Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
INTEGRAÇÃO DE UM JUIZ ONLINE DE ALGORITMOS COM O
AMBIENTE VIRTUAL DE APRENDIZAGEM MOODLE
por
Rafael Hernandez Galasso
Itajaí(SC), julho de 2013
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
INTEGRAÇÃO DE UM JUIZ ONLINE DE ALGORITMOS COM O
AMBIENTE VIRTUAL DE APRENDIZAGEM MOODLE
Linguagens de programação
por
Rafael Hernandez Galasso
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: Benjamin Grando Moreira,
M.Eng.
Itajaí(SC), julho de 2013
RESUMO
GALASSO, Rafael Hernandez. Integração de um juiz online de algoritmos com o
ambiente virtual de aprendizagem Moodle. Itajaí, 2013. 72 f. 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í, 2013.
O trabalho trata da integração de um juiz online ao Ambiente Virtual de Aprendizagem
Moodle, tendo por objetivo permitir que questões envolvendo a criação de algoritmos sejam
avaliadas de forma automatizada, gerando um feedback mais rápido ao aluno e facilitando a
correção do professor. Para o aprendizado de algoritmos é de fundamental importância a
pratica de exercícios de fixação, estimulando o raciocínio nos alunos. Com isso torna-se uma
tarefa difícil para o professor a individualização nas correções dos exercícios propostos pelo
mesmo, somado ao fato das turmas dos primeiros períodos de computação apresentarem
grande número de alunos. Porém com a popularização e utilização de ambientes virtuais de
aprendizagem pelas instituições de ensino para o auxilio e cursos online, surgiu a
oportunidade da integração de um juiz online no ambiente Moodle, agregando um processo
que executa, compila e compara a saída gerada a partir do algoritmo julgado com um conjunto
de saídas previamente cadastrados. O juiz online utilizado neste trabalho foi o disponível no
sistema BOCA . Com o sistema desenvolvido estima-se que com um feedback mais rápido
para o aluno o interesse pela matéria não decresça e que facilite para o professor a aplicação
de exercícios de fixação.
Palavras-chave: Algoritmos. Juiz online. Moodle.
ABSTRACT
The paper deals with the integration of a judge to the online Virtual Learning Environment
Moodle, aiming to allow issues involving the creation of algorithms are evaluated in an
automated manner, generating a faster feedback to the student and facilitating teacher's
corrections. For learning algorithms is of fundamental importance to the practice of focusing
exercises, stimulating thinking in students. Thus it becomes a difficult task for the teacher to
individualize corrections in the exercises for the same, plus the fact that the classes of the first
periods of computing present large number of students. But with the popularity and use of
virtual learning environments for education institutions to aid and online courses, the
opportunity of integrating a judge in the online environment Moodle, adding a process
executes, compiles and compares the output generated from the judged algorithm with a set of
outputs previously registered. The judge online used in this work was available in the system
BOCA. With the system was estimated that with a faster feedback to the student's interest in
the subject and not decreases the teacher to facilitate the application of fixation exercises.
Keywords: Algorithms. Online Judge. Moodle.
LISTA DE FIGURAS
Figura 1. Tela de inserção de código-fonte no ideone. ............................................................. 27
Figura 2. Tela com os resultados da compilação do código-fonte. .......................................... 28 Figura 3. Diagrama de caso de uso das funcionalidades do professor. .................................... 38 Figura 4. Diagrama de Casos de Uso das funcionalidades do aluno. ....................................... 41 Figura 5. Adaptação das tabelas do BOCA. ............................................................................ 43 Figura 6.Tabela tempaluno e tempprofessor criadas no BOCA. .............................................. 44
Figura 7. Esquema da integração de um juiz online no ambiente moodle. .............................. 46
Figura 8. Tela de escolha do tipo de questão Juiz Online. ....................................................... 48
Figura 9. Tela de criação da questão. ....................................................................................... 49 Figura 10. Tela com o exercício para o aluno .......................................................................... 53 Figura 12. Tela de feedback. .................................................................................................... 57
LISTA DE QUADROS
Quadro 1. Valores retornados. .................................................................................................. 30
Quadro 2. Descrição do método getLanguages. ....................................................................... 30 Quadro 3. Criação da trigger tg_atualiza_boca2. ..................................................................... 50 Quadro 4. Criação da função moodle_gatilho_to_boca(). ........................................................ 51 Quadro 5. Criação da trigger tg_envia_problemtable. ............................................................. 51 Quadro 6. Criação da função tempprofessor_gatilho_problemtable(). .................................... 52
Quadro 7. Criação da trigger tg_atualiza_boca_aluno. ............................................................ 54
Quadro 8. Criação da função moodle_gatilho_to_boca_aluno(). ............................................. 55
Quadro 9. Criação da trigger tg_envia_runtable. ..................................................................... 55 Quadro 10. Criação da função tempaluno_gatilho_runtable(). ................................................ 56 Quadro 11. Criação da trigger tg_atualiza_resposta_aluno. .................................................... 58 Quadro 12. Criação da função boca_to_moodle_resposta(). .................................................... 59
LISTA DE ABREVIATURAS E SIGLAS
API Application Programming Interface
BOCA BOCA Online Contest Administrator
GCC GNU Compiler Collection
HTTP Hypertext Transfer Protocol
IDE Integrated Development Environment
MOODLE Modular Object-Oriented Dynamic Learning Environment
PC2 Programming Contest Control System
SBC Sociedade Brasileira de Computação
SOAP Simple Object Access Protocol
SQL Structured Query Language
TTC Trabalho Técnico-científico de Conclusão de Curso
UML Unified Modeling Language
UNIVALI Universidade do Vale do Itajaí
WSDL Web Services Description Language
XML Extensible Markup Language
SUMÁRIO
1 INTRODUÇÃO ............................................................................................... 11
1.1 PROBLEMATIZAÇÃO ................................................................................. 14
1.1.1 Formulação do Problema ............................................................................... 14
1.1.2 Solução Proposta ............................................................................................. 14
1.2 OBJETIVOS .................................................................................................... 15
1.2.1 Objetivo Geral ................................................................................................. 15
1.2.2 Objetivos Específicos ...................................................................................... 15
1.3 Metodologia ..................................................................................................... 15
1.4 Estrutura do trabalho ..................................................................................... 16
2 FUNDAMENTAÇÃO TEÓRICA ................................................................. 17
2.1.1 Algoritmos........................................................................................................ 17
2.1.2 Problemas no ensino de algoritmos ............................................................... 17
2.2 MOODLE ........................................................................................................ 20
2.2.1 Características do Moodle .............................................................................. 20
2.2.2 Módulo de questionário do Moodle ............................................................... 22
2.3 Juízes online ..................................................................................................... 23
2.3.1 PC2(Programming Contest Control System – Sistema de Controle de
Concurso de Programação) ...................................................................................... 23
2.3.2 Mooshak ........................................................................................................... 24
2.3.3 BOCA online .................................................................................................... 25
2.4 Ferramentas de IDE e debugging online ...................................................... 25
2.4.1 Ideone ............................................................................................................... 26
2.4.2 Integração de uma IDE e debugging online ................................................. 28
2.5 Trabalhos similares ......................................................................................... 31
2.5.1 Um mecanismo para correção automática de exercícios práticos de
programação introdutória ........................................................................................ 31
2.5.2 Adaptação de um corretor automático de código para auxílio da
atividade de exercício e prática no ensino de programação .................................. 32
2.5.3 Corretor automático de exercícios programa para auxílio no ensino à
distância ...................................................................................................................... 33
2.5.4 Proposta de um laboratório virtual para aprendizagem de Prolog ........... 33
3 dESENVOLVIMENTO .................................................................................. 35
3.1 DESCRIÇÃO DO SISTEMA ........................................................................ 35
3.2 Análise de Requisitos ...................................................................................... 36
3.2.1 Requisitos Funcionais ..................................................................................... 36
3.2.2 Requisitos não Funcionais .............................................................................. 37
3.3 DIAGRAMAS DE CASO DE USO ............................................................... 38
3.3.1 Caso de Uso do professor ............................................................................... 38
3.3.2 Caso de Uso do aluno ...................................................................................... 41
3.4 BANCO DE DADOS....................................................................................... 43
3.5 Integração do juiz online do BOCA .............................................................. 45
3.6 INTERFACES DO SISTEMA ....................................................................... 47
3.6.1 Telas do professor ........................................................................................... 47
3.6.2 Telas do aluno .................................................................................................. 52
4 CONCLUSÕES ............................................................................................... 60
APÊNDICE A.FUNÇÕES DO DBLINK ................................................................ 65
APÊNDICE B.FUNÇÕES COMENTADAS DAS CLASSES TESTE.PHP
E RENDERER.PHP .................................................................................................. 71
11
1 INTRODUÇÃO
Por definição, algoritmo é uma sequência de passos bem definida em uma ordem
específica transformando uma entrada fornecida em uma saída, ou também pode-se dizer que
algoritmo é uma ferramenta para resolver problemas bem especificados (CORMEN, 2002).
Contudo, o termo algoritmo não surgiu a partir da computação, podendo ser
encontrado em outras áreas, bem como, Administração e Engenharia. Atualmente o termo
algoritmo é bastante associado à computação. Já na computação o seu uso está associado à
criação de um programa de software (MEDINA, 2005).
Segundo Tobar et. al. (2001 apud MOREIRA; FAVERO, 2008), é indispensável para
o estudante de computação, dentre outras disciplinas, o estudo de programação que tem como
fundamento o ensino de algoritmos. Algoritmos habilita os indivíduos a usarem lógica de
programação na resolução de problemas, sendo estes de grande relevância em disciplinas
posteriores e mais avançadas. A reprovação é um reflexo da dificuldade do individuo no
aprendizado de programação, sendo que o mau desempenho não se limita apenas nessa
disciplina, mas sim em todas as disciplinas que tomam por base a programação.
Segundo Prior (2003 apud MOREIRA; FAVERO, 2008,pg.1): ”A habilidade de
programação de computadores não pode ser adquirida sem um significante esforço em
atividades práticas de laboratório. Neste contexto, muitas ferramentas foram propostas para
auxiliar o educador no ensino de programação na prática”.
Algoritmos é uma disciplina fundamental para o ensino de programação, e se faz
presente em outros cursos, como os de engenharia. O uso de algoritmos pode ser constatado
em outras modalidades como a maratona de programação, exigindo dos alunos algumas
aptidões tais como princípios de lógica e a resolução de problemas através da interpretação
dos algoritmos descritos. Essa interpretação da solução aparece como um dos principais
fatores para a desmotivação na disciplina, culminando assim em altos índices de reprovação e
evasão por parte dos alunos, principalmente no curso de computação (RAPKIEWICZ, 2006).
A maratona é um evento promovido e organizado em parceria com demais entidades,
mas de forma preponderante pela Fundação Carlos Chagas, destinada aos alunos de graduação
e de pós-graduação na área de Computação e Tecnologia (FERREIRA, 2012).
12
Os fins almejados pela maratona são estimular em seus participantes a capacidade de
trabalhos em equipe, criatividade e habilidade de resolução de problemas em um ambiente
sob pressão. Os problemas apresentados envolvem a resolução de algoritmos de uma forma
mais eficaz e no menor tempo possível. Na competição um dos critérios de escolha do
vencedor é o tempo em que as respostas são enviadas, fazendo-se uso de um juiz online
(FERREIRA, 2012).
Partindo disso o Juiz online faz o papel de um avaliador de algoritmos. Uma vez
submetido o problema ele analisará um conjunto de dados de entrada e saída, comparando
com as respostas esperadas. Logo em seguida, as aprovações são feitas pelo menor tempo
possível atestando se a resposta encontrada está certa ou errada. Caso esteja errada o
participante poderá repara-la, e enviar novamente (CAMPOS, 2004).
A utilização do juiz online não se limita apenas em competições, mas também em
ambientes de ensino virtuais como o Moodle (Modular Object-Oriented Dynamic Learning
Environment - Ambiente de Aprendizagem Dinâmico Modular Orientado a Objetos).
Muitas instituições de ensino que procuram modernizar seu sistema e facilitar o acesso
ao conhecimento estão optando pelo uso do ambiente Moodle, que surge usando o conceito
construcionista social de educação. São pacotes de software tendo utilidade para profissionais
da educação e programadores, abordando o ensino on-line, em produções de cursos e sites na
internet (MOODLE, 2012a).
Por se tratar de um software Open Source oferece permissões de cópia, modificação e
uso, contanto que seja mantida a licença original, os direitos autorais e o fornecimento do
código-fonte aos demais usuários (MOODLE, 2012a).
Conforme supracitado o ambiente acadêmico está cada vez mais dinâmico, sendo que
este trabalho visou à criação de um tipo de questão para o módulo de questionário no Moodle,
com a finalidade de professores criarem problemas para seus alunos que envolvam a
resolução de algoritmos. No envio da resolução, por parte do aluno, um juiz online compila o
código com um conjunto de casos de testes, sendo que cada caso de teste contém as entradas
esperadas pelo programa que são cadastrados pelo professor, e compara com um conjunto de
saída padrão, também cadastrado pelo mesmo. Estando o conjunto de saída padrão idêntico ao
conjunto de saída gerado pelo algoritmo do aluno a resolução é considerada correta. Isso
permite que haja um feedback imediato sobre a solução enviada pelos estudantes.
13
Assim com uma resposta imediata o aluno irá manter o interesse na matéria lecionada
e com isso o rendimento será maior. O trabalho então busca utilizar os princípios e
mecanismo utilizados na maratona de programação para motivar os alunos no aprendizado de
algoritmos.
Para a integração do juiz online, no ambiente Moodle foi criado um tipo de questão no
módulo de questionário do mesmo. Esse questionário especifico, com campos para os dados
de entrada dos problemas que serão cadastrados pelo professor foi feito em PHP. Já na parte
de banco foram criados 5 gatilhos (triggers) que servem para transferência de informações.
O cadastro de questões se da através do ambiente Moodle, onde cadastrada uma
questão pelo professor, a mesma é armazenada em seu banco de dados.
Já com a questão cadastrada no banco de dados do ambiente Moodle , um gatilho ao
perceber uma mudança ou atualização em seus registros, é acionado levando as informações
dos problemas para o banco de dados do sistema BOCA. Onde foi criada uma tabela
temporária, que serve como ponte para a tabela de cadastro do problemas.
O segundo gatilho é acionado quando essa tabela temporária recebe os dados,
adicionando os mesmos na tabela de cadastro do problemas no sistema BOCA.
Portanto a medida que o aluno, estiver respondendo um problema de algoritmos no
ambiente Moodle, ao envia-lo, os seus dados serão armazenados no Moodle e o gatilho se
encarregará de enviar essas informações para o banco de dados do sistema BOCA, onde outra
tabela temporária foi criada.
A tabela temporária do aluno ao receber os dados aciona outro gatilho que irá guardar
os dados na tabela referente a solução dos problemas para ser julgado. Com isso o ultimo
gatilho será acionado quando um processo do BOCA chamado autojuding fizer a sua função,
que é verificar de minuto em minuto se há nas tabelas do BOCA algo para ser julgado.
Havendo algum algoritmo para ser julgado, o mesmo irá julgar.
O funcionamento para julgar um algoritmo inicia a partir da compilação do algoritmo
criado pelo aluno, e com o conjunto de casos de testes, sendo que cada caso de teste contém
as entradas esperadas pelo programa criados pelo professor junto ao problema, e que gera uma
saída. Essa saída é comparada com o conjunto de saídas padrão, cadastrado junto com o
14
problema pelo professor, gerando um possível acerto ou erro. Esse possível acerto ou erro é
enviado para o banco de dados do Moodle e com isso gerando o feedback imediato ao aluno.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Com um grande número de alunos em disciplinas de algoritmos e programação a falta
de individualização para a correção de trabalhos e exercícios propostos pelo professor são
fatores para o crescimento de desistência na matéria. Os primeiros períodos do curso de
Ciência da Computação são de suma importância para o desenvolvimento restante do curso,
pois é onde a noção de logica é construída com linguagens de programação desde C, C++ e
posteriormente JAVA.
Com isso os alunos das disciplinas iniciais do curso acabam se frustrando à medida
que criam algoritmos, pois sem saberem ao menos se o que estão construindo atende o
esperado deixam de lado exercícios que são essenciais para o aprendizado de algoritmos e
consequentemente desistem da matéria e do curso.
1.1.2 Solução Proposta
A integração de um juiz online no ambiente virtual Moodle, possibilitando assim a
pratica de exercícios de algoritmos. O juiz gera um feedback imediato baseado na comparação
da saída gerada pelo juiz com a saída padrão que o professor irá cadastrar. O aluno ao
praticar os exercícios recebe um feedback imediato, de um possível acerto ou erro.
15
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Adicionar no ambiente virtual Moodle o recurso de juiz online de algoritmos de
programação.
1.2.2 Objetivos Específicos
Pesquisar trabalhos similares;
Pesquisar as ferramentas a serem utilizadas:
o Pesquisar diferentes juízes online; e
o Pesquisar ferramentas de IDE e debugging online.
Pesquisar os conceitos necessários à implementação do sistema.
Compreender a estrutura do ambiente Moodle para a integração do juiz online;
Modelar a ferramenta para as funcionalidades de aluno e professor;
Desenvolver as funcionalidades modeladas;
Documentar.
1.3 Metodologia
A metodologia utilizada para se alcançar os objetivos do trabalho proposto envolveu
pesquisa sobre trabalhos similares que tivessem integração com o ambiente Moodle ou que
fossem Web, mas que tivessem exercícios com correções de forma online. Assim foram
encontrados os três principais: Adaptação de um avaliador automático de código para auxílio
da atividade de exercício e prática no ensino de programação (SOUZA, 2009), Avaliador
automático de exercícios programa para auxílio no ensino à distância (CUNHA et. al., 2006),
Proposta de um laboratório virtual para aprendizagem de Prolog (SANTOS NETO, 2007) e
Um mecanismo para correção automática de exercícios práticos de programação introdutória
(PELZ, 2012).
Para encontrar ferramentas que possibilitassem o feedback imediato foram analisados
diversos juízes online que fizessem a comparação entre a saída padrão do professor com a
saída gerada pelo mesmo. Alguns encontrados são: BOCA online Campos (2004), PC2
(Programming Contest Control System – Sistema de Controle de Concurso de Programação)
PC2 (2012a) e Mooshak (2012). Porém foi estabelecido um critério para a escolha: o sistema
16
deveria ser Open Source, tornando assim inviável a utilização do PC2 (não tem o seu código
aberto), restando apenas o Mooshak e o BOCA online como opção. Com pouca
documentação existente do Mooshak, tornou-se viável e única a utilização do BOCA online
Algumas ferramentas de IDE e debugging online foram pesquisadas. Muitas
encontradas não se enquadraram no requisito mínimo estipulado, que seria a execução dos
programas de forma online e que linguagens como C, C++ e Java, fizessem parte das
linguagens do programa. Dentre alguns IDE’s pesquisadas estão: Coderun (CODERUN,
2012), Codepad (CODEPAD, 2012), Online Compiler (ONLINE COMPILER, 2012),
Compilr (COMPILR, 2012) e Ideone (IDEONE, 2012d). Porém a única que se enquadrou foi
a Ideone por executar de forma online os programas e ter C, C++ e Java como linguagens em
sua lista, além de ser de código-aberto e fácil integração a outros sistemas.
Durante a pesquisa alguns conceitos foram encontrados bem como: Algoritmos
(SOUZA, 2005), e Problemas no ensino de algoritmos (RODRIGUES JUNIOR,2008;
RAPKIEWICZ,2006; SIEBRA,2009), que de forma positiva mostrou a importância de
exercícios de algoritmos em sala de aula para o aprendizado e também a falta de um feedback
nesses exercícios sendo como um dos fatores desmotivacional.
1.4 Estrutura do trabalho
Este documento está estruturado em quatro capítulos. O Capítulo 1, Introdução,
apresentou uma visão geral do trabalho.
No Capítulo 2, Fundamentação Teórica, é apresentada uma revisão bibliográfica
sobre trabalhos similares, o que é algoritmos, problemas no ensino de algoritmos, assim como
uma análise a respeito do ambiente moodle e sua estrutura, juizes online e ferramentas de
IDEs e debugging online.
O Capítulo 3 apresenta o projeto detalhado do sistema desenvolvido, incluindo sua
especificação e a sua modelagem em UML. O capítulo também discute como foi
implementado o sistema proposto, apresentando a metodologia utilizada no desenvolvimento.
Concluindo, no Capítulo 4, apresentam-se as conclusões, onde são abordados os
resultados, mudanças de algumas estratégias de desenvolvimento do projeto, alterações de
cronograma, dentre outros.
17
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo trata dos seguintes temas: Algoritmos, Problemas no Ensino de
Algoritmos, Ambiente Moodle, Juízes Online, Ferramentas de IDE e Debugging Online,
Trabalhos Similares.
Para o desenvolvimento do sistema proposto foi estudada a estrutura do ambiente
Moodle, a fim de adaptá-lo de forma a atender os requisitos necessários para o
desenvolvimento do trabalho proposto, e que também seja de fácil uso para os usuários. O
funcionamento do juiz online também foi estudado, pois o sistema depende principalmente da
sua integração com o ambiente Moodle, para que haja um feedback imediato dos problemas
resolvidos.
Os trabalhos similares foram analisados para que possíveis sistemas já criados
pudessem contribuir de alguma forma no desenvolvimento e podendo assim reutilizar o que já
se foi criado em seu desenvolvimento.
2.1.1 Algoritmos
Uma definição formal de algoritmos é um conjunto de instruções ou passos bem
definidos para a solução de um problema (SOUZA, 2005).
É necessária a extração, no problema, de informações fundamentais na construção de
um algoritmo, sendo nessa etapa a modelagem do algoritmo, resultante de uma abstração
mental. Após abstrair uma possível solução do problema, resultando assim em como resolver
o problema, deve-se descrever em passos bem definidos o processo para se chegar à solução.
Mas somente os passos não resolvem o problema, é necessário que seja montada uma
sequencia logica para a execução do problema, tornando assim de fato a solução completa
(SOUZA, 2005).
2.1.2 Problemas no ensino de algoritmos
Para o desenvolvimento de programas de computador os principais fundamentos são
obtidos em disciplinas como algoritmos e programação, que tem por finalidade habilitar
alunos no desenvolvimento e estruturação de algoritmos. Em sua tradicional apresentação do
conteúdo da disciplina para os alunos todas as áreas do conhecimento são abordadas como a
18
teoria, apresentação de exemplos e proposição de exercícios práticos que inicialmente são
simples e gradativamente, conforme o adiantamento do conteúdo, aumentam sua
complexidade (RODRIGUES JUNIOR, 2004).
Com um índice elevado de reprovação e desistência em instituições de ensino no
Brasil, a disciplina de algoritmos tem sido foco dos professores, preocupados com a melhoria
no processo de ensino e a qualidade oferecida para os alunos, mostrando assim necessidade de
algumas alterações tanto na parte didática como na metodológica da apresentação
(RODRIGUES JUNIOR, 2004).
A falta de interesse pela disciplina por parte do aluno deve-se ao fato dos métodos
tradicionais de ensino utilizados por professores não promoverem o interesse no aluno. Nos
primeiros períodos do curso, principalmente para alunos que não atuam de forma profissional
na área da informática, acaba não ficando clara a importância de certos conceitos e conteúdos
para sua formação acadêmica, conteúdos esses que acreditam não serem muito uteis na
pratica. Assim o desafio não fica a cargo só da necessidade de motivação, mas também de
mostrar que a disciplina e seu conteúdo são importantes e merecem cuidados e afeição
especial (RODRIGUES JUNIOR, 2004).
Outro problema encontrado ainda relacionado à motivação é a do aluno julgar o grau
de dificuldade da disciplina, esperando por um obstáculo difícil de ser vencido ou um
problema. Às vezes muitos professores reforçam essa ideia, prometendo realizar avaliações
complicadas e fazendo com que a avaliação perca o seu papel, que é o de avaliar
(RODRIGUES JUNIOR,2004).
O segundo problema encontrado no método tradicional de ensino na disciplina é o de
avaliar. As avaliações acabam sendo uma ação isolada, especial, com data marcada, sendo o
seu objetivo único de aprovação. Isto desenvolve no aluno um receio, prejudicando assim seu
aprendizado na disciplina (RODRIGUES JUNIOR, 2004).
O problema visto por Rapkiewicz (2006), por parte do aluno, é com relação a
verificação se o algoritmo que foi construído realmente funciona como esperado. Testes de
mesa costumam ser empregados nessa etapa da disciplina para a verificação se o algoritmo
desenvolvido pelo mesmo é eficaz. Um passo a passo deve ser executado pelo aluno para
verificar a funcionalidade de sua solução. Isso além de desmotivar o aluno traz um novo
problema, que seria o ato de seguir o passo a passo.
Algumas habilidades são destacadas no processo de desenvolvimento de algoritmos,
tais como, resolver problemas e mostrar o passo a passo na resolução dos mesmos. Para o
desenvolvimento de algoritmos são necessários em suas atividades habilidades como
19
raciocínio, compreensão e de representação. Muitos alunos na criação de algoritmos para a
resolução de problemas não conseguem desenvolvê-lo, sendo problemas que são considerados
fáceis do ponto de vista das estruturas lógicas envolvidas. Essas observações dão indícios da
dificuldade dos alunos com a resolução de problemas bem como o entendimento do problema
e o passo a passo para resolvê-lo (SIEBRA,2009).
Algumas dificuldades são da natureza da disciplina de algoritmos, não sendo do aluno
ou professor. De acordo com SIEBRA (2009) algumas destas dificuldades são:
O grande numero de alunos;
Dificuldade do professor compreender a logica do aluno;
Turmas heterogêneas;
Motivar os alunos.
Por se tratar de uma disciplina oferecida nos primeiros períodos do curso de
computação é formada por alunos recém saídos do segundo grau, alunos repetentes ou
transferidos de outras instituições. Desta forma há um grande numero de alunos matriculados,
dificultando a individualização de sua avaliação e o numero de avaliações propostos pelo
professor. Por falta de tempo hábil em um semestre para a aplicação de diversos trabalhos
valendo nota o professor se reserva ao direito de não aplica-los, por não conseguir corrigir em
pouco tempo tudo (SIEBRA,2009).
A dificuldade do professor em compreender a lógica do aluno deve-se ao fato de ser
difícil mudar um raciocínio logico depois de construído, e tentar construir outra forma de
resolução de problemas. Isso acarreta em uma difícil tarefa para o professor de compreender a
lógica especifica de cada aluno que muitas vezes acabam não sendo bem sucedidos na
construção de soluções de algoritmos. Isto atrapalha o desenvolvimento do professor em
provas, tendo que elaborar provas com mais atenção e requerendo mais tempo nas correções
das soluções de algoritmos (SIEBRA, 2009).
Para gerir a forma de ensinar, agradando ou até mesmo tornando mais atrativa para os
diferentes grupos, o professor encontra um grande desafio. Por serem turmas heterogêneas,
existem diferentes níveis de conhecimento entre os alunos e ritmo de aprendizagem. Alguns
possuem um contato prévio antes de ingressar no curso ou até mesmo trabalham na área,
enquanto muitos nunca tiveram contato com algoritmos e programação. Mesmo alunos com
níveis equivalentes mostram diferentes maneiras de raciocínio sendo estritamente pessoal e
20
único, diferenciando cada individuo dos demais. Essa forma única e pessoal de pensar e
raciocinar gera diferentes soluções de um mesmo problema (SIEBRA, 2009).
Em muitas dificuldades encontradas a motivação dos alunos fica a cargo do professor,
fazendo com que o interesse pela matéria não se vá, não acarretando em desistência da
disciplina. Muitos meios podem ser usados para que o professor consiga deixar o aluno
interessado na matéria, como instigar o aluno para que busque outras formas de soluções de
problemas ou técnicas novas. É importante que o professor deixe explícita a importância da
matéria e o seu uso em futuras matérias ou até mesmo na vida profissional (SIEBRA, 2009).
Com o sistema desenvolvido acredita-se que se o aluno tiver um feedback imediato em
exercícios práticos seu interesse irá crescer, o que pode influenciar de forma positiva na
disciplina.
2.2 MOODLE
O Moodle é um projeto que foi desenvolvido e ainda liderado por Martin Dougiamas,
software Open Source que é fornecido gratuitamente, sendo que seu uso se limita a copia,
modificação e uso desde que a sua modificação (código-fonte) seja compartilhada com a
comunidade Moodle. É um software visando à produção de cursos para a internet, com sua
filosofia construcionista social de educação. Sua utilidade acaba sendo principalmente para
profissionais da educação e programadores. (MOODLE, 2012a).
A sua instalação pode ser feita em qualquer computador/servidor que faça a execução
da linguagem PHP e que comporte base de dados do tipo SQL (MOODLE, 2012a). O sistema
é focado em segurança o tempo todo, sendo que os seus formulários são todos checados, os
dados validados e os cookies codificados. É um sistema adequado para aulas online,
complementando a aprendizagem presencial (MOODLE, 2012b).
2.2.1 Características do Moodle
De uma forma geral o ambiente Moodle é constituído de uma arquitetura modular, um
sistema simples, possibilitando sua instalação em qualquer plataforma que suporte o PHP. Os
cursos podem ser categorizados e pesquisados, tendo seu foco em total segurança
(MOODLE,2012b).
Segundo Moodle (2012b) as principais características do Moodle são:
21
Administração do site: o site tem como administrador um usuário que é definido
em sua instalação. Algumas extensões ou plugins dão ao administrador a
autonomia para a modificação no tema (fonte e aparência) podendo também
adicionar módulos com atividades e pacotes de idioma que permite a total
compatibilidade com qualquer idioma;
Administração dos usuários: a administração dos usuários tem por objetivo
minimizar o envolvimento por parte do administrador, mas mantendo a segurança.
Algumas extensões existem para auxiliar no mecanismo de autenticação, com
módulos de autenticação. Para a autenticação os alunos criam suas contas de
acesso, havendo uma verificação dos e-mails para confirmação. A conta é única
para todo o servidor, sendo que cada conta pode ter diferentes tipos de
acessos.Para a criação de curso e de professores é necessário uma conta de
administrador que faz esse controle. Já a conta de um criador de cursos somente
permite criar cursos e dar aula em cada curso. Os usuários também tem a opção de
selecionar um idioma desejado na interface do ambiente Moodle;
Administração de curso: a administração do curso tem a possibilidade da
existência de um professor pleno, tendo total controle sobre um curso e podendo
até restringir outros professores. Alguns formatos do curso existentes são semanal
e por tópico. Ainda na administração do curso existe a atividade, sendo sua
composição, fóruns, jornais, questionários, recursos, pesquisas de opinião,
pesquisas, tarefas e chats. Os professores podem personalizar escalas para serem
usadas na hora de dar a nota para tarefas e fóruns;
Módulo Tarefa: neste módulo as tarefas podem conter datas para o seu
cumprimento e uma nota máxima. Os alunos também podem enviar suas tarefas,
sendo que tarefas atrasadas podem ser permitidas, porém o tempo de atraso será
mostrado para o professor. As tarefas podem conter uma avaliação da classe;
Módulo Chat: neste módulo existe uma interação via texto, também aceitando o
envio de imagens. As sessões são todas documentas para possível visualização
posterior;
Módulo Pesquisa de Opinião: este módulo basicamente serve para uma votação
ou até mesmo para a obtenção de um feedback de cada aluno. O professor tem
acesso e visualização de quem escolheu o que;
22
Módulo Fórum: existem diferentes tipos de fóruns como fórum para professores,
news e fórum para uso geral. As discussões podem ser vistas começando pelas
mais recentes ou pelas mais antigas;
Módulo Questionário: podem ser escolhidos diferentes tipos de questões, além de
permitir mostrar um feedback com as respostas corretas. Como esse módulo é de
grande importância para o sistema desenvolvido será detalhado mais adiante;
Módulo Recursos: neste módulo existe um suporte para qualquer conteúdo
eletrônico como Word, Powerpoint, Flash, Vídeo e Sons. Existe a possibilidade de
envio de arquivos que são administrados no servidor, para os conteúdos que são
externos, por exemplo, da internet eles podem ser interligados ou incluídos na
interface do curso;
Módulo Pesquisa de Avaliação: o módulo pesquisa de avaliação é utilizado como
análise das classes nos cursos online. Os seus dados podem ser baixados no
formato de uma planilha Excel ou até mesmo arquivos de texto; e
Módulo Laboratório de Avaliação: já o módulo laboratório de avaliação permite
que parceiros façam avaliações de documentos, sendo administrado pelo professor
que pode dar notas na avaliação feita pelos alunos. Diversos critérios de avaliação
são suportados, havendo também a possibilidade de documentos de exemplo
fornecidos pelo professor, que irão servir para os alunos praticarem a avaliação.
2.2.2 Módulo de questionário do Moodle
Dentre alguns módulos existentes na estrutura do ambiente virtual Moodle foi
abordado nesse trabalho o módulo questionário, mostrando sua estrutura e possibilitando a
integração de um juiz online e uma IDE e debugging online.
O módulo de questionário permite ao professor criar questões que serão armazenadas
em uma base de dados, para poderem ser utilizadas posteriormente, tanto na disciplina para a
qual ele criou bem como podendo ser reutilizada em outros questionários ou até mesmo
disciplinas. Os questionários são avaliados de forma automática, havendo também a
possibilidade do professor definir um prazo limitado de disponibilidade do questionário.
Quando exceder o prazo o questionário se torna indisponível, ficando a critério do professor
se os questionários podem ser respondidos várias vezes, e ainda podem mostrar o feedback e/
23
ou as respostas. Alguns tipos de questão são padrão dos questionários, segundo
(MOODLE,2012b):
Questionários de múltipla escolha com resposta única ou respostas múltiplas;
Questões de Resposta Breve (palavras ou frases);
Questões Verdadeiro-Falso;
Questões de associação;
Questões aleatórias;
Questões numéricas (com escalas permissíveis);
Questões com resposta embutida (estilo fechado) com respostas dentro de
passagens do texto;
Texto e gráficos descritivos embutidos.
2.3 Juízes online
Foram pesquisados diferentes juízes online a fim de proporcionar a realização do
projeto proposto. Dentre os pesquisados houve uma seleção, eliminando de antemão alguns
juízes que não fossem Open Source, como o PC2que não atendeu a esse requisito.
Para a escolha do juiz online levou-se em consideração, além do sistema ser Open
Source, que sua documentação fosse disponível e de fácil acesso. E o que mais se enquadrou
foi o BOCA.
2.3.1 PC2(Programming Contest Control System – Sistema de Controle de
Concurso de Programação)
Sistema projetado com o intuito de dar suporte na operação do concurso de
programação, podendo ser utilizado em uma variedade de ambientes de computação. Permite
que os competidores (equipes) submetam programas através de uma rede para os juízes da
competição, que irão recompilar o programa submetido, executá-lo, ver o código fonte e/ou
resultado de execução, e enviar uma resposta de volta à equipe. O sistema também tem um
“juiz automático”, modo em que o software é quem realiza o julgamento, em vez de juízes
humanos (PC2, 2012b).
24
O sistema registra automaticamente o momento da submissão do algoritmo enviado e
o armazena, exibindo a classificação atual do concurso de vários modos, e permite que o juiz
recupere e execute novamente algoritmos arquivados. Permite também interação com os
juízes referentes a duvidas e esclarecimentos. O PC2 suporta manter competições simultâneas
em vários sites por transmissões de informações automáticas do concurso entre locais,
gerando assim um grande concurso e mostrando em cada local remoto o placar (PC2, 2012b).
Uma grande variedade de opções configuráveis permite ao administrador da
competição ajustar o sistema para as operações especificas da competição, como número de
equipes, problemas, linguagens de programação no concurso e o método de pontuação a ser
aplicado (PC2, 2012b).
O PC2 é um sistema construído em Java, projetado e distribuído para gerenciar e
controlar concursos de programação em tempo real. Suporta múltiplos sites de concursos,
sendo uma plataforma de operações heterogênea, incluindo uma mistura de Windows e Unix
em um mesmo concurso, atualizações dinâmicas em tempo real do estado do concurso e a
classificação para todos os sites (PC2, 2012c).
O sistema opera através de uma arquitetura cliente-servidor, onde cada site em um
concurso é executado um único servidor PC2 (PC2, 2012c).
Contudo o sistema PC2 não é um projeto Open Source, assim não existe uma forma de
obter o seu código-fonte para modifica-lo ou fazer uso em outro sistema (PC2, 2012d)
2.3.2 Mooshak
Mooshak é um sistema de gestão de competição de programação na Web. Algumas
características básicas sobre o Mooshak incluem um juiz automático de algoritmos
apresentados, respostas as perguntas de esclarecimento sobre descrições de problemas,
reavaliação de programas e acompanhamento de impressões (MOOSHAK, 2012).
Mooshak suporta diferentes tipos de competição, em especial aquelas com base em
regras ICPC. Também pode ser facilmente estendido para novos tipos de concursos
(MOOSHAK, 2012).
O sistema foi inicialmente concebido para concursos, mas está cada vez mais sendo
usado em cursos de programação por dar feedback instantâneo sobre aulas práticas, por
receber e validar tarefas a submissões e por pré-avaliar e marcar tarefas (MOOSHAK, 2012).
25
2.3.3 BOCA online
Software feito em PHP que tem interação com as equipes via navegador, foi
desenvolvido com o objetivo de controlar competições no modelo da Maratona de
Programação da SBC. (CAMPOS, 2011).
O sistema BOCA conta com um juiz online que ajuda no processo de julgar uma
submissão, fornecendo um script PHP. Uma vez submetido o problema pelas equipes o script
é capaz de executar comandos de compilar, executar e comparar a saída gerada pelos times
com a saída correta. Não é essencial para o sistema o processo de julgar de forma
automatizada, já que os juízes podem baixar do sistema BOCA todos os arquivos para avaliar
uma submissão (CAMPOS, 2011).
Mesmo com o juiz que corrige de forma automática, a idéia do sistema não consiste
em automatizar o sistema de avaliação as submissões, mas sim um apoio para os juízes
fazerem o seu trabalho. Sendo assim o juiz automático fornece ao juiz os dados gerados pelos
scripts ao tentar compilar, executar e comparar os resultados. Apresentados de uma forma
formatada durante o julgamento, os dados podem auxiliar na hora do juiz julgar a avaliação
submetida (CAMPOS, 2011).
2.4 Ferramentas de IDE e debugging online
O objetivo deste capítulo é apresentar algumas ferramentas de IDEs existentes
priorizando as que abordam pelo menos linguagens como C, C++ e Java, e que mostrem a
execução dos programas de forma online.
Foram pesquisadas 6 ferramentas de IDEs , são elas:
Coderun (CODERUN, 2012);
Codepad (CODEPAD,2012);
Py I/O (PY I/O, 2012);
Online Compiler (ONLINE COMPILER, 2012);
Compilr (COMPILR, 2012); e
26
Ideone (IDEONE, 2012a).
As ferramentas Coderun, Codepad e Py I/O foram desclassificadas por não se
enquadrarem nos requisitos mínimos estipulados da linguagem de programação suportada
pelo sistema.
Mesmo qualificadas no requisito mínimo de linguagem de programação suportada
pelo sistema a ferramenta Online Compiler acabou sendo descartada por não permitir a
execução dos programas de forma online. Já a ferramenta Compilr atendia aos dois requisitos
preestabelecidos, mas a sua integração com o ambiente virtual Moodle não seria possível.
Dessa forma a ferramenta Ideone acabou sendo a escolhida por atender aos requisitos
mínimos solicitados e será analisada a fim de entende-la para melhor aplica-la ao projeto
proposto
2.4.1 Ideone
Projetado para programadores, o Ideone é uma mini IDE e ferramenta de depuração
online. Permite compilar e executar o código online em mais de 40 linguagens de
programação dentre elas C, C++ e Java. O usuário seleciona a linguagem de programação
desejada, digita o seu código fonte e entrada dos dados na caixa de texto especifica, escolhe se
quer executar o código e escolhe sintaxe highlight.(IDEONE, 2012a).
Por ser uma ferramenta destinada a usuários domésticos, instituições educacionais e
pequenas empresas, facilita o seu uso nesse projeto, estando disponível em seu site a Ideone
API com um webservice e seu WSDL (IDEONE, 2012b).
O sistema disponibiliza para seus usuários gratuitos 1000(mil) submissões por mês.
Ultrapassando essas submissões gratuitas o usuário ainda tem a possibilidade de comprar mais
um conjunto de submissões, com preços variados (IDEONE, 2012c):
1.000 submissões por 10 dólares que prorroga a validade de todas as suas
submissões pagas até 60 dias a partir da data da compra.
10.000 submissões para 50 dólares que prorroga a validade de todas as suas
submissões pagas até 120 dias a partir da data da compra.
27
30.000 submissões para 140 dólares que prolongam a validade de todas as suas
submissões pagas até 180 dias a partir da data da compra.
100.000 submissões para 450 dólares prorroga a validade de todas as suas
submissões pagas até 365 dias a partir da data da compra.
A Figura 1 mostra a esquerda uma lista de possíveis linguagens a ser escolhida, já no
centro existe uma caixa de texto para a inserção do código-fonte, abaixo uma caixa para a
entrada de dados, um campo para habilitar ou desabilitar sintaxe highlight aparece no canto
direito.
Figura 1. Tela de inserção de código-fonte no ideone.
Fonte: Ideone (2012a).
A Figura 2 mostra a ferramenta Ideone recebendo valores de entrada, e após a
execução do código-fonte gera uma saída, que é apresentada conforme o algoritmo criado
28
Figura 2. Tela com os resultados da compilação do código-fonte.
Fonte: Ideone (2012a).
2.4.2 Integração de uma IDE e debugging online
Como o ambiente Moodle é online e o sistema desenvolvido utiliza o mesmo, é
interessante a integração de uma IDE e debugging online pois assim o aluno a medida que
cria as suas soluções pode testa-las para poder enviar novamente.
Alguns métodos que podem ser usados, bem como a interpretação dos dados
retornados por eles serão mostrados para melhor entendimento de sua API (IDEONE, 2012d):
O WebService;
Métodos;
Variáveis, valores, códigos e constantes.
Informações gerais do webservice, o Ideone.com é um serviço web padrão sendo
acessado via o protocolo SOAP. SOAP (Simple Object Access Protocol – Protocolo de
Acesso Objeto Simples) é um protocolo que fornece uma comunicação entre aplicações
rodando em diferentes sistemas operacionais, com diferentes tecnologias e linguagens de
programação. Essa comunicação é feita através de HTTP, sendo o mesmo suportado por todos
os navegadores de internet e servidores (SOAP,2012).
As funcionalidades do webservice permitem (IDEONE, 2012d):
29
fazer upload de código-fonte onde o mesmo pode ser compartilhado na
Internet;
execução do código-fonte no servidor com dados de entrada, podendo
escolher entre mais de 40 linguagens de programação;
permite fazer o download dos resultados da execução como saída, erro
padrão, informação de compilação, tempo de execução e uso de
memória.
Para fazer o uso do webservice o algoritmo cria uma pasta e executa no servidor,
sendo um processo bem simples como visto a seguir (Ideone, 2012d).
Primeiro utilizando o método getLanguages para recuperar uma lista de
linguagens de programação disponíveis;
Após o primeiro estagio com o método createSubmission cria-se uma
pasta;
Na verificação se o Ideone terminou a execução do programa usa-se o
método getSubmissionStatus. Caso o programa tenha terminado, vá
para o próximo passo. Caso o programa não estiver terminado repetir o
processo após esperar 35 segundos;
O uso do método getSubmissionDetails para recuperar informações
detalhadas sobre a execução do programa;
Ir para o passo 2 caso não queira fazer nada ou queira executar outro
programa.
Alguns métodos bem como getSubmissionStatus e getSubmissionsDetails não são
obrigados a sua chamada. Se apenas a tarefa for colocar código-fonte no ideone, então apenas
o método createSubmission será chamado (IDEONE,2012d).
Em cada método existem parâmetros comuns, sendo que cada função apresenta pelo
menos dois parâmetros. Desta forma os parâmetros que são encontrados são usuários e senha
(IDEONE,2012d).
30
Para valores retornados os métodos retornam um conjunto especifico de pares,
formando uma matriz associativa onde encontra-se as chaves como strings e os valores sendo
de vários tipos, tais como visto no Quadro 1 (IDEONE,2012d).
Chave Tipo de Valor Valor de amostra
error string OK/AUTH_ERROR/...
chave2 algumTipo algumValor
... ... ...
Quadro 1. Valores retornados.
Fonte: adaptado de Ideone (2012d).
O par [error,errorCode] está sempre incluso na matriz retornada. Se o erro!= OK,
significa que algo deu errado e que alguns pares que seriam retornados pelo método pode não
aparecer na matriz.
As variáveis status e resultado que são retornadas dos métodos getSubmissionStatus e
getSubmissionDetails merecem uma melhor explicação.
A execução do programa é especificada pelo Status, seus valores são interpretados
conforme o Quadro 2
Quadro 2. Descrição do método getLanguages.
Fonte: adaptado de Ideone (2012d).
Ao usar o método getSubmissionStatus e o status não ser igual a 0 deve-se esperar de
3 a 5 segundos para chamar o método novamente.
Valor Significado
<0 Espera de compilação – a pasta aguarda execução na fila .
0 Feito – o programa termina.
1 Compilação – o programa está sendo compilado
3 Em execução – o programa está sendo executado.
31
2.5 Trabalhos similares
Muitos trabalhos sobre esse assunto estão surgindo devido ao dinamismo que
ambientes virtuais de aprendizagem podem proporcionar, bem como a utilização de recursos
para esses ambientes como, por exemplo, exercícios de fixação propostos. Ainda existem
formas de integralizar outras funções, sendo assim o objetivo deste capítulo é apresentar
algumas ferramentas existentes que abordam juízes online no ambiente virtual Moodle, e/ou
que abordam a pratica de exercícios de programação em outro ambiente virtual de
aprendizagem, assim comparando-as, mas dando ênfase no sistema desenvolvido neste TTC.
2.5.1 Um mecanismo para correção automática de exercícios práticos de
programação introdutória
O projeto propõe a correção automatizada de exercícios práticos dando ênfase no
feedback ao aluno, permitindo ao mesmo verificar se os resultados são os desejados em cada
atividade. (PELZ, 2012).
O mecanismo de correção automática de exercícios práticos de programação
introdutória tem quatro etapas, verificação sintática do algoritmo construído pelo aluno,
verificação da presença de comandos obrigatórios, verificação de similaridade entre a
estrutura do aluno com a proposta pelo professor sendo a ultima o gabarito e por último a
execução do programa a fim de verificar se a saída gerada corresponde a saída
esperada/padrão (PELZ, 2012).
Portanto o sistema faz a verificação sintática do algoritmo para avaliar se a sua
execução ocorre sem erros. Faz a verificação da presença de comandos obrigatórios, assim
quando dado um exercício que necessite de desvios condicionais ele deve conter
obrigatoriamente esses desvios. Também faz a verificação de similaridade entre a estrutura do
programa do aluno com o proposto pelo professor, sendo que a estrutura criada pelo
professor será previamente definida pelo mesmo, portanto para tal feito a serialização da
estrutura do programa do aluno tem que ser feita, para que a comparação seja feita de uma
forma mais simplificada. E por fim faz a verificação das saídas sendo que os valores são
estipulados pelo professor nas variáveis do programa, sendo assim o código do aluno é
32
executado gerando uma saída a partir de entradas de teste. Essa saída é comparada com a
saída padrão definida pelo professor (PELZ, 2012).
O sistema foi utilizado por três turmas sendo que alguns exercícios foram propostos,
notando-se que em alguns casos os alunos construíam seus programas no processo de
tentativa e erro aproveitando o feedback do corretor automático para complementarem a
estrutura do seu programa. Mas de forma geral os experimentos realizados foram positivos
(PELZ, 2012).
O projeto descreve a forma de correção. Não apresentando facilidade para criação de
questões, sendo assim o professor necessita criar um XML manualmente. Além disso dá
ênfase ao feedback em atividades realizadas pelos alunos.
Com isso o projeto ajudou a dar uma visão na escolha de um ambiente virtual como o
Moodle que abstrai do professor a parte de código para a criação dos problemas, sendo que os
problemas podem ser criados com alguns passos e de forma visual. Além disso norteou sobre
o feedback das atividades para os alunos.
2.5.2 Adaptação de um corretor automático de código para auxílio da
atividade de exercício e prática no ensino de programação
Esse projeto propõe a adaptação do corretor BOCA para um corretor automático
chamado BOCA-LAB, fazendo uso de partes da programação já existentes no BOCA.
Diferente de outros corretores automáticos de código, o BOCA-LAB não utiliza um juiz na
confirmação das correções, deixando a cargo do sistema essa tarefa, sendo realizada de forma
automática (SOUZA, 2009).
Nesse sistema o professor pode inserir problemas, cadastrar dicas e ter um controle do
usuário. Já o aluno tem a opção de submeter seu código para a análise aguardando o resultado
de sua correção (SOUZA, 2009).
O sistema recebe a submissão de um problema por um aluno, analisa o código,
compila e testa. A entrada padrão gerada pelo professor deve estar contida na entrada do
programa compilado, a saída do programa do aluno é comparada com a saída esperada do
professor. Caso as saídas sejam iguais o problema estará correto, caso contrário estará errado.
BOCA-LAB é um sistema Web multiplataforma (SOUZA, 2009).
O resultado da aplicação prática com as turmas foi positivo. Os participantes foram
ativos no processo das numerosas correções, assim possibilitando uma estatística mais
33
detalhada, ficando comprovado que a ferramenta contribuiu de forma positiva no processo de
aprendizagem, gerando uma métrica de desempenho da turma (SOUZA, 2009).
O projeto faz uso de uma adaptação do corretor do BOCA, assim dando uma visão
maior para a utilização juiz online do sistema BOCA.
2.5.3 Corretor automático de exercícios programa para auxílio no ensino à
distância
O objetivo desse projeto é o de auxiliar no aprendizado de alunos em programação,
facilitando assim o mesmo e procurando uma menor dependência de professores (CUNHA
et.al., 2006).
O sistema funciona a partir de um compilador GCC e um testador que verifica se dado
uma entrada padrão sua saída está de acordo com a saída esperada em um arquivo XML. Esse
corretor gera relatórios de problemas encontrados através dos resultados obtidos nos testes e
na análise do código (CUNHA et.al., 2006).
Para integração com o ambiente virtual Moodle sua interface é divida em três etapas:
envio de tarefas, envio de gabarito e resultado dos testes (CUNHA et.al., 2006).
O projeto deu ênfase no aprendizado de programação, utilizando o ambiente virtual de
aprendizagem Moodle, com isso dando diretrizes para que fosse possível a integração de um
juiz online no ambiente Moodle .
2.5.4 Proposta de um laboratório virtual para aprendizagem de Prolog
Esse projeto tem como objetivo o desenvolvimento de um Ambiente Virtual de
Aprendizagem para a prática da linguagem de programação Prolog. Por se tratar de um
ambiente com interação em tempo real com um interpretador da linguagem via web,
correções e execuções automáticas de exercícios são feitas. Algoritmos são usados para a
avaliação de questões discursivas de forma automática (SANTOS NETO, 2007).
O ambiente faz uso do interpretador Pépe, sendo esse na plataforma Java, o que
permite que o mesmo possa ser acessado em qualquer parte do mundo (SANTOS NETO,
2007).
34
O sistema possibilita aos professores cadastrar questões em formatos diferentes:
verdadeiro/falso, discursiva e múltipla escolha. Ainda há a disponibilização de material de
apoio, avaliações e também a geração de relatórios (SANTOS NETO, 2007).
Em todas as listas de questões de exercícios ou da avaliação em questão, compara-se
com a resposta padrão do professor. Com base na comparação do algoritmo de correção
obtém-se uma nota (SANTOS NETO, 2007).
Os fins almejados pelo projeto foram atingidos, sendo uma ferramenta para auxiliar o
ensino de programação em lógica e auxiliando alunos e professores (SANTOS NETO, 2007).
O projeto se assemelha ao criado, por se tratar de um ambiente virtual utilizando
exercícios de fixação e que verifica se a resposta está conforme o esperado, para o ensino de
linguagem de programação. Assim contribuindo de certa forma por ser possível a utilização
em ambientes virtuais mecanismos para comparar e validar os exercícios dos alunos e assim
gerando um feedback para o mesmo.
35
3 DESENVOLVIMENTO
3.1 DESCRIÇÃO DO SISTEMA
O sistema tem como principal finalidade a criação de problemas de algoritmos,
auxiliando professores que ministram disciplinas de programação bem como os alunos, por
permitir a pratica de exercícios de fixação. Para a construção dos problemas o professor
preenche os campos necessários no ambiente Moodle, sendo eles, o titulo do problema, corpo
do problema (enunciado do problema), um conjunto de casos de teste, cada caso de teste
contém as entradas esperadas pelo programa(entrada) e saída padrão e por fim a linguagem de
programação para a resolução do problema. Já para que os alunos pratiquem os exercícios, os
seus algoritmos devem ser submetidos em forma de código-fonte na linguagem especificada
pelo professor, assim o código deve ser adicionado em um campo textarea, recebendo assim
um feedback imediato do sistema. Esse feedback pode ser tanto positivo, quando um
algoritmo estiver correto ou negativo, quando o algoritmo não estiver funcionando como o
esperado. Para que esse feedback ocorra o código-fonte submetido pelo aluno é compilado
por um juiz online de algoritmos, que está integrado ao ambiente Moodle. Esse código-fonte
compilado, com o conjunto de casos de testes cadastrados pelo professor( entrada padrão) ao
criar o problema, gera uma saída que é comparada com a saída padrão definida pelo professor,
ao criar o problema.
Para o aluno poder praticar este sistema possibilita o envio de algoritmos em três tipos
de linguagens sendo elas C, C++ e Java, porém quem delimita qual linguagem será usada em
cada problema é o professor, uma vez que na construção do sistema encontraram-se
dificuldades para que fosse o aluno quem escolhesse o tipo de linguagem.
A linguagem de programação utilizada para o desenvolvimento do sistema foi PHP em
conjunto com HTML. A ferramenta utilizada para o desenvolvimento da interface foi o
NetBeans IDE 7.1.2. Os servidores utilizados para a instalação/alocação do ambiente Moodle
e do sistema BOCA são distintos, ambos rodando o PostgreSQL como banco de dados. A
utilização de dois servidores distintos se deve por se tratar de questões de segurança, uma vez
que o sistema BOCA encontre algum problema em seu funcionamento devido a códigos
maliciosos o ambiente virtual Moodle não dê problema ou não pare o seu funcionamento.
36
Devido a incompatibilidade de linguagem entre SGBDs diferentes optou-se pelo
PostgreSQL como banco de dados no ambiente Moodle, uma vez que o sistema BOCA é
tratado com esse SGBD.
Na primeira etapa de projeto foi realizada a modelagem do sistema por meio da UML
(Unified Modeling Language), abrangendo análise de requisitos (funcionais do professor e do
aluno e não funcionais), diagramas de caso de uso e banco de dados, descritos nos itens
seguintes. Para a realização da modelagem do sistema, com os conceitos da UML, a
ferramenta utilizada foi o Enterprise Architect 8.
3.2 Análise de Requisitos
Foram levantados, a partir de estudos e junto ao professor que orienta o projeto,
requisitos básicos necessários para garantir o seu funcionamento.
3.2.1 Requisitos Funcionais
São funções detalhadas do comportamento esperado de um sistema, mostrando como
ele reage a entradas específicas e seu comportamento em determinadas situações
(SOMMERVILLE, 2003).
Em um sistema servem para descrever essas funções ou até mesmo serviços que se
espera de um sistema, podendo definir funções detalhadas como entradas e saídas
(SOMMERVILLE, 2003).
A utilização de requisitos funcionais no sistema desenvolvido foi dividida em
requisitos funcionais do professor e requisitos funcionais do aluno. Tais requisitos servem
para a criação e envio de questões no ambiente virtual Moodle.
Requisitos funcionais do professor:
o O sistema permite ao professor cadastrar novas questões;
o O sistema permite ao professor alterar as questões cadastradas;
o O sistema permite que o professor possa visualizar a estatística de
desempenho tanto individual quanto coletiva dos alunos.
Requisitos funcionais do aluno:
o O sistema permite ao aluno enviar respostas aos problemas propostos
pelo professor;
37
o O sistema dá um feedback imediato mostrando o status do problema
(certo, errado, erro de compilação ou tempo excedido), enviado pelo
aluno;
o O sistema permite ao aluno compilar o seu código-fonte e o resultado
da sua execução online;
o O sistema permite ao aluno editar um solução enviada e reenviar.
o O tempo limite de execução dos algoritmos é de 30 segundos.
3.2.2 Requisitos não Funcionais
Ao contrario dos requisitos funcionais, os requisitos não funcionais não descrevem as
funções especificas do sistema: são restrições sobre funções ou serviços que o sistema
proporciona, podendo estar relacionado a propriedades de sistema. Assim ele pode expressar
tempo de resposta, confiabilidade e espaço em disco. Ainda existe a alternativa até podendo
definir restrições para o sistema (SOMMERVILLE, 2003).
Requisitos não funcionais do sistema desenvolvido:
o A solução envolveu somente tecnologia open source;
o Os perfis de acesso ao sistema são:
Administrador: tem permissão para efetuar todas operações;
Professor: tem permissão para cadastrar turmas, problemas,
disciplinas, avaliar os exercícios e cadastrar exercícios;
Aluno: tem permissão para acessar o curso, ver participantes e
enviar respostas para o professor;
o Na correção automática dos exercícios enviados pelos alunos o sistema
utiliza um juiz online que foi integrado ao mesmo;
o O sistema utiliza banco de dados PostgreSQL;
o Foi utilizada a versão 2.0 do ambiente virtual Moodle.
38
3.3 DIAGRAMAS DE CASO DE USO
3.3.1 Caso de Uso do professor
A Figura 3 apresenta os Casos de Uso realizados pelo professor no ambiente Moodle.
O professor pode cadastrar questões em um banco de questões, alterar questões já cadastradas
e ainda há a possibilidade do professor gerar uma estatística de desempenho dos alunos.
Figura 3. Diagrama de caso de uso das funcionalidades do professor.
3.3.1.1 UC01.01 Cadastrar questões
Permite que após um questionário criado o professor possa cadastrar questões novas,
alimentando o banco de questões que posteriormente poderão ser usadas em outros
questionários ou até mesmo em outras disciplinas.
Cadastrar questões (Principal)
1. O professor estando devidamente logado no ambiente Moodle, e
selecionando o curso desejado, deve criar um questionário.
2. O sistema irá mostrar um botão edição de questionário.
3. O professor seleciona o botão edição.
uc PCT01- Módulo de cadastro e relatórios do professor
UC01.01 Cadastrar
questões
UC01.03 Gerar
estatística de
desempenho dos
alunos
UC01.02 Alterar
questões
cadastradas
Professor
«include»
39
4. O sistema irá mostrar a opção de adicionar uma nova pergunta ou
adicionar perguntas já existentes em outros cursos ou até mesmo
questionários.
5. O professor seleciona adicionar perguntas novas.
6. O sistema apresenta várias opções de questões.
7. O professor escolhe o tipo de questão, que no caso será o tipo criado
pelo sistema desenvolvido chamado: juiz online de algoritmos.
8. O sistema apresenta alguns campos para o preenchimento que são:
titulo da questão, texto da questão, entrada e saída padrão.
9. O professor preenche os campos com os dados do problema - titulo da
questão, texto da questão, entrada e saída padrão.
10. O professor clica no botão salvar.
11. O sistema retorna para a edição do questionário.
Adicionar mais questões ao questionário (Alternativo).
1. Após o passo 11 o professor, querendo adicionar mais questões ao
questionário, retorna ao passo quatro onde irá começar o processo
novamente.
Cancelamento (Exceção).
1. A qualquer passo o professor pode cancelar o cadastro de uma nova
questão, retornando assim à agenda do curso.
3.3.1.2 UC01.02 Alterar questões cadastradas
Permite ao professor a alteração de questões cadastradas.
Alteração de questões cadastradas (Principal).
1. O sistema mostra a lista de questões já cadastradas.
40
2. O professor seleciona a questão que deseja alterar.
3. O sistema mostra os campos da questão.
4. O professor altera os campos desejados.
5. O professor seleciona o botão salvar alterações.
6. O sistema altera a questão e retorna a lista de questões.
Cancelamento (Exceção).
1. A qualquer passo o professor pode cancelar a alteração de uma questão,
retornando assim a lista de questões.
3.3.1.3 UC01.03 Gerar estatística de desempenho dos alunos
Permite ao professor gerar estatística do desempenho dos alunos, a fim de comparar e
ver o rendimento da turma.
Gerar estatística de desempenho dos alunos (Principal).
1. O professor após estar logado, e no curso desejado, seleciona na
agenda do curso o questionário desejado. Nele existe um botão
resultados que será clicado pelo mesmo.
2. O sistema exibe um submenu, onde se encontra estatísticas.
3. O professor clica em estatísticas.
4. O sistema apresenta algumas informações referentes ao questionário,
bem como tentativas avaliadas, nota média das tentativas e nota
mediana.
5. O professor retorna aos problemas.
Cancelamento (Exceção).
1. A qualquer passo o professor pode cancelar a geração de estatística,
retornando assim a agenda do curso.
41
3.3.2 Caso de Uso do aluno
A Figura 4 apresenta os Casos de Uso realizados pelo aluno no ambiente Moodle.
Figura 4. Diagrama de Casos de Uso das funcionalidades do aluno.
3.3.2.1 UC02.01 Enviar respostas dos problemas
Permite que o aluno possa enviar sua solução para os problemas propostos pelo
professor.
Enviar respostas dos problemas (Principal).
1. O aluno devidamente logado no ambiente moodle e no curso desejado
seleciona o questionário criado pelo professor.
2. O sistema irá exibir a tela para o aluno iniciar o questionário, tendo um
botão para iniciar esse processo.
3. O aluno clica no botão iniciar questionário.
4. O sistema apresenta o questionário, podendo o aluno escolher qual
questão irá responder primeiro.
5. O aluno visualiza o problema e a linguagem escolhida pelo professor
para que possa criar o seu algoritmo.
6. O aluno digita o código-fonte no campo especificado e clica em enviar.
uc PCT02 - Módulo de relatórios
Aluno
UC02.01 Env iar
respostas dos
problemas
UC02.02 Visualizar o
feedback do problema UC02.03 Editar
solução env iada
«include»
«include»
42
7. O sistema retorna se foi enviado com sucesso.
8. O aluno clica em voltar para a agenda do curso.
3.3.2.2 UC02.02 Visualizar o feedback do problema
O aluno tem a possibilidade de visualizar após o envio de seus problemas o feedback
com sua nota, podendo estar certa ou errada
Visualizar o feedback do problema (Principal).
1. O sistema exibe após o aluno enviar seus problemas a opção de
visualizar sua nota.
2. O aluno seleciona em visualizar o feedback do problema enviado.
3. O sistema exibe o feedback com a nota podendo ser certo e errado,
sendo que quando estiver certo aparecerá 100% e quando estiver errado
aparecerá 0%.
4. O aluno retorna à agenda do curso.
3.3.2.3 UC02.03 Editar solução enviada
O aluno tem a possibilidade de editar uma solução já enviada a fim de melhorar o seu
desempenho .
Editar solução enviada (Principal).
1. O aluno clica em questões enviadas.
2. O sistema exibe o código-fonte já enviado.
3. O aluno pode fazer qualquer tipo de alteração em seu código, após feito
isso clica no botão enviar.
4. O sistema pergunta se o aluno deseja enviar e terminar tudo.
5. O aluno confirma.
6. O aluno clica em voltar para a agenda do curso.
43
Alteração diversas vezes (Alternativo)
1. Após o passo 4, depois de enviar a correção, caso o aluno queira alterar
novamente e reenviar, ele retorna ao passo 1.
3.4 BANCO DE DADOS
O banco de dados do sistema BOCA possui doze tabelas. Dentre elas quatro são
utilizadas pelo juiz do BOCA, conforme na Figura 5. Porém, foram criadas duas tabelas a
mais, como mostra a Figura 6, para que houvesse a manipulação dos dados entre as tabelas já
existentes.
Figura 5. Adaptação das tabelas do BOCA.
A tabela problemtable serve para o cadastramento das questões por parte do professor.
O BOCA espera por um arquivo .zip com as entradas e saídas cadastradas pelo professor, bem
44
como informações do problema. Além disso, a tabela é alimentada com outros atributos da
questão.
Esse arquivo .zip, tem em sua estrutura alguns diretórios, bem como: compare,
compile, description, input, limits, output, run, tests. Como nesse projeto serão alterados só
dois diretórios, os mesmos serão descritos. Para o diretório input, um arquivo contendo o
conjunto de casos de teste, sendo que cada caso de teste contém as entradas esperadas pelo
programa, que foram criados pelo professor, assim é adicionado a esse diretório. Já para o
diretório output, um arquivo contendo o conjunto de saídas criado pelo professor é
adicionado.
Na tabela runtable a medida que o aluno submete os seus algoritmos o atributo rundata
é alimentado, com um arquivo com a extensão necessária de cada linguagem de programação.
Após a execução do algoritmo o mesmo irá alimentar com valores da tabela answertable o
campo runanswer, onde diz se o algoritmo está correto ou se deu algum problema na
compilação ou na execução.
Langtable será uma tabela fixa onde as linguagens de programação serão apenas C,
C++ e Java, sendo assim com valores definidos.
Figura 6.Tabela tempaluno e tempprofessor criadas no BOCA.
45
3.5 Integração do juiz online do BOCA
A integração do juiz online do BOCA no ambiente Moodle foi feita através da criação
de gatilhos (Triggers). Segundo Silberschatz, Korth e Sudarshan (2006) gatilhos são uma
instrução que faz a execução automática pelo sistema caso haja alguma modificação no banco
de dados. O armazenamento do triggers no banco de dados é representado como sendo um
dado normal, sendo acessível a todas as operações do banco de dados. Sua introdução faz com
que o sistema de banco assuma a responsabilidade em executa-lo quando o evento
especificado ocorrer.
Portanto quando um professor cadastra uma questão no ambiente Moodle será
gravada no banco de dados do mesmo.
Após a inserção dos problemas no banco de questões do Moodle, o primeiro trigger
(gatilho) é acionado, gravando os dados da questão na tabela tempprofessor, criada no banco
de dados do sistema BOCA.
Com isso os dados são gravados na tabela tempprofessor, e um segundo gatilho é
acionado carregando os dados relacionados ao problema criado pelo professor e o arquivo
problem.zip com o input e output do problema são adicionados a tabela problemtable. Tabela
essa já nativa do BOCA.
Feito isso, à medida que o aluno responder a questão no ambiente Moodle o envio será
registrado nas tabelas do banco do ambiente. Já gravados no ambiente, outra trigger é
acionada, na tabela onde a resposta do aluno foi gravada, para a tabela tempaluno. Criada no
banco de dados do sistema BOCA.
A seguir outra trigger é acionada mas já na tabela tempaluno, que pega o arquivo com
a resposta do aluno e as informações da questão e cadastra na tabela runtable, tabela já nativa
do sistema BOCA.
Para a verificação se um problema submetido está correto faz-se uso de um processo
do BOCA chamado autojuding (juiz online), que compila o algoritmo enviado pelo aluno,
gerando assim uma saída, que é comparada com a saída padrão definida pelo professor na
criação do problema.
46
O mesmo fica sendo executado em paralelo indeterminadamente com uma
atualização de minuto em minuto, sempre verificando se há algum problema para ser julgado
existente nas tabelas do BOCA. Havendo um novo problema para ser julgado, ele julga e o
resultado será gravado na tabela do BOCA. Com isso a trigger na tabela runtable é acionada,
pegando o resultado na tabela do BOCA e alterando as tabelas do ambiente Moodle,
possibilitando que o aluno possa visualizar o feedback do seu problema (Figura 7).
Figura 7. Esquema da integração de um juiz online no ambiente Moodle.
Portanto o feedback imediato é a resposta 1.000000 no caso de uma resposta correta
ou 0.000000 quando a resposta estiver errada . Já o feedback do professor no corpo da
resposta poderá ser:
Erro de compilação.
Output erro de formatação (representando que a saída do programa não segue a
especificação exigida).
Tempo limite excedido(representando que excedeu o tempo estipulado que é
de 30 segundos na execução).
Para viabilizar a utilização dos gatilhos criados, é necessária a utilização, para a
transferência dos dados em servidores distintos o uso do Dblink.
O Dblink, é um conjunto de funções, que possibilita a conexão entre banco de dados
PostgreSQL com o intuito de ter acesso a dados externos. Os dados externos podem ser
47
considerados, tanto banco de dados distantes fisicamente exemplo, em servidores distintos,
como um banco de dados local. Sendo assim o Dblink permite o acesso remoto a uma tabela
de uma determinada base de dados, e a realizar a execução de queries. O seu desempenho
depende da infraestrutura da rede, por realizar o seu acesso através do protocolo TCP/IP.
(SMANIOTO, 2006)
Para a utilização do Dblink no banco de dados PostgreSQL é preciso que o conjunto
de funções que o compõem, sejam instalados. Sendo que o mesmo não vem instalado por
padrão. (SMANIOTO, 2006)
O conjunto de funções que compõem o Dblink estão descritos no Apêndice A
3.6 INTERFACES DO SISTEMA
Serão apresentadas nessa seção as principais interfaces do sistema desenvolvido,
sendo elas, a tela do professor, retratando a administração do curso, criação de questões e
relatórios de desempenho dos alunos. Ainda serão apresentadas as telas referentes ao aluno
compondo a tela para responder as questões e a tela de feedback.
3.6.1 Telas do professor
A tela de administração do curso permite ao professor a criação de questionários,
posteriormente a adição de questões aos questionários e a geração do curso criando turmas e
visualizando o desempenho dos alunos. Para possibilitar a edição e a criação de questionários
o botão de ativar edição deve ser clicado.
A Figura 7 apresenta uma lista de tipos de questões para a escolha do professor. Nessa
tela será escolhida pelo professor os exercícios do Juiz Online. Após a escolha do tipo de
questão o sistema irá apresentar outra tela para criação da questão, mostrando os campos
necessários para cada tipo de questão.
48
Figura 8. Tela de escolha do tipo de questão Juiz Online.
A Figura 8 mostra a tela para a criação da questão, após a seleção do tipo de questão.
O professor deve inserir o titulo para a questão, o texto do enunciado da questão, um conjunto
de entradas e um conjunto de saídas padrão. O professor deve especificar qual o tipo de
linguagem utilizada pelo aluno na criação do algoritmo.
Para poder julgar as questões o juiz do BOCA, necessita de um conjunto de entradas e
saídas padrão, que estarão em um arquivo .zip contendo também algumas informações
referentes a questão. Para possibilitar a criação dos arquivos contendo um conjunto de entrada
e um conjunto de saída padrão e posteriormente os mesmos serem adicionados a um arquivo
.zip. foi criado um código em PHP inserido na classe edit_juiz_form.php que encontrasse na
pasta /question/type/juiz, do ambiente Moodle. Assim após a criação dos arquivos contendo
as entradas e saídas, esses arquivos são inseridos no arquivo problem.zip existente no servidor
do Moodle. Como via dblink não é possível o envio de arquivos, a forma encontrada para o
envio desse arquivo problem.zip foi via FTP, para o servidor onde o BOCA está instalado.
Sendo assim quando o gatilho da criação de questão é acionado ele insere os atributos da
questão na tabela tempprofessor criada no BOCA que faz uma ponte para posteriormente
49
outro gatilho ser acionado e adicionar os atributos da questão juntamente com o arquivo
problem.zip na tabela problemtable onde é a tabela em que se é cadastrada o problema no
sistema BOCA.
Figura 9. Tela de criação da questão.
No Quadro 3 é apresentado o gatilho (trigger) tg_atualia_boca2, criado na tabela
mdl_question_juiz, que tem como papel acionar a função moodle_gatilho_to_boca() toda vez
que um dado for atualizado (AFTER UPDATE) na tabela.
50
Uma questão quando criada no ambiente Moodle tem os seus atributos comuns entre
questões inseridos na tabela mdl_question. Após esses dados serem inseridos, um id é criado e
inserido na tabela do tipo de questão desejado. Partindo desse principio a escolha na utilização
do AFTER UPDATE se deve ao fato de que o id é inserido primeiro na tabela
mdl_question_juiz, deixando o restante dos atributos em branco, para em seguida os seus
atributos serem atualizados, portanto um AFTER INSERT não serviria nesse caso.
CREATE TRIGGER tg_atualiza_boca2
AFTER UPDATE
ON mdl_question_juiz
FOR EACH ROW
EXECUTE PROCEDURE moodle_gatilho_to_boca();
Quadro 3. Criação da trigger tg_atualiza_boca2.
No Quadro 4, a função moodle_gatilho_to_boca cria uma ligação com o servidor onde
o banco de dados do BOCA está. Essa ligação entre bancos é feita através do dblink. Dessa
forma possibilita o envio de comandos SQL para o banco de dados do BOCA, onde é feita
uma inserção na tabela tempprofessor. Essa inserção contem os atributos de uma questão do
juiz online, salvas na tabela mdl_question_juiz no ambiente Moodle. Os atributos enviados da
questão são: o numero da questão, o nome da questão e a linguagem de programação
escolhida pelo professor.
51
O gatilho tg_envia_problemtable, visto no Quadro 5, foi criado na tabela
tempprofessor do banco de dados do BOCA. O mesmo é acionado à medida que algum dado é
inserido ou atualizado na tabela. A função chama-se tempaluno_gatilho_problemtable().
CREATE TRIGGER tg_envia_problemtable
AFTER INSERT OR UPDATE
ON tempprofessor
FOR EACH ROW
EXECUTE PROCEDURE tempprofessor_gatilho_problemtable();
Quadro 5. Criação da trigger tg_envia_problemtable.
A função tempaluno_gatilho_problemtable, vista no Quadro 6, ao ser acionada pelo
gatilho tg_envia_problemtable pega os dados que foram inseridos recentemente na tabela
tempprofessor e os insere em outra tabela, chamada problemtable. A mesma é a responsável
pela criação das perguntas pelo professor. Essa inserção é feita com os atributos na criação da
questão pelo professor, que foram inseridos na tabela do Moodle, e enviados para a tabela
CREATE OR REPLACE FUNCTION moodle_gatilho_to_boca()
RETURNS trigger AS
$BODY$
DECLARE
nomequestao text;
BEGIN
nomequestao := (SELECT name FROM mdl_question WHERE id=
NEW.question);
PERFORM dblink_exec('hostaddr= XXX.XXX.XX.XX
port=5432 user=XXXX password=XXXX dbname=bocadb',
'INSERT INTO tempprofessor(id,questionid,namequestion,langprog)
VALUES ((SELECT max(id) FROM tempprofessor)
+1,'||NEW.question||','''||nomequestao||''','||NEW.linguagempro
g||')');
RETURN NEW;
END;
$BODY$
LANGUAGE plpgsql;
Quadro 4. Criação da função moodle_gatilho_to_boca().
52
tempprofessor do BOCA. Dentre os atributos passados estão o numero do problema, nome do
problema, nome do arquivo e o arquivo contendo o problema.
CREATE OR REPLACE FUNCTION tempprofessor_gatilho_problemtable()
RETURNS trigger AS
$BODY$
BEGIN
INSERT INTO problemtable(contestnumber, problemnumber,
problemname, probleminputfilename, fake)
VALUES (5,NEW.questionid, NEW.namequestion, 'problem.zip',
lo_import('/home/icpcadmin/Public/problem.zip'),'false');
RETURN NEW;
END;
$BODY$
LANGUAGE plpgsql;
Quadro 6. Criação da função tempprofessor_gatilho_problemtable().
3.6.2 Telas do aluno
A Figura 9 apresenta a tela do aluno com o problema, mostrando o titulo do problema,
o corpo do enunciado contendo exemplos de entrada e saída que o programa deverá gerar,
além disso, existe uma caixa de texto para que o aluno possa colar o seu código-fonte e por
fim um texto mostra em qual linguagem deve ser criado o algoritmo.
Para que o juiz do BOCA possa julgar a solução submetida pelo aluno ele espera um
arquivo contendo o código-fonte do algoritmo. Portanto foi necessário criar um arquivo do
aluno a partir de seu código-fonte. Para viabilizar esse processo foi inserido um código em
PHP na classe renderer.php. Essa classe é a responsável por gerar a tela do aluno pelo
Moodle. Sendo assim o aluno ao clicar em submeter a sua solução via Moodle o arquivo é
criado no servidor onde o Moodle se encontra. Mas para enviar esse arquivo ao servidor onde
o juiz do BOCA se encontra foi necessário a utilização do envio via FTP, uma vez que via
dblink não seria possível, já que o dblink não suporta envio de arquivos. Após a criação do
arquivo, sequencialmente o gatilho de envio da solução do aluno é acionado, enviando à
tabela tempaluno, criada no banco de dados do BOCA os atributos da questão e atributos da
53
solução do aluno. Assim outro gatilho é acionado na tablea tempaluno que envia o arquivo
com a solução do aluno e os atributos referentes a mesma para a tabela runtable, onde a
mesma é responsável para que o juiz possa julgar as questões.
Figura 10. Tela do aluno com o problema a ser resolvido.
54
É apresentado no Quadro 7 o gatilho (trigger) tg_atualiza_boca_aluno, criado na
tabela mdl_question_attempts, que tem como papel acionar a função
moodle_gatilho_to_boca_aluno(), toda vez que um dado for atualizado (AFTER UPDATE)
na tabela.
A tabela mdl_question_attempts, é uma tabela criada pelo Moodle quando o mesmo é
instalado. Essa tabela é a responsável por guardar a resposta do aluno e alguns atributos
referentes à questão. Os atributos referentes a questão são inseridos a partir do momento em
que o aluno inicia uma tentativa. Mas a sua resposta só é salva nessa tabela quando o aluno
finaliza e envia tudo. Devido a isso foi escolhido para a sua utilização o AFTER UPDATE,
onde um AFTER INSERT não iria capturar a resposta do aluno ao terminar de responder a
questão.
CREATE TRIGGER tg_atualiza_boca_aluno
AFTER UPDATE
ON mdl_question_attempts
FOR EACH ROW
EXECUTE PROCEDURE moodle_gatilho_to_boca_aluno();
Quadro 7. Criação da trigger tg_atualiza_boca_aluno.
O Quadro 8, mostra a função moodle_gatilho_to_boca_aluno, que cria uma ligação
com o servidor onde o banco de dados do BOCA está. Essa ligação entre bancos é feita
através do dblink. Via dblink, uma instrução de inserção é enviada, para a tabela tempaluno,
onde os atributos enviados são: o timemodified, id da questão, nome da questão, a resposta do
aluno e a linguagem escolhida pelo professor para a resolução do problema.
55
CREATE OR REPLACE FUNCTION moodle_gatilho_to_boca_aluno()
RETURNS trigger AS
$BODY$
DECLARE
slinguagem int;
codigo text;
BEGIN
IF NEW.responsesumary <> ' ' THEN
slinguagem := (SELECT linguagemprog FROM mdl_question_juiz
WHERE question = NEW.questionid);
PERFORM dblink_exec('hostaddr= XXX.XXX.XX.XX port=5432
user=XXXX password=XXXX dbname=bocadb',
'INSERT INTO tempaluno(id, timemodified, questionid, namequestion,
bodyquestion, langprog)
VALUES
((SELECT max(id) FROM tempaluno)+1,
'||NEW.timemodified||','||NEW.questionid||',
$$'||NEW.questionid||'.c$$,
$$'||NEW.responsesumary||'$$,'||slinguagem||' )');
END IF;
RETURN NEW;
END;
$BODY$
LANGUAGE plpgsql;
Quadro 8. Criação da função moodle_gatilho_to_boca_aluno().
O gatilho tg_envia_runtable, visto no Quadro 9, foi criado na tabela tempaluno do
banco de dados do BOCA. O mesmo é acionado à medida que algum dado é inserido ou
atualizado na tabela. Assim chamando a função tempaluno_gatilho_runtable().
CREATE TRIGGER tg_envia_runtable
AFTER INSERT OR UPDATE
ON tempaluno
FOR EACH ROW
EXECUTE PROCEDURE tempaluno_gatilho_runtable();
Quadro 9. Criação da trigger tg_envia_runtable.
A função tempaluno_gatilho_runtable, vista no Quadro 10, ao ser acionada pelo
gatilho tg_envia_runtable pega os dados que foram inseridos recentemente na tabela
tempaluno e os insere em outra tabela, chamada runtable. A mesma é a responsável pelas
respostas do aluno. Essa inserção é feita com os atributos da resposta do aluno, que foram
inseridos na tabela do Moodle, e enviados para a tabela tempaluno do BOCA. Dentre os
56
atributos passados estão: o numero da questão, nome do arquivo, arquivo contendo o código-
fonte da resposta do aluno e a linguagem selecionada pelo professor.
CREATE OR REPLACE FUNCTION tempaluno_gatilho_runtable()
RETURNS trigger AS
$BODY$
DECLARE
nomearquivo text;
BEGIN
nomearquivo := NEW.questionid||(SELECT CASE
WHEN NEW.langprog = 1 THEN '.c'
WHEN NEW.langprog = 2 THEN '.cpp'
WHEN NEW.langprog = 3 THEN '.java'
ELSE 'other'
END);
INSERT INTO runtable
(contestnumber, runsitenumber, runnumber, usernumber, rundate,
rundatediff, rundatediffans, runproblem, runfilename,
rundata, runstatus, runlangnumber)
VALUES
(5,1,(SELECT max(runnumber) FROM runtable)+1,
2,NEW.timemodified,
5620,99999999,NEW.questionid, nomearquivo,
lo_import('/home/icpcadmin/teste/'||nomearquivo),
'openrun', NEW.langprog);
RETURN NEW;
END;
$BODY$
LANGUAGE plpgsql;
Quadro 10. Criação da função tempaluno_gatilho_runtable().
A Figura 11 apresenta o feedback para o aluno. Com isso o aluno tem uma resposta se
o seu algoritmo fez o que era esperado ou não. Assim quando o algoritmo estiver como o
esperado o textarea fica na cor verde e caso contrário fica na cor vermelha, simbolizando que
o algoritmo não está como esperado.
57
Figura 11. Tela de feedback.
Essa resposta é gerada na tabela runtable no banco de dados do BOCA. Sendo assim a
medida em que o juiz julga a questão é inserida a resposta em um campo em sua tabela.
Portanto, quando é inserida a resposta do juiz na tabela um gatilho é acionado. Esse gatilho
tem como função verificar se a resposta obtida é um yes (quando estiver correto) ou outros
tipos de erros (quando não estiver correto), assim transformando a resposta que é uma string,
em formato numérico, para poder ser inserida em duas tabelas no ambiente Moodle. São elas
58
mdl_question_attempt_steps e mdl_quiz_attempts, onde na primeira serão atualizados dois
atributos. Os atributos atualizados são state e o atributo fraction. Já a segunda tabela somente
um atributo é atualizado, sendo ele o sumgrades. Assim quando a solução estiver correta os
atributos fraction e sumgrades passam de 0.0000000 para 1.0000000 e o atributo state muda
de gradedwrong para gradedright. Caso contrario permanece inalterado.
O Quadro 11 mostra a criação do gatilho tg_atualiza_resposta_aluno, na tabela
runtable do BOCA. O mesmo aciona a função boca_to_moodle_resposta(), quando atualizada
a tabela, com a resposta do juiz.
CREATE TRIGGER tg_atualiza_resposta_aluno
AFTER UPDATE
ON runtable
FOR EACH ROW
EXECUTE PROCEDURE boca_to_moodle_resposta();
Quadro 11. Criação da trigger tg_atualiza_resposta_aluno.
A função boca_to_moodle_resposta(), vista no Quadro 12, ao ser acionada pelo
gatilho tg_atualiza_resposta_aluno pega o dado da resposta do juiz online e verifica se a
resposta é um acerto ou um erro, transformando essa resposta em um valor numérico, de
1.000000 ou 0.000000 respectivamente. Com essa resposta numérica, a função envia via
dblink, dois comandos de SQL de inserção com esses dados, em duas tabelas diferentes do
ambiente Moodle, sendo elas mdl_question_attempt_steps e mdl_quiz_attempts. Essas
alterações são fundamentais para que o feedback do aluno aconteça.
59
CREATE OR REPLACE FUNCTION boca_to_moodle_resposta()
RETURNS trigger AS
$BODY$
BEGIN
IF NEW.autoanswer = 'YES' THEN
PERFORM dblink_exec('hostaddr= XXX.XXX.XX.XX
port=5432
user=XXXX
password=XXXX
dbname=bocadb',
'UPDATE mdl_question_attempt_steps SET
state = ''gradedright'', fraction = '1.0000000'
WHERE questionattemptid=(SELECT id FROM
mdl_question_attempts
WHERE questionid=''NEW.runproblem'')');
PERFORM dblink_exec('hostaddr= XXX.XXX.XX.XX
port=5432
user=XXXX
password=XXXX
dbname=bocadb',
'UPDATE mdl_question_quiz_attempts SET
sumgrades='1.0000000'
WHERE uniqueid=(SELECT questionusageid
FROM mdl_question_attempts
WHERE questionid=''NEW.runproblem''
ORDER BY id DESC LIMIT 1)');
END IF;
RETURN NEW;
END;
$BODY$
LANGUAGE plpgsql;
Quadro 12. Criação da função boca_to_moodle_resposta().
Mesmo o juiz online julgando como correto ou incorreto o algoritmo do aluno, o
professor pode alterar de forma manual a correção. Já que o ambiente Moodle permite essa
funcionalidade para o professor.
60
4 CONCLUSÕES
O trabalho teve como principal objetivo a integração de um juiz online através de
gatilhos, IDE e debugging online no ambiente virtual Moodle, proporcionando aos alunos um
ambiente para exercitar seus conhecimentos e obter um feedback imediato de sua resposta,
podendo posteriormente reparar e reenviar. Esse feedback se dá a partir da integração entre o
ambiente Moodle e o juiz online, que compara um conjunto de casos de testes, sendo que cada
caso de teste contém as entradas esperadas pelo programa e saída padrão, cadastrados pelo
professor que são comparados com o resultado da compilação do algoritmo do aluno. Uma
característica importante deste trabalho foi o desenvolvimento de um novo tipo de questão
para o ambiente Moodle.
Desde o inicio da implementação desta ferramenta foram encontrados problemas,
quanto à complexidade no entendimento do código-fonte do ambiente Moodle, e a sua
manipulação.
A pesquisa realizada sobre a estrutura do ambiente Moodle foi de grande importância
para a definição de qual seria a melhor forma de aplicação dos exercícios criados pelos
professores. Dentre os tipos de questão pesquisados o que se mostrou mais próximo do que
foi criado para o sistema desenvolvido foi shortanswer que é um tipo de questionário, sendo
que algumas modificações e testes foram necessários.
Já na pesquisa sobre a estrutura dos juízes online, no começo foi um pouco difícil por
falta de documentação existente, mas foram estudadas as tabelas do banco de dados do
sistema BOCA. Assim facilitando o entendimento sobre como o sistema operava e podendo
dessa forma ser integrado a outro sistema, no caso ao ambiente virtual Moodle.
Para a pesquisa das IDEs e debugging online foi escolhida a Ideone que tem a sua
estrutura de fácil integração com outros sistemas, sendo bem documentada. Porém, com a
complexidade encontrada no desenvolvimento no Moodle, e pela utilização de programas e
sistemas pouco usuais de difícil entendimento, tais como: Ubuntu e Moodle. Assim ficando
para trabalhos futuros.
61
Para a criação dos problemas o professor tem que elaborar de forma diferente as
questões, tendo em vista que o juiz online espera um conjunto de casos de teste (input) com
suas respectivas saídas (output), assim os problemas devem ser elaborados com esse formato.
Com o sistema, espera-se que haja uma contribuição ao ensino de algoritmos nas
disciplinas de programação, e que o feedback imediato possa proporcionar uma maior
interação ao aluno, possibilitando assim a pratica de algoritmos.
Algumas limitações foram encontradas durante o desenvolvimento do sistema, sendo
elas: copiar dados da tabela para um arquivo sem perder a formatação, o envio de arquivos
entre servidores distintos e não poder enviar para o repositório Moodle.
A limitação quanto a copia dos dados da tabela para um arquivo se deve a medida que
foram criados comandos para copiar os dados contendo tanto os inputs e outputs do professor
quanto o algoritmo com a solução do aluno. Inviabilizava a simples copia dos dados por
perder a formatação e com isso no caso do aluno o algoritmo se perdia.
Quanto ao envio de arquivos entre servidores distintos, o uso do dblink para tal foi
inviabilizado por não suportar esse tipo de ação. Portanto outra técnica teve que ser
empregada, sendo ela o envio de arquivos via FTP.
Com relação a impossibilidade de envio ao repositório do Moodle deve-se ao fato do
sistema não possuir internacionalização (permitir suporte a varias línguas), sendo assim um
fator limitante.
Para trabalhos futuros fica a sugestão da integração da IDE e debugging online o
Ideone. Também a criação de uma tabela guardando os endereços de ips, senhas e logins, já
que no sistema desenvolvido estão inseridos nas triggers e com isso caso precise alterar
alguma informação referente a esses dados, é necessário alterar as triggers. Outra
funcionalidade, seria a estatística individual de cada aluno, mostrando quantos exercícios
foram aceitos e mostrando a media de acertos dos participantes para cada questão.
62
REFERÊNCIAS
CAMPOS, Cassio P. de; FERREIRA, Carlos E. BOCA: um sistema de apoio a competições
de programação. 2004. Disponível em:
<http://www.ime.usp.br/~cassio/boca/campos-ferreira-wei2004.pdf >. Acesso em: 18 ago.
2012.
CAMPOS, Cassio P. de. Autojudging. 2011. Disponível em:
<http://www.ime.usp.br/~cassio/boca/boca/doc/AUTOJUDGING.txt>. Acesso em: 19 set.
2012.
CICALA, Marcelo. Funções DBLINK: PostgreSQL.2013.Disponível em:
<http://studentsql.blogspot.com.br/2013/02/funcoes-dblink-postgresql.html>.Acesso em 29
maio 2013.
CODEPAD. 2012. Disponível em: < codepad.org>. Acesso em: 26 set. 2012.
CODERUN. Web Development Tools. 2012. Disponível em: < www.coderun.com>. Acesso
em: 26 set. 2012.
COMPILR. 2012. Disponível em: < compilr.com>. Acesso em: 26 set. 2012.
CORMEN, Thomas H. et. al. Algoritmos: teoria e prática. 2.ed. Rio de Janeiro:Elsevier.2002.
CUNHA, Daniel Matuki da et. al. Corretor automático de exercícios programa para auxílio no
ensino à distância. 2006. Disponível em: <http://www.linux.ime.usp.br/~cef/mac499-
06/monografias/patricia/monografia.pdf>. Acesso em: 29 ago. 2012.
FERREIRA, Carlos E. Matarona de Programação: o que é?. 2012. Disponível em:
<http://maratona.ime.usp.br/info12.html>. Acesso em: 15 ago. 2012.
PELZ, Fillipi D. ; JESUS, Elieser A. de ; RAABE, André L. A. Um mecanismo para correção
automática de exercícios práticos de programação introdutória . 2012. Disponível em: <
http://www.br-ie.org/pub/index.php/sbie/article/view/1780>. Acesso em 05 dez. 2012.
IDEONE. How to use ideone?. 2012. Disponível em: <http:// ideone.com >. Acesso em 26
set. 2012a.
IDEONE. Terms of Use: rules, warranty, liability. 2012. Disponível em:
<http://ideone.com/terms >. Acesso em: 27 set. 2012b.
IDEONE. Rules. 2012. Disponível em: < http://ideone.com/offer/users >. Acesso em: 26 set.
2012c.
IDEONE. Your great ideas will be born here. 2012. Disponível em: < http://ideone.com/ >.
Acesso em: 26 set. 2012d.
IDEONE.API. 2012. Disponível em: < http://ideone.com/files/ideone-api.pdf>. Acesso em:
30 set. 2012d.
63
MEDINA, Marco; FERTIG, Cristina. Algoritmos e programação: teoria e prática. São
Paulo: Novatec, 2005.
MOREIRA, Mireille Pinheiro; FAVERO, Eloi Luiz. Um ambiente para ensino de
programação.2008. Disponível em:
<http://www.ufpa.br/ppgcc/ppgcc/files/File/Seminario_Andamento/2008/EAD/artigo_1.1.pdf
>. Acesso em: 15 ago. 2012.
MOODLE. Moodle: sobre o moodle. 2012a. Disponível em:
< http://docs.moodle.org/all/pt_br/Sobre_o_Moodle >. Acesso em: 15 ago. 2012.
MOODLE. Características do Moodle. 2012b. Disponível em:
<http://docs.moodle.org/all/pt_br/Características_do_Moodle>. Acesso em: 10 out. 2012.
MOOSHAK. About. 2012. Disponível em: <http://mooshak.dcc.fc.up.pt/~zp/mooshak/>.
Acesso em: 12 set. 2012.
ONLINE COMPILER.2012. Disponível em: < http://www.onlinecompiler.net>. Acesso em:
12 set. 2012.
PC2. Welcome to the PC2 home page!. 2012. Disponível em: <
http://www.ecs.csus.edu/pc2 >.
Acesso em: 12 set. 2012a
PC2. An overview of PC2. 2012. Disponível em: <
http://www.ecs.csus.edu/pc2/pc2desc.html >.
Acesso em: 12 set. 2012b.
PC2. Contest administrator’s installation and configuration guide.2012. Disponível em:
<http://www.ecs.csus.edu/pc2/doc/v9/pc2v9AdminGuide.pdf>. Acesso em: 12 set. 2012c.
PC2. PC2 FAQ and troubleshooting guide. 2012. Disponível em:
<http://www.ecs.csus.edu/pc2/doc/faq/index.html#GETSOURCEFAQ>. Acesso em: 14 set.
2012d.
POSTGRESQL. PostgreSQL 9.2.4 Documentação.2013.Disponível em:
<http://www.postgresql.org/docs/9.2/static/dblink.html>. Acesso em: 29 maio 2013.
PY I/O.2012. Disponível em: < http://py-ide-online.appspot.com/>. Acesso em: 14 set. 2012.
RAPKIEWICZ, Clevi Elena et al. Estratégias pedagógicas no ensino de algoritmos e
Programação associadas ao uso de jogos educacionais. 2006. Disponível em:
<http://seer.ufrgs.br/renote/article/view/14284/8203>. Acesso em: 19 ago. 2012.
RODRIGUES JÚNIOR, Methanias Colaço. Experiências Positivas para o Ensino de
Algoritmos. 2004. Disponível
em:<http://www.uefs.br/erbase2004/documentos/weibase/Weibase2004Artigo001.pdf>.
Acesso em: 18 ago. 2012.
64
SANTOS NETO, Bernardo Lobato dos. Proposta de um laboratório virtual para aprendizagem
de prolog. 2007. Disponível
em:<http://www.portaltcc.icen.ufpa.br/portaltcc/principal/Tcc/action.do;jsessionid=B1899088
079A97FB8B03CFF4DB5093C7?act=download&id=106>. Acesso em: 02 set. 2012.
SIEBRA, Sandra de Albuquerque; SILVA, Danielle Rousy D. da. Prática de Ensino de
algoritmos. 2009. Disponível em: < http://www.slideshare.net/aej400aej/prtica-de-ensino-de-
algoritmo-volume-1-e-2>. Acesso em: 27 ago. 2012.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de
dados. Rio de Janeiro: Elsevier. 2006.
SMANIOTO, Carlos Eduardo. Consultas remotas no PostgreSQL. Artigo da SQL Magazine,
v.34, n.3.2006. Disponivel em: < http://www.devmedia.com.br/artigo-da-sql-magazine-34-
consultas-remotas-no-postgresql/6768>. Acesso em: 10 maio 2013.
SOAP. SOAP Introduction. 2012 Disponível em:
<http://www.w3schools.com/soap/soap_intro.asp>. Acesso em: 23 out. 2012.
SOMERVILLE, I. Engenharia de software. 6.ed. São Paulo: Addison-Wesley, 2003.
SOUZA, Allan de. Adaptação de um corretor automático de código para auxílio da atividade
de exercício e prática no ensino de programação. 2009. Disponível
em:<http://www.pergamum.udesc.br/dados-bu/000000/00000000000D/00000D51.pdf>.
Acesso em: 27 ago. 2012.
SOUZA, Marco Antonio Furlan de et. al. Algoritmos e lógica de programação. São Paulo:
Thomson. 2005.
65
APÊNDICE A. FUNÇÕES DO DBLINK
Segundo POSTGRESQL(2013),o conjunto de funções que compõem o Dblink são:
dblink_connect - abre uma conexão persistente com um banco de dados
remoto
dblink_connect_u - abre uma conexão persistente com um banco de dados
remoto, insegura
dblink_disconnect - fecha uma conexão persistente com um banco de dados
remoto
dblink - executa uma consulta em um banco de dados remoto
dblink_exec - executa um comando em um banco de dados remoto
dblink_open - abre um cursor em um banco de dados remoto
dblink_fetch - retorna linhas de um cursor aberto em um banco de dados
remoto
dblink_close - fecha um cursor em um banco de dados remoto
dblink_get_connections - retorna os nomes de todas as conexões dblink
nomeado aberto
dblink_error_message - recebe última mensagem de erro na conexão chamada
dblink_send_query - envia uma consulta assíncrona para um banco de dados
remoto
dblink_is_busy - verifica se a conexão está ocupada com uma consulta
assíncrona
dblink_get_notify - recuperar as notificações assíncronas em uma conexão
dblink_get_result - recebe um resultado de consulta assíncrona
dblink_cancel_query - cancela qualquer consulta ativa na conexão chamada
dblink_get_pkey - retorna as posições e nomes de campos de campos de chave
primária de uma relação
dblink_build_sql_insert - constrói uma instrução INSERT usando uma tupla
local, substituindo os valores de campo de chave primária com valores
fornecidos alternativas
dblink_build_sql_delete - constrói uma instrução DELETE utilizando valores
fornecidos para valores de campo de chave primária
66
dblink_build_sql_update - constrói uma instrução UPDATE utilizando uma
tupla local, substituindo os valores de campo de chave primária com valores
fornecidos alternativas
Para a utilização do Dblink, foi necessário criar as funções, nos dois bancos de dados,
tanto o do ambiente Moodle, quanto para o BOCA. Segundo, CICALA (2013), a seguir são
apresentadas as funções de criação:
SET search_path = public;
CREATE OR REPLACE FUNCTION dblink_connect (text)
RETURNS text
AS '$libdir/dblink','dblink_connect'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_connect (text, text)
RETURNS text
AS '$libdir/dblink','dblink_connect'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_connect_u (text)
RETURNS text
AS '$libdir/dblink','dblink_connect'
LANGUAGE C STRICT SECURITY DEFINER;
CREATE OR REPLACE FUNCTION dblink_connect_u (text, text)
RETURNS text
AS '$libdir/dblink','dblink_connect'
LANGUAGE C STRICT SECURITY DEFINER;
REVOKE ALL ON FUNCTION dblink_connect_u (text) FROM public;
REVOKE ALL ON FUNCTION dblink_connect_u (text, text) FROM public;
CREATE OR REPLACE FUNCTION dblink_disconnect ()
RETURNS text
AS '$libdir/dblink','dblink_disconnect'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_disconnect (text)
RETURNS text
AS '$libdir/dblink','dblink_disconnect'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_open (text, text)
RETURNS text
AS '$libdir/dblink','dblink_open'
67
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_open (text, text, boolean)
RETURNS text
AS '$libdir/dblink','dblink_open'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_open (text, text, text)
RETURNS text
AS '$libdir/dblink','dblink_open'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_open (text, text, text, boolean)
RETURNS text
AS '$libdir/dblink','dblink_open'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_fetch (text, int)
RETURNS setof record
AS '$libdir/dblink','dblink_fetch'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_fetch (text, int, boolean)
RETURNS setof record
AS '$libdir/dblink','dblink_fetch'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_fetch (text, text, int)
RETURNS setof record
AS '$libdir/dblink','dblink_fetch'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_fetch (text, text, int, boolean)
RETURNS setof record
AS '$libdir/dblink','dblink_fetch'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_close (text)
RETURNS text
AS '$libdir/dblink','dblink_close'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_close (text, boolean)
RETURNS text
AS '$libdir/dblink','dblink_close'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_close (text, text)
RETURNS text
AS '$libdir/dblink','dblink_close'
68
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_close (text, text, boolean)
RETURNS text
AS '$libdir/dblink','dblink_close'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink (text, text)
RETURNS setof record
AS '$libdir/dblink','dblink_record'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink (text, text, boolean)
RETURNS setof record
AS '$libdir/dblink','dblink_record'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink (text)
RETURNS setof record
AS '$libdir/dblink','dblink_record'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink (text, boolean)
RETURNS setof record
AS '$libdir/dblink','dblink_record'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_exec (text, text)
RETURNS text
AS '$libdir/dblink','dblink_exec'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_exec (text, text, boolean)
RETURNS text
AS '$libdir/dblink','dblink_exec'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_exec (text)
RETURNS text
AS '$libdir/dblink','dblink_exec'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_exec (text,boolean)
RETURNS text
AS '$libdir/dblink','dblink_exec'
LANGUAGE C STRICT;
CREATE TYPE dblink_pkey_results AS (position int, colname text);
CREATE OR REPLACE FUNCTION dblink_get_pkey (text)
69
RETURNS setof dblink_pkey_results
AS '$libdir/dblink','dblink_get_pkey'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_build_sql_insert (text, int2vector, int, _text,
_text)
RETURNS text
AS '$libdir/dblink','dblink_build_sql_insert'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_build_sql_delete (text, int2vector, int, _text)
RETURNS text
AS '$libdir/dblink','dblink_build_sql_delete'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_build_sql_update (text, int2vector, int, _text,
_text)
RETURNS text
AS '$libdir/dblink','dblink_build_sql_update'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_current_query ()
RETURNS text
AS '$libdir/dblink','dblink_current_query'
LANGUAGE C;
CREATE OR REPLACE FUNCTION dblink_send_query(text, text)
RETURNS int4
AS '$libdir/dblink', 'dblink_send_query'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_is_busy(text)
RETURNS int4
AS '$libdir/dblink', 'dblink_is_busy'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_get_result(text)
RETURNS SETOF record
AS '$libdir/dblink', 'dblink_get_result'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_get_result(text, bool)
RETURNS SETOF record
AS '$libdir/dblink', 'dblink_get_result'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_get_connections()
RETURNS text[]
AS '$libdir/dblink', 'dblink_get_connections'
LANGUAGE C;
70
CREATE OR REPLACE FUNCTION dblink_cancel_query(text)
RETURNS text
AS '$libdir/dblink', 'dblink_cancel_query'
LANGUAGE C STRICT;
CREATE OR REPLACE FUNCTION dblink_error_message(text)
RETURNS text
AS '$libdir/dblink', 'dblink_error_message'
LANGUAGE C STRICT;
71
APÊNDICE B. FUNÇÕES COMENTADAS DAS CLASSES
TESTE.PHP E RENDERER.PHP
Classe teste.php
<?php
$idquestion = $_POST['id'];
$linguagem = $_POST['args'];
$bodyquestion = $_POST['save'];
//Cria o arquivo de input com resposta do aluno
$fopenaluno=fopen('/home/rafael/moodledata/temp/'$idquestion.$lingu
agem, "w+");
if ($fopenaluno == false) die('Não foi possível criar o arquivo de
entrada.');
// Escreve no arquivo
//Utilizacao do stripslashes devido a utilizacao
//da funcao do escape do javascript no renderer.php
if (!fwrite($fopenaluno, stripslashes($_POST['save']))) die('Não foi
possível escrever.');
//Libera o arquivo
fclose($fopenaluno);
// Dados do servidor
$servidor = '200.XXX.XX.XX'; // Endereço
$usuario = 'XXXXX'; // Usuário
$senha = 'XXXXX'; // Senha
// Abre a conexão com o servidor FTP
$ftp = ftp_connect($servidor); // Retorno: true ou false
if ($login == true) die('conectou.');
// Faz o login no servidor FTP
$login = ftp_login($ftp, $usuario, $senha); // Retorno: true ou
false
if ($login == false) die('Não foi possível abrir uma conexao.');
// Define variáveis para o envio de arquivo
$local_arquivo='/home/rafael/moodledata/temp/'$idquestion.$linguage
m; // Localização (local)
$ftp_pasta = '/home/icpcadmin/Public/'; // Pasta (externa)
$ftp_arquivo = $idquestion.$linguagem; // Nome do arquivo (externo)
// Envia o arquivo pelo FTP em modo ASCII
$envio = ftp_put($ftp, $ftp_pasta.$ftp_arquivo, $local_arquivo,
FTP_BINARY); // Retorno: true / false
if ($envio == false) die('Não foi possível enviar o arquivo pelo
FTP.');
72
echo("Arquivo Salvo, não esqueça de clicar em proximo para o
envio");
?>
Função javascript da Classe renderer.php
//Utilizacao da funcao escape pois o javascript interpreta o & como outra
variavel e não como parte do codigo.
$batata = "
function testeAjax()
{
var bodyquestion = document.getElementById('" . $inputname .
"');
var idquestion = document.getElementById('idquestao');
var linguagemprog =
document.getElementById('linguagemprog');
var userid = document.getElementById('idusuario');
YUI().use('io-base', function(Y)
{
var config = {
method: 'POST',
data: 'save=' + escape(bodyquestion.value) +
'&id=' + idquestion.value + '&args=' + linguagemprog.value + '&usuarioid='
+ userid.value ,
on:
{
success: function(id, o, args)
{
window.alert(o.responseText);
},
failure: function (id, o, args)
{
window.alert('fudeu');
}
}
}
Y.io('".new moodle_url($CFG->wwwroot .
'/question/type/juiz/teste.php')."', config);
});
}";
