Thaís Helena Chaves de Castro Sistematização da Aprendizagem de Programação em Grupo Tese de Doutorado

Transcrição

1 Thaís Helena Chaves dee Castro Sistematização daa Aprendizagem de Programação emm Grupo Tese T de Doutorado Tese apresentada como requisito parcial para obtenção do título de Doutor peloo Programaa de Pós- Graduação em Informática da PUC-Rio. Orientador: Hugo Fuks Rio de Janeiro, marçoo de 2011

2 Thaís Helenaa Chaves de Castro Sistematização daa Aprendizagem de Programação emm Grupo Tese apresentadaa como requisito parcial para obtenção do título de Doutorr pelo Programa de Pós-Graduação em Informática da PUC-Rio. Aprovadaa pela Comissão Examinadora abaixo assinada. Hugo Fuks Orientador Departamento de Informática PUC-Rio Carlos José Pereira dee Lucena Departamento de Informática PUC-Rio Simone Diniz JunqueiraJ a Barbosa Departamento de Informática PUC-Rio Denise Del Re Filippo Escola Superior de Design Industrial UERJ Credinéé Silva de Menezes Departamento de Informática UFES José Eugenio Leal Coordenador( a) Setorial do Centro Técnico Científico C - PUC-Rio Rio de Janeiro, 244 de marçoo de 2011

3 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 É 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). Castro, Thaís Chaves de Ficha Catalográfica Sistematização da aprendizagem de programação em grupo / Thaís Helena Chaves de Castro ; orientador: Hugo Fuks f.: il. (color.) ; 30 cm Tese (doutorado) - Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática, 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

4 A meus pais, marido e filhos, pela dedicação e apoio.

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

6 Resumo Castro, Thaís Chaves de. Sistematização da Aprendizagem de Programação em Grupo. Rio de Janeiro, p. 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

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

8 Abstract Castro, Thaís Chaves de. A Systematization for Group Programming Learning. Rio de Janeiro, p. D.Sc. Thesis Computer Science Department, Pontifical Catholic University of Rio de Janeiro. In undergraduate introductory programming courses the use of Internetbased 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.

9 Sumário 1 Introdução A Tese Objetivo e como atingi-lo Estrutura da Tese 19 2 Análise sobre Aprendizagem de Programação Experiências em Disciplinas Introdutórias de Programação para Cursos de Graduação em Computação A Evolução dos Códigos em Aprendizagem de Programação Identificação de Categorias na Evolução dos Códigos Conclusão do Capítulo 39 3 Tecnologias para Aprendizagem de Programação em Grupo Ferramentas para Apoiar a Aprendizagem de Programação em Grupo Aportes Metodológicos e Tecnológicos como Apoio a Disciplinas de Programação Introdutória Proposta de Adaptações de um ambiente CSCL para o Contexto da Aprendizagem de Programação A Engenharia Semiótica O Método de Inspeção Semiótica O Contexto da Aprendizagem de Programação utilizando o ColabWeb Inspeção Semiótica do ColabWeb Etapas do MIS Proposta de Melhorias e Adaptações Conclusão do Capítulo 66

10 4 Colaboração na Aprendizagem de Programação Scripts para Apoiar o Processo de Colaboração Análise de Interações em Ambientes CSCL Um Estudo de Caso Exploratório sobre Aprendizagem de Programação em Grupo Análise Quantitativa Análise Qualitativa Um Esquema Progressivo para Aprendizagem de Programação em Grupo Conclusão do Capítulo 84 5 Sistematização da Aprendizagem de Programação em Grupo Definindo Padrões de Interação Estudo de Caso Descritivo Metodologia Análise Parte 1 Obtendo padrões Análise Parte 2 Usando os padrões na caracterização das Interações Representando Padrões de Interação Identificando Oportunidades de Intervir Usando a Sistematização Estudo de Caso Explanatório Conclusão do Capítulo Conclusão Contribuições Reflexões Adicionais no Tema Trabalhos Futuros 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

11 Apêndice B 148 Padrões de Interação no LCC 148

12 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

