You are on page 1of 417

Uso do Second Life no Suporte à

Aprendizagem Contextualizada de
Programação

Tese de Doutoramento apresentada por

Maria Micaela Gonçalves Pinto Dinis Esteves

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

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


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

A presente tese resultou do trabalho, esforço e dedicação da sua autora e do conjunto de


pessoas que de alguma forma a incentivaram, apoiaram e colaboraram para que esta se
concretizasse. Por isso pretendo expressar nesta nota o meu agradecimento a todos
aqueles que directa ou indirectamente me ajudaram.

Aos Professores Doutores Benjamim Fonseca e Leonel Morgado, orientadores desta


tese, a quem expresso a minha gratidão e agradecimento, pelo precioso apoio na
orientação e no incansável trabalho de acompanhamento prestado ao longo de todo este
processo, sem os quais seria impossível concluí-lo com êxito.

Aos professores Doutores Bulas Cruz e Paulo Martins pelo apoio constante na
realização deste trabalho.

Ao Professor Doutor António Pereira pelo carinho e incentivo manifestado ao longo


desta jornada.

Aos alunos que se voluntariaram para participar neste projecto, sem a sua
disponibilidade este estudo não existiria.

À Ivone Lopes e ao Luís Mendes pelo apoio e incentivo dado especialmente nas
revisões do Inglês dos artigos e pelas sugestões interessantes que forneceram.

Ao Instituto Politécnico de Leiria e à Escola Superior de Tecnologia e Gestão (ESTG)


por todas as facilidades concedidas.

Aos colegas do Departamento de Engenharia Informática da ESTG pela compreensão e


apoio que sempre me ofereceram, em especial aos colegas do grupo dos mundos
virtuais, nomeadamente ao Ricardo Antunes, pelo suporte e incentivo nesta longa
caminhada.

A toda a minha família em especial ao Manuel, Simão e Tiago não apenas pela
compreensão, apoio e incentivo, mas essencialmente por todo o tempo de convívio que
lhes roubei para concretizar esta tese.

Finalmente, os meus agradecimentos a todos aqueles que das mais variadas formas
ofereceram contributos para que o desenvolvimento deste trabalho fosse possível.

A todos agradeço sinceramente.

ii
iii
Resumo
Nesta tese apresenta-se o trabalho desenvolvido cujo objectivo consistiu na análise do
modo como o ensino e a aprendizagem introdutória da programação, a alunos nos
primeiros anos de cursos de informática do ensino superior, pode ser desenvolvido
dentro de um mundo virtual tridimensional online. Neste contexto, efectuou-se a revisão
da literatura, discutindo-se as questões das teorias de aprendizagem e respectivas
metodologias, nas quais se destaca a aprendizagem baseada em problemas, bem como, a
problemática da aprendizagem da programação e dos mundos virtuais tridimensionais
online, com o intuito de fundamentar a opção pelo mundo virtual adoptado.

O estudo realizado no contexto desta tese foi regido pela metodologia investigaçã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.

iv
v
Abstract
This thesis’ presents an analysis of how teaching and learning an introductory computer
programming at the university level could be developed within three-dimensional virtual
worlds. In this context, a revision of literature was made, the learning theories and
methods were presented and discussed, in which the problem-base learning was
highlighted; the difficulties reported in learning and teaching to programming; as well as
the review of the three-dimensional virtual worlds in order to substantiate the option
made.

This research adopted an action research methodology to the analysis of how teaching
and learning of computer programming at the university level could be developed within
the Second Life virtual world. Four cycles were employed in this study, from March
2007 to July 2008. Pre-exploratory research took place during the second semester of
the academic year 2006/2007, the first and second cycles of action research during the
first semester of 2007/2008, and the third and fourth cycles in the second semester of
that same academic year.

Results support the notion that it is possible to use this environment for a better
effectiveness in the learning of programming. The main results were the identification of
problems hampering the teacher’s intervention in this virtual world and the detection of
solutions for those problems that were found effective to the success in using this
environment for teaching-learning computer programming. It was also proposed a
framework for teaching-learning computer programming in these worlds, by
highlighting the factors that emerged as relevant in the analysis made.

Keywords: learning programming; collaborative virtual environments; action research;


virtual worlds; Second Life; project-based learning.

vi
vii
Índice
1. Introdução ............................................................................................................................ 2
1.1. 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

viii
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

ix
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.9. Plano do 2.º ciclo de investigação-acção ............................................................ 173
7.10. Resultados e reflexões do 2.º ciclo ...................................................................... 173
7.10.1. Professora......................................................................................................... 176
7.10.2. Questionários................................................................................................... 178
7.11. Plano do 3.º ciclo de investigação-acção ............................................................ 180
7.12. Resultados e reflexões do 3.º e 4.º ciclos de investigação-acção ..................... 183

x
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

xi
Índice de Figuras
Figura 2.1: Diferença entre o Behaviorismo e o Construtivismo. ...................................... 15
Figura 3.1: Ambiente de programação Eclipse IDE............................................................. 38
Figura 3.2: Exemplo de um padrão para a estrutura de repetição while. ........................... 44
Figura 3.3: Exemplo da animação de um algoritmo no sistema Algorithma 98,
representado na figura da esquerda e no sistema ANIMAL na figura da direita. ............ 49
Figura 3.4: Exemplo do sistema MatrixPro. .......................................................................... 50
Figura 3.5: Ambiente de trabalho do SICAS. ........................................................................ 51
Figura 3.6: Ambiente do animador de programas da Webworks. ...................................... 52
Figura 3.7: Ambiente de trabalho do Jeliot 3. ........................................................................ 53
Figura 3.8: Um exemplo do mundo de o Karel the robot. .................................................. 57
Figura 3.9 : Ambiente de trabalho do BlueJ. .......................................................................... 59
Figura 3.10: O ambiente de trabalho do Alice. ...................................................................... 60
Figura 3.11: Uma imagem de um mundo virtual criado com o Alice 3. ............................ 61
Figura 4.1: Avatares do Habitat. .............................................................................................. 71
Figura 4.2: À esquerda: avatar da investigadora no SL, “Micaela Korobase”. À direita:
um avatar do mundo virtual NeoPets. .................................................................................... 72
Figura 4.3: À esquerda: edição do aspecto visual do avatar da autora no mundo virtual
The Palace. À direita: edição da aparência de um avatar no mundo virtual MTV’s Virtual
Worlds – The Virtual Hills. ...................................................................................................... 73
Figura 4.4: Mapa de algumas áreas do Second Life, referenciando, nos pontos verdes, o
número de pessoas que se encontram em cada zona. .......................................................... 74
Figura 4.5: Exemplo de interacção com outro avatar do mundo Thinking Worlds. ....... 75
Figura 4.6: Exemplo de uma converção textual pública com vários avatares em
simultâneo no mundo virtual MTV......................................................................................... 75
Figura 4.7: Exemplo de uma conversa privada no Entropia Universe. ................................. 76
Figura 4.8: Seminário Ambientes Virtuais 3D em Educação na ilha da Universidade de
Aveiro no SL............................................................................................................................... 77
Figura 4.9: O interface do Jogo MUD textual. ...................................................................... 79
Figura 4.10: O interface do Meridian 59................................................................................. 81
Figura 4.11: À esquerda: aspecto gráfico do Ultima Online original. À direita: aspecto
actual. ........................................................................................................................................... 82
Figura 4.12: Exemplos de mundos virtuais de competição: Lineage II na imagem da
esquerda, World of Warcraft na imagem à direita................................................................. 84
xii
Figura 4.13: Exemplo de uma conversa textual pública; ..................................................... 86
Figura 4.14:Um avatar a experimentar roupa. ....................................................................... 87
Figura 4.15: Exemplo de uma conversa textual entre dois amigos no Frenzoo. ............. 88
Figura 4.16: O browser do Active Worlds Educational Universe. ..................................... 89
Figura 4.17: Na imagem da direita uma réplica da Praça do Comércio de Lisboa no SL;
Na imagem da esquerda uma réplica do Museu Nacional dos Coches no SL. ................ 90
Figura 4.18: Jogo America’s Army. ......................................................................................... 92
Figura 4.19: Mundo virtual criado no OpenCroquet para apoio ao ensino da
programação orientada a objectos........................................................................................... 94
Figura 5.1: Aspecto geral do viewer do Second Life. ........................................................... 100
Figura 5.2: Ilha no SL, durante a noite na qual se pode observar um belo céu estrelado.
.................................................................................................................................................... 102
Figura 5.3: Na imagem da esquerda, apresenta o terreno alugado pela autora, para dar
início às suas actividades. Na imagem da direita, a ilha da Universidade de Aveiro. ..... 103
Figura 5.4: O avatar da autora a editar a sua aparência no SL. ......................................... 104
Figura 5.5: O inventário de um avatar no SL. ..................................................................... 104
Figura 5.6: Exemplo de uma conversa pública entre vários avatares............................... 105
Figura 5.7: Exemplo de uma conversa privada entre dois avatares. ................................ 106
Figura 5.8: Exemplo de um cartão do SL. ........................................................................... 107
Figura 5.9:Exemplos de telas de informação no SL. .......................................................... 108
Figura 5.10: Objectos usados para transmitir pequenas mensagens no SL..................... 108
Figura 5.11: Editor de objectos no SL, no qual se observa o nome do dono e do criador
da cúpula azul. .......................................................................................................................... 110
Figura 5.12: A janela do editor que permite construir e alterar as propriedades dos
objectos. .................................................................................................................................... 111
Figura 5.13 : O menu redondo, designado de pie menu, na imagem da direita; na imagem
da esquerda, a janela inicial do editor de construção, com as várias prims que se podem
seleccionar................................................................................................................................. 112
Figura 5.14: A edição de uma prim no qual se pode observar os eixos direccionais a
vermelho, verde e azul. ........................................................................................................... 113
Figura 5.15: Objectos que auxiliam na rotação, na imagem da esquerda, e no aumento
do objecto, na imagem da direita........................................................................................... 113

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

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

xv
Índice de Tabelas

Tabela 4.1: Características dos mundos virtuais sociais........................................................ 91


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

xvi
xvii
Acrónimos

ACM 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

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

xix
1. Introdução

No presente capítulo introduz-se o tema desta tese, definindo o problema em questão,


especificando-se os objectivos a alcançar e os contributos resultantes deste trabalho.
Apresenta-se, ainda, a estrutura da tese.
Capítulo I: Introdução

3
Capítulo I: Introdução

1.1. Fundamentos da escolha do tema

Desde o início da sua carreira profissional que a autora tem estado ligada ao ensino da
programação, tendo-se iniciado nessa actividade no ensino secundário e actualmente no
ensino superior. Ao longo destes anos tem vindo a observar os problemas / dificuldades
que os alunos e professores enfrentam no seu dia-a-dia, razão pela qual se dedicou à sua
investigação.

Com o surgimento do primeiro computador por volta de 1945, tem-se vindo a assistir a
uma crescente proliferação deste em todos os sectores da actividade humana. Devido à
rápida evolução tecnológica do último século e primeira década do actual, como, por
exemplo, o aumento da capacidade de cálculo, a transmissão instantânea dos dados e a
incrível precisão das operações, constata-se que o computador é um instrumento
imprescindível. Tornou-se de tal maneira uma máquina de uso corrente que é
praticamente impossível não se tomar consciência da sua presença.

Mas, afinal, o que é um computador? É uma máquina que processa dados e executa
sobre eles, com uma cadência muito rápida, sequências de operações elementares, a
partir de informação inserida através de dispositivos de entrada, geralmente o teclado,
quando essa informação provém directamente de seres humanos (Rocha, 2008). Mais
concretamente, é uma máquina programável, em que as tarefas a desempenhar lhe são
fornecidas através de um programa, consistindo numa sequência de operações
elementares, que pode ser alterada ou substituída por outra sempre que se deseje.

Por ser este aspecto de máquina programável a característica-base do que constitui um


computador, a programação é considerada uma técnica elementar em qualquer curso da
área científica das Ciências Informáticas. Contudo, a programação está igualmente
presente na generalidade dos cursos de engenharia e de outras ciências, fazendo, por
isso, parte dos currículos destes cursos uma ou mais disciplinas de Ciências e Tecnologia
da Programação (Rocha, 2006). No caso de cursos que exijam conceitos sólidos de
programação e de desenvolvimento de software é normal que o seu estudo seja feito
através de várias disciplinas.

As primeiras disciplinas de programação aparecem normalmente logo no início da


generalidade dos cursos superiores de informática e áreas afins. Contudo, os alunos que
iniciam o estudo de uma linguagem de programação sentem muitas dificuldades na sua

4
Capítulo I: Introdução

aprendizagem. A consulta das actas das principais conferências mundiais na área de


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

1.1.Abordagem ao problema

A educação e a formação ao longo da vida constituem formas de aprender e de viver


que enriquecem o ser humano e dinamizam o desenvolvimento da sociedade. A
preocupação com a promoção de uma cultura que valorize a educação e a formação
desafia educadores e investigadores a procurarem estratégias que possam colaborar no
desenvolvimento efectivo de cada pessoa ao longo da vida (Miranda, Morais e Dias,
2007). Neste sentido e com a crescente evolução das tecnologias de informação e
comunicação e das diversas potencialidades que lhes estão associadas, o conceito de
ambiente de aprendizagem adquiriu novas dimensões, deixando de estar associado a um
intervalo temporal ou a um espaço físico bem definidos, para assumir novas variáveis
assentes não só nas características tecnológicas, mas também na flexibilidade temporal e
espacial, podendo cada pessoa desfrutar de ferramentas cognitivas de aprendizagem,
geralmente, a qualquer hora e em qualquer lugar.

Durante a última década, várias tecnologias foram desenvolvidas e adaptadas para


ambientes de aprendizagem, entre elas os mundos virtuais a três dimensões (3D). Por
“mundo virtual 3D”, considera-se, no âmbito desta tese, sistemas informáticos que
disponibilizam uma realidade virtual acessível em rede a vários utilizadores, geralmente a
partir de aplicações instaladas em computadores pessoais. Estas aplicações
disponibilizam vários elementos fundamentais de interacção, nomeadamente, a ilusão de
um espaço 3D onde os utilizadores estão inseridos; avatars, que são representações
virtuais dos utilizadores; e várias formas para os utilizadores comunicarem entre si
(Leonel, 2009). Neste âmbito, entre os mundos virtuais 3D mais populares, 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.

5
Capítulo I: Introdução

Uma das vantagens de utilizar um mundo virtual 3D para o ensino da programação é a


possibilidade que os aprendizes têm de ver um objecto ou colocá-lo sob múltiplas
perspectivas, que podem gerar uma melhor compreensão dos conceitos (Bricken e
Byrne, 1994). O trabalho de Dede (1995) vem reforçar esta ideia de que um mundo
virtual 3D oferece muitos benefícios, tais como a oportunidade de experimentar sem a
repercussão do mundo real, a oportunidade de aprender fazendo e a possibilidade de
personalizar o ambiente. Esta contextualização do conhecimento permite ao aprendiz
ter uma experiência não simbólica e na primeira pessoa de alguns conceitos.

Embora os mundos virtuais sejam relativamente recentes, já estão a ser usados como
um meio pedagógico, permitindo criar um ambiente 3D rico para contextualizar a
aprendizagem; sistemas de comunicação para apoiar a discussão e a colaboração; tirar
partido da integração Web que fornece em tempo real recursos e ferramentas para
pesquisar informação, como se refere no capítulo 3. Na literatura encontram-se alguns
defensores de que os mundos virtuais, vistos como ambientes virtuais de aprendizagem,
são o meio no qual se estabelece uma maior ligação interactiva entre o utilizador e o
computador (Schroeder, 1996; Prensky, 2001; Slator, Hill, Del Val, 2004; Danilicheva,
2010). Esta ligação prende-se com a sua capacidade de motivar, de envolver os
utilizadores, de ajudar a memorizar e a relembrar, e podem também encorajar o
desenvolvimento de várias habilidades sociais e cognitivas.

Por outro lado, vários autores (Carmen et al., 2010; Valdivia, Nussbaum e Ochoa, 2009)
referem os benefícios da aprendizagem colaborativa, uma vez que alunos têm que
explicar, justificar e argumentar as suas ideias aos outros. O uso dos mundos virtuais
fomenta a colaboração e a aprendizagem construtivista por permitir uma comunicação
em tempo-real juntamente com um ambiente visual e recursos de apoio à colaboração
(Dickey, 2005; Attasiriluk et al., 2009).

Face ao exposto, pretende-se analisar as características do uso dos mundos virtuais


tridimensionais para minimizar as dificuldades sentidas pelos alunos no seu processo de
aprendizagem da programação de computadores. Mais concretamente, pretende-se
utilizar um mundo virtual 3D de aprendizagem colaborativa para proporcionar um
ambiente visual contextualmente rico, imergindo os alunos num mundo onde estes
podem individual ou em grupo interagir e manipular a informação disponibilizada.

6
Capítulo I: Introdução

1.2. Objectivos e contributos fundamentais

O objectivo primordial deste trabalho foi explorar as possibilidades e dificuldades da


utilização dos mundos virtuais 3D online como plataforma para o ensino e aprendizagem
introdutória da programação de computadores a alunos do ensino superior.

Pretendeu-se analisar as características destes mundos quando utilizados em processos


de ensino e aprendizagem de programação, estudando e analisando os próprios
processos, como se desenvolvem, que tipos de apoios tecnológicos e metodológicos
requerem, que limitações e vantagens apresentam, tendo sempre em vista possibilitar
uma aprendizagem efectiva. De forma simples, verificar quais as dificuldades e as
facilidades de dar aulas e acompanhar os alunos no desenvolvimento dos seus trabalhos
nestes mundos.

Pretendeu-se também, com o trabalho apresentado nesta tese, definir um modelo para o
ensino e aprendizagem da programação de computadores nestes mundos virtuais 3D.
De forma a cumprir as finalidades propostas, foi necessário estabelecer um conjunto de
objectivos parcelares que se apresentam de seguida:

 Identificar e caracterizar os aspectos fundamentais da realidade complexa do


ensino e aprendizagem da programação de computadores e dos ambientes de
programação utilizados no seu suporte;

 Efectuar um estudo sobre o estado da arte dos mundos virtuais, onde deve ser
dada uma atenção especial às características que estes possuem que permitam a
sua utilização como plataforma para o ensino e aprendizagem da programação.
O levantamento do estado das características dos mundos virtuais revestiu-se da
maior importância no sentido de seleccionar um deles para ser usado neste
estudo;

 Efectuar um estudo rigoroso de como os processos de ensino e aprendizagem da


programação se desenrolam dentro do mundo virtual escolhido;

 Identificar e caracterizar os factores considerados relevantes no ensino e


aprendizagem da programação de computadores nos mundos virtuais 3D, de
modo a disponibilizar um modelo de apoio à sua utilização como plataforma.

7
Capítulo I: Introdução

O presente trabalho oferece um modelo de suporte às actividades de ensino e


aprendizagem da programação, contribuindo, deste modo, para melhorar a
aprendizagem da programação no ensino superior, procurando também ajudar os
professores a tirar partido dos mundos virtuais 3D para contextualizar o ensino da
programação, com a ambição de poder eventualmente minorar, desta forma, o insucesso
que actualmente se verifica.

A melhor compreensão do processo de ensino e aprendizagem da programação nestes


mundos virtuais é um caminho para a sua utilização nas aulas de introdução à
programação. Ao analisar se as dificuldades de utilização destes mundos virtuais para o
ensino e aprendizagem da programação podem ser superadas e como, constituiu-se uma
base que permite efectuar estudos tanto qualitativos como quantitativos para determinar
o impacte da sua utilização na motivação dos alunos para a aprendizagem, bem como de
outros temas ligados ao ensino e aprendizagem deste assunto.

1.3. Estrutura da tese

Esta tese possui sete capítulos, que estão organizados da seguinte forma:

Neste primeiro capítulo, de introdução, foi definido o problema, sendo especificados os


objectivos que se pretendiam alcançar, bem como os contributos resultantes deste
trabalho, e apresenta-se, ainda, a estrutura da dissertação.

No segundo capítulo focam-se os pressupostos teóricos que sustentam esta


investigação, onde são referidas as ideias dos diversos autores que contribuíram para o
desenvolvimento destas teorias. Mencionam-se algumas das metodologias educativas
inspiradas nestas teorias das quais se destaca a aprendizagem baseada em problemas.

No terceiro capítulo, referente ao ensino da programação, efectua-se uma resenha das


linguagens de programação que estão a ser utilizadas no ensino, assim como os
respectivos ambientes de programação, sendo também apresentadas as principais
dificuldades referidas na literatura.

O quarto capítulo apresenta uma caracterização genérica dos mundos virtuais. Nele se
faz um levantamento e classificação dos principais mundos virtuais existentes, dando
especial atenção aos mundos que apresentam características que possibilitam a sua
utilização no ensino e aprendizagem da programação.

8
Capítulo I: Introdução

No quinto capítulo efectua-se uma descrição detalhada do mundo virtual Second Life,
expondo as suas características principais. Apresenta-se também o modo como se
constroem objectos 3D neste mundo virtual, evidenciando-se a implementação de
programas neste mundo, de forma a gerar diferentes comportamentos para os objectos
criados.

No sexto capítulo é explicada a abordagem de investigação seguida, efectuando-se


igualmente uma explanação da estrutura metodológica da investigação-acção.

No sétimo capítulo, sobre a aplicação do método de investigação, descreve-se a praxis


educativa efectivada, regida pela metodologia investigação-acção, para obter respostas
ao problema proposto.

No oitavo capítulo, dedicado à reflexão e discussão dos resultados obtidos.

No nono capítulo apresenta-se o modelo proposto para a utilização do mundo virtual


Second Life como plataforma para o ensino introdutório da programação.

No último capítulo, de conclusão, recorda-se o problema e faz-se uma análise global do


trabalho realizado, tendo em conta os objectivos estabelecidos. Termina-se com diversas
reflexões sobre a continuidade desejada para este estudo.

9
2. Aprendizagem – fundamentos teóricos

Neste capítulo faz-se uma breve introdução às diferentes teorias da aprendizagem,


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

11
Capítulo II: Aprendizagem – Fundamentos Teóricos

2.1. Teorias de aprendizagem

Tudo o que ao longo da nossa vida provoca uma mudança que transforme a nossa
relação com o mundo pode e deve ser considerado aprendizagem. O progresso da
humanidade, o desenvolvimento científico, as grandes realizações conseguidas nas mais
diversas áreas culturais, só foram possíveis pelo facto de o ser humano possuir
capacidades para aprender, para reter e para transmitir às gerações vindouras as formas
pelas quais, ao longo da história, foi sendo configurada a adaptação ao mundo que o
rodeia (Abrunhosa, Leitão, 2002). De um modo espontâneo, consciente ou
inconscientemente, com pouco ou muito esforço, estamos constantemente a aprender.

Ao longo dos tempos o homem tem vindo a procurar compreender e aperfeiçoar os


métodos de estímulo e/ou apoio à aprendizagem – em particular, o ensino. Esta procura
contínua permitiu o desenvolvimento de muitas teorias que tentam explicar como o ser
humano aprende. Sendo difícil pormenorizar o conjunto dos fundamentos teóricos, que
ultrapassam o propósito deste trabalho, expõem-se, contudo, algumas teorias basilares
referindo-se em cada uma delas as principais figuras onde se enquadra este estudo.

2.1.1. Behaviorismo

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

2.1.1.1. Ivan Pavlov

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

12
Capítulo II: Aprendizagem – Fundamentos Teóricos

 Um estímulo (um pedaço de carne) provoca uma reacção (começa a salivar) –


«reflexo simples»;

 A associação de estímulos desencadeia-se a mesma reacção – acrescentou o som


de uma campainha sempre que apresentava o pedaço de carne ao cão e este
começava a salivar;

 O novo estímulo provoca uma resposta adequada ao primeiro estímulo «reflexo


condicionado» – o cão apenas ouve o som da campainha e começa a salivar.

Em dado momento da experiência o cão é capaz de responder ao estímulo


condicionado como se do estímulo não condicionado se tratasse. A este processo
chama-se de condicionamento e consiste em associar um estímulo condicionado a um
estímulo natural, de tal modo que o indivíduo reage ao estímulo condicionado do
mesmo modo que reage ao estímulo natural. Por conseguinte, Pavlov define o
comportamento como o conjunto de respostas objectivamente observáveis que o
organismo executa face a estímulos também objectivamente observáveis (Abrunhosa,
Leitão, 2002).

2.1.1.2. John Broadus Watson

Watson foi um psicólogo americano, influenciado pelos estudos de Pavlov, fundador da


corrente científica da psicologia conhecida por behaviorismo. Segundo Watson (1913) a
psicologia tem de ser objectiva. Assim propõe que a psicologia estude apenas o que é
observável, ou seja, o comportamento (behaviour), e se abstenha de qualquer tentativa
de identificar actividades mentais. A ligação Estímulo-Resposta, para Watson (1928),
processa-se de modo mecânico, o que lhe permite fazer uma interpretação causal do
comportamento e, consequentemente, elaborar leis explicativas do mesmo.

Tais leis pretendiam:

 Perante um determinado estímulo, prever a reacção subsequente.

 Perante uma dada resposta, determinar o estímulo que a desencadeou.

Para Watson (1928), os diferentes comportamentos são adquiridos segundo processos


de condicionamento, designados de «condicionamento clássico». A aprendizagem resulta
da resposta a um estímulo e esta não é mais do que a aquisição de um novo
comportamento.

13
Capítulo II: Aprendizagem – Fundamentos Teóricos

2.1.1.3. Burrhus Frederic Skinner

Skinner, psicólogo americano nascido em 1904, ficou conhecido pelas suas experiências
com animais, nomeadamente ratos, para as quais criou uma caixa especial, designada por
caixa de Skinner. Esta caixa possuía um dispositivo que permitia o fornecimento
automático de alimento (reforço) ao animal em observação. Para além disso, continha
também um mecanismo que registava as respostas do animal, dispensando o
pesquisador de uma permanente observação. No final dispunha de um registo
cumulativo das respostas do animal em observação.

Skinner colocou um rato faminto dentro da sua caixa e constatou que ao fim de algum
tempo o roedor descobre que para obter alimento tem de premir uma alavanca. Como o
animal só pode comer após ter accionado a alavanca, o alimento vai reforçar essa
resposta, ou seja, o animal aprende a pressionar a alavanca em função do reforço que é
o alimento. Isto significa que se estabeleceu no rato a associação entre a resposta
operante (premir a alavanca) e o reforço (alimento). A este processo denomina-se de
«condicionamento operante». Skinner (1983) considera que a aprendizagem ocorre
quando uma resposta a um estímulo é reforçada (reforço).

Embora o behaviorismo seja objectivo, ao fazer depender as respostas exclusivamente


de situações objectivamente observáveis, tem sido criticado por esta restritividade. No
cerne das críticas está a preocupação de que conduza a uma interpretação simplista e
demasiado redutora da conduta humana (Pereira, 2007).

2.1.2. Construtivismo/Cognitivismo

A teoria construtivista ou cognitivista opõe-se à behaviorista, pois considera a


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

14
Capítulo II: Aprendizagem – Fundamentos Teóricos

Behaviorismo ≠ Construtivismo/Cognitivismo

Carácter passivo Carácter activo


do sujeito do sujeito

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

Vários autores contribuíram para o desenvolvimento desta teoria, destacando-se


tradicionalmente figuras como J. Piaget (1896-1980), L. Vygotski (1896-1934) e J.
Bruner (1915-).

2.1.2.1. Jean Piaget

Piaget foi o grande introdutor do construtivismo/cognitivismo no panorama das


ciências modernas (Pereira, 2007). Formado em biologia, interessou-se por investigar o
desenvolvimento do conhecimento nos seres humanos. Segundo Piaget (1977), todos os
comportamentos humanos resultam da interacção organismo-meio.

“O conhecimento não é uma cópia do objecto nem uma tomada de consciência das formas a
priori que sejam predeterminadas no sujeito, é uma construção perpétua através de
intercâmbios entre o organismo e o meio, do ponto de vista biológico, e entre o pensamento e o
objecto, do ponto de vista cognitivo.” (Piaget, 1977).

Dito de outro modo, o conhecimento resulta da acção conjunta de factores individuais


de ordem inata e de factores adquiridos no contacto com a experiência. Opondo-se aos
behavioristas, Piaget afirma que o sujeito é um participante activo no seu próprio
desenvolvimento.

O construtivismo de Piaget explica a aprendizagem por um processo semelhante ao da


alimentação dos seres vivos: assimilação/acomodação/procura do equilíbrio. O
desenvolvimento cognitivo seria caracterizado por várias fases (estágios) alcançadas
pelas estruturas dos esquemas à disposição do indivíduo. Segundo Piaget (1977), cada
etapa ou estágio do desenvolvimento é caracterizada pela presença de esquemas mentais
que, quando coordenados entre si, constituem uma estrutura. Desta forma, o
desenvolvimento cognitivo faz-se por etapas sucessivas em que as estruturas mentais se

15
Capítulo II: Aprendizagem – Fundamentos Teóricos

constroem progressivamente. Cada novo estágio representa uma forma de equilíbrio


cada vez maior, que permite uma adaptação mais adequada às circunstâncias. Em todos
os estágios, a permuta entre o sujeito e o mundo opera-se por dois mecanismos
constantes, que são a assimilação e a acomodação. Assim, perante uma nova situação,
desconhecida, o aprendiz tenta primeiro identificá-la, incorporando-a nos esquemas já
constituídos. Este apoia-se nas referências conhecidas. A esta regulação Piaget
denomina de assimilação, que pode ser suficiente, mas pode, noutras circunstâncias,
revelar-se insuficiente e necessitar da modificação dos esquemas referenciais, ou até
mesmo da criação de novos esquemas. É a acomodação. O processo complementar,
dialéctico, que combina assimilação e acomodação, conduz ao equilíbrio. O processo de
equilíbrio permite a evolução, ela guia a coordenação das acções. Para Piaget a procura
do equilíbrio é auto-regulação dinâmica, regulação que tende a aperfeiçoar-se em função
dos factos exteriores que intervêm. É um processo que tende para o equilíbrio mas
nunca está efectivamente estabilizada.

“ (...) A cada instante, a acção é desequilibrada pelas transformações que aparecem no


mundo, exterior ou interior, e cada nova conduta vai funcionar não só para estabelecer o
equilíbrio, mas também para tender a um equilíbrio mais estável que o do estágio anterior a
esta perturbação.

(...) Pode dizer-se que toda a necessidade tende: 1º a incorporar as coisas e pessoas à
actividade própria do sujeito, isto é, “assimilar” o mundo exterior às estruturas já
construídas, e 2º, a reajustar estas últimas em função das transformações ocorridas, ou seja,
“acomodá-las” aos objectos externos. Assim, toda a vida mental e orgânica tende a
assimilar progressivamente o meio ambiente.

(...) Ora, assimilando assim os objectos, a acção e o pensamento são compelidos a


acomodarem-se a estes, isto é, a reajustarem-se por ocasião de cada variação exterior. Pode
chamar-se “adaptação ao equilíbrio destas assimilações e acomodações. O desenvolvimento
mental aparecerá, então como uma adaptação sempre mais precisa à realidade. “. (Piaget,
1973).

Para Piaget (1976) a aprendizagem implica provocar o desequilíbrio na mente do aluno


para que este procure o reequilíbrio, se reestruture cognitivamente e aprenda.

“A equilibração cognitiva é, pois, “majorante”, o que significa que os desequilíbrios não


conduzem a um regresso à forma anterior de equilíbrio, mas a uma forma melhor” (idid.).

16
Capítulo II: Aprendizagem – Fundamentos Teóricos

Contudo, na aprendizagem é necessário ter em consideração o desenvolvimento


cognitivo do aprendiz a cada momento, não se devendo propor-lhe tarefas que estejam
completamente além das suas capacidades (Pereira, 2007).

2.1.2.2. Lev Vygotski

Lev Vygotsky nasceu na Bielorrússia, em 1896. Trabalhou no Instituto de Psicologia de


Moscovo, entre 1923 e 1934, onde teve oportunidade de desenvolver as suas teorias
sobre o desenvolvimento cognitivo e a relação entre o pensamento e a linguagem.
Como marxista, acreditava que só podia compreender o ser humano no contexto do seu
ambiente sócio-histórico. Vygotsky (1979) enfatizou a ligação entre as pessoas e o
contexto cultural em que vivem e são educadas. De acordo com este autor, as pessoas
usam instrumentos que vão buscar à cultura onde estão imersas e entre esses
instrumentos tem lugar de destaque a linguagem, a qual é usada como mediação entre o
sujeito e o ambiente social. O conhecimento é inicialmente construído num nível social
e posteriormente num nível individual.

“(...) o verdadeiro curso do desenvolvimento do pensamento não vai do individual para o


socializado, mas do social para o individual.” (Vygotsky, 1979)

Da obra de Vygotski, destaca-se a ideia que marca de forma determinante os processos


pedagógicos ligados à educabilidade. Trata-se do conceito de zona de desenvolvimento
próximo (ZDP). É aprendendo a resolver uma situação com um tutor que domina o
esquema que o aprendiz progride e constrói, por sua vez, o esquema considerado
(Perraudeau, 2000). Vygotsky (1979) considera dois níveis distintos de desenvolvimento
em que o aprendiz pode desenvolver diferentes capacidades. Por um lado, o chamado
nível ou zona de desenvolvimento actual e, por outro, o nível ou zona de
desenvolvimento proximal. A zona de desenvolvimento proximal estabelece a distância
entre o que o aluno domina sozinho e o que ele domina com a colaboração de um
adulto, ou com os colegas mais capazes.

“Para determinar o actual nível de desenvolvimento, utilizam-se problemas que a criança


deve resolver sozinha e que são indicativos em relação às funções já formadas e chegadas à
maturidade.

(...) Esta disparidade entre a idade mental, ou o nível de desenvolvimento actual, que é
determinado com o auxílio dos problemas resolvidos de forma autónoma, e o nível atingido

17
Capítulo II: Aprendizagem – Fundamentos Teóricos

pela criança, quando resolve problemas, já não sozinha mas em colaboração, determina
precisamente a zona de desenvolvimento próximo.

(...) a pesquisa mostra que a zona de desenvolvimento próximo tem um significado mais
directo para a dinâmica do desenvolvimento intelectual e no êxito da aprendizagem do que
no nível actual do seu desenvolvimento.” (Vygotsky, 1979).

Segundo Vygotski (1981), construir o saber consiste em determinar um processo que


evite dois perigos. O primeiro é o de propor uma situação já dominada: o propósito é,
neste caso, vazio de sentido para o aprendiz. O segundo consiste no seu contrário: uma
situação de tal modo afastada dos esquemas adquiridos que a ajuda de um tutor, fora da
zona, se revelaria inoperante. Com efeito, parece que o aluno tira melhor proveito
quando o nível cognitivo do mediador é ligeiramente superior ao seu. Uma distância
cognitiva demasiado grande implica, por parte do aluno auxiliado, a aceitação de um
saber sem questionamento autêntico (Perraudeau, 2000).

2.1.2.3. Jerome Bruner

Jerome S. Bruner, psicólogo americano de formação, nasceu em 1915, sendo designado


de “o pai da Psicologia Cognitiva”, devido ao seu papel relevante no campo da
cognição. O pensamento de Bruner foi influenciado pela obra de Vygotsky,
principalmente no que se refere ao contexto social da aprendizagem (Pereira, 2007).

Bruner (1966) considera a aprendizagem um processo activo em que os sujeitos da


aprendizagem constroem as ideias ou os novos conceitos baseados nos seus saberes pré-
adquiridos ou actuais. Segundo este autor existe uma coordenação entre aquilo que o
sujeito pensa quando constrói a sua aprendizagem e o percurso do pensamento para
chegar ao objecto em estudo. Compreender um objecto é desenvolver um processo
dedutivo de categorização: no final de um raciocínio, o objecto é entendido como
pertencendo a uma categoria. A categorização, que se pode chamar de conceptualização,
constrói-se pela e através da linguagem (Perraudeau, 2000). Dito por outras palavras, o
sujeito da aprendizagem selecciona a informação e transforma-a, constrói hipóteses e
toma as decisões necessárias a essa construção, recorrendo-se da sua estrutura cognitiva
para o fazer. A estrutura cognitiva fornece o significado e a organização à realidade com
que o sujeito se confronta e permite ao sujeito da aprendizagem ir além da informação
recebida. Uma vez que o processo está ligado ao produto, o indivíduo aborda um novo

18
Capítulo II: Aprendizagem – Fundamentos Teóricos

conteúdo a partir do que já sabe e a partir da forma como integrou esse conhecimento
anterior. Assim, não é, antes de mais, o conteúdo exposto que informa o aluno, mas
aquilo que ele sabe é que lhe permite atribuir um significado ao conteúdo exposto
(Barth, 1995).

Bruner parte do conceito de que aprendizagem é a modificação do comportamento


resultante da experiência – aspecto particularmente evocativo da perspectiva
behaviorista. Contudo, de acordo com Perraudeau (2000), a concepção de Bruner
decorre da concepção de Piaget, por considerar que o conceito não se pode formar sem
ser através da construção, e distancia-se dele, pelo facto de, para Bruner, a construção se
efectuar graças à linguagem, em interacção entre os indivíduos.

“ (...) a aprendizagem é amplamente facilitada pela linguagem, a qual constitui não só um


meio de comunicação, mas também um instrumento que o indivíduo em situação de
aprendizagem pode utilizar de forma a ordenar o meio ambiente.” (Bruner, 1966, p.6).

Deste modo, Bruner atribui à linguagem um papel ordenador do meio ambiente, o qual
se afigura imprescindível num processo sistemático de aprendizagem pela progressiva
representação do mundo exterior que permite.

Bruner (1960) defende que:

“ (…) qualquer assunto pode ser eficazmente ensinado de uma forma intelectualmente
perceptível a qualquer criança em qualquer estado de desenvolvimento.”

Esta alegação constitui uma inovação, principalmente em relação às teorias de Piaget.


Por conseguinte, a aprendizagem deve sempre iniciar-se no ponto em que o aprendiz se
encontra sendo possível ensinar tudo ao aluno desde que se utilizem procedimentos
adaptados ao seu estágio de desenvolvimento e às suas necessidades. Esta noção está
subjacente à ideia de o currículo dever ser organizado em espiral, de modo a que as
construções que o sujeito realiza se façam continuamente sobre a aprendizagem já
realizada, construindo novas aprendizagens (Riding, 1980).

Bruner (1990) enfatiza a aprendizagem através da descoberta, na qual salienta o processo


activo do aluno. Deste modo, refere que para que se verifique, por parte do aluno,
aprendizagem deve haver uma situação de desafio que o leve a resolver problemas. Com
esta ideia, Bruner faz uma crítica às metodologias expositivas, considerando, ao invés,
que a aprendizagem das Ciências se faz melhor através do envolvimento dos alunos no
processo de descoberta e no uso das metodologias científicas próprias de cada ciência:

19
Capítulo II: Aprendizagem – Fundamentos Teóricos

“Julgamos que, logo de início, o aluno deve poder resolver problemas, conjecturar, discutir
da mesma maneira como se faz no campo científico da disciplina” (Bruner, 1966).

Contudo, Bruner refere na sua obra Toward a theory of instruction (1966) que para a
exploração de alternativas, por parte do aprendiz, é essencial “a presença de um nível
óptimo de incerteza”. Torna-se necessário, para garantir este último, agir de forma a
evitar que as tarefas a executar, no âmbito da exploração de alternativas, sejam de
acentuada rotina ou de demasiada incerteza. No primeiro caso, haverá “pouca
exploração” por parte dos sujeitos em situação de aprendizagem; no segundo, poderá
surgir “confusão e ansiedade”, o que implicará uma “redução da exploração”.

2.1.3. Teoria da aprendizagem situada

Lave e Wenger (1991) influenciados pelas ideias de Vygotsky, principalmente pelo


conceito de zona de desenvolvimento proximal, desenvolveram os princípios da
aprendizagem situada. A aprendizagem situada consiste na conjugação do saber e do
fazer, e implica que as actividades individuais e colectivas sejam parte de um todo
mutuamente construído, num processo dinâmico, activo, interactivo, dialéctico e
transaccional, que contribui para desenvolver conhecimentos sólidos e úteis (Wenger,
1998). Situar a aprendizagem significa, segundo Wenger (1998), criar condições para que
os aprendizes experimentem a complexidade e a ambiguidade da aprendizagem em
situações autênticas, criando assim o seu conhecimento através dos materiais, da
experiência, tais como as relações com os outros, as actividades, o ambiente e a
organização social dos participantes. Dito de outra forma, o conhecimento é uma
relação activa entre o aprendiz e o ambiente, e a aprendizagem ocorre quando o
aprendiz se envolve activamente com o contexto de instrução, que deve ser complexo e
realista.

Esta teoria está na origem do conceito de scaffolding, o qual teve origem na ZDP de
Vygostky, que em português nos remete para a noção de andaime. De facto, a função
dum andaime é apenas segurar uma estrutura em fase de crescimento. Uma vez a
estrutura construída e alicerçada, o andaime é retirado e voltará a ser colocado numa
nova posição com vista ao progresso da construção (Bettencourt-da-Cruz, 2006). Esta
noção de andaime tem como característica central o processo designado de participação
periférica legítima, que é um processo de entrada numa comunidade de prática do
conhecimento, envolvendo a participação nas práticas socioculturais, em que a unidade

20
Capítulo II: Aprendizagem – Fundamentos Teóricos

básica de análise é a actividade contextualizada das pessoas (Pereira, 2007). Uma


comunidade de prática é constituída por participantes de diferentes níveis: central, activo
e periférico. Um novo elemento que se junta à comunidade desloca-se da periferia para
o centro desta, tornando-se mais activo e envolvido na cultura subjacente.
Consequentemente, pode chegar a assumir o papel de um perito.

Neste contexto, a aprendizagem é concebida como um fenómeno sociocultural onde o


conhecimento é negociado e aplicado em situações do dia-a-dia, contrariando a
perspectiva da aprendizagem como acção de um indivíduo que obtém informação geral
a partir dum corpo de conhecimentos abstractos e descontextualizados (Bettencourt-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

21
Capítulo II: Aprendizagem – Fundamentos Teóricos

conceitos, e vice-versa, pode condenar as futuras gerações a um vazio cognitivo e a


resistências à mudança, que podem comprometer seriamente a resolução dos desafios
futuros que se lhes avizinham, onde a capacidade de aprendizagem se transformará em
vantagem competitiva e em eficácia organizacional.

Das referências teóricas anteriormente estabelecidas, surgiram algumas práticas para


novas formas de aprendizagem como, por exemplo, aprendizagem situada,
aprendizagem baseada em problemas, aprendizagem por descoberta, entre outras. As
características da metodologia da aprendizagem baseada em problemas, descritas na
secção seguinte, foram os factores que motivaram a autora em adoptá-la neste estudo,
em detrimento de outras.

2.2.1. Aprendizagem baseada em problemas

A aprendizagem baseada em problemas, conhecida pela sigla PBL (Problem-Based


Learning), tem vindo a ser aplicada há mais de 20 anos em diferentes domínios da
educação e em diferentes países. A primeira aplicação da PBL verificou-se no ensino
médico durante os anos 60 do século passado, tendo-se estendido a vários outros temas
do ensino superior e também secundário (Barrows, 2001). A sua aplicação no ensino
superior tem vindo a ser relatada com sucesso em diferentes áreas como, por exemplo,
no ensino da medicina (Barrows e Tamblyn, 1980; Hogan e Eva, 2005), da arquitectura
(Kingsland, 1996), da gestão (Stinson e Milter, 1996), da engenharia (Woods, 2001;
Lahtinen, 2005), entre outros domínios (Raine e Symons, 2005; Bateman et al., 2007;
Yang et al., 2009).

A PBL é uma forma colaborativa de ensino-aprendizagem, na qual se pretende propiciar


uma construção activa, coerente, de modelos mentais do conhecimento, ao invés do
simples processamento dos assuntos. É também uma forma de ensino-aprendizagem
contextualizada, uma vez que os princípios, as ideias e os mecanismos não são
estudados em abstracto, mas antes no contexto de uma situação concreta que pode ser
reconhecida pelos aprendizes como relevante e interessante. No caso ideal, a situação
assemelhar-se-á à situação profissional futura na qual o conhecimento adquirido irá ser
aplicado (Schmidt e Moust, 2001). Esta metodologia centra-se na resolução de
problemas complexos da vida real como um estímulo para a aprendizagem, integração e
organização da informação aprendida, de forma a garantir a sua aplicação em problemas
futuros (Tsai e Shen, 2009).

22
Capítulo II: Aprendizagem – Fundamentos Teóricos

Segundo Barrows (2001), o objectivo da PBL consiste em formar aprendizes que:

 adquiram uma base de conhecimentos integrada;

 obtenham uma base de conhecimentos estruturada relativa de problemas reais


da área de actuação do profissional em questão;

 ganhem uma base de conhecimentos associada a processos de resolução de


problemas;

 se envolvam, com iniciativa e entusiasmo, nos problemas que vão encontrando


ao longo da sua vida profissional;

 empreguem as capacidades de aprendizagem auto-dirigida, de forma a


continuarem o seu processo de aprendizagem ao longo da vida;

 examinem e avaliem a adequação dos seus conhecimentos de forma contínua;

 colaborem de forma eficaz como membros de um grupo.

A PBL, para além de promover a construção do conhecimento, fomenta a auto-reflexão,


a cooperação e a responsabilidade, sendo estas partes integrantes do processo de
aprendizagem (Gijselaers, 1996; Norman & Schmidt, 1992; Savery e Duffy, 1995).
Resumindo, uma das características que tornam a PBL num modelo educacional em
expansão, no que se refere à sua utilização no ensino, é o facto de se poder atingir
objectivos educacionais mais amplos, ou seja, permite não só a construção de
conhecimentos, por parte dos alunos, mas também o desenvolvimento de capacidades e
atitudes que lhes serão úteis na sua vida profissional futura, independentemente do
percurso que escolham.

2.2.1.1. A implementação da PBL

Em algumas instituições de ensino, a PBL foi implementada como uma estratégia de


educação em todos os anos curriculares de um curso como, sendo este formado por um
conjunto de problemas que constitui a espinha dorsal do currículo. Para além desta
estratégia, existem outras aplicações desta metodologia como estratégia educacional em
unidades curriculares isoladas dentro de um currículo convencional (Barrows, 2001;
Hogan e Eva, 2005).

Este modelo de aprendizagem tem dois aspectos centrais: a natureza do problema


utilizado, que é o impulsionador da aprendizagem; e a aprendizagem centrada no aluno

23
Capítulo II: Aprendizagem – Fundamentos Teóricos

(Duch et al., 2001). O problema é o ponto de partida no processo de aprendizagem dos


alunos. Assim, a qualidade do problema adoptado é um ponto central nesta
metodologia. Segundo o estudo realizado por Schmidt e Moust (2001) sobre a qualidade
do problema na PBL, quanto melhor for o conteúdo do problema adoptado, melhor
será o empenho dos alunos na sua resolução e maior será o interesse que estes
demonstram no assunto em estudo. Estes autores referem ainda que os problemas de
fraca qualidade apresentam um risco para a aprendizagem dos alunos, uma vez que estes
se sentem frustrados e desinteressados pelo que estão a aprender. Deste modo, o
conteúdo do problema deve ter um significado pessoal para os discentes e assim 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

24
Capítulo II: Aprendizagem – Fundamentos Teóricos

construtiva dos seus pares, imprescindíveis para uma aprendizagem autónoma e eficaz
(Barrows, 2001).

2.2.1.2. O papel do professor e dos alunos na PBL

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

Em suma, as teorias de aprendizagem podem ser implementadas na prática de ensino de


várias formas, nesta tese optou-se por empregar uma que tem um historial de êxito em
várias áreas tecnológicas e científicas, a PBL.

25
3. Ensino da Programação

Procura-se neste capítulo apresentar a situação actual do ensino introdutório da


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

27
Capítulo III: Ensino da Programação

3.1. Programar, o que é?

Numa visão genérica do termo, programar significa planear. No nosso quotidiano, todos
programamos algo. Por exemplo: programamos o nosso dia de trabalho, programamos
o relógio despertador para uma determinada hora, programamos as nossas férias, etc. E
todos somos capazes de o fazer com relativa facilidade.

“Programming is a widespread activity that is done both by nonspecialists (e.g., consumers who
change the settings of their alarm clock or cellular phone) and specialists (computer
programmers).” (Roy e Haridi, 2003).

Quando se fala em programar um computador, as coisas tornam-se mais complicadas.


Um computador, como foi referido no capítulo de introdução desta tese, é uma
máquina que processa dados e executa, com uma cadência muito rápida, sequências de
operações elementares, a partir de informação inserida através de dispositivos de
entrada, tipicamente o teclado (Rocha, 2008). Mais concretamente, é uma máquina
programável, em que as tarefas a desempenhar são-lhe fornecidas através de um
programa, que é uma sequência de operações elementares, podendo ser alterada ou
substituída por outra sempre que se deseje. Desta forma, a escrita de um programa tem,
normalmente, por objectivo resolver um ou mais problemas. Deve-se começar por
compreender e analisar o problema em questão, com o propósito de se esboçar uma
solução eficaz para o mesmo. A concepção de uma solução requer escrever um
conjunto finito, preciso e ordenado de passos que executados por uma determinada
ordem resolvem um problema - o algoritmo. Em seguida, é preciso codificar a solução
encontrada numa linguagem de programação, verificar se esta cumpre as regras
sintácticas da linguagem de programação em causa e testar se faz o pretendido, isto é, se
resolve o problema em questão.

Numa perspectiva mais elevada de mestria, programar é uma arte (no sentido de
“ofício”), porque existem muitas maneiras diferentes de codificar instruções, permitindo
a criatividade. É também uma ciência (no sentido de “saber estruturado”), porque é
constituída por um conjunto de regras orientadoras, porque é necessário o uso de lógica
e porque existem alguns métodos rigorosos de programação que asseguram a eficiência,
economia e utilidade dos programas gerados (Gomes, 2008).

28
Capítulo III: Ensino da Programação

3.2. Dificuldades na aprendizagem da programação

As disciplinas de programação surgem na generalidade nos primeiros anos dos cursos


superiores da área científica das Ciências Informáticas, sendo consideradas uma técnica
base destes cursos, como salientam Tucker et al. (2003)

“While programming is a central activity to computer science, it is only a tool that provides
a window into a much richer academic and professional field. That is, programming is to
the study of computer science as literacy is to the study of literature.”

O ensino inicial da programação centra-se no desenvolvimento de algoritmos, na


aprendizagem dos conceitos básicos da programação, na qual se utiliza, na sua maioria,
uma linguagem de programação procedimental ou orientada a objectos (McCracken et
al., 2001; Goldman et al., 2010). As competências-base que os alunos devem adquirir nos
primeiros anos de aprendizagem da programação (Goldman et al., 2010) são as
seguintes:

 Resumir o problema a partir da sua descrição – os alunos devem ser capazes, a


partir da especificação do enunciado do problema, de extrair os aspectos
relevantes deste.
 Gerar o algoritmo – Os alunos devem conseguir desenvolver uma solução para o
problema em causa. Esta solução pode ser efectuada por módulos, isto é, a
partir do problema inicial, os alunos devem ser capazes de decompô-lo em 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).

29
Capítulo III: Ensino da Programação

“By June 1949 people had begun to realize that it was not so easy to get a program right
as had at one time appeared. I well remember when this realization first came on me with
full force. The EDSAC (Electronic Delayed Storage Automatic Computer) was on the
top floor of the building and the tape-punching and editing equipment one floor below on a
gallery that ran round the room in which the differential analyser was installed. I was
trying to get working my first non-trivial program, which was one for the numerical
integration of Airy's differential equation. It was on one of my journeys between the
EDASC room and the punching equipment that “hesitating at the angles of stairs" the
realization came over me with full force in that a good part of the remainder of my life was
going to be spent in finding errors in my own programs.".

Apesar dos avanços tecnológicos, a aprendizagem da programação continua a ser


considerada uma tarefa árdua, principalmente para os alunos que pela primeira vez têm
contacto com ela, uma vez que o processo de familiarização com a programação não é
simples, sendo vários os conceitos que têm de ser compreendidos e praticados. Os
alunos têm de ter uma boa capacidade para resolver problemas, conhecer a sintaxe e a
semântica da linguagem de programação e serem capazes de compreender o código
existente (Winslow, 1996, Garner, 2008, Stiller, 2009). Como advoga Dijkstra (1989),
aprender a programar é um processo lento e gradual que requer um estudo baseado na
prática, e que é bastante diferente da maioria das disciplinas mais teóricas, que requerem
muita leitura e alguma memorização. Daí, ser necessário haver uma consciencialização
por parte dos alunos, quando iniciam o estudo da programação, que programar se
aprende fazendo e não vendo como se faz. A programação exige um treino intensivo na
resolução de problemas, envolvendo competências de diversas áreas para obter um
pequeno retorno (Perkins et al. 1988; Dijkstra, 1989). Como salienta Ben-Ari (2001), os
conceitos de programação não podem ser directamente transferidos do professor para
os alunos, eles devem ser activamente adquiridos por estes.

Apesar deste quadro de complexidade que envolve a aprendizagem da programação,


existem alunos que aprendem a programar facilmente, sem necessitarem de fazer um
esforço excessivo. Contudo, grande parte dos alunos não o consegue sem um
acompanhamento intensivo por parte do professor (Robins et al., 2003). Outros alunos
simplesmente acabam por desistir do curso por não alcançarem aprovação às disciplinas
que envolvem a programação (Kelleher e Pausch, 2005; Garner, 2009). Por outro lado,
uma percepção negativa sobre a natureza e os atractivos do trabalho na área da
computação, principalmente o receio de terem de trabalhar isolados sem contacto

30
Capítulo III: Ensino da Programação

humano e de ser um campo da ciência que atrai poucas mulheres, são factores que têm
contribuído para o declínio do interesse mostrado pelos alunos por esta área do saber
(Cassel et al., 2007; Stiller, 2009).

Várias têm sido as razões apontadas na literatura científica para as causas destas
dificuldades. Linn e Clancy (1992) referem que os alunos sentem dificuldades em
compreender o enunciado do problema e consequentemente em desenhar uma solução
para o mesmo. No estudo realizado por McCracken et al. (2001), no qual participaram
alunos de diferentes instituições de ensino e de diferentes países, os investigadores
concluíram que independentemente da linguagem de programação e do paradigma
(procedimental simples ou orientado a objectos) adoptado, os alunos sentem as mesmas
dificuldades. Neste estudo, McCracken et al. identificaram que a parte mais difícil da
programação, para a generalidade dos alunos, consiste em conseguirem compreender o
enunciado do problema a resolver e consequentemente desenvolverem uma solução.
Verificaram também que a maioria dos alunos não adquiriu as competências-base
desejadas, a média da pontuação obtida foi de 22.89 nos 110 pontos dos critérios gerais.
Este estudo foi repetido por Lister et al. (2004), que chegaram às mesmas conclusões:
identificou-se que os alunos apresentam frequentemente falhas de aptidão para resolver
problemas. Esta dificuldade, segundo Gomes et al. (2006) advém da falta de
conhecimentos de base de Matemática. Do estudo que realizaram com alunos de
Engenharia Informática do ensino superior, concluíram que a maioria destes alunos não
domina os conceitos básicos de Matemática, que posteriormente se reflecte na sua
capacidade de resolver problemas (ibid.). De acordo com Dann, Cooper e Pausch,
(2000), e também segundo Miliszewska e Tan (2007), esta lacuna deve-se principalmente
ao facto de os alunos não terem formação em cálculo no ensino secundário (pré-
superior). Este ponto de vista é igualmente defendido por Fonseca (2007) que vai mais
longe ao afirmar:

“As instituições de ensino partem da assunção falsa de que os aprendizes dispõem de


funções cognitivas para aprender e para reaprender, mas tal não é verdade. Por esse facto,
essas instituições têm sido um local de sucesso para alguns, mas de insucesso para
muitos.” (p. 355).

O próprio adianta ainda:

“Muitos alunos não têm o seu potencial de aprendizagem actualizado, na medida em que
carecem de pré-requisitos cognitivos básicos para obterem mais rendimento na

31
Capítulo III: Ensino da Programação

aprendizagem, considerando que raramente são colocados em situações de reflexão e de


pensamento crítico, porque são frequentemente integrados em programas inadequados e
ineficientes.” (p. 355).

Esta situação resulta no facto dos alunos não evidenciarem as qualidades perceptivas
necessárias para extrair dados da informação apresentada e conseguirem desenvolver
estratégias para resolver os problemas (ibid.).

Uma outra vertente apontada para a causa desta dificuldade refere-se à inadequada
pedagogia utilizada no ensino da programação (Spohrer e Soloway 1986; Linn e Clancy
1992; Guzdial 2004a). Linn e Clancy (1992) sugerem, das observações efectuadas, que os
alunos têm o seu conhecimento de programação organizado em torno da sintaxe da
linguagem de programação utilizada. Consequentemente, os alunos sentem dificuldades
em desenvolver algoritmos. Uma boa organização do conhecimento ajuda os alunos a
relembrar e a reutilizar a informação que aprenderam, na medida em que lhes auxilia no
reconhecimento de semelhanças entre diferentes problemas, assim como entre
diferentes partes da informação, melhorando a sua compreensão (Anderson, 2004).
Husic, Linn e Sloane (1989) e Robins et al. (2003) referem que os professores, muitas
vezes, dão demasiada ênfase à sintaxe da linguagem, pelo que os alunos organizam o seu
conhecimento, deste modo, em consequência da forma como a informação lhes é
apresentada (Linn, Sloane e Clancy, 1987; Guzdial, 2004a). A generalidade dos livros de
introdução à programação também pode contribuir para reforçar a ênfase na sintaxe da
linguagem e em exemplos individuais de aprendizagem em vez de encorajar os alunos a
reconhecer e a reutilizar padrões mais complexos (Guzdial, 2004a). Por exemplo, os
livros de introdução à linguagem C, geralmente, restringem-se a introduzir a sintaxe da
linguagem ao longo dos vários capítulos.

Apesar de alguns alunos não apresentarem dificuldades na resolução de problemas,


muitos não são capazes de codificar a solução encontrada na respectiva linguagem de
programação (Sohrer e Soloway, 1989; Winslow, 1996; Lahtinen et al., 2005). Os alunos
reclamam que não gostam de programar, uma vez, que não compreendem conceitos
básicos tais como a noção de variáveis, endereços de memória e outros (Jenkins, 2002;
Milne e Rowe, 2002; Miliszewska e Tan, 2007). Uma das causas possíveis refere que
estes conceitos são abstractos, sem uma representação equivalente na vida real (Lahtinen
et al., 2005; Miliszewska e Tan, 2007). Devido à natureza abstracta da programação,
muitos alunos sentem dificuldades em compreender a estrutura do programa e
principalmente o seu funcionamento (Cypher et al., 1993; Esteves e Mendes, 2004;

32
Capítulo III: Ensino da Programação

Lemieux, e Salois, 2006; Urquiza-Fuentes e Velázquez-Iturbide, 2009). Um aspecto


importante na aprendizagem da programação consiste em os alunos conseguirem
estabelecer uma ligação entre o que escrevem, quando estão a digitar o código, e o que o
programa realmente faz. Doutro modo, dificilmente os alunos conseguem compreender
o que se passa quando um programa não funciona correctamente. Uma das causas
apontadas refere-se ao facto dos alunos terem noções incorrectas dos conceitos-base de
programação (Kolikant e Mussai, 2008; Kaczmarczyk et al., 2010) e consequentemente
noções incorrectas acerca de um programa completo. A compreensão de um programa
é muitas vezes vista como um processo de condução de hipóteses cujo objectivo
consiste em construir uma representação mental do programa. Esta representação
mental compõe-se em distintas partes: descrever o código do programa, o significado
deste na perspectiva do domínio de aplicação e a ligação entre estes dois aspectos
(Vainio e Sajaniemi, 2007). Durante a compreensão de um programa, o programador
gera hipóteses relacionadas com as três partes da representação mental e tenta validar ou
invalidar as hipóteses colocadas. Por exemplo, gerar hipóteses “deixa ver o que este conjunto
de instruções faz, de forma a poder saber qual o seu objectivo; isto parece que efectua a pesquisa de um
número no vector” e validá-las “deixa ver se realmente é assim ”. Este processo é necessário
para a compreensão de novos programas e verificação de erros no código. Os alunos
inexperientes têm dificuldade em fazer esta representção mental tanto de partes de um
programa como de um programa completo.

Os primeiros estudos, como o trabalho de Mayer (1981), sobre os modelos mentais da


acção de escrever instruções num programa, seguido do estudo de Bayman e Mayer
(1983) no qual examinaram os equívocos dos alunos relacionados com a escrita de
instruções individuais na programação em Basic, concluíram que muitos alunos tinham
compreensões incorrectas ou equívocos, mesmo em relação às instruções mais simples.
Bonar e Soloway (1985), por seu turno, focaram-se em grupos de instruções de forma a
analisar a compreensão dos alunos sobre a programação. Deste estudo, Bonar e Soloway
concluíram que muitos dos erros resultam dos alunos não terem um conhecimento
correcto da linguagem de programação e usarem erradamente os conhecimentos que
têm de como resolver o problema passo-a-passo na linguagem natural.

Estudos efectuados mais recentemente, por Gotschi, Sanders, e Galpin, (2003), por Ma
et al., (2007) e por Kaczmarczyk et al., (2010) vêm corroborar este facto: os alunos têm
modelos mentais errados dos conceitos de base da programação, como, por exemplo,
inicializar variáveis, usar estruturas de controlo e empregar ponteiros, o que lhes

33
Capítulo III: Ensino da Programação

dificulta a tarefa de conseguir escrever programas correctamente. Não obstante, para


além de alguns alunos terem dificuldades em compreender os conceitos abstractos,
muitos há que embora os compreendam não sabem como aplicá-los correctamente de
forma a criar estruturas mais complexas (Perkins et al., 1988; Jenkins, 2002; Gomes et al.,
2008). Soloway (1986) realça que a dificuldade real dos alunos, no seu processo de
aprendizagem da programação, consiste em “putting the pieces together”, ou seja, em
perceber que elementos devem usar e como coordená-los de forma a criar um programa
correcto.

Uma das vertentes defendidas na literatura para estas dificuldades, especialmente


referente à codificação, diz respeito à linguagem de programação adoptada no ensino
(Hadjerrouit, 1998; Close, Kopec e Aman, 2000, Jekins, 2002, Gomes et al., 2008, Hanhs
e Brandt, 2009). Como Lister et al. (2004) verificaram no seu estudo, a maioria das
instituições de ensino utiliza a linguagem de programação Java. Tymann (2005), do
estudo que efectuou, acrescenta as linguagens de programação C e C++, como
linguagens de introdução da programação mais utilizadas no ensino. Dos estudos
realizados por Dingle & Zander, (2000) e por Raadt et al. (2002 e 2004) conclui-se que
os factores que mais influenciam a escolha da linguagem de programação a adoptar no
ensino na área da ciência da computação são:

 as necessidades do mercado;

 as exigências das empresas;

 a opinião dos alunos de que a linguagem leccionada seja a que vão usar na vida
profissional.

Conquanto, deve-se estar atento ao facto de que a popularidade de uma linguagem não
significa obrigatoriamente que esta seja uma boa opção para o ensino, como salientou
McGracken em 1973 no caso da linguagem FORTRAN:

“Nobody would claim that FORTRAN is ideal for anything, from teachability, to
understandability of finished programs, to extensibility. Yet it is being used by a whopping
70% of the students covered by the survey, and the consensus among the university people
who responded to the survey is that nothing is going to change much anytime soon”(p.
88).

De facto, o FORTRAN continuava a ser largamente utilizado na educação até ter


surgido o Pascal. Böszörményi (1998) faz um comentário semelhante em relação à

34
Capítulo III: Ensino da Programação

linguagem Java. Contudo, esta tem sido utilizada desde o seu aparecimento em 1995 até
aos dias de hoje. Talvez isto se deva ao facto de, como Böszörményi refere:

“(…) the approach we think today to be the best (if there is one) was not the first and
probably will not be the last. The university should not try to teach ultimate wisdom: it
should rather teach students to think about different possibilities” (p. 142).

Nos anos 70, Gries (1974) e Schneider (1978) referiam que a introdução à programação
deveria ter por objectivo a resolução de problemas e o desenvolvimento de algoritmos,
pelo que a linguagem de programação utilizada:

“(…) should be based on two critical and apparently opposing criteria: richness and
simplicity – rich in those constructs needed for introducing fundamental concepts in
computer programming but simple enough to be presented and grasped in a one semester
course.” Schneider (p. 110)

Estas alegações ainda hoje se mantêm válidas. Um aluno inexperiente começa por
aprender a sintaxe da linguagem, progredindo de forma a ser capaz de combinar essa
sintaxe para resolver problemas específicos e finalmente adquirir aptidões gerais de
resolução de problemas que podem ser transferidos para outros domínios não
relacionados com a programação (Bereiter e Ng, 1991). A ideia de ter uma sintaxe
simples está claramente relacionada com este pensamento; de colocar o foco da
aprendizagem na resolução de problemas. Jenkins (2002) salienta que as linguagens de
programação utilizadas na aprendizagem têm uma sintaxe adequada para os
profissionais, mas não para os alunos inexperientes. Tal como acontece, por exemplo,
com as linguagens C++, Java e C detentoras de um vocabulário extenso e complexo que
pouco tem a ver com a aprendizagem de algoritmos e a escrita de programas
estruturados.

Uma linguagem de programação com um pequeno número de comandos e funções


permite solucionar facilmente problemas simples, mas a solução de problemas mais
complexos pode tornar-se difícil. Como é o caso, por exemplo, da linguagem Scheme:
esta tem a vantagem de ter um único tipo de dados – listas – e uma operação – avaliação
da lista. Embora esta abstracção seja muito simples de explicar e não seja de difícil
compreensão para os alunos inexperientes, resulta, no entanto, num código que é difícil
de ler, uma vez que tem um grande número de parêntesis aninhado, assim como a
ausência de outros tipos de pontuação. Por outro lado, uma linguagem com um número
alargado de comandos e funções facilita a elaboração de problemas complexos, mas

35
Capítulo III: Ensino da Programação

torna difícil a assimilação da sintaxe. Os aprendizes têm dificuldades em reter duas ou


mais perspectivas de conceitos em simultâneo (Hofstadter, 1979). Deste modo, o facto
de os alunos terem de lidar com a semântica e sintaxe da linguagem, estruturas de dados
estáticas e dinâmicas, entre outros aspectos, dificulta a aprendizagem, como acontece
com as linguagens de programação profissionais, C, C++ e Java, possuidoras de uma
sintaxe complexa e uma extensa semântica, que se tornam difíceis de ensinar e
complicadas para os aprendizes assimilarem (Mclver e Conway, 1996).

No estudo desenvolvido por Jadud (2005), com alunos inexperientes, verificou-se que
os alunos passam grande parte do tempo imersos nos erros de sintaxe quando aprendem
a programar em Java. Este facto torna-se ainda mais evidente para os alunos com mais
dificuldades. Fenwick et al. (2009), no estudo que efectuaram, confirmaram os resultados
obtidos por Jadud (2005), tendo-se verificado que os alunos compilam o programa
poucas vezes e normalmente só o fazem no fim de terem escrito uma grande quantidade
de código. Em consequência desta forma de programar, quando os alunos compilam o
seu programa obtêm geralmente um elevado número de erros que dificilmente
conseguem corrigir. Face a este elevado número de erros, os alunos sentem-se
frustrados e desiludidos, como concluíram Rodrigo et al. (2009) no estudo efectuado
sobre o comportamento dos alunos inexperientes. Os erros de sintaxe mais frequentes
observados nestes estudos foram:

 falta de pontos-e-vírgulas;
 variáveis que não são declaradas;
 falta de chavetas, quer nas estruturas de controlo quer nos métodos;
 classes e métodos desconhecidos.

Por outro lado, Kopec et al. (2007) realizaram um estudo para observar que tipos de
erros cometem os alunos de nível intermédio, que já possuem alguns conhecimentos de
programação. Nesse estudo, os alunos aprenderam a programar com a linguagem C.
Kopec et al. verificaram que os alunos intermédios não cometem muitos erros de
sintaxe, sendo capazes de corrigir os que surgem no seu código. Contudo, os erros mais
frequentes observados nestes alunos incidiam na codificação de funções, nomeadamente
a utilização de funções com parâmetros de entrada incorrectos. Outros, no entanto,
utilizavam estruturas de repetição erradas: em vez de usarem um for, que seria o mais
correcto, para o problema em causa, usavam um ciclo while. Isto demonstrava falta de
conhecimento de como usar as estruturas de repetição correctamente. Kopec et al.

36
Capítulo III: Ensino da Programação

concluíram que os professores devem ter muito cuidado na apresentação e descrição do


enunciado do problema, uma vez que os alunos facilmente se confundem com a
linguagem usada na descrição do enunciado. Os alunos também apresentam dificuldades
para saber que estrutura melhor se adapta a uma determinada situação.

Outro aspecto importante na aprendizagem da programação é a atitude dos alunos face


aos erros, que, segundo Perkins et al. (1989), é bastante diferenciada. Existem alunos
incapazes de prosseguir quando confrontados com um erro no seu programa ou com a
falta de uma direcção clara do que fazer a seguir, alunos estes que Perkins et al. designam
por “estáticos”. Os alunos estáticos perdem toda a esperança de conseguir resolver o
problema por si só e de continuarem a progredir. Outros há que, face aos erros,
procuram soluções, experimentam e modificam o seu código, designados de Movers. E
dentro deste grupo, os Movers, existem alunos que analisam as mensagens de erro que o
sistema lhes fornece, tentam compreender a sua origem e conseguem corrigi-los e
consequentemente progridem na aprendizagem. Por outro lado, existem alunos dentro
deste grupo de Movers que fazem alterações aleatoriamente sem pensar no que estão a
fazer, deste modo não conseguindo progredir na aprendizagem.

O descontentamento gerado pelo uso das linguagens C, C++ ou Java na introdução à


programação (Feldman, 1992; Roberts, 1993; Hadjerrouit, 1998; Reges, 2006) motivou a
mudança, por parte de algumas universidades, para linguagens de programação usadas
no passado, como o Pascal, ou a ponderar a possibilidade de adoptar linguagens como
Python (Becker, 2002). Este descontentamento foi também factor impulsionador para o
desenvolvimento de novas linguagens de programação mais simples, com o intuito de
ajudar os alunos inexperientes a aprender a programar e a facilitar a migração posterior
para linguagens com características mais complexas (Guzdial, 2004b; Hundhausen et al.,
2010). Outra abordagem foi o desenvolvimento de ambientes que não alteram a
linguagem de programação usada, mas “escondem” partes da linguagem (Guzdial,
2004b). Na secção seguinte expõem-se algumas destas linguagens e alguns destes
ambientes.

Outros autores, como por exemplo Dann et al. (2000), Reis e Cartwright (2004),
Hundhausen, Farley e Brown (2009), referem que uma das causas que contribui para
este panorama de dificuldades, principalmente no que se refere à codificação, é a
utilização de ambientes de programação inadequados para alunos inexperientes. Os
ambientes de desenvolvimento integrados, comummente designados de Integrated
Development Environment (IDE), são ferramentas que permitem ao programador escrever,

37
Capítulo III: Ensino da Programação

editar, executar e testar programas. Os IDE são geralmente desenvolvidos tendo em


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

Figura 3.1: Ambiente de programação Eclipse IDE

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

38
Capítulo III: Ensino da Programação

a investigadora também constatou a mesma situação, uma vez que é permitido que
alunos de áreas muito diferenciadas frequentem o ensino, e como tal com
conhecimentos de base muito diversificados. Assim, é possível encontrar alunos que
vêm da área tecnológica já com alguns conhecimentos de programação e outros que
apenas possuem conhecimentos informáticos na óptica do utilizador. Um aspecto
fundamental no processo de aprendizagem é a assimilação de novos conceitos nas
estruturas cognitivas existentes (Vygotsky, 1979; Bruner, 1990). Por conseguinte, esta
discrepância nos conhecimentos de base dos alunos torna o processo mais complexo
para os pedagogos do ensino tradicional, devido às aulas serem frequentadas por alunos
de diferentes níveis de saber e capacidades.

Nesta secção reviu-se os factores principais que têm vindo a ser apontados na literatura
científica como causas que condicionam a aprendizagem da programação e a torna num
processo difícil e exigente para a maioria dos alunos. A resposta a cada uma destas
dificuldades resultou num conjunto de soluções que se traduziram, na sua maioria, no
desenvolvimento de ambientes de programação que tentam minimizar estas
dificuldades. O que não é de estranhar uma vez que não existe uma resposta correcta
que abranja estas dificuldades na sua totalidade. Na secção seguinte, sumariza-se as
diferentes soluções propostas para o ensino da programação de forma ajudar a colmatar
estas dificuldades.

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


programação

Na literatura científica encontram-se muitos artigos que relatam experiências ou


abordagem utilizadas no desenvolvimento de ferramentas cuja intenção é melhorar a
eficácia do ensino e da aprendizagem introdutória da programação de computadores.
Contudo, encontram-se poucos artigos relacionados com pedagogias para o ensino da
programação. Algumas das metodologias, consistem num conjunto de linhas
orientadoras que alertam os professores para determinadas questões de forma a
melhoraram a aprendizagem dos alunos. Por exemplo Hanks e Brandt (2009) do estudo
que desenvolveram, sugerem que os professores devem:

 Tentar que os alunos pensem no problema antes de começarem a codificá-lo.


Devem encorajar os alunos a perguntarem-se “Por que ordem devo fazer isto?”

39
Capítulo III: Ensino da Programação

 Ensinar os alunos a compilar e a testar os seus programas frequentemente. Se o


professor programar em frente aos alunos deve seguir este exemplo para que os
alunos se habituem a fazê-lo também. Assim, os alunos vão verificando e
corrigindo os erros de sintaxe à medida que surgem, sendo mais fácil para os
alunos aperceberem-se das falhas que cometem.
 Ensinar os alunos a usar o debugger, uma vez que muitos não o sabem utilizar.
Fazer o debugging a um programa é uma forma de os alunos compreenderem o
que o debug faz e de corrigirem os erros de execução. Esta aproximação também
á corroborada por outros autores como Murphy et al. (2008).
 Salientar as partes da linguagem de programação em que os alunos se confundem
mais.
 Incentivar os alunos a usarem técnicas de teste. A realização de testes é uma
forma disciplinada de desenvolvimento, que implica a escrita de blocos
autónomos de teste antes da implementação da correspondente unidade
funcional. Esta metodologia de testes tem vindo a ser usada na indústria no
desenvolvimento de software (Larman e Basili, 2003). Recentemente foi aplicada
no ensino introdutório da programação com algum sucesso (Wellington et al.,
2007; Desai et al. , 2009), como forma de facilitar a aprendizagem da
programação, na medida em que obriga os alunos a testarem cada uma das 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

40
Capítulo III: Ensino da Programação

subprograma independente. Como consequência da utilização desta metodologia, os


sub-programas são menos complexos, resultando em programas melhor estruturados.
Por outro lado os sub-programas são mais fáceis de testar e de corrigir os possíveis
erros. Esta abordagem segue a abordagem top-down para resolver problemas, que
consiste em dividir o problema inicial em sub-problemas cada vez mais pequenos, de
modo que o problema original se torne mais compreensível e de mais fácil interpretação.

3.3.2. Abordagem gramatical

A abordagem gramatical envolve a exposição passo-a-passo da estrutura gramatical da


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

3.3.3. Abordagem em espiral

A ideia-base da abordagem em espiral consiste em ensinar a linguagem de programação


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

41
Capítulo III: Ensino da Programação

3.3.4. Protocolo “pensar em voz alta”

Arshad (2009) sugere outra abordagem para o ensino introdutório da programação,


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

3.3.5. Programação de jogos

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

42
Capítulo III: Ensino da Programação

conceitos-base de programação utilizando uma linguagem menos complexa que o C ou


Java.

3.3.6. Programar do concreto para o abstracto

Esta metodologia baseia-se no princípio de que os jovens aprendem mais facilmente se


os dados a estudar forem tangíveis e directamente acessíveis aos seus sentidos visuais,
auditivos, tácteis e cinestésicos (Dann e Cooper, 2009). Com a experiência, desenvolvem
a capacidade de compreender dados abstractos, manipular símbolos, efectuar raciocínios
lógicos e, consequentemente, a generalizar. No entanto, a maioria das pessoas necessita,
ao longo da vida, de exemplos concretos para compreender ideias novas (ibid.). Segundo
estes autores, no ensino da programação deve-se começar do concreto para a
abstracção, como acontece no ambiente de programação Alice. Neste ambiente, os
alunos pegam em objectos concretos e familiares, como árvores, casas, carros e outros, e
a partir deles criam pequenos filmes de animação ou jogos. Assim, o aprendiz 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.

43
Capítulo III: Ensino da Programação

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

A utilização de padrões no ensino da programação torna-se mais eficiente se for


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

3.3.8. Programação aos pares

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

44
Capítulo III: Ensino da Programação

disponível para discutir com o condutor as opções a tomar em cada momento.


Enquanto par, os parceiros trocam de papéis regularmente, muitas vezes com base em
situações em que um elemento tem uma boa ideia para implementar uma solução. Esta
técnica tem sido utilizada em diversos projectos de grande dimensão por se considerar
que tem várias vantagens como, por exemplo, aumentar a produtividade e a satisfação,
enquanto melhora a qualidade do software desenvolvido (Beck, 1999; Hulkko e
Abrahamsson, 2005).

De um ponto de vista educativo, a programação aos pares pode ser vista como uma
forma de aprendizagem colaborativa. Esta metodologia de aprendizagem tem vindo a
ser reportada como uma técnica que ajuda os alunos a aprender a programar, resultando
numa melhoria do sucesso escolar (McDowell et al., 2006). Diversos autores referem que
o trabalho colaborativo em geral, e a programação em pares em particular, são técnicas
pedagógicas eficazes para a aprendizagem da programação (Bravo et al., 2004; McDowell
et al., 2006; Hedin et al., 2008). Contudo, no estudo desenvolvido por Hans (2007), este
concluiu que os tipos de problemas encontrados nos alunos que aprendem a programar
aos pares são idênticos aos encontrados nos alunos que aprendem sozinhos. No estudo
por si realizado, Hans verificou também, contudo, que os alunos que trabalham aos
pares são capazes de resolver mais problemas por si, principalmente erros de sintaxe, o
que pode aumentar a confiança e auto-estima do aluno.

Na adopção desta metodologia têm surgido estudos sugerindo que a personalidade dos
parceiros é um dos factores críticos na sua implementação (Kichuk e Wiesner, 1997;
Karn e Cowling, 2006). Uma vez que a programação aos pares é uma prática que
envolve duas pessoas que trabalham juntas para alcançar um objectivo comum, o êxito
desta prática é largamente determinado pelo grau de eficiência da forma pela qual os
pares trabalham em equipa, independentemente das suas capacidades e conhecimentos.
Neste contexto da eficácia da equipa, a personalidade tem vindo a ser referida como um
factor crítico de sucesso. Contudo, no estudo desenvolvido por Salleh et al. (2009), estes
concluíram que diferentes tipos de personalidade não afectam significativamente o
desempenho dos alunos na programação aos pares, tendo-se verificado que esta
metodologia aumenta a autoconfiança e a satisfação dos alunos na aprendizagem.

45
Capítulo III: Ensino da Programação

3.3.9. Programação por exemplos

A programação por exemplos é uma abordagem semelhante à programação por


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

3.3.10. Abordagem “bricolage”

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

46
Capítulo III: Ensino da Programação

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

Na literatura científica encontram-se algumas ferramentas que foram desenvolvidas com


o propósito de ajudar os alunos a colmatar as suas dificuldades, que se destacam na
secção seguinte. Estas ferramentas são usadas conjuntamente com algumas das
abordagens descritas, nomeadamente a programação aos pares, os padrões de
programação, entre outras.

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

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

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

47
Capítulo III: Ensino da Programação

ordenamento, nos quais os alunos são meros espectadores. Outras ferramentas,


normalmente mais genéricas, permitem ao aluno introduzir e simular os seus próprios
algoritmos ou programas, possibilitando-lhes assim uma participação muito mais activa
no seu próprio processo de aprendizagem.

Os tipos de ferramentas mais comuns são:

 ferramentas de animação – de algoritmos e de programas;

 os mundos programáveis;

 os ambientes de desenvolvimento controlado.

3.4.1. Ferramentas de animação

3.4.1.1. Ferramentas de animação de algoritmos

As ferramentas de animação de algoritmos, também designadas por ferramentas de


visualização, na sua generalidade, são representações gráficas das sucessivas operações
computacionais que um determinado algoritmo desencadeia. Estas ferramentas foram,
na sua maioria, desenvolvidas com o propósito de ajudar os alunos a compreenderem
como funcionam os algoritmos, ou ajudar a perceber como se processam as operações
nos tipos de dados abstractos, como por exemplo nas listas. Assim como auxiliar os
professores, durante as aulas, a ilustrar como se processam as operações num
determinado algoritmo (Brown e Najork, 1996).

As primeiras ferramentas de animação surgiram por volta dos anos 80 com o Brown
ALgorithm Simulator and Animator (BALSA). O BALSA é um sistema interactivo de
animação de algoritmos que permite visualizar diferentes pontos de vista de um
algoritmo e da estrutura de dados a ele associada (Brown, 1984a). Este sistema permite
aos alunos invocar o código existente e sobre o qual o BALSA gera uma animação. Os
alunos ao observarem estas animações compreendem melhor o funcionamento dos
algoritmos (Brow, 1984b). Nesta linha de desenvolvimento surgiu o Transition-based
ANimation GeneratiOn (TANGO) em 1989, reconhecido pelo facto de ter introduzido
uma nova técnica de animação chamada Path Transition. Esta técnica baseia-se na noção
de que uma animação é criada através de um conjunto de alterações feitas sobre uma
imagem (Stasko, 1989).

48
Capítulo III: Ensino da Programação

Desde então, muitos outros sistemas de visualização foram desenvolvidos. Os mais


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

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

Noutras aplicações um pouco mais evoluídas, o utilizador pode intervir no


funcionamento do algoritmo, através da inserção de valores, e até escolher outros
algoritmos dentro do mesmo estilo de animação. Como acontece, por exemplo, nos
sistemas CAT (Brown e Najork, 1996), IDSV (Jarc e Feldman, 1998), PILOT
(Bridgeman et al., 2000), VIP (Virtanen et al. 2005) e JHAVÉ (Naps e Rößling, 2007).

Dentro deste tipo de ferramentas existem alguns sistemas que permitem ao utilizador
criar as suas animações, limitadas a um tipo de estrutura de dados. É o caso do
MatrixPro (Karavirta et al., 2004), que permite aos professores criarem animações para
um algoritmo, desde que a sua estrutura de dados seja um vector, uma lista ligada, uma
árvore ou um grafo. Para os alunos, a ferramenta oferece a possibilidade de visualizar a
animação e um conjunto de exercícios onde os alunos simulam o funcionamento do
algoritmo. Os alunos, ao visualizar uma animação no MatrixPro podem avançar,

49
Capítulo III: Ensino da Programação

retroceder ou ir para um passo específico da animação, indicar a velocidade desta, e


inserir pontos de paragem (Figura 3.4).

Figura 3.4: Exemplo do sistema MatrixPro.

Dentro deste tipo de ferramentas, destaque-se o sistema SICAS (Gomes e Mendes,


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

50
Capítulo III: Ensino da Programação

colaborativas à distância. Esta ferramenta resulta da integração do SICAS com a


ferramenta colaborativa PlantEdit (Redondo, Bravo, Ortega, Verdejo, 2002).

Figura 3.5: Ambiente de trabalho do SICAS.

3.4.1.2. Ferramentas de animação de programas

Ao contrário das ferramentas referidas no ponto anterior, existem outras que permitem
gerar animações a partir do código-fonte. O número de aplicações existente deste tipo é
consideravelmente menor do que as ferramentas de animação de algoritmos, uma vez
que o esforço para desenvolver uma simples ferramenta de animação de programas é
muito maior dado ser necessário fazer o parse (análise gramatical ou lógica da linguagem
de programação).

Estas animações, na generalidade, mostram as instruções em execução e respectivas


consequências, por exemplo, no valor das variáveis. Dentro deste tipo de sistemas
existem aqueles cujas animações são efectuadas sobre um conjunto de programas pré-
definidos como é o caso do Webworks (Boroni et al., 1999), (Figura 3.6).

51
Capítulo III: Ensino da Programação

Figura 3.6: Ambiente do animador de programas da Webworks.

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

3.4.1.2.1. Jeliot

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

52
Capítulo III: Ensino da Programação

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

Figura 3.7: Ambiente de trabalho do Jeliot 3.

3.4.1.3. Discussão

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

53
Capítulo III: Ensino da Programação

na animação. Estes resultados influenciaram o desenvolvimento de um conjunto de


directivas, descritos por Röbling e Naps (2002), indicando o que estas ferramentas
devem conter para serem eficazes no ensino e aprendizagem da programação, como por
exemplo:

 permitir ao aluno inserir dados, possibilitando assim que este compreenda melhor
o funcionamento do algoritmo;
 permitir controlar o desenrolar da animação, ou seja, a ferramenta deve permitir
que o aluno volte atrás, ande para a frente, pare ou controle a velocidade da
animação – assim o aluno tem uma percepção melhor do seu funcionamento;
 possibilitar ao aluno e ao professor irem directamente para um ponto especifico
da animação – este é um aspecto importante, principalmente para o professor
poder fazer chamadas de atenção para um aspecto particular do algoritmo.

Estas recomendações foram seguidas no desenvolvimento de alguns sistemas de


animação como, por exemplo, no SICAS. Estudos feitos com o ambiente SICAS
concluem que os alunos que usaram este ambiente desenvolveram melhores algoritmos
do que os restantes colegas que não o usaram (Rebelo, Marcelino e Mendes, 2005).
Hundhausen et al.(2009), também corroboram este resultado; no estudo que realizaram
com ambiente ALVIS: concluíram que este reduz a resistência inicial dos alunos em
aprender a programar e encoraja-os na exploração do processo de programar sendo esta
mais centrada na execução do código. Contudo, estes autores mencionam que são
necessários mais estudos para verificar se este tipo de ambientes facilita realmente a
migração para outros ambientes profissionais.

Algumas destas ferramentas têm vindo a ser utilizadas em situações de aprendizagem


colaborativa, de modo a melhorar a aprendizagem da programação, em particular a
programação aos pares (Williams et al. 2000; Hundhausen, 2002; Nagappan et al. 2003;
Simon et al. 2004; McDowell et al. 2006; Hundhausen e Brown, 2008). A aprendizagem
colaborativa baseia-se na argumentação e no conhecimento partilhado, assim como na
coordenação de trabalhos em grupo (Soller et al., 2005). Alguns autores defendem a
junção dos benefícios da visualização e colaboração como forma de aumentar o nível de
empenhamento dos alunos na aprendizagem (Hübscher-Younger e Narayanan, 2003;
Nguyen, Huang e Hawryszkiewycz, 2004; Myller et al., 2007; Balakrishnan, Fussell e
Kiesler, 2008; Papka, 2009).

54
Capítulo III: Ensino da Programação

No estudo que Myller et al. (2007) fizeram sobre a utilização da visualização e


aprendizagem colaborativa não foram observadas grandes diferenças nos resultados
obtidos no grupo de alunos que usufruíram da visualização e colaboração em relação
aos que beneficiaram apenas da visualização. Contudo, numa réplica feita deste estudo
por Laakso et al. (2009) obtiveram-se diferenças significativas usando a visualização num
contexto colaborativo. Resultados idênticos foram obtidos por Hübscher-Younger e
Narayanan (2003): os alunos que beneficiaram da visualização juntamente com a
colaboração obtiveram melhores resultados. Assim também Hundhausen e Brown
(2008) salientam que a utilização da visualização colaborativa aumenta o nível de
envolvimento dos alunos no processo de aprendizagem.

Myller et al. (2009) indicam que, para a visualização e a colaboração serem uma
ferramenta eficaz, esta deve permitir aos alunos interagirem e construírem a sua
animação, uma vez que os alunos ao observarem passivamente a visualização diminuem
o nível de colaboração. Estes autores sugerem ainda, que uma ferramenta deve suportar
diferentes níveis de envolvimento dos alunos, como por exemplo, a possibilidade dos
alunos alterarem os valores de entrada durante a execução da animação ou o uso da
animação para discutir os resultados obtidos. Estas argumentações vêm ao encontro do
que Röbling e Naps (2002) alegam, como foi referido anteriormente. Como salienta
Kelleher (2006):

“It can be easier and more fun to learn with a group of people “.

Apesar da abundância de ferramentas de animação e de estas poderem ajudar os alunos


na aprendizagem de alguns aspectos da programação, a sua adopção generalizada pela
comunidade académica ainda não ocorreu (Röbling e Naps, 2002; Kaczmarczyk, et al.,
2010). Uma das razões apontadas para esta resistência à sua utilização, deve-se ao facto
de não existirem estudos que comprovem a sua real eficácia na aprendizagem
(Hundhlausen et al., 2002; Hundhausen et al. 2009). Contudo, a animação visual de um
programa pode ser útil pelo menos a três níveis: ajuda a compreender a semântica
operacional da linguagem fonte; é um auxiliar à depuração de erros (debugger de alto
nível); facilita o entendimento dos algoritmos (Esteves e Mendes, 2004). No entanto, as
ferramentas de animação não devem ser usadas isoladamente, mas como parte
integrante da experiência de aprendizagem. O valor real de uma animação não reside na
sua simples visualização, mas na capacidade de permitir que o aluno intervenha,
construa, explore, modifique, experimente e teste as suas teorias e soluções.

55
Capítulo III: Ensino da Programação

3.4.2. Mundos programáveis

Os mundos programáveis são uma técnica utilizada para facilitar a aprendizagem da


programação inspirada na linguagem Logo (Papert, 1980). Estes ambientes, na sua
generalidade, eliminam os detalhes que não são importantes para os conceitos que estão
a ser ensinados. Pretendem imergir os alunos no mundo de um agente – uma tartaruga
ou um robô – para que estes se sintam os actores principais que estão a conduzi-lo,
facilitando deste modo a construção dos modelos mentais dos conceitos que estão a
aprender (Buck e Stucki, 2001). Por exemplo no sistema “Karel the Robot”,
mencionado mais adiante, os detalhes eliminados foram as variáveis, tendo esta noção
abstracta sido substituída pelo estado que o robô Karel ocupa no mundo. Sendo este
estado visível e manipulado pelo programa do Karel, isto torna o estado mais real para
os alunos do que um conjunto de valores alfanuméricos armazenados na memória.

Um exemplo largamente utilizado deste tipo de mundos é o “Karel the Robot”, já


mencionado nos parágrafos anteriores (Pattis, 1981). Karel é um robô que habita num
mundo simples de grelhas com ruas e avenidas perpendiculares, no qual este se
movimenta (Figura 3.8). Assim, o Karel desloca-se pelo mundo, vira e detecta as paredes
que se encontram a meio bloco de distância de si, e apita se estiver no mesmo bloco. Os
alunos desenvolvem programas que movimentam o Karel pelo mundo e fazem-no
executar pequenas tarefas. O simulador do Karel permite aos alunos observarem o
progresso dos seus programas passo a passo. O Karel tem inspirado o desenvolvimento
de outros mundos programáveis, como por exemplo: Josef the robot (Tomek, 1983),
Martino, (Olimpo et al., 1985), PMS (Tomek et al., 1985), Robot Brothers (Olimpo,
1988), Marta (Calabrese, 1989), Pascal Genie (Miller e Chandhok, 1989), Turingal
(Brusilovsky, 1991), JKarelRobot (Buck e Stucki, 2001), Jeroo (Sanders e Dorn, 2003).

Estes mundos, na sua maioria, incluem um simulador que permite aos alunos
observarem a execução dos seus programas. Através do uso destes mundos, os alunos
rapidamente se familiarizam com várias estruturas de controlo, como, por exemplo, o if
e as estruturas de repetição. Assim, pretende-se que quando os alunos passarem para
linguagens de programação de uso geral e mais complexas tenham uma preparação que
lhes facilite essa mudança, ao contrário do que acontece com a generalidade dos alunos
quando iniciam o estudo da programação (Kelleher e Pausch, 2005).

56
Capítulo III: Ensino da Programação

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

3.4.2.1. Discussão

Os resultados da utilização do Karel mostram que neste ambiente os alunos são


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

Segundo Buck e Stucki (2001) o Karel apresenta algumas limitações, tais como, por
exemplo, a nível da compreensão o Karel não ajuda o aluno a prever qual o
comportamento do robô ao executar uma determinada instrução. Por outro lado, alguns

57
Capítulo III: Ensino da Programação

alunos sentem dificuldades em fazer a ligação entre o comportamento do Karel e o


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

3.4.3. Ambientes de desenvolvimento controlado

As ferramentas de desenvolvimento controlado oferecem geralmente um conjunto


limitado de características das ferramentas profissionais. Em alguns casos, o ambiente é
modificado de forma a esconder as características mais avançadas, como acontece por
exemplo com o GILD (Storey et al., 2003) e Net-Beans BlueJ Edition (Sun
Microsystems, 2009).

Outras ferramentas foram criadas especificamente para ajudar a aprendizagem dos


conceitos de programação, como por exemplo, Dr Java (Allen, Cartwright e Stoler,
2002), JPie (Goldman, 2004), CodeLab (Craft, 2004), jGRASP (Jain et al., 2006),
SimplifIDE (Vogts, Calitz e Greyling, 2008) e o BlueJ, do qual se faz uma breve
descrição.

3.4.3.1. BlueJ

O BlueJ (Köling, Quig, Patterson e Rosenberg, 2003) permite o desenvolvimento de


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

58
Capítulo III: Ensino da Programação

Figura 3.9 : Ambiente de trabalho do BlueJ.

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

3.4.3.2. Alice

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

59
Capítulo III: Ensino da Programação

programação orientada a objectos a alunos inexperientes. O Alice permite que os alunos


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

Figura 3.10: O ambiente de trabalho do Alice.

60
Capítulo III: Ensino da Programação

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

3.4.3.3. Discussão

A questão que se coloca com a utilização dos ambientes de programação controlados


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

61
Capítulo III: Ensino da Programação

comportamento a programar, ou seja, menos erros de compilação e menos vezes


recorreram à ajuda do sistema. Contudo, os resultados indicam que uma melhoria no
comportamento a programar não implica um aumento significativo no resultado
académico final. Este resultado realça o facto de que nem todos os alunos beneficiam da
ferramenta de igual modo, pelo que os professores precisam de estar atentos aos alunos
de alto risco que necessitam de mais assistência de forma a melhorar o seu desempenho.
Resultado semelhante foi obtido por BenneDsen e Schulte (2010), que realizaram um
estudo no qual analisaram o efeito que tinha no ensino introdutório da programação em
Java a utilização do BlueJ Visual Debugger. Neste estudo concluíram que os alunos não
beneficiaram grandemente deste ambiente em relação ao grupo de controlo que não o
utilizou.

Em relação ao ambiente Alice, que usa outra abordagem, estudos efectuados com
alunos com idades inferiores a 12 anos apresentaram resultados positivos na sua
utilização (Kellehar et al., 2007; Cooper, Dann e Harrison, 2010; Rodger et al., 2010). Por
exemplo, no estudo realizado por Kellehar et al. (2007) obtiveram resultados positivos e
os investigadores concluíram que a utilização deste ambiente motiva os alunos para a
aprendizagem da programação. Outros autores, como Johngard e McDonald (2008),
notaram que alguns alunos passam uma boa parte do tempo centrados na criação das
animações em vez de se focarem nos fundamentos da programação. Um estudo
efectuado na Universidade Tufts (Powers et al., 2007) usou o Alice no primeiro semestre
com alunos do ensino superior, seguido de uma linguagem de alto nível (C++). No
semestre seguinte, intercalaram a utilização do Alice com C++, em que cada conceito
foi introduzido no Alice e transferido para o C++. Powers et al. observaram dificuldades
nos alunos em transitarem para uma linguagem de alto nível, C++. Estas dificuldades
centraram-se principalmente a nível da sintaxe: os alunos sentiram-se frustrados quando
os seus programas não executavam devido aos erros de compilação existentes, facto que
é impossível acontecer quando se programa no Alice. Um estudo realizado
recentemente por Garlick e Cankaya (2010) sobre a utilização do Alice com alunos do
ensino superior, no qual participaram 150 alunos ao longo de dois semestres, obtiveram
resultados negativos, principalmente no que se refere à assimilação de 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

62
Capítulo III: Ensino da Programação

motivaram os autores do Alice a considerar alterar o Alice de forma a permitir os alunos


do ensino superior desenvolvessem programas em Java neste ambiente (Dann e Cooper,
2009). No entanto, a nova versão do Alice encontra-se actualmente numa versão beta e
em testes, pelo que ainda não são conhecidos resultados destas alterações.

Em suma, a utilização de ambientes de programação controlados pode ajudar alguns


alunos no seu processo de aprendizagem. Contudo, existem aprendizes que necessitam
de outro tipo de assistência que estes ambientes não conseguem dar.

3.5. A programação e os mundos virtuais

Todas as dificuldades relatadas nas secções anteriores, juntamente com o facto de os


alunos considerarem a sua primeira experiência com a programação de computadores
nada agradável (Kelleher, 2006), faz com que estes se sintam desmotivados e sem
interesse em aprender a programar. É necessário introduzir uma mudança inovadora
para alterar o estado actual de desinteresse que a generalidade dos alunos demonstra ter
pela programação e consequentemente pelos cursos de ciências de computação. Como
advoga Violino (2009),

“The loss of attraction to [computing] comes from our being unable to communicate the
magic and beauty of the field.”

Conforme já foi mencionado, os jovens aprendem mais facilmente se os dados a estudar


forem tangíveis e directamente acessíveis aos seus sentidos visuais, auditivos, tácteis e
cinestésicos (Dann e Cooper, 2009). Com a experiência, eles desenvolvem a capacidade
de compreender dados abstractos, manipular símbolos, efectuar raciocínios lógicos e
consequentemente a generalizar. No entanto, a maioria das pessoas necessita, ao longo
da vida, de exemplos concretos para compreender as novas ideias (ibid.). Segundo os
autores referidos, no ensino da programação deve-se começar do concreto para a
abstracção, como acontece com o Alice. Papert (1980) refere que:

“A programming language is like a natural, human language in that it favours certain


metaphors, images, and ways of thinking.”

Criar uma representação concreta (modelo externo) de algo abstracto (modelo mental)
ajuda na compreensão e facilita a resolução de problemas. Por exemplo, Noyes e
Garland (2003) no estudo que fizeram sobre o jogo lógico “Torres de Hanói”,
verificaram que o uso de um exemplo externo ajudou os aprendizes em certos aspectos

63
Capítulo III: Ensino da Programação

da resolução do problema. Williams e Noyes (2007) mencionam também que uma


representação baseada no computador desempenha um papel vital no desenvolvimento
das capacidades necessárias para resolver problemas, principalmente na fase inicial da
aprendizagem, uma vez que as representações visuais, espaciais e físicas são mais fáceis
de reter e manipular. Os alunos, ao obterem uma visualização imediata dos resultados de
uma acção, verificam mais facilmente se a sua ideia está certa ou errada. Se estiver errada
terão de a corrigir, repensar a solução e, consequentemente, este repensar e reanalisar da
situação vai estimular o seu pensamento crítico (Shneiderman, 1983; Kiili, 2005; Chan e
Black, 2006).

No entanto, alguns estudos concluem que a simples visualização não é suficiente para se
obter sucesso na aprendizagem (Naps et al., 2002; Hundhausen & Brown, 2008,
Urquiza-Fuentes e Velázquez-Iturbide, 2009), uma vez que os alunos podem olhar para
uma visualização dinâmica sem realmente compreender o seu sentido. A visualização
torna-se mais eficiente se envolver activamente o aprendiz, ao contrário da simples
observação passiva (Pierson e Rodger, 1998; Naps et al. 2002; Hundhausen e Brown,
2005, Schweitzer e Brown, 2009). Por exemplo, na visualização de um algoritmo, os
alunos beneficiam muito mais do ambiente se poderem construir e representar as suas
próprias visualizações, não só porque este tipo de exercícios aumenta a sua motivação e
interesse, mas também por que são um estímulo para gerar discussões significativas
sobre o assunto (Hundhausen e Brown, 2007, Urquiza-Fuentes e Velázquez-Iturbide,
2009).

Face ao exposto, e seguindo a linha orientadora que levou ao desenvolvimento do Alice,


passar do concreto para o abstracto (Dann, Cooper, 2009), influenciou a investigadora a
utilizar os mundos virtuais 3D, como plataforma para o ensino e aprendizagem da
programação. Nestes mundos, os alunos aprendem a programar num contexto visual
3D, colaborando uns com os outros e inseridos numa comunidade internacional, como
acontece por exemplo no mundo virtual Second Life., onde os alunos constroem
objectos 3D e desenvolvem programas dentro do mundo para gerar o comportamento
funcional desses objectos. Uma das vantagens de utilizar um mundo virtual 3D para o
ensino da programação é a possibilidade que os aprendizes têm de ver um objecto ou
colocá-lo sob múltiplas perspectivas, os quais podem gerar uma melhor compreensão
dos conceitos (Bricken e Byrne, 1994; Dickey, 2005; Champion, e Sekiguchi, 2005).

Embora o conceito de mundos virtuais multi-utilizador não ser novo, a crescente


popularidade de aplicações de mundos virtuais tem crescido exponencialmente nos

64
Capítulo III: Ensino da Programação

últimos 5 anos, como é constatável com os cerca de 180 mundos virtuais actualmente
disponíveis ou em desenvolvimento (de Freitas, 2008). Contudo, o aparecimento dos
mundos virtuais como ferramenta de ensino e aprendizagem é relativamente recente.
Nos últimos anos têm surgido alguns estudos, assim como uma variedade de iniciativas
educacionais na introdução dos mundos virtuais como complemento das actividades das
aulas tradicionais, e também como meio usado na educação à distância (Barab, et al.,
2000; Corbit e DeVarco, 2000; Bailey e Moar, 2002; Barab, Hay, Barnett e Squire, 2001;
Dickey, 2003, 2004, 2005, Jong, van der Meijden e von Berg, 2005; Lim, Nonis e
Hedberg, 2006; Peterson 2006; Robbins, 2007; de Freitas, 2008; Warburton, 2009). As
conclusões gerais destes estudos indicam que os alunos se sentem motivados com a
interacção gráfica que estes mundos apresentam, uma vez que são visualmente
atractivos, animados e interactivos. Jong et al. (2005) referem que:

“3D virtual world can support an effective, active, and more playful learning process” (p.
33).

Vários autores (Dede, 1995; Antonacci e Modaress, 2005; Hew e Cheung, 2010)
argumentam que os mundos virtuais têm a vantagem de permitir aos alunos
experimentar sem as repercussões do mundo real e oferecem oportunidades de aprender
fazendo. Esta asserção é compartilhada por Dickey (2005), ao alegar que os mundos
virtuais permitem aos alunos aprender através da interacção com objectos virtuais que,
dependendo do conteúdo, podem conduzir a uma melhor compreensão dos conceitos.
Esta compreensão resulta dos aprendizes interagirem com os objectos 3D do mundo,
permitindo-lhes, para além de aprender fazendo, observar os resultados das suas acções,
testar as suas hipóteses e reflectir sobre a sua própria compreensão (Winn, 2002; Chee,
2007). A vantagem mais aclamada dos mundos virtuais é o envolvimento, estimulando
os alunos a vivenciarem exaustivamente uma dada experiência, podendo ajudar a
colmatar o fosso entre a aprendizagem experimental e a representação da informação
(Winn, 2002; Sourin et al., 2006). Segundo Austin e Boulder (2007):

“Virtual worlds offer an opportunity for people to interact in a way that conveys a sense of
presence lacking in other media. These spaces can be huge, in terms of the number of
people that use them, and they are growing in popularity because they combine many of the
elements that make Web 2.0 really exciting: social networking; the ability to share rich
media seamlessly; the ability to connect with friends; a feeling of presence; and a connection
to the community.” (p.18).

65
Capítulo III: Ensino da Programação

Barab et al. (2000) usaram os mundos virtuais como suporte para facilitar a compreensão
dos conceitos de astronomia pelos alunos, baseado numa aprendizagem construtivista.
Barab et al. (2000) e Barab, Hay, Barnett e Squire (2001) concluíram que os mundos
virtuais podem ser utilizados de forma eficaz como uma ferramenta para facilitar a
compreensão dos fenómenos astronómicos. Bailey e Moar (2002) constataram, também,
que o uso dos mundos virtuais fomenta a colaboração e a comunicação entre os alunos.
Dickey (2003) corrobora estes resultados ao mencionar que a utilização dos mundos
virtuais 3D, tal como o Active Worlds, suporta uma aprendizagem construtivista por
permitir uma comunicação em tempo-real, juntamente com um ambiente visual e
recursos de apoio à colaboração. O mesmo autor refere ainda que o uso dos mundos
virtuais 3D ajuda os alunos a desenvolver as suas competências num ambiente
colaborativo tridimensional (Dickey, 2004). Antonacci e Modaress (2005) acrescentam
que os mundos virtuais ajudam os aprendizes a desenvolver as capacidades de
interpretação, análise, avaliação e resolução de problemas.

No estudo realizado por Sourin et al. (2006), observou-se que os alunos quando
trabalhavam no seu projecto dentro do mundo virtual, que consistia em desenvolver
objectos usando ferramentas gráficas, estes gradualmente e sem fazerem um esforço
extra eram imersos em muitos conceitos de computação gráfica. O mesmo autor refere,
ainda, que este facto fez com que os alunos aprendessem melhor os conceitos de
computação gráfica e obtivessem, em média, uma melhoria nos resultados do exame em
14%. Contudo, alguns estudos apresentam resultados contraditórios, referindo que o
uso dos mundos virtuais não melhora a aprendizagem dos alunos, uma vez que estes se
distraem facilmente durante as actividades online (Dalgarno, 2002; Lim et al., 2006,
Omale et al., 2009). Por exemplo, Lime et al. (2006) constataram que os alunos estavam
tão preocupados com a exploração do espaço 3D que não se conseguiam concentrar no
desenvolvimento das suas actividades.

Apesar de durante a escrita desta tese terem surgido alguns estudos relacionados com a
utilização dos mundos virtuais na educação, (de Freitas e Neumann, 2009; Warburton e
Perez-Garcia, 2009; Veletsianos, 2009; de Freitas et al., 2010; Hew e Cheung, 2010)
vários autores continuam a salientar a falta de estudos com linhas orientadoras de como
os usar no ensino (de Freitas e Veletsianos, 2010; Hew e Cheung, 2010). Como refere
Warburton (2009):

“Despite the high level of activity in the area (the Second Life Educators list has a
membership figure of over 5000), clear guidelines for practice remain difficult to find.”

66
Capítulo III: Ensino da Programação

Face aos problemas relatados que envolvem o ensino e aprendizagem da programação,


às diferentes soluções propostas e atendendo ao facto de os alunos continuarem a sentir
dificuldades na aprendizagem da programação, a autora sugere a utilização dos mundos
virtuais de modo a criar um contexto de aprendizagem no qual os alunos possam
aprender partindo do concreto para o abstracto. Pretende-se com a utilização destes
mundos criar um ambiente onde os alunos possam “brincar” com as ideias, dar largas à
sua imaginação através da construção de objectos, conjuntamente com a programação
do seu comportamento. Ambiciona-se com a utilização dos mundos virtuais 3D, imergir
os alunos no mundo de modo a que desta forma sejam os actores principais na
programação e sejam capazes de sentir e raciocinar qual o passo seguinte a dar para
solucionar o problema, de forma semelhante à filosofia usada no Karel.

Deste modo, como foi relatado no capítulo de introdução, considerou-se necessário


começar por estudar as possibilidades e dificuldades da utilização dos MV3D online
como plataforma para o ensino e aprendizagem introdutória da programação de
computadores a alunos do ensino superior.

67
4. Mundos Virtuais

Os aspectos abordados no presente capítulo dizem respeito ao processo de


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

69
Capítulo IV: Mundos Virtuais

4.1. Caracterização dos mundos virtuais

Os mundos virtuais existem, de algum modo, desde o início dos anos 80 do século
passado. Apesar disto, o significado desta expressão não é consensual. Isto reflecte a
dificuldade em descrever uma área que está intrinsecamente ligada ao desenvolvimento
tecnológico, mas caracterizada também por aspectos sociológicos. Obviamente, as
diferenças de entendimento sobre o que é um “mundo virtual” reflectem visões
alternativas, ora complementares, ora referentes a conceitos distintos. Considerando a
investigadora, contudo, ser esta a expressão mais comum para identificar as plataformas
com que trabalhou, optou-se aqui por reunir apenas as definições e características
propostas por autores que se enquadram também no significado dado no âmbito do
presente trabalho.

Segundo Warburton (2009), a definição de mundo virtual mais simples e consensual foi
dada por Schroeder (1996) que argumenta que os mundos virtuais devem ser definidos
como:

“A computer-generated display that allows or compels the user (or users) to have a sense of
being present in an environment other than the one they are actually in, and to interact
with that environment” (Schroeder, 1996).

Outros autores, como Castronova (2001), Smart, Cascio e Paffendof (2007) e de Freitas
(2008), consideram que a melhor forma de definir os mundos virtuais é através do
conjunto mínimo de características recorrentes que estes contêm, nomeadamente:

 Representação física – um corpo virtual designado de avatar, que é uma


representação personalizada do ser humano;

 Interactividade – permite uma interacção entre utilizadores e destes com


objectos no mundo virtual;

 Persistência – o mundo virtual continua a existir mesmo quando o utilizador


não está conectado e consequentemente não está a participar nele.

De seguida retrata-se cada um destas características em pormenor.

70
Capítulo IV: Mundos Virtuais

4.1.1 Representação física

No mundo virtual, cada indivíduo é representado graficamente através de um corpo


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

Figura 4.1: Avatares do Habitat.

Imagem retirada de Morningstar e Farmer, 1991.

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

71
Capítulo IV: Mundos Virtuais

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

A generalidade dos mundos virtuais permite ao utilizador seleccionar, configurar e


personalizar o seu avatar, relativamente ao sexo, à forma do rosto, à cor da pele ou
outros elementos. Este aspecto transmite ao utilizador uma sensação de solidez e
realismo na aparência. A nível educativo, possibilita ao professor e alunos uma
identificação visual do outro e o reconhecimento de alguém através da sua
representação física fomentando a comunicação (Veletsianos, 2010).

O nível de configuração dos avatares permitido depende do mundo: existem mundos


como o The Palace com um conjunto de avatares predefinidos, os quais pouco
permitem alterar; e outros em que quase tudo é configurável como no The Virtual Hills
ou no Second Life (Figura 4.3).

72
Capítulo IV: Mundos Virtuais

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

No entanto, os avatares que actualmente existem restringem-se ao mundo virtual em


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

4.1.2 Interactividade

Os mundos virtuais na sua generalidade são acedidos remotamente através da Internet,


permitindo a partilha do espaço entre vários utilizadores em simultâneo,
independentemente da sua localização geográfica. Estes mundos são designados de
multi-utilizador, como por exemplo, o Second Life.

A grande maioria dos mundos virtuais simula no total ou em parte as leis naturais da
Terra, como a gravidade, o dia e a noite, a topologia e o movimento, como forma de

73
Capítulo IV: Mundos Virtuais

apresentar alguma familiaridade aos utilizadores e gerar uma mais forte sensação de
presença do utilizador no mundo (Castronova, 2001). Para além deste aspecto, os
mundos virtuais contêm um conjunto de elementos que geram a sensação de presença e
de co-presença, ou seja, a sensação da presença de outrem, fomentando desta forma a
interacção entre os seus pares (Warburton, 2009), que são:

 Físicos – os utilizadores têm uma representação física no mundo (avatar),


através da qual podem observar os outros utilizadores (ou seja, os avatares dos
outros utilizadores), fazer gestos, rir, colocarem-se em determinadas poses,
dançar, abraçarem-se, aplaudir, etc. Para além disso, também permite a
possibilidade de localizar geograficamente no mundo outros avatares, por
exemplo a partir de um mapa (Figura 4.4).

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

 Estado – fornece informações mínimas sobre a presença dos avatares no


mundo, por exemplo indicando quando os avatares amigos entram ou saem do
mundo (ou seja, quando é que os respectivos utilizadores estão online ou offline).

 Comunicação – na generalidade dos mundos virtuais, a comunicação é


efectuada através da comunicação escrita, sendo contudo também comum a
comunicação vocal. Em alguns mundos é permitida uma conversação “aberta”
(ou seja, pública) através de vários canais, noutros a comunicação é mais restrita

74
Capítulo IV: Mundos Virtuais

limitando-se à utilização de um conjunto de frases pré-existentes, como é o caso


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

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

É possível, também, estabelecer comunicações textuais com outros utilizadores


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

75
Capítulo IV: Mundos Virtuais

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

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

76
Capítulo IV: Mundos Virtuais

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

4.1.3 Persistência

Uma das características importantes dos mundos virtuais é a sua persistência (Rosedale e
Ondrejka, 2003), isto é, o mundo continua a funcionar mesmo quando o utilizador se
encontra desconectado e já não participa nele. O utilizador pode ligar-se a qualquer
momento, mantendo-se no local em que se encontrava anteriormente. Um outro
aspecto a salientar é a persistência do aspecto físico do avatar e dos seus pertences, tais
como roupa, sapatos, malas e os objectos que criou ou comprou – aspecto que permite
ao utilizador identificar-se visualmente com o seu avatar.

A persistência do mundo abre um leque de oportunidades do ponto de vista educativo,


nomeadamente no que se refere à possibilidade de permitir o prolongamento das
actividades educativas no tempo (Salmon, 2009). Desta forma, deixa de existir as
limitações que muitas vezes os alunos colocam ao trabalho em grupo, relatando não o
apreciarem por não conseguirem se encontrar fora das aulas devido a morarem longe
uns dos outros (Miranda, Morais e Dias, 2007). Os professores, por outro lado, têm a
possibilidade de acompanhar e observar a evolução do trabalho, sem ser só no
momento em que este está a ser realizado. A persistência do mundo permite também a
existência de uma comunidade de utilizadores online em cada 24h do dia, como acontece

77
Capítulo IV: Mundos Virtuais

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

4.2. Os antecessores dos mundos virtuais

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

78
Capítulo IV: Mundos Virtuais

Figura 4.9: O interface do Jogo MUD textual.

Estes MUD apresentavam todas as características dos mundos virtuais actuais, embora
fossem baseados em texto. Estes sistemas constituíram as bases para o desenvolvimento
das comunidades actuais online, que presentemente são baseadas em espaços animados
3D proporcionando um cenário para o dia-a-dia do que ali acontece. As principais
semelhanças residem na dimensão e nas comunidades que se formaram nestes mundos
baseados em texto, em torno das quais se desenvolveram amizades (de Freitas, 2008).

Baseado nesta geração de MUD textuais, emergiu em 1985 o primeiro mundo virtual no
sentido utilizado nesta tese, o Habitat da LucasFilm, utilizando gráficos e avatares
(Figura 4.1). O Habitat era acedido através da utilização de um modem e de um
computador pessoal bastante comum em vários países, o Commodore 64. Este primeiro
mundo virtual manteve uma comunidade online durante seis anos, tendo um ambiente
social semelhante aos mundos baseados em texto. O Habitat era:

“(…) built on top of an ordinary commercial on-line service…Habitat presents its users
with a real-time animated view into an online simulated world in which users can
communicate, play games, go on adventures, fall in love, get married, get divorced, start
businesses, found religions, wage wars, protest against them, and experiment with self-
government.”

(Morningstar & Farmer, 1991)

79
Capítulo IV: Mundos Virtuais

Em 1996 surgiu o mundo virtual Meridian 59, tendo sido considerado o primeiro
mundo do tipo Massively Multiplayer Online Role Player Game ou MMORPG (GameSpy,
2003), ou seja, com um número muito elevado — milhares — de jogadores em
simultâneo (Achterbosch, Pierce e Simmons, 2008). Na sequência desta forte adesão, o
termo massively multiplayer foi introduzido na comunidade dos mundos virtuais, bem
como a denominação “mundo persistente” (GameSpy, 2003), uma vez que o mundo
continuava a existir quando o utilizador estava desconectado deste.

O Meridian 59 empregava muitas das características dos MUD. No entanto, revelou-se


inovador pelos seus gráficos, pois permitia aos utilizadores observar no ecrã uma
representação gráfica de tudo o que acontecia, como, por exemplo, ver outro jogador a
acenar (Figura 4.10). O sistema de comunicação, embora irrealista, uma vez que permitia
aos jogadores de qualquer parte do mundo conversar entre eles, facilitava o
estabelecimento de uma comunidade. A interface continha elementos que ainda hoje são
bastante populares como os mini-mapas (semelhantes a um sistema de radar) e uma
caixa de diálogo que permitia, além de conversar, exibir informação detalhada sobre as
acções que tinham sido realizadas. Os gráficos do Meridian 59 rapidamente se tornaram
obsoletos, mas este mundo virtual conseguiu abrir caminho para o desenvolvimento de
outros mundos que actualmente são conhecidos como MMORPG.

80
Capítulo IV: Mundos Virtuais

Figura 4.10: O interface do Meridian 59.

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

81
Capítulo IV: Mundos Virtuais

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

Com o desenvolvimento tecnológico verificado nas últimas décadas, principalmente no


acesso mais generalizado a equipamento informático com elevadas capacidades gráficas,
a banda larga, a serviços Web mais rápidos e a computadores pessoais cada vez mais
potentes, foram factores impulsionadores do crescimento acelerado destes mundos
virtuais existindo actualmente mais de 180 mundos disponíveis ou em desenvolvimento
(de Freitas e Veletsianos, 2010).

4.3. Categorização dos mundos virtuais

Como se explicou na secção anterior, os mundos virtuais existem há mais de 20 anos e


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

 mundos virtuais de competição;

 mundos virtuais sociais;

 mundos virtuais de formação;

82
Capítulo IV: Mundos Virtuais

 plataformas de desenvolvimento

 mundos virtuais profissionais.

Como foi referido no capitulo anterior, pretende-se usar os mundos virtuais no ensino
da programação de forma a que os alunos possam aprender a programar partindo do
concreto para o abstracto. A partir da construção de objectos os alunos desenvolvem
programas que simulam o comportamento atribuído a esses objectos. Pretende-se
também fomentar a aprendizagem colaborativa entre os alunos. Deste modo o mundo
virtual deve permitir:

 a conexão em simultâneo de vários utilizadores, com idade superior a 18 anos,


com o intuito de trabalharem e colaborarem entre si durante e depois das aulas.
O mundo deve ser multi-utilizador e persistente, de forma que os alunos possam
trabalhar no mundo quando quiserem e deixarem os seus trabalhos expostos
para que os colegas de grupo possam ver o que já foi feito. Assim como
possibilitar que o professor acompanhe o que está a ser feito fora das aulas;

 a comunicação em tempo real entre alunos e o professor enquanto estão online


no mundo virtual – o mundo deve permitir comunicação síncrona;

 a construção de objectos com relativa facilidade, sem requerer muito tempo de


aprendizagem. Por outro lado, não deve ser demasiado restritivo no tipo de
objectos que se possam criar, uma vez que se pretende que os alunos se
envolvam e se motivem com o que estão a fazer. O mundo deve permitir a
animação visual dos objectos criados, através da aplicação de programas que
simulem determinados comportamentos, como por exemplo, um robô que
segue o seu dono pelo mundo.

Face ao exposto, na análise dos mundos virtuais procurou-se responder às seguintes


questões: Qual o objectivo do mundo? Onde e como pode ser usado? E por quem? – que se
traduziram nos seguintes cinco parâmetros:

 Objectivo: qual o conteúdo, específico ou aberto, focado no mundo;

 Local: a interacção é restrita a um espaço ou é geograficamente dispersa;

83
Capítulo IV: Mundos Virtuais

 Plataforma: permite uma comunicação síncrona, assíncrona ou as duas. O


mundo é persistente. Qual o tipo de ligação que consente, através do
computador ligado à Internet ou é necessário alguma plataforma de jogo
específica. O acesso é gratuito ou é necessário o pagamento de uma licença de
utilização;

 População: qual o número de pessoas que permite ter conectado em


simultâneo e a sua idade;

 Programação: possibilita criar objectos dentro do mundo ou fora através de


outras aplicações, os objectos podem ser animados visualmente dentro do
mundo. Como, ou seja, que tipo de programação suporta para gerar essas
animações.

4.3.1 Mundos virtuais de competição

Os MMORPG são mundos virtuais orientados para a competição, com objectivos e


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

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

84
Capítulo IV: Mundos Virtuais

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

4.3.2 Mundos virtuais sociais

Ao contrário dos mundos referidos no item anterior, os mundos virtuais sociais


caracterizam-se por não terem um objectivo pré-definido, assim como não terem uma
narrativa. Um dos aspectos interessantes deste género de mundos virtuais é o facto de
não serem centrados numa tarefa mas serem mais uma ferramenta de socialização.
Assemelham-se aos espaços de conversas textuais como por exemplo o MySpace or
Cyworld (Messinger, Stroulia e Lyons, 2008), em que juntam as características destes
com a possibilidade de partilhar recursos, criar objectos 3D e trocar conteúdos
multimédia. Nos mundos sociais, o entretenimento pode variar desde concertos ou
apenas conversas com os amigos. de Freitas (2008) salienta que as interacções sociais
que se estabelecem nestes mundos virtuais são profundamente pessoais e podem
inclusive serem íntimas. Alguns destes mundos tornaram-se bastante populares, como é
o caso do Second Life (ibid.). Contudo, existem outros que foram encerrados, como
aconteceu com o Lively, extinto em 9 de Janeiro de 2009 e mais recentemente com o
There.com, que foi oficialmente encerrado em Março de 2010, devido a problemas
financeiros (Wilson, 2010).

Apesar de o There.com ter sido encerrado, era um mundo virtual aberto, orientado para
a socialização, no qual os participantes podiam conversar, jogar, fazer compras ou
participar em eventos (por exemplo, festas). Tendo sido criado em 1998 por Will
Harvey e Jeffrey Ventrella, a partir de 2001 foram lançadas várias versões beta e em
Outubro de 2003 (Wilson, 2010) a versão final. A utilização do There.com estava
direccionada a jovens acima dos 13 anos. A comunicação era feita através de uma
conversa textual, que podia ser pública, sendo visível por todas as pessoas que estavam

85
Capítulo IV: Mundos Virtuais

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

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

86
Capítulo IV: Mundos Virtuais

Figura 4.14:Um avatar a experimentar roupa.

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

87
Capítulo IV: Mundos Virtuais

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

Dentro desta categoria pode-se distinguir aqueles que permitem, para além da
socialização, a criação de elementos dentro do mundo, como acontece, por exemplo,
com o Activeworlds, o DotSoul, e o Second Life.

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

88
Capítulo IV: Mundos Virtuais

Figura 4.16: O browser do Active Worlds Educational Universe.

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

89
Capítulo IV: Mundos Virtuais

O SL é utilizado como plataforma para educação por diversas instituições, como


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

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

Para além da utilização do SL na educação, muitas organizações têm no SL um balcão


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

90
Capítulo IV: Mundos Virtuais

Douro, em parceria com a Portugal Telecom Inovação, desenvolveu um sistema que


permite às organizações manter uma constante interacção entre utilizadores no SL,
através da simulação da presença de funcionários usando avatares automatizados que
comunicam com as pessoas na vida real por meio de mensagens instantâneas e por
tecnologias de serviço de mensagens curtas (Valério et al., 2009).

No capítulo seguinte encontra-se uma descrição detalhada deste mundo virtual.

Na tabela seguinte apresenta-se um resumo com as características dos mundos virtuais


sociais estudados.

Objectivo Local Plataforma População Programar

There Aberto Disperso Síncrona Multi-utilizador Sim


Internet

Kaneva Social Disperso Síncrona Multi-utilizador Sim


Internet

Lively Social Disperso Síncrona Multi-utilizador Não


Internet

The Sims Social Disperso Síncrona Multi-utilizador Não


Online Objectivo Internet

Frenzoo Social Disperso Síncrona Multi-utilizador Não


Internet

IMVU Social Disperso Síncrona Multi-utilizador Não


Internet

Activeworlds Educação Disperso Síncorna Multi-utilizador Sim


Assíncrona
Internet

Second Life Aberto Disperso Síncorna Multi-utilizador Sim


Assíncrona
Internet

Tabela 4.1: Características dos mundos virtuais sociais.

91
Capítulo IV: Mundos Virtuais

4.3.4 Mundos virtuais de formação

Os mundos virtuais de formação são aqueles cujo objectivo consiste em apoiar as


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

Figura 4.18: Jogo America’s Army.

4.3.5 Plataformas de desenvolvimento

Dentro desta categoria incluem-se os mundos virtuais considerados como plataformas


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

92
Capítulo IV: Mundos Virtuais

O OLIVE, desenvolvido pelo Fronterra System de Nova Iorque e San Mateo da


Califórnia, é um exemplo interessante deste tipo de mundos virtuais, que tem vindo a
ser usado principalmente para formação profissional nas áreas da saúde, forças armadas
e comunicação social nos Estados Unidos (Forterra Systems, 2004). A MTV Networks
usou o OLIVE para criar um mundo online baseado nos seus programas televisivos, por
exemplo. Um outro exemplo de utilização do OLIVE é o caso do U.S. National
Institute of Health, que criou um mundo para treinar os seus alunos nos casos de
ocorrência de desastres. Uma das razões apontadas por David Kushner (2008) para
crescimento na utilização dos mundos virtuais na formação profissional é:

“...complexe environments are becoming more critical, and the cost of staging real-world
simulation training exercises is escalating.” (p38)

O principal factor desta plataforma ter vindo a ser utilizada apenas em contextos
profissionais deve-se ao elevado custo de licenciamento e ao facto de ser um mundo
privado, não estando disponível para o público em geral. Desta forma, este mundos
criados no OLIVE proporcionam um mundo mais seguro e controlável para o treino.

Ao contrário do OLIVE, o OpenCroquet é uma plataforma de desenvolvimento de open


source. Por conseguinte, pode ser utilizada livremente por qualquer utilizador sem custos
adicionais, o que permite criar aplicações baseadas em mundos virtuais, online 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).

93
Capítulo IV: Mundos Virtuais

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

Para além destes existem os motores de jogos, também conhecidos como game engines,
que permitem desenvolver jogos 3D, mundos virtuais 3D, entre outras aplicações
interactivas 3D. Estes motores, tipicamente, contêm um motor gráfico para efectuar o
rendering dos objectos 2D ou 3D, um motor físico que permite detectar colisões e
simular a gravidade, o suporte a animações, sons, entre outros elementos. Exemplos
dentro deste tipo de sistemas são Panda3D (2008), Delta3D (2008), CPAL3D (2002),
Unity3D (. 2005).

O OpenSimulator (2009) é um servidor de mundos virtuais que pode ser utilizado para
criar mundos virtuais 3D semelhantes ao Second Life. Contudo, não foi considerado
como alternativa no âmbito desta tese por só apresentar estabilidade tecnológica numa
fase posterior ao trabalho de campo realizado.

Na Tabela 4.2 apresenta-se um resumo das características destas plataformas de


desenvolvimento.

94
Capítulo IV: Mundos Virtuais

Objectivo Local Plataforma População Programar

Olive Aberto Disperso Licença de Multi-utilizador Sim


plataforma de utilização
desenvolvimento

OpenCroquet Aberto Disperso Gratuito Multi-utilizador Sim


Plataforma de
desenvolvimento

Unity3D Plataforma de Disperso Gratuito Multi-utilizador Sim


desenvolvimento

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

4.3.6 Mundos virtuais profissionais

Os mundos virtuais profissionais, também designados de trabalho, são mundos que


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

95
Capítulo IV: Mundos Virtuais

utilização de um mundo virtual 3D para que os utilizadores possam comunicar,


colaborar, partilhar aplicações e documentos.

Segundo de Freitas (2008) a principal diferença entre os mundos sociais e os


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

4.4. Mundo virtual adoptado

A escolha de um mundo virtual a ser adoptado nesta tese não teve em conta apenas a
linguagem de programação que o mundo virtual suporta, mas também, o contexto que
este permite criar para a aprendizagem da programação.

De todos os mundos virtuais analisados, o Second Life parece ser aquele cujas
características melhor se adequam aos objectivos desta tese. Conforme foi
anteriormente reportado, o SL contém uma ferramenta de modelação 3D fácil de usar,
que permite o desenvolvimento de diferentes objectos desde os mais simples aos mais
complexos. Permite também a animação visual dos objectos criados dentro do mundo,
um pouco como o que acontece no Alice. Este aspecto permite a um aluno criar um
objecto, implementar o comportamento que pretende que este simule, executar e
observar imediatamente no mundo o resultado do que foi codificado. No entanto, no
SL a linguagem de programação utilizada é semelhante à linguagem C a nível da sintaxe,
o que facilita a rápida migração dos alunos para outras linguagens de programação, o
que não sucede actualmente no Alice como foi referido no capítulo anterior.

Outro aspecto importante refere-se ao tipo de suporte pedagógico que o mundo detém
principalmente para aprendizagens construtivistas. Neste aspecto o SL tem algumas
características interessantes que viabilizam a sua utilização construtivista, nomeadamente

96
Capítulo IV: Mundos Virtuais

por permitir a construção colaborativa de objectos, assim como a partilha do código


entre os elementos de um grupo.

Em resumo, o SL foi o mundo virtual adoptado, no entanto neste estudo poderia


também ter sido usado outro tipo de mundo virtual como, por exemplo, o Active World
ou There.com, sendo no entanto estes mundos mais limitados no que se refere à
construção de objectos e ao tipo de colaboração que estes suportam.

97
5. Second Life

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

99
Capítulo V: Second Life

5.1. Introdução ao Second Life

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

Comunicação Comunicação por


Menu inferior escrita - Conversas voz
públicas

Figura 5.1: Aspecto geral do viewer do Second Life.

100
Capítulo V: Second Life

Este mundo é composto por várias regiões que estão interligadas, sendo frequentemente
designadas de sims, um diminutivo de “simulador”, uma vez que inicialmente um
servidor ou simulador suportava uma região (actualmente, um servidor físico pode
suportar um número variado de regiões). Cada região tem uma área de 65.536 m2
virtuais, sendo identificada por um nome. Uma posição no mundo virtual SL é dada
pelo nome da região e pelas coordenadas x, y, z dentro desta, que indicam a posição
este-oeste, norte-sul e altitude, respectivamente. O SL teve durante vários anos duas
áreas separadas: uma denominada de Teen Grid que estava reservada a adolescentes com
idades compreendidas entre 13 e 17 anos, e outra – a Main Grid – reservada a adultos.
Não era permitido que adultos entrassem na área dos adolescentes (excepto professores
devidamente verificados pela Linden Lab, e mesmo assim com grandes restrições de
movimentação) e vice versa. Em 2010, a Linden Lab fundiu a duas grelhas numa só,
com alguma complexidade na gestão da participação de menores de 16 anos, mas
permitindo que turmas do 12.º ano do ensino secundário ou do 1.º ano dos cursos
superiores pudessem estar juntas, já que estes anos escolares apresentam alguns meses
em que agregam alunos de 17 e 18 anos nas mesmas turmas.

O SL é um mundo virtual social, que imita o mundo real, não só no aspecto físico, no
qual existe a terra com efeito gravítico, a água, o céu e o passar do tempo com a noção
de dia e noite (Figura 5.2), mas também no aspecto económico. O SL tem a sua própria
moeda – o Linden Dollar (L$), que apesar de não ter valor real directo, pode ser trocado
por moedas efectivas, como dólares americanos ou euros. A moeda virtual tem um valor
flutuante em função da oferta e da procura diárias. Por exemplo, no momento de escrita
desta tese 1 US dólar equivalia a 275 L$.

101
Capítulo V: Second Life

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

5.2. Avatares no SL

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

102
Capítulo V: Second Life

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

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

103
Capítulo V: Second Life

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

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

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

104
Capítulo V: Second Life

Os utilizadores também têm a possibilidade de formar um grupo e convidar outros


avatares para fazerem parte dele. Desta forma, podem criar uma comunidade e conceder
privilégios aos elementos dessa comunidade, tais como só permitirem aos seus
elementos aceder a um terreno, manipular objectos ou trocarem mensagens entre si.

5.3. Comunicação

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

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

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

105
Capítulo V: Second Life

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

Janela das IM em que cada


separador corresponde a
uma conversa privada

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

Outra forma de comunicação existente no SL é através do uso de cartões digitais


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

106
Capítulo V: Second Life

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

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

107
Capítulo V: Second Life

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

Outra forma de transmitir pequenas mensagens, muito utilizada também, é através da


elaboração de um pequeno programa no qual se escreve a mensagem na cor pretendida
e se insere num objecto qualquer (Figura 5.10).

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

108
Capítulo V: Second Life

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

5.4. Construção de objectos 3D

Ao contrário dos outros mundos virtuais, quase tudo o que se encontra dentro do SL é
construído pelos seus utilizadores. Esta é uma das características bastante populares do
SL, pelo facto de este permitir aos seus utilizadores a criação, edição e destruição de
objectos 3D dentro do mundo. Contudo, não é possível construir objectos em
quaisquer terrenos do SL, uma vez que são propriedades privadas, estando a construção
limitada aos seus donos. Mas existem diversos espaços designados Sandboxes, nos quais
qualquer avatar que a eles tenha acesso (geralmente, o acesso é totalmente aberto) pode
construir os objectos que desejar.

No SL é possível construir objectos com comportamentos próprios, como pregões que


se movem ao sabor do vento ou aquários transparentes nos quais se observam
diferentes tipos de peixes a nadar. Para se conseguir garantir os direitos de autor de cada
objecto construído estes estão identificados por um Universally Unique Identifier (UUI),
uma string de 16 bytes que os identifica de modo único em todo o SL. Para se saber
quem foi o autor que criou um objecto basta editar esse mesmo objecto aparecendo na
janela do editor o nome do seu criador. Assim, pode-se entrar em contacto com autor
do referido objecto e pedir informações. O SL faz a distinção entre quem criou o
objecto e quem é o seu actual dono, uma vez que este pode já ter sido transmitido a
outra pessoa.

109
Capítulo V: Second Life

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

A aplicação cliente possui um editor que permite, de um modo acessível, a construção


de objectos tridimensionais (Figura 5.12). Todos os objectos no SL são construídos a
partir de um objecto 3D designado de prim, diminutivo de primitive, ou seja, um 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.

110
Capítulo V: Second Life

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

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

111
Capítulo V: Second Life

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

O modo mais básico e flexível para moldar e manipular objectos/prims é através do uso
dos seus objectos auxiliares. Estes objectos auxiliares encontram-se associados a cada
objecto quando são editados sob a forma de pequenos triângulos ou cones azuis, verdes
e vermelhos que representam os eixos direccionais:

 X: eixo Este/Oeste representado pela cor vermelha;

 Y: eixo Norte/Sul, representado pela cor verde;

 Z: Cima/Baixo, representado pela cor azul.

112
Capítulo V: Second Life

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

No caso de se pretender rodar um objecto ou alterar o seu tamanho, estes objectos


auxiliares mantêm as mesmas cores que representam os eixos sobre os quais essas
alterações são efectuadas, sendo apresentados sobre a forma de círculos ou pequenos
cubos à volta do objecto (Figura 5.15).

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

113
Capítulo V: Second Life

A construção de objectos mais complexos é feita através da ligação de vários objectos


entre si. Esta ligação tem por objectivo formar um objecto único, que permite ao
utilizador mover e manipular a combinação de objectos como se tratasse de um só. Para
ligar várias prims é necessário seleccionar, individualmente, todas as prims que se pretende
conectar enquanto se mantém o botão Shift do teclado premido. Por fim, prime-se em
simultâneo o botão Ctrl e a tecla L ou através do menu superior do SL selecciona-se no
item ferramentas (tools) a opção ligar prims.

Outra funcionalidade muito apreciada pelos construtores no SL é o facto de este


permitir a duplicação de objectos de uma forma rápida. Deste modo, facilita a
construção de objectos complexos, para tal basta seleccionar o objecto que se pretende
duplicar, em seguida premir em simultâneo a tecla Shift e deslocar uma das setas dos
eixos direccionais do objecto em causa. Na construção de objectos mais elaborados
convém saber manipular a câmara, de forma a focalizar determinados aspectos do
objecto (Figura 5.16). Para um principiante, o controlo da câmara pode-se tornar difícil
pois é necessário premir em simultâneo a tecla Alt do teclado, o botão esquerdo do rato
e deslocar este para a frente e para trás conforme se pretenda aumentar ou diminuir o
zoom. Uma outra forma de aceder ao controlo da câmara é através da sua janela de
controlo, que se encontra no menu superior item View/camera control. Contudo, esta
opção precisa de alguma prática, principalmente quando se pretende visualizar um
objecto em pormenor. O editor de objectos disponibiliza ainda uma grelha, tornando-se
visível quando se selecciona a opção Use Grid, permitindo o alinhamento de objectos de
uma forma mais precisa.

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

114
Capítulo V: Second Life

Para se criar objectos com uma aparência mais realista, o SL permite decorá-los com
cores ou texturas. Estes elementos de decoração podem ser adicionados ao objecto na
sua totalidade ou colocados faseadamente em cada um dos lados do objecto, bastando
seleccionar no editor a opção Select Texture, seguidamente ir ao objecto, com o rato
escolher a face que se pretende colorir e indicar a cor respectiva no editor. O SL
disponibiliza também um conjunto de texturas que podem ser utilizadas, mas se o
utilizador preferir pode importar para dentro do SL as suas texturas preferidas, num dos
seguintes formatos: Targa (.TAG), Windows Bitmap (.BMP) e JPEG. Contudo, é
necessário pagar 10 L$ por cada textura que se pretenda importar; esta limitação tem
por objectivo, segundo Rymaszewski (2007), evitar “encher” os servidores do SL.

Uma das características únicas do SL é o facto de este permitir a construção colaborativa


de objectos. Vários utilizadores podem trabalhar em equipa na construção de objectos,
assim como podem observar em tempo real a sua construção (Figura 5.18). O SL
contém um sistema de permissões que possibilita a um utilizador conceder a outros o
direito de editarem os seus objectos (Figura 5.17). Este sistema de permissões permite:

 a partilha do objecto com um grupo, previamente definido;

 que qualquer pessoa o possa mover;

 que qualquer pessoa o possa copiar;

 colocar o objecto visível quando se faz uma pesquisa;

 colocar o objecto à venda, no qual é possível definir o seu preço, bem como o
que o próximo dono pode fazer com este, isto é, modificar, copiar ou dar a
outro.

115
Capítulo V: Second Life

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

A característica mais apreciada é a partilha com os elementos de um grupo, tornando


possível a construção compartilhada e simultânea de objectos, evitando também que
outros utilizadores danifiquem os objectos que não são seus.

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

116
Capítulo V: Second Life

Os objectos criados no SL podem ser, de algumas formas, semelhantes aos objectos


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

5.5. Programar no Second Life

O SL tem uma linguagem de scripting associada, que permite definir comportamentos


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

5.5.1 Como se desenvolve um programa no SL

Após a construção de um objecto, na janela do editor selecciona-se o separador content


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

117
Capítulo V: Second Life

Figura 5.19: Desenvolvimento de programas no SL.

Área de
edição do
programa

Área de
mensagens

Figura 5.20: Editor de programas no SL.

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

118
Capítulo V: Second Life

“Hello Avatar” este ao ser executado envia a mensagem “Hello, avatar!” para o canal
público.

A linguagem LSL é executada no servidor num software denominado de simulador, que


simula o mundo virtual SL. No entanto, o compilador de LSL encontra-se no viewer do
SL, onde todos os programas são compilados e posteriormente enviados ao servidor
onde são executados (Rymaszewski et al., 2007). O compilador do LSL emite mensagens
de erros sempre que detecta que o programa não respeita as regras de sintaxe da
linguagem. Estas mensagens indicam a linha e a coluna na qual ou perto da qual o erro
de sintaxe ocorreu. Por exemplo, a mensagem:

“(7, 19): ERROR: Syntax error”

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

5.5.2 A linguagem de programação LSL

A linguagem LSL, enquanto linguagem de scripting, tem uma máquina de estados


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

default {
state_entry() {
llSay( 0, "Hello, Avatar!");
}

touch_start(integer total_number) {
llSay( 0, "Touched.");
}
}

119
Capítulo V: Second Life

O código que se encontra no evento state_entry é executado quando se prime no botão


Save do editor. Deste modo, o programa começa a ser executado ao entrar no estado
default. O segundo event handler touch_start, por seu lado, é desencadeado sempre que o
utilizador toca no objecto.

No programa “Hello Avatar” inicial, ambos os events handlers state_entry e touch_start


contêm a função llSay. llSay é uma função pré-definida da linguagem LSL, que permite a
escrita de mensagens de texto num determinado canal de comunicação, semelhante à
função printf da linguagem C. O canal zero é o canal público, sendo o seu texto visível
por todos os avatares que se encontram dentro de um determinado raio de acção.
Assim, por exemplo, llSay (0, “Hello, Avatar!”); escreve a mensagem “Hello, Avatar!” no
canal público.

O LSL contém uma biblioteca de funções pré-definidas que executam funcionalidades


comuns ou fornecem funcionalidades extras que seriam difíceis de escrever
directamente na linguagem (Figura 5.21). Actualmente existem mais de 300 funções na
biblioteca do LSL (Rymaszewski, 2007). Curiosamente todas as funções pré-definidas da
linguagem começam por dois ll, tornando-se assim mais fácil reconhecer as funções da
linguagem no código. Um aspecto importante refere-se ao facto de algumas destas
funções terem associado um valor de atraso, o que implica que demorem algum tempo a
serem executadas. Segundo Rymaszewski (2007), este valor existe para proteger o SL
contra certos tipos de abusos (tentativas de sobrecarregar os servidores com código
cíclico).

120
Capítulo V: Second Life

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

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

integer factorial (integer num){

if(num<3)

return num;

else {
llSay(0,"novo calculo");

return num*factorial (num -1);


}
}

default
{
state_entry()
{
integer n=7;

llSay(0, "Calculo do factorial de "+ (string)n);

llSay(0, (string) factorial(n));


}
}

121
Capítulo V: Second Life

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

Tipos de Dados 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).

122
Capítulo V: Second Life

integer counter;
integer second;
vector startPosition;

default{

state_entry()
{
llSay(0,"Toca-me, para eu me deslocar");
counter=0;
startPosition=llGetPos();//obtém as coordenadas da posição inicial
//do objecto
}

touch_start(integer num)
{
counter++;

llSetTimerEvent(1);//acciona o evento timer de 1 em 1 segundo


}

timer()
{
second++;
float x_d = llFrand (10.0);
float y_d = llFrand (10.0);
float z_d = llFrand (10.0);

vector increment = <x_d,y_d,z_d>;


vector newP = startPosition + increment;

llSetPos(newP); //coloca o objecto numa nova posição

llParticleSystem( [
PSYS_PART_FLAGS, PSYS_PART_WIND_MASK | PSYS_PART_EMISSIVE_MASK,
PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_EXPLODE,
PSYS_PART_START_COLOR, <1,0,0> ] ); //cria bolas vermelhas

if(second>19) //ao fim de 19 segundos coloca o objecto na posição


{ // inicial
while(llVecDist(llGetPos(),startPosition)>0.001)
llSetPos(startPosition);

llParticleSystem([]);
llResetScript();
}
}
}

123
Capítulo V: Second Life

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

Relativamente às estruturas de controlo, estas são idênticas às da linguagem C, quer em


termos das estruturas de decisão (if, switch), quer das de repetição (for, while, do...while).

No SL, a colaboração entre os avatares não se limita à construção de objectos, como já


foi mencionado, mas inclui também a cooperação no desenvolvimento de programas.
Assim, é possível partilhar um script que se encontra dentro de um objecto com os
amigos. Deste modo, é necessário partilhar o objecto primeiro e a seguir, com a janela
do editor do programa fechada, colocar o cursor do rato em cima do script, premir o
seu botão direito e seleccionar a opção Proprerties e nesta activar a opção Share with group.

Com esta linguagem é possível criar programas simples, como o programa “Hello
Avatar”, mas também programas bastante complexos que englobam vários estados,
sensores que possibilitam detectar vários objectos, entre outros. Contudo, é uma
linguagem simples com muitas funções pré-definidas que permite criar uma panóplia de
animações. Esta característica da linguagem LSL foi um dos factores tidos em
consideração quando se ponderou a utilização do SL para o ensino e aprendizagem da
programação, uma vez que vem ao encontro do que Jenkins (2002) argumenta que uma
linguagem de introdução à programação deve ser, como foi referido no capítulo III.

124
6. Metodologia de investigação

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

125
Capítulo VI: Metodologia de Investigação

6.1. Opções metodológicas

A procura de soluções para um problema de investigação deve envolver o emprego


de metodologias que, a partir de elementos teóricos e problemas de investigação,
permitam estabelecer directrizes e formular procedimentos para a determinação de
soluções optimizadas (Ackoff, 1998).

Na selecção do método de investigação a seguir deve-se ter em conta que na procura


de soluções inovadoras para os problemas educativos em geral, e em particular, no
que se refere ao uso de tecnologias de informação, é essencial a intervenção de
profissionais no terreno (Coutinho e Chaves, 2002). Este procedimento permite
clarificar o problema na sua fase inicial e possibilita a avaliação e teste de soluções in
loco. Toda a investigação está ligada à acção e dela depende em última análise,
ninguém poderá investigar um objecto sem agir ou interagir com ele, ou seja, o
investigador tem de se envolver na situação que tem para investigar. No entanto, isto
não implica que o investigador não faça uma interpretação objectiva daquilo que
observa para dar aos factos a sua interpretação pessoal. Assim, a investigação para ser
autêntica tem de produzir conhecimentos, conceitos novos, novas atitudes (Santos e
Travassos, 2009). Para o conseguir, o investigador terá de sujeitar-se às exigências do
método científico, conforme entendido pela comunidade científica.

Os investigadores que investigam novos domínios são muitas vezes confrontados


com o desafio de reconhecer e descrever estes fenómenos (Rijo, 2008). Poder-se-ia
ter optado por partir de um conjunto inicial de proposições com as quais se
procuraria corroborar e aprofundar os elementos a analisar, menosprezando outros.
No entanto, seria necessário existir um modelo ou teoria para estabelecer estas
hipóteses iniciais (Figueiredo, 2003).

Com base nas características da realidade que se pretendia conhecer, adoptou-se


como método científico a investigação-acção (IA). A opção por esta metodologia
baseou-se em dois aspectos fundamentais:

 O primeiro aspecto relaciona-se com facto de ser um trabalho exploratório


numa área onde existe pouca investigação (o ensino da programação de
computadores em mundos virtuais). No decorrer do trabalho, o investigador
pode ser simultaneamente o actor investigante e objecto de investigação.

126
Capítulo VI: Metodologia de Investigação

Num estudo exploratório, a metodologia investigação-acção, devido às suas


características, propicia um melhor método de investigação do que as
restantes alternativas (Dick, 2000; Farquhar, 2000; Santos e Travassos,
2009).O segundo aspecto a considerar consistiu no grau de flexibilidade
permitido pela investigação-acção, quando envolve tecnologias de
informação relacionadas com problemas sobre os quais pouco se sabe
(Neville, 1992; Bawden e Zuber- Skerritt, 2000), o que implica ir para o
terreno observar, alterar e reflectir, possibilitando uma melhoria de métodos
e processos em estudo.

A IA é um método de investigação que visa dar, ao mesmo tempo, contributos


práticos e científicos. Este método insere-se nos métodos qualitativos que são usados
mais frequentemente nas ciências sociais e humanas para o estudo de fenómenos de
grande complexidade, que num grande número de casos não podem ser estudados
por métodos quantitativos. Actualmente, estes métodos estão a ser utilizados em
Engenharia Informática e isto deve-se ao facto de as aplicações informáticas terem
hoje de ser desenvolvidas tendo em consideração factores sociais e humanos
(Figueiredo, 2003; Santos e Travassos, 2009). Existem grandes vantagens na
utilização desta metodologia de investigação, segundo Almeida (2001):

“Ela implica o abandono do praticismo não reflexivo, favorece, quer a colaboração


interprofissional, quer a prática pluridisciplinar — quando não interdisciplinar ou
mesmo transdisciplinar —, e promove, inegavelmente, a melhoria das intervenções em
que é utilizada.”.

Uma convicção fundamental deste método consiste em concluir que os processos


complexos podem ser melhor estudados introduzindo mudanças nesses processos e,
então, observar os efeitos produzidos por essas mudanças. (Baskerville, 1999; Schein,
2006).

A IA é um método essencialmente prático e aplicado, regendo-se pela necessidade de


resolver problemas reais, que pode ser utilizado por qualquer profissional. Contudo,
como o foco desta tese se centra no ensino da programação, passa-se a relatar apenas
as características da investigação-acção em educação.

Neste método não se distingue o momento da produção de conhecimento (que é


levado a cabo pelo investigador) do da aplicação desse conhecimento pelo professor
(que normalmente é também o investigador). Estes dois momentos estão interligados

127
Capítulo VI: Metodologia de Investigação

na investigação-acção. Assim, porque inclui nela os próprios sujeitos dessa


transformação, é provavelmente a investigação mais operante em matéria de
alterações profundas e duradouras de atitude. Essas transformações nascem de
dentro, são vividas, sentidas pelos próprios investigadores-actores. É a interconexão
entre teoria e reflexão do professor na acção que permite originar sólidas mudanças
nas práticas (Avison et al., 1999). Este processo de investigação na aula tem um alto
poder de incisão na prática e nas mudanças, levando o professor a apropriar-se do
currículo, tornando-se mais evidente a disfuncionalidade dos processos que tudo
previam de antemão (ibid.).

Neste estudo são valorizadas as situações pedagógicas concretas, na medida em que a


professora participante vai adequando as suas práticas de acordo com o desempenho
dos seus alunos, reflectindo passo a passo sobre os aspectos positivos e negativos das
suas tomadas de decisão que, inevitavelmente, acompanham o processo de ensino e
aprendizagem. Nesta linha de acção, assumiu-se o papel de professora- investigadora,
no sentido de a investigadora analisar reflexivamente como os processos de ensino e
aprendizagem decorrem no mundo virtual, qual a sua complexidade e como
professora aplicar nas aulas o resultado dessa investigação reflectida.

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

A investigação-acção, como método de investigação, estabeleceu-se essencialmente


no âmbito das ciências sociais e médicas. Atribui-se a Kurt Lewin (1946) o trabalho
pioneiro de investigação-acção que lhe deu corpo no âmbito da psicologia e na linha
de uma certa preocupação com os problemas sociais da sociedade americana.
Segundo este autor, a investigação-acção baseia-se numa “acção de nível realista sempre
seguida por uma reflexão autocrítica objectiva e uma avaliação de resultados”, não se pode ter
“acção sem investigação nem investigação sem acção”. Nesta linha de orientação, convém
referir o que se entende por (Dick, 2000):

Acção - o sentido de alterar, mudar uma situação;

Investigação - a obtenção de conhecimentos sobre um determinado problema


ou comunidade.

128
Capítulo VI: Metodologia de Investigação

Na investigação-acção, o professor trata de resolver os problemas que a prática


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

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

Na literatura encontra-se referência a várias propostas de organização estrutural de


investigação-acção. Nesta secção procede-se apenas à explanação da estrutura
metodológica seguida no decurso desta investigação.

Diversos autores definem o processo investigação-acção como um ciclo (ou espiral)


implícito ou explícito (Dick, 2000; Zuber-Skerritt, 2000; Cairncross e McEwan 2009).
Estes ciclos não significam a existência de repetição, mas sim de desenvolvimento,
no sentido em que os ciclos que se seguem são enriquecidos pelos precedentes.

Segundo Zubert-Skerritt (2000), um ciclo compreende quatro grandes fases:

1 - Planeamento estratégico;

2 - Acção, isto é implementação do plano;

3 - Observação;

4 - Reflexão crítica e autocrítica sobre os resultados dos pontos


anteriores e tomadas de decisões para o ciclo seguinte da
investigação-acção.

De acordo com Lessard-Hébert e Goyette (1990), na fase inicial, a definição do


problema pode englobar uma operação de pré-intervenção que compreende uma
pré-observação, a escolha do problema, a planificação do projecto e a delineação de
um calendário de operações. A fase seguinte inclui a operação de intervenção no
terreno, o ensaiar do projecto, a observação e registo. Por último, a reflexão que

129
Capítulo VI: Metodologia de Investigação

engloba as operações de avaliação, que abrangem a avaliação dos resultados da


intervenção, a apresentação desses resultados, as limitações do projecto, as
conclusões e as hipóteses que potenciem novas actuações. Quando a reflexão mostra
que o problema está resolvido ou se atingiu um nível de conhecimento significativo
sobre o problema, o projecto está concluído e o relatório final é preparado (Passfield,
2000; Cairncross e McEwan 2009), ou seja, é um processo cíclico (Figura 6.1) que
continua até que o problema inicial esteja satisfatoriamente resolvido e o processo de
investigação-acção seja dado por terminado (Carson et al., 2001).

A reflexão pode ser feita em simultâneo com a acção ou posteriormente. Quando o


investigador descreve a sua acção e todas as descrições são fruto de uma reflexão que
é feita em simultâneo com a acção ou a partir de uma retrospectiva da mesma,
designa-se por reflexão-na-acção. Segundo Schön (Schön seg. Smith, 2001), a
simultaneidade da reflexão com a acção é um conhecimento tácito que está na acção
do investigador. Quando alguém reflecte-na-acção converte-se num investigador no
seu contexto prático, não está a depender de uma teoria estabelecida, mas sim está a
construir a sua, pois não separa o pensamento da acção, experimenta, dando ao
pensamento o valor de um tipo de acção que se constrói na sua própria pesquisa. A
reflexão-na-acção é, no fundo, um processo por meio do qual se aplicam os dados
conhecidos para resolver um problema; o que implica, pois, experimentar com a
situação.

130
Capítulo VI: Metodologia de Investigação

Definição do problema

Planeamento Planeamento

Reflexão Reflexão

Acção Acção
Observação Observação

Figura 6.1: Metodologia de investigação-acção.

Adaptado de Edwards e Bruce (2000); Zuber-Skerritt (2000).

A retrospectiva feita pelo investigador que descreve as suas acções depois da sua
realização, reconstruindo mentalmente a acção ou através de filmes, para tentar
analisá-la com mais pormenor, tentando descobrir aspectos que lhe irão permitir
melhorá-la, chama-se de reflexão-sobre-acção. Alguns autores não distinguem
grandes diferenças entre esta e a anterior (Alarcão, 1991).

“Exercemos naturalmente este tipo de reflexão quando a acção assume uma forma
inesperada ou quando, por qualquer motivo, a percepcionamos a uma luz diferente da
habitual, tal como acontece quando, ao passarmos por aquela rua onde todos os dias
passamos, reparamos um dia numa janela bonita que nunca tinha atraído a nossa
atenção.” (Alarcão, 1991, p.9)

No decorrer desta investigação aplicaram-se estes dois tipos de reflexões, na medida


em que ao introduzir-se novas alterações visualizou-se e reflectiu-se em simultâneo a
ocorrência, ou não, de melhorias. Assim como, posteriormente, ao relembrar o
sucedido para descrever as observações feitas, se reflectiu sobre a acção efectuada, de
modo a obter-se progressivamente um conhecimento aprofundado da exequibilidade
deste meio de ensino.

131
Capítulo VI: Metodologia de Investigação

Durante as várias fases do processo de IA, as diferentes etapas devem ser


constantemente monitorizadas por uma variedade de mecanismos, devendo-se ser
rigoroso e sistemático nessa recolha (Dick, 2000; Cairncross e McEwan, 2009). Daí
ser necessário o uso de técnicas, tais como:

 elaboração de um diário com os relatórios das impressões subjectivas,


descrições dos encontros mantidos e das ilações aprendidas;

 realização de gravações áudio, vídeo ou fotografias dos encontros;

 recolha de documentos relativos a uma determinada situação;

 elaboração de inquéritos sob a forma de entrevistas ou questionários.

(Lessard-Hébert e Goyette, 1990; Cairncross e McEwan, 2009).

Em suma, sendo a preocupação primordial da investigadora compreender como o


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

132
Capítulo VI: Metodologia de Investigação

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

No presente capítulo descreve-se a praxis educativa realizada, regida pela metodologia


IA, para obter respostas ao problema proposto. Começa-se por expor a recolha e
análise de dados efectuada e termina-se com os resultados obtidos.
Capítulo VII: Aplicação do Método de Investigação

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

7.1. Sumário

O propósito de compreender os processos de ensino e aprendizagem da


programação de computadores utilizando o mundo virtual Second Life determinou a
opção de conduzir uma investigação qualitativa. Neste sentido, efectuaram-se quatro
ciclos da metodologia IA (Figura 7.1), que decorreram desde Março de 2007 até
Julho de 2008, tendo abrangido o 2.º semestre do ano lectivo 2006/2007 e o 1.º e 2.º
semestres do ano lectivo 2007/2008.

Começou-se por efectuar um estudo exploratório no qual se procurou indagar e


compreender como o SL poderia ser usado como plataforma para o ensino e
aprendizagem da programação. A condição exploratória deste estudo tinha como
intenção encontrar linhas de orientação para a planificação do primeiro ciclo. 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.

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

Definição do problema

Planeamento Planeamento

Reflexão Reflexão
Acção Acção
Observação Observação

1.º ciclo 2.º ciclo

Planeamento Planeamento

Reflexão Reflexão

Acção Acção
Observação Observação

3.º ciclo 4.º ciclo

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

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

2006/2007 2007/2008 2007/2008

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

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

Figura 7.2: Diagrama temporal desta investigação

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

7.2. Participantes

Neste estudo participaram, voluntariamente, alunos da Licenciatura em Informática


da Universidade de Trás-os-Montes e Alto Douro (UTAD) e do curso técnico pó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.

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

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

Gru Ciclo de Discipli Ano Número de Institui


pos IA nas curricular Alunos ção

A Lab. I 1. º 5 UTAD
Actividade
preliminar
B Lab. III 2. º 4 UTAD

Pós-
C Proj. I 6 ESTG
1.º e 2.º secundário
ciclo
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

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

de entrega de parte do trabalho, sendo a avaliação final a soma dessas avaliações


faseadas.

7.3. Recolha da informação

Nesta investigação, para reduzir a probabilidade de má interpretação, fez-se uma


conjunção de técnicas de recolha de dados, o que permitiu efectuar o cruzamento da
informação obtida, conduzindo a uma maior profundidade e compreensão dos
resultados que se obtiveram. Como refere Barbier (1990) quanto mais diversificadas
forem as técnicas utilizadas, mais “finos” e mais fiáveis serão os resultados. Neste
sentido foram utilizadas as seguintes fontes de dados:

 relatórios diários;

 registos electrónicos:

o imagens e vídeos das aulas virtuais;

o todas as mensagens trocadas entre a professora e os alunos;

 questionários;

 entrevistas informais.

No anexo I encontra-se o código atribuído a cada elemento da fonte de dados, que


serão utilizados na apresentação e discussão dos resultados.

De seguida expõem-se os objectivos que cada uma destas fontes de dados teve na
recolha de informação no âmbito desta investigação.

7.3.1. Relatórios diários

Neste estudo, a própria investigadora foi o instrumento principal de observação e


actuação. A observação participante permitiu tentar descobrir o sentido, a dinâmica e
os processos envolvidos nos acontecimentos, transcendendo o aspecto descritivo da
abordagem (Lessard-Hébert et al., 1990). Este tipo de observação serviu de base às
reflexões sobre as aulas realizadas.

Sendo a preocupação da investigadora compreender como o SL pode ser utilizado


como plataforma para o ensino e aprendizagem da programação e tendo em

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

consideração a inexistência de estudos indicativos de como este pode ser utilizado


neste âmbito, como foi referido no terceiro capítulo, começou-se por explorar o
mundo virtual sem pré-determinações do que poderia acontecer. Contudo, à medida
que o estudo foi evoluindo as observações das aulas incidiram, na sua generalidade,
sobre os seguintes pontos:

 a forma como os alunos e a professora interagiram entre si e com o mundo;

 a forma como se processaram as tarefas;

 o uso da interface do SL;

 os desafios, constrangimentos e as potencialidades para o ensino e


aprendizagem dentro do SL.

Através destas observações, foram criados relatórios diários correspondentes a cada


sessão, elaborados pela investigadora após o término destas, referindo os aspectos
importantes que ocorreram, as impressões subjectivas e as ilações aprendidas.

7.3.2. Registos electrónicos

O recurso aos registos electrónicos teve por objectivo ajudar a investigadora a


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

7.3.3. Questionários

Foram desenvolvidos e aplicados três questionários ao longo de cada um dos


semestres em que o estudo decorreu. Estes questionários foram apresentados aos
alunos que participaram no início, no meio e no fim do semestre. No anexo IV
encontram-se exemplares destes. Do ponto de vista de formato, os questionários

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

foram constituídos por questões de resposta aberta. De seguida, apresentam-se os


objectivos atribuídos aos questionários visando um esclarecimento adicional, por
parte dos alunos, sobre a aprendizagem no SL:

 O primeiro questionário teve como finalidade compreender as razões pelas


quais os alunos se sentiram motivados a participar nesta experiência, quais as
linguagens de programação que tinham estudado anteriormente e resultados
obtidos, e verificar, também, se já conheciam o SL;

 O segundo questionário teve como propósito o levantamento das


dificuldades até então sentidas pelos alunos e formas de superação, assim
como o método de ensino adoptado;

 O último questionário, realizado no fim do semestre lectivo, teve como


objectivo fazer uma avaliação do impacto que teve nos alunos a
aprendizagem da programação neste ambiente, assim como avaliar se o
enunciado do projecto proposto estava claro, se o consideraram interessante
o suficiente a ponto de os motivar na procura de soluções para o
implementarem, e, por último, avaliar o método de ensino usado. No final do
questionário, os inquiridos foram convidados a efectuar um comentário geral
sobre a actividade desenvolvida.

Estes questionários tiveram uma dupla função. Por um lado, resultaram em


indicadores importantes sobre a forma como os alunos encaram a aprendizagem no
SL. Por outro, contribuíram para um melhor conhecimento destes aspectos, por
parte da investigadora, e forneceram dados para a reflexão sobre o processo de
ensino e aprendizagem.

7.3.4. Entrevistas

Com o recurso às entrevistas pretendeu-se obter uma visão mais generalista do


problema investigado. As entrevistas com os alunos decorreram sob a forma de
conversas informais com periodicidade mensal, incidindo particularmente sobre as
aulas no SL, sobre o enunciado do projecto, sobre as dificuldades que os alunos
estavam a sentir e sobre sugestões para melhorar o processo de aprendizagem.
Durante as entrevistas, a investigadora tomou notas das opiniões dos alunos. Estas

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

permitiram estabelecer ideias sobre a forma como os participantes interpretavam as


dificuldades e potencialidades das tarefas (Bogdam e Biklen, 1994).

Os questionários e as entrevistas, em termos metodológicos, tiveram como objectivo


a produção de discursos pelos actores, tornando-os fontes directas de informação.
Como Almeida (2001) advoga, os alunos são simultaneamente aprendizes,
observadores e intérpretes do seu próprio processo de aprendizagem, pelo que os
seus comentários e observações são fonte fundamental de informação para se
compreender e melhorar o processo.

Toda esta informação proporcionou dados à investigadora para que esta fosse
obtendo um maior conhecimento sobre o processo de ensino e aprendizagem no SL,
de modo a poder melhorá-lo, assim como analisar o empenho e a motivação que os
alunos demonstravam ter ao longo do processo.

7.4. Análise da informação

Durante esta investigação houve também preocupação em validar os dados que iam
sendo obtidos, analisando a sua relevância e grau de profundidade, para que fosse
possível conferir-lhes credibilidade (Chizzotti, 1991). Numa investigação qualitativa,
em que as hipóteses e as questões do estudo emergem à medida que este se vai
desenvolvendo, a validação da informação recolhida é realizada através de
triangulação metodológica entre dados, investigador e teoria (Bogdan e Biklen, 1994).
A triangulação é, assim, um processo que utiliza múltiplas percepções para clarificar o
sentido e para identificar diferentes formas de abordagem do fenómeno em estudo
(Stake, 1995).

Neste estudo os dados analisados provieram das seguintes fontes:

 Relatórios diários de cada sessão;

 Questionários e entrevistas.

Os registos electrónicos serviram principalmente para auxiliar a investigadora a


confirmar e a relembrar o contexto das incertezas e opiniões dos alunos.

Toda a informação recolhida no decorrer desta investigação foi submetida a uma


análise de conteúdo. A análise de conteúdo efectuada nesta investigação baseou-se no

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

trabalho de Bettencourt-da-Cruz (2006), tendo sido realizadas, na generalidade, as


seguintes etapas:

1. Identificação de tópicos ou problemas significantes;

2. Agrupamento das declarações semelhantes em categorias, por comparação e


contraste;

3. Procura de inter-relações entre as categorias encontradas.

A primeira etapa da análise de conteúdo consistiu em dividir ou quebrar em unidades


os dados em bruto (Descombe, 1998, Bettencourt-da-Cruz, 2006). A finalidade desta
primeira etapa na análise de conteúdo é identificar as categorias que vão passar a ser
o objecto de análise nas fases seguintes do processo de IA. Neste sentido, começ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

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

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

7.5.1. Caracterização dos alunos

 Alunos de Lab. I – a disciplina de Lab. I funciona em paralelo com a


disciplina de Metodologias de Programação I, a primeira do currículo
integralmente dedicada à programação, embora no semestre anterior,
aspectos introdutórios da programação tivessem sido abordados em cerca de
30% da matéria lectiva de duas disciplinas, sumariadas na Tabela 7.2. Para
estes alunos, o projecto em LSL constituiu o primeiro exercício de elaboração
de um projecto de programação próprio, ou seja, esta foi a primeira vez que
os alunos se depararam com um enunciado de um trabalho com alguma
complexidade que tiveram de desenvolver. Atendendo aos antecedentes de
aprendizagem de programação destes alunos, juntamente com as respostas
dadas ao primeiro inquérito efectuado, pôde-se considerar que estes alunos
estavam numa fase muito inicial do estudo da programação.

 Alunos de Lab. III – para além do contacto com a programação de projectos


no ano curricular anterior (em C), aprenderam no 1.º semestre do ano
2006/2007 conceitos de programação orientada a objectos em C++ e nesse
mesmo semestre desenvolveram um segundo projecto prático em C++,
competências sintetizadas na Tabela 7.2. Deste conjunto de disciplinas que
frequentaram e considerando as respostas ao primeiro inquérito, considera-se
que estes alunos se encontravam numa fase que, embora inicial, visava já a
sua autonomização no uso e estudo da programação.

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

Ano Linguagens de programação Linguagens de


Disciplinas curricular anteriormente estudadas 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.

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

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

7.5.2.1. Projecto de Lab. I

Tendo em atenção o nível de aprendizagem da programação em que estes alunos se


encontravam, nível inicial, o enunciado do projecto teve por objectivo que os alunos
aprendessem a:

 Manipular estruturas de dados;

 Trocar informação entre objectos;

 Manipular estruturas de controlo;

 Estruturar o código;

 Desenvolver e aplicar funções implementadas por eles, bem como utilizar as


funções pré-definidas da linguagem.

Para além de os alunos se focarem nestas técnicas base, pretendeu-se igualmente


ampliar a complexidade das técnicas a dominar, nomeadamente, o lançamento de
respostas a eventos. Neste sentido, procurou-se que o enunciado do projecto
abrangesse estas técnicas de programação para que os alunos as colocassem em
prática. Assim, o enunciado constou na criação e programação de um cão virtual que
recebia ordens do dono e as executava, devendo também segui-lo.

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

7.5.2.2. Projecto de Lab. III

Os objectivos de aprendizagem do enunciado do projecto de Lab. III centraram-se,


para além da revisão das técnicas de programação aprendidas anteriormente, nos
seguintes aspectos:

 Na manipulação de estruturas de dados, tais como lists2 e strings;

 Na manipulação de informação, nomeadamente a explorar as técnicas de


canais de comunicação e o envio de mensagens através de e-mails;

 No lançamento e resposta a eventos;

 Na execução concorrente de código num mesmo objecto;

 Na gestão da máquina de estados;

 No uso de temporizadores e de sensores virtuais.

Aos alunos de Lab. III foram propostos dois projectos idênticos, quer na sua
complexidade quer a nível de dificuldade. Num caso, consistiu na criação de quatro
robôs; noutro, de um comboio e respectivas estações. Em ambos os casos,
pretendeu-se que os alunos desenvolvessem autonomamente um projecto mais
complexo que o de Lab. I.

7.5.3. Procedimento

Os projectos foram apresentados a todos os alunos na primeira aula, após a qual


alguns se voluntariaram para participar nesta investigação, havendo um total de 9
alunos: 5 de Lab. I e 4 de Lab. III.

No SL alugou-se um terreno no qual se construiu uma casa, com uma única divisão
onde os alunos puderam desenvolver os seus projectos ( Figura 7.4 e Figura 7.5). As
aulas dentro do SL decorreram online, isto é, a professora-investigadora estava em
Leiria e os alunos em Vila-Real, a 260 km de distância. Uma vez por mês,
encontravam-se em Vila Real para conversarem sobre o projecto.

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

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

Os alunos envolvidos nesta actividade juntaram-se à professora-investigadora online,


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

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

Figura 7.5: Imagem do interior da sala.

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

Os alunos utilizaram os computadores que se encontravam no laboratório de


informática da UTAD. Estes estavam equipados com processadores Pentium IV e 1
GB de RAM, e sistema operativo Windows XP, estando ligados à Internet com
largura de banda limitada.

7.5.4. Metodologia a usar nas aulas

A segunda questão levantada referiu-se à metodologia de ensino que a professora


devia adoptar e ao tipo de apoio a dar aos alunos durante as aulas. Com esta questão,
pretendeu-se decidir qual o tipo de intervenção que a professora-investigadora devia
usar nos ciclos seguintes e qual a metodologia que melhor se adaptava a este tipo de
ambientes. Como existiam alunos que estavam numa fase inicial da aprendizagem da
programação (Lab. I), seguiu-se uma sugestão encontrada na literatura: a
aprendizagem por exemplos (Halbert, 1984; Myers, 1990; Cypher, 1991; Lieberman,
2001; Lahtinen et al., 2005; Miliszewska e Tan, 2007). Na aprendizagem por
exemplos, os conceitos a aprender devem ser ilustrados por pequenos programas,
que os alunos executam e alteram, de forma a compreenderem melhor o que está a
ser ensinado (Lieberman, 2001). Assim, a professora devia preparar uma panóplia de
exemplos sobre os vários conceitos a serem ensinados.

Por outro lado, a investigadora pretendeu empregar uma pedagogia diferenciada, ou


seja, adaptar o ensino ao nível de conhecimento e ritmo de trabalho de cada aluno.
Como refere Tomlison (2000):

“In differentiated classrooms, teachers provide specific ways for each individual to learn
as deeply as possible and as quickly as possible, without assuming one student’s road
map for learning is identical to anyone else’s.”3

Como os alunos apresentam ritmos diferentes de aprendizagem é importante que


tenham no início um acompanhamento personalizado (ibid.). Neste sentido, a
professora deve adaptar os exemplos práticos ao nível de conhecimento de cada
aluno.

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

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

Para os alunos que se encontravam numa fase mais avançada (Lab. III) optou-se por
uma aprendizagem construtivista em que a professora desempenhou as funções de
tutora, como agente facilitadora do processo de aprendizagem (Bruer, 1993),
estimulando os alunos a colaborarem entre si de forma efectiva para que consigam
atingir os objectivos definidos no projecto. Esta ajuda envolve explicações,
demonstrações e a colocação de questões, de modo a que os alunos possam reflectir
na solução apresentada.

Os alunos de Lab. I realizaram o projecto individualmente. Embora esta organização


fosse uma opção do professor responsável pela disciplina na UTAD, este opção foi
também estendida aos alunos que realizaram o projecto no SL, de modo a haver
uniformização nesta disciplina. Já os alunos de Lab. III formaram grupos de dois
alunos para colaborarem entre si.

Outra variável considerada neste processo refere-se ao canal de comunicação a ser


usado pela professora durante as aulas. Nesta investigação, toda a comunicação
baseou-se na troca de mensagens escritas. A comunicação por voz, dentro do SL,
não foi utilizada, por duas razões fundamentais:

 A primeira, deveu-se ao facto de as aulas serem online e os alunos estarem na


sala de aula com outros colegas, que não faziam parte desta investigação. Não
era possível colocar os alunos participantes na investigação a comunicar por
voz com a professora, uma vez que seria uma acção perturbadora para os
restantes colegas;

 A segunda razão, prendeu-se com a panóplia de recursos tecnológicos


envolvidos. Para além de auriculares e microfones era necessário também
dispor de uma grande largura de banda para permitir que os alunos
conversassem em simultâneo. Este segundo factor tem sido frequentemente
referido na literatura como impedimento para a utilização de voz
(Zimmermann e Liang, 2008; Bessière, Ellis e Kellogg, 2009; Edirisingha et
al., 2009).

Assim, inicialmente optou-se por usar unicamente o canal público (consultar no


capítulo V, subcapítulo 5.3 uma explicação detalhada sobre comunicação no SL), não
só por ser o meio de comunicação mais utilizado no SL, mas também por ter a
vantagem de todos os alunos visualizar o que se estava a passar na aula.

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

7.5.5. Plano da aula

No que se refere ao plano da aula (Reynolds, 1992, seg. Bettencourt-da-Cruz, 2006,


p. 99):

“…esta deverá retratar cada uma das aulas em si, no que respeita às actividades que
a professora pretende levar a cabo em sala de aula e ao que espera que o aluno faça.
(...) Este plano deverá ser perspectivado como flexível e passível de reajustes ou, até
mesmo, de abandono face à realidade dos acontecimentos em sala de aula.”

Neste sentido, elaborou-se o plano das aulas desta primeira actividade preliminar. O
plano detalhado encontra-se no anexo II. A primeira fase consistia na construção dos
objectos que eram necessários para a realização do projecto. Pretende-se, para tal,
despender um máximo de 2 aulas, para ambos os grupos Lab. I e Lab. III. Esta
primeira fase serve, também, para que os alunos se adaptem e familiarizem com o SL.
As restantes aulas são dedicadas à programação. No fim de cada aula, a professora
fornecerá orientações sobre o que os alunos devem estudar e fazer em casa para a
aula seguinte.

7.6. Resultados e reflexões da fase preliminar

A professora começou, tanto nas aulas de Lab. I como nas de Lab. III, por explicar e
demonstrar como funcionam o SL em geral e o editor de código em particular,
incluindo as técnicas de construção de objectos. Nas três primeiras aulas, os alunos
dedicaram-se à construção dos objectos que faziam parte do projecto (um cão, um
robô e um comboio) e a familiarizarem-se com o editor. Durante esta etapa de
adaptação, as dificuldades sentidas pelos alunos de ambos os grupos foram
semelhantes, nomeadamente:

 Como ligar objectos entre si – um erro comum, que sucedeu ao tentarem


ligar vários objectos que tinham construído, foi que ao seleccionarem os
objectos em questão, por descuido seleccionavam também outros dos quais
não eram os donos, como, por exemplo, o chão da casa. Desta forma a
ligação tornava-se impossível. Em outras ocasiões, não seleccionaram todos
os objectos que pretendiam ligar entre si;

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

 Como criar cópias de objectos – sucedeu frequentemente que, ao tentarem


replicar um objecto, por exemplo, a pata do cão, seleccionarem outros dos
quais não eram os donos, nomeadamente, o chão; isto impediu-os de criar
réplicas. Por vezes, não tiveram os objectos que faziam parte da pata ou do
braço do robô todos ligados entre si, assim só parte do objecto era replicado.

Outro aspecto, a salientar durante esta actividade, consistiu no facto de os alunos


repetirem com alguma frequência o mesmo erro, nas várias aulas. Do ponto de vista
da investigadora, a frequente incidência destes erros deveu-se a dois factores:
primeiro, o editor tem uma panóplia de comandos (ver capítulo V) o que dificulta a
sua utilização, principalmente para quem é iniciante; segundo, os alunos não
compreenderam o que a professora lhes explicou. Devido ao facto de a explicação
ser dada por escrito e alguns comandos consistirem na conjunção de teclas como,
por exemplo, fazer o zoom (descrito no capítulo V, pag. 113), o que dificulta o
processo de execução, os alunos frequentemente não compreendiam que as tinham
de premir em simultâneo. Este segundo factor foi corroborado pelos alunos nos
encontros mensais, os quais mencionaram:

- “A nossa principal dificuldade consistiu em fazer o zoom aos objectos, de forma a


podermos seleccionar apenas os nossos e não percebíamos como fazê-lo”. (Ent., aluno
2 de Lab III, dia 26/4/2007)

-“Embora a professora explicasse como se devia fazer o zoom nós não


compreendíamos que tínhamos de utilizar as várias teclas em conjunto”. (Ent.,
aluno 4 de Lab. I, dia 27/4/2007)

Esta etapa da construção levou mais tempo do que a investigadora planeara, que
inicialmente era de duas aulas. Por um lado, as dificuldades sentidas atrasaram a
construção dos objectos, por outro, os alunos entusiasmaram-se com a construção e
em vez de criarem objectos simples empenharam-se em criar objectos mais
elaborados e complexos (Figura 7.7 e Figura 7.7).

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

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

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

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

Na quarta aula, deu-se início à aprendizagem da programação. Durante este processo,


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

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

Observou-se que os alunos conseguiram compreender o que estes pequenos


programas faziam e qual o objectivo de cada um. Quer através da experiência pessoal
da investigadora como docente de programação, quer através da literatura da área
(Chen e Weld, 2008), sabe-se que este aspecto é difícil de alcançar quando os alunos
estão a aprender a programar, principalmente, em ambientes tradicionais como, por
exemplo, compiladores de C para linha de comandos, onde os alunos, geralmente,
sentem grande dificuldade em perceber o objectivo da programação.

Um aspecto particularmente importante no ensino da programação é a reacção dos


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

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

“Algumas vezes perguntávamos se a professora nos podia ajudar e não obtínhamos


resposta.”. (Ent., aluno 3 de Lab. I, dia 12/7/2007)

Uma das soluções pensadas para ultrapassar este problema consistiu em criar algum
processo de chamada de atenção, sem ser por chat, de tal forma que a professora se
apercebesse visualmente de que um aluno ou grupo também precisava de ajuda. Este
mecanismo visual de chamada de atenção não chegou a ser implementado neste
ciclo, nem nos seguintes, uma vez que a investigadora, face ao problema exposto,
decidiu utilizar o canal público exclusivamente para dar explicações gerais a todos os
alunos e o canal privado para tirar dúvidas ou dar explicações individuais a um aluno
de cada vez.

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

Outro contratempo constatado verificou-se quando os alunos tinham dúvidas no


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

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

-“Muitas vezes esquecíamo[-no]s que se tinha de dar permissões para a professora


poder ver o código.”. (Ent., aluno 2 de Lab. I, dia 31/05 /2007)

-“ Acontecia frequentemente não nos lembrarmos como é que se davam as permissões e


por isso a professora não conseguia ver o código, porque as permissões estavam
erradas.”. (Ent., aluno 4 de Lab III, dia 31/05/2007)

Os alunos de Lab. I não conseguiram concluir o projecto na totalidade durante as


aulas como estava previsto no plano inicial. Contudo, embora estes alunos tivessem
uma semana adicional após as aulas terem terminado não foram capazes de o acabar
sozinhos. Este resultado deveu-se, na opinião da investigadora, por um lado, devido
aos alunos não terem hábitos de programação autónoma e, por outro, ao facto de
durante as aulas ter-se consumido algum tempo para que estes assimilassem os
conceitos de programação e respectivas técnicas, o que os impediu de chegarem à
última aula com o projecto totalmente concluído. Os alunos nos questionários e nas
conversas tidas com a professora, explicaram esta situação da seguinte forma:

-“Nós tínhamos outras disciplinas para fazer e deixámos o projecto para o fim, só que
depois não tivemos tempo de o acabar”.(Ent., aluno 1 de Lab I, dia
12/07/2007)

-“Pensávamos que o projecto era fácil de fazer e por isso dedicamo-nos (sic) a outras
disciplinas e deixámos esta para o fim e por isso não conseguimos acabar”. (QuestF.)

7.6.2. Aulas de Lab. III

Estes alunos facilmente se adaptaram ao SL e à linguagem de programação LSL. O


objectivo inicial da professora em centrar-se na orientação, fazendo com que os
alunos por sua auto-iniciativa investigassem e apresentassem soluções, foi totalmente
atingido. Contudo, esta metodologia levou a que os alunos efectuassem muitos erros
de execução. Frequentemente, aplicavam erradamente as funções predefinidas da
linguagem. Observou-se que escolhiam as funções por tentativa e erro, sem
pensarem no que realmente queriam fazer. Nestas situações, a professora
questionava-os sobre qual a funcionalidade que pretendiam implementar, 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

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

corrigiram o programa e continuaram à procura de uma solução. Apesar de os alunos


terem referido que o projecto era difícil e extenso, estes concluíram-no na totalidade,
como se pode constatar no seguinte comentário feito nas aulas:

-“O projecto é complicado e tem muitas funcionalidades, mas nos (sic) estamos a
gostar de o desenvolver.”(Reg., aluno 3 de Lab III, dia 8/05/2007)

No decorrer das aulas, observou-se, por parte dos alunos, um grande empenho no
desenvolvimento do projecto. Estes ficaram de tal modo fascinados pelo SL que
criaram vários objectos e programas por mero divertimento, acabando um deles por
receber uma proposta de compra, por um dos avatares residentes no SL (não se
tratou de uma tentativa de fraude académica, mas sim de legítimo interesse individual
no produto criado).

7.6.3. Professora

Do ponto de vista da investigadora, a maior dificuldade na utilização do SL para o


ensino da programação consistiu:

 Na gestão da comunicação entre a professora e os alunos – devido ao facto


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

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

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

 Na disposição espacial dos grupos de alunos no mundo virtual – os alunos


encontravam-se dispersos pela sala, outros vinham para fora trabalhar,
atendendo ao facto do limite visível de comunicação através do canal público
ser de 20m (virtuais). Consequentemente, a professora tinha de se deslocar
pelo espaço para se inteirar do que estavam a fazer e das possíveis dúvidas
existentes. Este facto poderia ter sido evitado caso fosse utilizado outro canal
na comunicação, como seja o uso de mensagens privadas através das quais se
pode estabelecer uma comunicação independentemente da distância a que se
está;

 No apoio aos alunos fora das aulas semanais – os alunos fora do tempo de
aula continuavam a desenvolver os seus projectos, a procurar soluções para
os diversos problemas. Todas as vezes que tinham aulas, expunham à
professora as dificuldades sentidas e os progressos alcançados. Em alguns
casos, preferiam enviar pelo SL uma mensagem à professora expondo as suas
dificuldades e pedindo orientações. Para um acompanhamento mais eficiente,
por parte da professora, seria útil existir um mecanismo de informação como,
por exemplo, e-mail ou outro sistema exterior ao SL, que desse indicação do

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

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


tentativas efectuadas para as ultrapassar.

7.6.4. Questionários

Relativamente aos questionários realizados nesta actividade, ao primeiro e segundo


responderam a totalidade dos alunos (15) que participaram, no último responderam 3
de Lab. I e 5 de Lab. III. Da análise feita a estes questionários e das reuniões tidas
com os alunos, foram mencionados os seguintes aspectos:

 Método de ensino usado – os alunos consideraram que em algumas aulas


tornou-se difícil de perceber o que a professora explanava porque alguns
colegas estavam a conversar ou os objectos a enviar mensagens. Referiram,
também, que o facto de estarem a trabalhar perto uns dos outros e alguns em
grupo, associado aos problemas em acompanhar o discurso da professora,
contribuiu para entrarem em conversas paralelas e a dispersarem-se dos
assuntos em discussão. Uma vez mais se confirma que o canal escolhido não
foi o mais apropriado. Os alunos de Lab. I consideraram que os exemplos
práticos que puderam testar e alterar foram importantes para compreenderem
os conceitos e os ajudaram no desenvolvimento do projecto;

 Projecto proposto – os alunos foram unânimes em referir que o enunciado


era explícito, que compreenderam o que tinham de implementar, embora não
soubessem de que forma. Os alunos de Lab. I consideraram o projecto
acessível, no entanto confessaram que não o conseguiram terminar por não
terem dedicado mais tempo fora do período das aulas. Por outro lado, os
seus colegas de Lab. III consideraram o enunciado do projecto interessante e
um pouco difícil, mas gostaram muito de o concretizar. Este facto levou a
investigadora a considerar que o enunciado do projecto atribuído aos alunos
de Lab. I talvez fosse demasiado simplista, pelo que estes alunos não se
aplicaram como deviam para o concluir. Este raciocínio vem na linha do que
Schmidt e Moust (2001) referem ao mencionarem que um problema não
deve ser nem demasiado simples nem demasiado complexo; quando um
projecto é demasiado fácil, muitas vezes, os alunos não se aplicam como
deveriam;

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

 Aprendizagem no SL – os alunos mencionaram que nunca tinham usado o


SL. Um aspecto positivo, realçado por todos, referiu-se ao facto de no SL
poderem observar visualmente a execução dos seus programas:

-“Assim conseguíamos perceber para que servem as estruturas de repetição e


decisão.” (Ent., aluno 5 de Lab. I, dia 12/07/2007)

-“No SL bastava observar o comportamento do nosso cão para saber se o


programa estava correcto, assim é muito mais fácil.” (Reg., aluno 3 de Lab. I,
dia 4/06/2007)

Referiram ainda que gostaram da experiência, que foi proveitosa para quem
estava a aprender a programar. Um dos pontos negativos que referiram
consistiu no facto de a linguagem de programação ser o LSL e não uma das
linguagens que estudam ao longo do curso;

 Comentário geral sobre a actividade – os alunos não fizeram grandes


comentários, mas genericamente gostaram da experiência, como se evidencia
nos seguintes comentários:

“Gostei de participar nesta experiência”(Ent., aluno 1 de Lab. I, dia


12/07/2007);

“gostei de programar no SL”;(QuestF.)

“fiquei viciado no SL” (Reg., aluno 4 de Lab III, dia 12/06/2007)

Na Tabela 7.3 apresenta um resumo do que se constatou ao longo da


actividade preliminar.

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

Participantes Constatações

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

Lab. I Dificuldades em compreender os erros de compilação;

Dificuldades em compreender como funcionam os eventos;

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


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

Dificuldade em gerir a comunicação entre os alunos e a professora;

Os alunos estavam muitos dispersos pelo espaço da aula no SL o que


Professora dificultou o acompanhamento por parte da professora;

Dificuldade em acompanhar o desenvolvimento do trabalho fora das aulas


semanais.

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

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

Após a fase preliminar, na qual se identificaram os vários problemas supra


mencionados, deu-se início à planificação do primeiro ciclo estruturado da IA. Neste
primeiro ciclo, a preocupação principal da investigadora consistiu em perceber a
razão primordial das dificuldades sentidas pelos alunos, sobretudo no que diz
respeito à programação e testar uma nova forma de comunicação para melhorar a
dinâmica das aulas.

7.7.1. Caracterização dos alunos

Neste ciclo participaram os alunos das disciplinas de Lab. II da UTAD e Proj. I da


ESTG. São disciplinas práticas, com presença obrigatória e uma carga horária de 2
horas semanais em sala de aula e 2 horas semanais de trabalho autónomo, estando
previstas 15 aulas. Na primeira aula apresentou-se aos alunos o enunciado do

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

projecto proposto, findo a qual se voluntariaram para participar nesta experiência 6


alunos da ESTG e 10 da UTAD.

Os alunos de Lab. II, no ano anterior, tiveram uma disciplina semestral de introdução
à linguagem C, na qual desenvolveram um projecto nesta linguagem de programação,
na linha de comandos. No corrente ano lectivo, em simultâneo com a disciplina de
Lab. II estavam a aprender programação orientada a objectos em C++ (Tabela 7.4).
Na generalidade, estes alunos possuíam um pouco mais de conhecimentos de
programação do que os de Proj. I. Os alunos de Proj. I, no ano anterior, tiveram uma
disciplina semestral de introdução ao C, na qual abordaram somente os conceitos
básicos, tendo sido, no entanto, este o primeiro projecto que desenvolveram. Estes
alunos, a nível de conhecimentos de programação, encontravam-se no mesmo
patamar dos de Lab. I.

Disciplinas Ano curricular Linguagens de programação Linguagens de programação


anteriormente estudadas 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;

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

o Manipulação de estruturas de dados, tais como lists e strings;

o Troca de informação entre objectos;

o Manipulação de estruturas de controlo;

o Estruturação do código;

o Desenvolvimento e aplicação de funções, implementadas pelos alunos


assim como as pré-definidas da linguagem.

Em relação aos alunos de Lab. II, acordou-se com o professor responsável


pela disciplina da UTAD que o enunciado do trabalho efectuado no âmbito
desta investigação teria de ter características idênticas aos dos trabalhos
propostos fora dela aos demais alunos da disciplina. Assim, este trabalho
consistiu na gestão de um armazém de farmácias onde os alunos aprenderam
a programar, focando técnicas não visuais como a manipulação de dados
textuais e numéricos. Os objectivos de aprendizagem deste projecto
centrarem-se, para além da revisão das técnicas de programação aprendidas
anteriormente, nos seguintes aspectos:

o Na manipulação de estruturas de dados, tais como lists e strings;

o Na manipulação de informação, nomeadamente a exploração de


técnicas de canais de comunicação e o envio de mensagens através de
e-mails;

o Na gestão de máquina de estados.

Os enunciados dos projectos foram disponibilizados no SIDE da UTAD e


no Moodle da ESTG, ao qual todos os alunos que participaram tinham
acesso.

No anexo III encontram-se os enunciados dos projectos propostos.

 Procedimento durante as aulas – os alunos trabalharam aos pares,


colaborando entre si na resolução do problema. Ambos os grupos de alunos
permaneceram na sala de aula acompanhados pelo respectivo professor da
disciplina e restantes colegas, e encontravam-se no SL com a 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,

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

também, reuniões agendadas uma vez por mês e outras sempre que se
considerassem necessárias. Relativamente ao plano da aula, este foi
semelhante aos dos alunos de Lab. I do semestre anterior, que pode ser
consultado no anexo II. Contudo, salienta-se o aspecto de na terceira aula os
alunos terem de entregar o algoritmo do projecto. Pretendeu-se, assim,
obrigar os alunos a pensar e a planear o projecto antes de iniciarem a sua
execução. Para além disto, o projecto teve quatro momentos de avaliação, ao
longo do semestre. Na última aula, todas as funcionalidades deviam estar
implementadas. Durante as aulas, a professora empregou uma pedagogia
diferenciada, disponibilizando exemplos práticos dos conceitos que foram
sendo introduzidos. Contudo, estes exemplos foram alterados e adaptados às
dificuldades versus facilidades e ritmos de trabalho de cada aluno;

 Comunicação – as aulas, em ambas as disciplinas, decorreram de forma


semelhante às da fase anterior, isto é, foram aulas online. Face às dificuldades
sentidas, na iteração anterior, referente à utilização exclusiva do canal público
durante as aulas, no próximo ciclo de IA passou-se a utilizar o canal público
exclusivamente para fazer chamadas de atenção, para expor ou demonstrar
algo para todos os alunos. O canal privado passou a ser o principal meio de
comunicação entre a professora e os alunos. Todos os objectos deveriam
enviar as suas mensagens directamente para o seu dono, através de um canal
próprio em vez de ser o público;

 Espaço da aula – para cada grupo de alunos, foram criadas zonas demarcadas
por um círculo onde estes deviam trabalhar (Figura 7.10). Esta demarcação
resultou do facto de na iteração anterior os alunos terem-se dispersado pelo
terreno, obrigando assim a professora a deslocar-se constantemente de forma
a inteirar-se do que estes faziam. No espaço da aula criou-se também uma
zona de exposição, onde se colocaram os vários exemplos usados nas aulas
para demonstração. Nesta zona, os alunos puderam colocar os trabalhos que
desenvolveram ao longo do semestre.

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

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

 Apoio aos alunos fora das aulas – considerando a dificuldade da professora,


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

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

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

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

Por volta da sétima semana, a investigadora efectuou uma interrupção no ciclo de IA


e reflectiu sobre o que se tinha observado até ao momento nesta iteração, de forma a
repensar sobre o que estava correcto e errado, inserindo alterações para melhorar o
processo de ensino e aprendizagem.

A primeira e segunda aulas foram de adaptação ao SL, consistindo estas na criação e


configuração do avatar, e na construção de objectos para a ambientação dos alunos
ao editor de SL. As dificuldades relatadas na fase preliminar, em relação à utilização
do editor, mantiveram-se, ou seja, ambos os grupos de alunos sentiram as mesmas
dificuldades em relação à forma de replicar e ligar objectos entre si. Nas reuniões
mensais, os alunos confirmaram que tiveram dificuldades em compreender como
usar os comandos, como se constata pelos seus comentários:

-“Não conseguímos compreender como criar uma cópia, nem como fazer o zoom.”.
(Ent., aluno 2 de Proj. I, dia 22/10/2007)

-“Foi difícil de perceber como ligar os objectos entre si.” (Ent., aluno S de Lab II,
dia 25/10/2007)

Por outro lado, os alunos de Proj. I pediram à professora para terem uma reunião na
qual lhes explicasse como funcionava o editor, como se podia fazer uma réplica de

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

um objecto e como se fazia o zoom. Notoriamente as dificuldades em usar o editor


desapareceram. Esta situação levou a investigadora a considerar importante que a
primeira aula no SL seja presencial e não remota para se poder explicar e demonstrar
a correcta utilização do editor.

Em termos de comunicação, a abordagem adoptada neste ciclo evitou os problemas


mencionados anteriormente, uma vez que, através do canal privado, a professora teve
sempre presente as solicitações que estava a receber dos alunos. Contudo, nem
sempre conseguiu dar uma resposta imediata às solicitações recebidas,
nomeadamente, quando se encontrava a esclarecer alguma dúvida a um aluno, para
não interromper a explicação em curso, a professora só respondia quando terminava.
Esta situação induziu os alunos a pensarem que a professora se tinha ausentado e
muitas vezes perguntavam através do canal público:

“ A professora está aí?” (Reg., aluno S de Lab II, dia 17/12/2007)

Para além deste aspecto, no geral, os alunos apreciaram a utilização deste meio de
comunicação, uma vez que, sentiram que tinham uma professora exclusivamente
para eles, como se constata pelos seus comentários:

-“(…)parecia que estávamos a ter explicações e não numa aula.”(QuestInt.)

-“Gostei, pois podia colocar as minhas dúvidas sem me preocupar com o que os meus
colegas iam pensar.” (Ent., aluno M de Lab. II, 22/11/2007)

Relativamente à distribuição espacial dos alunos, o facto de se terem demarcado


zonas de trabalho no espaço dedicado às aulas para cada grupo, evitou as constantes
deslocações da professora para fora da sala, e por outro lado ajudou-a a ter uma
noção geral da turma durante as aulas.

7.8.1. Programação alunos de Lab. II

A questão da programação foi introduzida usando-se a mesma metodologia dos


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

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

desenvolvimento do trabalho, observou-se que os alunos não foram capazes de


aplicar os conceitos aprendidos a novas situações. Apesar de estes alunos já terem
conhecimentos de programação em linguagem C, apresentavam muitas dificuldades e
falhas na compreensão dos conceitos básicos, principalmente em como os aplicar
correctamente. A título de exemplo: nas estruturas de repetição, não sabiam quando
nem como usá-las; nas funções, não sabiam como chamar uma função definida por
eles. Ao contrário do que seria de esperar, estes alunos não reconheciam as suas
dificuldades, como se pode constatar pelos seus comentários:

-“Eu sei a linguagem C, e não tenho dificuldades em C, eu tive uma boa nota o ano passado.”
(Reg., aluno A, dia 29/10/2007)

-“A linguagem C eu sei, aqui é que não percebo nada disto.” (Reg., aluno B de Lab. II, dia
5/11/2007)

Contudo, não mostraram nas aulas que realmente sabiam aplicar esses
conhecimentos. Alguns dos exemplos práticos, que a professora disponibilizou para
eles analisarem, foram na generalidade percebidos, mas no entanto os alunos não
foram capazes de observar que era precisamente esse mesmo código que tinham que
aplicar no seu trabalho. Este aspecto vem ao encontro do que Winslow (1996) refere:

“that novice programmers neglect strategies, are limited to the general knowledge of the
subject and that knowledge is fragile.”

Um conhecimento frágil é descrito, pelo mesmo autor, como sendo algo que os
alunos sabem, mas não conseguem aplicá-lo quando é necessário.

Os erros de compilação ocorreram com alguma frequência. Os alunos de Lab. II


apresentaram muitas falhas em termos de sintaxe, por exemplo, nas estruturas de
decisão e repetição, o que surpreendeu a investigadora, uma vez que estes já tinham
desenvolvido um projecto em C e não era de esperar este tipo de erros. A abordagem
adoptada pela professora consistiu em aconselhar os alunos a analisarem a linha do
código na qual o erro se encontrava e a pensarem no que faltava ou no que estava
errado. Contudo, após a reincidência dos mesmos erros, pôde-se concluir que esta
abordagem não foi a mais adequada. Assim, no ciclo de IA seguinte a professora
passou a escrever comentários no código dos alunos, para que estes tivessem sempre
presente uma justificação escrita da causa do erro.

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

Quanto aos erros de execução observou-se, em algumas situações, que os alunos não
eram capazes de concluir se o programa estava a funcionar correctamente ou não.
Como se tratava de um projecto não visual, que se resumia à manipulação textual da
informação, os alunos pediam com frequência o auxílio da professora para esta
conferir o correcto funcionamento do programa, como se pode constatar pelas
seguintes afirmações recolhidas nas aulas:

-“Confirme, se faz favor, se é isto que o programa tem de fazer.” (Reg., aluno A,
dia 5/11/2007)

-“Eu não percebo nada disto, não sei se o programa está certo ou errado.” (Reg.,
aluno B, dia 29/10/2007)

A falta de uma componente visual no projecto foi motivo de um maior


descontentamento e até frustração por não terem sido capazes de solucionar as
situações. Um dos grupos estava constantemente a solicitar ajuda, parava à mínima
dificuldade, quer em relação aos erros de compilação, quer de execução e até de
interpretação do enunciado do problema. Por mais que a professora tentasse que este
grupo progredisse sozinho, tal não foi alcançado. Uma das razões apontadas pelos
alunos nas respostas ao questionário foi:

-“(...) que o enunciado do trabalho prático era complicado para ser feito no SL e que
preferiam estar a implementar outro tipo de programa mais interessante.” (QuestF.)

Outra fonte de dificuldades, em relação aos erros de execução, residiu na escolha da


função correcta para simular uma determinada funcionalidade. Esta mesma
dificuldade também se observou nos alunos de Proj. I. O manual da linguagem LSL,
para cada função, descreve o que esta faz, o tipo de dados que recebe e devolve.
Embora existam muitas funções (Figura 7.12), algumas destas são correntemente
usadas, pelo que a investigadora estava com alguma dificuldade em compreender a
razão deste erro sistemático. Tendo-se observado no decorrer das aulas e
principalmente das conversas tidas com os alunos que o problema residia,
fundamentalmente, na dificuldade em compreenderem a língua inglesa, pelo que a
investigadora decidiu traduzir para português algumas das funções usualmente
empregues no projecto que os alunos estavam a desenvolver.

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

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

7.8.2. Alunos de Proj. I

Os alunos de Proj. I embora sentissem dificuldades em relação aos erros de


compilação, execução e de interpretação do problema, já referidos anteriormente,
tentavam dar-lhe solução, efectuando pesquisas e adaptando os programas-exemplo
que encontravam. Estes alunos demonstraram ser mais autónomos, apesar de
estarem no início da sua aprendizagem, mostraram maior entusiasmo com o SL,
demonstrado através do desenvolvimento de outros objectos e programas, para além
dos que lhes era solicitado no enunciado do projecto.

Face a estes dois cenários opostos relativos à reacção dos alunos, expostos a
enunciados diferentes, a investigadora, para despertar o interesse dos alunos de Lab.
II mais desmotivados, considerou pertinente introduzir uma componente visual no

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

enunciado do projecto dos alunos. Aos alunos de Proj. I, mais motivados,


introduziu-se, no projecto, uma componente de manipulação textual da informação.
Com este ajuste aos enunciados dos projectos pretendeu-se avaliar se haveria
mudanças significativas nestes dois grupos ao nível da motivação na aprendizagem,
tendo representado o início de uma nova iteração de IA. A Tabela 7.5 apresenta um
resumo das observações deste ciclo de IA.

Participantes Constatações

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

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

Lab. II
Dificuldades em compreender o objectivo do projecto e consequente
desmotivação dos alunos;

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

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


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

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


execução;
Professora
Dificuldade em acompanhar o desenvolvimento do trabalho fora das aulas
semanais.

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

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

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

7.9. Plano do 2.º ciclo de investigação-acção

Face ao exposto, efectuaram-se as seguintes alterações nas variáveis:

 Projecto – considerando as dificuldades e reacções dos alunos ao facto de


não terem um projecto sem execução visual, no projecto dos alunos Lab. II,
incluiu-se uma componente visual, a qual consistiu na criação de um balcão
com dois objectos, um receptor dos pedidos e outro que os executava.
Sempre que um pedido fosse executado com êxito, o objecto que os
executava devia, por exemplo, lançar uma bola para o ar, de modo a que os
alunos tivessem um feedback visual da execução do seu programa. No projecto
dos alunos de Proj. I, pretendeu-se analisar qual o efeito que surtiu nos
alunos inserir-se uma componente não visual. Assim, incluiu-se mais uma
funcionalidade “gestão de vendas”, para que os alunos passassem a focar-se
em técnicas não visuais como a manipulação de estruturas de dados e strings;

 Apoio ao aluno durante as aulas – Face às dificuldades em os alunos se


recordarem das causas dos erros cometidos, que foram anteriormente
explicados pela professora, esta passou a escrever comentários no código
destes, expondo as causas dos erros. De modo a que os alunos
compreendessem o funcionamento das funções predefinidas da linguagem
LSL, a professora traduziu para português as funções da linguagem mais
usadas, que foram disponibilizadas no SIDE da UTAD e no Moodle da
ESTG.

As restantes variáveis mantiveram-se inalteradas.

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

A estratégia adoptada neste ciclo, em relação ao projecto, não produziu os frutos


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

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

também não conseguiu que estes alunos passassem a gostar do que estavam a fazer
nem alterassem a sua posição. Contudo, a maioria conseguiu chegar ao fim das aulas
com parte do projecto desenvolvido, embora houvesse um grupo que acabou por
desistir e outro que não obteve aprovação à disciplina. Os restantes alunos
conseguiram chegar ao fim com êxito, devendo-se principalmente ao tipo de
acompanhamento que tiveram, à relação que se estabeleceu entre eles e a professora
e à ajuda do colega, particularmente por constatarem que este estava a ser 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

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

do erro, lemos e quando ocorre, voltamos a ler e assim conseguimos nos lembrar e
resolver o problema quando acontece.” (Ent., aluno R de Proj. I, dia
14/01/2008)

- “(...) a professora a explicar pelo chat na altura percebe-se mas quando voltamos a
cometer o mesmo erro já não nos lembramos o porquê e também não procuramos o que
foi dito no chat porque já lá está muita coisa escrita e é difícil de localizar; assim
escrito no código é mais rápido de iremos ver.” (Ent., aluno C de Lab II, dia
11/01/2008)

Deste modo, os erros de compilação diminuíram. Em relação aos erros de execução,


a tradução para português das principais funções ajudou os alunos a compreenderem
o seu funcionamento e como deviam ser utilizadas. Contudo, observou-se ao longo
das aulas que os alunos apesar de terem feito no início o algoritmo do trabalho não o
compreenderam na totalidade. Daí, que a cada passo que dessem na sua
implementação ficavam sem saber o que fazer a seguir e como fazê-lo. Estes
resultados induziram a investigadora na procura de outra solução para o ensino da
programação neste ambiente, que despertasse nos alunos o interesse pela
aprendizagem e, por outro lado, os impulsionasse na procura autónoma de soluções
para o problema que estavam a solucionar.

Naturalmente, surgiu a ideia de se utilizar a metodologia problem-based learning (PBL),


uma vez que esta pode ser aplicada a pequenos grupos de tutoria. Para além deste
aspecto, os estudos efectuados por De Grave (1998) e corroborados por Schmidt e
Moust (2001) sugerem que a análise do problema ao ser efectuada por um grupo
pequeno tem um efeito largamente positivo nos alunos, porque estes conseguem
relembrar as soluções aplicadas, em oposição ao que sucede na análise individual dos
problemas. Por outro lado, esta metodologia incentiva a discussão dos problemas
pelo grupo. De Grave (1998) e Schmidt e Moust (2001) consideram que o trabalhar
sobre o conhecimento que os alunos têm a priori e o facto de aprenderem uns com os
outros, mesmo antes de novas informações serem adquiridas, é um poderoso meio
para facilitar a compreensão da informação relevante sobre o problema em questão.
Estes e outros aspectos, referidos no capítulo 3, levaram a investigadora a utilizar esta
metodologia no ciclo seguinte.

A problemática da comunicação ficou parcialmente resolvida com a metodologia


usada. Com a utilização do canal privado para os alunos exporem as suas dúvidas

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

individualmente à professora, conseguiu-se criar uma dinâmica de trabalho eficaz


durante as aulas. A professora notava mais rapidamente os alunos que solicitavam
ajuda, colocavam as suas dúvidas e dificuldades sem se sentirem embaraçados pela
presença dos colegas, e sem perturbarem a aula, como se constata pelos seus
comentários referidos nos questionários e nos encontros mensais:

-“(...) assim, sentia-me à vontade para perguntar quantas vezes fossem necessárias,
nas aulas os meus colegas acham que eu não percebo nada por estar constantemente a
fazer perguntas.” (Ent., aluno M de Lab. II, 22/11/2007)

-“Deste modo é mais é mais interessante... pois os colegas não criticam as nossas
dúvidas.” (QuestInt.)

Apesar de os alunos estarem a trabalhar em grupos de dois alunos, cada um deles


tem um avatar que o representa no mundo virtual e com o qual trabalha em
colaboração com o colega no desenvolvimento do projecto. Assim, a professora
conseguiu aperceber-se das dificuldades de cada aluno e prestar o devido apoio.
Desta forma, o objectivo de se empregar nas aulas uma pedagogia diferenciada foi
alcançado.

7.10.1. Professora

Devido à natureza desta comunicação repartida, em que a professora teve de dividir


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

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

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

Janela com a comunicação, pelo


canal privado, entre a professora
e cada um dos alunos,
Janela com o código de um aluno que identificados pelo nome do
a professora estava a analisar. avatar.

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

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

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

Participantes Constatações

Agrado por se comentar por escrito os erros cometidos, evitou a sua


repetição;

Dificuldades em perceber se a execução do projecto estava correcta;


Lab. II
Dificuldades em saber o que faltava implementarem do projecto;

Desagrado pelo projecto que tiveram de desenvolver e consequente


desmotivação dos alunos.

Agrado por se comentar por escrito os erros cometidos, evitou a sua


repetição;
Proj. I

Agrado por aprenderem neste ambiente e pelo projecto que desenvolveram.

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


alunos;
Professora
Dificuldade em acompanhar o desenvolvimento do trabalho fora das aulas
semanais.

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

7.10.2. Questionários

No que respeita aos questionários realizados neste semestre, ao primeiro e ao


segundo responderam a totalidade dos alunos (16) que participaram. No último
questionário responderam 6 da ESTG e 6 de Lab. II. Da análise feita aos
questionários e das reuniões tidas com os alunos, salientam-se os seguintes aspectos:

 Método de ensino usado – ambos os grupos de alunos consideraram que os


exemplos dados para testarem e alterarem os ajudaram a compreender
melhor alguns conceitos, como a troca de mensagens entre objectos. As
funções e alguns exemplos práticos da linguagem LSL em português foram
uma boa ajuda na compreensão das mesmas. Os alunos da ESTG referiram
que eles próprios depois de pesquisaram na Internet exemplos de programas

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

em LSL que testaram e adaptaram ao problema proposto, tornou-lhes mais


fácil a compreensão e assimilação dos conceitos abordados. Os alunos
também foram unânimes ao afirmar que durante as aulas tiveram toda a ajuda
que necessitavam da parte da professora. Dois alunos de Lab. II inclusive
salientaram que foi essa mesma ajuda e empenho que os fez chegar ao fim do
projecto, uma vez que tinham vontade de desistir a par dos seus colegas.

 Projecto proposto – os alunos de Lab. II foram unânimes ao dizer que o


enunciado era extenso, tinha muitas componentes interligadas e que não
percebiam como é que as iam implementar. Referiram também que o
enunciado era explícito, tendo sido capazes de conceber o algoritmo. No
entanto, a codificação tornou-se mais complexa, pois os alunos não
entenderam o que o programa estava a fazer, nem perceberam como
interligar a informação. Mencionaram, ainda, que não compreendiam a razão
de lhes ter sido atribuído um projecto em que grande parte do trabalho
consistia na manipulação de dados, ao contrário dos seus colegas, que fizeram
um projecto completamente diferente. Os alunos salientaram que este tipo de
projecto não se adequava a este ambiente virtual e que na opinião deles foi
uma perda de tempo, manifestando ter sido preferível realizá-lo no
compilador normal como os seus colegas de turma.

Nas respostas dadas notou-se a frustração destes alunos, pelo facto de se


terem voluntariado na expectativa que também fossem criar objectos
interessantes e terem sucesso como o seu colega. Tal não aconteceu, em parte
por terem ficado bloqueados pelo enunciado do trabalho proposto, que não
lhes despertou interesse. Como refere Schmidt e Moust (2001), o enunciado
do problema deve estimular a discussão, este influencia o tempo e o interesse
que o aluno mostra pelo assunto que está a estudar. Os mesmos autores
salientam, ainda, que um “mau” enunciado prejudica a aprendizagem dos
alunos.

Os alunos de Proj. I consideraram que o enunciado do projecto era claro,


embora as alterações efectuadas o tornassem um pouco mais difícil. Contudo,
manifestaram o agrado pelo seu desenvolvimento e mencionaram ter sido
interessante aprender a programar no SL. O enunciado e o SL motivaram-
nos na procura de soluções para implementarem o projecto na sua totalidade.

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

 Aprendizagem no SL – para a maioria dos alunos este foi o primeiro contacto


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

 Comentário geral sobre a actividade – os alunos não fizeram grandes


comentários, salientando-se apenas um aluno de Lab. II que referiu não ter
gostado e que estava arrependido de ter participado.

7.11. Plano do 3.º ciclo de investigação-acção

Este ciclo teve início no segundo semestre do ano lectivo 2007/2008. 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.

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

 Projecto – considerando o comportamento dos alunos face ao tipo de


enunciado que desenvolveram no ciclo de IA anterior, nomeadamente o
facto de os alunos com um projecto com uma componente fortemente visual
apresentarem uma atitude positiva. Neste ciclo pretendeu-se propor um
projecto (ver enunciado no anexo III) que fosse “rico” o suficiente, de forma
a despertar nos alunos o interesse e motivação necessários para o quererem
concluir e aprender. Assim, o enunciado proposto consistiu no
desenvolvimento de uma pista para circulação de automóveis, com
cruzamentos e semáforos. A pista deveria ser constituída por blocos
independentes para que em qualquer momento fosse possível alterar o seu
formato. Os automóveis deviam circular somente dentro da pista, devendo
ser abastecidos com combustível, pois à medida que fossem circulando o
combustível diminuía. Era da responsabilidade do condutor (neste caso o
dono do veiculo) garantir que o veículo não parasse na pista por falta de
combustível. Se tal sucedesse o dono teria de pagar uma coima por desleixo.
Este projecto teve por objectivo que os alunos aprendessem a:

o Manipular as estruturas de dados;

o Trocar informação entre objectos;

o Manipular estruturas de controlo;

o Estruturar o código;

o Desenvolver e aplicar funções, implementadas pelos alunos assim


como as pré-definidas da linguagem.

Para além de os alunos se focarem nestas técnicas base, pretendeu-se


igualmente ampliar a complexidade das técnicas a dominar por estes,
nomeadamente, o lançamento de respostas a eventos.

 Comunicação – manteve-se a mesma metodologia usada nos dois últimos


ciclos. Contudo, devido ao facto de a professora não conseguir dar uma
resposta em tempo útil a todos os alunos, considerou-se necessário adicionar
pequenas frases previamente escritas para as situações mais frequentes, de
modo que a professora pudesse copiar e usar sempre que fossem necessárias,
pretendendo-se desta forma diminuir o tempo de resposta e servir de auxílio
no seu trabalho durante as aulas.

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

 Procedimento durante as aulas – prosseguiu-se com a mesma abordagem do


ciclo anterior, escrevendo-se comentários no código dos alunos, sempre que
se considerasse necessário, bem como a disponibilização em português das
funções mais utilizadas. Devido às dificuldades sentidas pelos alunos em
compreender como funciona o editor do SL, considerou-se ser mais
adequado que esta explicação fosse dada presencialmente. Deste modo, a
primeira aula na qual se explica o editor do SL foi presencial, na UTAD. Nas
aulas seguintes utilizou-se a metodologia problem-based learning, aplicada a
pequenos grupos de tutoria. Assim, os alunos formaram grupos de dois, para
discutirem entre eles o projecto, de forma a apresentarem à professora, na 3ª
semana, um relatório no qual expunham quais os problemas que estes
continham e como pensavam resolvê-los. Na aula seguinte, a professora
discutiu em conjunto com os alunos os pontos fortes e fracos de todas as
soluções apresentadas. Doravante, os alunos colaboram entre si no
desenvolvimento do projecto. O papel do professor deve ser o de incentivar
os alunos a esclarecer as suas ideias, a procurar soluções para os problemas, a
reflectir nas soluções apresentadas, a procurar incoerências e a encontrar
soluções alternativas. O plano das aulas encontra-se no anexo II. Também se
disponibilizaram objectos com exemplos de programas para os alunos
exercitarem e adaptarem.

A investigadora considerou pertinente, para esta investigação, a comparação dos


resultados obtidos com os recolhidos por outro professor, que seguisse a mesma
metodologia. Desta forma, pôde eliminar dos dados a variável “investigadora X” e
colher dados independentes dela. Para tal, neste ciclo outro professor de
programação da ESTG ficou responsável por leccionar as aulas de uma turma. Estas
aulas decorreram em dias diferentes, embora tivesse sido utilizado o mesmo espaço
no SL. Este estudo paralelo constituiu o 4.º ciclo da IA.

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

7.12. Resultados e reflexões do 3.º e 4.º ciclos de


investigação-acção

A presença da professora-investigadora na primeira aula, em que se explicou e


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

Figura 7.14: Imagem de um dos trabalhos desenvolvidos.

Após os alunos terem entregue o algoritmo do trabalho, reuniram-se juntamente com


a professora para conversarem sobre as soluções apresentadas para cada um dos

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

problemas identificados (Figura 7.15). Durante esta reunião, para cada um dos
problemas que os alunos identificaram, a professora expôs as soluções apresentadas
que foram examinadas e discutidas pelo grupo. A professora pediu aos alunos que
esclarecessem as suas ideias, encorajando-os a pensarem sobre o assunto, a
procurarem incoerências e a encontrarem alternativas. Para algumas questões
levantadas, por exemplo, “como é que os carros seguem a pista?”, o grupo não foi capaz de
encontrar uma resposta satisfatória para o problema. Contudo, esta discussão 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.

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

Do ponto de vista da professora, esta troca de ideias ajudou os alunos a tomar


consciência do trabalho que tinham de desenvolver e também dos conceitos a
absorver. Os alunos corroboraram desta opinião como se constata dos seguintes
comentários:

-“(...) esta discussão ajudou-me a compreender o que eu tinha de errado no meu


algoritmo e alguns aspectos que não tinha considerado...” (Ent., aluno A de Lab I,
dia 23/05/2008)

-“(...) foi bastante importante estarmos a discutir o projecto em conjunto pois pudemos
esclarecer as nossas dúvidas.” (Reg., aluno W de Lab I, dia 30/05/2008)

-“(...) foi a primeira vez que participei numa discussão assim, ajudou-me a
compreender o que tinha de fazer e estudar...noutras disciplinas devia-se fazer o
mesmo.” (Enc., Aluno B de Lab I, dia 23/05/2008)

No decorrer das aulas observou-se isso mesmo, os alunos tinham a noção do que
tinham que fazer, discutiam entre si qual seria a melhor solução e apresentavam à
professora algumas soluções já implementadas, para esta testar e verificar a sua
exequibilidade. A metodologia PBL ajudou os alunos a compreender os objectivos
do projecto desde o início e a estruturar as suas ideias, evitando assim incoerências e
equívocos ao longo do seu desenvolvimento. Estes resultados também são
corroborados por O’Kelly e Gibson (2006).

Os conceitos de programação foram sendo introduzidos à medida que os alunos


necessitavam deles para fazer o trabalho. Com esta metodologia conseguiu-se criar
uma dinâmica de trabalho, de colaboração e empenho entre os alunos na resolução
dos problemas, o que não se tinha observado nos anteriores colegas (1.º e 2.º ciclos
de IA). Este facto também foi confirmado pelos professores de outras disciplinas, ao
constatarem “que os alunos passam o tempo a falar do trabalho que estão a desenvolver no SL”.

No decorrer das aulas, observou-se uma diminuição dos pedidos de ajuda em relação
aos erros de compilação à medida que estes iam ocorrendo, devido ao facto de a
professora comentar no código, o porquê do erro, o que induziu os alunos a
conseguirem corrigi-los, como se constata pelos seus comentários:

-“Quando tinha um erro eu ia ver o que a professora me tinha escrito e assim consegui
corrigir alguns (...).” (Reg., aluno W de Lab. I, dia 20/06/2008)

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

-“(...) sempre que me surgia um erro de compilação, eu ia ver o que a professora me


tinha escrito e conseguia corrigi-lo, assim foi mas fácil.” (Ent., aluno S de Lab. I, dia
27/06/2008)

Por outro lado, os erros de execução tornaram-se mais frequentes, não por não
saberem usar as funções do SL, como se verificou nos ciclos anteriores, mas por
implementarem soluções que não tinham em consideração todas as vertentes do
problema. Um dos casos mais frequentes foi esquecerem-se de que a pista podia ter
cruzamentos, pelo que o carro em vez de seguir em frente virava. Quando isto
acontecia, os alunos tentavam de antemão resolver o problema sozinhos, só
recorrendo à ajuda da professora após várias tentativas mal-sucedidas. Este
comportamento vem ao encontro do que Williams e Noyes (2007) referem em
relação ao papel da visualização no ensino:

“Computer-based representation has the potential to play a vital role in the


development of problem solving abilities.”

Um outro factor a realçar, apesar de os alunos no espaço da sala estarem muito


distanciados uns dos outros, devido à natureza do projecto que estavam a
desenvolver, foi que a professora não teve de se deslocar constantemente para saber
quais eram as suas dúvidas, nem para as esclarecer, o que ajudou a manter a dinâmica
da aula. Tudo isto tornou-se possível devido ao processo de comunicação adoptado.
A utilização do canal privado para tirar dúvidas, juntamente com o facto de a
professora ter um conjunto de frases previamente preparadas das situações mais
frequentes, evitou que os alunos estivessem sem resposta às suas questões ou quando
não era possível, devido a complexidade da pergunta, era-lhes indicado que tinham
que aguardar um pouco. Para a professora, esta metodologia usada durante as aulas
aliviou a fadiga registada no ciclo antecedente, embora a preparação da aula levasse
mais tempo, pois para além da preparação normal de cada aula, tinha de prever quais
as dificuldades que iriam surgir em cada etapa do trabalho, para assim escrever
pequenas frases para serem usadas.

No que concerne ao acompanhamento dos alunos fora das aulas semanais, este
grupo, tal como o antecessor, preferia enviar mensagens à professora através do SL
ou marcar uma hora para tirar dúvidas. A professora sempre que queria deixar no
espaço da aula algumas mensagens aos alunos, por exemplo, a relembrar o que

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

deviam estudar para a aula seguinte, criou um objecto na forma de cogumelo com a
mensagem escrita por cima (Figura 7.16).

Deixem a sala limpa Trabalho de casa


Devem recolher os vossos objectos no Para a próxima aula devem completar,
fim da aula ler e guardar os dados dos fornecedores

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

As observações feitas directamente pela professora-investigadora durante o 3.º ciclo


de IA foram coincidentes com as do professor que leccionou no SL (4.º ciclo de IA),
sob a orientação da investigadora. Este professor fez o seguinte comentário em
relação à metodologia adoptada:

“Com esta metodologia os alunos têm consciência do que têm de desenvolver no


projecto. A discussão em grupo foi importante para eles poderem esclarecer as suas
dúvidas e interiorizarem o que estava errado e o porquê. Considero que é uma
metodologia apropriada para os alunos aprenderem a programar.”

Na Tabela 7.7 apresenta um resumo das observações destes dois ciclos de IA.

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

Participantes Constatações

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


na sua utilização;

Agrado por se comentar por escrito os erros cometidos, evitou a sua


repetição;

Lab. I
Agrado pela metodologia utilizada, nomeadamente a discussão em grupo do
projecto;

Agrado pelo enunciado do projecto.

Empenho dos alunos na resolução do projecto.

Dificuldade em acompanhar o desenvolvimento do trabalho fora das aulas


Professora
semanais.

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

7.12.1. Questionários

Relativamente aos questionários efectuados nesta actividade, responderam a


totalidade dos alunos que participaram aos três inquéritos. Nas respostas aos
inquéritos efectuados e nas reuniões mensais os alunos mencionaram:

 Método de ensino usado – a discussão em grupo sobre o trabalho foi muito


importante porque ajudou a ver o que estava errado no algoritmo, a
compreender melhor o enunciado e a ter uma visão global do mesmo. Evitou
que tivessem implementado o trabalho de forma errada, tal como acontece
muitas vezes em outros trabalhos, em que só se apercebem do erro depois do
trabalho ter sido entregue.

 Projecto proposto – os alunos consideraram o projecto aliciante, gostaram de


o implementar, embora fosse difícil porque tinha muitas componentes a
interagir entre si. A generalidade dos alunos considerou que a parte mais

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

difícil do projecto consistiu em colocar os carros a circular na pista e a


implementar o sistema de coimas para os donos.

 Aprendizagem no SL – na generalidade, os alunos manifestaram o seu


contentamento em aprender num ambiente aliciante, tal como o SL. Outros
consideraram que, por exemplo, para aprender programação avançada, o SL
não é apropriado.

 Comentário geral sobre actividade – só quatro alunos fizeram um


comentário, referindo que gostaram da actividade e da forma como decorreu.

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

Com a maioria dos problemas resolvidos em relação ao processo de ensino e


aprendizagem da programação no SL, a investigadora deu por terminado este
processo. Ficou por resolver a questão do acompanhamento dos alunos fora das
aulas semanais. Uma possível solução para este problema seria a integração do SL
com um sistema de gestão da aprendizagem, como proposto por Antunes et al.
(2008), na medida em que este acompanha e grava o trabalho autónomo do alunos
para posteriormente o professor poder observar. Assim, o professor tem a
possibilidade de perceber o que o aluno fez, de forma a poder ajudá-lo melhor.

Finda a apresentação do processo de investigação seguido, no próximo capítulo 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.

189
8. Análise dos resultados

No presente capítulo faz-se uma análise dos resultados da investigação-acção,


relacionando-os com a literatura científica existente.
Capítulo VIII: Análise dos Resultados

191
Capítulo VIII: Análise dos Resultados

8.1. Análise e discussão dos resultados

Como já foi referido anteriormente, o objectivo desta tese foi analisar como os
mundos virtuais, com características semelhantes ao SL, poderiam ser utilizados
como plataforma para o ensino e aprendizagem da programação.

No capítulo VII descreveu-se a actividade preliminar e a subsequente IA que


permitiu uma melhor compreensão do problema, e a obtenção do conhecimento que
possibilitou gerar uma proposta de um modelo para o ensino / aprendizagem da
programação nos mundos virtuais. Os resultados deste estudo relevam que o SL
apresenta características que suportam uma aprendizagem construtivista da
programação, mas tem restrições que podem deteriorar o seu uso pragmático. O foco
desta investigação centra-se em descortinar como usar o mundo virtual no ensino da
programação e não na sua eficácia relativamente aos resultados obtidos pelos alunos.
Por conseguinte, os resultados desta investigação não pretendem ser uma receita de
como os mundos virtuais devem ser usados, mas sim servir de guia e ponto de
partida a futuras investigações.

Ao longo deste estudo foram identificados os seguintes itens considerados


fundamentais na autenticação do SL como plataforma para o ensino / aprendizagem
da programação:

 métodos de comunicação;

 projecto;

 processo de aprendizagem;

 processo de ensino.

De seguida, faz-se uma análise de cada um destes elementos, relacionando-os com a


literatura científica existente.

8.1.1. Comunicação

Na educação online, os elementos fundamentais para o êxito dos alunos são as


interacções: aluno-aluno, professor-aluno(s) e a colaboração na aprendizagem
resultante dessas interacções (Palloff e Pratt, 2005). Assim, pode-se considerar que os

192
Capítulo VIII: Análise dos Resultados

termos colaboração e interacção são palavras-chave sobre as quais se deve reflectir


quando se pretende promover a construção de conhecimento apoiada por ambientes
de aprendizagem online (Dias, 2004; Miranda, Morais e Dias, 2007).

A palavra comunicação deriva do latim communicare, tal como “comungar”,


significando “dividir/partilhar alguma coisa com alguém”. Desde os primórdios que
a comunicação é um instrumento de integração, instrução, troca mútua e
desenvolvimento entre pessoas. Por isso, uma boa comunicação é essencial para
qualquer profissional. No contexto educacional, a comunicação apresenta-se como
elemento chave no planeamento, execução e avaliação de todo o processo
ensino / aprendizagem, isto é, a gestão da comunicação é parte integrante da gestão
de projectos educacionais, principalmente na modalidade à distância (Reis, 2008).

A primeira abordagem usada nesta investigação, referente à comunicação, que se


limitou a utilizar o canal público durante as aulas, rapidamente foi abandonada.
Conforme foi descrito no capítulo anterior, na secção7.6, constatou-se por parte de
todos os intervenientes (professora e alunos), a existência de muito ruído,
nomeadamente os alunos a trocar ideias entre si e os objectos a enviar mensagens
para o seu proprietário. Por estes motivos, nem sempre se conseguiu estabelecer uma
boa comunicação entre os vários participantes. Era difícil aos alunos seguir a linha de
raciocínio da professora e, por outro lado, frequentemente, a professora não se
apercebia dos seus pedidos de ajuda.

Após a constatação de que assim seria difícil utilizar o SL, optou-se por realizar a
análise fazendo-se a seguinte atribuição de funções dos canais público e privado:

 o canal público passou a ser utilizado apenas para a professora se dirigir a


todos os alunos em geral. Por exemplo, para fazer uma chamada de atenção
ou explicar algum conceito;

 o canal privado passou a ser usado exclusivamente para tirar dúvidas aos
alunos individualmente. Nos objectos, usou-se um canal privado específico
direccionado exclusivamente ao seu proprietário.

Deste modo, eliminou-se a perturbação sentida nas aulas e obteve-se um melhor


relacionamento professora-aluno.

O SL, pelo facto de ser um meio informal, directo e rápido, cria condições para os
alunos não se sentirem embaraçados pela presença dos colegas e, mais

193
Capítulo VIII: Análise dos Resultados

extrovertidamente poderem colocar questões e interagir, isto é, concordarem,


discordarem, exporem e tirarem dúvidas sempre que necessitarem. Como a troca de
opiniões é intensa, esta forma de comunicação com os ajustes efectuados,
principalmente no que se refere ao facto de a professora ter um conjunto de frases
pré–escritas, veio a ser um factor precioso na utilização do SL. À professora é dada a
vantagem de melhor gestão da aula através da colocação em discussão pública apenas
das questões mais pertinentes. Aos alunos possibilitou um meio “seguro” de
colocarem as suas dúvidas. Por exemplo, os alunos que reflectem maior timidez
numa sala de aula tradicional manifestaram sentirem-se mais desinibidos neste
ambiente, factor que leva a diferentes atitudes e modos de participação, tal como
Miranda et al. (2007) também constaram no estudo que efectuaram, e se observa nos
seguintes comentários recolhidos nas conversas mensais:

- “Neste ambiente como conversava directamente com a professora sem que os colegas
lessem o que escrevia senti-me muito mais à vontade que na sala de aula, pois nesta,
mesmo que tenha dúvidas, evito falar. Gostei muito...” (Ent., aluno S de LabI do
3.º Ciclo de IA)

- “Aqui, neste ambiente, senti-me completamente à vontade para falar e expor as


minhas dúvidas. Na sala de aula é diferente porque os meus colegas podem rir-se de
mim.” (Ent., aluno 2 de Lab. I, dia 31/05 /2007)

A maioria das opiniões recolhidas permitiu à investigadora concluir que é importante


estabelecer uma comunicação privada entre o professor e os alunos, principalmente
quando se refere ao esclarecimento de dúvidas, uma vez que os alunos podem
desenvolver um sentimento de confiança e segurança dentro do mundo virtual. Na
ausência desta confiança, os alunos sentem-se desconfortáveis e constrangidos em
colocar as suas dúvidas e comentários (Anderson, 2004).

Por outro lado, o facto de a comunicação se efectuar em tempo real permite tornar a
realização das actividades de aprendizagem num processo activo e dinâmico. Um
aspecto importante que mantém este dinamismo está relacionado com a rapidez do
feedback que os alunos recebem da professora. A literatura científica relacionada com
o ensino à distância refere que um rápido feedback é importante para os alunos não se
sentirem sozinhos, sendo também um factor relevante para a sua motivação e
compreensão dos assuntos que estão a estudar (Rekkedal, 1983; Bender, 2003;
Haythornthwaite, 2006). Neste estudo, esta questão também se colocou, uma vez que

194
Capítulo VIII: Análise dos Resultados

nem sempre a professora conseguia dar uma resposta suficientemente rápida a todas
as solicitações que recebia. Consequentemente, os alunos dispersavam-se e
começavam a conversar, como se pode observar pelos seguintes comentários
referidos nas conversas mensais:

- “Como a professora não dizia nada, eu começava a conversar com o meu colega.”
(Ent., aluno 2 de Lab. I, dia 31/05 /2007)

- “(...) às vezes, acontecia que a professora demorava algum tempo a dar uma resposta
e como não sabia se a rede tinha ido abaixo, perguntava através do canal público se a
professora ainda ali estava.” (Ent., aluno 2 de Lab. II, dia 3/07 /2007)

Como advoga Sobral (2008):

“Se um aluno colocar uma questão, houver uma discussão ou alguma alteração ao
funcionamento “normal”, o professor tem que ter uma resposta rápida. O professor
tem que estar presente e os alunos necessitam do sinal de acompanhamento caso
contrário a comunidade perderá a referência e sentir-se-á perdida”.(p. 23)

A solução encontrada pela investigadora consistiu em construir uma série de frases já


pré-definidas e preparadas, para poder copiar e colar no chat. Assim, sempre que
alguém lhe colocava uma questão e não podia responder imediatamente, recorria a
uma dessas frases, como por exemplo, “ tem de esperar um minuto, estou a falar com o seu
colega” ou para as situações de erro mais frequentes: “falta iniciar a variável”. De um
modo geral, o sentimento que os alunos expressaram em relação à comunicação foi
de agrado, como se verifica nas seguintes expressões retiradas dos questionários e das
conversas mensais: “gostei muito”, “...senti-me completamente à vontade ...”.

8.1.2. Projecto

A natureza do problema proposto aos alunos desempenha um papel importante na


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

195
Capítulo VIII: Análise dos Resultados

Neste estudo, o projecto foi o ponto de partida para o processo de aprendizagem da


programação. No decorrer do estudo foram utilizados dois tipos de projectos com
características bastante diferenciadas:

 Visual – os alunos aprendem a programar através de interacções “físicas”.


Estes projectos envolvem a construção de vários objectos tridimensionais,
como um robot ou um carro, e a implementação de vários programas que
simula o comportamento que esses objectos deveriam ter.

 Não visual – os alunos aprendem a programar, apenas no processamento de


informação textual. Nestes projectos, a comunicação com os objectos é feita
textualmente, os objectos recebem ordens textuais dos avatares e respondem
do mesmo modo ou guardam a informação em listas de strings.

No decorrer desta investigação, foram observados e registados diferentes tipos de


comportamento nos alunos, em relação ao enunciado do projecto. No projecto
visual, alguns alunos não se empenharam, como era de esperar, por concluir com
êxito o enunciado proposto, como foi o caso dos alunos de Lab. I da actividade
preliminar. Apesar de considerarem o projecto acessível e interessante não se
empenharam o suficiente, como se pode notar nos seguintes comentários referidos
nos questionários:

-“(...) achei o projecto bastante engraçado e fácil. Gostei de ver o comportamento do


meu cão, que nem sempre obedecia ao seu dono, mas não dediquei muito tempo a
fazê-lo, pois tinha outras disciplinas para fazer.” (Ent., aluno 2 de Lab. I, dia
31/05 /2007)

-“(...) gostei do projecto, mas não dediquei muito tempo para o desenvolver , porque
tinha outras disciplinas para fazer. Como achei o projecto fácil pensei que no fim o
fazia rapidamente, mas depois não tive tempo para o acabar.” Ent., aluno 1 de
Lab I, dia 12/07/2007)

Por outro lado, um outro grupo de alunos de Lab. I (3.º e 4.º ciclos) e da ESTG, com
um projecto visual mais complexo que exigia, também, a manipulação de dados não
visuais, apresentaram um comportamento oposto em relação aos seus outros colegas
de Lab. I. Gostaram do projecto e empenharam-se na sua concretização. O mesmo
tipo de comportamento foi constatado relativamente aos alunos de Lab. III com um
projecto visual, no entanto com um grau de dificuldade superior. Este tipo de

196
Capítulo VIII: Análise dos Resultados

comportamento observado vem ao encontro do que Allan e Tomlinson (2002)


referem:

“É necessário que as tarefas tenham o grau adequado de dificuldade para serem e


permanecerem motivadoras: as tarefas que são demasiado fáceis tornam-se aborrecidas e
consequentemente os alunos não se empenham na sua resolução; as tarefas que são
demasiado difíceis provocam frustração.”

Os alunos que aprenderam a programar, usando apenas um projecto não visual,


evidenciaram um comportamento de frustração e desinteresse pelo que estavam a
aprender. Os alunos não aprenderam adequadamente e “sufocaram” por não
compreenderem a razão de terem que desenvolver um projecto com estas
características neste ambiente, como é visível nos seus comentários mencionados nas
conversas mensais e durante as aulas:

- “(...) Não gosto deste projecto, não percebo o que tenho de fazer e como? Isto é complicado e
difícil. Não entendo porque tenho de fazer este projecto, os nossos colegas não fizeram nada
disto (...)”.(Ent., aluno S de Lab II, dia 25/10/2007)

-“(...) Isto não tem nada de engraçado… é só texto, se soubesse que ia ser assim não
tinha feito este trabalho.” (Ent., aluno J de Lab. II, 22/11/2007)

Uma das justificações encontradas para este tipo de comportamento foi dada por
Howard (1994) e Jensen (1998) que, nos estudos que efectuaram sobre a actividade
cerebral, explicam que a aprendizagem ocorre quando o aluno não se sente
aborrecido, frustrado, ansioso e quando não é sobrestimado, nem subestimado. Por
outro lado, segundo Pereira (2007), o conhecimento é uma relação activa entre o
aprendiz e o ambiente, e a aprendizagem ocorre quando o estudante se envolve
activamente com o contexto instrucional, que deve ser complexo e realista. Este
autor refere ainda que o aprendiz deve ser exposto à situação o mais realisticamente
possível, sem exclusão das complexidades do contexto.

Estes alunos beneficiaram do ambiente do SL apenas para reforçar o contexto da


aprendizagem e não como uma fonte visual de feedback (Prensky 2001; Roubidoux et
al., 2002) na execução dos programas, como sucedeu com os seus colegas. Não é
habitual para um aluno assumir que o seu script está correcto apenas porque este
aparentemente mostra dados textuais certos. Com um projecto visual, os alunos têm
um feedback óbvio quanto à exactidão do seu projecto, basta olhar para o
comportamento do seu objecto; por exemplo, o carro deve seguir a pista, se não o

197
Capítulo VIII: Análise dos Resultados

fizer está errado. O comportamento errado do carro ou do robô era motivo de uma
maior preocupação por parte dos alunos, impulsionando-os a procurarem uma
solução para o problema. A professora para motivar os alunos introduziu, a meio do
desenvolvimento do projecto, uma componente visual. Contudo, esta medida não foi
suficiente para alterar o comportamento dos alunos. Como Duch (2001) refere,
problemas eficazes devem despertar nos alunos o interesse e a motivação para
investigarem e procurarem compreender os conceitos que estão a ser introduzidos.

Um outro ponto a realçar deste estudo é que, quando foi apresentado aos alunos um
projecto com um misto das duas componentes visuais e não visuais, ou seja, um
enunciado com uma grande componente visual juntamente com manipulação de
dados não visuais, a reacção destes foi idêntica aos alunos com projecto visual, como
foi o caso dos alunos de Lab. I (3.º e 4.º ciclos) e da ESTG. Estes resultados vêm ao
encontro do que se refere na literatura sobre os benefícios da visualização, como é o
caso de certos aspectos da resolução de problemas nos alunos inexperientes, uma vez
que os ajuda a terem um melhor entendimento do problema, bem como o nível de
envolvimento e motivação que eles desenvolvem ao construírem e representarem as
suas próprias visualizações (Naps, 2005; van Dam, 2005; Kiili, 2005; Schweitzer e
Brown, 2009; Myller et al., 2009).

Aprender exige tanto brincar com as ideias como a dureza de redefinir e reformular
ideias sendo ambas as partes complementares e necessárias para a aprendizagem
(Barret, 2005). A diversão “transpirada” é o que Papert (1996) designou de “hard fun”;
in that it is both challenging and interesting, and this implies “hard”.

8.1.3. Processo de aprendizagem

8.1.3.1. Dificuldades dos alunos

Na aprendizagem, em geral, o erro é necessário para o aperfeiçoamento do processo


evolutivo do pensamento (Pereira, 2007). Em particular, na aprendizagem da
programação um aspecto importante é a reacção dos alunos aos erros de compilação
e execução (Esteves e Mendes, 2004, Lahtinen et al., 2005), que são inevitáveis no
processo de aprendizagem.

198
Capítulo VIII: Análise dos Resultados

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

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

A metodologia adoptada pela professora, no que se refere aos erros de compilação,


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

199
Capítulo VIII: Análise dos Resultados

do porquê e de como podiam evitá-lo e corrigi-lo. Miranda (2005), no estudo que


efectuou sobre a educação online, também corrobora este aspecto de existir uma
explicação escrita que pode ser consultada sempre que necessário, ajudando os
alunos a reflectirem e a relembrarem-se dos problemas.

Relativamente aos erros de execução, a primeira dificuldade observada relacionou-se


com a utilização das funções do LSL. Após várias iterações, verificou-se que a
principal dificuldade dos alunos residia na incompreensão da língua inglesa, pelo que
foi necessário traduzir para português as funções mais utilizadas. Outra dificuldade
que resultou em vários erros de execução, refere-se à compreensão do enunciado do
problema e consequentemente ao desenvolvimento do respectivo algoritmo. A
maioria dos alunos, apesar de ter feito o algoritmo antes de implementar o projecto,
não compreendeu o enunciado. Esta dificuldade complicou a estruturação do seu
pensamento. O facto de não perceberem o que tinham que fazer, levou-os a
perguntar constantemente “o que é para fazer a seguir?”, “o que me falta implementar?”.

A adopção da metodologia PBL veio minorar este problema. Com esta metodologia
os alunos desenvolveram o algoritmo e após a sua entrega à professora debateram
todos em grupo as soluções apresentadas. Este esforço colaborativo, onde os alunos
se entre ajudam na clarificação das suas questões, é o ponto central desta
metodologia (O'Kelly e Gibson, 2006). Como referem Schmidt e Moust (2001), o
conhecimento de um participante vai activar o conhecimento inacessível de outro.
Assim, o conhecimento colectivo torna-se acessível, os aprendizes começam por
trabalhar sobre o que sabem e a estabelecer pontes entre o seu conhecimento e o
problema em questão, porque alunos diferentes tendem a saber coisas diferentes ou a
pensar de outra maneira. Uma construção teórica torna-se um efeito colaborativo
que pode trazer novas luzes que não estão presentes nos participantes
individualmente antes de se começar a análise do problema em grupo (ibid.). Os
alunos que participaram neste estudo vieram a comprovar estes mesmos aspectos,
como se pode observar pelos comentários que fizeram nos encontros mensais e no
questionário:

- “(...) esta discussão em grupo foi muito útil, pois permitiu-me ver o que não tínha
feito no meu algoritmo e, por outro lado, verifiquei que tínha algumas coisas erradas.”
(Reg., aluno W de Lab I, dia 20/06/2008)

200
Capítulo VIII: Análise dos Resultados

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

Diversos autores argumentam que o diálogo e a discussão promovem a colaboração


e consequentemente apoiam a negociação social da aprendizagem (Vygotsky, 1978;
Lave e Wenger, 1991; Jonassen, 1999; Bourne, Harris e Mayadas, 2005). O
acrescentar de novas ideias para a discussão sem excluir ideias anteriores, salientando
que as conversações encorajam a diversidade, cria um ambiente fértil no qual novos
níveis de compreensão podem ser desenvolvidos, conduz a uma mudança conjunta
dos intervenientes e à criação de um conjunto rico de informação que sustenta o
ambiente no qual as experiências são emergentes (Bourne, Harris e Mayadas, 2005).

Por outro lado, as discussões online constituem uma oportunidade para os professores
orientarem experiências de aprendizagem, de acordo com o paradigma de
aprendizagem social e colaborativa, nas quais os alunos podem partilhar perspectivas
e as suas próprias experiências, construindo conhecimento através dos significados
partilhados (Tan, Wang, e Xiao, 2010). Neste sentido, Larkin-Hein (2001) salienta
que as discussões funcionam como um veículo adicional de ensino e de
aprendizagem, que facilita aos alunos a aquisição de capacidades de pensamento de
nível mais elevado e os torna mais competentes para transferirem e utilizarem a
informação em novas situações.

Com esta abordagem, os alunos conseguiram compreender melhor o projecto


proposto. As dúvidas que os seus colegas tiveram, “o que ainda me falta fazer?”, não se
registaram ao longo do decorrer da experiência. Para esta metodologia ser eficaz é
necessário também que o enunciado do problema, como foi referido na secção
anterior, desperte nos alunos o interesse e a motivação pela aprendizagem dos
conceitos que estão a ser introduzidos. Como referem O’Kelly e Gibson (2006), a
utilização da metodologia PBL favorece uma compreensão profunda dos conceitos
em vez de uma aprendizagem superficial, porque são os alunos que estão activamente
a desenvolver.

Um outro aspecto positivo salientado pela generalidade dos alunos que participaram
nos vários ciclos deste estudo, quer os de nível mais avançado, quer os elementares,
refere-se aos pequenos exemplos que a professora empregou durante as aulas para

201
Capítulo VIII: Análise dos Resultados

explicar os conceitos, como se pode constatar pelos seguintes comentários dos


alunos referidos nos encontros mensais e nos questionários:

-“(...)assim com estes exemplos é mais fácil perceber para que servem as estruturas de
repetição e como funcionam.” (Ent., aluno R de Proj. I, dia 28/11/2007)

-“(...)com os exemplos percebemos melhor e podemos alterá-los e adaptá-los ao nosso


projecto.” (Ent., aluno 1 de Lab I, dia 12/07/2007);

-“(...)os exemplos são uma grande ajuda, já andámos na net à procura de mais, assim
é mais fácil de ver como isto funciona.” (Ent., aluno S de Lab II, dia
5/06/2007)

Uma das dificuldades relatadas na literatura é que os alunos muitas vezes


compreendem a sintaxe e a semântica da linguagem ou de partes da linguagem, como
por exemplo as estruturas de decisão, mas não sabem como aplicá-la nem para que
serve (Perkins et al., 1988; Jenkins, 2002; Gomes et al., 2008). Deste modo, 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).

202
Capítulo VIII: Análise dos Resultados

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

203
Capítulo VIII: Análise dos Resultados

default{

state_entry(){
//escuta o que se passa no canal zero
//quando ouve o dono do objecto executa o listen
llListen(0,"",llGetOwner(),"");

}//fim do state_entry

//-------Executa as ordens enviadas pelo dono do objecto--------


//-------que podem ser: subir; descer;rodar;stop;---------------
//-------o stop- faz com que o objecto pare de rodar------------

listen(integer channel, string name, key id, string msg){

if(msg == "subir")
llSetPos(llGetPos() + <0,0,2>);
else if(msg == "descer")
llSetPos(llGetPos() + <0,0,-2>);
else if(msg == "rodar")
llTargetOmega( < 0, 1, 1 >, .2 * PI, 1.0 );
else if(msg =="stop")
llTargetOmega(<0,0,0>, 0,0);

}//fim do listen

}//fim do script

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

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

Uma das questões colocadas no inquérito efectuado no início das actividades, 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)

204
Capítulo VIII: Análise dos Resultados

-“Pode ser que desta forma consiga fazer está disciplina(Lab. I) porque estou no 3º ano e
quero acabar o curso.” (Reg., aluno B de Lab. II, dia 29/10/2007)

-“Eu não gosto de programar, mas gosto de jogar e como o SL é um mundo virtual e eu gosto
deste tipo de ambientes, vim experimentar. Os meus colegas dizem que gostaram.” (Ent.,
aluno S de Lab II, dia 25/10/2007)

Estes comentários revelam alguma insatisfação pela forma como os alunos


aprendem a programar, tal como Lethbridge (2007) refere:

“The number of students in computing disciplines have decreased in U.S. since 2000,
and points out some reasons for that such as: young people are so immersed in
computers that they do not see the excitement to them any more and the stereotype of
the ‘nerd’ coding all night with no social contact, leave the students avoid these areas.”

No SL observou-se o oposto, os alunos não estão sem contacto social quando


programam e gostam de o fazer, na generalidade. Duas situações tiveram um impacto
positivo nos alunos: um dos alunos recebeu uma proposta de outro avatar no SL para
comprar um dos seus objectos, que tinha programado; outro aluno recebeu uma
proposta de trabalho profissional para desenvolver programas numa empresa que
presta serviços no SL.

8.1.3.3. Avaliação feita pelos alunos ao SL

Para além dos aspectos mencionados anteriormente sobre a opinião dos alunos em
aprenderem no SL e as diferentes metodologias adoptadas ao longo desta
investigação, salienta-se nesta secção outros pontos tidos como importantes por
parte dos alunos. Das várias opiniões manifestadas pelos alunos, constatou-se que
uma das características que foi muito apreciada no SL refere-se ao facto de neste
ambiente poderem colaborar com o colega de grupo no desenvolvimento do
trabalho, sem terem de partilhar o mesmo espaço físico. Uma vez que o SL permite
partilhar o código, os alunos mesmo estando fisicamente distantes, conseguem
trabalhar em conjunto, como eles próprios referiram nos encontros mensais:

-“Aqui já não tenho o problema de ter que estar junto do meu colega para desenvolver
o projecto, principalmente ao fim-de-semana. Como eu sou de Pombal e costumo ir a
casa aos fins-de-semana, encontro-me com o meu colega no SL, usamos phones e
estamos a conversar e a desenvolver o projecto os dois, partilhamos o código e assim

205
Capítulo VIII: Análise dos Resultados

observamos o que um e outro está a fazer.” (Ent., aluno W de Lab I, dia


27/06/2008)

-“(...) um dos problemas que eu tinha em fazer trabalho de grupo era ter tempo para
estar com o meu colega, como trabalho em part-time era difícil. Assim, à noite
encontramo-nos no SL, cada um em sua casa, e trabalhamos no projecto durante a
noite.” (Ent., aluno D de Proj. I, dia 28/11/2007)

Para além deste aspecto, do SL permitir uma colaboração síncrona, também, foi
destacado como positivo o facto de poderem deixar ficar no SL o seu trabalho e
enviar para o colega uma mensagem, via canal privado, sobre o que este devia fazer:

-“(…) algumas vezes o meu colega não podia estar no SL a trabalhar comigo e eu
deixava-lhe recados sobre o que ele tinha de fazer.” (Ent., aluno A de Lab I, dia
27/06/2008)

O feedback instantâneo e um ambiente livre de risco é um convite à exploração,


experimentação e estimulação da curiosidade e da aprendizagem por descoberta
(Gee, 2003; Mitchell e Savill-Smith, 2004, Wagner, 2008; Salmon, 2009). A
importância do feedback visual instantâneo como forma de debug foi um dos aspectos
considerados mais relevantes pelos alunos. Para uma grande parte, o facto de
poderem olhar para o objecto desenvolvido e observarem o seu comportamento,
como por exemplo, se o cão segue o seu dono, sempre que este lhe dava essa ordem
e parava quando recebia a mensagem “stop”, foi um dos aspectos mais apreciados
neste mundo virtual. Por outro lado, consideraram importante poderem programar
objectos virtuais realistas como o carro, o comboio e o cão, sem terem medo de
estragar componentes como aconteceria se estivessem a mexer num robot real, como
se certifica nas seguintes opiniões referidas nos encontros mensais:

-“Gostei muito, principalmente de poder olhar para o meu boneco e ver como este se
comportava. Nos outros ambientes de programação é mais difícil de detectar os erros
de execução... aqui basta olhar.” (Ent., aluno C de Proj. I, dia 28/11/2007)

-“(...) considero este ambiente muito útil para quem está a aprender a programar,
aqui percebe-se para que serve a programação e como funciona. Os erros de execução
são muito simples de detectar basta olhar por exemplo no meu caso, o carro nunca
parava porque não ficava sem gasolina e foi muito fácil de verificar que o programa
não estava correcto.” (Ent., aluno 5 de Lab. I, dia 12/07/2007)

206
Capítulo VIII: Análise dos Resultados

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

Estes aspectos corroboram as conclusões feitas por Dede (1995) sobre os benefícios
dos mundos virtuais:

“…offer many benefits such as provisions for experimentation without real world
repercussions, opportunities to ‘‘learn by doing”…’,

Salientaram, também, a oportunidade que este ambiente lhes proporcionou de


conhecerem e trocarem ideias com pessoas de outros países, com as quais puderam
falar do trabalho que andavam a desenvolver e, inclusive, alguns lhes pediam ajuda
para resolver problemas nos scripts que estavam a implementar, como se constata nos
seus comentários das reuniões mensais:

-“Conheci um holandês que me pediu ajuda para resolver um erro que tinha no seu
script, mas eu não o consegui ajudar.” (Ent., aluno 3 de Lab. I, dia 12/7/2007)

-“(...) estive a falar com um americano sobre o meu trabalho e disse-lhe que tinha
aulas de programação no SL. Ele achou o máximo e disse-me que andava no SL só
por brincadeira, mas que gostava de saber criar coisas.” (Ent., aluno M de Proj. I,
dia 28/11/2007)

-“Fiquei a conhecer muita gente, alguns alugam terrenos só para se poderem encontrar
com os amigos, pois moram longe uns dos outros. Assim, vão brincando e construindo
coisas e pediram-me se eu os (sic) podia ensinar LSL.” (Ent., aluno 5 de Lab. I,
dia 12/07/2007)

Estas considerações feitas pelos alunos vêm ao encontro do que Paulo Dias (2004)
refere:

“A colaboração online é uma das formas de responder, em conjunto, a objectivos de


aprendizagem, de cultivar a interacção e de proporcionar a construção e a utilização do
conhecimento.”

Um dos pontos negativos relatados pelos alunos na sua generalidade, referiu-se ao


facto de a linguagem de programação do SL ser LSL. Os alunos preferiam que a
linguagem fosse uma das que estudam ao longo do curso ou usada na indústria, em
vez de estarem a esforçar-se por aprender outra linguagem, que embora semelhante à
linguagem C não voltaria a ser usada por eles no futuro. Como Jenkins (2002)

207
Capítulo VIII: Análise dos Resultados

advoga, este argumento não é relevante, porque o objectivo de uma linguagem de


introdução à programação como esta, é compreender os conceitos (variáveis,
funções, listas, etc.) e não o estudo da linguagem em si. Contudo, este aspecto
negativo mencionado pelos alunos não é relevante para o comprimento dos
objectivos desta investigação, mas é relevante porque os alunos se sentem afectados.

Salientam-se, ainda, exemplos de opiniões relativas à aprendizagem da programação


no SL, que traduzem o sentimento geral dos alunos que participaram na investigação:

-“Gostei, porque podia ver como o meu cão se comportava e isto ajudou muito”;
(Ent., aluno 4 de Lab I, dia 6/5/2008)

-“ diverti-me imenso”; (Ent., aluno 1 de Lab III, dia 26/4/2007)

-“ fiquei viciado no SL, passo muitas horas a desenvolver objectos só por


brincadeira”; (Ent., aluno 2 de Lab III, dia 26/4/2007)

- “Gostei muito, pois posso encontrar-me com os meus colegas que estavam no 2º ano e
já aprenderam LSL, assim podemos trocar ideias.” (Ent., aluno 10 de Lab I, dia
6/5/2008)

8.1.4. O processo de ensino no SL

Ao longo desta investigação foi claro e notório que as funções do professor são
multifacetadas, pois tem de realizar várias funções quando ensina no mundo virtual.
As suas funções começam antes de iniciar as aulas, em que o professor actua como
um design instrucional, planeia e prepara as aulas.

As funções do professor incluem actividades pouco habituais como preparar a sala


ou o espaço virtual, isto é, definir áreas na sala para cada grupo de alunos, de forma a
poder ajudá-lo a identificar o que cada grupo de alunos está a fazer no projecto. Para
além disto, também tem de preparar os materiais para as aulas e alguns deles visuais,
ou seja, exemplos práticos de objectos com pequenos programas que sejam
visualmente atractivos e interessantes, para que os alunos inexperientes possam
observar, experimentar e adaptar. Por outro lado, é indispensável que esses exemplos
sejam simples, de modo a que o professor durante uma aula facilmente os adapte às
dificuldades dos alunos. Estes materiais têm duas particularidades, por um lado
ajudar os alunos a compreender melhor os conceitos que estão a ser introduzidos e,

208
Capítulo VIII: Análise dos Resultados

por outro, despertar neles o interesse pela aprendizagem, através da observação do


que pode ser feito e da motivação em fazê-lo. Como advoga Miranda et al. (2007),
muitas das actividades de ensino e aprendizagem dependem da proposta do
professor. O professor precisa de estar presente e envolvido para assegurar que os
alunos se empenham colaborativamente na resolução das tarefas de uma forma
significativa. O trabalho do professor, no SL, é mais intenso e stressante do que nas
aulas tradicionais: este necessita de preparar antecipadamente, por escrito, tudo o que
quer ensinar e dizer, bem como prever quais serão as potenciais dificuldades dos
alunos e as possíveis questões que possam surgir, de forma a poder escrever
pequenas respostas a essas dificuldades e/ou questões e consequentemente dar aos
alunos um rápido feedback.

No decorrer das actividades foi patente que a presença e intervenção do professor


dentro e fora das aulas é imprescindível para assegurar que os alunos se empenhem
no desenvolvimento do seu projecto. Numa análise mais aprofundada ao papel do
professor nota-se que este tem de estar muito atento às necessidades dos alunos, de
forma a poder prestar a ajuda necessária, facilitar o discurso e fornecer instruções
directas quando necessário. Este aspecto foi considerado fundamental no
desempenho dos alunos, como foi mencionado pelos próprios. O professor, que deu
aulas aos alunos de Lab. I no 4º ciclo de IA, também corrobora esta opinião de que
ensinar no mundo virtual é muito mais trabalhoso e exige mais do professor do que
as aulas tradicionais. Por outro lado permite também um contacto mais directo e
personalizado com os alunos, tornando-se, assim mais fácil de identificar quais as
dúvidas e as dificuldades de cada um.

Neste estudo, conclui-se que a presença “física” do professor na primeira aula sobre
o SL é importante para que os alunos compreendam o interface. Isto facilita a
movimentação dos alunos no SL e a utilização do editor do programa. Obviamente,
isto deve-se à falta de familiarização dos alunos com o interface do SL e
eventualmente pode não ser relevante em estudantes que já tenham alguma
experiência com o mundo.

Considerou-se também importante, como meio de suporte aos alunos, existir um


espaço online onde fosse possível colocar os materiais de estudo, como por exemplo o
enunciado do trabalho, apontamentos sobre o SL e a linguagem LSL, assim como os
resultados da discussão em grupo, utilizando-se para este fim o SIDE. Outro ponto
considerado importante para que o professor pudesse dar um apoio mais focalizado

209
Capítulo VIII: Análise dos Resultados

aos alunos, seria a existência de um mecanismo que o informasse por e-mail ou outro
sistema fora do SL, das dúvidas e dificuldades que os alunos tiveram ao longo da
semana, fora do período das aulas.

Resumindo, ao longo desta investigação implementou-se e aperfeiçoou-se a


intervenção do professor tendo em mente o seu papel como construtivista. De
acordo com Brooks e Brooks (1993), os professores construtivistas são aqueles que:

 incentivam a autonomia e iniciativa dos estudantes;

 deixam que as respostas dos alunos conduzam as lições, a ponto de


alterarem as estratégias de ensino;

 encorajam a pesquisa dos estudantes fazendo perguntas pensadas e


abertas e entusiasmam-nos a fazer perguntas uns aos outros;

 encorajam a elaboração das respostas iniciais dos estudantes;

 envolvem os estudantes em experiências que podem originar


contradições às suas hipóteses iniciais e encorajam a discussão de forma a
ultrapassar tais contradições; dão tempo para reflectir, construindo
relações e mesmo criando metáforas.

210
Capítulo VIII: Análise dos Resultados

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

No presente capítulo expõe-se um conjunto de linhas orientadoras para a


utilização do SL como plataforma para o ensino introdutório da programação
a alunos do ensino superior, resultante da análise dos resultados desta
investigação. Este conjunto de linhas orientadoras tem por objectivo servir de
guia e ponto de partida para investigações futuras.
Capítulo IX: Proposta de um Modelo

213
Capítulo IX: Proposta de um Modelo

9.1. Proposta de um modelo

A introdução de uma nova tecnologia na educação implica, na generalidade,


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

9.2. Linhas orientadoras para o ensino da programação


utilizando o SL

Face ao observado ao logo da actividade preliminar e subsequentes ciclos de IA


constatou-se que o mundo virtual SL proporcionou aos alunos que participaram
nestas actividades:

 um suporte técnico e emotivo;

 um contexto lúdico para a programação;

 exemplos elucidativos;

 uma experiência comunitária que enfatiza a aprendizagem.

Cada um destes factores contribuiu individualmente para motivar os alunos a


aprender a programar.

214
Capítulo IX: Proposta de um Modelo

9.2.1. Suporte técnico e emotivo

Os alunos que frequentam as aulas de introdução à programação são muito


heterogéneos no que respeita aos seus conhecimentos de programação. Existem
alunos que estão a ter contacto com a programação pela primeira vez e outros que já
aprenderam a programar (Kelleher e Pausch, 2005; Gomes et al., 2008). Esta situação
é um desafio para o professor. Se o professor ensinar ao nível dos alunos com mais
conhecimentos, os outros sentem-se confusos, acabando provavelmente por desistir
da disciplina. Se o professor ensina ao nível dos mais fracos, os que possuem mais
conhecimentos sentem-se esmorecidos e ficam extremamente frustrados com a falta
de progressos e de desafios. Finalmente, se o professor ensina no nível intermédio, as
necessidades de ambos os alunos que estão no patamar acima e abaixo não são
contempladas. Por outro lado, observa-se, com frequência, que os estudantes
revelam níveis de autonomia bastante diferentes entre si, pelo que será necessário
intervir de forma diferenciada, diagnosticando o ponto da situação para cada um dos
casos, tentando conhecer o melhor possível os seus conhecimentos prévios, as suas
atitudes e interesses (Pereira, 2007).

Ao longo desta investigação observou-se que os alunos tinham ritmos e


necessidades de apoio muito diferentes entre si. Alguns alunos não eram capazes
de avançar sem o apoio constante da professora, como sucedeu com o aluno J
de Lab II. Outros alunos sentiam-se mais desinibidos para esclarecer as suas
dúvidas directamente com o professor, sem estarem os colegas a observar, como
referiu o aluno S de Lab I que participou no 3.º ciclo de IA.

Pedir e prestar ajuda são actos sociais que auxiliam a fomentar uma relação,
como se observou ao longo desta experiência. Ajudar não é somente dar
informação, mas é também motivar e incentivar o aluno para a aprendizagem. A
relação que se estabelece entre o professor e o aluno é uma componente
essencial do processo de aprendizagem online (Bruckman, 1997).

Foi reconfortante notar o à-vontade dos alunos a conversar com a professora,


levando-os a considerarem-na como uma colega de turma. Numa aula tradicional, os
alunos têm uma relação diferente com o professor. Nalguns casos, os alunos podem
sentir-se relutantes em pedir ajuda, por timidez. Noutros casos, o professor pode
estar sobrecarregado por ter muitos alunos e não ter tempo suficiente para ajudar

215
Capítulo IX: Proposta de um Modelo

cada um individualmente e principalmente aperceber-se das suas dificuldades. No SL


somos todos iguais, não existe a formalidade de uma sala de aula, os alunos tratam o
professor por “tu” e vêem-no como um colega de trabalho mais experiente com
quem trocam ideias, conversam e pedem ajuda. Aqui podem interagir uns com os
outros de uma forma mais livre de preconceitos do que no espaço real. Este foi um
dos aspectos realçados pelos alunos na sua avaliação sobre a comunicação.

Por conseguinte, a primeira recomendação destas orientações é que o professor


utilize o canal privado para esclarecer as dúvidas individuais de cada aluno e o canal
público para chamadas de atenção ou esclarecimentos gerais. Este tipo de
comunicação permitiu à professora, por outro lado, ter um contacto directo e
individual com cada aluno, permitindo-lhe, desta forma, aperceber-se das
dificuldades de cada um e a possibilidade de lhe dar o suporte adequado.

Observou-se na fase preliminar e no 1.º ciclo de IA uma repetição constante dos


mesmos erros de compilação e execução. No entanto, foi notória a diminuição dos
pedidos de ajuda a partir do momento em que a professora passou a escrever
comentários no código dos alunos sobre as causas do erro. Os alunos também
salientaram este aspecto referindo que deste modo poderiam ler quais as causas do
problema sempre que este surgia, sendo capazes de o resolver. Assim, recomenda-se
que o professor escreva comentários no código dos alunos sobre a causa do erro ou
da dificuldade em questão, tornando deste modo a ajuda do professor ainda mais
eficaz. Esta ajuda personalizada que a professora concedeu aos alunos levantou-lhe
algumas dificuldades, nomeadamente em conseguir dar uma resposta atempada a
todas as solicitações que recebia em simultâneo. Face a esta situação observada ao
longo do 1.º e 2.º ciclos recomenda-se que o professor tenha um conjunto de frases
predefinidas e escritas sobre as situações mais frequentes, de modo a dar um rápido
feedback aos alunos em qualquer situação.

Observou-se, principalmente no 3.º e 4.º ciclos, a importância do professor em


encorajar os alunos, autonomamente, a explorar soluções para os problemas, a
envolverem-se activamente na auto reflexão e na reflexão em grupo, a colaborarem
com os colegas. Constatou-se no 3.º e 4.º ciclos, que a discussão em grupo do
problema proposto gerou uma melhor compreensão deste por parte dos alunos. Esta
discussão serviu também para que os alunos se apercebessem da fragilidade das
soluções que apresentavam. Deste modo, recomenda-se a utilização da metodologia
PBL para pequenos grupos de tutoria. Esta recomendação vem ao encontro do que

216
Capítulo IX: Proposta de um Modelo

Dahlgren (2005) argumenta que a interacção entre pares é importante para a


aprendizagem, como uma das características referidas nas abordagens pedagógicas
centradas nos alunos na educação do ensino superior. O mesmo autor refere, ainda,
o uso de pequenos grupos de tutoria como forma base de trabalho, salientando a
importância da interacção e comunicação para o processo de aprendizagem.

Os alunos geralmente esperam apenas uma solução correcta para o problema vinda
do professor. Contudo, muitas vezes não existe apenas um única solução correcta,
mas sim várias igualmente válidas. Constatou-se nas reuniões em grupo dos 3.º e 4.º
ciclos que o facto de o professor dar alguma das soluções em forma de pergunta
levou os alunos a reflectirem na solução. Por vezes, os alunos podem sentir-se
irritados e confusos, como ocorreu com o aluno J de Lab. II. Neste caso, 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

217
Capítulo IX: Proposta de um Modelo

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

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

218
Capítulo IX: Proposta de um Modelo

Figura 9.2: Espaço utilizado nas aulas de programação durante os 3.º e 4.º ciclos de investigaçã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

219
Capítulo IX: Proposta de um Modelo

recurso e um catalisador da aprendizagem; não é apenas conceptual, simbólico ou


facto formal, mas é incorporado como potencial em objectos, artefactos, actividade
humana ou na estrutura de uma organização.

O uso de um projecto visual permite aos alunos manipularem representações


dinâmicas do mundo real e estas possibilitam objectivar os seus pensamentos de
modo a que possam reflectir sobre eles. Contudo, estes objectos, designados de
mindtools por Papert (1991), não funcionam sozinhos. Para aprender com estes
objectos, os alunos necessitam de ser preparados em relação ao que aprender,
precisam de oportunidades para articular o que descobrem e necessitam de feedback
sobre as suas descobertas. Para se conseguir isto, deve-se usar estes objectos como
um recurso em pequenos grupos colaborativos de aprendizagem, nos quais o
professor deve estar presente e dar feedback sempre que considerar necessário
(Laurillard, 2002).

A aprendizagem vem da experiência e muita da experiência útil provém dos erros.


Contudo, um aluno que não tenha confiança em si vai temer o fracasso e esse medo
dificulta ou mesmo impede a aprendizagem. Os alunos confiantes usam as falhas e a
frustração como mecanismos de incentivo. Eles sabem que uma “resposta errada”
oferece a oportunidade para descobrir um mal entendido e chegar a uma melhor
compreensão sobre o assunto. Esse conhecimento reparador levará a um melhor
desempenho ao longo do tempo. No entanto, muitos alunos não começam a
aprendizagem com confiança. O ensino tradicional normalmente desencoraja ou
penaliza as falhas através de sistemas de avaliação e do reconhecimento do
desempenho académico (Harrison, 2000). Os empregados podem temer que os seus
empregadores vejam o seu fracasso como um sinal de incapacidade e temem perder o
seu trabalho. Como resultado, a confiança em falhar é rara e difícil de desenvolver.
Assim, é importante remover o medo do fracasso como uma barreira para a
aprendizagem, tornando o fracasso ou erros como parte integrante do processo de
aprendizagem.

Ao longo desta investigação foi-se procurando formas de minimizar os erros e


consequentemente encontrar soluções para que os alunos aprendam e tirem partido
deles. Como se verificou, a comunicação utilizada entre a professora e os alunos veio
remover certas barreiras que, geralmente, impedem os alunos de expor as suas
dúvidas e fracassos ao professor. Um outro fenómeno observado foi que os alunos
não ficavam perturbados quando os seus objectos não se comportavam da maneira

220
Capítulo IX: Proposta de um Modelo

que esperavam, muito antes pelo contrário, na generalidade os que desenvolveram


um projecto visual iam à procura de uma solução para o problema. Como se conclui
dos comentários que os alunos fizeram no último encontro mensal:

-“diverti-me imenso, principalmente porque o meu cão passava a vida a dizer que
tinha fome, mesmo quando tinha acabado de comer”; (Ent., aluno D, de Proj. I,
dia 14/1/2008)

-“(...) gostei de criar o carro e a pista... este projecto foi interessante..” (Ent., aluno
B de Lab. I, dia 27/4/2007)

De acordo com Eckstein (2001), deve-se construir actividades que exijam que os
alunos reflictam sobre o que está certo e incorrecto como forma de compreender
melhor o tema em estudo. O mesmo autor refere ainda que se deve garantir que
todos os alunos que encontrem resultados incorrectos não serão estigmatizados por
não chegarem à resposta certa.

No ensino da programação ocorre frequentemente os alunos dizerem que sabem


programar, mas quando vão aplicar os conceitos verifica-se o oposto. Nesta
investigação também foi notória esta lacuna, principalmente nos alunos de Lab II,
que frequentemente diziam que sabiam programar mas não o conseguiam
demonstrar. Muitas vezes, os alunos são expostos a problemas simples e têm uma
solução simples. Quando se deparam com problemas complexos, os alunos
apresentam soluções que não resolvem o problema. Mais grave, a ausência de
experiência impede-os de reconhecer falhas no seu pensamento; esta foi uma das
lacunas identificadas em alguns alunos que participaram neste estudo. Por este
motivo, recomenda-se que o problema proposto deve ser complexo o suficiente de
forma a levar os alunos a reflectir na sua solução. Assim, o problema deve à primeira
vista sugerir uma solução simples baseada directamente nos conceitos gerais que o
aluno sabe. No entanto, após uma análise cuidadosa de um número de questões, os
alunos são levados a repensar na sua solução e a concluir que o problema exige uma
solução mais complexa.

O contraste entre a reacção inicial do aprendiz (o projecto é acessível) e o resultado


de algum estudo ou discussão (este problema é mais complexo do que inicialmente se
pensou) é crucial para o sucesso ( Anthony, 1996; McAndrew, Goodyear e Dalziel,
2006). Isto induz que o aprendiz reconheça que o assunto é mais subtil do que tinha
inicialmente pensado. Por outro lado, serve de ligação entre a aprendizagem dos

221
Capítulo IX: Proposta de um Modelo

conceitos básicos e os tópicos mais avançados. Esta forma faz com que os alunos
suspeitem da compreensão que têm dos conceitos básicos, de modo a que continuem
a questioná-los e a melhorar a sua compreensão. Como referem McAndrew et al.
(2006), os alunos, ocasionalmente, precisam de ser confrontados com uma realidade
distinta da que estão a fazer, de modo a aperceberem-se das subtilezas. Uma vez que
na indústria novas ideias são muitas vezes vistas como ferramentas ou técnicas de
programação, é necessário que os alunos sejam treinados para desenvolvê-las.

Ademais, este estudo mostrou que a atitude dos alunos perante a aprendizagem
dentro deste ambiente foi, em geral, de empenho na realização do projecto, tendo-se
observado uma saudável competição pela criação de objectos mais atraentes. Os
alunos de Lab. I e de Proj. I construíram um cão, os do Lab. III vários robots e um
comboio e as respectivas estações. Outros alunos de Lab. I (3.º e 4.º ciclos) criaram
carros, semáforos, uma bomba de gasolina e uma pista, tendo todos eles programado
os seus respectivos comportamentos. Os alunos trabalharam fora do período das
aulas, durante longas horas, colaborando uns com os outros e com a professora.
Constatou-se que os alunos aprendiam e divertiam-se com o que estavam a fazer. Os
alunos aprendem melhor num contexto onde a prática não é entediante e estão a
resolver problemas com significado, e isto motiva-os a trabalhar mais (Bergin et al.,
2001; Gee, 2003; Oliver, 2009).

No SL é relativamente fácil criar objectos engraçados e realistas, sendo possível


através da linguagem LSL programar o seu comportamento fazendo com que
interajam uns com os outros e com os avatares, o que torna os objectos ainda mais
realistas. Como refere Gee (2003):

“Thinking, problem solving, and knowledge are “stored” in material objects and the
environment. This frees learners to engage their minds with other things while combining
the results of their own thinking with the knowledge stored in material objects and the
environment to achieve yet more powerful effects.” (p. 210).

Um aspecto surpreendente foi observar que os alunos, por sua própria iniciativa,
criaram outros programas apenas por diversão e tinham orgulho em exibi-los.
Observou-se também que se empenhavam por descobrir novas funcionalidades, que
poderiam aplicar não só no seu projecto, mas também aos programas que andavam a
desenvolver por divertimento. Da experiência da investigadora como professora de
programação, também observou este tipo de comportamento em alguns dos alunos

222
Capítulo IX: Proposta de um Modelo

usando ambientes tradicionais. Contudo, este tipo de atitude não é generalizado, ou


seja, em ambientes tradicionais apenas alguns alunos programam “por diversão”.
Como Twining (2009) refere:

“virtual worlds seem to provide the ideal vehicle for providing people with such ‘lived
experiences’, of radically different models of education. They allow users to do things
which would be difficult or impossible to do in the physical world.”(p. 512 ).

Em resumo, é importante que os alunos estudem em locais onde se identifiquem e se


sintam confortáveis para deixar a sua imaginação voar. De acordo com Isaacson
(2007):

“A society’s competitive advantage will come not from how well its schools teach the
multiplication and periodic tables, but from how well they stimulate imagination and
creativity.”(p. 7).

Em suma, recomenda-se que o projecto proposto deve ser complexo o suficiente de


forma a obrigar a cooperação de todos os elementos do grupo para a sua resolução.
Deve ter, também, uma forte componente visual e ser adaptado ao nível de
conhecimento dos alunos.

9.2.3. A importância dos exemplos

Na programação existem muitos conceitos abstractos que os alunos precisam de


compreender para poderem progredir na aprendizagem. Como refere Gruber (2008),
um conceito abstracto é difícil de compreender e perceber qual a sua utilidade se não
existir um exemplo concreto. Os exemplos concretos de utilização desses conceitos
são especialmente úteis para estudantes que têm pouca experiência,
consequentemente, os alunos aprendem o conceito abstracto e observam uma
aplicação concreta. Isto permite-lhes distinguir o próprio conceito da sua aplicação.
Os alunos, muitas vezes, consideram difícil converter o que assimilam nas aulas em
competências que podem usar fora da sala (Bruckman, 1997). Eles lembram-se
menos do que ouviram, do que testaram e experimentaram (ibid.).

Constatou-se no decorrer dos vários ciclos, principalmente na fase preliminar e no


3.º e 4.º ciclos, no qual participaram os alunos com menos experiência de
programação, que a utilização de exemplos concretos os ajudou a compreender os
conceitos. Por outro lado, os exemplos serviram também como mecanismos de

223
Capítulo IX: Proposta de um Modelo

incentivo e motivação para os alunos explorarem o que podem fazer no mundo


virtual. Face ao observado, recomenda-se a utilização de pequenos exemplos para os
alunos testarem e alterarem de forma a melhor compreenderem os conceitos. Os
exemplos aplicados devem contudo ser lúdicos e mostrar as potencialidades do
ambiente. Não obstante, é necessário ter em atenção que estes não devem ser
demasiados complexos, pois se assim for perde-se o objectivo inicial.

Este estudo enfatizou a importância que tem para os alunos o exemplo do sucesso
alcançado pelos colegas. O facto de dois alunos terem conseguido obter sucesso na
comunidade SL e principalmente um deles ter recebido uma proposta de emprego foi
motivo de interesse para que outros quisessem seguir o seu exemplo. Como foi o
caso de um dos alunos de Lab. II, que apesar da frustração do projecto que teve de
desenvolver e de não ter gostado de o implementar, sempre quis aprender a
programar no SL, pois como ele próprio referiu: “eu quero aprender a programar para me
candidatar e ganhar um estágio remunerado no SL”, e conseguiu apesar de todas as
dificuldades que teve.

9.2.4. Comunidade que enfatiza a aprendizagem

O mundo virtual SL está cheio de objectos interessantes criados pelos seus


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

224
Capítulo IX: Proposta de um Modelo

construir objectos, a quererem aprender a programar, e a serem capazes de criar


funcionalidades como os outros fizeram.

O conjunto de exemplos disponíveis no mundo virtual para aprender não são


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

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

225
Capítulo IX: Proposta de um Modelo

No mundo virtual, os alunos nunca estão sozinhos mesmo quando estão fora do
tempo da aula. Quando tinham um problema no seu programa, existia sempre
alguém a quem eles podiam recorrer, e por vezes ocorria o inverso, eram os outros
que vinham ter com eles e lhes solicitavam ajuda. Ajudar os outros é uma actividade
central na cultura do mundo virtual (Bruckman, 1997; Wagner, 2008; Twining, 2009)
e é a base sobre a qual um relacionamento se estabelece.

Pelo facto da comunidade ser um impulso na aprendizagem da programação, como


se observou ao longo destas actividades, recomenda-se que os alunos fora das aulas
devem desenvolver os seus projectos em qualquer local livre no mundo virtual.

A Tabela 9.1 apresenta um resumo das recomendações resultantes deste estudo para
o ensino inicial da programação, utilizando o mundo virtual SL como plataforma ou
outro com características semelhantes.

226
Capítulo IX: Proposta de um Modelo

Elementos Procedimento recomendado


Projecto – deve ser complexo o suficiente de forma a
obrigar a cooperação de todos os elementos do grupo
para a sua resolução. Deve ter, também, uma forte
componente visual e ser adaptado ao nível de
conhecimento dos alunos.
Materiais de aprendizagem
Pequenos exemplos – fornecer aos alunos objectos
atractivos com programas simples sobre os novos
conceitos a aprender, que os alunos devem
experimentar e alterar. Estes exemplos devem ser
adaptados ao nível de conhecimento de cada aluno.
Problem-based learning para pequenos grupos de tutoria,
juntamente com uma pedagogia diferenciada;
Comunicação:
 Canal público – restringir a sua utilização, apenas
para explicações ou chamadas de atenção gerais
por parte do professor;
 Canal privado – este canal deve ser usado pelo
professor e alunos para tirar dúvidas e dar
explicações individualizadas por parte do professor
a cada um dos alunos.
Professor:
Metodologia
 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,

227
Capítulo IX: Proposta de um Modelo

Elementos Procedimento recomendado


dando-lhes apoio directo na fase inicial da
aprendizagem, e seguidamente ajudar os alunos a
transitar gradualmente para uma auto-
aprendizagem.
Ter um espaço no mundo virtual no qual decorrerão as
aulas. Restringir o acesso a esse espaço a alunos e
convidados.
Fora das aulas – para intensificar o contacto com a
comunidade, os alunos devem desenvolver os seus
projectos em qualquer local livre no mundo virtual.
Espaço da aula Espaço da aula:
 Identificar zonas de trabalho para cada grupo
de alunos.
 Definir uma zona para colocar os vários
exemplos práticos usados nas aulas. Neste
espaço os alunos podem deixar objectos que
considerem interessantes para os colegas.

Tabela 9.1: Modelo para o ensino / aprendizagem da programação de computadores dentro do


Second Life.

228
Capítulo IX: Proposta de um Modelo

229
10. Conclusões

Concluído o processo de investigação, tendo-se analisado e apresentado os


resultados, resta tirar conclusões acerca da forma como os objectivos definidos
inicialmente foram ou não atingidos. Por fim, apresentam-se as considerações finais e
o trabalho futuro.
Capítulo X: Conclusões

231
Capítulo X: Conclusões

10.1. Conclusões

Aprender a programar um computador é uma tarefa difícil e exigente, principalmente


para os alunos inexperientes. Por outro lado, a programação parece não ser um
assunto atractivo para a generalidade dos alunos dos cursos de informática do ensino
superior, em várias partes do mundo, como na América, Austrália, Nova Zelândia e
Europa (Mierlus, 2007; Lister et al., 2010). Os alunos gostam de usar o computador,
passam horas a jogar jogos complexos sozinhos ou online com outros colegas, mas
estas aplicações de lazer normalmente requerem algum tempo de adaptação, pois é
necessário ler as instruções, compreender os objectivos, etc. Os alunos também
gostam de conversar no Messenger, e expor as suas experiências em blogs, mas quando
se fala em aprender a programar um computador a motivação e o interesse
esmorecem.

Uma das questões primordiais que se coloca hoje em dia aos professores é como
ajudar os alunos a compreender os fundamentos e a ganhar motivação para a
programação. A resposta não é simples, depende do que se considera importante
ensinar, como, por exemplo, seguir uma abordagem orientada a objectos ou
procedimental, focar mais nos algoritmos e na resolução de problemas, dar mais
ênfase na linguagem da programação utilizada ou ao desenvolvimento de
competências como as de comunicação e colaboração, que também são desejáveis
que os alunos de engenharia adquiram (Jenkins, 2002; Ma et al., 2007; Shivers, 2008;
Czejdo, e Bhattacharya, 2009).

A proposta da investigadora consiste em contextualizar o ensino introdutório da


programação através da utilização dos mundos virtuais tridimensionais online 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

232
Capítulo X: Conclusões

superior em disciplinas de programação. Este estudo compreendeu uma actividade


preliminar e 4 ciclos subsequentes de investigação-acção, tendo resultado no
desenvolvimento de um modelo para o ensino e aprendizagem da programação de
computadores dentro do mundo virtual Second Life.

Em resumo, para concretizar os objectivos traçados cumpriram-se as seguintes


etapas:

 foi feito um levantamento das dificuldades relatadas na literatura científica


sobre a aprendizagem da programação, assim como a explanação das
principais abordagens pedagógicas propostas. Foram também descritas as
ferramentas que têm vindo a ser utilizadas para o ensino e aprendizagem da
programação;

 foram analisados os mundos virtuais existentes com o intuito de seleccionar


um para ser utilizado nesta investigação. Desta análise resultou na adopção
do mundo virtual Second Life;

 foi concebido o projecto de investigação, no qual se optou por utilizar uma


metodologia de investigação qualitativa, mais concretamente, a metodologia
investigação-acção;

 foi levado a cabo o trabalho de campo regido pela metodologia investigaçã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

233
Capítulo X: Conclusões

estes os experimentarem e alterarem. Contudo, o modelo realça a importância destes


exemplos serem adaptados ao nível de conhecimento de cada aluno. O modelo
propõe que se deve utilizar um canal de comunicação privado entre o professor e
aluno, para o esclarecimento de dúvidas e dar explicações individualizadas. Assim,
estabelece-se uma relação de partilha e ajuda, que se torna difícil de estabelecer
publicamente para muitos alunos. É igualmente importante o reconhecimento
público do trabalho dos alunos, como fonte de motivação para que estes se
envolvam e comprometam na sua aprendizagem.

Em suma, verificou-se que o mundo virtual SL ou outro com características idênticas


pode ser utilizado como plataforma para o ensino e aprendizagem introdutórios da
programação. Contudo, na sua utilização deve-se ter em conta principalmente os
seguintes factores:

 é necessário um grande empenho por parte do professor em todo o processo


de gestão, acompanhamento, suporte do ensino e aprendizagem;

 é necessário ter muito cuidado com o tipo de projecto que se propõe.

Estes são os dois pilares fundamentais que a investigadora considera indispensáveis


para se poder utilizar os mundos virtuais no ensino e aprendizagem da programação.
Apesar dos mundos virtuais terem características que os tornam bastante atractivos
para serem usados na educação, falta averiguar se o esforço compensa, isto é, se
realmente os alunos neste ambiente aprendem melhor, sendo esta uma das propostas
de trabalho futuro.

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

Este estudo pretende ser um ponto de partida para outras investigações, quer
qualitativas quer quantitativas, sobre os benefícios da utilização dos mundos virtuais
no ensino e aprendizagem da programação. Pelo que, este trabalho não termina nesta
dissertação, acredita-se que o modelo proposto servirá de guia a futuras investigações
e que estas venham trazer-lhe melhorias.

Uma das lacunas referidas nesta investigação diz respeito ao acompanhamento por
parte do professor do trabalho dos alunos fora das aulas. Uma das soluções possíveis
seria a integração das actividades no mundo virtual com um serviço de mensagens

234
Capítulo X: Conclusões

semelhante ao SMS dos telemóveis. Esta integração poderá ser ainda mais eficaz se
permitir que o professor siga os progressos e esforços dos alunos, de forma a poder
ajudá-los de um modo mais directo, mesmo quando este não se encontra dentro do
mundo. Para tal, seria necessário desenvolver um mecanismo automático que
registasse o trabalho dos alunos dentro do mundo quando o professor não está
presente, respondendo automaticamente a algumas questões, e proporcionar o
contacto com este através de vários meios, como por exemplo usar um sistema
semelhante ao proposto por Valério et al. (2009).

Um outro objectivo a alcançar futuramente prende-se com a confirmação de que


através da utilização dos mundos virtuais como plataforma no ensino e aprendizagem
da programação os alunos aprendem melhor do que nos ambientes tradicionais, o
que implicaria fazer um estudo comparativo entre estes distintos ambientes, a nível
nacional e internacional, de modo a se poder obter resultados mais conclusivos.

Especificamente, seria interessante averiguar não só o domínio das técnicas de


programação, mas também se os conhecimentos adquiridos pelos alunos são
autênticos e não superficiais, isto é, se eles são capazes de usar esses conhecimentos
em outras situações. Outro aspecto a explorar seria a utilização do mundo virtual
como plataforma para o ensino e aprendizagem da programação em disciplinas não
introdutórias da programação, com o propósito de se analisar o seu desempenho,
bem como a sua utilização em disciplinas como a engenharia do software. Os
resultados desta investigação serviriam também para introduzir melhorias ao presente
modelo.

A investigadora pretende desenvolver esta investigação e, em simultâneo, explorar


outras variáveis, tais como o impacto deste ambiente na motivação dos alunos, e se
diminui o índice de reprovação nas disciplinas de introdução à programação.

Um outro aspecto a desenvolver seria explorar e adequar o modelo ao ambiente de


sala de aula sem ser remotamente, embora se considere que a principal adaptação seja
de anular a utilização do canal público que seria substituído por explicações directas
para todos os alunos que se encontram nesse ambiente. Contudo, a mudança radical
de contexto não presencial para presencial poderá permitir descortinar outras
dinâmicas, por agora não antecipadas.

235
11. Referências Bibliográficas

Abrunhosa, M. A. e Leitão, M. (2002). Psicologia. Volume1. Areal Editores.

Ackoff, R. L. (1998), Acoff’s Best: His Classic Writtings on Management. John Wiley &
Sons, Inc.

Alarcão, I. (1991). Reflexão crítica sobre o pensamento de D. Schön e os programas de formação


de professores. Cadernos Cidíne 1: Supervisão e formação de professores,
Aveiro: Universidade de Aveiro, pp. 5-22.

Allan, S. e Tomlinson C.(2002). Liderar projectos de diferenciação pedagógica. Porto:


Edições Asa.

Allen, E., Cartwright, R. e Stoler, B. (2002). DrJava: a lightweight pedagogic


environment for Java. In Proceedings of the 33rd SIGCSE technical symposium on
Computer science education (SIGCSE '02). ACM, New York, NY, USA, 137-141.

Almeida, J. C. (2001). Em defesa da investigação-acção. Sociologia, nov. 2001, no.37,


p.175-176. ISSN 0873-6529 Disponível em on-line em
http://www.scielo.oces.mctes.pt/scielo.php?pid=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.

236
Austin, T., Boulder, C. (2007). The Horizon Report, 2007 Edition. New Media
Consortium and EDUCAUSE Learning Initiative. [Online]; disponível em
http://www.nmc.org/pdf/2007_Horizon_Report.pdf (acedido em 12 de
Setembro de 2008)

Avison, D. E., Lau, F., Myers, M. D. e Nielsen, P. A. (1999). Action research.


Commun. ACM 42, 1 (Jan. 1999), 94-97.

Bailey, F., e Moar, M. (2002). The Vertex Project: Exploring the creative use of
shared 3D virtual worlds in the primary (K-12) classroom. Paper presented at
SIGGRAPH 2002, San Antonio. In ACM SIGGRAPH 2002 Conference
Abstracts and Applications (pp. 52 – 54). New York: ACM SIGGRAPH.

Balakrishnan, A. D., Fussell, S. R. e Kiesler, S. (2008). Do visualizations improve


synchronous remote collaboration?. In Proceeding of the Twenty-Sixth Annual
SIGCHI Conference on Human Factors in Computing Systems (Florence, Italy, April
05 - 10, 2008). CHI '08. ACM, New York, NY, 1227-1236.

Barab, S. A., Hay, K. E., Barnett, M. G., e Squire, K. (2001). Constructing virtual
worlds: Tracing the historical development of learner
practices/understandings. Cognition and Instruction, 19(1), 47 – 94.

Barab, S. A., Hay, K. E., Squire, K., Barnett, M., Schmidt, R., Karrigan, K., et al.
(2000). Virtual solar system project: Learning through a technology-rich,
inquiry-based, participatory learning environment. Journal of Science Education
and Technology, 9, 7 – 25

Barbier, J. (1990). L’ evaluation en formation (2ª ed.). Paris: Press Universitaires de


France.

Barrett, T. (2005). Who said learning couldn’t be enjoyable, playful and fun? – The
voice of PBL students. In Esa Poikela & Sari Poikela (Eds.), PBL in Context –
Bridging Work and Education (pp. 159–175). Finland,Tampere University Press.

Barrows, H. (2001). Problem-based Learning (PBL). Disponível 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.

237
Bateman, M.; Storer, T.; Purdie, S. e Lock, R. (2007). Encouraging experimentation
in programming using a problem based learning approach. Proposal to SELF
2007, October 2007.

Bawden, R. e Zuber-Skerritt, O. (2000). The concept of process management. In


Action Learning, Action Research and Process Management: Theory, Practice, Praxis,
Action Research Unit. Faculty of Education, Griffith University, Brisbane.

Bayman, P. e Mayer, R. E. (1983). A diagnosis of beginning programmers'


misconceptions of BASIC programming statements. Commun. ACM 26, 9
(Sep. 1983), 677-679.

Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley

Becker, B. W. (2001). Teaching CS1 with karel the robot in Java. In Proceedings of the
Thirty-Second SIGCSE Technical Symposium on Computer Science Education
(Charlotte, North Carolina, United States). SIGCSE '01. ACM, New York,
NY, 50-54.

Becker, K. (2002). Back to Pascal: Retro but not backwards. Journal of Computing in
Small Colleges, 18(2):17–27.

Ben-Ari, M., (2001). Constructivism in computer science education. Journal of


Computer in Mathematics and Science Teaching 20 (1), 45-73.

Bender, T. (2003). Discussion-based online teaching of enhance student learning: Theory,


practice and assessment. Virginia: Stylus Publishing.

Bennedsen, J. e Schulte, C. (2010). BlueJ visual debugger for learning the execution
of object-oriented programs? ACM Trans. Comput. Educ. 10, 2, Article 8 (June
2010), 1-22.

Bereiter, C. e Ng., E. (1991). Three Levels of Goal Orientation in Learning. In


Journal of the Learning Sciences, nº 3, (vol. 1), 243-271

Bergin, J. (2006). Karel universe drag & drop editor. In Proceedings of the 11th Annual
SIGCSE Conference on innovation and Technology in Computer Science Education
(Bologna, Italy, June 26 - 28, 2006). ITICSE '06. ACM, New York, NY, 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.

238
Bettencourt-da-Cruz, T. M. (2006). A Internet na Construção de Conhecimento Didáctico.
Tese de Doutoramento, Universidade de Aveiro.

Blizzard Entertainment. (2010). World of Warcraft®: The Burning Crusade™


continues record breaking sales pace.
http://www.blizzard.com/press/070307.shtml. Consultado a 8 de Janeiro de
2010.

Bogdan, R. e Biklen, S. (1994). Investigação Qualitativa em Educação. Porto:Porto


Editora.

Bonar, J. e Soloway, E. (1985). Preprogramming knowledge: a major source of


misconceptions in novice programmers. Hum.-Comput. Interact. 1, 2 (Jun.
1985), 133-161.

Boroni, C. M., Goosey, F. W., Grinder, M. T., Lambert, J. L. e Ross, R. J. (1999).


Tying it all together: creating self-contained, animated, interactive, Web-based
resources for computer science education. In the Proceedings of the Thirtieth
SIGCSE Technical Symposium on Computer Science Education (New Orleans,
Louisiana, United States, March 24 - 28, 1999). SIGCSE '99. ACM, New
York, NY, 7-11.

Böszörményi, L. (1998). Why Java is not my favourite first-course language. 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.

239
Brown, M. e Sedgewick, R. (1984a). Progress Report: Brown University
Instructional Computing Laboratory. In Proceedings of the fifteenth SIGCSE
Technical Symposium on Computer Science Education, vol.6, No. 1, pp. 91-101,.

Brown, M., Najork, M. (1996). Collaborative Active Textbooks: A Web-Based


Algorithm Animation System for an Electronic Classroom, In Proceedings of the
IEEE Symposium on Visual Languages (VL’96) to be held September 3–6, 1996
in Boulder, Colorado

Brown, M., Sedgewick, R. (1984b). A System for Algorithm Animator, ACM


Computer Graphics, Vol. 18, pp. 177-186, Minneapolis, Julho.

Bruckman, A. S. (1997). MOOSE Crossing: Construction, Community, and Learning in a


Networked Virtual World for Kids. Massachusetts Institute of Technology.

Bruer, J.T. (1993). Schools for Thought: A science of learning in the classroom. Cambridge
MA: MIT Press.

Bruner, J. S. (1960). The Process of Education. Cambridge. Harvard University Press

Bruner, J. S. (1966). Toward a Theory of Instruction. Cambridge. Harvard University


Press.

Bruner, J. S. (1990). Acts of Meaning. Cambridge. Harvard University Press.

Brusilovsky, P. (1991). Turingal—the language for teaching the principles of


programming. In the 3rd European Logo Conference, Parma, Italy. 423–432.

Brusilovsky, P., Calabrese, E., Hvorecky, J., Kouchirenko, A., e Miller, P. (1997).
Mini-languages: A way to learn programming principles. Educat. Inform.
Technol., 2, 1, 65–83.

Buck, D. e Stucki, D. J. (2001). JKarelRobot: a case study in supporting levels of


cognitive development in the computer science curriculum. In Proceedings of the
Thirty-Second SIGCSE Technical Symposium on Computer Science Education
(Charlotte, North Carolina, United States). SIGCSE '01. ACM, New York,
NY, 16-20.

Byrne, P. e Lyons, G. (2001). The effect of student attributes on success in


programming. SIGCSE Bull. 33, 3 (Sep. 2001), 49-52.

Byrnes, J. (1996). Cognitive development and learning in instructional contexts. Boston : Allyn
and Bacon.

Cai, H., Sun, B., Farh, P. e Ye, M. (2008). Virtual Learning Services over 3D
Internet: Patterns and Case Studies. In Proceedings of the 2008 IEEE international
Conference on Services Computing - Volume 2 (July 07 - 11, 2008). IEEE Computer
Society, Washington, DC, 213-219

240
Cairncross, S.; McEwan, T. (2009). Researching engineering education: Some
philosophical considerations. In Proceedings of the 39th ASEE/IEEE Frontiers in
Education Conference, Santo Antonio, Texas, USA, 18- 21 October 2009, 1-6

Calabrese, E. (1989). Marta – The “intelligent turtle”. In Proceedings of the Second


European Logo Conference. G. Schuyten and M. Valcke (Eds.) pp 111-127,
Belgium.

Cameron, J. (2009). Avatar, disponível em


http://www.avatarmovie.com/index.html consultado a 15 de Dezembro de
2009.

Carmen L. Z. Gress, Meghann Fior, Allyson F. Hadwin e Philip H. Winne. (2010).


Measurement and assessment in computer-supported collaborative learning.
Comput. Hum. Behav. 26, 5 (September 2010), 806-814.

Carson, D. Gilmore, A., Gronhaug, K. e Perry (2001). Qualitative Marketing Research,


Sage, London.

Carvalho, R., Cozinheiro, L. (2007) AV3D – Ambiente virtual 3D de apoio à


programação orientada a objectos. Escola Superior de Tecnologia e Gestão do IPL.

Cassel, L.; McGettrick, A., Guzdial, M. e Roberts, E. (2007). The current crisis in
computing: what are the real issues?. In Proceedings of the 38th SIGCSE Technical
Symposium on Computer Science Education (Covington, Kentucky, USA, March 07
- 11, 2007). SIGCSE '07. ACM, New York, NY, 329-330.

Castronova, E. (2001). Virtual Worlds: A First-Hand Account of Market and


Society on the Cyberian Frontier. In The Gruter Institute Working Papers on Law,
Economics, and Evolutionary Biology, 2(1), 1-66.

Champion, E. e Sekiguchi, S. (2005). Suggestions for New Features to Support


Collaborative Learning in Virtual Worlds. In Proceedings of the Third international
Conference on Creating, Connecting and Collaborating Through Computing (January 28 -
29, 2005). C5. IEEE Computer Society, Washington, DC, 127-134.

Chan, M. S. e Black, J. B. (2006). Direct-manipulation animation: incorporating the


haptic channel in the learning process to support middle school students in
science learning and mental model acquisition. In Proceedings of the 7th
international Conference on Learning Sciences (Bloomington, Indiana, June 27 - July
01, 2006). International Conference on Learning Sciences. International
Society of the Learning Sciences, 64-70.

Chee, Y. S. (2007). Embodiment, embeddedness, and experience: game-based


learning and the construction of identity. Research and Practice in Technology
Enhanced Learning, 2, 1, 3–30.

Chen, J. e Weld, D. S. (2008). Recovering from errors during programming by


demonstration. In Proceedings of the 13th international Conference on intelligent User
interfaces (Gran Canaria, Spain, January 13 - 16, 2008). IUI '08. ACM, New
York, NY, 159-168.

241
Cheng, A. (1998). A graphical programming interface for a children’s constructionist learning
environment. Electrical Engineering and Computer Science Department. MIT,
Cambridge, MA.

Chizzotti, A. (1991). Pesquisa em ciências humanas e sociais. São Paulo: Cortez.

Clancy, M. J. e Linn, M. C. (1992). Case studies in the classroom. SIGCSE Bull. 24,
1 (March 1992), 220-224.

Close, R., Kopec, D. e Aman, J. (2000). CS1: perspectives on programming


languages and the breadth-first approach. In Proceedings of the 5th annual CCSC
Northeastern Conference on Computing in Small Colleges, pages 228–234.
Consortium for Computing Sciences in Colleges.

Cohen, L. e Manion, L. (1994). Research Methods in Education Fourth Edition, London,


Routledge.

Collis, B. (1998). New didactics for university instruction: why and how?. Computers
& Education, 31, pp.373-393

Collis, B.; Wende, M. (2002). Models of Technology and Change in Higher Education.
Center for Higher Education and Policies/Faculty of Educational Science and
Technology of University of Twente

Concepcion, A. I., Cummins, L. E., Moran, E. J., e Do, M. M. (1999). Algorithma


98: an algorithm animation project. SIGCSE Bull. 31, 1 (Mar. 1999), 301-305.

Cooper, S., Dann, W. e Harrison, J. (2010). A k-12 college partnership. In Proceedings


of the 41st ACM Technical Symposium on Computer Science Education (Milwaukee,
Wisconsin, USA, March 10 - 13, 2010). SIGCSE '10. ACM, New York, NY,
320-324.

Cooper, S., Dann, W. e Pausch, R. (2000). Alice: a 3-D tool for introductory
programming concepts. In Proceedings of the Fifth Annual CCSC Northeastern
Conference on the Journal of Computing in Small Colleges (Ramapo College of New
Jersey, Mahwah, New Jersey, United States). J. G. Meinke, Ed. Consortium
for Computing Sciences in Colleges. Consortium for Computing Sciences in
Colleges, 107-116.

Corbit, M. e DeVarco, B. (2000). SciCentr and BioLearn: Two 3-D implementations


of CVE science museums. In E. Churchill and M. Reddy (Eds.), Proceedings of
the Third International Conference on Collaborative Virtual Environments (pp. 65 –
71). New York: ACM.

Coutinho, Clara P. e Chaves, José H. (2002) O estudo de caso na investigação em


Tecnologia Educativa em Portugal. Revista Portuguesa de Educação, Volume 15,
número 1, 221-244.

Cox, A. e Campbell, M. (1994). Multi-user dungeons. Interactive Fantasy 2, 15-20

242
CPAL3D (2002). CPAL3D engine http://www.cpal3d.net. Consultado a 5 de Abril
de 2009.

Craft, T. (2004). Codelab-C: on Line Product. Jones and Bartlett Publishers, Inc

Crosby, M. e Stelovsky, J. (1995). From multimedia instruction to multimedia


evaluation. Journal Educ. Multimedia and Hypermedia 4, 147–162.

Cypher, A. (1991). EAGER: Programming Repetitive Tasks by Example, In CHI,


Proceedings SIGCHI’91. April. New Orleans, LA: pp.33-39..

Cypher, A., Halbert, D. C., Kurlander, D, Lieberman, H, Maulsby, D.,. Myers, B. A


and Turransky, A. Eds. (1993) Watch what I Do: Programming by Demonstration.
MIT Press.

Czejdo, B. D. e Bhattacharya, S. (2009). Programming robots with state diagrams. J.


Comput. Small Coll. 24, 5 (May. 2009), 19-26.

Dahlgren, L.-O. (2005). Learning conceptions and outcomes. In F. Marton, D.


Hounsell & N. Entwistle (Eds.), The experience of learning: Implications for teaching
and studying in higher education (3rd (Internet) ed., pp. 23–38). Edinburgh:
Edinburgh: University of Edinburgh, Centre for Teaching, Learning and
Assessment.

Dalgarno, B. (2002). The potential of 3D virtual learning environments: a


constructivist analysis. Electronic Journal of Instructional Science and Technology, 5, 2,
1–19. Consultado a 15 de Abril de 2007 em
http://www.usq.edu.au/electpub/e-jist/docs/Vol5_No2/Dalgarno%20-
%20Final.pdf

Damer, Bruce (2001), Global Cyberspace and Personal Memespace, disponível em


http://www.kurzweilai.net/meme/frame.html?main=/articles/art0096.html
consultada a 2 de Março de 2007.

Danilicheva, P., Klimenko, S., Baturin, Y. e Serebrov, A. (2010). Education in


Virtual Worlds: Virtual Storytelling. In CyberWorlds, 2009. CW '09. IEEE
International conferencve on Bradford Outubro 6-10-2010. pp. 333-338.

Dann, W. e Cooper, S. (2009). Education Alice 3: concrete to abstract. Commun.


ACM 52, 8 (Aug. 2009), 27-29.

Dann, W., Cooper, S., Pausch, R. (2000). Making the connection: programming
with animated small worlds. In Proceedings of the 5th annual conference on Innovation
and Technology in Computer Science Education. Helsinki, Finland, July, 2000, 41- 44.

de Barros, L. N., dos Santos Mota, A. P., Delgado, K. V. e Matsumoto, P. M.


(2005). A tool for programming learning with pedagogical patterns. In
Proceedings of the 2005 OOPSLA Workshop on Eclipse Technology Exchange (San
Diego, California, October 16 - 17, 2005). eclipse '05. ACM, New York, NY,
125-129.

243
de Freitas, S. (2008). Serious virtual worlds: a scoping study. Bristol: Joint Information
Systems Committee. Consultado em 14 de Outubro de 2009, em
http://www.jisc.ac.uk/publications/publications/seriousvirtualworldsreport.a
spx

de Freitas, S. e Neumann, T. (2009). The use of ‘exploratory learning’ for


supporting immersive learning in virtual environments. Computers and
Education, 52, 2, 343–352.

de Freitas, S. e Veletsianos, G. (2010). Editorial: Crossing boundaries: Learning and


teaching in virtual worlds. British Journal of Educational Technology, 41, 1, 3–9.

de Freitas, S., Rebolledo-Mendez, G., Liarokapis, F., Magoulas, G. e Poulovassilis,


A. (2010). Learning as immersive experiences: Using the four-dimensional
framework for designing and evaluating immersive learning experiences in a
virtual world. British Journal of Educational Technology. 41(1). 69-85

De Grave, W. S. (1998). Problem-based learning as knowledge construction. Doctoral


dissertation, Maastricht University, Maastricht, The Netherlands.

de Raadt, M., Watson, R., Toleman M., (2002). Language Trends in Introductory
Programming. In Proceedings of Informing Science and IT Education Conference, pages
329–337. InformingScience.org, June

de Raadt, M., Watson, R., Toleman M., (2004). Introductory programming: what’s
happening today and will there be any students to teach tomorrow? In
Proceedings of the 6th Conference on Australasian Computing Education, pages 277–
282. Australian Computer Society, Inc.

Dede, C. (1995). The evolution of constructivist learning environments: Immersion in distributed


virtual worlds. Educational Technology, 35(5), 46–52.

Delta 3D (2008). Delta 3D open source gaming simulation engine


http://www.delta3d.org/index.php. Consultado a 5 de Abril de 2009.

Demetrescu, C. e Finocchi, I. (2001). Smooth animation of algorithms in a


declarative framework. Journal of Visual Languages and Computing, 12(3).

Denning, P. J., (1989). A debate on teaching computing science. Communications of the


ACM, 32:1397–1414.

Denscombe, M. (1998). The good research guide for small-scale social research
projects, Open University Press.

DePasquale III, P. J., (2003). Implications on the Learning of Programming


Through the Implementation of Subsets in Program Development
Environments. PHD Thesis, Blacksburg, Virginia.

Desai, C., Janzen, D. S. e Clements, J. (2009). Implications of integrating test-driven


development into CS1/CS2 curricula. In SIGCSE ’09: Proceedings of the 40th
ACM technical symposium on Computer science education, pages 148–152, New York,
NY, USA, 2009. ACM.

244
Di Blas, N., Poggi, C. e Reeves, T. C. (2006). Collaborative learning in a 3D virtual
environment: design factors and evaluation results. In Proceedings of the 7th
international Conference on Learning Sciences (Bloomington, Indiana, June 27 - July
01, 2006). International Conference on Learning Sciences. International
Society of the Learning Sciences, 127-133.

Dias, P. (2004). Desenvolvimenyto de objectos de aprendizagem para plataformas


colaborativas. In X. Barrientos, V. Zuñiga, J. Ortiz, L. Isaías, S. Guerra, R.
Garza, M. Cantú e S. Hinojosa (Org.), Actas do VII Congeso Iberoamericano de
Informática Eductiva. Monterrey: Universidade de Monterrey, (pp. 3-12).

Dick, B. (2000) A beginner's guide to action research [On line]. Disponível em


http://www.scu.edu.au/schools/gcm/ar/arp/guide.html . Consultado a 5 de
Março de 2008.

Dickey, M. D. (2003). Teaching in 3D: Pedagogical affordances and constraints of


3D virtual worlds for synchronous distance learning. Distance Education, 24(1),
105 – 121.

Dickey, M. D. (2004). An architectural perspective for the design of educational


virtual environments. Journal of Visual Literacy, 24(1), 49 – 66.

Dickey, M. D. (2005). Three-dimensional virtualworlds and distance learning: two


case studies of ActiveWorlds as amedium for distance education. British
Journal of Educational Technology, 36, 3, 439–451.

Diehl, S. (2007). Software visualization: Visualizing the Structure, Behaviour, and Evolution
of Software. Springer New York.

Dijkstra, E. W. (1989). On the Cruelty of Really Teaching Computing Science. In


Communications of ACM, Issue 12, (vol.32), 1398-1404.

Dingle, A., Zander, C. (2000). Assessing the ripple effect of CS1 language choice. In
Proceedings of the 2nd Annual CCSC Computing in Small Colleges Northwestern
Conference, pages 85–93. Consortium for Computing Sciences in Colleges,

Duch, B. (2001). Writing Problems for Deeper Understanding. In B. Duch, S. E.


Groh, & D. E. Allen (Eds.) The power of problem-based learning: A practical “how
to” for teaching undergraduate courses in any discipline (pp. 47-53). Sterling, Virginia,
2001, Stylus Publishing

Duck, B., Gron, S. e Allen, D. (ed), (2001). The power of Problem-Based Learning. A
practical “How to” for teaching undergraduate courses in any discipline. Stylus
Publishing, LLC.

Dutta, K. (1985). Modular programming in C: an approach and an example.


SIGPLAN Not. 20, 3 (Mar. 1985), 9-15.

E-Arbitration-T (2008). e-Justice Centre, ODR in Second Life. http://www.e-arbitration-


t.com/2008/02/28/e-justice-centre-odr-insecond-life/ Consultado a 7 de
Setembro de 2009.

245
Eckstein, J. (2001). Learning to Teach and Learning to Learn. Proceedings of EuroPLoP
2000, UKV Konstanz.

Edirisingha, P., Nie, M., Pluciennik, M. and Young, R. (2009). Socialisation for
learning at a distance in a 3-D multi-user virtual environment. British Journal of
Educational Technology. 40(3), 458-479

Edwards, S., Bruce C. (2000). Reflective internet searching, an action research


model, in Ortrun Zuber-Skerrit (Ed). Action Learning, Action Research and
Process Management, Theory, Practice, Praxis. Action Research Unit, Griffith
University, 5th World Congress of Action Learning, Action Research and Process
Management, University of Ballarat, Victoria, September, pp. 141-152

Ericsson, K. A. e Simon, H. A. (1984). Protocol analysis: Verbal reports as data.


Cambridge: MIT Press.

Esteves, M. and Mendes, A. (2003). OOP-Anim, a system to support learning of


basic object oriented programming concepts. In Proceedings of the 4th
international Conference Conference on Computer Systems and Technologies: E-Learning
(Rousse, Bulgaria, June 19 - 20, 2003). B. Rachev and A. Smrikarov, Eds.
CompSysTech '03. ACM, New York, NY, 573-579.

Esteves, M. and Mendes, A. (2004). A Simulation Tool to Help Learning of Object


Oriented Programming Basics. In Proceedings of the 34th ASEE/IEEE Frontiers
in Education Conference, Savannah, Georgia, USA, October 2004, 20-23

Esteves, M., e Mendes, A., (2004). A Simulation Tool to Help Learning of Object
Oriented Programming Basics. In Proceedings of the 34th ASEE/IEEE Frontiers
in Education Conference. Savannah, Georgia, USA, October 2004, 20-23.

Esteves, Micaela; Fonseca, Benjamim; Morgado, Leonel; Martins, Paulo (2008).


Contextualization of Programming Learning: A Virtual Environment Study.
In Proceedings of the 38th ASEE/IEEE Frontiers in Education Conference, October
22 – 25, 2008, Saratoga Springs, NY, pp. 17-22, ISBN 978-1-4244-1970-8.
Washington, DC, USA: IEEE.

Everquest (2006), Everquest Web site, consultado 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.

246
Fenwick, J. B., Norris, C., Barry, F. E., Rountree, J., Spicer, C. J., and Cheek, S. D.
(2009). Another look at the behaviors of novice programmers. In Proceedings of
the 40th ACM Technical Symposium on Computer Science Education (Chattanooga,
TN, USA, March 04 - 07, 2009). SIGCSE '09. ACM, New York, NY, 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&idyea
r=1, Departamento de Engenharia Informática, Faculdade de Ciências e
Tecnologia da Universidade de Coimbra, Portugal. Consultado a 9 de Maio de
2006

Fonseca, V. (2007). Aprender a aprender a educabilidade cognitiva. Âncora Editora.


Lisboa.

Forterra Systems Inc. (2004). http://www.forterrainc.com/index.php/about-us.


Consultado a 15 de Março de 2009.

Frei, P., Su, V., and Ishii, H. (2000). Curlybot: Designing a new class of
computational toys. In the Conference on Human Factors in Computing Systems, Los
Angeles, CA. 129–136.

Frenzoo Limited. (2010).


http://www.frenzoo.com/beta/information.php?chapter=about_us.
Consultado a 15 de Março de 2010

GameSpy. (2003). Massively multiplayer online games: The past, the present, and
the future. http://archive.gamespy.com/amdmmog/. Consultado a 15 de
Abril de 2008.

Garlick, R. and Cankaya, E. C. (2010). Using Alice in CS1: a quantitative


experiment. In Proceedings of the Fifteenth Annual Conference on innovation and
Technology in Computer Science Education (Bilkent, Ankara, Turkey, June 26 - 30,
2010). ITiCSE '10. ACM, New York, NY, 165-168.

Garner, S. (2002). The Learning of Plans in Programming: A Program Completion


Approach. In Proceedings of the international Conference on Computers in Education
(December 03 - 06, 2002). ICCE. IEEE Computer Society, Washington, DC,
1053.

Garner, S. (2008). The Teaching and Learning of Programming: the Use of a Technology
Supported Part-Complete Solution Method. VDM Verlag.

247
Garner, S. (2009). Learning to Program from Scratch. In Proceedings of the 2009 Ninth
IEEE international Conference on Advanced Learning Technologies - Volume 00 (July
15 - 17, 2009). ICALT. IEEE Computer Society, Washington, DC, 451-452.

Gartner, Inc. (2007).Gartner Says 80 Percent of Active Internet Users Will Have A "Second
Life" in the Virtual World by the End of 2011, April 24, 2007. Disponível em
http://gartner.com/it/page.jsp?id=503861 Acedido em 29 de Março de 2009.

Gee, J. P. (2003),What video games have to teach us about learning and literacy, New York:
Palgrave Macmillan.

Gerdt, P., Kommers, P., Looi, C. K. and Sutinen, E. (2001). Woven stories as a
cognitive tool. In Cognitive Technology, LNAI 2117, pages 233–247.

Gijselaers, W. H. (1996). Connecting problem-based practices with educational


theory. In L. Wilerson & W, H. Gijselaers (Eds.) New Directions for Teaching and
Learning, Vol 68, (pp. 13 – 21). San Francisco: Jossey Bass.

Glinert, E. and Tanimoto, S. (1984). Pict: An interactive graphical programming


environment. Computer 17, 11, 7–25.

Goldman, K. J. (2004). A concepts-first introduction to computer science. In


Proceedings of the 35th SIGCSE Technical Symposium on Computer Science Education,
pages 432–436. ACM.

Goldman, K., Gross, P., Heeren, C., Herman, G., Kaczmarczyk, L., Loui, M., and
Zilles, C. (2010). Setting the Scope of Concept Inventories for Introductory
Computing Subjects. Trans. Comput. Educ. 10, 2 (Jun. 2010), 1-29.

Gomes, A. and Carmo, L. and Bigotte, E. and Mendes, A. (2006). Mathematics and
programming problem solving. 3rd ELearning Conference – Computer Science
Education. Coimbra, September.

Gomes, A. e Mendes, A. J. (1999). A animação na aprendizagem de conceitos


básicos de programação. Revista de Enseñanza y Tecnología, No. 13, pp. 22-32.

Gomes, A. J. e Mendes, A. J.(2000). Suporte à aprendizagem da programação com o


ambiente SICAS, in RIBIE.

Gomes, A., Areias, C. M., Henriques, J., Mendes, A. (2008). Aprendizagem de


programação de computadores: dificuldades e ferramentas de suporte. Revista
Portuguesa de Pedagogia, Vol. 42, # 2, pp. 161-179, Julho.

Gomes, A., Henriques, J., Mendes, A. J. (2008). Uma proposta para ajudar alunos
com dificuldades na aprendizagem inicial de programação de computadores.
Educação, Formação & Tecnologias, vol. 1 (1), Maio.

Gomes, A., Mendes, A. J. (2007). An environment to improve programming


education. In B. Rachev, A. Smrikarov, and D. Dimov (Eds.), Proceedings of the

248
2007 International Conference on Computer Systems and Technologies, Bulgaria, June
14–15, 2007, ACM: New York

Gotschi, T.; Sanders, I. and Galpin, V. (2003). Mental models of recursion. In


Proceedings of the 34th SIGCSE Technical Symposium on Computer Science Education
(Reno, Navada, USA, February 19 - 23, 2003). SIGCSE '03. ACM, New York,
NY, 346-350.

Gray, W. D.; Goldberg, N.C.; Byrnes, S. A. (1993), Novices and programming: Merely a
difficult subject (why?) or a means to mastering metacognitive skills? Review of the book
Studying the Novice Programmer, Journal of Educational Research on Computers,
pp 131-140.

Gries, D. (1974). What should we teach in an introductory programming course?. In


Proceedings of the Fourth SIGCSE Technical Symposium on Computer Science Education
SIGCSE '74. ACM, New York, NY, 81-89.

Gruber, P. (2008). Bringing Abstract Concepts Alive. How to Base Learning


Success on the Principles of Playing, Curiosity and In-Classroom
Differentiation. In Proceedings of the 3rd international Conference on informatics in
Secondary Schools - Evolution and Perspectives: informatics Education - Supporting
Computational Thinking (Torun, Poland, July 01 - 04, 2008). R. T. Mittermeir
and M. M. Sysło, Eds. Lecture Notes In Computer Science, vol. 5090.
Springer-Verlag, Berlin, Heidelberg, 134-141.

Guzdial, M. (2004a). Introduction to Computing and Programming in Python: A Multimedia


Approach. Prentice Hall, Upper Saddle River, NJ.

Guzdial, M. (2004b). Programming environments for novices. In Computer Science


Education Research, S. Fincher and M. Petre, Eds. Taylor and Francis, London,
128–154.

Guzdial, M., Kolodner, J., Hmelo, C., Narayanan, H., Carlson, D., Rappin, N.,
Hübscher, R., Turns, J., and Newstetter, W. (1996). Computer support for
learning through complex problem solving. Commun. ACM 39, 4 (Apr. 1996),
43-45.

Habbo Hotel (2006), Habbo Hotel Web site, 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.

249
Harper, R. (2007). Universidade de Aveiro Inaugura ilha no Second Life. No
Jornalismo Porto net (JPN).
http://jpn.icicom.up.pt/2007/05/25/universidade_de_aveiro_inaugura_ilha_
no_second_life.html. Consultado a 25 de Maio de 2007.

Harrison, Foote. (2000). Rohnert (eds.), Pattern Languages of Program Design 4,


Addison Wesley

Hartmann,W., Nievergelt, J., and Riechert, R. (2001). Kara: Finite state machines,
and the case for programming as part of general education. In IEEE Symposia
on Human Centric Computing Languages and Environments, Stresa, Italy. 135–141.

Hawi, N. (2010). Causal attributions of success and failure made by undergraduate


students in an introductory-level computer programming course. Comput.
Educ. 54, 4 (May 2010), 1127-1136.

Haythornthwaite, C. (2006). Facilitating collaboration in online learning. JALN


Journal of Asynchronous Learning Networks, Vol. 10,1 consultado em :
http://www.sloanconsortium.org/publications/jaln/v10n1/v10n1_2
haythornthwaite.asp a 23 Junho de 2009.

Hedin, G., Bendix, L. and Magnusson, B. (2008). Teaching Software Development


Using Extreme Programming. In Reflections on the Teaching of Programming, 2008,
pp.166-189.

Hew, K. F. e Cheung, W. S. (2010). Use of three-dimensional (3-D) immersive


virtual worlds in K-12 and higher education settings: A review of the research.
British Journal of Educational Technology. 41(1). 33-55.

Higgins, C. A., Gray, G., Symeonidis, P. and Tsintsifas, A. (2005). Automated


assessment and experiences of teaching programming. ACM Journal on
Educational Resources in Computing, 5(3):5.

Hoare, C. A. R., (1969). An axiomatic basis for computer programming.


Communications of the ACM, 12(10):576–580.

Hofstadter, D. (1979). Gödel, Escher, Bach: an Eternal Golden Braid, Part II, Chapter 10:
"Similar Levels", Basic Books.

Hogan, M. and Eva, K. W. (2005). Students’ perceptions of Problem-based learning


in an undergraduate medical programme. Poikela, E.; Poikela, S. (eds.). PBL in
Context - Brindging work and education. p. 135 - 145.

Hogger, C. J. (1990). Essentials of Logic Programming, Graduate Texts in Computer Science


1. Oxford University Press.

Holt, R., Wortman, D., Barnard, D., and Cordy, J. R. (1977). SP/k: A system for
teaching computer programming. Commun. ACM. 20, 5, 301–309.
Howard, P. (1994). The owner's manual for the brain. Austin, TX: Leornian.
Hübscher-Younger, T. and Narayanan, N. H. (2003). Constructive and collaborative
learning of algorithms. SIGCSE Bull. 35, 1, 6–10.

250
Hugon, M. A., Seibel, C. (1988). Recherches impliquees. Recherches actions - lecas de
l’éducation. Bruxelles : De Boeck.

Hulkko, H.; Abrahamsson, P. (2005), A Multiple case study on the impact of Pair
Programming on Product Quality. In ICSE’05. St. Louis, Missouri, USA,
Maio pp. 15–21.

Hundhausen, C. and Brown, J. (2005). What you see is what you code: A “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.

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

Isaacson, W. (2007). Einstein: His Life and Universe. Simon &Schuster Paperbacks,
Rockefeller Center. New York.

Jacobs, K. (2007). Microsoft Office Excel 2007: The L Line, The Express Line to Learning
(The L Line: The Express Line To Learning). Wiley; illustrated edition edition.

Jacobson, M. J. (2006). Empirical research into learning in 3D virtual and game environments:
selected review of the literature. Singapore: Learning Sciences Laboratory, National
Institute of Education, Nanyang Technological University.

Jadud, M. C (2005). A first look at novice compilation behaviour. Computer Science


Education, 15, 1, 25-40.

Jain, J., James, I., Cross, H., Hendrix, T. D. and Barowski, L. A. (2006).
Experimental evaluation of animated-verifying object viewers for Java. In
Proceedings of the 2006 ACM Symposium on Software Visualization, pages 27–36.
ACM.

Jarc, D. e Feldman, M. (1998). An Empirical Study of Webbased Algorithm


Animation Courseware in a Ada Data Structure Course, In Proceedings of the
Annual ACM SIGAda International Conference on Ada, Washington, D.C. – USA.

Jenkins, T. (2002). On the difficulty of learning to program. In Proceedings of 3rd


Annual LTSN_ICS Conference (Loughborough University, United Kingdom,
August 27-29. The Higher Education Academy, p.53-58.

Jenkins, T.(2002) On the difficulty of learning to program, in “Proceedings of the 3rd


annual conference of the LTSN centre for information and computer
science” (Loughborough, United Kingdom, August 27-29, 2002).
Jensen, E. (1998). Teaching with the brain in mind. Alexandria, VA: ASCD.
Johnsgard, K., and McDonald, J. (2008). Using ALICE in Overview Courses to
Improve Success Rates in Programming I. In 21st Conference on Software
Engineering Education and Training, CSEET 2008.

Johnston, M. W., Hanna, J. R., Millar, R. (2004). Advances in Dataflow


Programming Languages. ACM Computing Surveys, Vol. 36, No. 1, March, pp
1-34.

Jonassen, D. (1999). Designing constructivist learning environments. In C. M.


Reigeluth (Ed.), Instructional-design theories and models: A new paradigm of
instructional theory. Vol. II. Hillsdale, NJ: Lawrence Erlbaum Associates.

Jong, F. P. C. M., van der Meijden, H. e von Berg, J. (2005). 3D learning in the
workplace and at school: playing, learning, or both? Educational Technology, 45,
5, 30–34.

252
JPN. (2007). UA é a primeira universidade em Portugal a marcar presença no Second Life com
compra de ilha. Disponível em
http://jpn.icicom.up.pt/2007/04/03/aveiro_juntase_as_70_universidades_d
e_todo_o_mundo_no_second_life.html . Consultado a 9 de Setembro de
2010.

Kaczmarczyk, L., Petrick, E., East, J. P., and Herman, G. L. (2010). Identifying
student misconceptions of programming. In Proceedings of the 41st Annual ACM
Technical Symposium on Computer Science Education (SIGCSE’10).

Karavirta, V., Korhonen, A., Malmi, L. and Stlanacke, K. (2004). MatrixPro - A tool
for on-the-fly demonstration of data structures and algorithms. In Proceedings of
the 3rd Program Visualization Workshop, pages 26–33, The University of
Warwick, UK, July.

Karn, J. S. and Cowling, T. (2006). A Follow up Study of the Effect of Personality


on the Performance of Software Engineering Teams. ACM ISESE’06.

Kay, Alan (1993). The Early History of Smalltalk. In The second ACM SIGPLAN
conference on History of programming languages. pp. 69-95, ACM Press, New York,
NY, USA.

Kehoe, C., Stasko, J., end Taylor, A. (2001). Rethinking the evaluation of algorithm
animations as learning aids: An observational study. Int. Journal Hum.-Comput.
Studies 54, 2, 265–284.

Kelleher, C. (2006). Motivating Programming: using storytelling to make computer


programming attractive to middle school girls. PhD Thesis, School of Computer
Science, Carnegie Mellon University, Pittsburgh,

Kelleher, C. e Pausch R. (2005). Lowering the Barriers to Programming: A


Taxonomy of Programming Environments and Languages for Novice
Programmers. ACM Computing Surveys, Vol. 37, No. 2, June 2005, pp. 83–137.

Kelleher, C. Pausch, R. e Kiesler, S. (2007). Storytelling Alice Motivates Middle


School Girls to Learn Computer Programming. In CHI ’07: Proceedings of the
SIGCHI Conference on Human Factors in Computing Systems, pp. 1455-1464, New
York, NY, 2007.

Kerman, M. C. (2001). Programming and Problem Solving with Delphi. ISBN-10:


0321204417. Pearson Education; International edition

Kichuk, S. L. and Wiesner, W. H. (1997). The Big Five Personality Factors and
Team Performance: Implications for Selecting Successful Product Design
Teams. J. of Engin. and Technol. Management. 14, pp.195-221.

Kiczales, G. and Mezini, M. (2005). Aspect-oriented programming and modular


reasoning. In Proceedings of the 27th international Conference on Software Engineering
(St. Louis, MO, USA, May 15 - 21, 2005). ICSE '05. ACM, New York, NY,
49-58.

253
Kiili, K., (2005). Digital game-based learning: Towards an experiential gaming
model. Internet and Higher Education, Vol. 8, 13-24.

Kimura, T., Choi, J., and Mack, J. (1990). Show and tell: A visual programming
language. In Glinert, E. P., Ed. Visual Programming Environments: Paradigms and
Systems. IEEE Computer Science, 397–404.

Kingsland, A. J. (1996).Time expenditure, workload, and student satisfaction in


Problem-based Learning. Wilkerson, L.; Gijselaers, W.H. (Ed.). Bringing
Problem-based Learning to higher education. San Francisco: Jossey-Bass Publishers.
p.73-81.

Knowlton, K. C.(1966). L6: Bell telephone laboratories low-level linked list


language. 16 mm black and white sound film, 16 minutes, 1966

Kolb, D. A., (1984). Experimental Learning: Experience as the Source of Learning


and development. Prentice Hall, England

Kolikant, Y. B-D. and Mussai, M. (2008). “So my program doesn't run!” Definition,
origins, and practical expressions of students' (mis)conceptions of
correctness. Computer Science Education, 18, 2 (Jun. 2008), 135-151.

Köling, M., Quig, B., Patterson, A. and Rosenberg, J. (2003). The BlueJ system and
its pedagogy. Computer Science Education, 13.

Kolling, M. and Rosenberg, J. (1996). Blue—A language for teaching 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.

254
Kurtz, T. (1981). In Wexelblat, R., Ed. BASIC- History of Programming Languages.
Academic Press, New York, 515–537.

Laakso, M., Myller, N. and Korhonen, A. (2009). Comparing Learning Performance


of Students Using Algorithm Visualizations Collaboratively on Different
Engagement Levels. Journal Ed. Technol. Soc. 12, 2, 267-282

Lahtinen, E., Mutka, K. A., and Jarvinen, H. M (2005). A Study of the difficulties of
novice programmers, in “Proceedings of the 10th annual SIGSCE conference on
Innovation and technology in computer science education (ITICSE 2005)”
(Monte da Caparica, Portugal, June 27-29, 2005). ACM Press, New York, NY,
pp. 14-18.

Lahtinen, E., Mutka, K. A., and Jarvinen, H. M. (2005). A Study of the difficulties of
novice programmers. In Proceedings of the 10th annual SIGSCE conference on
Innovation and technology in computer science education (ITICSE 2005). Monte da
Caparica, Portugal, June 27-29, 2005, ACM Press, New York, NY, pp. 14-18.

Lahtinen, T. (2005). Implementation of Problem-based Learning in Engineering


Education- PBL curriculm in mechatronics. Poikela, E.; Poikela, S. (eds.).
PBL in Context - Brindging work and education. p. 79- 95.

Laird, J. (2001), Using a computer game to develop advanced AI, Computer, 34(7):70-75,
July 2001.

Lappalainen, V., Itkonen, J., Isomöttönen, V., and Kollanus, S. (2010). ComTest: a
tool to impart TDD and unit testing to introductory level programming. In
Proceedings of the Fifteenth Annual Conference on innovation and Technology in Computer
Science Education (Bilkent, Ankara, Turkey, June 26 - 30, 2010). ITiCSE '10.
ACM, New York, NY, 63-67.

Larkin-Hein, T. (2001). On-line discussions: a key to enhancing student motivation


and understanding?. In Proceedings of the Frontiers in Education Conference, 2001.
31st Annual - Volume 02 (FIE '01), Vol. 2. IEEE Computer Society,
Washington, DC, USA, F2G-6-F2G-12vol.2.

Larman, C. and Basili, V. R. (2003). Iterative and incremental development: A brief


history. Computer, 36(6):47–56, 2003.

Laurillard, D. (2002). Rethinking teaching for the knowledge society, EDUCAUSE,


Consultado em: http://www.educause.edu/ir/library/pdf/ERM0201.pdf, a
24/11/2008.

Lave, J., and Wenger, E. (1991). Situated learning: Legitimate peripheral participation.
Cambridge, MA: Cambridge University Press.

Lawrence, A., Badre, A., and Stasko, J. (1994). Empirically evaluating the use of
animations to teach algorithms. In Proceedings of the IEEE Symposium on Visual
Languages (VL’94). 48–54.

255
Lemieux, F. and Salois, M. (2006). Visualization Techniques for Program
ComprehensionA Literature Review. In Proceeding of the 2006 Conference on New
Trends in Software Methodologies, Tools and Techniques: Proceedings of the Fifth
Somet_06 H. Fujita and M. Mejri, Eds. Frontiers in Artificial Intelligence and
Applications, vol. 147. IOS Press, Amsterdam, The Netherlands, 22-47

Lemos, R. S. (1979). Teaching programming languages: A survey of approaches. In


Proceedings of the Tenth SIGCSE Technical Symposium on Computer Science Education
SIGCSE '79. ACM, New York, NY, 174-181.

Lessard-Hebert, M., Goyette, G., and Boutin, G. (1990). Recherche qualitative:


fondements et pratiques. Montréal: Agence d’ARC.

Lester, C. K. (2007). Jubilation: Programming with Euphoria 4.0 a ebook disponível


em http://www.usingeuphoria.com/books/jubilation/?entirebook
Consultado a 4/4/2008.

Lethbridge, C.; Diaz-Herrera, J.; LeBlanc, Jr.; Thompson, B. (2007). Improving


software practice through education: Challenges and future trends. Future of
Software Engineering, (FOSE apos;07),May 2007 Page(s):12 – 28.

Lewin, K. (1946). Action research and minority problems. Journal of Social Issues, Vol.
2 No. 4, pp. 34-6.

Lieberman, H., ed.(2001). Your wish is My Commend. Morgan Kaufmann: San


Francisco.

Lim, C. P., Nonis, D. e Hedberg, J. (2006). Gaming in a 3D multiuser virtual


environment: engaging students in science lessons. British Journal of Educational
Technology, 37, 2, 211–231.

Linn, M. C.; Sloane, K. D. e Clancy, M. J. (1987). Ideal and actual outcomes from
precollege Pascal instruction. Journal of Research in Science Teaching. 25, 5, 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.

256
Lohr, S. (2007) Free the Avatars, The New York Times. Disponível em
http://bits.blogs.nytimes.com/2007/10/10/free-the-avatars/ acedido a 29
de Março de 2009.

Lukas, G. (1972). Uses of the LOGO Programming Language in Undergraduate


Instruction. In Proceedings of the ACM Annual Conference (New York, New York,
1972), Association for Computing Machinery, pp. 1130-1136.

Ma, L., Ferguson, J., Roper, M., and Wood, M. (2007). Investigating the viability of
mental models held by novice programmers. In Proceedings of the Thirty-Eighth
SIGCSE Technical Symposium on Computer Science Education (Covington,
Kentucky, United States, March 07 - 11, 2007). SIGCSE '07.

Malmi, L., Karavirta, V., Korhonen, A., Nikander, J., Seppälä, O. and Silvasti, P.
(2004) Visual algorithm simulation exercise system with automatic
assessment: TRAKLA2. Informatics in Education, 3(2):267 – 288.

Manninen, T. (2004). Rich Interaction Model for Game and Virtual Environment Design,
Academic Dissertation, Department of Information Processing Science,
University of Oulu, Oulu, Finland.

Martins, S. W., Mendes, A. J., and Figueiredo, A. D. (2010). Diversifying activities to


improve student performance in programming courses. In Proceedings of the
11th international Conference on Computer Systems and Technologies and Workshop For
PhD Students in Computing on international Conference on Computer Systems and
Technologies (Sofia, Bulgaria, June 17 - 18, 2010). B. Rachev and A. Smrikarov,
Eds. CompSysTech '10. ACM, New York, NY, 540-545.

MathWorks (1994). Accelerating the pace of engineering and science (1994 – 2009)
– site oficial disponível em :http://www.mathworks.com consultada em
Março 2009

Maurice Vincent Wilkes. (2009). In Encyclopædia Britannica. Consultado a 22 de


Outubro de 2009, em Encyclopædia Britannica Online:
http://www.britannica.com/EBchecked/topic/725595/Maurice-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.

257
Mccracken, M., Almstrum, V., Diaz, D., Guzdial, M., Hagan, D., Kolikant, Y. B.-D.,
Laxer, C., Thomas, L., Utting, I., and Wilusz, T. (2001). A multi-national,
multi-institutional study of assessment of programming skills of first-year CS
students. In Proceedings of Working Group Reports on Innovation and Technology in
Computer Science Education (ITiCSE-WGR’01). 125–180.

Mcdowell, C., Werner, L., Bullock, H. E., and Fernald, J. (2006). Pair programming
improves student retention, confidence, and program quality. Comm. ACM 49,
8, 90–95.

Mclver, L.; Conway, D. (1996). Seven Deadly Sins of Introductory Programming


Language Design. In Proceedings of the 1996 International conference on Software
Engineering Education and Practice. Pag. 309-316.

Melnik, G. and Maurer, F. (2005). A cross-program investigation of students’


perceptions of agile methods. In ICSE ’05: Proceedings of the 27th international
conference on Software engineering. pages 481–488, New York, NY, USA, 2005.
ACM.

Mendes, António J. (2002). Software Educativo para Apoio à Aprendizagem de


Programação. 2002. Disponível em:
http://www.c5.cl/ieinvestiga/actas/tise01/pags/
charlas/charla_mendes.htm. (consultado a 13/9/2006).

Messinger, P., Stroulia, E. e Lyons, K. (2008). A Typology of VirtualWorlds:


Historical Overview and Future Directions. Journal of VirtualWorlds Research,
1(1). Consultado em 11 de Dezembro de 2008, em
http://journals.tdl.org/jvwr/article/view/291

Mierlus, I. (2007). Learning Programming Languages Using Visualizations. Fourth


International Conference on eLearning for Knowledge-based Society, November
Bangkok, Thailand, 25-32.

Miliszewska, I. e Tan, G. (2007). Befriending computer programming: A proposed


approach to teaching introductory programming. Journal of Issues in Informing
Science & Information Technology. 4, 277–289.

Miller, P. e Chandhok, R. (1989). The design and implementation of Pascal Genie.


In Proceedings of the ACM Computer Science Conference. Louisville, KY.

Milne, I. and Rowe, G. (2002). Difficulties in Learning and Teaching


Programming—Views of Students and Tutors. Education and Information
Technologies 7, 1 (Mar. 2002), 55-66.

Miranda, C., Morais, C. E, Dias, P. (2007). Colaboração em ambientes online na


resolução de tarefas de aprendizagem. In P. Dias, C. Freitas, B. Silva, A.
Osório, e A. Ramos (Orgs.) Actas de V Conferência Internacional de Tecnologias de
Informação e Comunicação na Educação, pp. 576-585. Braga: Centro de
Competências da Universidade do Minho.

Miranda, L. (2005). Educação online: Interação e estilos de aprendizagem de alunos do ensino


superior numa plataforma Web. Braga: Universidade do Minho.

258
Mitchell, Alice and Savill-Smith, Carol. (2004). The use of computer and video
games for learning - a review of the literature. Published by the Learning and
skills Development Agency. Consultado no endereço:
https://www.lsnlearning.org.uk/search/Resource-32183.aspx em
23/10/2007

Mitchell, John C. (2002). Concepts in Programming Languages. Cambridge


University Press. Cambridge, UK.

Moreno, A. and Joy, M. S. (2007). Jeliot 3 in a Demanding Educational Setting.


Electron. Notes Theor. Comput. Sci. 178 (Jul. 2007), 51-59.

Moreno, A., Myller, N., and Sutinen, E. (2004). JeCo, a Collaborative Learning Tool
for Programming. In Proceedings of the 2004 IEEE Symposium on Visual Languages
- Human Centric Computing (September 26 - 29, 2004). VLHCC. IEEE
Computer Society, Washington, DC, 261-263.

Moreno, A., Myller, N., Ben-Ari, M., and Sutinen, E. (2004). Program animation in
jeliot 3. In Proceedings of the 9th Annual SIGCSE Conference on innovation and
Technology in Computer Science Education (Leeds, United Kingdom, June 28 - 30,
2004). ITiCSE '04. ACM, New York, NY, 265-265.

Moreno, A., Myller, N., Sutinen, E. and Ben-Ari, M.(2004). Visualizing programs
with Jeliot 3. In Proceedings of the Working Conference on Advanced Visual Interfaces,
pages 373–376. ACM.

Morgado, L. (2009). Interconnecting virtual worlds. Journal of Virtual Worlds Research,


1(3). Consultado a 10 de Abril de 2009, em
http://journals.tdl.org/jvwr/article/view/469/430

Morningstar, C. e Farmer, F. R. (1991). The Lessons of Lucasfilm's Habitat, Published in


Cyberspace: First Steps, Michael Benedikt (ed.), MIT Press.

Motil, J. and Epstein, D. (2000). JJ: a Language Designed for Beginners (Less Is
More). Consultado em http://www.ecs.csun.edu/jmotil/TeachingWithJJ.pdf
a 2 de Março de 2007.

Murphy, L.; Lewandowski, G.; McCauley, R.; Simon, B.; Thomas, L. and Zander, C.
(2008). Debugging: the good, the bad, and the quirky – a qualitative analysis
of novices' strategies. In SIGCSE '08: Proceedings of the 39th SIGCSE technical
symposium on Computer science education, pages 163-167.

Myers, B. A.(1990). Taxonomies of Visual Programming and Program Visualization.


Journal of Visual Languages and Computing, Mar. 1(1). Pp. 97-123.

Myers, B. A., Ko, A. J., and Burnett, M. M. (2006). Invited research overview: 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.

259
Myller, N., Bednarik, R., Sutinen, E., and Ben-Ari, M. (2009). Extending the
Engagement Taxonomy: Software Visualization and Collaborative Learning.
Trans. Comput. Educ. 9, 1 (Mar. 2009), 1-27.

Myller, N., Laakso, M., and Korhonen, A. (2007). Analyzing engagement taxonomy
in collaborative algorithm visualization. In Proceedings of the 12th Annual
SIGCSE Conference on Innovation and Technology in Computer Science Education
(ITiCSE’07), J. Hughes, D. R. Peiris, and P. T. Tymann Eds. ACM Press,
251–255.

Nagappan, N., Williams, L., Ferzli, M., Wiebe, E., Yang, K., Miller, C., and Balik, S.
(2003). Improving the CS1 experience with pair programming. In Proceedings of
the 34th SIGCSE Technical Symposium on Computer Science Education (SIGCSE’03).
ACM Press, 359–362.

Naps, T. L. (2005). JHAVÉ – Supporting Algorithm Visualization. IEEE Computer


Graphics and Applications, 25(5):49–55.

Naps, T. L. and Rößling, G. (2007). JHAVÉ - More Visualizers (and Visualizations)


Needed. In Rößling, G. Ed. Proceedings of the Fourth Program Visualization
Workshop. Electronic Notes in Theoretical Computer Science, 178, 4 (2007), 33-41.

Naps, T. L., Rößling, G., Almstrum, V., Dann, W., Fleischer, R., Hundhausen, C.,
Korhonen, A., Malmi, L., McNally, M., Rodger, S., and Velázquez-Iturbide, J.
Á. (2002). Exploring the role of visualization and engagement in computer
science education. In Working Group Reports From ITiCSE on innovation and
Technology in Computer Science Education (Aarhus, Denmark, June 24 - 28, 2002).
ITiCSE-WGR '02. ACM, New York, NY, 131-152.

Neville, B. (1992). Research as consultant: consultant as researcher – a


phenomenological experiential model of action research. A Quarterly
Experience, Vol. 28, pp. 33-9.

Nguyen, Q. V., Huang, M. L., and Hawryszkiewycz, I. (2004). A New Visualization


Approach for Supporting Knowledge Management and Collaboration in 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.

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

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

262
Piaget, J. (1976). A Equilibração das estruturas cognitivas. Rio de Janeiro: Zahar
Editores.

Piaget,J., (1977). O desenvolvimento do pensamento. Dom Quixote, Lisboa.

Piajet, J. (1973). Seis estudos de psicologia. Dom Quixote, Lisboa.

Pierce, J. S., Christiansen, K., Cosgrove, D., Conway, M., Moskowitz, D., Stearns,
B., Sturgill, C., and Pausch, R. (1998). Alice: easy to learn interactive 3D
graphics. In CHI 98 Conference Summary on Human Factors in Computing Systems
(Los Angeles, California, United States, April 18 - 23, 1998). CHI '98. ACM,
New York, NY, 26-27.

Pierson, W. C. and Rodger, S. H. (1998). Web-based animation of data structures


using JAWAA. In Proceedings of the Twenty-Ninth SIGCSE Technical Symposium on
Computer Science Education (Atlanta, Georgia, United States, February 26 -
March 01, 1998). D. Joyce and J. Impagliazzo, Eds. SIGCSE '98. ACM, New
York, NY, 267-271.

Pillay, N. (2003). Developing intelligent programming tutors for novice


programmers. SIGCSE Bull. 35, 2 (Jun. 2003), 78-82.

Pita, Sara T. O. (2008). As interacções no Second Life: a comunicação entre


avatares. Prisma.com 6, ISSN 1646-3153, 19-31.

Poikela, E. (2004). Developing criteria for knowing and learning atwork: towards
context-based assessment. Journal of Workplace Learning, 16, 5, 267–274.

Porter, C. E. (2004). A typology of virtual communities: a multi-disciplinary


foundation for future research. Journal of Computer-Mediated Communication, 10,
1, Article 3.

Powers, K., Ecott, S., and Hirshfield, L. (2007). Through the Looking Glass:
Teaching CS0 with Alice. 38th SIGCSE Technical Symposium on Computer Science
Education, pp. 213-217, 2007.

Preece, J. (2000) Online Communities - Designing Usability, supporting sociability.


Chichester: John Wiley & Sons, 439 p, 2000.

Prensky M (2001), Digital game-based learning, New York: McGraw-Hill.

Price, B. A., Baecker, Ronald M. and Small, Ian S. (1993). A principled taxonomy of
software visualization. Journal of Visual Languages and Computing, 4(3):211– 266.

Quilici, A. E. E Miller, L. H. (1989). The Turbo C(r) Survival Guide. John Wiley &
Sons; 1 edition.

Raine, D. and Symons, S. (2005). Experiences of PBL in physics in UK higher


education. Poikela, E.; Poikela, S. (eds.). PBL in Context - Brindging work and
education. p. 67-79.

263
Ralston, A. (1971). Fortran and the first course in computer science. SIGCSE
Bulletin, 3(4):24–29.

Ramadhan, H. A. (2000). Programming by discovery. Journal of Computer Assisted


Learning, 16, 83-93.

Rebelo, B. (2007). SICAS-COL - Um Sistema Colaborativo para Aprendizagem Inicial da


Programação. Tese de Mestrado, Universidade de Coimbra – Departamento de
Engenharia Informática, Janeiro.

Rebelo, B. and Mendes, A. and Marcelino, M. and Redondo, M.(2005). Sistema


Colaborativo de Suporte à Aprendizagem em Grupo da Programação –
SICAS-COL. VII Simpósio Internacional de Informática Educativa. Leiria,
Novembro 2005.

Rebelo, B., Marcelino, M. J., Mendes, A. J. (2005). Evaluation and utilization of


SICAS – a system to support algorithm learning, In Proceedings of CATE05 –
Computers and Advanced Technology in Education, Oranjestad, Aruba, August,
2005.

Redondo, M., Bravo, C., Ortega, M., Verdejo, M., (2002). PlanEdit: An adaptive
tool for design learning by problem solving. In P. De Bra, P. Brusilovsky y R.
Conejo (Eds.), Adaptive Hypermedia and Adaptive Web Based-Systems, 2nd
International Conference of Adaptive Hypermedia and Adaptive Web- Based Systems, pp.
560-563.

Reges, S. (2006). Back to basics in CS1 and CS2. In Proceedings of the 37th SIGCSE
Technical Symposium on Computer Science Education, pages 293–297. ACM Press,

Reis, C. and Cartwright, R. (2004). Taming a Professional IDE for the Classroom.
In SIGCSE’04, (Norfolk, Virginia, USA, 2004), ACM, 156-160.

Reis, F. L. (2008). Formas de comunicação no ensino e-learning. Pensamento Plural:


Revista Científica do UNIFAE, São João do Boa Vista, V.2, n. 2 pp 5-15.

Rekkedal T. (1983). The written assignments in correspondence education. Effects


of reducing turnaround time. Distance Education, 4, 231-250

Reuters. (2003). Video game hones US soldiers’ fighting skills, The Straits Times, May 17
2003

Reynolds, A. (1992). What is competent beginning teaching? A review of the


literature. Review of Educational Research, 62 (1), 1-35.

Riding, R. J. (1980). Aprendizagem escolar – Mecanismos e processos. Lisboa. Ed. Livros


Horizonte.

Rijo, R. (2008). Framework para a Gestão de Projectos de Sistemas de Informação


de Contact Centers. Tese de doutoramento.

Robbert, M. A. (2000). Enhancing the value of a project in the database course.


SIGCSE Bull. 32, 1 (Mar. 2000), 36-40.

264
Robbins, S. (2007). A futurist’s view of Second Life education: a developing
taxonomy of digital spaces. In D. Livingstone & J. Kemp (Eds), Proceedings of
the Second Life EducationWorkshop 2007 (pp. 27–33). Chicago, IL. Consultado a
5 de Maio de 2008, em www.simteach.com/slccedu07proceedings.pdf

Roberts, E. S. (1993). Using C in CS1: evaluating the Stanford experience. In


Proceedings of the 24th SIGCSE Technical Symposium on Computer Science Education,
pages 117–121. ACM Press.

Robins, A., Rountree, J., and Rountree, N., (2003). Learning and teaching
programming: a review and discussion. Computer Science Education, 13(2):137–
172.

RöBling, G. e Freisleben, B. (2001). AnimalScript: An Extensible Scripting


Language for Algorithm Animation, In Proceedings of the 32nd SIGCSE Technical
Symposium on Computer Science Education. Charlotte, NC USA.

RöBling, G., Joy, M., Moreno, A., Radenski, A., Malmi, L., Kerren, A., Naps, T.,
Ross, R.J., Clancy, M., Korhonen, A., Oechsle, R. e Iturbide, J. A. (2008).
Enhancing learning management systems to better support computer science
education. SIGCSE Bull. 40, 4 (November 2008), 142-166.

Rocha, A. A. (2006). Introdução à Programação usando C. Lidel- edições técnicas, lda.

Rocha, A. A. (2008). Estruturas de dados e algoritmos em C. Lidel- edições técnicas, lda.

Rodger, S. H., Bashford, M., Dyck, L., Hayes, J., Liang, L., Nelson, D., and Qin, H.
(2010). Enhancing K-12 education with alice programming adventures. In
Proceedings of the Fifteenth Annual Conference on innovation and Technology in Computer
Science Education (Bilkent, Ankara, Turkey, June 26 - 30, 2010). ITiCSE '10.
ACM, New York, NY, 234-238.

Rodrigo, M. M. T., Baker, R. S. J., Sugay, J. O. and Tabanao E. (2009). Monitoring


novice programmer effect and behaviours to identify learning bottlenecks. In
Philippine Computing Society Congress: Research-in-Progress, March 2009.

Rosedale, Philip; Ondrejka, Cory R. (2003). Enabling Player-Created Online Worlds with
Grid Computing and Streaming. Gamasutra. Consultado em 27 de Maio de 2009
em
http://www.gamasutra.com/resource_guide/20030916/rosedale_01.shtml

Rößling, G. and Naps, T. L. (2002). A Testbed for Pedagogical Requirements in


Algorithm Visualizations. Proceedings of the 7th Conference on Innovation and
Technology in Computer Science Education (ITiCSE 2002). (Århus, Denmark).ACM
Press, New York, NY, USA, 2002, 96-100.

Roubidoux, M. A., Chapman, C. M., Piontek, M. E. (2002). Development and


evaluation of an interactive web-based breast imaging game for medical
students. Academic Radiology, 9 (10), 1169-1178.

Roy, P. V. e Haridi, S. (2003). Concepts, Techniques, and Models of Computer Programming.


The MIT Press, Cambridge, Massachusetts, London, England.

265
Rymaszewski, M., Au, W. J., Wallace, M. Winters, C., Ondrejka, C., Cunningham, B.
(2007). Second Life the official guide. Jonhn Wiley & Sons, Inc., Hoboken, New
Jersey.

Salleh, N., Mendes, E., Grundy, J., and Burch, G. S. (2010). An empirical study of
the effects of conscientiousness in pair programming using the five-factor
personality model. In Proceedings of the 32nd ACM/IEEE international Conference
on Software Engineering - Volume 1 (Cape Town, South Africa, May 01 - 08,
2010). ICSE '10. ACM, New York, NY, 577-586.

Salmon, G. (2009). The future of Second Life and learning. British Journal of
Educational Technology. 40(3), 526-538.

Salmon, G. e Hawkridge, D. (2009). Editorial: out of this world. British Journal of


Educational Technology, 40, 3, 401–413.

Sanders, D. and Dorn, B. (2003). Jeroo: a tool for introducing object-oriented


programming. In Proceedings of the 34th SIGCSE Technical Symposium on Computer
Science Education (Reno, Navada, USA, February 19 - 23, 2003). SIGCSE '03.
ACM, New York, NY, 201-204.

Santos, P. S. and Travassos, G. H. (2009). Action research use in software


engineering: An initial survey. In Proceedings of the 2009 3rd international
Symposium on Empirical Software Engineering and Measurement (October 15 - 16,
2009). Empirical Software Engineering and Measurement. IEEE Computer
Society, Washington, DC, 414-417.

Savery, J. R. and Duffy, T. M. (1995). Problem based learning: An instructional


model and its constructivist framework. Educational Technology, 35(5), 31-38.

Schein, Edgar H. (2006). Kurt Lewin’s Change Theory in the Field and in the
Classroom: Notes Twoard a Model of Managed Learning, Web page at
http://www.a2zpsychology.com/ARTICLES/kurt_lewin's_change_theory.ht
m, consultada a 24 de Outubro de 2007

Schmidt, Henk G. and Moust, Jos H. C. (2001). Factors Affecting Small-Group


Tutorial Learning: A Review of Research. In B. Duch, S. E. Groh, & D. E.
Allen (Eds.) The power of problem-based learning: A practical “how to” for teaching
undergraduate courses in any discipline (pp. 17-51). Sterling, Virginia, 2001, Stylus
Publishing.

Schneider, G. M. (1978). The introductory programming course in computer


science: ten principles. In Papers of the SIGCSE/CSA Technical Symposium on
Computer Science Education (Detroit, Michigan, February 23 - 24, 1978). ACM,
New York, NY, 107-114.

Schnotz, W., Rasch, T. (2005). Enabling, facilitating, and inhibiting effects of


animations in multimedia learning: why reduction of cognitive load can have
negative results on learning. Educational Technology Research and Development 53
(3), 47–58

266
Schroeder, R. (1996). Possible worlds: The social dynamic of virtual reality technology.
Boulder, CO. & Oxford: Westview Press

Schulte, C. and Bennedsen, J. (2006). What do teachers teach in introductory


programming?. In Proceedings of the Second international Workshop on Computing
Education Research (Canterbury, United Kingdom, September 09 - 10, 2006).
ICER '06. ACM, New York, NY, 17-28.

Schweitzer, D. and Brown, W. (2009). Using visualization to teach security. J.


Comput. Small Coll. 24, 5 (May. 2009), 143-150

Second Life (2006), Second Life Web site, consultado em http://www.secondlife.com


a 30 Outubro, 2006.

Sells, C., Flanders, J. and Griffiths, I. (2003). Mastering Visual Studio.NET. O'Reilly
Media; 1st edition

Senge, P. Mmmabe, N. Lucas, T. Kleiner, A. Dutton, J. and Smith, B. (2000). Schools


that learn: A Fifth Discipline Fieldbook for educators, Parents, and Everyone Who Cares
About Education. New York.

Sheard, J., Simon, S., Hamilton, M., and Lönnberg, J. (2009). Analysis of research
into the teaching and learning of programming. In Proceedings of the Fifth
international Workshop on Computing Education Research Workshop (Berkeley, CA,
USA, August 10 - 11, 2009). ICER '09. ACM, New York, NY, 93-104.

Shivers, O. (2008). Why teach programming languages. SIGPLAN Not. 43, 11


(Nov. 2008), 130-132.

Shneiderman, B. (1983). Direct manipulation: a step beyond programming


languages. IEEE Computer, Vol. 16, , 57-69.

Simon, B., Anderson, R., Hoyer, C., and Su, J. (2004). Preliminary experiences with
a tablet PC based system to support active learning in computer science
courses. In Proceedings of the 9th Annual SIGCSE Conference on Innovation and
Technology in Computer Science Education (ITiCSE’04). ACM, 213–217.

Skinner, B. F. (1983) A Matter of Consequences: Part 3 of an Autobiography.

Slator, B. M., Hill, C. and Del Val, D. (2004) Teaching computer science with virtual
worlds. IEEE Transactions on Education 47(2), pp. 269-275.

Sloane, K. D. and Linn, M. C. (1988). Instructional Conditions in Pascal


Programming Classes. In R. E. Mayer (ed.), Teaching and Learning Computer
Programming, p.207-235. Hillsdale, NJ: Lawrence Erlbaum Associates.

Smart, J., Cascio, J. e Paffendorf, J. (2007) Metaverse Roadmap 2007: Pathways to the 3D
Web. A Cross-industry Public Foresight Project. Consultado a 27 de Janeiro de 2008
em: www.metaverseroadmap.org

Smith, M. K. (2001) Donald Schön: learning, reflection and change, the encyclopedia of
informal education, www.infed.org/thinkers/et-schon.htm

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

268
Stinson, J. E.; Milter, R. G. (1996). Problem-based Learning in business education:
curriculum design and implementation. Wilkerson, L.; Gijselaers, W.H. (Ed.).
Bringing Problem-based Learning to higher education. San Francisco: Jossey-Bass
Publishers. p.33-42.

Storey, M.-A., Damian, D., Michaud, J., Myers, D., Mindel, M., German, D.,
Sanseverino, M. and Hargreaves, E. (2003). Improving the usability of Eclipse
for novice programmers. In Proceedings of the 2003 OOPSLA Workshop on
Eclipse Technology Exchange, pages 35–39. ACM.

Sun Microsystems, (2009). NetBeans. Disponível em http://edu.netbeans.org/bluej,


consultado a 7 de Novembro de 2009.

Sutinen, E., Tarhio, J., Lahtinen, S., Tuovinen, A., Rautama, E. e Meisalo, V. (1997).
Eliot – an Algorithm Animation Environment. University of Helsinki,
Department of Computer Science, Series of Publications A, No A-1997-4.

Tan, L., Wang, M. e Xiao, J. (2010). Best practices in teaching online or hybrid
courses: a synthesis of principles. In Proceedings of the Third international conference
on Hybrid learning (ICHL'10), Philip Tsang, Simon K. S. Cheung, Victor S. K.
Lee, and Ronghuai Huang (Eds.). Springer-Verlag, Berlin, Heidelberg, 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.

269
Tversky, B., Morrison, J. B., Betrancourt, M., (2002). Animation: can it facilitate?
International Journal of Human-Computer Studies. 57, 247-262.

Twining, P. (2009). Exploring the educational potential of virtual worlds—Some


reflections from the SPP. British Journal of Educational Technology. 40 (3), 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.

270
Virtanen, A., Lahtinen, E., and Järvinen, H.-M. (2005). VIP, a visual interpreter for
learning introductory programming with C++. In Proceedings of the 5th Koli
Calling Conference on Computer Science Education (KOLI’05). 125–130.

Vogts, D., Calitz, A. e Greyling, J. (2008). Comparison of the effects of professional


and pedagogical program development environments on novice
programmers. In Proceedings of the 2008 annual research conference of the South
African Institute of Computer Scientists and Information Technologists on IT research in
developing countries: riding the wave of technology (SAICSIT '08). ACM, New York,
NY, USA, 286-095.

Vygotsky, L. S. (1978). Mind in society: The development of higher psychological processes.


Boston, MA: Harvard University Press.

Vygotsky, L. S. (1979). Pensamento e Linguagem. Lisboa, Edições Antídoto.

Vygotsky, L. S. (1981). The genesis of higher mental functions. Em J. V. Wertsch


(Red.), The concept of activity in soviet psychology .(pp. 144-188). Armonk, NY: M.
E. Sharpe.

Wagner (2008). Learning Experience with Virtual Worlds. Journal of Information


Systems Education. 19(3). 263-266

Walsh, L. N., Howard, R. G., and Bowe, B (2007). Phenomenographic study of


students’ problem solving approaches in physics. Phys. Rev. ST Phys. Educ. Res.
3, 2.

Warburton, S. (2009). Second Life in higher education: Assessing the potential for
and the barriers to deploying virtual worlds in learning and teaching. British
Journal of Educational Technology. 40 (3), 414-426.

Warburton, S., Perez-Garcia, M. (2009). 3D design and collaboration in massively


multi-user virtual environments. In D. Russel (Ed.), Cases on collaboration in
virtual learning environments: processes and interactions. Hershey, PA: IGI Global.
Forthcoming April 2009

Watson, J. B. (1913). Psichology as the Behaviorist sees it. Psichological Review, 20, pp.
158-177.

Watson, J. B. (1928). Psychological Care of Infant and Child. New York: W. W. Norton
Company, Inc.

Wellington, C. A.; Briggs, T. H. and Girard, C. D. (2007). Experiences using


automated tests and test driven development in computer science I. In
AGILE '07: Proceedings of the AGILE 2007 Conference. pages 106-112.

Weng, K. S. (1975). Stream oriented computation in recursive data-flow schemas.


Tech. Rep. 68. Laboratory for Computer Science, MIT, Cambridge, MA.

Wenger, E. (1998). Communities of Practice, Learning, Meaning, and Identity. USA:


Cambridge University Press

271
Wilkes, M. (1985). Memoirs of a Computer Pioneer. The MIT Press.

Williams, D. J. and Noyes, J. M. (2007). Effect of experience and mode of


presentation on problem solving. Computers in Human Behavior 23(1), 258-274.

Williams, L., Kessler, R. R., Cunningham, W., AND Jeffries, R. (2000).


Strengthening the case for pair programming. IEEE Softw. 17, 4, 19–25.

Wilson, M. (2010). CEO, There.com. http://www.there.com/info/announcement.


Consultado a 12 de Março de 2010.

Winn, W. (2002). Current trends in educational technology research: The study of


learning environments. Educational Psychology Review, 14(3), 331 – 351

Winslow, L. E. (1996). Programming pedagogy – A psychological overview.


SIGCSE Bulletin 28, 17–22.

Wirth, N. (1993). Recollections about the development of Pascal. In the Second ACM
SIGPLAN Conference on History of Programming Languages (Cambridge,
Massachusetts, United States, April 20 - 23, 1993). HOPL-II. ACM, New
York, NY, 333-342.

Woods, D. (2001). They just don’t pull their weight. Schwartz, P.; Mennin, S.;
Webb, G. (Ed.). Problem-based Learning: case studies, experience and practice.
Londres: Kogan Page. p.163-170.

World of Warcraft (2006), World of Warcraft Web site, consultado em


http://www.worldofwarcraft.com/index.xml, a 30 Outubro, 2006.

Wu, P. (2009). Teaching basic game programming using JavaScript. J. Comput. Small
Coll. 24, 4 (Apr. 2009), 211-220.

Xinogalos, S.; Satratzemi, M. and Dagdilelis, V. (2006). An introduction to 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.

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

273
12. Anexos I

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

274
275
Fonte de dados Denominação Código

Mensagens escritas trocadas


Registos electrónicos entre professora e os alunos Reg.
durante as aulas

Questionário inicial QuestI.


Questionários Questionário intermédio QuestInt.

Questionário final QuestF.

Entrevistas informais Conversas informais com


Ent.
prioridade mensal

Alunos de: Os alunos, de cada unidade


curricular, são designados
Proj. I (1º e 2º ciclo)
pela 1º letra do nome do seu
Aluno S
Lab. II (1º e 2º ciclo) avatar.
Lab. I (3º e 4º ciclo)

Alunos de: Os alunos de cada unidade


curricular são designados
Lab. I Aluno 1
por números.
Lab. III

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

276
277
13. Anexos II

Planos das aulas no mundo virtual Second Life

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

Actividade Preliminar

Realizadas entre Março e Junho de 2007, na qual participaram 5 alunos da licenciatura em


Informática da UTAD.

O enunciado do projecto teve por objectivo que os alunos aprendam a:

 manipulação de estruturas de dados;


 troca de informação entre objectos;
 manipular estruturas de controlo;
 estruturar o código;
 desenvolver e aplicar funções, implementadas pelos alunos assim como as pré-
definidas da linguagem.

Para além de os alunos se focarem nestas técnicas base, pretendeu-se igualmente ampliar a
complexidade das técnicas a dominar por estes, nomeadamente, o lançamento de respostas
a eventos.

A tabela seguinte apresenta o plano das aulas previstas para os alunos de Lab. I

280
Semana Plano Projecto: cão BOBI
Apresentação do mundo virtual
Second Life (SL).
1
Criar e personalizar um avatar.
Adaptação ao SL.
Criar e modelar objectos. Fazer a
2 Primeiro esboço do cão.
ligação de objectos.
Introdução à linguagem LSL.
Sintaxe, operadores e variáveis.
Associar um script ao cão; comunicação
3 Exemplos de output utilizando o
pelo canal público.
canal de público.
Estruturas de controlo.
Estados: estados pré-existentes,
criar novos estados, transições entre
Colocar o cão em vários estados distintos.
estados.
Reacção do cão a eventos, como, por
4 Funções: exemplos de funções pré-
exemplo, acções do rato, actualizar o
existentes, criação de novas funções.
estado interno e modificar propriedades
Eventos: exemplos de event
que permitem realizar um determinado
handlers pré-existentes.
comportamento, como alterar cor ou
Continuação da aula anterior.
alterar a sua posição.
5 Colocar o robot a seguir o seu
dono
Comunicação entre objectos: envio
e recepção de mensagens.
6 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 Execução das ordens recebidas.
recebe do seu dono.
Fazer o parse das mensagens
7
recebidas.
Identificar os token que impliquem
uma tarefa para o robot executar.

Continuação da aula anterior Efectuar a rotação do cão para a direita e


8
Rotação de objectos. para a esquerda.

Criar um canal de comunicação entre o


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

281
Semana Plano Projecto: cão BOBI
Envio de mensagens para um
11 endereço de email. Leitura de
informação em notecards.
Envio de emails ao dono
12 Conclusão do projecto.

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

Actividade Preliminar

Realizadas entre Março e Junho de 2007, na qual participaram 4 alunos da licenciatura em


Informática da UTAD.

Os objectivos de aprendizagem do enunciado do projecto de Lab. III incluíam, para além


da revisão das técnicas de programação aprendidas anteriormente, centrarem-se nos
seguintes aspectos:

 na manipulação de estruturas de dados, tais como listas e strings;

 na manipulação de informação, nomeadamente a explorar as técnicas de canais de


comunicação e o envio de mensagens através de e-mails;

 no lançamento e resposta a eventos;

 na execução concorrente de código num mesmo objecto;

 na gestão de máquina de estados;

 no uso de temporizadores e de sensores virtuais.

Semana Plano Projecto: Robot Alf


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

283
Plano Projecto

Colocar o robot à escuta de comandos do dono


(owner) e a reagir a comandos direccionados do dono
para o robot nomeadamente mover o robot para a
frente e para trás.
Troca de mensagens entre Comunicação entre objectos: envio e recepção de
4 objectos; Lançamento e mensagens. Comunicação entre o canal de chat e os
resposta a eventos objectos: reacção de objectos a comandos.
Pôr o robot a executar as tarefas que recebe do seu
dono.
Fazer o parse das mensagens recebidas. Identificar os
token que impliquem uma tarefa para o robot executar.
Criar um canal de comunicação entre o robô e o seu
dono. Por o robô a enviar a mensagem "estou com
fome" ao dono como resposta ao evento tempo
Introdução aos estados; Criar
Completar as funcionalidades do robot no que diz
5 e mudar de estados;
respeito ao temporizador.
temporizadores
- No fim de 3h sem comer salta;
- Passado 4h sem comer muda de cor;
- Por fim desliga-se.
Temporizadores, continuação;
6 Sensores: detecção de avatares e objectos num
Introdução aos sensores
determinado raio de acção
Colocar o robot a detectar obstáculos e a desviar-se
Sensores, detectar e desviar de destes.
7
obstáculos

Guardar nessa lista a identificação dos vários objectos


Listas, inserir, retirar que o sensor foi detectando. Guardar as mensagens
8
informação de uma lista trocadas entre o robot e o seu dono.
Criar 4 robot. Designar um deles como sendo o chefe
Execução concorrente de do grupo, os restantes passan a executar as ordens
9
código num mesmo objecto dadas por este. O chefe do grupo só recebe ordens do
seu dono e transmite aos restantes.

Enviar informação através de Dispor os robot de modo a formarem um triangulo


10
email Colocar os robots a seguirem o movimento do chefe
do grupo
Programar o robot para executar uma sequência de
tarefas:
11 Continuação o robot chefe executa as instruções previamente
construídas num notecard e dá ordens aos outros
elementos
Tornar o robot num humanóide não só de aspecto
12 Conclusão do projecto mas também no movimento de braços e pernas.

284
Plano das aulas de Projecto I

Primeiro e segundo ciclos

Realizadas entre Outubro de 2007 e Janeiro de 2008, no qual participaram os alunos da


ESTG.

Pretendeu-se que estes alunos aprendessem a programar através de interacções físicas, pelo
que o enunciado foi semelhante ao desenvolvido pelos alunos de Lab. I (projecto visual),
embora com um grau de dificuldade um pouco superior. Com este trabalho pretendeu-se
que os alunos estudassem e praticassem os seguintes conceitos:

 Variáveis;

 Manipulação de estruturas de dados, tais como lists e strings;

 Troca de informação entre objectos;

 Manipulação de estruturas de controlo;

 Estruturação do código;

 Desenvolvimento e aplicação de funções, implementadas pelos alunos assim


como as pré-definidas da linguagem.

Semana Plano

Apresentação do mundo virtual Second Life (SL). Apresentação dos vários


1
enunciados do projecto; Criar e personalizar um avatar.

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

3 Criar e modelar os objectos do projecto;

285
Semana Plano

Introdução à linguagem Linden Sripting Language (LSL). Revisões dos


conceitos base
4
Sintaxe, operadores e variáveis. Exemplos de output utilizando o canal de
chat. Estruturas de controlo.

Estados: estados pré-existentes, criar novos estados, transições entre


5 estados.
Funções: exemplos de funções pré-existentes, criação de novas funções.

Continuação da aula anterior.


Colocar o robot a seguir o seu dono;
6
Eventos: exemplos de event handlers pré-existentes.
Entrega do algoritmo.
Comunicação entre objectos: envio e recepção de mensagens.
Comunicação entre o canal de chat e os objectos: reacção de objectos a
7 comandos.
Entrega da primeira fase do trabalho (envio de mensagem ao cão pelo
dono)

Pôr o cão ou Boneco de neve a executar as tarefas que recebe do seu dono
(temporizador).
8
Fazer o parse das mensagens recebidas.
Identificar os token que impliquem uma tarefa para o robot executar.

Continuação da aula anterior


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

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

Continuação do desenvolvimento do projecto.


Entrega da 3 fase (funcionalidades bolas ar ao fim 4 h sem comer,
11
desligar-se);
Envio de mensagens para o dono por email;
Implementação da segunda parte do projecto;
12
Listas: guardar a quantidade de vendas efectuadas;

13 Conclusão do projecto

286
Plano das aulas de Laboratório Informático II

Primeiro e segundo ciclos

Realizadas entre Outubro de 2007 e Janeiro de 2008, no qual participaram os alunos da


UTAD.

Os objectivos de aprendizagem deste projecto centrarem-se, para além da revisão das


técnicas de programação aprendidas anteriormente, nos seguintes aspectos:

 Na manipulação de estruturas de dados, tais como lists e strings;

 Na manipulação de informação, nomeadamente a exploração de técnicas de canais de


comunicação e o envio de mensagens através de e-mails;

 Na gestão de máquina de estados.

Semana Plano

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


1
avatar.

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

Introdução à linguagem Linden Sripting Language (LSL). Revisões dos


conceitos base
3 Sintaxe, operadores e variáveis. Exemplos de output utilizando o canal de
chat. Estruturas de controlo
Entrega do algoritmo.

Comunicação entre objectos: envio e recepção de mensagens.


4 Comunicação entre o canal de chat e os objectos: reacção de objectos a
comandos. Eventos, criar funções no LSL

Estados: estados pré-existentes, criar novos estados, transições entre


5 estados.
Entrega da primeira fase do projecto.

287
Semana Plano

Continuação da aula anterior.


6
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

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

11 Conclusão do Projecto

288
Plano das aulas de Laboratório Informático I

Terceiro e quarto ciclos

Realizadas entre Março e Junho de 2008, no qual participaram os alunos da UTAD.

Este projecto teve por objectivo que os alunos aprendessem a:

 Manipular as estruturas de dados;

 Trocar informação entre objectos;

 Manipular estruturas de controlo;

 Estruturar o código;

 Desenvolver e aplicar funções, implementadas pelos alunos assim como as


pré-definidas da linguagem.

Para além de os alunos se focarem nestas técnicas base, pretendeu-se igualmente ampliar a
complexidade das técnicas a dominar por estes, nomeadamente, o lançamento de respostas
a eventos.

Semana Plano

1 Apresentação do projecto

Apresentação do mundo virtual Second Life (SL) na UTAD. Criar e


2 personalizar um avatar. Criar e modelar objectos. Fazer a ligação de
objectos.
Introdução à linguagem Linden Sripting Language (LSL).
3 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

289
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

290
291
14. Anexos III

Enunciado dos projectos desenvolvidos pelos alunos no mundo


virtual Second Life.

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

Laboratório de Informática I

Trabalho Prático

Data de entrega:22 de Junho de 2007


NOTA: O trabalho deve ser entregue através do SIDE.

Cão “Bobi”

Resumo

No mundo virtual Second Life (www.secondlife.com), foi reservado um terreno para


criação de uma loja virtual, nas coordenadas:

http://slurl.com/secondlife/Cocaine%20Island/126/199/22.

Neste mundo virtual pretende-se construir um robô com a forma de um cão: “Bobi”, que
se desloca pelo mundo seguindo o respectivo dono. O “Bobi” deve ser colocado na loja
virtual em exposição. Quando algum avatar quiser adquirir o “Bobi”, este deve registar a
chave do seu novo dono, passando a obedecer exclusivamente às ordens enviadas por este.

Descrição da aplicação

Os alunos devem criar um objecto com a forma de um cão e atribuir-lhe um nome, por
exemplo “Bobi”. Este, cão, deve ser desenvolvido no Second Life, utilizando os objectos
disponíveis no mesmo (prims). O desenvolvimento do cão deve decorrer, no terreno
referido anteriormente ou em locais públicos (sandboxes), como a Sandbox Morris, por
exemplo:

http://slurl.com/secondlife/sandbox%20Morris\224\137\21

Quando estive pronto, o cão deve ser colocado em exposição na loja virtual acima referida.
Quando alguém o adquirir, o “Bobi” deve captar a chave do futuro dono e a partir desse
momento só obedece às ordens deste.

294
Funcionalidades a implementar

O “Bobi” precisa de ser alimentado de 3 em 3 horas. A alimentação consiste em bolinhas


de ração que o dono do Bobi lhe fornece sempre que toca nele. Assim, o nome do
comando “Touch” deve ser alterado para “Comida”. O “Bobi” é responsável por controlar
os intervalos de tempo em que é alimentado. Desta forma, sempre que passarem 3 horas
sem ser alimentado, o Bobi deve avisar o dono de que está com fome, por exemplo
enviando-lhe uma mensagem. Se as suas preces não forem atendidas, começa a saltar. Ao
fim de 4 horas sem ser alimentado, o “Bobi” pára e envia bolas de saliva para o ar. Por fim,
se continuar sem ser alimentado, o “Bobi” desliga-se (ou seja: fica inactivo).

O “Bobi” unicamente obedece às instruções do seu dono. Sempre que outra pessoa lhe
tocar ele ladra, ou seja envia a seguinte mensagem para o canal público: “Bau, Bau”.

De cada vez que o “Bobi” recebe uma instrução do seu dono, este deve executá-la. As
instruções são mensagens que o “Bobi” recebe e as executa como, por exemplo:

dono – stop .

Acção do “Bobi” - deixa de seguir o dono e pára.

dono – frente 5

Acção do “Bobi” - desloca-se 5 passos para a frente

dono – direita 90

Acção do “Bobi” - roda sobre si mesmo 90º para a direita.

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

Podem ser adicionadas ao “Bobi” outras funcionalidades que considerar interessantes.

295
Licenciatura em Informática Licenciatura em Tecnologias de Informação e Comunicação
Laboratório de Informática III
Trabalho Prático

Data de entrega: dia 18 de Junho de 2007

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

Exploração de rede ferroviária virtual

Resumo

No mundo virtual Second Life (www.secondlife.com), foi reservado um terreno para as


disciplinas Laboratório de Informática III e Laboratório de Tecnologias de Informação e Comunicação,
em:

http://slurl.com/secondlife/Cocaine%20Island/126/199/22.

Neste mundo virtual pretende-se simular o funcionamento de uma linha férrea que faça a
ligação entre duas cidades. Entre estas cidades existem várias indústrias (ex.: madeira, papel,
exploração petrolífera). Nesta linha circulam dois comboios, que vão recebendo mensagens
das estações que existem nas cidades e nas indústrias. Cada comboio deve processar essas
informações e saber onde tem de parar para receber/descarregar mercadorias. A linha pode
ter pontos de cruzamento entre comboios, com semáforos que lhes controlam o
movimento.

Descrição dos componentes a desenvolver

Este trabalho é constituído por: dois comboios de mercadorias; três indústrias (ex.:
madeira, papel, exploração petrolífera); duas cidades; cinco estações de comboios; e duas
linhas ferroviárias. Depois de montado, deve ocupar, no máximo, 100 m2 . dentro do
ambiente virtual Second Life, utilizando os objectos disponíveis no mesmo (prims).

Cada cidade é constituída por um conjunto de edifícios, cujo número de andares por
edifício deve variar entre 2 a 10. Cada cidade deve ocupar no máximo 20 m2.

Cada comboio deve ter uma locomotiva, que puxa quatro carruagens de mercadorias, para
transportar os produtos (cada carruagem só pode transportar um tipo de produto).

296
As estações de comboios são pequenos edifícios, constituídos por um só andar, que devem
ser colocados ao longo da linha férrea, indicando o ponto no qual o comboio deve parar.

Cada indústria deve ocupar, no máximo, 10 m2 , sendo constituída por um ou dois edifícios
a condizer visualmente com a respectiva actividade.

A linha ferroviária deve ser colocada de modo a ligar as duas cidades e as indústrias. A linha
deve ter pontos de cruzamento nos quais serão colocados semáforos para controlar o
tráfego.

Todo o desenvolvimento do trabalho deve decorrer em locais públicos (“sandboxes”),


como a Sandbox Morris, por exemplo:

http://slurl.com/secondlife/sandbox%20Morris\224\137\21

Quando o trabalho estiver pronto, deve ser colocado em exposição no terreno acima
referido, em local próprio para o efeito (contactar um dos docentes para o efeito).

Funcionalidades a implementar

• Cada comboio deve ter as seguintes funcionalidades:

o Receber os pedidos de cada cidade sobre as necessidades de papel, madeira e


petróleo que estas têm. Estes pedidos podem ser recebidos directamente ou
estarem descritos num notecard.

o Identificar os produtos que lhe foram pedidos e entregá-los por ordem das
cidades pelas quais vai passar.

o Saber onde parar e a quantidade de produtos que pode transportar.

o Quando o comboio está cheio deve avisar as indústrias que não pode parar.

o Enviar para o dono do comboio, no fim do dia, um relatório com os produtos


transportados e entregues.

o Sempre que um comboio não tenha mercadorias para transportar não deve
circular.

• Cada cidade deve ter uma estação ferroviária na qual o comboio descarrega os produtos
de que esta necessita. Deve ter um notecard com a descrição e a quantidade de produtos
de que necessita.

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

298
Licenciatura em Informática Licenciatura em Tecnologias de Informação e Comunicação
Laboratório de Informática III
Trabalho Prático

Data de entrega: dia 18 de Junho de 2007

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

Robô “Alf”

Resumo

No mundo virtual Second Life (www.secondlife.com), foi reservado um terreno para as


disciplinas Laboratório de Informática III e Laboratório de Tecnologias de Informação e Comunicação,
em:

http://slurl.com/secondlife/Cocaine%20Island/126/199/22

Neste mundo virtual pretende-se construir quatro robôs: “Alf”,”Alf1”, ”Alf2” e ”Alf3” que
se desloquem livremente e sigam o respectivo dono. Estes robôs devem comportar-se
como um só: há um chefe do grupo (Alf) que recebe ordens do dono (avatar) e as
transmite aos restantes.

Pretende-se que este grupo de robôs seja colocado na loja virtual. Quando algum avatar
comprar o robô-chefe Alf, este deve registar a chave do novo dono, e só responder a
ordens enviadas por ele.

Descrição dos robôs a desenvolver

Os alunos devem criar 4 robôs humanóides, identificá-los e definir qual deles vai ser o
chefe do grupo. Cada robô deve ter uma altura máxima de 2m, tendo todos a mesma
estrutura física mas cores e/ou texturas diferentes. Estes robôs devem ser desenvolvidos
no Second Life, utilizando os objectos disponíveis no mesmo (prims).

Todo o desenvolvimento do trabalho deve decorrer em locais públicos (“sandboxes”),


como a Sandbox Morris, por exemplo:

http://slurl.com/secondlife/sandbox%20Morris\224\137\21

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

Funcionalidades a implementar

O Alf é o único que tem permissões para contactar o dono, sendo responsável por
transmitir aos restantes elementos as ordens recebidas. O dono por sua vez também só
necessita de interagir com o Alf.

Cada robô precisa de ser alimentado de 3 em 3 horas. A alimentação consiste em energia


que é passada do dono para o Alf quando este é tocado pelo seu dono. Assim, devem os
alunos alterar o nome do comando “Touch” do robô-chefe Alf para “Energizar”. Cada vez
que o Alf for alimentado, deve enviar uma mensagem aos restantes num canal privado, a
dizer “energia”: desta forma todos são alimentados.

O robô Alf2 é responsável por controlar os intervalos de tempo em que são alimentados.
Desta forma, sempre que passarem 3 horas sem serem alimentados, o Alf2 deve avisar o
Alf. O Alf por sua vez vai avisar o dono de que está com fome; se não for atendido, dá
ordens aos restantes robôs para começarem a saltar coordenadamente formando uma
onda. Ao fim de 4 horas sem serem alimentados, o Alf2 envia nova mensagem ao Alf, a
dizer “a energia está a esgotar-se”. O Alf dá ordens para mudarem de cor e o Alf3 indica
qual a cor que cada um deve ter.

Por fim, se continuarem sem ser alimentados, o Alf dá ordens para se desligarem (ou seja:
ficarem inactivos).

O Alf, que vai à frente dos outros robôs, sempre que no seu caminho aparecer um
obstáculo deve desviar-se dele; os outros robôs devem fazer o mesmo.

A programação dos robôs, para que executem uma sequência de tarefas, pode ser feita
directamente. Por exemplo:

dono – stop .
Alf deixa de seguir o dono e pára.
dono – frente 5
Alf desloca-se 5 passos para a frente
dono – direita 90
Alf roda sobre si mesmo 90º para a direita.

300
dono – quadrado
Alf e os restantes robot dispõem-se em formação, na forma de um quadrado.
Outra alternativa consistiria em escrever as instruções num notecard, que é lido pelo Alf, o
qual dá depois ordens aos restantes elementos.

O Alf1 tem a função de guardar as tarefas executadas pelo grupo ao fim de um dia de
trabalho: nessa altura envia por e-mail ao dono os locais que visitaram e as tarefas que
andaram a fazer.

Podem ser adicionadas ao Alf outras funcionalidades que considerar interessantes.

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

Trabalho Prático

Data de entrega: dia 9 de Janeiro de 2008

NOTA: O trabalho deve ser entregue através do SIDE.

Deve ser composto por:


relatório de modelação e especificação; código fonte; executável e ficheiros de apoio.

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

Introdução

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

Descrição informal:

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

302
Cada produto é vendido por um fornecedor. Para cada fornecedor é armazenado o seu
código de identificação, o nome, um endereço, um número de telefone, e o nº de
contribuinte. Os fornecedores, mensalmente, enviam para a farmácia um catálogo que além
de conter dados actualizados sobre os produtos disponibilizados, incluem informação
sobre novos produtos, a qual é enviada à direcção para apreciação. A “caixaGestão” da
farmácia é responsável por elaborar as notas de encomenda a enviar aos fornecedores. As
notas de encomenda são elaboradas tendo em conta a informação relativa aos produtos
existentes em armazém com uma quantidade inferior à quantidade de alarme, e a relação
dos novos produtos a adquirir enviada pela Direcção. Na nota de encomenda é indicado o
código de identificação, o nome do fornecedor, o seu endereço, e uma lista de produtos a
encomendar. Para cada produto é indicado a sua referência, o nome e a quantidade
pretendida. Ao elaborar a nota de encomenda “caixaGestão” tem sempre em conta a
quantidade de encomenda registada para o produto.

Os produtos enviados pelos fornecedores são acompanhados por uma factura e por uma
guia de remessa onde constam os seguintes dados: nome do fornecedor, nome da farmácia,
endereço da farmácia, nº de contribuinte, e para cada produto é indicado o seu nome e a
quantidade enviada. A guia de remessa é processada de forma a se proceder no sistema à
actualização da quantidade em armazém para cada um dos produtos que constam da
mesma, ou à inserção do produto no sistema quando se trata de um novo produto. A
factura é enviada à Contabilidade para se proceder ao seu pagamento.

Quando é realizada uma venda, é verificado se existe quantidade suficiente em armazém e


caso exista é processada a venda sendo actualizada a respectiva quantidade existente em
armazém. Quando a quantidade existente em armazém de um produto é inferior à
quantidade de alarme definido para o mesmo, o sistema envia um alerta.

Diariamente é enviada à Direcção uma lista contendo informação relativa a todos os


movimentos efectuados. Semanalmente é enviada uma lista dos produtos cuja quantidade
existente em armazém está a duas unidades da quantidade de alarme definida para o
mesmo. Mensalmente é enviada uma lista com os dez produtos mais vendidos e os dez
menos vendidos.

303
Objectivos

O programa deve permitir ao utilizador efectuar as seguintes actividades:

1. Efectuar a gestão de fornecedores (criação, alteração, eliminação).

2. Receber catálogos (ficheiros de texto) com dados de produtos novos e actualização


de produtos actuais.

3. Fazer encomendas (produzir ficheiros de texto com os dados das encomendas).

4. Receber encomendas (ficheiros de texto com dados dos produtos entregues no


armazém).

5. Processar vendas efectuadas no balcão (dar baixa no inventário e lançar alertas).

6. Produzir relatórios.

Orientação para o desenho da aplicação.

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

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

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

O script de gestão dos produtos deve ter:

• uma lista com os dados de todos os produtos (key, nome, quantidade, quantidade
mínima para repor stock, etc);

• dois estados: um no qual se processa toda a informação referente a recepção de


encomendas; outro para processar informação da venda dos produtos;

• a recepção de encomendas deve ser feito através de um notcard que o fornecedor


entrega.

O script de gestão dos fornecedores deve ter:

• uma lista com os dados dos fornecedores (nome, endereço, etc);

• três estados: um no qual se processa a gestão de fornecedores; outro para


receber catálogos; e outro para fazer as encomendas.

• O pedido das encomendas deve ser feito por e-mail.

O script que emite automaticamente os relatórios diários, semanais e mensais.

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

305
Exemplo: fornecedores.txt

código de identificação; nome; endereço; número de telefone; nº de contribuinte

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

Exemplo: produtos.txt

código de identificação; nome; tipo; referência; código do fornecedor; quantidade existente;


quantidade de alarme; quantidade de encomenda

Os dados dos movimentos da farmácia devem ser guardados num ficheiro


“movimentos.txt”, utilizando os identificadores “v:” para objectos da classe “venda” e “c:”
para objectos da classe “compra”, obedecendo ao seguinte formato:

Exemplo: movimentos.txt

v: código produto; nome do produto; quantidade; data do movimento

c: código produto; nome do produto; quantidade; data do movimento; código do


fornecedor; nome do fornecedor

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

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

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

Boneco de Neve

Resumo

No mundo virtual Second Life (www.secondlife.com), foi reservado um terreno em:

http://slurl.com/secondlife/Cocaine%20Island/126/199/22

Neste mundo virtual pretende-se construir um boneco de neve (BN) formado por duas
bolas, uma mais pequena que representa a cabeça e outra maior, o corpo do boneco. As
duas bolas devem ser colocadas uma em cima da outra de modo a formar um boneco de
neve. A cabeça e o corpo do boneco embora sobrepostos devem ter funcionalidades
diferentes, assim a cabeça do boneco funciona como receptor de mensagens, que depois de
as analisar dá ordens ao corpo para as executar. As mensagens são enviadas pelo dono do
boneco.

Descrição do boneco neve a desenvolver

Os alunos devem criar um boneco de neve formado por duas bolas sobrepostas. O boneco
deve ter uma altura máxima de 2m. Este boneco deve ser desenvolvidos no Second Life,
utilizando os objectos disponíveis no mesmo (prims).

O desenvolvimento do cão deve decorrer, no terreno referido anteriormente ou em locais


públicos (sandboxes), como a Sandbox Morris, por exemplo:

http://slurl.com/secondlife/sandbox%20Morris\224\137\21

307
Funcionalidades a implementar

O BN só recebe ordens do seu dono, sempre que outra pessoa lhe toca na cabeça, ele
escreve a seguinte mensagem: “Eu não sou teu!!” e passado alguns segundos apaga-a.

A cabeça do BN recebe as ordens do seu dono, sendo responsável por as analisar e


transmitir à barriga o que esta deve fazer. A cabeça do BN controla a tempo durante o qual
o seu dono está sem interagir com ele. Se passarem 3 horas sem brincadeira a cabeça do
BN escreve a mensagem “Brinca comigo”por cima da sua cabeça, envia um e-mail ao seu
dono a dizer “Eu gostaria muito que brincasses comigo” e simultaneamente altera a cor da barriga
para cinza escuro. Assim que o dono começar a brincar com o BN a mensagem deve ser
apagada e este voltar repor a cor original da barriga.

Sempre que o dono tocar na barriga do boneco esta começa a lançar bolas para o ar, ao ser
tocado novamente as bolas cessam. Assim, devem os alunos alterar o nome do comando
“Touch” da barriga do BN para “Bolas de sabão”.

O dono do BN pode interagir com o boneco enviando-lhe as seguintes mensagens através


do chat:

dono –Salta 3 vezes

A barriga do BN separa-se da cabeça e dá três saltos;

dono –Circulo

A barriga do BN desloca-se de modo a desenhar um circulo;

dono –Cumprimenta

O BN escreve a seguinte mensagem por cima dele: “Olá, como vai?”;

dono –Segue-me

O BN ( cabeça e barriga) segue o dono;

dono – stop .

BN deixa de seguir o dono e pára

Podem ser adicionadas ao BN outras funcionalidades que considerar interessantes

308
2ª Fase do trabalho prático

Agora que o BN está pronto para ser vendido, pretende-se que implementem uma loja
virtual no Second Life. O objectivo é construírem um balcão virtual que faça a gestão das
vendas. Assim o balcão deve registar os seguintes elementos:

• o número de BN existentes na loja;

• o nome do BN;

• a quantidade de BN vendidos;

• o preço de cada BN;

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

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

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

Cão “Bobi”

Resumo

No mundo virtual Second Life (www.secondlife.com), foi reservado um terreno para


criação de uma loja virtual, nas coordenadas:

http://slurl.com/secondlife/Cocaine%20Island/126/199/22.

Neste mundo virtual pretende-se construir um robô com a forma de um cão: “Bobi”, que
se desloca pelo mundo seguindo o respectivo dono. O “Bobi” deve ser colocado na loja
virtual em exposição. Quando algum avatar quiser adquirir o “Bobi”, este deve registar a
chave do seu novo dono, passando a obedecer exclusivamente às ordens enviadas por este.

Descrição da aplicação

Os alunos devem criar um objecto com a forma de um cão e atribuir-lhe um nome, por
exemplo “Bobi”. Este, cão, deve ser desenvolvido no Second Life, utilizando os objectos
disponíveis no mesmo (prims). O desenvolvimento do cão deve decorrer, no terreno
referido anteriormente ou em locais públicos (sandboxes), como a Sandbox Morris, por
exemplo:

http://slurl.com/secondlife/sandbox%20Morris\224\137\21

Quando estive pronto, o cão deve ser colocado em exposição na loja virtual acima referida.
Quando alguém o adquirir, o “Bobi” deve captar a chave do futuro dono e a partir desse
momento só obedece às ordens deste.

310
Funcionalidades a implementar

O “Bobi” precisa de ser alimentado de 3 em 3 horas. A alimentação consiste em bolinhas


de ração que o dono do Bobi lhe fornece sempre que toca nele. Assim, o nome do
comando “Touch” deve ser alterado para “Comida”. O “Bobi” é responsável por controlar
os intervalos de tempo em que é alimentado. Desta forma, sempre que passarem 3 horas
sem ser alimentado, o Bobi deve avisar o dono de que está com fome, por exemplo
enviando-lhe uma mensagem. Se as suas presses não forem atendidas, começa a saltar. Ao
fim de 4 horas sem ser alimentado, o “Bobi” pára e envia bolas de saliva para o ar. Por fim,
se continuar sem ser alimentado, o “Bobi” desliga-se (ou seja: fica inactivo).

O “Bobi” unicamente obedece às instruções do seu dono. Sempre que outra pessoa lhe
tocar ele ladra, ou seja envia a seguinte mensagem para o canal público: “Bau, Bau”.

De cada vez que o “Bobi” recebe uma instrução do seu dono, este deve executá-la. As
instruções são mensagens que o “Bobi” recebe e as executa como, por exemplo:

dono – stop .

Acção do “Bobi” - deixa de seguir o dono e pára.

dono – frente 5

Acção do “Bobi” - desloca-se 5 passos para a frente

dono – direita 90

Acção do “Bobi” - roda sobre si mesmo 90º para a direita.

O “Bobi”, sempre que no seu caminho aparecer um obstáculo deve desviar-se dele.

Outra alternativa consiste em escrever as instruções num notecard, que é lido pelo Bobi e as
executa. O “Bobi” deve guardar as tarefas executadas ao fim de um dia de trabalho: nessa
altura envia por e-mail ao dono os locais que visitaram e as tarefas que andou a realizar.

Podem ser adicionadas ao “Bobi” outras funcionalidades que considerar interessantes.

2ª Fase do trabalho prático

311
Agora que o cão está pronto para ser vendido, pretende-se que implementem uma loja
virtual no Second Life. O objectivo é construírem um balcão virtual que faça a gestão das
vendas. Assim o balcão deve registar os seguintes elementos:

• o número de cães existentes na loja;

• o nome do cão;

• a quantidade de cães vendidos;

• o preço de cada cão;

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

312
Licenciatura em Informática Licenciatura em Tecnologias de Informação e Comunicação
Laboratório de Informática I
Trabalho Prático

Data de entrega: 23 de Junho de 2008

– Simulador de carros –

Introdução

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

Descrição informal

O simulador é constituído por uma pista e os respectivos carros. A pista é formada por
blocos independentes que são dispostos de modo a formar uma linha fechada. É da
responsabilidade do utilizador criar esta linha com os blocos fornecidos. A pista contém
um controlador que indica quantos os carros estão em circulação, o nome de cada carro e
do respectivo dono, e ainda a quantidade de combustível que cada carro tem. O
controlador é responsável por cobrar as coimas aos participantes que deixam os carros ficar
sem combustível no meio da pista. Sempre que o controlador observa que um carro está
parado sem combustível identifica o seu dono e envia-lhe um email com o valor da coima a
pagar.

Os blocos que formam a pista são de cinco tipos: cruzamentos; simples; curvas 45º;
semáforos; combustível. Cada bloco indica, sempre que solicitado, o seu tipo, se está livre,
isto é se não tem nenhum carro por cima e as suas coordenadas. O semáforo troca de cor
(verde, amarelo, vermelho), de x em x segundos.

Os carros movem-se a gasolina e por cada bloco gastam x litros de combustível,


especificado no fabrico do carro. Quando a quantidade de combustível for inferior a 0,5
litros deve aparecer por cima do carro a seguinte mensagem: ”Preciso de gasolina” e a cor
do carro pisca. Se o carro ficar sem combustível pára e o seu dono recebe uma coima de

313
10LD. Cada carro move-se consoante as ordens recebidas do seu dono. As ordens dadas
têm o seguinte formato, nome do carro seguida da ordem. Por exemplo: “vermelho andar”.

O dono pode enviar ao seu carro as seguintes ordens:

• Andar;

• virar esquerda/direita;

• abastecer;

• parar.

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

Objectivos

Criar um simulador de carros de alta velocidade que deve ter os seguintes itens:

1. Pista formada por blocos de cinco tipos (cruzamentos; simples; curvas 45º;
semáforos; combustível);

2. Controlador da pista que fornece informação sobre os carros que se


encontram em circulação e cobra as coimas;

3. Carros que recebem ordens do seu dono e as executam.

314
315
15. Anexos IV

Questionários

316
Questionário Inicial

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

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

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

Sim Não

2.1.Se sim, indique qual o resultado obtido.

3. Já conhecia o mundo virtual Second Life?

Sim Não

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

317
Questionário Intermédio

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

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

Sim Não

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

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

318
Questionário Final

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

1. Sentiu dificuldades na execução deste projecto?


Sim Não

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

319
16. Anexos V

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

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

Actividade Preliminar

Realizadas entre Março e Junho de 2007, na qual participaram 5 alunos da licenciatura em


Informática da UTAD.

322
Aula:1
Dia: 12/03/2007

Observações da aula: Os alunos entraram no SL, fizeram o seu registo e escolheram o


avatar, tendo, posteriormente, juntado ao meu avatar no espaço da aula. Ao observarem o
meu avatar quiseram saber como podiam personalizar o deles. Desta forma passei a
explicar-lhes como usar o editor para poderem alterar a forma do corpo, a cor da pele,
entre outros aspectos. Como não podia deixar de ser, todos quiseram saber onde arranjar
roupa para vestir o seu. Após esta introdução que serviu também de adaptação ao
ambiente, expus os diferentes modos que podem interagir com o ambiente, isto é, tocar
nos objectos, voar, dançar e correr. Por último, dedicamo-nos a criar um banco. Assim,
passei a explicar como funciona o editor de objectos do SL.

Nesta fase de construção, os alunos sentiram algumas dificuldades, nomeadamente: criar


cópias de objectos, utilizar o zoom e fazer a ligação entre objectos. Por exemplo, o aluno 2
preferiu fazer 4 pernas do banco do que criar réplicas de uma. Este facto levantou-lhe
algumas dificuldades em conseguir obter as 4 pernas do mesmo tamanho e forma.
Expliquei-lhe como usar a régua para criar objectos do mesmo tamanho.

Os alunos 3 e 4 tiveram alguma dificuldade em efectuar a ligação dos objectos, 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.

323
Aula: 2

Dia: 19/03/2007

Observações da aula: Nesta aula, o avatar de alguns alunos já tinha um aspecto diferente.
Comecei por expor qual o objectivo da aula, criar o cão para o projecto, e perguntei se
tinham alguma dúvida em relação ao que fizemos na aula passada, disseram-me que não.
Começamos a construção do cão. Os alunos estavam com algumas dificuldades em iniciar a
construção, tendo referido: “ que não tinham jeito para desenho”. Assim, mostrei-lhes um
exemplo e expliquei-lhes quais as primes que usei para o fazer. Desta forma, todos eles
começaram a criar um cão.

No decorrer da aula fui-lhes relembrando o que tínhamos feito na aula anterior com o
banco, ou seja criar cópias de objectos. É importante que um cão tenha as patas todas do
mesmo tamanho, assim como as orelhas. Como já não se lembravam de como se cria uma
réplica, tive de lhes explicar novamente. Expliquei-lhes as vantagens de criarem cópias dos
objectos, como para além de terem a certeza que são todas iguais, torna-se mais rápida a
sua construção.

Nesta fase dei especial atenção ao aluno 2 que na aula anterior não conseguiu criar as
réplicas das pernas do banco. Os alunos sentiram algumas dificuldades em criá-las, estavam
sempre a dizer: “isto dá erro”, “não me deixa fazer uma cópia”. A causa do problema
residia no facto que eles seleccionavam também o chão da sala, e como não eram os donos
de todos os objectos, o SL não lhes permitia criar as réplicas. Expliquei-lhes como usar o
zoom para terem a certeza de que estavam a seleccionar só os seus objectos. Os alunos 3 e
2 sentiram alguma dificuldade em compreender como fazer o zoom e diziam: “isto aqui
não funciona...”, “ não consigo ver nada…”. Ao fim de alguma insistência lá conseguiram
fazer os passos que eu estava a dizer. A razão pela qual eles não estavam a conseguir era
que não clicavam nas teclas em simultâneo. Os alunos 1 e 5 decidiram que o seu cão devia
ter pernas e patas, pelo que lhes disse que era melhor ligarem a perna à pata do cão e
depois criarem réplicas do objecto já ligado. Estes alunos não estavam a conseguir criar
réplicas completas da pata do cão, só criavam réplicas da perna. O problema estava na
ligação de objectos. Pedi-lhes que tentassem mover a pata do cão para cima, logo
observaram que só se deslocou a perna, uma vez que estes objectos não estavam ligados
entre si.

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

Aula: 3

Dia:26/03/2007

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

Apesar das dificuldades, nota-se que os alunos estão a gostar do que estão a fazer, cada um
dele está a empenhado para que o seu cão seja o mais bonito, razão pela qual não se
conseguiu entrar na programação. Pedi-lhes que em casa dessem uma vista de olhos ao
manual da linguagem LSL que está online.

325
Aula:4

Dia: 2/04/2007

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

No fim desta etapa introdutória fiz uma revisão das estruturas de controlo, nomeadamente
a estrutura de decisão if. Mostrei-lhe um exemplo de aplicação, o qual eles testaram, 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

326
tão rápida. Aluno 4 disse: ”..olha que fixe…assim podemos trocar código….”. Aproveitei
para lhes explicar como se faz para partilhar o código, houve alguma dificuldade
principalmente os alunos 1e 4 porque não estavam a conseguir fazer o que eu lhes dizia.
Depois de ver o código disse-lhe para ver o que faltava na linha 8 de pois do if. O aluno
conseguiu emendar o erro.

Após esta introdução passamos a falar do projecto e rever quais as funcionalidades que este
tinha de ter e o que tinha de estudar da linguagem para a próxima aula. Chamei-lhes a
atenção para a importância de eles estudarem um pouco sobre a linguagem antes da aula,
para que consigam progredir mais na compreensão da linguagem. Os alunos voltaram a
referir que tinham disciplinas em atraso e que por isso não tinham muito tempo para se
dedicarem ao projecto.

Aula:5

Dia:16/04/2007

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

327
fosse “cor” mudava a cor do objecto para verde. O aluno 5 teve dificuldades em chamar a
função, começou por se queixar que não funciona, depois de observar o código 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

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

Aula 7

Dia:30/04/2007

Observações da aula: O aluno 1 faltou a esta aula. Informei os alunos que o objectivo
desta aula era colocarem o cão a receber ordens do dono e a executá-las, principalmente o
andar e o parar. Assim disse-lhes para criarem um cubo e colocarem este a responder “sim”
para o dono sempre que este diz “olá”. A seguir iriam trabalhar no cão deles de forma a
completarem uma parte do projecto. Como aconteceu na alua passada a maioria dos alunos
não sabia por onde começar, pelo que tive de lhes dar um pequeno exemplo e explicar
como este funciona. Pedi-lhes então que o adaptassem de forma a fazer o que tinha pedido
no inicio da aula. Na generalidade todos foram capazes de o fazer, com excepção do aluno
2 que tem mais dificuldades. O aluno 4 queixou-se que “.. eu já chamei a professora várias
vezes…” como a quantidade de mensagens a circular no canal público continua a ser um
pouco exagerada o que dificulta a comunicação entre mim e os alunos. Esta situação 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

329
“andar” só tinham de chamar a respectiva função. A aula terminou e eu pedi-lhes que
tentassem em casa terminar esta parte do projecto.

Estes alunos conseguem acompanhar e fazer o que lhes é pedido, se partirem de um


exemplo semelhante ao que têm de fazer. Estão um pouco atrasados no desenvolvimento
do projecto mas como eles não trabalham em casa não sei se vão conseguir implementar
todas as funcionalidades requeridas.

Aula 8

Dia: 7/05/2007

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

Nesta aula senti alguma dificuldade em conseguir acompanhar as actividades de todos os


alunos, devido ao facto de eles estarem muito dispersos pelo terreno. Marquei uma aula
suplementar para a próxima semana das 18h às 20h, para ver se eles avançam um pouco
mais no projecto

330
Aula 9

Dia: 14/05/2007

Observações da aula: Faltaram os alunos 2 e 5. Nesta aula os alunos deviam colocar o


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

331
Aula 10

Dia: 28/05/2007

Observações da aula: A esta aula compareceram todos os alunos. Como os alunos 2 e 5


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

Aula 11

Dia: 4/06/2007

Observações da aula: Nesta aula estiveram presentes todos os alunos. Estiveram a


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

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

Em resumo é necessário repensar a forma de comunicação, uma vez que eu ao dedicar-me


a um alunos que está longe dos outros perco a noção do que os outros estão a fazer e das
necessidades que têm.

Aula 12

Dia: 11/06/2007

Observações da aula: Faltaram os alunos 1 e 3. Esta é a última aula e na próxima semana


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

333
Primeiro encontro mensal

Dia: 27/4/2007

Nesta reunião estiveram presentes todos os alunos de Lab. I. Aproveitei para saber quais as
dificuldades que estavam a ter , se estavam a gostar de aprender a programar no SL e quais
as razões de na criação dos objectos cometerem constantemente os mesmos erros.

Foram unânimes em responder que estavam a gostar da experiência. O aluno 5 referiu:

- “…isto é muito melhor aprender no SL é mais engraçado porque vemos logo o que o cão
faz”

Em relação aos erros constantes na construção dos objectos, o aluno 4 disse que:

-“embora a professora explicasse como se devia fazer o zoom nós não compreendíamos
que tínhamos de utilizar as várias teclas em conjunto”.

Os outros concordaram que a maior dificuldade era em perceber como usar os comandos e
que muitas vezes se esqueciam de qual era a sequência. O aluno 1 mencionou que acontecia
frequentemente não prestar atenção ao que a professora estava a explicar porque estava a
trabalhar no seu cão.

Em relação à programação:

Os alunos referiram que a linguagem LSL é parecida com o C e que não é difícil, o que a
torna mais complicada é o facto de não existir um manual em português. Em relação ao
enunciado do projecto os alunos foram unânimes ao referirem que gostam do enunciado o
problema maior é que têm alguma disciplinas em atraso o que lhes deixa pouco tempo para
se dedicar ao estudo, como é o caso do aluno 1,5 e 2.

Segundo encontro mensal

Dia: 31/05/2007

Nesta reunião estiveram presentes todos os alunos. Aproveitei para esclarecer algumas
dúvidas sobre o projecto. Perguntei o que consideram que está menos bem nas aulas e
como podemos alterar.

O aluno 4 referiu que –“…muitas vezes pede ajuda mas a professora não responde….fico
sem saber se a professora está online ou não”

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

Terceiro encontro mensal

Dia: 12/07/2007

Esta reunião serviu para se fazer um balanço geral da actividade, como foi em tempo de
exames os alunos 1 e 5 não puderam comparecer. No geral disseram que gostaram de
aprender a programar no SL e que gostariam de repetir a experiência.

O aluno 2 referiu que:

-“(...) gostei do projecto, mas não dediquei muito tempo para o desenvolver , porque tinha
outras disciplinas para fazer. Como achei o projecto fácil pensei que no fim o fazia
rapidamente, mas depois não tive tempo para o acabar.”

O aluno 3: -“(...) achei o projecto bastante engraçado e fácil. Gostei de ver o


comportamento do meu cão, que nem sempre obedecia ao seu dono, mas não dediquei
muito tempo a fazê-lo, pois tinha outras disciplinas para fazer.”

O aluno 3 referiu ainda que tinham problemas em conseguir comunicar comigo:

“Algumas vezes perguntávamos se a professora nos podia ajudar e não obtínhamos


resposta.”.

335
Relatório das aulas de Lab III

Actividade Preliminar

Realizadas entre Março e Junho de 2007

336
Aula 1:

Dia: 13/03/2007

Registo de observações: Os alunos entraram no SL, fizeram o seu registo e escolheram o


avatar. De seguida, juntaram-se à professora no espaço da aula. Ao observarem o meu
avatar quiseram saber como podiam personalizar o seu avatar, assim estive a explicar como
usar o editor para poderem alterar a forma do corpo, a cor da pele, entre outros aspectos.
Como não podia deixar de ser, todos quiseram saber onde arranjar roupa para vestir o seu
avatar. Após esta apresentação que serviu também de introdução ao SL os alunos
formaram grupos de dois, para desenvolverem o projecto ao longo do semestre. Assim
formaram-se os seguintes grupos: aluno 1 e 4 e aluno 2 e 3. Os alunos1 e 4 optaram por
fazer o trabalho do robô os restantes alunos escolheram o do comboio. Contudo, 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

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

Aula 2

Dia: 20/03/2007

Registo de observações: Verifiquei que todos os alunos tinham terminado a construções


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

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

Aula 3

Dia: 27/03/2007

Registo de observações: Nesta aula pretendia dar inicio à programação em LSL.


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

Aula 4

Dia: 3/04/2007

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

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

Em resumo, esta primeira aula de introdução ao LSL correu bem, nota-se que estes alunos
têm umas noções base de programação e alguma autonomia para procurarem soluções para
os seus problemas.

Aula5

Dia: 17/04/2007

Registo de observações: No inicio da aula os alunos 3 e 2 pediram-me se eu podia dar


uma vista de olhos no código deles pois estavam atentar enviar uma mensagem para outro
objecto, só que o receptor não o estava a receber. Novamente algumas dificuldades em
conseguir partilhar o código. Após observar o código verifiquei que o objecto emissor
estava a emitir por um canal e o receptor à escuta noutro, logo nunca podia ouvir a
mensagem. Pedi-lhes que me explicassem como funciona a função que estavam a utilizar.

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

Os alunos 1 e 4 não sabiam como colocar o nome por cima de cada um dos robôs, sugeri
que visse a função llSetText. Pesquisaram e concluíram que esta era a função que
precisavam, ao utilizá-la surgiu que um robot tinha por cima da cabeça o nome “Alf” e o
outro aparecia duas vezes escrito “Alf1”. Os alunos não sabiam o porquê desta situação.
Novamente, analisei o script e não havia razão para aparecer dois nomes escritos, sugeri ao
aluno que verificasse se o robot não tinha dois objectos com o mesmo scritp. Não
conseguiram descobrir qual o objecto que tinha outro script nem como este lá foi parar. Ao

341
analisar o robô verifiquei que no olho direito tinha um script que escrevia o nome do
robot. Problema resolvido.

No fim da aula disse-lhes que na próxima aula deviam trazer algumas dessas
funcionalidades a funcionar. O papel do professor nesta aula consistiu em analisar os erros
que foram surgindo e propor possíveis soluções para o aluno pensarem e resolverem o
erro.

Aula 6

Dia: 24/04/2007

Registo de observações: O aluno 2 faltou a esta aula. Nesta aula comecei por verificar
junto de cada grupo o que eles tinham feito depois da aula passada. Os alunos 1 e 4 já
tinham implementado algumas das funcionalidades do robô e estavam com dúvidas em
como colocar o robô a marcar as horas. Este alunos sabiam que precisavam de
implementar um temporizador mas não tinham encontrado nenhuma função que lhes
indique as horas em segundos. Assim indiquei-lhes algumas funções para eles irem estudar
e verem qual desta se adapta melhor ao caso deles.

O aluno 3 que estava a implementar o projecto do comboio disse-me que não tinham feito
grande coisa. Este aluno estava a tentar colocar o comboio a andar para a frente e para trás
mas sem sucesso, disse-me: “..este comboio é muito teimoso, não quer andar…”. Tentei
ver o código mas não consegui, assim pedi-lhe que me desse permissões. O aluno
perguntou-me como é que fazia isso pois já não se lembrava. Quando observei o código
verifiquei que estava a usar as funções erradas, pelo que lhe pedi para me explicar o que
pretendia fazer com aquelas funções e pedi-lhe que fosse ler no lsl wiki o que elas faziam.
O aluno 3 disse: “ pois não é bem isto que eu quero..”, então propus-lhe que fosse ver
exemplos do género que ele estava a tentar implementar. Passado algum tempo este aluno
disse-me que já tinha descoberto como era mas estava a dar erro. Fui ver o código e notei
que tinha um parâmetro de entrada errado, pelo que lhe pedi para ir ver melhor quais os
parâmetros de entrada da função em causa. Deste modo o aluno conseguiu corrigir o erro.

Os alunos 1 e 4 andavam de volta do temporizador, reparei que estavam numa grande


troca de ideias, sem chegarem a um acordo de como marcar o passar do tempo. Assim
pedi-lhes para ver o código, verifiquei que estavam a usar a função correcta mas no sítio

342
errado. Desta forma, perguntei-lhes qual era a ideia de cada um deles, sobre como isto
devia ser. Pela explicação que me deram, verifiquei que o aluno 4 estava a pensar
correctamente. Assim, sugeri que cada um deles criasse um objecto e implementassem o
que estavam a sugerir para ver quem tinha razão. Passado algum tempo o aluno 4 disse :
“Vês tinha razão o meu funciona…” enquanto o aluno 1 o programa dele tinha um erro de
compilação. Pedi ao aluno que partilha-se o código e expliquei-lhe o que estava errado no
código dele. No fim da aula informei-os que se precisassem de ajuda quando estão a
trabalhar ao longo da semana me podiam enviar uma mensagem.

Em resumo, na aula de hoje os alunos avançaram pouco em relação ao trabalho mas fiquei
com a impressão que ficaram a compreender um pouco melhor como a linguagem
funciona. Estes alunos programam por tentativa erro e quando não funciona vão alterando
à sorte sem pensar, principalmente o aluno 3.

Aula 7

Dia: 08/05/2007

Registo de observações: No início da aula fui verificar o que cada um dos grupos tinha
andado a fazer. Foi com agrado que confirmei que ambos os grupos tinham estado a
trabalhar no projecto. O aluno 4 esteve a mostrar-me os objectos que tinham andado a
programar e disse-me que alguns residentes perguntaram-lhe se ele não os queria vender,
houve um que gostou muito do seu robô.

Os alunos2 e3 andavam a tentar colocar o comboio a andar e a parar quando este recebesse
uma ordem de paragens mas estavam com algumas dificuldades em conseguir pará-lo. O
aluno 2 comentou: “..este comboio não é nada obediente…não pára nas estações.”. Passei
grande parte da aula a ajudar este grupo a conseguir colocar o comboio a parar, que é uma
funcionalidade base do projecto. Ao fim de várias tentativas sem sucesso feitas pelos
alunos, pediram-me para ver o código. Desta forma, pude observar o que estava de errado,
estes alunos tinham uma grande confusão no código. Pedi para me explicarem o que aquele
código fazia, tendo confirmado que estavam a fazer alterações por tentativa erro, sem
pensarem nem compreenderem o que realmente estavam a fazer. Assim aconselhei-os a
criarem um objecto simples, criarem um novo script que ponha o objecto a andar e a parar
ao fim de 2 metros e a inverter a marcha. No fim de isto estar pronto é que devem ir
colocar a função que analisa as mensagens.

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

No fim da aula disse-lhes que estavam a ir muito bem no desenvolvimento do projecto.

Aula 8

Dia: 15/05/2007

Registo de observações: Os alunos 2 e 3 encontraram-me no SL, no dia 11, e pediram se


eu os podia ajudar. Estive com eles 3h a ajudá-los a colocar o comboio a andar e a parar na
estação correcta. A maior dificuldade observada foi em conseguirem analisar as mensagens
recebidas de forma a saberem em que estação devia o comboio parar. Nesta aula os alunos
2 e 3 disseram-me que iam sair mais cedo pois tinham um outro trabalho para terminar e
estavam a faltar à aula de Lab III na UTAD. Tinham vindo à aula apenas para me
mostrarem o que já tinham conseguido avançar desde a última vez que estiveram comigo.

As alunos 1 e 4 estiveram a continuara a desenvolver o seu projecto. Estive a rever com


este grupo o que lhes faltava fazer. Assim, estivemos a trocar ideias de como implementar
algumas funcionalidades principalmente como os robôs podiam se desviar dos objectos.
Este grupo ficou de estudar como funcionam os sensores.

Aula 9

Dia: 22/05/2007

Registo de observações: Os alunos 1 e 4 pediram a minha ajuda pois estavam com


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

344
procura de um exemplo. Ao fim de algum tempo voltaram a chamar-me, disseram que
estavam a testar mas que não funcionava como eles queriam. Estive a observar o sript e
verifiquei que lhes faltava a função llEuler2Rot, pelo que sugeri que fossem ver o que esta
função fazia. Por fim, conseguiram colocar os robôs a rodar. Sugeri que criassem uma
função para rodar os objectos, sendo esta usada sempre que fosse necessário.

Nesta aula, os alunos 2 e 3 não solicitaram a minha ajuda. Contudo, fui verificar o que
andavam a fazer e disseram-me que estavam a tentar controlar as encomendas que o
comboio recebe de cada estação.

Aula 10

Dia: 29/05/2007

Registo de observações: O aluno 3 faltou à aula. O seu colega, o aluno 2 esteve a


continuar o trabalho sozinho. Disse-me que estavam com alguma dificuldades em controlar
as encomendas recebidas. Assim, estive grande parte da aula a ajudar este grupo. Notei que
tinham uma grande confusão no código, pelo que lhe disse para criar algumas funções,
inserir comentários de forma a que o código se torne mais legível. A maior dificuldade
sentida por este aluno consistiu em saber que funções poderia utilizar para separar a
mensagem recebida em strings isoladas. Desta forma fui-lhe sugerindo que fosse estudar o
que algumas funções predefinidas da linguagem fazem. O aluno conseguiu ver quais a s
funções que devia utilizar e foi procurar exemplos de aplicação.

Os alunos 1 e 4 também pediram ajuda pois estavam com dificuldades em colocar o


temporizador a funcionar e também não sabiam como é que podiam desligar os robôs.
Estive a analisar o código destes alunos e verifiquei que embora estivessem a usar a função
correcta llSetTimerEvent faltava-lhes o evento timer() que é chamado quando o tempo
marcado na função anterior chega ao fim. Assim, estive a explicar como funcionam os
eventos em especial o timer. Desta forma os alunos conseguiram colocar o timer a
funcionar.

No fim da aula, o aluno 3 confirmou-me que já tinha conseguido resolver o problema das
mensagens. Os alunos 1 e 4 pediram-me se podia ficar mais um bocado para os ajudar com
os sensores. Estive mais 3 horas no SL a ajudar estes alunos a trabalhar com os sensores. A

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

Aula 11

Dia: 5/06/2007

Registo de observações: Nesta aula os alunos de ambos os grupos disseram-me que


apenas lhes faltava implementar a parte de guardar todas as actividades efectuadas para
depois enviarem ao dono por email. O aluno 4 referiu que tinha andado a ver os vectores
mas não estava a funcionar. Perguntei-lhes porque não pensaram nas listas, nas quais
podiam guardar vários tipos de dados. Assim foram ver como funcionam as listas em LSL.
Cada grupo esteve a implementar listas no seu projecto. Os alunos 2 e 3 estavam com
alguma dificuldade em conseguirem saber o que estava dentro da lista, estive a ver o código
deles e verifiquei que estavam a usar a função errada, pelo que lhes pedi pra irem ver o que
aquela função fazia. O aluno 2 disse “ pois não é bem isto que nós queremos”, então sugeri
que fossem ler o que fazia as funções llGetListLength e llList2String. Desta forma este
alunos conseguiram listar todo o conteúdo da lista e verificar o que esta continha.

Os alunos 1 e 4 não estavam a conseguir enviar para o email deles o conteúdo da lista.
Verifiquei que tinham um erro nos parâmetros da função llEmail, pedi-lhes que
verificassem os parâmetros, tendo conseguido emendar o erro.

Ambos os grupos terminaram a aula com esta funcionalidade implementada, lembrei-lhes


que a próxima aula era a última antes da entrega do trabalho, tendo me dito que lhes faltava
pouco para terminarem o projecto.

Aula 12

Dia: 12/06/2007

Registo de observações: Esta é a última aula do semestre e os alunos têm de entregar o


trabalho na próxima semana dia 18, segunda-feira. Os alunos 1 e4 têm o trabalho
completo, pelo que estiveram apenas a embelezar mais os seus robôs. O aluno 4 disse-me
que já tinha vendido alguns dos seus objectos e que tinha inclusive recebido encomendas.

346
Disse-me também que várias pessoas queriam comprar os seus robôs mas que não os
queria vender pois eram os seus animais de estimação. Este aluno estava a pensar em
ganhar algum dinheiro em produzir scripts e objectos para outros avatares. Este aluno
referiu:”fiquei viciado no SL”

Os alunos 1 e 3 já tinham todo o trabalho completo a nível da programação faltava apenas


criar as estações, uma vez que não tinham tido tempo para o fazer. Assim aproveitaram a
aula para o fazer.

Nesta aula limitei-me a observar as suas construções.

Primeiro encontro mensal

Dia: 26/4/2007

Nesta reunião estiveram presentes todos os alunos. Estivemos a trocar ideias sobre o
projecto, tendo os alunos referido que o consideravam um pouco grande e complexo.
Perguntei-lhes se estavam a gostar da experiência, disseram que sim. O aluno 2 comentou:
“ diverti-me imenso a construir o meu comboio que mais parecia um cão “

O aluno 4 referiu. “ fiquei viciado no SL, passo muitas horas a desenvolver objectos só por
brincadeira.”

Segundo encontro mensal

Dia: 31/05/2007

Este encontro, no qual estiveram presentes todos os alunos, serviu principalmente para
conversar sobre o projecto e como as aulas estão a decorrer. Referiram alguma dificuldade
em conseguirem comunicar comigo. O aluno 1 referiu: “ algumas vezes chamava-mos a
professora mas não nos respondia”.

Outro problema com as permissões o aluno 3 comentou: “Acontecia frequentemente que


não nos lembrávamos como é que se davam as permissões e por isso a professora não
conseguia ver o código porque as permissões estavam erradas.”

347
Terceiro encontro mensal

Dia: 12/07/2007

Este encontro serviu para se fazer uma avaliação global das aulas no SL.

Os alunos na sua totalidade reafirmaram a sua satisfação em terem participado. O aluno 4


referiu que “fiquei viciado no SL. Já tenho vários clientes, ando a desenvolver objectos e
scripts.”, continuou “ ainda não fui capaz de vender os meus robôs apesar de ter recebido
boas ofertas”.

Quando lhes perguntei se consideravam o SL um bom ambiente de programação, disseram


que sim. O aluno 1 acrescentou: “ …no SL é fácil verificar se o programa está correcto ou
não basta olhar para o objecto e ver como este se comporta”

Todos os alunos confirmaram que se tiverem hipótese gostariam de repetir a experiência.

348
Relatório das aulas de Projecto I

Primeiro e segundo ciclos de Investigação-acção

Realizadas entre Outubro de 2007 e Janeiro de 2008

349
Aula 1:

Dia:10/10/2007

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

Aula 2

Dia: 17/10/2007

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

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

350
cada face a uma cor diferente. Nesta aula de introdução os alunos não trabalharam em
grupo. Recebi solicitações de todos eles a dizer que não estavam a conseguir seleccionar só
uma face do objecto, pelo que fiz uma chamada de atenção geral pelo canal público a
explicar como isto se fazia. O aluno R continuou com dificuldades, assim como o J, ao fim
de algumas tentativas falhadas lá conseguiram fazer o pretendido.

O passo seguinte consistiu na criação de um banco, sendo este um objecto simples de criar,
o qual envolve a junção de objectos e o desenvolvimento de réplicas. A base do banco
todos conseguiram criar, uns fizeram-na redonda, outros quadrada. No que respeita às
pernas, os alunos tiveram dificuldade em saber como criar uma cópia do objecto. Recebi
várias solicitações em simultâneo dos alunos a queixarem-se que dava erro. Assim fiz uma
chamada de atenção geral para lhes explicar como deviam fazer, mesmo assim o aluno M
não conseguiu. Deste modo, estive a explicar novamente como isto se faz a este aluno. O
aluno J e C estavam com o mesmo problema, pelo que estive individualmente a explicar
todos os passos que deviam fazer. Por fim, conseguiram criar as réplicas, no entanto
observei que o aluno D preferiu criar 4 pernas em vez de criar réplicas. Contudo, este aluno
estava com alguma dificuldade em colocar todas as pernas com o mesmo tamanho, assim
expliquei-lhe como podia usar a régua. Perguntei-lhe porque razão não criou uma cópia diz
que “Eu tentei mas dava erro e como não queria ficar parado fui criando, assim é mais rápido”.

O aluno R disse: “Isto fica assim! o meu banco quando o desloco perde as pernas…hehehe.”. Fiz uma
chamada de atenção geral e pedi que movessem o banco, como verificaram que este
“perdia as pernas” expliquei-lhes como podiam juntar de forma a criarem um objecto
único. O aluno C disse-me que não tinha percebido, pelo que tive de lhe explicar outra vez.
O mesmo sucedeu com outros alunos. A maior dificuldade residiu em conseguirem
seleccionar apenas os elementos que pertencem ao banco, o que os impede de os juntar.

Notas: nota-se que as dificuldades em compreenderem o funcionamento do editor se


mantêm. A explicação individual, passo a passo resolve a situação mas não é muito viável
pois implica ter outros alunos à espera.

351
Aula 3

Dia: 24/10/2007

Objectivo da aula: Criar os objectos do projecto, ou seja o cão e o boneco de neve.

Registo das observações: Disse-lhes que nesta aula deviam começar a criar o cão e o
boneco de neve, os objectos que fazem parte do projecto. Referi que nesta aula já deviam
trabalhar em grupo. Contudo, eles preferiram trabalhar individualmente disseram que assim
viam qual o “animal” que saia melhor. No decorrer da aula fui-lhes relembrado o que
tínhamos feito na aula passada com o banco, ou seja criar cópias de objectos, é importante
que um cão tenha as patas todas do mesmo tamanho, assim como as orelhas. Como já não
se lembravam de como se cria uma réplica de um objecto tive de lhes explicar outra vez.

O aluno B começou a criar o cão a partir de um cubo, perguntei-lhe que parte do corpo
estava a criar, disse “ a cabeça do cão”, achei estranho e perguntei-lhe se a forma da cabeça
não era redonda ou oval, assim o aluno mudou de prim.

Os alunos sentiram algumas dificuldades em criarem réplicas das patas, estavam sempre a
dizer “isto dá erro”, “não me deixa fazer uma cópia”. A causa do problema residia no facto
que eles seleccionavam também o chão da sala, e como não eram os donos de todos os
objectos o SL não lhes permitia criar réplicas. Os alunos B e D pediram-me se na segunda
parte da aula eu podia ir ter com eles para lhes explicar como funciona o editor. Assim, fiz
uma chamada de atenção geral e disse que na segunda parte da aula eu ia à sala.

Na segunda parte da aula os alunos disseram-me que assim é mais fácil de perceber, uma
vez que o editor tem muitas funcionalidades e muitas vezes eu estou a dizer uma coisa e
eles a fazerem outra, só ao fim de algumas tentativas é que compreendem o que eu estava a
dizer. Assim estive junto de cada aluno a explicar as diferentes funcionalidades do editor.
Expliquei-lhes, também, como se partilha objectos e scripts. Observei que construíram
mais rapidamente os objectos.

Notas: O editor do SL deve ser explicado presencialmente. Desta forma os alunos


compreendem o que estamos a dizer e como se faz.

352
Aula 4

Dia: 31/10/2007

Objectivos: Introdução à programação no LSL, revisão de alguns conceitos básicos.

Registo das observações: Foi com agrado que observei os alunos a exibirem os seus
objectos, cão e o boneco de neve. No início da aula o aluno R, M e C estiveram a mostrar
os objectos que tinham andado a criar, para além do cão.

Comecei por relembrar os alunos que no dia 14 deviam-me entregar o algoritmo do


trabalho. Expus os objectivos desta aula, tendo iniciado por explicar como funciona a
linguagem LSL e as suas características. Esta explicação foi sendo acompanhada por um
exemplo que lhes dei para cada um deles experimentar. Os alunos receberam o script e
inseriram-no num objecto para o poderem testar. Sugeri que alterassem a mensagem que
este continha para que surgisse por cima do objecto o nome de cada aluno. O aluno J não
foi capaz de fazer esta alteração, assim tive de lhe dar a função com o texto e pedi-lhe que
substituísse a que se encontrava no script por aquela.

A seguir, pedi que abrissem a página do lsl wiki e fossem procurar o significado da função
llSetText. O aluno B disse-me que não estava a perceber o que esta função fazia
concretamente, pelo que tive de lhe explicar o que lá estava escrito. Perguntei-lhe se tinha
dificuldades no Inglês respondeu-me: “sim, só tive francês”. Confirmei com os restantes
alunos se tinham percebido o que esta função faz e conclui que 3 deles tinham dificuldades
em ler Inglês.

O exemplo seguinte, que os alunos estiveram a testar, teve por objectivo introduzir os tipos
de dados básicos do LSL, declaração e iniciação de variáveis e as estruturas de decisão. Pedi
que fizessem algumas alterações ao código, nomeadamente alterassem o valor das variáveis,
declarassem outras e alterassem a estrutura de decisão para o caso de a condição ser falsa.
O aluno J solicitou a minha ajuda dizendo que o programa dele estava a dar um erro de
compilação. Pedi-lhe que partilhasse o código mas este já não se lembrava. Assim fiz uma
chamada de atenção geral e relembre-lhes como se partilhava o código.

Ao analisar o código do aluno J observei que tinha ; no fim do if logo dava-lhe um erro no
else. Expliquei-lhe a causa do erro e este corrigiu. Em simultâneo fui recebendo várias
solicitações de ajuda, pois estavam com alguns erros de compilação. No geral os erros

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

No fim da aula pedi-lhes que fossem pensando no projecto, lendo alguma coisa da
linguagem.

Notas: Notei alguma demora, da minha parte, em conseguir responder a todas as


solicitações que ocorreram em simultâneo. Assim como a repetição de algum erros de
sintaxe.

Aula5

Dia: 7/11/2007

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


objectos.

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

Na segunda parte da aula, depois do intervalo, estivemos a ver como se processa a


comunicação entre o dono e um objecto, assim como entre objectos. Assim, comecei por
explicar o conceito de comunicação e como este se processa no SL e dei um exemplo para
os alunos testarem. A seguir fomos colocar um objecto a comunicar com outro. Neste caso
surgiram algumas dificuldades, ao observar o código dos alunos reparei que no geral o

354
problema consistia no facto de o objecto emissor e receptor não estarem a comunicar pelo
mesmo canal. O aluno D disse-me que estava a testar um exemplo que tinha retirado da net
mas que dava um erro de compilação, ao observar o código reparei que lhe faltava uma }.
O aluno M perguntou-me se ainda estava online, disse que sim, tive de lhe pedir desculpa
pela demora em responder mas estava a ver o trabalho de outro colega.

Após terem completado esta parte do exemplo, foram fazer alterações de forma a
conseguirem implementar algumas das funcionalidades pedidas no projecto. Os alunos
foram capazes de implementar esta troca de mensagens entre o dono e o cão ou boneco de
neve com relativa facilidade. O aluno R perguntou se era possível separa em strings as
mensagens enviadas, por exemplo rodar 90 ele precisava de separar a mensagem em duas.
Assim, fiz uma chamada de atenção geral e expliquei-lhes como isto se fazia, tendo lhes
pedido que fossem ver no LSL wiki. O aluno B que não percebe muito bem Inglês estive a
explicar o que estas funções faziam. Reparei que os alunos tinham ido à internet procurar
exemplos e que estavam a testá-los.

No fim da aula relembrei que tinham de entregar o algoritmo antes do inicio da próxima
aula.

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

Aula 6

Dia: 14/11/2007

Objectivos: Comunicação entre objectos, continuação. Eventos.

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

355
algumas das funções faziam ao aluno R e depois ao M. Expliquei-lhes o que tinham que
alterar no código deles.

Os restantes alunos também andavam a tentar colocar o cão a seguir o dono. A maioria dos
alunos estavam a fazer alterações no código por tentativa erro, sem perceberem o que
estavam a fazer. Os alunos B e D testaram vários exemplos e tentaram criar um deles
através da junção dos exemplos testados. Pediram a minha ajuda pois estavam com
algumas dificuldades com os erros de compilação. Observei que tinham uma grande
quantidade de erros. Assim, disse-lhes que a melhor forma era pegarem num exemplo, e
fazerem pequenas alterações mas irem compilando e corrigindo os erros que surgissem.
Perguntei ao aluno B com quem tinha estado a falar se o seu colega tinha acompanhado a
nossa conversa disse-me que sim. Posteriormente fui confirmar com o aluno D, este 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.

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

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

Aula 7

Dia: 21/11/2007

Objectivos: Eventos, (início do 2 ciclo).

Registo das observações: Relembre-lhes da existência do objecto de dúvidas, uma vez


que até ao momento nenhum aluno o utilizou. Fui confirmar se tinham a primeira fase do
trabalho pronta para entregar todos os grupos me disseram que sim. Desta forma sugeri
que me enviassem que me enviassem por email o script.

Nesta aula estive a rever o que tínhamos dado sobre eventos. O aluno B disse-me que não
estava a perceber, dei-lhe um exemplo para ele testar e coloquei comentários a explicar
algumas das funções utilizadas. Este aluno comentou que assim com a explicação no
código é mais fácil de compreender o que este faz. Desta forma achei melhor dar este
código também aos restantes alunos.

O passo seguinte consistiu na alteração do código dado de forma a implementarem o


temporizador. Os alunos R e M solicitaram a minha ajuda pois o programa deles estava
com erros. Observei o código destes alunos, tendo verificado que os erros se deviam à falta
de ; e }, assim escrevi no código deles um comentário sobre as causas do erro. Os alunos
foram ver e conseguiram corrigi-los. O aluno R comentou: “pois esquecemo-nos sempre do ;”.

Os alunos B e D estavam com alguma dificuldade em mudar o nome do comando “tocar”


para comida, tive de lhes estar a dizer como isto se faz. O mesmo problema teve o aluno R
e M.

357
Os alunos B e D pediram a minha ajuda pois não estavam a conseguir colocar o tempo a
zero quando o dono tocava no cão. Ao observar o código reparei que não tinham
declarado a variável. Assim, em vez de lhes dizer a causa do erro escrevi no código um
comentário para eles lerem. O aluno B disse: “pois, assim não podia funcionar…”

O aluno C já tinha solicitado a minha ajuda mas ainda não tive oportunidade para lhe
responder, quando falei com ele, disse-me “ estou aqui com um erro já algum tempo…”. Reparei
que o erro é por falta de uma }, escrevi um comentário no código a referir que todas as
funções terminam por }.

No fim da aula confirmei a recepção de todos os trabalhos.

Notas: Estes alunos mostram-se empenhados na implementação do seu projecto. A escrita


de um comentário explicativo teve uma boa aceitação mas implica alguma demora em
responder.

Aula 8

Dia: 28/11/2007

Objectivos: eventos, temporizador.

Registo das observações: Informei os alunos que ia acrescentar algumas funcionalidades


ao projecto, nomeadamente o desenvolvimento de uma loja virtual na qual fosse possível
vender o cão e o boneco de neve aos residentes do SL. O aluno B comentou: “assim fica
mais completo e engraçado…ainda vamos ganhar dinheiro com isto”. O aluno M não gostou muito da
ideia por ser uma sobrecarga de trabalho. Na generalidade os alunos aceitaram bem esta
alteração.

Informei os alunos que se encontrava no Moodle da disciplina um pdf sobre a linguagem


LSL em português com a explicação de algumas das funções mais utilizadas.

Relembrei-lhes que na próxima aula tinham de entregar a 2ª fase do projecto. Verifiquei


que todos os grupos tinham esta fase completa.

Os alunos R e M pediram a minha ajuda, pois já tinham o temporizador a funcionar, no


entanto o cão não enviava bolas para o ar ao fim de 4h sem comer. As restantes
funcionalidades já estavam a funcionar correctamente. Assim, ao observar o código reparei
que não estavam a usar a função llParticleSystem, perguntei como estavam a pensar

358
implementar esta parte do programa. O aluno R disse-me que o cão devia atirar bolas, tipo
de futebol para o ar, que tinha no seu inventário. Expliquei-lhes que o que se pretendia era
que o cão deitasse para o ar bolas de sabão e mostrei-lhes um exemplo, tendo referido que
fossem ver como funciona a função llParticleSystem.

Os alunos B e D chamaram a minha atenção para eu ver o cão deles, este já tinha a
funcionalidades do comer todas a funcionar. Contudo estes alunos queriam que as bolas
fossem transparentes e o cão estava a deitar bolas vermelhas. Assim, expliquei-lhes que isso
depende das constantes que estavam a usar na função llParticleSystem.

Os alunos R e M disseram-me: “professora o nosso já funciona…olhe veja”.

Ambos os grupos ficaram com a funcionalidades do comer a funcionar. Perguntei se o cão


já se desligava caso o dono continua-se sem lhe dar de comer, só os alunos B e D tinham
esta funcionalidade a funcionar. Assim pedi-lhes que explicassem aos colegas como podiam
implementá-la.

No fim da aula os alunos B e D pediram-me se os podia ajudar a colocar o cão a seguir o


dono. Estes alunos já conseguiam identificar as ordens do dono faltava-lhes colocarem o
cão a obedecer às ordens. Assim, estive com este grupo mais 2 h depois da aula a ajudá-los.
A maior dificuldade deste grupo de alunos consiste em saber que funções utilizar. Na maior
parte das vezes eles vão à procura de exemplos que depois não conseguem adaptar, nem
compreender como funcionam. A minha ajuda resumiu-se a comentar alguns dos exemplos
que eles estiveram a testar para que eles compreendessem o que as funções fazem.

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

Aula 9

Dia:5/12/2007

Objectivos: movimento autónomo de objectos

Registo das observações: Os alunos B e D não compareceram. Nesta aula os alunos


tinham de entregar a segunda fase do projecto. Antes do inicio da aula recebi de todos os
grupos os respectivos ficheiros.

359
Nesta aula os alunos não solicitaram muito a minha ajuda. Passaram grande parte da aula a
estudarem exemplos de como colocar o cão e o Boneco de neve a andar, embora já
tivessem tentado anteriormente mas sem sucesso.

Perguntei aos alunos se já tinham ido ler o documento sobre o LSL em português,
disseram-me que sim, e que agora percebem melhor como certas funções funcionam.

Os alunos C e J conseguiram colocar o Boneco de Neve a deslocar-se, contudo ficou a


faltar-lhes o parar. Os seus colegas passaram a aula a testar exemplos mas não conseguiram
implementar a funcionalidade pedida. Estive a observar o código deles e verifiquei que lhes
faltava obterem a posição do dono, para poderem colocar o cão a segui-lo. Estive a
explicar-lhes o que tinham de fazer, ficou para trabalho de casa.

Os alunos R e M que estão mais adiantados pediram-me que lhes explicasse como
funcionam os sensores pois andaram a ver alguns exemplos e não perceberam. Depois da
aula terminar mantive-me no SL com este grupo de alunos durante a qual estive a 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

360
mínimo que este deve estar afastado do dono. Enquanto revia o código deste grupo recebi
várias solicitações dos outros alunos, que não consegui dar resposta em tempo útil.

Ao verificar que outros alunos tinham o mesmo problema, uma vez que os objectos
caminhavam quase colados ao dono, fiz uma chamada de atenção geral para explicar o que
deviam fazer.

Os alunos R e M disseram que já tinham visto um exemplo assim mas não perceberam o
que este fazia. Assim pedi para ver esse exemplo e estive a comentar no código algumas das
funcionalidades deste. Os alunos disseram-me que agora já perceberam e que o cão deles já
funciona.

Na segunda parte da aula estive a explicar aos alunos o funcionamento dos sensores, 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..”

361
Estivemos a conversar pelo canal público sobre como a implementar a loja virtual. Todos
os alunos perceberam como podiam implementá-lo, através da troca de mensagens entre o
balcão e cada um dos objectos vendidos.

Os alunos estiveram na segunda parte da aula a desenvolverem a troca de mensagens entre


o cão e o balcão. Observou-se alguns erros de compilação no manuseamento das listas. O
aluno D estava com dificuldades em conseguir obter o tamanho da lista de forma a poder
mostrar todos os elementos que esta continha. Ao observar o código reparei que tinha a
função llList2String a ser chamada sem o contador do ciclo for. O erro não estava onde o
aluno referiu mas sim no ciclo. Escrevi um comentário no código, desta forma o aluno
corrigiu o erro.

Ficou para trabalho de férias acabarem de fazer as funcionalidades do balcão.

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

Aula 12

Dia: 9/01/2008

Objectivos: comunicação para o email

Registo das observações: Durante as férias foi frequente encontrar alunos online que
solicitaram a minha ajuda na realização do trabalho. Grande parte do trabalho estava
completo.

Os alunos R e M estavam mais atrasados no desenvolvimento do projecto. Assim passei


grande parte da aula dedicada a ajudar estes alunos. Este grupo estava com algumas
dificuldades em enviar a informação para o email do dono. Disse-lhes para irem procurar
uma função que lhes permitia enviar a informação para o email. Passado algum tempo
disseram que não estavam a encontrar, assim tive de lhes dizer qual era.

Os restantes colegas estavam a completar algumas funcionalidades, sem grandes


dificuldades. O aluno M referiu:” afinal isto foi mais fácil do que parecia ao princípio.”

Os alunos R e M estavam com dificuldades em contabilizar a quantidade de cães vendidos.


Assim, tive de lhes sugerir que uma solução seria que cada cão ao ser comprado enviava
uma mensagem ao balcão da sua venda e este aumentava o contador.

362
Perguntei aos alunos se tinham todas as funcionalidades implementadas disseram-me que
sim. Os alunos C e J pediram-me para eu verificar.

No fim da aula, voltei a conferir com os alunos R e M o que lhes faltava, tendo verificado
que já tinham todas as funcionalidades implementadas.

Aula 13

Dia: 16/01/2008

Registo das observações: Esta é a última aula do semestre, os alunos têm de entregar o
trabalho no próximo dia 18.

Os alunos C e J pediram-me se eu não me importava que eles saíssem para poderem


terminar de fazer o relatório uma vez que já tinham todas as funcionalidades
implementadas.

Os restantes colegas andaram a embelezar alguns dos objectos como o balcão.

Nesta aula limitei-me a observar os alunos a trabalharem pois pouco ou nada fizeram em
relação ao código.

Primeiro encontro mensal

Data: 22/10/2007

Neste encontro estiveram presentes todos os alunos. Estivemos a conversar sobre o


projecto e a forma como têm decorrido as aulas. O aluno R referiu algumas dificuldades,
nomeadamente: “não conseguimos compreender como criar uma cópia, nem como fazer o zoom”

Os restantes colegas foram unânimes ao afirmar que sentem algumas dificuldades em


compreender como se usa o editor, talvez fosse melhor explicar presencialmente e não
online.

363
Segundo encontro mensal

Data: 28 / 11/2007

Nesta reunião faltou o aluno R. Estivemos a trocar impressões sobre o projecto, aproveitei
para esclarecer algumas dúvidas. Alguns alunos mencionaram o seu agrado por esta forma
de ensino.

O aluno M referiu: -“(...) estive a falar com um americano sobre o meu trabalho e disse-lhe que tinha
aulas de programação no SL. Ele achou o máximo e disse-me que andava no SL só por brincadeira, mas
que gostava de saber criar coisas.”

O aluno C disse: -“Gostei muito, principalmente de poder olhar para o meu cão e ver como este se
comportava. Nos outros ambientes de programação é mais difícil de detectar os erros de execução... aqui
basta olhar.”

O aluno D: -“(...) um dos problemas que eu tinha em fazer trabalho de grupo era ter tempo para estar
com o meu colega, como trabalho em part-time era difícil. Assim, à noite encontramo-nos no SL, cada um
em sua casa, e trabalhamos no projecto durante a noite.”

Terceiro encontro mensal

Data: 14/01/2008

Neste encontro compareceram todos os alunos, tendo servido para fazer um balanço geral
das aulas. Os alunos gostaram de aprender a programar no SL como se depreende dos seus
comentários.

Aluno B:

-“gostei de aprender a programar no SL, e não percebo porque razão não se usa este ambiente nas outras
aulas de programação”.

Alunos D:

-“diverti-me imenso, principalmente porque o meu cão passava a vida a dizer que tinha fome, mesmo
quando tinha acabado de comer”

Aluno M:

-“O projecto ficou mais complicado mas consegui implementá-lo na totalidade...”

364
Aluno R:

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

365
Relatório das aulas de Laboratório Informático II

Primeiro e segundo ciclos de Investigação-acção

Realizadas entre Outubro de 2007 e Janeiro de 2008

366
Aula 1:

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

Objectivos: Apresentação do projecto

Registo das observações: apresentação do mundo virtual SL e do projecto aos alunos de


Lab. II, pelo professor da UTAD. Nesta turma voluntariaram-se 10 alunos que formaram
grupos de dois alunos da seguinte forma: aluno F e T; aluno M e J; aluno C e S; aluno A e
B; aluno R e V;

Aula 2

Dia: 22/10/2007

Objectivos: Introdução ao SL, apresentação do editor, construção de objectos

Registo das observações: Os alunos entraram online, estive a mostra-lhes o espaço da


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

Observou-se algumas dificuldades em conseguirem colocar texturas no banco, e como


sucedeu com os seus colegas anteriores não foram capazes de criarem réplicas das patas
nem juntar os vários objectos num só.

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

Notas: Dificuldades em compreenderem o funcionamento do editor.

Aula 3

Dia: 29/10/2007

Objectivos: Introdução à linguagem LSL, revisão dos conceitos básicos de programação.

Registo das observações: Confirmei com os alunos se estes tinham submetido no SIDE
o algoritmo do trabalho. Após a aula fui retirar o algoritmo de cada grupo do SIDE.

Expus os objectivos desta aula, tendo iniciado por explicar como funciona a linguagem
LSL e as suas características. Esta explicação foi sendo acompanhada por um exemplo que
lhes dei para cada um deles experimentar. Os alunos receberam o script e inseriram-no
num objecto para o poderem testar. Sugeri que alterassem a mensagem que este continha
para que surgisse por cima do objecto o nome de cada aluno. Alguns alunos sentiram
dificuldades em conseguirem alterar a mensagem, como foi o caso do aluno R e C. Tive de
lhes explicar novamente como fazer esta alteração.

A seguir, fiz uma revisão geral dos conceitos base de programação, como a noção de
variável, tipos de dados base em C e o seu correspondente em LSL, as estruturas de
controlo e dei-lhes um exemplo para testarem.

O aluno A referiu: -“Eu sei a linguagem C, e não tenho dificuldades em C, eu tive uma boa nota o ano
passado.”

Assim, fiz uma chama de atenção geral e perguntei se alguém não compreendeu ou teve
dificuldades em se lembrar dos conceitos básicos. Dissera-me que não, pelo que sugeri que
passasse-mos então a analisar o projecto e a implementá-lo. A primeira fase que os alunos
tinham de entregar consistia na troca de informação entre a caixa de gestão de vendas e os
produtos.

368
Estivemos a conversar sobre o projecto e a forma de este ser implementado no SL, sugeri
que criassem uma caixa e escrevessem por cima “caixa de gestão” e outra “Aspirinas”. A
seguir deviam ir implementar um pequeno script para a caixa de aspirinas que envia-se uma
mensagem à caixa de gestão.

Estive a explicar para todos os alunos como se processa a comunicação entre objectos no
SL e dei-lhes um pequeno exemplo para verem, testarem e adaptarem para o projecto. Na
generalidade os alunos compreenderam o funcionamento deste exemplo, a seguir disse-lhes
agora alterem-no para o vosso trabalho.

O aluno B solicitou ajuda pois não percebeu o que tinha de fazer. Assim, pedi que lesse o
enunciado do trabalho principalmente a parte que fala da caixa de gestão. A mesma
dificuldade foi sentida por outros alunos. Desta forma fiz uma chamada de atenção geral e
pedi que fossem ler o enunciado do trabalho principalmente o que diz respeito à caixa de
gestão. Após confirmar que tinham lido perdi que me dissessem o que a caixa de aspirinas
devia enviar à caixa de gestão. Por surpresa minha nem todos foram capazes de me
responder, pelo que tive de lhes explicar o que se pretendia e o que tinham de fazer.

Desta forma os alunos deram início à implementação do projecto. O aluno J pediu que
visse o código dele porque tinha um erro, pedi que partilha-se comigo o código, mas este já
não se lembrava como isto se faz. Assim tive de lhe explicar como fazer. Ao observar o
código reparei que tinha vários erros de sintaxe, andou a retirar ; e } em alguma partes do
código que lhe tinha dado. Expliquei-lhe o que estava errado e pedi que alterasse.

O aluno B, pediu que o ajudasse pois não estava a conseguir fazer as alterações, este aluno
referiu: -“eu não percebo nada disto, não sei se o programa está certo ou errado”(

Estive a explicar-lhe, novamente, o que era pretendido no projecto e o que este devia fazer.
Pedi que partilha-se o código comigo para eu poder ver o que estava a fazer. Este aluno
também já não se lembrava de como isto se fazia.

O aluno J, voltou a pedir ajuda pois não estava a conseguir emendar os erros, fui ver e este
continuava na mesma. Assim tive de lhe dizer explicitamente o que faltava no código.
Entretanto, recebi várias solicitações de outros alunos que ia tentando dar resposta
enquanto observava o código do aluno J.

Estive a ajudar o aluno B e J a fazer pretendido, os restantes alunos foram solicitando ajuda
devido aos erros de compilação nomeadamente à falte de ;

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

Notas: Observei algumas lacunas de programação nestes alunos, principalmente não


conseguirem corrigir erros básicos. Notei dificuldade em conseguir dar resposta a todas as
solicitações.

Aula 4

Dia: 5/11/2007

Objectivos: continuação do projecto, Eventos, funções e listas;

Registo das Observações: Comecei por relembrar aos alunos que tinham de entregar a
primeira fase do projecto na próxima aula. Perguntei se tinham estudado alguma coisa de
LSL, disseram-me que não.

O aluno J pediu que o ajudasse pois não estava a perceber nada disto. Assim estive a ajudar
este aluno a conseguir colocar dois objectos a comunicarem entre si.

Fiz uma chamada de atenção geral para lhes explicar como funcionam os eventos em LSL,
dei-lhes um pequeno exemplo para eles testarem. O aluno F disse-me que o meu exemplo
não estava a funcionar, pedi que partilhasse o código para eu poder ver. Observei que este
aluno não esteve atento ao que tinha dito, pelo que tive de lhe explicar o que tinha de fazer.
Mesmo assim este aluno não estava a conseguir perceber o que este código fazia, pelo que
tive de lhe dar outro mais simples. O aluno F referiu: “ agora percebi…”

A seguir estivemos a estudar como se podem criar funções no LSL, tendo lhes dado um
exemplo para eles testarem. O aluno A pediu-me para analisar que o programa dele estava
correcto.

Estive a confirmar com todos os grupos o que tinham de entregar na próxima aula no
SIDE.

Na segunda parte da aula os alunos continuaram a desenvolver o projecto, a fase seguinte


consiste na caixa de gestão actualizar o stock de medicamentos. Sugeri que guardassem

370
numa lista o stock de cada medicamento existente no armazém. Assim pedi-lhes que
fossem ler no LS wiki sobre listas.

O aluno B pediu para eu lhe explicar como funcionam as listas pois não estava a perceber
nada. Assim expliquei-lhe e dei-lhe um exemplo para ele observar. Como disse-me que não
percebia o que este fazia, tive de lhe dar um mais simples e explicar-lhe cada parte do
código. Este aluno comentou: -“A linguagem C eu sei, aqui é que não percebo nada disto.”

Recebi várias solicitações para lhes explicar como funcionam as listas pelo que achei
melhor fazer uma chamada de atenção geral e explicar a todos como estas funcionam tendo
lhes dado um exemplo, para testarem. Contudo, a alguns alunos tive de lhes dar outro mais
simples e explicar como fiz com o aluno B.

No fim da aula relembrei-lhes que tinham de submeter no SIDE a 1º fase do projecto.

Notas: Muitas dificuldades na compreensão da linguagem, estes alunos têm pouca


autonomia, não são capazes de avançarem sozinhos estão sempre à espera que eu os ajude.
Nota-se uma repetição dos erros de compilação como a falta de ; e {.

Aula5

Dia: 12/11/2007

Objectivos: continuação do projecto, mudança de estados.

Registo das observações: Todos os alunos confirmaram que tinham entregue a primeira
fase do projecto. Perguntei se tinham avançado mais alguma coisa ou estudado as listas,
disseram-me que não. Assim pedi-lhes que fossem estudar alguma das funções usadas nas
listas.

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

371
nome do produto. Foi difícil para estes alunos compreenderem qual o objectivo da funçõe
s, que eles criaram, e como a usar.

O aluno J, está constantemente a solicitar ajuda, embora eu tente que ele e o colega o aluno
M procurem resolver os problemas por eles, mas sem sucesso. O aluno J refere
constantemente que percebe de C, mas no entanto não é capaz de resolver um simples erro
como a falta de uma { num if.

O aluno C e S pediram para eu ver se o programa deles fazia o que era pedido, pois este
não tinha erros de compilação, mas não eram capazes de ver se estava correcta a sua
execução. Este tipo de pedido começa a ser muito solicitado pelos alunos.

Nesta aula pouco se avançou no projecto, os alunos não foram capazes de concluir o que
eu tinha pedido.

O aluno J pediu-me para ficar mais um pouco no SL, depois da aula, porque estava com
muitas dúvidas nas listas. Assim, estive com este alunos mais os alunos M, F e T que
entretanto apareceram online a trabalhar no projecto. As maiores dificuldades destes alunos
foram em perceberem o que as funções predefinidas da linguagem fazem, corrigir os erros
de compilação, nomeadamente faltas de ; e {. Não sabem usar funções desenvolvidas por
eles, estes alunos são capazes de as criar as funções mas não sabem como usá-las e
quando.

Notas: Nota-se alguma frustração nos alunos e falta de empenho no seu desenvolvimento,
estão sempre à espera da minha ajuda. Não são capazes de ver sequer se o programa está
correcto ou não.

Aula 6

Dia: 19/11/2007

Objectivos: Ler informação de cartões, semelhante a ler dados em ficheiros.

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

372
Expus o objectivo da aula de hoje, ler informação de cartões, e expliquei-lhes as
semelhanças com o ler dados em ficheiros, que tinham aprendido em C. Pedi-lhes para
irem ver as funções llGetNotecardLine, LLGetInventoryNumber, entre outras.

O aluno R disse-me que não percebia nada do que estas funções faziam, se eu o podia
ajudar, pois não sabia Inglês. Perguntei se o colega percebia, o aluno V, disse-me que não.
Assim, pedi ao aluno V que observa-se o que eu ia explicar ao colega, deste modo estive a
explicar-lhe o que cada uma delas fazia e dei-lhe um exemplo para ele testar. Perguntei-lhe
se compreendeu o exemplo. Disseram-me que não, pelo que tive de lhes dar outro mais
simples, e expliquei-lhes todos os passos do código.

A mesma dificuldade sentiu os aluno A e B, a quem procedi de igual forma.

O aluno J está constantemente a pedir ajuda, pediu-me para verificar se o programa dele
estava a funcionar pois não tem erros de compilação. Perguntei-lhe se ele e o colega não
conseguem ver se o programa funciona ou não, este respondeu:” isto é só texto a correr, eu
não consigo ver se está certo ou não..” Voltei a insistir mas isto é semelhante aos
programas que fazem em C. O aluno J responde “pois mas aqui eu não percebo nada, e
não sou só eu os meus colegas também (...) só que eu como eles não vêm o que digo não
me importo de dizer e peço ajuda”

O aluno R estava a pedir ajuda a algum tempo, pelo que tive de lhe pedir desculpa de só
agora conseguir falar com ele mas estava a falar com outro colega. O código deste aluno
estava com erros de compilação ao analisá-lo observei que faltavam ; chavetas nos if, e por
conseguinte tinham muitos erros de compilação. Assim comecei a escrever comentários no
código antes de cada erro e pedi para eles verem o que tinha escrito. O aluno, conseguiu
corrigir os vários erros sozinho.

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

373
Aula 7

Dia: 26/11/2007

Objectivos: continuação Ler informação de cartões (início do 2º ciclo)

Registo das observações: Comecei por relembrar que na próxima semana tinham de
entregar a 2º fase do projecto. Os alunos A, B R e U disseram que não sabiam que era já na
próxima semana, pelo que tive de lhes relembrar que o método de avaliação era igual para
todos os alunos de Lab. II.

Informei os alunos que tinha traduzido para português algumas das funções predefinidas
da linguagem LSL mais utilizadas.

Nesta aula compareceu o aluno 4 de Lab. III, a meu pedido, para ver se ajuda os colegas a
sentirem-se um pouco mais motivados. Este aluno esteve a mostrar-lhes alguns dos
objectivos que tinha feito e esteve a tirar dúvidas aos colegas.

O aluno J referiu: “pois se este projecto também fosse assim, agora isto é só texto e mais
nada…”

Expus aos alunos as alterações que tinha feito no projecto nomeadamente que tinham de
criar um boneco que recebia os pedidos e que devia mandar bolas de sabão para o ar
sempre que um pedido era satisfeito. Mostrei-lhes a minha boneca e a funcionalidade que
eles tinham de implementar.

Os erros de compilação que foram surgindo, nomeadamente do aluno J, passei a escrever


comentários no código para este ver e corrigir. O aluno referiu que assim é melhor.

Nesta aula estive a ajudar os alunos a concluírem a leitura da informação dos cartões. No
fim da aula verifiquei que os alunos A,B R e U não tinham todas as funcionalidades pedidas
implementadas. Ofereci-me para os ajudar ao longo da semana.

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

374
Aula 8

Dia: 3/12/2007

Objectivos: Continuação do projecto.

Registo das observações: Os alunos A e B não compareceram. Perguntei se todos tinham


submetido no SIDE a segunda fase, disseram-me que sim. Embora os alunos R e U
referiram que não fizeram todas as funcionalidades pedidas.

Nesta aula os alunos estiveram a construir a boneca. Já não se lembravam de como se faz a
réplica de objectos, nem como se usa o zoom. Assim fiz uma chamada de atenção geral
para voltar a explicar como isto se faz.

Os alunos J e M voltaram a pedir se eu podia ficar com eles no SL depois da aula para os
ajudar no projecto. Assim estive com estes alunos no SL online a ajudá-los, notei que a
escrita de comentários no código fez com que os pedidos de ajuda em relação aos erros de
compilação diminuíram. O aluno J pediu-me para o ajudar no LSL pois queria concorrer a
um estágio renumerado no SL.

Notas: Notou-se que os alunos estavam mais descontraídos e satisfeitos por estarem a
construir alguma coisa.

Aula 9

Dia: 10/12/2007

Objectivos: Continuação do projecto

Registo das observações: Os alunos A e B não compareceram. Perguntei aos colegas se


sabiam alguma coisa deste grupo, referiram-me que eles tinham desistido da disciplina.

O aluno M referiu que também tinha vontade de fazer o mesmo, pois não percebia nada
disto e já estava arrependido de se ter voluntariado para estas aulas.

O aluno C pediu que eu visse o código deles pois não percebia a razão pela qual este não
estava a funcionar. Ao analisar o código reparei que tinham as funções definidas mas não
as estavam a chamar no programa. Este tipo de erros em alunos que já tiveram
programação na qual tiveram aprovação e com boas notas é um pouco estranho. Escrevi

375
um comentário no código do aluno a explicar porque razão o programa não podia
funcionar. Este percebeu e tentou corrigir a situação mais o colega o aluno S, mas tive de o
ajudar a chamar as funções pois não conseguiram colocar os parâmetros de entrada
correcto.

Os alunos J e M estavam constantemente a pedir auxílio, não por erros de compilação mas
por não saberem o que fazer a seguir. O mesmo sucedia com os alunos R e V que não
sabiam o que tinham de fazer a seguir. Perguntei-lhes como é que tinham feito o algoritmo,
disseram-me que o algoritmo foi fácil de fazer ali é que não percebem nada.

Assim fiz uma chamada de atenção geral e estive a explicar o que tinham de entregar na 3
fase do projecto. Os alunos F e T disseram-me que já tinham essa parte implementada.

O aluno 4 voltou a comparecer na aula e esteve a ajudar os colegas mais atrasados no


desenvolvimento do projecto. Este aluno referiu que tem tentado motivar os colegas mas
eles não estão a gostar do que estão a fazer.

No fim da aula referi que na próxima tinham de entregar a 3 fase do projecto.

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

Aula 10

Dia: 17/12/2007

Objectivos: continuação do projecto

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

376
O aluno J pediu-me se o podia ajudar nas férias para conseguir acabar o projecto pois
estavam com muitas dificuldades.

Nesta aula estive a ajudar os alunos R e U que estavam mais atrasados no desenvolvimento
do projecto. Estes alunos apesar de não estarem constantemente a pedir auxílio não são
capazes de procurarem soluções para o que estão a fazer. Tive de lhe dar alguns exemplos
para eles testarem e compreenderem como se lê informação de um cartão. Contudo, os
alunos não foram capazes de ver que era esse o código que tinham de aplicar no projecto
deles.

O aluno S perguntou para o canal público: “a professora está aí?” Tive de lhe pedir desculpa
por não o ter atendido mas estava a ajudar um colega dele.

Em relação à boneca os alunos nesta aula não estiveram a trabalhar nela, preferiram
avançam na implementação do projecto.

Notas: a componente visual introduzida no projecto não surtiu o efeito desejado. Os


alunos continuam frustrados e desmotivados.

Aula 11

Dia: 7/01/2008

Objectivos: conclusão do projecto

Observações: durante as férias ajudei os alunos J, M C e S no desenvolvimento do projecto


no SL. Os alunos R e V não pediram ajuda nem compareceram nas horas que eu marquei
com os colegas, apesar de lhes enviar um email a dizer que ia estar online.

Os alunos não implementaram a funcionalidade da boneca enviar bolas de sabão para o ar


quando concluía um pedido. A razão apontada por eles é que não tiveram tempo e também
não acharam muita graça a essa funcionalidade.

Nesta aula estiveram a completar o resto das funcionalidades que lhes faltava. Os alunos R
e V mais atrasados no desenvolvimento deste não compareceram à aula.

377
Primeiro encontro mensal.

Data: 25/10/2007

Primeiro encontro com os alunos no qual estiveram todos presentes. Aproveitei esta
reunião para compreender as dificuldades em usar o editor, bem como para saber as razões
que levaram os alunos a participar neste projecto.

O aluno S referiu:“foi difícil de perceber como ligar os objectos entre si.”

-“Eu não gosto de programar, mas gosto de jogar e como o SL é um mundo virtual e eu gosto deste
tipo de ambientes, vim experimentar. Os meus colegas dizem que gostaram.”

Os restantes alunos confirmaram que também sentiram dificuldades em perceber o que eu


dizia, no que diz respeito ao editor. Em relação ao projecto referiram que pensavam que
iam fazer um projecto diferente como foi o caso dos seus colegas nos outros anos e que
não compreendem o porquê de ser diferente com eles.

Segundo encontro mensal

Data: 22/11/2007

Esta reunião serviu para esclarecer algumas dúvidas sobre o projecto. Em relação à
comunicação utilizada nas aulas os alunos foram unânimes ao dizerem que gostaram pois
podiam por as suas dúvidas sem que os colegas vissem. Como disse o aluno M:

“Gostei, pois podia colocar as minhas dúvidas sem me preocupar com o que os meus colegas iam pensar.”

Em relação ao projecto o aluno J mencionou: -“(...) Isto não tem nada de engraçado… é só
texto, se soubesse que ia ser assim não tinha feito este trabalho.”

Os colegas também são da mesma opinião.

378
Terceiro encontro mensal

Data: 11/01/2008

Este encontro serviu para fazer um análise geral das aulas. Os alunos mostraram o seu
desagrado por terem de aprender outra linguagem de programação que não lhes ia servir de
nada no seu futuro profissional.

Em relação aos comentários escritos no código o aluno C disse:

- “(...) a professora a explicar pelo chat na altura percebe-se mas quando voltamos a cometer
o mesmo erro já não nos lembramos o porquê e também não procuramos o que foi dito no chat
porque já lá está muita coisa escrita e é difícil de localizar; assim escrito no código é mais
rápido de iremos ver”.

Os colegas também são da mesma opinião.

Relativamente ao facto dos colegas terem desistido, os alunos voltaram a confirmar que
também tiveram vontade de fazer o mesmo, o que os motivou a continuar foi o apoio que
tiveram por parte da professora.

379
Relatório das aulas de Laboratório Informático I

Terceiro e quarto ciclos de Investigação-acção

Realizadas entre Março e Junho de 2008

380
Aula 1:

Dia: 14/03/2008

Objectivos: Apresentação do projecto

Registo das observações: apresentação do mundo virtual SL e do projecto aos alunos


de Lab. I, pelo professor da UTAD. Nesta turma voluntariaram-se 9 alunos que
formaram grupos de dois alunos da seguinte forma: aluno A e M; aluno R e C; aluno F e
B; aluno D e I; aluno W. O aluno W fez o projecto sozinho, por opção dele uma vez
que já conhecia o SL.

Os alunos A,M,R,C e W fazem parte da turma da investigadora, os restante alunos (F, B,


D e o I) ficaram na turma do professor Ricardo da ESTG cujas aulas são à terça-feira.

Aula 2

Dia: 28/03/2008

Objectivos: Introdução ao SL, apresentação do editor, construção de objectos

Registo das observações: Esta aula decorreu na UTAD na qual estiveram presentes os
9 alunos que se voluntariaram, a meu pedido de forma a poder explicar o editor do SL.
Os alunos estiveram a trabalhar individualmente, cada um no seu PC. Apesar do aluno
W já conhecer o SL também esteve presente.

Apresentei a sala de trabalho na qual cada grupo tem uma zona definida, mostrei-lhes a
zona de exposições e apresentei-lhes o professor Ricardo que estava online de Leiria.

Nesta aula os alunos estiveram a criar um banco, outros preferiram criar um carro.
Deste modo tive a possibilidade de explicar e demonstrar como se faz o zoom, liga
objectos, criam réplicas.

Esta aula serviu também para apresentar o projecto e a metodologia de avaliação que
consiste em 3 fases a primeira entrega do algoritmo na segunda parte do código
implementado e na 3 o projecto completo.

Na próxima semana os alunos vão estar nas respectivas turmas.

381
Aula 3

Dia: 4/04/2008

Objectivos: Construção dos objectos do projecto, Introdução ao LSL.

Registo de observações: Nesta aula os alunos estiveram a concluir a construção do


carro outros a iniciar a sua construção como foi o caso dos alunos R e C.

Relembrei aos alunos que deviam entregar na próxima semana o algoritmo do projecto.

No decorrer da aula os alunos apenas solicitaram a minha opinião em relação ao carro,


como foi o caso do aluno A, que me perguntou se este estava grande demais. 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.

382
Aula 4

Dia: 11/04/2008

Objectivos: Funções predefinidas da linguagem

Registo das observações: todos os alunos entregaram o algoritmo do projecto. Referi


que na próxima aula íamos conversar sobre as várias soluções apresentadas.

Nesta aula começaram a desenvolver o projecto, colocar o carro a andar. Perguntei se


tinham lido o ficheiro sobre LSL, o aluno R e C disseram-me que não. Assim disse-lhes
para irem ler e só no fim é que poderia começar a trabalhar no projecto. Fiz uma
chamada de atenção geral no qual informei os alunos para a importância de estudarem
antes da aula as funcionalidades da linguagem, caso contrário iriam passar a aula a
estudar o que deviam ter feito em casa.

Os alunos A,M e W começaram a colocar o carro a andar. Assim estive-lhes a perguntar


o que algumas funções predefinidas da linguagem fazem. O aluno M já não se lembrava,
pelo que sugeri que tivessem aberto o ficheiro ou LSLwiki para verem. Estive-lhes a
explicar o que são os eventos e como estes funcionam, tendo lhes dado um exemplo
para eles testarem.

O aluno W como já tinha conhecimentos de LSL, avançou um pouco mais rápido tendo
pedido a minha ajuda para alguns erros de compilação. Ao observar o código dele
verifiquei que lhe faltava alguns ; e tinha parâmetros errados em algumas funções.
Assim, escrevi um comentário antes de cada erro. Recorri às frases que tinha preparado
tendo-me ajudado a responder mais rapidamente. Tive o cuidado de verificar se o aluno
tinha conseguido corrigir todos os erros ele disse-me que sim, os comentários 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.

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

Estes alunos conseguiram colocar o carro a andar continuamente 10 passos. Os alunos


R e C só conseguiram colocar o carro a deslocar-se um passo. Relembrei que na
próxima aula íamos discutir o algoritmo do trabalho.

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

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

Aula5

Dia: 18/04/2008

Objectivos: análise do algoritmo

Registo das observações: Nesta aula estiveram presentes os 9 alunos. O professor


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

384
alunos não perceberam que se eu altera-se a forma da pista o carro teria de ser capaz de
a seguir. O algoritmo que todos eles apresentaram o carro seguia uma trajectória
predefinida. Assim perguntei-lhes o que acontecia se eu alterar a forma da pista?

Eles responderam quase em simultâneo “ o carro continuava a circular”. Tive de lhes


chamar a atenção que nesse caso o carro andava mas não por cima da pista. O aluno D,
disse que não estava a perceber o que eu queria dizer. Assim, disse-lhes supondo que a
pista era quadrada, o carro segue um percurso quadrado, certo. Se eu parar o carro e
alterar a forma da pista para oval o que acontece se eu colocar o carro nessa pista. O
aluno D respondeu: “continua a andar na forma quadrada….” O que eu confirmei; “
exactamente mas não é esse o objectivo do enunciado, se eu alterar a forma da pista o
carro tem de seguir o percurso da nova pista…” O aluno W comentou: “ estou a
perceber… então o meu algoritmo está errado”.

Os colegas também concluíram o mesmo que parte do algoritmo deles tinha erros. O
mesmo sucedeu com os semáforos e com as coimas, as soluções apresentadas não
tinham em consideração todas as vertentes do problema. Ao longo da discussão foram
sugerindo várias soluções para os mesmos problemas, o aluno A referiu se não existia só
uma solução, por exemplo, para a funcionalidade da gasolina. Assim, chamei-lhes a
atenção que existe diversas formas de fazer a mesma coisa, não é obrigatório fazerem
todos da mesma forma é claro que umas soluções são mais eficientes que outras.

No fim desta discussão em grupo, os alunos manifestaram o seu agrado por poderem
discutir as várias soluções e verem o que estava errado em cada uma delas. O aluno w
comentou:”Isto devia ser feito noutras disciplinas, porque muitas vezes só sabemos o
que está errado no fim de termos o projecto todo desenvolvido”

Os alunos ficaram de pensar e apresentar novas soluções para os problemas detectados


no seu algoritmo.

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

385
Aula 6

Dia: 9/05/2008

Objectivos: continuação do projecto, sensores

Registo das observações: No inicio da aula o aluno A disse-me que já tinha pensado
numa solução para a pista : “ o carro devia ter um sensor que via onde estava o próximo
bloco..”. Dei os parabéns ao aluno pela solução apresentada. Perguntei-lhe se tinha
estudado como se implementam os sensores disse-me que tinha visto apenas o que
estava no meu documento sobre LSL. Assim estive a explicar-lhe como estes funcionam
e dei-lhe um exemplo para ele testar e tentar adaptar ao projecto.

Perguntei aos colegas se já tinham pensado numa solução, disseram-me que ainda não,
que para já o carro ia funcionar assim, caminho pré-definido, estavam a ver como ele ia
dar as curvas, os carro por enquanto não curvavam. Assim, estive a ver como estes
alunos estavam a implementar as curvas. Notei que os alunos R e C já tinham estudado
as funções do LSL e estavam a usar a função correcta llSetRot, mas não estava a
funcionar correctamente. O aluno R pediu para eu os ajudar “pois o carro estava um
pouco teimoso em vez de curvar para a direita ia para a esquerda”.

O aluno w nesta aula pediu pouca ajuda diz que estava a ver se coloca o carro a andar
correctamente num percurso pré definido. Tentei que estes alunos se preocupassem em
colocar o carro a andar correctamente mas eles preferiram fazer primeiro assim.

No fim da aula escrevi num objecto que os alunos deviam estudar os sensores, para a
próxima aula.

O professor Ricardo referiu que na turma dele os alunos estiveram a aprender como
funciona os sensores. Nesta aula alguns alunos cometeram vários erros de compilação
que ele comentou no código. Referiu que os alunos D e I estão muito entusiasmados
com a construção da pista e teme que se atrasem no desenvolvimento do programa, já
chamou a atenção deles para se dedicarem mais ao projecto.

Notas: Observa-se que os alunos estão mais conscientes do que têm de fazer no
projecto.

386
Aula 7

Dia: 16/05/2008

Objectivos: sensores, continuação

Registo das observações: Comecei por relembrar que na próxima aula deviam
entregar a primeira parte do projecto. Escrevi num objecto a data de entrega da primeira
fase.

Os alunos R e C estiveram a mostrar-me o carro deles, este já consegue seguir um


percurso pré-definido com curvas. Agora iam tentar alterar para que o carro detecte os
blocos da pista. Referiram que estiveram a conversar com os colegas e que estes lhe
disseram que estavam a usar sensores. Assim, pediram-me que lhes explique como
funcionam os sensores pois tinham estado a estudar, mas não compreenderam muito
bem. Assim estive-lhes a explicar como estes funcionam tendo lhes dado um exemplo
com o código comentado para eles testarem.

O aluno A também pediu o ajuda, enviei-lhe uma mensagem “já falo contigo, estou a
esclarecer dúvidas ao teu colega”. Assim, que terminei estive a ver o código deste aluno
pois o carro só detecta as placas que estão à frente as curvas não.

O aluno W, pediu que o ajudasse com os sensores, assim dei-lhe também o exemplo
para ele testar.

A maior dificuldade sentida pelos alunos consiste em alterarem o raio de acção do


sensor de forma que este detecte os blocos. A maioria dos alunos está a fazer esta
alteração por tentativa erro. No fim da aula só os alunos R e C não tinham conseguido
colocar o sensor a funcionar correctamente.

Na aula do professor Ricardo também observou as mesmas dificuldades.

Notas: Observa-se uma diminuição dos erros de compilação, surgem mais erros de
execução. Nota-se que os alunos estão empenhados no desenvolvimento do projecto.

387
Aula 8

Dia: 23/05/2008

Objectivos: continuação do projecto, cruzamentos na pista, temporizadores…

Registo das observações: Conferi no SIDE que todos os alunos desta turma tinham
entregue a primeira fase do projecto (colocar o carro a andar, independentemente da
posição da pista).

Como os alunos já todos tinham o carro a circular, fiz uma chamada de atenção geral e
perguntei-lhes o que sucedia se a pista tiver cruzamento, responderam-me que o mais
certo era o carro seguir em frente. Sugeri que deviam implementar os semáforos. Assim
estiveram a dedicar-se à sua construção. Coloquei na zona de exposição um semáforo a
funcional para eles verem como podiam construir um. Contudo este exemplo não tinha
o código acessível.

Na segunda parte da aula os alunos dedicaram-se a programar o funcionamento do


semáforo. Assim estivemos a trocar ideias em conjunto sobre como este devia ser
desenvolvido. O aluno W sugeriu que este devia funcionar com um ciclo for e que ao
fim de 5 voltas dia trocar de cor. Perguntei se os outros concordavam, disseram que era
uma boa ideia então sugeri que o implementassem para verem se funcionava. Os alunos
R e C foram os primeiros a concluir o desenvolvimento desta funcionalidade e
chamaram os colegas e disseram isto é demasiado rápido, tem de haver outra forma.

Eu perguntei-lhes como funcionam os semáforos que se encontram nas estradas. O


aluno A referiu troca de sinal ao fim de alguns minutos. Perguntei-lhes porque não
fazem o mesmo. Assim, foram procurar funções que controlem o tempo. Tendo ficado
para trabalho de casa estudar o funcionamento dos temporizadores.

Na outra turma o professor Ricardo referiu que os alunos estiveram a desenvolver o


sistema da gasolina. Os alunos sugerirem várias soluções e cada grupo estava a
implementar uma diferente.

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

Aula 9

Dia: 30/05/2008

Objectivos: temporizadores…

Registo das observações: O aluno R faltou a esta aula. Os alunos continuaram com o
desenvolvimento dos semáforos. O aluno C pediu para lhe explicar como funciona o
evento Timer. O mesmo pedido fez o aluno M. Assim fiz uma chamada de atenção
geral e estive a explicar-lhes como estes funcionam, tendo lhes dado um exemplo para
eles testarem.

Os alunos estiveram a testar o funcionamento dos semáforos, houve algumas


dificuldades em controlar a passagem do verde a amarelo. O aluno W, esqueceu-se que
o semáforo está menos tempo no amarelo do que no vermelho, ou seja o semáforo
deste aluno tinha igual tempo de vermelho, amarelo e verde. Foi o colega C que chamou
atenção para o mal funcionamento deste.

Na segunda parte da aula estivemos a conversar em grupo, como os carros deviam saber
que tinham de para no vermelho. Relembrei-lhes algumas das sugestões que tinham
proposto anteriormente.

Assim ficaram de implementar uma das soluções apresentadas para a próxima aula.

O aluno W referiu que -“(...) foi bastante importante estarmos a discutir o projecto em conjunto pois
podemos esclarecer as nossas dúvidas.”

Os alunos A e M pediram para ficar mais um pouco no SL para os ajudar no projecto.


O aluno F e B também compareceram. Assim estive mais de 3 h com estes alunos
depois da aula terminar a ajudá-los no desenvolvimento do trabalho.

O professor Ricardo comentou que os alunos D e I estavam um pouco atrasados no


desenvolvimento do projecto.

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

Aula 10

Dia: 13/06/2008

Objectivos: Continuação do projecto.

Registo de observações: Relembrei aos alunos que só tínhamos mais uma aula antes
da entrega do trabalho. Nesta aula, estiveram a desenvolver o sistema de gasolina.

O aluno W disse-me que já tinha o seu projecto a funcionar, mas queria que o dono
visse o nível de gasolina que o carro tinha. Assim, sugeri que adicionasse um cilindro
que ia diminuindo à medida que a gasolina ia sendo gasta. O aluno esteve a tentar
desenvolver esta funcionalidade. Contudo, disse-me que não estava a conseguir e ia
fazer de outra forma, ou seja, escrever por cima do carro, em percentagem, a quantidade
de gasolina que este ainda tinha.

Os restantes colegas centraram-se apenas no desenvolvimento do código e não na parte


visual, tendo esta ficado para trabalho de casa.

Os alunos da outra turma já tinham esta funcionalidade implementada. O professor


Ricardo comunicou-me que a aula tinha decorrido bem. Contudo, os alunos D e I
estavam mais atrasados.

Nota: Os alunos já não pedem ajuda devido aos erros de compilação.

Aula 11

Dia: 20/06/2008

Objectivos: Conclusão do projecto.

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

390
ainda lhes falta implementar a parte visual da gasolina e o sistema de coimas. Os
restantes colegas estiveram a desenvolver o sistema de coimas.

O aluno W estava mais adiantado no desenvolvimento do projecto. Estive a conversar


com ele sobre a aprendizagem no SL. Este aluno referiu que gostou do facto de eu ter
comentado por escrito a razão dos erros: “quando tinha um erro eu ia ver o que a professora me
tinha escrito e assim consegui corrigir alguns (...)”

Esta aula decorreu normalmente sem grandes pedidos de ajuda, uma vez que cada grupo
estava concentrado em terminar o projecto.

O professor Ricardo referiu que os alunos D e I não completaram todas as


funcionalidades durante as aulas, mas esperava que ainda o conseguissem fazer.

Primeiro encontro mensal

Datas:17/04/2008

Nesta reunião estiveram presentes os 9 alunos. Estivemos a conversar e a trocar


opiniões sobre o projecto. Em relação às aulas, os alunos referiram que estavam a gostar
de aprender a programar no SL.

Segundo encontro mensal

Datas: 23/05/2008

Nesta reunião estivemos a conversar sobre o projecto, e sobre algumas das soluções
apresentadas na discussão em grupo.

O aluno A disse:

-“(...) esta discussão ajudou-me a compreender o que eu tinha de errado no meu algoritmo
e alguns aspectos que não tinha considerado...”

O aluno B referiu:

-“(...) foi a primeira vez que participei numa discussão assim, ajudou-me a compreender o que tinha de
fazer e estudar...noutras disciplina devia-se fazer o mesmo”

391
Terceiro encontro mensal

Datas: 27/06/2008

Este encontro serviu para fazermos uma avaliação geral de como decorreram as aulas.
Os alunos foram unânimes em referir que gostaram desta metodologia e que devia ser
usada noutras disciplinas.

O aluno S comentou:

-“(...) sempre que me surgia um erro de compilação, eu ia ver o que a professora me tinha
escrito e conseguia corrigi-lo, assim foi mas fácil”.

392

You might also like