thaís helena chaves de castro s...
TRANSCRIPT
TesobtGra
S
se apreseenção do aduação em
Thaís H
Sistemati
de
entada cotítulo de Dm Informát
R
Helena Ch
zação da
Program
T
omo requDoutor pelotica da PU
Ori
Rio de Jane
haves de
a Aprend
mação em
Tese de D
uisito parco ProgramaC-Rio.
entador: H
eiro, março
e Castro
dizagem
m Grupo
outorado
cial para a de Pós-
Hugo Fuks
o de 2011
Coo
Tese apdo título InformátExamina
ordenador(
S
presentadade Doutor
ica da Padora abaix
D
D
D
Esco
a) Setorial
Tha
Sistemati
de
a como reqr pelo ProgPUC-Rio. xo assinad
Departame
CaDepartame
SimoDepartame
ola Superio
Departa
do Centro
Rio de
aís Helena
zação da
Program
quisito pargrama de
Aprovadada.
ento de Info
rlos José ento de Info
one Diniz Jento de Info
Denor de Desig
Credinéamento de
o Técnico C
Janeiro, 24
a Chaves d
a Aprend
mação em
rcial para Pós-Gradua pela C
HuO
ormática –
Pereira deormática –
Junqueiraormática –
nise Del Rgn Industria
é Silva de Informática
José EugeCientífico -
4 de março
de Castro
dizagem
m Grupo
obtenção uação em Comissão
ugo Fuks Orientador – PUC-Rio
e Lucena – PUC-Rio
a Barbosa – PUC-Rio
Re Filippo al – UERJ
Menezes ca – UFES
enio Leal - PUC-Rio
o de 2011
Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, da autora e do orientador.
Thaís Helena Chaves de Castro
Concluiu o Bacharelado em Processamento de Dados pela Universidade Federal do Amazonas (UFAM) em 2001, e o Mestrado em Informática pela Universidade Federal do Espírito Santo (UFES) em 2003. É professora do Departamento de Ciência da Computação da UFAM desde 2004, onde atua na pesquisa em Engenharia de Software (processos de desenvolvimento de software, interface humano-computador), Sistemas Colaborativos e Inteligência Artificial (interfaces adaptativas, sistemas multiagente, representação do conhecimento).
Ficha Catalográfica
Castro, Thaís Chaves de
Sistematização da aprendizagem de programação em grupo / Thaís Helena Chaves de Castro ; orientador: Hugo Fuks. – 2011.
154 f.: il. (color.) ; 30 cm
Tese (doutorado) - Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática, 2011.
Inclui referências bibliográficas.
1. Informática - Teses. 2. Aprendizagem de Programação. 3. Programação em Grupo. 4. CSCL. I. Fuks, Hugo. II. Pontifícia Universidade Católica do Rio deJaneiro. Departamento de Informática. III. Título.
CDD:004
A meus pais, marido e filhos, pela dedicação e apoio.
Agradecimentos
A Deus, por tudo.
A meu orientador pelo apoio e objetividade.
A David Robertson (School of Informatics, University of Edinburgh) pela atenção
e expertise.
Aos colegas do Groupware@LES pelo companheirismo.
Aos professores e funcionários da PUC-Rio que facilitaram meu trabalho na
instituição.
Ao CNPq pelo suporte financeiro na PUC-Rio e na University of Edinburgh.
À UFAM pelo investimento na titulação de seu corpo docente.
Resumo
Castro, Thaís Chaves de. Sistematização da Aprendizagem de Programação em Grupo. Rio de Janeiro, 2010. 154p. Tese de Doutorado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.
A programação é uma atividade cognitiva que envolve alto nível de
abstração, cuja aprendizagem permanece bastante complexa apesar das
recorrentes pesquisas no tema. Nas disciplinas introdutórias de programação em
cursos de graduação, o uso de groupware baseado na Internet representa uma
oportunidade para introduzir boas práticas no processo de aprendizagem dos
alunos, especialmente o registro de todas as interações entre os alunos em seus
grupos enquanto resolvem exercícios, bem como a evolução dos códigos
produzidos por cada estudante. Os logs das conversas e os fragmentos de código
nelas inseridos fornecem pistas dos processos de tomada de decisão, da
metodologia de trabalho e do uso de padrões de interação e estereótipos da
composição desses padrões, os quais devem ser filtrados e categorizados para
análise e identificação “just in time” de dificuldades dos estudantes e à oportuna
intervenção do professor durante o processo.
A investigação aqui relatada trata da concepção de elementos estruturantes
para ampliar as oportunidades de intervenção pelo professor em um contexto de
aprendizagem de programação em grupo. A partir de uma série de estudos de caso
com turmas de calouros em cursos de computação, foi desenvolvida a
sistematização de práticas, metodologias e tecnologias em uma abordagem para
apoiar a aprendizagem de programação em grupo, baseada em três frentes de
investigação, a saber: pressupostos pedagógicos, ferramentas LMS e métodos de
colaboração.
O eixo teórico referente à aprendizagem é a teoria de desenvolvimento
cognitivo de Piaget, aliada a técnicas conhecidas de programação em grupo
utilizadas no ensino de graduação em disciplinas introdutórias de programação.
As ferramentas computacionais são utilizadas para monitorar e intervir durante o
processo de aprendizagem. Nesse contexto, ambientes CSCL incentivam a
colaboração e regulam as práticas desejadas, e nesta tese, outras tecnologias,
como linguagens para representação de agentes e identificação de padrões são
agregadas a eles para melhorar o acompanhamento e facilitar a intervenção. Por
fim, como método de colaboração, é proposto um esquema progressivo de
aprendizagem de programação em grupo, que auxilia os alunos a gradativamente
adotarem práticas colaborativas na resolução de exercícios e que pode ser
formalizado para incorporação a plataformas automatizadas.
Palavras-chave
Aprendizagem de programação, programação em grupo, CSCL.
Abstract
Castro, Thaís Chaves de. A Systematization for Group Programming Learning. Rio de Janeiro, 2011. 154p. D.Sc. Thesis – Computer Science Department, Pontifical Catholic University of Rio de Janeiro.
In undergraduate introductory programming courses the use of Internet-
based groupware presents an opportunity to introduce good practices into the
learning process, in particular, information recording of all interaction between
students within their groups while solving exercises as well as code evolution of
their individual productions. Conversation logs with code fragments give clues of
decision making strategies, work methods and use of interaction patterns and
composition stereotypes for those patterns, that must be filtered and organized for
a “just in time” analysis and identification of students’ difficulties and for a proper
intervention from the teacher during that process.
The research reported here deals with devising structuring elements that
may broaden intervention opportunities from the teacher in a context of
group programming learning. Based on a set of case studies with freshmen in
computing courses a systematization for practices, methods and technologies was
developed producing an approach for supporting group programming based in
three investigation paths: pedagogical assumptions, CSCL environments and
collaboration methods.
The main learning rationale is Jean Piaget’s Cognitive Development
Theory, used alongside group programming techniques commonly applied in
undergraduate introductory programming courses. Computational tools are used
to monitor and intervene during learning process and in such context, CSCL
environments encourage collaboration and regulate expected practices. In this
thesis other technologies like languages for agent representation and patterning
identification are also exploited for improving control and facilitate interventions.
Finally, as collaboration method, it is proposed a Programming Progressive
Learning Scheme that helps students to adopt collaborative practices when solving
exercises and that can be formalized to be used with automated platforms.
Keywords
Programming learning, group programming, CSCL.
Sumário
1 Introdução 16
1.1. A Tese 17
1.2. Objetivo e como atingi-lo 18
1.3. Estrutura da Tese 19
2 Análise sobre Aprendizagem de Programação 21
2.1. Experiências em Disciplinas Introdutórias de Programação para
Cursos de Graduação em Computação 24
2.2. A Evolução dos Códigos em Aprendizagem de Programação 27
2.2.1. Identificação de Categorias na Evolução dos Códigos 34
2.3. Conclusão do Capítulo 39
3 Tecnologias para Aprendizagem de Programação em Grupo 41
3.1. Ferramentas para Apoiar a Aprendizagem de Programação em Grupo4
3.2. Aportes Metodológicos e Tecnológicos como Apoio a Disciplinas de
Programação Introdutória 47
3.3. Proposta de Adaptações de um ambiente CSCL para o Contexto da
Aprendizagem de Programação 48
3.3.1. A Engenharia Semiótica 49
3.3.1.1. O Método de Inspeção Semiótica 50
3.3.2. O Contexto da Aprendizagem de Programação utilizando o
ColabWeb 52
3.3.3. Inspeção Semiótica do ColabWeb 53
3.3.3.1. Etapas do MIS 54
3.3.4. Proposta de Melhorias e Adaptações 64
3.4. Conclusão do Capítulo 66
4 Colaboração na Aprendizagem de Programação 68
4.1. Scripts para Apoiar o Processo de Colaboração 70
4.2. Análise de Interações em Ambientes CSCL 71
4.3. Um Estudo de Caso Exploratório sobre Aprendizagem de
Programação em Grupo 72
4.3.1. Análise Quantitativa 73
4.3.2. Análise Qualitativa 75
4.4. Um Esquema Progressivo para Aprendizagem de Programação em
Grupo 78
4.5. Conclusão do Capítulo 84
5 Sistematização da Aprendizagem de Programação em Grupo 86
5.1. Definindo Padrões de Interação – Estudo de Caso Descritivo 87
5.1.1. Metodologia 88
5.1.2. Análise Parte 1 – Obtendo padrões 94
5.1.3. Análise Parte 2 – Usando os padrões na caracterização das
Interações 103
5.2. Representando Padrões de Interação 113
5.3. Identificando Oportunidades de Intervir 116
5.4. Usando a Sistematização – Estudo de Caso Explanatório 118
5.5. Conclusão do Capítulo 125
6 Conclusão 126
6.1. Contribuições 128
6.2. Reflexões Adicionais no Tema 129
6.3. Trabalhos Futuros 130
6.4. Publicações de Resultados Parciais da Tese 131
Referências 133
Apêndice A 140
Exercício sobre Banco de Sangue: Padrões de Interação 140
Análise das Conversas 141
Apêndice B 148
Padrões de Interação no LCC 148
Lista de figuras
Figura 1.1 – Elementos da Tese 18
Figura 2.1 – Funcionamento recursivo do AcKnow 35
Figura 3.1 – Metamensagem para o wiki 56
Figura 3.2 – Página de abertura do ColabWeb 57
Figura 3.3 – Predominância da Linguagem Textual 58
Figura 3.4 – Recurso Calendário 58
Figura 3.5 – Perda de Contexto 59
Figura 3.6 – Visualização de Informações sobre Grupo 60
Figura 3.7 – Navegação nos Grupos 61
Figura 4.1 – Esquema Progressivo de Aprendizagem de Programação em
Grupo 80
Figura 4.2 – Workflow do Esquema Progressivo de Aprendizagem de
Programação em Grupo 83
Figura 5.1 – Representação Formal das Conversas 114
Lista de tabelas
Tabela 2.1 – Histórico da aluna Jane Doe 36
Tabela 4.1 – Distribuição de Critérios para Estudo Experimental 74
Tabela 4.2 – Dificuldades sentidas pelos grupos 76
Tabela 4.3 – Conclusões fornecidas pelos grupos 77
Tabela 4.4 – Percepções sobre as dificuldades sentidas pelos grupos 78
Tabela 5.1 – Tipos e exemplos de padrões de interação 102
Tabela 5.2 – Padrões de Interação para a Fase 3 dos Grupos 1 e 2 103
Tabela 5.3 – Padrões de Interação para a Fase 3 dos Grupos 3 e 5 104
Tabela 5.4 – Padrões de Interação para a Fase 3 dos Grupos 7 e 8 107
Tabela 5.5 – Padrões de Interação do 2º.Exercício da Fase 5, dos Grupos
1 e 5 108
Tabela 5.6 – Padrões de Interação do 2º.Exercício da Fase 5, dos Grupos
3 e 4 109
Tabela 5.7 – Padrões de Interação do 2º. Exercício para a Fase 5, do
Grupo 7 110
Tabela 5.8 – Padrões de Interação do 2º. Exercício para a Fase 5, dos
Grupos 6 e 9 110
Tabela 5.9 – Padrões de Interação do 2º. Exercício para a Fase 5, dos
Grupos 2 e 8 111
Tabela 5.10 – Estereótipo “repetição de padrões de interação” (caso i) 117
Tabela 5.11 – Pistas para intervir nos estereótipos do caso (iii) 118
Tabela 5.12 – Padrões de Interação do 1º. Exercício para a Fase 5 dos
Grupos 2 e 5 de 2009 120
Tabela 5.13 – Padrões de Interação do 1º. Exercício para a Fase 5 do
Grupo 6 de 2009 120
Tabela 5.14 – Padrões de Interação do 1º. Exercício para a Fase 5 do
Grupo 3 de 2009 121
Tabela 5.15 – Padrões de Interação do 2º. Exercício para a Fase 5 dos
Grupos 2 e 3 de 2009 123
Tabela 5.16 – Padrões de Interação do 2º. Exercício para a Fase 5 dos
Grupos 4 e 5 de 2009 124
Lista de quadros
Quadro 5.1 – Enunciado do exercício “Campeonato de Futebol” 95
Quadro 5.2 – Enunciado do exercício “Atendimento em Ambulatório” 95
1 Introdução
Aprendizagem de programação é uma atividade cognitiva que requer alto
nível de raciocínio abstrato (Weinberg, 1971). Essa necessidade de abstração
frequentemente provoca bloqueios nos alunos de graduação em computação
durante a disciplina introdutória de programação, transformando a aprendizagem
no tema em uma experiência penosa e desmotivadora. Para amenizar o problema,
diferentes abordagens têm sido utilizadas e um elemento comum a todas elas é a
busca pelo desenvolvimento de habilidades para a solução de problemas, o que
induz o aluno a intuitivamente entender estratégias como divisão e conquista,
além de ilustrar a representação de uma solução na linguagem de programação
adotada na disciplina.
Abordagens mais recentes procuram aplicar conceitos e técnicas utilizados
em aprendizagem colaborativa à aprendizagem de programação. Nesse caso, a
principal motivação para incorporar a colaboração na aprendizagem é que o
mercado de trabalho exige profissionais aptos a trabalharem em equipes e essa
habilidade é formada durante os cursos de graduação. A construção dessa
habilidade exige um planejamento mais profundo das disciplinas introdutórias. No
plano de curso deve estar prevista a utilização de métodos de aprendizagem
colaborativa além das estratégias de aprendizagem e práticas pedagógicas usuais.
O pressuposto desses métodos colaborativos é de que os alunos aprendem mais
quando conseguem interagir com seus pares, em busca de uma solução para um
dado problema (Delval, 2002).
Em disciplinas introdutórias de programação em nível de graduação, o uso
de groupware baseado na Internet representa uma oportunidade para introduzir
boas práticas no processo de aprendizagem dos alunos, especialmente o registro
de todas as interações entre os alunos em seus grupos enquanto resolvem
exercícios, além do registro da evolução dos códigos de cada aluno. O registro das
atividades é um requisito essencial para acompanhar o progresso da
17
aprendizagem, tornando possível para o professor fornecer feedback apropriado ao
longo do processo, especialmente na realização dos exercícios.
Os alunos que trabalham em grupos apoiados por LMSs (Sistemas de
Gerenciamento da Aprendizagem) geralmente produzem extensos logs de
conversas incluindo fragmentos de código, rastros dos processos de tomada de
decisão, da metodologia de trabalho e do uso de seus próprios padrões de
desenvolvimento, os quais devem ser filtrados e categorizados para futuras
análises dando subsídios para a identificação “just in time” de dificuldades dos
estudantes e à oportuna intervenção do professor durante o processo.
A investigação aqui relatada trata da concepção de elementos estruturantes
para ampliar as oportunidades de intervenção pelo professor em um contexto de
aprendizagem de programação em grupo.
1.1. A Tese
Esta tese investiga tecnologias de apoio à aprendizagem de programação,
enfatizando técnicas de programação em grupo, visando a inserção da colaboração
em contextos de aprendizagem de programação.
Para utilizar técnicas de colaboração em aprendizagem de programação é
necessário investigar essas técnicas e identificar como elas são aproveitadas no
contexto de programação, considerando a natureza abstrata da atividade e as
dificuldades que os alunos iniciantes em cursos de graduação em computação
enfrentam nas disciplinas introdutórias.
O professor dos cursos introdutórios precisa, além de planejar seu curso e
cuidar para que as atividades transcorram conforme planejado, ter a habilidade de
modificar uma atividade ou intervir sempre que identificar alguma dificuldade que
pareça intransponível para os grupos. Para identificar essas dificuldades durante a
realização dos exercícios é desejável que haja monitoramento das atividades, o
que pode ser realizado utilizando um ambiente CSCL, modificado para atender as
demandas de programação.
Em geral, nos cursos de programação introdutória, as turmas são grandes e o
professor, mesmo registrando todas as interações, não consegue, sem auxílio de
mecanismos de filtragem e classificação de conteúdos, acompanhar o que se passa
em cada grupo para poder intervir durante a realização dos exercícios. Daí surge a
quest
de ap
Opor
são
acom
1.2.
uma
três f
Ferra
de P
conh
revis
tendo
ferra
de ap
em e
serem
gradu
utiliz
tão de pesq
prendizagem
Da quest
rtunidades
ampliada
mpanhamen
Objetivo e
O objetivo
abordagem
frentes de i
amentas LM
O pressup
Piaget, alia
hecidas de p
são bibliogr
o em comum
amentas com
prendizagem
empresas d
m utilizada
uação cujo
Segundo
zados para
quisa: como
m de progra
tão de pe
s de interve
as com
nto.
e como at
o desta tese
m para apoia
investigação
MS e no Mé
posto pedag
ada a práti
programaçã
ráfica desta
m o uso de
mputacionai
m. As técni
de desenvol
as em disc
cerne é com
a investiga
apoiar a ap
ampliar op
amação em g
squisa acim
enção na a
o uso d
tingi-lo
é sistemati
ar a aprendiz
o devem se
étodo de Co
Figura 1.1
gógico da te
cas vigente
ão em grupo
tese se bas
software de
is são úteis
cas de prog
lvimento de
iplinas intr
mputação.
ação feita
prendizagem
portunidades
grupo?
ma, embas
aprendizag
de uma
izar práticas
zagem de p
er abertas –
olaboração,
1 – Element
ese é a teor
es de ensi
o. As prátic
seiam em c
e apoio para
para monito
gramação em
e software
rodutórias
nesta tese
m presencia
s de interve
samos nos
em de pro
abordage
s, metodolo
programação
no Pressup
o que é ilu
tos da Tese
ia de desen
no de pro
cas pedagó
oncepções
a a realizaçã
orar e interv
m grupo in
e muitas v
de program
e, os LMS
al na gradu
enção em um
ssa hipótes
gramação
m sistem
ogias e tecno
o em grupo.
posto Pedag
ustrado na F
e
nvolvimento
gramação
gicas relaci
pedagógica
ão de exercíc
vir durante
vestigadas
vezes adap
mação em
s tem sido
ação, confi
18
m processo
se que é:
em grupo
mática de
ologias em
. Para isso,
gógico, nas
Figura 1.1.
o cognitivo
e técnicas
ionadas na
as diversas,
cios. Essas
o processo
são usadas
ptadas para
cursos de
o bastante
irmado por
19
pesquisas em máquinas de busca na web e exemplo prático na instituição onde os
estudos de caso desta tese foram aplicados, a Universidade Federal do Amazonas
(UFAM). Ainda de acordo com a teoria de Piaget, esta pesquisa assume que os
ambientes LMSs aliados a técnicas colaborativas (o que chamamos ambientes
CSCL) incentivam a colaboração e regulam as práticas desejadas. Portanto, o
segundo pilar desta tese é baseado em ambientes CSCL e tecnologias que apoiem
a adoção de práticas desejadas com possibilidades de integração a esses
ambientes. Para isso, foram investigadas linguagens de agentes e adoção do LCC
para descrever agentes responsáveis pela identificação de padrões de interação
gerados a partir de um esquema proposto nesta tese.
Nesta tese, a intervenção é vista como o ponto crucial na aprendizagem de
programação em grupo. Neste sentido, foi proposto um esquema progressivo de
aprendizagem de programação, que auxilia os alunos a gradativamente adotarem
práticas colaborativas na resolução de exercícios de programação enquanto o
professor observa como eles estão incorporando práticas colaborativas às práticas
individuais anteriormente identificadas através de uma análise baseada na
evolução dos códigos individuais dos alunos, desenvolvida no contexto desta tese.
Esse esquema pode, conforme verificado com uma linguagem de representação do
conhecimento, ser generalizado para outros contextos de aprendizagem.
1.3. Estrutura da Tese
No Capítulo 2 é feita uma análise sobre a aprendizagem de programação,
discutindo as peculiaridades dessa atividade, contextualizada no cenário das
disciplinas introdutórias em cursos de graduação em computação, onde se adota
como elemento de referência à análise, a evolução dos artefatos (códigos-fonte)
produzidos pelos estudantes, segundo categorias descritivas da evolução de tais
artefatos, identificadas automaticamente no início da pesquisa aqui relatada.
Considerando o contexto da aprendizagem de programação em grupo, no
Capítulo 3 são discutidas algumas das metodologias utilizadas bem como as
tecnologias de apoio ao processo. Tomando como objeto de investigação um
ambiente CSCL amplamente utilizado no meio acadêmico (o Moodle) e sua
customização e ampliação proposta pelo Departamento de Ciência da Computação
20
da UFAM, o ColabWeb, métodos da Engenharia Semiótica foram utilizados para
propor adaptações e modificações buscando a melhoria da interface deste
ambiente de forma que pudesse atender as especificidades de uma disciplina de
programação. O método utilizado foi o da Inspeção Semiótica, por uma
necessidade do momento em que a inspeção foi realizada, mas a sistematização
proposta nesta tese deixa aberta a escolha do método, pois isso vai depender das
características do ambiente que a ser testado e do contexto de colaboração.
No Capítulo 4 a colaboração é o foco da investigação na aprendizagem de
programação. A partir de um estudo de caso exploratório sobre a aprendizagem de
programação em grupo e da análise dos relatos da literatura na área, é proposto
um esquema progressivo para aprendizagem de programação em grupo. Esse
esquema requer o uso de um ambiente CSCL configurado de forma que atenda às
especificidades e necessidades de interação de cada etapa.
No Capítulo 5, os elementos estruturantes selecionados ou concebidos,
organizados e aplicados nos capítulos anteriores são aplicados na sistematização
da aprendizagem de programação em grupo, através de dois estudos de caso. Essa
sistematização requer a utilização de um método de avaliação constante das
interfaces dos ambientes computacionais utilizados para que estes não atrapalhem
o processo de interação e prejudiquem a intervenção, de um ambiente CSCL que
facilite as interações segundo o pressuposto pedagógico adotado.
O Capítulo 6 apresenta as conclusões desta tese e sua possível aplicação a
outros contextos relacionados, seguido das referências utilizadas e apêndices.
2 Análise sobre Aprendizagem de Programação
Este capítulo discute as abordagens utilizadas para apoiar a aprendizagem de
programação na graduação. Inicia com um levantamento das dificuldades no
primeiro contato do aluno com a construção de programas, comparando com uma
teoria de desenvolvimento cognitivo. Na Seção 2.1 são apresentadas experiências
com o ensino formal de programação em cursos introdutórios de programação,
destacando análises relevantes para o contexto deste trabalho. Em seguida,
baseado na experiência de programação introdutória da UFAM e nos trabalhos
analisados, é proposta e discutida uma forma de representação para identificar e
analisar elementos ligados à evolução de códigos de alunos cursando a disciplina
introdutória de programação, fornecendo pistas para se conhecer como ocorre o
desenvolvimento cognitivo desses alunos em programação.
A busca por conhecimento sobre habilidades necessárias à programação é
recorrente na pesquisa em computação. Em um dos clássicos sobre o assunto,
Dijkstra (1982) defendeu que programar era levar o aluno ao mais alto nível de
pensamento, isto é, à pura abstração. De um ponto de vista de profissionais de
desenvolvimento de software, o livro de Weinberg “The Psychology of Computer
Programming” (1971) aborda o aspecto psicológico da aprendizagem de
programação, envolvendo, além da abstração, habilidades psicossociais. Já Knuth
(2005) afirma que Ciência da Computação é “meramente” a solução de
problemas, expressa através da programação. Seguindo essas considerações,
aprender a programar é aprender a resolver problemas, utilizando níveis de
pensamento mais elevados, requerendo maior uso da abstração. Para que isso tudo
ocorra, também é necessário que haja motivação no próprio grupo social.
Embora haja muita pesquisa sobre o assunto (Weinberg, 1971) (Dijkstra,
1982), todas as etapas do raciocínio pelas quais o indivíduo passa ao adquirir as
habilidades necessárias à programação ainda não são conhecidas, razão pela qual
é tão difícil afirmar quais atividades ou métodos são mais adequados para tornar
22
mais fácil a aprendizagem de programação em cursos de graduação em
computação.
Apesar das etapas de raciocínio que levam alguém a aprender programação
não serem conhecidas, há muitas pesquisas em estilos, modelos e técnicas de
aprendizagem que podem servir de subsídios para entender o processo de
aprendizagem de programação. Jean Piaget, cujo tema central de pesquisa foi
procurar entender como ocorre a aprendizagem em crianças e adolescentes,
adaptou o método clínico de diagnóstico utilizado em medicina para conseguir
compreender por meio de entrevistas como os indivíduos testados estavam
aprendendo determinados conceitos. Seus achados foram amplamente divulgados
e discutidos em seus diversos livros, como (Piaget & Inhelder, 1968), (Piaget,
1972) (Piaget, 1995).
Em (Piaget & Inhelder, 1968), Piaget estabelece estágios de aprendizagem
por onde todos os indivíduos passam para elaborarem pensamentos mais
sofisticados e abstratos. Esses estágios foram definidos acompanhando o processo
natural do desenvolvimento infantil, servindo de parâmetro para intervenção
pedagógica, que deve ser fornecida respeitando o estágio em que a criança se
encontra.
Refletindo sobre os achados de Piaget e procurando estabelecer um paralelo
entre esses estágios de desenvolvimento observados no desenvolvimento da
criança até a adolescência, e os jovens que ingressam em cursos de graduação na
UFAM que, em sua maioria, estão na fase final da adolescência. Como foi o
desenvolvimento da abstração nesses alunos? Será que eles possuem dificuldades?
Diferentemente do que ocorre nos primeiros estágios infantis, sensório-motor e
operações concretas, os estágios seguintes vão requerendo cada vez mais
operações abstratas e o refinamento destas nem sempre é exigido dos alunos no
ensino médio. Isso pode ocorrer devido à metodologia adotada em muitas escolas,
exigências de cumprir um currículo ou ainda pelo fato de que os alunos precisam
passar em testes de avaliação fortemente baseados em conteúdos para poderem
ingressar em um curso de graduação.
Como somos todos diferentes e passamos pelos estágios de
desenvolvimento cada um na sua velocidade, deve-se cogitar que nem todos os
alunos possuem o mesmo nível de abstração para resolver problemas. Ainda que
todos consigam resolver problemas com muita destreza, para programar é
23
necessário abstrair essa solução, criando programas de computador, uma máquina
abstrata. Se ainda examinarmos os muitos relatos na literatura como em
(McKeown e Farrell, 1999), (Clancy et al, 2003), (Chamillard e Braun, 2000),
(Lister e Leaney, 2003), (Eckerdal e Berglund, 2005) que afirmam que os alunos
iniciantes em cursos de graduação em computação possuem alguma dificuldade
em resolver problemas e possuem muito mais dificuldade na abstração das
soluções, percebemos que os alunos não conseguem transferir o conhecimento
adquirido nas disciplinas de conhecimentos gerais da educação básica para uma
representação mais abstrata. Cientes das transições nas etapas do
desenvolvimento, segundo Piaget, o processo de aquisição de níveis de abstração
mais refinados dos alunos de computação deve ser trabalhado de forma
semelhante, levando-os à reflexão.
As disciplinas introdutórias de programação, então, não podem se
concentrar somente na dificuldade de abstração da solução. É necessário que a
disciplina inclua uma etapa anterior, que deve ser fornecida seguindo algum
modelo de solução de problemas para que o aluno, gradativamente consiga
explicitar seus processos de raciocínio e consiga fazer a transição dessas etapas
para as etapas mais abstratas de representação de programas em uma linguagem
que possa ser traduzida para o computador.
Todos os trabalhos acima mencionados afirmam que a aprendizagem de
métodos e a compreensão de conceitos para a construção de programas de
computador não é trivial, pois requer o uso de habilidades cognitivas de alto nível
e um processo de raciocínio abstrato. Alguns trabalhos, como o descrito em
(Dijkstra, 1982), enfatizam que programar envolve mais raciocínio que qualquer
outra habilidade. Apesar de seu caráter abstrato, programação também é uma
atividade de engenharia, uma vez que seu objetivo é a produção de artefatos que
precisam satisfazer requisitos de qualidade, sendo submetidos à verificação. Para
se conhecer como as disciplinas introdutórias de programação identificam as
necessidades e desenvolvem essas habilidades nos alunos a seção seguinte
descreve alguns relatos de experiências com essas disciplinas. A Seção 2.2
descreve como, baseada na literatura revista, procuramos explicitar o processo de
raciocínio dos alunos ao desenvolverem programas na disciplina introdutória.
24
2.1.Experiências em Disciplinas Introdutórias de Programação para Cursos de Graduação em Computação
As disciplinas introdutórias de programação são uma preocupação constante
em diversas instituições de ensino de graduação (McKeown & Farrell, 1999). As
causas são diversas e as soluções mais diversas ainda. O que se deve ter como
parâmetros para avaliar o sucesso de uma disciplina de programação é produção
de códigos ou algoritmos de forma que atendam as especificações do professor.
Apesar das muitas divergências sobre métodos, técnicas, as discussões sobre que
paradigma adotar primeiro, todas as referências consultadas concordam que é
necessário planejar bem essas disciplinas para que a experiência do aluno seja, no
mínimo, agradável e que ele consiga entender os conceitos principais.
O mercado de trabalho do egresso de cursos de computação requer um
profissional capaz de planejar soluções de problemas de forma criativa, utilizando
menos tempo para chegar a bons códigos. Portanto, acreditamos que a partir da
primeira disciplina esses alunos dever ser estimulados com situações-problema
reais e serem constantemente testados em suas habilidades de abstração e
resolução de problemas. Neste sentido, em (Mckeown & Farrell, 1999), os
autores recomendam que os alunos sejam encorajados a aprender técnicas de
resolução de problemas já nesse primeiro curso, pois freqüentemente os alunos
encontram muita dificuldade ao aplicar as competências adquiridas em sua
formação básica, em disciplinas como matemática, a um novo contexto para eles
que é o de programação. Isto acaba sendo uma fonte de medo e frustração,
contribuindo assim para a evasão precoce nos cursos de graduação em
computação. Devido a essa preocupação, em (Clancy et al, 2003) é descrito um
esforço em desenvolver um novo formato para uma disciplina introdutória de
programação baseado em sessões de laboratório. Nessa disciplina, para apoiar as
atividades de programação individuais foram planejadas muitas atividades
relacionadas como discussões online, exercícios de programação em pares, leitura
de textos diretamente da web, anotações reflexivas, entradas no diário e
colaborações usando o processo de revisões por pares para criticar as respostas
dos colegas a um dado tópico.
O artigo descrito acima trata da transformação de uma metodologia
envolvendo aulas teóricas e práticas para outra envolvendo somente aulas práticas,
25
partindo dos problemas para os conceitos, contemplando diversas atividades bem
distribuídas nas sessões. Percebe-se no relato uma preocupação excessiva com o
desenvolvimento de questionários para criar nos alunos o hábito da reflexão, mas
metodologia se provou ineficaz para identificar a origem das dificuldades dos
alunos na apreensão dos conceitos. Quanto aos exercícios de programação
resolvidos em pares, não há evidências de melhoria no desempenho dos alunos
como resultados dessa técnica, visto que não há registro dessas atividades.
Seguindo a linha de avaliação, o trabalho discutido em (Chamillard &
Braun, 2000) descreve a combinação de algumas técnicas de avaliação em uma
disciplina introdutória de programação e demonstra por análises estatísticas as
diferenças e relacionamentos entre essas técnicas. O plano de curso da disciplina
segue a premissa de que antes de aprenderem a programar os alunos devem estar
aptos a resolver problemas. Primeiramente os alunos resolvem problemas sem o
uso de uma linguagem de programação, somente aprendendo posteriormente a
representar a solução em uma linguagem de programação. Nessa disciplina, após a
fase inicial de resolução de problemas, as aulas prosseguem com seis sessões de
laboratório onde os alunos resolvem problemas individualmente, sendo permitida
a consulta a outros colegas sempre que há necessidade. É importante salientar que
a complexidade dos problemas aumenta à medida que as sessões avançam. Uma
vez terminada a fase individual é proposto um estudo de caso consistindo no
desenvolvimento de um programa (preferencialmente um jogo) por grupos
pequenos (2 a 4 integrantes). Ao final, é conduzida uma avaliação da
aprendizagem comparando estatisticamente o desempenho dos alunos nas sessões
de laboratório, o estudo de caso e práticas individuais controladas e sem consulta
(provas) aplicada duas vezes no decorrer do período letivo.
A principal contribuição do trabalho descrito acima é a análise estatística
das correlações entre os diferentes mecanismos de avaliação utilizados, embora
permaneça questionável se os métodos de avaliação utilizados foram os mais
adequados à aprendizagem dos alunos. Outros elementos da análise têm sua
confiabilidade prejudicada devido à ausência de controle no ambiente físico de
trabalho dos grupos, tornando impossível afirmar se uma dada tarefa em grupo foi
desenvolvida por um único aluno, o que poderia causar um erro nas correlações.
Outro trabalho que também utiliza modelos de avaliação para apoiar a
aprendizagem de programação é descrito em (Lister & Leaney, 2003). Nesse
26
artigo, os autores utilizam pré-avaliações dos alunos (aquelas feitas no início da
disciplina ou de cada assunto) como base para categorizá-los em estágios de
aprendizagem, conforme os estágios definidos na taxonomia de Bloom (Bloom,
1956) para a área cognitiva: conhecimento, compreensão, aplicação, análise,
síntese e avaliação. A partir daí a disciplina é formatada de modo a oferecer
atividades diferenciadas aos alunos, correspondendo aos diferentes estágios de
treinamento.
Em um esforço para identificar aspectos que facilitam a aprendizagem de
programação, o trabalho descrito em (Eckerdal & Berglund, 2005) afirma que
através das respostas dos alunos a perguntas como “o que é programação?” é
possível definir uma ordem de apresentação dos paradigmas de programação. Os
autores acreditam que os alunos precisam saber o que a aprendizagem de
programação realmente é, para que aprendam seus conceitos abstratos. A maioria
das respostas apuradas sugere que aqueles alunos sejam primeiramente expostos a
um raciocínio mais estruturado antes de serem apresentados a paradigmas mais
abstratos como a orientação a objetos.
O que realmente é necessário para se aprender e facilitar a aprendizagem de
programação ainda não é conhecido. Embora alguns dos trabalhos mencionados
acima façam tentativas de estabelecer um roteiro comprovadamente adequado
para seguir, não há trabalhos na literatura revista até janeiro de 2010 que tenham
tido êxito em estabelecer métodos irrefutáveis e técnicas para aprendizagem de
programação. Por outro lado, há iniciativas cujo principal objetivo é criar e manter
o interesse dos alunos na disciplina utilizando abordagens inicialmente baseadas
nos processos de resolução de problemas que os alunos iniciantes em cursos de
graduação em computação já foram expostos durante a educação básica,
necessárias à apreensão dos conceitos. Outros ainda valorizam as práticas
colaborativas, como a técnica de programação em pares, parte da metodologia dos
métodos ágeis de programação, como meio de envolver os alunos em projetos de
interesse coletivo, proporcionando uma vivência em grupo, necessária no mercado
de trabalho.
27
2.2. A Evolução dos Códigos em Aprendizagem de Programação
Buscar compreender quais processos cognitivos estão envolvidos na
aquisição das habilidades para programação possibilita que as práticas utilizadas
por cada aluno se tornem evidentes e o conhecimento gerado possa ser reutilizado
em outros cursos de programação introdutória. Nesta seção apresentamos uma
caracterização de diferentes maneiras de agrupar as modificações observadas na
evolução dos códigos de alunos de Ciência da Computação e Engenharia da
Computação cursando a disciplina de Introdução à Computação na UFAM.
As versões de códigos, objeto desta análise, foram obtidas diretamente de
um banco de dados local, que foi povoado durante a realização de trabalhos
práticos da disciplina introdutória, conforme planejamento e execução discutida
em (Almeida, Castro & Castro, 2006).
Conforme mencionado anteriormente, na UFAM há um histórico de
experiências com diferentes abordagens na disciplina introdutória dos cursos de
graduação em computação. Esta disciplina vem sendo ministrada desde 1990 com
o paradigma funcional e, na época em que este estudo foi realizado (2007/2008) a
linguagem Haskell vinha sendo utilizada há aproximadamente quatro anos. A
análise abaixo apresentada é baseada nas características da linguagem Haskell,
embora os conceitos abordados sejam pertinentes a qualquer linguagem de
programação.
Ao observar os códigos dos alunos, identificamos e agrupamos as
modificações na evolução dos códigos em três categorias de evolução de códigos:
sintáticas, semânticas e refactoring. Juntamente com exemplos em Haskell,
fornecemos fragmentos em Prolog que capturam esses tipos de modificação.
Modificações sintáticas – exemplos: endentação, inserção e deleção de
caracteres. Essas modificações visam tornar o código interpretado corretamente
pelo interpretador Haskell, processo que sugere muitas correções por tentativa e
erro na tentativa de encontrar uma solução. Tipos de modificações sintáticas:
a. Endentação – endentação da segunda linha de uma função, posicionando
o código + x/y após o símbolo de igualdade, para que seja visto como uma linha
única pelo interpretador. O exemplo seguinte mostra um ajuste necessário (do
Programa A para o Programa B) às especificidades do Haskell, sem mudança na
representação do programa.
28
Programa A Programa B
f x y = x*y
+ x/y
f x y = x*y
+ x/y
Uma maneira de detectar automaticamente os espaços extras acrescentados
ao Programa B é transformando termos (todo caractere no programa) em
elementos de lista. Feito isso, é possível comparar cada elemento da lista e inferir
que tipo de modificação ocorreu. Abaixo está um exemplo de fragmento de
código em Prolog, que ilustra como comparar quaisquer dois programas.
sameF(T1,T2) :-
T1=.. [FunctionName|BodyList],
T2=.. [FunctionName|BodyList].
b. Inserção, Modificação ou Deleção de Caractere – ex. Mal uso de , em
vez de ; ou vice-versa e também a ausência de algum símbolo conectivo, como
um operador aritmético. O exemplo seguinte ilustra uma alteração necessária na
solução assim como um ajuste às especificidades do Haskell:
Programa A Programa B
f(x,y)=(x;1)+ (2,y) f(x,y)=(x,1)+(2,y)
No Programa B, foi necessário modificar o símbolo utilizado na tupla (x,1).
Uma proposta para identificação automática de tais modificações requer a
implementação de uma gramática de cláusulas definidas, DCG (Definite Clause
Grammar), capaz de entender códigos em Haskell. No fragmento de código
abaixo há rudimentos de uma gramática em Haskell, baseada no predicado
pattern/1, o qual detecta os erros sintáticos supracitados. Os outros predicados
chamados expr/1, variable/1 and pattern_seq/1 são partes integrantes dos
Programas A e B. Os predicados sp/0 e optsp/0 são verdadeiros (match) para
espaços ótimos e opcionais no código.
decls(Z) --> pattern(X), optsp, "=", optsp, expr(Y),
{Z=..[f,head(X),body(Y)]}.
29
decls(Z) --> pattern(X), optsp, "=", optsp,
decl_seq(Y), {Z=..[f,head(X),Y]}.
decls(Z) --> variable(X1), sp, patternseq(X2), optsp,
"=", optsp, expr(Y), {X=..[head,X1|X2],
Z=..[f,X,body(Y)]}.
decls(Z) --> variable(X1), sp, pattern_seq(X2), optsp,
"=", optsp, decl_seq(Y), {X=..[head,X1|X2],
Z=..[f,X,Y]}.
decl_seq(Z) --> declseq(X), {Z=..[body|X]}.
declseq(Z) --> expr(X), {Z=[X]}.
declseq(Z) --> expr(X), ";", declseq(Y), {Z=[X|Y]}.
c. Inclusão de uma nova função – ex. Acrescentar uma nova função ao
programa, visando desenvolver e testar toda a solução incrementacionalmente.
Isso é normalmente encontrado em códigos de alunos e indica o uso de boas
práticas de programação, enfatizadas no curso introdutório da UFAM, baseadas na
estratégia de divisão e conquista.
Uma maneira de detectar automaticamente tais modificações requer a
implementação do mesmo tipo de regra apresentada anteriormente, uma DCG.
Modificações semânticas – exemplos: modificação nas estruturas de dados;
mudança de tupla para lista; inclusão de uma função recursiva; e correção de
bugs. Essas modificações afetam diretamente a avaliação da função, resultando
em uma saída errada.
a. Mudança de variáveis independentes para tuplas – ex. Uma equação do
Segundo grau poderia ser calculada de duas maneiras: utilizando raízes
independentes ou utilizando tuplas para calcular as duas raízes ao mesmo tempo.
Os dois métodos de representação são encontrados nas soluções dos alunos e estão
corretos e ambos apresentam utilizam os mesmos argumentos, embora no
primeiro haja uma necessidade de se duplicar a definição da função para outra
variável. Exemplo:
Programa A Programa B
r_x a b c =(-b) + e / 2*a
where
e=sqrt(b^2–4*a*c)
rs a b c = (x,y)
where
x = ((-b) + e)/2*a
30
r_y a b c =(-b) – e / 2*a
where
e=sqrt(b^2–4*a*c)
y = ((-b) - e)/2*a
e = sqrt(b^2-4*a*c)
No Programa A duas funções são utilizadas para resolver a equação do
segundo grau. Apesar do esforço extra do programador em duplicar as funções, se
elas forem muito grandes a legibilidade do código seria afetada. O Programa B
apresenta uma solução mais elegante e precisa para o mesmo problema.
Direcionando a saída para uma tupla, no caso (x,y), e definindo localmente a
fórmula o programa todo se torna mais legível, poupando o programador de um
esforço extra desnecessário.
Mais uma vez, para se detectar automaticamente tais modificações uma
implementação possível é utilizando a DCG. Nesse caso, a operação sobre a DCG
também consiste em transformar termos em listas, mas compara cada conjunto em
ambos os programas. Conforme ilustrado no fragmento de código abaixo, é
possível identificar qual estrutura foi modificada entre as versões de código. A
representação abaixo atende tanto estas modificações semânticas quanto as
seguintes.
compare2(T1,T2,Subst) :-
T1 =.. [f,H1,B1|[]],
T2 =.. [f,H2,B2|[]],
H1 =.. [head|Head1],
B1 =.. [body|Body1],
H2 =.. [head|Head2],
B2 =.. [body|Body2],
comp2(Head1,Head2,[],Subst1),
comp2(Body1,Body2,Subst1,Subst).
No predicado acima, a lista de substituição foi construída, tornando possível
a comparação entre T2 e T1.
b. Mudança de tuplas para listas – ex. Se uma solução pode ser representada
utilizando tuplas ou listas, Segundo as noções de eficiência trabalhadas no curso
introdutório, é melhor utilizar listas em vez de tuplas, no caso de se tratar de
31
coleções grandes. No exemplo seguinte é ilustrada a mudança de tuplas (Programa
A) para listas (Programa B):
Programa A Programa B
composed a b = (a, b, b+a) composed a b = [a, b, b+a]
A DCG também é a base para as operações desse tipo. Nesse caso, as
operações realizadas identificam diretamente as mudanças na estrutura, entre duas
versões de código. Utilizando o predicado Prolog built-in ‘:=/2’, mudanças como
as do exemplo são facilmente detectadas, conforme o fragmento de código
mostrado para a modificação sintática (a).
c. Inclusão de uma função recursiva – ex. utilizando uma função recursiva
em vez de uma iterativa. Na maioria dos casos encontrados, e em geral em
linguagens funcionais, recursão é mais apropriada e freqüentemente leva a uma
solução mais precisa. Essa é uma das principais razões pelas quais os professores
têm tanta necessidade de saberem se o conceito de recursão foi plenamente
entendido por seus alunos. O exemplo abaixo mostra a representação de uma
solução para a função fatorial, onde o Programa A apresenta uma solução iterativa
e o Programa B, uma recursiva:
Para se detectar automaticamente tais modificações deve-se implementar
uma regra para identificar se um programa foi escrito utilizando uma função
recursiva. Isto requer a identificação da ocorrência de termos específicos
referentes ao domínio do problema presentes nas versões de código.
d. Correção de bugs – ex. pequenas modificações feitas a fórmulas ou
definições de funções, podendo se caracterizar por correção simples de bugs ou
em um estilo de programação por tentativa e erro. Durante o curso introdutório da
UFAM os alunos têm que utilizar um método para solução de problemas antes da
codificação. Nesse caso, tais modificações são um sinal de que eles podem não ter
Programa A Programa B
fat n = if n==0
then 1
else product [1..n]
fat n = if n==0
then 1
else n * fat(n – 1)
32
seguido essas orientações, tornando-se uma oportunidade para o professor intervir.
Sendo assim, quando uma função não funciona, os alunos ao adotarem essa
prática, geralmente fazem muitas modificações consecutivas sem raciocinar sobre
o problema, ignorando assim o processo de solução de problemas adotado no
curso (Polya, 1986). O código abaixo ilustra a inclusão de uma estrutura
condicional IF-THEN-ELSE, no caso, uma correção simples de bug:
Programa A Programa B
fat n = n * fat (n - 1)fat n = if n==0 then 1
else n * fat(n – 1)
Para detectar automaticamente tal modificação deve ser implementado um
predicado de casamento de padrões, o qual verifica se determinada estrutura
(dependendo da estrutura que se deseja detector) é parte de uma versão seguinte.
Isso também é especialmente útil para verificar se o aluno está raciocinando sobre
o problema antes de iniciar a codificação.
Refactoring – exemplo: modificações cujo objetivo é melhorar o código, de
acordo com métricas de qualidade conhecidas da engenharia de software. As
modificações mostradas abaixo foram extraídas do catálogo de refactorings em
Haskell (Thompson, Reinke & Li, 2006). O catálogo foi adaptado de forma que as
modificações pudessem ser agrupadas em duas categorias: (i) estrutura de dados,
as quais afetam a representação de dados e consequentemente todas as funções
envolvidas pelo refactoring (ex. tipos algébricos ou existenciais, tipos de dados
concretos ou abstratos, construtor ou função construtiva, incluir um construtor); e
(ii) nomeação, a qual implica que a estrutura de ligação do programa permanece a
mesma após o refactoring (ex. inclusão ou remoção de um argumento, remoção ou
inclusão de uma definição, renomeação). Após verificação preliminar dos códigos
dos alunos e conversas com professores que ministraram a disciplina introdutória
na UFAM no período de 2004 a 2008, constatamos que as modificações do tipo
(i) não ocorrem porque a declaração de tipos não é exigida desses alunos, sendo
fornecida a eles quando necessário. Portanto, como esses refactorings são muito
complexos para iniciantes, comentamos e exemplificamos somente aqueles que
são pertinentes ao curso introdutório analisado.
a. Inclusão ou remoção de um argumento – ex. incluir um novo argumento a
uma definição de função ou constante. O valor padrão do novo argumento é
33
fixado no mesmo nível da definição. A posição onde o novo argumento é incluído
não é ao acaso: inserir o argumento no início de uma lista de argumentos implica
que ele só pode ser incluído a aplicações de funções parciais. O exemplo abaixo
mostra a inclusão de uma função indefinida:
Programa A Programa B
f x = x + 17
g z = z + f x
f y x = x + 17
f_y = undefined
g z = z + f f_y x
Uma maneira de detectar automaticamente tal modificação é comparando
duas funções e verificando se os nomes das funções ou parâmetros das funções
foram modificados. A regra seguinte escrita em Prolog ilustra como identificar
uma pequena modificação nos parâmetros da função, sugerindo um refinamento
na solução. Ela exemplifica um casamento de padrões, mantendo os dados em
uma lista substituta. O predicado apresentado abaixo é similar ao apresentado
anteriormente para modificações semânticas do tipo (a), com pequenas
simplificações.
compare1(T1,T2,Subst) :-
T1 =.. [FunctionName|List1],
T2 =.. [FunctionName|List2],
comp1(List1,List2,[],Subst).
b. Remoção ou inclusão de uma definição – ex. exclusão de uma definição
que não está mais sendo utilizada. O exemplo a seguir ilustra a remoção da tabela
da função:
Programa A Programa B
showAll = ...
format = ...
table = ...
showAll = ...
format = ...
Para detectar automaticamente tal modificação basta utilizar o mesmo
predicado apresentado para as modificações semânticas do tipo (a), o compare2/3,
que pode também verificar se o nome de uma função foi modificado ou excluído.
34
Desse modo, não é necessária a criação de um nome predicado e sim estabelecer
os tipos de modificação que se deseja verificar.
c. Renomeação – ex. renomear um identificador de programa, o qual pode
ser uma variável valorada, variável de tipo, um construtor de dados, um construtor
de tipos, um nome de classe ou um nome de uma instância de classe. O exemplo
abaixo ilustra a modificação na função chamada ‘fazer’ para ‘faz’:
Programa A Programa B
fazer = ... fazer ...
entrada = ... fazer ...
tabela = ...
where
fazer = ...
faz = ... faz ...
Entrada = ... faz ...
tabela = ...
where
faz = ...
Utilizando-se o predicado compare/2, ilustrado nas modificações semânticas
do tipo (a) é possível identificar automaticamente tal modificação. O potencial
dessa modificação, além de legibilidade, é para um refactoring desejável, na
detecção de plágio. Se o professor for informado de tal modificação, e verificar
que se tratou de um caso isolado, notando que na versão seguinte do código
daquele aluno não houve melhora em outros trechos do código quanto a métricas
de qualidade de software relativas ao nível do curso, ele deve procurar um código
similar nas versões de código de outros alunos, visando à detecção de plágio.
2.2.1. Identificação de Categorias na Evolução dos Códigos
As regras em Prolog e a DCG foram implementadas e testadas, conforme
mencionamos anteriormente, no banco de dados com as versões de códigos dos
alunos que cursaram Introdução à Computação na UFAM em 2006, ano anterior
ao desenvolvimento dessa ferramenta, chamada AcKnow. O objetivo dessa
ferramenta é analisar e categorizar a evolução dos códigos dos alunos, fornecendo
elementos para que o professor faça intervenções no processo de aprendizagem de
programação de seus alunos enquanto eles ainda estão elaborando sua solução.
Como entrada de dados, o AcKnow foi projetado para receber funções presentes
nos códigos dos alunos indicados por uma análise quantitativa previamente
realizada por uma ferramenta de controle de versões chamada AAEP (Almeida,
Castro & Castro, 2006). Essas indicações são baseadas na quantidade de versões
que c
difer
ident
profe
análi
detal
funci
meca
apres
ende
entre
são a
estru
Além
semâ
de qu
de re
cada aluno
re significat
tificado(s)
essor, que e
ise do AcK
lhada, forne
ionamento
anismos de
O AcKno
sentados an
ntação, inc
e caracteres
aquelas rela
uturas de da
m disso, re
ânticas cujo
ualidade de
efactoring p
fez. Quand
tivamente d
como caso
envia as ve
Know para c
ecendo feed
recursivo d
inferência,
Figura 2.
ow, seguin
nteriormente
clusão ou r
e inclusão
acionadas a
ados e ope
factoring, n
objetivo é
e software. A
ara Haskell
do a essa qu
a distribuiç
o especial,
rsões direta
cada par de
dback diret
do AcKnow
DCG e base
1 – Funcion
ndo as cat
e nesta seçã
emoção de
ou remoção
a avaliação
erações nas
neste conte
a melhoria
Atualmente
, definido e
uantidade d
ão normal d
, ficando
amente para
e versões, o
tamente aos
w, incluindo
e de conhec
namento re
tegorias de
ão, classific
e vírgula e
o de parênte
de funções
funções sã
exto, são c
na qualidad
e o AcKnow
em (Thomps
de versões d
da turma, e
marcado p
a o AcKnow
o professor
s alunos. A
o suas part
cimento.
ecursivo do
e modificaç
ca como m
ponto e ví
eses. As mo
. Por exem
ão classific
casos espec
de do códig
w utiliza pa
son, Reinke
de um ou m
sse(s) aluno
para visual
w. Então, b
faz uma an
A Figura 2.
tes integran
o AcKnow
ções e os
modificações
írgula, espa
odificações s
plo, modifi
adas nessa
ciais de mo
o segundo a
arcialmente
e & Li, 2006
35
mais alunos
o(s) é (são)
lização do
baseado na
nálise mais
1 ilustra o
ntes, como
exemplos
s sintáticas
acejamento
semânticas
icações em
categoria.
odificações
as métricas
o catálogo
6).
36
O AcKnow foi utilizado para analisar a história do desenvolvimento dos
alunos da disciplina Introdução à Computação da UFAM. Como essa análise foi
realizada após o fechamento da disciplina, não obtivemos o consentimento de
todos os alunos para a divulgação, ainda que de forma anônima, de seus códigos.
A análise foi realizada para todos os alunos da turma, sendo os resultados
referentes a esta totalidade, pois obtivemos consentimento para analisar os dados,
só não para mostrar os códigos da maioria. Ao analisarmos os códigos,
identificamos os casos que foram apontados pelo AAEP e procuramos seus
autores, obtendo seu consentimento para divulgação dos códigos de forma
anônima. Dentre esses alunos, uma nos chamou mais atenção pela natureza de
suas modificações, o que também divergiu dos outros alunos indicados pelo
AAEP. Aqui nós a chamamos Jane Doe e iremos analisar detalhadamente a
evolução de seus códigos referentes a um dos exercícios realizados após o
primeiro mês do curso de quatro meses. Na Tabela 2.1 são apresentadas as
categorias de modificações de Jane Doe, associadas aos intervalos de tempo entre
elas.
Tabela 2.1 – Histórico da aluna Jane Doe
Nesta seção apresentamos a evolução dos códigos de Jane Doe como
solução para o seguinte problema: Dado um segmento de reta r, que passa por dois
pontos a e b, localizados no primeiro quadrante do plano cartesiano e qualquer
ponto p, determine se p pertence ao segmento de reta ou à sua continuação ou se
está localizado acima ou abaixo da reta.
Baseado na análise apresentada abaixo é evidenciado que Jane Doe utiliza
corretamente o desenvolvimento incremental de soluções, utilizando a estratégia
de divisão e conquista, perceptível em quase todas as versões de código, as quais
são indícios de uma assimilação do método de solução de problemas de Polya
(1986), trabalhado em sala de aula. Somado a isso, ela ainda utiliza refactoring, o
Versão Intervalo Categoria 1 0 sintática 2 mesmo minuto sintática 3 1 minuto sintática 4 1 minuto sintática 5 8 minutos refactoring 6 171 minutos semântica 7 44 horas refactoring
37
que indica uma preocupação com métricas de qualidade de software. Seguem as
modificações:
(modificação 1)
pertseg x1 y1 x2 y2 x3 y3 = if x1>0 && y1>0 && x2>0 && y2>0
then if seg x1 y1 x2 y2 x3 y3
then "p belongs to AB"
else if det==0
then "p belongs to r"
else if det>0
then "p is above r"
else "p is below r"
else "p is not in the 1st quarter"
seg x1 y1 x2 y2 x3 y3 = (cresc x1 y1 x2 y2 x3 y3||decresc x1 y1 x2 y2 x3
y3||conth x1 y1 x2 y2 x3 y3||contv x1 y1 x2 y2 x3 y3)
(modificação 2)
det x1 y1 x2 y2 x3 y3 = x1*y2+x2*y3+x3*y1-(x3*y2)-(x2*y1)-(x1*y3)
Conforme evidenciados no código (modificação 1) e na (modificação 2), na
primeira versão (modificação 1) ela resolve parcialmente o problema, mas a
solução não é precisa o suficiente. Então, na segunda versão (modificação 1 +
modificação 2), ela mantém o código anterior, acrescentando uma linha, com a
descrição de uma outra função.
(modificação 3)
cresc x1 y1 x2 y2 x3 y3 = x3>x1 && x3<x2 && y3>y1&& y3<y2
decresc x1 y1 x2 y2 x3 y3 = x3>x1 && x3<x2 && y3<y1 && y3>y2
conth x1 y1 x2 y2 x3 y3 = x3>x1 && x3<x2 && y3==y1 && y3==y2
contv x1 y1 x2 y2 x3 y3 = x3==x1 && x3==x2 && y3>y1 && y3<y2
Conforme evidenciado no código acima (modificação 3), nesta terceira
versão, ela acrescenta as funções necessárias para estabelecer as condições da reta.
38
Na quarta versão (modificação 4), ela tenta modificar a última linha do código,
mas desiste após acrescentar e retirar espaços. Na quinta versão ela renomeia
pertseg com segment.
(modificação 4)
segm (x1,y1) (x2,y2) (x3,y3) = (cresc (x1,y1) (x2,y2) (x3,y3)||decresc
(x1,y1) (x2,y2) (x3,y3)||conth (x1,y1) (x2,y2) (x3,y3)||contv (x1,y1) (x2,y2)
(x3,y3))
det (x1,y1) (x2,y2) (x3,y3) = x1*y2+x2*y3+x3*y1-(x3*y2)-(x2*y1)-
(x1*y3)
Conforme mostrado o fragmento de código acima (modificação 4), após
alteração no nome da função, na sexta versão, ela tem um salto cognitivo,
mudando seg x1 y1 x2 y2 x3 y3 por segm (x1,y1) (x2,y2) (x3,y3) e det x1 y1 x2
y2 x3 y3 por det (x1,y1) (x2,y2) (x3,y3) porque percebeu que o problema é mais
facilmente resolvido com o uso de tuplas. Na sétima versão, ela acrescenta uma
nova linha no final do código.
Outra informação relevante relativa à Tabela 2.1 e à evolução do código
descrita acima é que entre as versões 5 e 6 Jane Doe resolveu outros 5 exercícios
da mesma lista de exercícios. Alguns desses exercícios pediam explicitamente
para utilizar tuplas nas soluções. Após resolvê-los, ela retornou ao problema em
questão e submeteu a versão 6 utilizando tuplas na solução. Portanto, Jane Doe
teve o insight ao resolver outro problema, o que é notável em quem não tem
experiência anterior com programação.
Cerca de 100 alunos estavam matriculados na disciplina de Introdução à
Computação no período em que foi gerado o banco de dados com a evolução dos
códigos analisados. O método estatístico utilizado pelo AAEP indicou uma média
de 3 alunos por exercício como casos especiais. Fora Jane Doe, os outros alunos
apresentaram um padrão parecido de modificações, com exceção das de
refactoring, efetuando muitas modificações sintáticas em curto intervalo de tempo
seguidas de algumas modificações semânticas intercaladas com modificações
sintáticas, em intervalos maiores. Somente poucos (4 alunos em 2 exercícios
diferentes) fizeram refactoring. Nesses casos em que ocorreram refactoring, eles
só se concentraram nas últimas versões.
39
Ao analisar a evolução dos códigos dos alunos, refletindo sobre os
experimentos de Piaget (1978) com crianças, percebeu-se que eles passam pelas
mesmas etapas que as crianças quando estão aprendendo novos conceitos que
requerem mais esforço de abstração do que sua estrutura abstrata já armazena.
Primeiramente, assim como as crianças, eles tentam repetidas vezes fazer com que
sua linha de raciocínio não modifique, adaptando o ambiente, no caso fazendo
modificações sintáticas. Quando não conseguem por este caminho tentam
modificar a estrutura do pensamento com o que já conhecem, fazendo uma ou
mais modificações semânticas intercaladas com modificações sintáticas. Aqueles
que já compreendem bem o problema, o que seria comparado à aquisição de
habilidades cognitivas de um próximo estágio no desenvolvimento, conseguem
fazer modificações de refactoring.
A identificação das sequências de utilização das categorias de evolução de
códigos realizada para essa turma é uma pista importante para saber como propor
atividades que incentivem o desenvolvimento do raciocínio abstrato dos alunos.
Assim como afirmado por Piaget e reproduzido em (Parrat-Dayan & Tryphon,
1998) referente ao ensino básico, a aprendizagem colaborativa acelera o
desenvolvimento dessas habilidades se forem incentivadas interações focadas à
resolução de exercícios, uma vez que, organizados em grupos, os alunos são
instigados a defender seus pontos de vista e questionar seus pares. Para que isso
ocorra é essencial que haja um acompanhamento dos professores envolvidos no
processo e que esses consigam identificar pistas para intervirem nas interações,
sempre que houver uma dificuldade na fluidez da discussão.
2.3. Conclusão do Capítulo
Neste capítulo discutimos sobre a necessidade de abstração em programação
e porque ela é um empecilho na aprendizagem de programação. Elaboramos nosso
ponto de vista comparando o desenvolvimento de habilidades de programação
com o desenvolvimento de habilidades cognitivas nas crianças, pois pelo que
observamos, o processo é similar ao de adultos para a aquisição de habilidades de
raciocínio mais abstrato, como é o caso da programação.
Descrevemos o que algumas pesquisas têm demonstrado sobre métodos e
técnicas utilizados em salas de aula, com o objetivo de facilitar a aprendizagem de
40
programação de alunos de graduação, principalmente de cursos de computação.
Com isso, identificamos que a utilização de técnicas de solução de problemas é
um meio importante para sistematizar o processo de aprendizagem através da
reflexão em termos de problemas, mas a escolha da linguagem de programação
adotada no curso introdutório é essencial para tornar a codificação mais centrada
na solução do problema e menos em recursos da linguagem.
A Seção 2.2, baseada em (Castro, Fuks & Castro, 2008b), trata da análise
sobre a evolução dos códigos dos alunos de uma turma iniciante em programação.
Ela explicitou, através da identificação de categorias, o processo de
desenvolvimento de códigos como solução de exercícios, utilizando o método de
solução de problemas de Polya (1976). Com isso, o professor, se auxiliado por
mecanismos de identificação dos gargalos na evolução dos códigos, como muitas
modificações sintáticas sem modificação semântica e sem êxito na solução do
problema, ele pode intervir antes mesmo do aluno procurá-lo e assim contribuir
para o processo de aquisição de habilidades em programação daquele aluno.
No próximo capítulo descrevemos uma investigação sobre as tecnologias
que apóiam a aprendizagem de programação em grupo e ajudam o professor a
intervir. Assim como o AcKnow detecta elementos do processo de aquisição do
conhecimento em programação, outras ferramentas e técnicas de computação
auxiliam o professor a detectar outras características necessárias à intervenção
adequada.
3 Tecnologias para Aprendizagem de Programação em Grupo
Neste capítulo discute-se sobre as tecnologias e algumas metodologias que
aliadas a essas tecnologias auxiliam na aprendizagem de programação em grupo.
Para isso, iniciamos com relatos do estado da arte nesse tema, comparando
abordagens que utilizam groupware e LMSs passíveis de utilização na
aprendizagem de programação em grupo. Após essa exploração inicial,
descrevemos exemplos de ferramentas desenvolvidas especialmente para apoiar
programação em grupo. Continuando com a busca por diretrizes para unir
tecnologias e metodologias para criar cursos introdutórios de programação em
grupo, apresentamos modelos de cursos idealizados com esse propósito. Na última
seção, discutimos então, em um contexto de utilização de um LMS, a aplicação de
uma inspeção para se descobrir se os elementos de interface projetados visando
aprendizagem de programação em grupo estavam adequados ao seu propósito, de
acordo com um método de inspeção baseado em engenharia semiótica.
Há algum tempo, em computação, para facilitar a abstração do mundo
complexo, adota-se uma estratégia de divisão e conquista a priori, assumindo-se
que as peças divididas são independentes umas das outras (Dijkstra, 1982). Além
disso, com o avanço no desenvolvimento das tecnologias, é necessário procurar
entender como cada peça se encaixa no contexto (Lieberman & Selker, 2000).
Por esse motivo, é necessário se adaptar as ferramentas utilizadas para
apoiar aprendizagem em geral a um contexto específico, envolvendo todos os
tipos de tecnologias e metodologias necessárias e adequadas, independente de sua
área de aplicação.
Acreditava-se que colaboração irrestrita e completamente natural ocorria
sempre que se formavam grupos de interesses comuns, mas com o passar dos
anos, tornou-se evidente que alguma forma de estrutura adicional é necessária
para facilitar a aprendizagem e a interação (Dillenbourg & Fischer, 2007). Essa
estrutura adicional deve estar presente nos ambientes computacionais utilizados
42
para aprendizagem. A partir de agora, para facilitar a leitura da tese, se o LMS se
propuser a fornecer suporte também à colaboração, chamaremos de ambiente
CSCL (do inglês Computer Supported Collaborative Learning).
Com o objetivo de analisar as interações em ambientes CSCL, de acordo
com seu contexto de aprendizagem, conforme descrito em (Dillenbourg &
Fischer, 2007), as abordagens baseadas em esquemas de codificação são, segundo
o autor, “especialmente interessantes” por facilitarem a automatização do
processo de análise. Essa possibilidade de automatização favorece análises de
interação em tempo real, o que possibilita que o professor receba informações
sobre quais grupos em sua turma precisam de sua ajuda em um determinado
momento e que tipo de suporte é necessário, facilitando a intervenção.
Apesar de a intervenção ser um fator chave para a aprendizagem de
programação, há relatos de experimentos com ambientes de programação
colaborativa, não voltados para a aprendizagem, onde ela parece não ter tido
muita importância. É o caso dos experimentos descritos em (Nosek, 1998), onde
são enfatizadas algumas vantagens em se investir mais em práticas de
colaborativas. Nas duas edições desses experimentos os times desenvolveram
programas mais eficientes, demonstrando, em alguns casos, soluções muito
criativas para problemas desafiadores e importantes em seu domínio natural.
O trabalho de Nosek afirma que a programação colaborativa deve ser
incentivada por questões de eficiência. No entanto, um ambiente CSCL com
suporte à programação deveria possuir mecanismos mais específicos para
acompanhamento da codificação dos grupos.
Para se intervir em ambientes CSCL configurados para programação, é
necessário que estes possuam ferramentas de coordenação de atividades
relacionadas ao processo de desenvolvimento, de forma que as oportunidades para
de intervenção sejam identificadas e direcionadas rapidamente ao professor para
que assim consiga intervir e modificar a atitude do grupo assim que a dificuldade
surge. A ferramenta AcKnow, detalhada no capítulo anterior, foi desenvolvida
para avaliar a evolução dos códigos individuais dos alunos, mas poderia ser
utilizada, em conjunto com práticas de programação em grupo, para avaliar a
evolução dos códigos do grupo. Nesse caso, a análise poderia ser realizada dentro
do espaço do grupo no ambiente CSCL utilizado.
43
Sabe-se (Davis, 1989) que todos os sistemas de ensino e aprendizagem
deveriam ser construídos em duas fundações: as necessidades dos alunos e a
consequência da aprendizagem do curso ou programa. Um ambiente de
aprendizagem ideal tem que ser baseado em um plano que flui de um
entendimento completo desses dois fundamentos (Davis, 1989). Se um plano de
utilização do ambiente é necessário para aprendizagem em geral é importante
também para aprendizagem de programação em grupo.
Corroborando com a importância da aprendizagem de programação em
grupo com apoio de ambientes CSCL, em (Aragon, Johnson & Shaik, 2002) são
definidos os requisitos para aprendizagem nesses ambientes e são feitas algumas
recomendações para quem for trabalhar com esses ambientes: criar times virtuais
de aprendizagem; simular a realidade utilizando estudos de caso apropriados; e
requisitar projetos colaborativos das escolas, empresas ou outras organizações.
Na seção seguinte selecionamos e descrevemos algumas ferramentas
desenvolvidas para apoiar a programação em grupo, considerando além da
necessidade de representação de contexto em ambientes CSCL, a identificação de
oportunidades de intervenção nesses ambientes e as recomendações para cursos
que utilizam esses ambientes.
3.1.Ferramentas para Apoiar a Aprendizagem de Programação em Grupo
Das ferramentas pesquisadas no Google até início de Janeiro de 2011, foram
selecionadas as que apresentavam uma descrição consistente e resultados claros
de análise de utilização. Como cursos introdutórios utilizam diferentes paradigmas
de programação, procuramos fazer uma análise abrangente, iniciando com
ferramentas voltadas à produção de algoritmos. Em seguida, apresentamos uma
que utiliza linguagem de programação estruturada, envolvendo um processo de
solução de problemas. Outras ferramentas desenvolvidas especificamente para
programação distribuída e as voltadas à percepção das atividades de times de
desenvolvimento precedem um relato sobre uma análise comparativa das
ferramentas que envolvem visualização.
Scratch é uma ferramenta educacional para o entendimento de construção de
algoritmos (Jain, Singhal & Gupta, 2010). Ela foi projetada para facilitar a
44
manipulação de mídia por alunos iniciantes em programação. Segundo seus
autores, ela estimula os alunos a desenvolverem programas e aprenderem sobre
objetos, pois basta arrastar e organizar blocos, no estilo Lego, para construir um
algoritmo. Como extensão ao Scratch, os autores propõem um framework
colaborativo para o compartilhamento de idéias e códigos implementados. O
aluno envia seu código diretamente a outro usuário ou compartilha-o com um
grupo, que analisam e editam o código e o devolvem com anotações.
Na mesma linha voltada à construção de algoritmos está o RAPTOR
(Carlisle, Wilson, Humphries & Hadfield, 2004) que utiliza símbolos gráficos,
como caixas de fluxograma, em vez dos blocos Lego do Scratch. Os alunos, então,
executam esses algoritmos no ambiente nos modos contínuo ou passo a passo. O
ambiente visualmente mostra a localização do símbolo em execução assim como
os conteúdos de todas as variáveis.
No sentido de viabilizar uma maior percepção de contexto, é descrito em
(Selker, 1994) o COgnitive Adaptive Computer Help (COACH), que é um
sistema de ajuda que monitora as ações do usuário. Quando um usuário inicia uma
atividade não familiar, o COACH lhe apresenta conselhos proativamente. Esse
sistema foi desenvolvido para proporcionar aprendizagem de programação através
do uso de “helps”. Assim, COACH é um sistema de help proativo e adaptativo
que explica procedimentos em termos de contexto do próprio usuário.
Em cursos de programação há muitas dificuldades a considerar, incluindo as
formas de estimular as interações dos alunos na aula ou entre aulas, métodos de
enriquecer as experiências de aprendizagem dos alunos e meios de ajudar os
alunos no compartilhamento de conhecimento com seus colegas. Em cursos
tradicionais de programação, programação baseada em solução de problemas é
considerara uma abordagem promissora (Hwang, Wang, Hwang, et al., 2008). A
principal dificuldade encontrada por iniciantes em programação é em expressar
soluções de problemas como programas. Portanto, a abrangência de compreensão
de programação e como aplicá-la à geração de programas devem permanecer um
foco importante. O WPAS foi desenvolvido para dar suporte às atividades de
aprendizagem, elaboradas segundo a taxonomia de Bloom voltado ao
desenvolvimento cognitivo. Fazendo uma correspondência com a taxonomia de
Bloom, as atividades elaboradas envolvem: teste de conceitos de programação,
preenchimento de lacunas no programa, depuração de código, codificação para
45
resolver problemas e revisão por pares, relativas aos níveis de desenvolvimento
cognitivo: conhecimento e compreensão, aplicação, análise, síntese e avaliação.
Trabalho em grupo pode ser apoiado com outras ferramentas groupware
como anotações de código. Programação pode ser apoiada, por exemplo, com
destaque de sintaxe. A transmissão de código e visualização deve ser feita mais
facilmente. Além disso, É necessário que se tenha suporte para a edição de código
fonte em grupo (Moreno, Myller & Sutinen, 2004).
RECIPE (Shen & Sun, 2000) é um protótipo para dar suporte à programação
colaborativa. Essa ferramenta possibilita o compartilhamento de códigos em Java,
com níveis de permissão diferentes, fornecidos pelo autor. Ela integra também um
compilador e os códigos compartilhados são visualizados e editados ao mesmo
tempo por múltiplos usuários, desde que tenham permissão para isso.
Em (Hillegersberg & Herrera, 2007) é apresentada uma visão geral e uma
proposta de requisitos de usuários para ambientes de apoio ao desenvolvimento
em times de desenvolvimento geograficamente distantes. Os requisitos são:
descrever e manter informação dos dados durante o ciclo de vida do
desenvolvimento do produto; manter coordenação e controle durante um projeto e
transversalmente a projetos; possuir acessibilidade remota ao ambiente de projeto;
negociar e encontrar consenso com membros de times de outros ambientes
semelhantes.
Em (Jo & Arnold, 2003) é apresentada uma experiência com projeto e
implementação de uma ferramenta colaborativa para suporte à programação na
Internet. Ele dá suporte comunicação síncrona entre os diferentes dispositivos e
participantes. A ferramenta DPE é então um tipo de groupware que suporta
programação distribuída por engenheiros de software. DPE possui mecanismos de
discussões online, banco de dados de software, ambiente de programação
integrado e ferramentas para engenharia de software distribuída.
JeCo (Moreno, Myller & Sutinen, 2004b) é uma ferramenta colaborativa
simplificada para dar suporte à aprendizagem de programação. A proposta é
fornecer uma ferramenta que promova a visualização de programas e facilite a
colaboração para aumentar o compromisso dos alunos. JeCo enfatiza
aprendizagem em grupo aumentando a percepção dos times de alunos. JeCo
integra dois sistemas existentes, Jeliot3 e Woven Stories. O Jeliot 3 anima a
execução de programas. O Woven Stories é uma ferramenta de co-autoria que
46
representa o histórico do documento em forma de grafo (Moreno, Myller &
Sutinen, 2004).
Jazz (Cheng, Hupfer, Ross, Patterson & Clark, 2003) é baseado em uma
metáfora de escritório aberto para desenvolvimento de aplicações. Seguindo a
proposta da Extreme Programming (Beck, 1999), desenvolvedores organizadores
em um time trabalham próximos, cada um em sua estação de trabalho, onde
haverá em outro lugar um espaço para as reuniões dos times, compartilhamento de
quadros e horários, etc. O ponto chave dessa organização do trabalho é percepção
(awareness) do time. O aspecto mais visível dos melhoramentos do Jazz para o
Eclipse é a “Jazz Band”, uma visualização que proporciona ao usuário uma
percepção periférica de outros membros do time. Ela mostra o usuário e as listas
de times às quais o usuário pertence assim como membros de outros times. Os
times no Jazz são esperados serem pequenos, informais, ad hoc e baseados em
convite: qualquer um pode criar um time a acrescentar qualquer um ao seu time.
Para estimular a colaboração foram criados os chats ancorados [Hupfer, Cheng,
Ross, et al, 2004]. Nesses chats um desenvolvedor tem a opção de destacar uma
região de código no editor, clicar e iniciar um chat sobre ela. Assim que a
discussão termina, uma transcrição é salva e aparece como um marcador na
margem esquerda do código. Os membros do time podem posteriormente rever o
chat, clicando no marcador.
Em (Storey, Cubranic & German, 2005) é descrito um levantamento na
literatura sobre ambientes de visualização de código para embasar a proposta de
se utilizar visualização de códigos e informações relacionadas como perfil do
desenvolvedor no desenvolvimento de programas como forma de fornecer
mecanismos de percepção para desenvolvimento de software. Os autores definem
um framework, contendo os critérios utilizados para avaliar as ferramentas. Eles
concluem, no entanto, que segundo aqueles critérios todas as ferramentas
analisadas ainda precisam de muitas melhorias para que atendam a seus
propósitos. As ferramentas de visualização de código têm um grande apelo, porém
ainda não possuem as funcionalidades necessárias para apoiar a aprendizagem de
programação, pois tal processo envolve a necessidade de coordenação do curso,
juntamente com recursos comuns a LMS em geral, acoplados a um ambiente de
desenvolvimento de software.
47
As ferramentas descritas nesta sessão propiciam a colaboração espontânea,
considerando que os participantes possuem a necessidade de colaborar em busca
de uma troca de idéias e não apenas em busca de soluções prontas para suas
dificuldades. No contexto da aprendizagem de programação em cursos
introdutórios, além desses mecanismos de visualização e compartilhamento de
códigos são necessários aportes teóricos e tecnológicos que promovam a
aprendizagem.
3.2. Aportes Metodológicos e Tecnológicos como Apoio a Disciplinas de Programação Introdutória
O projeto Studio-1.00 focou no desenvolvimento de um novo currículo e a
reconfiguração de facilidades para suporte ao ensino da disciplina introdutória de
programação do MIT como um curso baseado em estúdio. O projeto tinha o
objetivo de melhorar as técnicas de aprendizagem ativa, programação interativa e
a exploração e a descoberta de métodos e conceitos de desenvolvimento de
software. Tudo isso facilitado com o uso de dispositivos móveis em uma sala de
aula eletrônica (Barak, Lipson & Lerman, 2006). Nesse formato, o curso incluía 3
sessões de estúdio por semana, cada uma com 90 minutos e um tutorial para
grupos pequenos (12 alunos), com duração de 60 minutos.
Como resultado da análise (Barak, Lipson & Lerman, 2006), os notebooks
ligados à rede sem fio possibilitaram a integração do formato de estúdio em uma
sala de aula tradicional, somente com carteiras e quadro branco, sem necessidade
de laboratórios especialmente projetados. Os instrutores e alunos conseguiram
aproveitar todas as vantagens do uso de computadores como ferramentas
cognitivas em uma sala com configuração padrão. A tecnologia funciona melhor
quando é mesclada com outros elementos do processo de aprendizagem e atende a
uma necessidade educacional específica que não tinha sido contemplada de outra
maneira.
No contexto de um curso introdutório de Engenharia de Software [Chen,
Liu, Sun & Wang 2010] notou-se a necessidade de se desenvolver habilidades
colaborativas nos alunos para que fossem mais bem preparados para o mercado de
trabalho. Foi definido um modelo de aprendizagem que é uma combinação de
aprendizagem baseada em problemas e aprendizagem baseada em tarefas, o
48
PTBL. Esse modelo é combinado com tecnologias Web3D para ampliar as
habilidades de trabalho em equipes de desenvolvimento.
A abordagem de aprendizagem baseada em problemas é utilizada para
ensinar e treinar habilidades de desenvolvimento de programas. Os alunos, após
receberem os problemas especialmente para treinar uma habilidade são levados a
se comunicar com os outros integrantes de seus times. A abordagem baseada em
tarefas é utilizada para proporcionar ao aluno uma circunstância real que pode
motivá-los a estudar. As tecnologias Web3D, envolvendo jogos multiusuários, são
unidas à abordagem baseada em tarefas e a tarefa é definida como um jogo, que os
times de alunos deverão entregar para completar a tarefa.
Assim que os alunos iniciam no curso, devem primeiro se organizar em
grupos e escolher um dos jogos descritos por professores e assistentes. Os
próprios alunos em seus grupos são responsáveis pela divisão de tarefas, de
acordo com as tarefas envolvidas em cada jogo. Eles devem se comunicar e
colaborarem entre si, o que vai influenciar diretamente as notas que irão receber.
Os modelos apresentados não analisam como ocorre a colaboração entre os
membros das equipes, concentrando-se somente nos resultados. No entanto, a
análise dos cursos evidencia uma demanda por tecnologia que auxilie a
intervenção do professor durante o processo, servindo de subsídio para uma nova
proposta de organização do curso introdutório que promova a colaboração em
programação.
3.3. Proposta de Adaptações de um ambiente CSCL para o Contexto da Aprendizagem de Programação
No contexto de um projeto de pesquisa da UFAM, foi desenvolvido o
ColabWeb, um ambiente CSCL configurado e desenvolvido utilizando a
plataforma Moodle. Este ambiente é utilizado como apoio às disciplinas
presenciais ministradas por professores do Departamento de Ciência da
Computação. O projeto de interface para o ColabWeb privilegiou sua
funcionalidade, o que fez com que os primeiros cursos ocorressem com um
aproveitamento desequilibrado de seus recursos. Em vista dessa diferença em
termos de sucesso no uso daquele groupware, evidenciada neste trabalho através
49
do gerenciamento de cursos de computação introdutória, decidiu-se fazer uma
inspeção que evidenciasse o poder de comunicação do artefato de software
(ColabWeb). Para isso, é utilizado o Método de Inspeção Semiótica (MIS) (De
Souza et al., 2008).
Outros métodos de avaliação aplicados a ambientes CSCL já foram
utilizados em contextos de curso, como os descritos em (Pimentel, Fuks &
Lucena, 2004) que avalia a participação dos alunos em fóruns, (Fuks et al., 2003)
que avalia a participação dos alunos de um curso em todas as atividades do
groupware utilizado e (Pimentel, Fuks & Lucena, 2003b) que avalia a participação
em debates. No entanto, nenhum desses trabalhos considera que a interface
influencia na avaliação da participação dos alunos nas atividades propostas em um
ambiente CSCL. Tal aspecto só é considerado em métodos de inspeção baseados
na semiótica como é o caso do MIS.
Conforme a expectativa do MIS, foram elencadas recomendações de
melhorias para a comunicabilidade do ColabWeb. Este trabalho propõe e inaugura
uma linha de avaliação de ambientes de aprendizagem com ênfase na
comunicabilidade. Avalia-se uma instância (ColabWeb) de uma arquitetura
amplamente utilizada (Moodle), observando-se unidades, que neste caso são
cursos. A partir dessas unidades generalizam-se as observações para a instância.
3.3.1. A Engenharia Semiótica
A Engenharia Semiótica propõe uma abordagem para IHC (Interação
Humano-Computador) centrada na comunicação, onde o designer dos sistemas
computacionais são atores ativos na comunicação com o usuário. Segundo De
Souza (2005), enquanto teoria de IHC, as metas da engenharia semiótica são:
apresentar uma caracterização de IHC (extensa e distinta); prover uma ontologia
consistente da qual podem ser derivados frameworks e modelos, sobre aspectos
particulares de IHC; e detalhar restrições epistemológicas e metodológicas, bem
como condições aplicáveis ao espectro da pesquisa na qual a teoria possa servir de
apoio.
Ao se construir um ambiente computacional, segundo a engenharia
semiótica, é necessário refletir sobre a metacomunicação da interface com o
usuário. Para isso, é adotado o modelo de funções comunicativas de Jakobson
50
(Jakobson, 1960) apud (De Souza, 2005), o qual propõe funções comunicativas.
Estas funções são utilizadas para a construção de artefatos de metacomunicação
em IHC. O foco de cada função está em um dos seguintes elementos: o autor, o
receptor, o contexto, o canal, o código e a mensagem. Isto é explorado
indiretamente ao longo do trabalho de inspeção semiótica, uma vez que o próprio
método analisa aspectos relacionados a essas funções comunicativas.
Pode ser que o pesquisador de IHC não queira ou não possa construir um
ambiente computacional. Isto ocorre porque seu público alvo (usuários) já utiliza
um ambiente ou porque sua instituição adota uma determinada plataforma
computacional. Neste caso, é necessário avaliar os elementos de IHC por meio das
funções comunicativas que já estão presentes no ambiente, a fim de propor
modificações para melhorar a metacomunicação com o usuário ou, se o ambiente
atender às funções comunicativas conforme desejado, relatar e registrar esses
elementos.
A fim de avaliar o efeito da comunicabilidade dos sistemas computacionais,
a engenharia semiótica propõe dois métodos, o Método de Inspeção Semiótica
(MIS) (De Souza et al., 2006) e o Método de Avaliação da Comunicabilidade
(MAC) (Prates, De Souza & Barbosa, 2000). O MIS é utilizado para inspecionar
um artefato computacional, considerando o designer como ator ativo através de
sua metacomunicação com o usuário, sem a necessidade de fazer testes com
usuários. Já o MAC propõe uma abordagem mais centrada na utilização do
artefato pelo usuário, envolvendo testes com usuários considerando um aspecto de
interface. Vale salientar que neste trabalho somente é utilizado o MIS, dada a
necessidade de se efetuar uma inspeção geral no artefato, antes de se concentrar
em aspectos específicos de sua interface e pelo fato de a análise ter sido realizada
após a utilização do ambiente CSCL como apoio a uma disciplina ministrada no
semestre anterior.
3.3.1.1. O Método de Inspeção Semiótica
Conforme definido em (De Souza et al., 2008), o propósito do Método de
Inspeção Semiótica (MIS) é avaliar a comunicabilidade de artefatos
computacionais interativos. O MIS é, portanto um método que avalia a
comunicabilidade, concentrando-se nos significados da interface com o usuário
51
expressos pelo designer. O método auxilia os inspetores a anteciparem os tipos de
consequência que as escolhas de projeto (design) podem trazer quando usuários
reais interagem com o sistema.
O MIS é aplicado em 5 etapas: (i) análise dos signos metalinguísticos, (ii)
análise dos signos estáticos, (iii) análise dos signos dinâmicos, (iv) uma
comparação entre a mensagem de metacomunicação do designer gerada nos
passos anteriores, e (v) uma avaliação final da comunicabilidade do sistema
inspecionado.
Antes de se iniciar o MIS propriamente dito, é necessária uma fase de
preparação, que envolve um levantamento sobre a documentação existente e uma
organização prévia do espaço a ser analisado, por exemplo, a criação de grupos ou
inscrição em grupos existentes. Nesse trabalho será analisada a metamensagem do
designer do ColabWeb, ambiente CSCL inspecionado, considerando a
metamensagem do designer do Moodle, pois é a plataforma onde o ColabWeb foi
implementado. Em (i) analisa-se os signos metalinguísticos existentes na
documentação, help do sistema ou meta-mensagem na tela. Os signos estáticos
analisados em (ii) são aqueles cujo significado é interpretado independentemente
das relações temporais e causais, sendo o contexto da interpretação limitado aos
elementos presentes na interface em um dado momento. Em (iii) são consideradas
as transições na interface, como consequências das ações realizadas sobre uma
tela. As três primeiras etapas se combinam para transmitir a mensagem de
metacomunicação do designer (iv), que pode ser parafraseada ao seguinte
esquema:
“Aqui está o meu entendimento de quem você é, o que eu aprendi que
você quer ou precisa fazer, em qual jeito você prefere fazer e porquê. Este é o
sistema que eu projetei pra você e este é o jeito que você pode ou deve usá-lo para
satisfazer seus propósitos que casam com esta visão”.
Na última etapa do MIS (v) avalia-se a comunicabilidade do sistema,
reconstruindo uma mensagem de metacomunicação unificada e julgando os custos
e benefícios das estratégias comunicativas identificadas nas etapas anteriores.
O MIS pode ser aplicado a qualquer artefato de software de onde se queira
inspecionar o poder de comunicação do designer com o usuário. Para groupware,
há preocupações próprias, portanto é necessário se observar outras interações,
além das de usuário com designer (De Souza, 2004). Pelo menos um trabalho
52
exemplifica o MIS para groupware, publicado em (Guimarães & De Souza, 2008).
A diferença dessas inspeções anteriores para a realizada neste trabalho é quanto à
unidade, conforme mencionado anteriormente. Em vez de se avaliar o ColabWeb
de forma geral, o cenário de inspeção escolhida conduz à avaliação da
metacomunicação em cursos, posteriormente generalizada para o software.
Na próxima será feita uma descrição sobre a utilização do ColabWeb
(Santos, Castro & Castro, 2007) como ferramenta de apoio à aprendizagem de
programação introdutória. O ColabWeb é um groupware baseado na arquitetura
Moodle, desenvolvido incrementalmente e utilizado para gerenciar artefatos
digitais produzidos pelos alunos nas disciplinas de graduação e pós-graduação de
computação na Universidade Federal do Amazonas (UFAM).
3.3.2. O Contexto da Aprendizagem de Programação utilizando o ColabWeb
No primeiro semestre de cada ano acadêmico, são oferecidas quatro turmas
da disciplina Introdução à Computação na UFAM para alunos cursando,
preferencialmente, o primeiro semestre de seus cursos. Dessas quatro turmas, duas
são dirigidas aos alunos de Ciência da Computação e duas para os alunos de
Engenharia da Computação. Ao todo são aproximadamente 110 alunos por
semestre.
Em 2005 começou-se a utilizar ferramentas de apoio para o ensino de
Introdução à Computação, devido à grande quantidade de alunos. Como resultado
de estudos de caso da utilização dessas ferramentas (Almeida, Castro & Castro,
2006), as turmas de 2008 utilizaram o ColabWeb, devido às suas funcionalidades
de gerenciamento de grupo e conteúdo. Esta última funcionalidade foi necessária,
pois segundo a evolução da metodologia adotada no curso, os alunos passaram a
ser divididos em grupos para resolverem exercícios de programação.
Consequentemente, os alunos se engajaram em outras atividades, como por
exemplo, discussões em grupo, escrita cooperativa de relatórios e reflexões sobre
os códigos. Para tanto, foram criados 3 cursos no ColabWeb que serão descritos a
seguir.
O curso IC-Apoio serve como site de apoio para a disciplina, contendo
informações comuns a todas as turmas, ementa e discussões mais gerais dos
53
alunos, servindo também de socialização entre os alunos dos diferentes cursos. Os
outros dois cursos são cursos propriamente ditos: IC-CComputação, com as duas
turmas de Ciência da Computação, e IC-EngComputação, com as duas turmas de
Engenharia da Computação. Apesar da expectativa de que ambos os cursos
fossem uniformemente frequentados, a utilização não foi homogênea, o que será
discutido nas próximas sessões.
3.3.3. Inspeção Semiótica do ColabWeb
Dado que o ambiente ColabWeb é uma instância do ambiente Moodle,1 foi a
partir deste ambiente que foi realizada uma inspeção inicial para se descobrir
quem eram seus possíveis usuários na visão do designer, representante da equipe
de desenvolvimento do Moodle, e se há documentação suficiente para todos os
tipos de usuário que este designer pretende atender. Constatou-se que a
documentação, apesar de pouca, era consistente com os propósitos da ferramenta.
O Moodle, então, pode ser visto como uma ferramenta para desenvolvedores e
que, devidamente estendida, conforma-se com as necessidades específicas de cada
instituição que a utiliza.
Como o projeto do Moodle tem como meta fornecer um sistema
totalmente configurável para o professor gerenciar seus cursos, há muitos
elementos na configuração de cada curso, o que por sua vez requer uma análise
minuciosa para avaliar sua adequação a cada tipo de curso. O ColabWeb manteve
esses elementos totalmente configuráveis assim como o projeto de interface
original. Isso deixa o cenário de inspeção muito amplo e difícil de analisar,
necessitando para isso delimitar um escopo.
A fim de se delimitar o escopo da inspeção, o curso utilizado foi a
complementação virtual da disciplina Introdução à Computação, ministrado para
alunos do primeiro semestre de Ciência e Engenharia da Computação. Para este
trabalho foram analisadas quatro turmas do curso, três que já ocorreram durante o
semestre acadêmico de 2008.1 e outro desenvolvido como exemplo. Na última
etapa do MIS, isto é, na avaliação final, são propostas adaptações, considerando as
limitações da arquitetura utilizada. Os cursos analisados (conforme definição do
1 http://moodle.org
54
ColabWeb), e utilizados por alunos, professores e monitores, foram: “IC-
CComputação”, “IC-EngComputação” e “IC-Apoio”. O curso “EngSemiotica” foi
criado com configurações padrão, para que fosse possível observar quais aspectos
de qualquer instância do Moodle podem ser modificados.
O cenário de inspeção elaborado foi o seguinte: “Joana é uma aluna recém
chegada ao curso de Ciência da Computação e está matriculada na disciplina
Introdução à Computação. Nesta disciplina ela vai aprender a programar
utilizando Haskell, uma linguagem funcional. As atividades propostas, bem como
avisos e notas serão acompanhadas no ambiente computacional ColabWeb. O
problema é que ela nunca usou um ambiente gerenciador de cursos e, devido à
necessidade de estudar programação, não tem muito tempo de percorrer o
ambiente para se acostumar com o esquema de navegação e organização em seu
curso. Por outro lado, seu professor criou o curso IC-Apoio no mesmo ambiente,
que serve de apoio às atividades propostas no curso IC-CComputação, com
informações gerais sobre a disciplina. Ela espera não ficar confusa em ter que
utilizar esses dois cursos dentro de um ambiente que não conhece, pois precisa
fazer os trabalhos.”
3.3.3.1. Etapas do MIS
As cinco etapas do MIS apresentadas anteriormente na Seção 3.3.1.1 são
instanciadas abaixo para o ColabWeb, o ambiente CSCL que utilizamos na
pesquisa desta tese.
Etapa 1 – análise dos signos metalingüísticos
Nesta etapa é realizada uma inspeção na documentação disponível (on-line
e off-line) sobre a ferramenta em questão, buscando a meta-mensagem do
designer para o usuário. No caso do ColabWeb, não há documentação disponível
sobre a ferramenta, somente um artigo científico (Santos, Castro & Castro, 2007)
que discorre sobre a funcionalidade de gerenciamento de grupos, uma extensão ao
Moodle original, descrita como “... a percepção dos indivíduos enquanto parte de
um ou vários grupos, além da possibilidade de re-organização em subgrupos”.
Dado que o ColabWeb herda muitas das restrições e funcionalidades do
Moodle, é importante citar a mensagem do designer que aparece na abertura do
55
site do Moodle (traduzido para português): “O Moodle é um Sistema Gerenciador
de Cursos (SGC), também conhecido como um Sistema Gerenciador da
Aprendizagem (SGA) ou Ambiente Virtual de Aprendizagem (AVA). É uma
aplicação web gratuita que educadores podem utilizar para criarem sites de
aprendizagem efetivos”. Há alguns manuais disponíveis no site, mas conforme
consta na descrição transcrita anteriormente o Moodle foi projetado para ser
estendido por programadores ou utilizado por instrutores de cursos na web, que
ora assumem o papel de administradores de cursos ora de tutores ou professores.
Portanto, não há documentação para um dos usuários finais, o aluno. O designer
do Moodle entende que isto, a documentação, cabe ao administrador ou professor.
Apesar de o projeto do Moodle não possuir documentação para alunos, no
site há alguns exemplos de documentação, entre elas “Moodle: An introductory
user guide for students” . Neste documento, o designer se refere ao Moodle como
uma ferramenta bastante intuitiva e convida o usuário a experimentar o sistema
“tente e veja o que acontece” (trad. do autor). Este e os outros exemplos de
documentação para o usuário final foram desenvolvidas juntamente com uma
instância do Moodle e a presença de uma página de exemplos indica que é isso
que o designer do Moodle espera que seus usuários (designers de sites) façam.
Quanto ao ColabWeb, ao se entrar em qualquer curso não há sequer uma
“dica” de como proceder, ou do que os ícones significam. Foi observada também
a ausência de um help para o usuário. Com relação ao curso IC-CComputação há
descrições gerais sobre as atividades a serem desenvolvidas feitas pelo professor
(designer de curso), como o que consta no wiki para o exercício 4, conforme
ilustrado na Figura 3.1. Os signos metalinguísticos presentes na interface do
ColabWeb podem ser muitos ou poucos, dependendo do designer do curso. Nos
cursos analisados esses signos quase não existem, com exceção das meta-
mensagens conforme exemplificado na Figura 3.1, “Aqui deve ser feito o relatório
do exercício 4”.
que s
um e
finai
o pro
essa
a me
usuár
comp
eu ap
de u
intera
do pr
escre
sistem
utiliz
esta
estaç
outro
prete
O MIS sug
se conclui c
esquema de
s para o Co
ofessor, um
inspeção co
eta-mensage
rio final (alu
[Aqui está
putação, qu
prendi que v
um sistema
agir com ou
rofessor. Vo
ever textos
ma que eu
zá-lo de form
visão]. Vo
ção de perce
os cursos e
endida.
Figu
gere que se
cada etapa
e metacomu
olabWeb, um
ma vez que
onsideramo
em inicial
uno). O tex
á o meu en
ue já está ac
você quer o
para geren
utros alunos
ocê precisa
em ferrame
projetei pra
ma que pre
cê pode us
epção para
ainda subdi
ura 3.1 – Pá
vá construi
do método
unicação, d
m é o aluno,
o ColabWe
s somente o
de comuni
xto entre col
ntendimento
costumado a
ou precisa f
nciar a disci
s, resolvend
ser capaz d
entas auxili
a você e ess
encha uma
sar o calend
estar a par
ividir seus g
ágina de Ex
indo a meta
. Esta meta
descrito na s
, segundo o
eb herda pa
o aluno com
cação do d
lchetes é o e
o sobre que
a utilizar am
fazer, de qu
iplina que
do exercício
de visualiza
iares como
sa é a mane
variedade d
dário para v
automaticam
grupos em
xemplo no
amensagem
amensagem
seção anter
o projeto do
arte do proj
mo usuário f
designer do
esquema de
m você é].
mbientes de
ue forma e p
você está m
os e acompa
ar as ativida
wikis, fóru
eira pela qu
de propósito
verificar os
mente da m
subgrupos,
wiki
do designe
deve ser b
rior. Há doi
ColabWeb
jeto do Mo
final. Em se
o ColabWeb
metacomun
Você é um
e redes soci
porquê]. Vo
matriculado
anhando as
ades de seus
uns e chats.
ual você pod
os que coad
s eventos d
movimentaçã
conforme a
56
er à medida
baseada em
is usuários
. O outro é
oodle. Para
eguida está
b para seu
nicação.
m aluno de
iais.[O que
ocê precisa
o, podendo
instruções
s colegas e
. [Este é o
de ou deve
dunam com
do curso, a
ão em seus
a atividade
“logi
nesse
super
Figu
Conf
inicia
desig
cham
não s
recur
as ati
Meu
selec
muito
nome
Etapa 2 –
A Figura
in” é substi
es ambiente
rior, entr
ura 3.2 – Pá
forme ilust
almente os
gner do cur
mar atenção
se consegue
rso chamad
ividades no
s Cursos e M
cione outra p
Da mesma
o pequeno.
e do ambien
análise dos
3.2 aprese
tuída pela p
es. Além di
re parên
ágina de ab
trado na
s grupos ex
rso, neste c
do usuário
e eliminar o
o estação d
os cursos qu
Monitorar T
palavra, as
a forma qu
O seu pos
nte, mas est
s signos está
enta a tela
palavra “ace
isso, não é
nteses e
bertura do C
Figura 3.3
xistentes, à
caso o prof
o quanto ao
os outros gr
e percepção
e o usuário
Tudo são út
caixas abaix
e o link pa
sicionament
tá entre parê
áticos
de abertur
esso”, o qu
bem comu
utilizand
ColabWeb
3, no curs
à esquerda,
fessor, desta
o seu grupo
rupos da vi
o (Spósito,
pertence. A
teis para o s
xo da Estaç
ara entrar no
to é bom, p
ênteses e uti
ra do Cola
e não é um
unicada, poi
do fonte
so IC-CCo
, e no cen
aca a palav
. Isto é um
isão do usuá
Castro & C
As palavras
seu entendim
ção de Perce
o ambiente
pois aparec
ilizando fon
abWeb. A
m jargão mui
s se localiz
muito
mputação,
ntro, em “G
vra “import
m bom recur
ário. À dire
Castro, 2008
padrão que
mento. Caso
epção são al
, o link par
e centraliza
nte pequena
57
mensagem
ito comum
za na parte
pequena.
aparecem
Grupos” o
tante” para
rso quando
eita, há um
8) monitora
aparecem,
o o usuário
lteradas.
ra sair está
ado com o
a.
útil,
calen
confu
(desi
Neste
modo
ativid
tópic
Fi
A Figura 3
marcando
ndário apar
fundem o u
igner do cur
A Figura 3
e caso, o p
o, ao clica
dades do m
co do curso
igura 3.3 –
3.4 mostra o
as datas
recem “even
usuário, seg
rso) e podem
F
3.5 mostra
professor de
ar em uma
mesmo tipo
abordado n
Predominâ
o recurso “C
ocupadas c
nts key”, q
gundo decl
m numa últi
Figura 3.4
a estruturaç
ecidiu organ
a atividade
e perde o
naquela ativi
ância da Li
Calendário”
com algum
que por est
larações fe
ima instânc
– Recurso
ção de tópic
nizar o cur
e, o usuári
o contexto d
idade.
inguagem T
”, presente n
m tipo de
tarem escrit
eitas ao pro
ia tornar o r
Calendário
cos no curso
rso por tipo
io visualiza
do curso, c
Textual
nesse curso.
atividade,
tos em outr
ofessor da
recurso inút
o
o IC-EngCo
os de ativid
a também
como por e
58
. Apesar de
abaixo do
tro idioma,
disciplina
til.
omputação.
dade. Deste
as outras
exemplo, o
2a. e
esque
texto
comp
comp
porqu
você
e aco
preci
acom
ativid
colab
proje
form
Você
perce
curso
prete
Em seguid
etapa, basea
ema de met
o em destaqu
[Aqui está
putação, qu
putacionais
uê]. Você S
está matric
ompanhand
isa interagi
mpanhando
dades de s
borar com
etei pra voc
ma que preen
ê pode usar
epção para
os e ainda
endida.
Etapa 3 –
Fig
da está o ref
ada somente
tacomunica
ue, o que fo
á o meu en
ue já está
. [O que eu
Seu professo
culado pode
do as instru
ir com os o
as instruçõe
seus colega
eles utiliza
cê e essa é
ncha uma v
r o calendá
estar a pa
subdividir
análise dos
gura 3.5 – P
finamento d
e nos signos
ção do desi
oi acrescenta
ntendimento
acostumad
aprendi qu
or precisa d
endo interag
uções do p
outros alun
es do profes
as escrever
ando wikis,
a maneira
variedade de
ário para v
ar automatic
r seus grup
s signos din
Perda de C
da metamen
s estáticos,
igner, o text
ado.
o sobre que
do a utiliz
e você quer
de um sistem
gir com outr
professor e
nos de seu
ssor. Você p
textos em
fóruns e c
pela qual
e propósitos
verificar os
camente da
pos em su
nâmicos
Contexto
nsagem do d
onde o tex
to riscado é
m você é].
zar ambien
r ou precisa
ma para gere
ros alunos,
se comuni
grupo, res
precisa ser
ferramenta
chats. [Este
você pode
s que coadu
eventos do
a moviment
ubgrupos, c
designer ao
xto entre col
o que foi r
Você é um
tes de red
fazer, de qu
enciar a disc
resolvendo
icar com v
solvendo ex
capaz de vi
as auxiliare
e é o sistem
ou deve ut
unam com e
o curso, a e
tação em s
conforme a
59
final desta
lchetes é o
retirado e o
m aluno de
des sociais
que forma e
ciplina que
exercícios
você. Você
xercícios e
isualizar as
es como e
ma que eu
tilizá-lo de
esta visão].
estação de
seus outros
a atividade
selec
págin
quem
probl
dos l
enxe
grupo
atual
visua
links
A partir d
cionar qualq
na como a m
m participa
lema quanto
links hierár
rgar. Caso
os, o que é
l selecionan
F
Ainda na
alização. Ca
s que lá apar
da lista de gr
quer grupo
mostrada na
em qualque
o à navegaç
rquicos na p
selecione
é totalmente
ndo um grup
Figura 3.6 –
Figura 3.
aso o usuár
recem. Isto
rupos mostr
em que o
a Figura 3.6
er grupo, in
ção. O usuá
parte superi
grupos, o u
e inútil e co
po na página
– Visualiza
7, a caixa
rio consiga
mitiga o pr
rada na pág
usuário est
6. Um prime
nclusive seu
ário fica per
ior da tela,
usuário rec
onfuso visto
a principal d
ação de Info
a de diálog
a enxergá-la
roblema da f
gina princip
eja inscrito
eiro problem
us logs de a
rdido, pois
algo que n
ceberá uma
o que o usu
do site do c
ormações s
go “Seguir
a, ele pode
falta de refe
al do curso
. Esta ação
ma é que o
cesso. Mais
precisa sele
nem sempre
lista com
uário chegou
urso (Figur
obre Grup
para...” é
rá selecion
erencial.
60
o é possível
o gera uma
usuário vê
s grave é o
ecionar um
e consegue
links para
ou à página
ra 3.7).
po
de difícil
nar um dos
final
o tex
etapa
comp
eu ap
preci
comu
resol
você
dentr
que
coleg
tamb
tipo.
pode
coad
do cu
opçõ
movi
movi
curso
prete
A seguir
desta 3a. e
xto retirado
a.
[Aqui está
putação, qu
prendi que v
isa de um s
unicar com
lvendo exer
pode visua
ro do curso
você quiser
gas e colab
bém pode a
[Este é o s
e ou deve u
dunam com
urso, clicar
ões de visu
imentação
imentação p
os e ainda
endida.
apresentam
etapa. O que
o e o que e
Figu
á o meu en
ue já está ac
você quer o
sistema para
você. Você
rcícios e ac
alizar qualqu
e depois ca
r ir. Você
borar com e
acessar os r
sistema que
utilizá-lo de
esta visão].
sobre um e
ualização n
deseja es
para estar a
subdividir
mos o refina
e está entre
está destaca
ura 3.7 – Na
ntendimento
costumado a
ou precisa fa
a gerenciar
ê precisa in
companhand
uer atividad
aminhar pel
precisa ser
eles utilizan
recursos iso
e eu projetei
forma que
. Você pode
vento e ver
na estação
star ciente
par automa
r seus grup
amento da
colchetes é
ado é o que
avegação n
o sobre que
a utilizar am
fazer, de qu
a disciplina
nteragir com
do as instru
de de seus c
los links sup
r capaz de
ndo wikis,
oladamente
i pra você e
preencha u
e usar o cal
r sua descriç
de percepç
ou que
aticamente d
pos em su
metamensa
é o esquema
e foi acresc
os Grupos
m você é].
mbientes co
e forma e p
a que você
m os outros
uções do pr
colegas, atra
periores par
visualizar a
fóruns e c
, visualizan
e essa é a m
uma varieda
lendário par
ção. Pode ta
ção, custom
cursos de
da movimen
ubgrupos, c
agem do d
a, o que está
centado ao
Você é um
omputaciona
porque]. Seu
está matric
alunos de
rofessor. A
avés do link
ra a parte do
as atividade
chats. Para
ndo todos o
maneira pela
ade de prop
ra verificar
ambém mod
mizando qu
eseja acom
ntação em s
conforme a
61
designer ao
á riscado é
final desta
m aluno de
ais. [O que
u professor
culado e se
seu grupo,
Além disso,
k de grupos
o ambiente
es de seus
isso, você
os daquele
a qual você
pósitos que
os eventos
dificar suas
ue tipo de
mpanhar a
seus outros
a atividade
62
Etapa 4 – conclusão do MIS
A impressão geral sobre a análise dos signos metalinguísticos, estáticos e
dinâmicos é focada na navegação por um usuário final de um curso no ColabWeb.
No cenário utilizado, os problemas navegacionais concentram-se nas
visualizações das atividades. A especificidade da visualização dos grupos é um
exemplo do que ocorre também com outros recursos. Aparentemente, o designer
do ColabWeb crê que ao usuário clicar em um determinado fórum, ele estaria
interessado em acessar todos os itens daquela categoria, não se dando ao trabalho
de consultar antes o usuário, se ele gostaria de ver outros fóruns ou voltar para
onde estava.
No caso específico de IC-CComputação o curso foi configurado
considerando a ordem cronológica dos exercícios, de acordo com os conceitos
trabalhados no curso, o que facilitou a organização das atividades e manteve um
padrão navegacional constante e coerente.
Os problemas navegacionais encontrados se referem a qualquer curso criado
no ColabWeb, constatado através da criação do curso IC-EngSemiotica. Quanto a
problemas específicos nas configurações de cursos, como o que ocorre com o
curso IC-EngComputação (Figura 3.5). Isto se deve ao fato do ColabWeb herdar
do Moodle o amplo esquema de configurações para o professor, o que acarreta em
situações muito complicadas.
Para concluir a inspeção, nota-se que a metacomunicação no ColabWeb é
eficiente quando o designer de curso é um especialista no uso dessa ferramenta.
Porém não é eficiente para os usuários finais (alunos), visto que os cursos podem
ser organizados de maneiras diversas. Além disso, o usuário se perde com o
esquema navegacional, interrompendo sua atividade para retomá-la do ponto onde
havia parado. Os usuários do ColabWeb (alunos de computação) normalmente
têm a característica de explorar o ambiente para entender seu funcionamento. Para
este tipo de usuário o software, apesar de apresentar problemas navegacionais,
adéqua-se ao propósito. Quanto às permissões de acesso a alguns logs, não é nem
um pouco efetiva, pois confunde os usuários, além de violar os direitos dos
grupos.
63
Etapa 5 – avaliação qualitativa dos resultados do MIS
A triangulação dos resultados na inspeção do ColabWeb é baseada na
análise de um chat de propósito geral em IC-Apoio, em wikis de IC-
CComputação, no chat do curso IC-Apoio e fóruns em IC-EngComputação.
Apesar de se crer que a entrevista sobre os elementos centrais da inspeção é
importante, ainda não foi possível entrevistar os alunos que participaram dos
cursos em 2008.1, pois os mesmos não responderam aos emails enviados. Foram
acrescentadas, então, entrevistas com os professores, sobre comentários
específicos de alguns alunos ou algum item que foi detectado no MIS.
Nos registros do ColabWeb, há uma predominância sobre dificuldades
relacionadas à conectividade ou demora associada ao carregamento de páginas do
ColabWeb. O comentário a seguir, retirado de um fórum do curso IC-
EngComputação, exemplifica este problema:
“Com 300kbs ,a tarde, ta mt complicado de usar o ColabWeb.”
A aluna se refere à velocidade de sua conexão em casa. A equipe de suporte
do ColabWeb informou que o problema ocorre no acesso externo à rede
metropolitana de pesquisa, uma vez que ficou sujeito a uma grande quantidade
desses acessos. O suporte informou também que isto já foi resolvido com a
compra de um servidor mais robusto e um pequeno aumento na largura de banda
da RNP-AM, onde a UFAM está conectada.
Outro comentário diz respeito ao editor do ColabWeb. De modo geral os
editores do ColabWeb não parecem ter um comportamento esperado. Algumas
vezes não é possível customizar o texto, conforme reclamação de uma aluna:
“Quando se modifica as cores de um texto, ao invés de mudar somente a
parte selecionada, outro pedaço do texto não selecionado aparece de cor
diferente”.
A aluna faz uma sugestão:
“Minha opiniao é que trocassem esse editor de texto online. Colocar um
mais simples e funcional. Não sei se tem alguem está pretendo usar tantas cores,
plano de fundo, smiles(!!), acho pouco provável. Um editor de texto a "la bloco de
notas" estaria ótimo”.
Sobre o problema de navegação, apontado nas outras etapas do MIS, os
professores afirmaram ter recebido muita reclamação por email no início da
disciplina, mas depois os alunos se “acostumaram”. Ainda segundo os
64
professores, os alunos inscritos no curso IC-EngComputação encontraram mais
problemas para utilizar o ColabWeb, tanto de localização dos exercícios quanto ao
uso dos recursos associados aos exercícios.
Entende-se que os alunos de computação sejam mais acostumados a se
adaptarem ao uso de um novo software. Por isso, os problemas navegacionais
foram superados, em geral, no início da disciplina. No entanto, eles ocorreram e
foram registrados pelos professores. Vale também ressaltar que os alunos do curso
IC-EngComputação vivenciaram mais dificuldades em associar recursos a
exercícios, o que pode ser constatado em alguns comentários nos fóruns.
O fato de a qualidade da metacomunicação do ColabWeb depender da
experiência do designer de curso significa que o sistema é configurável. Como o
designer de curso sem experiência, usuário a quem a plataforma Moodle se propõe
a auxiliar, não consegue projetar um curso de forma que consiga acompanhar as
atividades, utilizando um mínimo de recursos simples e úteis, a metacomunicação
do Moodle e, consequentemente, do ColabWeb, é muito pobre.
Os designers do Moodle omitem informações importantes e diretrizes para
que o usuário se sinta à vontade de fazer um bom projeto de curso e realizar as
atividades da maneira desejada. Isto faz com que os designers do Moodle não
consigam atingir seu propósito com a tecnologia, que é, conforme mencionado
anteriormente, o de auxiliar o professor (designer de cursos) a projetar um curso
semi-presencial ou a distância.
3.3.4. Proposta de Melhorias e Adaptações
Ao longo deste artigo chamou-se de problemas navegacionais a forma de
navegação e estruturação de páginas web do ColabWeb, que é uma herança do
Moodle. Nesta sessão, pretende-se discutir sobre os aspectos relacionados a esse
esquema de navegação, procurando alternativas para amenizar seus efeitos.
O Moodle é estruturado em módulos quase independentes, de forma que
seja fácil para outros desenvolvedores construírem outros módulos em forma de
plugins. Por essa característica, o Moodle é considerado um sistema extensível.
Seu esquema navegacional segue a estrutura de diretórios físicos, acompanhando
a sequência de páginas visitadas pelo usuário ao entrar no ambiente. Sendo assim,
ao entrar no ColabWeb, aparecem somente os cursos onde o usuário pode entrar.
65
Quando ele seleciona um curso, o designer do sistema que deixá-lo ciente de
como fazer para retornar à página anterior, fornecendo um link com o titulo da
página ou uma referência ao seu conteúdo. Começa a ficar problemático quando o
usuário começa a selecionar outros links dentro do curso e não consegue retornar
para onde estava utilizando o mesmo raciocínio.
Para exemplificar, suponha que um usuário do ColabWeb acesse o fórum
específico de um exercício. Caso desista de fazer comentários ou simplesmente
quiser retornar para a página anterior, o link imediatamente anterior não irá
produzir o resultado esperado, levando-o à lista de todos os fóruns disponíveis.
Neste caso, o designer espera que o usuário saiba que o lugar onde ele estava era
IC-CComputação, já que era a página principal do curso.
Para alguns usuários a mensagem do designer está clara, mas para muitos
pode confundir, pois a semântica da estrutura de navegação que aparece em forma
de links diz respeito à forma como o sistema armazena os dados e não segundo do
ponto de vista semiótico.
No contexto em que o ColabWeb foi utilizado, aprendizagem de
programação, acredita-se que o sistema não necessite de muitas adaptações para o
contexto, pois as atividades de grupo e entrega de códigos e relatórios podem ser
desenvolvidas sem prejuízo em um ambiente CSCL, como o ColabWeb.
As sugestões de adaptações e/ou extensões que podem ser desenvolvidas
para o ColabWeb, de forma que atenda melhor seus usuários precisam estar de
acordo com o que é possível modificar no sistema sem modificar muito a estrutura
da arquitetura onde ele está, pois modificações mais profundas trazem efeitos
colaterais para o sistema, muitas vezes imprevisíveis. Tendo isso em vista,
propõem-se algumas sugestões quanto ao contexto no qual o sistema foi
inspecionado e outras mais gerais, sobre a estrutura navegacional.
Apesar de serem adequadas ao uso de alunos aprendendo programação,
algumas extensões seriam úteis, como uma ferramenta que fizesse um
rastreamento na evolução dos códigos dos grupos para que todos (professores,
monitores e alunos) pudessem consultar e aprender sobre as estratégias adotadas
para cada situação. No curso de IC-CComputação os alunos utilizaram uma
ferramenta para submissão de códigos, que armazenava todas as versões em um
banco de dados. Visto que já há uma ferramenta desenvolvida para acompanhar a
66
evolução dos códigos a partir de um banco de dados (Castro, Fuks & Castro,
2008b), isso poderia ser uma extensão aos recursos do ColabWeb.
Uma desvantagem levantada nessa inspeção foi a abrangência de tipos de
configuração para o designer do curso. O Moodle apresenta uma lista muito
grande de atividades para configurar. O designer de curso menos experiente,
aquele professor que resolve utilizar o sistema como apoio à sua disciplina, sem
nunca tê-lo utilizado antes, não consegue nem entender o que são todas aquelas
opções. Há opções padrão, mas não há uma explicação sobre elas ou sugestões de
como organizar seu curso. Normalmente os designers de curso mantêm a
configuração padrão porque é aparentemente mais fácil. No entanto, o padrão do
Moodle é um curso com todos os recursos possíveis, cujas atividades são
organizadas em Tarefas. Cremos que esta é uma das maneiras mais complicadas
de se configurar um curso.
O ColabWeb poderia apresentar uma tela anterior à configuração do curso,
na qual o designer perguntasse ao usuário qual seu nível de habilidade no uso do
sistema. A partir daí, as telas seguintes poderiam apresentar mais ou menos
opções de configurações, deixando as outras como padrão. Para aqueles designers
de curso com menos experiência seriam apresentadas somente configurações
sobre conteúdo, datas e eventos. A interface do curso seria montada com os
recursos mais utilizados. Vale ressaltar que isto é possível de ser realizado no
ColabWeb, apenas omitindo da tela as informações fornecidas pelo Moodle e
fazendo um preenchimento automático das requisições de configuração.
A estrutura de navegação do Moodle não permite ser modificada. No
entanto, da mesma forma que as configurações, podem-se omitir os links
indesejados da interface com o usuário, acrescentando outro, referenciando assim
o desejado. Dessa forma, o problema que ocorre com a visualização de grupos
poderia ser amenizado retirando-se o link de grupos, permanecendo somente a
palavra que os descreve.
3.4. Conclusão do Capítulo
Neste capítulo discutimos sobre como as ferramentas utilizadas para apoiar
a colaboração precisam ser sensíveis ao seu contexto de aplicação e devem
possuir algum esquema de codificação das atividades para facilitar as próprias
67
interações e as intervenções no caso de serem voltadas à aprendizagem.
Destacamos que os ambientes CSCL podem ser adaptados e mecanismos
auxiliares podem ser incorporados a eles para que apoiem aprendizagem de
programação em grupo.
Mostramos relatos sobre o funcionamento de ferramentas e metodologias
desenvolvidas para apoiar a aprendizagem de programação em grupo. Os
defensores desta modalidade de ensino de programação afirmam que a atividade
é, no mínimo, mais prazerosa que o método tradicional, focado no indivíduo,
servindo de incentivo para os alunos. As ferramentas apresentadas não são
completas no sentido de acompanhar os processos de raciocínio e discussão nos
grupos. Por isso a proposta de se utilizar ambientes CSCL, que já possuem
mecanismos essenciais à colaboração como base para o desenvolvimento de
outros recursos necessários à aprendizagem de programação.
A Seção 3.3 é baseada em (Castro & Fuks, 2009). Ela faz uma inspeção
semiótica em um ambiente CSCL chamado ColabWeb, que por sua vez, é uma
implementação a partir do Moodle. Essa inspeção foi realizada em 3 cursos que
ocorriam simultaneamente no ambiente, voltados à aprendizagem de
programação. Foram identificadas dificuldades de navegação e sugeridas
modificações para aquele tipo de curso. Uma vez seguidas essas recomendações, o
ColabWeb poderia continuar sendo utilizado para apoiar a aprendizagem de
programação em grupo.
No próximo capítulo discutimos sobre colaboração na aprendizagem de
programação em grupo. Iniciamos com uma revisão na literatura sobre métodos
de colaboração, seguida de uma prospecção sobre as características da
aprendizagem de programação em grupo e a necessidade de incorporar
colaboração às metodologias utilizadas. Terminamos o capítulo com a descrição
de um estudo de caso exploratório para identificar as dificuldades encontradas
pelos alunos de graduação em computação ao programarem em grupo.
4 Colaboração na Aprendizagem de Programação
Neste capítulo discutimos conceitos de colaboração e como os métodos de
colaboração são utilizados para apoiar a aprendizagem de programação em grupo
em ambientes CSCL. Inicia-se com uma discussão sobre a necessidade de
colaboração em aprendizagem de programação e a formação dos grupos. Em
seguida, apresentamos alguns exemplos de métodos conhecidos, adaptados de
(Sharan, 1999) para o contexto de aprendizagem do próprio processo de
colaboração. Na Seção 4.1 discutimos sobre como os scripts de colaboração
auxiliam na aquisição de habilidades para colaboração e na análise das interações.
Considerando que os alunos adquiram as habilidades para colaboração e seguindo
a ênfase na necessidade de análise das interações produzidas, na Seção 4.2
discutimos sobre os métodos de análise de interações utilizando padrões de
interação e atos de fala. Os ambientes CSCL são projetados para fornecerem
ferramentas que proporcionam a aplicação de métodos para apoiar a colaboração e
sua análise, mas algumas outras tecnologias podem enriquecer esses ambientes,
estruturando-os internamente, não afetando a maneira como o usuário se relaciona
com as ferramentas.
Após as duas primeiras seções, que são subsídios para nossa proposta de
intervenção na aprendizagem de programação em grupo, apresentamos, na Seção
4.3, um estudo de caso exploratório desenvolvido para se conhecer as dificuldades
e características apresentadas por alunos iniciantes em programação ao realizarem
um exercício em grupo, sem restrições para a organização dos grupos e utilização
de métodos. Baseados nos resultados dessa exploração, na Seção 4.4,
apresentamos um esquema que, inspirado nos scripts de colaboração, propõe uma
transição das práticas de programação individuais para a prática em grupo.
Uma das práticas aceitas (Parrat & Tryphon, 1998) em contextos de
aprendizagem é a colaboração como forma de se desenvolver os processos
cognitivos, desde que seja respeitada a fase do desenvolvimento em que os alunos
se encontram. Conforme afirmado por Piaget em (Parrat & Tryphon, 1998),
69
geralmente a partir dos 10 ou 11 anos, o respeito às regras nas atividades em
grupos passa a ser uma realidade intrínseca e não algo externo, imposto.
No contexto de aprendizagem de programação abordado nesta tese, os
alunos mais novos já identificados têm 16 anos. Nessa idade, apesar da provável
falta de prática nas escolas, a colaboração já está incorporada à realidade do
pensamento deles e às suas tarefas cotidianas.
O trabalho em grupo é benéfico a esses alunos por ser ativo e investigativo,
proporcionando as trocas de idéias e as negociações para se chegar a uma
concepção do grupo. Para isso, afirma Piaget (Parrat & Tryphon, 1998), que o
trabalho em grupo não pode ser totalmente prescrito de fora, devendo envolver
uma negociação sobre a formação dos grupos, alinhadas aos interesses dos alunos
e professores. O grupo também funciona como um mecanismo regulador do
pensamento individual, servindo ao mesmo tempo de estimulador e órgão de
controle.
A colaboração é incentivada também nos ambientes de trabalho. No
mercado de trabalho da Engenharia de Software, por exemplo, é comum a
organização das equipes de desenvolvimento de software por projetos, onde
somente um líder é indicado, cabendo a ele formar sua equipe e distribuir as
tarefas. Para isso, há técnicas de gestão do conhecimento provenientes de métodos
organizacionais que são muito utilizadas. Os egressos dos cursos de computação
precisam conhecer e estar fluentes em colaboração, envolvendo diferentes
métodos e técnicas. Para isso, é importante que os alunos sejam expostos ao
desenvolvimento de programas em grupo desde o primeiro curso de programação.
Relembrando o que foi abordado no Capítulo 2, a colaboração em
programação em grupo não ocorre naturalmente, devido à falta desta prática na
educação básica, que privilegia a memorização de muito conteúdo, em vez do
desenvolvimento do raciocínio. Dado que programação envolve raciocínio muito
abstrato, os alunos precisam primeiramente entender os processos para se chegar à
solução de um problema, codificado em um programa, para posteriormente
perceberem a necessidade das trocas de idéias para gerarem soluções melhores.
Assim como aprendizagem no contexto da educação básica, a colaboração
entre os integrantes de um grupo aprendendo programação também precisa ser
mediada. Através desta mediação, o professor pode intervir enquanto os alunos
ainda estão elaborando sua solução, através da identificação de possíveis
70
estagnações nas discussões e soluções parciais dos grupos. Ao utilizar um
ambiente CSCL para registrar as conversas dos grupos referentes a cada exercício,
o professor terá oportunidades de intervir durante o processo de aprendizagem.
Para que isso ocorra é necessário que o ambiente CSCL utilizado ofereça
mecanismos para estruturação das conversas espontâneas, de forma que essas
estagnações sejam identificadas e o professor seja avisado em tempo de intervir
durante o processo, podendo para isso utilizar uma linguagem de representação
das interações.
4.1.Scripts para Apoiar o Processo de Colaboração
Os alunos utilizando ambientes CSCL para aprender programação têm
acesso e precisam dos mesmos recursos que alunos aprendendo qualquer outro
assunto, como ferramentas de chat, fórum, relatórios em estilo wiki e esquema de
armazenamento de arquivos. Há relatos (Kobbe, Weinberger, Dillenbourg, Harrer,
Hämäläinen & Häkkinen & Fischer, 2007) que afirmam que a aprendizagem
colaborativa depende da interação efetiva entre os alunos. No entanto, quando
esses alunos são deixados sozinhos para utilizarem as ferramentas do ambiente
para interagirem, sem nenhum direcionamento, eles raramente se envolvem em
interações produtivas como questionar uns aos outros, articular o raciocínio ou
elaborar reflexões. Os scripts para colaboração foram propostos para incentivar a
aprendizagem colaborativa moldando a maneira como os alunos interagem. Para
isso, especificam uma sequência de atividades de aprendizagem e papéis que
deverão ser assumidos pelos alunos durante a interação. Em sua definição clássica
(O’Donnel & Dansereaus, 1992), um script para colaboração é um conjunto de
instruções referentes a como os integrantes do grupo devem interagir, como
devem colaborar e como devem resolver o problema.
Na tentativa de obter um panorama do que já se havia escrito sobre scripts
para colaboração e facilitar sua adoção em ambientes CSCL, em (Kobbe,
Weinberger et al, 2007) é proposto um framework, contendo os mecanismos e
componentes necessários. Um script deve ter a descrição detalhada de atividades,
estabelecer papéis com suas expectativas e funções, recursos virtuais ou físicos,
grupos, mecanismos como distribuição de tarefas, formação de grupos e
seqüenciamento.
71
Em (Villasclaras-Fernández, Isotani, Hayashi & Mizoguchi, 2009) é
proposta uma abordagem utilizando ontologias, unificando os conceitos de micro-
scripts e macro-scripts, classificação atual para diferenciar a ênfase na construção
de argumentos ou sequências de argumentos (micro-scripts) da preocupação com
organização de sessões de interação, incluindo a descrição de grupos, papéis,
atividades ou classificação de sentenças (macro-scripts). Essa abordagem propõe
uma ontologia para a criação de atividades envolvendo os dois níveis.
As desvantagens da utilização de scripts (Dillenbourg, 2002) se traduzem
em preocupações que devem estar presentes em quem vai propor ou utilizar
scripts. Os professores devem observar durante o desenvolvimento das atividades
propostas se os scripts estão perturbando as interações naturais ou os processos
naturais de soluções de problemas, aumentando a carga cognitiva, transformando
as interações em uma sequência didática ou ainda fazendo as interações se
tornarem sem objetivos claros.
4.2. Análise de Interações em Ambientes CSCL
Considerando que a aprendizagem de programação em grupo seja apoiada
por um ambiente CSCL e que este ambiente de alguma forma incentive a
colaboração e a utilização de fóruns e chats através da definição de scripts de
colaboração ou outra metodologia, a análise das interações requer um trabalho
minucioso que ao mesmo tempo seja realizado durante o processo de discussão
para a resolução dos exercícios e, no caso específico de programação, durante o
desenvolvimento dos códigos.
Para utilizar as informações provenientes das análises de interações, em
(Dillenbourg & Fischer, 2007) é sugerido que se possibilite sua visualização aos
membros do grupo. Essas ferramentas são chamadas “group mirrors”, pois
refletem alguma forma de interpretação externa das interações aos usuários.
Ambientes CSCL devem ser desenvolvidos para proporcionarem interações
que produzam bons produtos. Algumas maneiras de estimular essas interações
são: deixar os alunos em uma situação onde eles precisem se envolver em
interações trabalhosas para construírem um entendimento compartilhado;
selecionar uma representação de tarefa que molde a linguagem utilizada pelos
alunos; apontar diretamente tipos específicos de “utterances” utilizando interfaces
72
semi-estruturadas; estruturar colaboração através de scripts; capturar interações,
permitindo sua visualização pelos membros dos grupos ou conduzindo análises
mais profundas (Dillenbourg & Fischer, 2007).
Ainda em (Dillenbourg & Fischer, 2007), é descrito o termo ‘orquestração’
para identificar os desafios de coordenar produtivamente intervenções em níveis
diferentes, enfatizando o papel do professor ao conduzir atividades de CSCL em
escolas ou universidades. A orquestração se refere às dimensões cognitiva,
pedagógica e prática de um ambiente CSCL distribuído. No nível cognitivo, o
professor precisa equilibrar as tarefas em mecanismos de aprendizagem
individualizada, interações em pequenos grupos e atividades com toda a turma.
No nível pedagógico, o professor precisa adaptar em tempo real as atividades
planejadas ao que está ocorrendo naquele momento em sala de aula.
Neste trabalho consideramos a pesquisa em scripts de colaboração como
forma de estruturar o curso de programação introdutória e facilitar a análise das
interações. No entanto, as desvantagens do uso de scripts apontadas na seção
anterior nos levou à reflexão sobre o caráter abstrato da programação já discutido
no Capítulo 2 e em como poderia ser prejudicial a adoção de mecanismos
externos, micro-scripts, para o processo de elaboração do raciocínio em
programação.
Independente da utilização de micro-scripts é necessário se adotar
mecanismos para acompanhar as interações e outros ainda para analisá-las. Este
trabalho tem como objetivo a sistematização da aprendizagem de programação em
grupo, o que envolve acompanhamento e análise das interações. Para elaborar
esses mecanismos é necessário que se explore o contexto de aprendizagem de
programação que se deseja trabalhar, observando como os grupos se organizam
para resolver um exercício de programação em grupo. Por isso, foi desenvolvido
um estudo de caso exploratório, conforme definição em (Yin, 2010).
4.3.Um Estudo de Caso Exploratório sobre Aprendizagem de Programação em Grupo
No primeiro semestre de 2007 foi desenvolvido um estudo de caso em
introdução à programação com duas turmas de alunos matriculados no primeiro
73
semestre dos cursos de graduação em Ciência da Computação e Engenharia da
Computação na Universidade Federal do Amazonas (UFAM).
O objetivo desse estudo de caso foi proporcionar aos alunos a experiência
no desenvolvimento de soluções para problemas complexos através da
distribuição de tarefas, negociação, composição de soluções parciais e
refinamentos sucessivos. Isto foi alcançado trabalhando em grupos de até 5 alunos
os quais eram também responsáveis pelo registro das atividades desenvolvidas ao
longo das etapas do trabalho, utilizando um ambiente baseado no controle de
versões chamado AAEP (Almeida, Castro & Castro, 2006). Ao final do curso,
como trabalho final, foi proposta uma tarefa em grupo. Conforme exigência da
tarefa, a solução deveria ser acompanhada de um registro das interações entre os
membros das equipes. Após a entrega e correção dessas tarefas, houve uma fase
de análise e interpretação dos dados gerados baseados nos processos de
classificação, codificação e tabulação.
Além do desenvolvimento de códigos e manutenção do registro das
interações, os alunos também responderam a questionário, o qual foi submetido a
uma análise quantitativa. Finalmente, eles puderam expressar livremente sobre
suas dificuldades e sobre o desenvolvimento dos trabalhos, sendo esses
comentários submetidos a uma análise qualitativa.
4.3.1. Análise Quantitativa
O objetivo do questionário era revelar o nível de aderência à colaboração na
aprendizagem de programação como uma forma de mudar de práticas individuais
para aprendizagem de programação em grupo através da interação entre os
membros dos grupos. Os dados foram analisados de acordo com a distribuição
absoluta sugerida em (Levin, 1987) descrita na Tabela 4.1.
74
Tabela 4.1 – Distribuição de Critérios para Estudo Experimental
Critérios Respostas
Totalmente Parcialmente Em branco /
Não observado
Seqüências
sugeridas
7 2 0
Metas alcançadas 7 2 0
Problema
resolvido
7 1 1
Busca por códigos
similares
4 2 3
Anotações
satisfatórias
6 3 0
Integração entre
os membros do
time
4 3 2
Reutilização dos
códigos do
próprio time
8 1 0
Conforme destacado na análise mostrada na Tabela 4.1, houve 9 grupos de
respondentes e em todos os critérios houve uma predominância de respostas
“Totalmente”, o que indica satisfação e sucesso na execução da tarefa em grupo.
Na maioria dos critérios, a maioria das respostas corresponde à primeira coluna
(Totalmente) indicando que houve uma tentativa de seguir a especificação do
problema. No entanto, no critério “Busca por códigos similares” e “integração
entre os membros do grupo” as respostas foram quase igualmente distribuídas
entre as três colunas, indicando que os respondentes não estavam muito
confortáveis em lidar com esses critérios.
75
4.3.2. Análise Qualitativa
Na análise qualitativa desta pesquisa os objetos da pesquisa não foram
reduzidos aos critérios do questionário; em vez disso, eles foram estudados como
uma unidade em seu contexto de aplicação diário, o que já foi mencionado na
descrição do estudo de caso. Assim como em toda pesquisa qualitativa, vale
ressaltar que, de acordo com (Flick, 2004), as reflexões dos pesquisadores com
respeito às suas ações e observações em seu campo de trabalho (sala de aula, neste
caso), suas impressões, sentimentos e outras digressões se tornam dados por elas
mesmas e constituem uma parte da interpretação.
As reflexões dos grupos e dos pesquisadores foram coletadas e
transformadas em textos baseadas nos relatórios de desenvolvimento dos alunos,
reunidas pelos grupos e anotações do observador/pesquisador. A documentação de
dados não é simplesmente um registro neutro da realidade, mas um estágio
essencial de sua construção no processo da pesquisa qualitativa. A interpretação
dos dados é adaptada ou para a codificação e categorização ou para a análise de
estruturas seqüenciais no texto.
A fim de se analisar os textos dos relatórios de desenvolvimento, dois
aspectos foram considerados: as dificuldades encontradas pelos grupos e os
sucessos relatados na conclusão. O procedimento metodológico utilizado foi o
descrito em (Mayring, 1983), propondo três técnicas: a) abreviação da análise de
conteúdo; b) análise explanatória do conteúdo, e c) análise estrutural do conteúdo.
Para sintetizar essas técnicas, elevando-as a um nível mais alto de abstração, a
redução do material (os textos dos relatórios) foi realizada através da omissão de
declarações redundantes, conforme a primeira técnica propõe. As outras técnicas
foram aplicadas em seguida e resultaram nos dados da Tabela 4.2, que descreve as
dificuldades sentidas pelos grupos e na Tabela 4.3, que descreve as conclusões
fornecidas pelos grupos, conforme descritas nos relatórios de desenvolvimento
dos grupos.
76
Tabela 4.2 – Dificuldades sentidas pelos grupos
Informantes Descrição das dificuldades sentidas pelos
grupos
A Interpretação da declaração de algumas questões
B Transformação dos esboços de solução em código
Haskell; reunião de todo o time; alcance de um
consenso; agregação de todas as soluções.
C Entendimento da sintaxe do Haskell; agregação de
todas as soluções.
D Entendimento de como se constrói um programa;
construção adequada do programa; verificação de
erros; utilização do interpretador Hugs.
E Refinamento das soluções.
F Implementação do código.
G Utilização do interpretador Hugs; entendimento da
sintaxe do Haskell.
H Refinamento das soluções; utilização da recursão.
I Interpretação da declaração de algumas questões;
planejamento da solução; entendimento da sintaxe
do Haskell.
Para clarificar textos difusos, ambíguos ou contraditórios envolvendo
conteúdo relacionado ao contexto de aplicação, como, por exemplo, informação
sobre autor, situações gerativas, etc, os pesquisadores utilizaram a técnica de
análise explanatória de conteúdo. Baseados nessa análise, as percepções dos
pesquisadores sobre as dificuldades sentidas pelos grupos são apresentadas na
Tabela 4.4.
77
Tabela 4.3 – Conclusões fornecidas pelos grupos
Informantes Descrição das conclusões fornecidas pelos grupos
A Foi muito produtivo; nós colocamos nosso conhecimento em
prática; nós aprendemos como trabalhar em grupo.
B Ensinou-nos a trabalhar como um time, ajudando cada
participante a amadurecer e aprender como lidar com as
dificuldades e diferenças dos outros; houve um
comprometimento do grupo em todas as atividades realizadas.
C Não relatado
D Não relatado
E Demandou um trabalho conjunto do grupo; demandou uma
conexão e, sobretudo consenso entre todos os membros do
grupo; comunicação entre os membros do time foi mantida
principalmente via Internet (Chat e e-mail).
F Não relatado
G Não relatado
H Não relatado
I Uma discussão direcionada do grupo foi necessária para se
encontrar uma solução viável.
Considerando as conclusões relatadas pelos grupos, é possível formular a
seguinte paráfrase explanatória: “é necessário se trabalhar em grupo e há uma
demanda por compromisso, esforço e acordo dos participantes. As atividades
propostas foram benéficas e representou uma boa oportunidade de pôr em prática
o conhecimento em programação até então adquirido por todos”.
Os grupos experimentaram muitas dificuldades principalmente relacionadas
à codificação em linguagem Haskell da solução proposta. Mesmo que o
planejamento da solução tenha sido muito difícil para os alunos, já que esta
habilidade (solução colaborativa de problemas) depende de coordenação e
interação, as principais dificuldades relatadas foram as relacionadas às habilidades
necessárias ao processo de codificação, utilização das técnicas de programação
apropriadas e conhecimento da linguagem de programação específica. Isto resulta
que aprendizagem de programação pode ser mais bem aproveitada quando
78
conduzida em grupo, desde que siga um modelo ou esquema que facilite este
processo.
Tabela 4.4 – Percepções sobre as dificuldades sentidas pelos grupos
Informantes Percepções dos pesquisadores
A Interpretação da declaração de algumas questões.
B Implementação do código; reunião de todo o time; alcance de um
consenso; agregação de todas as soluções.
C Implementação do código; agregação de todas as soluções.
D Entendimento de como se constrói um programa; implementação
do código; verificação de erros; utilização do interpretador Hugs.
E Refinamento de soluções
F Implementação do código
G Utilização do interpretador Hugs; implementação do código;
H Refinamento das soluções; utilização da recursão.
I Documentação da atividade desenvolvida; planejamento da
solução; implementação do código.
Finalmente, a maioria dos grupos relatou que a experiência de desenvolver
uma atividade de programação em grupo foi positiva. Foi também observado que
tão importante quanto a formação dos grupos é o desenvolvimento da própria
tarefa, com a participação efetiva de cada membro do grupo.
4.4. Um Esquema Progressivo para Aprendizagem de Programação em Grupo
Um recorte na literatura relacionada à aprendizagem de programação em
grupo incluindo: o relato de uma experiência de 15 anos com aprendizagem de
programação (Castro et al, 2002); o uso de métodos colaborativos para representar
o conhecimento sobre resolução de problemas (Mendonça et al, 2002) (Pereira et
al, 2002) (Silva et al, 2002); a especificação de padrões de colaboração (Kobbe et
al, 2007); e um estudo-piloto na aprendizagem colaborativa de programação
(Castro et al, 2008), mostra que a programação em grupo é uma tarefa difícil em
grande parte devido à inexperiência dos estudantes com o trabalho em grupo. Para
desenvolver atividades em grupo, especialmente aquelas como a programação, é
79
necessário um modelo para orientar a atividade ou, no caso da inexistência de tal
modelo, um “esquema de progressão” para a aprendizagem de programação,
como proposto a seguir.
A análise do estudo de caso descrito em (Almeida, Castro & Castro, 2006)
resultou na concepção e desenvolvimento do “AAEP”, uma ferramenta
desenvolvida no contexto de uma dissertação de mestrado para a organização e
acompanhamento das soluções dos estudantes que permite, caso o professor
considere necessário, a comparação entre 2 versões quaisquer da solução de um
estudante. Essa ferramenta foi desenvolvida essencialmente para atender as
demandas do professor, possibilitando a ele o gerenciamento dos registros de
problemas pelos usuários e análises das soluções. Outras funcionalidades tais
como a elaboração de código-fonte de programas, edição e teste associado a
descrições para cada versão são acessíveis a professores e alunos.
O AAEP foi usado em sala de aulas para o apoio à programação em grupo, o
que foi crucial para adaptar um modelo de colaboração para aprendizagem de
programação em grupo envolvendo as seguintes ações:
Verificar se os estudantes procuravam por código já escrito para
problemas similares antes de tentar resolver um problema específico, o que
evidenciaria um estreito relacionamento entre solução de problemas e
programação baseada em exemplos;
Fazer o planejamento do processo de resolução mais explícito através da
organização e registro das versões de código produzidas;
Verificar se os estudantes reutilizavam as versões anteriores de seus
próprios códigos;
Observar se a interação no grupo conduzia a soluções mais rápidas;
Observar a incorporação da prática do indivíduo no grupo, com foco nas
possíveis mudanças comportamentais;
Analisar o comportamento do estudante dentro do grupo.
A Figura 4.1 ilustra o esquema progressivo de aprendizagem de
programação que define uma progressão do indivíduo para o grupo na
programação, em um cenário que inicia na Fase 1, com uma preparação que
envolve sessões no laboratório tratando com problemas introdutórios e
escla
o res
qual
probl
atore
defin
desen
reais
basea
funci
relato
desen
conte
arecimentos
spectivo reg
seria a me
lema torna-
es para cad
nição das
nvolviment
de trabalho
Figura 4
A opção p
ada na ex
ionais desen
os citados
nvolvido ao
Uma ferra
eúdo criado
s sobre a me
gistro. Na Fa
elhor soluç
-se colabora
da atividad
tarefas. P
o onde os g
o.
4.1 – Esque
pela divisão
xperiência c
nvolvido na
no início
o longo de u
amenta de a
o antes e d
etodologia. A
ase 3 o trab
ão individu
ativa: o pro
de. Na Fase
Por fim, n
grupos com
ema Progre
em
o em 6 fase
com o en
aquela instit
desta seção
um semestre
apoio à col
urante o cu
A Fase 2 co
balho em gr
ual desenvo
ofessor defin
e 5 o grup
na Fase 6
mpetem num
essivo de Ap
m Grupo
es, bem com
nsino de p
tuição desde
o, consider
e acadêmico
laboração f
urso, seguin
onsiste da so
upo começa
olvida. Na
ne as tarefa
po é tamb
6 acontece
m cenário qu
prendizage
mo a seque
rogramação
e 1989, bem
rando-se um
o.
foi utilizada
ndo as dire
olução indiv
a com a dec
Fase 4 a s
as e o grupo
ém respon
uma ativ
ue reproduz
em de Prog
enciação pro
o usando l
m como na a
m curso de
a e incorpor
etivas encon
80
vidual com
cisão sobre
solução do
o define os
nsável pela
vidade de
z situações
gramação
roposta, foi
linguagens
análise dos
e 75 horas
rou todo o
ntradas em
81
(Fuks, Pimentel & Lucena, 2006), com atenção aos problemas descritos em
(Pimentel, Fuks & Lucena, 2003). A Figura 4.2 descreve o planejamento das
atividades práticas de acordo com as fases e semanas do curso. A seguir são
apresentados amostras de exercícios por fase. Esses exercícios são oriundos do
repositório de exercícios de programação da UFAM, com acesso restrito via
colabweb.ufam.edu.br.
1. Preparação – Survey inicial onde estudantes respondem um
questionário disponível no ambiente de apoio e resolvem problemas
introdutórios, por exemplo: “Um grupo de quatro amigos deseja
comprar um produto que custa mais dinheiro do que eles têm. De
modo a realizar a compra, o grupo decide que o valor final deve ser
dividido proporcionalmente ao valor que cada um já contribuiu,
considerando que aquele que contribuiu com mais dinheiro poderia,
em princípio, conseguir mais algum na mesma proporção. Descreva
como você resolveria esse problema usando o Haskell, indicando
quanto cada um deveria pagar.”
2. Codificação Individual I – Sessões de laboratório para resolver
problemas geométricos básicos com análise das soluções baseada
nos tempos de resolução. Exemplo: “Dados 2 pontos, p1 e p2,
localize no espaço cartesiano uma linha. Determine a equação dessa
linha.”
3. Codificação Individual II – Resolução de um exercício em Haskell
com registro das anotações. Exemplo: “Dados 3 pontos, p1, p2 e p3,
localizados no espaço cartesiano, determine se eles constituem um
triângulo e, se for caso, determinar sua área.”
4. Codificação em Grupo I – Análise e seleção de soluções individuais,
com anotações colaborativas sobre o processo decisório e os
refinamentos identificados. Exemplo: “Considere 2 pontos, p1 e p2,
localizados no espaço cartesiano. Estamos interessados em
identificar entre os seguintes relacionamentos entre eles são
aplicáveis: (a) se é possível traçar uma linha passando por p1 e p2 e
em paralelo à linha das abscissas; (b) se é possível traçar uma linha
passando por p1 e p2 e em paralelo ao eixo das ordenadas; (c) se p1
e p2 estão no mesmo quadrante; (d) se p1 e p2 estão em diferentes
82
quadrantes; (e) se p1 e p2 estão em quadrantes opostos; (f) se p1 e
p2 estão em quadrantes adjacentes.”
5. Codificação em Grupo II – Resolução de 3 problemas, sendo que o
primeiro é resolvido como na fase anterior, com membros do grupo
revisando os códigos uns dos outros, fazendo anotações. No segundo
problema ocorre a divisão de tarefas, realizada pelo professor. No
terceiro problema a distribuição de tarefas é feita pelo grupo, que
registra todo o processo decisório. Exemplo para uso como segundo
ou terceiro problema: “Em uma clínica, tão logo um paciente chega,
ele recebe um número de atendimento. Em cada turno há sempre três
médicos, que atendem os pacientes dependendo do número de
pacientes que cada um já tem em sua lista de atendimento. O médico
que tiver menos pacientes na lista recebe o próximo paciente.
Usando tuplas, pode-se definir a seguinte entrada: médicos (("dr. A",
4, 23), ("dr. B", 1, 13), ("dr. C", 3, 27)), onde o segundo termo de
cada tupla refere-se ao número de pacientes na lista do médico e o
terceiro termo se refere ao último paciente atendido por aquele
médico. Baseado nessa entrada, escreva um script em Haskell que,
para um dado paciente, escolha qual lista de atendimento ele será
alocado.”
6. Codificação em Grupo III – Atividade no estilo de uma maratona de
programação, consistindo de: observação externa por professor ou
programador experiente; uso de ferramenta de monitoramento de
atividades do grupo; e estágios com complexidade crescente.
Exemplo de cenário: “Num banco de sangue há o registro de doação
que inclui o CPF do doador (CPF), sexo (S), idade (I), tipo de
sangue (TS), fator RH (RH), data (DD) e a quantidade de sangue
doada (QS), que pode ser 250 ou 500ml. O sangue é mantido em
recipientes com capacidade fixa de 250ml. Hospitais (H) solicitam
sangue diariamente. Cada solicitação indica as características do
sangue (tipo e fator RH) e a quantidade requisitada (QR). Sabe-se
que homens e mulheres devem guardar intervalos mínimos entre
doações, sendo 2 meses para mulheres e 3 meses para homens. As
defin
resol
racio
segui
ida
res
Figura 4
Ainda com
nição em Ha
lução indiv
ocínio mais
inte, Codifi
ades máxim
spectivamen
4.2 – Workf
m respeito a
askell são o
vidual requ
matemático
ficação em
mas e mín
nte...”
flow do Esq
Programa
ao esquema
s conceitos
uer o mesm
o devido à n
Grupo I, re
nimas para
quema Pro
ação em Gr
proposto, a
envolvidos
mo nível d
natureza do
equer o uso
a doadores
ogressivo de
rupo
a modulariza
s na fase de
de expertis
os problema
o de expres
são 60 e
e Aprendiz
ação de pro
preparação
e, em adiç
as geométric
sões condic
83
e 15 anos
zagem de
oblemas e a
o. A fase de
ção a um
cos. A fase
cionais em
84
adição ao conhecimento sobre problemas geométricos. Na fase de Codificação em
Grupo II, os estudantes usam tuplas e listas para resolver os problemas propostos.
Por fim, na fase de Codificação em Grupo III, os estudantes precisam resolver
problemas que envolvem tuplas, listas e recursão.
A partir da primeira fase de codificação em grupo, os estudantes trabalham
nos grupos que são formados na terceira semana de práticas, após a aplicação de
uma sessão supervisionada de laboratório. O requisito adotado é que cada grupo
seja o mais heterogêneo possível, com um mínimo de 5 membros. Não mais que 2
devem ter experiência formal em programação, 1 pode ter alguma experiência
(por exemplo programação de scripts Web) e 2 a 3 não possuem experiência em
programação.
Conforme mostrado nos exemplos de exercícios nessa seção, após a
formação dos grupos, os exercícios aumentam em complexidade de acordo com o
esquema progressivo e o conteúdo do curso. Isso possibilita o avanço gradual de
um ritmo de trabalho baseado em práticas individuais para a incorporação de
práticas colaborativas no desenvolvimento de programas.
4.5. Conclusão do Capítulo
Neste capítulo apresentamos o trabalho em grupo como uma maneira de se
desenvolver habilidades cognitivas. Como em muitos ambientes de trabalho na
área de computação, as habilidades relacionadas à colaboração são requisitos
necessários aos desenvolvedores e gerentes, essa é uma prática que os alunos
precisam ser expostos desde a graduação.
Para incorporar colaboração nas práticas da disciplina introdutória
destacamos que é necessária, além de planejamento, a adoção de mecanismos de
estruturação das interações. Um mecanismo muito utilizado em aprendizagem
colaborativa é script de colaboração. Discutimos como eles podem ser utilizados
para estruturas as conversas durante a realização de atividades em grupo,
apresentando também as desvantagens em utilizá-los.
Independentemente da utilização de scripts é necessário se conhecer como
os alunos, intuitivamente, se organizam em seus grupos para resolverem
exercícios de programação. Por isso, na Seção 4.3 apresentamos um relato
85
baseado em (Castro et al, 2008) que descreve a análise de um estudo de caso
exploratório.
No próximo capítulo discutimos a aplicação e análise de dois estudos de
caso. O primeiro para aplicar o esquema progressivo de aprendizagem de
programação em grupo descrito na Seção 4.4 deste capítulo. O outro para
confirmar as categorias para análise das conversas identificadas no primeiro
estudo de caso, chamadas de padrões de interação. Os três estudos de caso, o
apresentado neste capítulo e os do próximo capítulo, embasam a sistematização da
abordagem sistematizada para aprendizagem de programação em grupo.
5 Sistematização da Aprendizagem de Programação em Grupo
Até agora propusemos elementos de uma abordagem para aprendizagem de
programação em grupo baseada em: (1) elementos da evolução de códigos para
evidenciar pistas de aquisição de níveis mais elevados de abstração a partir da
identificação de fragmentos de código que representam modificações na forma
como o aluno “enxerga” a solução do exercício; (2) elaboração de exercícios de
programação adequados ao desenvolvimento da habilidade de abstração de alunos
iniciantes em cursos de graduação em computação, proporcionando a prática em
grupo como sugerido nos estudos de Piaget; (3) recomendações para utilização,
configuração e desenvolvimento de interfaces para ambientes CSCL de forma a
proporcionar maior poder de comunicabilidade entre os alunos; e (4) um esquema
progressivo de introdução de práticas colaborativas no contexto de situações de
aprendizagem de programação em grupo.
Para que os elementos enumerados acima se transformem na sistematização
de uma abordagem é necessário evidenciar se, com a utilização de um ambiente
CSCL (3) para apoiar a disciplina de programação introdutória, a elaboração de
exercícios de programação que proporcionem a evolução do raciocínio abstrato
(2), seguindo um macro-script para colaboração (4) e considerando que o aluno
modifique seu raciocínio através do refinamento sucessivo dos códigos (1), as
oportunidades de intervenção são ampliadas.
As intervenções têm o propósito de, através do acompanhamento durante a
resolução dos exercícios, incentivarem as interações no ambiente. Essas atividades
requerem a identificação e análise dos padrões presentes nas interações, que
constituem o elemento final da sistematização proposta nesta tese.
Nas próximas seções são apresentados dois estudos de caso. O primeiro foi
elaborado aplicando os 4 primeiros elementos da abordagem. Sua análise indica
como acompanhar de forma mais efetiva as conversas dos alunos no ambiente
CSCL utilizado, caracterizando padrões que possibilitam a sistematização
87
proposta nesta tese. O segundo estudo de caso buscou analisar a abordagem com
todos os elementos definidos, relacionando seus resultados aos do estudo anterior.
Optamos pela utilização da metodologia de estudos de caso por tratar-se da
aplicação de um método a uma situação real de aprendizagem, no caso uma
disciplina de programação introdutória. O esquema progressivo de aprendizagem
de programação em grupo proposto precisava ser testado de modo a provar sua
utilidade em cursos introdutórios de programação como forma de desenvolver nos
alunos habilidades para colaboração em programação, apoiando o refinamento de
sua habilidade de abstração.
Escolhemos a UFAM como instituição para aplicação do estudo uma vez
que lá poderíamos aplicar esse estudo ao longo de toda a disciplina de introdução
à programação, definindo todas as etapas do curso, sem que precisássemos fazer
uma observação participante, o que poderia, neste caso, prejudicar a análise.
Primeiramente, propusemos um estudo de caso para aplicarmos os
elementos dessa abordagem, em forma de um estudo de caso descritivo [Yin, ],
onde procuramos por evidências de como os grupos utilizam o esquema proposto,
dentro da metodologia do curso. A partir da análise desse estudo de caso,
identificamos padrões nas interações nas discussões registradas nos fóruns que
nos permitiram caracterizar através do estilo de conversa, se o grupo estava
interagindo de forma a favorecer a colaboração.
Um segundo estudo de caso foi então definido, sendo o seu projeto uma
replicação do primeiro, com a diferença de que nesse momento procuramos
explicações para confirmar uma hipótese, o que caracteriza um estudo de caso
explanatório (Yin, 2010). Foram utilizadas as categorias encontradas
anteriormente, as quais foram chamadas de padrões de interação.
5.1. Definindo Padrões de Interação – Estudo de Caso Descritivo
Esse estudo de caso foi desenvolvido no primeiro semestre de 2008, na
UFAM, concomitantemente com duas turmas da disciplina Introdução à
Computação, uma turma de 60 alunos calouros de Ciência da Computação e outra
com 50 alunos calouros de Engenharia da Computação. Seu objetivo é descobrir
como os grupos utilizam o esquema progressivo de aprendizagem de programação
em grupo. Para isso, buscamos as evidências:
88
a. Quanto à reutilização de códigos. Os alunos procuram reutilizar
códigos deles mesmos ou dos outros membros do grupo?
b. Sobre a qualidade das interações. As interações no grupo propiciam
uma troca de conhecimentos (colaboração)?
c. Sobre os estilos individuais de programação. Eles se modificam
conforme as interações com o grupo?
d. Sobre a intervenção do professor. O professor consegue identificar
oportunidades de intervenção durante a realização dos exercícios?
Uma questão paralela ao objetivo e à busca das evidências acima era “como
identificar oportunidades de intervenção nos grupos?”. Essa questão orientou a
busca por evidências nas conversas, registradas no fórum do ambiente CSCL
utilizado, o ColabWeb, e nos códigos, primeiramente armazenados em um sistema
de controle de versões, o AAEP, e posteriormente somente no próprio fórum e no
relatório do grupo.
O estudo de caso descritivo foi escolhido porque o fim era descobrir como
aquelas turmas se organizariam nos grupos e descrever como foi o processo de
apropriação do esquema progressivo. Neste caso, conforme descrito em (Yin,
2010), não há uma proposição, hipótese ou categorias a priori, sendo a descrição
do fenômeno em si a maior preocupação.
Apesar de nos estudos de caso descritivos a observação participante ser
muito utilizada, neste estudo de caso utilizamos observação não-participante, pois
as turmas observadas possuíam cada uma dois professores para conduzir tanto as
aulas teóricas, quanto às aulas práticas, incluindo o acompanhamento online. Uma
vez que todo o registro das atividades era realizado no ColabWeb ou outra
ferramenta auxiliar, não precisamos nos inserir nos grupos para observá-los,
mantendo assim uma maior isenção.
5.1.1. Metodologia
A disciplina Introdução à Computação possui quatro horas teóricas e duas
práticas por semana. Este estudo de caso interfere somente nas aulas práticas, que
após uma explicação inicial no laboratório, deveriam ser complementadas a
distância, preferencialmente sem que os integrantes de um grupo estivessem no
mesmo ambiente físico.
89
Para a realização do estudo de caso foram utilizados os registros resultantes
da coleta de dados dos seguintes instrumentos:
• 1 questionário de anuência à participação na pesquisa
• 1 questionário de avaliação inicial, contendo perguntas sobre a formação
acadêmica dos alunos e exercícios lógico-dedutivos
• 4 exercícios iniciais de programação (fase de preparação)
• 2 exercícios de laboratório para a fase individual (para 1 aula de
laboratório)
• 4 exercícios de laboratório para as fases em grupo (para 6 aulas de
laboratório)
• 1 exercício de laboratório para a fase de competição (para 1 aula de
laboratório)
• Observações individuais dos alunos
• Observações individuais dos monitores
• Logs das discussões registradas em fórum ou chat do ColabWeb
• Logs do processo de eleição das melhores soluções
• Logs do processo de modularização e delegação de módulos
Considerando as fases do esquema progressivo de aprendizagem de
programação em grupo, as atividades planejadas seguem a sequência abaixo.
Apesar de prazos fixos, o professor fornece uma alternativa para caso de o
ColabWeb estar fora do ar, que é a utilização de outra ferramenta de domínio
público. Nesse caso os alunos enviam o link, fornecendo acesso ao professor.
Fase 1 – Preparação: da 1a. à 4a. semana de aula
1. Levantamento inicial
a. Aplicação do questionário de anuência e do questionário de
avaliação inicial.
2. Aplicação dos exercícios 1 e 2, para serem resolvidos individualmente
em qualquer ponto de rede remoto
a. Atividade prática a distância, utilizando o AAEP, com sessão
aberta na terça-feira, às 16 horas e encerramento na sexta-feira,
às 16 horas.
b. Análise de resultados baseada no tempo de resolução e na
precisão dos códigos.
90
3. Definição dos grupos
a. Escolha pelos professores, baseada em 1 e 2.
Fase 2 – Codificação Individual: 5a. semana
1. Resolução do exercício 3, contendo observações individuais feitas no
próprio AAEP. Esta atividade é realizada exclusivamente no laboratório
durante uma sessão.
a. As turmas 1 e 3 têm a sessão na quinta-feira e as turmas 2 e 4, na
sexta-feira.
Fase 3 – Codificação em Grupo (1): Elaboração de soluções coletivas
1. O exercício 4 é disponibilizado no AAEP e explicado pelo tutor na
sessão semanal de laboratório.
a. Os alunos devem resolvê-lo completamente e individualmente
durante a mesma sessão de laboratório.
b. Posteriormente à sessão, os alunos, em seus grupos, têm até às
23 horas do mesmo dia para discutirem e decidirem qual solução
individual é a melhor. Esta discussão deve ser realizada no
ColabWeb em forma de fórum ou chat, podendo ser acrescida de
uma enquete.
c. Se houver ainda algum melhoramento no código escolhido pelo
grupo, um dos membros do grupo deve submetê-lo novamente
ao AAEP até as 23 horas do dia seguinte.
2. Cada etapa vale uma nota de 0 a 10. As tarefas são resolução individual
em laboratório; registro das discussões com escolha da melhor; e
correção da solução escolhida pelo grupo.
a. Nota 1 – codificação individual em laboratório (avaliação
individual)
b. Nota 2 – registro da discussão dentro do prazo (avaliação em
grupo com atribuição de nota para quem participar ativamente da
discussão)
c. Nota 3 – código do grupo (avaliação em grupo)
Fase 4 – Codificação em Grupo (2): construção coletiva com divisão pelo
professor
1. Sistematização dos processos descritos nas fases II e III para construção
coletiva de soluções, cujo exercício requer uma divisão e definição dos
91
autores de cada parte. O professor fornece a divisão como parte da
descrição do exercício 5.
a. As partes do exercício devem ser resolvidas individualmente
durante uma sessão de laboratório, podendo ser refinadas até as
20 horas do mesmo dia.
b. Posteriormente à sessão, os alunos, em seus grupos, têm até às
19 horas do mesmo dia para discutirem sobre eventuais dúvidas
ou confirmarem que não têm dúvidas. Esta discussão deverá ser
realizada no ColabWeb em forma de fórum ou chat.
c. Em seguida, os grupos têm até às 23 horas do mesmo dia para
discutirem sobre a integração dos módulos (como fazer, o que
precisa modificar, o que está errado, etc.). Esta discussão
também deve ser realizada no ColabWeb em forma de fórum.
d. A próxima etapa é a integração dos módulos, com resolução do
exercício no AAEP, devendo ser finalizada até as 23 horas do dia
seguinte. Todas as versões do código deverão conter observações
relevantes sobre as tentativas de integração.
2. Cada etapa vale uma nota de 0 a 10. Para resumir, as tarefas são:
resolução individual dos módulos em laboratório; registro das
discussões sobre eventuais dúvidas; registro das discussões sobre
integração dos módulos; desenvolvimento do exercício completo
desenvolvido no AAEP.
a. Nota 1 – codificação dos módulos no laboratório (avaliação
individual)
b. Nota 2 – discussões sobre dúvidas (avaliação do grupo)
c. Nota 3 – discussões sobre integração das partes (avaliação do
grupo)
d. Nota 4 – exercício completo feito no AAEP (avaliação do
grupo)
Fase 5 – Codificação em Grupo (3): construção coletiva com divisão pelo grupo
1. Sistematização dos processos descritos nas fases II e III para construção
coletiva de soluções, cujos exercícios requerem uma divisão e definição
dos autores de cada parte. O próprio grupo deverá dividir o exercício 6
em partes, a seu critério.
92
a. O exercício 6 será disponibilizado no ColabWeb para cada turma
exatamente 24 horas antes das sessões de laboratório. Cada
grupo terá, portanto, até as 23 horas do dia anterior à sua sessão
de laboratório para discutir sobre a modularização e divisão de
tarefas para o exercício proposto. Esta discussão deverá ser
realizada no ColabWeb em forma de fórum ou chat.
b. Durante a primeira sessão de laboratório, os alunos devem
resolver individualmente as partes que ficaram responsáveis.
Esta codificação deverá ser realizada exclusivamente no AAEP.
Os alunos poderão refiná-las até as 24 horas do mesmo dia.
c. Posteriormente à sessão, os alunos, em seus grupos, terão até as
23 horas do mesmo dia para discutirem sobre eventuais dúvidas
ou confirmarem que não têm dúvidas. Esta discussão deverá ser
realizada no ColabWeb em forma de fórum ou chat.
d. Em seguida, os grupos terão até as 23 horas do domingo para
discutirem sobre a integração dos módulos (como fazer, o que
precisa modificar, o que está errado, etc.). Esta discussão
também deve ser realizada no ColabWeb em forma de fórum ou
chat.
e. A próxima etapa é a integração das partes, com resolução do
exercício no AAEP, realizada durante a 2ª. sessão de laboratório,
podendo ser refinada até as 23 horas do mesmo dia. Todas as
versões do código deverão conter observações relevantes sobre
as tentativas de integração.
2. Cada etapa vale uma nota de 0 a 10. Para resumir, as tarefas são registro
das discussões sobre divisão de tarefas; resolução individual das partes
em laboratório; registro das discussões sobre eventuais dúvidas; registro
das discussões sobre integração das partes; desenvolvimento do
exercício completo desenvolvido no AAEP.
a. Nota 1 – discussões sobre divisão (avaliação do grupo)
b. Nota 2 – codificação das partes no laboratório (avaliação
individual)
c. Nota 3 – discussões sobre dúvidas (avaliação do grupo)
93
d. Nota 4 – discussões sobre integração das partes (avaliação do
grupo)
e. Nota 5 – exercício completo feito no AAEP (avaliação do grupo)
3. O exercício 7 é realizado da mesma maneira que o exercício 6, nas duas
semanas seguintes.
Fase 6 – Time de desenvolvimento: competição
1. Estilo de maratona de programação, realizada durante uma sessão de
laboratório (exercício 8). Possivelmente com um prêmio em jogo.
2. Auto-avaliação do processo
a. Aplicação de questionário de avaliação final da disciplina
Os grupos iniciais, até a fase 5, são formados pelos professores, mediante a
avaliação de um questionário inicial que identifica o nível de expertise dos alunos.
Para isso, cada grupo pode conter de 5 a 8 alunos, dos quais de 1 a 3 integrantes
devem possuir alguma experiência em programação, 3 a 4 inexperientes em
programação e 1 com experiência em programação por scripts web. Esse critério
de divisão de grupos é baseado em experiência com turmas anteriores da mesma
disciplina. Segundo professores dessa disciplina, cerca de 50% dos alunos que
ingressam nos cursos de computação da UFAM já possuem experiência com
programação, desses somente poucos possuem experiência informal, como
programação por scripts.
Para testar os elementos apresentados nesta tese e acompanhar as práticas
propostas de programação em grupo, um conjunto de ferramentas computacionais
foi disponibilizado aos alunos, cada uma apoiando um tipo de atividade. O
ColabWeb foi utilizado como principal ambiente do curso. Nele estavam todas as
informações sobre a disciplina e é nele que as discussões e outras interações estão
registradas, bem como a entrega de relatórios e as comunicações dos professores
com as turmas. No AAEP, ambiente com suporte ao controle de versões, o aluno
codifica sua solução e o próprio AAEP armazena todas as versões de código para
posterior análise. Como o AAEP foi projetado para apoiar a programação
individual, alternativamente, os alunos podem codificar utilizando o seu próprio
interpretador HUGS, incluindo suas versões de código junto com a conversa para
agilizar as discussões.
94
No decorrer do período letivo, o AAEP foi abandonado pelos alunos, pois
estes acharam mais produtivo incluir os códigos nas próprias conversas dos
grupos, não vendo a necessidade de codificar no AAEP e depois registrar no
grupo. Os alunos comentaram em sala de aula que os grupos encontram erros e
corrigem as soluções mais rapidamente que os alunos sozinhos, utilizando o
AAEP.
5.1.2. Análise Parte 1 – Obtendo padrões
Esse estudo de caso foi planejado para as quatro turmas de Introdução à
Computação da UFAM. No entanto, as professoras responsáveis pelas turmas de
Engenharia da Computação não conseguiram aplicá-lo porque o laboratório
utilizado pelos alunos só foi liberado após as 3 primeiras semanas de aula e
porque, segundo as professoras, os alunos não puderam ser treinados no uso do
ColabWeb, o que os impediu de terem sucesso na sua utilização. Outros fatores,
como a configuração do curso, apontados no Capítulo 3, também contribuíram
para isso.
Durante a realização do estudo de caso para as turmas de Ciência da
Computação, o professor acompanhou as discussões primeiramente observando se
os grupos estavam discutindo. Quando não havia discussão, enviava um email aos
integrantes do grupo pedindo que discutissem sobre o exercício. No decorrer das
discussões, segundo entrevista posterior com o professor, ele não conseguiu
intervir tanto quanto gostaria, pois não conseguia identificar rapidamente se o
grupo estava com dificuldades a não ser que o próprio grupo o procurasse.
A resolução dos exercícios seguiu o planejamento das fases do plano
progressivo de aprendizagem de programação em grupo, conforme apresentado no
Capítulo 4. Para essa análise, utilizamos os logs do fórum referentes a três
exercícios da fase 5, Codificação em Grupo II.
Ao procedermos a análise dos logs, observamos que os turnos de fala,
apesar das diferenças de vocabulário e estilo, apresentavam intenções que se
repetiam em todos os grupos. Dada a natureza dos diálogos, notamos uma
semelhança com Atos de Fala, que, conforme descrito por Searle (1969), são
classificações para os diferentes usos da linguagem, principalmente sobre a
interpretação de questões, exclamações, comandos, ou seja, sobre enunciados que
95
não são unicamente descritivos. Percebemos que são descritos para cada fala uma
classificação que retrata a intenção do indivíduo, o que sugeriu sua adequação à
situação observada na análise. A teoria dos atos de fala é utilizada em ambientes
multiagente para descrever as interações dos agentes. Para adaptá-la ao contexto
de fóruns de discussão voltados à aprendizagem de programação, achamos
necessário estender o conceito do ato de fala, de forma que retratasse a
continuação desses atos, em forma de resposta. Dessa forma podemos perceber se
o grupo está conversando (alternando turnos, comentando falas anteriores) ou se
está somente cumprindo o roteiro do esquema progressivo.
Chamamos essas classificações inspiradas em atos de fala estendidos de
padrões de interação, devido a sua utilização em desenvolvimento de ambientes
CSCL, possuindo categorias de descrição para cada padrão, o que fornece mais
subsídios para verificação de consistência de cada padrão.
Conforme mencionado anteriormente, a elicitação dos padrões de interação
e posteriormente das combinações recorrentes dos mesmos, basearam-se nos logs
dos exercícios da fase 5. Os quadros a seguir apresentam os enunciados de dois
exercícios que serão usados para ilustrar várias etapas e situações do processo.
Quadro 5.1 – Enunciado do exercício “Campeonato de Futebol”
Campeonato de Futebol No campeonato amazonense de futebol, os times se enfrentam em dois turnos e depois os
campeões de cada turno se enfrentam e decidem quem é o campeão estadual. Em cada turno, todos os times jogam contra todos e a pontuação obedece ao seguinte critério: (a) O vencedor de uma partida ganha 3 pontos; (b) Os times que empatam ganham 1 ponto cada; (c) O perdedor perde 1 ponto.
Considere que os times inscritos para o campeonato 2008 são: Nacional, São Raimundo, Grêmio Coarience, Rio Negro, Fast, Libermorro, América e Sulamérica. Faça um script em Haskell para dar pontuações parciais em cada turno, mostrar o total de pontos ganhos por cada time ao final do primeiro e segundo turno e mostrar o vencedor de cada turno.
Obs.: A pontuação do primeiro turno é desconsiderada para os cálculos da pontuação do segundo turno.
Obs2.: Como esta questão é para ser resolvida em um período máximo de 24 horas, serão consideradas somente as corretas e a pontuação se dará de acordo com a criatividade na resolução.
Quadro 5.2 – Enunciado do exercício “Atendimento em Ambulatório”
Atendimento em Ambulatório Em um ambulatório, assim que o paciente chega recebe uma senha para atendimento. Há vários médicos disponíveis por turno de trabalho e esses médicos receberão novos
pacientes dependendo do número de pacientes que cada um já tem em sua lista de atendimento. O médico que possui menos pacientes em sua lista de atendimento recebe o próximo. Usando tuplas, podemos definir a seguinte entrada:
medicos_disp = [(24432, 4, 23), (144, 1, 13), (234, 3, 27)] , onde o segundo termo de cada tupla refere-se ao número de pacientes na lista de atendimento do médico identificado no primeiro
96
termo da tupla (CRM do Médico). O terceiro termo refere-se ao último paciente atendido pelo médico.(CRM,NumeroPacientes,UltimoPaciente)
Baseado nessa entrada, escreva um script em Haskell para, um dado novo paciente, escolha em qual lista de atendimento (de qual médico) o novo paciente deve ser alocado.
Observação: Cada integrante da equipe tem que fazer uma das funções listadas abaixo. A
decisão de quem vai fazer o que deve ser feita utilizando-se o fórum de discussão no ColabWeb, assim como as decisões do relatório.
No relatório deve conter quem fez cada função e, para cada uma, as etapas do Polya. medicos_disp = [(24432, 4, 23), (144, 1, 13), (234, 3, 27)] 1. Lista do número de pacientes de cada médico 2. Índice do menor elemento da lista 3. Médico com menos pacientes, a tupla do médico
(CRM,NumeroPacientes,UltimoPaciente) 4. CRM do médico com menos pacientes 5. Chega um novo paciente (identificado por seu número) e retorna a lista das filas dos
médicos atualizada 6. Chama um paciente da fila de um médico: as entradas são o CRM do médico e o número
do paciente que estava na fila, e retorna a lista das filas dos médicos atualizada 7. Número do último paciente que foi atendido (Somente para equipes com 7 Integrantes)
A fase 5 do esquema progressivo de aprendizagem de programação em
grupo é crucial porque é nela que os alunos precisam pensar no problema como
um todo e elaborar sua solução coletivamente. Durante o processo de solução de
problemas eles precisam acomodar as perspectivas uns dos outros e negociar
sempre que há um conflito de idéias. A seguir comentamos sobre como os grupos
discutiram sobre a resolução do 2º. exercício da fase 5, descrito no Quadro 5.2 e
como os padrões de interação são identificados, utilizando-se um conjunto de
palavras-chave, em destaque nos fragmentos de conversa.Vale notar que o
professor propôs um método específico de resolução. Alguns grupos adaptaram
esse método para que o exercício fosse resolvido de acordo com a característica
do próprio grupo.
Todos os fragmentos de conversa mostrados abaixo são uma cópia exata
das conversas registradas no ColabWeb. Portanto, há muitos erros sintáticos e
gramaticais, como era de se esperar em conversas informais. Eles foram deixados
para fornecer ao leitor uma perspectiva real da conversa.
O grupo 1 não discutiu nem sobre o entendimento do exercício nem sobre
sua resolução, não atentando para a divisão do trabalho e do processo de juntar
todas as soluções individuais em uma única solução do grupo. Em vez disso, cada
integrante do grupo disponibilizou sua própria solução. Eles produziram soluções
individualizadas, o que pode ser visto pela codificação.
97
Um integrante do grupo 2 liderou naturalmente seu grupo. Outro assumiu
a distribuição das partes do exercício entre os integrantes. A conversa sobre o
entendimento geral do exercício foi rudimentar, ganhando alguma força ao
envolver aspectos sobre a codificação. O último tópico da conversa utilizou
padrões de interação “sugerir”. O líder examinou todos os códigos e apontou o
que poderia ser melhorado em cada um, conforme ilustra o fragmento abaixo.
StDi FALTA StKa AJEITAR A FUNÇÃO E REFAZER PASSOS DO
POLYA, StDio E StJofi CORRIGIREM OS PASSOS DO
POLYA.
StDio, já coloquei acima o que precisa fazer no
teu caso,StJofi, as entradas são uma lista de
tuplas, mesmo que na função tu trabalhe com o
resultado da função anterior, corrigi lá nos
passos do polya. Exemplo:
Entradas:[("dr. A", 4, 23), ("dr. B", 1, 13),
("dr. C", 3, 27)]
Saídas: "dr. B"
StKa a tua função tá errada, ela têm que
retornar a lista completa de tuplas, sendo que a
tupla do medico requerido na entrada terá o
segundo termo -1 e o último termo será o número
do paciente colocado na entrada.
Exemplo:
Entradas: "dr. A" 28 [("dr. A", 4, 23), ("dr.
B", 1, 13), ("dr. C", 3, 27)]
Saída: [("dr. A", 3, 28), ("dr. B", 1, 13),
("dr. C", 3, 27)]
No fragmento de conversa acima ocorreu uma conversação mais natural.
Esse aspecto e a fluência com que a conversa se desenrolou levou o grupo a um
resultado excelente.
O grupo 3 basicamente seguiu a mesma rota: um aluno assumiu a
liderança do grupo, mas também foi o responsável pela distribuição das partes do
exercício aos outros integrantes. A discussão sobre a codificação começou
fluindo, mas se perdeu um pouco. Nesse ponto um aluno disponibilizou seu
código e relatório e isso aparentemente chamou a atenção de uma aluna. Ela
98
reagiu iniciando um padrão de interação “esclarecer” começando com sua opinião
acerca do código, conforme mostrado no fragmento abaixo.
StVi Aê pessoal!!! já fiz a minha e
achei bem simples:
aux_menores x xs = [ y | y <- xs
, y < x ]
indice_menor xs = [i | i <-
[0..length xs-1], aux_menores
(xs!!i) xs == []]
Mas apesar de ter achado
simples, queria que dessem uma
olhado no final da função do
"indice_menor xs" ( aux_menores
(xs!!i) xs == []), porque foi
onde tive mais dificuldade.
esclarecer
disponibilizar
perguntar
StFla Bem a minha ficou bem pequena,
achei até estranho, mas axo q
está completa já que era uma
questão simples. O que fiz foi
aproveitar a questão 2 que
mostra o índice menor, e usa-la
para mostrar o médico com menos
pacientes. Segue abaixo:
medicos_menos_pacientes = disp!!
indice_menor
Indice_menor foi a questão usada
na 2ª, já que ela pode ser usada
para mostar também o médico com
menos pacientes. Vejam aew qq
pode estar errado!
esclarecer
explicar
disponibilizar
explicar
StVi Kra..
explica detalhadamente o q tu
fez... pq... naum tô encontrando
um método q entre o q eu fiz?
ahh..
vc testou? pq tipo.. a minha é
"indice_menor xs" deu certo?
re-disponibilizar
perguntar
99
O grupo 4 teve mais de um integrante liderando o grupo. Uma aluna
propôs um tópico sobre alguma peculiaridade que ela encontrou no exercício.
Baseado nisso, outro aluno levantou um ponto sobre a natureza do exercício e um
terceiro sugeriu um método de resolução levemente diferente daquele proposto
pelo professor. Todos seguiram a sugestão do terceiro integrante disparando
discussões sobre as soluções individuais. O fragmento abaixo registra o momento
que um aluno percebe a natureza do exercício. Então outro aluno propõe uma
maneira de fazê-lo ganhando a liderança do processo de solução.
StJa Eu achei que o problema é sequêncial...
Cada uma das funções exigidas tem a sua
resolução facilitada se usada a
anterior a ela, já que uma aparente
interdepender da outra... Acredito que
a melhor solução do problema seria
fazer ordenadamente cada função para ir
aproveitando-as aos poucos,
criando funções auxiliares quando
necessário.
sugerir
StLu Eu também acho que é um problema em que
cada resposta segue a lógica de sua
anterior, deveriamos então fazê-las em
ordem para tornar o problema mais fácil
e "entendível".
re-sugerir
StRoma Pelo visto todos do grupo concordam
quanto ao problema ser sequêncial e
consequentemente
reaproveitar funções de
cada questão em questões posteriores.
Sendo assim, devido ao pouco espaço de
tempo que nos resta, o ideal seria que
cada um tentasse bolar uma solução para
cada questão a sua maneira, e dentre
estas escolheríamos as mais corretas
para combina-las e formar a
melhor solução. Em caso de perda de
tempo em determinada questão, procure
pensar na próxima, dando apenas
continuidade ao raciocínio de outro ou
sugerir
100
ate mesmo modificando-o, pois não temos
mais o tempo suficiente para enrolar
com questões que outros já
desenvolveram tranquilamente e que
podem talvez apenas ser melhoradas.
É interessante observar a partir do fragmento acima que apesar de
ocorrerem duas idéias antagônicas para a solução do exercício como um grupo, os
líderes encontraram uma maneira de atender ambos os pontos de vista,
caracterizando a discussões por muitas sugestões após “informar” e “esclarecer”.
Isso provou ser uma boa maneira de lidar com diferentes opiniões, mas demorou
mais que o necessário. O grupo atingiu um bom resultado, mas com uma ajuda
extra ele poderia ter atingido o consenso mais rapidamente.
Todos os integrante do grupo 5 disponibilizaram seus códigos sem uma
discussão anterior, o que indica ser resultado de uma conversa presencial.
Aparentemente, a partir do fragmento abaixo, o fórum só foi utilizado para
convocar os integrantes a participarem de um chat.
StRi Nós estamos elaborando o relatório de todas as
funções que vcs fizeram. Eu e a StKeyu precisamos
que vcs entrem na sessão do chat que foi criada
pradiscutiros isso. qui pelo fórum demora muito.
http://colabweb.ufam.edu.br/moodle/mod/chat/view.
php?id=6
chamar
atenção
O grupo 6 não discutiu sobre o entendimento do exercício, mantendo a
conversa restrita a dois integrantes e somente acerca do último item do exercício.
O grupo 7 seguiu um pouco a estrutura de alternância de turnos das
conversas dos grupos 2 e 3. Um aluno liderou a conversa disponibilizando seu
código e perguntando sobre a distribuição das partes aos integrantes do grupo.
Outro aluno alocou os alunos as partes do exercício e pediu que todos
disponibilizassem seus códigos assim que fosse possível juntamente com sua
respectiva explicação. Todos os integrantes seguiram a sugestão. Um terceiro
integrante leu todos os códigos, encontrando um erro e identificando sua possível
causa. Algo que merece atenção é que ao final da conversa um aluno destacou que
101
ele não tinha feito sua parte, mas não precisava de ajuda. Somente no ultimo turno
da conversa ele disponibilizou seu código.
Inicialmente, o grupo 8 discutiu sobre o entendimento do exercício. Um
integrante concordou com a sugestão de outro integrante e todos continuaram
reutilizando as funções uns dos outros, em alternância com outros padrões de
interação. O grupo permaneceu colaborando exceto por um integrante. Que não
participou da conversa. A partir do fragmento abaixo, está claro que ele fez a parte
dele sem considerar ou reutilizar as funções de seus pares.
StFlamo Eu fiz a quinta questão. Como eu não sei funções feitas das questões anteriores ela ficou um pouco grande, mas,basicamente ela possui as mesmas funções já feitas até o exercício quatro.
doutor xs = [a|(a,b,c)<-xs]
funcao xs = [b|(a,b,c)<-xs]
senha xs = [c|(a,b,c)<-xs]
...
explicar
disponibilizar
Muitos padrões de interação do tipo “perguntar” ocorreram nessa
conversa, o que é incomum comparando-se com as outras conversas de fórum
relativas a essa turma. No entanto, também ocorreram muitos padrões do tipo
“disponibilizar” e “explicar” em alternância com “perguntar”, o que se
caracterizou como um estereótipo positivo.
O grupo 9 apresentou um estereótipo negativo semelhante ao do grupo 1,
mas sem nenhuma conversa. Todos disponibilizaram seus códigos e um aluno foi
responsável por testar a solução do grupo.
A maneira com que cada grupo trabalhou no seu primeiro exercício que
exigiu um grau maior de colaboração evidencia causas de dificuldades específicas
nas atividades que requerem muita troca de idéias e também utilizações bem
sucedidas de métodos informais de colaboração.
No 2o. exercício, a maioria dos grupos tentaram colaborar e se comportar
como um grupo, embora eles não tenham atingido o “nirvana” da programação em
grupo, ou seja, eles tentaram mas não conseguiram plenamente os objetivos uma
102
vez que não discutiram as abordagens uns dos outros para o exercício. Os
fragmentos de código eram em sua maioria soluções individuais. Entretanto, o
registro dos exercícios do grupo mostrou-se um recurso muito útil uma vez que
deixam claro ao professor como identificar cada dificuldade do grupo, ajudando-o
a intervir sempre que achar necessários, preparando-o par o próximo exercício.
Outros grupos, mais especificamente grupos 2 e 4, desenvolveram seus
trabalhos sem qualquer dificuldade. O grupo 4 até usou um novo método para a
solução do problema, resultado acima das expectativas naquele ponto. Os grupos
1 e 9 ignoraram completamente o fato que era esperado que eles fizessem os
exercícios como um grupo. Apenas o grupo 10 não concluiu o exercício.
A Tabela 5.1 apresenta os padrões de interação e um exemplo para cada um
deles, conforme encontrados nos logs das conversas. A identificação desses
padrões fornece uma idéia geral sobre o funcionamento dos grupos. A partir
dessas categorias o corpo das mensagens é analisado mais detalhadamente,
possibilitando identificar o funcionamento dos grupos, quanto à participação de
seus membros e natureza das discussões, mas ainda não sendo possível saber
sobre a profundidade dessas discussões.
Tabela 5.1 – Tipos e exemplos de padrões de interação
Categoria Exemplo
Disponibilização de artefato “Minha funções…”
Informe “Pessoal, o problema não é tão difícil…”
Clarificação “Eu não pude logar antes.”
Confirmação “Eu já anotei isso…”
Pergunta “Alguém mais quer incluir alguma coisa no relatório?”
Sugestão “…todos deveriam tentar criar uma solução pra cada questão do seu próprio jeito…”
Chamada de atenção “Ei, Galera! Vamos fazer o exercício!”
Identificação de erro “Eu acho que vc cometeu um erro quando definiu o tipo int como saída...”
Explicação “…o que eu fiz foi usar a 2ª. Questão que…”
103
Utilizando esses padrões, é possível identificar grupos que produzem
discussões mais profundas, utilizando atos de fala alternados e os que não
discutem de fato, utilizando muitos atos de fala do tipo “disponibilização de
artefato”, sem serem intercalados com outros. Esse aprofundamento da análise e a
respectiva definição de “estereótipos” no surgimento dos padrões são discutidos a
seguir.
5.1.3. Análise Parte 2 – Usando os padrões na caracterização das Interações
Para o exercício “Campeonato de Futebol”, descrito no Quadro 5.1, todos os
grupos deveriam entregar sua solução final, juntamente com o registro de
participação no fórum do ColabWeb. Os logs originais podem ser encontrados em
colabweb.ufam.edu.br. Em seguida mostramos a análise dos logs de cada grupo,
com seus padrões de interação. A quantidade de interações não corresponde
exatamente à quantidade de interações nos logs, pois quando a fala seguinte do
mesmo indivíduo era a continuação da anterior, foi registrada apenas uma.
Dos grupos formados, os grupos 3, 4 e 6 não utilizaram o fórum.
Apresentamos os padrões de interações, comparando de dois em dois grupos,
emparelhados pelo tamanho dos logs. Os destaques mostram o que consideramos
serem interações produtivas.
A Tabela 5.2 mostra a análise das interações dos grupos 1 e 2. Ambos os
logs foram curtos, indicando uma superficialidade na discussão. O grupo 1 possui
rudimentos de discussão sobre um aspecto do código. O grupo 2 não conversou
muito. Apesar de alternar poucos turnos, o grupo discutiu bem mais que o
primeiro, uma vez que em alguns turnos os alunos utilizam aprofundam mais as
discussões, utilizando mais de um padrão de interação. A alternância de padrões
‘explicar’, ‘esclarecer’ e ‘sugerir’ com ‘disponibilizar’ são indícios de interação
produtiva.
Tabela 5.2 – Padrões de Interação para a Fase 3 dos Grupos 1 e 2
Grupo 1 Grupo 2
StAf disponibilizar
StDi sugerir / disponibilizar
104
StAt disponibilizar
StHu esclarecer / explicar
StAl explicar
StDi re-explicar-StHu / disponibilizar / explicar
StAt re-explicar-Al
StHu esclarecer / disponibilizar
StAl esclarecer
StDi sugerir
StAt sugerir
StKa esclarecer / disponibilizar
StAl informar
StJofi informar
StGe disponibilizar
StDi informar
StDi explicar / disponibilizar
StDi perguntar
StJofi informar
StKa confirmar
A Tabela 5.3 apresenta a análise para os grupos 3 e 5, embora haja uma
diferença muito grande na quantidade de alternância de turnos. O grupo 3
apresentou um log extenso, podendo indicar uma participação ativa de todos.
Analisando mais a fundo as conversas, percebe-se que o grupo não discutiu muito
para escolher uma solução. Incentivados por uma aluna, o grupo conseguiu
convergir e escolher finalizar o exercício, embora a quantidade de alternância de
turnos seja o esforço dessa aluna para retomar as discussões. Já o grupo 5
apresenta uma alternância de turnos esperada para o exercício, com destaque para
os padrões ‘explicar’ e suas continuações.
Tabela 5.3 – Padrões de Interação para a Fase 3 dos Grupos 3 e 5
Grupo 3 Grupo 5
StEmra informar StRibe explicar /
105
disponibilizar
StFla informar StDiso explicar /
disponibilizar
StVi informar StKeyu explicar /
disponibilizar
StEmra perguntar StRibe perguntar
StJu re-pergutar-StEmra /
sugerir / perguntar
StDa explicar /
disponibilizar
StFla re-perguntar-StJu StRibe perguntar
StJu perguntar StRibe explicar
StVi re-perguntar-StJu StDa re-explicar-StRibe
StEmra re-perguntar-StJu /
esclarecer
StJo re-explicar-StRibe
StVi explicar / perguntar StRibe explicar2
StEmra re-perguntar-StVi StJo re-explicar2-
StRibe
StFla re-perguntar-StVi StJo disponibilizar /
explicar
StVi sugerir StKeyu explicar /
disponibilizar
StEmra re-sugerir-StVi StJo re-explicar-
StKeyu
StVi Confirmar StRibe re-explicar-
StKeyu
StEmra re-confirmar-StVi StDa re-explicar-
StKeyu
StEmra Perguntar
StVi re-confirmar-StVi
StJu re-confirmar-StVi /
perguntar
StVi re-perguntar-StJu
StEmra perguntar
StFla informar
106
StVi re-informar-StFla
StEmra re-informar-StFla
StVi re-informar-StFla /
perguntar
StFla informar
StThi perguntar
StEmra re-perguntar-StVi /
perguntar /
disponibilizar
StFla re-disponibilizar-
StEmra
StEmra re-disponibilizar-
StEmra
StJu informar
StThi perguntar
StJe esclarecer
StFla re-esclarecer-StJe
StVi re-esclarecer-StJe
StThi re-esclarecer-StJe
StFla re-esclarecer-StJe
StVi perguntar
StEmra re-esclarecer-StJe
StFla re-perguntar-StVi
StVi re-esclarecer-StJe
StJe informar
StVi re-informar-StJe
StFla re-informar-StJe
StThi perguntar
StVi re-informar-StJe
StVi informar
StJe informar
StThi informar
StJu informar
107
StEmra informar
StFla informar
A Tabela 5.4 mostra a análise das interações dos grupos 7 e 8. O grupo 9
não faz parte da comparação porque não achamos relevante representar apenas
dois turnos com padrão ‘disponibilizar’. O grupo 7 discute pouco sobre o código,
o que pode ser percebido pela ausência do padrão disponibilizar em alternância
com explicar. Já o grupo 8 começa bem a discussão, alternando os padrões, mas
continua em sessão de chat, o que inviabiliza esta classificação.
Tabela 5.4 – Padrões de Interação para a Fase 3 dos Grupos 7 e 8
Grupo 7 Grupo 8
StCri chamar atenção StDanpe perguntar /
disponibilizar
StPat Perguntar StFlamo informar
StAnt disponibilizar StWil re-informar-Flamo
StCri re-disponibilizar-StAnt StCrys disponibilizar
StAnt Esclarecer StMan explicar /
disponibilizar
StCri re-esclarecer-StAnt StDanpe sugerir
StAnt Explicar StCrys re-sugerir-
StDanpe /
disponibilizar
StCri re-explicar-StAnt StCrys explicar /
disponibilizar
StPat Sugerir StWil Disponibilizar
StFlamo re-disponibilizar-
StCrys
Continuou em sessão de chat
No exercício “Atendimento em Ambulatório”, descrito no Quadro 5.2, os
grupos apresentam logs mais diversificados, indicando no geral um maior
envolvimento com a atividade. Os grupos que mais se destacam são o 2 e o 8, que
apresentam logs mais extensos, com mais alternância de turnos, sugerindo um
108
caminho progressivo até a solução. Surpreendentemente, o grupo 3, que
apresentou um log extenso no exercício passado, apresenta contribuições
modestas neste exercício.
Na Tabela 5.5 é mostrada a análise para os grupos 1 e 5, por apresentarem
sequências de padrões de interação semelhantes, com ocorrência predominante do
padrão disponibilizar, quase sem alternância de outros padrões. Destacamos
somente os turnos com padrões de interação diferentes de disponibilizar.
Tabela 5.5 – Padrões de Interação do 2º.Exercício da Fase 5, dos Grupos 1 e 5
Grupo 1 Grupo 5
StAf disponibilizar StJo disponibilizar
StAl disponibilizar StDiso disponibilizar
StAf disponibilizar StDiso disponibilizar
StAl esclarecer StDiso disponibilizar
StAl disponibilizar StRibe disponibilizar
StAt confirmar StKeyu disponibilizar
StAt disponibilizar StRibe chamar atenção
StAt disponibilizar StDa disponibilizar
StAt disponibilizar StKeyu disponibilizar
A Tabela 5.6 mostra a análise para os grupos 3 e 4. Os logs desses grupos
indicam que fizeram tentativas de discussão. Analisando mais detalhadamente o
conteúdo das mensagens representadas nos padrões de interação, percebemos que
eles não discutiram o suficiente para a produção do relatório final, o que é
confirmado pela correção do exercício pelo professor, que atribuiu um conceito
mediano a esses grupos. O grupo 3 mostra uma pequena melhora na maneira
como conduz a conversa. No exercício anterior uma aluna ficava sempre
instigando o grupo e provocando respostas, nem sempre espontâneas. Neste
exercício, o grupo alterna mais os papéis, alternando também outros padrões com
o padrão de interação disponibilizar (em destaque). Já o grupo 4, apesar de possuir
uma boa alternância de turnos e padrões de interação não utilizar disponibilizar,
indicando que não compartilhou códigos. Destacamos os padrões sugerir,
indicando que estão tentando produzir códigos que parecem terem sido
compartilhados off-line.
109
Tabela 5.6 – Padrões de Interação do 2º.Exercício da Fase 5, dos Grupos 3 e 4
Grupo 3 Grupo 4
StJu disponibilizar StRobo perguntar
StEmra disponibilizar StRobo explicar
StJu informar /
disponibilizar /
explicar
StJa sugerir
StThi disponibilizar StLuvi re-sugerir-StJa
StThi disponibilizar StRoma sugerir
StJe disponibilizar StRoma chamar atenção
StVi disponibilizar /
perguntar
StJa sugerir
StFla disponibilizar /
explicar
StJuma perguntar
StVi re-disponibilizar-
StFla
StJeca re-perguntar-
StJuma
StJu informar StLuvi re-perguntar-
StJuma /
perguntar
StEmra disponibilizar
StVi informar
StFla disponibilizar /
explicar
StJu confirmar
StFla disponibilizar
Optamos por mostrar a análise referente ao grupo 7 separadamente, pois os
padrões de interação são diversificados, aparecendo também por duas vezes
apontar um erro, seguido de respostas. A Tabela 5.7 mostra esses padrões de
interação.
110
Tabela 5.7 – Padrões de Interação do 2º. Exercício para a Fase 5, do Grupo 7
Grupo 7
StDan chamar atenção
StDan disponibilizar / explicar
StAnt sugerir
StAnt disponibilizar / explicar
StAnt disponibilizar / explicar
StDan disponibilizar / explicar
StPat disponibilizar / explicar
StPat apontar um erro / explicar /
disponibilizar
StPat perguntar
StCri explicar
StAnt confirmar / informar
StCri informar
StCri Disponibilizar
StAnt apontar um erro
StCri re-apontar um erro-StAnt
A Tabela 5.8 mostra a análise para os grupos 6 e 9. No grupo 6 somente
dois alunos trocam idéias. São apenas quatro turnos de conversa, aparentemente
realizadas para completar a atividade, sem discussões sobre os códigos. O grupo 9
também não discute sobre o problema, o que é indicado por sequências de
disponibilizar com poucas alternâncias de outros padrões de interação.
Tabela 5.8 – Padrões de Interação do 2º. Exercício para a Fase 5, dos Grupos
6 e 9
Grupo 6 Grupo 9
StCarg chamar atenção StLu explicar
StPauce re-chamar atenção /
perguntar
StLu disponibilizar
StCarg re-perguntar StLu disponibilizar
StPauce disponibilizar StCarf esclarecer
111
StCarf explicar /
disponibilizar
StCarf explicar
StSam disponibilizar
StDani disponibilizar
StCarf disponibilizar
StCarf disponibilizar
Os grupos 2 e 8, neste exercício, foram apontados pelo professor como os
que desempenharam bem todas as etapas, desde as discussões preliminares até a
codificação em si, expressa no relatório. A Tabela 5.9 mostra a análise desses
grupos. No grupo 2, a sequência de utilização dos padrões de interação é boa, pois
o uso de vários padrões em alternância indica que a conversa flui, convergindo no
final. Destacamos a sequência final, onde são apontados erros em alguns códigos
e corrigidos, porque exprime convergência. O grupo 8 também apresenta uma boa
alternância, indicando fluidez na conversa. Destacamos uma sequência de padrão
“apontar um erro”, com resposta e posterior “disponibilizar” corrigido.
Tabela 5.9 – Padrões de Interação do 2º. Exercício para a Fase 5, dos Grupos
2 e 8
Grupo 2 Grupo 8
StDi perguntar StDanpe perguntar
StBra perguntar StCrys perguntar
StDi disponibilizar /
re-perguntar-StBra
StDanpe disponibilizar
StDio confirmar StCrys re-perguntar-
StDanpe
StDi sugerir StDanpe explicar
StDio informar StCrys re-explicar-
StDanpe
StHu disponibilizar /
informar
StWil disponibilizar / re-
perguntar-
StDanpe
112
StDi chamar atenção StDanpe perguntar /
apontar um erro
StJofi esclarecer StWil perguntar
StDio disponibilizar StBru informar /
perguntar
StDi disponibilizar StCrys re-perguntar-
StBru
StHu disponibilizar StBru disponibilizar
StDio disponibilizar StDanpe re-perguntar-
StBru
StBra disponibilizar StWil re-apontar um
erro-StDanpe
StHu esclarecer StDar disponibilizar
StBra re-esclarecer-StHu StBru disponibilizar
StHu esclarecer StFlamo disponibilizar /
explicar
StHu disponibilizar /
perguntar
StMan disponibilizar /
explicar
StBra disponibilizar StMan esclarecer
StHu perguntar StMan informar
StBra re-perguntar-StHu /
confirmar
StWil disponibilizar
StHu re-confirmar-StBra
StDi informar
StKa disponibilizar
StDi informar
StKa disponibilizar
StDio informar
StDi apontar um erro
StJofi disponibilizar
StDio informar
StDi apontar um erro
StKa re-apontar um erro-
113
StDi / esclarecer
StDi informar
StJofi perguntar
StDi informar
Neste exercício, pela primeira vez na disciplina, os alunos precisaram
construir uma solução única a partir de partes desenvolvidas individualmente.
Esperávamos que os grupos tivessem dificuldades no momento de juntar as partes,
pois o estilo de programação de cada um e a solução, se não for discutida no
grupo, pode ser bem diferente e difícil de encaixar com as demais. Mesmo os
grupos que possuem pouco registro de discussão conseguiram elaborar uma
solução. Podemos perceber que o grupo 6, por exemplo, não discute nada.
Observando os logs dos integrantes do grupo constatamos que a solução é de
somente um aluno. Com exceção deste grupo, todos procuraram cumprir o
exercício, reaproveitando as funções já criadas por algum integrante.
O exercício seguinte não teve muitas modificações quanto à utilização dos
padrões de interação. Sua análise está no Apêndice A.
5.2. Representando Padrões de Interação
Estereótipos são combinações de diferentes padrões de interação. Alguns
desses estereótipos já foram identificados como positivos ou negativos e são
apresentados na Seção 5.3. Estereótipos positivos são aqueles que normalmente
conduzem a um bem-sucedido esforço colaborativo de codificação, enquanto os
estereótipos negativos são aqueles que não indicam esforço colaborativo,
eventualmente expressando o código de um único membro ou um código
incorreto.
Entretanto, estereótipos não emergem facilmente nos logs de conversas.
Duas razões principais para isso são a ocorrência de quebras na conversação que
não são adequadamente restauradas numa discussão on-line e a complexidade do
diálogo natural. Assim, uma representação estruturada para a discussão poderia
ser benéfica. Uma forma de tratar o problema de definir, casar e tratar com
estereótipos detectados dentro dos logs de diálogos baseados no fórum é utilizar
uma linguagem de representação formal com boa dose de expressividade.
comu
padrõ
2004
deno
coord
simp
recur
inicia
intera
de in
mens
mens
avali
ilustr
Escla
1 a(c
Uma lin
unicação em
ões de inte
4) é uma no
ominada Op
denação.
Apesar
plicidade ne
rsos de infer
Tipicam
ar um tópic
ação. O inic
nteração. Em
sagem para
sagem algu
iador envian
A seguir
rados na Fig
arecer (Clar
clarifier,C) :
nguagem b
m ambiente
eração. O L
otação já u
pen Knowled
de ser um
ecessária pa
rência prov
ente, cada
co com um
ciador autom
m seguida
a todos os
uém resolve
ndo a mensa
Figura 5.
r apresentam
gura 5.1 ap
rifying).
::=
baseada na
es multiage
LCC (Ligh
utilizada em
dge (www.o
a linguagem
ara represen
vidos pela pl
processo in
ma mensage
maticament
um agente
demais insc
er respondê-
agem de vo
1 – Repres
mos um fra
arecem esta
a lógica p
ente foi ent
htweight Co
m diferentes
openk.org)
m bastante
ntar adequad
lataforma O
nicia por u
em, dispara
te torna-se o
virtual cha
critos na c
-la, a pesso
lta ao coord
sentação Fo
agmento de
ando instan
pra tratar
tão adotada
oordinate C
s aplicações
que ajuda a
e expressiva
damente as
Open Knowl
um membro
ando desse
o coordenad
amado “bro
onversa. Ca
oa torna-se
denador via
ormal das C
código LC
nciado para
com proto
a para repr
Calculus) (R
s sob uma p
a tratar o pr
a, o LCC
interações
ledge.
o do grupo
modo um
dor para aqu
oadcaster”
aso após a
automatica
broadcaste
Conversas
C, onde os
o padrão de
114
tocolos de
resentar os
Robertson,
plataforma
roblema de
mantém a
através de
decidindo
padrão de
uele padrão
distribui a
leitura da
amente um
er.
elementos
e interação
115
2 a(broadcaster(X,L,Er),B) <-- new_clarification(X,L).
3 a(broadcaster(X,L,Er),B) ::=
4 (information(X) => a(reader,R) <-- L=[R|Rs] then
5 Er=[E|Es] <-- evaluation(X,E) <= a(reader,R) then
6 a(broadcaster(X,Rs,Es),B)) or
7 null <-- L=[] and E=[].
8 a(reader,R) ::=
9 information(X) <= a(broadcaster(X,_,_),B) then
10 (evaluation(X,E) => a(broadcaster(X,_,_),B) <-- agree(X,E) or
11 evaluation(X,E) => a(broadcaster(X,_,_),B) <-- do_query(X,E)).
O padrão de interação Esclarecer requer três papéis: clarifier
(esclarecedor), que é quem inicia a interação; broadcaster (propagador), que é
quem envia a mensagem a todos os inscritos na interação e reader (leitor), que é
quem lê a mensagem e pode tornar-se avaliador, respondendo à clarificação.
Nesse caso, os complementos do padrão de interação são as linhas 10 e 11.
Esse fragmento de código pode ser lido como segue:
1. a(clarifier,C)::=. Uma declaração associando o papel esclarecedor a uma
instância ‘C’. O ‘::=’ significa que a definição do papel inicia após essa cadeia
(lado esquerdo).
2. a(broadcaster(X,L,Er),B) <-- new_clarification(X,L). Uma declaração
associando outro papel instanciado por ‘B’, que, dados uma cadeia ‘X’, uma lista
de leitores ‘L’ e avaliadores ‘Er’, propaga a mensagem para cada agente inscrito
na interação caso exista uma nova mensagem a receber, representada por
‘new_clarification(X,L)’.
3. a(broadcaster(X,L,Er),B) ::=. Associa o papel de propagador a uma instância
‘B’ e depois a sua definição é iniciada.
4. (information(X) => a(reader,R) <-- L=[R|Rs] then. Envia a informação ‘X’ a
um leitor caso existam leitores na lista ‘L’.
5. Er=[E|Es] <-- evaluation(X,E) <= a(reader,R) then. Constrói uma lista de
avaliadores ‘Er’ se um leitor ‘R’ envia uma avaliação ‘E’ referente à informação
‘X’.
6. a(broadcaster(X,Rs,Es),B)) or. Chama novamente o propagador para os
próximos leitores ‘Rs’ e avaliadores ‘Es’.
116
7. null <-- L=[] and E=[]. Esta declaração associa o valor ‘null’ enquanto não
houverem leitores ou avaliadores nas listas ‘L’ and ‘E’.
8. a(reader,R) ::=. Similar aos esclarecedores, esta declaração associa o papel de
leitor a uma instância ‘R’.
9. information(X) <= a(broadcaster(X,_,_),B) then. A informação ‘X’ é recebida
do propagador ‘B’.
10. evaluation(X,E) => a(broadcaster(X,_,_),B) <-- agree(X,E) or. A declaração é
válida se o leitor concorda com a informação ‘X’, enviando uma sentença curta de
concordância.
11. evaluation(X,E) => a(broadcaster(X,_,_),B) <-- do_query(X,E)). Se a
declaração anterior não for verdadeira, o leitor não concorda com a informação
‘X’ e ele envia uma consulta ‘do_query’ contendo sua avaliação ‘E’,
possivelmente também uma consulta.
Outros padrões de interação requerem diferentes complementos. Há casos,
tais como “Informar” que requer mais que um tipo de resposta. Entretanto, há
casos como em “Disponibilizar” que não necessariamente possuem qualquer
complemento. As representações em LCC de todos os padrões de interação podem
ser examinadas no Apêndice B.
O professor analisa os padrões de interação apresentados por cada grupo e
define qual sequência ele considera bem sucedida como um estereótipo. Uma base
de conhecimento é então criada para cada exercício compreendendo o log de
conversas do grupo, padrões de interação e estereótipos. Sempre que um
estereótipo não identificado surgir durante uma conversa no fórum, o professor
deve analisar em profundidade e dar feedback ao grupo antes que a tarefa seja
concluída. Ele pode precisar incluir novos estereótipos na base de conhecimento.
Na próxima seção discute-se como estereótipos que emergiram dos logs de
discussões no fórum de modo a intervir adequadamente quando fizer uso do
esquema progressivo para aprendizagem de programação em grupo.
5.3. Identificando Oportunidades de Intervir
Para saber quando intervir, os professores deveriam sempre: (a) identificar
os estudantes que não estão correspondendo à participação esperada nos próprios
117
grupos, o que implica que os alunos encontraram dificuldades em executar a tarefa
solicitada; (b) identificar os estereótipos negativos, buscando ajudar os alunos
sempre que eles estiverem “bloqueados”. As observações do professor devem
focar em: o relacionamento entre padrões de interação apresentados na Tabela 5.1,
o esquema progressivo de aprendizagem de programação usado como suporte
para os exercícios apresentados durante o curso introdutório, os papéis que os
alunos desempenham dentro de seus grupos e a identificação de estereótipos que
servem guia para as intervenções do professor.
As pistas para intervenção emergem sempre que: (i) um padrão de
interação aparece repetitivamente numa discussão no fórum; (ii) somente um ou
dois membros do grupo se mantêm trabalhando, mesmo se estiverem usando
diferentes padrões de interação e (iii) a combinação de padrões de interação
reforçar estereótipos negativos. A Tabela 5.10 descreve as pistas extraídas das
discussões no fórum para o primeiro caso (i) ilustrando a intervenção
correspondente.
Tabela 5.10 – Estereótipo “repetição de padrões de interação” (caso i)
Padrão de Interação Pista Intervenção
Making an Artifact
Available
Não há alternância nas
interações
Solicitar aos membros do
grupo inspecionar os
códigos dos colegas
Informing Perda de tempo com
questões irrelevantes
Solicitar aos membros do
grupo que reiniciem a
discussão
Asking Ausência de liderança Solicitar aos membros do
grupo que escolham um
líder
No caso (ii), quando apenas um ou dois membros do grupo trabalham, as
pistas para intervenção surgem ao detectar-se que um par de emissores dominam
as discussões no fórum.
118
No caso (iii), quando a combinação de padrões de interação não conduzem
à colaboração, membros do grupo provavelmente estão em um caminho
equivocado devido a um estereótipo negativo. A Tabela 5.11 descreve as pistas
extraídas do fórum para o caso (iii), mostrando as intervenções correspondentes.
Tabela 5.11 – Pistas para intervir nos estereótipos do caso (iii)
Estereótipo Pista Intervenção
Asking, Calling Attention
and Suggesting
Quando esse estereótipo surge antes
de um ‘Making an Artifact Available’
ou entra em ciclo por
aproximadamente 10 vezes, o grupo
não está conseguindo entender a
tarefa.
Solicitar aos membros do grupo
que dividam a tarefa como
recomendado.
Informing, Clarifying Eles têm dificuldade em focalizar no
exercício, de modo que não estão de
fato resolvendo-o. Ao invés disso,
eles falam sobre algo com pouca
relevância ou outro assunto não
relacionado.
Solicitar aos membros do grupo
que escolham o que seja
relevante para a conclusão da
tarefa e manter o foco no
processo de desenvolvimento.
5.4. Usando a Sistematização – Estudo de Caso Explanatório
Esse estudo de caso foi desenvolvido no primeiro semestre de 2009 com uma
turma de 60 alunos de alunos calouros do curso de Engenharia da Computação da
UFAM. Finalizamos a proposta de sistematização da abordagem para
aprendizagem de programação em grupo a partir de dados e informações gerados
a partir do estudo de caso anterior, aplicado com a turma de alunos calouros do
curso de Ciência da Computação de 2008. Era necessário verificar se os padrões
de interação e os estereótipos se aplicavam a outra turma com características
semelhantes para que fosse válido afirmar a abordagem para programação em
grupo era viável e poderia ser replicável.
119
Pela experiência do estudo de caso de 2008 e outras experiências de
professores de outras edições da disciplina sabíamos que as turmas de calouros de
Engenharia da Computação progrediam mais lentamente que as de Ciência da
Computação. Tendo isso em vista, foi necessário garantir que fatores externos à
abordagem, como o preparo do laboratório e utilização de ferramentas extras,
como o AAEP não desmotivariam os alunos. A utilização do AAEP foi
completamente retirada do plano de curso da disciplina e o laboratório foi
configurado para utilizar o ColabWeb e interpretador HUGS.
Esse segundo estudo de caso utilizou a mesma descrição e sequência de
atividades que o primeiro, utilizando o esquema progressivo de aprendizagem de
programação como um macro-script para incentivar a interações dos alunos.
Ainda que pudéssemos não atingir todas as etapas do esquema, o plano foi
mostrado aos alunos tal qual estava para a turma anterior. Como utilizamos os
padrões de interação como categorias de análise e procuramos explicar porque as
oportunidades de intervenção são ampliadas, indicando os momentos em que
deveriam ocorrer, esse estudo se caracteriza como um estudo de caso
explanatório, segundo definição em (Yin, 2010).
Conforme havíamos antecipado, a turma progrediu mais lentamente que a
do ano anterior. Foi necessário então intercalar os exercícios planejados com mais
exercícios adicionais que na turma anterior, atrasando o cronograma de aplicação
do esquema progressivo de aprendizagem de programação em grupo. Sendo
assim, a turma não atingiu o terceiro exercício da fase 5, Codificação em Grupo II,
com divisão do trabalho realizada pelo grupo. Como analisamos três exercícios no
estudo de caso anterior, referentes à fase 5, conseguimos comparar com os
mesmos exercícios referentes à mesma fase nesse estudo de caso. O que não
inviabilizou a validação dos padrões de interação e estereótipos.
O primeiro exercício, “Campeonato de Futebol”, apresentou...
Os grupos 1 e 7 não registraram nenhuma interação e o grupo 4 somente
fez uma pergunta para os outros integrantes do grupo que decidiram permanecer
calados. Um estereótipo que trate a ausência de interações, se aplicado nesses
grupos, alertaria o professor sobre a inatividade e ele poderia invocar esses grupos
à participação.
Os grupos 2 e 5 apresentam necessidades opostas, mas que causaram
interações improdutivas. O grupo 2, conforme destaque na Tabela 5.12, apresenta
120
logo de início duas sequências do padrão de interação “perguntar”, seguido de
confirmar, sem co-utilização de “disponibilizar”. Diz o estereótipo que nesse caso
o professor precisa intervir tentando resolver possíveis dúvidas de entendimento
do exercício. O grupo 5 alterna um pouco os padrões de interação no início e
apresenta em seguida quatro entradas do tipo “disponibilizar”, sem alternância
com outros padrões, o que indica que o grupo não discute sobre as soluções
individuais.
Tabela 5.12 – Padrões de Interação do 1º. Exercício para a Fase 5 dos Grupos
2 e 5 de 2009
Grupo 2 Grupo 5
StJo perguntar StAlma perguntar
StRa re-perguntar-StJo StSato explicar
StBar perguntar StGui sugerir
StRa re-perguntar-StBar StFlato sugerir
StBar confirmar StFe informar
StBar informar StSato disponibilizar
StBar esclarecer StPau disponibilizar
StPau disponibilizar
StPau disponibilizar
StPau disponibilizar
Conforme mostrado na Tabela 5.13, o grupo 6 apresenta duas sequências
do padrão de interação “perguntar”. Em seguida aparece o padrão “sugerir”,
divergindo do mau estereótipo apresentado pelo grupo 2. Apesar de só haver uma
ocorrência do padrão “disponibilizar”, sugerindo que os integrantes do grupo
tiveram acesso aos códigos de outra forma, há outro padrão “sugerir”, indicando
uma escolha da solução do grupo. Considerando que nessa fase os alunos
resolvem o exercício individualmente e escolhem a solução para representar o
grupo, a falta de alternância com o padrão “disponibilizar” não é um problema.
Tabela 5.13 – Padrões de Interação do 1º. Exercício para a Fase 5 do Grupo 6
de 2009
Grupo 6
121
StDan perguntar / sugerir
StHife re-perguntar-StDan
StGer re-perguntar-StDan
StHife perguntar
StGer re-perguntarStHife
StDar re-perguntarStHife
StHife sugerir
StTay re-perguntarStHife
StDar sugerir
StDan explicar /
disponibilizar
StHife informar
Finalmente, o grupo 3 não apresenta nenhum estereótipo negativo. Em
determinado momento da discussão, mais ou menos na metade, o grupo
disponibiliza trechos de um chat que alega ter utilizado para discutir mais
dinamicamente sobre o entendimento do exercício. Esse trecho, que não pode ser
analisado por este método, não prejudica a análise da conversa, pois o grupo
apresenta uma alternância exemplar de padrões de interação, com vários bons
estereótipos. Isso pode ser visto na Tabela 5.14.
Tabela 5.14 – Padrões de Interação do 1º. Exercício para a Fase 5 do Grupo 3
de 2009
Grupo 3
StMasi Informar
StKema re-informar-StMasi
StKema disponibilizar / sugerir
StHata re-sugerir-StKema
StFer Disponibilizar
StKema re-disponibilizar-StFer
StKema disponibilizar /
explicar
StFer re-explicar-StKema /
122
explicar
StPaure esclarecer
StPaure disponibilizar
StKema re-esclarecer-StPaure /
informar
StHe informar
Sessão de chat...
StKema perguntar
StFer re-perguntar-StKema
StKema confirmar
StFer re-confirmar-StKema
StKema disponibilizar
StFer perguntar
StKema perguntar
StFer re-perguntar-StKema
StKema explicar
StFer re-explicar-StKema /
disponibilizar
StKema sugerir / disponibilizar
StHata esclarecer
StFer disponibilizar /
explicar
StFer explicar
StKema re-explicar-StFer
StHata informar /
disponibilizar
StKema disponibilizar /
perguntar
StHata perguntar / informar
StKema re-perguntar-StHata
StKema informar
123
O professor responsável pela turma do estudo de caso de 2008 é o mesmo
da turma de 2009. Ele mesmo então identificou os estereótipos no primeiro estudo
de caso. Portanto, na turma de 2009, segundo relato realizado pelo professor, ele
alertou os alunos sobre a ocorrência dos estereótipos negativos que ocorreram
após o primeiro exercício e mostrou exemplos do que ocorreu na turma anterior
que atrapalhou a realização dos exercícios. O resultado foi conversas melhor
estruturadas, somente com a ocorrência de um estereótipo, que não é tão
facilmente identificável, a “ausência de continuação” após a ocorrência de quatro
interações sucessivas.
Como no exercício anterior, três grupos, 1,7 e 8 não registraram nenhuma
conversa. Um integrante do grupo 8 tentou chamar o grupo para participar,
utilizando o padrão de interação “chamar atenção” mas seu grupo não respondeu.
Conforme esperado nessas situações, isto se refletiu em prejuízos na solução do
exercício. Esses grupos não conseguiram concluir o exercício. Os grupos 2, 3, 4 e
5 apresentaram uma boa alternância de padrões de interação, embora ainda tenha
ocorrido o estereótipo de ausência de continuação. A Tabela 5.15 mostra as
conversas dos grupos 2 e 3, enquanto que a Tabela 5.16 mostra as dos grupos 4 e
5, destacando a quinta interação em cada uma, onde o professor poderia intervir
para incentivar mais as conversas.
Tabela 5.15 – Padrões de Interação do 2º. Exercício para a Fase 5 dos Grupos
2 e 3 de 2009
Grupo 2 Grupo 3
StTi perguntar StKema chamar atenção /
sugestão
StBar re-perguntar-StTi /
informar
StHata informar
StTi disponibilizar StFer re-informar-StHata
StTi informar StKema sugerir
StJo disponibilizar StFer perguntar
StJo explicar StKema re-perguntar-StFer
StLepo disponibilizar / explicar StHata re-sugerir-StKema
StBru disponibilizar StKema perguntar
124
StBru explicar StMasi disponibilizar
StBar disponibilizar StKema re-disponibilizar-StMasi
StRa disponibilizar StKema sugerir
StRa disponibilizar StKema disponibilizar
StHata esclarecer
StHata disponibilizar
StKema perguntar
StKema disponibilizar / sugerir
StKema Disponibilizar
Conforme mostra na Tabela 5.16, ocorre o estereótipo de ausência de
continuação logo no começo da conversa. A falta de intervenção pode ser um
forte indício da conversa muito breve e conseqüente dificuldade do grupo em
atingir uma solução adequada.
Tabela 5.16 – Padrões de Interação do 2º. Exercício para a Fase 5 dos Grupos
4 e 5 de 2009
Grupo 4 Grupo 5
StFag informar StGui Perguntar
StRob re-informar-StFag /
perguntar
StGui Informar
StFag re-perguntar-StRob StGui Disponibilizar
StWal informar StFe Informar
StFag disponibilizar StAr Informar
StRob disponibilizar StSato Disponibilizar
StRob disponibilizar StPau Disponibilizar
StFag informar
StWal disponibilizar
StFag informar
StRob re-informar-StFag
StFlaju informar
StWal disponibilizar
StFag informar
125
StLucha disponibilizar
5.5. Conclusão do Capítulo
Neste capítulo tratamos da sistematização de nossa abordagem à aprendizagem de
programação em grupo, focalizando a definição do último elemento estruturante –
os padrões de interação e os estereótipos a eles associados – bem como a
aplicação dos elementos da abordagem em situação real de uso.
A investigação baseou-se em (i) um estudo de caso descritivo cuja
exploração possibilitou a definição dos padrões de interação e a caracterização de
estereótipos da ocorrência desses padrões; (ii) a representação formal desses
padrões de interação e sua implementação em um interpretador do LCC para a
plataforma multiagente Open Knowledge; (iii) um estudo de caso explanatório
onde as oportunidades de intervenção foram evidenciadas, da mesma forma que a
antecipação de possíveis estereótipos negativos pelo professor, resultou em
interações mais produtivas.
Os padrões de interação propostos são inspirados na teoria dos atos de fala
e buscam identificar a intenção dos membros de cada grupo. A ocorrência dos
padrões de interação caracterizam estereótipos positivos e negativos, e a presença
desses últimos ou de estereótipos não classificados expressam oportunidades de
intervenção. Quando incorporado ao esquema progressivo e aos demais elementos
relatados nos capítulos 2 a 4, esses padrões e estereótipos proporcionam ao
professor um conjunto de pontos de inspeção onde ele estará apto a identificar
dificuldades, atuando sobre indivíduos ou grupos sempre que achar necessário.
Esses pontos de inspeção podem ser acompanhados manualmente ou inferidos e
tratados automaticamente com vistas à geração de feedback aos grupos. A adição
de novos estereótipos a um repositório pode estar associada à geração de
heurísticas para a intervenção.
6 Conclusão
Esta tese descreve uma abordagem sistematizada para aprendizagem de
programação. Essa abordagem é fundamentada na teoria do desenvolvimento
cognitivo de Jean Piaget, na utilização de ambientes CSCL para auxiliar no
registro e monitoramento das atividades de aprendizagem guiadas por um
esquema progressivo de aprendizagem de programação em grupo.
Através de três estudos de caso, uma inspeção no ColabWeb, ambiente
CSCL utilizado para a pesquisa desta tese e a representação formal de padrões de
interação provamos a hipótese: Oportunidades de intervenção na
aprendizagem de programação em grupo são ampliadas com o uso de uma
abordagem sistemática de acompanhamento.
A teoria de desenvolvimento cognitivo evidenciada por Piaget é descrita a
partir de experimentações com o método clínico utilizado para avaliar os estágios
de desenvolvimento cognitivo em que os sujeitos se encontram (Piaget &
Inhelder, 1968), (Piaget, 1972), (Piaget, 1978), (Piaget, 1995). A partir da teoria
de Piaget fazemos uma comparação com o desenvolvimento da capacidade de
abstração nos adolescentes, perfil da maioria dos alunos ingressantes nos cursos
de Engenharia da Computação e Ciência da Computação da UFAM, instituição
onde desenvolvemos os estudos de caso desta pesquisa.
Assim como a criança passa por estágios para desenvolver seu pensamento,
entendemos que os adolescentes precisem também passar por estágios no
desenvolvimento de pensamentos mais abstratos como os exigidos em
programação. O problema é que esses processos não estão claros para o professor
nem para os próprios alunos, uma vez que somente se tem acesso aos programas
prontos e as pessoas esquecem facilmente o raciocínio que as levou a chegar a
determinada solução. Sendo assim, desenvolvemos uma ferramenta chamada
AcKnow que procura modificações nas versões dos programas dos alunos
previamente capturadas e armazenadas em um banco de dados. Essas
modificações na evolução dos códigos são classificadas em sintáticas, semânticas
127
e de refactoring. O AcKnow investigou os códigos dos alunos de 2007, após a
disciplina ser encerrada e foi identificado um padrão de muitas modificações
sintáticas seguidas de algumas semânticas intercaladas com sintáticas. Em alguns
casos, houve até modificações de refactoring, o que significa uma boa capacidade
de enxergar a solução e aprimorá-la contemplando as noções da disciplina de
eficiência e legibilidade do código.
Sabemos que o grupo tem um papel importante na aprendizagem para
descobrirmos como os alunos se organizam em grupos e levantarmos as
necessidades desenvolvemos um estudo de caso exploratório aplicado a uma
turma de calouros de Ciência da Computação em 2007. Esse estudo apontou a
falta de organização e de critérios de divisão de tarefas no grupo como uma das
causas da dificuldade dos grupos realizarem o exercício no tempo previsto. Isso
serviu de subsídio para a elaboração de um esquema progressivo de aprendizagem
de programação em grupo
Nesse ponto da pesquisa já sabíamos que exercícios em grupo eram
agradáveis aos alunos, que eles poderiam contribuir mais para a aprendizagem e
como os alunos organizavam seu pensamento na codificação. O próximo passo foi
refletir sobre uma forma de sistematizar a aprendizagem de programação em
grupo, considerando que os alunos não conseguiam se organizar facilmente para
programar. Então foi proposto o esquema progressivo de aprendizagem de
programação em grupo, que atua como um macro-script para colaboração,
introduzindo gradativamente a colaboração nas práticas dos alunos. Antes de
testá-lo planejamos a disciplina de Introdução à Computação de 2008 como um
curso no ambiente CSCL ColabWeb.
Em 2008 o esquema progressivo de aprendizagem de programação em
grupo foi posto em prática com uma turma real de alunos iniciantes em Ciência da
Computação e Engenharia da Computação. A turma de Engenharia da
Computação apresentou dificuldades no acompanhamento do esquema devido a
fatores externos como a configuração do ambiente do curso no ColabWeb e infra-
estrutura do laboratório. Consideramos para análise, por esse motivo, somente a
turma de Ciência da Computação. O esquema progressivo se mostrou eficaz para
a introdução de práticas de colaboração à programação porque estimula os
participantes a refletir sobre o processo de solução de problemas como um grupo,
percebendo a necessidade de interdependência entre os envolvidos.
128
Avaliamos esse ambiente sob a perspectiva do Método de Inspeção
Semiótica proposto por (De Souza, 1995) como um método de inspeção dos
signos metalingüísticos característicos do poder de comunicabilidade do projetista
da interface com o usuário. Mostramos que muitas sugestões de navegabilidade e
visualização da interface herdadas do Moodle não são adequadas para o contexto
de aprendizagem de programação em grupo. Fizemos recomendações de
utilização de padrões de interface que em sua maioria foram acatadas pelo
professor e aplicadas juntamente com o estudo de caso explanatório de 2009.
Para a análise do estudo de caso de 2008 foi realizado uma revisão métodos
para colaboração e em formas de análise de interação e atos de fala. Utilizamos a
forma de categorizar discurso dos atos de fala (Searle, 1969) e criamos padrões de
interação, onde a unidade de análise é uma fala, que pode estar em duas ou mais
entradas desde que faça parte do mesmo pensamento, e suas respostas ou
continuações. Discutimos com o professor da turma de 2008 sobre os momentos
em que ele interveio e, vendo a análise, os momentos que gostaria de intervir se
estivesse ciente dos padrões de interação durante a resolução dos exercícios. A
partir daí elaboramos estereótipos positivos e negativos, os bons sendo aqueles
que promoviam colaboração e os maus os que a atrapalhavam ou não a
incentivavam. Representamos formalmente os padrões de interação e executamos
com as informações do 2º. exercício da fase 5. Os padrões provaram-se
consistentes.
O último estudo de caso, um estudo explanatório, aplicado à turma de
calouros de Engenharia da Computação de 2009 foi desenvolvido seguindo o
mesmo plano do de 2008 com o intuito de comprovar a aplicabilidade dos padrões
de interação e refinar os estereótipos. A análise foi realizada e os padrões de
interação foram facilmente identificados. Alguns estereótipos foram refinados e
outro foi incluído.
6.1. Contribuições
O caminho percorrido para alcançar o objetivo central da investigação –
uma sistematização para aprendizagem de programação em grupo – envolveu a
produção de elementos que acreditamos contribuem para o conhecimento na área.
São eles:
129
1. Uma série de estudos de caso que possibilitam a exploração de vários
aspectos relacionados à aprendizagem de programação, compreendendo
desde a caracterização da construção individual de soluções até a
elicitação de padrões comportamentais de grupos atuando em vários
estágios do processo.
2. A definição de categorias da evolução de códigos dos alunos e o
desenvolvimento de um artefato para gestão do conhecimento em
desenvolvimento de programas.
3. A aplicação da Engenharia Semiótica na análise e reformulação de
interface em software com vários níveis de comunicabilidade entre
designer e usuários em plataforma LMS de uso intensivo.
4. Um esquema progressivo para a aprendizagem de programação em grupo
que induz e apóia os alunos numa transição de trabalho e aprendizagem
essencialmente individual para um estágio colaborativo de atuação.
5. A definição de um conjunto de padrões de interação e a caracterização de
estereótipos da ocorrência desses padrões. Esses elementos foram
formalizados e podem ser integrados a plataformas multiagente de apoio
às atividades dos atores envolvidos na aprendizagem.
6.2. Reflexões Adicionais no Tema
O esquema progressivo de aprendizagem de programação em grupo pode
ser utilizado em qualquer disciplina ou contexto de trabalho em equipe, desde que
a abordagem metodológica utilizada tenha um processo com etapas bem definidas,
como é o caso do processo de solução de problemas de Polya, utilizado nos
estudos de caso aqui relatados.
Não é imprescindível a utilização de um ambiente CSCL para o
acompanhamento das etapas do esquema progressivo. Se o contexto for uma
disciplina de natureza mais discursiva, o ambiente pode ajudar, mas não é
essencial. Nesse caso, o acompanhamento pode ser realizado na sala de aula e pela
análise dos textos produzidos em sala de aula. No contexto de programação, dado
o seu caráter extremamente abstrato, a utilização de um ambiente CSCL, aliado às
técnicas de identificação dos padrões de interação propostas neste trabalho, a
utilização de um ambiente CSCL configurado segundo alguma técnica de
130
avaliação de comunicabilidade, como o MIS é imprescindível. Os padrões de
interação propostos nesta tese se aplicam somente ao contexto de programação em
grupo, embora possam ser reavaliados e estendidos para comportarem outros
contextos.
Os padrões de interação encontrados na análise do estudo de caso
descritivo provaram-se aplicáveis ao contexto de aprendizagem de programação
descrito, um curso introdutório de programação utilizando o paradigma funcional.
Analisando as características das conversas referentes aos exercícios de
programação observamos que eles se aplicam a esses exercícios porque os alunos
possuem uma atividade de resolução de problemas para desenvolver. Portanto, se
a matéria estudada for engenharia de software ou arquitetura de computadores, se
a metodologia utilizada for resolução de problemas, os padrões de interação ainda
serão aplicáveis.
Uma vez utilizados os padrões de interação, os estereótipos definidos
precisam ser dinâmicos, pois dependem do objetivo do professor e características
da turma. Ao aplicar os padrões de interação como mecanismo de análise a um
novo contexto, o professor define a priori alguns estereótipos para ter um ponto de
partida para sua análise. Ao longo da primeira aplicação da análise ele pode
refinar os estereótipos previstos e identificar outros.
Após a primeira aplicação da análise utilizando os padrões de interação e
estereótipos a um novo contexto, se os padrões de interação já estiverem
incorporados a um ambiente CSCL, o professor precisa ter acesso à criação de
novos estereótipos e adaptação dos existentes para outros contextos ao seu.
6.3. Trabalhos Futuros
A seguir listamos alguns desdobramentos ou aprofundamentos da
investigação relatada nesta tese.
Inserir toda sistematização no Open Knowledge, inclusive definindo
assistentes inteligentes para atuar na intervenção.
Aplicar diferentes combinações dos elementos a times de desenvolvimento
de software – com experimentos exploratórios em disciplinas avançadas de
desenvolvimento de software; em empresas start-up ou incubadas; em
empresas com projetos na UFAM.
131
Investigar a incorporação de outras ferramentas nos diversos estágios da
sistematização – por exemplo, de clustering, de análise qualitativa, de
mineração de dados, etc.
Aplicar a sistematização a outros domínios de formação onde a natureza
da atividade envolvendo abstração provoque bloqueios e dificuldades
similares nos alunos.
Aplicar a sistematização no mesmo domínio (aprendizagem de
programação), porém utilizando outro paradigma não imperativo –
programação de jogos, programação visual, sistemas dinâmicos, etc.
6.4. Publicações de Resultados Parciais da Tese
A seguir listamos os relatos de resultados parciais desta tese, apontando
também a contribuição a que se refere conforme os itens na Seção 6.1.
CASTRO, T., FUKS, H., CASTRO, A. & SPÓSITO, M. Integração de
Ferramentas para Acompanhamento da Aprendizagem de Programação.
Anais do XVIII Simpósio Brasileiro de Informática na Educação – SBIE
2007 / Workshop - Ambientes de apoio à aprendizagem de algoritmos e
programação, ISBN 978-85-7669-159-4, São Paulo, SP, 2007.
[1]
CASTRO, T., FUKS, H., SPÓSITO, M. & CASTRO, A. The Analysis of a
Case Study for Group Programming Learning. ICALT - Proc. Of the 8th
IEEE International Conference on Advanced Learning Technologies, July
1-5, 2008, Santander, Spain.
[1]
CASTRO, T., FUKS, H. & CASTRO, A. Detecting Code Evolution in
Programming Learning. In Proceedings of the 19th Brazilian Symposium
on Artificial Intelligence, Salvador, Brazil, October 26-30, 2008, Salvador,
Brazil. Series: Lecture Notes in Computer Science , Vol. 5249. Sublibrary:
Lecture Notes in Artificial Intelligence. ISBN: 978-3-540-88189-6,
pp.145-156.
[2]
132
CASTRO, T., FUKS, H. & CASTRO, A. Programming in Groups: a
Progression Learning Scheme from the Individual to the Group. FIE -
Proc. of the 38th Annual Frontiers in Education Conference, October 22-
25, 2008, Saratoga Springs, New York, USA. IEEE Catalog Number:
CFP08FIE-CDR. ISBN: 978-1-4244-1970-8. Library of Congress: 79-
640810. ISSN: 0190-5848. Pp F1F15-F1F20.
[4]
CASTRO, T., FUKS, H. & CASTRO, A. Aprendendo a Programar em
Grupo. Anais do V Simpósio Brasileiro de Sistemas Colaborativos - SBSC
2008. 27 a 29 Outubro 2008, Vila Velha, ES. ISBN: 978-0-7695-3500-
5/08, Ed. IEEE-CS, pp. 45-54.
[4]
CASTRO, T., FUKS, H., SANTOS, L. & CASTRO, A. Fleshing out Clues
on Group Programming Learning. ICEIS 2009, 11th International
Conference on Enterprise Information Systems, Milan, May 2009. ISBN:
978-989-8111-85-2.
[5]
CASTRO, T. & FUKS, H. Inspeção Semiótica do ColabWeb: Proposta de
Adaptações para o Contexto de Aprendizagem de Programação . Revista
Brasileira de Informática na Educação. Vol.17, N. 1. Pp 71-81. ISSN
1414-5685. 2009
[3]
CASTRO, T., FUKS, H., SPÓSITO, M. & CASTRO, A. Análise de um
Estudo de Caso para Aprendizagem de Programação em Grupo. IEEE-
RITA: Revista Iberoamericana de Tecnologia del Aprendizaje. ISSN:
1932-8540. V.4, N.2, pp. 155-160. 2009.
[1]
Referências
ALMEIDA NETO, F. A. ; CASTRO, T. ; CASTRO, A. N. Utilizando o Método
Clínico Piagetiano para Acompanhar a Aprendizagem de Programação. In:
XVII Simpósio Brasileiro de Informática na Educação, 2006. Brasília:
Gráfica e Editora Positiva Ltda, v. 17. p. 184-193. 2006.
ARAGON, S. R.; JOHNSON, S. D.; SHAIK, N. The influence of learning style
preferences on student success in online vs. face-to-face environments.
American Journal of Distance Education, 16(4), 227-243. 2002
BARAK, M.; LIPSON, A.; LERMAN, S. Wireless Laptops as Means for
Promoting Active Learning in Large Lecture Halls. Journal of Research on
Technology in Education, 38(3), 245-262. 2006.
BECK, K. Extreme Programming Explained: Embrace Change. Addison-Wesley.
Winner of the Jolt Productivity Award. (ISBN 978-0321278654). 1999.
BLOOM, B. S. Taxonomy of educational objectives. New York: David Mckay,
1956. 262 p. (v. 1).
CARLISLE, M. C., WILSON, T. A., HUMPHRIES, J. W.; HADFIELD, S. M.
RAPTOR: Introducing Programming to Non-Majors with Flowcharts.
Consortium for computing sciences for colleges. P52-60. 2004.
CASTRO, T.; FUKS, H.; SPÓSITO, M.; CASTRO, A. The Analysis of a Case
Study for Group Programming Learning. ICALT - Proc. of the 8th IEEE
International Conference on Advanced Learning Technologies, July 1-5,
Santander, Spain. 2008.
CASTRO, T.; FUKS, H.; CASTRO, A. N. Detecting Code Evolution in
Programming Learning. In: 19th Brazilian Symposium on Artificial
Intelligence, 2008, Salvador, Bahia. Lecture Notes in Computer Science /
Lecture Notes in Artificial Intelligence, v. 5249. p. 145-156. 2008b.
CASTRO, T.; FUKS, H. Inspeção Semiótica do ColabWeb: Proposta de
Adaptações para o Contexto de Aprendizagem de Programação . Revista
Brasileira de Informática na Educação. Vol.17, N. 1. Pp 71-81. ISSN 1414-
5685. 2009.
134
CHAMILLARD, A. T. AND BRAUN, K. A. Evaluating Programming Ability in
an Introductory Computer Science Course. In: SIGCSE 3/00. ACM 1-58113-
213-1/00/0003. Austin, Texas, USA. 2000.
CHEN, W.; LIU, Z.; SUN, X.; WANG, Y. A game theoretic framework to
identify overlapping communities in social network, in Data Mining and
Knowledge Discovery Journal, Special issues, 2010, 21(2), Sep. 2010.
CHENG, L. T. S.; HUPFER, S.; ROSS, J; PATTERSON, B.; CLARK, C S. Jazz:
a collaborative application development environment. Conference on Object
Oriented Programming Systems Languages and Applications: Companion of
the 18th annual ACM SIGPLAN conference on Object-oriented
programming, systems, languages, and applications, 2003.
CLANCY, M.; TITTERTON, N.; RYAN, C.; SLOTTA, J. AND LINN, M. New
Roles for Students, Instructors, and Computers in a Lab-based Introductory
Programming Course. In: SIGCSE, ACM 1-58113-648-X/03/0002. 2003.
DAVIS, F. Perceived Usefulness, Perceived Ease of Use, And User Acceptance of
Information Technology, MIS Quarterly, Vol. 13, pp. 319-339, 1989.
DELVAL, J. Introdução à Prática do Método Clínico: descobrindo o pensamento
das crianças. Editora ARTMED. Porto Alegre, Brasil. 2002
DE SOUZA, C. S. Compulsory Institucionalization: investigating the paradox of
computer supported informal social process. Interacting with Computers, v.
16, n. 4, p. 635-656. 2004.
DE SOUZA, C. S. The Semiotic Engineering of Human-Computer Interaction.
MIT Press. ISBN 0-262-04220-7. 2005.
DE SOUZA, C. S., LEITÃO, C. F., PRATES, R. O., DA SILVA, E. J. The
semiotic inspection method. In Proceedings of VII Brazilian Symposium on
Human Factors in Computing Systems (Natal, RN, Brazil, November 19 - 22,
2006). IHC '06, vol. 323. ACM, New York, NY, 148-157. DOI=
http://doi.acm.org/10.1145/1298023.1298044. 2006.
DE SOUZA, C. S., LEITÃO, C. F., PRATES, R. O., BIM, S. A. & DA SILVA, E.
J. Using the Semiotic Inspection Method in Scientific Research Contexts.
Manuscrito não publicado. 2008.
DIJKSTRA, E. On the Teaching of Programming, i.e. on the Teaching of
Thinking. In: Selected Writings on Computing: A Personal Perspective.
Springer-Verlag NY. 1982.
135
DILLENBOURG, P. Over-scripting CSCL: The risks of blending collaborative
learning with instructional design. Paper presented at Three Worlds of
CSCL: Can We Support CSCL? P. Kirschner, Inaugural Address, Open
Universiteit Nederland. 2002.
DILLENBOURG, P.; FISCHER, F. Basics of computer-supported collaborative
learning. Zeitschrift. 2007.
ECKERDAL, A. AND BERGLUND, A. What Does It Take to Learn
Programming Thinking?. In: ICER’05, ACM 1-59593-043-4/05/0010.
Seattle, Washington, USA. 2005.
FLICK, U. Uma introdução à pesquisa qualitativa. 2nd ed. Porto Alegre:
Bookman, 311 p. 2004.
FREUDENBERG, S., ROMERO, P., DU BOULAY, B. 'talking the talk': Is
intermediate-level conversation the key to the pair programming success
story? In Proc. of Agile 2007, IEEE Computer Society, pages 84-91. 2007.
FUKS, H., CUNHA, L.M., GEROSA, M.A., LUCENA, C.J.P. Participação e
Avaliação no Ambiente Virtual AulaNet da PUC-Rio. In: Silva, M.;
Educação Online: Teorias, Práticas, Legislação e Formação Corporativa;
Edições Loyola, Rio de Janeiro, ISBN 85-15-02822-0, Cap. 15, pp. 231-254.
2003
GUIMARÃES, F. J. Z., DE SOUZA, C. S. Análise de um Ambiente de Apoio a
Comunidades de Prática utilizando o Método de Inspeção Semiótica.
Monografias em Ciência da Computação, Departamento de Informática,
PUC/RJ, n. 06/08. ISSN 0103-9741. 2008.
HILLEGERSBERG VAN, J.; HERRERA, M. Tool Support for Distributed
Software Development : The past - present - and future of gaps between user
requirements and tool functionalities. In: TOMAG+REMIDI 2007
Proceedings : The Seventh International Conference of Computer Ethics:
Philosophical Enquiry. 2007.
HUTCHLEY, I.; WOOFFITT, R. Conversation Analysis, 2nd edition. Polity
Press. USA. 2008.
HWANG, W. Y.; WANG, C. Y.; HWANG, G. J.; HUANG, Y. M.; HUANG, S.
A web-based programming learning environment to support cognitive
development. Interacting with Computers, 20, 6, 524–534. 2008.
136
JAIN, A. K.; SINGHAL, M.; GUPTA, M. S. Educational Tool for Understanding
Algorithm Building and Learning Programming Languages. In Proceedings
of the World Congress on Engineering and Computer Science 2010, Vol I
WCECS 2010, October 20-22, San Francisco, USA. 2010.
JAKOBSON, R. Linguistics and Poetics. In Style in Language, ed. T.A. Sebeok,
350-377. Cambridge, MA: The MIT Press. 1960.
JO, C-H.; ARNOLD, A. A Portable and Collaborative Distributed Programming
Environment. The 2003 International Multi-Conference in Computer Science
and Computer Engineering – The International Conference on Software
Engineering, (IMCCSCE – SERP’03), 198-203, Las Vegas, Nevada, June 23-
26, 2003.
KNUTH, D. E. The Art of Computer Programming. Fundamental Algorithms,
Third Edition (Reading, Massachusetts: Addison-Wesley, 1997), xx+650pp.
ISBN 0-201-89683-4. Volume 1, Fascicle 1, MMIX: A RISC Computer for
the New Millennium, v+134pp. ISBN 0-201-85392-2. 2005.
KOBBE, L., WEINBERGER, A., DILLENBOURGH, P., HARRER, A.,
HÄMÄLÄINEN, R., HÄKKINEN, P. AND FISCHER, F. Specifying
computer-supporter collaboration scripts. Computer-Supported Collaborative
Learning, 2:211-214. 2007.
LEVIN, J. Estatística Aplicada a Ciências Humanas. 2nd. Edition. Editora Harbra
Ltda. ISBN 85-294-0207-3. 1987.
LIEBARMAN, H.; SELKER, T. Out of context: computer systems that adapt to,
and learn from, context. In IBM Systems Journal. Volume 39 Issue 3-4, July
2000.
LISTER, R.; LEANEY, J. Introductory Programming, Criterion-Referencing, and
Bloom. In: SIGCSE, ACM 158113-648-X/03/0002. Reno, Nevada, USA.
2003.
MCDOWELL, C., WERNER, L., BULLOCK, H., FERNALD, J. The Impact of
Pair Programming on Student Performance, Perception and Persistence. In the
proc. of the International Conference on Software Engineering, pp. 602. 2004.
MCKEOWN, J. E FARRELL, T. Why We Need to Develop Succcess in
Introductory Programming Courses. In: CCSC – Central Plains Conference,
Maryville, MO. 1999.
137
MORENO, A.; MYLLER, N.; SUTINEN, E. Collaborative program visualization
with woven stories and jeliot 3. In International Conference on Web Based
Communities, pages 482–485, Lisbon, Portugal, March 2004.
MORENO, A.; MYLLER, N.; SUTINEN, E. JeCo, a Collaborative Learning Tool
for Programming. Proceeding VLHCC '04 Proceedings of the 2004 IEEE
Symposium on Visual Languages - Human Centric Computing. IEEE
Computer Society Washington, DC, USA. 2004b.
NAGAPPAN, N., WILLIAMS, L., FERZLI, M., WIEBE, E., YANG, K.,
MILLER, C., BALIK, S. Improving the CS1 experience with pair
programming. In Proceedings of the 34th SIGCSE technical symposium on
Computer science education., pp. 359 – 362. 2003.
NOSEK, J. T. The Case for Collaborative Programming. Commun. ACM 41(3):
105-108. 1998.
O’DONNEL, A.M.; DANSEREAU. Scripted cooperation in student dyads: A
method for analyzing and enhancing academic learning and performance. In
Hertz-Lazarowitz and N. Miller (Eds.), Interaction in cooperativegroups: The
theoretical anatomy of group learning (pp. 120-141). London, Cambridge
University Press. 1992.
PARRAT-DAYAN S.; TRYPHON, A. Jean Piaget Sobre a pedagogia: Textos
Inéditos. São Paulo: Casa do Psicólogo, 1998.
PASTEL, R. Student assessment of group laboratories in a data structures course.
In Journal of Computing Sciences in Colleges, v. 22, issue 1, pp. 221 – 230.
2006.
PERES, F., MEIRA, L. Educational software evaluation centered on dialogue:
interface, collaboration and scientific concepts. In Proceedings of the Latin
American conference on Human-computer interaction. Pp. 97 – 106. 2003.
PIAGET, J.; INHELDER, B. A Psicologia da Criança. Trad. Octavio M. Cajado.
São Paulo: Difel, 146 p.1968.
PIAGET, J. A Evolução Intelectual da Adolescência à Vida Adulta. Trad.
Fernando Becker e Tania B.I. Marques. Porto Alegre: Faculdade de
Educação, 1993. Traduzido de: Intellectual Evolution from Adolescence to
Adulthood. Human Development, v. 15, p. 1-12, 1972.
PIAGET, J. Fazer e Compreender. Trad. Cristina L. de P. Leite. São Paulo:
Melhoramentos; EDUSP, 186 p.1978.
138
PIAGET, J. Abstração Reflexionante: Relações lógico-aritméticas e ordem das
relações espaciais. Trad. Fernando Becker e Petronilha G. da Silva, Porto
Alegre: Artes Médicas, 1995.
PIMENTEL, M., FUKS, H., LUCENA, C.J.P. Avaliação da Participação em
Conferências Textuais Assíncronas. Anais Eletrônico do X Workshop de
Informática na Escola, integrante do XXIV Congresso da Sociedade
Brasileira de Computação (WIE/SBC 2004), ISBN: 85-88442-94-9, 31 Julho
- 6 Agosto, Salvador, BA, 2004.
PIMENTEL, M., FUKS, H. AND LUCENA, C.J.P. Co-text Loss in Textual Chat
Tools. In: 4th International and Interdisciplinary Conference on Modeling and
Using Context - CONTEXT 2003, LNAI 2680, Stanford, CA, USA, June, pp
483-490, 2003.
PIMENTEL, M., FUKS, H., LUCENA, C.J.P. Avaliação da Participação dos
Aprendizes em Debates Síncronos”. XIV Simpósio Brasileiro de Informática
na Educação - SBIE 2003, 12 a 14 de Novembro de 2003, ISBN: 85-88442-
70-1, Rio de Janeiro - RJ, pp. 140-149. 2003b.
POLYA, G. How to Solve It, 2nd Ed. Princeton University Press, 1957, ISBN 0-
691-08097-6. 1957.
PRATES, R.O., DE SOUZA, C.S., BARBOSA, S.D.J. Communicability
Evaluation Method for User Interfaces. Interactions. New York: , v.7, n.1,
p.33 - 38, http://doi.acm.org/10.1145/328595.328608. 2000.
ROBERTSON, D. A Lightweight Method for Coordination of Agent Oriented
Web Services. In Proceedings of AAAI Spring Symposium on Semantic Web
Services. Stanford. 2004.
SANTOS, L. N.; CASTRO, A. N.; CASTRO, T. Alteração no Modelo de Grupos
do Moodle para Apoiar a Colaboração. In: XVIII Simpósio Brasileiro de
Informática na Educação, 2007, São Paulo. Simpósio Brasileiro de
Informática na Educação. Porto Alegre : SBC, v. 1. p. 24-35. 2007.
SEARLE, J. Speech Acts. Cambridge University Press. ISBN 0-521-09626-X.
1969.
SELKER, T. COACH: A Teaching Agent That Learns. Communications of the
ACM, July 1994.
SHARAN, S. Handbook of Cooperative Learning Methods. The Greenwood
educators’ reference collection. Praeger Publishers. 1999.
139
SHEN, H; SUN, C. RECIPE: a prototype for Internet-based real-time
collaborative programming. In: Proceedings of the 2nd Annual International
Workshop on Collaborative Editing Systems. Philadelphia, Pennsylvania,
USA. 2000.
SPÓSITO, M. A. F.; CASTRO, T.; CASTRO, A. N. Estação de percepção: uma
abordagem para o monitoramento em ambientes virtuais de aprendizagem. In:
XIX Simpósio Brasileiro de Informática na Educação, 2008, Fortaleza-CE.
Sociedade Brasileira da Computação, p. 288-298. 2008.
STAHL, G. Supporting group cognition in an online math community: a cognitive
tool for small-group referencing in text chat. Journal of Educational
Computing Research. 2006.
STOREY, M.-A.; CUBRANIC, D.; GERMAN, D. On the use of visualization to
support awareness of human activities in software development: A survey and
a framework. ACM Symposium on Software Visualization (SoftVis'05), 193–
202, 2005.
THOMPSON, S., REINKE, C. AND LI, H. Refactoring Functional Programs.
Final Report GR/R75052/01. http://www.cs.kent.ac.uk/projects/refactor-fp.
2006.
VILLASCLARAS-FERNÁNDEZ, E. D.; ISOTANI, S.; HAYASHI, Y.;
MIZOGUCHI, R. Looking Into Collaborative Learning: Design from Macro-
and Micro-Script Perspectives. AIED 2009: 231-238. 2009.
VYGOTSKY, L. S. Mind in Society: the Development of Higher Psychological
Processes. Editores: Cole, M; John-Steiner, V; Scribner, S.; Souberman, E.
Harvard University Press. 1978.
WEINBERG, G. M. The Psychology of Computer Programming. Computer
Science Series. Litton Educational Publishing, F9264-000-4. USA. 1971.
YIN, ROBERT K. Estudo de Caso: Planejamento e Métodos 4ª. Edição. Bookman
Editora. ISBN 8577806553. 2010
Apêndice A
Este apêndice mostra as análises realizadas quanto ao 3o. exercício
correspondente à fase 5 do esquema progressivo de aprendizagem de programação
em grupo no estudo de caso descritivo discutido no Capítulo 5.
Exercício sobre Banco de Sangue: Padrões de Interação
Em um dado Banco de Sangue, diariamente, são feitas doações por pessoas
de diferentes tipos sangüíneos, para as quais é feito um registro contendo o CPF
do doador (CPF), o sexo (S), a idade (I), o tipo sangüíneo (TS), o fator RH (RH),
bem como a data da doação (DD) e a quantidade doada (QD) (250 ou 500 ml). O
sangue doado é guardado em recipientes com uma capacidade fixa (250ml).
Também diariamente, são feitas requisições pelos hospitais (H), cada requisição
indica as características do sangue (tipo e fator RH) e a quantidade solicitada
(QS). Sabemos que homens e mulheres possuem intervalos de tempo diferentes
para fazer doações. Para homens o intervalo mínimo é de 2 (dois) meses e para
mulheres é de 3 (três). A idade máxima para doadores (ambos os sexos) é 60 anos
e a mínima é 15 anos.
Sejam as seguintes estruturas
Doação (CPF, S, I,TS,RH,DD,QD)
Requisiç
ão
(H,TS,RH,QS)
CPF, H e TS são strings onde TS pode assumir apenas os
valores {“a”,“b”,“ab”,“o”}. I, QD e QS são inteiros; DD é uma
tripla na forma (dia, mês, ano). S e RH são do tipo char, podendo
assumir os valores indicados: S {‘m’,‘f’}, RH {‘+’,‘–’}.
Determine funções para atender os seguintes requisitos:
* Controle de estoque: deseja-se saber o estado atual do estoque.
141
* Controle de requisições: nem todas as requisições feitas por hospitais
são passíveis de atendimento. Deseja-se saber as requisições que são atendidas.
* Análise estatística: deseja-se ter informações estatísticas por mês e por
ano do tipo: quantidade média de doações, quantidade de doações abaixo da
média, média de doações por tipo sanguíneo, doadores regulares, etc. Informações
similares para as requisições, também.
* Sugestões de doações: o banco de sangue gostaria de incentivar os
doadores a doarem novamente, passado o intervalo mínimo das doações.
Este trabalho será com o mesmo grupo anterior. Terá duas semanas para ser
entregue.
Neste trabalho, terão que ser definidas quais as funções que serão escritas,
assim como, quem irá desenvolver cada função. Como o problema não está
completamente definido, desejamos que utilizem a criatividade para criar as
funções que atendam os requisitos levantados.
Análise das Conversas
Grupo 1
StAf informar StGe re-informar-StAf StGe informar / disponibilizar StAf re-disponibilizar-StGe StAl disponibilizar StAl explicar StAf disponibilizar StAt disponibilizar StDani informar StAf re-informar-StDani /
sugerir StDani disponibilizar
Grupo 2
StDan informar
StDi informar
StDi perguntar
142
StJofi re-perguntar-StDi
StJofi re-informar-StDi
StKa sugerir
StDi re-sugerir-StKa
StHu re-sugerir-StKa
StDi informar / perguntar
StDi informar
StDi perguntar
StHu re-perguntar-StDi
StHu sugerir
StHu informar
StDi re-sugerir-StHu
StJofi re-sugerir-StHu
StDi explicar
StHu informar / perguntar
StDi re-perguntar-StHu
StJofi sugerir
StDio re-sugerir-StJofi
StHu disponibilizar
StHu sugerir / informar
StDi re-sugerir / informar
StDio perguntar
StDio re-informar-StDi
StDi explicar
StDi informar
StKa re-informar-StDi
StHu informar
StDi re-informar-StHu
StDi disponibilizar
StDi perguntar
StHu disponibilizar
StHu informar
StJofi informar
143
StDan perguntar
StJofi sugerir
StDi re-sugerir-StDi
StJofi esclarecer
StDio informar
StHu disponibilizar
StJofi re-disponibilizar-StHu
StJofi sugerir
StDio disponibilizar
StKa disponibilizar
StJofi disponibilizar
StDio re-disponibilizar-StJofi
Grupo 3
StThi informar
StJe re-informar-StThi
StThi explicar
StThi chamar atenção
StThi informar
StEmra perguntar
StJe disponibilizar
StJe explicar
StEmra re-explicar-StJe
StJe informar
StFla re-explicar-StJe
StVi re-explicar-StJe
StThi explicar
StJe explicar / disponibilizar
StJu informar
StEmra disponibilizar
StVi confirmar
StVi perguntar
StVi chamar atenção
144
StVi explicar / perguntar2
StJu re-perguntar-StVi /
re-perguntar2-StVi
StVi confirmar
StJe re-confirmar-StVi
StJe informar
StVi perguntar3
StFla re-perguntar3-StVi
StVi disponibilizar
StJe re-disponibilizar-StVi
StVi esclarecer
StVi informar
StVi disponibilizar
StJe re-disponibilizar-StVi
StVi informar
StEmra informar
StVi informar
StJu informar
StJe chamar atenção
StJe disponibilizar
StVi disponibilizar
StAnd disponibilizar
StThi disponibilizar
StJe apontar um erro
StJu disponibilizar
Grupo 4
StRobo perguntar
StJef re-perguntar-StRobo
StJuma re-perguntar-StRobo
StJa confirmar
StLuvi perguntar
145
StRobo re-perguntar-StLu
StJa explicar
StRoma re-explicar-StJa
StJef explicar
StLuvi informar
Grupo 5
StKeyu chamar atenção
StKeyu informar
StKeyu explicar
StKeyu esclarecer
StKeyu chamar atenção
StRibe disponibilizar / explicar
StKeyu informar
StKeyu disponibilizar
StRibe perguntar
StKeyu re-perguntar-StRibe
StRibe informar
Sessão de chat...
Grupo 6
StCarg chamar atenção
StPauce perguntar
StBruca disponibilizar
StPauce re-disponibilizar-StBruca
StMamo re-disponibilizar-StBruca
/ perguntar
Grupo 7
StAnt chamar atenção
146
StCri explicar
StCri disponibilizar
StCri esclarecer / disponibilizar
StAnt re-explicar-StCri
StCri informar
StAnt explicar / disponibilizar
StPat perguntar
StPat informar / disponibilizar
StCri re-disponibilizar-StPat
StCri sugerir
StPat re-sugerir-StCri
StPat informar
StAnt disponibilizar
Grupo 8
StDanpe disponibilizar
StFlamo explicar
StFlamo disponibilizar
StMan perguntar
StFlamo re-perguntar-StMan
StBru disponibilizar
StCrys re-perguntar-StMan
StMan confirmar
StDar disponibilizar
StWil disponibilizar / perguntar
StWil perguntar
Grupo 9
StLu disponibilizar / explicar
StCarf re-disponibilizar-StLu
StCarf informar / explicar
147
StLu disponibilizar
StCarf disponibilizar / explicar
StCarf explicar
StDani informar / perguntar
StDani informar
Apêndice B
Neste apêndice mostramos a representação completa em LCC dos padrão de
interação “disponibilizar”, que foi testados com a análise do 2º. exercício do
estudo de caso descritivo discutido no Capítulo 5. Os outros padrões seguem o
mesmo esquema de representação só modificando as representações das conversas
reais e os nomes dos papéis, podendo ter mais um acrescentado como alternativa
de resposta.
Padrões de Interação no LCC
O código abaixo foi escrito em inglês, pois foi desenvolvido durante o
doutorado sanduiche na Universidade de Edimburgo, sob orientação do professor
David Robertson, autor da linguagem LCC.
/* Scenario 1 (to make [an artefact - code or report ref.
to a task] available)
1: developer sends a code/report to any reader, including
an evaluator
2a: a reader sees receives the artefact and the evaluation
2b: an evaluator sees the code/report and sends back a
message with her evaluation
evaluation can be sent to developer only or broadcasted
*/
a(developer,D) ::=
a(broadcaster(X,L,Er),B) <-- artefact(X,L).
a(broadcaster(X,L,Er),B) ::=
(send_artefact(X) => a(reader,R) <-- L=[R|Rs] then
Er=[E|Es] <-- evaluation(X,E) <= a(reader,R)
then
a(broadcaster(X,Rs,Es),B)) or
149
null <-- L=[] and E=[].
a(reader,R) ::=
send_artefact(X) <= a(broadcaster(X,_,_),B) then
evaluation(X,E) => a(broadcaster(X,_,_),B) <--
do_evaluation(X,E).
/* Group 2 - Doctors Queue Problem */
known(i2,artefact(report,[a3,d2])).
known(a3,do_evaluation(report,i_dont_know)).
known(d2,do_evaluation(report,ok)).
/*known(a2,do_evaluation(report,fine)).*/
known(resp1,artefact(code_versions,[c2,a2])).
known(a2,do_evaluation(code_versions,fine)).
/*known(d2,do_evaluation(code_versions,ok)).*/
known(c2,do_evaluation(code_versions,i_dont_know)).
/*
All ocurrences of "Making available" in Group2, exercise 4
*/
/*
known(a2,artefact(40,x+x)).
known(resp1,artefact(130,code_versions)).
known(a2,artefact(140,report)).
known(i2,artefact(160,report)).
known(resp1,artefact(170,tests)).
known(a3,artefact(190,function_code)).
known(i2,artefact(230,code_versions)).
known(a3,artefact(250,report)).
known(a3,artefact(260,code_versions)).
known(a2,do_evaluation(265,code_versions,ok)).
known(a2,do_evaluation(275,report,ok)).
known(d2,artefact(320,codes)).
known(d2,artefact(340,report)).
known(a2,do_evaluation(345,codes,ok)).
known(a2,do_evaluation(346,report,ok)).
known(c2,artefact(380,report_c2)).
known(a2,do_evaluation(385,report_c2,ok)).
150
*/
/*
Original conversation
*/
/*
known(a2,new_question(10,topic1,lets_divide_the_work)).
known(a3,new_question(20,topic2,who_wants_to_do_that)).
known(a2,knows_answer(30,who_wants_to_do_that,i_can_do_it)).
known(a2,artefact(40,x+x)).
known(resp1,knows_answer(50,who_wants_to_do_that,i_can_do_it)
).
known(a2,new_suggestion(60,do_the_second_and_do_like_this)).
known(resp1,do_disagree(70,do_the_second_and_do_like_this,bec
ause_somebody_else_divide_the_task)).
known(i2,artefact(80,task_division)).
known(i2,new_information(90,its_necessary_to_keep_code_versio
ns)).
known(a2,new_warning(100,please_do_your_codes_and_send_the_re
ports)).
known(c2,new_clarification(110,i_couldnt_read_all_this_until_
now_so_ill_take_longer)).
known(resp1,concording(120,please_do_your_codes_and_send_the_
reports,ok)).
known(resp1,artefact(130,code_versions)).
known(a2,artefact(140,report)).
known(i2,concording(150,please_do_your_codes_and_send_the_rep
orts,ok)).
known(i2,artefact(160,report)).
known(resp1,artefact(170,tests)).
known(a3,concording(180,please_do_your_codes_and_send_the_rep
orts,ok)).
known(a3,artefact(190,function_code)).
known(i2,new_clarification(200,a3_function_is_another_one)).
known(a3,agree(210,a3_function_is_another_one,oh_sorry)).
known(i2,new_clarification(220,a3_thats_your_function)).
known(i2,artefact(230,code_versions)).
known(i2,new_question(240,codes,can_you_all_make_your_codes_a
vailable)).
known(a3,artefact(250,report)).
151
known(a3,artefact(260,code_versions)).
known(a2,do_evaluation(265,code_versions,ok)).
known(i2,new_confirmation(270,a3_you_did_the_correct_function
)).
known(a2,do_evaluation(275,report,ok)).
known(a3,new_question(280,correct_function,what_was_the_corre
ct_function)).
known(i2,knows_answer(290,what_was_the_correct_function,this_
one)).
known(a2,new_information(300,reports_missing)).
known(a2,new_information(310,im_gonna_put_them_on_the_wiki_re
port)).
known(d2,artefact(320,codes)).
known(a2,new_information(330,the_reports_on_the_wiki_are_good
_so_far_but_missing_pieces)).
known(d2,artefact(340,report)).
known(a2,do_evaluation(345,codes,ok)).
known(a2,do_evaluation(346,report,ok)).
known(resp1,new_information(350,im_here)).
known(a2,new_error(360,xy+z-w,z)).
known(a2,patch(370,z,h)).
known(c2,artefact(380,report_c2)).
known(a2,do_evaluation(385,report_c2,ok)).
known(resp1,new_information(390,finally)).
known(a2,new_error(400,report1,function_identifier_not_clear)
).
known(a2,new_error(410,report2,missing_explanation_for_functi
on)).
known(a2,patch(420,function_identifier_not_clear,f_x)).
known(a2,patch(430,missing_explanation_for_function,this_is_t
he_explanation)).
known(c2,new_information(440,my_report_was_really_incomplete_
but_now_its_ok)).
known(a2,new_information(450,the_report_is_ready)).
known(c2,new_question(460,does_anyone_want_to_add_something_o
n_the_report)).
known(a2,new_information(470,we_shouldve_discussed_more_but_w
ell_be_more_active_on_the_next_exercise)).
*/
152
Parte inicial do programa de simulação do LCC, com chamadas aos padrões
de interação desenvolvidos nesta tese:
% File: simulator.pl
% Author: Dave Robertson
% A basic simulator for LCC.
:- ensure_loaded(library(system)),
ensure_loaded(basic),
ensure_loaded(util),
ensure_loaded(loader).
% This portray clause is to prevent you seeing too much
detail of the
% LCC interaction model when debugging. Uncomment it in
SICStus Prolog
% if you want to see no details of the interaction model when
debugging.
% (see SICStus manual for how portray/1 works).
% portray(def(_,_,_)) :- print('Definition').
sim(Agents, InstitutionFile, FProt) :-
load_institution(InstitutionFile, Prot),
simulate([], Agents, Prot, FProt).
scenario1c :-
sim([a(developer,a2),a(developer,a3),a(developer,resp1
),a(developer,i2),a(developer,c2),a(developer,d2),a(re
ader,a3),a(reader,resp1),a(reader,i2),a(reader,c2),a(r
eader,a2),a(reader,d2),a(evaluator,a2)],
makeavailable4, FProt),
lcc_disp(FProt).
scenario2 :-
sim([a(informer,i2),a(reader,r2),a(enquirer,enq2)],
informing, FProt), lcc_disp(FProt).
scenario3 :-
sim([a(clarifier,c1),a(reader,r1),a(concurring,cc1),
a(enquirer,enq1)], clarifying, FProt),
153
lcc_disp(FProt).
scenario4 :-
sim([a(checker,ck),a(chooser,ch)], confirmation, FProt),
lcc_disp(FProt).
scenario5b :-
sim([a(asker,a2),a(reader,r2),a(respondent,resp2)],
generalquestions2, FProt),
lcc_disp(FProt).
scenario6 :-
sim([a(advisor,ad),a(reader,r), a(concurring,cc),
a(objector,o)], suggesting, FProt),
lcc_disp(FProt).
scenario7 :-
sim([a(caller,c),a(reader,r),a(concurring,cc),
a(enquirer,enq)], callingattention, FProt),
lcc_disp(FProt).
scenario8 :-
sim([a(spotter,s),a(reader,r),a(solver,sv)], pointing,
FProt),
lcc_disp(FProt).
scenario8b :-
sim([a(spotter,s2),a(reader,r2),a(solver,sv2)], pointing2,
FProt),
lcc_disp(FProt).
scenario8c :-
sim([a(spotter,a2),a(reader,a3),a(reader,resp1),a(reader,i2)
,a(reader,c2),a(reader,a2),a(reader,d2),a(solver,a2)], pointing3,
FProt),
lcc_disp(FProt).
scenario9 :-
sim([a(asker,a),a(reader,r), a(explainer,e)], explaining,
FProt),
lcc_disp(FProt).
154
scenario9b :-
sim([a(asker,a2),a(reader,r2),a(explainer,e2)], explaining2,
FProt),
lcc_disp(FProt).