13 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 Tabela 5.3 Padrões de Interação para a Fase 3 dos Grupos 3 e Tabela 5.4 Padrões de Interação para a Fase 3 dos Grupos 7 e Tabela 5.5 Padrões de Interação do 2º.Exercício da Fase 5, dos Grupos 1 e Tabela 5.6 Padrões de Interação do 2º.Exercício da Fase 5, dos Grupos 3 e Tabela 5.7 Padrões de Interação do 2º. Exercício para a Fase 5, do Grupo Tabela 5.8 Padrões de Interação do 2º. Exercício para a Fase 5, dos Grupos 6 e Tabela 5.9 Padrões de Interação do 2º. Exercício para a Fase 5, dos Grupos 2 e 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 Tabela 5.13 Padrões de Interação do 1º. Exercício para a Fase 5 do Grupo 6 de Tabela 5.14 Padrões de Interação do 1º. Exercício para a Fase 5 do Grupo 3 de Tabela 5.15 Padrões de Interação do 2º. Exercício para a Fase 5 dos Grupos 2 e 3 de Tabela 5.16 Padrões de Interação do 2º. Exercício para a Fase 5 dos

14 Grupos 4 e 5 de

15 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

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

18 18 questão de pesquisa: como ampliar oportunidades de intervenção em umm processo de aprendizagem de programação em grupo? Da questão de pesquisa acima, embasamos nossa hipótese que é: Oportunidades de intervenção na aprendizagem de programação em grupo são ampliadas com o uso de uma abordagem sistemática de acompanhamento Objetivo e como atingi-lo O objetivoo desta tese é sistematizar práticas, metodologias e tecnologias em uma abordagem para apoiar a aprendizagem de programação o em grupo.. Para isso, três frentes de investigação devem ser abertas no Pressuposto Pedagógico, nas Ferramentas LMS e no Método de Colaboração, o que é ilustrado na Figura 1.1. Figura 1.11 Elementos da Tesee O pressuposto pedagógico da tese é a teoria de desenvolvimentoo cognitivo de Piaget, aliada a práticas vigentes de ensino de programação e técnicas conhecidas de programação em grupo. As práticas pedagógicas relacionadas na revisão bibliográfica desta tese se baseiam em concepções pedagógicas diversas, tendo em comumm o uso de software dee apoio paraa a realização de exercícios. Essas ferramentas computacionais são úteis para monitorar e intervir durante o processo de aprendizagem. As técnicas de programação em grupo investigadas são usadas em empresas de desenvolvimento dee software e muitas vezes v adaptadas para serem utilizadas em disciplinas introdutórias de programação em cursos de graduação cujo cerne é computação. Segundo a investigação feita nesta tese, os LMSs tem sidoo bastante utilizados para apoiar a aprendizagem presencial na graduação, confirmado por

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

21 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 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 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 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 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 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 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 28 Programa A f x y = x*y + x/y Programa B 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 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 r_x a b c =(-b) + e / 2*a where e=sqrt(b^2 4*a*c) Programa B rs a b c = (x,y) where x = ((-b) + e)/2*a

30 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 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: Programa A fat n = if n==0 then 1 else product [1..n] Programa B fat n = if n==0 then 1 else n * fat(n 1) 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

32 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 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 f y x = x + 17 f_y = undefined g z = z + f x 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 showall =... format =... table =... Programa B 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 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 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

35 35 que cada aluno fez. Quando a essa quantidade de versões de d um ou mais alunos difere significativamente da distribuição normal da turma, esse(s) aluno(s) é (são) identificado(s) como caso especial,, ficando marcado para p visualização do professor, que envia as versões diretamente paraa o AcKnow. Então, baseado na análise do AcKnow para cada par dee versões, o professor faz uma análise mais detalhada, fornecendo feedback diretamente aos alunos. A Figura 2. 1 ilustra o funcionamento recursivo do AcKnow, incluindo suas partes integrantes, como mecanismos de inferência, DCG e basee de conhecimento. Figura 2. 1 Funcionamento recursivo doo AcKnow O AcKnow, seguindo as categorias de modificações e os exemplos apresentados anteriormentee nesta seção, classifica como modificaçõesm s sintáticas endentação, inclusão ou remoção de e vírgula e ponto e vírgula, espacejamento entree caracteres e inclusão ou remoçãoo de parênteses. As modificações semânticas são aquelas relacionadas a avaliação de funções. Por exemplo, modificações em estruturas de dados e operações nas funções são classificadas nessa categoria. Além disso, refactoring, neste contexto, são casos especiais de modificações semânticas cujo objetivo é a melhoria na qualidade do código segundo as métricas de qualidade de software. Atualmente e o AcKnow utiliza parcialmente o catálogo de refactoring para Haskell, definido em (Thompson, Reinkee & Li, 2006).

