UNIVERSIDADE DO VALE DO ITAJAÍ

CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

APRIMORAMENTO E AVALIAÇÃO DO CORRETOR DE

QUESTÕES DO PORTUGOL STUDIO

por

Andrei Hodecker

Itajaí (SC), Dezembro de 2014

 UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO

APRIMORAMENTO E AVALIAÇÃO DO CORRETOR DE QUESTÕES

DO PORTUGOL STUDIO

Área de Informática na Educação

por

Andrei Hodecker

Relatório apresentado à Banca Examinadora

do Trabalho Técnico-científico de Conclusão
do Curso de Ciência da Computação para
análise e aprovação.
Orientador(a): André Luís Alice Raabe,
Doutor

Itajaí (SC), Dezembro de 2014

 AGRADECIMENTOS

Agradeço aos meus pais Vanilde e Leonel, a minha namorada Fernanda, e ao meu
orientador André Raabe pelo apoio que me ofereceram durante todo estre trabalho.

Agradeço também a banca avaliadora pelas excelentes contribuições e também a Luiz

Fernando Noschang cujas contribuições foram de extrema importância para realização deste
trabalho.
Não se pode criar experiência. É preciso passar por ela.
- Albert Camus
 RESUMO

HODECKER, Andrei. Aprimoramento e Avaliação do Corretor de Questões do Portugol

Studio. Itajaí, 2014. Número de Páginas: 80. Trabalho Técnico-científico de Conclusão de
Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e
do Mar, Universidade do Vale do Itajaí, Itajaí, 2014.

Diversos cursos de Ciência da Computação em todo mundo iniciam com disciplinas de

introdução a programação, e o conhecimento adquirido pelo aluno nesta disciplina tende a
influenciar seu desempenho nas demais disciplinas. Porém, ambientes de desenvolvimento
são geralmente direcionados para programadores experientes, utilizando vocabulário com
conceitos técnicos que um aluno iniciante ainda não compreende. Com um enfoque
educacional, o Portugol Studio tem por objetivo fornecer um ambiente de desenvolvimento
mais amigável a alunos novatos, dentre várias funcionalidades destaca-se o seu corretor
estático e dinâmico, que tem como finalidade orientar o aluno na resolução de exercícios de
programação. O corretor estático pode analisar o código do aluno e compará-lo com soluções
modelos definidas pelo criador do exercício, além de buscar padrões incorretos no código do
aluno e exibir dicas para o mesmo. Porém o corretor estático possuía aspectos de
prototipação, e a especificação de exercícios para o mesmo demandava muito trabalho. Neste
trabalho foram desenvolvidas melhorias para o corretor estático, como novos algoritmos que
percorrem a árvore sintática abstrata e encontram padrões de erros, denominados tree walkers,
bem como um editor de exercícios que facilita a criação de questões para o corretor, além
disso, realizou-se um experimento com um grupo de alunos a fim de avaliar a efetividade das
ações tomadas pelos estudantes quando uma dica do corretor é emitida. Ao final deste
trabalho, o corretor estático do Portugol Studio foi melhorado em diversos aspectos, o editor
de exercícios permite rapidamente a criação de questões sem demandar muito conhecimento
técnico e, além disso, o experimento indicou que o corretor teve um impacto positivo na
resolução dos exercícios pelos alunos, embora não tenha se saído tão bem em alguns tree
walkers e nas soluções modelos. A metodologia utilizada no experimento se mostrou eficaz e
as informações coletadas servirão de embasamento para traçar diretrizes para trabalhos
futuros.

Palavras-chave: Corretores Automáticos; Ensino de Programação; Mensagens de Erros em

Ambientes de Desenvolvimento.
 ABSTRACT

Several Computer Science courses around the world start with programming introduction
disciplines, the knowledge acquired by students in this discipline tends to influence their
performance in other subjects. However, development environments are generally intended to
experienced programmers, using technical vocabulary and concepts that a beginner student
still doesn't understand. With an educational focus, Portugol Studio aims to provide a more
user friendly development environment for novice students, of many features stands out its
static and dynamic assessments, which aims to guide the student in solving programming
exercises. The static assessment can analyze the code of the student and compare it with
model solutions, seek incorrect patterns and send tips for the student. But the static
assessment still has prototyping aspects, and the developtment of exercises for it demand a lot
of work. In this paper was developed improvements in the static assessment, as well the
development of new algorithms that walk through the abstract syntax tree and find error
patterns, called tree walkers, an exercise editor to facilitate the creation of questions for the
assessment system, in addition, this paper conducted an experiment with a group of students
exploring what happens when a hint of static assessment is displayed. At the end of this
project, the static assessment of Portugol Studio was improved in various aspects, the
exercise editor developed, now allow the creation of exercises quickly and without requiring
much knowledge, in addition, the experimente pointed that the automated assesment had a
positive impact in the exercise solving process, although didn’t worked as expected with some
tree walkers and model solutions. The metodology used in the experiment proved effective na
the obtained knowledge from the experiments will serve as the basis to set guidelines for
future papers.

Keywords: Automated Assessment, Teaching programming, Error Messages in Developtment

Environment.
 LISTA DE FIGURAS

Figura 1. SQL utilizado para obter a porcentagem de erros. .................................................... 20

Figura 2. Script e query utilizados para obtenção das questões. .............................................. 22
Figura 3. ASA para a expressão (3 + 4) * 5. ............................................................................ 29
Figura 4. Exemplo de um simples desvio condicional. ............................................................ 30
Figura 5. Exemplo de uma ASA. .............................................................................................. 30
Figura 6. Exemplo de uma ASA. .............................................................................................. 32
Figura 7. Interface do ambiente Portugol Studio 2.0 em execução. ......................................... 33
Figura 8. Mensagens de erros na interface do Portugol Studio. ............................................... 34
Figura 9. Depuração de um código no Portugol Studio. .......................................................... 34
Figura 10. Diagrama de objeto de uma ASA de um programa em Portugol. ........................... 36
Figura 11. Ilustração d o funcionamento completo do corretor. .............................................. 38
Figura 12. Erro na ferramenta DrScheme. ................................................................................ 43
Figura 13. Código do aluno após a mensagem da Figura 12. ................................................... 44
Figura 14. Funcionamento do corretor com a alteração do projeto. ......................................... 52
Figura 15. Exemplo de tratamento de parâmetros .................................................................... 52
Figura 16. Diagrama de classes de uma questão do corretor.................................................... 54
Figura 17. Exemplo de um teste unitário do tree walker “NumberOfInstructions”. ................ 61
Figura 18. Exemplo de um teste unitário executado na interface do NetBeans. ...................... 61
Figura 19. Classe de mensagem do corretor estático................................................................ 61
Figura 20. Protótipo da tela de início do editor de questões..................................................... 62
Figura 21. Tela de criação do exercício. ................................................................................... 63
Figura 22. Tela de edição do corretor dinâmico. ...................................................................... 64
Figura 23. Tela com a aba "Exercício" selecionada. ................................................................ 64
Figura 24. Opções para incluir parâmetros. .............................................................................. 65
Figura 25. Tela de solução selecionada com código-fonte invisível. ....................................... 66
Figura 26. Tela de solução selecionada com código-fonte visível. .......................................... 66
Figura 27. Diagrama de casos de uso do editor de questões. ................................................... 66
Figura 28. Plug-in na interface do Portugol Studio .................................................................. 67
Figura 29. Tela de detalhes do exercício. ................................................................................. 68
Figura 30. Exemplo de uma correção do exercício 1. .............................................................. 68
Figura 31. Esquema do banco de dados para gravar logs. ........................................................ 69
 LISTA DE TABELAS

Tabela 1. Questões selecionadas para a análise dos erros. ....................................................... 21

Tabela 2. Rubricas possíveis que serão anotadas. .................................................................... 24
Tabela 3. Resumo dos atributos dos corretores avaliados. ....................................................... 41
Tabela 4. Forma de feedback que cada corretor utiliza ............................................................ 42
Tabela 5. Rubricas inferidas em cada edição de código. .......................................................... 44
Tabela 6. Resultados coletados com a metodologia. ................................................................ 45
Tabela 7. Tree Walkers e questões onde estes foram inferidos. ............................................... 50
Tabela 8. Resultados obtidos por estudante ............................................................................. 70
Tabela 9. Resultados obtidos por exercício. ............................................................................. 71
Tabela 10. Mensagens coletadas do corretor estático e suas rubricas. ..................................... 73
 LISTA DE QUADROS

Quadro 1. Interface para a implementação de visitors. ............................................................ 31

Quadro 2. Utilização de um listener a partir de um parser do ANTLR. ................................... 32
Quadro 3. Exemplos de normalização de algoritmos. .............................................................. 38
Quadro 4. Tree Walkers desenvolvidos em Pelz (2014) .......................................................... 39
Quadro 5. Questão representada pelo XML interpretado pelo corretor. .................................. 40
Quadro 6. Tree Walkers inferidos durante a realização do trabalho. ....................................... 48
Quadro 7. Relação dos tree walkers e suas estratégias adotadas. ............................................. 49
Quadro 8. Solução de um aluno para a questão 14. .................................................................. 49
Quadro 9. Exemplo do manifesto do tree walker “NumberOfInstructions”. ........................... 50
Quadro 10. XML de uma questão, novos atributos destacados em negrito. ............................ 53
Quadro 11. Exemplo simplificado do controlador do corretor dinâmico. ................................ 55
Quadro 12. Exemplo de utilizações das diretivas do editor. .................................................... 56
 LISTA DE EQUAÇÕES

Equação 1 ................................................................................................................................. 20
Equação 2 ................................................................................................................................. 20
Equação 3 ................................................................................................................................. 25
Equação 4 ................................................................................................................................. 45
Equação 5 ................................................................................................................................. 46
 LISTA DE ABREVIATURAS E SIGLAS

ANTLR Another Tool for Language Recognition

ASA Árvore Sintática Abstrata
ASL Advanced Student Language
BSL Beginner Student Language
HTML HyperText Markup Language
IDE Integrated Development Environment
JSON JavaScript Object Notation
PHP PHP: Hypertext Preprocessor
SPA Single-Page Application
SQL Structured Query Language
TTC Trabalho Técnico-científico de Conclusão de Curso
UNIVALI Universidade do Vale do Itajaí
XML Extensible Markup Language
 15

SUMÁRIO

1 INTRODUÇÃO .................................................................................................................. 16
1.1 PROBLEMATIZAÇÃO ................................................................................................. 17
1.2 FORMULAÇÃO DO PROBLEMA .......................................................................................... 17
1.2.1 Solução Proposta .......................................................................................................... 19
1.3 OBJETIVOS ................................................................................................................... 23
1.3.1 Objetivo Geral .............................................................................................................. 23
1.3.2 Objetivos Específicos .................................................................................................... 23
1.4 METODOLOGIA ................................................................................................................. 23
1.4.1 Desenvolvimento dos Tree Walkers .............................................................................. 23
1.4.2 Desenvolvimento do Editor de Questões ...................................................................... 24
1.4.3 Experimento com os Alunos.......................................................................................... 24
1.5 ESTRUTURA DO TRABALHO .............................................................................................. 25
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 27
2.1 CORREÇÃO ESTÁTICA ............................................................................................... 27
2.1.1 Etapas da Análise de Programas ................................................................................. 28
2.2 PORTUGOL STUDIO .................................................................................................... 33
2.2.1 Corretor Proposto em PELZ ........................................................................................ 36
2.3 TRABALHOS SIMILARES ........................................................................................... 41
2.3.1 Corretores Automáticos ................................................................................................ 41
2.3.2 Avaliação da Efetividade das Mensagens de Erros ..................................................... 42
2.3.3 Considerações............................................................................................................... 46
3 DESENVOLVIMENTO .................................................................................................... 48
3.1 TREE WALKERS........................................................................................................... 48
3.2 CORRETOR E EDITOR DE QUESTÕES ..................................................................... 51
3.2.1 Alterações no Corretor ................................................................................................. 51
3.2.2 Editor de Questões ........................................................................................................ 54
3.3 EXPERIMENTO DE AVALIAÇÃO .............................................................................. 58
4 RESULTADOS .................................................................................................................. 60
4.1 IMPLEMENTAÇÃO DOS TREEWALKERS............................................................................. 60
4.2 EDITOR DE EXERCÍCIOS .................................................................................................... 62
4.3 PLUG-IN DO CORRETOR AUTOMÁTICO ............................................................................. 67
4.4 EXPERIMENTO COM OS ALUNOS ....................................................................................... 69
4.4.1 Comportamento do aluno em relação a mensagens ..................................................... 72
5 CONCLUSÕES .................................................................................................................. 75
5.1 TRABALHOS FUTUROS...................................................................................................... 76
 16

1 INTRODUÇÃO

Muitos cursos em todo mundo iniciam com disciplinas de introdução a programação,

esta é a essência da ciência da computação (KINNUNEN e MALMI, 2006), e o conhecimento
adquirido pelo aluno nesta disciplina tende a influenciar o desempenho deste nas demais
disciplinas (RAABE et al., 2007). Porém, programação não é um assunto fácil de ser
estudado, requer o entendimento correto de conceitos abstratos (LAHTINEN et al., 2005),
esta complexidade se reflete em altas taxas de desistência. Kinnunen e Malmi (2006) relatam
que muitas instituições apresentam taxas entre 20 e 40 por cento em disciplinas de introdução
a programação. Na UNIVALI (Universidade do Vale do Itajaí), por exemplo, conforme dados
estatísticos fornecidos pela universidade, a taxa de reprovação ao longo da década de 90 na
disciplina introdutória de algoritmos era próxima de 50% (RAABE et al., 2007).

Para que se possa auxiliar a aprendizagem desta disciplina, Hostins e Raabe (2007)
observam que existe uma tendência, tanto na comunidade científica brasileira quanto em
livros didáticos, para a utilização de pseudolinguagens com a utilização de palavras
reservadas em português. Esta abordagem tem sido adotada para que a aprendizagem tenha
um enfoque maior nos aspectos da lógica de programação, sem adentrar aspectos técnicos de
sintaxe. Atento a esta tendência o Grupo de Informática na Educação (GIE) da UNIVALI vem
realizando pesquisas a fim de desenvolver ferramentas que possam melhorar o aprendizado
dos alunos nas disciplinas introdutórias, um dos frutos destas pesquisas é o WebPortugol,
desenvolvido por Hostins e Raabe (2007), uma ferramenta acessível via navegador de Internet
que possibilita a edição e testes de programas escritos na pseudolinguagem Portugol.

Com o intuito de evoluir a ferramenta, no início de 2009 iniciou-se um novo projeto

tendo como base o WebPortugol, com o objetivo de alterar a sintaxe da linguagem,
denominada Portugol 1.1, para que esta se tornasse mais similar as linguagens C e PHP(PHP:
Hypertext Preprocessor), tal linguagem foi batizada de Portugol 2.0. Em decorrência da nova
sintaxe, optou-se por construir um novo ambiente e descontinuar o WebPortugol, nasciam
assim o Portugol Core e o Portugol Studio (NOSCHANG, 2012).

O Portugol Core compreende o núcleo da linguagem Portugol 2.0, dividido em

analisador sintático, analisador semântico e interpretador, desenvolvido com o intuito de ser
interoperável com outras ferramentas, graças a esta característica foi possível viabilizar os
trabalhos de Oliveira (2013) e Mannes (2013). Já o Portugol Studio é um ambiente de
 17

desenvolvimento que permite a criação e execução de algoritmos construídos na linguagem

Portugol 2.0 (NOSCHANG, 2012). Conforme Pelz (2014) a ferramenta oferece suporte a
leitura e escrita de arquivos, arquivos separados em abas, salientador de sintaxe com
diferentes temas, console de entrada e saída de dados, localização e substituição de palavras, e
exibição de mensagens de erro das análises feitas pelo núcleo.

1.1 PROBLEMATIZAÇÃO

1.2 FORMULAÇÃO DO PROBLEMA

