TCC Final Matheusdemetrio Revisado
TCC Final Matheusdemetrio Revisado
TCC Final Matheusdemetrio Revisado
Florianópolis – SC
2017/2
1
UFSC
Florianópolis
2
Orientador(a):
Prof. Dr. rer. nat. Christiane A. Gresse von Wangenheim, PMP
________________________________________________
Co-Orientador(a):
Prof. Dr. Jean C. R. Hauck
________________________________________________
Banca examinadora:
Giselle Araújo e S. de Medeiros
________________________________________________
3
RESUMO
LISTA DE FIGURAS
LISTA DE TABELAS
SUMÁRIO
1. INTRODUÇÃO .......................................................................................................7
1.1 CONTEXTUALIZAÇÃO ..........................................................................................7
1.2 OBJETIVOS ...........................................................................................................9
1.3 METODOLOGIA DE PESQUISA ..........................................................................10
1.4 ESTRUTURA DESTE DOCUMENTO...................................................................12
2. FUNDAMENTAÇÃO TEÓRICA ............................................................................13
2.1 APRENDIZAGEM E ENSINO ...............................................................................13
2.2 ENSINO DE COMPUTAÇÃO NO ENSINO FUNDAMENTAL II ............................16
2.3 ANÁLISE E AVALIAÇÃO DE CÓDIGO.................................................................21
2.3.1 ANÁLISE DE CÓDIGO APLICADA À EDUCAÇÃO ..............................................25
2.3 APP INVENTOR...................................................................................................27
3. ESTADO DA ARTE ..............................................................................................35
3.1 DEFINIÇÃO DO PROTOCOLO DE REVISÃO .....................................................35
3.2 EXECUÇÃO DA BUSCA ......................................................................................37
3.3 ANALISE DOS TRABALHOS ENCONTRADOS ...................................................39
3.3.1 DR. SCRATCH .....................................................................................................39
3.3.2 NINJA CODE VILLAGE FOR SCRATCH .............................................................42
3.4 DISCUSSÃO ........................................................................................................45
3.4.1 AMEAÇAS A VALIDADE DO MAPEAMENTO SISTEMÁTICO .............................46
4. DESENVOLVIMENTO DO CODEMASTER – APP INVENTOR ...........................48
4.1 MODELO CONCEITUAL ......................................................................................48
4.2 ANÁLISE DOS REQUISITOS ...............................................................................52
4.2.1 REQUISITOS FUNCIONAIS ................................................................................52
4.2.2 REQUISITOS NÃO-FUNCIONAIS ........................................................................54
4.3 CASOS DE USO ..................................................................................................55
4.4 MODELAGEM E IMPLEMENTAÇÃO DO CODEMASTER ...................................58
4.4.1 ARQUITETURA DO MÓDULO DE AVALIAÇÂO ..................................................59
4.4.2 ARQUITETURA DO MÓDULO DE APRESENTAÇÃO .........................................63
4.4.3 TESTES DE UNIDADE DO SOFTWARE .............................................................68
4.4.4 EXPANDINDO O CODEMASTER ........................................................................69
4.4.5 DESIGN DE INTERFACE DO CODEMASTER ....................................................71
5. AVALIAÇÃO DO CODEMASTER – APP INVENTOR...........................................78
5.2 AVALIAÇÃO DA CORRETUDE ............................................................................78
5.2.1 EXECUÇÃO DA AVALIAÇÃO DA CORRETUDE .................................................78
5.3 AVALIAÇÃO POR USUÁRIOS .............................................................................82
5.3.1 DEFINIÇÃO DA AVALIAÇÃO POR USUÁRIOS ...................................................82
5.3.2 EXECUÇÃO DA AVALIAÇÃO POR USUÁRIOS ..................................................83
5.3.3 ANÁLISE DOS DADOS ........................................................................................85
6. CONCLUSÃO.......................................................................................................91
REFERÊNCIAS ....................................................................................................................93
7
1. INTRODUÇÃO
1.1 CONTEXTUALIZAÇÃO
Os computadores transformaram completamente o mundo e o mercado de
trabalho (MERCADO, 2002). Juntamente com estas mudanças, a computação e as
tecnologias advindas delas fazem parte do coração da economia mundial e do modo
de vida das pessoas. Atualmente todos os estudantes possuirão uma vida altamente
influenciada pela computação e muitos trabalharão em áreas em que a computação
está diretamente envolvida (CSTA, 2011). A computação é a busca por soluções para
um determinado problema, dada uma determinada entrada, obter um resultado por
meio de um algoritmo. Ela envolve o entendimento, o desenvolvimento e projeto de
computadores, assim como processos computacionais (CSTA, 2011).
Portanto todos os cidadãos devem possuir um entendimento básico sobre os
princípios e práticas da computação, podendo se tornar criadores de sistemas
computacionais e também consumidores mais competitivos e produtivos (CSTA,
2011).
A falta de incentivo no ensino da computação nas escolas de ensino básico
acarreta em dois principais problemas: o não despertar do interesse dos jovens pela
área da computação e o não mostrar o que realmente é ensinado nos cursos
superiores para atrair o público alvo correto. Isso acaba gerando um outro grande
problema, carência de mão-de-obra qualificada nas empresas de Tecnologia da
Informação e Comunicação (ACATE, 2012). Além de influenciar os cidadãos que
precisam deste conhecimento nas suas vidas profissionais e pessoais.
Por esses motivos é importante que o ensino da computação seja incluído no
Ensino Básico, contribuindo desta maneira na popularização da computação na
sociedade em geral. Contudo, isso atualmente não acontece, geralmente não é dada
a mesma atenção a computação quanto a outras disciplinas clássicas. Mesmo
abordando o ensino do uso de TI (p.ex. o uso de editores de texto, editores de imagem,
etc.) atualmente, na maioria dos casos, não se ensina o pensamento computacional,
abordando conceitos como a representação de dados, criação de algoritmos e análise,
examinação de diferentes algoritmos baseando-se em outras estratégias de solução,
que são conceitos dos quais devem ser ensinados já aos alunos no Ensino Básico
(CSTA, 2011).
8
Por outro lado, os alunos do ensino básico já possuem uma interação muito
forte com os dispositivos existentes, como smartphones, tablets e computadores.
Cerca de 82% das crianças do Brasil acessam a internet de dispositivos móveis
(BARBOSA, 2015), facilitando algumas iniciativas existentes focadas em levar o
ensino da computação para crianças do mundo inteiro (HOUR OF CODE, 2016)
(COMPUTAÇÂO NA ESCOLA, 2016). Portanto, deve-se usar isto em benefício do
ensino, usar os dispositivos que fazem parte do seu dia a dia, que os alunos já estão
acostumados, e focar o ensino de computação por meio do desenvolvimento de
aplicativos móveis.
Isto pode ser feito utilizando o App Inventor. O App Inventor (APP INVENTOR,
2016) é um ambiente de programação visual baseado em blocos que permite que
qualquer pessoa, inclusive crianças, comecem a programar e construir aplicativos
completos para dispositivos Android. Para a programação destes aplicativos os alunos
aprendem a usar diversos tipos de comandos como laços, condicionais e
procedimentos, iguais aos usados na programação convencional por texto, e então,
indiretamente, o pensamento computacional.
Porém, mesmo com a disponibilidade aberta do App Inventor, a programação
de apps ainda não é ensinada amplamente nas escolas. Uma das barreiras à
integração do ensino de computação nas escolas é a falta de ferramentas que dão
suporte aos professores na avaliação de trabalhos práticos de programação dos
estudantes (MORENO-LEÓN et al., 2015). Esta situação se agrava ainda, pelo fato
de que atualmente existe uma falta de professores do Ensino Básico com formação
para o ensino de computação, sendo ensinada, tipicamente, por professores de outras
disciplinas, como história por exemplo, de forma interdisciplinar.
Levando em consideração especialmente a falta de formação dos professores
do Ensino Básico, a avaliação dos programas de aplicativos desenvolvidos pelos
alunos representa uma atividade complexa e de um esforço considerável para os
professores (ESERYEL et al., 2013). Nesta situação, um avaliador automático de
código que permite uma análise e avaliação automatizada do código desenvolvido
pelos alunos pode facilitar esta parte, reduzindo a necessidade de competências
específicas do professor e também reduzindo o esforço necessário para analisar todos
os programas desenvolvidos pelos alunos. Uma análise automatizada pode também
aumentar a objetividade e eliminar qualquer favoritismo ou inconsistência (ZEN et al.,
2011).
9
1.2 OBJETIVOS
OBJETIVO GERAL
O trabalho tem como objetivo desenvolver uma ferramenta web para analisar e
avaliar código desenvolvido no App Inventor, a ser utilizado para avaliar trabalhos
práticos no ensino de programação de aplicativos móveis no Ensino Básico (no Ensino
Fundamental II focando em jovens de 11 a 14 anos de idade) alinhado à referência de
curriculo (CSTA, 2016).
OBJETIVOS ESPECÍFICOS
Os objetivos específicos são:
O1. Sintetizar a fundamentação teórica sobre aprendizagem e ensino de computação
no Ensino Básico, o ambiente App Inventor, a análise de código e avaliação no
processo de ensino.
O2. Analisar o estado da arte sobre analisadores de código referentes a linguagens
de programação baseada em blocos.
O3. Desenvolver uma ferramenta web para a análise de código desenvolvido no App
Inventor.
O4. Aplicar e avaliar a ferramenta desenvolvida na prática.
em parceria com Pelle (2018) a integração dos analisadores de App Inventor e Snap!
e a estrutura de servidor. Na quarta iteração a interface gráfica é desenvolvida em
parceria com os bolsistas da iniciativa Computação na Escola, incluindo pesquisas
sobre a interface gráfica com o público alvo. Por último são feitos os testes no sistema
e aplicada possíveis correções e ajustes.
A3.1 - Análise de requisitos e modelagem da arquitetura do sistema.
A3.2 – Modelagem baixo nível e implementação do analisador e avaliador de códigos
do App Inventor.
A3.3 – Modelagem baixo nível e implementação da estrutura de serviços do servidor
e integração dos analisadores.
A3.4 – Desenvolvimento da interface gráfica do sistema.
A3.5 - Testes do sistema.
2. FUNDAMENTAÇÃO TEÓRICA
1
ADDIE é um acrônimo para Analyze, Design, Develop, Implement e Evaluate.
15
vários tipos de avaliações que podem ser feitas para medir o desempenho que o aluno
atinge na aprendizagem (CORTESÃO, 2002). As avaliações podem ser provas (tanto
escritas como orais), exercícios, trabalhos práticos, seminários, etc. As provas têm o
objetivo de serem mais pontuais naquilo que querem avaliar, geralmente avaliando a
parte mais teórica da aprendizagem, aumentando a precisão das medidas
educacionais (HAYDT, 1988). Os trabalhos práticos abrangem mais o nível de
aprendizagem de aplicação, e avaliam com mais foco a parte prática da
aprendizagem.
No ensino da computação, é possível inferir as competências adquiridas
durante o processo de aprendizagem por meio da análise/avaliação de trabalhos
práticos de programação. Nos trabalhos é possível identificar se os alunos têm
capacidade de colocar em prática os conceitos teóricos, mostrando habilidade em
organizar, sintetizar e aplicar a informação e a competência adquirida, e a habilidade
em gerenciar os recursos disponíveis (MORENO-LEÓN et al., 2015).
Porém, a análise destes trabalhos práticos na avaliação, tipicamente, requer
um esforço considerável e competência do professor na área de conhecimento
(MEDEIROS, 1974).
(PCNs) que formam uma base comum para os currículos nacionais. De acordo com
as PCNs, os professores devem orientar os seus alunos do 6º ao 9º ano de forma
clara e objetiva, adequando o ensino aos ideais de democracia e buscando a melhoria
da qualidade do ensino nas escolas brasileiras (OLIVEIRA, 2013). Além disso a PCN
“[...] buscará eleger, como objeto de ensino, conteúdos que estejam em consonância
com as questões sociais que marcam cada momento histórico” (PCN, 1998). As
disciplinas que as PCNs abrangem são: Língua Portuguesa, Matemática, Ciências
Naturais, Geografia, História, Arte, Educação Física, Língua Estrangeira e temas
adicionais como Pluralidade Cultural, Meio Ambiente, Saúde e Orientação Sexual.
Contudo, a computação é tratada como ensino de informática, resumindo-se ao
ensino do uso de ferramentas básicas para dar apoio a informatização das demais
disciplinas.
Porém, de acordo com a Sociedade Brasileira de Computação é importante que
a computação seja inserida no contexto do ensino fundamental:
“É importante salientar que devemos primar pela qualidade do
ensino em todos os níveis da cadeia de formação de recursos
humanos. Entendemos que a Computação deva ser ensinada desde
o ensino fundamental, a exemplo de outras ciências como Física,
Matemática, Química e Biologia. Esses são pontos muito importantes
para que no futuro tenhamos recursos humanos qualificados para
enfrentar os desafios que advirão (SBC, 2015).”
Com estes objetivos alcançados os alunos já terão uma noção clara e objetiva
do que é a área da computação e além disso já terão competência computacional para
qualquer área do conhecimento da vida profissional.
Computação no Ensino Básico é muitas vezes ensinada por meio de unidades
instrucionais que ensinam a programação de código (WING, 2006). Neste contexto,
pode se identificar diferentes tipos de ensino de programação. Uma forma de ensino
guia o aluno a executar exercícios de programação predefinidos, como por exemplo
completar um trecho de código faltante. Geralmente esses exercícios tem apenas uma
resposta correta e, portanto, a análise e avaliação do mesmo refere-se apenas a uma
comparação com um gabarito.
Muitas atividades de computação focam na criação de soluções para
problemas do mundo real, em que as soluções são artefatos de software, como por
exemplo, jogos, animações ou até mesmo apps para celulares para solucionar
problemas da comunidade. Essas atividades de computação estão ligadas a
21
A análise de código também pode ser usada para outras finalidades, como a
análise da qualidade do código desenvolvido (YULIANTO et al., 2014). Neste caso,
podendo ser dividida em dois tipos de análise: a estática e a dinâmica (YULIANTO et
al., 2014). A análise estática analisa o código fonte sem a necessidade de executar a
aplicação e é usada para detectar problemas no código, incluindo potenciais bugs,
complexidade desnecessária e partes de código que necessitam manutenção. Neste
caso é incluída a analise sintática, léxica e semântica.
A análise dinâmica analisa os erros gerados em tempo de execução da
aplicação e ajuda a avaliar a corretude da aplicação, ou seja, verifica se a aplicação
realmente resolve o problema proposto e está de acordo com sua especificação
(TRUONG et al., 2004).
O foco do presente trabalho está voltado a análise estática, já que por meio
dela também pode-se analisar a qualidade do código no contexto do ensino.
A análise estática é um método de aferição do programa desenvolvido
examinando o código fonte sem a necessidade de executar o programa (ROUSE,
2006). Esse processo fornece a compreensão da estrutura do código e ajuda a
verificar se o código adere as normas industriais, mundiais, de mercado ou até mesmo
de ensino (ROUSE, 2006).
Os analisadores estáticos de código podem ajudar programadores,
desenvolvedores, ou instrutores a fazer uma análise estática de código, permitindo
assim que se possa encontrar erros que não se manifestam ou permitindo avaliar um
determinado código (ROUSE, 2006). Analisadores estáticos são ferramentas de
software que varrem o código fonte (SOMMERVILLE, 2007) e são as ferramentas
mais comuns para analisar e avaliar de forma automática os trabalhos práticos de
programação (STRIEWE et al., 2014), sendo o foco do presente trabalho.
23
Figura 5 - Visão do fluxo do verificador adaptado voltado ao ensino (Sinthsirimana et al., 2013)
O verificador pode ser dividido em partes, cada parte fica responsável por uma
tarefa ou um pequeno conjunto de tarefas. O verificador recebe como entrada a
estrutura de dados gerada pelo parser que é o código fonte estruturado:
• Compartilhamento de dados;
• Uso de serviços web públicos;
• Uso de acelerômetro e sensores de orientação;
• Reconhecimento de localização.
Existem muitas linguagens de programação hoje em dia, cada uma com suas
peculiaridades e objetivos (IEEE, 2016). A maior parte das linguagens de
programação hoje utilizadas no desenvolvimento profissional são linguagens de
programação textual. Porém, com o objetivo de engajar crianças e jovens na área da
computação e para facilitar a aprendizagem de computação nesta faixa etária, são
indicados o uso de linguagens de programação visuais (RESNICK et al., 2009).
Linguagens de programação visuais baseado em blocos permitem criar
sistemas de software ou aplicativos arrastando e encaixando blocos. Nas linguagens
visuais todos os componentes das linguagens já estão definidos, normalmente, em
forma de figuras ou blocos, o usuário deverá colocar esses blocos numa ordem que
faça sentido ao programa e então a aplicação começa a ser programada. Desta
maneira ele não precisará escrever linhas de código textuais, eliminando a
necessidade de se entender e memorizar as complexas sintaxes de linguagens
textuais.
28
Interface de Botão; Caixa de Seleção; Escolhe Data; Criação da parte visual do app.
Usuário Imagem; Legenda; Escolhe Lista; Todos os elementos visíveis da
Visualizador de Listas; Notificador; aplicação ficam neste grupo.
Caixa de Senha; Deslizador; Lista
Suspensa; Caixa de Texto; Escolhe
Hora; Navegador Web.
Organização Organização Horizontal; Horizontal Auxilia na organização dos
Scroll Arrangement; Organização em elementos visíveis do grupo de
interface com usuário.
30
Bloco Descrição
If e if else Testa uma condição dada. Se a condição for verdadeira,
executa uma sequência de blocos, senão, ignora esta
sequência de blocos.
For each – from – to Executa os blocos na seção para cada valor numérico no
intervalo - a partir de – e - terminando em -, incrementando o
número a cada vez executado.
For each list item Executa uma sequência de blocos para cada item de uma lista.
While Testa uma condição repetidas vezes, enquanto for verdadeira
executa uma sequência de blocos.
If then else Testa uma condição, se for verdadeira, executa os blocos do
then, se for falsa, executa os blocos do else.
Do Executa um bloco e retorna um resultado.
Evaluate but ignore result Usado como bloco fictício, o bloco em que este esteja
conectado será executado, mas seu retorno será ignorado.
Open another screen Abre uma tela com o nome dado.
Open another screen with start Abre uma tela com o nome e um valor passado.
value
Get start value Retorna o valor atual dado a uma tela.
Close screen Fecha a tela atual.
Close screen with value Fecha a tela atual e retorna o valor passado a ela.
Close application Fecha a aplicação.
Get plain start text Retorna o texto que foi passado a tela quando foi iniciada por
outro app.
Close screen with plain text Fecha a tela e passa o texto ao app que iniciou ela.
Bloco Descrição
Bloco Descrição
Basic number block Representa qualquer número positivo ou negativo.
=, ≠, >, ≥, <, ≤ Blocos com as operações de igualdade ou desigualdade.
Min, max Retorna o maior ou menor valor.
Sqrt, abs, -, log, e^, round, ceiling, Operações unárias padrões.
floor
Modulo of, remainder of, quotient if Operações de módulo, resto e quociente.
Sin, cos, tan, asin, acos, atan Operações trigonométricas.
Convert radians to degrees, Conversão de graus em radianos e radianos em graus.
convert degrees to radians
+, -, *, / Operações de soma, subtração, multiplicação e divisão.
Integer random Retorna número inteiro entre valores passados.
Random fraction Retorna uma fração randômica.
Random set seed to Define a semente para a geração de números randômicos.
Format as decimal Formata um número decimal em uma quantidade de casas
decimais definidas.
Is a number? Retorna verdadeiro se o objeto passado é um número.
Convert number Converte um número em binário, hexadecimal ou decimal.
Bloco Descrição
String “” Contém um texto (string)
Join Concatena strings.
length Retorna quantidade de caracteres da string.
Is empty Retorna verdadeiro se a string não contém caracteres.
compare texts < > = Compara strings, se é “maior” ou “menor” alfabeticamente, ou string igual.
Trim Remove qualquer espaço que exista na string e retorna.
Upcase Retorna a string passada formatada em letras maiúsculas.
Downcase Retorna a string passada formatada em letras minúsculas.
33
Bloco Descrição
Create empty list Cria uma lista vazia.
Make a list Cria uma lista a partir dos blocos definidos, se não definir blocos, cria uma
lista vazia.
Add items to list Adiciona itens ao final da lista.
Is in list? Retorna verdadeiro se o elemento está na lista.
Length of list Retorna a quantidade de itens na lista.
Is list empty? Retorna verdadeiro se a lista está vazia.
Pick a random item Obtém um item qualquer da lista.
Index in list Retorna a posição que determinado item está na lista.
Select list item Seleciona o item que está em determinada posição na lista.
Insert list item Insere item na lista na posição informada.
Replace list item Substitui item da lista por novo na posição informada.
Remove list item Remove item da lista na posição informada.
Append to list Adiciona itens da segunda lista no final da primeira.
Copy list Faz uma cópia da lista incluindo sublistas.
Is a list? Retorna verdadeiro se o objeto é uma lista.
List to csv row Interpreta a lista como uma linha e retorna um arquivo CSV.
List from csv row Captura um texto em CSV formatado em uma linha e cria uma lista.
List to csv table Interpreta a lista como uma tabela e retorna um arquivo CSV.
List from csv table Captura um texto em CSV formatado em uma tabela e cria uma lista.
Lookup in pairs Usado para pesquisar informações em uma estrutura em pares parecida
com um dicionário.
Cores: Componentes responsáveis por determinar as cores do aplicativo, podendo
ser utilizadas cores padrões ou cores personalizadas pelo desenvolvedor.
Tabela 8 - Blocos de Cores
Bloco Descrição
Basic color blocks Bloco de cores básicas.
Make color Recebe uma lista de 3 ou 4 valores que representam o valor RGB
ou RGBA da cor.
34
Bloco Descrição
Initialize global name to Usado para criar uma variável global definindo um
nome.
Get Uma forma de obter qualquer variável que tenha sido
criada no escopo atual.
Set to Uma forma de atribuir um valor a uma variável criada.
Initialize Local name to - in (do) Permite a criação de uma variável que será usada
apenas no DO de um método.
Initialize Local name to - in (return) Permite a criação de uma variável que será usada
apenas no RETURN de um método.
Bloco Descrição
Procedure do Agrupa uma sequência de blocos e não retorna uma
resposta ao final da sua execução.
Procedure result Agrupa uma sequência de blocos e retorna uma
resposta ao final da sua execução.
3. ESTADO DA ARTE
Questão de Pesquisa. Esse estudo tem como questão central de pesquisa a seguinte
pergunta: “Quais analisadores estáticos de código existem para análise de código de
linguagens de programação visuais no contexto de ensino de programação no Ensino
Fundamental II?”
Bases de pesquisa. Para uma ampla busca nas bases de dados digitais na área do
presente trabalho, são buscados artigos científicos publicados entre os anos de 2010
(data do lançamento da primeira versão do App Inventor) e 2016 em Português e
Inglês. Por meio do portal CAPES2 as fontes para a realização da busca são:
• IEEE Xplore3
• ACM Digital Library4
• ScienceDirect5
• Springer6
• Wiley7
De acordo com a sintaxe de cada uma desta base são definidas as strings de busca
de cada base.
2
Portal desenvolvido pelo Ministério da Educação, onde é possível encontrar artigos científicos de
relevância - https://www.capes.gov.br/
3
http://ieeexplore.ieee.org/
4
http://portal.acm.org
5
http://www.sciencedirect.com
6
http://link.springer.com/
7
http://www.wiley.com/
8
https://scholar.google.com.br/
9
http://teach.appinventor.mit.edu/
37
ACM Digital Library (“code analyzer”) AND (“visual programming language” OR “block-based
languages” OR “App Inventor” OR “Scratch” OR “Blockly” OR “Snap!” OR
“App Lab”) AND (“learning”)
ScienceDirect (“Static code analyzer” OR “code analyzer” OR “Computer programming
analyzer”) AND (“visual programming language” OR “block-based
languages” OR “App Inventor” OR “Scratch” OR “Blockly” OR “Snap!” OR
“App Lab”) AND (“Education” OR “teaching” OR “learning”)
Springer (“code analyzer”) AND (“visual programming language” OR “block-based
languages” OR “App Inventor” OR “Scratch” OR “Blockly” OR “Snap!” OR
“App Lab”) AND (“education”)
Wiley (“code analyzer”) AND (“visual programming language” OR “block-based
languages” OR “App Inventor” OR “Scratch” OR “Blockly” OR “Snap!” OR
“App Lab”) AND (“learning”)
Google Scholar (“code analyzer”) AND (“visual programming language” OR “scratch”) AND
(“learning”)
App Inventor (“code analyzer”)
identificados cinco artigos potencialmente relevantes. Muitos dos artigos não incluídos
eram voltados a analisadores para atividades de programação especificas, fixas e pré-
definidas como por exemplo o Tynker, e consequentemente não foram levados em
consideração por não estarem alinhados ao critério de qualidade definido.
Vale ressaltar também que foi encontrado na base ACM um resumo de um
artigo (abstract) no qual o autor informa que está desenvolvendo um analisador de
código para Snap! (BALL & GARCIA, 2016). Porém, como no momento da busca não
foi encontrado um artigo completo ou mais informações sobre o andamento deste
projeto, o trabalho não foi incluído nesta revisão.
Após essa análise inicial, os artigos relevantes foram lidos na íntegra. Ao final
foram considerados apenas as ferramentas de análise estática de código para
linguagens de programação visuais no contexto de ensino que estivessem completas
e prontas para o uso de instrutores. Na Tabela 13 encontram-se os resultados da
busca.
Após terminada a análise é apresentada uma tela com informações sobre os conceitos
analisados bem como notas e um feedback, (Figura 9).
Além das notas, a partir das estatísticas geradas, o Ninja Code Village verifica
padrões no código e fornece uma lista de funções presentes em sua biblioteca, que
são semelhantes ao código analisado que podem servir como inspiração ao usuário
para melhorar ou expandir o seu código.
No Ninja Code Village não há a possibilidade de executar em modos de aluno
e instrutor e também não é possível gerenciar turmas de alunos.
44
3.4 DISCUSSÃO
Observa-se que analisadores estáticos de código para linguagens de
programação visuais no contexto de ensino estão quase inexistentes. Na pesquisa
englobando qualquer linguagem de programação visual foram encontrados somente
dois analisadores para Scratch, sendo que o HairBall (BOE, 2013) é uma API que está
englobado no Dr. Scratch. Foi encontrado também um resumo sobre um possível
analisador para Snap!, porém, sem maiores informações. Não foi encontrado nenhum
analisador estático de código para App Inventor, foco do presente trabalho. Portanto
é notável a carência de ferramentas de análise de código no contexto de ensino. De
forma geral, é perceptível algumas tendências sobre, principalmente, quais conceitos
do pensamento computacional são importantes serem analisados por analisadores de
código estáticos no contexto de ensino.
O CodeMaster deve avaliar, com base no Dr. Scratch (DR. SCRATCH, 2017), na
rubrica para avaliar apps proposta por Sherman (2015) e no framework do
pensamento computacional (BRENNAN & RESNICK, 2012), os conceitos do código
conforme apresentado na Tabela 18.
0 1 2 3
Telas Apenas uma tela Apenas uma tela Pelo menos duas 2 ou mais telas e
com componentes com componentes telas e uma delas pelo menos 2 delas
visuais e que seu visuais que se altera seu estado alteram seus estados
estado não se altera alteram com a com a execução com a execução do
com a execução do execução do app. do app. app.
app (tela
informativa).
Interface de Usuário Utiliza apenas 1 Utiliza 2 ou mais Utiliza mais de 5 Utiliza mais de 5
elemento visual elementos visuais elementos visuais elementos visuais
sem alinhamento. sem alinhamento. com 1 tipo de com 2 ou mais
alinhamento. elementos de
alinhamento.
Nomeação: Nenhum ou poucos De 10 a 25% dos De 26 a 75% dos Mais de 76% dos
Variáveis e procedimentos nomes são alterado nomes são nomes são nomes são alterados
do padrão. (menos alterados do alterados do do padrão.
do que 10%) padrão. padrão.
Laços Não usa laços Usa “While” (laço Usa “For each” Usa “For each” (item
simples) (variável simples) de lista)
Condicionais Não usa Usa apenas “if’s” Usa apenas “if Usa um ou mais “if -
condicionais. simples. then else”. else if”.
Operações Lógicas e Não usa operadores Usa um tipo de Usa dois tipos de Usa mais de 2 tipos
Matemáticas operador. operadores. de operadores.
50
Listas Não usa listas. Usa uma lista Usa mais de uma Usa uma lista de
unidimensional. lista tuplas (map).
unidimensional.
Persistência de dados Dados são Usa persistência Usa algum dos Usa uma base de
armazenados em em arquivo (File bancos de dados dados web
variáveis ou ou locais do App tinywebdb ou
propriedades de Fusion Inventor (TinyDB). Firebase do App
componentes e não Tables). Inventor (firebase ou
tem persistência TinyWebDB).
quando app é
fechado.
Sensores Sem uso de Usa um tipo de Usa 2 tipos de Usa mais de 2 tipos
sensores. sensor. sensores. de sensores.
Mídia Sem uso de mídias. Usa um tipo de Usa 2 tipos de Usa mais de 2 tipos
Mídia. Mídia. de mídia.
Desenho e Animação Sem uso de Uso de área Uso de animação Uso de animação
desenho e sensível ao toque. com bolinha pré- com imagem.
animação. definida.
Nota. Com base nos conceitos apresentados na Tabela 18, o CodeMaster apresenta
uma pontuação para cada critério. A nota final do projeto é definida numa escala de 0
a 10, alinhando a escala de notas tipicamente utilizados no ensino básico no Brasil.
Para se obter a nota final, é definida a seguinte fórmula:
Nível de competência. Para tornar essa nota mais divertida e agradável aos jovens,
o resultado é transformado na apresentação de nível de competência representado
por faixas de ninjas em cores diferentes. Cada faixa de valores de possíveis notas é
mapeado a cores de faixa de ninja, como mostrado na tabela 19.
51
Modo de uso. O CodeMaster tem dois modos de uso. No modo individual o aluno
submete seu próprio código à análise sem necessitar de cadastro. No modo individual,
o feedback inclui:
• A pontuação total e a nota (em termos numéricos e por meio da faixa do ninja
usando a imagem do ninja);
• A pontuação por critério de avaliação;
• A rubrica de avaliação.
As pontuações e nota dão ao aluno o feedback em termos da performance
atingida no desenvolvimento do projeto analisado. A rubrica deve ser utilizada para
guiar a melhoria da performance do aluno indicando como poderá melhorar a sua
pontuação nos diversos critérios analisados.
RF04 Realizar Parse do A ferramenta deve realizar o Lista de arquivos .bky. Lista de Document’s
Projeto App parse do(s) arquivo(s) .bky (representação interna de
Inventor encontrado(s) no RF03 código).
gerando uma estrutura de
código intermediária.
RF05 Analisar Projeto A ferramenta deve realizar a Lista de Document’s. Listas de cada tipo de elemento
App Inventor análise quantitativa dos do código definidos na análise
elementos definidos para cada de cada conceito
conceito conforme detalhada
na Tabela 17.
RF06 Avaliar Projeto A ferramenta deve avaliar Listas de cada tipo de Uma resposta de avaliação
App Inventor cada conceito citado na elemento do código. formada pela nota para cada
Tabela 17 de acordo com os conceito, um nível de
elementos especificados competência e um feedback.
encontrados no projeto App
Inventor e gerar uma nota para
cada conceito.
RF07 Apresentar A ferramenta deve apresentar Uma avaliação Interface de usuário exibe a
Avaliação do na interface de usuário a formada pela nota avaliação. Notas de cada
projeto App avaliação detalhada do seu para cada conceito. conceito, nota final e nível de
Inventor de forma projeto. Deve apresentar a competência.
detalhada nota de cada conceito
separadamente, bem como a
nota final e o nível de
competência do aluno e o
feedback
RF08 Apresentar A ferramenta deve apresentar Um conjunto de Interface de usuário exibe em
Avaliação dos na interface de usuário a avaliações cada uma tabela a nota de cada conceito,
projetos App avaliação de um conjunto de formada pela nota nota final e nível para cada
Inventor de forma projetos de forma resumida ao para cada conceito. avaliação do conjunto, Além de
resumida professor. uma média de todas as notas
finais de cada aluno e o total
dos projetos submetidos a
análise.
RF09 Realizar Cadastro A ferramenta deve permitir o Nome completo, e- Insere cadastro no banco de
de Professor cadastro de professor por mail, senha, dados. Interface de usuário
meio de sua interface Web. instituição, cidade, exibe mensagem de sucesso,
estado, país. ou mensagem de erro caso
algo dê errado.
RF10 Realizar Login de A ferramenta deve permitir que E-mail e senha. Redirecionado para página
Professor o professor autentique sua principal do professor ou
identidade por meio de login. interface com usuário exibe
mensagem de erro caso não
consiga autenticar.
RF11 Realizar Logout A ferramenta deve permitir que Login do professor na Encerramento da sessão atual
de Professor o professor encerre a sessão sessão atual. e redirecionamento para página
atual de autenticação de sua inicial da ferramenta.
identidade por meio de logout.
RF12 Manter Registro A ferramenta deve manter em Login do professor e Sistema armazena em seu
de Avaliações do seu banco de dados todos os projetos submetidos banco de dados todas as
Professor registros de avaliações feitas na sessão atual. avaliações de projetos que o
por professores por turma professor submeteu na sessão
atual.
RF13 Manter Registro A ferramenta deve manter em Projeto submetido por Sistema armazena em seu
de Avaliação de seu banco de dados o registro usuário anônimo. banco de dados toda avaliação
Usuário Anônimo de uma avaliação feita por de projeto que qualquer usuário
usuário anônimo. anônimo tenha submetido.
RF14 Apresentar todas A ferramenta deve apresentar Login do professor e Interface com usuário
Avaliações do em sua interface com o todas avaliações apresenta em tabela todas as
Professor presentes no banco de avaliações (notas de cada
54
ID Requisito Descrição
RNF01 Sistema Web A ferramenta deve ser acessada via navegador Web com conexão à
internet. Navegadores compatíveis: Google Chrome versão 56.0.2924.87;
Mozilla Firefox versão: 51.0.1; e Microsoft Edge versão 38.14393.0.0.
RNF02 Linguagem de A ferramenta deve ser desenvolvida na linguagem de programação Java,
Programação Java pois é uma linguagem muito conhecida facilitando a manutenção do
sistema por profissionais qualificados.
RNF03 Políticas de Privacidade O rodapé da interface do usuário da ferramenta deve conter as
informações de políticas de privacidade adotadas ou link para página que
contenha tais informações.
RNF04 Termos de Uso O rodapé da interface do usuário da ferramenta deve conter as
informações de termos de uso adotados ou link para página que contenha
tais informações.
RNF05 Usabilidade •Eficácia: 90% dos usuários da avaliação por painel de especialistas
devem conseguir completar a tarefa de analisar um ou múltiplos códigos
sem assistência.
•Satisfação: Pontuação total de SUS: 80 pontos.
RNF06 Identidade Visual da A interface de usuário deve ter padrões de identidade visual definidos pela
CnE Iniciativa Computação na Escola.
RNF07 Informação de A interface de usuário deve mostrar informação de progresso da análise
Progresso da Análise de projeto em execução.
RNF08 Desempenho A ferramenta deve analisar um conjunto de até 30 projetos em menos de
30 segundos num computador com no mínimo: processador com 2
núcleos e 2gb de ram; além de uma conexão de internet a cabo de pelo
menos 5mbps.
RNF09 Projeto App Inventor O sistema deve analisar projetos App Inventor da versão nb162a.
RNF10 Internacionalização O sistema deve conter a opção de textos em português e inglês.
RNF11 Extensibilidade O sistema deve permitir que novos critérios de análise sejam
acrescentados ao sistema no futuro.
55
Fluxo de Exceção:
FE02 - O e-mail e senha do professor não são identificados. O sistema informa uma mensagem:
“Usuário e senha não identificados pelo sistema”.
com o modelo de avaliação definido na seção 4.1. REST (RODRIGUEZ, 2008) é uma
arquitetura que permite a separação de sistemas web em módulos (serviços). Para
implementar esse serviço o CodeMaster utiliza o framework Jersey (JERSEY, 2017)
que usa a API JAX-RS (JAX-RS API, 2017) abstraindo os detalhes de baixo nível da
implementação de comunicação entre os servidores e simplifica a implementação de
um serviço REST. A escolha desse framework foi feita pela simplicidade de uso, por
ser adequado ao que é proposto no CodeMaster e pela grande quantidade de material
disponível, auxiliando na implementação do sistema.
O módulo de apresentação é o responsável pelo controle da interface de
usuário, o registro de professores e turmas, a submissão de projetos e a apresentação
de resultados tanto para professores quando alunos. O componente de front-end
utiliza as tecnologias JSP, Java Script, HTML5 e CSS3 comuns no desenvolvimento
de páginas web.
arquivos contém os códigos a serem analisados, portanto, deve ser feito o parse, para
isso é utilizada a biblioteca JSON Simple de código aberto para o parse dos arquivos
json e bibliotecas nativas do Java para o parse dos arquivos xml. Esta etapa é feita
pelas classes XMLParse e JSONParse que constroem estruturas de dados em
memória com o código e retornam. Por sua vez essas estruturas de dados são
passadas para a classe Codigo que, por meio de um algoritmo, percorrerá essas
estruturas e contabilizara todos os blocos utilizados, gerando estatísticas sobre os
componentes do projeto recebido.
ConceitoCT é uma classe abstrata que recebe uma instância da classe Codigo
onde contém todas as estatísticas do projeto. Cada conceito definido na seção 4.1
estende essa classe ConceitoCT e implementa o método avaliaCodigo retornando
com base nas estatísticas geradas uma pontuação de 0 a 3 para tal conceito. Por fim,
todas as pontuações são calculadas de modo a gerar uma pontuação, nota final e
nível ninja e retornadas encapsuladas na classe AppInventorGrade.
O design de interface do CodeMaster foi feito de forma iterativa, para cada fluxo
de execução proposto foi desenvolvida a interface gráfica do sistema. Com a intenção
de criar uma interface gráfica com boa usabilidade seguindo padrões de identidade
visual definidos pela iniciativa Computação na Escola, a interface gráfica foi elaborada
em conjunto com os bolsistas Heliziane Barbosa e Luiz Felipe Azevedo da iniciativa
Computação na Escola do GQS/InCod/INE/UFSC.
Para cada caso de uso proposto é apresentado abaixo o design de interface
criada bem como o fluxo de execução principal.
72
2. Aluno clica no
item de menu
“Aluno”.
3. Aluno clica em
escolher arquivo
e escolhe projeto
em seu
computador.
4. Aluno clica em
“Avaliar” e
sistema retorna o
resultado da
análise do
projeto.
73
2. Professor clica no
menu superior no
botão “professor”.
3. Professor clica na
opção de “Ainda
não sou
cadastrado” abaixo
dos campos de
login e senha.
4. Professor
informa, nome, e-
mail, senha,
instituição de
ensino, disciplina,
cidade, estado e
clica em cadastrar.
74
5. Professor recebe
e-mail com link para
validar conta.
6. Professor abre
link recebido no e-
mail e uma
mensagem de conta
confirmada é
exibida.
7. Página da área
de login de
professor é exibida.
2. Professor clica
no botão
professores no
menu superior
da tela.
75
3. Professor
informa seu e-
mail e senha
nos campos
de login e
senha e clica
em Login.
4. O sistema
autentica o
professor e é
redirecionado
à página
principal do
modo
professor.
2. Professor
seleciona os
conceitos que
deseja avaliar.
3. Professor
escolhe
múltiplos
arquivos de
seu
computador
que
correspondem
a uma turma.
4. Professor clica
em avaliar e
recebe o
resultado da
análise de
todos os
projetos em
uma tabela.
77
3. Sistema
consulta no
Banco de
Dados e
retorna o
resultado das
análises da
turma
selecionada.
Multifuncional ai2.appinventor.mit.edu/?galleryId=461834013193
Aplication 0112
ai2.appinventor.mit.edu/?galleryId=483371359928
PingPong
3200
ai2.appinventor.mit.edu/?galleryId=571077764474
TicTacToe
4704
ai2.appinventor.mit.edu/?galleryId=540510216912
EuroFrance2o16
8960
ai2.appinventor.mit.edu/?galleryId=591848322839
Space_invaders
3472
80
ai2.appinventor.mit.edu/?galleryId=514251574974
Facebook
8736
School
ai2.appinventor.mit.edu/?galleryId=540761930360
Classmate&Schedu
4224
le
ai2.appinventor.mit.edu/?galleryId=477661731802
IH Logo Quiz
3168
Para a avaliação manual dos códigos, cada projeto selecionado foi aberto no
próprio App Inventor e para cada conceito da rubrica foi verificada e contada a
presença dos blocos e componentes visuais. Analisando os aplicativos manualmente
se obteve as pontuações, notas e níveis mostradas na Figura 21.
81
Jovem Tutor
Educação Física
Informática
0 1 2
6° ano
5° ano
2° ano
0 1 2
O CodeMaster é útil?
Todos os usuários consideram o CodeMaster útil para a aprendizagem e ensino
de programação. De forma geral conceitos como o entendimento de programação,
organização em avaliações e diferenciação das partes de um aplicativo foram
elogiados do CodeMaster. A forma de fazer o upload de projetos foi considerada
positiva, porém algumas sugestões foram dadas, como por exemplo, a possibilidade
do próprio aluno fazer o envio do projeto para o professor via o sistema. Os dados
coletados sobre a utilidade são apresentados na tabela 29.
Você acha a ferramenta CodeMaster útil na “Porque você pode criar um programa (no Snap!
aprendizagem de programação? Explique, ou no App Inventor), e ser avaliado para ver se
porque? seu jogo/app está bom ou se precisa de algumas
melhorias.”
Você acha a ferramenta CodeMaster útil no “Penso que é uma forma rápida de avaliar os
ensino de computação no ensino Básico? alunos e ainda verificar a profundidade do
Explique, porque? entendimento que eles obtiveram.”
“Eu acho útil o CodeMaster, porque podemos
nos organizar melhor com as avaliações.”
“Vejo como importante principalmente na
conceituação e diferenciação das diferentes
partes de um aplicativo como a conectividade,
telas, mídias...”
Você acha que na sua forma atual (fazer o “Uma forma em que cada aluno submetesse seu
upload de um conjunto de projetos de alunos próprio app para posterior verificação completa
identificando-os por seu nome no arquivo) é e de toda turma por parte do professor também
prático no seu dia-a-dia? Explique, porque? seria útil, pois nem sempre o professor fica com
uma cópia do projeto feito pelo aluno.”
“Mas penso que o nome pode ser o do app, para
facilitar e já dar uma ideia do que se trata o app.”
O CodeMaster é funcional?
Em relação a funcionalidade, a ferramenta obteve um feedback positivo, foi
observado um erro durante a execução da análise por um dos avaliadores que deve
ser corrigido.
Além disso a nota obtida pelos alunos, em sua maioria achou justa, porém, foi
comentado em uma das avaliações em que mesmo o projeto analisado recebendo
upgrades a nota não aumentava como o aluno esperava. Isso pode ser um fator que
desanima o aluno no seu processo de aprendizagem, por isso, futuramente é
importante verificar especificamente a necessidade de uma atualização na forma de
cálculo da nota final.
Fazendo análise da Tabela 30, observa-se que a completude das
funcionalidades da ferramenta tem um feedback positivo, porém, em comentários, foi
sugerida a inserção de mais alguns critérios na análise de código, como paralelismo,
duplicidade de código e presença de código morto. Também foi comentado que seria
interessante ser possível ordenar a listagem de projetos analisados por um professor
por cada uma das colunas presentes no resultado da avaliação que é apresentada.
87
resposta maior também. Percebe-se por meio dos dados da Tabela 31 que os alunos
têm menos tolerância quanto a velocidade da ferramenta, já por parte dos professores
não houve pontos negativos.
Pontos fortes
Sugestões de melhoria
Vale ressaltar que durante período de aplicação dos testes aos alunos e
professores o CodeMaster ainda se encontrava em desenvolvimento, portanto a
avaliação foi feita numa primeira versão que poderia retornar erros e inconsistências
durante o processo de avaliação de código. Outra ameaça a validade da avaliação
feita é a quantidade de usuários capacitados disponíveis para avaliar a ferramenta,
entende-se que mais usuários testando e avaliando poderia retornar resultados com
mais precisão e confiabilidade.
91
6. CONCLUSÃO
O objetivo principal deste trabalho foi desenvolver uma ferramenta web para
análise e avaliação de código gerado pelo App Inventor para dar suporte ao ensino de
computação ao Ensino Básico. Neste contexto, foi feita a análise da fundamentação
teórica (O1). Também foi realizada a análise do estado da arte identificando a falta de
ferramentas de análise de código para suporte ao ensino de computação de modo
generalizado (O2). Deste modo, baseando-se na fundamentação teórica e na análise
do estado da arte, foi elaborado um modelo conceitual incluindo a definição de uma
rubrica para análise de código do App Inventor e foi desenvolvida uma ferramenta que
analisa e avalia automaticamente projetos de apps criados com o App Inventor (O3).
O desenvolvimento da ferramenta CodeMaster - App Inventor foi feito de forma
integrada e em conjunto com Pelle (2018) que implementou o CodeMaster – Snap!.
Os resultados da avaliação do CodeMaster - App Inventor fornecem uma indicação
inicial da sua corretude, utilidade, funcionalidade, desempenho e usabilidade muito
positiva (O4).
O CodeMaster permite o cadastro de professores e a análise e avaliação de
múltiplos projetos em lote, podendo ser agrupados por turmas de alunos. Além do
serviço disponibilizado a professores que querem ensinar programação para seus
alunos, a ferramenta permite que alunos possam avaliar seus projetos e receberem
um feedback de como está o seu nível de competência em programação por meio de
notas e faixas de ninja que tornam o sistema mais amigável para os jovens aprendizes.
Por falta de tempo hábil, a parte de pesquisador, que deve exibir estatísticas gerais
de projetos analisados, citada nos requisitos funcionais, não foi implementada e não
está disponível na primeira versão do CodeMaster.
Com o CodeMaster – App Inventor, existe hoje uma ferramenta robusta e única
para análise e avaliação automatizada de códigos produzidos no ambiente de
programação visual App Inventor, dando suporte a professores e alunos no ensino e
aprendizagem de computação no Ensino Básico.
Como trabalhos futuros, recomenda-se a implementação de análise de
usabilidade dos projetos App Inventor, por exemplo, analisando a posição de
elementos gráficos dos aplicativos, ou cores utilizadas. Além disso, recomenda-se a
pesquisa da necessidade de implementação dos critérios de paralelismo, trechos de
código duplicados e trechos de código morto além de sua implementação caso se faça
92
REFERÊNCIAS
BRENNAN, K., RESNICK, M. New frameworks for studying and assessing the
development of computational thinking. Proceedings of the 2012 Annual Meeting
of the American Educational Research Association, Vancouver, Canada, 2012.
CSTA. ACM. CSTA K –12 Computer Science Standards, 2011. Disponível em:
<http://csta.acm.org/Curriculum/sub/CurrFiles/CSTA_K-12_CSS.pdf>. Acesso em:
setembro de 2016.
Daniel, G. T., von Wangenheim, C. G., Araújo, G., de Medeiros, S., & da Cruz Alves,
N. Ensinando a Computação por meio de Programação com App Inventor. Anais
do Computer on the Beach, Florianópolis, Brasil, 2017, 357-365.
95
JAX-RS API, Java™ API for RESTful Web Services (JAX-RS) delivers API for
RESTful Web Services development in Java SE and Java EE. 2017. Disponível
em: < https://github.com/jax-rs>. Acesso em: julho de 2017.
MORENO-LEÓN, J.; ROBLES, G. Analyze your Scratch projects with Dr. Scratch
and assess your computational thinking skills. In: Proceedings of the Scratch
Conference, Amsterdam, Netherlands, 2015.
PISKURICH, George M. Rapid instructional design: Learning ID fast and right. John
Wiley & Sons, 2015.
DR. SCRATCH. Dr.Scratch – Analise seus projetos Scratch aqui. Disponível em:
<http://www.drscratch.org/>. Acesso em: Setembro 2016.
RODRIGUEZ, Alex. Restful web services: The basics. IBM developerWorks, 2008.
SBC, Plano de Gestão para a SBC Biênio Agosto 2015 - Julho 2017, 2015.
Disponível em: <http://www.sbc.org.br/documentos-da-sbc/send/135-eleicoes/999-
plano-de-gestao-para-a-sbc-bienio-agosto-2015-julho-2017> Acesso em: setembro
de 2016.
99
TRUONG, N.; ROE, P.; BANCROFT, P. Static analysis of students' Java programs.
In: Proceedings of the Sixth Australasian Conference on Computing Education,
Australia, 2004.
VIEGA, J. et al. ITS4: A static vulnerability scanner for C and C++ code.
In: Proceedings of the 16th Annual Conference On Computer Security Applications,
Dulles, Virginia, USA, 2000.
Zen, K., Iskandar, D.N.F.A., Linang, O. (2011). Using Latent Semantic Analysis for
automated grading programming assignments. Proceedings of the 2011
International Conference on Semantic Technology and Information Retrieval,
Putrajaya, Malaysia, pages 82 –88.
101
Convite Professor
Olá,
Gostaríamos de convidar você para participar da avaliação do CodeMaster, uma
ferramenta online que analisa e avalia projetos de apps programados no AppInventor
e Snap! no contexto do ensino de programação em escolas.
A ferramenta foi desenvolvida no contexto do TCC de Matheus Faustino Demetrio sob
a orientação da Profa. Christiane Gresse von Wangenheim realizado na iniciativa de
Computação na Escola no INCoD/INE/UFSC.
Na avaliação estaremos solicitando a você que simule a avaliação de projetos.
Disponibilizaremos a você um pacote de projetos AppInventor prontos para enviar ao
sistema simulando a avaliação em massa de vários projetos de diferentes alunos, e
ao final, o preenchimento de um questionário sobre a utilidade e usabilidade da
ferramenta. No total, não deve levar mais do que 30 minutos.
Para facilitar a avaliação gostaríamos de realizar a avaliação junto com vocês para
que possamos esclarecer quaisquer dúvidas que possam surgir no decorrer da tarefa.
Caso você esteja de acordo, favor enviar e-mail para [email protected]
para agendar um horário para a avaliação a ser realizada na escola onde você atua.
A sua participação é voluntaria sem renumeração. Todos os seus dados serão
tratados de forma sigilosa usados somente para fins de pesquisa.
Desde já, muito obrigado pela ajuda! O seu feedback é muito importante para nossa
pesquisa.
Ao final estaremos disponibilizando a ferramenta gratuitamente no site da iniciativa
Computação na Escola (http://www.computacaonaescola.ufsc.br) para qualquer
interessado.
Att,
Matheus e Christiane
Cenário Professor
Questionário Professor
Nome * ________________________________________________
• Safari
• Microsoft Edge
• Outro
Explique, porque:
______________________________________________________________
Se sim, quais?
_________________________________________________________________
Você acha que existem aspectos relevantes no (processo de) avaliação de projetos
de programação no ensino de computação no ensino básico que não são suportados
pela ferramenta? *
• Sim
• Não
Se sim, quais?
_________________________________________________________________
105
Você acha que na sua forma atual (fazer o upload de um conjunto de projetos de
alunos identificando-os por seu nome no arquivo) é prático no seu dia-a-dia?
• Sim
• Não
Se não, o que deverá ser diferente?
___________________________________________________________________
Satisfação
Escala de resposta para cada um dos 10 itens: 1 (discordo totalmente), 2, 3, 4, 5
(concordo completamente)
Item Afirmação Discordo Concordo
Totalmente completamente
1 2 3 4 5
1 Eu penso que usarei este sistema com frequência.
2 Acho o sistema desnecessariamente complexo.
3 Penso que o sistema é fácil de usar.
4 Acho que vou precisar da ajuda de um técnico para
usar este sistema.
5 Acho as funções deste sistema bem integradas.
6 Encontro muitas inconsistências neste sistema.
7 Imagino que as pessoas aprenderão rapidamente a
usar este sistema.
8 Não acho o sistema prático de usar.
9 Senti-me confiante ao usar o sistema.
10 Precisei aprender muitas coisas antes de ser capaz
de operar o sistema.
Comentários gerais
O que mais você gostou da ferramenta CodeMaster? *
__________________________________________________
Alguma sugestão de melhoria referente a ferramenta CodeMaster?*
__________________________________________________
Mais algum comentário?
Convite Aluno
Olá,
Gostaríamos de convidar você apara participar de uma avaliação do CodeMaster, uma
ferramenta online que analisa e avalia projetos de apps programados no AppInventor
e Snap!.
A ferramenta foi desenvolvida no contexto do TCC de Matheus Faustino Demetrio sob
a orientação da Profa. Christiane Gresse von Wangenheim realizado na iniciativa de
Computação na Escola no INCoD/INE/UFSC.
Cenário Aluno
Imagine que você fez um app com App Inventor. Agora você gostaria de saber até que
ponto você está dominando a programação de apps – se ainda está só iniciando isto
ou já é um mestre em programação. Assim, você abre o CodeMaster e analisa o seu
projeto.
Questionário Aluno
Nome *________________________________________________
Você está em que ano do ensino fundamental?*
• 1° ano
• 2° ano
• 3° ano
• 4° ano
• 5° ano
• 6° ano
• 7° ano
• 8° ano
• 9° ano
109
• Outro: _______________
Qual ambiente de programação você usou para programar? (Pode ser mais de uma
resposta)
- App Inventor
- Scratch
- Snap!
- Outro: _______________
Comentários gerais
O que mais você gostou da ferramenta CodeMaster? *
__________________________________________________
Alguma sugestão de melhoria referente a ferramenta CodeMaster?*
__________________________________________________
Mais algum comentário?
Resumo
1. Introdução
Pensamento Computacional é a competência que envolve resolver problemas, projetar
sistemas, e entender o comportamento humano, formados por conceitos fundamentais da
ciência da computação (Wing, 2006). É considerado a competência chave para a atual
geração de estudantes em um mundo extremamente influenciado pelos princípios da
113
computação (Wing, 2006). Por esse motivo, ensinar o pensamento computacional tem sido o
foco por todo o mundo (Grover and Pea, 2013) (Kafai and Burke, 2013) (Resnick et al., 2009).
Muitas dessas iniciativas focam em ensinar programação, que não é apenas uma parte
fundamental da computação, mas também uma importante ferramenta para suporte a tarefas
cognitivas que envolvem o pensamento computacional (Grover and Pea, 2013). Linguagens
de programação baseada em blocos encorajam e motivam a aprendizagem de conceitos de
programação, reduzem a carga cognitiva e permitem o foco na lógica e estruturas envolvidas
na programação ao invés do aprendizado de complexas sintaxes de linguagens de
programação baseadas em texto (Kelleher and Pausch, 2005)(Maiorana et al., 2015)(Grover
et al., 2015). Muitas atividades do pensamento computacional focam em criar soluções para
problemas do mundo real, em que as soluções são artefatos de software, como
games/animações em tópicos interdisciplinares ou aplicativos móveis para resolver problemas
na comunidade (Monroy-Hernández and Resnick, 2008) (Fee and Holland-Minkley, 2010).
Neste contexto, as atividades não possuem uma única solução correta.
Um elemento crucial no processo de aprendizagem é a avaliação e feedback (Hattie
and Timperley, 2007) (Shute, 2008) (Black and Wiliam, 1998). A avaliação guia a
aprendizagem e prove um feedback tanto para o estudante quanto para o professor. Para
uma aprendizagem efetiva, os estudantes precisam saber o seu nível de performance em uma
tarefa, como relacionar a sua performance a uma boa performance e o que fazer para diminuir
a diferença entre elas. (Sadler, 1989)
Não existe consenso nas estratégias para avaliar conceitos do pensamento
computacional (Brennan and Resnick, 2012) (Grover et al., 2014). A avaliação do pensamento
computacional é particularmente complexa pela natureza abstrata da construção mensurada.
Muitos autores têm proposto diferentes aproximações e frameworks para tentar guiar a
avaliação dessa competência de diferentes formas, incluindo a avaliação de artefatos de
softwares criados por estudantes (Brennan and Resnick, 2012). As avaliações de softwares
podem abranger diversos aspectos de qualidade, como corretude, complexidade, reuso,
conformidade com padrões de programação, etc.
Outro problema que complica a avaliação do pensamento computacional na pratica
educacional é que a avaliação manual de trabalhos de programação requer recursos
substanciais em se tratando de tempo e pessoas. Isso pode causar uma baixa escalabilidade
no ensino de computação a um grande número de estudantes (Eseryel et al., 2013) (Romli et
al., 2010) (Ala-Mutka, 2005). Além disso, muitos professores de outras disciplinas introduzem
o ensino de computação de forma interdisciplinar em suas turmas, com isso, esses
professores, são desafiados em respeito a avaliação. Desse modo, a avaliação manual pode
permitir que erros aconteçam na avaliação dos estudantes, bem como inconsistência, fadiga
e favoritismo (Zen et al., 2011).
114
2. Fundamentação
Este capítulo apresenta os conceitos referentes a teoria da aprendizagem e do ensino,
bem como o princípio de uma unidade instrucional e design instrucional. Também são
apresentados conceitos de análise de código e uma visão geral sobre o ambiente de
programação App Inventor.
• Compartilhamento de dados;
• Uso de serviços web públicos;
• Uso de acelerômetro e sensores de orientação;
• Reconhecimento de localização.
No foco do presente artigo necessita-se então da medição destes aspectos com base
em trabalhos práticos, que possuam várias possíveis soluções a serem desenvolvidas pelos
alunos. Neste caso a análise e avaliação de código requer mais flexibilidade, pois,
possivelmente existem diversas soluções corretas ao problema. Assim, se faz necessário um
analisador de código que possa fazer uma análise mais flexível e livre do código.
Neste contexto, a análise e avaliação do programa baseia-se no pressuposto de que
certos atributos mensuráveis podem ser extraídos do programa, avaliando se os alunos
aprenderam o que era esperado utilizando uma rubrica. A rubrica usa medidas descritivas
para separar os níveis de desempenho em uma determinada tarefa, delineando os vários
117
Existem muitas linguagens de programação hoje em dia, cada uma com suas
peculiaridades e objetivos (IEEE, 2016). A maior parte das linguagens de programação hoje
utilizadas no desenvolvimento profissional são linguagens de programação textual. Porém,
com o objetivo de engajar crianças e jovens na área da computação e para facilitar a
aprendizagem de computação nesta faixa etária, são indicados o uso de linguagens de
programação visuais (RESNICK et al., 2009).
Linguagens de programação visuais baseado em blocos permitem criar sistemas de
software ou aplicativos arrastando e encaixando blocos. Nas linguagens visuais todos os
componentes das linguagens já estão definidos, normalmente, em forma de figuras ou blocos,
o usuário deverá colocar esses blocos numa ordem que faça sentido ao programa e então a
aplicação começa a ser programada. Desta maneira ele não precisará escrever linhas de
código textuais, eliminando a necessidade de se entender e memorizar as complexas sintaxes
de linguagens textuais.
Umas das linguagens de programação visual é o Blockly (BLOCKLY, 2017). Criado
pela Google, tem como objetivo ser uma biblioteca que sirva como base para o
desenvolvimento de ambientes de programação.
118
3. CodeMaster
Por meio da análise do estado da arte é possível identificar a necessidade de se
desenvolver mais ferramentas de análise e avaliação de código para linguagens de
programação visual. Portanto, a proposta é o desenvolvimento de uma ferramenta de análise
e avaliação de código voltada especificamente para o App Inventor com foco no ensino de
programação para o Ensino Básico. O objetivo é desenvolver uma ferramenta de análise de
código do App Inventor no contexto de ensino, o CodeMaster - App Inventor. A ferramenta
deve permitir a análise e avaliação automática dos trabalhos práticos desenvolvidos pelos
alunos, fornecendo um feedback instrucional.
• Analisar o projeto que contém o código da aplicação nos formatos bky e scm;
• Avaliar um projeto individual retornando um feedback instrucional incluindo nota,
pontuação total, pontuação por critério e nível ninja;
• Apresentar as avaliações dos projetos ao professor em uma tabela com todos os projetos
analisados e podendo exportar esses dados em planilha;
• Apresentar a avaliação do projeto ao aluno.
• Apresentar dados gerais e anônimos sobre as avaliações já realizadas pelo CodeMaster
a pesquisadores interessados.
O CodeMaster deve avaliar, com base no Dr. Scratch (DR. SCRATCH, 2017), na
rubrica para avaliar apps proposta por Sherman (2015) e no framework do pensamento
computacional (BRENNAN & RESNICK, 2012), os conceitos do código conforme apresentado
na Tabela 18.
0 1 2 3
Telas Apenas uma tela Apenas uma tela com Pelo menos duas telas 2 ou mais telas e
com componentes componentes visuais e uma delas altera seu pelo menos 2 delas
visuais e que seu que se alteram com a estado com a alteram seus
estado não se altera execução do app. execução do app. estados com a
com a execução do execução do app.
app (tela
informativa).
Interface de Usuário Utiliza apenas 1 Utiliza 2 ou mais Utiliza mais de 5 Utiliza mais de 5
elemento visual sem elementos visuais sem elementos visuais com elementos visuais
alinhamento. alinhamento. 1 tipo de alinhamento. com 2 ou mais
elementos de
alinhamento.
Nomeação: Nenhum ou poucos De 10 a 25% dos De 26 a 75% dos Mais de 76% dos
Variáveis e nomes são alterado nomes são alterados nomes são alterados nomes são alterados
procedimentos do padrão. (menos do padrão. do padrão. do padrão.
do que 10%)
Laços Não usa laços Usa “While” (laço Usa “For each” Usa “For each” (item
simples) (variável simples) de lista)
Condicionais Não usa Usa apenas “if’s” Usa apenas “if then Usa um ou mais “if -
condicionais. simples. else”. else if”.
Operações Lógicas e Não usa operadores Usa um tipo de Usa dois tipos de Usa mais de 2 tipos
Matemáticas operador. operadores. de operadores.
120
Listas Não usa listas. Usa uma lista Usa mais de uma lista Usa uma lista de
unidimensional. unidimensional. tuplas (map).
Persistência de dados Dados são Usa persistência em Usa algum dos bancos Usa uma base de
armazenados em arquivo (File ou de dados locais do dados web
variáveis ou Fusion App Inventor (TinyDB). tinywebdb ou
propriedades de Tables). Firebase do App
componentes e não Inventor (firebase ou
tem persistência TinyWebDB).
quando app é
fechado.
Sensores Sem uso de Usa um tipo de sensor. Usa 2 tipos de Usa mais de 2 tipos
sensores. sensores. de sensores.
Mídia Sem uso de mídias. Usa um tipo de Mídia. Usa 2 tipos de Mídia. Usa mais de 2 tipos
de mídia.
Desenho e Animação Sem uso de desenho Uso de área sensível Uso de animação com Uso de animação
e animação. ao toque. bolinha pré-definida. com imagem.
Como resultado da análise dos critérios o sistema apresenta uma nota e um nível de
competência ao aluno.
Nota. Com base nos conceitos apresentados na Tabela 1, o CodeMaster apresenta uma
pontuação para cada critério. A nota final do projeto é definida numa escala de 0 a 10,
alinhando a escala de notas tipicamente utilizados no ensino básico no Brasil. Para se obter
a nota final, é definida a seguinte fórmula:
Nível de competência. Para tornar essa nota mais divertida e agradável aos jovens, o
resultado é transformado na apresentação de nível de competência representado por faixas
de ninjas em cores diferentes. Cada faixa de valores de possíveis notas é mapeado a cores
de faixa de ninja, como mostrado na tabela 2.
Modo de uso. O CodeMaster tem dois modos de uso. No modo individual o aluno submete
seu próprio código à análise sem necessitar de cadastro. No modo individual, o feedback
inclui:
• A pontuação total e a nota (em termos numéricos e por meio da faixa do ninja usando
a imagem do ninja);
• A pontuação por critério de avaliação;
• A rubrica de avaliação.
• Pontuação total e a nota (em termos numéricos e por meio da cor da faixa do ninja);
• Pontuação por critério de avaliação;
• Médias da turma por critério de avaliação, pontuações totais e notas;
• A rubrica de avaliação.
3.2 Implementação
Com base no modelo conceitual, o CodeMaster foi desenvolvido como uma aplicação
web. A ferramenta automatiza a análise e avaliação de projetos de programação do App
Inventor. A Figura 1 apresenta uma visão geral dos casos de uso implementados pelo
CodeMaster.
4. Conclusão
App Inventor fornecem uma indicação inicial da sua corretude, utilidade, funcionalidade,
desempenho e usabilidade muito positiva.
O CodeMaster permite o cadastro de professores e a análise e avaliação de múltiplos
projetos em lote, podendo ser agrupados por turmas de alunos. Além do serviço
disponibilizado a professores que querem ensinar programação para seus alunos, a
ferramenta permite que alunos possam avaliar seus projetos e receberem um feedback de
como está o seu nível de competência em programação por meio de notas e faixas de ninja
que tornam o sistema mais amigável para os jovens aprendizes.
Com o CodeMaster – App Inventor, existe hoje uma ferramenta robusta e única para
análise e avaliação automatizada de códigos produzidos no ambiente de programação visual
App Inventor, dando suporte a professores e alunos no ensino e aprendizagem de
computação no Ensino Básico.
Referências
Monroy-Hernández, A.; Resnick, M. (2008). Empowering kids to create and share programmable media
Interactions. 15(2), 50-53.
MORENO, R. Decreasing cognitive load for novice students: Effects of explanatory versus corrective feedback in
discovery-based multimedia. Instructional Science, v. 32, n. 1, p. 99-113, 2004.
MORENO-LEÓN, J.; ROBLES, G.; Computer programming as an educational tool in the English classroom a
preliminary study. In: Proceedings of 2015 IEEE Global Engineering Education Conference, Tallinn, Estonia,
2015.
NEUNER, G. ET AL, Pedagogía. La Habana: libros para la educación,1981.
RASHKOVITS, R; LAVY, I. FACT: A Formative Assessment Criteria Tool for the Assessment of Students'
Programming Tasks. In: Proceedings of the World Congress on Engineering. Londres, UK, 2013.
Resnick, M., Maloney, J., Monroy-Hernandez, A., Rusk, N., Eastmond, E., Brennan, K. (2009). Scratch:
Programming for all. Communications of the ACM, 52(11), 60–67.
Romli, R., Sulaiman, S., Zamli, K. Z. (2010). Automatic programming assessment and test data generation - a
review on its approaches. Proceedings of International Symposium in Information Technology, Kuala Lumpur,
Malaysia, 1186–1192.
Sadler, D. R. (1989). Formative assessment and the design of instructional systems, Instructional Science, 18(2),
119-144.
Shute. V. J. (2008). Focus on formative feedback. Review of Educational Research, 78(1),153-189.
WANGENHEIM, C. G.; NUNES, V. R.; SANTOS, G. D. Ensino de computação com scratch no ensino fundamental–
um estudo de caso. Revista Brasileira de Informática na Educação, v. 22, n. 03, 2014.
WHITTAKER, C. R., SALEND, S. J., DUHANEY, D. Creating instructional rubrics for inclusive classrooms. Teaching
Exceptional Children, 34(2), 8-13, 2001.
Wilcox, C. (2016). Testing Strategies for the Automated Grading of Student Programs. Proceedings of the 47th
ACM Technical Symposium on Computing Science Education, Memphis, Tennessee, USA, 437-442.
Wing, J. (2006). Computational Thinking. Communications of the ACM, 49(3), 33-36.
Yadav, A., Burkhart, D., Moix, D., Snow, E., Bandaru, P., Clayborn, L. (2015). Sowing the Seeds: A Landscape
Study on Assessment in Secondary Computer Science Education. Proceedings of CSTA Annual Conference,
Grapevine, TX, USA.
Zen, K., Iskandar, D.N.F.A., Linang, O. (2011). Using Latent Semantic Analysis for automated grading programming
assignments. Proceedings of the 2011 International Conference on Semantic Technology and Information
Retrieval, Kuala Lumpur, Malaysia, 82 –88.