36 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 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 minutos semântica 7 44 horas refactoring 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

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

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

54 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 Etapas do MIS As cinco etapas do MIS apresentadas anteriormente na Seção 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 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 metamensagens conforme exemplificado na Figura 3.1, Aqui deve ser feito o relatório do exercício 4.

56 56 Figura 3.1 Página de Exemplo no wiki O MIS sugere que se vá construindo a metamensagem do designer à medida que se conclui cada etapa do método. Esta metamensagem deve ser baseada em um esquema de metacomunicação, descrito na seção anterior. Há dois usuários finais para o ColabWeb, um é o aluno,, segundo o projeto do ColabWeb. O outro é o professor, uma vez que o ColabWeb herda parte do projeto do Moodle. Para essa inspeção consideramos somente o aluno como usuário final. f Em seguida está a meta-mensagem inicial de comunicação do designer doo ColabWebb para seu usuário final (aluno). O texto entre colchetes é o esquema de metacomunicação. [Aqui está o meu entendimentoo sobre quem você é]. Você é umm aluno de computação, que já está acostumado a utilizar ambientes dee redes sociais.[o que eu aprendi que você quer ou precisa fazer, de que forma e porquê]. p Você precisa de um sistema para gerenciar a disciplina que você está matriculadom o, podendo interagir com outros alunos, resolvendo exercícios e acompanhando as instruções do professor. Você precisa ser capaz de visualizar as atividades de seuss colegas e escrever textos em ferramentas auxiliares como wikis, fóruns e chats.. [Este é o sistema que eu projetei pra você e essa é a maneira pela qual você pode ou deve utilizá-lo de forma que preencha uma variedade de propósitos que coadunam com esta visão]. Você pode usar o calendário para verificar oss eventos do curso, a estação de percepção para estar a par automaticamente da movimentaçãm ão em seus outros cursos e ainda subdividir seus grupos em subgrupos, conforme a atividade pretendida.

57 57 Etapa 2 análise doss signos estáticos A Figura 3.2 apresenta a tela de abertura do ColabWeb. A mensagem login é substituída pela palavra acesso, o que não é umm jargão muito comum nesses ambientes. Além disso, não é bem comunicada, pois se localiza na parte superior, entre parênteses e utilizando fonte muito pequena. Figura 3.2 Página de abertura do ColabWeb Conforme ilustrado na Figura 3.3, no curso IC-CComputação, aparecem inicialmente os grupos existentes, à esquerda, e no centro, em Grupos o designer do curso, neste caso o professor, destaca a palavra importante para chamar atenção do usuário quanto aoo seu grupo. Isto é umm bom recurso quando não se conseguee eliminar os outros grupos da visão do usuário. À direita, há um recurso chamado estação de percepçãoo (Spósito, Castro & Castro, C 2008) monitora as atividades nos cursos que o usuário pertence. As palavras padrão que aparecem, Meus Cursos e Monitorar Tudo são úteis para o seu entendimento. Casoo o usuário selecione outra palavra, as caixas abaixo da Estação de Percepção são alteradas. Da mesma forma que o link para entrar no ambiente, o link para sair está muito pequeno. O seu posicionamento é bom, pois aparece centralizado com o nome do ambiente, mas está entre parênteses e utilizando fonte pequena.