Professores historicamente vêm enfrentando a difícil questão de quanto feedback
individual devem fornecer aos estudantes em exercícios como problemas matemáticos,
algoritmos ou redações. Por um lado, a avaliação é a base da experiência educacional, pois
permite aos estudantes aprenderem com seus próprios erros. Por outro lado, avaliar cada
estudante individualmente pode exigir um grande esforço de tempo (HUANG et al., 2013).

O tamanho da classe também prejudica a aprendizagem, para Lahtinen et al. (2005) os

grupos de estudantes são grandes e heterogêneos, portanto, se torna difícil desenvolver
exercícios que beneficiam a todos. Além disso, Nguyen et al. (2014) observa que o tempo em
laboratório nunca é o bastante e que eles frequentemente competem com outros estudantes
pela atenção do professor.

A estratégia pedagógica mais usual no ensino de programação é deixar os estudantes

praticarem repetidamente a resolução de problemas algorítmicos. Estudantes aprendem de
maneira mais rápida quando eles cometem erros, especialmente na programação. Em outras
palavras, obter a resposta errada ajuda os estudantes a identificar erros em sua solução e
possibilitam a busca pela resposta correta. Com este objetivo, padrões pedagógicos são
construídos para capturar as melhores práticas em um domínio específico, alguns padrões já
definidos envolvem o aprendizado por erros, com implicações especiais no ensino de ciência
da computação (JERINIC, 2012).

É essencial que os estudantes tenham a oportunidade de praticar suas novas

habilidades em programação em um ambiente onde eles possam receber feedback construtivo
e corretivo (VENABLES e HAYWOOD, 2003). Segundo Raabe et al. (2007), a
disponibilidade e utilização de ambientes desenvolvidos especificamente para o ensino de
 18

algoritmos foi, dentre muitas variáveis envolvidas, responsável pela redução do índice de
reprovação de 50% em 2001, para 35% em 2007.

Sendo o feedback tão necessário, Marceau et al. (2011) afirma que a mensagem de
erro é o ponto de contato mais importante entre o sistema e o programador, é essencial
oferecer boas mensagens para programadores novatos. Algumas ferramentas de
desenvolvimento auxiliam na tarefa de detectar erros no código-fonte, mas geralmente as
mensagens de erros são tão difíceis de compreender que se torna mais um desafio para o
aluno entender qual foi o seu erro (HRISTOVA et al., 2003), ou que decisão tomar para
resolver os problemas encontrados (JERINIC, 2012). Os motivos para mensagens de erros
serem ineficientes são diversos, para Nienaltowski et al. (2008) as ferramentas comerciais são
construídas para especialistas, e suas mensagens de erros são superficiais demais, não muito
visuais e técnicas demais.

Com o intuito de oferecer um melhor feedback ao aluno, Pelz (2014) propôs um

gerador de dicas para guiar novatos na aprendizagem de programação, este integrado ao
Portugol Studio. Tal gerador de dicas é um mecanismo para correção estática que oferece
dicas relevantes para o aluno conseguir resolver problemas pré-definidos.

O trabalho de Pelz (2014) rendeu bons frutos, além do desenvolvimento do corretor

estático que é baseado em algoritmos que percorrem a árvore sintática abstrata, denominados
tree walkers, outras melhorias foram realizadas no Portugol Core, como a implementação do
suporte ao padrão de projeto Visitor. Porém as dicas do corretor são exibidas no mesmo local
das mensagens do analisador sintático, demonstrando assim, aspectos de protótipo. Além
disso, não foi possível verificar se as dicas são consistentes, pois a implementação não foi
finalizada em tempo hábil para a realização dos testes com os usuários.

Para a realização das provas de conceito do trabalho de Pelz (2014), somente duas
questões foram preparadas. Portanto, não foram desenvolvidos muitos tree walkers,
necessários para emitir dicas, para a elaboração de mais questões.

Ao possuir um conjunto significativo de tree walkers é possível então criar um editor

de questões com o intuito de facilitar a personalização e criação de exercícios por professores
não envolvidos no projeto. Estimulando assim a criação de um banco de exercícios auto
corrigíveis (PELZ, 2014).
 19

1.2.1 Solução Proposta

A solução proposta abrange um editor de exercícios para o corretor estático e
dinâmico do Portugol Studio, a inferência e desenvolvimento de novos tree walkers e também
um teste com os alunos com o objetivo de verificar qual o impacto que o corretor tem na
resolução de exercícios pelo aluno.

Editor de exercício para o corretor

Este trabalho consiste na criação de um editor de questões, que facilite a criação de

novas questões voltadas ao corretor desenvolvido em Pelz (2014). Este corretor possui uma
interface amigável, e permite criar, editar e salvar exercícios, inserir uma solução modelo,
bem como associar tree walkers aos exercícios.

Definição e coleta das questões para análise no ambiente ALICE

Além do editor, este trabalho também contempla o desenvolvimento de novos tree

walkers, tendo como referência a base de questões do ALICE e pesquisa bibliográfica para
inferir os erros mais comuns cometidos por alunos novatos. O ALICE é um ambiente virtual
de ensino onde são disponibilizados conteúdos e materiais complementares a disciplina de
Algoritmos e Programação, além disso, os alunos podem enviar soluções de exercícios pelo
ambiente e receber a correção no mesmo.

A base de questões armazenadas no ambiente ALICE é composta por respostas de

alunos novatos a lista de 60 exercícios definidas em Pelz (2011). Para poder inferir os erros
mais comuns cometidos por estes alunos, foi realizada uma pesquisa com base nas submissões
armazenadas neste ambiente. Como a quantidade de soluções disponíveis no ambiente é alta,
por volta de 1429, e a inferência foi realizada pelo pesquisador, decidiu-se definir um
conjunto menor de questões. Desta forma, foram selecionadas 12 questões dentre as 60
questões existentes.

Os critérios adotados para selecionar estas 12 questões foram:

 Alto índice de erros: A questão possui uma porcentagem de submissões erradas

significativa em relação as outras questões, para que oferecesse maior subsídio
ao processo de realização da inferência.
 20

 Cobrir diferentes tópicos da disciplina: Outro critério observado para a seleção

foi o tópico abordado na questão. Foram selecionadas as questões de modo a
contemplar os tópicos com maior incidência de erros que são: desvio
condicional, laço de repetição, vetores e matrizes.

 Formarem uma amostra significativa da população de erros existentes na base:

O total de soluções com erros na base do ALICE era de 1429. A partir das
questões selecionadas analisamos 212 soluções que correspondem a 14,83% do
total. Usando o calculo de erro amostral pode-se demonstrar que esta porção
restringe o erro ao máximo de 6%. Segundo Barbeta (2002), a Equação 1
fornece a primeira aproximação do tamanho da amostra, enquanto a Equação 2
oferece o tamanho da amostra. Tendo em mãos a população e o tamanho da
amostra, foi possível calcular a taxa de erro máximo de aproximadamente 6%.

1
𝑛0 = Equação 1
𝐸02
𝑁 × 𝑛0
𝑛= Equação 2
𝑁 + 𝑛0

 Serem adequadas para construção de um instrumento de teste: As questões

também foram selecionadas de modo a servirem para constituição de um teste a
ser aplicado a um grupo de alunos para respondê-las, ou seja, passíveis de
serem respondidas no corretor do Portugol Studio. Este teste irá permitir a
avaliação da consistência das dicas emitidas pelos tree walkers.

A Figura 1 ilustra o SQL (Structured Query Language) utilizado para obter a

porcentagem de erros em cada questão.

Figura 1. SQL utilizado para obter a porcentagem de erros.

 21

A Tabela 1 a seguir mostra as questões selecionadas, bem como seu tópico abordado e
a porcentagem de erro constatada. Os critérios adotados permitiram reduzir o universo de
submissões analisadas em aproximadamente 80%.

Tabela 1. Questões selecionadas para a análise dos erros.

Tópico Nº Questão % Erros

Desvio 14 72%

Desvio 18 67%

Laço 27 75%

Laço 29 79%

Laço 30 63%

Laço 34 64%

Laço 40 69%

Vetor 45 69%

Vetor 47 76%

Vetor 51 81%

Matriz 57 76%

Matriz 60 90%

Para obter as questões do ambiente ALICE foi desenvolvido um script na linguagem

JavaScript1, este se conectava com o banco de dados do ambiente, buscava as soluções dos
alunos que continham erros e salvava cada uma em um arquivo com a extensão “.por”, que é
utilizada pelo Portugol Studio para salvar e abrir algoritmos escritos em Portugol. Estes
arquivos serão úteis nos testes dos tree walkers desenvolvidos. Na 0 a seguir fica evidenciado
o script e a query utilizada.

1
O JavaScript foi executado localmente e sem o auxílio de um browser, isto foi possível por meio do projeto
NodeJS, que permite o desenvolvimento na linguagem JavaScript em um ambiente server-side.
 22

Figura 2. Script e query utilizados para obtenção das questões.

Inferência dos erros cometidos a partir das questões do ALICE

Com a seleção das questões e a obtenção das soluções submetidas pelos alunos, foi
realizado o processo de inferência dos erros mais comuns.

Durante o processo foram encontradas diversas soluções idênticas, suspeita-se de um

alto índice de plágio, já que os alunos poderiam resolver as questões em casa sem a presença
de um professor. Além disso, algumas destas submissões foram desenvolvidas na linguagem
C, portanto não se aplicam em um corretor baseado em Portugol.

É importante elucidar que os erros foram analisados em submissões finais, o estudante

pode ter cometido outros erros no desenvolvimento da solução. Alguns dos erros encontrados
eram semânticos ou sintáticos, portanto, não são de valia para o corretor estático ou dinâmico.

Experimento para avaliar a influencia das dicas

Este trabalho também propõe um experimento para avaliar a influencia das dicas
emitidas pelo corretor nas ações tomadas pelos alunos através da realização de uma lista de
 23

exercícios criados com o editor de questões proposto, através de um instrumento de teste

integrado ao Portugol Studio. Os exercícios que serão verificados serão selecionados a partir
da lista em Pelz (2014), tendo como critério para a seleção das questões terem um índice de
erros maior em relação as outras, cobrir diferentes tópicos da disciplina, e serem adequadas
para a construção do instrumento de teste.

1.3 OBJETIVOS

1.3.1 Objetivo Geral

 Realizar um experimento para avaliar a influencia das dicas emitidas pelo corretor nas
ações tomadas pelos alunos.

1.3.2 Objetivos Específicos

 Inferir os erros mais comuns realizados pelos alunos que possam ser detectados por
tree walkers.
 Implementar tree walkers realizando a integração das dicas disparadas por estes com a
interface do Portugol Studio.

 Desenvolver um editor de questões para o Portugol Studio.

1.4 METODOLOGIA
Nesta seção, um detalhamento dos procedimentos metodológicos utilizados para o
desenvolvimento do trabalho é apresentado.

1.4.1 Desenvolvimento dos Tree Walkers

O desenvolvimento dos tree walkers inferidos se deu utilizando as estratégias
definidas no item 3.1 , tendo como exemplos outros tree walkers que já haviam sido criados
no trabalho de Pelz (2014).

Além disso, foram utilizados testes unitários, desta forma todas as situações em que os
tree walkers deveriam detectar erros foram especificadas, quando se desejava testar o tree
walker apenas se executava o teste unitário que mostrava o resultado encontrado. Este
processo é documentado mais profundamente também no item 3.1 .
 24

1.4.2 Desenvolvimento do Editor de Questões

O editor de exercícios para o Portugol Studio foi construído observando os requisitos
funcionais, não funcionais e regras de negócios especificados detalhadamente no item 3.2.2 .
Para o desenvolvimento com os frameworks utilizados (AngularJS e Bootstrap) foram
utilizadas as suas respectivas documentações e exemplos, que podem ser encontradas online.

Outras ferramentas foram utilizadas durante o desenvolvimento, como o GulpJS2 e o

Bower3. O GulpJS permite a criação de um de um fluxo de trabalho mais produtivo, bastando
apenas um comando para que seja iniciado um servidor com a aplicação e que a mesma seja
atualizada automaticamente quando o editor de código salva um arquivo do código-fonte,
além de outras tarefas repetitivas como o deploy da aplicação. Já a ferramenta Bower é um
gerenciador de pacotes com as bibliotecas utilizadas no projeto, desta maneira é simples que
se instale uma nova dependência ou que se atualizem as demais. A página inicial do projeto4
no GitHub fornece um passo-a-passo de como utilizar estas duas ferramentas.

1.4.3 Experimento com os Alunos

Para inferir se a mensagem de um tree walker está sendo eficiente utilizou-se uma
metodologia inspirada no trabalho de Marceau et al. (2011), detalhada na seção 2.3.2 Ao
analisar se um tree walker foi eficiente, observou-se o código-fonte do aluno na correção
seguinte a emissão das mensagens. Para cada tree walker e código-fonte analisado será
anotado uma rubrica, que representa a alteração que o aluno realizou no código para resolver
o problema. A Tabela 2 demonstra as rubricas utilizadas e sua.

Tabela 2. Rubricas possíveis que serão anotadas.

Rubrica Explicação
Mnemônico da palavra fixed (corrigido). Será assinalado quando o aluno
[FIX]
corrigiu completamente apontado pela mensagem de erro.
Mnemônico da palavra attention (atenção), será assinalado quando se
constatar que o aluno está tentando resolver o problema, mas sua solução
[ATT] ainda não é correta. Entende-se por atenção quando o aluno clicou em uma
das mensagens que aparece no painel ou realizou uma alteração no código-
fonte para tentar solucionar o problema.

2
Para mais informações visite http://gulpjs.com/.
3
Para mais detalhes visite http://bower.io/.
4
Disponível em https://github.com/andreihod/Portugol-Editor-Exercicios.
 25

Mnemônico da palavra unrelated (sem relação), e será assinalado quando a

[UNR]
alteração do aluno não tem relação com o problema constatado.

O processo de anotar as rubricas para cada correção se deu em 3 etapas: primeiramente

se anotava como “FIX” as mensagens que existiam em uma correção mas não na correção
seguinte do aluno, as que persistiam ou não tinham continuidade eram anotadas com “UNR”,
em uma segunda etapa se analisou as rubricas com “UNR”, se o aluno deu foco na mensagem
do corretor significa que o mesmo prestou atenção, então se assinalou a rubrica “ATT”, por
último se analisou todas as correções com rubricas “UNR”, agora em menor quantidade, e se
analisou o código-fonte do aluno na correção seguinte, se o aluno realizou alguma alteração
que tem a ver com o erro, então se assinalou a rubrica “ATT”, o processo de análise do
código-fonte foi a última análise pois é o que demanda maior esforço do pesquisador.

A partir das rubricas anotadas, foi possível calcular uma “taxa de eficiência” para cada
tree walker. Era desejado calcular as taxas de cada aluno separadamente e no fim realizar uma
média, pois um aluno que execute a correção várias vezes pode influenciar na qualidade os
resultados, mas por ter sido o primeiro contato dos alunos com o corretor, e o tempo do
experimento ter sido limitado por problemas técnicos, poucos dados sobre os tree walkers
foram coletados, fazendo que o cálculo de média por aluno se tornasse irrelevante. A Equação
3 demonstra o cálculo de cada tree walker. A variável t representa o tree walker.

𝐹𝐼𝑋
𝑒𝑡 = ∗ 100 Equação 3
𝑈𝑁𝑅 + 𝐴𝑇𝑇 + 𝐹𝐼𝑋

1.5 ESTRUTURA DO TRABALHO

Este trabalho é dividido em quatro capítulos. No capítulo 1, Introdução, é discutido a
problematização, os esforços já realizados na tentativa de resolver o problema, a solução
proposta por este trabalho, os objetivos que este trabalho pretende alcançar. Além disso, é
abordada a metodologia utilizada para a elaboração do mesmo.

No capítulo 2 é abordado a Fundamentação Teórica, onde são detalhados conceitos

fundamentais para a elaboração do trabalho. Neste capítulo é abordada correção estática e
etapas da compilação, o Portugol Studio bem como seu corretor estático e dinâmico, e
trabalhos similares na área de corretores automáticos e avaliação de efetividade de mensagens
de erros.
 26

No capítulo 3 é detalhado o Desenvolvimento do projeto, os tree walkers inferidos e

