Professional Documents
Culture Documents
Aprendizagem Contextualizada de
Programação
Sob orientação do
Professor Doutor Benjamim Fonseca
e do
Professor Doutor Leonel Morgado
Aos professores Doutores Bulas Cruz e Paulo Martins pelo apoio constante na
realização deste trabalho.
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.
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.
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.
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.
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
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
xvi
xvii
Acrónimos
xviii
UO Ultima Online
UTAD Universidade de Trás-os-Montes e Alto Douro
UUI Universally Unique Identifier
xix
1. Introdução
3
Capítulo I: Introdução
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.
4
Capítulo I: Introdução
1.1.Abordagem ao problema
5
Capítulo I: Introdução
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).
6
Capítulo I: Introdução
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:
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;
7
Capítulo I: Introdução
Esta tese possui sete capítulos, que estão organizados da seguinte forma:
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.
9
2. Aprendizagem – fundamentos teóricos
11
Capítulo II: Aprendizagem – Fundamentos Teóricos
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.
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.
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
13
Capítulo II: Aprendizagem – Fundamentos Teóricos
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).
2.1.2. Construtivismo/Cognitivismo
14
Capítulo II: Aprendizagem – Fundamentos Teóricos
Behaviorismo ≠ Construtivismo/Cognitivismo
“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).
15
Capítulo II: Aprendizagem – Fundamentos Teóricos
(...) 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.
16
Capítulo II: Aprendizagem – Fundamentos Teóricos
(...) 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).
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).
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.
“ (…) qualquer assunto pode ser eficazmente ensinado de uma forma intelectualmente
perceptível a qualquer criança em qualquer estado de desenvolvimento.”
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”.
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
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
22
Capítulo II: Aprendizagem – Fundamentos Teóricos
23
Capítulo II: Aprendizagem – Fundamentos Teóricos
24
Capítulo II: Aprendizagem – Fundamentos Teóricos
construtiva dos seus pares, imprescindíveis para uma aprendizagem autónoma e eficaz
(Barrows, 2001).
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.
25
3. Ensino da Programação
27
Capítulo III: Ensino da Programação
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).
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
“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.”
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.".
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:
“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
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.
32
Capítulo III: Ensino da Programação
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
as necessidades do mercado;
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).
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.
35
Capítulo III: Ensino da Programação
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
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
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.
39
Capítulo III: Ensino da Programação
40
Capítulo III: Ensino da Programação
41
Capítulo III: Ensino da Programação
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
43
Capítulo III: Ensino da Programação
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
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
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
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.
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
os mundos programáveis;
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
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.
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
50
Capítulo III: Ensino da Programação
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).
51
Capítulo III: Ensino da Programação
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).
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
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.
54
Capítulo III: Ensino da Programação
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 “.
55
Capítulo III: Ensino da Programação
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
3.4.2.1. Discussão
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
3.4.3.1. BlueJ
58
Capítulo III: Ensino da Programação
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
60
Capítulo III: Ensino da Programação
3.4.3.3. Discussão
61
Capítulo III: Ensino da Programação
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
“The loss of attraction to [computing] comes from our being unable to communicate the
magic and beauty of the field.”
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
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).
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
67
4. Mundos Virtuais
69
Capítulo IV: 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:
70
Capítulo IV: Mundos Virtuais
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.
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.
4.1.2 Interactividade
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:
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
Capítulo IV: Mundos Virtuais
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.
75
Capítulo IV: Mundos Virtuais
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.
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).
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
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.”
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.
80
Capítulo IV: Mundos Virtuais
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.
82
Capítulo IV: Mundos Virtuais
plataformas de desenvolvimento
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:
83
Capítulo IV: Mundos Virtuais
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).
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).
86
Capítulo IV: Mundos Virtuais
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
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
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
Capítulo IV: Mundos Virtuais
91
Capítulo IV: Mundos Virtuais
92
Capítulo IV: Mundos Virtuais
“...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.
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.
94
Capítulo IV: Mundos Virtuais
95
Capítulo IV: Mundos Virtuais
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
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
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
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
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.
104
Capítulo V: Second Life
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).
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.
106
Capítulo V: Second Life
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
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.
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.
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.
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:
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.
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
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.
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.
116
Capítulo V: Second Life
117
Capítulo V: Second Life
Área de
edição do
programa
Área de
mensagens
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.
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.
default {
state_entry() {
llSay( 0, "Hello, Avatar!");
}
touch_start(integer total_number) {
llSay( 0, "Touched.");
}
}
119
Capítulo V: Second Life
120
Capítulo V: Second Life
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:
if(num<3)
return num;
else {
llSay(0,"novo calculo");
default
{
state_entry()
{
integer n=7;
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:
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++;
timer()
{
second++;
float x_d = llFrand (10.0);
float y_d = llFrand (10.0);
float z_d = llFrand (10.0);
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
llParticleSystem([]);
llResetScript();
}
}
}
123
Capítulo V: Second Life
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
126
Capítulo VI: Metodologia de Investigação
127
Capítulo VI: Metodologia de Investigação
128
Capítulo VI: Metodologia de Investigação
1 - Planeamento estratégico;
3 - Observação;
129
Capítulo VI: Metodologia de Investigaçã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
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)
131
Capítulo VI: Metodologia de Investigação
132
Capítulo VI: Metodologia de Investigação
133
7. Aplicação do método de investigação
135
Capítulo VII: Aplicação do Método de Investigação
7.1. Sumário
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
Planeamento Planeamento
Reflexão Reflexão
Acção Acção
Observação Observação
137
Capítulo VII: Aplicação do Método de Investigação
Actividade Reflexão/Plano 1.º Ciclo Reflexão/Plano 2.º Ciclo Reflexão/Plano 3.º Ciclo
Preliminar 4.º Ciclo
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
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.
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
Tabela 7.1: Número de alunos que participaram em cada fase desta investigação e respectivas
disciplinas.
139
Capítulo VII: Aplicação do Método de Investigação
relatórios diários;
registos electrónicos:
questionários;
entrevistas informais.
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.
140
Capítulo VII: Aplicação do Método de Investigação
7.3.3. Questionários
141
Capítulo VII: Aplicação do Método de Investigação
7.3.4. Entrevistas
142
Capítulo VII: Aplicação do Método de Investigação
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.
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).
Questionários e entrevistas.
143
Capítulo VII: Aplicação do Método de Investigaçã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).
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.
145
Capítulo VII: Aplicação do Método de Investigação
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).
Estruturar o código;
147
Capítulo VII: Aplicação do Método de Investigação
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
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
149
Capítulo VII: Aplicação do Método de Investigação
“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
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.
151
Capítulo VII: Aplicação do Método de Investigação
“…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.
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:
152
Capítulo VII: Aplicação do Método de Investigação
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.
154
Capítulo VII: Aplicação do Método de Investigação
155
Capítulo VII: Aplicação do Método de Investigação
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.
156
Capítulo VII: Aplicação do Método de Investigação
-“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.)
157
Capítulo VII: Aplicação do Método de Investigação
-“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
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.
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
7.6.4. Questionários
160
Capítulo VII: Aplicação do Método de Investigação
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;
161
Capítulo VII: Aplicação do Método de Investigação
Participantes Constatações
162
Capítulo VII: Aplicação do Método de Investigação
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.
o Variáveis;
163
Capítulo VII: Aplicação do Método de Investigação
o Estruturação do código;
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;
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.
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.
-“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
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:
-“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)
168
Capítulo VII: Aplicação do Método de Investigação
-“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.
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)
-“(...) 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.)
170
Capítulo VII: Aplicação do Método de Investigação
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
Participantes Constatações
Lab. II
Dificuldades em compreender o objectivo do projecto e consequente
desmotivação dos alunos;
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
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)
- “(...) 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)
175
Capítulo VII: Aplicação do Método de Investigação
-“(...) 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.)
7.10.1. Professora
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”.
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
7.10.2. Questionários
178
Capítulo VII: Aplicação do Método de Investigação
179
Capítulo VII: Aplicação do Método de Investigaçã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
o Estruturar o código;
181
Capítulo VII: Aplicação do Método de Investigação
182
Capítulo VII: Aplicação do Método de Investigação
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:
À 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.
184
Capítulo VII: Aplicação do Método de Investigação
-“(...) 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).
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
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:
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).
Figura 7.16: Objectos com mensagens para os alunos relembrarem o que tinham de fazer.
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
Lab. I
Agrado pela metodologia utilizada, nomeadamente a discussão em grupo do
projecto;
7.12.1. Questionários
188
Capítulo VII: Aplicação do Método de Investigação
189
8. Análise dos resultados
191
Capítulo VIII: Análise 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.
métodos de comunicação;
projecto;
processo de aprendizagem;
processo de ensino.
8.1.1. Comunicação
192
Capítulo VIII: Análise dos Resultados
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 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.
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
- “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)
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)
“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)
8.1.2. Projecto
195
Capítulo VIII: Análise dos Resultados
-“(...) 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
- “(...) 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.
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”.
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.
199
Capítulo VIII: Análise dos Resultados
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)
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.
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
-“(...)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)
-“(...)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)
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
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.
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:
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)
“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.”
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
-“(...) 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)
-“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”…’,
-“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:
207
Capítulo VIII: Análise dos Resultados
-“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)
- “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)
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.
208
Capítulo VIII: Análise dos Resultados
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.
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.
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
213
Capítulo IX: Proposta de um Modelo
exemplos elucidativos;
214
Capítulo IX: Proposta de um Modelo
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).
215
Capítulo IX: Proposta de um Modelo
216
Capítulo IX: Proposta de um Modelo
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.
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.
219
Capítulo IX: Proposta de um Modelo
220
Capítulo IX: Proposta de um Modelo
-“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.
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).
“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
“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 ).
“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).
223
Capítulo IX: Proposta de um Modelo
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.
224
Capítulo IX: Proposta de um Modelo
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.
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
227
Capítulo IX: Proposta de um Modelo
228
Capítulo IX: Proposta de um Modelo
229
10. Conclusões
231
Capítulo X: Conclusões
10.1. Conclusões
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).
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
233
Capítulo X: Conclusões
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).
235
11. Referências Bibliográficas
Ackoff, R. L. (1998), Acoff’s Best: His Classic Writtings on Management. John Wiley &
Sons, Inc.
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.
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)
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.
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
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.S. (1985). How to design a problem-based curriculum for the preclinical years.
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.
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.
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.
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.
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
238
Bettencourt-da-Cruz, T. M. (2006). A Internet na Construção de Conhecimento Didáctico.
Tese de Doutoramento, Universidade de Aveiro.
Bourne, J., Harris, D., Mayadas, F. (2005). Online Engineering Education: Learning
Anywhere, Anytime. Journal of Engineering Education 94(1), 131-146.
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.
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,.
Bruer, J.T. (1993). Schools for Thought: A science of learning in the classroom. Cambridge
MA: MIT Press.
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.
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
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.
241
Cheng, A. (1998). A graphical programming interface for a children’s constructionist learning
environment. Electrical Engineering and Computer Science Department. MIT,
Cambridge, MA.
Clancy, M. J. e Linn, M. C. (1992). Case studies in the classroom. SIGCSE Bull. 24,
1 (March 1992), 220-224.
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
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.
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
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.
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 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.
Denscombe, M. (1998). The good research guide for small-scale social research
projects, Open University Press.
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.
Diehl, S. (2007). Software visualization: Visualizing the Structure, Behaviour, and Evolution
of Software. Springer New York.
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,
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.
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
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.
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.
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.
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.
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.
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., 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.
248
2007 International Conference on Computer Systems and Technologies, Bulgaria, June
14–15, 2007, ACM: New York
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.
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.
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.
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.
Hofstadter, D. (1979). Gödel, Escher, Bach: an Eternal Golden Braid, Part II, Chapter 10:
"Similar Levels", Basic Books.
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., 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Lewin, K. (1946). Action research and minority problems. Journal of Social Issues, Vol.
2 No. 4, pp. 34-6.
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.
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.
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
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.
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.
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
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.
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., 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., 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.
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
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.
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.
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.
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.
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.
262
Piaget, J. (1976). A Equilibração das estruturas cognitivas. Rio de Janeiro: Zahar
Editores.
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.
Poikela, E. (2004). Developing criteria for knowing and learning atwork: towards
context-based assessment. Journal of Workplace Learning, 16, 5, 267–274.
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.
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.
263
Ralston, A. (1971). Fortran and the first course in computer science. SIGCSE
Bulletin, 3(4):24–29.
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.
Reuters. (2003). Video game hones US soldiers’ fighting skills, The Straits Times, May 17
2003
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
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., 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.
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.
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
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.
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
266
Schroeder, R. (1996). Possible worlds: The social dynamic of virtual reality technology.
Boulder, CO. & Oxford: Westview Press
Sells, C., Flanders, J. and Griffiths, I. (2003). Mastering Visual Studio.NET. O'Reilly
Media; 1st edition
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.
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.
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.
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.
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
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. T. (1989). Tango: a Framework and System for Algorithm Animation. Technical
Report. UMI Order Number: CS-89-30., Brown University.
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.
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.
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.
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.
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.
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.
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.
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.
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.
271
Wilkes, M. (1985). Memoirs of a Computer Pioneer. The MIT Press.
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.
Wu, P. (2009). Teaching basic game programming using JavaScript. J. Comput. Small
Coll. 24, 4 (Apr. 2009), 211-220.
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.
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
274
275
Fonte de dados Denominação Código
276
277
13. Anexos II
278
279
Plano das aulas de Laboratório de Informática I
Actividade Preliminar
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.
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
283
Plano Projecto
284
Plano das aulas de Projecto I
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;
Estruturação do código;
Semana Plano
285
Semana Plano
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.
13 Conclusão do projecto
286
Plano das aulas de Laboratório Informático II
Semana Plano
287
Semana Plano
.
7
Continuação. Ficheiros
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
Estruturar o código;
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
289
Semana Plano
.
7
Continuação. Sensores
10 Continuação do projecto.
11 Conclusão do Projecto
290
291
14. Anexos III
292
293
Licenciatura em Informática Licenciatura em Tecnologias de Informação e Comunicação
Laboratório de Informática I
Trabalho Prático
Cão “Bobi”
Resumo
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” 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 .
dono – frente 5
dono – direita 90
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.
295
Licenciatura em Informática Licenciatura em Tecnologias de Informação e Comunicação
Laboratório de Informática III
Trabalho Prático
Nota: A defesa dos trabalhos pode ser efectuada em qualquer das chamadas do 2º
semestre.
Resumo
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.
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.
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
o Identificar os produtos que lhe foram pedidos e entregá-los por ordem das
cidades pelas quais vai passar.
o Quando o comboio está cheio deve avisar as indústrias que não pode parar.
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
Nota: A defesa dos trabalhos pode ser efectuada em qualquer das chamadas do 2º
semestre.
Robô “Alf”
Resumo
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.
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).
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.
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.
301
Licenciatura em Informática Licenciatura em Tecnologias de Informação e Comunicação
Trabalho Prático
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.
303
Objectivos
6. Produzir relatórios.
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.
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.
• uma lista com os dados de todos os produtos (key, nome, quantidade, quantidade
mínima para repor stock, etc);
• 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
Os dados dos produtos da farmácia devem ser guardados num ficheiro “produtos.txt”,
obedecendo ao seguinte formato:
Exemplo: produtos.txt
Exemplo: movimentos.txt
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
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.
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).
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.
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”.
dono –Circulo
dono –Cumprimenta
dono –Segue-me
dono – stop .
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 nome do BN;
• a quantidade de BN vendidos;
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
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” 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 .
dono – frente 5
dono – direita 90
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.
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 nome do 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
– 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.
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”.
• 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);
314
315
15. Anexos IV
Questionários
316
Questionário Inicial
Sim Não
Sim Não
317
Questionário Intermédio
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
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
322
Aula:1
Dia: 12/03/2007
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.
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”.
330
Aula 9
Dia: 14/05/2007
331
Aula 10
Dia: 28/05/2007
Aula 11
Dia: 4/06/2007
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..”
Aula 12
Dia: 11/06/2007
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.
- “…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.
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.
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.
-“(...) 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.”
335
Relatório das aulas de Lab III
Actividade Preliminar
336
Aula 1:
Dia: 13/03/2007
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
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
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
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.
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.
Aula 8
Dia: 15/05/2007
Aula 9
Dia: 22/05/2007
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
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
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.
Aula 12
Dia: 12/06/2007
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”
Dia: 26/4/2007
Nesta reunião estiveram presentes todos os alunos. Estivemos a trocar ideias sobre o
projecto, tendo os alunos referido que o consideravam um pouco grande e complexo.
Perguntei-lhes se estavam a gostar da experiência, disseram que sim. O aluno 2 comentou:
“ diverti-me imenso a construir o meu comboio que mais parecia um cão “
O aluno 4 referiu. “ fiquei viciado no SL, passo muitas horas a desenvolver objectos só por
brincadeira.”
Dia: 31/05/2007
Este encontro, no qual estiveram presentes todos os alunos, serviu principalmente para
conversar sobre o projecto e como as aulas estão a decorrer. Referiram alguma dificuldade
em conseguirem comunicar comigo. O aluno 1 referiu: “ algumas vezes chamava-mos a
professora mas não nos respondia”.
347
Terceiro encontro mensal
Dia: 12/07/2007
Este encontro serviu para se fazer uma avaliação global das aulas no SL.
348
Relatório das aulas de Projecto I
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.
351
Aula 3
Dia: 24/10/2007
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.
352
Aula 4
Dia: 31/10/2007
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.
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.
Aula5
Dia: 7/11/2007
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.
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
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”.
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
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.
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 }.
Aula 8
Dia: 28/11/2007
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.
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
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 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.
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.
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.
Notas: Observei que estes alunos conseguiram compreender o que tinham de fazer com
relativa facilidade.
Aula 12
Dia: 9/01/2008
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.
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.
Nesta aula limitei-me a observar os alunos a trabalharem pois pouco ou nada fizeram em
relação ao código.
Data: 22/10/2007
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.”
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:
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
366
Aula 1:
Aula 2
Dia: 22/10/2007
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.
Aula 3
Dia: 29/10/2007
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.
Aula 4
Dia: 5/11/2007
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.
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.
Aula5
Dia: 12/11/2007
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
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.
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
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.
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
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
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.
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
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.
Aula 11
Dia: 7/01/2008
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.
-“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.”
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.”
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.
- “(...) 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”.
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
380
Aula 1:
Dia: 14/03/2008
Aula 2
Dia: 28/03/2008
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.
381
Aula 3
Dia: 4/04/2008
Relembrei aos alunos que deviam entregar na próxima semana o algoritmo do projecto.
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.
382
Aula 4
Dia: 11/04/2008
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.
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.
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
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?
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”
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
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
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.
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.
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
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.
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.
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.”
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
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.
Aula 11
Dia: 20/06/2008
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.
Esta aula decorreu normalmente sem grandes pedidos de ajuda, uma vez que cada grupo
estava concentrado em terminar o projecto.
Datas:17/04/2008
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