58 58 Figura 3.3 Predominância da Linguagem Textual T A Figura 3.4 mostra o recurso Calendário, presente nesse n curso.. Apesar de útil, marcando as datas ocupadas com algum tipo de atividade, abaixo do calendário aparecem events key, que por estarem escritos em outro idioma, confundem o usuário, segundo declarações feitas ao professor da disciplina (designer do curso) e podem numa última instância tornar o recurso r inútil. Figura 3.4 Recurso Calendárioo A Figura 3.5 mostra a estruturação de tópicos no cursoo IC-EngComputação. Nestee caso, o professor decidiu organizar o curso por tipos de atividade. Deste modo, ao clicar em uma atividade, o usuário visualizaa também as outras atividades do mesmo tipo e perde o contexto do curso, como c por exemplo, o tópico do curso abordado naquela atividade.

59 59 Figura 3.5 Perda de Contexto Em seguida está o refinamento da metamensagem do designer d ao final desta 2a. etapa, baseada somentee nos signoss estáticos, onde o texto entre colchetes é o esquema de metacomunicação do designer, o texto riscado é o que foi retirado e o texto em destaque, o que foi acrescentado. [Aqui está o meu entendimentoo sobre quem você é]. Você é umm aluno de computação, que já está acostumado a utilizar ambientes de redes sociais computacionais. [O que eu aprendi que você quer ou precisa fazer, de que forma e porquê]. Você Seu professor precisa de um sistema para gerenciar a disciplina que você está matriculado podendo interagir com outros alunos, resolvendo exercícios e acompanhando as instruções do professor e se comunicar com você. Você precisa interagir com os outros alunos de seu grupo, resolvendo exercícios e acompanhando as instruções do professor. Você precisa ser capaz de visualizar as atividades de seus colegas escrever textos em ferramentas auxiliares como e colaborar com eles utilizando wikis, fóruns e chats. [Estee é o sistema que eu projetei pra você e essa é a maneira pela qual você pode ou deve utilizá-lo de forma que preencha uma variedade dee propósitoss que coadunam com esta visão]. Você pode usar o calendário para verificar os eventos doo curso, a estação de percepção para estar a par automaticamente da movimentação em seus outros cursos e ainda subdividirr seus grupos em subgrupos, conforme c a atividade pretendida. Etapa 3 análise doss signos dinâmicos

60 60 A partir da lista de grupos mostrada na página principal do curso o é possível selecionar qualquer grupo em que o usuário esteja inscrito. Esta açãoo gera uma página como a mostrada na Figura 3.6. Um primeiro problema é que o usuário vê quem participa em qualquer grupo, inclusive seus logs de acesso. Maiss grave é o problema quanto à navegação. O usuário fica perdido, pois precisa selecionar um dos links hierárquicos na parte superior da tela, algo que nem n sempree consegue enxergar. Caso selecione grupos, o usuário receberá uma lista com links para grupos, o que é totalmentee inútil e confuso visto que o usuário chegou à página atual selecionando um grupo na páginaa principal do site do curso (Figura 3.7). Figura 3.6 Visualização de Informações sobre Grupo Ainda na Figura 3. 7, a caixaa de diálogo Seguir para... é de difícil visualização. Caso o usuário consigaa enxergá-la, ele poderá selecionar um dos links que lá aparecem. Isto mitiga o problema da falta de referencial.