desenvolvidos, o editor de questões criado e o experimento da avaliação do corretor estático.

No capítulo 4 é demonstrado os resultados obtidos neste trabalho, como os softwares

finalizados e as informações obtidas com o experimento com os alunos.

No capítulo 5 é detalhado as Conclusões deste trabalho, bem como ideias para

trabalhos futuros e as referências bibliográficas utilizadas.
 27

2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo serão discutios os referenciais teórios para o desenvolvimento deste
trabalho. Dentre os assuntos discutidos encontram-se correção estática, Portugol Studio e
trabalhos similares.

2.1 CORREÇÃO ESTÁTICA

Para Ala-Mutka (2005) existem duas abordagens principais para a correção de
algoritmos. Uma delas se faz através da execução dos algoritmos analisados para determinar
se está correto ou não, esta abordagem se denomina correção dinâmica. A outra abordagem se
denomina correção estática, e é realizada sem a necessidade de executar o algoritmo e pode
identificar problemas não constatados em uma correção dinâmica.

Parte da correção estática pode ser realizada junto ao compilador ou interpretador da

linguagem, visto sua capacidade de identificar variáveis não utilizadas, conversões implícitas,
funções de uma linguagem sendo utilizada fora da convenção, entre outros (ALA-MUTKA,
2005). Além disso, é possível avaliar o estilo de programação a fim de identificar práticas de
legibilidade e manutenção do código, alguns dos critérios adotados são tabulação,
comentários descritivos e nomes de variáveis significativos (RAHMAN et al., 2007). Estes
elementos são muito importantes para as desenvolvedores facilmente entender e melhorar um
programa no futuro.

De acordo com Ala-Mutka (2005), apesar do fato que a maioria dos erros de
funcionamento ser mais habitualmente identificados dinamicamente na execução do programa
com casos de testes, alguns erros ou trechos de código com erros em potencial podem ser
reconhecidos estaticamente, alguns exemplos são: identificação de problemas na atualização
da variável de controle de laços de repetição, inconsistência entre o tipo de parâmetro e seu
uso, código não utilizado e condições redundantes.

A correção estática engloba diversas técnicas de análise, destacam-se: avaliação do

estilo de programação, verificação de erros sintáticos e semânticos, análise de métricas de
software, detector de palavras chaves, constatação de plágio, e análise de diagrama (Rahman
et al., 2007).

Existem diversas vantagens na correção estática quando comparada a dinâmica, para

Truong et al. (2004), como esta abordagem não necessita que o código seja compilado e
 28

executado, exige certamente menos carga de trabalho para o computador. Rahman (2007)
observa também que apenas programas livres de erros podem ser analisados pela correção
dinâmica, ao contrário da estática.

Porém, existem algumas desvantagens na correção estática, para Nguyen et al. (2014),
exercícios de programação são complexos e podem ser abordados com muitas soluções ou
estratégias, além de tipicamente exigirem criatividade. Portanto Truong et al. (2004) observa
que instrutores ou professores precisam fornecer diversas soluções modelos para que estas
sejam comparadas as dos alunos, caso contrário o corretor não será capaz de lidar com a
variabilidade das soluções dos estudantes. Apesar desta desvantagem, Nguyen et al. (2014)
afirma que em muitos exercícios de programação, os alunos irão se beneficiar mais com uma
avaliação personalizada do que um binário correto ou incorreto.

Segundo Ala-Mutka (2005) a maior desvantagem da correção estática é que esta não
pode avaliar se uma questão está correta e funcional. Este critério é muito importante para
corretores automáticos e só pode ser resolvido através de um corretor dinâmico. Segundo
Truong et al. (2004) aplicações em sistemas tutores ou corretores costumam fazer uso de
ambas abordagens para avaliar os algoritmos dos estudantes.

2.1.1 Etapas da Análise de Programas

Segundo Aho et al. ( 2007), uma linguagem de programação pode ser definida pela
descrição de seus programas, que se denomina a sintaxe, e do que os mesmos significam que
se denomina semântica. Portanto, um compilador necessita analisar se o programa segue as
convenções sintáticas e semânticas da linguagem fonte.

Na compilação, a análise de um algoritmo consiste em três fases: análise linear, na

qual um fluxo de caracteres constituindo um programa de computador é lido e agrupado em
tokens, análise hierárquica, na qual os tokens são aninhados hierarquicamente, e análise
semântica, na qual verificações são realizadas a fim de se assegurar que os componentes de
um programa se combinam de forma significativa (Aho et al., 2007).

Análise Semântica

Segundo Rahman et al. (2007) um erro semântico ocorre quando um comando é

escrito gramaticalmente correto, mas logicamente errado. Alguns erros semânticos comuns
 29

são laços de repetição infinitos e divisão por zero, estes erros não geram mensagens de erros
na etapa de compilação, mas durante a execução podem produzir resultados indesejados.

De acordo com Aho et al. (2007), alguns exemplos de verificação estática que
compreende a análise semântica são:

1. Verificação de tipos: Um compilador deve gerar um aviso se um operador for

aplicado a um operando com tipo incompatível, por exemplo, na linguagem
Portugol se uma variável do tipo caracter for atribuída a uma variável do tipo
inteiro um erro de tipo incompatível é emitido.

2. Verificação de fluxo de controle: Os enunciados que fazem o fluxo de controle

deixar um escopo precisam ter algum local para onde transferir o controle, por
exemplo, uma instrução retorne da linguagem Portugol faz com que o controle
deixe uma função e retorne um valor, um erro ocorre se tal instrução não está
envolvida em uma função.

3. Verificações de unicidade: Um objeto precisa ser definido exatamente uma

vez, por exemplo, na linguagem Portugol todo programa pode ter apenas uma
função inicio, caso contrário um erro é emitido.

Linguagens de programação são normalmente complexas e traduzir o código-fonte

diretamente para linguagem de máquina não é desejável (JONES, 2003). Neste contexto, o
uso de árvores sintáticas abstratas como forma de representação intermediária permite que a
tradução seja desacoplada da análise sintática (AHO et al.,2007). A Figura 3 demonstra uma
árvore sintática abstrata para representar a expressão (3 + 4) * 5.

Figura 3. ASA para a expressão (3 + 4) * 5.

Fonte: Aho et al. (2007).
 30

Árvores sintáticas abstratas permitem representar características essenciais de uma

estrutura de entrada e omitir detalhes desnecessários da sintaxe. Uma forma de distinguir uma
ASA (árvore sintática abstrata) de uma árvore sintática concreta é perceber a omissão de nós
que representam pontuação, como ponto-vírgula ao fim de comandos, ou vírgulas separando
parâmetros (JONES, 2003). A Figura 4 mostra um exemplo de um desvio condicional, e na
Figura 4 sua respectiva árvore sintática abstrata.

Figura 4. Exemplo de um simples desvio condicional.

Fonte: Hostins (2006).

Figura 5. Exemplo de uma ASA.

Fonte: Hostins (2006).

Segundo Louden (1997), a utilização de ASA é uma das técnicas mais comuns para
construção de interpretadores, uma vez que gera uma estrutura do programa em memória que
pode ser percorrida a fim de realizar a interpretação do código, obtendo assim o mesmo
resultado de um programa compilado.

Tree Walkers
 31

Segundo Jones (2003) uma ASA pode ser construída através de um analisador (em
inglês se denomina parser) codificado a mão, ou através de código produzido por geradores
de parsers. Dentre diversas ferramentas utilizadas neste contexto, destaca-se o ANTLR
(Another Tool for Language Recognition), que segundo Parr (2009) pode ser resumido em
duas funcionalidades: uma ferramenta que traduz uma gramática para um parser ou lexer
(analisador léxico) em Java (ou outra linguagem alvo), e a uma biblioteca para a execução
deste parser/lexer produzido.

Por padrão, parsers gerados com a ferramenta ANTLR em sua versão atual (4.0),
constroem uma árvore sintática que armazena a maneira que este reconheceu a estrutura de
entrada. É uma estrutura muito eficiente, pois contém todo o conhecimento de como o parser
agrupou os símbolos em frases (PARR, 2009).

Segundo Pelz (2014), a hierarquia de classes de uma árvore sintática abstrata sugere o
cumprimento com o padrão de projeto Composite, que de acordo com Gamma et al. (1995) é
descrito como o resultado da composição de um ou mais objetos similares. Este padrão de
projeto sugere também a utilização do padrão Visitor, que percorre uma estrutura Composite
resulta em algo similar a uma inferência de tipos.

Para percorrer uma ASA, Parr (2009) observa que a ferramenta ANTLR possui um
ParseTreeWalker que sabe como percorrer estas árvores e disparar eventos em
implementações de listeners ou visitors que um desenvolvedor pode criar por ele próprio. No
Quadro 1 é possível observar a interface para a implementação de visitors para a gramática da
linguagem de programação Java.

Quadro 1. Interface para a implementação de visitors.

public interface JavaListener extends ParseTreeListener<Token> {
void enterClassDeclaration(JavaParser.ClassDeclarationContext ctx);
void exitClassDeclaration(JavaParser.ClassDeclarationContext ctx);
void enterMethodDeclaration(JavaParser.MethodDeclarationContext ctx);
...
}

Fonte: Parr (2009).

Além disso, o ANTLR gera um listener base com implementações vazias dos métodos
da interface, para o exemplo do Quadro 1 se denominaria JavaBaseListener, portanto, um
desenvolvedor pode construir seus próprios listeners utilizando a classe base como
superclasse e implementando os métodos que tem interesse (PARR, 2009). Assumindo que o
 32

desenvolvedor tenha criado um objeto listener chamado MyListener, o Quadro 2 demonstra a

utilização do mesmo.

Quadro 2. Utilização de um listener a partir de um parser do ANTLR.

JavaLexer lexer = new JavaLexer(input);
CommonTokenStream tokens = new CommonTokenStream(lexer);
JavaParser parser = new JavaParser(tokens);
ParserRuleContext<Token> tree = parser.compilationUnit(); // parse

ParseTreeWalker walker = new ParseTreeWalker(); // create standard walker

MyListener extractor = new MyListener(parser);
walker.walk(extractor, tree); // initiate walk of tree with listener

Fonte: Parr (2009).

Na dissertação de Pelz (2014) foram desenvolvidos tree walkers que no contexto de

seu trabalho percorrem com diferentes estratégias uma ASA, possibilitando que se
identifiquem padrões de erros comuns realizados por alunos em um problema específico.

A abordagem escolhida para a implementação destes tree walkers em Pelz (2014) foi a
visitor, ela é realizada ao adicionar um método abstrato, que recebe por parâmetro um
visitante, no topo da hierarquia de classes dos nós de uma ASA, para cada classe concreta
deve-se por fim sobrescrever este método. A Figura 6 apresenta um diagrama de classe que
representa esta estrutura.

Figura 6. Exemplo de uma ASA.

Fonte: Pelz (2014).

Uma ASA pode ser percorrida por tree walkers tanto através de listeners, quanto
através de visitors, Parr (2009) observa que a principal diferença entre estas abordagens é que
por listeners os métodos desenvolvidos são chamados independentemente por um tree walker
 33

padrão, já na abordagem por visitors os métodos invocados devem chamar a visita de seus nós
filhos, caso contrário, parte da ASA não será percorrida.

2.2 PORTUGOL STUDIO

O Portugol Studio é um ambiente de desenvolvimento que permite a criação, edição e
execução de programas escritos na linguagem Portugol 2.0. O ambiente possui todos os
recursos básicos de uma IDE (Integrated Development Environment), tais como: manipulação
de arquivos, execução e interrupção de programas, console para entrada e saída de dados,
console para exibição de erros de compilação e execução, salientador de sintaxe e code
completion (NOSCHANG, 2012). Segundo Noschang et al. (2014) este projeto se difere de
IDEs professionais por não focar na produtividade, mas sim na aprendizagem, tornando-a
mais amigável a alunos iniciantes.

A interface do Portugol Studio se divide em três partes principais, são elas: (i) o
código fonte, onde os estudantes podem criar seus programas; (ii) árvore de símbolos, onde é
possível visualizar as variáveis do programa e (iii) console de entrada e saída/ mensagens,
onde o estudante visualiza mensagens de erros e interage com seu programa (NOSCHANG et
al., 2014). Na Figura 7 é possível visualizar a interface de da IDE Portugol Studio em
funcionamento.

Figura 7. Interface do ambiente Portugol Studio 2.0 em execução.

As mensagens de erros no Portugol Studio foram elaboradas de maneira a oferecer

dicas úteis aos alunos, visto que estas mensagens em IDEs professionais são pouco
informativas e repletas de termos técnicos que normalmente o estudante não conhece, isto só
 34

foi possível graças a uma abordagem especial no analisador semântico para que este percorra
a ASA de diferentes formas a fim de identificar erros de uma maneira mais precisa
(NOSCHANG et al., 2014). A Figura 8 demonstra algumas mensagens de erros emitidas pelo
Portugol Studio.

Figura 8. Mensagens de erros na interface do Portugol Studio.

Fonte: Noschang et al. (2014).

Um depurador permite que um programa seja executado passo-a-passo em um

ambiente de desenvolvimento, e que os valores das variáveis sejam observados durante este
processo. Segundo Noschang et al. (2014) esta funcionalidade foi destacada no Portugol
Studio, optou-se por utilizar botões de execução e depuração do mesmo tamanho na interface,
a fim de chamar a atenção do aluno e enfatizar sua importância. Durante o desenvolvimento
do programa o estudante pode visualizar na árvore de símbolos as variáveis utilizadas, bem
como seu escopo representado pela hierarquia da árvore. Quando o aluno depura o programa,
os valores de cada variável passa a ficar visível, e é possível observar as mesmas sendo
alteradas durante a execução. A Figura 9 demonstra a depuração de um programa no Portugol
Studio.

Figura 9. Depuração de um código no Portugol Studio.

 35

A utilização do depurador demanda o acionamento do botão depurar, representado na

Figura 9 por um ícone de inseto, que ao ser clicado inicia o processo de depuração, ao ser
clicado novamente avança um passo na depuração, além disso, a linha que está sendo
depurada fica sempre destacada na tela, para que o aluno não se confunda em depurações com
muitas linhas ou laços de repetição (NOSCHANG et al., 2014).

Além de um depurador, a IDE possui um corretor dinâmico, segundo Pelz (2014) a

mesma utiliza o mecanismo de entrada e saída da linguagem Portugol para realizar a
verificação do comportamento do algoritmo desenvolvido pelo aluno. Os casos de testes são
descritos em um arquivo XML(Extensible Markup Language), durante a execução o corretor
entra com os dados descritos neste arquivo em cada instrução leia, e a cada instrução escreva
a saída é comparada com a armazenada no arquivo. O resultado desta verificação é mostrado
ao aluno em forma de casos de testes, podendo ser corretos ou falhos. Este corretor será
detalhado na seção 2.2.1 .

O Portugol Studio faz uso de outro projeto internamente, o Portugol Core. Segundo
Noschang (2012) este projeto é totalmente independente do Portugol Studio, permitindo assim
a utilização do mesmo por outras ferramentas e é dividido internamente em 3 partes:
analisador sintático, semântico e interpretador.

O Portugol Core implementa o suporte para a linguagem Portugol 2.0 que possui todos
os elementos básicos de uma linguagem de programação, tais como: estruturas de controle
para desvio condicional e laços de repetição, operações aritméticas, de atribuição, booleanas e
de manipulação de bits, diferenças de escopo entre variáveis, funções e procedimentos, e
também suporte a vetores e matrizes (PELZ, 2014). Além destes elementos básicos, o
Portugol Studio oferece bibliotecas para a construção de programas mais sofisticados, como
por exemplo, biblioteca gráfica e sons, permitindo o desenvolvimento de jogos de baixa
complexidade em duas dimensões, alguns exemplos do uso destas bibliotecas podem ser
obtidos no próprio Portugol Studio (NOSCHANG et al., 2014).

O Portugol possui uma linguagem intermediária representada por uma ASA, esta
árvore, por sua vez, é instanciada por um parser gerado com a ferramenta ANTLR em sua
terceira versão. O Portugol Core provê serviços de análise de código e oferece mecanismos
para a execução de entrada e saída de dados durante a interpretação da linguagem
 36

