Filo Arthropoda (Barnes, 1977) Subfilo Trilobita Fósseis, todos extintos Subfilo Chelicerata
TCC2 ALEXANDRE SCHEAD DOS SANTOS KONESKIsiaibib01.univali.br/pdf/Alexandre Schead dos Santos... ·...
77
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO SOUNDLOOPS: UMA ABORDAGEM MUSICAL PARA O APRENDIZADO DE LAÇOS DE REPETIÇÃO Área deInformática na Educação por Alexandre Schead dos Santos Koneski Elieser Ademir de Jesus, M.Sc. Orientador Itajaí (SC), dezembro de 2010
Transcript of TCC2 ALEXANDRE SCHEAD DOS SANTOS KONESKIsiaibib01.univali.br/pdf/Alexandre Schead dos Santos... ·...
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SOUNDLOOPS: UMA ABORDAGEM MUSICAL PARA O APRENDIZADO DE LAÇOS DE REPETIÇÃO
Área deInformática na Educação
por
Alexandre Schead dos Santos Koneski
Elieser Ademir de Jesus, M.Sc. Orientador
Itajaí (SC), dezembro de 2010
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SOUNDLOOPS: UMA ABORDAGEM MUSICAL PARA O APRENDIZADO DE LAÇOS DE REPETIÇÃO
Área deInformática na Educação
por
Alexandre Schead dos Santos Koneski Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Elieser Ademir de Jesus, M.Sc.
Itajaí (SC), dezembro de 2010
ii
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................. iv
LISTA DE FIGURAS ................................................................................. v
LISTA DE TABELAS ............................................................................... vi
RESUMO ................................................................................................... vii
ABSTRACT .............................................................................................. viii
1 INTRODUÇÃO........................................................................................ 1
1.1 PROBLEMATIZAÇÃO ..................................................................................... 3
1.1.1 Formulação do Problema ................................................................................. 3
1.1.2 Solução Proposta ............................................................................................... 4
1.2 OBJETIVOS ........................................................................................................ 7
1.2.1 Objetivo Geral ................................................................................................... 7
1.2.2 Objetivos Específicos ........................................................................................ 7
1.3 METODOLOGIA ................................................................................................ 8
1.4 ESTRUTURA DO TRABALHO ....................................................................... 9
2 FUNDAMENTAÇÃO TEÓRICA ........................................................ 10
2.1 ENSINO DE PROGRAMAÇÃO ..................................................................... 10
2.1.1 Tópicos Fundamentais .................................................................................... 12
2.1.2 Tópicos Considerados Difíceis ....................................................................... 13
2.1.3 Ensino de loops ................................................................................................ 14
2.1.4 Uso de música para ensino de algoritmos ..................................................... 15
2.2 FORMAS DE VISUALIZAÇÃO DE ALGORITMOS ................................. 17
2.3 INTELIGÊNCIAS MÚLTIPLAS .................................................................... 19
2.4 ELEMENTOS MUSICAIS ............................................................................... 21
2.5 OBJETOS DE APRENDIZAGEM .................................................................. 22
2.6 SCORM E LMS ................................................................................................. 23
2.7 TRABALHOS SIMILARES ............................................................................. 24
2.7.1 Alice 2.0 ............................................................................................................ 24
2.7.2 Wu’s Castle ...................................................................................................... 25
2.7.3 Scratch 1.4 ........................................................................................................ 28
2.7.4 Fruity Loops Studio ........................................................................................ 29
3 DESENVOLVIMENTO ........................................................................ 32
3.1 DIAGRAMAS UML .......................................................................................... 32
3.2 ESCRACHO ....................................................................................................... 38
3.3 ELEMENTOS MUSICAIS UTILIZADOS .................................................... 40
3.4 REPRESENTAÇÃO DOS TRECHOS MUSICAIS ...................................... 42
3.5 EMPACOTAMENTO E TESTE COM LMS ................................................ 45
3.6 FERRAMENTAS UTILIZADAS .................................................................... 45
iii
3.7 PROBLEMAS ENCONTRADOS .................................................................... 46
4 CONCLUSÃO ........................................................................................ 48
4.1 TRABALHOS FUTUROS ................................................................................ 49
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 51
GLOSSÁRIO ............................................................................................. 55
A MODELAGEM DO SOUNDLOOPS ................................................ 57
A.1 REQUISITOS FUNCIONAIS .......................................................................... 57
A.2 REQUISITOS NÃO FUNCIONAIS ................................................................ 58
A.3 REGRAS DE NEGÓCIO .................................................................................. 58
B PESQUISA REALIZADA ................................................................... 59
B.1 QUESTIONÁRIO APLICADO ....................................................................... 59
B.2 DADOS COLETADOS ..................................................................................... 60
B.3 ANÁLISE DOS DADOS OBTIDOS ................................................................ 64
B.4 CONCLUSÃO DA ANÁLISE .......................................................................... 68
iv
LISTA DE ABREVIATURAS
ACM Association for Computing Machinery EA Enterprise Architect IEEE Institute of Electrical and Electronics Engineers LMS Learning Management System LOR Learning Object Repositories NQC Not Quit C OA Objeto de Aprendizagem SBC Sociedade Brasileira de Computação SCORM Sharable Content Object Reference Model TCC Trabalho de Conclusão de Curso UC Use Case UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí XML Extended Markup Language
v
LISTA DE FIGURAS
Figura 1. Diagrama de atividades do SoundLoops. ............................................................................. 6
Figura 2. Interface do Jeliot 3 ............................................................................................................. 18
Figura 3. Interface do Alice ................................................................................................................ 25
Figura 4. Imagem do nível três do jogo Wu’s Castle ......................................................................... 26
Figura 5. Imagem do nível dois do jogo Wu’s Castle ........................................................................ 27
Figura 6. Interface do Scratch ............................................................................................................ 28
Figura 7. Interface do Fruity Loops para criação dos ritmos ............................................................. 30
Figura 8. Diagrama de Casos de Uso do Aluno ................................................................................. 33
Figura 9. Diagrama de Casos de Uso do SoundLoops ....................................................................... 34
Figura 10. Interface do SoundLoops .................................................................................................. 35
Figura 11. Diagrama de Classe do SoundLoops ................................................................................ 36
Figura 12. Diagrama de Sequência da correção dos trechos no SoundLoops .................................... 37
Figura 13. InstrumentoView Bumbo .................................................................................................. 39
Figura 14. Partes do instrumento bateria ............................................................................................ 41
Figura 15. Exemplo de partitura representada por um arquivo MusicXML ...................................... 42
Figura 16. Formato do MusicXML .................................................................................................... 43
Figura 17. Formato do arquivo XML que será utilizado para representar as estruturas musicais ..... 44
Figura 18. Formato do arquivo XML utilizado para definir a lista dos exercício ............................. 45
Figura 19. Algoritmo sugerido pela banca ......................................................................................... 50
Figura 20. Gráfico que ilustra as respostas da pergunta “Você toca algum instrumento?” ............... 64
Figura 21. Gráfico que ilustra as respostas da pergunta “Qual instrumento você toca?” .................. 65
Figura 22. Gráfico que ilustra as respostas da pergunta “Qual gênero musical você ouve?” ............ 68
vi
LISTA DE TABELAS
Tabela 1. Tabela comparativa das características das ferramentas similares e do SoundLoops. ....... 31
Tabela 2. Tabela com os dados da pesquisa ....................................................................................... 60
vii
RESUMO
KONESKI, Alexandre Schead dos Santos. SoundLoops: uma abordagem musical para o aprendizado de laços de repetição. Itajaí, 2010. 77 f. Trabalho 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í, 2010. O processo de ensino e aprendizagem de programação enfrenta difíceis obstáculos. Por este e ainda outros motivos, cursos de computação e áreas afins têm apresentado altos índices de evasão e reprovação em disciplinas que abordam conteúdos de programação. Esta realidade se aplica a diferentes instituições de ensino de diversos países. As disciplinas de programação possuem vários desafios a serem vencidos tanto pelo aluno quanto pelo professor. O fato de grande parte dos alunos que entram para os cursos de computação não possuirem experiências prévias com programação é um dos grandes obstáculos. Sabe-se que não é fácil ensinar a programar, o alto nível de abstração dos conceitos envolvidos torna esta tarefa complexa. Com estas e ainda outras dificuldades expostas, diversas ferramentas e estratégias já foram desenvolvidas com objetivo de mudar a realidade atual. Este trabalho propõe o desenvolvimento de um objeto de aprendizagem para apoiar o ensino de loops, tópico apontado por vários trabalhos como um dos mais difíceis de serem ensinados. Este objeto de aprendizagem faz uso de sons e imagens para dar feedback sobre a execução do algoritmo. A decisão de utilizar a música como pano de fundo para o ensino de loops foi tomada com base na pesquisa realizada durante o desenvolvimento deste trabalho. Esta pesquisa mostra que existe uma relação entre os alunos do curso de Ciência da Computação da UNIVALI e a música. A pesquisa mostrou que 59% dos alunos possuem interesse na música como hobby, sendo que 41% dos alunos toca algum instrumento. O objeto de aprendizagem proposto explora os efeitos da música no ensino de programação, fazendo uso da “visualização” por meio de sons para dar feedback sobre a execução do algoritmo. Também são usados meios visuais com a mesma finalidade, buscando o uso de um maior conjunto de inteligências dos alunos durante o uso do objeto de aprendizagem. O objeto de aprendizagem proposto, chamado SoundLoops, foi concluído e testado no sistema de gerenciamento de aprendizagem chamado Moodle usando o modelo de referência SCORM. Palavras-chave: Ensino de programação. Ensino de laços de repetição. Ensino de programação utilizando música.
viii
ABSTRACT
The process of teaching and learning programming faces difficult obstacles. For this reason and
others, computer courses and related areas have shown high rates of truancy and failure in
disciplines that address programming content. This reality applies to different educational
institutions of various countries. The disciplines of programming have several challenges to be
faced by both the student and the teacher. The fact that many of the students entering computing
courses for not having previous experience with programming is a major obstacle. We know that
programming is not easy to teach, the high level of abstraction of the concepts involved makes this
complex task. With these and other difficulties still exposed, various tools and strategies have been
developed in order to change the current reality. This paper proposes the development of a learning
object to support the teaching of loops, topic pointed out by several studies as one of the most
difficult to be taught. This learning object makes use of sounds and images to give feedback on the
implementation of the algorithm. The decision to use music as background for the teaching of loops
was made based on research carried out during this work. This research shows that a relationship
exists between students of Computer Science UNIVALI and music. The survey showed that 59% of
students are interested in music as a hobby, and 41% of students play an instrument. The proposed
tool explores the effects of music in teaching programming, using the "view" by using sound to
provide feedback on the implementation of the algorithm. Visual media are also used for the same
purpose, trying to use a wider range of intelligences of students while using the tool. The proposed
tool, called SoundLoops was completed and tested in the learning management system called
Moodle using the SCORM standard.
Keywords: Learning programming. Learning loops. Music learning programming.
1 INTRODUÇÃO
Segundo as diretrizes do MEC (Ministério da Educação) para os cursos da área de
Computação e Informática, os assuntos algoritmos e estrutura de dados exercem papéis
fundamentais na formação do aluno. Este fato se comprova ao analisarmos os três principais
conceitos na construção de um software: algoritmos, modelos de computação e linguagens formais
(BRASIL, 2006, p. 5). Ambos os assuntos se complementam durante o processo de aprendizagem
de programação.
Barbosa (1994) identificou que a abordagem meramente expositiva para o ensino de
algoritmos e programação contribui parcialmente para a dificuldade no aprendizado e a alta taxa de
reprovação nas disciplinas de várias universidades do mundo todo.
Outros fatores citados por Beaubouef e Mason (2005) têm contribuição significativa na
diferença entre o número de alunos matriculados a cada ano e o número de formandos. Entre estes
fatores vale ressaltar a falta de habilidades matemáticas e de solucionar problemas. Durante o
estudo realizado por Beaubouef e Manson (2005), também foi identificado que a principal
dificuldade dos alunos no aprendizado de algoritmos está no nível de abstração dos conceitos.
Professores e pesquisadores vêm testando diversas idéias no sentido de diminuir o nível de
abstração na aprendizagem de algoritmos. McWhorter e O’Connor (2009) buscaram em suas
pesquisas descobrir qual o efeito provocado nos alunos pelo uso da ferramenta LEGO Mindstorms,
desenvolvida pelo mesmo grupo fabricante dos brinquedos LEGO. A linha LEGO Mindstorms
contém robôs montáveis e programáveis em várias linguagens, algumas das linguagens aceitas são
NQC (Not Quit C) e C++. Pelos relatos de McWhorter e O’Connor (2009), não foram encontradas
significativas diferenças de motivação nos alunos participantes do estudo.
Uma possibilidade também explorada é a chamada Programação Visual. Uma ferramenta
criada por Smith (2000) que surgiu do uso desta possibilidade recebeu o nome de Creator. Com
algumas limitações, essa ferramenta permite ao aluno “programar” sem conhecer qualquer sintaxe
de programação. Através da manipulação de elementos gráficos oferecidos pela ferramenta (figuras,
caixas de texto e outros elementos visuais) o aluno consegue montar expressões visuais e arranjos
espaciais de texto.
2
Com base na pesquisa realizada por Baldwin e Kuljis (2001) a visualização tem um papel
muito importante na compreensão por parte do aluno. Desenhos e figuras durante as explicações
podem ser de grande ajuda. Contudo, conclusões tiradas a respeito da ferramenta Creator, indicam
que a longo prazo outras abordagens de ensino podem ser mais benéficas.
Eagle e Barnes (2009) propuseram uma outra forma alternativa para o ensino de algoritmos,
os jogos. O jogo chamado Wu’s Castle recebeu melhorias e foi proposta uma pesquisa com objetivo
de verificar a sua eficiência enquanto ferramenta pedagógica. Como forma de diminuir a abstração,
o aluno vê e interage com arrays(um dentre os vários tipo de estrutura de dados) e loops (laços de
repetição) na tentativa de resolver os desafios impostos pelo jogo. Resultados apontados por Eagle e
Barnes (2009) revelam que o Wu’s Castle é mais eficiente no aprendizado de algoritmos do que
aulas expositivas e métodos tradicionais.
A música é uma outra forma de se trabalhar o ensino de algoritmos, já que a mesma possui
uma estrutura bem definida de repetições, isso faz parte da natureza da composição. Em muitos
casos existe uma introdução, logo em seguida uma estrofe, refrão, estrofe, novamente um refrão e
uma estrofe seguida de uma finalização. E estas partes da música, como a estrofe, são novas
repetições feitas através de combinações de ritmos, melodias e harmonias. Este trabalho busca na
música uma nova forma de visualização para os loops. Por meio das repetições naturalmente
presentes na música é possivel “visualizar” um algoritmo que compõe o ritmo, por exemplo.
Burg e Romney (2009) realizaram um experimento juntanto alunos de Ciência da
Computação e Música para que trabalhassem em conjunto na realização de projetos. Durante o
experimento muitos dos alunos do curso de Ciência da Computação se mostraram motivados e
familiarizados com a música, muitos já tocavam algum instrumento ou gostavam de ouvir. Certa
semelhança a realidade descrita pelos autores é identificada na UNIVALI (Universidade do Vale do
Itajaí).
Uma pesquisa foi realizada com os aluno da UNIVALI, e os resultados mostram que 41%
dos alunos tocam algum instrumento, em 69% dos casos guitarra ou violão. Essa realidade pode
estar relacionada com os principais gêneros musicais citados pelos alunos, a musica eletrônica e o
rock. Muitos dos alunos revelaram possuir vários anos de experiência musical, elevando a média
geral à 5 anos e 3 meses.
3
Considerando os resultados apresentados anteriormente, este trabalho propõe explorar o uso
da música como meio de apoiar a aprendizagem os conceitos de loops. Segundo Gardner (1999), é
possível através do uso dos sentidos visão e audição, ativar o uso de um conjunto maior de
inteligências durante o processo de aprendizagem de modo a aumentar consideravelmente a
capacidade do aluno de reter o conhecimento. Sabendo disso, a proposta deste trabalho é criar um
objeto de aprendizagem capaz de tornar mais concreta a manipulação de loops por meio das
inteligências ativadas pelo uso dos sentidos visão e audição.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
O processo de aprendizagem das disciplinas de algoritmos e programação enfrenta diversas
dificuldades, tanto por parte do aluno como do professor (TOBAR et al, 2001). A realidade
brasileira se mostra semelhante, prova disso é a realização do segundo Workshop de Ambientes de
Apoio à Aprendizagem de Algoritmos e Programação em 2009 que mostra por sua própria
existência que apesar dos esforços já realizados ainda existem dificuldades na aprendizagem e altos
índices de reprovação e desistência (JESUS; RAABE, 2009).
Proulx (2000) observou que um dos graves e freqüentes agravantes no aprendizado de
programação é a primeira experiência. Os desafios encontrados pelo aluno iniciante podem tornar a
experiência frustrante por vários motivos, a saber: preocupação excessiva com detalhes da sintaxe
da linguagem utilizada, dificuldades em enxergar o problema a ser solucionado, a falta de
habilidade para solucionar problemas, de construir o algoritmo para a solução e de abstrair o
funcionamento dos mecanismos escolhidos, entre outros. De acordo com Mota et al (2009) o
cenário brasileiro apresenta dificuldades semelhantes por parte dos alunos, com por exemplo,
dificuldades com a linguagem e na compreensão de conceitos abstratos (loops, ponteiros e arrays).
Tobar et al (2001), além de outros autores anteriormente citados, relacionam as dificuldades
previamente mencionadas com o alto grau de repetência e dificuldades apresentadas pelos alunos
nas disciplinas que englobam os conceitos de algoritmos e programação. O autor ainda descreve a
dificuldade encontrada pelos professores no acompanhamento efetivo durante as atividades
laboratoriais de programação, decorrente do grande número de alunos em sala de aula.
4
Durante sua pesquisa Júnior e Rapkiewicz (2004) apontaram três diferentes vertentes na
busca por meios de solucionar os problemas no processo de aprendizagem de algoritmos e
programação, sendo estas: ferramentas, estratégias e ferramentas para apoiar estratégias. Este
trabalho foca em uma das vertentes apontadas pelos autores, pois propõe a criação de um objeto de
aprendizagem para auxiliar a aprendizagem de loops.
Dale (2006) mostra que entre outros tópicos os loops são considerados pelos professores
como difíceis de ensinar, e isto sugere que também sejam considerados pelos alunos como difíceis
de aprender. Este trabalho tem como objetivo amenizar as dificuldades encontradas tanto pelos
professores quanto pelos alunos durante o processo de aprendizagem de laços de repetição.
1.1.2 Solução Proposta
Assim como alguns dos trabalhos mencionados anteriormente, este TCC pretende abordar a
diminuição do nível de abstração dos algoritmos durante o aprendizado. Este trabalho propõe o
desenvolvimento de um objeto de aprendizagem para apoiar o ensino de laços de repetição fazendo
uso de sons e imagens para dar feedback sobre a execução do algoritmo.
SegundoIEEE Learning Technology Standards Committee (2002), objetos de aprendizagem
podem ser definidos como toda e qualquer entidade, podendo ser esta digital ou não, que possa ser
utilizada, reutilizada ou referenciada durante o aprendizado auxiliado por tecnologias.
Este trabalho parte do pressuposto de que ao utilizar vários sentidos (especificamente visão e
audição) o aluno pode trabalhar mais de um tipo de inteligência. Gardner (1999) define um conjunto
de nove inteligências, a saber: linguística, lógico-matemática, espacial, sinestésica, interpessoal,
musical, intrapessoal, naturalista e existencial. Gardner afirma que o modelo ideal de escola é
aquele que reconhece que nem todos os alunos aprendem da mesma maneira, e valoriza as
habilidades e interesses naturais do aluno, incluindo o conjunto mais desenvolvido de suas
inteligências.
Na realidade de uma sala de aula não há como saber o perfil individual de cada aluno, mas
com a utilização de ferramentas e metodologias existe a possibilidade de fazer com que os alunos
utilizem mais de uma das inteligências combinadas. Este trabalho sugere a criação de um objeto de
aprendizagem que faça uso de uma abordagem musical, como forma de atingir um maior número de
inteligências durante o ensino de laços de repetição.
5
A alternativa de um OA (objeto de aprendizagem) foi feita pela oportunidade de reutilização
que ele oferece. Pelo fato de sua aplicação ser especificamente no suporte ao ensino de laços de
repetição, possibilita a qualquer docente interessado na sua utilização modelar seu planejamento de
ensino para a inserção do OA.
O objeto de aprendizagem desenvolvido tem como objetivo explorar as possibilidades que a
música tem a oferecer para o aprendizado. Em conjunto aos recursos sonoros o objeto de
aprendizagem faz uso do recurso visual, possibilitando ao aluno visualizar os loops executando em
tempo real com feedback auditivo.
O produto final deste projeto é um objeto de aprendizagem jogável com níveis crescentes de
dificuldade. Ao jogar o aluno precisareproduzir de forma idêntica os trechos musicais executados
pelo OA. Os recursos oferecidos ao aluno para reprodução dos trechos são uma interface de
composição rítmica e uma variável, cujo valor está relacionado com a quantidade de repetições do
rítmo. A interface de composição ritmica possui instrumentos, representados por grandes
retângulos, e retângulos menores representando a presença ou ausência de som em cada uma das
subdivisões. O aluno deve construir um compasso, que é a divisão do rítmo em grupos de tempos.
Estes tempos são compostos por subdivisões ritmicas. Neste caso foi definido que o aluno deve
construir um compasso com oito subdivisões, arrastando os retângulos menores (“TOCA” ou
“SILÊNCIO”) para dentro dos retângulos maiores (instrumentos). Não fica explícito para o aluno,
mas a variável é um contador do loop que repetirá a composição ritmica definida na interface.
Apenas o elemento musical chamado ritmo vai estar presente nesta composição.
Com o intuito de não impor barreiras com relação a experiência musical prévia de cada
indivíduo, apenas sons de fácil assimilação serão inclusos: bumbo, caixa e chimbal (todos fazem
parte do instrumento chamado bateria, seja eletrônica ou acústica). A Figura 1 mostra o processo de
utilização do SoundLoops representado através de um diagrama de atividades:
6
Figura 1. Diagrama de atividades do SoundLoops.
7
O OA propostoserá desenvolvido em Flash, portanto independente de sistemas operacionais
e altos requisitos de hardware. Escolheu-se trabalhar com Flash pela facilidade que ele oferece de
manipulação de arquivos de áudio e arquivos XML (Extended Markup Language – Linguagem de
Marcação Extensível). O XML foi escolhido para representar as estruturas musicais que são
utilizadas pelo mecanismo de comparação entre os trechos disponíveis no SoundLoops e aqueles
que são construídos pelo aluno. Através do XML também existe a possibilidade de novos trechos
serem adicionados ao repertório pré-estabelecido na criação do OA, já que o mesmo algoritmo de
correção pode ser utilizado para geração de trechos musicais. No entanto, não será incluso um
módulo para a criação de novos trechos, estes terão de ser gerados de forma manual.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Desenvolver um objeto de aprendizagem que possa ser utilizado como ferramenta de suporte
ao ensino de laços de repetição utilizando sons e imagens para prover feedback sobre a execução de
algoritmos.
1.2.2 Objetivos Específicos
1. Pesquisar e documentar ferramentas similares;
2. Pesquisar e documentar conceitos sobre teoria musical, com ênfase no ritmo e na sua
percepção;
3. Definir um mecanismo que sirva tanto para a comparação do material produzido pelo
aluno com o que será ouvido por ele quanto para a geração de novos trechos musicais;
4. Utilizar técnicas de engenharia de software para especificar, projetar e modelar o objeto
de aprendizagem proposto;
5. Definir e produzir os artefatos musicais, tais como sons e combinações de sons que
constituirão os trechos musicais que serão utilizados em cada nível do objeto de
aprendizagem;
6. Implementar o objeto de aprendizagem SoundLoops; e
7. Gerar os LOM do SoundLoops de acordo com o modelo de referência SCORM
(Sharable Content Object Reference Model – Modelo de Referência de Objeto de
8
Conteúdo Compartilhável) e testá-lo em pelo menos um LMS (Learning Management
System – Sistema De Gerenciamento de Aprendizagem).
1.3 METODOLOGIA
As pesquisas realizadas durante o desenvolvimento deste TCC (Trabalho de Conclusão de
Curso) tiveram como fonte de informação os seguintes repositórios: ACM (Association for
Computing Machinery - Associação para Máquinas de Computação), IEEE (Institute of Electrical
and electronics Engineers - Instituto de Engenheiros Eletricistas e Eletrônicos) e Google Scholar.
Também foi utilizado o site de busca Google, na ausência de artigos e outros trabalhos nos
repositórios anteriormente citados.
Buscando obter informações e experiências de ferramentas já existentes foi realizada uma
busca por trabalhos similares. A similaridade neste TCC se refere a uma ou várias características de
outra ferramenta que de alguma forma são semelhantes às do OA proposto neste trabalho. Foram
pesquisadas ferramentas com objetivos similares ao do OA proposto (neste caso o propósito de
ensinar loopsou o ensino de algoritmos em geral); ferramentas que além de ensinar loops ou
algoritmos o fizessem por meio da música; ferramentas que além de ensinar pudessem ser
consideradas como jogo, assim como o OA proposto; e ferramentas que pudessem colaborar com a
idealização do funcionamento ou da interface do OA proposto.
Para encontrar ferramentas similares foi definido o seguinte conjunto de palavras-chave
relacionadas ao trabalho: ensino de programação, ensino de algoritmos, metodologias de ensino de
programação, ensino de programação usando música, ensino de laços de repetição, music learning
programming, sound learning programming, learning object programming e learning
programming. Através destas foi possível encontrar alguns trabalhos similares descritos adiante
neste TCC. Foi necessário o uso dos termos no idioma inglês pela dificuldade em encontrar
trabalhos publicados em português e que apresentem um alto nível de similaridade com o trabalho
proposto neste TCC. Além da busca por meio das palavras-chave definidas não foi usada nenhuma
técnica mais específica, como a revisão sistemática.
Foi escolhida uma modelagem orientada a objetos utilizando alguns dos diagramas UML
(Unified Modeling Language – Linguagem Unificada de Modelagem) para modelar o sistema. Os
diagramas escolhidos foram: diagrama de classes, diagrama de sequência, diagrama de atividades e
9
casos de uso. A ferramenta utilizada na produção dos diagramas foi o EA (EnterpriseArchitect), que
possibilita a criação e integração dos mesmos em um único projeto.
Para a implementação do objeto de aprendizagem foi utilizada a ferramenta Adobe Flash
Professional CS5 em conjunto com o ambiente de programação FlashDevelop (versão 3.2). O Flash
CS5 foi utilizado com fins de desenho e integração do código com a interface, enquanto toda a
programação foi feita utilizando o FlashDevelop e compilado no compilador do Flash CS5.
Após a implementação o objeto de aprendizagem foi empacotado nos padrões SCORM 1.2
utilizando a ferramenta eXeLearning. Em seguida testado no LMS Moddle, porém não foram
realizados testes com usuários. Testes relacionados à influência do SoundLoops na aprendizagem
não foram realizados neste TCC.
1.4 ESTRUTURA DO TRABALHO
No primeiro capítulo deste trabalho é oferecida uma visão geral. Primeiramente é feita uma
introdução com o objetivo de dar um breve panorama das recentes pesquisas na área de Ensino de
Algoritmos e Programação, logo em seguida apresenta-se uma definição do problema a ser
solucionado neste trabalho e a solução proposta. Também fala-se neste capítulo sobre os objetivos
deste trabalho e a metodologia utilizada para realização dos mesmos.
O segundo capítulo preocupa-se em definir os conceitos acerca do desenvolvimento deste
trabalho, sendo eles: ensino de programação, formas de visualização, inteligências múltiplas,
elementos musicais, objeto de aprendizagem, SCORM e LMS. Em seguida é apresentado o relato
da pesquisa feita sobre trabalhos similares analisando e comparando-os com o trabalho que será
desenvolvido neste TCC.
O terceiro capítulo descreve o desenvolvimento do sistema proposto neste trabalho. Este
capítulo também apresenta os diagramas UML que descrevem o funcionamento do sistema e os
elementos musicais envolvidos. Neste capítulo também são discutidos a forma de representação dos
trechos musicais e o processo de empacotamento do objeto de aprendizagem no padrão SCORM.
Ainda neste capítulo são apresentadas as ferramentas utilizadas durante o processo de
desenvolvimento e por fim os problemas encontrados durante o desenvolvimento.
O quarto e último capítulo apresenta as conclusões deste trabalho, relacionando os objetivos
específicos com os respectivos resultados obtidos durante o desenvolvimento deste trabalho.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo inicialmente são discutidos os pontos principais sobre o ensino de
programação, tais como: a sua importância, as dificuldades de ensino e aprendizagem, os tópicos
ensinados e como são ensinados. Em seguida fala-se das várias formas de visualização de
algoritmos adotadas pelas diferentes ferramentas existentes no campo atualmente. Discute-se
algumas das semelhanças entre o OA proposto neste trabalho e as ferramentas citadas, e ao final
explica-se como é a forma de visualização adotada pelo OA desenvolvido.
Em seguida são abordados os conceitos sobre a teoria das inteligências múltiplas, além do
conceito a relação da teoria com a sugestão proposta por este trabalho. Na Sessão 2.4 são
brevemente abordados os elementos musicais envolvidos neste trabalho, e de forma um pouco mais
aprofundada o ritmo. Ainda neste capítulo são definidos os conceitos sobre os LMSs, o modelo de
referência SCORM e OAs, pois um dos objetivos específicos deste trabalho é testar o OA
desenvolvido em pelo menos um LMS.
Por fim, estão descritos os trabalhos similares. São analisadas as características pertinentes
em relação a sua utilização, finalidade e similaridade com o OA proposto. Ao fim é apresentada
uma tabela comparativa que relaciona os trabalhos analisados e o OA desenvolvido neste trabalho.
2.1 ENSINO DE PROGRAMAÇÃO
De acordo com o currículo guia oferecido pela Sociedade Brasileira de Computação (SBC,
2003) e as diretrizes do MEC (BRASIL, 2006, p. 5) para os cursos das áreas de Computação e
Informática, as disciplinas algoritmos, estruturas de dados e linguagens formais devem fazer parte
do currículo dos cursos.
Segundo Stroustrup (2009) a programação possui papel fundamental na formação de um
profissional da computação, pois este conhecimento auxilia na compreensão sobre como o
computador funciona. Este autor também afirma que para se idealizar algo no computador sempre
será necessário uma linguagem de programação, mesmo que na maior parte dos casos estejamos
lidando de forma implícita com esta linguagem. O autor ainda enfatiza a importância do sólido
conhecimento em programação não somente como um pré-requisito durante a graduação, mas
também na grande necessidade destes conhecimentos no mercado de trabalho mundial.
11
Santos e Costa (2006) afirmam que a programação é um dos assuntos principais do curso de
Computação, seu conteúdo abrange também os conceitos, os princípios e os modelos de
programação e o estudo de estruturas de dados e de métodos de classificação e pesquisa de dados.
Ainda é mencionado pelos autores a importante finalidade da programação de concretizar produtos
de software, que nada mais são do que passos para a solução de um problema transformados por
vários conhecimentos em um programa de computador capaz de solucionar este problema.
Beaubouef e Mason (2005) mencionam índices de desistência entre 30% e 40% nos cursos
de Ciência da Computação em várias universidades. Muitos dos estudantes matriculam-se sem o
devido conhecimento sobre os assuntos abordados e campos de atuação da profissão. Outros
estudantes ainda não possuem os pré-requisitos necessários, especialmente lógicos e matemáticos.
Por estes e ainda outros motivos envolvendo principalmente os desafios impostos no aprendizado
de algoritmos e programação, os estudantes ao longo dos primeiros semestres acabam
desmotivados, decidindo migrar para outras áreas de conhecimento.
Alguns dos sistemas e alternativas propostas para mudança desse cenário são: a) o uso da
ferramenta LEGO Mindstorms com objetivo de aumentar a motivação e interesse de estudantes em
ingressar nos cursos de computação; b) o jogo Wu’s Castle com objetivo de auxiliar o ensino de
algoritmos e programação (mais especificamente arrays e loops); c) a ferramenta Alice também
com objetivo de auxiliar o ensino de algoritmos e programação porém de forma mais abrangente; d)
e ainda outros que serão mencionado adiante neste trabalho. Seguindo uma outra vertente na busca
pela melhoria do ensino de programação, Ynoguti (2005) propôs o uso do método cartesiano de
dividir um problema complexo em vários problemas de simples resolução, também conhecido pelo
nome de método dos refinamentos sucessivos.
Este trabalho é mais uma alternativa que busca melhorar o ensino de programação, mais
especificamente o tópico laços de repetição. Busca-se explorar as possibilidades oferecidas pela
música como meio de ativar um maior número de inteligências durante o aprendizado. Com isso
espera-se promover uma melhor compreensão do conteúdo abordado. É possível também que haja
um significativo aumento na motivação de alunos com afinidade pela música.
12
2.1.1 Tópicos Fundamentais
Koffman, Miller e Wardle (1984) sugerem alguns tópicos fundamentais para os cursos de
computação que podem ser estudados no primeiro semestre de curso. Os itens a seguir não estão
organizados na ordem em que são lecionados:
1. Estratégias para solução de problemas – divisão de problemas, solução por analogia,
transformar uma solução específica de um problema em uma solução generalizada;
2. Análise de problemas – entender o problema, identificar os dados de entrada, e descreve
os dados de saída requeridos;
3. Representação de algoritmos – pseudo códigos e técnicas gráficas;
4. Verificação de algoritmos – teste de mesa e teste de dados;
5. Estrutura de controle – seqüencial, iterativa, e estrutura condicional;
6. Subprogramas – funções e procedimentos, parâmetros, escopo de variáveis, aninhamento
de funções, e recursividade;
7. Tipos de dados escalares– tipos primitivos de dados: inteiro, real, booleano, e caractere;
aritmético, booleano, e operações relacionadas a esses tipos de dados;
8. Tipos de dados estruturados– vetores (arrays), vetor de caracteres (string), e estruturas
genéricas de dados;
9. Projeto de algoritmos – abstração de procedimentos, abstração de dados, projeto top-
down, refinamentos sucessivos, ocultamento de informação (encapsulamento), e projeto
top-down versus projeto bottom-up;
10. Codificação – utilização de declarações de controle estruturado, e estilo de programação
incluindo identação e escolha de nomes de identificadores apropriados;
11. Corretude de programa – geração de dados de teste, técnicas de depuração incluindo
comandos de saída, teste top-down versus teste bottom-up;
12. Técnicas de documentação – comentários;
13. Estruturas de dados (se suportado pela linguagem) – conjuntos, arquivos, e alocação
dinâmica de listas encadeadas;
14. Algoritmos – busca e organização;
13
15. Análise de algoritmos – tempo de busca linear a logarítmico, e tempo de ordenação n² e
nlog; e
16. Verificação do programa – loop invariantes.
Os autores deixam claro que esta é apenas uma sugestão e que existe a preferência de
algumas universidades por lecionar alguns dos tópicos em semestres mais avançados, isso pode
variar de acordo com o interesse e filosofia de cada instituição.
Portanto é possível chegar a conclusão de que os índices de reprovação e desistência
mencionados por Beaubouef e Mason (2005) são decorrentes de dificuldades encontradas em um ou
mais tópicos listados anteriormente.
2.1.2 Tópicos Considerados Difíceis
Dale (2006) identificou os tópicos considerados pelos instrutores como os mais difíceis de
serem ensinados. A pesquisa realizada pelo autor deixou em aberto para que os instrutores se
expressassem do modo que preferissem por conta disso diferentes termos foram usadados para
referênciar os mesmos conteúdos e tópicos não esperados surgiram. Os tópicos identificados foram
classificados pelo autor em quatro categorias, sabe-se:
1. Resolução de problemas e Design: categoria esta que se referencia a tópicos
relacionados a algoritmos e da forma de estruturar a solução para o problema proposto;
2. Tópicos Gerais de Programação: esta categoria agrega tópicos específicos da construção
do código e da linguagem de programação tais como: loops, arrays, passagens por
parâmetro, recursividade entre outros;
3. Object-Oriented Constructs: esta categoria abrange os conceitos de programação
orientada a objetos como um todo, alguns exemplos: objeto, classe, polimorfismo,
hierarquia e outros; e
4. Maturidade dos Alunos: esta última categoria agrega tópicos diretamente relacionada
com os próprios alunos e seus prévios conhecimentos, portanto não relacionados as
disciplinas mas que também foram citados durante a pesquisa. Muitos dos instrutores
sentem a necessidade de ensinar tópicos como por exemplo: gerenciamento do tempo de
estudo, o valor do esforço, formular o algoritmos antes de codificá-lo, como estudar e
14
ainda outros. Fato ainda relevantes nesta categoria é a falta de preparo dos estudantes,
mencionado por muitos dos instrutores.
Cientes dos tópicos mais difíceis de serem ensinados, diversos autores vêm propondo
alternativas para auxiliar o aprendizado destes tópicos. Este trabalho tem o foco específico de
auxiliar o ensino de loops, considerado pelos instrutores um dos tópicos mais difíceis de serem
ensinados.
2.1.3 Ensino de loops
Barbosa (1994) identificou que a abordagem meramente expositiva para o ensino de
algoritmos e programação é um dos fatores que dificultam o aprendizado. Os seres humanos são
muito bons no processamento de informação visual, no entanto a maior parte dos conceitos
envolvidos no aprendizado de algoritmos e programação e estruturas de dados são muito abstratos e
não possuem uma representação gráfica simples (PEARS et al, 2007).
Para os alunos iniciantes é sempre desafiador compreender os conceitos envolvidos nas
disciplinas de algoritmos e programação.Durante as aulas em laboratório a atenção do professor
para a correção e esclarecimento de dúvidas é fundamental, no entanto o grande número de alunos
em sala de aula dificulta esta tarefa. O tempo dedicado a aulas laboratoriais torna-se essencial, um
dos motivos é o pouco tempo disponível para as aulas práticas. Com objetivo de satisfazer as
necessidades, promover um meio de mais fácil compreensão para os alunos e beneficiar ambos
professor e aluno durante as aulas laboratoriais, vários tipos de ferramentas vem sendo criadas.
Exemplos de tipos de ferramentas são: ferramentas de visualização, ferramentas de avaliação
automatizada e ambientes de programação para iniciantes, este podendo ser subdividido em
ferramentas de suporte a programação e microworlds (PEARS et al, 2007).
As ferramentas de visualização são uma das alternativas para alcançar os objetivos
anteriormente citados, contudo muitas pesquisas têm revelado que a simples visualização não é
suficiente para auxiliar o aprendizado de algoritmos e programação. Além de ver o que está sendo
representado de forma gráfica é necessário que o aluno entenda o contexto e o significado por trás
das imagens. Propor atividades como perguntas, predições ou experimentos durante o envolvimento
do aluno com a ferramenta de visualização é uma forma de melhorar o nível de aprendizado
(PEARS et al, 2007).
15
Segundo Pears et al (2007) as ferramentas de visualização podem ser divididas em duas
categorias, uma delas agrupa as ferramentas que visualizam a estrutura ou execução do código
passo a passo como o jogo Wu’s Castle em um de seus níveis(detalhes a respeito serão descritos na
sessão 2.7), enquanto a segunda categoria agrupa as ferramentas que focam os conceitos ou à
animação do algoritmo podendo ou não estas omitir o código ou fazer uso de um pseudocódigo,
como as ferramentas Alice, Scratch e o jogo Wu’s Castle em um de seus níveis (também descritos
na sessão 2.7).
Assim como as ferramentas Alice, Scratch e Wu’s Castle o OA proposto neste trabalho
pretende fazer uso da visualização para auxiliar o ensino de loops. A forma de “visualização”
utilizada pelo OA é musical, ou seja, este trabalho propõe fornecer feedback do tipo sonoro sobre a
execução dos loops.
2.1.4 Uso de música para ensino de algoritmos
Tatsumiet al (2009) formularam a hipótese de que incorporar o estudo da música para os
senior high school students (equivalente aos estudantes do último ano do ensino médio brasileiro)
seria uma nova e estimulante maneira de ensiná-los algoritmos e programação. Para testar esta
hipótese foi escolhida pelos autores a linguagem de programação Dolittle, uma linguagem orientada
a objetos para alunos iniciantes que permite a escrita de programas que reproduzem peças musicais
por meio de ricas estruturas de controle como loops e desvios condicionais.
A hipótese formulada pelos autores foi submetida a um teste em duas escolas japonesas. Os
autores montaram apostilas específicas para o experimento, reunindo informações sobre algoritmos,
a linguagem Dolittle e informações básicas sobre notação musical. Os objetivos estabelecidos para
os alunos que participassem do experimento foram:
1. Oferecer uma experiência prática de programação;
2. Introduzir o aluno a programação;
3. Cultivar a boa atitude do aluno em relação às questões de direitos autorais; e
4. Enriquecer a apreciação musical.
A primeira turma submetida ao experimento foi da escola Machida High School, localizada
no centro de Tokyo. O experimento nesta escola foi realizado como uma disciplina suplementar
opcional dividida em 2 aulas de 70 minutos e uma terceira de 100 minutos. Segundo os autores o
16
número de alunos inscritos para a disciplina superou as expectativas. Foram 29 alunas e 13 alunos
inscritos. Os alunos utilizaram a versão online do software Dolittle que pode ser utilizada em
qualquer navegador web com Java JRE, não sendo necessária a instalação do Dolittle nos
computadores da sala de aula.
Os conteúdos foram apresentados da seguinte forma: durante o primeiro dia de aula os
alunos foram introduzidos ao software Dolittle; no segundo dia os alunos se registraram no LMS
Moodle e tiveram acesso a atividades relacionadas a notação musical; e durante o terceiro
transcreveram suas músicas favoritas utilizando o Dolittle.
A segunda turma a participar do experimento foi da escola Momodani High School
localizada na cidade de Osaka. Neste experimento todos os 20 alunos da turma participaram como
uma disciplina obrigatória do ano letivo. Algumas mudanças foram feitas com relação ao
experimento anterior, os autores utilizaram uma versão revisada das apostilas adicionando alguns
aspectos requisitados pelos alunos participantes do experimento anterior. E neste segundo
experimento os alunos utilizaram a versão stand-alone do programa Dolittle que permitiu que seus
programas fossem salvos e carregados de forma simples. A ordem dos conteúdos apresentados foi
mantida a mesma para ambos os experimentos.
Segundo os autores é possível destacar os seguintes resultados:
1. A abordagem musical conseguiu promover um ambiente de aprendizado divertido, os
alunos puderam encontrar diversão no estudo de programação;
2. Houve uma perceptível mudança de atitude, os alunos passaram a construir programas
avidamente;
3. Os alunos compreenderam que os softwares existentes são produto de esforços de muitas
pessoas;
4. Muitas alunas, que tendem a evitar disciplinas que envolvem matemática, ciências e
informática, foram atraidas pela música. Um dos professores participantes do
experimento ressaltou que foi a primeira vez que estudantes do gênero feminino
frequentaram suas aulas. Um resultado inesperado segundos os autores, afirmam que a
razão pode ser o fato de muitas das alunas no Japão frequentaram aulas de piano quando
mais jovens.
5. Os alunos perceberam a importância dos direitos autorais; e
17
6. O custo da abordagem se mostrou muito inferior se comparado a abordagens usando
robôs por exemplo, assim como também não foi necessário nenhum espaço adicional
além da própria sala de aula.
Assim como na pesquisa realizada durante o desenvolvimento deste TCC, a música se
mostrou um tema interessante para os alunos de computação. Por esse motivo, pode-se chegar a
conclusão de que a música pode ser um bom ambiente para o aprendizado dos alunos de
computação.
2.2 FORMAS DE VISUALIZAÇÃO DE ALGORITMOS
No decorrer do surgimento das ferramentas de visualização de algoritmos diferentes
abordagens foram sendo adotadas. A ferramenta de visualização chamada Alice busca diminuir a
abstração dos conceitos relacionados à programação orientada a objetos oferecendo ao aluno uma
representação visual do que ele esta programando. A ferramenta Alice oferece ao aluno um
micromundo 3D animado, e por meio deste mundo o aluno pode ver o resultado das suas ações.
Portanto ao criar um objeto da classe “coelho” por exemplo, o aluno logo perceberá que um coelho
foi criado em seu mundo.
De forma semelhante ao Alice, a ferramenta Scratch faz uso de animações 2D para
representar um micromundo. O Scratch busca diminuir a abstração dos conceitos de programação
representando de forma gráfica objetos e suas ações em um mundo virtual. Segundo Xinogalos
(2003) os micromundos oferecidos por estas ferramentas são capazes de aproximar o modelo
mental dos estudantes das características reais de uma linguagem de programação.
Outra abordagem possível é adotada pelo jogo Wu’s Castle, que mostra passo a passo como
acontece a execução de um algoritmo, as mudanças das variáveis e os fluxos percorridos durante a
execução. O aluno pode “andar” pelo código e observar as variáveis, prever os acontecimentos,
mudanças de valores, e durante as iterações são feitas perguntas a respeito do código e das variáveis
para determinar se ele pode passar ou não pelo desafio.
A ferramenta Jeliot 3 é um ambiente de programação em Java que automaticamente cria a
partir do código nela escrito uma animação mostrando a execução de cada instrução. A forma como
o Jeliot 3 apresenta as estruturas de programação é propositalmente semelhante a notação utilizada
nos diagramas UML (Unified Modeling Language), e por meio de setas o Jeliot 3 indica de onde
18
surgem novos elementos. O Jeliot 3 também faz referência ao código executado naquele instante
destacando-o, uma das características que este trabalho pretende implementar (MORENO et al,
2004; CARSON; PARBERRY; JENSEN, 2007). A Figura 2 ilustra a interface do Jeliot 3:
Figura 2. Interface do Jeliot 3
Fonte: Adaptado de http://cs.joensuu.fi/jeliot/description.php.
MatrixPro é outra ferramenta de visualização de algoritmos com uma abordagem diferente,
esta é uma ferramenta para instrutores criarem suas animações de acordo com as necessidades. A
MatrixPro permite apenas criar animações 2D das estruturas de dados conhecidas na programação.
Após escolher uma das estruturas de dados disponíveis o usuário cria as animações por meio de
uma interface gráfica. Estas animações são criadas quadro-a-quadro, por tanto são bastante flexíveis
na criação e reprodução das mesmas durante as aulas (CARSON; PARBERRY; JENSEN, 2007).
Este trabalho propõe explorar o entendimento dos algoritmos e estruturas de programação
por meio de uma representação musical. Da mesma forma que outras ferramentas conseguem
19
mostrar uma representação gráfica de vários conceitos envolvidos no ensino de programação
(alguns anteriormente exemplificados, tais como classes, objetos, métodos e outros), o SoundLoops
pretende representar os loops de forma gráfica e principalmente auditiva. A abordagem proposta
consiste em fazer com que o aluno perceba que os trechos de músicas que ele ouvirá no
SoundLoops possuem um padrão que se repete. Então, o aluno reproduzirá no SoundLoops os
trechos de música que ouviu utilizando loops musicais configuráveis, e obtendo feedback da
execução dos mesmos de forma visual e auditiva.
2.3 INTELIGÊNCIAS MÚLTIPLAS
Gardner (1995, 1999) afirma em sua teoria que a inteligência é um potencial biopsicológico
para processar informações que pode ser ativada num cenário cultural para solucionar problemas ou
criar produtos que sejam valorizados numa cultura. O autor ainda diz que todos os seres humanos
possuem desde seu nascimento um conjunto de nove inteligências, sabe-se: lógivo-matemática,
linguística, musical, espacial, corporal-cinestésica, interpessoal, intrapessoal, naturalista e
existencial.
O foco deste trabalho são as inteligências musical, espacial e lógico-matemática. A
inteligência musical se manifesta no reconhecimento de padrões tonais (incluindo sons de ambiente)
e na habilidade para discernir timbres e ritmos. Também é responsável pela capacidade de executar
e compor padrões musicais. É fortemente desenvolvida em músicos, compositores e maestros.
A inteligência lógico-matemática é a capacidade lógica e matemática, assim como a
capacidade de raciocínio científico ou indutivo. Esta inteligência envolve também a capacidade de
reconhecer padrões, de trabalhar com símbolos abstratos e discernir relacionamentos ou ver
conexões entre peças separadas ou distintas. Esta inteligência pode ser melhor observada em
ciêntistas, matemáticos e filósofos.
Por fim, a inteligência espacial manifesta-se através da capacidade de formar modelos
mentais (imagens) e operar com tais imagens. Estas imagens não são necessariamente visuais,
podem ser construídas através do tato. É predominante em arquitetos, navegadores, jogadores de
xadrez e cartógrafos.
20
Durante a vida estas inteligências podem se desenvolver ou não, ou ainda regredir. Cada
indivíduo vai ser influenciado pelo meio em que vive de forma diferente, fazendo com que cada
indivíduo possua as inteligências em níveis diferentes (GARDNER, 1999).
Gardner (1995) afirma que as inteligências múltiplas são independêntes em grau
significativo entre si. Para explicar esta independência o autor se apoia nos casos de lesão cerebral,
em que existe a perda de determinadas capacidades enquanto outras permanecem intactas. Portanto,
segundo o autor as inteligências não interferem umas nas outras.
No entanto, as inteligências agem de forma integrada (GARDNER, 1999). Pode-se tomar
como exemplo um jogador de futebol, não basta um alto nível de inteligência corporal-cinestésica,
também são necessários altos níveis de inteligência espacial para realização de bons passes e chutes
a gol, e altos níveis de inteligência interpessoal para uma relação e trabalho em equipe com seus
companheiros.
Logo, espera-se que se os alunos tenham um maior rendimento no aprendizado se forem
ensinados utilizando um maior conjunto de inteligências. O resultado pode ser ainda melhor se as
inteligências mais desenvolvidas de cada aluno fossem ativadas durante o ensino, sendo esta a idéia
de um escola ideal para Gardner (1995), o ensino é feito de maneira diferênciada para cada aluno.
Tradicionalmente as aulas são lecionadas de forma verbal ou através de leituras. Neste caso,
os alunos apenas fazem uso da sua inteligência linguística. Este trabalho propõe o uso de um
conjunto maior de inteligências durante o aprendizado de laços de repetição. Por meio do objeto de
aprendizagem proposto pretende-se fazer com que o aluno utilize as inteligências musical, espacial,
e lógico-matemática, propondo desafios que envolvam a percepção musical e a programação.
Durante a resolução dos exercícios propostos pelo SoundLoops espera-se que o aluno utilize
a inteligência musical para diferenciar os instrumentos através dos timbres e discernir os ritmos de
cada instrumento. Também espera-se que a inteligência musical se manifeste em conjunto à
inteligência lógico-matemática para que o aluno perceba que existem padrões musicais e que os
mesmos se repetem um determinados número de vezes. E para mapear os padrões musicais ouvidos
e construir os compassos de forma visual espera-se que o aluno utilize a inteligência espacial.
O foco é criar um ambiente de aprendizagem do interesse dos alunos, que segundo a
pesquisa realizada com os alunos durante este trabalho, a música é um destes ambientes. Com o
desenvolvimento do SoundLoops espera-se proporcionar este tipo de ambiente.
21
2.4 ELEMENTOS MUSICAIS
Segundo Med (1996), música é a combinação de sons simultâneos e sucessivos, com ordem,
equilíbrio e proporção dentro do tempo. Os sons mencionados pelo autor se referem aos elementos
básicos que formam a música. Estes elementos são: melodia, harmonia e ritmo. A melodia é
formada por um conjunto de sons tocados em ordem sucessiva. Uma melodia pode ser ilustrada por
uma seqüência de notas quaisquer. A harmonia é formada por um conjunto de sons tocados
simultaneamente, e pode ser ilustrada por uma seqüência qualquer de acordes (notas tocadas
simultaneamente). O último elemento é definido pelo autor como a ordem e proporção em que estão
dispostos os sons que constituem a melodia e a harmonia.
Dentro da pulsação que são organizados os ritmos, portanto, quanto mais rápida a pulsação
mais rápido o ritmo. A pulsação é uma alternância de acentos fortes e fracos, uma batida constante
que pode ser dividida em várias frações de iguais durações. É comum a divisão da pulsação em duas
e quatro partes, que alternam entre batidas fortes e fracas (PALMER; KRUMHANSL, 1990). Um
exemplo comum são aulas de dança em que conta-se 1, 2, 3, 4... etc. Esta contagem é o
acompanhamento da pulsação da música, neste exemplo as contagens 1 e 3 representam os acento
forte, enquanto as contagens 2 e 4 representam os acentos fracos.
Palmer e Krumhansl (1990) descrevem a percepção musical como um processo que envolve
a transformação e organização do material musical por meio da referência a um sistema mais
abstrato de conhecimento sobre a estrutura musical. Este sistema abstrato de conhecimento muitas
vezes representa regularidades ocultas encontradas na própria cultura musical do ouvinte, como por
exemplo um determinado sistema tonal. E por meio destas estruturas mentais podem ser
compreendidos com maior facilidade aspectos globais da estrutura musical, e levar a expectativas
sobre eventos futuros.
Quando ouvimos uma música estamos ouvindo a melodia e harmonia nela presentes, mas o
que mais percebemos e sentimos são a pulsação e o ritmo da música. Por esta nossa capacidade
inata de sentir e interpretar as batidas fortes e fracas em um padrão rítmico, somos capazes de nos
mover e dançar no ritmo da música (PHILLIPS-SILVER; TRAINOR, 2005). Por esse motivo
decidiu-se focar este trabalho no ritmo. A bateria foi escolhida como instrumento que tocará os
trechos no SoundLoops pelo fato de ser o principal instrumento rítmico em bandas e possuir um
som simples, evitando assim envolver melodia e harmonia nos trechos. Para associar o tema do
22
aprendizado com o instrumento, foi decidido usar os sons de uma bateria eletrônica e fazer uso da
metáfora “bateria eletrônica programável” para o SoundLoops.
2.5 OBJETOS DE APRENDIZAGEM
A idéia principal dos objetos de aprendizagem é dividir o conteúdo educacional em
pequenas partes e transformá-las em objetos de aprendizagem que podem ser reutilizados em
diferentes ambientes de aprendizagem (Wiley, 2000).
Duas definições para objetos de aprendizagem são mais conhecidas e aceitas com
divergências entre si. Wiley (2000) descreve um objeto de aprendizagem como todo e qualquer
recurso digital que possa ser reutilizado para apoiar o aprendizado. Esta definição é menos
abrangente e apenas engloba recursos digitais. Por outro lado, o IEEE Learning Objects Metadata
Workgroup (2002) descreve objetos de aprendizagem como todo e qualquer recurso, digital ou não
digital, que possa ser utilizada, reutilizada ou referenciada durante o aprendizado com auxílio de
tecnologias. Esta última definição abrange um campo muito maior de recursos neste caso
considerados objetos de aprendizagem.
Além da característica chave de reutilização que permite que os objetos de aprendizagem
sejam usados em ambientes diferentes e com propósitos diferentes, existem outras características
desejáveis em um objeto de aprendizagem citadas por Wiley (2002), sabe-se:
1. Tradicionalmente o conteúdo é dividido em horas de estudo, objetos de aprendizagem
devem possuir a característica de dividir o conteúdo em pequenas frações de 2 à 15
minutos de estudo;
2. Objetos de aprendizagem devem ser independentes uns dos outros, podendo ser tomados
de forma independente;
3. Poder ser agregado, objetos de aprendizagem podem ser agrupados em grandes coleções
de conteúdo; e
4. Devem ser etiquetados com metadados, isso permite uma fácil busca e identificação do
objeto de aprendizagem nos repositórios.
Para facilitar o acesso e a utilização dos objetos de aprendizagem foram criados repositórios
para guardar os objetos de aprendizagem. Um LOR (Learning Object Repositories - Repositório de
Objetos de Aprendizagem) é um banco de dados eletrônico que mantém uma coleção de objetos de
23
aprendizagem que permite o acesso, a utilização e a reutilização dos objetos de aprendizagem nele
mantidos (PRAKASH; SAINI; KUTTI, 2009).
Seguindo as características de um objeto de aprendizagem, foi desenvolvido um objeto de
aprendizagem com escopo do conteúdo restrito a apenas loops. Deste modo, dividindo o ensino de
programação em partes e restringindo a apenas um tópico, podendo assim ser agregado a uma
coleção de objetos que auxiliam o ensino de programação. Portanto, o objeto de aprendizagem
desenvolvido neste trabalho é independente de uma coleção de outros objetos de aprendizagem, e
pode ser utilizado sem estar agregado a uma coleção.
2.6 SCORM E LMS
De acordo com Ellis (2009) LMSs podem ser definidos como uma ferramenta que
automatiza a administração, monitoramento, e notificação de eventos de capacitação. O autor ainda
destaca algumas das principais funcionalidades que caracterizam um LMS, tais como: centralização
e automatização da administração, uso de auto-atendimento e serviços auto-guiados, agilidade ao
receber e enviar conteúdo de aprendizagem, permitir personalizar e reutilizar o conteúdo de
aprendizagem, entre outras. Os LMSs podem ser softwares de acesso via internet, por esse motivo
muitas vezes utilizados em instituições educacionais como complemento as aulas em sala.
Em conjunto a um LMS acessado via um navegador web pretende-se utilizar o SCORM, que
segundo a ADL (2008) é um conjunto de normas e especificações para qualquer conteúdo de ensino
e aprendizagem via internet. Estas normas e especificações referem-se a como o conteúdo pode ser
empacotado para ser transferido e importado por um LMS, o formato deste empacotamento é
chamado Package Interchange Format (Pacote no Formato de Intercâmbio). São utilizados arquivos
XML para armazenar todas as informações que o LMS precisa saber sobre o conteúdo empacotado.
O SCORM também define como este conteúdo deve se comportar após ter sido aberto pelo LMS,
fornecendo métodos para tratar o conteúdo em uma parte da janela do LMS ou uma nova janela.
Toda a comunicação feita entre o LMS e o conteúdo empacotado é feita através dos métodos
fornecidos pelo SCORM, bastando que o LMS tenha suporte e seja implementado a devida
chamada de um método JavaScript.
Após a implementação do SoundLoops foram preparados os metadados necessários para
testá-lo em um LMS utilizando os padrões definidos pelo SCORM. No capítulo de
desenvolvimento é descrito como foi feito este procedimento com maiores detalhes.
24
2.7 TRABALHOS SIMILARES
2.7.1 Alice 2.0
O Alice é uma ferramenta educacional para o ensino de algoritmos e programação. O Alice
oferece ao aluno um ambiente de programação visual, onde arrastando e encaixando objetos o aluno
pode popular um mundo com objetos tridimensionais. Podem ser inseridos no mundo objetos e
eventos programáveis de acordo com a vontade do aluno, com algumas limitações impostas pela
ferramenta. No Alice1 também existe a possibilidade de programar a interação entre os objetos e o
mundo via teclado e mouse (POWERS; ECOTT; HIRSHFIELD, 2007).
Assim como no OA desenvolvido, o software Alice abstrai os conceitos de programação.
Por exemplo, no Alice o aluno utiliza variáveis, mas não existe a necessidade de declará-las
explicitamente. No Alice as variáveis são, na verdade, atributos dos objetos que podem ser
colocados no mundo virtual. Para cada objeto do mundo virtual o aluno tem a sua disposição um
conjunto de ações possíveis. Um exemplo seria a ação “pular”, onde o aluno determina o valor da
variável “altura do pulo” por meio da interface gráfica do Alice (POWERS; ECOTT;
HIRSHFIELD, 2007).
O programa Alice tem um foco menos específico do que o OA desenvolvido neste trabalho,
pois abrange a criação de algoritmos, estruturas condicionais, laços de repetição, recursividade,
conceitos de orientação a objetos entre outros.
A abstração dos aspectos fundamentais da programação pode se tornar um problema. A
medida em que o aluno migra das facilidades do Alice para a realidade das linguagens de
programação baseadas em texto (como Java e C++) ele encontrará várias dificuldades. Alguns dos
desafios encontrados são: ambiente de desenvolvimento, sintaxe e erros decorrentes da mesma,
declaração e inicialização de variáveis, tamanho de código entre outros (POWERS; ECOTT;
HIRSHFIELD, 2007).
Um fator importante a ser destacado é que o Alice possui erros sintáticos assim como as
linguagens de programação, porém em número muito reduzido, pois muitos são impossíveis de
acontecer. Na ocorrência de um erro sintático o Alice exibe mensagens de erro para tentar auxiliar o
1http://www.alice.org/
25
aluno a solucionar o problema. Entretanto, não nem sempre é fácil interpretar as mensagens de erro
e utilizá-las para corrigir o problema. A ausência de uma execução passo a passo do programa pode
dificultar a tarefa de encontrar os erros. A Figura 3 ilustra a interface do Alice.
Figura 3. Interface do Alice
Fonte: Adaptado de Powers, Ecott e Hirshfield (2007).
2.7.2 Wu’s Castle
Wu’s Castle é um jogo desenvolvido com a ferramenta RPG Maker XP, um software de
desenvolvimento de role-playing games (jogos de interpretação de personagem) em duas
dimensões. Os códigos exibidos no jogo para o aluno, assim como a sintaxe utilizada durante o
jogo, são todos na linguagem C++. O jogo possui dois tipos de interação: uma em que o jogador
(aluno) manipula arrays (um dentre os vários tipos de estruturas de dados) através de for loops (um
tipo específico de laço de repetição) e outra em que o jogador caminha e interage durante a
execução de laços de repetição aninhados acompanhando a mudança das variáveis em tempo de
execução. O SoundLoops oferece ao aluno um contato com arrays e loops de forma visual, de
forma semelhante com uma das atividades do Wu’s Castle (EAGLE; BARNES, 2009).
26
O jogo Wu’s Castle é dividido em três níveis, sendo cada um deles subdivididos em
missões. Tanto no primeiro quanto no terceiro nível o aluno controla uma criatura mágica chamada
Machina. Esta criatura é controlada através de trechos de código selecionados pelo aluno
instruindo-a para a realização de determinadas tarefas, sendo que estas tarefas podem variar a cada
missão. O aluno manipula os loops dentro do jogoatravés da seleção de uma entre as opções
oferecidas. Além disso, também é possível alterar os parâmetros dos loops. A Figura 4 representa o
nível três do jogo Wu’s Castle, onde o jogador interage com loops aninhados (EAGLE; BARNES,
2008).
Figura 4. Imagem do nível três do jogo Wu’s Castle
Fonte: Adaptado de Eagle e Barnes (2008).
Durante o segundo nível o aluno é colocado dentro de estruturas que representam loops
aninhados para observar visualmente os passos da execução. Nesse nível o objetivo é responder as
perguntas feitas em momentos aleatórios da execução do código, tais como “qual é a variável que
representa o contador do loop em execução?”. A qualquer momento é permitido que o aluno veja o
código que está sendo executado assim como a linha de código executada naquele instante e o valor
27
de variáveis alteradas naquele momento, muito semelhante a uma execução passo a passo de alguns
softwares de desenvolvimento. Assim como o OA desenvolvido neste trabalho o jogo Wu’s Castle
também foca nos loops, porém de uma forma apenas visual. A ferramenta desenvolvida neste
trabalho, o SoundLoops, proporciona um feedback semelhante, porém adicionando feedback do tipo
sonoro à execução dos loops (EAGLE; BARNES, 2008). A Figura 5 ilustra o segundo nível:
Figura 5. Imagem do nível dois do jogo Wu’s Castle
Fonte: Adaptado de Eagle e Barnes (2008).
A divisão em níveis também acontece no OA desenvolvido neste trabalho, de forma a
gradualmente exigir mais complexidade nas soluções dos algoritmos. No entanto, durante o uso
doSoundLoops não são exibidos códigos textuais. O foco principal do OA desenvolvido é auxiliar a
compreensão dos loops, portanto muitos dos detalhes de programação foram abstraídos.
Resultados apontados por Eagle e Barnes (2008, 2009) revelam que alunos que jogaram o
Wu’s Castle como complemento às aulas obtiveram mais auto-confiança e domínio sobre os tópicos
arrays e loops.
28
2.7.3 Scratch 1.4
O Scratch é um ambiente educacional para iniciantes em programação com idade a partir de
8 anos. O Scratch permite ao aluno construir algoritmos utilizando uma linguagem de programação
visual muito similar a do Alice descrito anteriormente. Para facilitar a programação e evitar erros
sintáticos o Scratch possui diferentes formas e cores em seus elementos de programação (laços de
repetição, estruturas condicionais, variáveis). Através dessas cores e formas fica claro e intuitivo
para os alunos como estruturar o algoritmo e onde as variáveis podem ser utilizadas (MALAN;
LEITNER, 2007).
Durante a execução não existe uma execução passo a passo para que o aluno tente encontrar
erros sintáticos que possam vir a acontecer, porém é possível acompanhar o valor das variáveis
durante a execução. O feedback pode ser tanto de forma visual como sonora, diferente do Alice ele
apresenta um cenário 2D animado (MALAN; LEITNER, 2007). A Figura 6 ilustra a interface do
programa Scratch:
Figura 6. Interface do Scratch
Fonte: Adaptado de http://scratch.mit.edu/
29
Através das estruturas de programação disponíveis no Scratch é possível realizar a tarefa de
reproduzir um trecho de música, porém identificou-se que isso requer um nível entre intermediário
e avançado. Como esperado essa não é a finalidade do Scratch, e algumas experiências com o
software permitiram definir algumas maneiras de facilitar a execução de sons e oferecer feedback
sobre a execução (MALAN; LEITNER, 2007). A seguir mostra-se uma lista de aspectos que podem
facilitar a reprodução de trechos musicais:
1. Separação do algoritmo em compassos;
2. Barra de tempo visível exibindo os segundos e a localidade do compasso sendo
desenvolvido pelo aluno no momento atual;
3. Feedback fazendo um acompanhamento visual por tempos em cada compasso; e
4. Opção de ouvir apenas os instrumentos desejados quando o trecho for reproduzido;
O SoundLoops possui semelhanças com o Scratch na interface. Da mesma forma que o
aluno arrasta os componentes para montar os algoritmos no Scratch, acontece no SoundLoops. A
diferença é que o SoundLoops foca-se nos loops e os algoritmos são montados para reproduzir
trechos musicais, portanto o feedback acontece de forma visual e principalmente auditiva.
2.7.4 Fruity Loops Studio
O Fruity Loops Studio (foi analisada a versão 9.0.1) é um aplicativo para produção de
músicas de qualquer gênero. Possui uma grande variedade de instrumentos e efeitos a disposição.
Cada instrumento adicionado possui diversas características como timbre, volume (intensidade
sonora), efeitos, ritmo e ainda outros.
O Fruity Loops Studio subdivide a música em pequenas partes e cada uma representa uma
pequena fração de tempo, estas partes são representadas graficamente por botões que permitem a
manipulação do usuário. Por meio de cliques nos botões o usuário cria os ritmos desejados. A troca
entre as tonalidades escuras e claras representa quando o instrumento não deve ser tocado (silêncio)
e quando ele deve ser tocado, respectivamente. Neste software cada instrumento (ou parte do
instrumento no caso da bateria) é representado em uma faixa horizontal diferente. Na Figura 7
pode-se ver 4 faixas, cada uma delas representando uma peça ou parte diferente do instrumento
bateria. O OA desenvolvido neste trabalho faz uso de um mecanismo semelhante para sua interface.
A Figura 7 ilustra a interface para a criação dos ritmos no Fruity Loops.
30
Figura 7. Interface do Fruity Loops para criação dos ritmos
Na Figura 7 os nomes dos instrumentos estão dispostos ao lado esquerdo, seguindo na
horizontal as subdivisões que formam seu ritmo. Abaixo de todos os instrumentos está uma luz que
acompanha a reprodução da música, mostrando assim qual das subdivisões de cada um dos
instrumentos está sendo reproduzida no momento.
31
Tabela 1. Tabela comparativa das características das ferramentas similares e do SoundLoops.
Ferramenta / Características
Tipo e nível de abstração da linguagem utilizada
Presença de um debugger
Tipo de feedback
Alice 2.0 Alto nível de abstração. Uso de uma linguagem visual própria.
Não existe um debugger na versão analisada, porém pode ser algo que se implementado ajude os alunos a encontrar seus erros.
O feedback acontece de forma visual (3D) e sonora. Não existe um meio de identificar qual trecho do código está sendo executado, isso poderia tornar mais fácil identificar os erros e compreender como funcionam as estruturas de programação.
Wu’s Castle Alto nível de abstração. Apresenta trechos de código de linguagens de alto nível como C++ e Java.
Em um dos níveis do jogo existe um acompanhamento passo a passo do programa, semelhante a um debugger.
O feedback acontece de forma visual (2D) e existe a possibilidade de identificar o trecho de código executado no momento.
Scratch 1.4 Alto nível de abstração. Uso de uma linguagem visual própria.
Não existe um debugger na versão analisada, porém pode ser algo que se implementado ajude os alunos a encontrar seus erros.
O feedback acontece de forma visual (2D) e sonora. Não existe um meio de identificar qual trecho do código está sendo executado, isso poderia tornar mais fácil identificar os erros e compreender como funcionam as estruturas de programação.
Fruity Loops Studio (versão 9.0.1)
Alto nível de abstração dos elementos musicais: compasso, tempo, ritmo, etc.Ele possui uma linguagem de programação bem específica: programação de ritmo em bateria eletrônica.
Não existe um debugger pois se trata de um software de produção musical.
O feedback acontece de forma sonora e visual. Além da música sendo reproduzida é possível identificar a subdivisão que está sendo reproduzida em um determinado momento.
SoundLoops Alto nível de abstração dos elementos musicais: compasso, tempo, ritmo, etc. Faz uso de uma linguagem de programação bem específica: programação de ritmo em bateria eletrônica.
Existe um debugger, porém não é controlado pelo usuário (aluno). Caso contrário durante a utilização do mesmo não seria possível perceber o ritmo da música.
O feedback acontece de forma sonora e visual. Além da música sendo reproduzida será possível identificar a subdivisão que está sendo reproduzida.
3 DESENVOLVIMENTO
Este capítulo descreve o desenvolvimento do SoundLoops. Primeiramente são mostrados os
diagramas UML, casos de uso, de classe e de seqüência,que foram utilizados para modelar o
SoundLoops. Parte da modelagem do SoundLoops foi colocada como um apêndice, entre elas estão
os requisitos funcionais, não funcionais e regras de negócio.
Em seguida apresentados os elementos musicais utilizados: o instrumento escolhido para
tocar os trechos musicais, os timbres dos instrumentos disponíveis no SoundLoops, os padrões
rítmicos e a velocidade adotada para os trechos musicais.
Em seguida é abordado um dos mais pertinentes temas do desenvolvimento do SoundLoops,
a representação dos trechos musicais. São discutidas as especificações do formato definido para o
arquivo XML utilizado para representar as estruturas musicais e organizar os níveis de dificuldade.
Ainda neste capítulo são descritos os detalhes sobre o empacotamento do SoundLoops para
os testes em um LMS. Em seguida são apresentadas as ferramentas utilizadas durante o
desenvolvimento do SoundLoops.
Por fim, são discutidos os problemas encontrados durante o desenvolvimento do
SoundLoops, assim como as medidas adotadas para contorná-los ou pelo menos minimizá-los.
3.1 DIAGRAMAS UML
Nesta sessão serão apresentados os diagramas UML que modelam o SoundLoops. O
primeiro diagrama apresentado é o diagrama de casos de uso (Figura 8), que define as ações que o
usuário poderá realizar durante o uso do SoundLoops. A seguir serão descritos alguns dos principais
casos de uso apresentados na Figura 8.
33
Figura 8. Diagrama de Casos de Uso do Aluno
O UC (Use Case – Caso de uso) 01 representa a ação do usuário de silenciar um instrumento
enquanto um trecho é tocado. Quando houver trechos com sons de mais de um instrumento o UC 01
permitirá ao usuário silenciar um dos instrumentos e se concentrar em um por vez. O UC 04 refere-
se a ação do usuário de fazer uso da interface de composição clicando nos botões e arrastando-os
para compor o trecho ouvido por ele. Os botões arrastados pelo usuário representam a ação de tocar
ou não tocar a subdivisão em que estão encaixados.
Os UCs 05 e 06 representam a ação do aluno de avançar pelos trechos e níveis de
dificuldade disponíveis no sistema, respectivamente. O UC 07 representa a ação de reproduzir o
trecho proposto para o aluno no momento. Por fim os UCs 08 e 09 representam a ação de reproduzir
o trecho programado pelo aluno e corrigir o trecho programado pelo aluno, respectivamente.
A Figura 9 apresenta os casos de uso do SoundLoops, que serão discutidos a seguir.
34
Figura 9. Diagrama de Casos de Uso do SoundLoops
O UC 01 representa a ação do SoundLoops de carregar os arquivos XMLs para memória.
Ao iniciar, o SoundLoops carrega um arquivo XML com a lista de exercícios disponíveis (mais
detalhes na sessão 421 3.4). No início de cada exercício é necessário que o SoundLoops faça a
leitura do arquivo XML que representa este exercício (mais detalhes na sessão 421 3.4) e carregue
este exercício para memória. A classe ConstrutorDeSequenciadores é a responsável por fazer a
leitura do arquivo XML correspondente ao exercício e construir um Seqüenciador que corresponde
a representação em memória do exercício. Mais adiante nesta mesma sessão será mostrado o
diagrama de classes do SoundLoops que apresenta em mais detalhes as principais classes e seu
relacionamento.
O UC 02 representa a ação do SoundLoops de indicar ao aluno de forma visual, textual e
sonora onde está o erro do aluno. Após a correção do trecho musical produzido pelo aluno o
SoundLoops exibe uma menssagem indicando onde está o erro do aluno ou parabenizando-o pelo
seu acerto. No primeiro nível de dificuldade, com apenas um instrumento, o SoundLoops exibe de
forma textual em que subdivisão está o erro e reproduz o trecho musical proposto até a subdivisão
que está errada. E enquanto o trecho musical é reproduzido o aluno tem o acompanhamento visual
de qual subdivisão está sendo reproduzida naquele momento (subdivisão em vermelho). A Figura
10 mostra a interface do SoundLoops momentos depois do botão “corrigir exercício” ter sido
clicado.
35
Figura 10. Interface do SoundLoops
Nos níveis de dificuldade 2 e 3, onde estão presentes sempre 2 e 3 instrumentos
respectivamente, apenas é mostrado uma menssagem textual para o aluno indicando em qual dos
instrumentos está a subdivisão incorreta. A decisão de mudar a forma de indicar o erro do primeiro
nível para os demais foi tomada levando em consideração que o aluno poderia encontrar a maneira
correta de fazer por tentativa e erro. Já que a subdivisão pode ser preenchida por “toca” ou
“silêncio” apenas, então bastaria tentar em todos os instrumentos alterar a subdivisão indicada pelo
SoundLoops.
Quando o erro não está na composição rítmica dos instrumentos mas sim no número de
repetições do trecho musical, o SoundLoops apenas mostra de forma textual que existe uma
36
diferença entre o número de repetições do trecho musical proposto e o número que o trecho do
aluno está repetindo. Está maneira de exibir este tipo de erro foi padronizada para todos os níveis de
dificuldade.
A Figura 11 representa o diagrama de classes SoundLoops, este diagrama apresenta as
classes do sistema e seus relacionamentos.
Figura 11. Diagrama de Classe do SoundLoops
As classes apresentadas na Figura 11 representam as classes lógicas. Foram criadas classes
específicas para representar a parte gráfica. As classes chamadas de SequenciadorView e
InstrumentoView contém cada uma um Instrumento e um Sequenciador, respectivamente. A
comunicação entre estas duas partes é feita através de eventos, seguindo o padrão de projeto
Observer.
A Figura 12 representa o diagrama de sequência da correção dos trechos produzidos pelo
aluno, este diagrama ilustra como se comporta cada classe envolvida nesta tarefa:
37
Figura 12. Diagrama de Sequência da correção dos trechos no SoundLoops
Após a solicitação de correção enviada pelo aluno a Interface vai chamar o método
“corrige” do objeto Corretor (a Figura 11 mostra todos os atributos e métodos da classe) passando
por parâmetro as composições do aluno e a do SoundLoops. Este método vai receber as
composições e compará-las, cada subdivisão (representadas por um vetor como mostra a Figura 11)
e o número de repetições. Cada trecho em memória será representado por um objeto da classe
Seqüenciador e cada instrumento presente no trecho será representado por um objeto da classe
Instrumento. No caso das composições do aluno e do SoundLoops estarem idênticas o aluno será
parabenizado e desafiado a resolver um novo trecho com maior dificuldade. Caso contrário o objeto
Corretor descobrirá onde está o erro do aluno pelo método “getPosicaoDoErro” e pedirá que o
Sequênciador toque o trecho até o local do erro para prover feedback sonoro ao aluno. Ao mesmo
tempo a Interface receberá o resultado do método “corrige” e fornecerá o feedback visual para
mostrar onde está o erro.
38
3.2 ESCRACHO
O Escracho é um interpretador de comandos desenvolvido utilizando a ferramenta Flash
CS3 e a linguagem Action Script 3. Assim como o SoundLoops o Escracho é uma ferramenta de
auxilio ao ensino de programação. O Escracho utiliza uma interface semelhante a do Scratch, em
que os alunos arrastam comandos ifs, whiles, do whiles, if elses, variáveis e outros para construir
algoritmos. Estes algoritmos são construidos pelos alunos para solucionar os desafios propostos
pelo Escracho.
Escolheu-se fazer a reutilização do código do Escracho para construir o SoundLoops. Foram
estudadas as classes do Escracho para definir quais classes seria interessante aproveitar, levando em
consideração a menor complexidade do problema a ser solucionado pelo SoundLoops. As principais
classes reutilizadas foram ProgramaScratch, ComandoCompositeScratch, RepositorioDeMatrizes e
Blinker.
A classe ProgramaScratch no Escracho representa um trecho de código para onde o aluno
pode arrastar comandos e variáveis. No SoundLoops esta classe foi adaptada para ser a
representação visual dos instrumentos e sequenciadores. Os métodos e variáveis referentes a
manipulação de variáveis e interpretação dos comandos contidos em um ProgramaScratch foram
descartados ou não utilizados.
As classes InstrumentoView e SequenciadorView do SoundLoops herdam da classe
ProgramaScratch do Escracho. No construtor de cada um destas classes são removidos os eventos
mouse_down e mouse_over que permitiam respectivamente, o aluno arrastar um ProgramaScratch
e destacar um ProgramaScratch quando o mouse é passado por cima. A classe InstrumentoView
sobrescreve os métodos “adicionaComandoNaPosicao”, “removeComando” e
“reposicionaComandosFilhos”. Foi necessário sobrescrever estes métodos pelo fato do SoundLoops
não lidar com diferentes comandos e redimencionamento destes comandos, então adaptou-se estes
métodos às necessidades do SoundLoops. A Figura 13 mostra um objeto da classe InstrumentoView
com todas as subdivisões do array do seu respectivo objeto Instrumento preenchidas.
39
Figura 13. InstrumentoView Bumbo
Outra classe reutilizada do Escracho é a ComandoCompositeScratch. Os 2 tipos de
comandos aceitos pela classe InstrumentoView, “Toca” e “Silencio” (a Figura 13 mostra como estes
comandos são apresentados no SoundLoops), herdam da classe ComandoCompositeScratch do
Escracho. Esta herança permite que estes comandos sejam inseridos ou removidos de um
InstrumentoView, e quando isto acontece é preenchida ou removida uma das subdivisões do array
de subdivisões do objeto Instrumento daquele respectivo InstrumentoView.
A classe RepositorioDeMatrizes do Escracho foi reutilizada no SoundLoops para permitir
que o número de comandos “Toca” e “Silencio” fossem infinitos sem a necessidade de cria-los
previamente. Esta classe possui um array de comandos, e para cada comando adicionado neste
array será criado uma cópia deste comando marcada como sendo um comando matriz. Quando o
evento mouse_down for disparado por um destes comandos marcados como comando matriz, este
comando deixa de ser marcado como matriz e uma nova cópia deste comando é criada. Esta cópia é
marcada como matriz e assume o lugar do comando anteriormente marcado como matriz.
Por fim, a classe Blinker do Escracho foi reutilizada para destacar a subdivisão tocada no
momento durante a execução do trecho musical produzido pelo aluno. Dessa forma o SoundLoops
provê feedback visual sobre a execução do algoritmo produzido pelo aluno. No Escracho a classe
Blinker funciona de forma um pouco mais complexa. Esta classe redimenciona o tamanho e faz um
efeito gradiente com as cores do comando, programa ou expressão executada no momento. O
40
SoundLoops não faz uso dos mesmo comandos, expressões e variáveis que o Escracho utiliza,
portanto a classe Blinker teve de ser adaptada as necessidades do SoundLoops. Foi retirado o efeito
de redimencionamento de tamanho, e ao invés de um efeito gradiente a subdivisão tocada é colorida
com vermelho. Algumas das classes do Escracho citadas anteriormente herdam de outras classes,
portanto outras classes além das citadas anteriormente foram utilizadas por meio de heranças.
3.3 ELEMENTOS MUSICAIS UTILIZADOS
A idéia de “visualizar” loops pode ser executada utilizando qualquer instrumento ou até
mesmo batendo palmas, desde que exista a idéia de repetições das mesmas execuções. Pensando nas
dificuldades existentes em reconhecer os sons e quando existem repetições, foi escolhida a bateria
como instrumento que toca os trechos no SoundLoops.
O instrumento bateria é formado por várias partes, sendo que geralmente não são usadas
todas em todos os momentos de uma música. O conjunto destas partes montadas formam o
instrumento que conhecemos como bateria. Existem partes da bateria consideradas fundamentais,
sendo estas: bumbo, caixa e chimbal. Este conjunto fundamental da bateria forma o conjunto de
sons que são ouvidos pelo aluno no SoundLoops, sons que estão sempre presentes na bateria e
podem ser ouvidos em grande parte das músicas. Foram escolhidas as partes que estamos mais
habituados a ouvir pensando em sons de fácil assimilação e reconhecimento. Estas partes são
gradualmente inseridas nos trechos musicais que estão disponíveis no SoundLoops até que sejam
tocadas as três no mesmo trecho. Além disso, a funcionalidade de “silenciar” qualquer uma das
partes da bateria ou até mesmo todas foi inserida para garantir que a pouca percepção musical não
represente uma dificuldade para o aluno durante a utilização do SoundLoops. Na Figura 14 são
apresentadas as partes componentes de uma bateria, e em destaque as peças cujos sons estarão
presentes no SoundLoops.
41
Figura 14. Partes do instrumento bateria
Após definir o instrumento que toca os trechos musicais no SoundLoops, foi definido qual
estilo musical este instrumento tocaria. Procurou-se um estilo que facilitasse a percepção musical e
fosse agradável ou pelo menos conhecido pelos alunos. A música eletrônica oferece estas
características, a bateria é substituída por uma bateria eletrônica que se destaca junto a voz pela
forma como são gravados os instrumentos presentes. A simplicidade dos ritmos presentes na música
eletrônica é outra característica que foi aproveitada para compor os trechos presentes no
SoundLoops visando facilitar a percepção rítmica .
Serão reproduzidos pelo SoundLoops trechos comuns de bateria na música eletrônica, por
esse motivo escolheu-se usar um timbre de bateria eletrônica. O timbre define como será o som
ouvido, mais agudo, mais grave, e não possui relação com a nota musical reproduzida. O
SoundLoops faz uso de timbres de bateria eletrônica, mas também disponibilizara outros timbres
para o aluno que por algum motivo preferir trocar.
Na tentativa de não impor barreiras relacionadas a experiência musical prévia do aluno, os
trechos foram mantidos em uma velocidade que não seja rápida, mas que ao mesmo tempo não
42
dificulte a percepção dos ritmos. Músicas tocadas muito lentamente podem dificultar a percepção
rítmica pela longa duração de cada nota.
Apresentando estas características foi escolhida a metáfora “bateria eletrônica programável”
para o SoundLoops, que faz relação ao estilo de música usado e ao fato de usar implicitamente
loops para reproduzir os trechos.
3.4 REPRESENTAÇÃO DOS TRECHOS MUSICAIS
Os trechos musicais contidos no SoundLoops foram armazenados em forma de texto em
arquivos XML. Cada trecho foi armazenado em um arquivo, e quando necessário são carregados
para a memória para serem reproduzidos para o aluno e para as correções, onde estes são
comparados com a composição feita pelo aluno.
Foi estudada a possibilidade da utilização do padrão MusicXML para a representação dos
trechos musicais contidos no SoundLoops. O MusicXML2 é um padrão de representação de
partituras desenvolvido com objetivo de padronizar os arquivos de representação musical,
especialmente visando estabelecer um padrão entre os softwares para escrita de partituras. Ele
permite a execução e visualização do trecho musical representado. Mas percebeu-se que para o
SoundLoops a utilização do MusicXML seria muito complexa e pouco seria o proveito tirado dos
artifícios presentes no padrão. A Figura 15 representa um exemplo da leitura de um arquivo
MusicXML:
Figura 15. Exemplo de partitura representada por um arquivo MusicXML
Fonte: Adaptado de
http://www.recordare.com/musicxml/tutorial/hello-world
2http://www.recordare.com/musicxml
43
A Figura 16 representa o formato do arquivo MusicXML que armazena os dados da Figura
15:
Foi criado então um formato próprio para a representação dos trechos musicais do
SoundLoops. A classe ConstrutorDeSequenciadores (para mais detalhes veja a Figura 11) é
responsável por ler estes arquivos XML e a partir deles construir o Seqüenciador (representando o
trecho) e cada Instrumento (representando cada instrumento contido no trecho). Esse mecanismo
também permitirá que novos trechos musicais sejam adicionados ao SoundLoops. A Figura 17
representa o mecanismo que armazenará as estruturas musicais:
<?xmlversion="1.0"encoding="UTF-8"standalone="no"?>
<!DOCTYPE score-partwise PUBLIC
"-//Recordare//DTD MusicXML 2.0 Partwise//EN"
"http://www.musicxml.org/dtds/partwise.dtd">
<score-partwiseversion="2.0">
<part-list>
<score-partid="P1">
<part-name>Music</part-name>
</score-part>
</part-list>
<partid="P1">
<measurenumber="1">
<attributes>
<divisions>1</divisions>
<key>
<fifths>0</fifths>
</key>
<time>
<beats>4</beats>
<beat-type>4</beat-type>
</time>
<clef>
<sign>G</sign>
<line>2</line>
</clef>
</attributes>
<note>
<pitch>
<step>C</step>
<octave>4</octave>
</pitch>
<duration>4</duration>
<type>whole</type>
</note>
</measure>
</part>
</score-partwise>
Figura 16. Formato do MusicXML
Fonte: Adaptado de http://www.recordare.com/musicxml/tutorial/hello-world
44
Os trechos musicais foram divididos em três níveis de dificuldade. Os níveis de dificuldade
foram definidos de forma que o aluno possa se adaptar gradualmente aos sons presentes em cada
trecho e a complexidade rítmica envolvida na solução dos exercícios.
Um outro padrão de XML foi criado para armazenar o nome dos arquivos que representam
os trechos musicais e o seu respectivo nível de dificuldade. Este XML é lido logo no início da
execução do SoundLoops e seu conteúdo é armazenado em diferentes arrays, um para cada nível de
dificuldade. A Figura 18representa o mecanismo que define a lista de trechos musicais do
SoundLoops:
?xml version="1.0" encoding="ISO-8859-1"?> <musica> <bpm>120</bpm> <numeroDeCompassos>5</numeroDeCompassos> <listaDeInstrumentos> <instrumento> <nome>caixa</nome> <timbre>caixa</timbre> <subdivisoesDoCompasso> <subdivisao>pausa</subdivisao> <subdivisao>toca</subdivisao> <subdivisao>pausa</subdivisao> <subdivisao>toca</subdivisao> <subdivisao>pausa</subdivisao> <subdivisao>toca</subdivisao> <subdivisao>pausa</subdivisao> <subdivisao>toca</subdivisao> </subdivisoesDoCompasso> </instrumento> <instrumento> <nome>chimbal</nome> <timbre>chimbal</timbre> <subdivisoesDoCompasso> <subdivisao>toca</subdivisao> <subdivisao>pausa</subdivisao> <subdivisao>pausa</subdivisao> <subdivisao>pausa</subdivisao> <subdivisao>pausa</subdivisao> <subdivisao>pausa</subdivisao> <subdivisao>toca</subdivisao> <subdivisao>pausa</subdivisao> </subdivisoesDoCompasso> </instrumento> </listaDeInstrumentos> </musica>
Figura 17. Formato do arquivo XML que será utilizado para representar as estruturas musicais
45
3.5 EMPACOTAMENTO E TESTE COM LMS
Após a implementação do SoundLoops foi testado seu comportamento dentro de um LMS.
Antes dos testes o SoundLoops foi empacotado e exportado nos padrões especificados pelo
SCORM, para somente depois ser testado.
O LMS escolhido para o teste foi o Moodle3, um servidor com o sistema operacional
Windows XP foi criado somente para o teste. Após a criação de um curso fictício uma atividade foi
postada contendo o SoundLoops. Um usuário teste foi criado e adicionado a lista de alunos do curso
criado anteriorment. Efetuou-se login no Moodle utilizando este usuário teste e foi possível
visualizar a atividade criada anteriormente. Ao abrir a atividade foi possível utilizar o SoundLoops
de maneira aceitável, não foram encontrados problemas durante o teste.
Portanto, ao final do teste foi possível utilizar o SoundLoops através do LMS Moodle. O
resultado obtido foi o esperando, o funcionamento estável do SoundLoops em um LMS.
3.6 FERRAMENTAS UTILIZADAS
Para o desenvolvimento do SoundLoops foram utilizadas as ferramentas Adobe Flash CS5
Professional, FlashDevelop e Audacity. Para o desenho das interfaces do SoundLoops foi utilizada
a ferramenta Adobe Flash CS5 Professional e para a codificação a ferramenta FlashDevelop. A
3http://moodle.org/
<?xml version="1.0" encoding="ISO-8859-1"?> <exercicios> <exercicio> <nomeDoArquivo>ex1.xml</nomeDoArquivo> <dificuldade>1</dificuldade> </exercicio> <exercicio> <nomeDoArquivo>ex6.xml</nomeDoArquivo> <dificuldade>2</dificuldade> </exercicio> <exercicio> <nomeDoArquivo>ex11.xml</nomeDoArquivo> <dificuldade>3</dificuldade> </exercicio> </exercicios>
Figura 18. Formato do arquivo XML utilizado para definir a lista dos exercício
46
programação foi feita orientada a objetos utilizando os diagramas produzidos neste trabalho como
referência.
Foi necessário uma ferramenta de edição de áudio para editar os timbres de bateria presentes
no SoundLoops, para este fim foi escolhida a ferramenta Audacity. A produção dos trechos
presentes no repertório padrão do SoundLoops foi feita a partir do próprio SoundLoops, utilizando a
interface de composição e gerando os arquivos XML no formato definido neste trabalho.
Por fim, foram gerados os metadados do SoundLoops no modelo de referência SCORM
utilizando a ferramenta eXeLearning4. A ferramenta eXeLearning foi utilizada para empacotar e
gerar todos os arquivos necessários para que o SoundLoops possa ser importado por um LMS. Para
o ambiente de teste foram necessários um servidor web, um banco de dados e o PHP instalados,
como pré-requisitos para a instalação do LMS. O LMS utilizado para o teste foi o Moodle e o banco
de dados MySQL5.
3.7 PROBLEMAS ENCONTRADOS
Um dos problemas encontrados durante o desenvolvimento do SoundLoops foi gerado pela
imprecisão da classe Timer do Flash. Como estabelecido na única regra de negócio do SoundLoops,
os sons dos instrumentos precisam estar sincronizados entre si e dentro de uma pulsação precisa. A
classe do SoundLoops Sequenciador possui um objeto da classe Timer que dispara eventos de
tempos em tempos. Quando estes eventos são disparados a classe Sequenciador, que possui um
array de Instrumentos (classe do SoundLoops mencionada anteriormente), faz com que estes
instrumentos toquem a subdivisão atual do compasso.
A imprecisão rítmica gerada pelo disparo impreciso dos eventos da classe Timer
compromete a eficiência do SoundLoops. O aluno precisa perceber que existe um padrão rítmico se
repetindo um determinado número de vezes, e se na primeira vez a execução for pouco imprecisa e
na seguinte muito mais imprecisa isso pode fazer com que o aluno não perceba que o ritmo se
repetiu. Se o atraso fosse constante talvez não fosse notado por pessoas com pouca ou nenhuma
experiência musical, mas não existe um padrão para os atrasos.
4http://exelearning.org/wiki 5http://www.mysql.com/
47
Portanto, toda a sincronia dos instrumentos e precisão rítmica depende deste Timer, que se
mostrou ser ineficiente quando exigido este nível de precisão. Para minimizar o problema foi
estabelecida uma velocidade (determinada pelo bpm estabelecido no XML) para os trechos que não
apresentasse problema constante, seja por atraso ou aceleração. Para estabelecer esta velocidade
também foram consideradas as dificuldades que isso poderia gerar para o aluno. O número de bpm
estabelecidos foi de 120, acima disso ou abaixo o SoundLoops pode apresentar problemas de
sincronia e precisão ao tocar os trechos musicais. Uma solução mais apropriada seria a
implementação de uma classe Timer que substituiria a classe do Flash, no entanto isso não foi
possível pelo tempo pré-estabelecido para a entrega deste projeto.
Para o desenvolvimento do SoundLoops foi reutilizado o código da ferramenta Escracho. O
Escracho é um interpretador de comandos desenvolvido também com finalidades educativas. O
Escracho por ser um interpretador de comandos se mostrou robusto, mas pouco desta complexidade
foi aproveitada. Foram reutilizadas apenas as classes ComandoScratch, ProgramaScratch e Blinker,
sendo que muitos de seus métodos não foram utilizados ou sobrescritos. Muito do tempo para o
desenvolvimento do SoundLoops foi gasto para entender as classes e o funcionamento do Escracho,
porém pouco proveito foi tirado disso. Talvez uma implementação sem reutilização de código fosse
mais apropriada.
Graças a pesquisa realizada durante este trabalho (os detalhes são apresentados no apêndice)
considera-se que a música é mais uma alternativa a ser explorada para a melhoria do ensino, devido
a grande porcentagem dos alunos que mostrou interesse pela música.
4 CONCLUSÃO
A primeira tarefa realizada neste trabalho foi a pesquisa e documentação de trabalhos
similares, que sem dúvida contribuíram para a compreensão das características relevantes para o
OA proposto. Com a realização desta tarefa foi possível conhecer as qualidades e defeitos das
abordagens adotadas pelas ferramentas estudadas, e assim melhorar a qualidades do OA proposto
neste trabalho.
A pesquisa sobre os conceitos musicais envolvidos no trabalho mostrou que a abordagem
rítmica é certamente a mais adequada para o OA proposto, pois como foi estudado o ritmo é o
elemento mais facilmente sentido e identificado por pessoas estudadas ou não musicalmente.
O estudo de um mecanismo para correção dos trechos produzidos pelo aluno foi
fundamental ao trabalho, isto torna o SoundLoops uma ferramenta mais completa pois automatiza a
correção dos exercícios propostos. Dessa forma o instrutor que decidir utilizar o SoundLoops
encontrará menor dificuldade durante as aulas com grande número de alunos. Outro ponto positivo
ao realizar esta tarefa foi a descoberta da utilização do mesmo mecanismo para a geração de novos
trechos musicais.
Durante a etapa de especificação foi possível identificar com clareza as funcionalidades que
seriam permitidas durante a utilização do OA proposto, assim como as necessidades exigidas para o
funcionamento correto da mesma. A etapa de modelagem promoveu a oportunidade de melhor
analisar as classes necessárias e seus relacionamento para a implementação do SoundLoops. A
produção do diagrama de seqüencia da correção dos trechos musicais produzidos pelo aluno
também contribuiu de forma considerável para a compreensão de como deveria ser implementada
esta funcionalidade.
A implementação do SoundLoops contribuiu de forma significativa para o cumprimento do
objetivo geral deste trabalho. Durante esta etapa foi possível conhecer uma nova linguagem de
programação e novas ferramentas que contribuíram para o desenvolvimento do SoundLoops. Por
meio da implementação do SoundLoops também se construiu a possibilidade de avaliar a música
como mais uma alternativa para auxiliar o ensino de loops. E como parte fundamental do
cumprimento do objetivo geral, através desta etapa criou-se um objeto de aprendizagem que utiliza
sons e imagens para prover feedback sobre a execução do algoritmo.
49
Os testes do SoundLoops no LMS Moodle contribuíram para uma avaliação do
comportamento do mesmo em um LMS. Uma das formas mais comuns de utilizar um objeto de
aprendizagem é através de um LMS, e por isso a importância do teste para o cumprimento do
objetivo geral.
Por fim, a realização das tarefas anteriormente discutidas contribuíram para a realização dos
objetivos específicos deste trabalho e conseqüentemente o cumprimento do objetivo geral. De
forma que a “idéia” de implementar um OA que apóieo ensino de laços repetição utilizando a
música como metáfora, agora pode ser chamada de projeto. Essa transformação se deu graças a
pesquisa sobre as ferramentas existentes, o conhecimento da viabilidade da abordagem, o estudo
sobre um mecanismo de correção capaz de produzir novos trechos e a modelagem deste projeto em
diagramas que definem como deve ser produzido o OA proposto. E a transformação deste projeto
em um produto final se deu graças a implementação e o teste do mesmo em um LMS.
Mesmo não constando nos objetivos específicos a pesquisa realizada com os alunos deu uma
visão do perfil musical dos alunos de computação da UNIVALI, e de certa forma contribuiu com o
objetivo geral do trabalho. Os resultados da pesquisa mostraram que muitos dos alunos possuem
interesse pela música e boa parte destes toca algum instrumento. Isso certamente não significa que a
abordagem musical é eficiente, mas que pode ser considerada uma alternativa para o ensino.
4.1 TRABALHOS FUTUROS
Ao final deste trabalho ainda resta responder a pergunta: o SoundLoops é capaz de auxiliar o
ensino de laços de repetição? Testes para responder esta pergunta não foram realizados devido ao
tempo de entrega do projeto, portanto é o principal trabalho futuro a ser considerado, afinal é parte
fundamental da validação de uma ferramenta de ensino.
Pelo fato de testes não terem sido realizados para verificar a eficiência do SoundLoops
durante o aprendizado de loops, surge a possibilidade de na verdade o SoundLoops aumentar ainda
mais a abstração dos loops. Esta possibilidade se baseia na afirmação de Palmer e Krumhansl
(1990), que entendem a percepção musical como a transformação do material musical ouvido em
um sistema mais abstrato. O que pode ser mais abstrato que o entendimento dos loops por meios
convencionais.
50
Também observou-se que da maneira como foi concebido, o SoundLoops não contribui no
nível de codificação para o entendimento dos loops mas sim na percepção de padrões repetitivos.
Ao utilizar o SoundLoops o aluno poderia ser capaz de identificar padrões repetitivos nos trechos
musicais e assossioar a utilização de um laço de repetição para repetir aquele padrão, mas em
nenhum momento o SoundLoops contribui em nível de codificação, por exemplo fazendo referência
a um tipo de loop específico.
Foram notados pelo banca alguns pontos a serem melhorados com relação a usabilidade do
SoundLoops. O primeiro é deixar uma referência visual do volume atual para o aluno. Da forma
como foi feito o SoundLoops apenas permite que o aluno clique para aumentar ou diminuir o
volume sem oferecer uma referência visual em alguma escala de onde o volume atual se encontra.
O segundo é fornecer algum tipo de feedback sobre a execução das “pausas” ou “silêncios”
presentes em um trecho musical. O SoundLoops apenas oferece feedback visual das “pausas”
quando está executando o trecho musical produzido pelo aluno. Dessa forma se torna difícil a
percepção de ritmos que iniciam com “pausas”.
Outras sugestões e idéia foram feitas pela banca e seram discutidas a seguir. Muito foi
discutido sobre “como o aluno vai aprender laços de repetição utilizando o SoundLoops?”, uma das
idéias que surgiram desta discução está relacionada com a separação dos instrumentos e comandos.
Também foi considerada a idéia de inserir desvios condicionais que permitem ao aluno decidir, por
exemplo, quando o instrumento chimbal deve ser tocado e quando ambos chimbal e caixa devem
ser tocados. Outra idéia sugerida foi deixar que o aluno determine a duração das notas. Com isso
talvez fosse possível inserir desafios em que o aluno possui um número limitado de recursos
disponíveis para reproduzir determinado trecho musical (idéia semelhante a do jogo LightBot6). A
Figura 19 representa uma idéia de algoritmo para reproduzir um trecho musical.
6 http://armorgames.com/play/6061/light-bot-20
Loop_infinito Se (tempo = 2) Toca bumbo e chimbal Senão Se (tempo é par) Toca bumbo Fimse Fimse End_loop
Figura 19. Algoritmo sugerido pela banca
REFERÊNCIAS BIBLIOGRÁFICAS
ADL - Advanced distributed learning. 2008. Disponível em: <http://www.adlnet.gov>. Acesso em: 8 mar. 2010. BALDWIN, Lynne P.; KULJIS, Jasna. Learning programming using program visualization techniques. In: Hawaii International Conference on System Sciences, 34., 2001, Hawaii. Proceedings... Hawaii: IEEE, 2001. p. 1-8. BARBOSA, Gerardo O. Raciocínio lógico formal e aprendizagem em cálculo diferencial e integral: o caso da Universidade Federal do Ceará. Dissertação (Mestrado em Educação), Universidade Federal do Ceará, Fortaleza, 1994. BEAUBOUEF, Theresa; MASON, John. Why the high attrition rate for computer science students: some thoughts and observations. In: ACM SIGCSE Bulletin, USA, v. 37, n. 2, p. 103-106, jun. 2005. BRASIL. MEC – Ministério da Educação. Diretrizes curriculares para cursos da área de Computação e Informática. 2006. Disponível em:<http://www.inf.ufrgs.br/mec/ceeinf.diretrizes.html>. Acesso em: 5 de mar 2010. BURG, Jennifer; ROMNEY, Jason. Linking computer science, art and practice through digital sound. In: Technical Symposium on Computer Science Education, 40., 2009, Chattanooga. Proceedings... Chattanooga: ACM, 2009. P. 473-477. CARSON, Erik; PARBERRY, Ian; JENSEN, Bradley. Algorithm Explorer: visualizing algorithms in a 3D multimedia environment. In: Technical Symposium on Computer Science Education, 38., 2007, Covington. Proceedings... Covington: ACM, 2007. p. 155-159. DALE, Nell B. Most difficult Topics in CS1: Results of an Online Survey of Educators. In: ACM SIGCSE Bulletin, USA, v. 1, n. 5, p. 49-53, jun. 2006. EAGLE, Michael; BARNES, Tiffany. Experimental of an Educational Game for Improved Learning in Introductory Computing. In: ACM SIGCSE Bulletin, USA, v. 1, n. 5, p. 321-325, mar. 2009. EAGLE, Michael; BARNES, Tiffany. Teaching Arrays and Loops in a Game. In: ACM ITiCSE Bulletin, Spain, v. 1, n. 5, p. 245-249, jun. 2008.
52
ELLIS, Ryann K. Field guide to learning management systems. ASTD Learning Circuits, 2009. Disponível em: <http://www.astd.org/NR/rdonlyres/12ECDB99-3B91-403E-9B15-7E597444645D/23395/LMS_fieldguide_20091.pdf >. Acesso em: 30 maio 2010. GARDNER, Howard. Intelligence reframed: multiple intelligences for the 21st century. New York: Basic Books Inc, 1999. GARDNER, Howard. Inteligências múltiplas: a teoria na prática. 1. ed. Porto Alegre: Artes Médicas, 1995. IEEE Learning Technology Standards Committee. 1997. Disponível em: <http://www.ltsc.ieee.org/wg12/index.html>. Acesso em: 9 mar. 2010. JESUS, Elieser Ademir de; RAABE, André Luis Alice. Interpretações da Taxonomia de Bloom no Contexto da Programação Introdutória. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 20., 2009, Florianópolis. Anais... Florianópolis: SBIE, 2009. p. 1-10. JÚNIOR, J. C. R. P. ; RAPKIEWICZ, C. E. O Processo de Ensino e Aprendizagem de Algoritmos e Programação: Uma Visão Crítica da Literatura. In: Workshop de Educação em Computação e Informática do estado de Minas Gerais, 3., 2004, Belo Horizonte. Anais... Belo Horizonte: WEIMIG, 2004. KOFFMAN, E. B.; MILLER, P. L.; WARDLE, C. E. Recommended curriculum for CS1, 1984. In: Communications of the ACM, USA, v. 27, n. 10, p. 998-1001, oct. 1984. MALAN, David J.; LEITNER, Henry H. Scratch for budding computer scientists. In: Technical Symposium on Computer Science Education, 38., 2007, Covington. Proceedings... Covington: ACM, 2007. p. 223-227. MC.WHORTER, William I. ; O’CONNOR, Brian C. Do Lego Mindstorms motivate students in CS1? In: ACM SIGCSE Bulletin, USA, v. 1, n. 5, p. 438-442, mar. 2009. MED, Bohumil. Teoria da música. 4.ed. Brasília: Musimed, 1996. MORENO, Andrés et al. Visualizing programs with Jeliot 3. In: Working conference on Advanced visual interfaces, 2004, Gallipoli. Proceedings... Gallipoli: ACM, 2004. p. 373-376.
53
MOTA, Marcelle Pereira; BRITO, Silvana R. de; MOREIRA, Mireille Pinheiro; FAVERO, Eloi Luiz. Ambiente integrado à plataforma Moodle para apoio ao desenvolvimento das habilidades iniciais de programação. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 20., 2009, Florianópolis. Anais... Florianópolis: SBIE, 2009. p. 1-10. PALMER, Caroline; KRUMHANSL, Carol L. Mental representations for musical meter. Journal of Experimental Psychology: Human Perception and Performance, v.16, n.4, p. 728-741. 1990. PEARS, Arnold et al. A survey of literature on the teaching of introductory programming. In: ACM SIGCSE Bulletin, USA, v. 39(4), p. 204-223, 2007. PHILLIPS-SILVER, Jessica; TRAINOR, Laurel J. Feeling the beat: movement influences infant rhythm perception. Science, v.308, n.5727, p. 1430, jun. 2005. POWERS, Kris; ECOTT, Stacey; HIRSHFIELD, Leanne M. Through the looking glass: teaching CS0 with Alice. In: ACM SIGCSE Bulletin, USA, v. 1, n. 5, p. 213-217, mar. 2007. PRAKASH, Lakshmi S.; SAINI, Dr.Dinesh K.; KUTTI, N. S. Integrating edulearn learning content management system (LCMS) with cooperating learning object repositories (LORs) in a peer to peer (P2P) architectural framework. ACM SIGSOFT Software Engineering Notes, New York, v.34, n.3, p. 1-7, may. 2009. PROULX, V. K. Programming Patterns and Design Patterns in the Introductory Computer Science Course. In: Technical Symposium on Computer Science Education, 31., 2000, New York. Proceedings... New York: ACM, 2000. p. 7-12. Advanced Distributed Learning. 1999. Disponível em: <http://www.adlnet.gov/Technologies/scorm/default.aspx>. Acesso em: 30 maio 2010. SANTOS, R. P. ; COSTA, H. A. X. Análise de Metodologias e Ambientes de Ensino para Algoritmos, Estruturas de Dados e Programação aos iniciantes em Computação e Informática. INFOCOMP JOURNAL OF COMPUTER SCIENCE, Minas Gerais, v. 5, n. 1, p. 41-50, mar. 2006. SMITH, D.C. ; CYPHER, A. ; TESLER, L. Novice Programming Comes of Age. In: Communications of the ACM, v. 43, n. 3, 2000, p. 75-81. SBC - SOCIEDADE BRASILEIRA DE COMPUTAÇÃO. 2003. Currículo de Referência da Sociedade Brasileira de Computação para Cursos de Graduação em Computação e Informática. Disponível em:
54
<http://www.sbc.org.br/index.php?language=1&subject=1&search=1&page=1&content=search&phrase=curr%EDculo+refer%EAncia&area=all&target=0>. Acesso em: 18 abr. 2010. STROUSTRUP, Bjarne. Programming in an undergraduate CS curriculum. In: Western Canadian Conference on Computing Education, 14., 2001, British Columbia. Proceedings... British Columbia: ACM, 2009. p. 82-89. TATSUMI, Takeo et al. Incorporating music into the study of algorithms and computer programming. In: International Conference on Multimodal Interfaces, 2., 2009, New York. Proceedings... New York: ACM, 2009. TOBAR, C. M. et al. Uma Arquitetura de Ambiente Colaborativo para o Aprendizado de Programação. In: Simpósio Brasileiro de Informática na Educação, 12., 2001. Anais... Vitória: SBIE, 2001. Wiley, D. A. Learning object design & sequencing theory. 2000. Doctoral Dissertation, Brigham Young University. Wiley, D. A. “Connecting learning objects to instructional design theory: A definition, a metaphor, and a taxonomy.” In: Wiley, D. A. ed., The instructional use of learning objects: online version. 2002. Disponível em: <http://reusability.org/read/chapters/wiley.doc>. Acesso em: 8 jul. 2010. XINOGALOS, S. An introduction to object-oriented programming with a didactc microworld: objectKarel. In: COMPUTERS AND EDUCATION, 8., 2003, New York. Proceedings... New York: ACM, 2003. p. 233-233. YNOGUTI, Carlos Alberto. Uma metodologia para o ensino de algoritmos. In: Global Congress on Engineering and Technology Education, 2005, São Paulo. Anais... São Paulo: GCETE, 2005. p. 684-687.
GLOSSÁRIO
Compasso É a divisão do ritmo em grupos de tempos.
Harmonia Notas tocadas simultaneamente.
Melodia Notas tocadas sequêncialmente.
Ritmo Ordem e proporção em que estão dispostas a melodia e harmonia.
Tempos Batidas da pulsação.
APÊNDICES
A MODELAGEM DO SOUNDLOOPS
Neste apêndice são mostrados os detalhes da modelagem do SoundLoops. A seguir serão
apresentados os requisitos funcionais e não funcionais e regras de negócio.
A.1 REQUISITOS FUNCIONAIS
Para construção do SoundLoops levantou-se os seguintes requisitos funcionais:
1. O sistema deve percorrer os níveis de dificuldade conforme o aluno consegue avançar;
2. O sistema deve randomizar um trecho dentre os disponíveis no nível de dificuldade
atual;
3. O sistema deve permitir ao usuário ajustar a intensidade dos sons emitidos pelo sistema;
4. O sistema deve permitir ao usuário escolher qual dos timbres disponíveis do instrumento
bateria o mesmo deseja utilizar;
5. O sistema deve permitir ao usuário ouvir o trecho a ser reproduzido pelo mesmo
indeterminado número de vezes;
6. O sistema deve permitir ao usuário silenciar qualquer número de instrumentos presentes
em sua composição;
7. O sistema deve permitir ao usuário ouvir o trecho que ele compôs indeterminado número
de vezes;
8. O sistema deve permitir ao usuário verificar se o trecho criado por ele está idêntico ao
proposto pelo sistema, mesmo quando incompleto;
9. O sistema deve reproduzir o trecho criado pelo aluno após realizar a correção de cada
trecho presente no primeiro nível de dificuldade;
10. O sistema deve identificar desigualdades entre o trecho proposto e o trecho criado pelo
usuário;
11. O sistema deve informar ao usuário onde está o seu erro após identificá-lo; e
12. O sistema deve permitir a adição de novos trechos aos níveis de dificuldade propostos
pelo sistema.
58
A.2 REQUISITOS NÃO FUNCIONAIS
Para construção do SoundLoops levantou-se os seguintes requisitos não funcionais:
1. O sistema deve conduzir o usuário aos próximos trechos conforme o mesmo cria trechos
idênticos ao propostos pelo sistema;
2. O sistema deve conduzir o usuário aos próximos níveis conforme o mesmo alcança os
objetivos propostos pelo sistema em cada nível;
3. O sistema apenas permitirá trechos de no máximo 1 minuto;
4. O sistema apenas permitirá trechos tocados por uma ou mais das seguintes partes do
instrumento bateria: bumbo, caixa e chimbal; e
5. O sistema deve permitir ao usuário também acompanhar a reprodução do trecho criado
por ele por meio visual.
A.3 REGRAS DE NEGÓCIO
Para a construção do OA proposto levantou-se a seguinte regra de negócio:
1. O sistema deve reproduzir os sons dos instrumentos de forma sincronizada entre si.
Esta regra de negócio é fundamental, pois se os sons dos instrumentos não forem
reproduzidos de forma sincronizada entre si não se pode perceber o ritmo, já que este último
provém da execução cadenciada de elementos musicais.
B PESQUISA REALIZADA
Neste apêndice são mostrados e discutidos os resultados obtidos com a pesquisa realizada
durante este trabalho. A pesquisa foi realizada na UNIVALI com alunos de todos os períodos do
curso de Ciência da Computação. A pesquisa teve como objetivo principal conhecer o perfil
musical dos alunos e verificar o interesse dos mesmos pela música.
B.1 QUESTIONÁRIO APLICADO
O questionário aplicado durante a pesquisa reuniu as seguinte perguntas:
1. Quantos anos você tem?;
2. Qual é o seu curso?;
3. Você toca algum instrumento?;
4. Qual instrumento?;
5. A quantos ano você toca?; e
6. Que tipo de música você ouve?.
As duas primeiras perguntas foram feitas com objetivo de filtrar eventuais alunos de outros
cursos e fazer uma média da idade dos alunos que participaram da pesquisa. As outras perguntas
tiveram como objetivo saber se os alunos possuem alguma experiência musical e qual o nível da
mesma. As últimas duas perguntas nos permitiu verificar quais os instrumentos mais tocados e
gêneros mais apreciados pelos alunos. Outro ponto importante da pesquisa foi constatar se os alunos
possuem interesse pela música.
60
B.2 DADOS COLETADOS
A Tabela 2 apresenta todos os dados coletados durante a pesquisa:
Tabela 2. Tabela com os dados da pesquisa
PERGUNTAS DO QUESTIONÁRIO
Aluno Idade Você toca algum
instrumento? Qual
instrumento?
A quanto tempo você
toca?
Que gênero musical você
ouve?
Gênero secundário
1 22 sim guitarra 3 rock blues
2 18 sim guitarra 5 heavy metal
3 17 sim violão 4 bossa nova
4 19 sim violão 1 rock gospel
5 17 sim bateria 0,3 rock eletrônica
6 22 sim violão 14 gaúcha rock
7 23 sim violão 5 rock
8 20 sim violão 1 rock
9 18 sim violão 1,5 rock
10 21 sim violino 4 rock
11 18 sim violão 1 rock
12 20 sim violão 1 reggae
13 17 sim violão 5 heavy metal
14 20 sim teclado 3 trance
15 17 sim piano 4 rock instrumental
16 29 sim violão 10 heavy metal eletrônica
17 27 sim teclado 17 heavy metal
18 24 sim violão 11 rock
19 22 sim guitarra 7 rock heavy metal
20 25 sim guitarra 2 rock
21 22 sim bateria 5 eclético
22 28 sim teclado 15 gospel
23 22 sim teclado 5 rock
24 21 sim guitarra 3 rock heavy metal
25 21 sim guitarra 1 rock
26 23 sim violão 0,5 rock
27 23 sim teclado 2 rock
28 28 sim violão 1 eclético
29 20 sim violão 8 eclético
30 21 sim bateria 3 rock
31 23 sim guitarra 4 rock
32 19 sim violão 4 eclético
33 18 sim violão 1 eclético
34 18 sim violão 3 eclético
35 18 sim guitarra 2 rock
36 20 sim guitarra 1 rock
37 18 sim violão 0,5 rock eletrônica
38 18 sim violão 3 rock sertanejo
39 18 sim guitarra 5 rock eletrônica
40 18 sim violão 8 samba
41 21 sim violão 10 rock
61
42 23 sim guitarra 6 rock
43 20 sim violão 3 sertanejo
44 23 sim teclado 2 rock eletrônica
45 22 sim baixo 3 rock
46 20 sim guitarra 6 rock
47 23 sim violão 3 sertanejo
48 20 sim trompete 6 mpb
49 20 sim baixo 8 heavy metal
50 20 sim violão 6 clássica
51 20 sim violão 6 rock
52 20 sim guitarra 1 rock
53 22 sim órgão 7 gospel axé
54 23 sim violão 1 rock
55 21 sim guitarra 1 eclético
56 19 sim guitarra 3 heavy metal rock
57 21 sim guitarra 1 rock
58 21 sim piano 11 clássica eletrônica
59 36 sim baixo 10 gospel
60 21 sim violão 1 rock
61 22 sim violão 5 rock
62 22 sim violão 8 rock
63 21 sim teclado 1 gospel
64 24 sim guitarra 12 rock heavy metal
65 19 sim bateria 2 rock eletrônica
66 24 sim teclado 18 eclético
67 20 sim teclado 10 mpb
68 19 sim violão 4 sertanejo
69 21 sim guitarra 13 clássica heavy metal
70 21 sim gaita 1 blues heavy metal
71 19 sim teclado 15 eclético
72 20 sim violão 2 eclético
73 25 sim bateria 5 eclético
74 20 sim violão 3 rock
75 22 sim violão 5 heavy metal
76 19 sim guitarra 5 rock
77 26 sim piano 13 eclético
78 20 sim guitarra 5 eclético
79 18 sim guitarra 10 rock
80 23 sim guitarra 17 rock blues
81 20 não 0 sertanejo
82 24 não 0 heavy metal
83 19 não 0 rock
84 20 não 0 sertanejo
85 19 não 0 pop
86 19 não 0 rock eletrônica
87 24 não 0 reggae
88 19 não 0 eletrônica
89 23 não 0 rock
90 23 não 0 mpb
91 18 não 0 hip hop
92 17 não 0 hard core
93 19 não 0 rock
94 19 não 0 pop
62
95 20 não 0 sertanejo
96 26 não 0 eclético
97 18 não 0 eclético
98 23 não 0 eletrônica
99 20 não 0 rock
100 18 não 0 eletrônica rock
101 19 não 0 bossa nova pop
102 19 não 0 eclético
103 29 não 0 eclético
104 18 não 0 eletrônica pop
105 25 não 0 eclético
106 37 não 0 eclético
107 19 não 0 gospel
108 18 não 0 rock
109 34 não 0 eletrônica sertanejo
110 27 não 0 pop
111 19 não 0 pop rock
112 23 não 0 gaúcha sertanejo
113 18 não 0 eclético
114 18 não 0 eclético
115 22 não 0 eletrônica
116 28 não 0 heavy metal
117 20 não 0 eletrônica
118 21 não 0 hip hop
119 18 não 0 eclético
120 19 não 0 eletrônica rock
121 18 não 0 heavy metal
122 18 não 0 sertanejo
123 20 não 0 eletrônica
124 23 não 0 eclético
125 21 não 0 heavy metal
126 22 não 0 eclético
127 24 não 0 rock pop
128 22 não 0 sertanejo
129 23 não 0 rock
130 44 não 0 eclético
131 26 não 0 sertanejo
132 30 não 0 eletrônica
133 20 não 0 sertanejo
134 23 não 0 rock
135 20 não 0 rock
136 20 não 0 eclético
137 22 não 0 sertanejo rock
138 25 não 0 rock
139 24 não 0 rock
140 18 não 0 eclético
141 20 não 0 heavy metal
142 21 não 0 eclético
143 18 não 0 eclético
144 17 não 0 eletrônica sertanejo
145 17 não 0 eletrônica
146 23 não 0 rock eletrônica
147 19 não 0 eletrônica rock
63
148 17 não 0 rock heavy metal
149 23 não 0 gospel pagode
150 22 não 0 heavy metal rock
151 18 não 0 hard core heavy metal
152 20 não 0 sertanejo eletrônica
153 18 não 0 eclético
154 22 não 0 eletrônica
155 25 não 0 rock
156 30 não 0 heavy metal
157 20 não 0 heavy metal
158 19 não 0 eclético
159 19 não 0 rock
160 19 não 0 eletrônica
161 19 não 0 clássica
162 19 não 0 eclético
163 19 não 0 rock
164 18 não 0 eclético
165 19 não 0 eletrônica
166 19 não 0 rock
167 26 não 0 gospel
168 19 não 0 rap
169 22 não 0 eclético
170 26 não 0 eclético
171 27 não 0 rock
172 31 não 0 pop rock
173 21 não 0 pop
174 28 não 0 eclético
175 21 não 0 heavy metal
176 20 não 0 eclético
177 21 não 0 rock
178 29 não 0 eletrônica
179 21 não 0 rock
180 21 não 0 rock
181 20 não 0 rock
182 20 não 0 rock
183 21 não 0 pop rock
184 21 não 0 eletrônica sertanejo
185 20 não 0 pop rock
186 21 não 0 rock
187 26 não 0 rock
188 22 não 0 eclético
189 20 não 0 rock
190 21 não 0 sertanejo eletrônica
191 19 não 0 rock
192 18 não 0 rock
193 31 não 0 instrumental
194 29 não 0 rock
64
B.3 ANÁLISE DOS DADOS OBTIDOS
O total de alunos que participaram do experimento foi 194, sendo que este número foi
obtido após filtrar os alunos que responderam o questionário porém pertenciam a outros cursos,
como por exemplo: Engenharia Civil, Engenharia Ambiental e Sistemas para Internet. A idade
média dos alunos é de 21 e meio, sendo que o desvio padrão é de 3,9. O que é o esperado, alunos
entre 17 e 25 anos, em sua maioria.
Confirmando especulações, muitos dos alunos participantes do experimento tocam algum
instrumento, chegando a 41% que tocam e 59% que não tocam. Estes dados mostram que existe um
interesse pela música por parte dos alunos, e este interesse pode ser explorado pelas ferramentas e
metodologias de ensino. A Figura 20 apresenta os dados desta pergunta de forma gráfica:
Figura 20. Gráfico que ilustra as respostas da pergunta “Você toca algum instrumento?”
Os instrumentos mais citados pelos alunos foram violão e guitarra, apesar de muitos outros
também serem citados, por exemplo: teclado, piano, bateria e baixo. A Figura 21 ilustra a
distribuição em porcentagem dos instrumentos tocados pelos alunos:
65
Figura 21. Gráfico que ilustra as respostas da pergunta “Qual instrumento você toca?”
Muitos dos alunos se mostraram experientes em seu instrumento de domínio e outros até
mesmo em mais de um instrumento. Porém, muitos também se mostraram iniciantes, tornando a
média do tempo de experiência dos alunos enganosa. A média do tempo de experiência dos alunos
foi de 5 anos e três meses com um desvio padrão de 4 anos e 5 meses. Mas isto reflete que mesmo
que nem todos sejam experientes muitos possuem interesse.
Para a última pergunta algumas medidas foram adotadas para que fosse possível representar
os dados de forma mais clara. Muitos gêneros e subgêneros musicais foram citados pelos alunos e
durante a análise agrupados em gêneros mais conhecidos. Quando foram citados 2 ou mais gêneros
semelhantes entre si foi considerado o gênero representante do agrupamento, por exemplo: o gênero
“Rock” agrupa os subgêneros e nomenclaturas “Rock ‘N Roll”, “Rock Clássico”, “Pop Rock” e
outros. Com isso também foram eliminadas nomenclaturas diferentes para o mesmo gênero musical.
E foram considerados apenas 2 gêneros mencionados pelos alunos, nos casos em que o aluno
respondeu com mais de 2 gêneros não semelhantes entre si foi utilizado o termo “Eclético”.
66
Gêneros e nomenclaturas agrupadas no gênero “Rock”:
1. Rock antigo;
2. Rock clássico;
3. Indie rock;
4. Hard rock;
5. Rock ‘n roll;
6. Rock progressivo;
7. Pop rock;
8. Punk rock; e
9. Rock alternativo.
Gêneros e nomenclaturas agrupadas no gênero “Heavy Metal”:
1. Metal extremo;
2. Black metal;
3. Metal;
4. Death metal; e
5. Metal sinfônico.
Gêneros agrupados no gênero “Eletrônica”:
1. Dance;
2. Psy;
3. House; e
4. Techno.
Gêneros com menos de 10 ocorrências agrupados em “Outros”:
1. Bossa nova;
2. Gospel;
67
3. Gaúcha;
4. Reggae;
5. Instrumental;
6. MPB;
7. Samba;
8. Clássica;
9. Axé;
10. Blues;
11. Hip Hop;
12. Hard Core;
13. Pagode; e
14. Rap.
Percebeu-se que a maioria dos alunos ouve o gênero “Rock” e talvez isso esteja relacionado
com os instrumentos mais tocados pelos alunos (guitarra e violão). Outro gênero com muitas
ocorrências foi o “Eletrônica” e “Heavy Metal”, que também pode ter influência nos instrumentos
mais tocados. A Figura 22 apresenta de forma gráfica os dados coletados:
68
Figura 22. Gráfico que ilustra as respostas da pergunta “Qual gênero musical você ouve?”
B.4 CONCLUSÃO DA ANÁLISE
Foi possível perceber que a música é uma área de interesse de uma considerável parte dos
alunos de computação. Portanto é mais uma alternativa a ser explorada pela educação como forma
de auxiliar o ensino. Ferramentas que não requisitem um alto nível de musicalidade talvez possam
ser de grande ajuda no ensino.