61 61 A seguir apresentamos o refinamento da metamensagem do designer ao final desta 3a. etapa. O que está entre colchetes é o esquema, o que estáá riscado é o texto retirado e o que está destacado é o que foi acrescentado ao final desta etapa. Figura 3.7 Navegação nos Grupos [Aqui está o meu entendimentoo sobre quem você é]. Você é umm aluno de computação, que já está acostumado a utilizar ambientes computacionais. [O que eu aprendi que você quer ou precisa fazer, de que forma e porque]. p Seuu professor precisa de um sistema paraa gerenciar a disciplina que você está matriculado e se comunicar com você. Você precisa interagir com os outros alunos de seu grupo, resolvendo exercícios e acompanhando as instruções do professor. Além disso, você pode visualizar qualquer atividade de seus colegas, através do linkk de grupos dentro do curso e depois caminhar pelos links superiores para a parte doo ambiente que você quiser ir. Você precisa serr capaz de visualizar as a atividades de seus colegas e colaborar com eles utilizando wikis, fóruns e chats. c Para isso, você também pode acessar os recursos r isoladamente, visualizando todos os daquele tipo. [Este é o sistema que eu projeteii pra você e essa é a maneira m pelaa qual você pode ou deve utilizá-lo de forma que preencha uma variedade de propósitos que coadunam com esta visão].. Você podee usar o calendário para verificar os eventos do curso, clicar sobre um evento e ver r sua descrição. Pode também modificar suas opções de visualização na estação de percepção, customizando que tipo de movimentação deseja estar ciente ou que cursos deseja acompanhar a movimentação para estar a par automaticamente da movimentação em seus outros cursos e ainda subdividirr seus grupos em subgrupos, conforme c a atividade pretendida.

62 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 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 , pois os mesmos não responderam aos s 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 no início da disciplina, mas depois os alunos se acostumaram. Ainda segundo os

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

68 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 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 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 71 Em (Villasclaras-Fernández, Isotani, Hayashi & Mizoguchi, 2009) é proposta uma abordagem utilizando ontologias, unificando os conceitos de microscripts 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 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 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 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 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 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 Metas alcançadas Problema resolvido Busca por códigos similares Anotações satisfatórias Integração entre os membros do time Reutilização códigos próprio time dos do 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 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 76 Tabela 4.2 Dificuldades sentidas pelos grupos Informantes A B C D E F G H I Descrição das dificuldades sentidas pelos grupos Interpretação da declaração de algumas questões 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. Entendimento da sintaxe do Haskell; agregação de todas as soluções. Entendimento de como se constrói um programa; construção adequada do programa; verificação de erros; utilização do interpretador Hugs. Refinamento das soluções. Implementação do código. Utilização do interpretador Hugs; entendimento da sintaxe do Haskell. Refinamento das soluções; utilização da recursão. 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 77 Tabela 4.3 Conclusões fornecidas pelos grupos Informantes A B C D E F G H I Descrição das conclusões fornecidas pelos grupos Foi muito produtivo; nós colocamos nosso conhecimento em prática; nós aprendemos como trabalhar em grupo. 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. Não relatado Não relatado 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 ). Não relatado Não relatado Não relatado 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 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 A B C D E F G H I Percepções dos pesquisadores Interpretação da declaração de algumas questões. Implementação do código; reunião de todo o time; alcance de um consenso; agregação de todas as soluções. Implementação do código; agregação de todas as soluções. Entendimento de como se constrói um programa; implementação do código; verificação de erros; utilização do interpretador Hugs. Refinamento de soluções Implementação do código Utilização do interpretador Hugs; implementação do código; Refinamento das soluções; utilização da recursão. 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 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 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

80 80 esclarecimentos sobre a metodologia. A Fase 2 consiste da solução individual com o respectivo registro. Na Fase 3 o trabalho em grupo começaa com a decisão sobre qual seria a melhor solução individual desenvolvida. Na Fase 4 a solução do problema torna-se para cada atividade. Na Fasee 5 o grupo é também responsável pela colaborativa: o professor define as tarefas e o grupoo define os atores definição das tarefas. Por fim, na Fase 6 acontece uma atividade de desenvolvimento onde os grupos competem num cenário que reproduzz situações reais de trabalho. Figura 4.1 Esquema Progressivo de Aprendizagem de Programação em Grupo A opção pela divisão em 6 fases, bem como a sequenciação proposta, foi baseada na experiência com o ensino de programaçãoo usando linguagens funcionais desenvolvido naquela instituição desdee 1989, bemm como na análise dos relatos citados no início desta seção, considerando-se umm curso dee 75 horas desenvolvido ao longo de um semestree acadêmico. Uma ferramenta de apoio à colaboração foi utilizadaa e incorporou todo o conteúdo criado antes e durante o curso, seguindo as diretivas encontradas em

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