intermediária (PELZ, 2014). Na Figura 10 é demonstrada através de um diagrama de objeto a

ASA de um programa em Portugol carregado na memória.

Figura 10. Diagrama de objeto de uma ASA de um programa em Portugol.

Fonte: Pelz (2014).

Além dos recursos demonstrados anteriormente, o projeto provê apoio a aprendizagem

do aluno. Segundo Noschang et al. (2014) o aluno tem acesso dentro da própria IDE a um
conteúdo de ajuda, em que o estudante pode observar um exemplo de código que ilustra o
tópico, além do botão “Tente Você Mesmo” que quando acionado abre o código de exemplo
no Portugol Studio para que o estudante possa praticar o que aprendeu. Também existe um
canal no YouTube5 com um total de 11 vídeos onde os alunos podem aprender conceitos de
programação introdutória utilizando o Portugol Studio.

2.2.1 Corretor Proposto em PELZ

O corretor estático proposto em Pelz (2014) faz uso de uma lista de 60 problemas de
programação definidas por Pelz (2011). Todos estes problemas são integrados ao mecanismo

5
Disponível em https://www.youtube.com/user/PortugolStudio.
 37

de correção dinâmica presente no corretor automático do Portugol Studio. O objetivo deste

corretor é de melhorar o mecanismo de correção acrescentando técnicas de análise estática de
algoritmos.

Funcionamento do Corretor

Segundo Pelz (2014) uma das verificações estáticas realizada é a verificação da

quantidade de comandos leia e escreva no código do aluno, isto é necessário para o
funcionamento do corretor dinâmico, que precisa fazer a entrega de valores em comandos
leia, e recuperar as saídas de comandos escreva, portanto, para que a correção seja possível, a
quantidade destes comandos deve ser igual a quantidade de valores de entrada/saída do teste
do corretor dinâmico.

Outro exemplo de correção estática definido em Pelz (2014) é verificar se um

determinado comando é utilizado ou não na solução do aluno. Pois o aluno pode resolver um
problema corretamente do ponto de vista da correção dinâmica, mas incorretamente do ponto
de vista educacional. Um exercício pode, por exemplo, pedir a um aluno o desenvolvimento
de um algoritmo que realize a potência entre uma base e um expoente informado pelo usuário,
se este aluno utilizar uma biblioteca matemática para resolver o problema, o objetivo do
exercício de utilizar laços de repetição não é alcançado.

Para Pelz (2014) estas duas análises mencionadas anteriormente entregam poucas
dicas e não verificam a solução como um todo. A análise feita para avaliar estruturas faltantes
ou em excesso, é realizada comparando a resposta do aluno com uma solução modelo, para
isto, ambas às soluções devem ser normalizadas. O processo de normalização é necessário,
pois algumas instruções apesar de serem diferentes possuem o mesmo mecanismo lógico, por
exemplo, os comandos enquanto, faça enquanto e para são diferentes, mas todos representam
um laço de repetição e executam a mesma tarefa.

Após o processo de normalização, a estrutura dos algoritmos da solução modelo e do

aluno são serializadas em números, como é demonstrado no Quadro 3, para então serem
comparadas com o algoritmo da distância de Levenshtein (PELZ, 2014).
 38

Quadro 3. Exemplos de normalização de algoritmos.

Algoritmo Portugol Normalizado
programa { Inicio 0 {
funcao inicio() { declVar 1
inteiro numero, result, contador declVar 1
escreva("Informe o número para ver sua tabuada: ") declVar 1
leia(numero) saida 2
entrada 3
para (contador = 1; contador <= 10; contador ++) { iniVar 4
result = numero * contador loop { 5
escreva (numero, " X ", contador, " = ", result , "\n") atrib 6
} saida 2
} atrib 6
} }
}

Fonte: Pelz (2014).

Segundo Gilleland (2009) a distância de Levenshtein é realizada ao verificar quantas

adições, remoções ou substituições são necessárias para transformar uma cadeia de caracteres
em outra. Neste sentido, Pelz (2014) elucida que são comparadas as strings serializadas da
solução do aluno e da solução modelo.

O corretor de Pelz (2014) não se limita apenas a encontrar estruturas faltantes entre
duas soluções, mas também pode percorrer a ASA com algoritmos específicos em busca de
erros que alunos tendem a cometer. Caso estes algoritmos de verificação, denominados tree
walkers, encontrem os padrões que foram programados para verificar, uma dica é enviada ao
aluno. O funcionamento do corretor é demonstrado na Figura 11.

Figura 11. Ilustração d o funcionamento completo do corretor.

Fonte: Pelz (2014).
 39

Tree Walkers Desenvolvidos

O desenvolvimento de tree walkers foi realizado através do padrão Visitor, e a

navegação pela ASA é realizada de maneira similar a uma análise semântica. Portanto, um
tree walker pode possuir uma tabela de símbolos como as que são utilizadas comumente em
compiladores ou interpretadores. Sendo assim, um tree walker que deseja verificar se uma
variável não foi utilizada, por exemplo, pode armazenar as variáveis em uma tabela de
símbolos e verificar quais delas não são utilizadas em nenhuma expressão (PELZ, 2014).

Segundo Pelz (2014) o processo de inferência dos tree walkers desenvolvidos se deu
pela análise manual das soluções dos alunos no ambiente ALICE por um professor
especialista, por fim, foram verificados quais deles eram passíveis de identificação por tree
walkers. O Quadro 4 demonstra os tree walkers que foram desenvolvidos em Pelz (2014),
bem como uma breve descrição dos mesmos.

Quadro 4. Tree Walkers desenvolvidos em Pelz (2014)

Nome do Tree Walker Parâmetros Descrição
MandatoryInstructions Lista de nós que Procura a existência de uma ou mais
devem aparecer na estruturas dentro do código do aluno.
estrutura do Realiza uma notificação quando não
programa. encontrado.
ProhibitedInstructions Lista de nós que não Realiza uma notificação quando
podem aparecer na encontra um ou mais instruções na
estrutura do estrutura do aluno.
programa.
ReadAfterOperation N/D Realiza uma notificação caso o aluno
faça uma entrada de dados após ter
manipulado as variáveis do programa.
ReadWriteOrder N/D Realiza uma notificação ao perceber
que a ordem das variáveis passadas por
parâmetro no comando leia está em
uma ordem diferente durante a saída de
dados.
UsingAux N/D Realiza uma varredura na estrutura do
código para certificar-se que o uso de
variável auxiliar para a troca de valores
entre variáveis foi utilizada
corretamente.
VarIsNotUsed N/D Realiza a notificação de alguma
variável que foi declara e não utilizada
durante o programa.

Fonte: Pelz (2014).

 40

Definição das Questões

Os exercícios utilizados pelo corretor do Portugol Studio são representados por

arquivos XML (Extensible Markup Language), neste arquivo podem existir diversas soluções
modelos, estas são armazenadas já serializadas e com uma lista de tree walkers que serão
disparados na correção do algoritmo solução (PELZ, 2014). No Quadro 5 é demonstrado um
exemplo de um exercício armazenado em um arquivo XML.

Quadro 5. Questão representada pelo XML interpretado pelo corretor.

