felipe lucas weber pasini - udescsistemabu.udesc.br/pergamumweb/vinculos/00000d/00000d07.pdf ·...
TRANSCRIPT
FELIPE LUCAS WEBER PASINI
FERRAMENTA PARA APOIO AO ENSINO DE INICIAÇÃO À PROGRAMAÇÃO DE
COMPUTADORES
JOINVILLE – SC
2015
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC
CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
FELIPE LUCAS WEBER PASINI
FERRAMENTA PARA APOIO AO ENSINO DE INICIAÇÃO À PROGRAMAÇÃO DE
COMPUTADORES
Trabalho de Conclusão de Curso
apresentado à Universidade do Estado de
Santa Catarina, como requisito para a
obtenção do título de Bacharel em Ciência
da Computação.
Orientadora: Profª Luciana Rita Guedes,
M.Sc.
JOINVILLE – SC
2015
FELIPE LUCAS WEBER PASINI
FERRAMENTA PARA APOIO AO ENSINO DE INICIAÇÃO À PROGRAMAÇÃO DE
COMPUTADORES
Trabalho de Conclusão de Curso aprovado como requisito parcial para a
obtenção do grau de Bacharel, no curso de Graduação em Ciência da
Computação na Universidade do Estado de Santa Catarina.
Banca Examinadora:
Orientadora:
______________________________________________________________
Profª Luciana Rita Guedes, M.Sc.
Universidade do Estado de Santa Catarina
Membro:
___________________________________________________________
Profª Isabela Gasparini, Dra.
Universidade do Estado de Santa Catarina
Membro:
___________________________________________________________
Profª Éverlin Fighera Costa Marques, M.Sc.
Universidade do Estado de Santa Catarina
Joinville – SC, Novembro de 2015
RESUMO
O projeto da Olimpíada Brasileira de Informática (OBI) na UDESC motiva estudantes
a participarem da OBI e realiza minicursos de programação para os interessados na
competição. Estes minicursos vêm sendo realizados de forma tradicional, mas
percebe-se que o processo de ensino e aprendizagem de programação pode ser
melhorado fazendo uso de novas metodologias e ferramentas de apoio ao ensino de
programação. Neste contexto, este trabalho compara diversas ferramentas para
apoio ao ensino de iniciação à programação e suas metodologias, tendo em vista as
necessidades específicas dos minicursos da OBI. A partir da análise dos trabalhos
relacionados, este trabalho desenvolveu uma ferramenta web de apoio ao ensino de
programação. A ferramenta desenvolvida conta com um corretor de códigos para a
linguagem C. Foram então realizados testes funcionais na ferramenta, estes que
geraram resultados satisfatórios. Foi também desenvolvido um conjunto de aulas
utilizando algumas das metodologias estudadas. No entanto, a ferramenta e o
conjunto de aulas não chegaram a ser aplicadas em um minicurso da OBI no tempo
em que este trabalho foi realizado.
PALAVRAS-CHAVE: OBI, ferramentas de ensino de programação, metodologias de
ensino, testes funcionais.
ABSTRACT
The project of the Brazilian Informatics Olympiad (BOI) in UDESC motivates students
to participate in the BOI and performs programming mini-courses for those interested
in the competition. These short courses are being conducted in a traditional way, but
it is clear that the programming teaching and learning process can be improved by
making use of new programming learning tools and methodologies. In this context,
this work will make a comparison of several tools to support the teaching of
programming introduction and their respective methodologies, considering the
specific needs of BOI’s short courses. From the analysis of related works, this work
developed a web based programming learning tool. The developed tool has code
corrector for the C language. Functional tests were then carried out on the tool, these
producing satisfactory results. It has also been created a set of classes using some
of the methodologies studied. However, neither the tool nor the set of classes came
to be applied in one of BOI’s short courses in the time this work was done. .
KEYWORDS: BOI, programming teaching tools, teaching methodologies, functional tests.
LISTA DE FIGURAS
Figura 1: Processo de Mapeamento Sistemático ........................................... 11
Figura 2: Taxonomia Revisada de Bloom ....................................................... 16
Figura 3: Zona de desenvolvimento proximal ................................................. 20
Figura 4: Ferramenta Alice ............................................................................. 37
Figura 5: Interface do Scratch ......................................................................... 39
Figura 6: App Inventor para Android ............................................................... 40
Figura 7: Ambiente SACI ................................................................................ 42
Figura 8: Diagrama de Casos de uso do sistema ........................................... 51
Figura 9: Esquema front-end e back-end ........................................................ 52
Figura 10: Estrutura navegacional simplificada do ambiente .......................... 54
Figura 11: Principais áreas da ferramenta SACI ............................................. 55
Figura 12: Interface do aluno .......................................................................... 56
Figura 13: Interface do professor, cadastro de alunos. ................................... 57
Figura 14: Interface do professor, cadastro de curso ..................................... 58
Figura 15: Interface do professor, cadastro de aulas. ..................................... 59
Figura 16: Esquema conceitual, diagrama entidade-relacionamento. ............ 60
Figura 17: Exemplo de saídas do sistema ...................................................... 63
Figura 18: Interface do aluno implementada ................................................... 65
Figura 19: Seletor de aula ............................................................................... 65
Figura 20: Área de trabalho ............................................................................ 66
Figura 21: Interface do professor implementada ............................................ 67
Figura 22: Teste funcional – cadastros ........................................................... 69
Figura 23: Teste funcional – dados cadastrados ............................................ 70
Figura 24: Teste funcional – teste de código .................................................. 71
Figura 25: Teste funcional – teste de código incorreto ................................... 72
Figura 26: Teste funcional – teste de submissão de códigos ......................... 73
LISTA DE TABELAS
Tabela 1: Resumo de características desejáveis para minicursos da OBI ....... 9
Tabela 2: Resultados da busca automatizada com a query de pesquisa ....... 14
Tabela 3: Verbos da taxonomia revisada........................................................ 17
Tabela 4: Objetivos da taxonomia afetiva ....................................................... 19
Tabela 5: Categorias do modelo ARCS .......................................................... 23
Tabela 6: Nove eventos de ensino ................................................................. 25
Tabela 7: Classificação das metodologias ...................................................... 32
Tabela 8: Classificação das ferramentas ........................................................ 45
Tabela 9: Resumo dos requisitos para ferramenta aplicada em minicursos da
OBI ............................................................................................................................ 48
Tabela 10: Relação de funcionalidades Planejadas x Concluídas .................. 64
Tabela 11: Minicurso OBI nível 0 - programação para iniciantes .................... 76
LISTA DE ABREVIATURAS
ACM Association for Computing Machinery
ARCS Atenção Relevância Confiança Satisfação
CAPES Coordenação de Aperfeiçoamento de Pessoal de Nível Superior
IEEE Instituto de Engenheiros Eletricistas e Eletrônicos
OBI Olimpíada Brasileira de Informática
SBC Sociedade Brasileira de Computação
SBIE Simpósio Brasileiro de Informática na Educação
UDESC Universidade do Estado de Santa Catarina
UNICAMP Universidade Estadual de Campinas
ZDP Zona de Desenvolvimento Proximal
SUMÁRIO
1 INTRODUÇÃO ............................................................................................... 1
1.1 JUSTIFICATIVA .............................................................................................. 2
1.2 OBJETIVO ...................................................................................................... 4
1.2.1 Objetivo Geral ................................................................................................. 4
1.2.2 Objetivos Específicos...................................................................................... 4
1.3 METODOLOGIA ............................................................................................. 4
1.4 ESTRUTURA DO TRABALHO ....................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA ..................................................................... 6
2.1 OLIMPíADA BRASILEIRA DE INFORMATICA ............................................... 6
2.1.1 OBI na UDESC ............................................................................................... 8
2.2 MAPEAMENTO SISTEMATICO ................................................................... 10
2.3 METODOLOGIA DE PESQUISA .................................................................. 12
3 TRABALHOS RELACIONADOS ................................................................. 15
3.1 METODOLOGIAS APLICADAS AO ENSINO DE PROGRAMAÇÃO ........... 15
3.1.1 Taxonomia Cognitiva de Bloom Revisada .................................................... 16
3.1.2 Taxonomia Afetiva de Krathwohl .................................................................. 18
3.1.3 Zona de Desenvolvimento Proximal de Vygotsky ......................................... 19
3.1.4 Ritmo de educação de Whitehead ................................................................ 21
3.1.5 Modelo ARCS de Keller ................................................................................ 21
3.1.6 Nove eventos de ensino de Gagné ............................................................... 25
3.1.7 OntoRevPro .................................................................................................. 27
3.1.8 Metodologia baseada no Paradigma do Paraquedas ................................... 28
3.2 COMPARAÇÃO DAS METODOLOGIAS ...................................................... 31
3.2.1 Contribuição das metodologias pesquisadas para este trabalho .................. 34
3.3 FERRAMENTAS APLICADAS AO ENSINO DE PROGRAMAÇÃO ............. 35
3.3.1 ProgTest ....................................................................................................... 36
3.3.2 Alice .............................................................................................................. 36
3.3.3 AlgoWeb ....................................................................................................... 37
3.3.4 Scratch .......................................................................................................... 38
3.3.5 App Inventor para Android ............................................................................ 40
3.3.6 CIFluxProg .................................................................................................... 41
3.3.7 SACI (OBI) .................................................................................................... 41
3.4 COMPARAÇÃO DAS FERRAMENTAS........................................................ 43
3.4.1 Contribuição das ferramentas pesquisadas para este trabalho .................... 46
4 FERRAMENTA PROPOSTA ........................................................................ 47
4.1 PROPOSTA PRELIMINAR: USO DO AMBIENTE SACI .............................. 48
4.2 PROJETO DA NOVA FERRAMENTA .......................................................... 49
4.2.2 Projeto da interface ....................................................................................... 51
4.2.2.1. Esquema front-end e back-end ..................................................................... 52
4.2.3 Modelo do Banco de Dados .......................................................................... 59
4.2.4 Sistema de correção automática de códigos ................................................ 61
4.2.5 Estado da ferramenta ................................................................................... 64
4.2.6 Testes Funcionais ......................................................................................... 68
4.3 INTEGRAÇÃO COM METODOLOGIAS ....................................................... 74
4.3.1 Aulas criadas ................................................................................................ 75
5 CONSIDERAÇÕES FINAIS ......................................................................... 78
REFERÊNCIAS ......................................................................................................... 80
APÊNDICES ............................................................................................................. 86
1
1 INTRODUÇÃO
A OBI é uma competição organizada nos moldes das outras olimpíadas científicas
brasileiras, como Matemática, Física e Astronomia. É uma iniciativa da Sociedade
Brasileira de Computação (SBC), organizada pelo Instituto de Computação da
Universidade Estadual de Campinas (UNICAMP), com o objetivo de despertar nos alunos
o interesse pela Computação, através de uma atividade que envolve desafio,
engenhosidade e uma saudável dose de competição (OBI, 2015). A competição é
realizada em modalidades, onde a modalidade Iniciação é destinada a estudantes do
Ensino Fundamental e as demais (Programação e Universitária) têm foco em estudantes
do Ensino Médio ou das primeiras fases do Ensino Superior. Estas últimas modalidades
objetivam testar os conhecimentos dos estudantes na resolução de problemas de
programação de computadores.
Com o propósito de divulgar a OBI nas escolas de Ensino Médio de Joinville, foi
criado o projeto de extensão “OBI na UDESC”, incentivando as escolas a sediarem a
primeira etapa da competição, motivando os estudantes a participarem e realizando
minicursos para os interessados na competição (UDESC, 2015). Os minicursos realizados
pelo projeto tem como objetivo capacitar ou aprimorar os conhecimentos dos alunos na
lógica envolvida em programação de computadores, permitindo-os participar da OBI nas
modalidades Programação e Universitária.
Atualmente estes minicursos são realizados de forma tradicional, ou seja, aulas
com conteúdo exposto em quadro (ou em projetor), e os alunos, idealmente, fazem
anotações e, posteriormente, resolvem exercícios referentes ao assunto, usando
computadores para programar sempre que necessário. Percebe-se que esta metodologia
tradicional de ensino não condiz com as reais possibilidades existentes na área de
educação, principalmente no ensino de tecnologia. Entende-se que existem incontáveis
ferramentas tecnológicas voltadas ao uso na educação, e que é possível utilizá-las para
obter melhores resultados, tanto no aprendizado dos estudantes quanto em sua
motivação para o estudo. Deste modo, há interesse em que estas técnicas de ensino
sejam aprimoradas com o uso de novas metodologias e ferramentas de apoio ao ensino
de programação, o que motivou o desenvolvimento deste trabalho.
2
1.1 JUSTIFICATIVA
O ensino de programação é constituído de maneira genérica pelo ensino de lógica,
em que se aborda o processo de criação de algoritmos, independente de linguagens, para
resolução de problemas, e o ensino das linguagens de programação, onde o foco está em
como escrever programas em uma determinada linguagem (DOS SANTOS; COSTA,
2006). Existem diversos problemas inerentes ao ensino de programação, tal como o alto
índice de reprovações ou desistências em disciplinas de programação (PEREIRA JÚNIOR
et al., 2005). A existência de problemas como estes pode ser atribuída a diversos fatores
tais como: a tendência dos alunos de se concentrarem nas primeiras complicações que
encontram, normalmente relacionadas a sintaxe (RONGAS; KAARNA; KALVIAINEN,
2004), a dificuldade de interpretação dos problemas a serem resolvidos (PEREIRA
JÚNIOR et al., 2005) e, em alguns casos, problemas com a estratégia de ensino usada.
Atualmente, existem diversas ferramentas e metodologias usadas para auxiliar o
processo de ensino de lógica e linguagens de programação. Por ferramentas, nos
referimos a produtos de software ou tecnologias que foram desenvolvidas ou podem ser
usadas para o apoio ao ensino de programação. Já as metodologias existentes, em geral
não foram desenvolvidas para o uso especifico na área de ensino de programação, mas
já foram empregadas com sucesso para tal. Existem metodologias cujo foco está na
avaliação como a Taxonomia de Bloom (DE JESUS; RAABE, 2009)(DENTON;
MCKINNEY; DORAN, 2005), que diz respeito aos objetivos de aprendizagem e ajudam a
orientar o professor na elaboração de avaliações, outras com foco na revisão, como a
OntoRevPro (Ontologia para Revisão de Programas) (DE FÁTIMA NEVES; COELLO,
2006), que serve como uma espécie de guia para o que o aluno deve prestar atenção
durante a revisão de um programa, existem também aquelas com foco no processo de
ensino, como a metodologia do Paradigma do Paraquedas (SARRIA et al. 2009), que
defende o refinamento gradual de uma solução, ou o modelo ARCS de Keller (DENTON;
MCKINNEY; DORAN, 2005), no qual deve-se primeiro conseguir a atenção dos alunos,
mostrar-lhes a relevância do tópico, construir a confiança dos alunos em dado tópico, e
então dar-lhes um senso de satisfação como resultado do que aprenderam. Além do foco
de estudo, existem também abordagens distintas adotadas por tais metodologias, a fim de
auxiliar o processo de aprendizagem (OLIVARES CEJA; BUENDIA CERVANTES, 2013).
A abordagem “bottom-up” é aquela em que se ensina programação começando pela
linguagem e partindo para a lógica, em níveis crescentes de complexidade. Em
contraponto, existe a abordagem “top-down”, em que a lógica é ensinada primeiro e,
3
então, a linguagem de programação é introduzida para se aplicar a lógica já abordada
(GREYLING; CILLIERS; CALITZ, 2006).
Dentre as ferramentas existentes, pode-se destacar aquelas que fazem uso de
ambientes visuais, como CIFluxProg (DE SANTIAGO; DAZZI, 2004), B# (GREYLING;
CILLIERS; CALITZ, 2006) , ambos com programação via fluxogramas, ou como Scratch
(SCRATCH, 2015), ferramenta de programação usando blocos visuais, e Code.org
(CODE.ORG, 2015), ferramenta web abrangendo vários estilos, desde programação em
blocos, até jogos educacionais. Há outras que usam ambientes com maior ênfase em
elementos textuais, como Codecademy (CODECADEMY, 2015), uma ferramenta web em
que o aluno aprende uma linguagem de sua escolha de forma interativa, programando
enquanto segue instruções (ou aulas). Ainda com ênfase em elementos textuais, pode-se
citar o AIDE (AIDE, 2015), uma ferramenta para dispositivos móveis que, de maneira
similar, ensina programação Java e Android. Existe também a ferramenta SACI (SACI,
2015) um ambiente de aprendizagem online, disponibilizado pela OBI, cujo curso, de
Javascript, é composto de aulas com vídeos explicativos e diversos exercícios.
Algumas destas ferramentas servem para auxiliar o professor no processo de
ensino, fornecendo meios capazes de melhorar o aprendizado do aluno, como é o caso
do CIFluxProg (DE SANTIAGO; DAZZI, 2004) que permite o uso de fluxogramas e
pseudocódigo, ou do Scratch (SCAICO et al., 2013)(MOTA et al., 2014), que faz uso de
programação visual, substituindo a utilização de uma linguagem específica por blocos de
comandos. Outras ferramentas são desenvolvidas com o propósito de possibilitar a
autoaprendizagem por parte do aluno, como o Codecademy, AIDE, e SACI, em que o
aluno interage e recebe as lições diretamente do sistema.
Ferramentas para ensino de programação são utilizadas principalmente com
estudantes iniciantes na área de programação, potencialmente tornando o processo de
aprendizado mais eficiente, e auxiliando no desenvolvimento de uma mentalidade lógica
para programação (DOS SANTOS; COSTA, 2006). Desta forma, uma ferramenta de
apoio ao ensino de programação, juntamente com suas metodologias, pode ser muito útil
nos minicursos de programação da OBI na UDESC.
Desta forma, este trabalho tem como objetivo desenvolver uma ferramenta para
apoio aos minicursos preparatórios da OBI na UDESC, a partir deum estudo comparativo
das características de diversas ferramentas já existentes para apoio ao ensino de
4
programação, e suas respectivas metodologias. Para isto, será definida qual abordagem é
a mais adequada para o desenvolvimento da ferramenta. Por fim, esta ferramenta será
implementada, testada e, se possível, avaliada em um curso de iniciação à programação
de computadores, visando a preparação de estudantes para a OBI.
1.2 OBJETIVO
1.2.1 Objetivo Geral
Desenvolver uma ferramenta para apoiar as aulas de minicursos preparatórios para
a OBI, a partir do estudo comparativo de ferramentas já existentes e suas respectivas
metodologias.
1.2.2 Objetivos Específicos
Para atender o objetivo geral, os seguintes objetivos específicos devem ser
realizados:
1. Fazer levantamento bibliográfico e a análise comparativa das ferramentas e
metodologias existentes para apoio ao ensino de iniciação à programação;
2. Selecionar características que sejam adequadas à necessidade dos
minicursos do projeto OBI na UDESC;
3. A partir dos resultados da pesquisa e análise das ferramentas, criar uma
ferramenta que atenda às necessidades dos minicursos do projeto OBI na
UDESC;
4. Realizar testes funcionais da ferramenta, registrando os resultados obtidos.
1.3 METODOLOGIA
O trabalho proposto assume, inicialmente, a forma de um estudo comparativo
sobre ferramentas de apoio ao ensino de programação e as metodologias empregadas
nas mesmas. Após o levantamento teórico, será feita uma análise comparativa destas
ferramentas e metodologias. Posteriormente será feita a adaptação de uma ferramenta a
ser utilizada, e avaliada em um curso de programação para iniciantes.
5
1.4 ESTRUTURA DO TRABALHO
A estrutura deste trabalho está dividida em cinco capítulos, o primeiro capítulo
contem a introdução e justificativa do trabalho, assim como seu objetivo.
O segundo capítulo contém uma breve fundamentação teórica sobre a OBI, além
da descrição do processo de pesquisa empregado no decorrer deste trabalho. No terceiro
capítulo são apresentados os trabalhos relacionados, bem como as tabelas comparativas
das ferramentas e metodologias. O quarto capítulo apresenta a ferramenta desenvolvida.
Por fim, no quinto capítulo são apresentadas as considerações finais deste
trabalho.
6
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo será apresentado, na seção 2.1, a OBI e suas características. Já
seção 2.2 é apresentado o conceito de mapeamento sistemático, que virá a ser usado na
seção 2.3, que apresenta a metodologia de pesquisa usada neste trabalho.
2.1 OLIMPÍADA BRASILEIRA DE INFORMATICA
A Olimpíada Brasileira de Informática (OBI), criada em 1999, é uma competição
organizada nos moldes das outras olimpíadas científicas brasileiras, como Matemática,
Física e Astronomia. É uma iniciativa da Sociedade Brasileira de Computação (SBC),
organizada pelo Instituto de Computação da UNICAMP (Universidade Estadual de
Campinas), com o objetivo de despertar nos alunos o interesse pela Computação,
importante na formação básica atual, através de uma atividade que envolve desafio,
engenhosidade e uma saudável dose de competição (OBI, 2015).
A competição é realizada em três modalidades, de acordo com a escolaridade do
participante, nas quais os alunos competem individualmente, com cada aluno podendo
estar inscrito em apenas uma modalidade. As modalidades são Iniciação, Programação, e
Universitária, apresentadas abaixo:
Modalidade Iniciação: para alunos de ensino fundamental. As tarefas das
provas são sobre problemas de lógica e problemas de computação, tais
problemas de computação sendo sobre lógica de programação, mas sem o uso
de computador. Esta modalidade é dividida em dois níveis:
o O Nível 1, é para alunos até o sétimo ano do ensino fundamental;
o Já o Nível 2, é para alunos até o nono ano de ensino fundamental.
Modalidade Programação: para alunos do último ano do ensino fundamental
até o ultimo ano do ensino médio. As tarefas da prova são sobre problemas de
programação, fazendo uso de computador, com níveis variados de dificuldade,
desde tarefas fáceis, sendo suficiente ter um conhecimento mínimo de
7
programação, até tarefas mais difíceis, que exigem um conhecimento mais
avançado de programação, como noções de estruturas de dados. Assim como
a modalidade Iniciação, esta modalidade é dividida em níveis, estes sendo:
o O Nível Júnior, é para alunos do ensino fundamental;
o O Nível 1, é para alunos até o segundo ano do ensino médio;
o E o Nível 2, é para alunos até o terceiro ano do ensino médio.
Modalidade Universitária: para alunos que estejam cursando, pela primeira
vez, o primeiro ano de um curso de graduação, independente da área. Esta
modalidade exige conhecimento em programação em um nível normalmente
ensinado em bons colégios técnicos, ou no primeiro ano de cursos superiores
de computação ou engenharia. Assim como na modalidade Programação, a
prova é composta de tarefas sobre problemas de programação com níveis
variados de dificuldade, desde tarefas mais fáceis, onde um conhecimento
básico de programação é suficiente, até tarefas mais difíceis, que exigem um
conhecimento mais avançado de programação. Ao contrario das modalidades
anteriores, a modalidade Universitária não é dividida em níveis.
A olimpíada é realizada em duas fases. A primeira fase é realizada em Escolas-
sede habilitadas pela organização da OBI. Os melhores classificados da primeira fase são
convocados para a segunda fase, que é realizada em universidades localizadas nas
capitais dos estados ou em cidades com grande concentração de competidores. Durante
a prova, nas modalidades Programação e Universitária, os competidores podem escolher
entre as linguagens C, C++, Pascal, Python, Java ou Javascript para implementar suas
soluções. As soluções submetidas pelos competidores são enviadas para a organização
da OBI para correção, onde cada tarefa é corrigida passando por uma bateria de testes, e
recebe uma quantidade de pontos de acordo com o resultado dos testes. A nota final do
competidor é definida pela relação entre a quantidade de pontos obtidos dentre todas as
tarefas da prova e o total de pontos possíveis desta.
Os resultados das provas são então divulgados no website da OBI. Todos os
participantes recebem certificados de participação e os melhores colocados de cada
modalidade recebem medalhas de ouro, prata e bronze. Os melhores colocados das
modalidades Iniciação e Programação são convidados para uma semana de cursos no
Instituto de Computação da UNICAMP, onde é feita uma seleção para escolher os quatro
8
alunos, da modalidade Programação, a fazer parte da equipe brasileira na IOI
(International Olympiad in Informatics) do ano seguinte.
2.1.1 OBI na UDESC
Com o propósito de divulgar a OBI nas escolas de Ensino Médio de Joinville, foi
criado, no início de 2013, o projeto de extensão “OBI na UDESC”, incentivando as escolas
a sediarem a primeira etapa da competição, motivando os estudantes a participarem e
realizando minicursos para os interessados na competição (UDESC, 2015). Os principais
objetivos do projeto de extensão “OBI na UDESC” são:
Divulgar a OBI nas escolas de Joinville que oferecem Ensino Médio,
incentivando a escola a sediar a primeira fase da OBI e motivando os
estudantes a participar;
Realizar minicursos no campus da UDESC para estudantes do Ensino
Médio que queiram aprimorar seus conhecimentos e participar da OBI em
edições posteriores;
Fomentar o desenvolvimento de talentos na área de programação de
computadores, com vistas ao desenvolvimento da região como reconhecido
polo de informática no estado de Santa Catarina.
Os minicursos, como o nome já indica, são de curta duração, com 24 horas de
curso distribuídas ao longo de três semanas, com quatro horas diárias. Os minicursos
realizados pelo projeto trazem um pouco sobre a ciência da computação, a lógica
envolvida em programação de computadores e estruturas de programação, permitindo os
alunos a participarem da OBI nas modalidades Programação e Universitária. Os objetivos
dos minicursos são:
Introduzir conceitos básicos de Ciência da Computação;
Revisar Pensamento Lógico;
Introduzir conceitos e princípios de lógica de programação de computadores
para desenvolvimento de algoritmos;
Apresentar noções gerais sobre linguagens de programação;
9
Introduzir o estudo de uma linguagem de programação de alto nível no
paradigma procedural, a Linguagem C;
Introduzir conceitos sobre estruturas de programação, estas sendo, estrutura
de dados, estruturas sequenciais, estruturas de seleção e estruturas de
repetição;
Proporcionar uma visão geral de construção de algoritmos com as principais
estruturas de programação, e proporcionar a pratica de resolução de
problemas já aplicados na modalidade Programação da OBI.
Estes minicursos são realizados de forma tradicional, ou seja, aulas com conteúdo
exposto em quadro (ou em projetor), e os alunos, idealmente, fazem anotações e,
posteriormente, resolvem exercícios referentes ao assunto, usando computadores para
programar sempre que necessário.
Tabela 1: Resumo de características desejáveis para minicursos da OBI
Causa Efeito
Público alvo iniciante Conteúdo a partir do básico
Linguagens de programação C, C++, Pascal, Python, Java ou Javascript
Cursos de curta duração Ferramenta simples de usar
Corretor automático de códigos
Turmas com muitos alunos Ambiente web
Controle e acompanhamento do
aprendizado
Levando em consideração o que foi apresentado sobre a OBI e o projeto da OBI na
UDESC, pôde-se identificar certas características adequadas às necessidades de seus
minicursos. Primeiramente identifica-se que o publico alvo é composto de alunos do
ensino médio, iniciantes em programação e, portanto a evolução do conteúdo das aulas
deve ser feita a partir do básico. Percebe-se também que os minicursos devem abordar
10
umas das linguagens de programação atualmente aceitas pela OBI, ou seja, C, C++,
Pascal, Python, Java ou Javascript.
Como os minicursos do projeto OBI na UDESC são de curta duração, algumas
características são desejáveis como, por exemplo, a necessidade de que a ferramenta
seja suficientemente simples a fim de que o professor não perca muito tempo ensinando o
aluno como usá-la. Considera-se importante também o uso de um ambiente web nas
aulas, para que os alunos possam continuar a seguir o conteúdo, mesmo fora da sala de
aula, em suas casas, por exemplo. Levando em conta que as turmas podem ter muitos
alunos, outra característica desejável é que o professor não precise corrigir códigos, o que
permitiria dedicar-se mais à atividade de ensino. Por fim, é desejável que a ferramenta
forneça ao professor meios de acompanhar ou de ter controle sobre a evolução de
aprendizagem dos alunos. Sendo assim, estas características serão levadas em
consideração no restante do trabalho e a Tabela 1 apresenta um resumo destas
características.
2.2 MAPEAMENTO SISTEMATICO
O mapeamento sistemático foi a metodologia de pesquisa escolhida para a
realização deste trabalho devido a alguns fatores principais. Esta é uma metodologia
bastante utilizada, inclusive no Grupo de Pesquisa em Informática na Educação (GPIE) da
UDESC, ao qual este trabalho está associado, além de ser uma metodologia bem
definida, e que gera resultados de pesquisa relevantes. Desta forma julgou-se necessário
primeiramente apresentar as características desta metodologia.
Mapeamento sistemático é uma metodologia frequentemente usada em diferentes
áreas de pesquisa, como na área da medicina por exemplo (KITCHENHAM &
CHARTERS 2007, DYBA et al. 2006, HANNAY et al. 2007, KAMPENES et al. 2007 In
apud PETERSEN et al. 2008) . Um mapeamento sistemático providencia uma estrutura
do tipo de relatórios e resultados de pesquisa que vem sendo publicados, categorizando-
os. Frequentemente gera um sumário visual, também conhecido como mapa sistemático,
de seus resultados. Os objetivos principais de um mapeamento sistemático são a
classificação, condução de análise temática e identificação das publicações relacionadas
ao tema da pesquisa (PETERSEN et al. 2008).
11
O processo de um mapeamento sistemático é composto de cinco passos
essenciais, a definição de questões de pesquisa, a realização da pesquisa de estudos
primários relevantes, a triagem dos documentos, keywording dos resumos, e a extração
de dados e mapeamento, cada passo do processo tendo um tipo de resultado, o resultado
final sendo o mapa sistemático, de acordo com a Figura 1.
Figura 1: Processo de Mapeamento Sistemático (Adaptado de: PETERSEN et al. 2008)
A definição de questões de pesquisa tem como objetivo definir o escopo de revisão
do mapeamento, em outras palavras, elas exemplificam os objetivos de estudo de
mapeamento. A pesquisa por estudos primários relevantes é feita através de um ou mais
termos de busca, em bases de dados científicas, ou buscando manualmente em meio a
publicações relevantes. Tais cadeias de pesquisa devem, é claro, ser feitas levando em
consideração as questões de pesquisa. A triagem dos artigos é a etapa em que critérios
de inclusão e exclusão são usados para eliminar artigos não relevantes para responder as
questões de pesquisa, desta forma apenas os artigos relevantes permanecem.
Keywording é uma forma de reduzir o tempo necessário para desenvolver o
esquema de classificação e garantir que o esquema leve em conta os estudos existentes.
É feita em dois passos, primeiro os resumos são lidos em busca de palavras chave e
conceitos que reflitam a contribuição do artigo, também se identifica o contexto da
pesquisa. Quando isto esta pronto, o conjunto de palavras chave de diferentes artigos é
combinada para gerar um entendimento de alto nível sobre a natureza e contribuição da
pesquisa. Isto ajuda a definir um conjunto de categorias para o mapa sistemático.
Quando se tem um esquema de classificação, os artigos relevantes são
organizados em um esquema, então a coleta de dados é iniciada. No decorrer da
extração de dados o esquema de classificação evolui, adicionando novas categorias, ou
unindo e dividindo outras. Durante a extração de dados é usada uma tabela, contendo
12
cada categoria do esquema de classificação, para documentar a extração de dados.
Quando os dados de um artigo são inseridos na tabela, é feita uma analise racional para
determinar em que categoria este se encaixa. A partir da tabela final, é possível calcular a
frequência de publicações em cada categoria, resultando em um mapa sistemático.
2.3 METODOLOGIA DE PESQUISA
A pesquisa deste trabalho foi iniciada na forma de um levantamento bibliográfico
manual, buscando por artigos relacionados a ferramentas e metodologias de ensino de
programação. Em seguida a pesquisa assumiu a forma de um mapeamento sistemático
que contribui para a elaboração dos termos de busca a serem utilizados e resultou num
grande número de trabalhos a serem analisados. Após a etapa da triagem dos artigos,
como não havia a necessidade de gerar o mapa sistemático, a pesquisa voltou à forma de
uma pesquisa bibliográfica manual. Deste modo, utilizando os artigos selecionados no
mapeamento sistemático como base, foram pesquisados artigos que complementassem,
ou apresentassem de forma mais completa as metodologias e ferramentas encontradas.
Primeiramente, como parte do mapeamento sistemático, três questões de pesquisa
foram elaboradas a fim de descobrir quais ferramentas e metodologias vêm sendo usadas
nos últimos anos. Foram realizadas buscas com diferentes intervalos de tempo, desde
cinco até vinte anos, optou-se então pelo intervalo de quinze anos devido à quantidade de
publicações encontradas além de ser próximo ao tempo de existência da OBI:
QP1: Quais ferramentas de ensino de programação têm sido usadas nos últimos
quinze anos?
QP2: Quais metodologias de ensino de programação têm sido usadas nos últimos
quinze anos?
QP3: Como as metodologias de ensino de programação estão relacionadas às
ferramentas de ensino de programação?
Em seguida, foi feito um termo de busca, em português e inglês, para ser usada
nas bases de dados da SBIE, IEEE Xplore, ACM Digital Library, Scopus, e Portal de
13
Periódicos CAPES, os dois últimos que posteriormente foram excluídos por resultarem em
quantidades excessivas de artigos, na ordem dos milhares. O termo de busca utilizado da
pesquisa de artigos nas bases de dados foi o seguinte:
("tools" OR "methodologies") AND ("education" OR "learning") AND
("programming")
("ferramentas" OR "metodologias") AND ("ensino" OR "aprendizagem") AND
("programação")
Juntamente a este termo de busca, foram atribuídos parâmetros extras na pesquisa
de artigos nas bases de dados. Estes parâmetros, usados para filtrar os resultados da
pesquisa, foram os seguintes:
Apenas publicações dos últimos 15 anos: este parâmetro serve para
complementar o termo de busca, para que este possa adquirir resultados
dentro do período de tempo definido pelas questões de pesquisa;
Efetuar busca apenas nos metadados (título, resumo, e palavras chave) dos
documentos: desta forma tem-se uma garantia extra de que os artigos
encontrados serão, efetivamente, relacionados ao tema do trabalho.
Com os artigos primários relevantes encontrados, foi realizada a triagem destes
artigos. Os critérios de inclusão e exclusão usados fôramos seguintes:
Critérios de Inclusão:
o Artigos que retratam o uso de ferramentas e/ou metodologias em um
contexto de ensino de programação;
o Quando várias ferramentas ou metodologias foram retratadas em um
mesmo artigo, cada ferramenta ou metodologia relevante foi tratada
separadamente, por meio de uma pesquisa manual posterior;
o Manter apenas os trabalhos cujas metodologias ou ferramentas
pudessem ser potencialmente usadas nos minicursos da OBI;
Critérios de Exclusão:
14
o Trabalhos cujos resultados da aplicação destas não tenham sido
satisfatórios;
o Trabalhos cujo foco estivesse muito diferente do que o desejado;
o Trabalhos cuja literatura estivesse disponível apenas em forma de
resumo ou de apresentação de slides.
Após a realização da triagem mencionada, foi montada a Tabela 2, exibindo a
quantidade de artigos encontrados em cada base de dados, o total de artigos
encontrados, a quantidade de artigos, candidatos, restantes após uma triagem dos
artigos, e a quantidade final de artigos restantes após ser realizada uma triagem mais a
fundo em cada artigo candidato. Embora o SBIE não se caracterize como um mecanismo
de busca, o termo de busca foi aplicado no sítio do evento, no item pesquisa, gerando os
resultados indicados na tabela.
Tabela 2: Resultados da busca automatizada com a query de pesquisa
BASE DE DADOS QUANTIDADE DE ARTIGOS
SBIE 9
IEEE Xplore 12
ACM Digital Library 26
Total 47
Candidatos 40
Seleção final 17
Com a seleção final dos artigos, como mencionado anteriormente foi feita uma
pesquisa “convencional”, ou seja, foi feita uma pesquisa bibliográfica manual de artigos
que complementassem os artigos selecionados na triagem do mapeamento sistemático.
Com o objetivo de melhor estudar o conteúdo encontrado sobre as ferramentas e
metodologias encontradas nos artigos, possibilitando uma posterior análise mais
detalhada, foi realizada uma busca por mais trabalhos que abordem o uso destas
15
ferramentas e, principalmente, metodologias a fim de tornar possíveis as tabelas de
classificação apresentadas mais adiante neste trabalho.
3 TRABALHOS RELACIONADOS
Nesta seção são apresentadas algumas das metodologias e ferramentas
relacionadas ao apoio ao ensino de programação após a aplicação parcial do
mapeamento sistemático. Embora a busca tenha sido por metodologias e ferramentas de
apoio ao ensino de programação, notou-se que os trabalhos costumam ter um foco mais
voltado para ferramentas ou metodologias, e não ambos. Deste modo, os trabalhos
encontrados foram divididos em dois grupos, aqueles focados nas metodologias e os
focados nas ferramentas de ensino de programação. Também foi necessário fazer
escolhas com relação à quais trabalhos seriam relevantes para a presente pesquisa. Os
critérios usados para estas escolhas foram os de manter apenas os trabalhos cujas
metodologias ou ferramentas pudessem ser potencialmente usadas nos minicursos da
OBI, excluindo os trabalhos com ferramentas ou metodologias não testadas, inacabadas,
ou cujo foco estivesse muito diferente do desejado.
3.1 METODOLOGIAS APLICADAS AO ENSINO DE PROGRAMAÇÃO
Os artigos selecionados apresentam diversas metodologias de ensino sendo
utilizadas no contexto de ensino de programação. No geral estas metodologias não foram
desenvolvidas para o ensino de programação especificamente, mas já foram empregadas
com sucesso para tal. Dentre estas, a grande maioria foi apresentada sem a ligação com
uma ferramenta especifica, embora várias façam menção a que tipo de mídia ou
ferramenta devem ser usadas para complementar, ou aprimorar seu uso. Esta seção
apresenta as metodologias encontradas no decorrer da pesquisa realizada.
16
3.1.1 Taxonomia Cognitiva de Bloom Revisada
A taxonomia de Bloom (BLOOM et al. 1956) foi criada a fim de facilitar a troca de
questões de testes entre professores de varias universidades, cada questão avaliando o
mesmo objetivo de aprendizagem (DE JESUS; RAABE, 2009)(DENTON; MCKINNEY;
DORAN, 2005). Em sua versão original, esta taxonomia fornece definições para as seis
principais categorias do domínio cognitivo, estas sendo conhecimento, compreensão,
aplicação, análise, síntese e avaliação. Estas categorias são ordenadas das mais simples
para as mais complexas, onde uma mais simples é pré-requisito de uma mais complexa.
Para cada uma das seis categorias, existem verbos associados, estes por sua vez
auxiliam na classificação de questões nos níveis ta taxonomia.
Mais tarde a taxonomia de Bloom foi revisada (KRATHWOHL, 2002 in apud DE
JESUS; RAABE, 2009), tornando-a mais fácil de ser aplicada. As seis categorias do
processo cognitivo foram renomeadas para lembrar, entender, aplicar, analisar, criar, e
avaliar, respectivamente, porém a categoria criar passou a ser a de maior hierarquia, de
acordo com a Figura 2.
Figura 2: Taxonomia Revisada de Bloom (Adaptado de: EDUTEKA, 2015)
A pirâmide da esquerda representa a hierarquia e nomenclatura originais da
taxonomia de Bloom, em que a categoria Avaliação é considerada a de maior ordem, com
a categoria Síntese logo abaixo. Já a pirâmide da direita representa a hierarquia e
17
nomenclatura da versão revisada da taxonomia, onde a categoria Síntese passou a ser a
categoria Criar, e a ser considerada a categoria de maior ordem, trocando de lugar com a
categoria Avaliação que passou a ser chamada de Avaliar.
Os verbos associados a cada categoria da taxonomia revisada, apresentados na
Tabela 3, auxiliam na criação ou classificação de questões dentro das categorias da
taxonomia, que por sua vez se referem a determinados objetivos de aprendizagem. Por
exemplo, se o objetivo de aprendizagem for que o aluno seja capaz de analisar um
algoritmo, pode-se usar o verbo “diferenciar”, atribuído a este objetivo, como base na
criação de uma questão, pedindo que o aluno diferencie os tipos de métodos em um dado
algoritmo.
Tabela 3: Verbos da taxonomia revisada (Adaptada de: DE JESUS; RAABE, 2009)
Lembrar Entender Aplicar Analisar Avaliar Criar
Reconhecer Interpretar Executar Diferenciar Verificar Gerar
Relembrar Exemplificar Implementar Organizar Criticar Planejar
Classificar Atribuir Produzir
Sumarizar
Inferir
Comparar
Explicar
Tais categorias da taxonomia, e seus respectivos verbos, aplicadas no contexto de
ensino de programação, são interpretados da seguinte maneira:
1. Categoria Lembrar: Recuperação de conhecimento relevante da memória
de longo termo, por exemplo, identificar trechos específicos em um trecho de
código;
2. Categoria Entender: Construção de significados através de diferentes tipos
de linguagens, por exemplo, escrever em pseudocódigo um programa que
calcule uma formula conhecida;
18
3. Categoria Aplicar: Utilização de processos conhecidos para executar ou
implementar, por exemplo, implementar um programa utilizando como
exemplo um código que resolva um problema semelhante;
4. Categoria Analisar: Decomposição de um problema em suas partes
constituintes e determinação das relações entre as partes e o todo, por
exemplo, diferenciar um método construtor dos demais métodos de uma
classe;
5. Categoria Avaliar: Realização de julgamentos baseados em critérios e
padrões, por exemplo, encontrar um erro de lógica em um trecho de código
dado;
6. Categoria Criar: Juntar elementos para formar um todo coerente e
funcional, por exemplo, aplicar algoritmos conhecidos em uma combinação
não familiar para o aluno;
3.1.2 Taxonomia Afetiva de Krathwohl
Criada juntamente à taxonomia de Bloom, a taxonomia Krathwohl (KRATHWOHL
et al. 1964), também conhecida como taxonomia de Bloom no domínio afetivo, fornece
definições sobre as categorias do domínio afetivo, cujos objetivos descrevem mudanças
de interesse, atitudes e valores, entre outros (DE FARIA, 2011)(DENTON; MCKINNEY;
DORAN, 2005), de acordo com a Tabela 4. As categorias da taxonomia afetiva de
Krathwohl são:
Recepção (atenção): É o nível inicial da taxonomia afetiva, e esta
relacionada com a sensibilidade do aluno à existência de certos fenômenos
e estímulos, e a vontade, ou disposição, de recebê-los ou prestar atenção a
eles;
Resposta: Neste nível, o que interessa são respostas que ultrapassam o
mero atentar-se para o fenômeno. O estudante está suficientemente
motivado e ativamente prestando atenção. Como uma primeira etapa, num
processo de "aprender fazendo", o estudante se compromete em alguma
medida com os fenômenos subentendidos;
Valorização: Neste nível o aluno manifesta um comportamento consistente
em situações apropriadas, vindo a ser percebido como um valor sendo
19
adotado. O comportamento caracterizado por valorização é motivado pelo
comprometimento do indivíduo com o valor subjacente, aceito pelo aluno,
como seu próprio critério de valor;
Organização: À medida que o aluno adquire valores, eles se deparam com
situações em que mais de um valor é pertinente. Estas situações requerem
que o indivíduo organize tais valores em um sistema coesivo;
Caracterização: É o nível mais alto da taxonomia afetiva. O indivíduo já
tem seus valores em uma hierarquia definida, organizados em um sistema
consistente, e já está acostumado a agir de acordo com tais valores.
Tabela 4: Objetivos da taxonomia afetiva (Adaptada de: FONTÃO, 2015)
Dimensão Afetiva
NÍVEIS Objetivos Capacidades a adquirir
A. Recepção (atenção)
Apercebe-se de fatos diversos, (cf. a predisposição para ouvir, para falar, para agir, etc).
Descrever, destacar, escolher, identificar, localizar, manter, nomear, perguntar, responder, seguir, usar, etc.
B. Resposta
Responder a estímulos. Apresentar ideias, questionar, seguir regras.
Ajudar, apresentar, desempenhar, discutir, escrever, estudar, falar, responder, etc.
C. Valorização Atribuir valores diversos a fenômenos, fatos, objetos e comportamentos.
Completar, convidar, comprar, demonstrar, diferenciar, distinguir, dividir, explicar, iniciar, justificar, propor, etc.
D. Organização
Atribuir prioridades a valores. Resolver conflitos. Criar sistemas de valores.
Comparar, completar, concordar, defender, discordar, explicar, formular, generalizar, integrar, (inter)relacionar, modificar, ordenar, organizar, preparar, sintetizar, etc.
E. Caracterização
Adotar sistemas de valores. Por em prática sistemas de valores.
(Inter)agir, argumentar, cooperar, generalizar, integrar, modificar, ouvir, persuadir, propor, questionar, resolver, reformular, seriar, verificar, etc.
3.1.3 Zona de Desenvolvimento Proximal de Vygotsky
A Zona de Desenvolvimento Proximal (ou ZDP) de Vygotsky (VYGOTSKY, 1980)
consiste da distância entre o nível de desenvolvimento real (ou atual), e do nível de
desenvolvimento potencial do aluno (BORGES et al., 2007). O nível de desenvolvimento
real é o conjunto das capacidades, e conhecimentos, que o aluno já desenvolveu e
assimilou até o momento. Este nível é determinado pela capacidade do aluno de resolver
20
sozinho, sem ajuda, os problemas que lhe são propostos. Já o nível de desenvolvimento
potencial, é o conjunto das capacidades e conhecimentos que o aluno pode vir a aprender
com a ajuda de outras pessoas. Este nível é determinado pelos problemas que o aluno
não consegue solucionar sozinho, mas que consegue resolver sob orientação, ou com
ajuda (cooperação) de colegas mais capazes (ZANELLA, 1994).
Desta forma a ZDP é potencializada pela interação social do aluno com outros
indivíduos mais experientes. O nível potencial eventualmente passa a ser o nível real,
como na Figura 3, ou seja, aquilo que o aluno precisou de ajuda para solucionar em dado
momento, ele passa a ser capaz de solucionar sozinho em outro. Portanto na prática o
professor deve estimular o desenvolvimento cooperativo e colaborativo, a fim de conduzir
o aluno no processo de transformação de seu nível potencial em seu nível real.
Figura 3: Zona de desenvolvimento proximal (ZDP, 2015)
No contexto de ensino de programação, a ZDP é o nível de cobertura dos
conceitos que o aluno pode dominar eficientemente e com confiança, com a assistência e
interação do professor, ou mesmo de colegas que saibam mais sobre o assunto. Desta
forma, o conteúdo deve ser quebrado em pedaços menores, para que o aluno consiga
acompanhar o desenvolvimento de novos conceitos (DENTON; MCKINNEY; DORAN,
2005). Deve-se também realizar atividades que envolvam a interação e cooperação entre
21
alunos, para ajudar no desenvolvimento dos conceitos abordados em aula (VYGOTSKY,
1989).
3.1.4 Ritmo de educação de Whitehead
De acordo com Whitehead (WHITEHEAD, 1967), o progresso do aluno não se dá
de forma uniforme e estável, sem distinção causada pela mudança no tipo ou alteração de
ritmo. A vida é essencialmente periódica, compreendendo períodos diários, sazonais, e
anuais. Há também períodos mais sutis, de crescimento mental, com suas recorrências
cíclicas, ainda que sempre diferentes de ciclo para ciclo, as fases subordinadas são
reproduzidas em cada ciclo. Desta forma o ritmo, é essencialmente a transmissão de
diferença em um contexto de repetição. A falta de atenção ao ritmo e à natureza do
crescimento mental é uma das principais fontes de inexpressividade e desmotivação na
educação. Whitehead descreve que um ciclo para aprendizado bem sucedido consiste de
três períodos: romance, precisão, e generalização (WHITEHEAD, 1967 in apud DENTON;
MCKINNEY; DORAN, 2005):
O período de romance é o período onde os alunos devem comparecer à
riqueza de possibilidades inerentes ao novo assunto. Neste período o
conhecimento não é dominado por procedimentos sistemáticos. É o período
da evocação do interesse pelo assunto, em preparação para o período de
precisão.
Durante o período de precisão, os alunos se concentram em dominar os
conceitos, notações, procedimentos e estratégias relevantes. Este período
representa adição ao conhecimento.
No período de generalização, os alunos são orientados a descobrir o valor,
significado e aplicações gerais de o que aprenderam. Este período envolve o
prazer do sucesso, subsequente ao que aprenderam no período de
precisão.
3.1.5 Modelo ARCS de Keller
O modelo ARCS de Keller é um método para melhorar o apelo motivacional de
materiais didáticos (KELLER, 1987)(KELLER, 2000). Ele enfatiza o domínio afetivo do
22
ensino, definindo quatro categorias conceituais que agrupam muitos dos conceitos
relacionados à motivação do aluno, conforme é possível observar na Tabela 5. Primeiro
consiga a Atenção dos alunos, em seguida mostre a Relevância do tópico, então construa
a Confiança deles com exercícios factíveis de crescente complexidade, e por último, dê
aos alunos um sentimento de Satisfação como resultado de tudo o que aprenderam
(KELLER, 1984 in apud DENTON; MCKINNEY; DORAN, 2005).
23
Tabela 5: Categorias do modelo ARCS (Adaptado de: WIKIPEDIA, 2015; KELLER, 1987; KELLER, 2000)
ATENÇÃO RELEVÂNCIA CONFIANÇA SATISFAÇÃO
Capturar o Interesse:
Providenciar novidade
e surpresa.
Relacionar-se com as Metas:
Apresentar objetivos e
propósitos úteis do aprendizado, e
métodos específicos para conquista bem
sucedida.
Requisitos de Aprendizado:
Informar os alunos
sobre os requisitos de aprendizagem e de desempenho, e os
critérios de avaliação.
Reforço Intrínseco:
Incentivar e apoiar o prazer intrínseco da
experiência de aprendizagem.
Estimular Inquérito:
Estimular a
curiosidade, propondo questões ou
problemas a resolver.
Igualar Interesses:
Corresponder objetivos com os
interesses e necessidades dos
alunos.
Atividades de Aprendizado:
Oferecer
oportunidades desafiadoras e
significativas para a aprendizagem bem
sucedida.
Recompensas Extrínsecas:
Fornecer reforço
positivo e feedback motivacional.
Mantenha a Atenção
(Variabilidade):
Incorporar uma variedade de métodos e mídias para atender
às necessidades variadas de alunos.
Relacionar a Experiências
(Familiaridade):
Apresentar conteúdo em formas que sejam compreensíveis e que
sejam relacionadas aos valores e
experiências dos alunos.
Atribuições do Sucesso:
Relacionar o sucesso na aprendizagem com
o esforço pessoal e capacidade dos
alunos.
Tratamento Justo (Equidade):
Manter consistentes
os padrões e consequências para o
sucesso.
Para conseguir a atenção dos alunos o professor deve ser capaz de capturar, e
manter, o interesse e a curiosidade destes. Uma maneira de se capturar o interesse dos
alunos é providenciar novidades ou surpresas durante as aulas, estas que podem variar
desde simples eventos inesperados, como um assovio alto, até táticas mais elaboradas
como o uso de vídeos ou, até mesmo cantar um “macete” para o entendimento do
assunto. Adicionalmente, propor questões ou problemas mentalmente estimulantes para
os alunos resolverem, principalmente no início das aulas, é uma maneira de estimular a
curiosidade dos alunos com relação ao assunto abordado. A atenção dos alunos é obtida
quando se têm o interesse e a curiosidade destes, porém para que esta atenção não seja
perdida, é importante a variação dos métodos e mídias usadas em aula, pois a repetição
leva a perda de interesse.
24
Mesmo que a atenção seja obtida, o interesse é perdido se o aluno não perceber o
valor do tópico, portanto se deve mostrar a relevância do tópico aos alunos. Para fazer
com que os alunos vejam relevância no tópico, o professor deve apresentar os objetivos e
propósitos do tópico, bem como a forma de alcançá-los, correspondendo tais objetivos a
interesses ou necessidades dos alunos. Uma forma de abordar a relevância do assunto
sendo apresentado é relacionar este a experiências e interesses dos alunos, fazendo
analogias a coisas que os alunos conheçam, a fim de transmitir o conteúdo de maneira
compreensível.
Para construir a confiança dos alunos com relação ao conteúdo ensinado, deve-se
ajuda-los a estabelecer expectativas positivas para o sucesso. Normalmente os alunos
tem pouca confiança, pois tem pouco entendimento de o que se espera deles. Ao informar
os alunos sobre o que se espera deles, e quais são os critérios de avaliação, construir a
confiança se torna mais fácil. Adicionalmente, fornecer exercícios, atividades, ou desafios,
factíveis e de crescente complexidade sobre o assunto abordado ajuda no entendimento
do aluno sobre este, e pode melhorar a confiança do aluno. É importante também que o
aluno atribua o sucesso na aprendizagem, com seu esforço e capacidade pessoal. Se o
aluno pensar que, por exemplo, “acertou a questão por sorte”, sua confiança no assunto
dificilmente será conseguida ou mantida.
Se os alunos estão atentos, interessados no conteúdo, e moderadamente
desafiados, então eles estarão motivados a aprender, mas para manter esta motivação é
necessário dar aos alunos um senso de satisfação relacionado ao aprendizado. Esta
satisfação se refere aos sentimentos positivos do aluno em relação a suas conquistas e
experiências de aprendizado. Desta forma deve-se incentivar o prazer intrínseco dos
alunos em relação ao aprendizado, fornecendo reconhecimento e evidencia do sucesso
do aluno. Fornecer recompensas extrínsecas, ou reforços positivos, tanto de forma
substantiva quanto simbólica, também pode gerar satisfação no aluno. Por exemplo,
podem se constituir de notas, privilégios, certificados, ou outros símbolos de conquista.
Por fim, um senso de equidade, ou tratamento justo, é importante. Os alunos devem sentir
que a quantidade de esforço requerida pelo curso foi adequada, que ouve consistência
entre os objetivos, conteúdo, e testes, e que não ouve favoritismo nas avaliações.
25
3.1.6 Nove eventos de ensino de Gagné
Os nove eventos de ensino de Gagné (GAGNÉ, 1992) são um framework que se
correlaciona e aborda as condições de aprendizagem, tendo ênfase no domínio cognitivo
da mesma (DENTON; MCKINNEY; DORAN, 2005). O aprendizado ocorre em uma série
de eventos de aprendizagem, cada um dos quais deve ser realizado antes do próximo
para que o aprendizado ocorra. Da mesma forma, os eventos de ensino devem espelhar
os de aprendizagem (KRUSE, 2008). Na Tabela 6 estão os nove eventos de ensino e os
respectivos processos mentais associados a eles:
Tabela 6: Nove eventos de ensino (Adaptado de: KRUSE, 2008)
Evento de Ensino Processo mental Interno
1 Ganhar a atenção Estímulos ativam os receptores
2 Informar os objetivos aos alunos Cria nível de expectativa para a aprendizagem
3 Estimular relembrança de aprendizado prévio
Recuperação e ativação de memória de curto prazo
4 Apresentar o conteúdo Percepção seletiva de conteúdo
5 Fornecer orientações de aprendizagem
Codificação semântica para a o armazenamento da memória de longo prazo
6 Provocar desempenho (prática) Responde a perguntas para melhorar a codificação e verificação
7 Fornecer feedback Reforço e avaliação do desempenho correto
8 Avaliar desempenho Recuperação e reforço de conteúdo como avaliação final
9 Aumentar a retenção e transferência
Recuperação e generalização da habilidade aprendida para nova situação
Cada evento ao ser executado gera um determinado processo mental relacionado
ao ensino. Estes eventos, apresentados a seguir, devem satisfazer as condições
necessárias para o aprendizado e servir como base para criar o ensino:
1. Ganhar a atenção: Para que qualquer aprendizagem ocorra, primeiramente
professor deve ganhar a atenção dos alunos. A curiosidade motiva os alunos
a aprender, desta forma, iniciar cada aula com uma pergunta instigante, ou
um fato interessante, é uma boa maneira de se conseguir a atenção dos
26
alunos. A variação nas dinâmicas de aula é outro fator importante para que a
atenção dos alunos seja mantida.
2. Informar os objetivos aos alunos: No inicio de cada aula os alunos devem
encontrar uma lista de objetivos de aprendizagem. Normalmente tais
objetivos são apresentados na forma de “Ao concluir esta aula você será
capaz de...”, isto inicia o processo interno de expectativa e ajuda a motivar o
aluno para completar a aula.
3. Estimular relembrança de aprendizado prévio: Associar novas
informações com o conhecimento prévio pode facilitar o processo de
aprendizagem. Codificar e armazenar informações na memória de longo
prazo se torna mais fácil para os alunos quando tais informações estão
relacionadas à suas experiências e conhecimentos pessoais. Uma maneira
simples de estimular a relembrança é para fazer perguntas sobre
experiências anteriores, uma compreensão dos conceitos prévios, ou um
corpo de conteúdo.
4. Apresentar o conteúdo: É neste evento de ensino que o novo conteúdo é
realmente apresentado ao aluno. O conteúdo deve ser fragmentado e
organizado de forma significativa, explicado e então demonstrado. Se
possível, as mídias usadas nas aulas devem variar, incluindo textos,
gráficos, e vídeos.
5. Fornecer orientações de aprendizagem: Para ajudar os alunos a codificar
a informação para o armazenamento de longo prazo, orientação adicional
deve ser fornecida juntamente com a apresentação de novos conteúdos.
Estratégias de orientação incluem o uso de exemplos, exemplos negativos,
estudos de caso, representações gráficas, mnemônicos e analogias.
6. Provocar desempenho (prática): Neste evento de instrução, é exigido do
aluno que pratique a nova habilidade ou comportamento aprendido.
Provocar desempenho oferece uma oportunidade para que os alunos
confirmem seu correto entendimento, e a repetição aumenta ainda mais a
probabilidade de retenção do conteúdo. O professor pede aos alunos que
respondam, demonstrando o entendimento.
7. Fornecer feedback: Conforme os alunos praticam novos comportamentos é
importante que o professor forneça feedback específico e imediato de seus
desempenhos. Contrario de questões em uma avaliação, exercícios nas
27
aulas devem ser usados para fins de compreensão e de codificação, não
para fins avaliativos.
8. Avaliar desempenho: Ao completarem os módulos de ensino, os alunos
devem ter a oportunidade, ou obrigação, de tomar uma avaliação final. Esta
avaliação deve ser concluída sem o recebimento de ajuda, feedback, ou
dicas adicionais.
9. Aumentar a retenção e transferência: O professor fornece praticas
variadas para generalizar as aptidões dos alunos. Programas de formação
eficazes tem um foco no desempenho, incorporando design e mídias que
facilitam a retenção e a transferência para o trabalho. A repetição de
conceitos aprendidos é uma forma testada e aprovada de se ajudar na
retenção de conteúdo.
Seguindo o apresentado, estes eventos podem ser aplicados no ensino de
programação. O primeiro evento, capturar a atenção, funciona de maneira similar ao
modelo de Keller, onde a atenção pode ser capturada de várias maneiras, como
proporcionar algum tipo de surpresa. No segundo evento, informar os objetivos, os alunos
são informados, por exemplo, que ao concluírem a aula eles serão capazes de programar
estruturas de repetição básicas. No quarto evento tais estruturas de repetição são então
apresentadas e demonstradas, e em seguida, no quinto evento, são mostrados exemplos
ou maneiras diferentes de aplicá-las. De maneira similar os demais eventos podem, de
acordo com suas definições, ser usados para o ensino de programação de computadores.
3.1.7 OntoRevPro
Devido à carência de ferramentas com a finalidade de auxiliar na revisão de
programas, foram iniciados estudos para apresentar uma solução abrangente para
auxiliar na revisão de programas. A partir destes estudos, foi feita uma conceituação e
formalização do processo de revisão de programas através de uma ontologia chamada
OntoRevPro (DE FÁTIMA NEVES; COELLO, 2006). O domínio da OntoRevPro é orientar
o aluno na revisão de programas Java, e tem como objetivo apresentar respostas para as
seguintes questões:
1. O que se espera de uma boa revisão?
2. O que deve ser revisado?
3. Como um aluno iniciante em programação pode fazer uma revisão
satisfatória em um programa feito por outra pessoa?
28
A OntoRevPro, sendo uma ontologia, é em essência uma hierarquia de classes,
cada uma das quais, indica um conjunto de conceitos que podem existir em um domínio,
e os atributos que estabelecem relacionamentos entre classes (Lewis et al. 2001 in apud
DE FÁTIMA NEVES; COELLO, 2006). Os conceitos representados pelas classes do
OntoRevPro são os itens que devem ser observados durante a revisão de um programa
Java.
Em aula a ontologia é usada para realizar revisão de programas entre pares de
alunos. Desta maneira um aprendizado de dois sentidos é propiciado, ou seja, o aluno
que revisa aprende ao analisar o programa do colega, e o aluno autor do programa
aprende ao ter seu programa revisado, sendo mostrados os pontos em que podem ser
feitas melhorias.
Uma das formas de se utilizar a OntoRevPro é a disponibilização desta em formato
HTML, na forma de uma lista com tópicos a serem consultados. A hierarquia da ontologia
mostra o que deve ser revisado, mas se necessário, o aluno pode selecionar um item
especifico da ontologia para ver sua descrição e dicas de orientação sobre a revisão de
programas. A ontologia proporciona aos alunos meios para entender o que deve ser
revisado em um programa Java, alem de ajudar a aumentar o entendimento sobre boas
praticas e estilos de programação mais adequados para a linguagem.
3.1.8 Metodologia baseada no Paradigma do Paraquedas
O paradigma do paraquedas é uma abordagem de estudos de sistemas na qual um
ou mais modelos são refinados a fim de se tornarem mais precisos. Modelos são
construídos a partir das observações que podem ser feitas de um sistema, tais
observações determinam os estados e eventos do sistema. Para melhor entender o
paradigma, devemos nos por mentalmente a um certo nível acima do sistema a ser
modelado. Tomando como exemplo a vista superior de um campo de futebol: quando se
está muito acima, o que pode ser percebido é apenas o campo e pessoas se movendo
dentro deste, esta é a primeira abordagem do sistema. Ao descer um pouco, se
aproximando do campo, mais detalhes podem ser percebidos, como a existência de uma
bola, a qual os jogadores passam uns para os outros, e cores diferentes de uniformes,
desta forma o modelo é refinado. Pode-se aproximar do sistema cada vez mais, desta
29
forma refinando gradualmente o modelo, e o tornando mais completo (SARRIA et al.
2009).
A metodologia baseada no paradigma do paraquedas divide o conhecimento de
programação em oito noções:
1. Noção de Sistema: A noção de sistema é ensinada como um conjunto de
elementos interagindo em um domínio muito específico. São dados
exemplos começando pelos mais conhecidos, como o sistema solar, e então
passando para os que os alunos usam no dia a dia, como televisão,
computadores, e videogames. A ideia é mostrar que tudo ao nosso redor é
um sistema, e que a maioria pode ser modelada. É mostrado que programas
de computador são modelos de sistemas reais, e pede-se que os alunos
identifiquem elementos de sistemas e descrevam suas interações.
2. Noção de Observação: Uma vez que os alunos entendem um sistema eles
são capazes de descrevê-lo. Neste ponto estamos interessados nos
elementos, e não no sistema como um todo. Seguindo o paradigma do
paraquedas, se aproxima do sistema e pede-se aos alunos que identifiquem
o que é estático (constantes), e o que se altera (variáveis). Adicionalmente
identifica-se que valores cada elemento pode assumir, o conjunto destes
valores define o tipo de dados destes.
3. Noção de Estado: Se aproximando mais uma vez em um sistema, faz-se
que os alunos percebam que as variáveis as vezes tem um valor, e outras
vezes tem outro valor. O valor de todas as variáveis define o estado do
sistema. Pergunta-se aos alunos, como o sistema muda de um estado para
outro. Eles percebem que certas operações devem ser executadas para que
os valores das variáveis sejam alterados, consequentemente mudando o
estado do sistema. É aqui que a definição do conceito de algoritmo surge: a
sequencia de operações levando a troca de um estado para outro.
4. Noção de Condição: Se o estado do sistema é desconhecido, os alunos
sentem a necessidade de ter uma estrutura de controle para considerar
vários casos. Então é introduzida a noção de condição, iniciando pelas
fundações básicas de lógica proposicional (tabelas verdade e conectivos).
No inicio é usado apenas a estrutura “if<condição>”, para então
introduzir a expressão “else”.
30
5. Noção de Abstração: Quanto mais complexo o problema, maior o código
se torna. Quando os alunos sentirem a necessidade de ter formas
alternativas de programar, que permitam escrever menos linhas de código,
então é ensinado como organizar várias operações em uma única. Agora os
alunos podem construir suas próprias operações utilizando as mais básicas.
Com as novas operações, eles podem construir outras, e assim por diante.
Isto traz a noção de níveis de abstração de uma forma natural. Neste ponto
é feita a primeira avaliação, esta em duas partes, a sem (“prova”), e a com o
computador (“mini projeto”).
6. Noção de Recursão: A recursão, como a forma básica de repetição, é uma
noção de difícil entendimento, portanto é simplificada, inicialmente,
considerando apenas recursão numérica, e é ensinada pelo que ela é, ou
seja, uma chamada de função. Esta noção da abre a possibilidade de se
resolver muitos mais problemas, sendo assim dedica-se um tempo
considerável para os alunos praticarem a recursão.
7. Noção de Iteração: Apesar de a recursão ser a forma mais simples de
repetição por não mudar o estado das variáveis, é mais natural para os
alunos aplicar outras estruturas de repetição que mudem o estado das
variáveis. Estas são chamadas iterações, e possuem diversas formas (for,
while, do-while), com foco na estrutura “while<condição>”. Aqui os
alunos já têm todas as ferramentas para resolveram a maioria dos
problemas, então a segunda avaliação é aplicada.
8. Noção de Abstração de Dados: Esta ultima noção vem da necessidade de
agrupar grandes quantidades de informação. Quando a quantidade de
variáveis necessárias se torna muito grande, se torna inconveniente
manuseá-las, portanto são introduzidas estruturas de dados como listas por
exemplo. Apos esta noção ser concluída é feita a terceira e ultima avaliação.
De acordo com o autor (SARRIA et al. 2009), programação esta além dos
computadores, e desta forma o uso de computadores nas aulas deve ser iniciado na
terceira noção, a noção de estado, e não na primeira. Adicionalmente é recomendado o
uso de ferramentas visuais na aplicação desta metodologia, para manter a atenção dos
alunos, pois em meio à tecnologia atual (videogames, telas touch-screen, etc), o uso de
ambientes textuais deixou de ser conveniente.
31
3.2 COMPARAÇÃO DAS METODOLOGIAS
A classificação e comparação das metodologias encontradas, que são
apresentadas na Tabela 7, foram feitas usando as cinco categorias de classificação: foco,
domínio, abordagem, uso, e ferramenta. A escolha destas categorias se deve a
características identificadas dentre as metodologias estudadas e posteriores discussões
sobre como agrupá-las. Entre os requisitos, sempre que possível, foram levados em conta
as características dos minicursos da OBI na UDESC. As cinco categorias escolhidas
estão explicadas a seguir.
Foco: identifica qual é o foco da metodologia. As possíveis classificações que as
metodologias podem receber neste campo são avaliação, processo, e revisão. As
metodologias classificadas como tendo foco em avaliação são aquelas que definem como
fazer as avaliações, ou questões avaliativas, auxiliando na identificação do nível de
entendimento dos alunos. Já as metodologias classificadas com foco em processo são
aquelas que definem como deve ser feita, ou organizada, a aula em si, dizendo, por
exemplo, em que ponto certos conceitos devem ser ensinados. Por fim as metodologias
classificadas como tendo foco em revisão são aquelas que definem como deve ser feita a
revisão de um programa em determinada linguagem de programação.
Domínio: identifica se a metodologia se encontra no domínio cognitivo ou afetivo
do aprendizado. As metodologias classificadas como estando no domínio cognitivo são as
que fazem definições relacionadas à retenção de conteúdo pelos alunos. Já as
classificadas como do domínio afetivo, fazem definições sobre como manter a atenção e a
motivação dos alunos, para que se concentrem no conteúdo sendo passado. Por fim, as
metodologias classificadas como mistas são aquelas que fazem definições para ambos os
domínios cognitivo e afetivo.
Abordagem: identifica se uma metodologia faz uso de uma abordagem “bottom-
up” ou “top-down”, e há também a possibilidade de tal classificação não se aplicar a
metodologia. As metodologias com uma abordagem “bottom-up” são aquelas em que, por
exemplo, se ensina a programar começando pela linguagem e partindo para a lógica, em
níveis crescentes de complexidade. Já as com uma abordagem “top-down” são aquelas
que, a lógica é ensinada primeiro e, então, a linguagem de programação é introduzida
32
para se aplicar a lógica já abordada (GREYLING; CILLIERS; CALITZ, 2006). Os casos em
que esta classificação não se aplica são os que a metodologia tiver foco em avaliação, ou
estiver puramente no domínio afetivo, impedindo que uma das abordagens de ensino seja
adotada. Para os propósitos de um minicurso da OBI na UDESC, ou mesmo para o
ensino de programação em geral, entende-se que este critério é um fator decisivo na
escolha da metodologia a ser empregada, pois afeta diretamente a forma como a aula
deve ser elaborada.
Uso: identifica o tipo de uso da metodologia, ou seja, para o que, ou como ela é
usada. Neste campo as metodologias podem receber a classificação de metodologia de
construção de objetivos, construção de aulas, ou de abordagem de conteúdos. As
metodologias de construção de objetivos são aquelas usadas na construção, ou definição,
dos objetivos de aula ou de ensino. Já as metodologias de construção de aulas são
aquelas usadas no planejamento das aulas propriamente ditas. Por fim, as metodologias
de abordagem de conteúdo são aquelas que servem como referência para os alunos e/ou
professores de como determinado conteúdo deve ser abordado, por exemplo, como
revisar um programa.
Ferramenta: identifica se alguma ferramenta, ou ferramentas, estão associadas à
metodologia. As metodologias que recebam a classificação “Independente” são aquelas
que não dependem de ferramentas, ou não foram associadas a nenhuma ferramenta nas
fontes pesquisadas. Já as que receberem a classificação “Ferramentas multimídia”, ou
similar, são metodologias que não estão associadas a nenhuma ferramenta específica,
mas que em sua definição fazem recomendações de que tipo de mídia ou ferramenta
deve ser usada em conjunto.
Tabela 7: Classificação das metodologias
METODOLOGIA FOCO DOMÍNIO ABORDAGEM USO FERRAMENTA
Taxonomia de Bloom
Avaliação Cognitiva Não se aplica Construção de objetivos
Independente
Taxonomia de Krathwohl
Processo Afetiva Não se aplica Construção de objetivos
Independente
ZDP de Vygotsky Processo Cognitiva Bottom-up Construção de aulas
Sugere o RemotePP, porem é independente de ferramentas
33
Ritmo de educação de Whitehead
Processo Mista Bottom-up Construção de aulas
Independente
Modelo ARCS de Keller
Processo Afetiva Não se aplica Construção de aulas
Ferramentas multimídia
Nove eventos de ensino de Gagné
Processo Cognitiva Bottom-up Construção de aulas
Ferramentas multimídia
OntoRevPro Revisão Cognitiva Top-down
Abordagem de conteúdos
Web browser e ferramentas de compartilhamento de arquivos
Paradigma do Paraquedas
Processo Cognitiva Top-down Construção de aulas
Sugere ferramentas visuais, porém é independente de ferramentas
Como se pode ver, grande parte das metodologias comparadas tem foco no
processo de ensino, o que pode significar que os autores se preocupam mais com o
planejamento da aula, ou até mesmo que existe uma maior necessidade em corrigir o
processo de ensino nos cursos de programação em geral.
As metodologias estão em sua maioria no domínio cognitivo, indicando uma maior
preocupação dos autores com a retenção de conteúdo do que com a motivação dos
alunos. Isto também pode indicar que existem mais problemas com o entendimento dos
assuntos do que com a motivação nos cursos de programação.
Dentre as metodologias estudadas não existe uma abordagem predominante em
relação às outras. Desta forma, percebe-se que não existe um consenso entre os autores
sobre que abordagem é a mais adequada para o ensino de programação, ou até mesmo
que a abordagem mais adequada a ser escolhida depende do contexto.
O uso das metodologias está focado principalmente no auxílio para construção das
aulas. Percebe-se que esta categoria se relaciona fortemente com a categoria foco, sendo
assim grande parte das metodologias com foco no processo tem seu uso na construção
de aulas, provavelmente pelos mesmos motivos em que o foco está no processo.
Por fim, percebe-se que as metodologias em geral não estão associadas a uma
ferramenta específica mas, por vezes, sugerem que tipo de ferramenta usar. Este
resultado sobre a falta de associação entre metodologias e ferramentas denota que os
34
estudos destas duas abordagens (metodologias x ferramentas) são comumente
desconexos, ou seja, é incomum que o estudo de metodologias esteja associados
diretamente a ferramentas e vice-versa.
3.2.1 Contribuição das metodologias pesquisadas para este trabalho
A seção anterior apresentou as principais metodologias de auxilio ao ensino de
programação encontradas. A taxonomia de Bloom (BLOOM et al. 1956) define seis
categorias do domínio cognitivo e tem foco em como mensurar objetivamente a
aprendizagem dos alunos. A taxonomia associa alguns verbos a cada uma das
categorias, o que auxilia na criação de objetivos de aula e dos exercícios e avaliações
relativos a estas aulas. A taxonomia de Bloom foi a única metodologia encontrada com
foco em avaliação. Ela independe de ferramenta para ser utilizada.
A taxonomia de Krathwohl (KRATHWOHL et al. 1964) foi criada como uma
extensão à Taxonomia de Bloom e atua no quesito motivacional dos alunos. Faz
definições de categorias do domínio afetivo do aprendizado, cujos objetivos descrevem
mudanças de interesse, atitudes e valores. A taxonomia pode ser usada na construção de
objetivos motivacionais para o ensino de programação, em conjunto aos objetivos criados
pela taxonomia de Bloom. Esta metodologia também independe de ferramentas.
A ZDP de Vygotsky (VYGOTSKY, 1980) é definida pela distância entre os níveis de
desenvolvimento real e potencial do aluno, ou seja, a capacidade dos alunos de
resolverem problemas sozinhos ou com ajuda, respectivamente. A metodologia tem foco
no processo de ensino e é usada na construção das aulas. Sugere a quebra do conteúdo
em pedaços pequenos e a realização de atividades que envolvam cooperação entre
alunos. Como a metodologia incentiva a cooperação entre alunos, deve-se
preferencialmente usar uma ferramenta de ensino de programação com suporte a tal
cooperação.
O “ritmo de educação de Whitehead” (WHITEHEAD, 1967), o “modelo ARCS de
Keller” (KELLER, 1987)(KELLER, 2000), e os “nove eventos de Gagné” (GAGNÉ, 1992)
são metodologias muito similares na definição de seus passos, porém em níveis de
complexidade e detalhamento crescentes. Os “nove eventos de Gagné” é o mais
complexo que o “modelo ARCS de Keller”, que por sua vez é mais detalhado que o “ritmo
de educação de Whitehead”. As três metodologias têm foco no processo de ensino e
35
podem ser usadas para auxiliar na construção das aulas para o ensino de programação.
Tanto o “modelo ARCS de Keller” quanto os “nove eventos de Gagné” recomendam o uso
de mídias distintas nas aulas.
A OntoRevPro (DE FÁTIMA NEVES; COELLO, 2006) é uma metodologia usada
para que o aluno entenda o que deve ser revisado em um programa Java. Em aula, a
OntoRevPro é usada na revisão de programas entre alunos, proporcionando um
aprendizado em dois sentidos, ou seja, aprende-se revisando um programa ou tendo seu
programa revisado. Por se tratar de uma metodologia de revisão, tem sua aplicação na
correção de exercícios. Contudo, por ser especificamente sobre revisão de programas na
linguagem Java, a ferramenta a ser usada em conjunto deve suportar tal linguagem.
A metodologia do Paradigma do Paraquedas (SARRIA et al. 2009) diz respeito ao
refinamento gradual de um sistema ou programa. A metodologia tem foco no processo e
construção das aulas e divide o assunto ou conteúdo de uma aula de programação em
oito noções, definindo certa quantidade de aulas necessárias para abordar cada uma. Em
sua definição, a metodologia recomenda o uso de ferramentas visuais nas aulas, a fim de
auxiliar no entendimento do conteúdo pelos alunos. A metodologia do Paradigma do
Paraquedas por definir quantidade de aulas para cada noção, dificilmente poderia ser
usada nos minicursos da OBI, pois extrapolariam o tempo total do disponível para os
minicursos.
3.3 FERRAMENTAS APLICADAS AO ENSINO DE PROGRAMAÇÃO
A busca por trabalhos que apresentassem ferramentas voltadas ao ensino de
programação resultou em um grande numero de artigos. Foi necessária a seleção
daqueles mais relevantes para o objetivo deste trabalho. Os critérios usados para esta
seleção foram os de manter apenas os trabalhos cujas ferramentas pudessem ser
potencialmente usadas nos minicursos da OBI, excluindo os trabalhos cujos resultados
não tenham sido satisfatórios, como ferramentas não testadas, inacabadas, ou cujo foco
estivesse muito diferente do que o desejado.
36
3.3.1 ProgTest
O ProgTest é um ambiente web para submissão e avaliação automática de
trabalhos de programação, baseado em atividades de teste, que fornece apoio
automatizado para avaliar os programas e casos de teste submetidos pelos alunos,
dando-lhes feedback imediato. Para este fim, múltiplas ferramentas de teste estão
integradas ao ProgTest, fornecendo apoio a aplicação de critérios de teste (DE SOUZA et
al. 2012).
O ProgTest tem suas principais funcionalidades acessíveis através de duas visões,
a do professor e a do aluno. Na visão do professor, este pode criar novos cursos,
matricular alunos e definir trabalhos de programação, para os quais, o professor deve
especificar os critérios de teste a serem usados durante a avaliação. Alem disso o
professor deve fornecer um gabarito, consistindo de um programa que implemente a
solução correta para o trabalho, e um conjunto de casos de teste para o programa
fornecido, este devendo estar 100% adequado aos critérios de teste especificados.
Na visão do aluno, este tem acesso a todos os trabalhos associados aos cursos em
que está matriculado, e ao submeter uma solução para um trabalho, o aluno deve enviar
juntamente ao programa, o conjunto de testes utilizado para testa-lo.
O ProgTest então avalia a solução do aluno para o trabalho, comparando os
resultados do programa do aluno e do professor com ambos os conjuntos de teste, e
então calcula uma nota para o trabalho do aluno. Que pode ver o relatório de avaliação de
seu trabalho, alem de outros relatórios fornecidos. O aluno pode também reenviar novas
versões de seu trabalho até conseguir nota máxima.
3.3.2 Alice
Alice é uma ferramenta de ensino de programação que propicia uma experiência
visual e animada em 3D, aumentando o fator motivação dos alunos (SALCEDO; IDROBO,
2011). Através do ambiente visual em 3D, ver Figura 4, a ferramenta visa trazer pessoas
jovens para o mundo da programação. Os conceitos e sintaxe das linguagens de
programação são adquiridos através de exercícios práticos e interação com a ferramenta.
A programação na ferramenta Alice é feita visualmente na forma de “arrastar e soltar”,
37
arrastando itens de um painel para outro, gerando assim o código para os métodos
correspondentes. Os alunos podem ver muitos dos fundamentos de programação
orientada a objetos, como uma representação gráfica completa de um objeto, o
comportamento de um código de repetição, entre outros. Desta forma, por vezes os
conceitos são aprendidos de forma intuitiva através de exercícios desenvolvidos na Alice.
Figura 4: Ferramenta Alice
3.3.3 AlgoWeb
O AlgoWeb é um ambiente web composto de quatro partes, o portfólio de
problemas, que é um conjunto de problemas algorítmicos, um editor/interpretador de
algoritmos, uma ferramenta de avaliação de soluções, e uma interface do professor
(DORNELES; PICININ; ADAMI, 2010).
38
O portfólio de problemas possui um grande conjunto de problemas algorítmicos,
que cobrem um programa de estudos completo para um curso introdutório de
programação. Cada problema vem com alguns exemplos de dados de entrada e de saída,
que são usados pelo ambiente para checar a solução para determinado problema. O
portfólio de problemas é armazenado em um banco de dados MySQL. Uma vez que um
problema é selecionado, o ambiente apresenta uma descrição para tal, incluindo um
exemplo de dados de entrada e o correspondente dado de saída.
O editor/interpretador de algoritmos tem um sistema de destacamento de sintaxe
para Português estruturado, tal função ajuda que os usuários identifiquem erros de
digitação ou construções inválidas de nomes. O usuário pode testar sua solução
utilizando o interpretador fornecido, e este por sua vez, antes de executar o código,
garante que o algoritmo seja lexicamente e sintaticamente correto, caso contrário,
mensagens de erro aparecem indicando o erro no código.
A ferramenta de avaliação de soluções, funciona de maneira similar à do ProgTest,
comparando a solução e os casos de uso do aluno com a presente no portfólio de
problemas. Um ranking das soluções mais eficientes, e seus respectivos autores, é
armazenado para cada problema, servindo de motivação para os alunos a melhorarem a
eficiência e eficácia de seus algoritmos.
A interface do professor é por onde este acompanha o progresso do aprendizado
dos alunos, e avalia os problemas encontrados pelos alunos ao escreverem algoritmos. A
interface do professor fornece uma lista de alunos que solucionaram determinado
problema, uma lista de problemas solucionados por determinado aluno, e todas as
versões salvas de um determinado algoritmo com o respectivo numero de operações
executadas, no momento que reconhecido como correto pelo ambiente.
3.3.4 Scratch
O ambiente Scratch, desenvolvido pelo MIT (Massachusetts Institute of
Technology), traz uma linguagem de programação através do conceito de código
orientado a design, onde a programação assume uma abordagem de “arrastar e soltar”,
uma maneira totalmente visual de se programar, e enfatiza a manipulação de mídias,
criação de histórias animadas, jogos e apresentações interativas. Projetada para estimular
39
o uso de uma abordagem de aprendizagem em que os alunos estão constantemente
reavaliando suas decisões, explorando novos caminhos e imaginando novas
possibilidades (SCAICO et al., 2013)(MOTA et al., 2014). Os programas são construídos
por meio da montagem de pilhas de blocos de comandos coloridos, eliminando problemas
de sintaxe e incentivando a exploração do ambiente, sua interface pode ser vista na
Figura 5.
Figura 5: Interface do Scratch
O Scratch possui uma sintaxe simples, e fornece um ambiente que possibilita a
construção de projetos como se fossem histórias animadas ou jogos, tornando fácil o
desenvolvimento de projetos no ambiente. Dentre os blocos de comandos do Scratch
estão inclusas construções de repetição, condicionais, sons, variáveis entre outros, o que
permite a introdução de conceitos de programação, muitas vezes considerados difíceis
para os alunos iniciantes em programação, de forma natural e descontraída. O Scratch
40
tem sua versão online, e uma versão offline para download, ambas disponiveis no website
do Scratch – MIT.
3.3.5 App Inventor para Android
O App Inventor para Android, desenvolvido pela Google, é um ambiente para o
desenvolvimento de aplicações Android, muito similar ao ambiente Scratch. Possui uma
interface de programação em blocos de comandos, utilizando a abordagem de arrastar e
soltar para o desenvolvimento dos aplicativos. Os aplicativos desenvolvidos na ferramenta
são aplicativos Android completos, que podem ser instalados e publicados, o que da aos
alunos um senso maior de envolvimento, devido a habilidade de criar aplicações que eles
poderão usar fora da sala de aula (KARAKUS et al. 2012). O App Inventor para Android é
uma ferramenta online acessível por navegadores web. Sua interface pode ser vista na
Figura 6.
Figura 6: App Inventor para Android
41
3.3.6 CIFluxProg
O CIFluxProg é composto de dois módulos de desenvolvimento, um para a criação
de Fluxogramas e outro para a criação de algoritmos em Portugol, junto de um compilador
e um interpretador. Desta forma o CIFluxProg permite que soluções sejam criadas e
testadas tanto na forma de Fluxogramas quanto em pseudocódigo, em um ambiente
visual de desenvolvimento. A ferramenta permite a execução das soluções tendo uma
visualização do resultado ou dos erros cometidos, isto torna mais simples para os alunos
a interação e o entendimento dos processos de criação de soluções de problemas
computacionais (DE SANTIAGO; DAZZI, 2004).
O módulo de Portugol foi desenvolvido para os alunos com maior facilidade de
trabalhar, e de entender a lógica das soluções em ferramentas textuais. O modulo
apresenta uma caixa de texto para a edição de códigos, uma barra de estruturas, e uma
barra de menus. Já o modulo de Fluxogramas permite a criação de soluções na forma de
Fluxogramas, de maneira visual e de fácil manipulação. O interpretador usado para
executar as soluções em Fluxogramas é o mesmo usado para as soluções em Portugol,
sendo assim, toda solução criada em qualquer um dos módulos pode ser aberta e editada
no outro.
3.3.7 SACI (OBI)
O SACI é um ambiente de aprendizagem online, disponibilizado pela OBI,
desenvolvido para o ensino de Programação de Computadores. No momento está
disponível um curso destinado a iniciantes, sem experiência em programação (SACI,
2015). O curso é composto de aulas com vídeos explicativos e diversos exercícios.
Atualmente com quatorze aulas, o conteúdo do curso, em Javascript, já permite resolver
diversos problemas de provas passadas da OBI.
Por se tratar de um ambiente web, não é preciso instalar o sistema em um
computador para utilizá-lo. Basta ter acesso à internet para carregar o conteúdo das aulas
em um navegador web, como Firefox, Chrome, ou outros, funcionando inclusive nos
navegadores web de dispositivos móveis, sem a necessidade de nenhuma adaptação ou
42
configuração extra. A interface do ambiente, conforme apresentado na Figura 7, é toda
em português, desde o conteúdo das aulas até as mensagens de erros de sintaxe do
editor.
Figura 7: Ambiente SACI
O ambiente SACI, também permite que professores criem seus próprios cursos,
com suas respectivas aulas. Cada aula pode ter conteúdo escrito, exercícios, e até
mesmo um vídeo, de acordo com o que o professor julgar necessário. Para que o aluno
tenha acesso a estes cursos, basta que este tenha uma conta no ambiente SACI, e que o
professor lhe forneça o link do curso. Existe também a possibilidade de o professor fazer
o download do código do sistema, podendo assim organizar cursos em um servidor
próprio, ou até mesmo disponibilizar o sistema para ser usado de maneira offline.
Vale ainda mencionar, sobre o ambiente TOBI (Treinamento para a Olimpíada
Brasileira de Informática), também da OBI, destinado a quem já tem conhecimento básico
em programação, e quer aprender técnicas avançadas. Para se usar o TOBI é necessária
a instalação de um compilador no computador sendo usado. O TOBI é uma plataforma
web que contém todos os problemas da OBI e é organizado da seguinte maneira (TOBI,
2015):
43
Capítulo: cada capítulo é composto por diversas seções, o usuário só pode
acessar um capitulo quando terminar todas as seções do capitulo anterior;
Seção: contém um texto introdutório sobre o assunto abordado nesta seção e
problemas da OBI que podem ser resolvidos utilizando esta teoria.
Problemas Obrigatórios: problemas que precisam ser resolvidos para finalizar
uma seção e avançar para a próxima. Para cada problema é possível ver seu
histórico de submissão e, ao resolver o problema terá uma explicação da
solução esperada;
Problemas Sugeridos: são problemas opcionais que podem ser usados para
aperfeiçoar o assunto.
Como já mencionado, o TOBI tem foco em quem já tem conhecimento básico de
programação e quer aprender técnicas avançadas, desta forma este ambiente, apesar de
interessante, não se encaixa no foco deste trabalho, o ensino introdutório a programação
de computadores.
3.4 COMPARAÇÃO DAS FERRAMENTAS
A classificação e comparação das ferramentas encontradas foram feitas usando as
cinco categorias de classificação: apresentação, conexão, linguagem, colaboração, e
disponibilidade. A escolha destas categorias se deve a características identificadas dentre
as ferramentas apresentadas e posteriores discussões sobre como agrupá-las. Entre os
requisitos, sempre que possível, foram levados em conta as características dos
minicursos da OBI na UDESC. As cinco categorias estão explicadas a seguir.
Apresentação: este campo de classificação se faz importante, pois reflete
diretamente em como o aluno interage com a ferramenta, influenciando a maneira como
esta deve ser usada em uma aula. Diz respeito à forma em que a ferramenta apresenta o
conteúdo, podendo ser de forma visual, textual ou mista. As ferramentas classificadas
como sendo do tipo visual são aquelas em que o foco da ferramenta está em
programação visual, como por exemplo, construção de fluxogramas. Já as ferramentas do
tipo textual são aquelas em que a programação é feita de forma “convencional”, ou seja,
escrevendo o código (ou pseudocódigo) do algoritmo a ser implementado. As ferramentas
44
classificadas como mistas são aquelas que possuem características tanto visuais quanto
textuais.
Conexão: como o objetivo da busca e classificação das ferramentas é encontrar
ferramentas que possam ser usadas nos minicursos da OBI na UDESC, a forma de
acesso a estas é um fator de importância. Esta classificação diz respeito à necessidade
ou não da ferramenta de possuir conexão com a internet, e se esta é uma ferramenta web
ou deve ser instalada no computador para ser utilizada. As ferramentas podem ser
classificadas como Online (Web), caso deva ser acessada usando um navegador web,
Online (PC), caso a ferramenta seja instalada no computador e necessite conexão com a
internet, e Offline, caso não necessite de conexão com a internet. De acordo com esta
classificação pode ser determinado, por exemplo, que a ferramenta será utilizada apenas
em sala de aula, ou que os alunos poderão utiliza-la também em suas casas para resolver
exercícios passados em aula, e até mesmo continuar praticando após a conclusão dos
minicursos.
Linguagem: identifica quais linguagens são abordadas por cada ferramenta. Como
um dos objetivos dos minicursos da OBI na UDESC é preparar os alunos para
participarem na OBI, cujos problemas podem ser submetidos em um número limitado de
linguagens, ou seja, C, C++, Pascal, Python, Java ou Javascript, tal classificação é
necessária, pois ajuda a determinar a relevância da ferramenta para o contexto da OBI.
Colaboração: identifica se a ferramenta tem capacidade de propiciar um ambiente
de colaboração entre os alunos, ou se esta é para uso individual dos mesmos. A
capacidade ou não de colaboração propiciada pela ferramenta influencia em como e quais
metodologias serão utilizadas junto à mesma nos minicursos. Vale também salientar que
a competição da OBI é individual, mas atualmente nos minicursos os alunos são
incentivados ao trabalho colaborativo, em duplas ou equipes, como estratégia de
aprendizagem.
Disponibilidade: este campo identifica se a ferramenta esta disponível para ser
utilizada. Este é um fator de grande importância, pois identifica se a ferramenta pode ou
não ser adquirida para uso nos minicursos da OBI. A Tabela 8 contém as classificações
das ferramentas que se encontram atualmente disponíveis para uso e/ou obtenção
(apenas 7 de um total de 13 ferramentas analisadas). A tabela completa, com a análise
das 13 ferramentas é apresentada no Apêndice A.
45
Tabela 8: Classificação das ferramentas
FERRAMENTA APRESENTAÇÃO CONEXÃO LINGUAGEM COLABORAÇÃO DISPONIBILIDADE
ProgTest Textual Online
(Web)
Java Individual Disponível
Alice Visual Offline Pseudo Individual Disponível
Scratch Visual Online (Web) e Offline
Pseudo Individual e Colaborativo
Disponível
App Inventor para Android
Visual Online (Web)
Pseudo Individual Disponível
AlgoWeb Textual Online (Web)
Pseudo Individual Disponível
CIFluxProg Mista Offline Pseudo Individual Disponível (via email)
SACI (OBI) Textual Online (Web) e possibilidade de Offline
Javascript Individual Disponível
Considerando-se a tabela completa apresentada no Apêndice A, dentre as
ferramentas pesquisadas não existe predominância com relação ao tipo de
apresentação, com a quantidade de ferramentas visuais sendo levemente inferior à de
textuais. Percebe-se então, a falta de consenso sobre que meio de apresentação é o mais
adequado para o ensino de programação.
As ferramentas em sua maioria tem algum tipo de conexão com a internet, dentre
as quais a maioria é uma ferramenta web, o que evidencia o crescimento da opção de
desenvolvimento de aplicações para a web, inclusive na área de ensino de programação.
A grande maioria das ferramentas de ensino de programação encontradas não
utilizam uma linguagem de programação específica, e optam pelo uso de pseudo
linguagens. Tal predominância pelo uso de pseudo linguagens indica que os autores em
geral se preocupam mais com o ensino da lógica do que com o ensino de uma linguagem
de programação especifica.
As ferramentas em geral não propiciam um ambiente de colaboração entre os
alunos, e são em sua maioria de uso individual.
46
Por fim, com relação à disponibilidade e levando em conta o Apêndice A, pode-se
ver que a maioria das ferramentas está disponível (um pouco mais da metade, ou seja, 7
num total de 13), seja por conta da licença de uso, ou mesmo por conta do autor não a ter
disponibilizado.
3.4.1 Contribuição das ferramentas pesquisadas para este trabalho
A seção anterior apresentou as principais ferramentas de auxilio ao ensino de
programação encontradas. O ProgTest (DE SOUZA et al. 2012) é um ambiente web
capaz de fazer avaliação automática de trabalhos de programação dos alunos e, dar-lhes
feedback imediato na forma de um relatório de avaliação para o trabalho, incluindo uma
nota para este. O aluno é capaz de ver o relatório de avaliação de seu trabalho, e tentar
refazer e reenviar o trabalho até conseguir nota máxima. No âmbito de auxilio ao ensino
de programação, o ProgTest tem seus méritos no quesito de fornecer avaliação
automática e imediata para os alunos, permitindo que dediquem mais tempo praticando e
melhorando seus programas. Outro ponto positivo é o da linguagem de programação Java
no sistema, pois esta é uma das linguagens permitidas para a submissão de problemas
nas provas da OBI. Porém, a ferramenta, por ter foco na avaliação de trabalhos e
exercícios de programação, pouco influencia na forma como a aula de programação
propriamente dita é aplicada.
O AlgoWeb (DORNELES; PICININ; ADAMI, 2010) é uma ferramenta similar ao
ProgTest no quesito de ter foco na correção de trabalhos e exercícios de programação,
com a vantagem extra de possuir um editor/interpretador de algoritmos embutido. No
entanto, além da desvantagem apresentada no ProgTest, a ferramenta AlgoWeb tem a
desvantagem de trabalhar com Português Estruturado (pseudo linguagem), sendo
necessário transferir o ensino para uma das linguagens suportadas pela OBI.
Ambas as ferramentas Alice (SALCEDO; IDROBO, 2011) e Scratch (SCAICO et al.
2013)(MOTA et al., 2014) utilizam apresentação visual na forma de arrastar e soltar para
a criação de algoritmos, algo que torna mais simples o ensino da lógica de programação.
Estas ferramentas servem para auxiliar a aula propriamente dita, e permitem que o ensino
seja feito de forma descontraída, abordando a lógica de programação de forma ótima. O
47
contraponto do uso destas ferramentas é que o ensino de programação é feito em pseudo
linguagem, portanto ainda seria necessário ensinar uma das linguagens de programação
da OBI, algo que o tempo dos minicursos não permite.
A ferramenta App Inventor para Android (KARAKUS et al., 2012)possui
características positivas similares às ferramentas Alice e Scratch, com a mesma
desvantagem. A ferramenta possui o fator positivo extra de que aplicativos desenvolvidos
na ferramenta são aplicativos Android completos, que podem ser instalados e publicados,
o que permite seu uso em situações reais em dispositivos móveis. Algo que não ocorre
nas ferramentas Alice e Scratch, em que os códigos podem ser utilizados apenas na
própria ferramenta.
A ferramenta CIFluxProg permite que a programação seja feita tanto de maneira
visual via fluxogramas, quanto de maneira textual via pseudocódigo. A vantagem da
ferramenta é a facilidade no entendimento da lógica ao relacionar/comparar o fluxograma
de um algoritmo com sua versão em pseudocódigo. A ferramenta tem as desvantagens
de funcionar apenas com pseudo linguagem, além do fato que fluxogramas são pouco
utilizados atualmente para o ensino de programação (DE SANTIAGO; DAZZI, 2004) .
Por fim, a ferramenta SACI (SACI, 2015) é um ambiente web que possui um
interpretador de Javascript, uma das linguagens da OBI. Adicionalmente, existe certa
facilidade de se adicionar novas aulas ao ambiente, além de permitir o uso de vídeos nas
aulas. Dentre as possíveis alternativas para uso da ferramenta SACI estão: o uso
exclusivo da ferramenta nas aulas e a combinação com outra ferramenta com suporte a
uma pseudo linguagem.
4 FERRAMENTA PROPOSTA
Após o estudo das metodologias e das ferramentas apresentadas, percebeu-se
que é possível utilizar mais de uma metodologia combinada com mais de uma ferramenta.
Por exemplo, seria viável utilizar a taxonomia de Bloom para exercícios e afins, e escolher
os nove eventos de Gagné para o planejamento do conteúdo das aulas. Partindo deste
raciocínio a escolha das metodologias e ferramentas deixa de ser uma questão trivial. No
48
inicio desta pesquisa, foram identificadas características desejáveis para uma ferramenta
a ser aplicada nos minicursos da OBI na UDESC. Estas características estão replicadas
na Tabela 9, na forma de requisitos da ferramenta.
Tabela 9: Resumo dos requisitos para ferramenta aplicada em minicursos da OBI
Característica Requisito
Público alvo iniciante Conteúdo a partir do básico
Linguagens de programação C, C++, Pascal, Python, Java ou Javascript
Cursos de curta duração Ferramenta simples de usar
Corretor automático de códigos
Turmas com muitos alunos Ambiente web
Controle e acompanhamento do
aprendizado
Resumidamente, deve ser voltada para iniciantes em programação, deve aceitar
uma das linguagens da OBI, ser em ambiente web e possuir um corretor automático de
códigos.
4.1 PROPOSTA PRELIMINAR: USO DO AMBIENTE SACI
Observou-se que a ferramenta SACI é a mais completa dentre as estudadas no
contexto dos minicursos da OBI na UDESC, pois além de suportar uma das linguagens da
OBI (Javascript), seu ambiente permite não só testar os programas na forma de
exercícios, mas também ter acesso aos conteúdos da aula simultaneamente. Esta
característica levou a escolha da ferramenta SACI para uso nos minicursos da OBI na
49
UDESC. Adicionalmente foi planejada a adaptação do sistema para que, além de
Javascript, este possa aceitar também o uso da linguagem de programação C.
Neste sentido, foi realizado contato com os autores do projeto SACI com relação à
obtenção dos códigos fonte do ambiente e a permissão para seu uso na UDESC. No
entanto não obtivemos resposta dos autores do projeto SACI, tornando impossível realizar
as adaptações no ambiente.
Desta forma optou-se pela criação de um novo ambiente, com base nas
características do SACI. O novo ambiente tem sua interface desenvolvida com base nos
moldes da OBI e foi feito de forma a aceitar o uso da linguagem de programação C. A
escolha desta linguagem tem vários motivos. Além de ser a linguagem na qual os
minicursos da OBI na UDESC se baseiam atualmente e ser uma das linguagens aceitas
na OBI, é uma das principais linguagens de programação ensinadas da UDESC (PPC-
BCC, 2010), é uma linguagem de programação largamente utilizada, sua sintaxe se
assemelha à de diversas outras linguagens de programação, e pode servir como uma
base para que o aluno aprenda outras linguagens no futuro (MERCÊS, 2012).
Os detalhes do projeto desta nova ferramenta são apresentados nas seções a
seguir.
4.2 PROJETO DA NOVA FERRAMENTA
A partir da decisão de que seria desenvolvida uma nova ferramenta, inspirada no
ambiente SACI mas com corretor de códigos em linguagem C, partiu-se para a
elaboração do projeto.
A proposta consiste na criação de um ambiente web que permita ao aluno seguir o
conteúdo das aulas enquanto tem acesso direto a uma interface para aplicar os conceitos
de programação que estão sendo ensinados, ou seja, a ferramenta disponibiliza o
conteúdo e exercícios de uma aula e, simultaneamente permite que o aluno resolva tais
exercícios de programação, testando-os e submetendo-os para correção automática
dentro do mesmo ambiente.
50
Como diferenciais em relação ao ambiente SACI, esta nova ferramenta tem, além
do corretor de códigos em C, um ambiente dedicado ao professor onde é possível
gerenciar cursos, aulas e alunos. Atualmente a ferramenta SACI permite a inclusão de
novos cursos e aulas, porém é necessário criar uma estrutura de diretórios e arquivos
rigorosamente estruturados e uni-los num arquivo compactado para que possa ser
disponibilizada no ambiente. Isto torna a tarefa de construção de aulas um tanto
trabalhosa e pouco amigável para o professor.
Assim sendo, foram elaborados os artefatos do projeto de software. Para
especificação de requisitos, foram criados casos de uso. Em seguida foi elaborado o
projeto da interface. Após isso, criou-se o modelo do banco de dados e, por fim foi
decidido como implementar o corretor automático de códigos.
4.2.1 Casos de Uso
Um caso de uso descreve a sequência de eventos de um ator que usa um sistema
para completar um processo. É uma técnica de modelagem usada para descrever o que
um novo sistema deve fazer, e descreve as operações típicas que o sistema deve cumprir
para cada usuário. Cada caso de uso deve descrever somente uma funcionalidade ou
objetivo do sistema da maneira mais clara o possível, de modo que seja de fácil
compreensão para os leitores (MACORATTI, 2015). Sendo assim, os casos de uso
devem ter nomes curtos que os identifiquem, normalmente na forma de verbo +
substantivo. Os componentes de um modelo de casos de uso são: o ator, os casos de
uso, e o sistema a ser modelado. O ator é uma entidade externa ao sistema que participa
de um ou mais casos de uso, ele tipicamente solicita ações ou eventos do sistema. Já os
casos de uso, são os eventos, ou sequencia de eventos, feitos por um ator no sistema.
Para facilitar a visão geral do sistema é comum representar os casos de uso na
forma de diagramas. Nestes diagramas os casos de uso são representados por elipses e
o ator por um boneco, com setas, ou linhas, indicando suas relações.
Deste modo, foi criado um diagrama dos casos de uso do sistema, apresentado na
Figura 8, definindo de maneira simplificada as possibilidades de interação entre os
usuários e o ambiente.
51
Figura 8: Diagrama de Casos de uso do sistema
Como visto nos casos de uso, o ator aluno deve ter a possibilidade de visualizar
aulas e respectivos exercícios, submeter tais exercícios para avaliação, e visualizar que
aulas já completou. Vale esclarecer que considera-se completa a aula na qual o aluno
tenha submetido um exercício e este tenha sido aceito, ou seja, que o exercício esteja
com a resposta correta. Já o professor tem a capacidade de cadastrar alunos no sistema,
criar cursos, aulas e respectivos exercícios. O professor deverá também visualizar os
exercícios submetidos pelo aluno, e por fim visualizar que aulas os alunos completaram.
4.2.2 Projeto da interface
A interface do aluno se baseia no ambiente SACI, com uma área dedicada para o
conteúdo da aula de um lado, e uma área com o editor de código e o visualizador de
resultados de execução, do outro. Com relação à edição de códigos, o aluno tem duas
possibilidades: apenas testar ou submeter seu código para avaliação. Na primeira opção,
de testar o código, o aluno fornece um arquivo de entrada na área correspondente no
ambiente, de modo a visualizar seu funcionamento. Neste caso, o código não é submetido
para avaliação. Já na opção de submeter o código para ser avaliado, o programa é
testado com um arquivo de entradas previamente fornecido pelo professor. Nesta
52
situação, os resultados da execução do programa são avaliados, comparando-os com os
resultados esperados para o exercício, também fornecidos pelo professor. O aluno é
então informado se seu código está ou não correto.
O ambiente emprega o uso de uma das linguagens permitidas na OBI, a linguagem
de programação C. Existe também, uma interface para o professor, na qual este pode
cadastrar cursos, adicionar aulas a estes cursos, cadastrar alunos e visualizar cursos e
alunos inscritos. Embora este projeto seja inspirado no ambiente SACI, ele possui
características novas em relação ao original, como é o caso da linguagem de
programação C e da interface do professor.
4.2.2.1. Esquema front-end e back-end
O projeto para o desenvolvimento do novo ambiente foi dividido de forma geral na
criação do front-end, contendo as interfaces do aluno e do professor, e o back-end
contendo o banco de dados, os arquivos submetidos pelos alunos, e os arquivos das
aulas. Como pode ser visto na Figura 9:
Figura 9: Esquema front-end e back-end
Front-end:
o Interface dos alunos:
Selecionar aulas;
53
Mostrar que aulas o aluno já concluiu;
Interface baseada no SACI para apresentar as aulas e exercícios;
o Interface do professor:
Pagina para adicionar aulas/alunos, e para visualizar as
submissões dos alunos;
Back-end:
o Sistema para compilar, executar e corrigir (de maneira simples) os
códigos que alunos submetem para as soluções de exercícios;
o Banco de dados para armazenar dados de usuários:
Informações de usuário (logins, senhas, e etc);
Aulas completadas pelos alunos;
Códigos das ultimas submissões dos alunos;
o Arquivos de aulas.
A partir do esquema elaborado, foram planejados tanto a estrutura navegacional quanto os projetos da interface, seja do professor ou do aluno.
4.2.2.2. Estrutura navegacional
O esquema para a estrutura navegacional do ambiente, apresentado na Figura 10,
define a hierarquia das operações possíveis a serem realizadas pelos usuários no
ambiente web. Esta hierarquia condiz com menus e sub-menus, ou os passos
necessários para realizar uma operação, presentes no ambiente.
54
Figura 10: Estrutura navegacional simplificada do ambiente
Com exceção do primeiro passo que é o login, a estrutura do ambiente é
diferenciada entre o usuário aluno e o usuário professor. No caso do aluno, este deve
selecionar a aula que deseja visualizar, para então ser capaz de submeter um exercício
para tal aula. Já para o professor tem a opção de visualizar os alunos inscritos e de
gerenciar cursos, onde pode cadastrar alunos e gerenciar aulas. Na opção de gerenciar
aulas, o professor terá a capacidade de criar ou remover aulas.
Os próximos passos no desenvolvimento do ambiente foram o projeto das
interfaces do aluno e do professor, bem como a modelagem do banco de dados do
ambiente.
4.2.2.3. Projeto da interface do aluno
Antes de explicar o projeto da interface, vale esclarecer o modelo de problemas
usados nas competições da OBI. Como ocorre em outras competições de programação,
todos os problemas possuem uma tarefa bem definida a ser escrita em uma linguagem de
55
programação, bem como exemplos de entrada de dados e exemplos de saída. Os
competidores podem então testar seus códigos usando tais exemplos de entrada e saída,
até ficarem satisfeitos com o programa, para então submetê-lo para avaliação. Quando o
programa é submetido, ele é testado no com um conjunto de entrada mais completo e
comparado a respectivas saídas esperadas. Da mesma forma, o ambiente desenvolvido
segue o mesmo padrão.
Para a criação da interface do aluno foi usada como base a interface do ambiente
SACI que, de acordo com a Figura 11, é composta de maneira geral por três elementos,
uma área superior, a área central de conteúdo, e a área de trabalho na parte inferior. A
área superior informa que aula o aluno esta vendo no momento, permite selecionar outra
aula, com os links para aula anterior e para a próxima aula, e informa quem é o usuário
atualmente logado. A área de conteúdo é onde a aula em si é apresentada e os exercícios
são passados para o aluno, o conteúdo é subdividido em abas e uma subárea para um
vídeo, caso exista, é mostrada. Já a área de trabalho é composta das janelas de entrada,
programa, e saída, que devem ser usadas para resolver os exercícios passados e
visualizar os resultados.
Figura 11: Principais áreas da ferramenta SACI
Desta forma a interface do aluno criada foi composta de maneira similar, com três
áreas equivalentes, porém reorganizadas, de acordo com a Figura 12. Inicialmente foram
56
consideradas duas formas de organizar a interface do aluno. A primeira, idêntica ao SACI,
com o conteúdo em cima e a área de trabalho em baixo, e a segunda com estas áreas
lado a lado. Foi então decidido que as áreas de conteúdo e de trabalho não estariam mais
“empilhadas”, mas sim lado a lado. Isto facilita a visualização do conteúdo da aula ao
proporcionar uma área maior de exibição. Além disso, mantém uma área suficiente para a
edição de códigos na área de trabalho. Adicionalmente, a área superior tem a seleção das
aulas de forma diferente, com uma caixa seletora ao invés de links para a aula anterior e
próxima aula, permitindo ao aluno selecionar diretamente que aula deseja visualizar. Com
a aula selecionada na caixa seletora, a área de conteúdo carrega automaticamente a aula
selecionada.
Figura 12: Interface do aluno
Com relação à área de conteúdo, esta ainda contém subdivisões em abas,
definidas pelo professor, para separar o conteúdo e os exercícios. A área de trabalho
contém apenas dois botões: um para testar o código escrito e outro para submeter tal
código para avaliação. A função de teste, acionada ao clicar no botão “Testar”, executa o
código usando a entrada fornecida pelo aluno para então exibir os resultados obtidos, que
podem ser mensagens de erro, alertas e a própria saída do programa escrito. Já a função
de submissão de códigos, acionada ao clicar no botão “Submeter”, funciona de maneira
similar, porém utilizando arquivos de entrada e saída fornecidos pelo professor para o
exercício da aula. O código do aluno é compilado e executado usando o texto no arquivo
de entrada, e sua saída é comparada com a do arquivo de saída, e então o aluno recebe
57
uma mensagem informando os alertas e erros de compilação, caso existam, e se a
“resposta” para o exercício esta certa ou errada, ou seja, se o código está certo ou errado
em relação ao que foi pedido no exercício.
4.2.2.4. Projeto da interface do professor
A interface do professor tem como principal finalidade realizar o cadastro de
alunos, cursos e aulas, e visualizar os alunos cadastrados em cada curso. A interface tem
apenas um menu lateral que dá acesso as opções de cadastro e visualização, como pode
ser visto da Figura 13.
Figura 13: Interface do professor, cadastro de alunos.
O cadastro dos alunos é feito pelo professor, e não pelos alunos em si,
principalmente por uma questão de controle, pois o objetivo é que a ferramenta seja
usada em turmas fechadas de um minicurso de programação da OBI na UDESC. Na
interface de cadastro de alunos, além das informações básicas do aluno (nome, usuário e
senha) o professor deve também selecionar em que curso o aluno será cadastrado.
As interfaces para o cadastro de cursos e para o cadastro de aulas são muito
similares à do cadastro de alunos, com a diferença de que no cadastro de aulas o
professor deverá também fornecer os arquivos de aula a serem utilizados no sistema. As
58
interfaces de cadastro de cursos e de alunos podem ser vistas nas Figuras 14 e 15,
respectivamente.
Figura 14: Interface do professor, cadastro de curso
Como pode ser visto, a interface de cadastro de cursos possui apenas um campo,
o nome do curso. Embora bastante simples, esta interface é uma parte critica no processo
de cadastro de aulas e alunos, pois ambos necessitam de cursos previamente
cadastrados.
59
Figura 15: Interface do professor, cadastro de aulas.
Na interface de cadastro de aulas o professor deve primeiramente selecionar a que
curso a aula pertence e informar o nome da aula. Em seguida devem ser selecionados os
arquivos de aula para upload. Estes arquivos representam o conteúdo da aula e os
arquivos de entrada e saída, usados pelo corretor de códigos na interface do aluno. O
arquivo HTML fornecido pode ser feito da maneira que o professor desejar, porem o
sistema possui um arquivo HTML padrão que separa o conteúdo em abas. Para usar esta
separação por abas, basta que o professor edite o arquivo padrão e inserindo o conteúdo
de sua aula nas áreas correspondentes a cada aba, indicadas no arquivo.
4.2.3 Modelo do Banco de Dados
A fim de armazenar os dados necessários para as funcionalidades do ambiente foi
modelado um Banco de Dados. A partir do planejamento do ambiente foram definidas
quais tabelas, e relações entre tabelas, o banco de dados deveria possuir. Desta forma
foram feitas as tabelas principais, PROFESSOR, ALUNO, CURSOS, e AULAS, e as tabelas de
relacionamento entre elas, PROF_CURSOS, CURSO_AULAS, CURSO_ALUNOS, e
ALUNO_AULAS, de acordo com o esquema conceitual exibido na Figura 16.
60
Figura 16: Esquema conceitual, diagrama entidade-relacionamento.
Desta forma um professor pode criar e visualizar diversos cursos, diversas aulas e
alunos podem estar cadastrados por curso, e um aluno pode ter completado diversas
aulas. As tabelas do banco de dados foram implementadas em MySQL, com o auxilio da
interface web phpmyadmin, e suas características, bem como os detalhes específicos do
relacionamento entre tabelas podem ser vistos no seguinte esquema relacional:
ALUNO (idUser, nome, usuario, senha)
PROFESSOR (idProf, nome, usuario, senha)
CURSOS (idCurso, nome)
AULAS (idAula, nome)
CURSO_ALUNOS (idCurso, idUser, ultimaAula)
o idCurso referencia CURSOS
o idUser referencia ALUNO
PROF_CURSOS (idProf, idCurso)
o idProf referencia PROFESSOR
o idCurso referencia CURSOS
CURSO_AULAS (idCurso, idAula)
o idCurso referencia CURSOS
o idAula referencia AULAS
61
ALUNO_AULAS (idUser, idAula, completa)
o idUser referencia ALUNO
o idAula referencia AULAS
Embora o banco de dados tenha sido modelado tendo em mente todas as funcionalidades
futuras do ambiente, o ambiente atualmente não faz uso completo de todas as tabelas
criadas. Como é o caso da tabela ALUNO_AULAS, que identifica quais aulas já foram
completadas pelo aluno, e será usada na interface do professor para visualizar o
progresso de cada aluno. A implementação desta função do ambiente não fazia parte do
escopo inicial e deve ser implementada em trabalhos futuros.
4.2.4 Sistema de correção automática de códigos
Para o desenvolvimento da nova ferramenta foram consideradas algumas
possibilidades relacionadas ao corretor de códigos. Foi considerado o uso do sistema
BOCA-LAB (NAZÁRIO; DE SOUZA, 2010), um sistema de correção de códigos voltado ao
ensino de programação. Também foi considerado o uso do FLAVIO-OJ, um sistema de
correção automática de códigos que compila e testa os códigos submetidos. E por fim
criar um sistema próprio de correção, no qual duas alternativas adicionais foram
consideradas. O uso de um interpretador da linguagem C, com o qual o código não teria a
necessidade de ser compilado para que fosse executado. Por fim, compilar e executar o
código no servidor, de maneira a capturar as strings de saída para serem utilizadas no
sistema
O BOCA (Online Contest Administrator) (DE CAMPOS et al., 2004) é um sistema
de apoio para competições de programação, que possui total integração na web e possui
código aberto sem limitação de uso. Desta forma foi considerado o uso do sistema BOCA-
LAB (NAZÁRIO; DE SOUZA, 2010) um plugin para o BOCA adaptado para o ensino de
programação. Além da correção de automática de códigos o BOCA-LAB fornece dicas de
orientação ao aluno, à medida que este realiza submissões invalidas. Porém a opção de
uso do BOCA-LAB para este trabalho foi desconsiderada por dois motivos: não foi
62
possível ter acesso ao código fonte em tempo hábil e, como trata-se de um sistema
completo dedicado ao uso em competições, percebeu-se que sua integração com a
ferramenta aqui proposta não seria trivial.
Já o FLAVIO-OJ, é um sistema de correção de códigos desenvolvido por Flavio
Roberto Bayer, um bolsista do projeto da OBI na UDESC. Ele começou a desenvolver o
sistema em 2013 como voluntário no projeto, e continuou seu desenvolvimento como
bolsista em 2014. O sistema FLAVIO-OJ foi usado em minicursos da OBI desde 2013,
apenas para auxiliar nos resultados das avaliações realizadas na última aula destes, onde
eram feitas simulações de competições. Embora tenha sido usado algumas vezes, não
existe nenhum registro oficial deste projeto, nem mesmo nenhuma documentação foi
produzida. Embora o FLAVIO-OJ esteja disponível, este não foi utilizado por ter uma
estrutura de correção semi-automática (necessita da intervenção e do acompanhamento
minucioso do programador no momento da submissão do código) que deveria ser
amplamente modificada para atender os requisitos deste projeto. Também não há
nenhuma documentação disponível que possa auxiliar no entendimento e possível
integração da mesma à ferramenta aqui proposta. .
Após discussões sobre qual abordagem tomar, a abordagem de criar um sistema
próprio que compila e executa o código no servidor foi escolhida. A alternativa de utilizar
um interpretador para a linguagem C foi descartada após a conclusão de que seu uso
acarretaria em trabalho adicional sem benefícios em relação à alternativa de compilar os
códigos. Desta forma a alternativa escolhida foi a de compilar e executar os códigos no
servidor. Um fator adicional que contribuiu para esta escolha foi a possibilidade deste
corretor ter seu desenvolvimento continuado em trabalhos futuros.
Desta forma, o ambiente desenvolvido utiliza um sistema de correção simples, que
compila e executa códigos em C escritos pelo aluno através de um arquivo php no
servidor onde o ambiente esteja hospedado. O sistema utiliza os dados dos alunos para
criar pastas únicas para cada aluno, onde são salvos os arquivos com o código C
submetido. Com os arquivos salvos o sistema compila os códigos com a seguinte linha de
comando, “gcc programa.c -Wall -o programa” , e captura a saída de erros e
alertas para que possam ser exibidos para o aluno, caso existam. Em seguida caso a
compilação tenha terminado sem erros, e o programa tenha sido gerado, é executada a
seguinte linha de comando, “programa < input.txt > output.txt”, que executa
63
o programa previamente gerado passando um arquivo de entrada, “input.txt”, e
gerando um arquivo de saída, “output.txt”, este que será então comparado com um
arquivo de saída, presente no diretório da aula, fornecido pelo professor.
Os resultados, ou saídas esperadas, para este corretor de códigos são levemente
diferentes entre as funções de teste e submissão no sistema. Na função de teste, o
sistema retorna todos os alertas e erros encontrados na compilação ou execução do
código, uma linha pontilhada de separação, e os resultados de execução do programa,
nesta ordem. Já na função de submissão, ao invés dos resultados de execução do
programa, o sistema informa se o código submetido esta certo ou não. Um exemplo de
saída esperada pode ser visto na Figura 17.
Figura 17: Exemplo de saídas do sistema
Embora este sistema apenas indique se o código esta certo ou não, sem muitas
informações extras, já é o suficiente para os objetivos deste trabalho, além de simplificar o
trabalho de correção do professor, por fornecer uma resposta rápida sobre o código
submetido. Esta proposta assemelha-se aos resultados gerados pelo programa SACI.
64
4.2.5 Estado da ferramenta
No estado de desenvolvimento atual a ferramenta possui quase todas as
funcionalidades planejadas inicialmente. Dentre as funcionalidades planejadas, aquelas
ainda não completamente implementadas são a visualização de aulas completadas, e a
visualização de cursos e alunos cadastrados. A ralação entre as funcionalidades
planejadas e completadas pode ser vista de maneira resumida na Tabela 10.
Tabela 10: Relação de funcionalidades Planejadas x Concluídas
Interface Funcionalidade Estado
Aluno Seletor de aulas Implementado
Aluno Editor de códigos Implementado
Aluno Corretor de códigos Implementado
Aluno e Professor Visualizar aulas concluídas Implementado parcialmente
Professor Cadastrar Cursos e Alunos Implementado
Professor Cadastrar e fazer upload de
aulas
Implementado
Professor Visualizar cursos e alunos
cadastrados
Implementado parcialmente
A interface do aluno já tem implementadas as funcionalidades de seleção de aulas,
edição e correção de códigos. Já na interface do professor estão implementadas as
funcionalidades de cadastro de cursos, aulas e alunos. As funções para visualizar aulas
concluídas, de ambas as interfaces, e para visualizar cursos e alunos cadastrados, na
65
interface do professor foram criadas em termos de estrutura (ficam armazenadas), mas
não estão acessíveis nesta versão inicial da interface. A interface do aluno implementada
pode ser vista na Figura 18.
Figura 18: Interface do aluno implementada
Como pode ser visto, a interface do aluno possui três áreas principais: a área
superior, a área de conteúdo, na esquerda, e a área de trabalho, na direita. Na área
superior estão localizados o seletor de aulas, do lado esquerdo, e o nome do aluno junto
ao botão de sair, do lado direito.
Figura 19: Seletor de aula
Para selecionar uma aula, como pode ser observado na Figura 19, basta que o
aluno clique na aula desejada dentre as disponíveis na caixa seletora. Com a aula
selecionada a interface carrega automaticamente o arquivo HTML que contém o conteúdo
66
correspondente. Este arquivo HTML por padrão divide o conteúdo da aula em abas, mas
pode ser alterado e formatado da maneira que o professor quiser.
Na área de trabalho, apresentada na Figura 20, se encontram o editor de códigos,
o editor de arquivo de entrada, e a caixa de visualização dos resultados de execução. O
editor de códigos foi implementado com CodeMirror (CODEMIRROR, 2015), uma
biblioteca em javascript especializada em editores de código. O editor conta com
destacamento de sintaxe, bem como funções de autocompletar certas partes do código
(por exemplo auto-fechar parênteses). Funções adicionais podem ser configuradas de
acordo com o necessário.
Figura 20: Área de trabalho
O editor de arquivo de entrada é usado pelo corretor de códigos quando o aluno
deseja testar seu programa. O sistema envia o conteúdo dos editores de código e de
arquivo de entrada para o servidor, onde o corretor está situado. O corretor compila o
código e o executa usando o arquivo de entrada fornecido para então retornar os
resultados. Os resultados de execução retornados são exibidos na caixa de visualização
de resultados. No caso do aluno submeter o código para avaliação, o processo de
correção é quase o mesmo que o para testes, com duas diferenças, primeiramente o
corretor não utiliza o arquivo de entradas do aluno, mas sim o do professor, eo retorno
67
não é mais a saída do programa, mas sim uma linha indicando se o programa está ou não
correto.
A interface do professor por sua vez, tem as funcionalidades de cadastro de
cursos, aulas e alunos implementadas. A Figura 21 mostra a interface do professor junto
às três sub interfaces de cadastro.
Figura 21: Interface do professor implementada
Na função de cadastro de cursos, é preciso apenas informar o nome deste. No
cadastro de aulas, o professor seleciona o curso desejado, informa o nome e seleciona os
arquivos de aula. Ao concluir o cadastro da aula, um diretório com o nome da aula é
criado no servidor, dentro do diretório do curso correspondente. Caso a aula seja a
primeira a ser cadastrada para um curso, o diretório do curso é criado primeiro. O diretório
de aula contém os arquivos de aula fornecidos pelo professor, bem como pastas para os
códigos submetidos por alunos. Por fim no cadastro de alunos o professor insere o nome,
usuário, e senha do aluno, seleciona em qual curso o aluno será cadastrado e finaliza o
cadastro.
68
4.2.6 Testes Funcionais
Um teste funcional é um teste realizado para demonstrar o funcionamento das
funções especificadas de um software ou sistema. O teste é realizado olhando-se o
sistema apenas através de suas interfaces, sem considerar o comportamento interno
deste. O teste é executado com um conjunto de dados de entrada, e o resultado obtido é
comparado com um resultado esperado (PRESSMAN, 2011).
Desta forma durante o processo de desenvolvimento da ferramenta foi realizada
uma serie de testes funcionais. Os testes foram realizados primeiramente na interface do
professor, a fim de verificar o funcionamento das funções de cadastro, e em seguida na
interface do aluno, com maior ênfase no corretor de códigos.
Os testes na interface do professor se resumem a testes das funções de cadastro
de curso aulas e alunos. Um exemplo de um teste realizado nestas funções está
demonstrado na Figura 22. No teste demonstrado são testadas as três funções de
cadastro na interface do professor.
69
Figura 22: Teste funcional – cadastros
No item (1) é realizado o cadastro de um novo curso com o nome
“Teste_Funcional”. Em seguida no item (2), primeiramente foi verificado que o curso do
item anterior foi cadastrado com sucesso e foi exibido na caixa seletora dos cursos
cadastrados. Em seguida foram selecionados arquivos para a aula, que foi cadastrada
com o nome “Aula-Teste”. Já no item (3) um aluno com o nome “Aluno Teste Funcional”
foi cadastrado no curso. Por fim, para finalizar este teste de cadastros e iniciar os testes
na interface do aluno, foi feito o login na conta recém-cadastrada do novo aluno. Na
interface do aluno verificou-se que os cadastros foram, de fato, efetuados com sucesso,
como pode ser visto na Figura 23.
70
Figura 23: Teste funcional – dados cadastrados
Como se pode ver, a caixa seletora de aulas na parte superior esquerda exibe a
“Aula-Teste” cadastrada anteriormente. Adicionalmente ao ver que o HTML do conteúdo
de aula foi carregado, verifica-se que o upload dos arquivos de aula foi realizado com
sucesso e que a função seletora de aulas funciona corretamente. Com relação ao
cadastro do aluno, fica evidente que este foi realizado sem problemas, considerando que
foi possível acessar a conta deste, e ao ver que seu nome está sendo corretamente
exibido na pagina. Vale também ressaltar que, o fato de a “Aula-Teste” aparecer para o
aluno selecionar comprova que ambos, o aluno e a aula, foram corretamente associados
ao curso “Teste_Funcional”, no qual foram cadastrados.
Com os testes de cadastro concluídos foram iniciados os testes do corretor de
códigos. Primeiramente foi testada a função de teste de códigos. A função foi inicialmente
testada com códigos sem erros, a fim de verificar o funcionamento básico desta. A Figura
24 mostra alguns dos testes realizados com a função de teste de códigos.
71
Figura 24: Teste funcional – teste de código
Com estes testes iniciais, verificou-se que o sistema é capaz de executar
corretamente diferentes estruturas de programação, como estruturas condicionais ou de
repetição. Em seguida foram realizados testes utilizando códigos incorretos, a fim de
verificar o funcionamento das mensagens de erro do corretor de códigos. A Figura 25
mostra dois dos testes realizados.
72
Figura 25: Teste funcional – teste de código incorreto
Com estes testes verificou-se a funcionalidade do corretor ao processar códigos
com erros. No primeiro caso demonstrado, por estar faltando o “return()” da função, o
corretor retorna um alerta correspondente. Já no segundo caso falta um ponto e vírgula
após o “return()”. Com isso, o código não é compilado e o corretor retorna uma
mensagem informando o aluno sobre o erro de sintaxe cometido.
Por fim, foram realizados testes na função de submissão de códigos. A função de
submissão de códigos é a responsável por determinar se o programa do aluno está certo
ou não. A função avalia o código do aluno ao comparar sua saída com um arquivo de
saída esperada fornecido pelo professor. Desta forma, os testes desta função servem
para apresentar o resultado desta comparação de respostas, ou seja, indicar se o código
está correto ou não. A Figura 26 apresenta alguns dos testes realizados nesta função.
73
Figura 26: Teste funcional – teste de submissão de códigos
Nos primeiros dois casos de teste mostrados na Figura 26 a resposta correta para
o exercício foi a string “Bacalhau” entre duas linhas vazias. Nos casos seguintes a
resposta correta era o valor de entrada multiplicado por 2. Como pode ser visto, no
primeiro e terceiro casos o corretor de códigos reconheceu a resposta do aluno como
correta. Já no segundo e quarto casos a resposta foi dada como incorreta. No segundo
caso a resposta é incorreta por conta do resultado “Sardinha” ao contrario de “Bacalhau”
como era esperado. No quarto caso, ao invés de 2, a entrada está sendo multiplicada por
20.
Desta forma os testes funcionais da ferramenta foram concluídos, com resultados
satisfatórios. Com exceção de alguns casos de teste do corretor de códigos que
resultaram em erros no servidor, todas as funcionalidades implementadas na ferramenta
estão funcionando como o esperado.
74
4.3 INTEGRAÇÃO COM METODOLOGIAS
Com relação às metodologias, considerou-se a possibilidade de optar por mais de
uma metodologia simultaneamente. Com base nessa possibilidade decidiu-se utilizar duas
metodologias: A primeira para apoiar a construção, ou definição, dos objetivos de ensino,
ou seja, o que se espera atingir ao termino das aulas. A segunda para apoiar a
construção, ou planejamento, das aulas.
Sendo assim, optou-se pelo uso da taxonomia de Bloom para construção de
objetivos, e do modelo ARCS de Keller para apoio na metodologia de construção das
aulas. Ao usar a taxonomia de Bloom na criação dos objetivos deve-se relacionar o
conteúdo da aula a uma ou mais das categorias do domínio cognitivo definidas (lembrar,
entender, aplicar, analisar, avaliar, criar). Em uma aula sobre estruturas de repetição por
exemplo, um dos objetivos de aula pode ser que ao final da aula os alunos sejam capazes
de entender o funcionamento de uma estrutura de repetição. Estes objetivos por sua vez,
além de auxiliarem o professor no direcionamento da aula, são usados na criação de
avaliações relacionando-os com os verbos associados a cada categoria da taxonomia.
Desta forma, a taxonomia de Bloom foi escolhida para elaborar os exercícios a
serem inseridos nas aulas no ambiente desenvolvido (objetivos de avaliação), além da
construção dos objetivos das aulas. Já o modelo ARCS de Keller foi escolhido para ser
usado na construção das aulas propriamente ditas (metodologia), complementando e
ajudando a atingir os objetivos construídos com a taxonomia de Bloom.
Foi também considerado o uso da taxonomia de Krathwohl no lugar da taxonomia
de Bloom, devido a ambas serem usadas na criação de objetivos de aula. Porém, optou-
se pela taxonomia de Bloom pela possibilidade de usá-la na criação de exercícios e de
objetivos de avaliação, algo necessário para a criação das aulas e exercícios a serem
utilizadas na ferramenta desenvolvida. Outro fator que influenciou na decisão foi que o
“modelo ARCS de Keller” escolhido para ser utilizado, já trata do quesito motivacional na
definição de seus passos, o que torna o uso da taxonomia de Krathwohl redundante.
Durante o processo de escolha de metodologias, o “ritmo de educação de
Whitehead” e os “nove eventos de ensino de Gagné” também foram considerados como
candidatos no lugar do “modelo ARCS de Keller”, devido à grande similaridade entre
75
estas propostas. No entanto o “ritmo de educação de Whitehead” foi descartado pela
simplicidade, ou generalização excessiva da definição de seus “passos”. Já a metodologia
dos “nove eventos de Gagné” foi descartada por ser de complexidade elevada demais
para um curso de curta duração, como é o caso dos minicursos da OBI na UDESC. Este
motivo (dificuldade de aplicação em cursos de curta duração) também inviabilizou o uso
da metodologia do “Paraquedas”, cujo artigo menciona quantidades de aulas para
aplicação da proposta que extrapolam os minicursos da OBI. Desta forma o modelo
ARCS foi escolhido por ter um nível de detalhamento e complexidade médio em
comparação com os demais.
Com as metodologias escolhidas foram feitas as aulas a serem usadas em
conjunto com o ambiente desenvolvido. Valendo ressaltar que não houve necessidade de
integrar as metodologias ao ambiente desenvolvido. As metodologias foram utilizadas na
criação de aulas que virão a ser apresentadas utilizando o ambiente.
Devido a diversos fatores, não foi possível aplicar tal ferramenta e metodologias em
um minicurso no tempo deste trabalho. Sendo assim, a aplicação em um minicurso da
OBI na UDESC com as aulas criadas e suas metodologias será proposta para trabalhos
futuros.
Com relação às aulas criadas fazendo uso das metodologias, estas estão sendo
abordadas na seção a seguir.
4.3.1 Aulas criadas
Com as metodologias escolhidas, abordadas anteriormente, foram criadas duas
aulas exemplo para um minicurso da OBI nível 0, ou seja de programação para iniciantes
sem qualquer conhecimento em programação. Os conceitos e forma de aplicação das
metodologias estão apresentados de maneira resumida na Tabela 11, apresentada a
seguir.
76
Tabela 11: Minicurso OBI nível 0 - programação para iniciantes
Aula Objetivos em relação ao estudante
(Taxonomia de Bloom)
Estratégias da aula
(Modelo ARCS de Keller)
Aula 1: Algoritmos
não-computacionais
Ao concluir a aula o aluno deverá ser capaz de: Reconhecer um algoritmo
não-computacional Escrever um algoritmo não-
computacional
Atenção: Apresentar o conceito de algoritmos e enfatizar os jogos conhecidos com algoritmos;
Relevância: Esclarecer que todo programa de computador é um algoritmo e que, portanto, o conhecimento é essencial para criar programas computacionais;
Confiança: Demonstrar que os algoritmos (não-computacionais) fazem parte de nossas vidas e podem ser compreendidos facilmente;
Satisfação: Apresentar exercícios iniciais mais simples de modo que o aluno possa perceber que tem capacidade de realizá-los.
Aula 2: algoritmos
computacionais iniciais
Ao concluir a aula o aluno deverá ser capaz de:
Identificar as partes de um
algoritmo computacional (entrada, processamento e saída)
Compreender os conceitos relativos à memória do computador e aos dispositivos de entrada e saída
Implementar um algoritmo simples usando os conceitos apresentados
Atenção: Relembrar conceitos e exercícios vistos anteriormente;
Relevância: Apresentar a estrutura do computador e fazer uma comparação com comandos de entrada e saída e com declaração de variáveis
Confiança: Apresentar a estrutura básica de um programa de computador, demonstrando sua similaridade com algoritmos não-computacionais já estudados;
Satisfação: Apresentar exercícios iniciais apenas com saída de dados, passando posteriormente a agregar processamento (cálculos) e saída.
Juntamente com as aulas foram criados exercícios correspondentes, também
seguindo os conceitos das metodologias escolhidas.
77
Exercícios planejados para a 1ª aula:
1. Escreva um algoritmo com os passos necessários para fazer pipoca.
2. Supondo que você tenha duas jarras: uma com capacidade de 3 litros e
outra com capacidade de 5 litros. Considere que ambas as jarras são
opacas, ou seja, não é possível ver seus conteúdos. Imagine que você não
tenha nenhum instrumento de medição à disposição e que disponha apenas
de água (em abundância) e das duas jarras já mencionadas. Sua tarefa é
escrever um algoritmo que indique os passos necessários para encher a
jarra maior com 4 litros de água, usando apenas as duas jarras disponíveis,
podendo enchê-las, transferir água ou esvaziá-las a qualquer momento.
Exercícios planejados para a 2ª aula:
1. Escreva um programa em C que mostre na tela seu nome completo.
2. Crie um programa em C que armazene sua idade em uma variável do tipo
inteiro e mostre o valor desta variável na tela.
3. Faça um novo programa em C que mostre na tela seu nome e sua idade
numa mesma linha.
Estes exercícios criados para cada aula estão relacionados, direta ou indiretamente
com os objetivos e estratégias de aula desenvolvidas. Por exemplo, o primeiro exercício
da aula 1 esta relacionado com o objetivo de “escrever um algoritmo não computacional”
e a estratégia de “apresentar exercícios iniciais simples”. De maneira similar o restante
dos exercícios se relaciona com os objetivos e estratégias de aula.
78
5 CONSIDERAÇÕES FINAIS
Este trabalho demonstrou que o ensino de programação para iniciantes apresenta
alguns desafios a serem transpostos como é o caso do alto índice de desistência e de
reprovação por parte dos alunos. O projeto OBI na UDESC enfrenta este desafio ao
oferecer minicursos de iniciação à programação para alunos do ensino médio da rede
publica e privada de Joinville. A partir desta necessidade, foi idealizada uma ferramenta
que pudesse dar suporte a estes minicursos, tanto para o aluno quanto para o professor.
Deste modo, no decorrer deste trabalho, foi realizada uma busca por ferramentas e
metodologias de ensino de programação, que por sua vez foram apresentadas, e cujos
resultados foram comparados e analisados. Dentre as ferramentas apresentadas, aquela
que mais se destacou, foi a ferramenta SACI, disponibilizada pela OBI. Dentre os fatores
de destaque desta ferramenta pode-se ressaltar a facilidade de se criar e disponibilizar
aulas, além da capacidade de acessar o ambiente de qualquer dispositivo com acesso à
internet, seja este um computador ou um celular/tablet. No entanto, não foi possível
utilizar e adaptar esta ferramenta, pois seu código-fonte não está disponível. Apesar
disso, a ferramenta SACI ainda pôde ser usada como inspiração para o desenvolvimento
da ferramenta proposta. Portanto, apesar das semelhanças, a ferramenta proposta foi
implementada com suporte à linguagem C e oferece uma interface mais amigável para o
professor. Foi feita também a modelagem de um banco de dados para ser usado com a
ferramenta desenvolvida.
Com relação às metodologias, duas se mostraram interessantes para o uso em
conjunto com a ferramenta desenvolvida, sendo estas: a taxonomia de Bloom e o modelo
ARCS de Keller. Ambas podem ser usadas de forma complementar à outra. A taxonomia
de Bloom é usada para desenvolver os exercícios e objetivos de aula. Já o modelo ARCS
é usado na construção das aulas em si, complementando e ajudando a atingir os
objetivos de aula definidos.
Vale salientar que o uso da ferramenta desenvolvida neste trabalho (bem como do
ambiente SACI no qual ela inspirou-se) possui um diferencial em relação a outras
estudadas no sentido de permitir que haja uma correção automática de códigos dentro do
próprio ambiente da aula. Deste modo, o professor pode acompanhar o desenvolvimento
79
cognitivo do aluno de forma mais dinâmica, sem a obrigação de corrigir os exercícios
manualmente. Outras características da ferramenta, definidas como requisitos ao longo
do projeto, foram: possibilidade de uso em ambiente web e interface simples de usar. Os
testes funcionais aplicados à ferramenta geraram resultados satisfatórios.
Devido a diversos fatores, não foi possível avaliar os resultados, aplicando tal
ferramenta e metodologias em um minicurso no tempo em que este trabalho foi realizado.
Sendo assim, propõe-se que a aplicação da ferramenta em um minicurso da OBI na
UDESC seja realizada em um trabalho futuro. Outra proposta para a continuidade do
trabalho seria a integração da ferramenta aqui desenvolvida ao ambiente SACI original,
que usa apenas a linguagem JavaScript e poderia ter um ganho significativo com a
implementação da linguagem C. Finalmente, seria possível conduzir novos estudos para o
uso de outras linguagens de programação no mesmo ambiente, como Python ou Java,
por exemplo.
80
REFERÊNCIAS
AIDE. Android IDE. Disponível em: <http://www.android-ide.com/>. Acesso em: 5 mar.
2015.
BHATTACHARYA, Prabir et al. A Collaborative Interactive Cyber-learning Platform for
Anywhere Anytime Java Programming Learning. In: Advanced Learning Technologies
(ICALT), 2011 11th IEEE International Conference on. IEEE, 2011. p. 14-16.
BLOOM, Benjamin S. et al. Taxonomy of Educational Objectives: The Classification
of Education Goals. Cognitive Domain. Handbook 1. 1956.
BORGES, Robson M. et al. Usando o modelo 3C de colaboração e Vygotsky no ensino de
programação distribuída em pares. XVIII Simpósio Brasileiro de Informática na
Educação (SBIE), p. 12-22, 2007.
CODECADEMY. Disponível em: <http://www.codecademy.com/>. Acesso em: 5 mar.
2015.
CODEMIRROR. Disponível em: <https://codemirror.net/>. Acesso em: 13 Dez. 2015.
CODE.ORG. Disponível em: <http://www.code.org/>. Acesso em: 23 mar. 2015.
DE BARROS, Leliane Nunes et al. A tool for programming learning with pedagogical
patterns. In: Proceedings of the 2005 OOPSLA workshop on Eclipse technology
eXchange. ACM, 2005. p. 125-129.
DE CAMPOS, CASSIO P.; FERREIRA, Carlos E. BOCA: um sistema de apoio a
competições de programação. In: Workshop de Educação em Computação. 2004. p.
885-895.
DE FARIA, Eustaquio Sao Jose et al. Uma Metodologia Para Ensino de Programação de
Computadores Baseada na Taxonomia de Objetivos Educacionais de Bloom e Aplicada
Através da Programação em Duplas.Revista Ciência e Tecnologia, v. 13, n. 22/23, 2011.
DE FÁTIMA NEVES, Maria; COELLO, Juan Manuel Adán. OntoRevPro: Uma Ontologia
sobre Revisão de Programas para o Aprendizado Colaborativo de Programação em Java.
In: Anais do Simpósio Brasileiro de Informática na Educação. 2006. p. 358-367.
81
DE JESUS, Elieser Ademir; RAABE, André Luis Alice. Interpretaçoes da TAXONOMIA de
Bloom no contexto da Programaçao Introdutória. Anais do XX Simpósio Brasileiro de
Informática na Educaçao. SBIE, v. 20, p. 2009, 2009.
DE SANTIAGO, Rafael; DAZZI, Rudimar Luís Scaranto. Ferramenta de apoio ao ensino
de algoritmos. 2004.
DE SOUZA, Draylson Micael; MALDONADO, José Carlos; BARBOSA, Ellen Francine.
Aspectos de Desenvolvimento e Evolução de um Ambiente de Apoio ao Ensino de
Programação e Teste de Software. In: Anais do Simpósio Brasileiro de Informática na
Educação. 2012.
DENTON, Leo F.; MCKINNEY, Dawn; DORAN, Michael V. A melding of educational
strategies to enhance the introductory programming course. In:Frontiers in Education,
2005. FIE'05. Proceedings 35th Annual Conference. IEEE, 2005. p. F4G-7.
DORNELES, Ricardo Vargas; PICININ JR, Delcino; ADAMI, André Gustavo. ALGOWEB:
A Web-Based Environment for Learning Introductory Programming. In: ICALT. 2010. p.
83-85.
DOS SANTOS, Rodrigo Pereira; COSTA, Heitor Augustus Xavier. Análise de
Metodologias e Ambientes de Ensino para Algoritmos, Estruturas de Dados e
Programação aos iniciantes em Computação e Informática. Infocoomp, Journal of
Computer Sciense, v. 5, n. 1, 2006.
DYBÅ, Tore; KAMPENES, Vigdis By; SJØBERG, Dag IK. A systematic review of statistical
power in software engineering experiments. Information and Software Technology, v.
48, n. 8, p. 745-755, 2006.
EDUTEKA. Disponível em: <http://www.eduteka.org/TaxonomiaBloomCuadro.php3>.
Acesso em: 22 mai. 2015.
FONTÃO, Manuel Fonseca. A taxonomia de Bloom e a sua revisão. Disponível em:
<http://quiosquedasletras.blogspot.com.br/2011/12/taxonomia-de-bloom-e-sua-
revisao.html>. Acesso em: 26 mai. 2015.
GAGNE, Robert M. et al. Principles of instructional design. 1992.
82
GREYLING, J. H.; CILLIERS, C. B.; CALITZ, A. P. B#: The Development and Assessment
of an Iconic Programming Tool for Novice Programmers. In: Information Technology
Based Higher Education and Training, 2006. ITHET'06. 7th International Conference
on. IEEE, 2006. p. 367-375.
HANNAY, Jo E.; SJØBERG, Dag IK; DYBÅ, Tore. A systematic review of theory use in
software engineering experiments. Software Engineering, IEEE Transactions on, v. 33,
n. 2, p. 87-107, 2007.
KAMPENES, Vigdis By et al. A systematic review of effect size in software engineering
experiments. Information and Software Technology, v. 49, n. 11, p. 1073-1086, 2007.
KARAKUS, Murat et al. Teaching computing and programming fundamentals via App
Inventor for Android. In: Information Technology Based Higher Education and
Training (ITHET), 2012 International Conference on. IEEE, 2012. p. 1-8.
KELLER, John M. How to integrate learner motivation planning into lesson planning: The
ARCS model approach. VII Semanario, Santiago, Cuba, p. 1-13, 2000.
KELLER, John M. Development and use of the ARCS model of instructional
design. Journal of instructional development, v. 10, n. 3, p. 2-10, 1987.
KELLER, John M. The use of the ARCS model of motivation in teacher training. Aspects
of educational technology, v. 17, p. 140-145, 1984.
KITCHENHAM, B.; CHARTERS, S. Procedures for Performing Systematic Literature
Reviews in Software Engineering. Keele University & Durham University, UK, 2007.
KRATHWOHL, David R. A revision of Bloom's taxonomy: An overview.Theory into
practice, v. 41, n. 4, p. 212-218, 2002.
KRATHWOHL, David R. et al. Taxonomy of Educational Objectives: The
Classification of Education Goals. Cognitive Domain. Handbook 2. 1964.
KRUSE, Kevin. Gagne’s Nine Events of Instruction: An Introduction. Jan. 2008.
Disponivel em: <http://modps34.lib.kmutt.ac.th/documents/Ajarn09/8.GagneStyle.pdf>.
Acesso em: 7 Jan. 2015.
83
MACORATTI, José C. Modelando Sistemas em UML – Casos de Uso. Disponível em:
<http://www.macoratti.net/net_uml2.htm> Acesso em: 10 Dez. 2015.
MERCÊS, Fernando. O que fazer com o C que se aprendeu na faculdade. Jan. 2012.
Disponivel em: <http://www.mentebinaria.com.br/artigos/0x13/0x13-cfaculdade.html>.
Acesso em: 11 Nov. 2015.
MOTA, Fernanda P. et al. Desenvolvendo o Raciocínio Lógico no Ensino Médio: uma
proposta utilizando a ferramenta Scratch. In: Anais do Simpósio Brasileiro de
Informática na Educação. 2014. p. 377-381.
NAZÁRIO, Débora Cabral; DE SOUZA, Allan. BOCA-LAB: Corretor automático de Código
adaptado ao Ensino de Linguagem de Programação.Anais do Computer on the Beach,
p. p. 42-46, 2010.
NOBRE, Isaura Alcina Martins; DE MENEZES, Crediné Silva. Suporte à Cooperação em
um Ambiente de aprendizagem para Programação (SAmbA). In: Anais do Simpósio
Brasileiro de Informática na Educação. 2002. p. 337-347.
OBI. Disponível em: <http://olimpiada.ic.unicamp.br/>. Acesso em: 8 mar. 2015.
OLIVARES CEJA, J. M.; BUENDIA CERVANTES, E. An epistemology for software tool
design that promotes knowledge production: Experiences with students learning computer
programming languages. In: e-Learning and e-Technologies in Education (ICEEE),
2013 Second International Conference on. IEEE, 2013. p. 37-41.
PEREIRA JÚNIOR, J. C. R. et al. Ensino de algoritmos e programação: uma experiência
no nível médio. In: XIII Workshop de Educação em Computação (WEI’2005). São
Leopoldo, RS, Brasil. 2005.
PETERSEN, Kai et al. Systematic mapping studies in software engineering. In: 12th
International Conference on Evaluation and Assessment in Software Engineering.
sn, 2008.
PPC-BCC. Projeto pedagógico do curso de bacharelado em ciência da computação. Fev.
2010. Disponível em: <
84
http://www.joinville.udesc.br/portal/ensino/graduacao/ciencia_computacao/arquivos/ppc_b
cc_a_patrir_2010-02.pdf>. Acesso em: 12 nov. 2015.
PRESSMAN, Roger S. Engenharia de software. McGraw Hill Brasil, 2011.
RONGAS, Timo; KAARNA, Arto; KALVIAINEN, Heikki. Classification of computerized
learning tools for introductory programming courses: learning approach. In: Advanced
Learning Technologies, 2004. Proceedings. IEEE International Conference on. IEEE,
2004. p. 678-680.
SACI. Disponível em: <http://olimpiada.ic.unicamp.br/saci>. Acesso em: 7 jun. 2015.
SALCEDO, Sebastian Londoño; IDROBO, Ana Maria Orozco. New tools and
methodologies for programming languages learning using the scribbler robot and Alice. In:
Frontiers in Education Conference (FIE), 2011. IEEE, 2011. p. F4G-1-F4G-6.
SARRIA, M. et al. Introduction to programming for engineers following the parachute
paradigm. In: Frontiers in Education Conference, 2009. FIE'09. 39th IEEE. IEEE, 2009.
p. 1-4.
SCAICO, Pasqueline Dantas et al. Ensino de Programação no Ensino Médio: Uma
Abordagem Orientada ao Design com a linguagem Scratch. Revista Brasileira de
Informática na Educação, v. 21, n. 02, p. 92, 2013.
SCRATCH. Disponivel em: <https://scratch.mit.edu/>. Acesso em: 23 mar. 2015
TOBI. Disponível em: <http://olimpiada.ic.unicamp.br/tobi>. Acesso em: 7 jun. 2015.
UDESC. Disponível em: <http://www.obi.joinville.udesc.br/index.php>. Acesso em: 8 mar.
2015.
VYGOTSKY, Lev Semenovich. Mind in society: The development of higher
psychological processes. Harvard university press, 1980.
VYGOTSKI, Lev Semenovitch. A formação social da mente. Psicologia, v. 153, p. V631,
1989.
85
WIKIPEDIA. Instructional design. Disponivel em:
<http://en.wikipedia.org/wiki/Instructional_design>. Acesso em: 27 Mai. 2015.
WHITEHEAD, Alfred North. Aims of education. Simon and Schuster, 1967.
ZANELLA, Andréa Vieira. Zona de desenvolvimento proximal: análise teórica de um
conceito em algumas situações variadas. Temas psicol., Ribeirão Preto , v. 2, n. 2, ago.
1994 Disponível em <http://pepsic.bvsalud.org/scielo.php?script=sci_arttext&pid=S1413-
389X1994000200011&lng=pt&nrm=iso>. Acesso em: 11 jun. 2015.
ZDP. Teoria da Aprendizagem Significativa. Disponivel em:
<http://cae.ucb.br/tas/tas/tas13.html>. Acesso em: 27 Mai. 2015.
86
APÊNDICES
Apêndice A: Tabela completa de classificação das ferramentas
FERRAMENTA APRESENTAÇÃO CONEXÃO LINGUAGEM COLABORAÇÃO LICENÇA E DISPONIBILIDADE
AmCorA/SAmbA (NOBRE et al. 2002)
Textual Online (Web)
Diversas Colaborativo Indisponível
RemotePP Mista Online (PC)
Independente de linguagem
Colaborativo Indisponível
ProgTest Textual Online
(Web)
Java Individual Disponível e Open Source
ACE (BHATTACHARYA et al.,2011)
Textual Online (Web)
C# Colaborativo Sourceforge vazio. Indisponível
Alice Visual Offline Pseudo Individual Disponível para fins não Comerciais
Scratch Visual Online (Web) e Offline
Pseudo Individual e Colaborativo
Disponível e Gratuito
App Inventor para Android
Visual Online (Web)
Pseudo Individual Disponível e Gratuito
AlgoWeb Textual Online (Web)
Pseudo Individual Disponível
ProPAT (Eclipse Plugin) (DE BARROS et al. ,2005)
Textual Offline Diversas Individual Indisponível
CIFluxProg Visual Offline Pseudo Individual Disponível (via email)
B# Visual Offline Pseudo Individual Indisponível
AIDE (Android IDE)
Textual Offline Java, Css, HTML e Javascript
Individual Comercial com lições introdutórias gratuitas
SACI (OBI) Textual Online (Web)
Javascript Individual Disponível