83 83 idades máximas e mínimas paraa doadores respectivamente... são 60 e 15 anos Figura 4.2 Workflow do Esquema Progressivo dee Aprendizagem de Programação em Grupo Ainda com respeito ao esquema proposto, a modularização de problemas e a definição em Haskell são os conceitos envolvidos na fase de preparação. A fase de resolução individual requer o mesmo nível de expertise, em adição a um raciocínio mais matemático devido à natureza dos problemas geométricos. A fase seguinte, Codificação em Grupo I, requer o uso de expressões condicionais em

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

86 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 == []] esclarecer disponibilizar 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. 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! 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? perguntar esclarecer explicar disponibilizar explicar re-disponibilizar perguntar

99 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. 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". 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 re-sugerir sugerir

100 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. 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 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] explicar disponibilizar funcao xs = [b (a,b,c)<-xs] senha xs = [c (a,b,c)<-xs]... 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 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 Disponibilização de artefato Informe Clarificação Confirmação Pergunta Sugestão Chamada de atenção Identificação de erro Explicação Minha funções Exemplo Pessoal, o problema não é tão difícil Eu não pude logar antes. Eu já anotei isso Alguém mais quer incluir alguma coisa no relatório? todos deveriam tentar criar uma solução pra cada questão do seu próprio jeito Ei, Galera! Vamos fazer o exercício! Eu acho que vc cometeu um erro quando definiu o tipo int como saída... o que eu fiz foi usar a 2ª. Questão que

103 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 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 StAf Grupo 1 Grupo 2 disponibilizar StDi sugerir / disponibilizar

104 104 StAt StAl StAt StAl StAt StAl StGe disponibilizar explicar re-explicar-al esclarecer sugerir informar disponibilizar StHu esclarecer / explicar StDi re-explicar- StHu / disponibilizar / explicar StHu esclarecer / disponibilizar StDi sugerir StKa esclarecer / disponibilizar StJofi informar StDi informar StDi explicar / disponibilizar StDi perguntar StJofi StKa informar 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 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 / StJo re-explicar-stribe esclarecer 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 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 107 StEmra StFla informar 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 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 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 / StJa sugerir disponibilizar / explicar StThi disponibilizar StLuvi re-sugerir-stja StThi disponibilizar StRoma sugerir StJe disponibilizar StRoma chamar atenção StVi disponibilizar / StJa sugerir perguntar StFla disponibilizar / StJuma perguntar explicar 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 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 / StLu disponibilizar perguntar StCarg re-perguntar StLu disponibilizar StPauce disponibilizar StCarf esclarecer

111 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 / StDanpe disponibilizar re-perguntar-stbra 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 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 / StWil disponibilizar confirmar 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 113 StDi StJofi StDi StDi / esclarecer informar perguntar 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 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.

114 114 Uma linguagem baseada naa lógica pra tratar com protocolos de comunicação em ambientes multiagente foi então adotadaa para representar os padrões de interação. O LCC (Lightweight Coordinate Calculus) C (Robertson, 2004) é uma notação já utilizada em diferentes aplicaçõess sob uma plataforma denominada Open Knowledge ( que ajuda a tratar o problema de coordenação. Apesar de ser uma linguagem bastante expressiva, o LCC mantém a simplicidade necessária para representar adequadamente as interações através de recursos de inferência providos pela plataforma Open Knowledge. Tipicamente, cada processo inicia por um membroo do grupo decidindo iniciar um tópico com uma mensagem, disparando desse modo um padrão de interação. O iniciador automaticamente torna-se o coordenador para aquele padrão de interação. Em seguida um agente virtual chamado broadcaster distribui a mensagem paraa todos os demais inscritos na conversa. Caso após a leitura da mensagem alguém resolver respondê-la, de volta ao coordenador via broadcaster. a pessoa torna-se automaticamente um avaliador enviando a mensagem Figura 5. 1 Representação Formal das Conversas C A seguir apresentamos um fragmento de código LCC, onde os elementos ilustrados na Figura 5.1 aparecem estando instanciado para o padrão dee interação Esclarecer (Clarifying). 1 a(clarifier,c) ::=