<questao>
<enunciado>Faça um programa que solicita ao usuário dois números inteiros e armazena
nas variáveis A e B. A seguir (utilizando apenas atribuições entre variáveis) troque os
seus conteúdos fazendo com que o valor que está em A passe para B e vice-versa. Ao final
exiba na tela os valores que ficaram armazenados nas variáveis. </enunciado>
<solucoes>
<solucao>
<modelo>programa { funcao inicio() { inteiro a,b,aux leia(a,b)
aux = a a = b b = aux escreva(a,"
",b) }}</modelo>
<visitors>
<visitor class-name="ReadWriteOrder"/>
<visitor class-name="ReadAfterOperation"/>
<visitor class-name="VarIsNotUsed"/>
<visitor class-name="MandatoryInstructions">
<parametro tipo="java.util.List">
<valores>
<valor tipo="java.lang.Class"
valor="br.univali.portugol.nucleo.asa.NoOperacaoAtribuicao"/>
<valor tipo="java.lang.Class"
valor="br.univali.portugol.nucleo.asa.NoDeclaracao"/>
</valores>
</parametro>
<parametro valor="2" tipo="java.lang.Integer"/>
</visitor>
<visitor class-name="UsingAux"/>
</visitors>
</solucao>
<solucao>
<modelo>programa { funcao inicio() { inteiro a, b leia(a,b) a = b - a
b = b - a a = b + a escreva(a,"
",b) }}</modelo>
<visitors>
<visitor class-name="ReadWriteOrder"/>
<visitor class-name="ReadAfterOperation"/>
<visitor class-name="VarIsNotUsed"/>
<visitor class-name="MandatoryInstructions">
<parametro tipo="java.util.List">
<valores>
<valor tipo="java.lang.Class"
valor="br.univali.portugol.nucleo.asa.NoOperacaoAtribuicao"/>
<valor tipo="java.lang.Class"
valor="br.univali.portugol.nucleo.asa.NoDeclaracao"/>
</valores>
</parametro>
<parametro valor="2" tipo="java.lang.Integer"/>
</visitor>
</visitors>
</solucao>
</solucoes>
<testes>
...
</testes>
</questao>
 41

2.3 TRABALHOS SIMILARES

2.3.1 Corretores Automáticos

Na dissertação de Pelz (2014) foi realizada uma análise de três revisões da literatura
sobre corretores automáticos. Douce (2006) realizou um levantamento histórico das
ferramentas de correção de algoritmos, desde 1960 até o presente. Já Ala-Mutka (2005)
direcionou sua revisão em apresentar os métodos e técnicas utilizados e como essas
ferramentas são geralmente utilizadas. Ihantola et al. (2010) atualizou a revisão de Ala-Mutka
(2005) incluindo corretores construídos após a publicação do trabalho.

Segundo Pelz (2014) a busca por corretores também foi realizada nas bases da ACM,
ScienceDirect e IEEExplore, além da leitura de artigos referenciados nas revisões sistemáticas
de Ala-Mutka (2005), Douce (2006) e Ihantola et al. (2010). Os critérios adotados para
selecionar os corretores que seriam analisados foram: possuir foco educacional em alunos
iniciantes e se preocupar com o feedback que o mesmo recebe enquanto resolve o problema, e
também o detalhamento da técnica utilizada. Dos trabalhos selecionados na análise, pode-se
destacar os seguintes corretores: Scheme-robo, PROUST, ELP, Expresso.

A Tabela 2 apresenta um resumo dos atributos dos corretores avaliados em Pelz

(2014), é demonstrado que tipo de correção os mesmos realizam e para qual linguagem alvo
estes foram desenvolvidos.

Tabela 3. Resumo dos atributos dos corretores avaliados.

Corretor Av. Av. Compara Linguagem Avalia com
Dinâmica Estática Solução Erros
Modelo Sintáticos
Sheme-Robo Sim Sim Sim Scheme Não
PROUST Não Sim Não, Utiliza Pascal Sim
Frames
ELP Sim Sim Sim Java, C# e C Não
Expresso Não Sim Não Java Sim
AutoLEP Sim Sim Sim Java Sim
Portugol Sim Sim Sim Portugol Sim
Studio

Fonte: Pelz (2014).

 42

Nestes corretores, Pelz (2014) observou que aqueles que realizam análise dinâmica
para validar a resposta do aluno, também fazem uso deste mecanismo como uma forma de
feedback ao mostrar as entradas utilizadas e as saídas obtidas. Em alguns corretores, as
mensagens de erros emitidas pelo compilador podem ser consideradas como feedback, não foi
explicitado se ocorreu algum esforço no intuito de deixa-las mais didáticas. A Tabela 3
demonstra visualmente a forma de feedback que cada corretor faz uso.

Tabela 4. Forma de feedback que cada corretor utiliza

Forma de feedback Sheme- PROUST ELP Expresso AutoLEP Portugol
Robo Studio
Exibe casos de teste X X X X
Exibe diferenças para X X X
solução modelo
Mensagens do X X X
compilador
melhoradas
Requisita presença de X X
palavra-chave
Entrega mensagem X
utilizando Frames
mapeados previamente

Fonte: Pelz (2014).

Segundo Pelz (2014), os corretores que possuem um feedback mais rico foram o
AutoLEP e o ELP. O ELP, ao contrário do AutoLEP, não possui a habilidade de analisar
algoritmos que possui erros de sintaxe, esta característica deve ser tratada com importância,
pois alunos comumente cometem este tipo de erro durante o primeiro contato com a
linguagem. O feedback considerado mais complexo é o da ferramenta PROUST, em que todo
o exercício deve ser mapeado criando todas as situações possíveis onde o aluno pode errar, o
que exige um grande esforço do professor.

2.3.2 Avaliação da Efetividade das Mensagens de Erros

Complementando a análise realizada por Pelz (2014) este trabalho buscou identificar
pesquisas que abordassem a avaliação da qualidade das mensagens emitidas. Neste sentido
encontrou-se o trabalho de Marceau et al. (2011) que é detalhado a seguir.

O referido trabalho buscou avaliar a efetividade das mensagens de erros exibidas pela
ferramenta DrScheme. Esta ferramenta tenta resolver o problema de que linguagens de
 43

programação são projetadas para especialistas, e não são muito adequadas para o ensino de
programação. Para isto, a ferramenta oferece diversos níveis da linguagem, cada qual é um
subconjunto do próximo nível, e as mensagens de erros referem-se apenas a conceitos que os
alunos aprenderam até aquele nível. Os alunos que aprendem com esta ferramenta podem
progredir por até cinco níveis, iniciando em Beginner Student Language (BSL) até Advanced
Student Language (ASL). Além disso, as mensagens do DrScheme foram desenvolvidas ao
longo de uma década de extensiva observação em laboratório e sala de aula.

Segundo Marceau et al. (2011) apesar de todo o cuidado com a ferramenta DrScheme
no ensino dos alunos, ainda é comum perceber problemas de interpretações de mensagens de
erros. Com o intuito de entender como os estudantes respondem a mensagens de erros e
determinar porque algumas mensagens causam mais dificuldades do que outras, foram
realizadas: uma análise de diversas edições do código em resposta a mensagens de erros,
entrevistas aos alunos sobre suas interpretações das mensagens de erros, e formulários de
pesquisa para os estudantes sobre o vocabulário das mensagens. Sendo que a contribuição
chave do trabalho é a sua metodologia para avaliar a mensagens de erros.

A Figura 12 demonstra uma função na linguagem Scheme submetida para execução 40

minutos após o início do curso de programação, o estudante está criando uma função chamada
label com um parâmetro denominado name. O erro está na falta do caractere “)” após name e
também conservative, a mensagem de erro exibida é a seguinte: “define: expected a name for
the function’s 2nd argument, buf found something else”.

Figura 12. Erro na ferramenta DrScheme.

Fonte: Marceau et al. (2011).
 44

Na Figura 13 é possível verificar a edição no código que o aluno realizou para corrigir
o problema que a mensagem de erro na Figura 12 apontou. Segundo Marceau et al. (2011) o
aluno inseriu a palavra name no código, e existe uma lógica para tal ação, a mensagem de erro
avisou que esperava um name no código, então o aluno tratou de colocar.

Figura 13. Código do aluno após a mensagem da Figura 12.

Fonte: Marceau et al. (2011).

Marceau et al. (2011) denota que a ferramenta DrScheme foi alterada para salvar o
programa do aluno toda vez que o mesmo tentava executá-lo, junto como a mensagem de erro
que este recebeu e a tecla pressionada em resposta a mensagem. Dos 140 alunos registrados
no curso, 64 concordaram em participar da coleta de dados.

A metodologia definida para a avaliação das mensagens de erro partiu da premissa

básica de como elas devem funcionar: se uma mensagem de erro é eficiente, é porque o
estudante leu, conseguiu entender o seu significado, e pôde usar a informação transmitida para
formular uma ação útil. Estudantes podem ficar presos em qualquer um destes passos, o
objetivo, portanto foi avaliar o quão longe nestes passos o estudante consegue progredir em
resposta a uma mensagem de erro (MARCEAU et al., 2011). Para cada execução de código
após a exibição de uma mensagem de erro, a equipe assinalou uma rubrica, como demonstra a
Tabela 4.

Tabela 5. Rubricas inferidas em cada edição de código.

Rubrica Descrição
[DEL] O estudante apagou o código problemático.

[UNR] O estudante faz algo que não tem relação ao erro e também não ajuda.

[DIFF] O estudante faz algo que não tem relação ao erro, mas corrige outro erro.

[PART] O estudante entendeu o erro e está no caminho de encontrar a solução.

[FIX] O estudante corrigiu o erro.

Fonte: Marceau et al. (2011)

 45

Segundo Marceau et al. (2011) muitos erros são variações do mesmo problema
encontrado, então estas mensagens foram agrupadas em seis categorias: erros que
correspondem a parênteses, índice fora dos limites, declarações, chamadas de função,
condições e número de parâmetros. A Tabela 5 demonstra os resultados da coleta, a coluna
“exibidos” mostra quantas vezes os estudantes viram o erro, a coluna “analisados” quantas
respostas ao erro foram verificadas, a coluna “Eficiência” indica a efetividade da mensagem
de erro para a correção do problema, enquanto as demais colunas da direita demonstram a
quantidade de cada rubrica anotada.

Tabela 6. Resultados coletados com a metodologia.

Categoria Exibidos Analisados Eficiência DEL UNR DIFF PART FIX

Parênteses 129 26 76% 0 3 1 3 19

Índice 73 33 84% 1 3 2 2 25

Declaração 73 32 50% 2 11 4 4 11

Chamada 63 29 36% 1 10 2 7 9
de Função

Condição 61 31 49% 2 12 0 4 13

Contagem 24 21 52% 1 5 0 8 7
de
Parâmetros

Fonte: Marceau et al. (2011).

Marceau et al. (2011) denota que a coluna denominada “Efetividade” não deve ser
confundida com uma simples proporção da coluna “FIX” em relação a coluna “Analisados”,
este cálculo seria errôneo de duas maneiras: as rubricas DEL e DIFF não podem ser
contabilizadas desfavorecendo a efetividade da mensagem, e também não leva em
consideração a quantidade de execuções que o usuário realizou. Para resolver estes
problemas, a efetividade foi calculada para cada estudante e somada, a Equação 3 e a Equação
4 demonstram como o cálculo foi contabilizado, para estudante s e categoria c.

𝐹𝐼𝑋
𝑝𝑠,𝑐 = Equação 4
𝑈𝑁𝑅 + 𝑃𝐴𝑅𝑇 + 𝐹𝐼𝑋
 46

𝑝𝑐 = (∑ 𝑝𝑠,𝑐 )/𝑛 Equação 5

Os resultados coletados no trabalho de Marceau et al. (2011) permitem observar que

mensagens em erros de índice fora dos limites foram facilmente corrigidos (84%), e erros
relacionados a parênteses também foram relativamente fáceis (76%). Já as demais categorias
de mensagens não se mostraram muito eficientes, especialmente na categoria de erros
relacionados as chamadas de funções (36%).

Observando os resultados obtidos neste trabalho, Marceau et al. (2011) inferiu uma
série de recomendações para melhorar as mensagens de erros em ferramentas de
desenvolvimento voltadas a educação, são elas:

 Simplifique o vocabulário nas mensagens: Mensagens de erros usualmente

tentam ser diretas, contudo, acabam utilizando termos que os alunos não
compreendem nos primeiros contatos com a linguagem.

 Ajudar os estudantes a compreender os termos salientando fragmentos de

código: Mensagens de erros contêm muitas referências ao código, como por
exemplo, “o corpo da função...” ou “encontrou uma parte extra...”, portando
salientar estes trechos no código-fonte do aluno pode ajudá-lo a localizar o
erro.

 Tratar mensagens de erros como uma parte do ensino: Os desenvolvedores da

IDE devem aplicar conceitos comuns de consistência, complexidade e curva de
aprendizado para definir mensagens de erros. Professores devem se assegurar
que estas mensagens estão de acordo com o plano de ensino da disciplina,
assim como professores de matemática se asseguram que suas notações sejam
as mesmas dos livros utilizados.

2.3.3 Considerações
É possível observar que, de acordo com a pesquisa realizada por Pelz (2014), muitos
corretores fazem uso de uma comparação com a solução modelo. Estas soluções modelos são
importantes no corretor de Pelz (2014) para que o professor possa criar diversas abordagens
possíveis para o mesmo problema. Porém, durante a inferência dos tree walkers foi constatado
 47

que os mesmos se aplicam mais para o exercício, do que para cada solução modelo. Sendo
assim, algumas alterações no corretor foram realizadas a fim de utilizar as soluções modelos
como forma de fornecer feedback, atualmente exclusividade dos tree walkers.

A metodologia utilizada por Marceau et al. (2011) para a inferência da efetividade das
mensagens de erros do compilador foi utilizada para a elaboração em um experimento com o
corretor estático do Portugol Studio.

É importante observar que existem diferenças entre o experimento de Marceau et al.

(2011) e o que será realizado neste trabalho. No trabalho de Marceau foram analisados erros
sintáticos disparados pelo compilador, enquanto o corretor estático do Portugol Studio faz uso
de uma análise semântica, observando problemas mais complexos. Outra diferença é que o
experimento de Marceau separou as mensagens em categorias, enquanto uma abordagem de
categorização das mensagens não é interessante para o experimento deste trabalho, visto que é
de grande valia saber quais tree walkers especificamente estão sendo mais efetivos.
 48

3 DESENVOLVIMENTO
Neste capítulo será abordado como o projeto será desenvolvido, detalhando os tree
walkers inferidos, o editor de questões e suas funcionalidades e os processos do experimento
de avaliação das mensagens dos tree walkers.

3.1 TREE WALKERS

A inferência dos erros mais comuns e definição dos tree walkers foi realizada a partir
das questões analisadas no item 1.2.1 e tornou possível inferir e implementar seis novos tree
walkers. O Quadro 6 detalha todos estes tree walkers, bem como seu objetivo, parâmetros,
tipo e estrutura analisada.

Quadro 6. Tree Walkers inferidos durante a realização do trabalho.

Estrutura
Nome do TreeWalker Objetivo Parâmetros Tipo
Analisada
Identificar
PossibleInfiniteLoop possíveis laços Nenhum Genérico Loop
infinitos.
Verificar se
existe uma Inteiro: Número
quantidade correto de Desvios
NumberOfConditions Genérico
errada de possibilidades Condicionais
desvios no esperadas.
código do aluno
Detectar se o
aluno não
Vetores e
ConstantIndex incrementou o Nenhum Genérico
Matrizes.
índice do vetor
ou matriz.
Detectar se
Laços de
existe algum
Repetição,
EmptyBlocks bloco de código Nenhum Genérico
Funções e
vazio no código
Condições.
do aluno.
Detectar se o Inteiro: Número
aluno está máximo
utilizando uma permitido; Qualquer
NumberOfInstructions Específico
instrução mais Bloco da ASA: Instrução
vezes que o Instrução
necessário. analisada.
Detectar se
Inteiro: 1 para
existe vetor ou Vetores e
MandatoryArray vetor e 2 para Específico
matriz no Matrizes
matriz.
exercício.
 49

Para que cada tree walker cumpra com seu objetivo especificado, foi definido a
estratégia que cada um irá adotar para reconhecer os padrões desejados. O Quadro 7
demonstra as estratégias que foram adotadas para desenvolver os tree walkers.

Quadro 7. Relação dos tree walkers e suas estratégias adotadas.

Tree Walker Estratégia
Verificar se nenhuma das variáveis presentes na condição de um
PossibleInfiniteLoop
laço de repetição é alterada dentro do mesmo.
Contar as os desvios condicionais (se e caso) a fim de identificar
NumberOfConditions
quantos caminhos possíveis existem.
Verifica se o índice de um vetor ou matriz dentro de um laço é
ConstantIndex
uma constante ou uma variável não é alterada no contexto.
Verifica todos os blocos de códigos (laços, condições, etc) que
EmptyBlocks
não possuem nenhuma instrução dentro.
Incrementa um contador toda vez que o nó desejado da ASA é
NumberOfInstructions
visitado.
Sinaliza quando, ao percorrer toda a ASA, não visitou nenhuma
MandatoryArray
utilização de vetor ou matriz.

O processo de inferência se deu pela análise de questões respondidas pelos alunos no

ambiente ALICE. Para exemplificar o processo a seguir será detalhado o caso de inferência do
tree walker “NumberOfConditions”. A questão tem por objetivo que o algoritmo exibisse a
idade do usuário a partir de uma data de nascimento. O Quadro 8 demonstra a solução de um
aluno a esta questão.

Quadro 8. Solução de um aluno para a questão 14.

programa
{
funcao inicio(cadeia parametros[])
{
inteiro d,m,a,aa,i
escreva ("Digite o dia de seu nascimento: ")
leia (d)
escreva ("\nDigite o mês de seu nascimento: ")
leia (m)
escreva ("\nDigite o ano de seu nascimento: ")
leia (a)
escreva ("\nDigite o ano atual: ")
leia (aa)
i = aa - a
escreva ("\nSua idade é: ",i)

}
}

No algoritmo do Quadro 8 é possível perceber que o aluno está no caminho correto,

mas o mesmo não considerou se o usuário já realizou aniversário, para que isto seja feito é
necessário ao menos um desvio condicional no código. Com este problema em mente, foi
inferido o tree walker “NumberOfConditions”, que pode verificar o número de possibilidade
 50

geradas por desvios condicionais na ASA da solução do aluno, este tree walker pode ser de
utilidade em questões que envolvem um número conhecido de possibilidades. Na Tabela 6 é
possível observar a relação de todos os tree walkers e as questões onde os mesmos puderam
ser inferidos, o enunciado das questões é evidenciado no Apêndice A.

Tabela 7. Tree Walkers e questões onde estes foram inferidos.

Nome do TreeWalker 14 18 27 29 30 34 40 45 47 51 57 60
PossibleInfiniteLoop x x x x x x x x x x x
NumberOfConditions x x x x x x x x x x
ConstantIndex x x x x x
EmptyBlocks x x
NumberOfInstructions x
MandatotyArray x x x x x

Para que o editor de questões possa exibir os tree walkers disponíveis e criar a
interface necessária para que os seus parâmetros possam ser definidos, se faz necessário um
arquivo de manifesto do tree walker. A estrutura básica deste manifesto deve ser composta
pelo nome do tree walker, o autor que o criou, uma descrição da sua funcionalidade, e seus
respectivos parâmetros. Este arquivo é representado na notação JSON (JavaScript Object
Notation) pois é mais adequado a natureza do editor de questões que funcionará em um
navegador de internet, como é descrito no item 3.2.3 . O Quadro 9 exemplifica um arquivo de
manifesto de um tree walker.

Quadro 9. Exemplo do manifesto do tree walker “NumberOfInstructions”.

{
"nome": "NumberOfInstructions",
"autor": "andreih@outlook.com",
"descricao" : "Incrementa um contador toda vez que o nó desejado da ASA é visitado.",
"parametros" :
[
{
"nome": "Quantidade de Instruções",
"tipo": "inteiro"
},
{
"nome": "Instrução",
"tipo": "no"
}
]

}
 51

3.2 CORRETOR E EDITOR DE QUESTÕES

3.2.1 Alterações no Corretor

No decorrer da especificação dos tree walkers foi possível perceber oportunidades de
aprimoramento da correção estática a partir de alterações de baixo esforço de implementação.
Desta forma estas foram especificadas e desenvolvidas de modo que ocorreram alterações na
estrutura do arquivo XML que especifica a questão do corretor. As alterações são:

 Tags para a questão: Foram adicionadas “tags” para cada questão, para que
assim possa ser possível realizar pesquisas no editor por classificações de
questões já existentes. Por exemplo, será possível buscar questões que possuem
a tag “laço de repetição” e assim verificar somente questões que abordam este
tema.

 Tree Walkers para o exercício: Boa parte dos tree walkers existentes são
relativos ao exercício como um todo e raramente a soluções modelos, portanto
agora é possível incluir tree walkers associados as questões que serão
disparados sempre, independentes da solução modelo.

 Soluções modelos incorretas: Para que se possa fazer um melhor uso de

soluções modelos, é possível marcar uma solução como “incorreta”, assim
quando um algoritmo do aluno se assemelhar a uma solução incorreta, uma
mensagem de erro é emitida para orientar o aluno. Figura 14 demonstra o
corretor de Pelz (2014) com esta nova funcionalidade.

 Mensagens de erros alternativas: Anteriormente as mensagens de erros

emitidas pelos tree walkers são fixas dentro do código, agora é possível
especificar uma mensagem de erro alternativa como parâmetro. Desta forma é
possível emitir dicas mais contextualizadas com o exercício que está sendo
desenvolvido.
 52

Figura 14. Funcionamento do corretor com a alteração do projeto.

Além das novas funcionalidades do corretor, foram desenvolvidas diversas melhorias

no código-fonte do mesmo, destacam-se:

 Interoperabilidade do XML: Um dos problemas do XML de especificação dos

exercícios era a sua dependência a implementação do mesmo. Alguns atributos eram
especificados com classes do Java, ou com caminhos e classes da implementação do
corretor. Isto fazia com que estas questões ficassem subordinadas a implementação
interna do corretor. Um exemplo era que se desejasse usar um nó da ASA como
parâmetro do tree walker, o tipo do parâmetro deveria ser “java.lang.Class”, ou no
caso de uma lista “java.util.List” (o Quadro 5 possui um exemplo mais prático). O
código-fonte do corretor foi alterado para utilizar símbolos comuns como “inteiro”,
“lista”, “no”, etc. Internamente o corretor decide como deve tratar cada tipo de
parâmetro, como é exemplificado na Figura 15.

Figura 15. Exemplo de tratamento de parâmetros

 53

 Refatoração do código base do corretor estático: A parte mais importante do corretor

estático está localizado na classe “CorretorEstatico”, esta classe possui o método
“executar” que é responsável por toda a atividade do corretor estático, como executar
tree walkers, comparar soluções similares, etc. Uma refatoração de código foi
necessária, separando estas funcionalidades em métodos específicos. Desta forma, a
manutenção do código deve ser mais fácil, visto que está mais modularizado.

 Correções e pequenas melhorias: Outras alterações e correções de pequenos erros

foram feitas no corretor, um branch6 foi criado com o nome de “andrei_ttc27” para
acomodar estas mudanças, e foram registrados cerca de 18 commits de código do dia
13 de agosto até 8 de outubro.

Com estas modificações, alguns atributos foram adicionados na estrutura do XML de

definição das questões. O Quadro 10 demonstra a mesma questão especificada no
anteriormente no Quadro 5, mas com os atributos novos destacados em negrito.

Quadro 10. XML de uma questão, novos atributos destacados em negrito.

<questao>
<enunciado>Faça um programa que solicita ao usuário dois números inteiros e armazena nas
variáveis A e B. A seguir (utilizando apenas atribuições entre variáveis) troque os seus conteúdos
fazendo com que o valor que está em A passe para B e vice-versa. Ao final exiba na tela os valores
que ficaram armazenados nas variáveis. </enunciado>
<tags>
<tag>Sequencial</tag>
<tag>Variável Auxiliar</tag>
<tag>Números Inteiros</tag>
</tags>
<visitorsExercicio>
<visitor class-name="ReadAfterOperation"/>
</visitorsExercicio>
<solucoes>
<solucao>
<incorreta>false</incorreta>
<modelo>programa { funcao inicio() { inteiro a,b,aux leia(a,b) aux = a
a = b b = aux escreva(a,"
",b) }}</modelo>
<visitors>
<visitor class-name="ReadWriteOrder"/>
<visitor class-name="VarIsNotUsed">
<mensagemAlternativa>Variável não utilizada!</mensagemAlternativa>
</visitor>
<visitor class-name="MandatoryInstructions">
<parametroLista tipo="lista">
<valores>
<valor tipo="no" valor="NoOperacaoAtribuicao"/>
<valor tipo="no" valor="NoDeclaracao"/>
</valores>
</parametro>

6
Um brach é uma ramificação no versionamento do projeto, utilizado para desenvolver novas funcionalidades e
testá-las separadamente.
7
O código-fonte do branch “andrei_ttc2” pode ser consultado em https://github.com/UNIVALI-L2S/Portugol-
Corretor/tree/andrei_ttc2.
 54

<parametroValor valor="2" tipo="inteiro "/>

</visitor>
<visitor class-name="UsingAux"/>
</visitors>
</solucao>
<solucao>
<incorreta>true</incorreta>
<mensagemErro>Esta solução está incorreta!</mensagemErro>
<modelo>programa { funcao inicio() { inteiro a, b leia(a,b) a = b - a
b = b - a a = b + a escreva(a,"
",b) }}</modelo>
</solucao>
</solucoes>
<testes>
...
</testes>
</questao>

É possível representar esta estrutura em um digrama de classes, e observar a relação

das classes. A Figura 16 demonstra o diagrama de classe de um exercício, é possível perceber
que a classe Visitor (representa o tree walker) pode estar tanto em uma questão, quanto em
uma solução.

Figura 16. Diagrama de classes de uma questão do corretor.

3.2.2 Editor de Questões

O editor de questões foi planejado para atender as novas funcionalidades adicionadas
ao corretor, funcionando em um ambiente web, com a aplicação sendo executada no lado
cliente utilizando a tecnologia SPA (Single-Page Application). Este editor foi incorporado no
ambiente de competição de programação integrado ao Portugol Studio que foi desenvolvido
pelo acadêmico Gleison de Souza Malheiros, portanto o sistema de autenticação se dá por este
ambiente.
 55

Foi escolhido o framework JavaScript AngularJS 8para o desenvolvimento do projeto9,

já que este permite a construção de aplicações SPA com um alto nível de modularização, e é
um dos mais populares atualmente. Outro framework escolhido foi o Bootstrap10, este facilita
a construção de aplicações web responsivas (se adaptam a tela do dispositivo), portanto o
editor possui sua interface otimizada para dispositivos como tablets e smartphones.

O framework AngularJS permite desenvolver aplicações modularizadas em

controladores, serviços, diretivas e templates. Os controladores são responsáveis pela lógica
da aplicação, os serviços são utilizados pelos controladores para consumir recursos (tree
walkers, por exemplo), diretivas é uma maneira de criar elementos HTML (HyperText
Markup Language) customizados e utilizar em diversos lugares da aplicação, e por fim os
templates é onde se define a interface da aplicação.

Foram criados controladores para o corretor estático, dinâmico, e para o exercício em

geral, bem como templates para todos eles, desta forma as regras de negócios de cada um
deles fica encapsulado no seu controlador. A tela inicial também possui um controlador
próprio, que cuida em gerenciar a pesquisa dos exercícios. O Quadro 11 possui um exemplo
simplificado de como ficou o controlador do editor dinâmico, é possível observar as funções e
suas funcionalidades, as variáveis “$scope” e “$rootScope” são do framework e servem para
se ter acesso a variáveis da aplicação.

Quadro 11. Exemplo simplificado do controlador do corretor dinâmico.

function DinamicoController ($scope, $rootScope){

$scope.addEntrada = function (caso) {

var tipo = caso.formCasoTipoE;
var valor = caso.formCasoValorE;
caso.entradas.push({'tipo': tipo, 'valor': valor});
caso.formCasoValorE = "";
};

$scope.removeEntrada = function (caso, index) {

caso.entradas.splice(index, 1);
};

$scope.addSaida = function (caso) {

var tipo = caso.formCasoTipoS;
var valor = caso.formCasoValorS;
caso.saidas.push({'tipo': tipo, 'valor': valor});
caso.formCasoValorS = "";
};

8
O framework AngularJS pode ser obtido em https://angularjs.org/.
9
O código-fonte do projeto pode ser encontrado em https://github.com/andreihod/Portugol-Editor-Exercicios.
10
O framework Bootstrap poder ser obtido em http://getbootstrap.com/.
 56

$scope.removeSaida = function (caso, index) {

caso.saidas.splice(index, 1);
};

$scope.addCaso = function () {
$rootScope.Exercicio.casos.push({entradas: [], saidas: []});
};

$scope.removeCaso = function (index) {

swal({ title: "Você tem certeza?",
text: "Você tem certeza que deseja excluir este caso de teste?",
type: "warning"},
function(){$scope.removeCasoSemPergunta(index);}
);
};

$scope.removeCasoSemPergunta = function (index) {

$rootScope.Exercicio.casos.splice(index, 1);
swal("Excluído!", "O caso de teste foi excluído com sucesso!", "success");
$rootScope.$digest();
};

Com o intuito de reaproveitar elementos que eram utilizados constantemente no editor,

foram criadas duas diretivas, uma para os tree walkers e outra para a barra superior. O Quadro
12 demonstra como se utiliza estas diretivas, a diretiva da barra tem como atributo o estilo,
que pode ser um número de 0 a 3, indicando quais opções da barra se deseja utilizar, no caso
do estilo 3 é a barra com opções do corretor estático. Já na diretiva do tree walker são
necessários dois atributos, o atributo “tw” é o manifesto do mesmo, e o atributo “lista” é onde
este tree walker está sendo inserido (em uma solução modelo, ou exercício, por exemplo).

Quadro 12. Exemplo de utilizações das diretivas do editor.

<div>
<barra estilo="3"></barra>
</div>
<div>
<treewalker tw="manifesto" lista="listatw"></treewalker>
</div>

Utilizando diretivas garante-se que a lógica por trás destes elementos seja sempre a
mesma, um exemplo de como estes atributos são exibidos no navegador podem ser
visualizados na Figura 20.

A seguir, os requisitos funcionais que o corretor atende:

 RF1.0 - Deve ser possível criar e editar questões para o corretor do Portugol
Studio.
 57

o RF1.1 - Deve ser possível criar ou excluir uma questão com o editor.

o RF1.2 - Deve ser possível editar questões já existentes com o editor.

o RF1.3 - Deve ser possível visualizar outras questões criadas com o

editor.
RF1.3.1 - Deve ser possível filtrar questões pelas suas tags.

o RF1.4 - Deve ser possível salvar as questões.

o RF1.5 - Deve ser possível fazer o download da questão no formato

“.pex”11.
RF1.6 - Deve ser possível atribuir e excluir tags em uma questão.

 RF2.0 - Deve ser possível definir o funcionamento do corretor dinâmico.

o RF2.1 - Deve ser possível criar casos de testes e editar casos já

existentes.

o RF2.2 - Deve ser possível definir entradas/saídas de dados para cada

caso de teste especificado.

 RF3.0 - Deve ser possível definir o funcionamento do corretor estático.

o RF3.1 - Deve ser possível definir tree walkers para o exercício como
um todo.

o RF3.2 - Deve ser possível incluir diversas soluções modelos.

 RF3.2.1 - Deve ser possível marcar uma solução modelo como

"errada" e definir uma mensagem de feedback para a mesma.

 RF3.2.2 - Deve ser possível definir um algoritmo em Portugol

para a solução modelo.

o RF3.2.3 - Deve ser possível definir tree walkers para a solução modelo.

 RF4.0 - Deve ser possível especificar os parâmetros dos tree walkers incluídos
no exercício.

Abaixo, a relação das regras de negócio que o corretor atende:

11
Formato utilizado para armazenar exercícios em arquivos do Portugol Studio.
 58

 RN1.0 - O sistema não deve permitir que um usuário exclua o exercício de

outro usuário.

 RN2.0 - O sistema não deve permitir que um tree walker tenha seus parâmetros
obrigatórios indefinidos.

 RN3.0 - O sistema deve garantir que ao menos uma solução modelo seja
correta.

Por fim, os requisitos não funcionais que o corretor abrange:

 RNF1.0 - O sistema deve funcionar em um ambiente web.

 RNF2.0 - O sistema deve utilizar a tecnologia SPA (Single-Page Application).

 RNF3.0 - O sistema deve ser desenvolvido para a pseudolinguagem Portugol

2.0.

3.3 EXPERIMENTO DE AVALIAÇÃO

Neste trabalho, foi realizado um experimento envolvendo alunos do primeiro período
do curso de Ciência da Computação da UNIVALI. O objetivo deste experimento foi avaliar a
influência das dicas emitidas pelo corretor estático nas ações tomadas pelos alunos para
corrigir o erro diagnosticado, bem como avaliar se o corretor automático como um todo ajuda
o aluno a resolver os exercícios propostos. De uma maneira geral, esperava-se entender como
corretor estático e dinâmico do Portugol Studio e seus tree walkers afetam o aluno durante o
desenvolvimento de uma solução para um exercício.

Neste experimento foi avaliada a efetividade das mensagens de erros emitidas pelos
tree walkers. Entende-se que uma mensagem de erro efetiva é aquela que fornece informações
úteis para o aluno corrigir o problema e progredir na resolução do exercício, ou seja, a ação
tomada pelo aluno após a exibição da mensagem deve ser relevante para a correção do
problema apontado pela mesma.

Participaram do experimento um grupo de 23 alunos da disciplina de Algoritmos e

Programação no dia 20 de outubro de 2014, no horário das 19h30min até as 21h00min, nesta
data os alunos já conheciam algoritmos com vetores e estavam tendo os primeiros contatos
com matrizes, mas ainda não estavam experientes ao ponto de responderam as questões com
 59

muita facilidade (visto que a análise é referente as mensagens de erros, é necessário que o
aluno encontre um pouco de dificuldade).

Os alunos responderam 12 questões (referidas no item 1.4 ) que são as mesmas

questões que foram analisadas para inferir novos tree walkers. Para capturar a ação que o
aluno tomou após a exibição da mensagem foi desenvolvido um plug-in para o Portugol
Studio, detalhado no item 4.3 .

O plug-in foi alterado para gravar um registro toda vez que o aluno solicitava uma
correção de um exercício no corretor e também na tela onde são exibidas as dicas do corretor
estático e os casos de teste do corretor dinâmico. Desta maneira foi possível registrar não só a
correção, mas também se o aluno navegou entre os casos de testes ou selecionou uma
mensagem emitida pelo corretor estático.

Durante a execução do experimento, alguns imprevistos ocorreram, fazendo com que

o tempo dos alunos em contato com o corretor fosse limitado. Era previsto que os alunos
ficassem em torno de 2 horas utilizando o corretor, mas um problema na instalação do plug-in
atrasou o experimento em 45 minutos. Por este motivo, os alunos não avançaram muito nos
exercícios, e consequentemente os dados coletados foram menores do que o esperado,
prejudicando principalmente análise das mensagens do corretor estático.
 60

4 RESULTADOS

4.1 IMPLEMENTAÇÃO DOS TREEWALKERS

O desenvolvimento dos tree walkers ocorreu sem muitas dificuldades para os tree
walkers “NumberOfConditions”, “EmptyBlocks”, “NumberOfInstructions” e
“MandatoryArray”, estes eram os mais simples de serem implementados pois consistem
apenas de contadores ou verificadores dos nós da ASA. Já os tree walkers
“PossibleInfiniteLoop” e “ConstantIndex” demandaram um esforço maior do que o esperado
para serem desenvolvidos, estes são mais complexos pela sua natureza de múltiplos escopos,
como detalhado a seguir:

 PossibleInfiniteLoop: O que o torna complexo é o fato de que um laço de repetição

pode possuir outros laços em seu escopo, sendo assim esses laços também são
potenciais laços infinitos e precisam ser analisados, para isso, uma lista com as
variáveis válidas no escopo é definida, quando as variáveis são utilizadas no escopo
estas são sinalizadas, se ao final de um escopo de um laço nenhuma das variáveis da
condição foi utilizada, logo o laço é possivelmente infinito.

 ConstantIndex: É complexo pois o índice de um vetor ou matriz pode ser uma

expressão com outros vetores e matrizes, portanto a verificação é de certa forma
recursiva.

Observando a complexidade dos tree walkers e a quantidade de possibilidades que

precisam ser constatadas pelos mesmos, se fez necessário a implementação de testes unitários
para cada tree walker utilizando a ferramenta JUnit, com testes unitários foi possível verificar
se um determinado tree walker realmente encontra os problemas de um determinado
programa, desta forma sempre que se for alterar um tree walker pode-se executar os testes
para saber se a alteração não desfaz a identificação de algum padrão de erro que funcionava
anteriormente a alteração. A Figura 17 demonstra ó código-fonte de um dos casos dos testes
unitários implementados.
 61

Figura 17. Exemplo de um teste unitário do tree walker “NumberOfInstructions”.

Os casos unitários se integram muito bem ao NetBeans (ambiente de desenvolvimento

Java) e é possível checar se um determinado tree walker passou em todos os testes. A Figura
18 demonstra o tree walker “NumberOfInstructions” sendo testatado.

Figura 18. Exemplo de um teste unitário executado na interface do NetBeans.

Além do desenvolvimento de novos tree walkers, se fez necessário a padronização das

mensagens do corretor estático, estas mensagens podem possuir, além de uma dica em forma
de texto, a indicação do trecho de código-fonte onde foi constatado o erro e também o nome
do tree walker que disparou aquela mensagem (para fins de log). Foi criada então a classe
“MensagemCorretorEstatico” que é uma sub-classe da classe “Mensagem” (do projeto
Portugol Núcleo), também foi alterado a interface “Dica” que todos os tree walkers
implementam para que passe somente a aceitar mensagens desta nova classe. A Figura 19
demonstra um trecho desta classe bem como as sobrecargas do construtor.

Figura 19. Classe de mensagem do corretor estático.

 62

4.2 EDITOR DE EXERCÍCIOS

As capturas de tela a seguir demonstram como funciona o editor de questões
desenvolvido. Na Figura 20 é possível observar a tela de início do editor, nela é possível
pesquisar as questões por tags, criar um novo exercício, fazer o download de uma questão no
formato “pex” (botão com ícone de nuvem), editar uma questão (botão com ícone de lápis) e
excluir uma questão (botão com ícone de lixeira).

Figura 20. Protótipo da tela de início do editor de questões.

Quando o usuário decide editar uma questão ou criar uma nova, o mesmo é
direcionado para a tela apresentada na Figura 21, nesta tela é possível definir um título,
especificar o enunciado, incluir e excluir tags, salvar o exercício (botão de disquete no canto
direito superior) e realizar o download do arquivo “pex” (botão de nuvem ao lado do
disquete). Para adicionar uma tag, basta que o usuário digite o seu conteúdo no campo
“Adicione uma tag” e em seguida pressione a tecla “enter”.
 63

Figura 21. Tela de criação do exercício.

Quando o usuário clica no botão “Correção Dinâmica” da tela apresentada na Figura

21 ele é direcionado para a tela demonstrada na Figura 22. Nesta tela, é possível cadastrar
diversos casos de testes, bem como suas respectivas entradas e saídas esperadas. O usuário
pode escolher o tipo do dado da entrada que deseja e o seu respectivo valor, em seguida clica
em adicionar para que o valor seja incluído na lista de entradas logo abaixo, o mesmo vale
para as saídas. O usuário pode também criar novos casos clicando no botão “Novo Caso”, ou
excluir casos existentes clicando no botão “excluir” no canto superior direito dos casos, é
possível possuir um número ilimitado de casos.
 64

Figura 22. Tela de edição do corretor dinâmico.

Já quando o usuário clica no botão “Correção Estática” da tela apresentada na Figura

21, o mesmo é direcionado para a tela demonstrada na Figura 23. Nesta tela existe a aba
“Exercício”, que serve para definir os tree walkers comuns a todas as soluções modelos. O
usuário pode clicar em um tree walker na coluna da esquerda e este é adicionado ao exercício
(ou a solução modelo, caso ela esteja selecionada). Após adicionar o tree walker, o editor
monta automaticamente uma interface para que sejam definidos seus parâmetros, esta
montagem se dará observando os parâmetros do tree walker especificado no manifesto
descrito no item 3.1 .

Figura 23. Tela com a aba "Exercício" selecionada.

 65

É importante observar que os parâmetros dos tree walkers podem ser exibidos de
diversas formas, conforme o especificado no seu arquivo de manifesto. A Figura 24
demonstra todas as possibilidades que o corretor oferece para incluir parâmetros: como um
valor em um campo de edição, uma lista de parâmetros, ou então um caixa de combinação
que se selecione um valor.

Figura 24. Opções para incluir parâmetros.

Na tela demonstrada na Figura 25 é possível associar os tree walkers de uma solução

modelo, marcar a solução como incorreta, e também especificar o código-fonte desta solução.
Por padrão o editor de código-fonte permanece invisível, mas o usuário pode habilita-lo
selecionando a caixa de seleção “exibir código-fonte”.
 66

Figura 25. Tela de solução selecionada com código-fonte invisível.

Por fim na tela representada na Figura 26, é possível visualizar a edição de uma
solução modelo com a edição do código-fonte habilitado na interface. É importante observar
que o check-box “Solução Errada?” quando selecionado esconde os tree walkers da solução,
visto que soluções incorretas não possuem este mecanismo.

Figura 26. Tela de solução selecionada com código-fonte visível.

Para exemplificar com maior clareza todo o funcionamento do editor de questões, a

Figura 27 demonstra o diagrama de casos de uso do projeto que será desenvolvido, é
importante elucidar que o caso de uso “Responder Exercício” não será abordado por este
projeto, este está no diagrama apenas para demonstrar o funcionamento completo do Portugol
Studio e a resolução de exercícios.

Figura 27. Diagrama de casos de uso do editor de questões.

 67

4.3 PLUG-IN DO CORRETOR AUTOMÁTICO

Para dar suporte ao corretor dinâmico e estático dentro do Portugol Studio, foi
desenvolvido um plug-in que tem as funções deste corretor. Este plug-in pode ser instalado
em qualquer instância do Portugol Studio, e só é iniciado quando o usuário clica no seu ícone,
ao lado esquerdo do editor de código, como pode ser observado na Figura 28.

Figura 28. Plug-in na interface do Portugol Studio

Na tela inicial do plug-in, o aluno pode escolher entre diversos exercícios para
começar a responder, foram colocados um total de 12 exercícios para dar suporte ao
experimento descrito no item 3.3. Cada exercício possui 3 diferentes atributos, são eles:

 Status: Indica a situação do exercício que pode ser disponível (bandeira verde),
iniciado (bandeira amarela) e também finalizado (bandeira quadriculada).

 Nota: Indica a melhor nota do aluno naquele exercício, que se dá pela

quantidade de casos de testes que o exercício do aluno foi dado como correto, a
nota do exercício pode variar de 0 a 10.

 Tentativas: Indica a quantidade de vezes que o aluno solicitou uma correção

naquele exercício.

Ao dar um duplo clique sobre um dos exercícios da lista, o aluno é transferido para
outra tela com o enunciado da questão e alguns componentes de interface, mostrada na Figura
29. O botão “corrigir” executa o corretor estático e dinâmico com o código-fonte do aluno no
 68

contexto do exercício selecionado, a barra de progresso logo abaixo do botão indica quantos
casos de testes o algoritmo do aluno passou, e por fim, os botões de navegação avançar e
retroceder navega entre as questões, e o botão com um ícone de “casa” volta a tela inicial com
a lista de exercícios.

Figura 29. Tela de detalhes do exercício.

Quando se clica no botão “corrigir” da interface, o resultado da correção aparece em

um painel flutuante logo acima do botão, neste painel são exibidas as mensagens do corretor
estático e dinâmico (se houver alguma), e logo abaixo os casos de testes corretos e errados
que o corretor constatou, estes casos podem ser expandidos, de modo que o aluno pode
verificar todos os casos, as saídas esperadas e as encontradas. A Figura 30 apresenta uma
correção do exercício 1 onde o usuário acertou 80% dos casos e recebeu uma mensagem do
corretor estático.

Figura 30. Exemplo de uma correção do exercício 1.

 69

Além disso, para dar suporte ao experimento com os alunos, o plug-in grava logs no
banco todas as vezes que o aluno solicita a correção, navega pelos casos de testes e clica em
alguma mensagem. Foram salvos o usuário, o exercício, o número da tentativa, a nota, as
mensagens e o código-fonte, como pode-se notar com a Figura 31.

Figura 31. Esquema do banco de dados para gravar logs.

4.4 EXPERIMENTO COM OS ALUNOS

As tabelas a seguir apresentam os resultados obtidos nos testes de dois pontos de vista,
um observando os estudantes separadamente e trançando uma média dentre os exercícios
respondidos, e no outro observando cada exercício fazendo a média entre os estudantes que o
responderam. Na Tabela 8 são expostos os resultados coletados de cada estudante, tais como:

 Exercícios Iniciados: A quantidade de exercícios iniciados, ou seja, quantos

exercícios o aluno solicitou a correção ao menos uma vez. São estes os
exercícios que entraram no cálculo das colunas subsequentes.

 Média de Tempo: A média de tempo que o estudante ficou nos exercícios,

contabilizado pelo horário da última correção menos o horário da primeira
correção, o resultado é mostrado em minutos, se o estudante fez apenas uma
correção, o mesmo não possui tempo. Para cada estudante, foi calculada a
média dentre os exercícios que o mesmo respondeu, exercícios não iniciados
pelo estudante foram desconsiderados.

 Quantidade Média de Correções: A médias das vezes que os alunos clicaram

no botão “corrigir” do corretor automático por exercício.
 70

Tabela 8. Resultados obtidos por estudante

Exercícios Média de Tempo nos Quantidade Média de Nota Média do
Estudante
Iniciados Exercícios (min) Correções Solicitadas Estudante

Estudante 1 3,00 16,33 4,66 6,00

Estudante 2 3,00 40,66 4,00 3,33

Estudante 3 2,00 - 1,00 0,00

Estudante 4 6,00 5,16 3,16 8,33

Estudante 5 2,00 - 1,00 9,50

Estudante 6 1,00 31,00 3,00 0,00

Estudante 7 2,00 3,50 3,50 5,00

Estudante 8 2,00 - 1,00 7,50

Estudante 9 2,00 5,00 2,00 4,00

Estudante 10 2,00 1,50 2,5 9,50

Estudante 11 1,00 - 1,00 10,00

Estudante 12 2,00 6,00 2,00 5,00

Estudante 13 1,00 6,00 3,00 0,00

Estudante 14 2,00 7,50 2,00 0,00

Estudante 15 1,00 28,00 3,00 0,00

Estudante 16 3,00 1,33 2,66 5,00

Estudante 17 2,00 7,50 3,50 2,50

Estudante 18 6,00 2,66 2,66 3,00

Estudante 19 4,00 1,25 1,50 8,75

Estudante 20 4,00 4,50 1,75 7,25

Estudante 21 3,00 0,66 1,66 10,00

Estudante 22 3,00 5,66 2,33 5,66

Estudante 23 1,00 4,00 3,00 5,00

Médias 2,52 7,75 2,43 5,01

Na Tabela 9 são expostos os resultados obtidos de cada um dos doze exercícios, as

colunas da tabela são respectivamente:

 Alunos que iniciaram: A quantidade de estudantes que solicitaram a correção

ao menos uma vez do exercício em questão.

 Nota Média: A nota do aluno no exercício é calculada pelo número de casos de

testes constatados corretos no momento da correção, como todos os exercícios
possuíam 10 casos, a nota pode varia de 0 a 10. Pelo fato de um aluno poder
 71

possuir várias notas no mesmo exercício, ou seja, ele pode solicitar a correção
várias vezes, considerou-se a melhor nota de cada estudante no exercício, e em
seguida calculada uma média entre todos. Estudantes que não iniciaram o
exercício não pertencem ao universo do cálculo.

 Média de Tempo: A diferença de tempo em minutos entre a primeira

solicitação de correção e a última, média de tempo entre todos os estudantes
que responderam a questão.

 Média de Correções: Média de vezes que cada estudante clicou no botão

“corrigir” de cada exercícios.

Tabela 9. Resultados obtidos por exercício.

Alunos que Média de Tempo no Média de Correções
Exercício Nota Média
Iniciaram Exercício (em minutos) Solicitadas

Exercício 1 19 4,5263 9,6316 2,6316

Exercício 2 16 9,75 7,3750 2,3750

Exercício 3 7 5,7142 1,7143 2,2857

Exercício 4 5 6,2 5,8 3,20

Exercício 5 2 5 0 1,5

Exercício 6 2 0 2,5 3,5

Exercício 7 0 0 0 0

Exercício 8 1 0 28 3

Exercício 9 0 0 0 0

Exercício 10 2 0 2,5 2,5

Exercício 11 1 0 15 3

Exercício 12 3 0 0 1

Médias 4,83 2,59 6,043 minutos 2,082

Algumas informações interessantes podem ser extraídas de ambas as tabelas. Na

Tabela 8 é possível observar que os alunos responderam poucos exercícios, uma média 2,5
exercícios por aluno, também não fizeram um uso abusivo do corretor, uma média de 2,43
correções, isto indica que os alunos não fazem uso abusivo do corretor, ou seja, a facilidade
na correção do exercício não substitui completamente o raciocínio lógico que os alunos
precisam utilizar para resolver o exercício.

Na Tabela 9 podemos perceber que os 5 primeiros exercícios foram os mais

respondidos pelos usuários, também foram os únicos com casos de testes corretos. Algumas
variáveis que contribuíram para que os 12 exercícios não fossem concluídos:
 72

 Inexperiência com o corretor: Este foi o primeiro contato dos alunos com o
corretor automático, foi perceptível durante o experimento que no início os
alunos precisaram explorar o mesmo para entender como funcionava, o que
tomou algum tempo. É perceptível na Tabela 8 que o exercício 1, normalmente
o primeiro a ser realizado, tem uma média de tempo maior que os outros 4
subsequentes, além de uma nota um pouco menor em relação aos outros, isto
pode indicar uma evolução dos alunos durante o experimento utilizando o
corretor.

 Dificuldade na resolução dos exercícios: Uma quantidade significativa de

alunos possuía uma dificuldade natural na resolução dos exercícios, fazendo
com que mesmo as questões iniciais exigissem um grande esforço do mesmo.

 Tempo hábil para a resolução: Devido a problemas técnicos para a instalação

do corretor, o experimento que estava previsto para ser iniciado às 19 horas, só
foi executado por volta das 19 horas e 45 minutos, e foi finalizado no intervalo
da aula às 21 horas. Com um tempo maior de experimento é bem provável que
os alunos conseguissem realizar mais exercícios.

4.4.1 Comportamento do aluno em relação a mensagens

Neste experimento também avaliamos as mensagens exibidas pelo corretor dinâmico e

estático, analisando a ação tomada pelo aluno após solicitar a correção de um exercício.

O corretor dinâmico, que executa o código do aluno em diversas situações possíveis e

compara as saídas encontradas com as esperadas, também pode exibir mensagens quando as
entradas e saídas do algoritmo não satisfazem aos casos testados, são mensagens como
“Número de entradas insuficientes!” ou “Nenhuma saída encontrada!”. Avaliamos se a ação
tomada pelo aluno logo após receber uma destas mensagens foi investigativa no sentido de
entender o motivo da mensagem. Consideramos que se o aluno utilizou o componente de
navegação dos casos de testes após receber uma destas mensagens, o mesmo se importou em
tentar solucionar o problema.

O resultado obtido foi de que das 83 vezes que mensagens do corretor dinâmico
apareceram para todos os alunos, houve 43 (51,8%) utilizações do componente de exibição
dos casos de testes. Apesar deste número não ser ruim, afinal pelo menos metade das vezes o
aluno se interessa em verificar os casos, ele pode indicar que estas mensagens e o próprio
 73

componente de exibição dos casos necessitam ser aprimorados de modo a deixar mais claro
para o aluno que problemas foram encontrados no momento de execução dos testes.

A Tabela 10 mostra os tree walkers que foram registrados, os exercícios de onde

partiram, bem como a quantidade de correções que estes aparecem. Foram registrados
somente 4 tree walkers durante o experimento, também avaliamos as mensagens de erros das
soluções modelos da mesma maneira que se avaliou as dos tree walkers.

Tabela 10. Mensagens coletadas do corretor estático e suas rubricas.

Tree Walker Exercícios Correções FIX ATT UNR Eficiência

Mensagens das
Exercício 4 12 0 6 6 0%
Soluções Incorretas
EmptyBlocks Exercícios 1 e 2 12 8 0 4 66%

ReadAfterOperation Exercícios 1 e 2 2 0 0 2 0%

NumberOfConditions Exercícios 1, 2, 8 e 12 26 6 1 19 23%

MandatoryArray Exercício 8 e 12 3 1 0 2 33%

FIX = Corrigido, ATT = Atenção e UNR = Sem relação.

A partir dos dados coletados foi possível obter informações relevantes sobre o uso do
corretor estático pelos alunos:

 Mensagens dos Casos Incorretos: Estas mensagens partiram de exercícios com

soluções modelos incorretas, como por exemplo o exercício 4. Estas
mensagens tiveram uma taxa de eficiência de 0%, ou seja, nenhum aluno que
recebeu a mensagem conseguiu consertar o suposto erro (de acordo o corretor),
embora tenha-se indícios que os mesmos deram atenção as mensagens. Em
uma segunda análise aos resultados foi possível constatar que a solução dos
alunos não estavam erradas como o corretor apontava, ou seja, o cálculo de
similaridade acusou semelhança de uma solução correta com uma incorreta.
Este problema indica que se deve ter cuidado no momento de elaborar as
soluções modelos, é possível que uma abordagem mais conservadora seja mais
adequada, ou seja, somente utilizar soluções diferentes quando estas diferenças
forem consideráveis.

 EmptyBlocks: Este tree walker é o mais simples dos implementados neste

trabalho, sua função é avisar o aluno quando um bloco de código não possui
 74

nenhuma instrução. A taxa de eficiência foi de 66%, boa parte dos alunos que
receberam a mensagem conseguiram encontrar o erro e solucionar o problema.

 ReadAfterOperation: Apareceu apenas duas vezes durante o experimento,

nenhuma das vezes foi solucionado. É possível afirmar que não é um erro
muito comum entre os alunos.

 NumberOfConditions: Foi o tree walker que mais foi executado, um total de

26 vezes, mas com baixa eficiência, 23% segundo a metodologia utilizada.
Talvez deva ser reconsiderado o seu uso ou as mensagens que o mesmo
dispara, ficou claro que não é eficiente ao apontar um erro.

 MandatoryArray: Como o “ReadAfterOperation”, foi executado poucas vezes,

provavelmente por conta dos alunos terem resolvidos mais os exercícios
iniciais, que não envolviam matriz e vetor. Alcançou uma taxa de eficiência de
33%, porém pela baixa quantidade de dados coletados deste tree walker não é
possível afirmar que esta taxa é conclusiva. Como é um tree walker simples e
objetivo assim como o “EmptyBlocks”, é possível que sua taxa de eficiência
seja mais alta quando inferida a uma base de dados maior.

 Outros Tree Walkers: Nenhum outro tree walker foi capturado pelos testes,
acreditamos que o pouco tempo do experimento foi um dos fatores que
contribuíram. Um experimento durante todo um mês ou todo um semestre
letivo pode revelar informações mais consistentes.
 75

5 CONCLUSÕES

Nesta seção são apresentadas as conclusões obtidas com o desenvolvimento deste

projeto e ideias para trabalhos futuros.

Todos os tree walkers planejados foram desenvolvidos com êxito, desta forma o
corretor conta agora com um total de 12 tree walkers disponíveis para a utilização no
exercício. Foi possível perceber durante o desenvolvimento que não é complicado
desenvolver a maioria deles, e que os mesmos se assemelham muito, porém alguns tree
walkers mais complexos podem demandar muito tempo e teste, neste sentido, testes unitários
demonstraram ser de grande auxílio para a implementação dos mesmos.

O editor de exercícios também desenvolvido neste projeto se mostrou eficaz no seu

objetivo, desta maneira ficará muito mais simples para pessoas sem conhecimento profundo
no funcionamento do corretor criar suas próprias questões. A escolha de desenvolver em um
ambiente web se mostrou correta, pois foi possível utilizar diversos componentes de interface
que melhoram a usabilidade. Espera-se que o editor de questões estimule a criação de um
banco de dados de questões.

O corretor estático ganhou novas funcionalidades e teve seu código aprimorado, além
de ter tido diversos problemas constatados e corrigidos. O mesmo foi incorporado em um
plug-in para o Portugol Studio, e já pode ser utilizado por alunos, desta maneira é possível
fazer download do corretor separadamente e instalar no editor. O plug-in também foi alterado
para gravar logs durante sua utilização, é esperado que com a utilização do mesmo seja
possível extrair informações valiosas sobre o uso do corretor pelos estudantes. Durante um
experimento com os alunos o corretor não se mostrou instável, apresentado apenas alguns
problemas que não impactaram seu uso e podem ser corrigidos facilmente.

Apesar do experimento com os alunos ter obtido uma quantidade de dados um pouco
menor do que esperado, ainda foi possível obter informações valiosas sobre o uso do corretor
pelos alunos. Constatamos que o aluno não usa o corretor em benefício próprio tentando, de
alguma forma, burlar o sistema corretor para obter nota máxima, isto pôde ser constatado
tanto pelos dados de utilização quanto por uma observação dos alunos durante a realização do
experimento.
 76

O primeiro contato dos alunos com o corretor foi de descoberta de como o mesmo
funcionava, durante a execução do experimento era possível perceber que os alunos
começavam a usar o corretor com mais segurança conforme progrediam nos exercícios. De
modo geral a recepção dos alunos ao corretor foi bem positiva, acreditamos que a utilização
do corretor durante todo um semestre letivo pode deixar mais evidente a praticidade que o
mesmo pode oferecer para o professor e o aluno.

As mensagens que os alunos recebiam do corretor estático não tiveram um efeito

satisfatório, apenas o tree walker “EmptyBlocks” conseguiu atingir uma taxa de eficiência
adequada, porém é necessário salientar que este tree walker não é de grande utilidade para o
aluno encontrar a resposta correta, mas sim para melhorar seu código. Outro problema foi a
utilização de diversas soluções modelos, que não se comportaram da maneira esperada. Porém
o corretor dinâmico se mostrou eficiente, praticamente não apresentando problemas e
assinalando notas como se esperava.

Mesmo com os problemas encontrados é possível afirmar que o corretor obteve um

impacto positivo na resolução dos exercícios pelos alunos, apesar de possuir alguns pontos
onde precisa ser melhorado. O experimento foi realizado com sucesso e a metodologia se
mostrou eficaz, sendo que pode ser aplicada novamente no futuro.

Observando os objetivos elucidados no item 1.3 deste projeto, pode-se considerar que
todos eles foram cumpridos.

5.1 TRABALHOS FUTUROS

Foram constatados alguns pontos onde o corretor ainda pode ser aprimorado, e ideias
para torna-lo ainda melhor.

Agora com o editor de exercícios desenvolvido, pode ser interessante avaliar o quanto
este editor contribui para a criação de questões para o corretor do Portugol Studio, se é
realmente fácil de usar quais dificuldades os usuários podem ter em utilizá-lo.

O plug-in que dá funcionalidade ao corretor desenvolvido neste trabalho não é

integrado a nenhum ambiente, sendo os exercícios embutidos no mesmo, é possível integrar o
plug-in com o ambiente de competição de programação desenvolvido pelo aluno Gleison em
seu TTC, fazendo com que o aluno possa ter acesso a diversos torneios de programação. O
 77

plug-in também precisa ser aprimorado na maneira em que se exibem os casos testados no
corretor dinâmico, da maneira que está hoje não se mostrou muito amigável.

Sendo que o cálculo de similaridade de algoritmos apresentou alguns problemas

durante este trabalho, talvez fosse interessante pesquisar novas metodologias para calcular a
similaridade entre programas, quem sabe utilizando alguma técnica de inteligência artificial.
Espera-se que melhorando a qualidade do cálculo de similaridade o corretor possa fazer
melhor uso de múltiplas soluções modelos.

Observando que as soluções incorretas para os exercícios podem ser capturadas, é

possível que estas mesmas sejam agrupadas por similaridade e um docente responsável inclua
mensagens de ajuda nesses grupos de soluções, desta forma o corretor poderia fazer uso
destas soluções incorretas, que são indiretamente submetidas pelos próprios alunos, para
oferecer um feedback para os estudantes.

A fórmula utilizada na para mensurar pode ser revista e melhorada, uma ideia é fazer
com que a rubrica “ATT” possa inferir positivamente no cálculo, já que se o aluno prestou
atenção na mensagem é um indício positivo que a mensagem está funcionando.

Sendo que existe uma metodologia bem definida e o instrumento de coleta de dados já
está desenvolvido, outros trabalhos podem aplicar novamente o experimento por um período
de tempo maior ou com um número de alunos mais considerável.
 78

REFERÊNCIAS
AHO, A. V.; LAM, M. S.; SETHI, R.; ULLMAN, J. D. Compiladores: princípios, técnicas
e ferramentas. 3.ed. Editora Pearson, 2007.

ALA-MUTKA, K. M., A Survey of Automated Assessment Approaches for Programming

Assisments. Computer Science Education, p. 83-102, 2005.

BARBETTA, Pedro Alberto. Estatística Aplicada às Ciências Sociais, 5. ed.. Editora UFSC,
2002.

DOUCE, C.; LIVINGSTONE, D.; ORWELL, J. Automatic test-based assessment of

programming: A review Journal on Educational Resources in Computing, Volume 5 Issue 3,
Article No. 4 ACM New York, NY, USA 2005.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley Professional; USA, 2 edition 1995.

GILLELAN, Michael. Levenshtein Distance, in Three Flavors. 2009. Disponível em:

<http://people.cs.pitt.edu/~kirk/cs1501/Pruhs/Spring2006/assignments/editdistance/Levenshte
in%20Distance.htm>. Acessado em: 25 maio. 2014.

HOSTINS, Higor. Uma Ferramenta Para Apoio a Construção e Teste de Algoritmos.

Trabalho Técnico-científico de Conclusão de Curso (Graduação em Ciência da Computação)
– Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí,
SC, Brasil, 2006.

HOSTINS, H.; RAABE, A. L. A. Auxiliando a aprendizagem de algoritmos com a

ferramenta Webportugol, XIV Workshop sobre Educação em Computação (WEI 2007),
p.96-105, Rio de Janeiro, RJ, Brasil, 2007.

HRISTOVA, Maria; MISRA, Ananya; RUTTER, Megan; MERCURI, Rebecca; MAWR,

Bryn. Identifying and Correcting Java Programming Errors for Introductory Computer
Science Students. In: Symposium on Computer Science Education, 2003. Reno, Nevada,
EUA, 2003.

HUANG, J.; PIECH, C.; NGUYEN, A.; GUIBAS, L. Syntactic and Functional Variability
of a Million Code Submissions in a Machine Learning MOOC. 1st Workshop on Massive
Open Online Courses at the 16th Annual Conference on Artificial Intelligence in Education,
p. 25–32, Memphis, Tennessee, USA, 2013.

IHANTOLA, P.; AHONIEMI, T.; KARAVIRTA, V.; SEPPÄLÄ, O. Review of recent

systems for automatic assessment of programming assignments, In: 10th Koli Calling
International Conference on Computing Education Research. Koli, Finlandia, 2010.

KHIRULNUZAM, A. R.; AHMAD, S.; NORDIN, J. The Design of an Automated C

Programming Assessment Using Pseudo-code Comparison Technique. National
Conference on Software Engineering and Computer Systems, p. 1–10, Kuantan, Pahang,
Malaysi, 2007.
 79

KINNUNEN, P.; MALMI, L. Why students drop out CS1 course? Computer Science
Education. Second International Workshop On Computing Education Research, v. 24, n. 7,
p. 97–108, Houston, Texas, USA, 2006.

JERINIC, Ljubomir. Pedagogical Patterns For Learning Programming By Mistakes. In:

Computer Algebra and Dynamic Geometry Systems in Mathematical Education 2012.
Procedings... Faculty of Sciences, University of Novi Sad. Jun. 2012. Novi Sad, Servia,
2012.

JONES, Joel. Abstract Syntax Tree Implementation Idioms. In: 10th Conference on
Pattern Languages of Programs, Illinois, EUA, 2003.

LAHTINEN, E.; ALA-MUTKA, K.; JÄRVINEN, H.-M. A study of the difficulties of

novice programmers. Annual Sigcse Conference On Innovation And Technology In
Computer Science Education, v. 37, n. 3, p. 14–18, Caparica, Portugal, 2005.

LOUDEN, Kenneth C. Compiladores: princípios e práticas. São Paulo: Pioneira Thomson,

2004.

MANNES, Paula. Integração do Portugol Core com o BIPIDE. Trabalho Técnico-

científico de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de
Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, SC, Brasil,
2013.

MARCEAU, Guillaume; FISLER, Kathi; KRISHNAMURTHI, Shriram. Measuring the

effectiveness of error messages designed for novice programmers. In: 42nd ACM
technical symposium on Computer science education - SIGCSE '11. Procedings... Dallas,
Texas, EUA, 2011.

NGUYEN, A.; PIECH, C.; HUANG, J.; GUIBAS, L. Codewebs: Scalable Homework
Search for Massive Open Online Programming Courses. International World Wide Web
Conference, Seul, South Korea, 2014.

NIENALTOWSKI, Marie-hélène; PEDRONI, Michela; MEYER, Bertrand. Compiler Error

Messages: What Can Help Novices? In: Technical Symposium on Computer Science
Education 39. Portland, Oregon, EUA, 2008.

NOSCHANG, L. F. Adaptação do Portugol Core para integração com outras

ferramentas. Itajaí, 2012. 74. Trabalho Técnico-científico de Conclusão de Curso
(Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do
Mar, Universidade do Vale do Itajaí, Itajaí, SC, Brasil, 2012.

NOSCHANG, Luiz Fernando; PELZ, Fillipi; JESUS, Elieser A. de Jesus; RAABE, André L.
A. Uma IDE para Iniciantes em Programação. In: Workshop de Informática na Escola, No
prelo 2014.

OLIVEIRA, N. P. BIP C: criação de um compilador da linguagem C para a arquitetura

dos processadores BIP. Trabalho Técnico-científico de Conclusão de Curso (Graduação em
Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade
do Vale do Itajaí, Itajaí, SC, Brasil, 2013.
 80

PARR, T., Language Implementation Patterns: Create Your Own Domain-Specific and
General Programming Languages. The Pragmatic Bookshelf, 2009.

PELZ, F. D.; RAABE, A. L. A. Análise do Feedback Fornecido por Corretores de

Algoritmos com Propósito Educacional. Latin American Conference on Learning Objects,
Valdivia, Chile, 2013.

PELZ, F. Um Gerador De Dicas Para Guiar Novatos Na Aprendizagem De

Programação, Dissertação de Mestrado (Mestrado em Computação Aplicada) - Universidade
do Vale do Itajaí, Itajaí, SC, Brasil, 2014.

RAABE, A. L. A.; DAZZI, R. L. S.; SANTIAGO, R. de. Adquirindo experiência na

construção de ferramentas de apoio a aprendizagem de algoritmos. In: Workshop de
Ambientes de Apoio a Aprendizagem de Algoritmos e Programação -, 2007, São Paulo.
XVIII Simpósio Brasileiro de Informática na Educação, 2007.

RAHMAN, K. A.; NORDIN, M. J. A Review on the Static Analysis Approach in the

Automated Programming Assessment Systems. In: National Conference On Programming
07. Proceedings..., Kuala Lumpur, Malaysia, 2007.

TRUONG, N.; ROE P.; BANCROFT, P. Static analysis of students' Java programs. In:
Conference On Australasian Computing Education, 6., Dunedin, New Zealand.
Proceedings… Darlinghurst:Australian Computer Society, jan. 2004. p. 317-325.

VENABLES, A.; HAYWOOD, L. Programming Students NEED Instant Feedback! 5th

Australasian Computing Education Conference (ACE2003), v. 20, p. 267–272, Adelaide,
Australia, 2003.
 81

GLOSSÁRIO
Code Completion Funcionalidade em IDES que completa automaticamente trechos de
código.
Pseudolinguagem É utilizada como uma forma genérica de representar um algoritmo.
Scheme Uma linguagem de programação que suporta programação funcional e
procedural.
Semântica No contexto de compiladores é o significado que cada token tem um
programa.
Server-Side Denominação para um ambiente de execução de código em um
servidor.
Sintaxe no contexto de compiladores é como os programas de uma linguagem
são descritos.
Tree Walker Um algoritmo que percorre uma ASA a fim de encontrar padrões e
realizar uma ação.
Visitor Um padrão de projeto comportamental que representa uma operação a
ser realizada sobre elementos da estrutura de um objeto.
 82

APÊNDICE A. QUESTÕES UTILIZADAS

Questão 14: Faça um programa que solicita a data de nascimento de uma pessoa e a
data atual e exiba a idade desta pessoa em anos (A data deve ser armazenada em 3 variáveis
inteiras para ano, mês e dia).

Questão 18: Faça um programa que solicita ao usuário três números reais e exibe na
tela apenas o menor deles.

Questão 27: Faça um programa que solicita ao usuário uma quantidade indeterminada
de números inteiros. O programa deve calcular e escrever a média aritmética apenas dos
números pares. A entrada de dados deve ser encerrada quando o número 0 (ZERO) for
digitado.

Questão 29: Faça um programa para uma calculadora simples que solicita ao usuário
dois operandos como entrada, seleciona uma das opções da lista (1- soma, 2- produto, 3-
divisão, 4- potência) e exibe o resultado. O algoritmo deve executar repetidamente até que os
dois operandos informados sejam iguais a zero. Utilize uma variável do tipo real para exibir o
resultado.

Questão 30: Faça um programa que gere e exiba os 20 primeiros termos da série de
Fibonacci (Os dois primeiros termos da série são 1 e 1, os termos subsequentes são a soma
dos dois últimos. Observe o exemplo: 1,1,2,3,5,8,13,21,..)

Questão 34: Faça um programa que solicita o peso de 25 pessoas e exibe qual o maior
peso e qual o menor peso dentre os digitados.

Questão 40: Faça um programa que solicita ao usuário o número de alunos de uma
turma e o número de provas realizadas. A seguir o programa deve para cada aluno:

a) Solicitar o nome do aluno

b) Para cada prova realizada solicita a nota deste aluno

c) Exibir o nome e a média aritmética das notas deste aluno

Após o término da digitação o programa deverá exibir o nome do aluno com maior
média. Saídas:
 83

 Pedido para a quantidade de alunos = “Digite a quantidade de alunos na sala:”;

 Pedido para a quantidade de provas realizadas = “Digite a quantidade de

provas aplicadas:”

 Para cada aluno = “Digite o nome do aluno:”;

 Para cada prova do aluno = “Digite a nota da prova:”;

 Após cada pedido de nome e nota será exibido o nome do aluno e média
aritmética;

 Ao fim será exibido = “Aluno com melhor média: ”,seguido do nome do aluno
com melhor média.

Questão 45: Faça um programa que leia um vetor de 100 posições e mostre-o
ordenado em ordem crescente.

Questão 47: Faça um programa que solicita ao usuário 50 valores reais e armazene em
um vetor. O programa deve verificar e exibir quantos elementos não repetidos (diferentes)
existem neste vetor.

Questão 51: Faça um programa que preenche dois vetores de 5 posições inteiras. A
seguir crie um novo vetor contendo a união dos elementos dos dois vetores (A união deve
excluir elementos repetidos). Exiba os vetores originais e o vetor união.

Questão 57: Faça um programa que manipula uma matriz quadrada de qualquer
tamanho, somando os valores que não estão nem na diagonal principal nem na diagonal
secundaria.

Questão 60: Faça um programa que preenche uma matriz de 4X4 com números reais.
O programa deve exibir qual a posição (linha e coluna) do elemento minimax, ou seja, o
menor valor que esteja na linha em que se encontra o maior valor da matriz.