Relatorio de estagio - INESC · PDF fileSistema automático de reconhecimento de pautas...

Faculdade de Engenharia da Universidade do Porto

Mestrado Integrado em Engenharia Informática e Comp utação

Sistema automático de reconhecimento de pautas musi cais manuscritas no

INESC Porto

Relatório do Estágio Curricular da MIEIC 2006/2007

Guilherme Artur Conceição Capela

Orientador na FEUP: Prof. Eurico Manuel Elias Morais Carrapatoso

Orientador no INESC Porto: Prof. Jaime dos Santos Cardoso

Setembro de 2007

Sistema automático de reconhecimento de pautas musicais manuscritas

ii

Ao meu cão Afonsinho que nos deixou com muitas saudades


iii

Resumo

O presente relatório tem por objectivo apresentar e descrever de forma detalhada o projecto “Sistema automático de reconhecimento de pautas musicais manuscritas”, realizado no âmbito do estágio curricular de fim de curso, do Mestrado Integrado em Engenharia Informática e Computação, da Faculdade de Engenharia da Universidade do Porto. O projecto decorreu na Unidade de Telecomunicações e Multimédia do Instituto de Engenharia de Sistemas e Computadores do Porto, de 15 de Fevereiro a 14 de Agosto de 2007.

Este projecto surge da necessidade de preservação da nossa herança musical recente, cujas obras musicais existem em grande parte somente como manuscritos originais ou fotocópias. Essa preservação envolve a digitalização destes trabalhos e consequente acessibilidade num formato que permita o armazenamento, navegação, análise, recuperação (retrieval), manipulação e publicação. O actual processo necessário para o reconhecimento de pautas musicais manuscritas é muito dispendioso em tempo, tendo de ser efectuado manualmente. A razão prende-se com a qualidade das soluções automáticas actuais neste campo, ainda longe do ideal. O reconhecimento musical óptico (Optical Music Recognition – OMR) clássico está mais focado em pautas impressas, ou seja, regulares. Desenvolver uma técnica de OMR que possa, de forma (semi-)automática, representar uma pauta manuscrita em formato digital seria extremamente benéfico pois permitiria um acesso generalizado a partituras que nunca foram publicadas, e portanto de momento dificilmente acessíveis.

Neste estágio pretendeu-se, como objectivo principal, integrar num sistema único tecnologia de OMR, facilitando a conversão mencionada e a representação das partituras em estilo hierárquico, utilizando para tal o formato MusicXML (Music Extended Markup Language). Esta representação estruturada permite o posterior acesso nas diversas vertentes acima enumeradas. Tal objectivo foi alcançado pela criação de uma aplicação web, através da qual se pode efectuar o reconhecimento, edição, armazenamento e pesquisa das pautas musicais. Nesta primeira fase do projecto começou-se por integrar uma solução de OMR existente, que posteriormente será substituída com as novas técnicas e algoritmos estudados nas restantes componentes do projecto, para reconhecer correctamente pautas manuscritas. No entanto o sistema desenvolvido permite que se incorpore um qualquer número de programas de OMR, cuja vantagem é a possibilidade de se seleccionar o OMR mais apropriado para a partitura em questão a ser reconhecida, uma vez que existem diversos tipos de notação musical desde as escritas mais antigas até ao standard actual.

Com a realização deste projecto consegue-se responder aos objectivos enunciados, particularmente em relação à componente realizada neste estágio. Com a criação do sistema total, é possível preservar as obras musicais permitindo o reconhecimento óptico e o tratamento da informação de uma forma inovadora. É um sistema muito vantajoso pois permite realizar a tarefa de forma generalizada e livremente a partir de qualquer local com um PC (Personal Computer) com acesso à Internet, com qualquer sistema operativo. Não apenas é possível preservar as obras musicais antigas como também o seu reconhecimento é facilitado através de uma utilização simples, intuitiva e eficaz.


iv

Agradecimentos

Gostaria em primeiro lugar de agradecer a ambos os meus orientadores de estágio, Prof. Jaime dos Santos Cardoso no INESC Porto, e Prof. Eurico Manuel Elias Morais Carrapatoso na FEUP, pela confiança, apoio, disponibilidade, compreensão e enorme paciência que tiveram comigo durante todo o estágio. Mesmo nos momentos mais complicados e com as minhas falhas, o ambiente foi sempre positivo e contei com o apoio de ambos.

Não podia deixar de agradecer também à minha colega de estágio, a Ana Maria Rebelo, pela amizade, conversas, boa companhia e paciência que teve comigo.

Um agradecimento vai também para o Prof. Carlos Guedes da ESMAE pela confiança e apoio depositado em mim, para a realização do estágio neste projecto ao qual está associado.

É também devido um agradecimento aos meus colegas na UTM que me receberam bem e estiveram sempre prontos a interromper os seus trabalhos e ajudar quando fosse necessário, e pelo bom ambiente criado.

Um outro agradecimento um pouco anónimo vai para as pessoas que não conheço mas que me deram algumas ajudas valiosas no fórum do Ruby on Rails a troco de um simples obrigado.

Durante este período de tempo que misturou um grande conjunto de emoções boas e más, gostaria também de agradecer a várias pessoas fora do estágio e do INESC Porto, que de uma ou outra forma me deram apoio ou simplesmente força durante esta fase da minha vida.

Agradeço portanto em primeiro aos meus pais e à minha irmã por todo o apoio e muita, mas mesmo muita paciência que tiveram comigo.

Um agradecimento especial vai para a minha tia Fátima “A.T.I.A.” Capela, que me conhece bem, compreende e apoia. E cujos conselhos me têm ajudado a pensar, decidir e actuar.

Outro agradecimento especial vai para o meu grande primo Rui Barbosa por também ser um bom amigo para além de bom primo.

Não podia deixar de mencionar os meus mentores musicais, o Hugo, a Liliana Rocha e o Paulo Barros, cujas ajudas, compreensão, conselhos e influências não têm preço.

Próximo do fim, mas de grande importância, um grande obrigado aos meus amigos Filipe Coelho e João Pinto pela boa amizade e pelas ajudas preciosas durante toda esta aventura. Vamos ganhar!

Também gostaria de agradecer ao meu bom amigo Ivo Rocha pela sua amizade insubstituível com a qual tenho o privilégio de contar há já muitos anos, e que há algum tempo me ajudou a “abrir os olhos” em relação à vida.

E claro, ao meu amigo periquito, o Pequenino, que só é meu amigo e às outras pessoas morde ☺.


v

Índice de Conteúdos

1 Introdução ...........................................................................................................................................1 1.1 Apresentação do INESC Porto............................................................................................................. 1 1.2 O Projecto SARPMM no INESC Porto ................................................................................................. 3

1.2.1 Contexto e Motivação ........................................................................................................ 3 1.2.2 Objectivos .......................................................................................................................... 5 1.2.3 Resultados Esperados....................................................................................................... 6

1.3 Estudo e Desenvolvimento da Aplicação OMRSYS no Projecto SARPMM......................................... 6 1.4 Organização e Temas Abordados no Presente Relatório .................................................................... 7 1.5 Contribuições deste Projecto e Publicações Relacionadas.................................................................. 8

2 Análise do Problema ...........................................................................................................................9 2.1 Conceitos Fundamentais...................................................................................................................... 9

2.1.1 Organização de uma Obra Musical ................................................................................... 9 2.1.2 Símbolos a Reconhecer..................................................................................................... 9 2.1.3 Semântica Musical........................................................................................................... 14

2.2 Descrição Geral ................................................................................................................................. 15 2.2.1 Intervenientes .................................................................................................................. 15 2.2.2 Sistema Global ................................................................................................................ 16

2.3 Plano de Trabalhos do Estágio .......................................................................................................... 18

3 Revisão Tecnológica .........................................................................................................................19 3.1 Estado da Arte ................................................................................................................................... 19

3.1.1 Soluções Existentes ou Semelhantes.............................................................................. 19 3.2 Tecnologias Consideradas................................................................................................................. 30

3.2.1 Base de Dados ................................................................................................................ 30 3.2.2 Aplicação de OMR........................................................................................................... 33 3.2.3 Aplicação Web e Editor de Pautas Embutido .................................................................. 34 3.2.4 Servidor ........................................................................................................................... 37

3.3 Outras Ferramentas Usadas .............................................................................................................. 38

4 Especificação ....................................................................................................................................39 4.1 Visão Geral ........................................................................................................................................ 39 4.2 Características dos Utilizadores......................................................................................................... 40 4.3 Requisitos Funcionais ........................................................................................................................ 41

4.3.1 Aplicação Web................................................................................................................. 43 4.3.2 Aplicação de OMR........................................................................................................... 50 4.3.3 Editor de MusicXML......................................................................................................... 54 4.3.4 Armazenamento .............................................................................................................. 55

4.4 Requisitos de Qualidade .................................................................................................................... 56 4.4.1 Eficiência ......................................................................................................................... 56 4.4.2 Fiabilidade ....................................................................................................................... 56 4.4.3 Manutenção ..................................................................................................................... 57 4.4.4 Portabilidade.................................................................................................................... 57 4.4.5 Segurança ....................................................................................................................... 57 4.4.6 Usabilidade ...................................................................................................................... 58


vi

4.5 Requisitos Tecnológicos .................................................................................................................... 58 4.6 Requisitos de Desenvolvimento ......................................................................................................... 61 4.7 Protótipo da Interface......................................................................................................................... 61

5 Desenvolvimento da Aplicação .........................................................................................................65 5.1 Visão Geral ........................................................................................................................................ 65

5.1.1 Decomposição Horizontal ................................................................................................ 65 5.1.2 Decomposição Vertical .................................................................................................... 66

5.2 Modelos de Dados ............................................................................................................................. 67 5.2.1 Base de Dados do Armazenamento ................................................................................ 67 5.2.2 Aplicação Web................................................................................................................. 73

5.3 Plugins e Gems.................................................................................................................................. 77 5.4 Estruturação do Código...................................................................................................................... 78 5.5 Diagrama de Componentes ............................................................................................................... 79 5.6 Interface Gráfica................................................................................................................................. 80

6 Conclusões e Perspectivas de Trabalho Futuro ...............................................................................87 6.1 Avaliação do Trabalho Desenvolvido ................................................................................................. 87 6.2 Perspectivas Futuras.......................................................................................................................... 88 6.3 Considerações Pessoais.................................................................................................................... 89

Referências e Bibliografia ......................................................................................................................91

ANEXO A: Acrónimos Utilizados ....................................................................................................92

ANEXO B: Diagramas de Casos de Utilização ..............................................................................94


vii

Índice de Figuras

Figura 1 - Uma das variações do logótipo do INESC Porto.......................................................1

Figura 2 - Organigrama do INESC Porto ...................................................................................2

Figura 3 - Hierarquia de Utilizadores.......................................................................................41

Figura 4 - Casos de Uso do Sistema Geral separado por pacotes.............................................42

Figura 5 - Funcionamento do Ajax...........................................................................................59

Figura 6 - Arquitectura do Ruby on Rails.................................................................................60

Figura 7 - Fluxograma da Aplicação Web................................................................................62

Figura 8 – Protótipo da interface, mostrando a pesquisa nos conteúdos..................................63

Figura 9 - Diagrama de Actividades da Submissão de Pautas Musicais ..................................64

Figura 10 - Decomposição Horizontal .....................................................................................66

Figura 11 - Diagrama da Base de Dados do Armazenamento..................................................69

Figura 12 - Diagrama de classes do Model...............................................................................74

Figura 13 - Diagrama de classes do Controller........................................................................76

Figura 14 - Diagrama de classes dos helpers do View.............................................................77

Figura 15 – Diagrama de Componentes da Arquitectura Física...............................................80

Figura 16 - Ecrã inicial após autenticação com um Utilizador Privilegiado............................81

Figura 17 - Visualização dos dados de utilizador.....................................................................81

Figura 18 - Validação de utilizadores.......................................................................................82

Figura 19 - Listagem de pautas musicais..................................................................................83

Figura 20 - Submissão de pautas - Passo 1...............................................................................83





Figura 25 - Submissão de pautas - Passo 6 (editor, onde se pode concluir a submissão) ........85

Figura 26 - Submissão de pautas - Passo 6 (edição de uma página) ........................................85

Figura 27 - Pesquisa total .........................................................................................................86


viii

Índice de Tabelas

Tabela 1 – Claves .....................................................................................................................10

Tabela 2 - Armadura de clave...................................................................................................10

Tabela 3 - Notas e pausas .........................................................................................................11

Tabela 4 - Linhas de repetições ................................................................................................12

Tabela 5 - Fórmula de compasso..............................................................................................12

Tabela 6 - Articulações.............................................................................................................12

Tabela 7 - Requisitos do Sistema .............................................................................................43

Tabela 8 - Requisitos da Gestão da Conta de Utilizador..........................................................45

Tabela 9 - Requisitos da Gestão de Utilizadores......................................................................46

Tabela 10 - Requisitos da Gestão de Pautas .............................................................................46

Tabela 11 - Requisitos da Gestão de Autores...........................................................................47

Tabela 12 - Requisitos da Gestão de Instrumentos...................................................................47

Tabela 13 - Requisitos da Gestão de Géneros Musicais...........................................................48

Tabela 14 - Gestão de Actualizações........................................................................................48

Tabela 15 - Validação de Utilizadores .....................................................................................48

Tabela 16 - Validação de Pautas...............................................................................................49

Tabela 17 - Validação de Autores ............................................................................................49

Tabela 18 - Validação de Instrumentos ....................................................................................49

Tabela 19 - Requisitos do Motor de Pesquisa ..........................................................................50

Tabela 20 - Requisitos da Aplicação de OMR .........................................................................51

Tabela 21 - Requisitos do Editor de MusicXML......................................................................55

Tabela 22 - Requisitos do Armazenamento..............................................................................56

Tabela 23 - Descrição sumária das classes do diagrama da base de dados ..............................69

Tabela 24 - Tabela users...........................................................................................................71

Tabela 25 - Tabela works..........................................................................................................72

Tabela 26 - Tabela authors.......................................................................................................72

Tabela 27 - Tabela authors_works...........................................................................................72

Tabela 28 - Tabela musical_genres..........................................................................................72

Tabela 29 - Tabela sections......................................................................................................72

Tabela 30 - Tabela scores.........................................................................................................72

Tabela 31 - Tabela instruments................................................................................................72

Tabela 32 - Tabela instruments_sections.................................................................................73

Tabela 33 - Tabela updates.......................................................................................................73


1

1 Introdução

Nesta secção é inicialmente feita uma breve apresentação da instituição onde o estágio foi realizado. Após essa primeira apresentação descreve-se o projecto de estágio enunciando os objectivos do mesmo, distinguindo o projecto total em que o estágio se insere assim como a parte que foi abordada durante o estágio, numa segunda subsecção. Por fim, é descrito o modo como o presente documento se encontra organizado, com vista a colocar o leitor familiarizado com o mesmo para permitir uma leitura mais agradável.

1.1 Apresentação do INESC Porto 1

O INESC Porto2 (Instituto de Engenharia de Sistemas e Computadores do Porto) é uma associação privada sem fins lucrativos declarada de utilidade pública, constituída em 18 de Dezembro de 1998, cujos associados fundadores são o INESC, a Universidade do Porto (UP) e a Faculdade de Engenharia da Universidade do Porto (FEUP). Em Junho de 2006, a Faculdade de Ciências da Universidade do Porto (FCUP) e o Instituto Politécnico do Porto (IPP) tornaram-se igualmente associados do INESC Porto. Uma das variações do logótipo da instituição pode ser observada na Figura 1.

Figura 1 - Uma das variações do logótipo do INESC Porto

Tendo origem no pólo do Porto do INESC, cuja criação ocorreu em Maio de 1985, o INESC Porto surge como o corolário de um processo de profunda reestruturação do INESC, que começou pela progressiva especialização local dos vários pólos e pela sua autonomização. Esse processo conduziu à constituição de um conjunto de novas instituições, ligadas centralmente ao INESC, o qual assume um papel de um centro de orientação estratégica e consolidação nacional.

Em 2002, foi-lhe atribuído o estatuto de Laboratório Associado pela Fundação para a Ciência e Tecnologia para o quinquénio 2002/2006, após ter obtido a classificação de Excelente na última avaliação efectuada por peritos internacionais nomeados pelo Ministério da Ciência e Tecnologia.

A missão do INESC Porto consiste em exercer uma interface entre o mundo académico e o mundo empresarial da indústria e dos serviços, bem como a administração pública, no âmbito das tecnologias de informação, telecomunicações e electrónica, dedicando-se a actividades de investigação científica e desenvolvimento tecnológico, transferência de tecnologia, consultoria e formação avançada.

Neste enquadramento, o INESC Porto propõe-se a:

1 Esta secção é baseada de forma significativa no Manual de Acolhimento do INESC Porto. 2 http://www.inescporto.pt/


2

• Levar a cabo a produção de ciência e de tecnologia capazes de competir a nível nacional e mundial;

• Colaborar na formação de recursos humanos de qualidade científica e técnica, motivados para apostar

nas capacidades nacionais e na modernização do país;

• Contribuir para a evolução do sistema de ensino científico e tecnológico, modernizando-o e adaptando-o

às necessidades do tecido económico e social;

• Contribuir, pela realização dos objectivos anteriores, para a construção de um Portugal moderno, de uma

economia sólida e de uma sociedade de qualidade.

A Sede Social localiza-se no Campus da FEUP, na Rua Dr. Roberto Frias, 378, 4200-465 Porto. No entanto, para além deste edifício, onde se encontra centralizada grande parte das Unidades, Departamento e Serviços, o INESC Porto tem ainda um pólo no Departamento de Física da FCUP, cuja localização fica na Rua do Campo Alegre, 687, 4050-179 Porto.

Esta instituição conta actualmente com cerca de 300 colaboradores, desde contratados, a bolseiros, docentes e estagiários para realizar as suas actividades e divide-se em várias unidades, como pode ser visto no organigrama da Figura 2.

Figura 2 - Organigrama do INESC Porto

O presente estágio foi realizado na Unidade de Telecomunicações e Multimédia (UTM), cujo Coordenador de Unidade é o Prof. José Ruela. Pode ser consultado no organigrama da Figura 2, estando essa unidade realçada em relação às restantes.

A UTM actua em áreas chave no âmbito das modernas redes e serviços de comunicação, em especial Processamento de Sinal e Imagem, Arquitecturas de Redes, Serviços de Telecomunicações, Microelectrónica, TV (Televisão) Digital e Multimédia. Conta actualmente com cerca de 95 colaboradores.


3

Os Objectivos Estratégicos da unidade são:

• Através da organização de grupos de I&D (Investigação e Desenvolvimento) na Unidade, realizar

investigação básica e promover a formação avançada de recursos humanos, explorando nomeadamente

financiamentos de programas de I&D europeus e nacionais;

• Participar em projectos europeus, que permitem a cooperação científica e técnica com empresas e

centros de I&D de vanguarda, a actualização tecnológica permanente e o acompanhamento da actividade

de organismos de normalização;

• Criar massa crítica nas principais áreas de intervenção da Unidade através de um conjunto de

investigadores altamente qualificados e com competências diversificadas;

• Participar em projectos de I&D de grande dimensão e celebrar de contratos de desenvolvimento ou de

consultoria que requerem o conhecimento e a capacidade de integração de várias tecnologias. Esta

actividade tem sido realizada nomeadamente em parceria com operadores de redes e fornecedores de

serviços de Telecomunicações, operadores de Televisão e fabricantes de sistemas de comunicação e de

equipamento de teste.

Os principais temas de investigação actualmente cobertos pela Unidade são: arquitecturas e protocolos de redes sem fios e móveis e de redes de banda larga, serviços de telecomunicações e aplicações multimédia distribuídas, processamento de áudio digital, análise e síntese de vídeo e imagem, sistemas integrados de televisão digital, teste e validação de sistemas de comunicação, teste e projecto de testabilidade de circuitos electrónicos, arquitecturas reconfiguráveis para processamento dedicado.

1.2 O Projecto SARPMM no INESC Porto

O projecto “Sistema automático de reconhecimento de pautas musicais manuscritas”, daqui em diante referido por SARPMM, é um projecto de longo prazo, estruturado em diversos módulos mais pequenos.

Nesta secção é apresentado o projecto global, em duas subsecções, explicando inicialmente o seu contexto e motivação, seguindo-se os objectivos do mesmo. Apenas na secção seguinte - 1.3 - será dado ênfase à tarefa objecto do presente estágio.

1.2.1 Contexto e Motivação

Neste projecto pretende-se desenvolver um “Sistema automático de reconhecimento de pautas musicais manuscritas”, sendo esta uma área onde as soluções actuais ainda se encontram muito aquém das expectativas.

A notação musical nos dias de hoje é uma das linguagens internacionais mais vastamente reconhecida de sempre. Tem sido desenvolvida ao longo dos tempos com requisitos de consistência e precisão. Ler música é algo que qualquer pessoa pode aprender, e uma vez aprendido torna-se um processo natural que deixa de ser um esforço consciente, de certa forma como acontece com a leitura de palavras que aprendemos desde pequenos. No entanto, os métodos actuais de leitura de pautas musicais manuscritas por computadores ainda se encontram longe de serem perfeitos. A percepção de notação musical através do computador começou com o campo do reconhecimento musical óptico (Optical Musical Recognition - OMR), assim que os investigadores “atacaram” o problema do reconhecimento e interpretação dos símbolos da notação musical impressa a partir de uma imagem digitalizada.


4

Hoje em dia existem diversas soluções de software de OMR comercial, tais como o Capella-scan, OmeR, PhotoScore, SharpEye, e SmartScore. Mais recentemente o interesse na percepção foi estendido a todos os componentes: a letra da música, melodia e outros símbolos, até mesmo a componentes multi-linguísticos manuscritos. Tem-se investido bastante na investigação durante as últimas décadas no desenvolvimento de sistemas capazes de reconhecer e interpretar o conteúdo de pautas musicais. O reconhecimento de notação musical através do computador, a sua interpretação e utilização entre várias aplicações levanta diversos desafios e questões em relação aos algoritmos apropriados, técnicas e métodos com os quais se possa reconhecer a notação musical automaticamente.

Apesar da investigação em OMR ser contínua, com a disponibilização de vários sistemas OMR comerciais, ainda continua a ser escasso um desempenho satisfatório em termos de precisão e confiabilidade. Muito do trabalho existente fornece uma eficiência boa apenas quando são processadas folhas de música impressa e bastante regular, uma vez que o OMR clássico se encontra mais focado neste tipo de partituras. Mas essa eficiência é severamente comprometida quando se tratam de pautas manuscritas pois estas introduzem novas dificuldades, com a notação a variar de pessoa para pessoa, e possivelmente variando inclusive na mesma partitura, e com símbolos e linhas de pauta variando em tamanho, formas, intensidade, entre outros. Isto justifica a investigação em torno da definição de algoritmos de OMR robustos. O actual processo necessário para o reconhecimento dessas pautas é manual, e consequentemente muito dispendioso em recursos humanos e tempo.

Em Portugal muitas das obras musicais escritas durante o século XX ainda existem somente como manuscritos originais ou como fotocópias. A preservação da nossa herança musical recente envolve a digitalização destes trabalhos e consequente acessibilidade num formato que permita navegação, análise e a pesquisa pelas características das pautas. Infelizmente, este objectivo ambicioso de possibilitar o acesso generalizado a pautas musicais manuscritas que nunca foram publicadas tem sido sucessivamente atrasado pelo software de reconhecimento de pautas musicais actual. O actual processo necessário para o reconhecimento de símbolos musicais manuscritos em pautas e colocá-los em relação com a estrutura musical é muito dispendioso em tempo, tendo de ser efectuado por via manual.

Desenvolver uma técnica de OMR que possa, de forma semi-automática, representar uma pauta manuscrita num formato digital seria extremamente benéfico pois permitiria um acesso generalizado a partituras que nunca foram publicadas, e portanto de momento dificilmente acessíveis. Sendo Portugal um país onde escasseia uma tradição de publicação musical, a maioria dos trabalhos produzidos durante o último século ainda existem como manuscritos originais e são acedidos e/ou distribuídos como fotocópias. A codificação deste conjunto de trabalhos num formato digital em estilo hierárquico permite uma aprofundada manipulação da informação para publicação, motivos de análise computacional, catalogagem, armazenamento e recuperação de importantes características de todo o conjunto, assim como a extracção das várias partes das músicas. Ou seja, relativamente ao último ponto, se tivermos uma partitura manuscrita com vários instrumentos e a codificarmos no formato digital MusicXML, pode-se extrair facilmente apenas a parte de um desses instrumentos, sem ter de a escrever novamente. Essa mesma tarefa realizada por via manual é um processo extremamente moroso. No entanto, é bastante útil pois permite que se forneça a um músico apenas a partitura do seu instrumento ao invés de este ter de a interpretar por entre as restantes partituras da obra, que é algo que dificulta essa mesma leitura.


5

Tudo isto pode ser conseguido através de um sistema que permita efectuar o reconhecimento óptico, armazenar, pesquisar e navegar por entre as partituras, assim como descarregá-las em MusicXML ou nas imagens originais.

1.2.2 Objectivos

O presente projecto é único em relação a várias características. Não só é dedicado ao reconhecimento da notação musical standard manuscrita (em oposição à notação musical mais antiga, como foi já alvo de outros projectos de OMR), e portanto envolvendo diferentes soluções técnicas, mas tem também como alvo a conversão (semi-)automática da pauta para o formato MusicXML através de um sistema online completo que integre todas as facilidades necessárias aos objectivos deste projecto num só local. O formato MusicXML pretende suportar intercâmbio entre notação musical, actuação, análise, e aplicações de recuperação. Com este formato é possível extrair partes de uma música e fornecer a cada músico que a irá interpretar, somente a sua parte para facilitar-lhe a leitura e desempenho. Desenvolver um procedimento para OMR que realize uma conversão (semi-)automática de uma pauta manuscrita para MusicXML traria diversas vantagens em relação ao acesso e preservação dessa pauta em forma digital:

• O MusicXML permite representar um manuscrito através das suas partes, secções, frases e motivos

musicalmente relevantes, tornando portanto mais fácil o acesso às porções relevantes da pauta enquanto

se navega pela mesma no monitor de um computador;

• A codificação MusicXML permite a recuperação de informação musical relevante para análise, e

portanto facilitando a realização de certos tipos de análises computacionais num conjunto de pautas;

• A codificação MusicXML facilita a conversão de um manuscrito para MIDI (Musical Instrument Digital

Interface) ou outros formatos de representação digital, tais como Humdrum ou MuseData, os quais

permitem que se tenha uma pauta preservada em diversos formatos de acordo com a necessidade e

propósito;

• Finalmente, a codificação MusicXML permite a conversão do manuscrito para publicação de música em

qualidade standard utilizando software de notação musical tais como o Finale ou o Sibelius. Esta

propriedade facilita a reedição dessa pauta e/ou a extracção de partes, e provém directamente da fonte do

manuscrito.

Um benefício adicional da conversão automática e armazenamento da pauta musical em MusicXML é a possibilidade de integrar a pauta manuscrita no formato MX. O MX é um formato multi-camada com base no XML (Extensible Markup Language) para representação de música integrando vários formatos por camada. O MX sincroniza essas várias camadas pertencendo a uma peça de música, por exemplo uma gravação áudio (e.g. em WAV) e a pauta da mesma peça (e.g. em MusicXML). O MX representa portanto uma peça integrando vários formatos de dados sincronizados entre si podendo conter notação, áudio e vídeo.

Neste projecto pretende-se, como objectivo principal, integrar num sistema único tecnologia de OMR que facilite a conversão de pautas de música manuscritas para o formato digital e a sua representação em estilo hierárquico utilizando para tal o formato MusicXML. Ou seja, trata-se da criação de um sistema com o intuito de o disponibilizar online, através do qual se possa efectuar o reconhecimento, edição e armazenamento das pautas musicais manuscritas. Após esse reconhecimento pretende-se obter uma versão digital que seja facilmente gerida, editada, pesquisada, entre outros, a qual ficará imediatamente armazenada no arquivo mantido pelo sistema.


6

Este projecto deverá culminar na criação de uma base de dados de pautas manuscritas de música portuguesa do século XX e de um motor de busca online para acesso à mesma, integrados no sistema completo. Esta base de dados estará disponível para motivos de apreciação, publicação, educacionais e de musicologia, preservando portanto este conjunto de música de uma forma ainda não explorada. Em suma, este projecto é único em combinar música e tecnologias de informação de uma forma bastante coesa. O motor de busca por si só será inovador e poderá ter implicações positivas no futuro do OMR.

1.2.3 Resultados Esperados

Para os objectivos enunciados, tem-se as seguintes expectativas:

• Uma base de dados portuguesa anotada, de pautas manuscritas de música portuguesa do século XX

digitalizadas, contendo o original e a versão em MusicXML;

• Disponibilização de tecnologia de OMR que facilite a conversão de partituras manuscritas em notação

musical standard para formato digital e a sua representação em estilo hierárquico;

• Um sistema computacional para digitalizar pautas musicais manuscritas, no formato MusicXML,

tornando a tarefa mais rápida e menos trabalhosa;

• Motor de pesquisa online de pautas de música portuguesa do século XX;

• Permitir adicionar, visualizar e editar as pautas em MusicXML através do sistema, por via online;

• Aplicação web com tecnologia de reconhecimento de pautas musicais manuscritas integrando todas as

partes enunciadas, criando uma solução completa, de acesso livre.

Para a concretização deste sistema não se pretende “reinventar a roda”, mas sim utilizar soluções existentes, nomeadamente ao nível do OMR, integrando-as numa primeira fase e desenvolvendo apenas os módulos necessários. No entanto, em paralelo será feito um estudo em relação às técnicas, algoritmos e métodos do módulo de OMR.

Após essa fase de integração e desenvolvimento dos módulos inexistentes é que serão usadas as técnicas e novos métodos de reconhecimento das pautas musicais estudados com vista a realizar um correcto reconhecimento das pautas musicais manuscritas, melhorando dessa forma o módulo de OMR integrado no sistema realizando um avanço importante nesta área.

Desta forma é possível preservar todas essas obras musicais e permitir o tratamento da informação de uma forma ainda por explorar. Como as pautas impressas são de certa forma um caso particular, no qual a escrita é mais perfeita, estas serão igualmente reconhecidas. Pretende-se obter um sistema bastante completo, o que irá fomentar um grande avanço neste campo.

1.3 Estudo e Desenvolvimento da Aplicação OMRSYS no Projecto SARPMM

A realização do projecto no seu todo abrangerá um espaço de tempo maior do que a duração do presente estágio curricular, no qual o projecto teve início, devido à sua grande dimensão e complexidade. Após ter sido inicialmente produzida toda a especificação e arquitectura do sistema, tentou-se avançar o mais possível no desenvolvimento, obtendo-se uma solução funcional, com boa qualidade e que permita demonstrar o funcionamento do sistema. Este protótipo foi desenvolvido integrando soluções existentes, complementado com a implementação dos módulos inexistentes para esta primeira fase do projecto. Pretende-se


7

desta forma obter um sistema funcional com vista a ser melhorado futuramente com a continuação do projecto.

Desta forma, após o estudo e a especificação do sistema, desenvolveu-se uma aplicação web, o OMR System (daqui em diante será referido por OMRSYS), integrando os módulos existentes com os módulos implementados.

O principal objectivo durante o estágio foi o de especificar todo o sistema e desenvolver a aplicação web e respectiva base de dados. Para efectuar o reconhecimento óptico foi usado um software de OMR livre já existente. Relativamente à edição das partituras em MusicXML no estágio, pretendeu-se permitir fazê-lo pelo menos de uma forma simples, que mais tarde no projecto será convertido num editor real. Assim como o motor de pesquisa também nesta fase inicial é ainda um motor simples que ainda não efectua pesquisas a nível da informação contida nas pautas em MusicXML. A aplicação foi desenvolvida seguindo o modelo iterativo e incremental.

Em geral os objectivos para a aplicação web no presente estágio consistem em permitir:

• Adicionar partituras ao sistema, com reconhecimento e conversão para MusicXML integrados na

aplicação web;

• Fazer toda a gestão da informação do sistema: utilizadores, partituras, autores, instrumentos, entre

outros. E permitir a navegação por entre toda essa informação;

• Manter um arquivo de partituras navegável, guardando a sua forma original assim como a forma digital

obtida através do reconhecimento óptico;

• Pesquisar por entre toda a informação no sistema;

• Editar as pautas submetidas assim como as existentes de forma textual, e uma vez que a sua visualização

está dependente do editor, a visualização também é textual.

1.4 Organização e Temas Abordados no Presente Relat ório

O presente documento encontra-se dividido em sete capítulos que descrevem o projecto assim como a parte desenvolvida durante o estágio. E também por um conjunto de anexos com informação complementar que de uma forma ou outra ajudam a melhor compreender o problema e o trabalho realizado.

Após este capítulo introdutório, no Capítulo 2, Análise do Problema, apresenta-se o problema em detalhe, num contexto geral. E no final é indicado o plano de trabalhos do estágio.

No Capítulo 3, Revisão Tecnológica, analisa-se o estado da arte, fazendo uma análise crítica sobre as soluções existentes ou semelhantes, e suas lacunas. Segue-se também uma análise crítica sobre as possíveis tecnologias a usar na implementação do sistema.

No Capítulo 4, Especificação, descreve-se os vários tipos de requisitos da solução a implementar.

No Capítulo 5, Desenvolvimento da Aplicação, começa-se por justificar as tecnologias adoptadas. De seguida é efectuada uma descrição pormenorizada da solução desenvolvida, na qual se refere os vários aspectos e detalhes do modelo de dados e da interface.

No Capítulo 6, Avaliação de Resultados, faz-se uma análise e discussão sobre os resultados obtidos.


8

No Capítulo 7, Conclusões e Perspectivas de Trabalho Futuro, tiram-se conclusões acerca do trabalho desenvolvido, perspectivas futuras e algumas considerações pessoais.

1.5 Contribuições deste Projecto e Publicações Rela cionadas

Resume-se de seguida as contribuições deste projecto para a preservação da nossa herança cultural e o acesso generalizado à mesma:

• Preenche a lacuna do reconhecimento óptico de pautas musicais manuscritas em notação standard;

• Não dá atenção apenas ao reconhecimento óptico, mas sim a uma solução de OMR completa e livre,

disponível online, que inclui de uma forma integrada o armazenamento das obras musicais, facilidades

de gestão de todo o arquivo e as facilidades necessárias para efectuar a submissão e reconhecimento das

partituras;

• Guarda as pautas digitalizadas em MusicXML, um formato recente e em expansão;

• Permite a construção de todo um corpus, a sua preservação e estudo, e também a sua manipulação

permitindo a extracção de partes, entre outros.

O trabalho relacionado com este projecto resultou já na aceitação para publicação do artigo “A Shortest Path Approach for Staff Line Detection”, Ana Rebelo, Artur Capela, J. F. Pinto da Costa, C. Guedes, E. Carrapatoso, Jaime S. Cardoso, na International Conference on Automated Production of Cross Media Content for Multi-channel Distribution (AxMedis 2007) e na submissão para publicação do artigo “Automatic Recognition System for Handwritten Music Scores”, Artur Capela, E. Carrapatoso, Jaime S. Cardoso, na IASTED International Conference EuroIMSA 2008.


9

2 Análise do Problema

Neste capítulo é feita a apresentação do problema num contexto global, dizendo quais são os pressupostos, o que se espera obter e os sub-problemas em que se pode desdobrar. São também apresentados alguns conceitos fundamentais para uma melhor compreensão do problema e do projecto. No final é apresentado o plano de trabalhos do estágio.

2.1 Conceitos Fundamentais

Para melhor se compreender o âmbito do projecto em estudo, existe um conjunto de tópicos referentes às obras musicais, que são pertinentes apresentar. Cada um desses tópicos encontra-se numa subsecção própria.

2.1.1 Organização de uma Obra Musical

As partituras alvo deste projecto no geral estão organizadas da seguinte forma: encontram-se escritas com todas as partes, ou seja, todos os instrumentos numa só secção ao mesmo tempo. Podemos ter, por exemplo, uma peça escrita para piano, violino e violoncelo, e todas essas 3 partes estarem escritas na mesma folha de pauta em conjunto.

No entanto, é possível que se tenha uma obra separada em várias secções, como é costume acontecer em alguns estilos de música. Ou seja, é possível ter uma pauta completa só para um dado instrumento e outra em separado para um outro instrumento dessa mesma peça, por exemplo. Por outras palavras, teríamos essa obra separada em 2 secções ao invés de se ter os instrumentos todos em conjunto numa só partitura.

Devido a esta possibilidade, e com vista a tornar o sistema o mais flexível possível, é de todo o interesse que o mesmo permita submeter obras musicais com uma ou mais secções, cobrindo os vários casos possíveis.

2.1.2 Símbolos a Reconhecer

O ideal para o sistema a desenvolver seria o reconhecimento de toda a notação musical, tal como um músico real reconheceria. E mesmo assim, em geral, um músico não reconhece todos os tipos de notação musical existente. A notação musical é largamente vasta, considerando todas as possibilidades existentes e as suas variações ao longo dos tempos. Conseguir ter um sistema a reconhecer todas as possibilidades, como um Ser Humano, seria algo extremamente complexo e talvez de momento impraticável. Algo desta complexidade requer estudos longos de vários anos, existindo inclusivé diversos investigadores nesta área a realizar trabalho há longos anos e ainda não existem soluções de OMR ideais.

No entanto, mesmo sem considerar todas as variantes, o problema é já uma tarefa bastante complexa, principalmente considerando que se trata de notação manuscrita, o que traz uma série de dificuldades acrescidas devido às variações na notação de cada pessoa ao escrever os mesmos símbolos. Existe ainda o problema de que, considerando todas as possibilidades existentes, diversos símbolos podem ser confundidos entre si devido à sua semelhança, principalmente sendo manuscrito devido a linhas demasiado juntas ou separadas, entre outros problemas. Também, em certos casos, podem aparecer símbolos mais complexos na partitura, os quais se podem comparar a uma estrutura de dados no sentido de que são um todo mais


10

complexo e portanto complicado de reconhecer, como por exemplo as cifras de música de guitarra, que são um diagrama que representa as posições onde marcar as notas no instrumento.

Devido aos problemas enunciados e aos objectivos deste sistema, é necessário fazer uma selecção mais específica do problema a resolver, ou seja, seleccionar quais os símbolos que deverão ser tratados pela aplicação de OMR do projecto. Em primeiro lugar esta aplicação irá reconhecer notação standard. Logo, variantes históricas de tipos de notação específica não serão tratados, assim como por exemplo, a notação de bateria, para a qual não existe sequer um standard global, aparecendo com diversas variações consoante os autores e publicações. As tablaturas também não serão reconhecidas, até porque é algo específico de certos instrumentos e não geral. Para além disso uma tablatura é um conceito diferente, não é uma partitura propriamente dita. Seria também complicado visto que se teria de reconhecer números e seria uma segunda “pauta” com número de linhas variável consoante o instrumento (e.g. 6 para guitarra e 4 ou 5 ou 6 para baixo) o que provavelmente traria confusão para o reconhecimento. O espaçamento entre as linhas também é geralmente variável. Essas notações não fazem parte do corpus que este projecto tem como objectivo preservar e reconhecer para armazenar em MusicXML. No entanto o sistema pode conter vários módulos de OMR para além do que é alvo de estudo neste projecto.

Apresenta-se de seguida os símbolos a serem reconhecidos, agrupados em várias tabelas contendo imagens exemplificativas. É preciso ter também em conta que alguns têm mais do que uma forma, como é o caso de uma colcheia solitária ou se estiver agrupada com outra(s).

Símbolo Exemplos

Clave de Sol

Clave de Dó

Clave de Fá

Tabela 1 – Claves

Símbolo Exemplos

Nenhum

Sustenidos

Bemóis

Tabela 2 - Armadura de clave


11

Símbolo Exemplos Símbolo Exemplos

Semibreve

Pausa de Fusa

Pausa de Semibreve

Semifusa

Mínima

Pausa de Semifusa

Pausa de Mínima

Figura com

ponto(s)

Semínima

Nota com sustenido

Pausa de Semínima

Nota com

duplo sustenido

Colcheia

Nota com

bemol

Pausa de Colcheia

Nota com

duplo bemol

Semicolcheia

Nota com bequadro

Pausa de Semicolcheia

Acordes

Fusa

Quiálteras

Tabela 3 - Notas e pausas


12

Símbolos Exemplos

Pauta

Linhas e espaços

suplementares

Linha de compasso

Linha de compasso dupla

Barra final

Marcas de repetição

Chaves de volta

Tremolo

Simile

Tabela 4 - Linhas de repetições

Símbolos Exemplos

Fórmula de compasso

Tempo 4/4

Tempo 2/2

Tabela 5 - Fórmula de compasso

Símbolos Exemplos

Ligadura

Legato

Tabela 6 - Articulações

Em relação às claves é necessário considerar também a sua posição relativamente às linhas de pauta. Com base nisso sabe-se então as notas de cada linha da pauta (ainda sem considerar a tonalidade) a partir da linha onde a clave começa, pois a mesma clave pode começar em linhas diferentes em certos casos.

A armadura de clave representa a tonalidade da peça. O reconhecimento das tonalidades é fundamental pois, para além de ser necessário saber as notas que cada linha e espaço


13

representam, é igualmente fundamental saber se têm alterações, senão pode ser lida a nota errada. Estes símbolos a representar a tonalidade ficam sempre ao lado direito da clave, seja ela qual for. A ordem tanto dos sustenidos como dos bemóis é fixa, sendo a que se pode ver nos exemplos que constam da tabela. Contudo, não têm de estar especificamente nas linhas em que ali aparecem, embora seja pouco comum isso acontecer.

As notas e pausas podem ter algumas variações. A Tabela 3 mostra-as de uma forma genérica abrangendo todos os casos que deverão ser tratados. Contudo, há alguns pontos que necessitam uma explicação.

Qualquer nota ou pausa, e não apenas as do exemplo na Tabela 3, pode ter um ou mais pontos. Quando uma nota ou pausa tem um ou mais pontos, a sua duração total equivale à sua duração mais a dos pontos. A duração de cada ponto é igual a metade do que tem antes, ou seja, o primeiro ponto equivale a metade da duração da nota, o segundo a metade da duração do ponto anterior, e assim por diante.

Algumas notas podem ser agrupadas, como se mostra no segundo exemplo das colcheias, semicolcheias, fusas e semifusas na Tabela 3. Estas notas podem aparecer tanto agrupadas como singulares. Os acidentes ou alterações (sustenidos, bemóis e bequadros) podem aparecer em qualquer nota, mas em pausas não.

As notas foram exemplificadas sem harmonia, ou seja, singulares. No entanto numa pauta as notas poderão estar agrupadas na vertical, formando um acorde ou harmonia, e portanto é preciso considerar esses casos também em que em vez de se ter apenas uma cabeça de nota têm-se várias empilhadas. No caso das figuras com haste, só aparece uma haste ligada a elas. É o exemplo dos acordes na Tabela 3.

É necessário também reconhecer as variações na divisão do tempo, ou seja, as quiálteras, estando representado um exemplo de uma tercina. Contudo, existem muitos casos possíveis, por exemplo com cinco notas agrupadas, seis notas, doze notas, entre outros. E inclusivé em vez de ter só um número existem casos em que aparece o número de notas reais separado com ‘:’ do número de notas esperadas. Por exemplo, se aparecer “6:4” significa que são tocadas 6 notas no lugar de 4.

O reconhecimento das linhas de pauta é absolutamente indispensável para se poder eliminar (ou marcar com outra cor) para permitir o correcto reconhecimento dos restantes símbolos e poder identificar todas as notas presentes na pauta. São igualmente indispensáveis as linhas suplementares para permitir reconhecer igualmente as notas presentes nessas partes, que são inclusivé bastante frequentes.

As linhas de compasso podem ajudar se forem reconhecidas pois sabendo as divisões dos compassos permitem verificar se a duração total das notas reconhecidas no interior de um compasso bate certo e portanto dessa forma pode-se detectar falhas no reconhecimento e tentar corrigir durante esse processo. Já as linhas de compassos duplas e barra final não são muito necessárias pois as primeiras apenas separam secções da música e a barra final indica o final da peça, o que pode ser facilmente deduzido com a leitura do último compasso. No entanto, em relação às linhas de compasso duplas é necessário reconhecê-las pelo menos como uma linha de compasso para o poder separar do seguinte.

As marcas de repetição são frequentes e portanto é útil reconhecê-las. Ajudam a definir a estrutura musical da peça. E as chaves de volta são um complemento quando as repetições envolvem terminações diferentes, e portanto cada número indica a vez em que essa parte é


14

tocada nas repetições. Existem ainda símbolos para repetições envolvendo áreas maiores de uma peça: contudo é algo simples de colocar manualmente e para uma primeira fase não será algo fundamental. Esses símbolos são os Coda e Segno, por exemplo.

O tremolo é a repetição de uma nota ou acorde o mais rápido possível de forma regular, não é muito frequente, aparecendo geralmente em poucas notas durante uma peça, se aparecer de todo. É portanto pouco necessário o seu reconhecimento.

Os símbolos simile são importantes de reconhecer porque são símbolos de repetição que substituem as notas numa pauta, indicando que o compasso ou conjunto de compassos assinalados são iguais ao(s) anterior(es).

A correcta identificação do compasso é outra questão bastante importante, pois com base nisso pode-se verificar que o que foi reconhecido se encontra coerente e portanto provavelmente correcto. Com o compasso sabe-se quantos tempos se deve ter em cada caixa (também denominada por compasso). O compasso tem duas possíveis formas de apresentação, sendo uma delas através de 2 números sobrepostos, como uma fracção, mas sem traço. Ou então através de um símbolo nos casos particulares de ser quaternário com unidade semínima (4/4) ou binário com unidade mínima (2/2). Aparece logo a seguir à tonalidade.

A Ligadura é um sinal de forma semicircular que se coloca acima ou abaixo das notas para ligar sons. Neste caso é a união de duas ou mais notas da mesma altura e mesmo nome. As durações das notas são somadas e ela é tocada como uma única nota. O Legato significa que as notas cobertas por este símbolo devem ser tocadas sem nenhuma interrupção como se fossem uma só, continuamente. Neste tipo de símbolo, devido a serem bastante variáveis pode ser complicado identificá-los, no entanto devido à sua frequência é importante reconhecê-los.

Esta apresentação não é de forma alguma exaustiva, é somente uma parte da notação standard que é mais importante ser reconhecida inicialmente. Com toda esta especificação já é possível reconhecer pautas completas e com input mínimo por parte do utilizador após o processo de reconhecimento. Estando esta porção principal concluída, o projecto, em relação a este módulo, poderá avançar para o reconhecimento e interpretação de mais símbolos com vista a tornar o sistema cada vez mais completo e aos poucos eliminar a necessidade de intervenção do utilizador.

2.1.3 Semântica Musical

Os símbolos por si só não são suficientes, é preciso realizar a sua interpretação, compreender as relações entre si. E aí sim, teremos um reconhecimento da pauta analisada. É portanto necessário definir essas relações todas antes de serem implementadas na aplicação.

Para obter a relação entre os símbolos é necessário efectuar algumas análises. Para se saber a altura de uma nota (qual a nota que a figura representa) tem de se relacionar a mesma com as linhas de pauta, a clave e a tonalidade. É preciso também verificar se tem algum sustenido, duplo sustenido, bemol, duplo bemol ou bequadro junto à nota. As durações das notas podem ser obtidas relacionando as cabeças das notas com as hastes, feixes e bandeiras (stems, beams, flags), e sem esquecer os pontos que aumentam a duração das notas (não confundir com a técnica stacato, na qual o ponto aparece por cima ou por baixo da nota ao invés de aparecer à sua direita).


15

A separação dos vários compassos deverá ser verificada com o valor do compasso reconhecido, permitindo verificar se as leituras à partida estarão ou não correctas.

2.2 Descrição Geral

O levantamento de informação através da proposta de candidatura do projecto da FCT (Fundação para a Ciência e Tecnologia), pesquisa de informação em vários sítios web acerca do tema e estudo dos trabalhos realizados na área, e reuniões com pessoas associadas ao projecto, permitiu realizar um estudo acerca do que o sistema deverá ser. Com esse estudo foi possível identificar os intervenientes, as funcionalidades e todas as características desejáveis do sistema.

Nesta secção realiza-se uma apresentação de todo o sistema num contexto geral, referindo os seus intervenientes.

2.2.1 Intervenientes

Para este sistema identificou-se a existência de quatro classes de utilizadores. Irão ser descritos de forma gradual desde o que tem menos acesso até ao utilizador administrativo com acesso total às funcionalidades do sistema.

O Utilizador Geral é um utilizador não registado, e portanto com acesso restrito, pode apenas consultar informação e não pode adicionar, editar, nem remover. Em geral pode-se dizer que é um visitante, podendo consultar as pautas e informação existentes e efectuar pesquisas. Contudo, pode registar-se livremente no sistema para poder usufruir de um acesso mais privilegiado, tornando-se num Utilizador Registado. Mas o registo só se torna efectivo após validação por parte do Administrador ou um Utilizador Privilegiado.

O Utilizador Registado, para além de usufruir dos privilégios de um Utilizador Geral, tem ainda acesso para introduzir novos objectos no sistema, assim como editá-los e removê-los. Contudo apenas pode editar e/ou remover objectos que tenha adicionado. Por último pode gerir a sua conta de utilizador, ou cancelá-la, perdendo o estatuto de Utilizador Registado, e portanto perdendo os privilégios que lhe estavam atribuídos. Nesse último caso os objectos que lhe estavam associados passam a pertencer ao Administrador por forma a serem mantidos no sistema, pois devido à sua natureza é importante mantê-los.

Para além do Utilizador Registado existe um outro tipo de Utilizador Registado, com mais privilégios, que é precisamente o Utilizador Privilegiado, cujo registo só pode ser efectuado pelo Administrador do sistema. No fundo o Utilizador Privilegiado é quase um Administrador pois pode realizar todas as tarefas de administração possíveis, excepto a de gerir os utilizadores do seu nível, que só é permitida ao Administrador por questões de segurança. O Utilizador Privilegiado, para além do acesso que um Utilizador Registado possui, ainda possui também o acesso à gestão de Utilizadores Registados, ou seja, pode criar, editar e remover utilizadores desse tipo. Pode ainda validar objectos em fila de espera por validação, e não precisa de esperar para que os objectos que criar sejam validados, pois são automaticamente considerados validados ao serem inseridos por este utilizador. Este perfil de utilizador é pensado para o caso de professores e representantes de instituições, ou seja, utilizadores com um estatuto maior, e portanto com outras exigências e considerados como sendo utilizadores confiáveis. Podem por exemplo pretender criar contas para alunos seus e no que respeita à gestão de objectos têm acesso não só aos seus, mas a todos os presentes no sistema. Têm a possibilidade de criar actualizações/notícias e fazer a sua gestão.


16

Por último, o Administrador tem acesso total às funcionalidades e recursos do sistema. Contudo, não se pode remover a si próprio do sistema ou deixaria de haver Administrador. Apenas este utilizador especial pode gerir os Utilizadores Privilegiados, ou seja, criar novos utilizadores deste tipo, assim como editá-los e removê-los.

Nenhum dos utilizadores precisa de ter um vasto conhecimento técnico pois toda a interacção com o sistema é feita intuitivamente através de um browser. Contudo, a administração do sistema também pode ser necessária a nível da base de dados e aí já serão necessários alguns conhecimentos técnicos. No entanto, num funcionamento normal isso não será necessário, visto toda a gestão ser feita através da aplicação web.

2.2.2 Sistema Global

O sistema desenvolvido no presente estágio tem como objectivo fornecer uma solução total para efectuar o reconhecimento óptico de pautas musicais manuscritas, integrando num sistema único todas as facilidades para a realização dessa tarefa, assim como para o armazenamento das partituras reconhecidas. Pretende-se desta forma disponibilizar um método (semi-)automático para efectuar o reconhecimento óptico de pautas musicais manuscritas, e ao mesmo tempo permitir a manutenção de um arquivo para essas obras. Com esse arquivo facilita-se a publicação e estudo das mesmas.

Com base no estudo realizado verificou-se que o sistema deveria ser constituído por várias partes e a interacção ser feita através de uma aplicação web, cujo intuito é de ser acessível por via online com acesso livre ao público em geral. Para além da aplicação web o sistema consiste numa base de dados que guarda toda a informação do sistema, incluindo as partituras e os utilizadores do mesmo, e é constituído também por uma ou mais aplicações de OMR e um editor de partituras em MusicXML que permita editá-las, visualizando a página da pauta com a original lado a lado. A aplicação web contém também um motor de pesquisa cujo intuito é o de permitir não só efectuar pesquisas textuais pelos objectos do sistema, mas também de realizar pesquisas através da informação contida nas pautas em MusicXML. Uma outra questão importante que foi identificada nesta fase foi a de a inserção de novos objectos no sistema, assim como o registo livre de novos utilizadores, terem de ser validados pelo Administrador ou um Utilizador Privilegiado, permitindo dessa forma exercer um controlo sob os utilizadores e nova informação adicionada ao sistema por forma a evitar abusos.

Para além das obras musicais e utilizadores, existem outros objectos associados às partituras que o sistema deve conter. Existem portanto também autores, instrumentos musicais e géneros musicais que devem ser geridos através da aplicação.

Pensou-se também que seria útil poder apresentar actualizações/notícias e fazer a gestão das mesmas, ou seja, permitir colocar actualizações/notícias para as pessoas poderem visualizar ao aceder ao sítio web do sistema. A gestão dessas mesmas actualizações é feita por parte dos Utilizadores Privilegiados e pelo Administrador.

Outra particularidade em que se pensou foi a de criar a aplicação web com suporte multilingue básico, por forma a facilitar o acesso não só ao país de origem das obras que se pretende preservar, mas também internacionalmente.

O sistema deve portanto satisfazer as seguintes áreas de requisitos:

• Aplicação web

• Suporte multilingue


17

• Área do Utilizador Geral

o Registo no sistema;

o Navegação por entre as pautas, autores, instrumentos, géneros musicais e actualizações/notícias;

o Utilização do Motor de Pesquisa.

• Área do Utilizador Registado

o Contém as funcionalidades do Utilizador Geral;

o Autenticação, recuperação de senha e gestão da conta de utilizador, podendo cancelar a mesma;

o Submissão de pautas e respectiva gestão das partituras próprias;

o Criação de autores e instrumentos, assim como a sua edição e eliminação, mas apenas dos que criou.

• Área do Utilizador Privilegiado

o Contém as funcionalidades do Utilizador Registado;

o Edição e eliminação de objectos de todo o sistema, excepto utilizadores do mesmo nível ou superior;

o As submissões de partituras, criação de objectos e utilizadores não estão sujeitas a validação;

o Criação, edição e eliminação de actualizações/notícias e géneros musicais;

o Validações dos objectos criados por Utilizadores Registados, assim como de novos Utilizadores Registados.

• Área do Administrador

o Contém as funcionalidades do Utilizador Privilegiado;

o A pesquisa através do Motor de Pesquisa inclui os utilizadores registados no sistema;

o Não se pode remover a si próprio para não permitir que o sistema fique sem administrador por engano.

• Editor de pautas em MusicXML

o Visualização e edição das pautas em MusicXML lado a lado com as pautas originais.

• Motor de pesquisa

o Pesquisa geral pelos objectos do sistema, pautas e autores;

o Pesquisa pela metadata contida nas pautas em MusicXML.

• Aplicação de OMR

• O módulo de OMR pode conter várias aplicações de reconhecimento óptico;

• Reconhecimento das partituras e armazenamento do resultado em MusicXML.

• Armazenamento

• Base de dados contendo todos os objectos do sistema;

• Suporte XML.

Este sistema deverá permanecer continuamente disponível e não deve permitir acessos indevidos, ou seja, deve permitir apenas as funcionalidades a que um utilizador de um dado nível tenha acesso. Dá-se preferência também a que o sistema possa ser executado em ambientes livres, como por exemplo, em Linux. E pretende-se que possa ser acedido através de qualquer browser instalado num computador pessoal. Em termos de desempenho pretende-


18

se que se justifique usar o sistema para realizar o reconhecimento, ou seja, que o tempo gasto para efectuar essa tarefa seja vantajoso em relação à mesma ser realizada manualmente, pois de outra forma não se justificaria o seu uso. Deve permitir um acesso multi-utilizador igualmente com bom desempenho.

2.3 Plano de Trabalhos do Estágio

O plano de trabalhos do projecto difere do plano de trabalhos do estágio, uma vez que o projecto prolonga-se para além dos 6 meses de estágio, como foi já mencionado no capítulo 1. O estágio prevê o desenvolvimento da aplicação web integrando ferramentas existentes para além dos módulos a desenvolver, por forma a no final se obter um sistema completo já funcional e demonstrável, mas com vista a ser melhorado com a continuação do projecto até responder a todos os objectivos já enunciados.

Inicialmente efectuou-se a análise do problema, já apresentada neste capítulo. Seguir-se-á uma análise sobre o estado da arte, com vista a verificar as soluções existentes ou semelhantes com o objectivo de justificar o trabalho que será realizado neste projecto. Será também efectuada uma análise sobre as tecnologias existentes a considerar para serem utilizadas no desenvolvimento da aplicação web. Após isso será feita a especificação do sistema, detalhando fundamentalmente as partes que serão implementadas durante o estágio. Esta primeira fase está prevista para ter uma duração de dois meses, ao fim da qual será realizada uma apresentação (LabMeeting) no INESC Porto para apresentar o projecto aos restantes colaboradores da instituição. Para finalizar esta primeira fase serão escolhidas as tecnologias por entre as analisadas e feita uma aprendizagem intensiva com o auxílio de documentação apropriada antes de proceder à implementação.

Na fase seguinte dar-se-á início à implementação do sistema começando pela base de dados e depois prosseguindo com a aplicação web durante os 3 meses seguintes. Finalmente proceder-se-á à escrita do presente documento e a afinação do sistema e correcção de problemas que sejam detectados durante essa fase.

Durante o período da implementação pretende-se escrever um artigo de uma outra parte do projecto, acerca de um algoritmo estudado no projecto para a detecção das linhas de pauta. Pretende-se também escrever um outro artigo no final da implementação para publicar o sistema completo.


19

3 Revisão Tecnológica

Neste capítulo faz-se uma apresentação do estado da arte em torno do problema em causa com vista a clarificar a necessidade de desenvolvimento de uma solução para o problema proposto.

Inicialmente é feita uma breve descrição do estado da arte no campo do OMR, após a qual é realizada uma análise crítica das várias soluções existentes ou semelhantes. Por último faz-se uma análise crítica das tecnologias que foram consideradas para serem utilizadas no desenvolvimento da aplicação e da base de dados.

Toda esta análise é feita com base na análise do problema realizada no capítulo 2.

3.1 Estado da Arte

A percepção de notação musical através do computador começou com o campo do OMR, cuja investigação tem sido contínua e começou nos anos 80. Actualmente existem vários sistemas de OMR comerciais, mas o desempenho continua deficiente em termos de precisão e confiabilidade no que respeita a partituras manuscritas uma vez que estes sistemas se orientam mais para partituras impressas. Quando são usados com esse tipo de pautas musicais exibem um bom desempenho se forem bastante regulares, ao contrário do que sucede com as partituras manuscritas.

O reconhecimento de música manuscrita tem sido conduzido por uma diversidade de motivos, e como resultado, com diferentes objectivos técnicos. Num sistema para reconhecimento óptico dos caracteres da notação de música Orthodox Hellenic Byzantine, um sistema deste tipo foi a primeira vez apresentado. O projecto ROMA3, um outro projecto de OMR, foi dedicado ao reconhecimento da notação de música antiga ao contrário do foco deste projecto, que é a notação musical standard. Uma outra diferença relativamente ao presente projecto é a de que esses trabalhos constam somente do reconhecimento e não de um sistema completo como o que é proposto neste projecto. Mais recentemente o interesse na percepção foi estendido a todos os componentes de uma obra, ou seja, a letra, entre outros.

3.1.1 Soluções Existentes ou Semelhantes

Esta secção encontra-se separada em várias subsecções consoante o tipo de solução existente de que se tratar. No interior de cada uma dessas subsecções existe uma subsecção para cada ferramenta, biblioteca, toolkit, formato de dados estudado entre outros. Toda esta análise foi efectuada no primeiro mês do presente estágio e é válida para essa altura. Entretanto novas versões poderão ter sido lançadas.

3.1.1.1 Aplicações de OMR

Esta análise de soluções existentes não é de forma alguma exaustiva, nomeadamente em relação a soluções comerciais. As soluções comerciais analisadas servem apenas como exemplo, havendo muitas outras disponíveis no mercado, de características semelhantes.

3 http://alfa.ist.utl.pt/~mpinto/roma/


20

3.1.1.1.1 OpenOMR

Ligações

• Sítio do projecto: http://sourceforge.net/projects/openomr

• Pacote JfreeChart usado para apresentação de gráficos: http://www.jfree.org/jfreechart

• Pacote Joone usado para redes neuronais: http://www.jooneworld.com

Descrição

O OpenOMR é uma ferramenta de OMR opensource para pautas musicais impressas. Permite a um utilizador digitalizar música impressa e tocá-la através dos altifalantes do computador. Este projecto resulta do trabalho de mestrado de Arnaud F. Desaedeleer conta com a última versão datada de Novembro de 2006. É portanto muito recente e está ainda em fase pre-alpha.

É uma ferramenta multi-plataforma que assenta na linguagem de programação Java. É possível obter resultados positivos com pautas impressas, tendo funcionando relativamente bem com os exemplos impressos testados. Esta aplicação utiliza redes neuronais, permitindo efectuar o treino das mesmas. Sendo opensource e encontrando-se documentada e com resultados positivos com pautas impressas, esta ferramenta aparenta ser um bom ponto de partida para criar uma boa solução de OMR, que inclua mais tarde suporte para pautas manuscritas.

Características

• OpenSource

• Linguagens: Java

• Versão actual: Pre-Alpha

• Plataformas: Windows, Linux/Unix, OS X

• Redes neuronais (possui uma rede de conhecimento básica)

• Usa os pacotes Java Joone (o motor apenas), JfreeChart (necessários para executar) e JCommon

• Contém a tese de mestrado do autor do projecto explicando a arquitectura, a implementação e a

utilização

3.1.1.1.2 Audiveris

Ligações

• Sítio do projecto: https://audiveris.dev.java.net

Descrição

O Audiveris é um módulo de OMR opensource, multi-plataforma e escrito em Java, tendo sido o primeiro disponibilizado nestas condições. Começando por uma imagem de uma pauta musical passada por scanner, por exemplo, pode reconhecer a informação musical contida na pauta. Após isso pode passar essa informação a outras ferramentas tais como um sequenciador de MIDI, um editor de pautas, ou qualquer outra ferramenta que receba como entrada informação musical. Esta aplicação trabalha somente com música impressa.

A versão estável mais recente é a 2.4, que concluiu a primeira fase do projecto. Essa fase consiste na extracção automática de itens musicais, essencialmente baseada na sua aparência e


21

estrutura. No entanto, esta versão data de há mais de um ano, Janeiro de 2006. Mas o projecto no CVS (Concurrent Versions System) data de há três meses atrás. A próxima versão, 3.0, está planeada para incluir elementos importantes da segunda fase. Essa fase consiste no reconhecimento automático dos símbolos individuais extraídos durante a primeira fase e guiado pela gramática musical, e consequente armazenamento usando o formato MusicXML. Existe ainda uma terceira fase planeada, a qual consiste na correcção dos erros inevitáveis que restam no final de todo o reconhecimento.

O Audiveris continua portanto em desenvolvimento, desenvolvimento esse baseado na experiência adquirida a partir de um protótipo escrito em Ada há alguns anos. Até ao momento o desenvolvimento foi maioritariamente focado na primeira fase da extracção automática de música, tendo atingido um nível aceitável com a versão 2.3 (tendo ainda sido lançada a versão 2.4 posteriormente). Contudo, o desenvolvimento da próxima versão, deu já início à implementação da segunda fase, a fase do reconhecimento e armazenamento do resultado obtido. Foi anunciado que demoraria umas semanas, mas na realidade já passou mais de um ano e ainda continua na versão 2.4.

Devido à existência da documentação de implementação, esta aplicação seria um bom ponto de partida para o módulo de OMR, tal como o OpenOMR. No sítio web do projecto existe uma lista de contribuições desejadas, sendo uma delas o tratamento de pautas manuscritas.

Características

• OpenSource

• Linguagens: Java

• Versão actual: 2.4


• Usa redes neuronais, grafos de adjacência linear (LAG – Linear Adjacent Graphs) e sticks (uma técnica

acima dos LAGs para especificamente tirar vantagem dos structuring sticks de uma partitura

• Usa JAI (Java Advanced Imaging)

• O projecto parece estar um bocado parado uma vez que a última versão data de Janeiro de 2006, embora

no CVS pareça ter havido continuidade

3.1.1.1.3 Gamera

Ligações

• Sítios do projecto:

o http://sourceforge.net/projects/gamera

o http://ldp.library.jhu.edu/projects/gamera

o http://www.bzzt.net/~arnouten/wiki/index.php/Gamera

• Vista geral: http://dkc.jhu.edu/gamera/html/overview.html

• Apresentação: http://www.music.mcgill.ca/~ich/classes/mumt611_07/omr_2003.ppt

• Artigo: http://www.music.mcgill.ca/~ich/research/icmc02/icmc2002.gamera.pdf

Descrição


22

O Gamera é um sucessor do AOMR, o qual era direccionado ao reconhecimento musical. O Gamera é um motor opensource de reconhecimento mais vasto, através do qual o reconhecimento musical pode ser implementado como um toolkit. Trata-se de uma framework, ou seja, não realiza o reconhecimento óptico por si só, é somente uma plataforma que pode ser utilizada para implementar módulos de reconhecimento óptico. É intencionada para experts de domínio na criação de aplicações de análise de documentos estruturados, baseada em Python, com muitas extensões em C++ para processamento de imagem de baixo nível. Combina uma biblioteca de programação com ferramentas gráficas para o treino e desenvolvimento interactivo de sistemas de reconhecimento. O formato de saída para representação das pautas reconhecidas é o GUIDO. No caso geral representa a informação num formato baseado em XML. É também extensível através de plugins.

A última versão data de um pouco mais de meio ano, sendo de Junho de 2006. Existe bastante documentação acerca do projecto e sua utilização. Este projecto foi criado como parte do projecto Lester S. Levy Sheet Music Project, representando a Levy Collection uma das maiores colecções online de pautas musicais disponível. O artigo da ligação acima em “Ligações” contém uma breve descrição do sistema, incluindo também uma apresentação na respectiva ligação no mesmo local acerca de todo o projecto. Ambos são de leitura aconselhada para se ter uma ideia do projecto.

Características

• OpenSource

• Linguagens: C++, Python

• Versão actual: 3.0.1 Beta


3.1.1.1.4 AOMR2

Ligações

• Sítio do projecto: http://www.bzzt.net/~arnouten/wiki/index.php/Gamera#AOMR2:_omr_toolkit

Descrição

O AOMR2, também conhecido como GAMUT, é um toolkit de OMR para o Gamera. O toolkit adiciona os algoritmos de segmentação “remove_stems” e “music_segmentation”.

Características

• OpenSource

• Linguagens: Python, C/C++


3.1.1.1.5 Staff Line Removal Toolkit

Ligações

• Sítio do projecto: http://lionel.kr.hs-niederrhein.de/~dalitz/data/projekte/stafflines

Descrição


23

Trata-se de um toolkit de remoção de linhas de pauta para o Gamera. É uma biblioteca de experimentação com diferentes métodos de remoção de linhas de pauta em imagens digitais de pautas musicais. Disponibiliza métodos para remover as linhas de pauta e manter informação acerca das suas posições após isso. Disponibiliza também um mecanismo de plugin que permite adicionar um algoritmo do próprio utilizador para o mesmo efeito.

Características

• OpenSource

• Linguagens: Python, C/C++

• Versão actual: 1.3.1


3.1.1.1.6 OMeR

Ligações

• Sítio do produto: http://www.myriad-online.com/en/products/omer.htm

Descrição

O OMeR é uma aplicação comercial de OMR, a qual permite reconhecer somente música impressa. Trata-se de um add-on para o Melody Assistant ou o Harmony Assistant, os quais são editores de pautas e sintetizadores digitais, sendo o segundo uma versão enriquecida do primeiro. Permite intervir durante o processo para forçar o reconhecimento de alguns símbolos.

O formato de saída é um formato próprio da aplicação.

Características

• Comercial

• Versão actual: 2.1.1

• Plataformas: Windows, OS X

• Reconhece música impressa, mas não manuscrita

3.1.1.1.7 capella-scan

Ligações

• Sítios do produto

o http://www.musicxml.org/capella/capella-scan.html

o http://www.capella-software.com/capscan.htm

Descrição

O capella-scan é uma aplicação de OMR comercial que suporta o formato MusicXML para exportação do resultado do reconhecimento. Esta ferramenta suporta também o reconhecimento de pautas em formato PDF (Portable Document Format). Esta aplicação faz parte do editor de notação musical capella. Apesar de não ser explicitamente indicado, tudo indica que suporta apenas música impressa através dos exemplos dados. Contudo, tem um


24

suporte bastante avançado para efectuar o reconhecimento dos símbolos musicais com sucesso.

Características

• Comercial


• Plataformas: Windows

3.1.1.1.8 SharpEye Music Reader

Ligações

• Sítio do produto: http://www.visiv.co.uk

• Informação sobre o produto: http://www.musicxml.org/sharpeye/index.html

Descrição

O SharpEye é mais um programa de OMR comercial com suporte de MusicXML. Apenas reconhece pautas impressas e permite efectuar correcções após o processo de reconhecimento. Contudo, não dispõe de facilidades para impressão e transposição da música, tendo isso de ser feito através de outras aplicações, tais como o Sibelius.

Características

• Comercial


• Plataformas: Windows

3.1.1.2 Editores e Visualizadores

Nesta secção são apresentados exemplos de soluções existentes no âmbito dos editores e visualizadores de pautas musicais em MusicXML ou noutro formato semelhante.

3.1.1.2.1 Canorus

Ligações

• Sítio do projecto: https://canorus.berlios.de/wiki/index.php/Main_Page

• Ideias do ponto de vista do utilizador: https://canorus.berlios.de/wiki/index.php/Catch_words

• Formato CanorusML: https://canorus.berlios.de/wiki/index.php/CanorusML

Descrição

O Canorus é um editor de pautas opensource num formato baseado em XML, do género do MusicXML, que é o CanorusML. O projecto ainda é bastante recente, encontrando-se ainda na sua segunda versão, 0.2.5, em estado pre-alpha. No entanto é baseado num outro, já com um certo grau de maturidade, pertencente aos mesmos autores, o NoteEdit. Os autores deste projecto pretendem criar uma nova geração do programa e torná-lo multi-plataforma, sendo o Canorus o sucessor oficial do NoteEdit.

Permite a escrita de notas musicais, tem suporte para scripting, importação/exportação de vários formatos, nos quais está planeado o MusicXML, e ainda outras funcionalidades. A


25

aplicação tem já suporte de exportação para o formato do Lilypond e está planeado suportar importação também, sendo o Lilypond uma aplicação do tipo do LateX, mas para pautas, permitindo a escrita de pautas através de código fonte num ficheiro de texto simples, o qual depois é usado para criar o output em PDF, MIDI, entre outros. O ponto mais forte do Lilypond é o output, ponto de enfoque do projecto.

Uma das características previstas para o Canorus é a possibilidade da criação de extensões para o tão popular browser Firefox.

Algumas das funcionalidades de destaque do projecto são:

• Vista do código de fonte da pauta com um parser em tempo real e renderização na vista da pauta;

• Interface por linha de comandos e suporte de scripting;

• Plugins;

• Function markings;

• Novo formato baseado em XML;

• Uso do Qt4 e é multi-plataforma;

• Interface de utilizador moderna (gráficos de vector para os elementos musicais, múltiplos viewports

numa pauta singular);

• Documentação Doxygen;

• Vozes múltiplas – Polifonia e número de contextos ilimitado;

• Múltiplos viewports na mesma pauta;

• Playback com MIDI.

Características

• OpenSource

• Linguagens: C++, Python, Ruby

• Versão: 0.2.5 alpha


3.1.1.2.2 MusicRain

Ligações

• Sítio do produto: http://www.mediarain.com/musicrain

Descrição

O MusicRain é um visualizador de pautas online que foi criado em particular para distribuidores e editoras de pautas musicais, tornando uma biblioteca de pautas musicais num processo de compra e experiência de multimédia interactiva.

Este software permite para além de visualizar as pautas, também ouvi-las e fazer um ajuste dinâmico do playback. É também possível realizar uma exportação directa para MusicXML.

A visualização é de qualidade elevada, permitindo igualmente imprimir com uma qualidade do mesmo nível.


26

Por último, este produto faz a gestão de DRMs (Digital Rights Management) através de medidas sofisticadas de protecção anti-print da imagem no ecrã e com uma segurança de dados avançada.

Características

• Comercial

• Versão: 2.0

• Plataforma: Flash

3.1.1.3 Formatos de Saída

Em seguida são analisados dois formatos de saída para comparação com o formato pretendido para o projecto, o MusicXML, também este analisado para além desses outros dois formatos.

3.1.1.3.1 MusicXML

Ligações

• Sítio do projecto: http://www.musicxml.org

• Definição do formato: http://www.musicxml.org/xml.html

• Exemplo: http://www.musicxml.org/xml/example11.html

• Downloads: http://www.musicxml.org/downloads.html

• Sítio do projecto da biblioteca de MusicXML: http://libmusicxml.sourceforge.net

• Mais informação

o http://www.recordare.com/dtds

o http://www.music-notation.info/en/musixml/MusiXML.html

Descrição

O MusicXML é um formato de notação musical baseado em XML. É aberto para uso geral através de uma licença royalty-free. De momento é suportado por aproximadamente umas 75 aplicações e foi criado e continua em desenvolvimento pela Recordare LLC. A Recordare desenvolveu a tecnologia MusicXML para criar um método internet-friendly para publicação de pautas musicais, permitindo a músicos e fãs de música tirarem mais proveito da sua música online. A versão 2.0 encontra-se em desenvolvimento e o seu lançamento está planeado para breve.

Este formato de representação de notação musical foi desenhado com vista a permitir o intercâmbio de pautas, particularmente entre diferentes editores de pautas musicais. Apesar de ser relativamente recente, tendo a versão 1.0 sido lançada em Janeiro de 2004 e o formato introduzido em 2000, está-se a tornar num standard, havendo já algumas aplicações opensource a suportá-lo, para além de todas as comerciais existentes.

O formato é definido através de uma série de DTDs (Document type definitions), as quais são livremente redistribuídas através da licença pública de MusicXML Document Type Definition. Com este formato é possível publicar mais facilmente os trabalhos musicais, e sendo aberto é possível tornar as pautas digitais mais populares e assim permite-se que seja usável pelo maior número possível de aplicações.


27

É também, de certa forma, um tradutor universal para notação musical ocidental comum desde o século XVII, pois pode-se desta forma efectuar, através do uso de ferramentas apropriadas, a conversão entre formatos de notação musical. Encontra-se desenhado como um formato de intercâmbio para notação, análise, recuperação, e aplicações de actuação.

Foi criada uma biblioteca de MusicXML em C++, portável e intencionada a facilitar o suporte deste formato. É um projecto opensource, e disponibiliza a conversão de/para representação em memória e o formato MusicXML. Uma vez que o formato foi primariamente desenhado para intercâmbio, conversões para outros formatos de representação de música estão contidos na biblioteca. O formato GUIDO já é suportado e as ferramentas de conversão correspondentes encontram-se incluídas na biblioteca.

Características

• Formato aberto e royalty-free, baseado em XML

• Está a ser desenvolvida a nova versão, 2.0, a ser lançada no 1º semestre de 2007

3.1.1.3.2 NIFF

Ligações

• Informação: http://neume.sourceforge.net/niff/

Descrição

O formato NIFF (Notation Interchange File Format) é uma formato de representação de notação musical, usado primariamente para transferir notação musical entre diferentes editores de pautas. É de momento considerado obsoleto devido ao surgimento do MusicXML, tendo inclusive o sítio do projecto sido fechado em Fevereiro de 2006.

O projecto do formato NIFF começou em Fevereiro de 1994 com vista a criar um formato aberto que permitisse o intercâmbio de música entre diversas aplicações, tendo o projecto sido patrocinado por várias editoras de software de notação musical.

Este formato é baseado no formato RIFF (Resource Interchange File Format), o qual é um formato disponibilizado pela Microsoft, no qual a informação é dividida em listas, chunks e etiquetas. Praticamente toda a informação num ficheiro NIFF é opcional. O nível de detalhe contido pode variar entre apenas a altura e tempo (tipo MIDI) até uma disposição completa da página, gráficos embutidos e informação de MIDI embutida. O standard nunca se chegou a estabelecer excepto num intercâmbio limitado entre software de OMR e de escrita de pautas.

Características

• Formato aberto baseado no formato RIFF

• Considerado obsoleto após o surgimento do MusicXML

3.1.1.3.3 GUIDO

Ligações

• Sítio do projecto: http://www.informatik.tu-darmstadt.de/AFS/GUIDO

Descrição

O formato GUIDO é uma linguagem formal para representação de música ao nível da pauta, sendo representado em texto simples. É muito flexível e pode ser facilmente estendido e


28

adaptado para capturar uma vasta variedade de características musicais para além da notação musical convencional, com a sua sintaxe não restringindo as características que pode representar. Portanto, o GUIDO pode ser facilmente adaptado e personalizado para cobrir conceitos musicais especializados. O seu desenho é fortemente influenciado pelo objectivo de facilitar uma representação adequada do material musical, desde pequenas porções até pautas sinfónicas complexas. O GUIDO é um formato de notação musical de propósito geral. É intencionado para software de notação, sistemas de composição e analíticos e ferramentas, sistemas de actuação, e grandes bases de dados musicais. É flexível, facilmente portável e possibilita a leitura directa por uma pessoa.

Este formato começou a ser trabalhado em 1992/1993. Não é primariamente focado em notação musical convencional, mas foi criado como um formato aberto, capaz de armazenar informação musical, estrutural e de notação.

O GUIDO encontra-se estruturado em três camadas consecutivas:

• Basic GUIDO – Introduz os conceitos principais e permite representar muita da música convencional de

hoje;

• Advanced GUIDO – Estende o Basic GUIDO adicionando formatação de pauta exacta e alguns

conceitos musicais mais avançados;

• Extended GUIDO – Pode representar extensões definidas pelo utilizador, assim como informação

microtonal ou classes de altura definidas pelo utilizador.

Características

• Formato aberto

3.1.1.4 Motores Online

A seguinte lista de motores online contém alguns sítios que foram encontrados, a título de exemplo do que existe actualmente. A primeira ligação da lista é de um projecto associado ao Gamera, já apresentado na secção 3.1.1.1.3.

• http://levysheetmusic.mse.jhu.edu

o É possível ver as pautas em imagem apenas e efectuar pesquisas, por pautas, autores e também com alguma

informação acerca das obras, mas não a nível de conteúdo musical

• http://www.music-scores.com

o A pesquisa é a nível do sítio e pode-se ver as pautas em formato PDF, podendo-se também tocá-las e ouví-las,

através do Scorch Plug-in do Sibelius Software

• http://www.musicaviva.com

o Portal que reúne ligações para pautas existentes noutros sítios web, permitindo uma navegação através de vários

critérios diferentes. Contém uma pesquisa simples pelo sítio

• http://sca.uwaterloo.ca/Mutopia

o Pesquisas ao nível do sítio. Navegação por autor, instrumento ou na totalidade. A distribuição dos ficheiros são

em PDF, PS (PostScript) e no formato Lilypond

• http://www.nissimo.com

o Pesquisas a nível do sítio. De resto o sítio encontrava-se com problemas na altura em que foi visitado e por isso

não foi possível ver pautas por exemplo


29

• http://plato.acadiau.ca/courses/musi/callon/2273/scores.htm

o Colecção de ligações para sítios web com pautas, separados por vários critérios

3.1.1.5 Resumo Crítico

Após a realização desta análise de soluções existentes no mercado actualmente, verifica-se a necessidade e interesse existente na continuação do desenvolvimento e estudo de novas soluções, que preencham as lacunas existentes e melhor satisfaçam as necessidades dos utilizadores.

A análise efectuada tentou de certa forma cobrir exemplos das várias partes relacionadas com o sistema proposto, ou seja, aplicações de OMR, editores de pautas com suporte MusicXML, arquivos de partituras online e seus motores de busca, verificando ao mesmo tempo soluções livres e comerciais.

Como se pode constatar existem já soluções opensource disponíveis para as várias partes consideradas. No entanto, as aplicações de OMR apenas tentam responder às necessidades do reconhecimento de pautas musicais impressas. Embora se obtenha resultados razoáveis ainda se encontram longe do ideal. Mas apesar do trabalho que ainda se encontra por realizar no desenvolvimento destas soluções elas são já um bom ponto de partida, nomeadamente para continuar o seu desenvolvimento e estudo com investigação nesta área. Uma dessas soluções, o OpenOMR, é bastante recente e ainda é pre-alpha. Mas já apresenta resultados aparentemente bastante satisfatórios, é multi-plataforma e encontra-se bastante documentada. Outra solução opensource e multi-plataforma, o Audiveris, foi a primeira a aparecer nestas condições e conta já com mais tempo de vida, encontrando-se numa versão estável e aparentemente bastante documentada. Contudo, ainda só está concluída uma parte do sistema e aparenta estar um pouco parado no que respeita ao seu desenvolvimento. Foi também analisado o Gamera com a biblioteca AOMR2, o qual é uma framework opensource de reconhecimento óptico multi-plataforma, em versão beta, que combina uma biblioteca de programação com ferramentas gráficas. Este projecto insere-se num projecto maior, o Lester S. Levy Sheet Music Project, que pretende ser uma colecção online de pautas musicais. Ainda nenhum dos três suporta MusicXML. Contudo a segunda fase do desenvolvimento do Audiveris incorpora a exportação para esse formato.

As soluções de OMR comerciais existentes no mercado actual também têm maior foco em pautas impressas, com bons resultados em geral, mas continua presente a lacuna das pautas manuscritas. E são também bastante dispendiosas em termos de custo. É por isso mesmo bastante apetecível a existência de soluções de utilização livre.

Estes sistemas de OMR em geral são usados offline em modo standalone, não havendo uma disponibilização online de forma integrada para efectuar o reconhecimento óptico, edição, armazenamento e pesquisa como no sistema que se pretende desenvolver neste projecto. Existem motores online, no entanto são apenas colecções de pautas e em geral não permitem pesquisas a nível da metadata das pautas, até porque em geral as pautas não estão num formato adequado (e.g. MusicXML). No sistema a desenvolver pretende-se criar um motor de busca que permita pesquisar no arquivo com base na informação musical das partituras. Este sistema integrando as várias partes como o que é pretendido, será algo inovador e único no seu todo, para além de que pretende efectuar o tratamento de pautas manuscritas na notação musical standard. Pela natureza do sistema a desenvolver será possível também uma maior divulgação do mesmo e das obras que irá conter.


30

Os editores existentes, apesar de suportarem bastantes funções são utilizados em modo offline, e conter um editor embutido num sistema online como o prosposto é algo que facilitaria a tarefa bastante ao utilizador.

O formato MusicXML aparenta ser a escolha adequada para armazenar as pautas, não só por ser recente, estar a ganhar terreno, mas também porque se adequa ao music retrieval devido à sua natureza de organização da informação das pautas em formato XML.

Como se pode verificar, o trabalho a realizar justifica-se em todos os aspectos pois é uma área ainda com bastantes lacunas, importante para a preservação da nossa cultura musical e interessante do ponto de vista de toda a investigação e trabalho a desenvolver. É uma área com interesse a nível internacional e que conta já com bastantes anos de investigação.

3.2 Tecnologias Consideradas

Nesta secção é feito um levantamento das várias alternativas que foram apreciadas em relação às tecnologias a usar no desenvolvimento do sistema tendo em vista as suas necessidades, as facilidades que essas tecnologias possibilitam para uma implementação mais eficaz e evitar a “reinvenção da roda” usando componentes já existentes onde for possível. Tudo isso com vista a escolher as mais adequadas às necessidades que o sistema impõe.

Serão analisadas as vantagens e desvantagens de cada uma das alternativas referidas nas subsecções que se seguem. Desta forma na secção 4.5 opta-se de forma justificada pelas tecnologias e ferramentas mais apropriadas.

Um ponto importante a considerar na análise das tecnologias é o grupo a que pertencem, se são comerciais, livres ou opensource. Será dada preferência à utilização de tecnologias opensource, excepto se for mais indicado utilizar outra.

3.2.1 Base de Dados

Uma necessidade obrigatória para a base de dados é o suporte XML para possibilitar o armazenamento e pesquisa das pautas em MusicXML. A tecnologia de bases de dados a utilizar no projecto deverá portanto, não só permitir que os ficheiros das pautas em MusicXML sejam correctamente e eficazmente armazenados, mas também que seja possível efectuar pesquisas a nível da metadata contida neles (possibilitando desta forma o music retrieval). É também necessário armazenar as pautas originais em formato de imagem, mantendo uma associação página a página com a informação em MusicXML.

Algo também a ter em consideração é a compatibilidade do SGBD (Sistema de Gestão de Bases de Dados) escolhido com a plataforma de desenvolvimento que irá ser usada. Deverá haver uma fácil utilização da base de dados através da tecnologia usada, sendo o SGBD suportado pela mesma.

3.2.1.1 PostgreSQL

Ligações

• Sítio do projecto: http://www.postgresql.org

• Futuro suporte de XML nativo: http://developer.postgresql.org/pgdocs/postgres/datatype-xml.html

Descrição


31

O PostgreSQL é um SGBD relacional livre, opensource e bastante maduro, contando já com 15 anos de desenvolvimento activo e uma arquitectura comprovada que lhe deu uma forte reputação de confiabilidade e integridade dos dados. Contém suporte para XML, embora sem ter nenhum tipo de dados nativo, como no caso do MS SQL Server 2005. Este SGBD é largamente usado hoje em dia e é um SGBD de referência no mundo do opensource. Existem diversas ferramentas disponíveis, não só para administração das bases de dados, mas também como funcionalidades adicionais. É um SGBD geralmente suportado por todas as plataformas e corre nos principais sistemas operativos incluindo Windows, Linux/Unix e OS X. Suporta o armazenamento de binary large objects, os quais incluem imagens, som e video. Contém interfaces de programação nativas para C/C++, Java, Ruby, ODBC, .Net, Perl, Python, Tcl, entre outros. É altamente scalable tanto na quantidade de informação que pode gerir como no número de utilizadores concorrentes que pode acomodar.

Os limites que este SGBD impõe são os seguintes:

• Tamanho máximo da base de dados – Ilimitado;

• Tamanho máximo de uma tabela – 32 TB;

• Tamanho máximo de uma linha – 1.6 TB;

• Tamanho máximo de um campo – 1 GB;

• Número de linhas por tabela – Ilimitado;

• Número máximo de colunas por tabela – 250 a 1600 dependendo dos tipos de dados;

• Máximo de índices por tabela – Ilimitado.

Os limites apresentados são adequados ao sistema que se está a desenvolver. O PostgreSQL está também largamente de acordo com os standards existentes. E é altamente personalizável podendo-se criar stored procedures em várias linguagens de programação as quais incluem C/C++, Java e Ruby.

O suporte de XML não é apenas uma capacidade, mas sim um conjunto de características suportadas por um SGBD. Essas capacidades incluem armazenamento, importação/exportação, validação, indexação, eficiência de modificação, pesquisa, transformação, e mapeamento de XML para SQL (Structured Query Language). O suporte do PostgreSQL não inclui todas essas funcionalidades. Mas em futuras versões o suporte irá sendo melhorado.

As funcionalidades de XML actualmente em falta são o suporte de XQuery, sintaxe SQL/XML (ISO/IEC 9075-14) e um tipo de dados optimizado para o armazenamento de XML, sendo actualmente armazenado no tipo text. As pesquisas são realizadas usando o XPath, que processa os documentos de texto XML e retorna os resultados baseados na query requerida.

Está previsto numa próxima versão deste SGBD o melhoramento do suporte XML com um tipo de dados nativo, o tipo xml, trazendo algumas vantagens tal como no MS SQL Server 2005. Isso pode ser observado através da segunda ligação acima, a qual é a secção do suporte XML no manual do PostgreSQL na versão online de desenvolvimento.

Por tudo o que foi dito, o PostgreSQL parece ser uma boa alternativa a usar como SGBD no sistema a desenvolver neste projecto servindo à partida todas as necessidades do sistema, e ao mesmo tempo com melhorias para futuro das quais o sistema poderá beneficiar.


32

3.2.1.2 MySQL

Ligações

• Sítio do projecto: http://www.mysql.com

• Suporte XML: http://dev.mysql.com/tech-resources/articles/mysql-5.1-xml.html

Descrição

O MySQL é um SGBD relacional livre e opensource bastante maduro e muito popular. Devido a esse grau de maturidade existe um elevado suporte no geral. A popularidade do MySQL deve-se ao seu bom desempenho, confiabilidade e facilidade de utilização. Este SGBD, tal como o PostgreSQL corre em Windows, Linux/Unix e OS X.

Este SGBD aparenta ser uma boa escolha para se trabalhar com a plataforma Ruby On Rails considerada como potencial candidata na subsecção 3.2.3.1, pois já existe um bom suporte e ferramentas para essa plataforma que dão preferência ao MySQL. É o SGBD mais fácil de se configurar para usar nessa plataforma de desenvolvimento web. Para além de ser fácil de usar, tem bom desempenho e boa confiabilidade.

No entanto em termos de suporte de XML não é ainda a melhor solução uma vez que as funcionalidades de manipulação de XML apenas estão previstas para uma próxima versão que se encontra em desenvolvimento como se pode ver na ligação disponibilizada acima acerca do suporte XML.

Este SGBD é bastante flexível e scalable, tendo a capacidade para manipular quantidades de dados volumosas da ordem dos terabytes e permite uma personalização completa. Contém também vários mecanismos que lhe permitem um desempenho elevado e a integridade dos dados é também garantida. Dispõe também de uma protecção dos dados elevada através das características de segurança de que dispõe.

3.2.1.3 Microsoft SQL Server 2005 Express

Ligações

• Sítio do produto: http://www.microsoft.com/sql

• Informação acerca do suporte de XML: http://www.developer.com/db/article.php/3531196

• Artigo sobre XML no SQL Server 2005: http://www.itwriting.com/sqlxml.php

Descrição

O SQL Server 2005 Express da Microsoft é um SGBD relacional que contém suporte nativo para armazenamento e tratamento de informação em XML. Nos tipos de dados suportados podemos verificar a existência do tipo xml, possibilitando um armazenamento directo de informação neste formato com várias facilidades associadas. Contém suporte para XQuery.

Este SGBD é de fácil instalação e tem boa integração com a plataforma .Net e o Visual Studio 2005. Com todas as ferramentas disponibilizadas é de fácil uso e gestão. Contém suporte para uso da autenticação do Windows. É um SGBD bastante flexível, uma vez que suporta tanto o formato relacional como o de XML.

A versão Express é a versão livre do SQL Server 2005, sendo esta versão a que se está a considerar. No entanto, tem as seguintes limitações de desempenho relativamente à sua versão comercial:


33

• 1 CPU – O SQL Server 2005 Express pode ser instalado e executado em sistema multi-processador, no

entanto, apenas usa um processador de cada vez não tirando partido dos recursos na totalidade. Esta

limitação não permite a execução paralela de queries;

• 1 GB de RAM – O buffer pool está limitado a 1 GB de RAM. O buffer pool é usado para armazenar

páginas de informação entre outros. Esta limitação não permite o uso do AWE (Address Windowing

Extensions);

• 4 GB de tamanho da BD (Base de Dados) – Esta é a limitação mais importante no caso do sistema a

desenvolver, uma vez que o conteúdo armazenado poderá mais tarde ultrapassar os 4 GB. Irão ser

armazenadas muitas imagens em conjunto com as pautas em MusicXML, e consoante a dimensão da

informação for crescendo os 4 GB de limite podem ser uma ameaça e trazer problemas exigindo a

migração da BD. No entanto não há limites em relação ao número de bases de dados que podem ser

agregadas ao servidor.

Também existem limitações a nível das características empresariais. As que constam da seguinte lista não estão presentes nesta versão livre do SQL Server 2005:

• Serviços de análises (ambos OLAP (On Line Analytical Processing) e Data Mining);

• Serviços de integração (sucessor do DTS (Database Transformation Services));

• Serviços de notificação;

• Constructor de relatórios (embora os serviços de anúncio estejam incluídos);

• Agente SQL;

• Consultor de afinação da base de dados;

• Pesquisa completa por texto;

• Log shipping;

• Database mirroring;

• Fail-over clustering.

Este SGBD corre somente em sistemas operativos Windows.

3.2.2 Aplicação de OMR

A aplicação de OMR assentará inicialmente numa das soluções existentes já analisadas na secção 3.1.1. Mais tarde, numa outra fase do projecto, poderá continuar-se o desenvolvimento da solução usada para suportar pautas manuscritas, ou começar-se um OMR com base nessa solução. Nesta fase o ideal é que se use uma solução funcional e que consiga obter resultados razoáveis pelo menos com pautas impressas.

No entanto, de futuro, se se optar por implementar um OMR de raíz poderá ser usada a linguagem C++ ou Java, uma vez que em princípio são adequadas à aplicação, visto serem orientadas a objectos e bastante populares e maduras. Por esses motivos existem muitos pacotes/toolkits de tratamento de imagem, entre outros, implementados para usar com essas linguagens, os quais são necessários para este tipo de aplicação.


34

3.2.3 Aplicação Web e Editor de Pautas Embutido

Para desenvolver a aplicação web com o editor de pautas embutido consideraram-se algumas opções, embora todas elas integrando a tecnologia AJAX, devido às vantagens que esta oferece. Em cada subsecção que se segue são apresentadas as várias alternativas.

3.2.3.1 Ruby on Rails

Ligações

• Sítio do projecto: http://www.rubyonrails.org

• InstantRails, solução completa com web server e BD: http://instantrails.rubyforge.org/wiki/wiki.pl

• Sítio do IDE RadRails: http://www.radrails.net/download_radrails.php

• Plugins: http://wiki.rubyonrails.org/rails/pages/Plugins

Descrição

O Ruby On Rails é uma full-stack framework muito recente que foi lançada em 2004, para desenvolver aplicações web com base de dados segundo o padrão Model-View-Control, tendo como objectivos aumentar a velocidade e a facilidade do desenvolvimento web. É um projecto opensource escrito na linguagem Ruby que suporta todos os sistemas operativos. Desde o Ajax na vista, ao pedido e resposta no controlador, ao modelo de domínio a envolver a base de dados, dá-nos um ambiente de desenvolvimento puro em Ruby. Apenas necessita de uma base de dados e um web server para além da framework.

Os princípios fundamentais do Ruby On Rails são “Don’t repeat yourself” (DRY) e “Convention over configuration”.

“Don’t repeat yourself” significa que a informação é localizada num único local. Por exemplo, graças ao ActiveRecord, as definições das classes não têm de especificar os nomes das colunas, o Ruby pode consultar essa informação na base de dados. Portanto, defini-la em código seria redundante.

“Convention over configuration” significa que uma pessoa apenas precisa de especificar aspectos pouco convencionais da sua aplicação. Por exemplo, se houver uma classe Sale no modelo, a tabela correspondente na base de dados será denominada sales por omissão. Apenas se uma pessoa se afastar desta convenção, tal como chamar a tabela de sold_products, é que terá de escrever código em relação a esses nomes.

Esta framework encontra-se de momento na versão 1.2 e contém suporte para plugins, os quais permitem estender ou modificar o núcleo da plataforma. Existem inúmeros plugins disponíveis através do sítio oficial da plataforma.

O Ruby On Rails segue o padrão Model-View-Control da seguinte forma:

• Model (acesso à base de dados) – Através do ActiveRecord faz a ligação objecto-tabela para acesso à

base de dados. O ActiveRecord cria e gere as ligações entre objectos e tabelas, desde que estas obedeçam

às normas convencionadas pela plataforma;

• View (interface) – Visualização da aplicação com suporte Ajax permitindo a actualização de secções das

páginas sem as voltar a carregar explicitamente;

• Controller (lógica de negócio) – É a interligação entre a interface e o acesso à base de dados onde deve

ficar toda a lógica de negócio.


35

Como as aplicações web em geral podem ser desenvolvidas segundo este modelo, esta plataforma introduz o conceito de scafolding, significando que é possível especificar apenas algumas configurações mínimas e a plataforma cria a estrutura básica necessária ao funcionamento da aplicação.

No entanto, se a aplicação web a desenvolver não obedecer às convenções da plataforma, é necessário um esforço extra para especificar as diferenças tanto a nível de configuração como a nível de código.

Existe uma ferramenta opensource, o InstantRails, a qual se trata de uma solução completa desta plataforma contendo já um SGBD e um web server já totalmente configurado e pronto a usar. Desta forma torna-se muito simples colocar a plataforma em execução e pronta para o desenvolvimento. Contudo, esta última ferramenta é somente para Windows.

Há também a possibilidade de usar o IDE (Integrated Development Environment) RadRails, também opensource, para desenvolver a aplicação, visto já estar preparado para a plataforma e ser fácil integrá-lo na mesma. Este IDE é cross-platform e é desenvolvida com o Eclipse.

Com tudo isto esta plataforma aparenta ser um excelente meio para a criação da aplicação web do sistema a desenvolver.

3.2.3.2 Tapestry com Tacos

Ligações

• Sítio do Tapestry: http://tapestry.apache.org

• Sítio do Tacos: http://tacos.sourceforge.net

• Tapestry support network: http://tapestrysupport.com

Descrição

O Tapestry é uma framework opensource para a criação de aplicações web em Java, sendo dinâmicas, robustas e altamente scalable. Complementa e é construída na standard Java Servlet API (Application Programming Interface), e portanto funciona em qualquer servlet container ou servidor de aplicações. O Tapestry divide uma aplicação web num conjunto de páginas, cada uma construída a partir de componentes. Desta forma consegue-se uma estrutura consistente, permitindo à framework assumir a responsabilidade por assuntos chave como a construção de URLs (Uniform Resource Locator) e despacho, armazenamento de estado persistente no cliente ou no servidor, validação do input do utilizador, localização/internacionalização, e informação de excepções. Desenvolver aplicações nesta plataforma envolve a criação de templates HTML (HyperText Markup Language) usando HTML pleno e a combinação de templates através de pequenas porções de código em Java usando opcionalmente ficheiros descritores em XML.

Com o Tapestry criam-se aplicações em termos de objectos, e os métodos e propriedades desses objectos. Com esta plataforma pode-se criar novos componentes facilmente e a própria traz já por volta de 50, desde componentes simples de output até complexas data grids e tree navigators. Encontra-se organizado em torno de simplicidade, consistência, eficiência e feedback.

Actualmente encontra-se bastante maduro, estando na versão 4.1.1. Permite a integração com IDEs como o Eclipse e o NetBeans e contém uma série de possíveis extensões. Encontra-se de acordo com o padrão de desenho Model-View-Controller já explicado na subsecção anterior.


36

Em conjunto com o Tapestry pode-se usar a biblioteca Tacos, a qual disponibiliza componentes de alta qualidade e comportamento Ajax para o Tapestry. Disponibiliza uma infra-estrutura de núcleo para usar lógica relacionada com Ajax nos próprios componentes e nos próprios do utilizador e nas páginas. É um projecto opensource actualmente na versão 4.0.1.

No seu todo, e devido à boa aceitação da plataforma, esta também parece uma boa alternativa.

3.2.3.3 Google Web Toolkit

Ligações

• Sítio do projecto: http://code.google.com/webtoolkit

Descrição

O Google Web Toolkit é uma framework opensource de desenvolvimento de software em Java que torna a escrita de aplicações em Ajax mais fácil. Esta plataforma ajuda a evitar problemas na a construção de aplicações web dinâmicas enquanto oferece aos utilizadores a mesma experiência dinâmica e de acordo com os standards. A escrita é feita em Java e o compilador da plataforma converte as classes em Java para HTML e JavaScript. A versão actual é a 1.3, permanecendo ainda em fase beta.

As características desta plataforma são as seguintes:

• Componentes de interface dinâmicos e reutilizáveis;

• RPC (Remote Procedure Call) simples;

• Gestão do histórico do browser;

• Debugging real;

• Compatibilidade com os browsers;

• Integração com Junit;

• Internacionalização;

• Interoperabilidade e controlo refinado;

• OpenSource.

Com base nas suas características, esta plataforma, tal como as anteriores, também parece ser uma boa solução. Contudo permanece em versão beta e aparenta ser menos completa, nomeadamente em relação ao Ruby On Rails.

3.2.3.4 ASP.Net AJAX

Ligações

• Sítio do produto: http://ajax.asp.net

Descrição

O ASP .Net Ajax é uma framework livre da Microsoft que permite a rápida criação de uma nova geração de experiências web mais eficientes, interactivas e personalizadas, que funcionam em todos os browsers mais populares. Esta plataforma combina o poder do ASP .Net no servidor com o benefício de uma execução Ajax do lado do cliente. Integra bibliotecas de script compatíveis com todos os browsers com a framework de aplicações web ASP .Net


37

2.0. Desta forma pode-se criar rapidamente páginas com interfaces sofisticadas e receptivas, e com comunicação cliente-servidor mais eficiente através de simplesmente adicionarem-se alguns controlos de servidor às páginas. Na realidade é um conjunto de extensões para a plataforma ASP. Net. Encontra-se de momento na versão 1.0.

Com esta plataforma pode-se:

• Criar interfaces de nova geração com componentes Ajax reutilizáveis;

• Melhorar as páginas web existentes usando controlos Ajax poderosos com suporte dos browsers actuais;

• Continuar a usar o Visual Studio 2005 para levar as aplicações ASP .Net 2.0 a um novo nível;

• Aceder a serviços remotos e informação directamente do browser sem scripts complicados;

• Utilizar os benefícios de uma framework livre com suporte técnico da Microsoft.

Esta plataforma seria boa opção no caso de se desenvolver a aplicação web na plataforma .Net.

3.2.3.5 Editor de MusicXML

O editor de MusicXML será numa primeira fase um editor simples de texto embutido na aplicação, simplesmente mostrando o texto e permitindo editá-lo. No entanto, mais tarde, numa outra fase pretende-se integrar ou desenvolver um editor que permita visualizar e editar as pautas directamente dessa forma em vez de ser textual. Nesta fase o ideal é que se use uma solução funcional que permita pelo menos visualizar e editar os conteúdos em MusicXML.

Uma possível tecnologia a usar para o desenvolvimento deste módulo numa fase mais avançada deste projecto seria Flash, uma vez que é uma tecnologia bastante poderosa para desenvolver aplicações multimédia e interactivas para uso em aplicações web. Foi inclusive analisado um exemplo comercial semelhante, na secção 3.1.1.2.

3.2.4 Servidor

A tecnologia usada em relação ao servidor depende da plataforma de desenvolvimento web que se escolher. No entanto apresentam-se aqui as alternativas consideradas para as plataformas que se tomou como alternativas na secção 3.2.3. Estas tecnologias têm como objectivo a disponibilização das aplicações web para o público em geral, e deverão ser escolhidas com base nas necessidades existentes.

3.2.4.1 Apache com Mongrel

Ligações

• Sítio do Apache: http://httpd.apache.org

• Sítio do Mongrel: http://mongrel.rubyforge.org

Descrição

O Apache HTTP Server Project é uma tentativa de desenvolver e manter um servidor HTTP (Hypertext Transfer Protocol) opensource para sistemas operativos modernos. É muito popular e vastamente usado de hoje em dia, tendo como objectivos disponibilizar um servidor seguro, eficiente e extensível disponibilizando serviços de HTTP em concordância com os actuais standards do HTTP.


38

O Mongrel é um servidor e uma biblioteca de HTTP rápida para Ruby que é intencionado para hospedar aplicações web em Ruby de qualquer tipo usando HTTP pleno ao contrário do FastCGI e SCGI. Já suporta Ruby On Rails. Corre por cima do Apache.

3.2.4.2 lighttpd com Mongrel

Ligações

• Sítio do lighttpd: http://www.lighttpd.net

• Informação: http://wiki.rubyonrails.org/rails/pages/Lighttpd

• Sítio do Mongrel: http://mongrel.rubyforge.org

Descrição

O lighttpd é um web server opensource ao qual estão associados segurança, velocidade, conformidade e flexibilidade. Está desenhado para optimizar ambientes de alto desempenho. Usa pouca memória e faz uma gestão efectiva do processador. Pode ser usado com Mongrel para hospedar aplicações web em Ruby.

3.2.4.3 Tomcat

Ligações

• Sítio do projecto: http://tomcat.apache.org

Descrição

O Apache Tomcat é o servlet container opensource que é usado na implementação de referência oficial para as tecnologias Java Servlet e JavaServer Pages.

3.2.4.4 Jetty

Ligações

• Sítio do projecto: http://www.mortbay.org

Descrição

O Jetty é um web server opensource implementado totalmente em Java, baseado em standards e completo.

3.3 Outras Ferramentas Usadas

Para além das ferramentas a usar no desenvolvimento do sistema são necessárias outras para a escrita da documentação. Na escrita dos relatórios e documentos foram usados o Microsoft Office 2003, e o Poseidon for UML 4.2.0 para criar os diagramas em UML (Unified Modeling Language). Para tratamento de imagem tanto na documentação como para utilização no sistema desenvolvido foram usados o Microsoft Paint, The GIMP e Microsoft Office Picture Manager. Todo o trabalho foi desenvolvido em ambiente Microsoft Windows por questões de facilidade de uso uma vez que não havia restrições impostas.


39

4 Especificação

Este capítulo tem como objectivo apresentar a especificação da solução proposta. É efectuada uma análise, primeiramente em geral e depois em detalhe, sobre os requisitos do sistema total com todas as características que o mesmo deverá ter na conclusão do projecto. Os requisitos encontram-se agrupados em subsecções, de acordo com as suas especificidades. Na subsecção dos requisitos funcionais são apresentados os casos de uso do sistema.

Como será dada mais importância ao sistema global durante o estágio, será o todo que estará mais em foco, inclusive porque o módulo de OMR assentará sobre uma solução existente, que posteriormente será trabalhada com vista a melhorá-la e adaptá-la ao reconhecimento de pautas manuscritas. No entanto isso também será analisado com vista a uma total especificação do sistema.

Para cada requisito em particular será atribuída uma prioridade em relação à sua importância no desenvolvimento do sistema. Essa prioridade será alta, média ou baixa consoante seja mais ou menos importante e necessário satisfazer esse requisito no desenvolvimento do sistema na sua totalidade. Um requisito com prioridade alta significa que no final do projecto terá de se encontrar completo e funcional. Se um requisito tiver prioridade média terá de existir, mas poderá ainda não estar totalmente completo, e se a prioridade for baixa significa que só será implementado se houver tempo, sendo algo adicional que não é fundamental no sistema para esta fase, mas que lhe acrescenta valor. Contudo, é necessário salientar que alguns requisitos considerados com prioridade alta, devido à sua complexidade o seu desenvolvimento será gradual durante todo o desenvolvimento do projecto, continuando mesmo após o estágio.

4.1 Visão Geral

Uma aplicação de OMR permite reconhecer pautas musicais a partir das suas páginas digitalizadas, por exemplo com um scanner. As pautas são então convertidas para um formato manipulável e usável através de um computador. Podem ser impressas ou manuscritas, embora no geral as ferramentas actuais sejam mais adequadas a pautas impressas, havendo ainda um longo percurso a percorrer para se obter um reconhecimento fiável e completo. As pautas manuscritas levantam uma série de problemas adicionais devido às variações na escrita de pessoa para pessoa, e até mesmo na mesma pauta podem haver variações na escrita, sendo por isso bastante irregular, dificultando muito o processo de reconhecimento, sendo necessário desenvolver técnicas mais avançadas que as existentes actualmente.

Um sistema como o que se pretende desenvolver inclui mais do que apenas a aplicação de reconhecimento de pautas musicais. É um sistema disponível online onde se pode juntar todo um corpus de obras musicais com vista à sua preservação, divulgação e estudo. É um sistema de livre utilização onde se pode dar um contributo para esse corpus introduzindo novas obras.

Neste sistema o reconhecimento óptico das partituras é realizado de forma integrada através de uma aplicação web por via online, em oposição à generalidade de aplicações de OMR que são usadas em modo offline.

O que se pretende é portanto um sistema que consiste numa base de dados onde serão armazenadas todas as pautas musicais manuscritas, tanto no formato original (imagens das folhas digitalizadas) como num formato digital de estilo hierárquico utilizável por


40

computador, o MusicXML, após reconhecimento da pauta pelo módulo de OMR. E também numa aplicação Web disponível online para acesso geral, a qual permitirá a navegação e visualização das pautas disponíveis. Aos utilizadores registados permitirá adicionar novas pautas ao sistema, sendo reconhecidas e convertidas para o formato digital na altura em que são adicionadas. Para serem de facto incorporadas no corpus, estas pautas têm de ser validadas pelo Administrador, ou um Utilizador Privilegiado. Deverá ser possível fazer toda a gestão das pautas, seus autores, instrumentos usados, géneros musicais, actualizações/notícias e dos utilizadores do sistema. A aplicação web deve incluir ainda um módulo de visualização e edição das pautas em MusicXML, integrado no sistema para uso online. Assim como deve possuir também um motor de pesquisa avançado, o qual permita não só pesquisar por entre os objectos do sistema com base em uma ou mais palavras, mas também realizar pesquisas pelo conteúdo das pautas armazenadas em MusicXML.

O sistema será separado em vários módulos, permitindo um estudo mais detalhado e rigoroso. Deles fazem parte, num primeiro nível, a Aplicação Web, o Armazenamento (base de dados), a Aplicação de OMR e o Editor de Pautas.

4.2 Características dos Utilizadores

Para este sistema foram identificados quatro actores como se descreve de seguida, com base no que foi já descrito na secção 2.2.1:

• Utilizador Geral – Utilizador geral do sistema, o qual não se encontra registado no mesmo;

• Utilizador Registado – Utilizador registado no sistema através de registo pessoal no sítio web ou tendo

sido criado por um utilizador de nível superior, tendo portanto a possibilidade de inserir obras no

sistema, assim como autores e instrumentos;

• Utilizador Privilegiado – Utilizador registado no sistema através do Administrador. Possui as mesmas

funcionalidades de um Utilizador Registado, mas também funcionalidades de Administrador, podendo

por exemplo gerir Utilizadores Registados;

• Administrador – Administrador do sistema, utilizador com acesso total. É o único utilizador que pode

criar Utilizadores Privilegiados, sendo essa a única forma de o fazer.

Pode ser vista de seguida a hierarquia entre eles no seguinte diagrama:


41

Figura 3 - Hierarquia de Utilizadores

4.3 Requisitos Funcionais

Os requisitos funcionais representam todas as funcionalidades que o sistema deverá ter.

O desenvolvimento deste sistema divide-se em várias partes e inclui a integração de todas elas, podendo ser usados módulos já existentes, na sua totalidade, parcialmente ou mesmo como base para o desenvolvimento de cada um, sendo a ideia geral a de aproveitar o que já foi desenvolvido em vez de reinventar “a roda”. No entanto, em geral essas várias partes estão muito relacionadas ou mesmo dependentes umas das outras. Por exemplo, para adicionar uma pauta em imagem, e portanto sendo necessário o reconhecimento da mesma, é fundamental utilizar o módulo de OMR, e logo de seguida o módulo de edição e visualização da pauta em MusicXML.

Tentou-se fazer uma divisão bem estruturada dos vários módulos com vista a uma leitura fácil de todas as funcionalidades do sistema e para permitir uma maior facilidade na implementação e integração das várias partes. Essa estruturação pode ser observada no diagrama de casos de uso do sistema completo, na Figura 4, no qual as funcionalidades estão estruturadas por pacotes devido à quantidade de casos de uso existentes. Esses pacotes representam os módulos do sistema, fazendo todos eles parte da Aplicação Web. Estão representados também dois actores de sistema, o do módulo da Aplicação de OMR e o do Editor de Pautas. Encontram-se representados dessa forma simplificada uma vez que podem ser vistos como “externos” ao sistema. Existe ainda o módulo do Armazenamento que consiste na base de dados e não aparece neste diagrama.


42

Figura 4 - Casos de Uso do Sistema Geral separado por pacotes

O sistema deverá possuir as seguintes funcionalidades, presentes na Tabela 7. No entanto, uma vez que o sistema global é constituído por vários módulos, para melhor se poder estudar os requisitos de cada um e de uma forma mais detalhada, estes irão ser abordados de seguida em várias subsecções. Estes requisitos aqui apresentados serão portanto detalhados nas subsecções que se seguem. Para maior detalhe os diagramas de casos de uso de cada pacote/módulo e actor de sistema pode ser consultado no anexo da página 94.


43

Requisito Prioridade Reconhecer pautas musicais manuscritas Alta4 Exportar as pautas reconhecidas para MusicXML Alta Permitir armazenar pautas musicais manuscritas convertidas para MusicXML, com a pauta original digitalizada, mantendo a relação das páginas no formato original e no formato digital

Alta

Efectuar a gestão das pautas musicais Alta Efectuar a gestão dos autores Alta Efectuar a gestão dos instrumentos Alta Efectuar a gestão dos géneros musicais Alta Efectuar a gestão das actualizações/notícias Média Efectuar a gestão dos utilizadores Alta Permitir que uma pessoa se registe no sistema Média Permitir que uma pessoa se autentique no sistema, e vice-versa Alta Permitir a um utilizador efectuar a gestão da própria conta de utilizador Média Efectuar pesquisas a nível das pautas, autores e todo o sistema Alta Validação, por parte do Administrador ou Utilizadores Privilegiados, dos novos Utilizadores Registados para que se tornem activos no sistema. Se não forem considerados válidos, deve permitir a remoção dos mesmos

Média

Validação, por parte do Administrador ou Utilizadores Privilegiados, das novas pautas adicionadas para que se tornem disponíveis no sistema. Se não forem consideradas válidas, deve permitir a remoção das mesmas

Média

Validação, por parte do Administrador ou Utilizadores Privilegiados, dos novos autores adicionados para que se tornem disponíveis no sistema. Se não forem considerados válidos, deve permitir a remoção dos mesmos

Média

Validação, por parte do Administrador ou Utilizadores Privilegiados, dos novos instrumentos adicionados para que se tornem disponíveis no sistema. Se não forem considerados válidos, deve permitir a remoção dos mesmos

Média

Tabela 7 - Requisitos do Sistema

4.3.1 Aplicação Web

A aplicação web é o ponto de acesso a todo o sistema, é o que permite ao utilizador realizar todas as tarefas possíveis e permitidas, e aceder a todos os componentes do sistema. Pode-se afirmar que é a interface entre o utilizador e todo o sistema.

Esta parte do sistema deve disponibilizar uma interface na qual se possa seleccionar outro idioma para além do idioma por omissão. Pretende-se que a Aplicação Web seja desenvolvida implementando essa funcionalidade a um nível simples e genérico, ou seja, que seja criada com este conceito em mente embora inicialmente seja importante apenas o idioma Português. Contudo, deixando já pronta para utilizar um segundo idioma, o Inglês, em que apenas seja necessário introduzir o texto de tradução de cada string da interface.

A Aplicação Web tem basicamente duas formas de acesso: o acesso autenticado e o acesso anónimo apenas como visitante. Contudo, um visitante pode ter a intenção de se registar no sistema para usufruir de mais funcionalidades e privilégios, podendo portanto efectuar o seu registo. Após o seu registo ser validado passa a poder usufruir do sistema dessa forma, como um Utilizador Registado.

O sistema deverá ser gerido totalmente através da aplicação web. Deverá portanto permitir realizar a gestão dos utilizadores e de todos os objectos, assim como efectuar pesquisas.

4 Apesar de este requisito ter uma prioridade alta, devido à sua complexidade será uma solução em

desenvolvimento gradual. Sendo inicialmente consideradas pautas impressas e manuscritas muito regulares.


44

Para visitantes – o Utilizador Geral – o sistema deverá permitir somente a listagem e navegação pelos conteúdos do sítio web (excepto utilizadores), incluindo pelas próprias pautas e sua visualização ou descarregá-las para o disco ou outro local. Podem também efectuar qualquer tipo de pesquisa disponibilizada. Contudo, como foi já referido, têm a possibilidade de se registar no sistema, passando a ser um Utilizador Registado, se for aceite.

No caso de se tratarem de Utilizadores Registados há três tipos de acesso diferente, consoante o utilizador de que se trata.

Se for um simples Utilizador Registado, para além das funcionalidades de um Utilizador Geral este já possui mais algumas funcionalidades. Pode fazer a gestão de pautas e gestão da própria conta de utilizador. Pode inserir pautas musicais, e também actualizar e remover pautas existentes, mas apenas as que lhe pertencerem. Para poder utilizar os seus privilégios o utilizador terá primeiro de se autenticar no sistema, podendo realizar o respectivo logout após realizar todas as tarefas pretendidas. O utilizador pode também adicionar novos autores e instrumentos musicais, se houver necessidade de tal. No entanto, qualquer objecto que adicione fica à espera de validação.

A inserção de novas pautas pode ser feita de três formas, sendo a principal a inserção de uma pauta em imagem, obtida através da digitalização por scanner, sendo reconhecida através do módulo de OMR. Depois do reconhecimento é dada a possibilidade de se visualizar o resultado obtido, lado a lado com a pauta original, podendo o utilizador corrigir eventuais erros de reconhecimento ou adicionar partes que não foram reconhecidas, através do editor de pautas embutido no sistema. Após isso pode então submeter o resultado passando então a existir uma nova pauta no sistema. Contudo, fica em fila de espera para ser validada pelo Administrador ou um Utilizador Privilegiado.

Uma outra forma é no caso de o utilizador pretender submeter a pauta já no formato MusicXML. Tal como no primeiro caso fica em fila de espera para validação. Esta forma tem duas vertentes, pois pode-se inserir a nova pauta com ou sem fonte original. Pode ser útil no caso de se ter uma pauta convertida mas por algum motivo a fonte original ter-se perdido. Desta forma o sistema torna-se mais flexível permitindo as várias situações possíveis.

A actualização de pautas existentes pode ser efectuada através de duas formas distintas. O utilizador pode actualizar a obra musical em termos dos objectos que fazem parte dela (secções e páginas) ou editar a informação da obra, suas secções e editar as respectivas páginas em MusicXML. Na primeira dessas duas opções, o utilizador segue um processo semelhante ao da submissão de novas pautas, mas com a diferença de que não tem de inserir os dados da obra e esta já contém secções e páginas, as quais o utilizador pode remover e/ou alterar a ordem. No segundo método é aberta a visualização da partitura, em modo de edição, com as opções de edição já enumeradas. Com este segundo método permite-se, por exemplo, que um utilizador adicione uma obra musical e se após o reconhecimento não tiver tempo para efectuar as correcções necessárias, pode-as fazer mais tarde.

A remoção de uma pauta existente consiste na sua simples remoção, com confirmação. Contudo, tal como na actualização, só o pode fazer a pautas que lhe pertençam.

O Utilizador Registado pode também actualizar os seus dados pessoais ou cancelar a sua conta de utilizador se pretender abandonar o sistema definitivamente. No segundo caso as suas pautas e os restantes objectos criados passam a pertencer ao Administrador.


45

O segundo caso dos utilizadores registados é o Utilizador Privilegiado, que para além das funcionalidades já mencionadas pode ainda realizar a gestão de utilizadores, mas somente de Utilizadores Registados, ou seja, do nível abaixo do seu. Os Utilizadores Privilegiados são criados pelo Administrador apenas. E pode também validar utilizadores que se tenham registado, assim como pautas, autores e instrumentos em fila de espera para aceitação após submissão. No entanto, uma vez que tem privilégios de administrador, em relação à inserção de pautas existe uma diferença, a qual passa pela inexistência de validação das mesmas, ficando imediatamente disponíveis no sistema. O mesmo se passa em relação à inserção de autores, instrumentos e utilizadores, podendo fazer a gestão total destes. Pode ainda fazer também a gestão de géneros musicais, a qual não pode ser feita por utilizadores de nível inferior por forma a se poder limitar o âmbito de obras musicais do corpus. E por último pode criar e fazer a gestão de actualizações/notícias para informar sobre eventos, entre outros, que podem ser consultadas por todos utilizadores.

Por último, se se tratar do Administrador do sistema, para além de todas as funcionalidades acima e particularidades do Utilizador Privilegiado, tem as diferenças que se seguem. A gestão de utilizadores inclui também Utilizadores Privilegiados, e este utilizador não pode cancelar a sua conta por forma a evitar que o sistema fique sem Administrador por erro.

Por forma a melhor estruturar o estudo e especificação desta parte fundamental do sistema, os seus requisitos encontram-se detalhados em várias subsecções, uma para cada módulo da Aplicação Web.

Para cada tabela de requisitos nas subsecções seguintes, a coluna “Acesso” indica que utilizadores têm acesso à funcionalidade utilizando a hierarquia definida na secção 4.2, em que um utilizador que descenda de outro também tem acesso salvo indicação do oposto. Por exemplo, uma funcionalidade com acesso “Geral” pode ser acedida pelos outros que derivam do Utilizador Geral. Por questões de espaço, a palavra “Utilizador” é omitida nessa coluna.

4.3.1.1 Gestão da Conta de Utilizador

Este módulo disponibiliza todas as funcionalidades usuais para um utilizador registado no sistema poder gerir os seus dados e a sua conta de utilizador. A este módulo estão também associadas as funcionalidades de registo, pedido de nova senha e autenticação.

Os casos de uso da Gestão da Conta de Utilizador podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na Tabela que se segue.

Requisito Acesso Prioridade

Permitir registar-se no sistema Geral, apenas Média

Autenticar-se no sistema

Registado, antes de estar autenticado, mas todos conseguem aceder, embora só se

autentiquem se forem utilizadores registados

Alta

Fazer logout para abandonar o sistema quando está autenticado Registado, estando autenticado Alta Pedir nova senha no caso de se ter esquecido da actual Registado, antes de estar autenticado Média Visualizar os dados pessoais Registado Média Actualizar os dados pessoais Registado Média Cancelar a conta de utilizador Registado, excepto Administrador Média Listar autores próprios Registado Média Listar instrumentos próprios Registado Média Listar pautas próprias Registado Média

Tabela 8 - Requisitos da Gestão da Conta de Utilizador


46

4.3.1.2 Gestão de Utilizadores

Este módulo disponibiliza as funcionalidades usuais de gestão de utilizadores de um sistema, podendo listá-los, visualizá-los, editá-los e eliminá-los, assim como criar novos utilizadores. Os Utilizadores Privilegiados gerem os Utilizadores Registados e o Administrador gere também os Utilizadores Privilegiados para além dos Registados. No entanto, por uma questão de espaço a Tabela 9 representa os requisitos sem diferenciar este último detalhe.

Os casos de uso da Gestão de Utilizadores podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na tabela que se segue.


Listar os utilizadores existentes Privilegiado Alta Visualizar os dados de um utilizador Privilegiado Alta Inserir um novo utilizador no sistema Privilegiado Alta Alterar os dados de um utilizador existente Privilegiado Média Eliminar um utilizador existente Privilegiado Média Consultar os autores de um utilizador existente Privilegiado Média Consultar os instrumentos de um utilizador existente Privilegiado Média Consultar as pautas de um utilizador existente Privilegiado Média

Tabela 9 - Requisitos da Gestão de Utilizadores

4.3.1.3 Gestão de Pautas

Este módulo disponibiliza as funcionalidades usuais de gestão de objectos num sistema, podendo listar as pautas, visualizá-las, editá-las e eliminá-las, assim como submeter novas pautas. No entanto a forma como são visualizadas, submetidas e editadas têm diferenças únicas relativamente a este tipo de requisitos. A sua visualização e um dos modos de edição estão interligados com o módulo Editor de MusicXML, enquanto que a submissão e segundo modo de edição passam por uma sequência de passos, que podem incluir a utilização do módulo de reconhecimento óptico e do editor no final. Estes requisitos são fundamentais no desenvolvimento do sistema.

Os Utilizadores Registados apenas podem actualizar ou remover pautas que tenham submetido, enquanto que os utilizadores dos níveis seguintes podem fazer o mesmo para qualquer pauta presente no sistema.

Os casos de uso da Gestão de Pautas podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na tabela que se segue.


Listar as pautas existentes no sistema Geral Alta Listar as pautas existentes no sistema, criadas pelo próprio Registado Alta Visualizar uma pauta tanto no formato original como em MusicXML Geral Alta Descarregar uma pauta tanto no formato original como em MusicXML, paginada e não paginada Geral Alta Inserir uma nova pauta, convertendo-a automaticamente nessa altura e permitindo visualizar o resultado obtido, corrigir as partes que seja necessário através de um editor simples

Registado Alta

Inserir uma nova pauta já convertida Registado Alta Actualizar uma pauta existente, tanto através da inserção/remoção de secções e páginas como através dos seus dados e edição das páginas existentes

Registado Média

Eliminar uma pauta existente Registado Alta

Tabela 10 - Requisitos da Gestão de Pautas


47

4.3.1.4 Gestão de Autores

Este módulo disponibiliza as funcionalidades usuais de gestão de objectos num sistema, podendo listar os autores, visualizá-los, editá-los e eliminá-los, assim como criar novos autores.

Os Utilizadores Registados apenas podem actualizar ou remover autores que tenham criado, enquanto que os utilizadores dos níveis seguintes podem fazer o mesmo para qualquer autor presente no sistema.

Os casos de uso da Gestão de Autores podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na tabela que se segue.


Listar os autores existentes no sistema Geral Alta Listar os autores existentes no sistema, criados pelo próprio Registado Alta Visualizar os dados de um autor Geral Alta Listar as pautas de um autor Geral Alta Inserir um novo autor Registado Alta Actualizar um autor existente Registado Média Eliminar um autor existente Registado Média

Tabela 11 - Requisitos da Gestão de Autores

4.3.1.5 Gestão de Instrumentos

Este módulo disponibiliza as funcionalidades usuais de gestão de objectos num sistema, podendo listar os instrumentos, visualizá-los, editá-los e eliminá-los, assim como criar novos instrumentos.

Os Utilizadores Registados apenas podem actualizar ou remover instrumentos que tenham criado, enquanto que os utilizadores dos níveis seguintes podem fazer o mesmo para qualquer instrumento presente no sistema.

Os casos de uso da Gestão de Instrumentos podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na tabela que se segue.


Listar os instrumentos existentes no sistema Geral Alta Listar os instrumentos existentes no sistema, criados pelo próprio Registado Alta Visualizar os dados de um instrumento Geral Alta Listar as pautas associadas a um instrumento Geral Alta Inserir um novo instrumento Registado Alta Actualizar um instrumento existente Registado Média Eliminar um instrumento existente Registado Média

Tabela 12 - Requisitos da Gestão de Instrumentos

4.3.1.6 Gestão de Géneros Musicais

Este módulo disponibiliza as funcionalidades usuais de gestão de objectos num sistema, podendo listar os géneros musicais, visualizá-los, editá-los e eliminá-los, assim como criar novos géneros musicais.

Os casos de uso da Gestão de Géneros Musicais podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na tabela que se segue.


48

Requisito Acesso Prioridade Listar os géneros musicais existentes no sistema Geral Alta Visualizar os dados de um género musical Geral Alta Listar as pautas associadas a um género musical Geral Alta Inserir um novo género musical Privilegiado Alta Actualizar um género musical existente Privilegiado Média Eliminar um género musical existente Privilegiado Média

Tabela 13 - Requisitos da Gestão de Géneros Musicais

4.3.1.7 Gestão de Actualizações

Este módulo disponibiliza as funcionalidades usuais de gestão de objectos num sistema, podendo listar as actualizações/notícias, visualizá-las, editá-las e eliminá-las, assim como criar novas actualizações/notícias.

Os casos de uso da Gestão de Actualizações podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na tabela que se segue.


Listar as actualizações existentes no sistema durante um período de tempo predefinido Geral Alta Listar todas as actualizações existentes no sistema Geral Alta Visualizar uma actualização Geral Alta Inserir uma nova actualização Privilegiado Alta Actualizar uma actualização existente Privilegiado Média Eliminar uma actualização existente Privilegiado Média

Tabela 14 - Gestão de Actualizações

4.3.1.8 Validação de Utilizadores

Este módulo disponibiliza as funcionalidades necessárias para os Utilizadores Privilegiados e o Administrador poderem validar novos utilizadores registados no sistema. Podem listar esses mesmos utilizadores, visualizá-los, e aceitá-los ou cancelá-los.

Os casos de uso da Validação de Utilizadores podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na tabela que se segue.


Listar os utilizadores por validar Privilegiado Alta Visualizar um utilizador por validar Privilegiado Alta Aceitar um utilizador por validar, ficando activo no sistema Privilegiado Alta Cancelar um utilizador por validar, sendo eliminado do sistema Privilegiado Alta

Tabela 15 - Validação de Utilizadores

4.3.1.9 Validação de Pautas

Este módulo disponibiliza as funcionalidades necessárias para os Utilizadores Privilegiados e o Administrador poderem validar novas pautas submetidas no sistema. Podem listar essas mesmas pautas, visualizá-las, e aceitá-las ou cancelá-las. A visualização das pautas é feita através do Editor de MusicXML com a pauta original lado a lado com a pauta em MusicXML.

Os casos de uso da Validação de Pautas podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na tabela que se segue.


49

Requisito Acesso Prioridade Listar as pautas por validar Privilegiado Alta Visualizar uma pauta por validar tanto no formato original como em MusicXML Privilegiado Alta Descarregar uma pauta por validar tanto no formato original como em MusicXML, paginada e não paginada

Privilegiado Média

Aceitar uma pauta por validar, ficando activa no sistema Privilegiado Alta Cancelar uma pauta por validar, sendo eliminada do sistema Privilegiado Alta

Tabela 16 - Validação de Pautas

4.3.1.10 Validação de Autores

Este módulo disponibiliza as funcionalidades necessárias para os Utilizadores Privilegiados e o Administrador poderem validar novos autores criados no sistema. Podem listar esses mesmos autores, visualizá-los, e aceitá-los ou cancelá-los.

Os casos de uso da Validação de Autores podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na tabela que se segue.


Listar os autores por validar Privilegiado Alta Visualizar um autor por validar Privilegiado Alta Aceitar um autor por validar, ficando activo no sistema Privilegiado Alta Cancelar um autor por validar, sendo eliminado do sistema Privilegiado Alta

Tabela 17 - Validação de Autores

4.3.1.11 Validação de Instrumentos

Este módulo disponibiliza as funcionalidades necessárias para os Utilizadores Privilegiados e o Administrador poderem validar novos instrumentos criados no sistema. Podem listar esses mesmos instrumentos, visualizá-los, e aceitá-los ou cancelá-los.

Os casos de uso da Validação de Instrumentos podem ser consultados no respectivo anexo na página 94. No entanto pode-se ver os requisitos na tabela que se segue.


Listar os instrumentos por validar Privilegiado Alta Visualizar um instrumento por validar Privilegiado Alta Aceitar um instrumento por validar, ficando activo no sistema Privilegiado Alta Cancelar um instrumento por validar, sendo eliminado do sistema Privilegiado Alta

Tabela 18 - Validação de Instrumentos

4.3.1.12 Motor de Pesquisa

Este módulo tem como objectivos permitir a qualquer utilizador, registado ou não, efectuar pesquisas pelos objectos do sistema, com vista a se encontrar mais facilmente os conteúdos que se pretende. Também deve permitir pesquisar ao nível da informação contida nas pautas em MusicXML, com o intuito de possibilitar a realização comparações, análises computacionais, entre outros. No entanto esta última parte será abordada numa fase posterior fora do contexto deste estágio.

Em relação à pesquisa pelas pautas armazenadas em MusicXML, será avaliada numa fase posterior a possibilidade de poder ser realizada através de excertos de pauta, que o utilizador poderá “escrever” directamente no browser através de um pequeno editor. Por exemplo, pode-se saber um pequeno pedaço de uma música e não saber qual é, e dessa forma pode-se


50

procurar pela música através do motor de busca escrevendo esse pedaço conhecido. Este tipo de pesquisa são algo particularmente inovador neste projecto pois é algo ainda por explorar, que permitirá um vasto conjunto de possibilidades.

No que respeita à pesquisa total, quando é feita pelo Administrador, os utilizadores registados no sistema são também incluídos nela, mas apenas neste caso.

Em resumo pode-se visualizar os requisitos deste módulo na Tabela seguinte.


Pesquisar ao nível do próprio sítio Geral Média Pesquisar ao nível de características das pautas, incluindo a sua metadata em MusicXML Geral Alta Pesquisar ao nível dos autores Geral Alta

Tabela 19 - Requisitos do Motor de Pesquisa

Os casos de uso deste módulo podem ser consultados no respectivo anexo na página 94.

4.3.2 Aplicação de OMR

O sistema pode incorporar uma ou mais aplicações de OMR neste módulo, e deverá ficar preparado para tal. Dessa forma existem algumas vantagens, como por exemplo ter software de OMR para diferentes tipos de notação musical, integrados no mesmo sistema. No entanto, por questões práticas e de simplificação, neste relatório será sempre considerada uma aplicação de OMR apenas, que se refere à que é objectivo de estudo do projecto.

O objectivo deste componente é reconhecer pautas musicais manuscritas e representá-las num formato utilizável por computador. Contudo, esse desenvolvimento e estudo deverá ser progressivo, no sentido de que deverão primeiro ser reconhecidas pautas musicais impressas, e só mais tarde com o decorrer do projecto se chegará ao objectivo de reconhecer pautas manuscritas.

O programa deverá receber como entrada um ficheiro de imagem, que contenha a página de uma pauta musical. De seguida deverá analisar essa imagem e fazer o respectivo reconhecimento do seu conteúdo musical, reconhecendo os símbolos encontrados e interpretando a sua semântica musical. Por último, com toda a informação obtida da pauta original, deverá guardar essa informação num formato de saída facilmente manipulável por computador, neste caso o MusicXML.

Uma vez que a aplicação é usada de forma integrada no sistema, o input dela é controlado pela aplicação web. Desta forma a aplicação de OMR recebe sempre um ficheiro de cada vez, devolvendo o seu resultado num novo ficheiro, e a aplicação web é que se encarrega de gerir todas as páginas fornecidas para reconhecimento, assim como o seu armazenamento. As imagens fornecidas deverão conter uma extensão que indique o seu formato para a aplicação de OMR as poder usar correctamente.

Este módulo deverá reconhecer os símbolos de notação musical standard, como se apresentou na secção 2.1.2. Em suma, os requisitos deste componente e as suas respectivas prioridades estão representados na tabela que se segue.


51

Requisito Prioridade Reconhecimento de notação musical standard em pautas musicais manuscritas Alta Receber como entrada uma imagem de uma página da pauta musical manuscrita, obtida através de um scanner

Alta

Reconhecer os símbolos musicais na pauta digitalizada Alta Interpretar os símbolos reconhecidos Alta Construir a semântica musical da pauta analisada Alta Exportação do reconhecimento para o formato MusicXML Alta

Tabela 20 - Requisitos da Aplicação de OMR


Uma aplicação deste tipo pode-se dividir em vários módulos, como se pode ver de uma forma geral nas subsecções seguintes, por forma a fazer uma breve especificação sobre esta parte do sistema. Contudo, como se irá usar uma aplicação de OMR existente nesta primeira fase do projecto, esta pode não ser exactamente a aproximação levada a cabo pelos seus autores da mesma. Mas será de alguma forma semelhante, uma vez que em geral é a estrutura abordada.

Este módulo encontra-se portanto separado em três módulos, embora o terceiro esteja muito ligado ao segundo. O primeiro deles divide-se em cinco partes, como se pode ver na subsecção que se segue.

Esta aproximação mais comum e simples é através de um conjunto de tarefas compostas numa arquitectura sequencial onde o sistema trabalha de tarefa em tarefa, desde a primeira à última, onde cada fase produz resultados que são os dados de entrada da fase seguinte. Contudo, por forma a esta arquitectura ser mais flexível, o processo não deverá consistir apenas numa sequência da primeira à última fase, mas é importante manter os resultados de cada fase para que possam ser sempre modificados ou revistos mais à frente no processo.

4.3.2.1 Reconhecimento dos Símbolos Musicais da Imag em

O motor OMR compreende duas fases: reconhecer os símbolos gráficos (tais como cabeças de nota e linhas) e as relações entre os símbolos (tais como a altura e ritmo das notas). O módulo de reconhecimento dos símbolos gráficos encontra-se por sua vez dividido numa sequência de cinco operações:

• Pré-processamento da imagem: Para diminuir/eliminar a influência de variações nas condições de

captura da imagem, e realizar uma limpeza e correcção à mesma;

• Identificação e remoção das linhas de pauta: Para permitir a correcta identificação de todos os símbolos

presentes na imagem;

• Remoção dos símbolos não musicais: Eliminação dos símbolos irrelevantes para a análise efectuada;

• Segmentação e classificação dos objectos: Identificação dos objectos de interesse na imagem;

• Montagem dos objectos: Reconhecimento dos símbolos, classificação de cada objecto identificado como

um símbolo musical.

A. Pré-Processamento da Imagem

Neste módulo realizam-se correcções ao nível do processamento de imagem para tornar mais fácil o reconhecimento. É fundamental antes de se passar aos módulos seguintes.

O pré-processamento pode envolver praticamente qualquer operação de processamento de imagem standard, incluindo a remoção de ruído, blurring, deskewing, ajuste do contraste, sharpening, binarização, ou morfologia. Pode ser necessário realizar um qualquer número de


52

operações numa imagem por tratar para prepará-la para o processo de reconhecimento, podendo-se no final deste módulo obter uma imagem binarizada para ser usada nos restantes módulos.

Portanto, uma das principais etapas é a binarização, para colocar toda a imagem colorida somente a preto e branco. No entanto a descoloração das pautas devido ao tempo podem dificultar o processo e podem ser necessários algoritmos localmente adaptativos. E geralmente linhas quebradas provocam problemas de segmentação dos símbolos.

Outra correcção que poderá ser necessária é a rotação, para alinhar as linhas de pauta se estiverem mal orientadas na folha, o que é muito provável numa pauta manuscrita.

Também poderá ser necessário realizar uma limpeza da imagem, no caso de o papel da pauta manuscrita se encontrar velho e com marcas, o que pode dificultar muito a análise da imagem.

B. Identificação e Remoção das Linhas de Pauta

A identificação das linhas de pauta foi uma parte deste projecto que foi aprofundada por outros colaboradores do mesmo, enquanto decorria o presente estágio. Foi escrito um artigo acerca da detecção de linhas de pauta para uma conferência, no qual o estagiário colaborou, tendo sido aceite.

Para se poder identificar os símbolos correctamente é importante identificar e remover as linhas de pauta, por forma a obter uma imagem onde constem apenas os símbolos musicais. Contudo, tem de se manter o conhecimento da posição delas para depois se poder construir a semântica musical.

Esta é precisamente uma das dificuldades de separar símbolos musicais com o computador uma vez que na sua maioria se encontram ligados às linhas de pauta. Tem de se realizar esta tarefa para que se possa separar correctamente cada um dos símbolos individuais. E a correcta identificação das linhas de pauta e o agrupamento das linhas é essencial à classificação de símbolos e mais tarde à sua interpretação.

Basicamente, este processo consiste em procurar na página os pixels que pertencem às linhas de pauta e removê-los. E também como já foi mencionado, há a necessidade de reter a posição dessas mesmas linhas para se poder relacionar a sua posição com as dos símbolos na imagem, para os poder interpretar correctamente. Contudo, devido à sobreposição de objectos, essas linhas não podem ser removidas na totalidade da sua extensão pois os pixels que pertencem a outros objectos têm de permanecer na imagem para a análise não ser adulterada.

As dificuldades desta fase inicial do processo de reconhecimento, principalmente por se tratar de pautas manuscritas, são as seguintes:

• As linhas nem sempre são rectas ou horizontais;

• Podem ser mais largas em algumas partes e mais finas noutras;

• Há sobreposição de símbolos musicais com as linhas;

• O espaçamento entre as linhas, e entre cada conjunto de linhas não é sempre o mesmo;

• As linhas não mantêm um paralelismo exacto entre elas;

• Nem sempre as linhas são contínuas devido a falhas de escrita ou desaparecimento com o tempo.

Existem vários métodos possíveis de se usar para realizar esta tarefa, sendo alguns deles os que se seguem, e foram descritos no projecto ROMA:


53

• Projecção Horizontal;

• Detecção dos Cantos da Linha;

• Projecção Horizontal-Vertical;

• Detecção de Traços.

No presente projecto, por parte de outros colaboradores a trabalhar em algoritmos de OMR, foi também estudado um novo método – A Shortest Path Approach for Staff Line Detection – o qual foi descrito no artigo mencionado na secção 1.5 e no início desta.

C. Remoção dos Símbolos Não Musicais

Tendo a imagem binarizada e sem as linhas de pauta é agora necessário eliminar símbolos irrelevantes para a análise que irá ser efectuada, com vista a obter uma imagem que contenha somente símbolos musicais.

Para este módulo pode ser usado um OCR (Optical Character Recognition), no caso de ter a letra, títulos, marcações de tempo, entre outros, o que irá permitir uma melhor análise por parte dos módulos que se seguem. Estes símbolos podem então ser removidos e analisados recorrendo a um OCR externo, ou esse reconhecimento estar integrado na aplicação.

D. Segmentação e Classificação dos Objectos

A segmentação dos objectos é o processo de reconhecimento e identificação de objectos simples, como blobs (binary large objects) ou linhas, que fazem parte de símbolos musicais, isolando-os e construindo um modelo interno dos objectos. É o núcleo deste sistema de OMR.

Os símbolos mais comuns neste tipo de reconhecimento são linhas verticais (hastes e linhas de barra (stems e barlines)) e cabeças de nota pretas (preenchidas). Portanto, são removidos usando heurísticas antes da identificação mais geral de símbolos ser aplicada. As linhas verticais são consideradas qualquer área a preto que seja fina e alta.

Algumas das cabeças de nota preenchidas, principalmente as que tocam noutras cabeças de nota podem não ser identificadas nesta fase e são portanto passadas à fase mais geral de identificação de símbolos.

Podem ser usadas ferramentas para a criação de classificadores de heurísticas simples, combinação da imagem baseada em templates, e um classificador com aprendizagem usando o algoritmo k-nearest neighbor melhorado com um algoritmo genérico. Outros algoritmos de classificação possíveis incluem redes neuronais, árvores de decisão ou modelos de Markov escondidos.

E. Montagem dos Objectos

Os objectos simples isolados são juntados formando os vários símbolos musicais, tais como notas, pausas, entre outros. Geralmente neste passo usam-se DCG’s (Defined Clause Grammars) que descrevem cada símbolo musical através dos seus componentes, e.g. uma colcheia é composta por uma cabeça de nota (blob), uma haste (linha) e uma “bandeira” (flag) se não estiver agrupada com outras, senão terá uma linha a uni-las em vez da “bandeira”.

Cada símbolo é classificado combinando cada elemento na página o mais próximo possível com os símbolos numa base de dados. Uma boa característica de uma boa aproximação é a base de dados que descreve cada símbolo não ser fixa. Em vez disso a aparência de novos símbolos é aprendida por exemplo. Dessa forma novos símbolos podem ser facilmente


54

adicionados ao sistema. Esta aproximação permite que símbolos dramaticamente diferentes, como por exemplo colcheias manuscritas ou impressas, possam ser reconhecidos.

4.3.2.2 Reconstrução dos Grupos Musicais de Semântic a

Este módulo representa a segunda fase de um motor de OMR.

O reconhecimento dos símbolos musicais por si só não é suficiente, é preciso atribuir-lhes o seu significado na música da pauta analisada. Por isso mesmo neste módulo serão usados mecanismos para converter as características gráficas reconhecidas para um formato usável em computador. Ou seja, é a especificação das semânticas musicais das características gráficas. Recebe como entrada os símbolos identificados no módulo anterior, assim como uma base de dados de conhecimento de semânticas musicais. Tem como saída os grupos musicais de semântica reconhecidos na pauta.

Este processo reconstrói um documento numa representação semântica dos símbolos individuais. Combina os símbolos em notas musicais. É neste módulo que os símbolos são interpretados musicalmente. O primeiro passo é criar relações entre eles, por exemplo, para saber a altura de uma nota é preciso relacioná-la com um conjunto de linhas de pauta, uma clave e uma tonalidade. As durações são determinadas relacionando uma cabeça de nota com hastes, feixes e “bandeiras” (stems, beams and flags).

Por fim pode-se incluir a realização de correcção métrica. Assim que as relações entre os símbolos tenha sido determinada é possível corrigir erros efectuados nos módulos anteriores examinando as durações das notas. Uma vez que em cada compasso a duração total das notas tem de ser igual à sua definição e as notas devem estar alinhadas verticalmente entre as várias partes, muitos erros podem ser corrigidos verificando a consistência entre as localizações relativas das notas. Podem ter sido provocados erros por exemplo por falhas de tinta e por exemplo uma colcheia ser identificada como semínima por não se ler bem a parte superior da nota (ou inferior se estiver virada para baixo).

4.3.2.3 Construção da Representação Final

Por último, temos a construção da representação final. Neste módulo realiza-se a transformação dos símbolos identificados, a interpretação pós-estrutural, num formato de descrição musical para armazenamento. Neste caso será o formato MusicXML.

4.3.3 Editor de MusicXML

Este módulo deverá permitir ao utilizador a possibilidade de, através da aplicação web, visualizar as pautas em MusicXML, lado a lado com o original, e ainda permitir a sua edição após o reconhecimento óptico, ou simplesmente quando se pretender actualizar a informação ou alguma página da obra.

A possibilidade de editar através de um browser uma pauta lado a lado com a original, permite comparar e efectuar as correcções necessárias, ou inserir as partes que não foram reconhecidas com sucesso pelo módulo de OMR. Após essa edição do resultado obtido o editor deverá então permitir guardar o resultado final corrigido, na base de dados.

O editor deve permitir representar todos os símbolos de uma pauta com notação musical standard, começando numa primeira fase por representar pelo menos os símbolos que a aplicação de OMR permite reconhecer. Contudo, este módulo é bastante complexo, e por isso numa primeira fase consistirá de um simples editor de texto para editar e visualizar o código


55

em MusicXML. Numa fase posterior do projecto, será melhorado para o verdadeiro editor de pautas que se tem como objectivo. Por esse motivo, em relação à duração do estágio o objectivo principal deste componente é pelo menos poder visualizar e editar o conteúdo em MusicXML.

Os requisitos deste módulo e as suas respectivas prioridades encontram-se especificados na tabela seguinte.


Visualização de pautas em MusicXML Alta Edição de pautas em MusicXML Alta Guardar na base de dados uma pauta em MusicXML que tenha sido editada Alta Permitir a edição/visualização lado a lado com a pauta original Média Suportar a representação completa de pautas em notação musical standard Média5

Tabela 21 - Requisitos do Editor de MusicXML


Pretende-se com este editor oferecer uma solução completa, possibilitando aos utilizadores realizar todas as tarefas online através da aplicação web sem necessidade de utilizar ferramentas exteriores e offline. Deste modo o utilizador tem todas as tarefas associadas ao reconhecimento óptico bastante facilitadas.

4.3.4 Armazenamento

Um objectivo fundamental em relação ao que é pretendido com o sistema em desenvolvimento passa precisamente pelo armazenamento das pautas musicais manuscritas.

Esta parte do sistema consiste numa base de dados relacional adequada ao tipo de dados que irão ser armazenados, tanto no que respeita às capacidades da base de dados, nomeadamente o suporte de XML, como também relativamente ao desenho da mesma. Deve ser eficiente e suportar o armazenamento de toda a informação necessária, no que respeita às pautas armazenadas e ao sistema (dados dos utilizadores, entre outros).

É necessário que o armazenamento das pautas seja completo, ou seja, que se guarde tanto a versão original em imagens digitalizadas com um scanner como também a versão digital criada pelo módulo de OMR no formato MusicXML. Desta forma preserva-se tanto o original, para referência, como uma versão digital facilmente manipulável através de um computador e que permite uma fácil leitura e manuseamento da pauta.

Todos os dados são inseridos na base de dados através da aplicação web, ou seja, nenhum utilizador tem de manipular a base de dados directamente, tudo ocorre por intermédio da aplicação web.

O armazenamento da informação, para além de fundamental, é também um objectivo do projecto em curso para preservar as obras musicais que são alvo de preservação neste sistema. Esta base de dados deverá facilitar o processo de music retrieval que o projecto tem também como objectivo de possibilitar numa fase posterior, através do sistema a desenvolver. Em

5 A prioridade é média no sentido de que inicialmente é apenas necessário representar os símbolos que a

aplicação de OMR irá reconhecer numa primeira fase, e depois é que terá de evoluir por forma a permitir a representação completa. Este requisito refere-se a todo o projecto, para além do estágio.


56

suma os requisitos deste módulo e as suas respectivas prioridades podem ser observados na tabela que se segue.

Requisito Prioridade

Possibilitar o armazenamento de pautas musicais em MusicXML em conjunto com as suas originais Alta Permitir pesquisar a informação contida nas pautas em MusicXML Alta Permitir pesquisar a informação em geral contida na base de dados Alta Possibilitar o armazenamento da informação necessária ao sistema (dados dos utilizadores, entre outros) Alta

Tabela 22 - Requisitos do Armazenamento

4.4 Requisitos de Qualidade

Existem alguns requisitos de qualidade a considerar neste sistema, os quais serão explicitados de seguida. Estes são os requisitos de qualidade que o sistema deverá ter no final da sua implementação. Deverão ser tidos em conta durante todo o desenvolvimento e são a vários níveis, como pode ser visto nas subsecções que se seguem.

4.4.1 Eficiência

Os requisitos funcionais devem ser implementados tendo em vista uma utilização eficiente dos recursos do sistema, tais como a memória, processamento e largura de banda no acesso online.

Em relação ao armazenamento, a base de dados deverá ser desenhada com o objectivo de possibilitar um armazenamento eficaz e ainda possibilitar pesquisas de uma forma rápida e eficaz. Deve também ser o mais eficiente possível o módulo de OMR, evitando demoras muito grandes durante o reconhecimento das pautas musicais manuscritas. Os algoritmos devem ser estudados tendo por finalidade não só o correcto reconhecimento das pautas, mas também tendo como objectivo que sejam eficientes.

A resposta do sistema em geral deverá ser apenas o necessário para poder ser o mais eficiente possível, sem gastar mais recursos do que seja realmente necessário. No entanto, não é um sistema crítico.

4.4.2 Fiabilidade

O sistema deverá estar preparado para que no caso de ocorrerem falhas durante o seu funcionamento, este possa tentar garantir que não haja perdas de dados e deverá também, sempre que necessário e possível, emitir mensagens de erro claras, permitindo ao utilizador compreender o que se passa. Ou seja, deverá ser realizado um correcto tratamento de erros.

Os resultados obtidos com o módulo de OMR deverão ser o mais fiáveis possíveis, sendo fieis à pauta reconhecida. Não se pode exigir uma fiabilidade da ordem dos 100%, mas é necessário que pelo menos consiga justificar e despertar o interesse pela sua utilização. E uma vez que se trata de reconhecimento de pautas musicais manuscritas deverá também haver uma tolerância às diferenças da notação de autor para autor para reconhecer correctamente os símbolos musicais presentes na pauta.

O funcionamento do editor de pautas deverá ser também fiável, garantindo que não se perdem dados durante o carregamento e armazenamento de uma pauta em MusicXML. A edição numa


57

parte da pauta não deverá alterar outras partes sem que o utilizador se possa dar conta disso mesmo, comprometendo a validade da pauta editada e/ou visualizada.

No que respeita à aplicação web, sendo ela o ponto de acesso a todo o sistema e às suas demais funcionalidades, deverá ser fiável no sentido de produzir os resultados esperados e evitar a perda de dados, nomeadamente dos dados armazenados na base de dados. Sempre que se realizarem inserções estas não deverão interferir com os restantes dados da base de dados, e sempre que se proceder à actualização de uma pauta não deve igualmente interferir no restante, e também não deverá acontecer a perda da pauta anterior e da nova ao mesmo tempo, perdendo essa obra do arquivo. Por último, a remoção de uma pauta não deve comprometer a integridade dos restantes dados armazenados. O mesmo deverá ser tido em conta em relação à gestão dos utilizadores registados no sistema.

O controlo das pautas validadas e por validar deverá também ser fiável, não podendo ocorrer casos erróneos que comprometam a validade do sistema. O mesmo é necessário no caso da validação de autores e instrumentos.

4.4.3 Manutenção

O sistema deverá ser projectado segundo padrões de desenvolvimento de software estabelecidos, devendo ser correctamente documentado. Deve também em geral ser orientado a objectos de forma a ter classes ou objectos reutilizáveis tornando assim fácil a sua manutenção. A base de dados deverá ser facilmente expandida, sem comprometer os dados existentes.

Do ponto de vista da utilização, o sistema deverá ser facilmente mantido através da aplicação web, sem necessidade de conhecimentos técnicos profundos.

4.4.4 Portabilidade

O sistema deverá permitir o acesso a partir de qualquer sistema ou plataforma com ligação à internet através de um browser, independentemente do sistema operativo no qual seja executado.

No que respeita à execução do sistema num servidor com acesso pela internet, as ferramentas deverão ser multi-plataforma, podendo correr sempre de preferência em sistemas livres.

4.4.5 Segurança

Neste sistema é importante considerar questões de segurança entre os vários tipos de utilizador para não permitir acessos indevidos à informação armazenada. E portanto o acesso é controlado através de registo e autenticação no sistema.

As várias funcionalidades devem funcionar consoante o acesso permitido para cada tipo de utilizador autenticado no sistema, e para o caso de ser um utilizador visitante não deve permitir igualmente acessos indevidos.

Um utilizador não deverá por exemplo obter acesso de actualização e/ou remoção a pautas que não lhe pertencem. Somente Utilizadores Privilegiados e o Administrador podem aceder dessa forma a pautas não introduzidas por eles mesmos. E um visitante nunca deverá ter acesso de escrita a nenhum conteúdo. Um Utilizador Privilegiado não pode ter acesso à gestão de utilizadores do seu nível e um Utilizador Registado não pode sequer ter acesso à gestão de


58

utilizadores. Todo o acesso pela Internet à base de dados só deverá ser possível através da aplicação web e respectivos módulos.

Na realização de pesquisas nunca deverá ser mostrada informação que não pertença ao nível de acesso do utilizador que a efectuou. E no caso de acontecerem erros não deverá ser mostrada informação comprometedora, tal como palavras-passe.

4.4.6 Usabilidade

A interface é muito importante no sistema a desenvolver, e dela em conjunto com a fiabilidade do reconhecimento óptico das pautas musicais manuscritas, depende o seu sucesso e adesão por parte dos utilizadores. Se a aplicação facilitar com sucesso a conversão das pautas manuscritas para MusicXML e dessa forma consiga poupar tempo aos utilizadores, então já se poderá dizer que atingiu um bom nível de usabilidade, pois o objectivo é fazer com que esta conversão seja mais rápida e menos trabalhosa do que se for feita manualmente. E portanto a usabilidade da interface é muito importante, pois se esta estabelecer um obstáculo à correcta realização da tarefa os objectivos estarão comprometidos.

É razoável que seja preciso algum tempo, mas nunca demasiado, para aprender a usar o módulo de edição das pautas. Contudo, o sistema em geral deverá ser facilmente utilizável por um utilizador que o vá usar pela primeira vez, conseguindo mesmo assim demorar menos tempo do que se fizesse a conversão da pauta manuscrita manualmente. No entanto, deverá ser disponibilizada uma secção de ajuda onde um utilizador se possa esclarecer sobre eventuais dúvidas.

Algo para facilitar uma fácil utilização é tornar o sistema intuitivo, fácil de aprender e com um funcionamento familiar. É necessário ter em conta também que será um sistema usado por várias gerações de pessoas, umas mais novas e com conhecimentos mais alargados sobre a informática e outros com poucos conhecimentos e menos habituados ao seu uso, e no entanto sendo potenciais utilizadores. Por isso mesmo deve-se ter em conta a facilidade de uso do sistema por todos os utilizadores em geral.

4.5 Requisitos Tecnológicos

As tecnologias a usar no sistema tiveram de ser seleccionadas por entre as várias analisadas ma secção 3.2, uma vez que o sistema ainda não existia e tinha de ser criado de raiz. Fez-se uma análise sobre possíveis tecnologias a usar para implementar o sistema. Nesta secção são reveladas quais as tecnologias a usar, justificando as mesmas.

Começando pelo SGBD, optou-se pelo PostgreSQL. As razões prendem-se com o facto de ser um SGBD bastante maduro, livre, opensource, bastante usado e portanto com muito bom suporte, possui uma documentação bastante completa e é multi-plataforma. As suas características e limites tornam-no adequado para utilizar no sistema a desenvolver, nomeadamente no que respeita ao suporte de XML, necessário para se pesquisar por entre as pautas em MusicXML, que aparenta estar mais desenvolvido que o do MySQL. É inclusive facilmente utilizado com a plataforma que se irá usar. É também uma BD relacional, o que é importante uma vez que se pretende armazenar todos os dados do sistema numa única BD.

A plataforma que irá ser usada é o Ruby on Rails. Optou-se por esta plataforma por diversos motivos. É uma plataforma livre, opensource e multi-plataforma que conta já com uma elevada maturidade. Esta plataforma foi feita a pensar no desenvolvimento web moderno,


59

dinâmico e com utilização de BDs. Como tal, as únicas adições necessárias são um SGBD e um servidor, pois de resto a plataforma contém as tecnologias necessárias integradas para um completo desenvolvimento das aplicações web. A linguagem de programação é o Ruby e contém JavaScript, Ajax (ver Figura 5), HTML e CSS. Uma das grandes vantagens é o acesso às BDs que é muito simplificado, não sendo necessário na grande maior parte dos casos a utilização de SQL nem de estabelecer as ligações explicitamente pois a plataforma trata disso. Toda a plataforma inclui inúmeras facilidades mesmo para facilitar a escrita de HTML (helpers) e existe um elevado número de plugins e gems (pacotes de funcionalidades para Ruby) livres que podem ser usados e são facilmente instalados. Suporta também optimistic locking, para evitar a colisão de acessos a dados. Encontra-se também com uma popularidade crescente, com uma comunidade bastante activa. Desta forma existem inúmeros fóruns e tutoriais, assim como bastante documentação acerca da utilização da mesma.

Figura 5 - Funcionamento do Ajax

(Diagrama retirado do livro “Agile Web Deveolpment with Rails” listado na bibliografia)

Uma outra característica importante é que esta plataforma ajuda o programador a criar uma aplicação web de uma forma lógica e organizada, uma vez que segue uma estrutura bem definida, de acordo com o modelo MVC (Model-View-Controller). Dessa forma o código põe ser melhor estruturado e é mais fácil de ser continuado o seu desenvolvimento.

A arquitectura da plataforma pode ser visualizada na Figura 6.


60

Figura 6 - Arquitectura do Ruby on Rails

(Diagrama retirado da fonte: http://www.kyleshank.com/files/rails_case_study.pdf)

A linguagem de programação usada, o Ruby, é uma linguagem que pareceu ser bastante adequada e até preferível ao Java. Apesar de serem ambas orientadas a objectos, o Ruby tem uma maior flexibilidade, sem perda de desempenho. Por exemplo, no Java é necessário definir os tipos de dados mas o Ruby é dinamicamente tipado, o tipo de dados de uma variável é inferido dinamicamente em execução. É uma linguagem simples de perceber e facilmente aprendida para quem já usar programação orientada a objectos. É não só uma linguagem orientada a objectos pura e muito completa, mas também de scripting, e o código pode ser alterado durante a execução sem ter de ser recompilado. Suporta também multithreading mesmo quando o sistema operativo não o suporta.

Resumindo, o facto de ser uma plataforma completa, livre, madura, com bom suporte, uma comunidade crescente e activa, e que simplifica a criação de aplicações web através da utilização de uma linguagem de programação orientada a objectos poderosa, pareceu ser a plataforma ideal. Inclusive, sendo uma plataforma a ganhar bastante terreno, pareceu uma interessante e boa aposta pensando no futuro e no futuro da web. E como se pretende inovar com este projecto, podemos também inovar utilizando uma plataforma moderna com a potencialidade de ir mais além sem ter de se “reinventar a roda”.

O acesso à BD através do Ruby on Rails é realizado através da instalação de um adaptador livre, existindo vários para o efeito, alguns estão incluídos nas gems disponíveis pela gestão de gems do Ruby.

O editor nesta fase será de edição simples com texto pleno e portanto fará parte do código da aplicação web em Ruby on Rails.

No que respeita à aplicação de OMR vai-se utilizar para o efeito o OpenOMR, o qual pareceu ser uma boa solução para esta primeira fase pois foi possível obter resultados satisfatórios com pautas impressas e a solução está completa e funcional, necessitando apenas de criar o resultado final em MusicXML. Encontra-se também bem documentada, é livre, opensource e multi-plataforma.


61

Como a plataforma escolhida é o Ruby on Rails optou-se por utilizar o Apache como servidor de HTTP, com a utilização do Mongrel para executar a aplicação web. É uma das soluções sugeridas pela própria plataforma e pareceu adequada visto ser eficiente, livre e opensource.

Desde o início do projecto pretendeu-se realizar o armazenamento das pautas em MusicXML. No entanto fez-se uma análise no capítulo 3 para verificar se de facto seria o formato digital adequado. Com a análise realizada constatou-se que de facto é o formato adequado e portanto será o usado. Não só é o mais recente e ao mesmo tempo maduro, está a ganhar terreno, sendo já suportado por todas as aplicações de maior relevo, como também a sua estrutura de forma hierárquica é ideal para representar a informação musical e permitir efectuar pesquisas com base nela.

4.6 Requisitos de Desenvolvimento

A abordagem que irá ser levada a cabo durante o projecto será baseada no modelo de desenvolvimento iterativo e incremental pois após cada incremento o mesmo irá ser testado, avaliado e integrado no sistema, sendo o próprio sistema testado e avaliado. Pretende-se desta forma desenvolver o sistema de forma gradual disponibilizando mais rapidamente as funcionalidades prioritárias, sendo alvo de uma maior verificação e teste, corrigindo os problemas de uma forma controlada e construindo as várias partes do sistema tendo o que já estiver concretizado a funcionar correctamente e portanto evitando problemas maiores. Desta forma o sistema irá também sendo reavaliado podendo-se introduzir melhorias, corrigir eventuais falhas e implementando novas funcionalidades a cada iteração.

Uma vez que se encontre concluída toda a fase de desenvolvimento, o sistema deverá ser testado e validado na sua totalidade, corrigindo eventuais falhas. Deverá ser fornecido um Manual de Utilizador em inglês, e o sistema deverá conter uma secção de ajuda, visto ser um sistema disponível online e o manual ser apenas para quem instala o sistema e não para quem o irá usar via web.

4.7 Protótipo da Interface

Com base nos requisitos funcionais apresentados neste capítulo, a interface deverá ser implementada segundo a estrutura definida no diagrama da Figura 7. Este fluxograma define como é que a navegação e organização da aplicação web a desenvolver se deve realizar.


62

Figura 7 - Fluxograma da Aplicação Web

Nesta parte final da especificação decidiu-se também como será a organização visual dos componentes da interface. Optou-se por dividir a interface em seis partes:

• Autenticação;

• Zona de título, idioma e contexto;

• Pesquisa rápida;

• Menu principal, com acesso a todas as funcionalidades;

• Conteúdos;

• Menu inferior, com acesso a páginas genéricas como por exemplo os contactos e ajuda.

Na seguinte imagem de protótipo pode ser vista a organização da mesma no que será o ecrã inicial. Cada uma das seis partes enunciadas encontra-se pela mesma ordem a começar no canto superior esquerdo, como se pode verificar pela Figura 8. Ou seja, em cima optou-se por colocar a autenticação à esquerda, a zona de título no centro e à direita a pesquisa rápida.


63

Abaixo dessa parte tem-se o menu principal à esquerda e à direita, ocupando a maior parte da área da aplicação, os conteúdos. Por último, em baixo, fica o menu inferior.

Figura 8 – Protótipo da interface, mostrando a pesquisa nos conteúdos

Outra opção que se tomou, como pode ser observado na mesma figura, foi a utilização de um menu expansível a dois níveis (principal e expandido), no caso do menu principal.

Em termos das dimensões da área da aplicação optou-se pela resolução de 1024x768, que é actualmente talvez a resolução mais genérica. E para cada secção seguiu-se o princípio de fornecer à área de conteúdos o maior espaço possível, deixando portanto para as restantes apenas o necessário.

Todo o tema e cores pelas quais se optou para utilizar na interface, assim como as imagens criadas, tiveram origem no próprio tema do projecto. Por outras palavras, pretendeu-se dar um ar vintage à aplicação visto tratar de obras musicais manuscritas, e portanto antigas.

No geral a aplicação, para cada módulo segue um funcionamento genérico, ou seja, são feitas listagens de objectos e utilizados formulários para inserção e edição de dados. No entanto, esta aplicação tem uma particularidade que exige um maior planeamento de como será mais tarde implementado. Trata-se da submissão de pautas musicais, nomeadamente o caso principal, de submissão com reconhecimento óptico das páginas inseridas. Por esse motivo criou-se um diagrama de actividades para especificar a sequência de passos necessários para este caso principal da submissão, que inclui os passos todos. O diagrama pode ser visto de seguida, na Figura 9.


64

Figura 9 - Diagrama de Actividades da Submissão de Pautas Musicais

Para além da sequência de passos necessários, decidiu-se que a criação das secções e da submissão dos ficheiros das páginas da pautas se deverá realizar de forma semelhante à criação de anexos no envio de mensagens de webmail, uma vez que é um caso já bastante familiar e intuitivo.


65

5 Desenvolvimento da Aplicação

Neste capítulo pretende-se explicar como foi efectuada a implementação do protótipo durante o estágio, assim como detalhes pertinentes sobre a mesma, os problemas encontrados e respectivas soluções.

5.1 Visão Geral

Tal como foi especificado no capítulo anterior, o sistema divide-se em vários módulos principais:

• Aplicação web;

• Aplicação de OMR;

• Editor de MusicXML;

• Armazenamento.

No presente estágio o sistema foi desenvolvido com vista a obter uma solução completa e demonstrável. No entanto, devido à complexidade que cada módulo impõe, o desenvolvimento não foi total. Ou seja, o que de facto foi desenvolvido foi a Aplicação Web, que é o ponto de acesso e interacção com o sistema, assim como a base de dados do Armazenamento, igualmente fundamental. Para a Aplicação de OMR foi usado o OpenOMR como foi já mencionado. Em relação ao Editor de MusicXML ainda não é um editor real, mas sim edição e visualização directa do código MusicXML para pelo menos se poder visualizar e editar as pautas no formato digital. Um dos módulos da Aplicação Web, o motor de pesquisa, devido à sua complexidade foi parcialmente implementado. Nesta fase do projecto esse módulo permite apenas pesquisas simples por entre os objectos da BD, e só numa fase posterior, já fora do âmbito do estágio, é que irá ser implementada a pesquisa utilizando a metadata contida nas pautas em MusicXML. No entanto, mesmo com o pouco tempo disponível para realizar a implementação do sistema, foi possível apresentar uma solução completa e todos os casos de uso se encontram implementados.

Desta forma é apresentada neste capítulo a implementação da BD e da Aplicação Web, focando os detalhes da sua estrutura, modelos de dados e a estruturação do código desenvolvido, assim como as interfaces principais do sistema concebido.

5.1.1 Decomposição Horizontal

O sistema segue uma decomposição horizontal com base no modelo MVC, separado em três camadas distintas, como pode ser visto na Figura 10. Essas três camadas são:

• Interface com o utilizador (View): O que o utilizador do sistema vê e com o qual interage. Esta camada

comunica com a seguinte enviando-lhe os dados introduzidos e recebendo os dados requeridos;

• Lógica de negócio (Controller): É a camada intermédia na qual se faz a comunicação com a BD e a

Interface do sistema. Nesta camada é onde os dados são processados e tratados, sendo também feita a

comunicação com os vários módulos que compõem o sistema. Esta camada é responsável por garantir

um bom funcionamento no geral;


66

• Base de dados (Model): Camada na qual é feito o armazenamento da informação que o sistema utiliza e

armazena, ou seja, é onde se encontra toda a informação manipulada pelo sistema. Essa informação

inclui as pautas, informação associada e a informação dos utilizadores.

Figura 10 - Decomposição Horizontal

5.1.2 Decomposição Vertical

A decomposição vertical é feita por subsistemas, de forma hierárquica, em que cada subsistema corresponde a um grupo de funcionalidades e abrange todas as camadas da implementação. No fundo a decomposição vertical aqui apresentada coincide com os módulos e submódulos já apresentados na especificação de requisitos.

Portanto, pode-se dizer que verticalmente o sistema divide-se nos seguintes subsistemas:

• Gestão de Actualizações: Inclui toda a gestão de Actualizações/Notícias;

• Gestão de Autores: Inclui toda a gestão de Autores;

• Gestão da Conta de Utilizador: Inclui toda a gestão dos dados de Utilizador;

• Gestão de Géneros Musicais: Inclui toda a gestão de Géneros Musicais;

• Gestão de Instrumentos: Inclui toda a gestão de Instrumentos;

• Gestão de Pautas: Inclui toda a gestão de Pautas;

• Gestão de Utilizadores: Inclui toda a gestão de Utilizadores;

• Pesquisa: Subsistema do motor de pesquisa;

• Edição e Visualização: Subsistema de edição e visualização de pautas;

• OMR: Subsistema de reconhecimento óptico de pautas musicais;

• Validação de Autores: Inclui as facilidades de validação de Autores;

• Validação de Instrumentos: Inclui as facilidades de validação de Instrumentos;

• Validação de Pautas: Inclui as facilidades de validação de Pautas;


67

• Validação de Utilizadores: Inclui as facilidades de validação de Utilizadores.

Ilustração 1 - Decomposição Vertical

5.2 Modelos de Dados

O sistema implementado sendo composto por uma aplicação web e uma base de dados, é representado por mais do que um diagrama de classes. De seguida são apresentados esses mesmos diagramas separados nas duas subsecções que se seguem, consoante o seu contexto.

Em cada subsecção serão explicadas as particularidades existentes referentes a cada modelo de dados.

5.2.1 Base de Dados do Armazenamento

No desenho da base de dados que usada para armazenar as pautas musicais optou-se por separá-las em várias páginas em relação à componente em MusicXML, uma vez que a pauta original também será armazenada em conjunto e se encontra dividida em várias páginas. Dessa forma cada página original fica armazenada em conjunto com a sua equivalente reconhecida em MusicXML. Na classe Score, o atributo digital_score é o atributo onde será armazenada cada pauta em MusicXML, com possibilidade de ser pesquisado usando a sua metadata. No atributo original_score fica armazenada a sua fonte original.

O atributo email na classe User é o nome de utilizador de cada utilizador registado no sistema uma vez que é único. Por esse motivo é utilizado na autenticação dos utilizadores.

Cada classe contém três atributos especiais que são específicos da plataforma usada, o Ruby on Rails. Esses atributos são created_on, updated_on e lock_version. As subclasses contêm-nos através de herança da superclasse. Estes atributos são manipulados automaticamente pelo


68

Ruby on Rails. Os dois primeiros, tal como os seus nomes indicam, guardam as datas de quando o objecto foi criado e a da sua última modificação. O terceiro atributo tem uma outra função especial, serve para efectuar o optimistic locking, por forma a evitar colisões entre os utilizadores quando estes actualizam o mesmo objecto concorrentemente. Através do atributo lock_version, o Rails consegue saber se, quando se está a actualizar um objecto, este foi actualizado por outro processo enquanto se alterou os valores antes de se guardar de novo na BD. Dessa forma pode-se evitar colisões apanhando a excepção que o Rails lança quando ocorre concorrência.

Existe mais um caso especial, próprio do Rails, em duas classes do diagrama. As classes Work e Section contêm um atributo com sufixo _count. Os atributos com esse sufixo são um contador mantido pelo Rails para os objectos cujo prefixo é o nome dessa classe no plural, quando são criados através da classe que contém o contador. Desta forma pode-se saber quantas secções uma obra contém, ou quantas páginas uma secção contém, de forma mais eficiente em termos de desempenho.

Na classe Update cada atributo, à excepção dos três atributos especiais já mencionados, está duplicado com um sufixo _pt ou _en. O motivo dessa duplicação é devido ao suporte multilingue da aplicação web, por forma a poder guardar as actualizações/notícias nas duas línguas suportadas.

Apesar de algumas subclasses não conterem atributos específicos, são no entanto representadas pois é necessário distinguir o tipo de objecto na aplicação. No caso de ser um objecto do tipo User é preciso saber que tipo de utilizador é através da subclasse que o representa. O mesmo se passa no caso de ser um objecto do tipo Instrument.

Na Figura 11 pode ser observado o diagrama de classes da base de dados.


69

Figura 11 - Diagrama da Base de Dados do Armazenamento

Na tabela que segue descreve-se cada uma das tabelas representadas no diagrama. Classe Descrição User Representa um utilizador registado genérico

Registered Deriva de User e representa um utilizador do tipo Utilizador Registado Privileged Deriva de User e representa um utilizador do tipo Utilizador Privilegiado

Administrator Deriva de User e representa um utilizador do tipo Administrador Work Representa uma obra musical armazenada no sistema que é composta por uma ou mais secções

Author Representa um autor de obras musicais MusicalGenre Representa um género musical

Section Representa uma secção pertencente a uma obra. No caso da peça estar separada em várias partes, senão terá apenas uma secção com todos os instrumentos na mesma pauta

Score Representa uma página de uma secção de uma obra. Contém a imagem original da página assim como a versão em MusicXML da mesma

Instrument Representa um instrumento musical genérico Vocal Deriva de Instrument e representa um instrumento do tipo Vocal, neste caso será um tipo de voz

Strings Deriva de Instrument e representa um instrumento do tipo Cordas, neste caso será um instrumento de cordas

Blow Deriva de Instrument e representa um instrumento do tipo Sopro, neste caso será um instrumento de sopro

Keys Deriva de Instrument e representa um instrumento do tipo Teclas, neste caso será um instrumento de teclas

Percussive Deriva de Instrument e representa um instrumento do tipo Percussivo, neste caso será um instrumento percussivo

Update Representa uma actualização/notícia da secção de notícias

Tabela 23 - Descrição sumária das classes do diagrama da base de dados

Na especificação do modelo conceptual da base de dados identificaram-se as seguintes regras de integridade, não observáveis através do diagrama de classes:

• Entidade User:

o O email tem de ser único;


70

o Por questões de segurança a password tem de conter 8 ou mais caracteres (na BD na realidade é armazenada

apenas a sua hash por questões de segurança).

• Entidade Author:

o O atributo birth_day tem de ser uma data mais antiga que a data actual em que o Author for criado, e encontrar-

se no formato correcto.

• Entidade Work:

o A creation_date tem de se encontrar no formato correcto e ser igual ou inferior à data actual quando a obra for

inserida;

o A publishing_date tem de se encontrar no formato correcto e ser igual ou inferior à data actual quando a obra for

inserida, e também superior à creation_date.

• Entidade Section:

o O section_number tem de ser igual ou inferior à quantidade de ocorrências de objectos do tipo Section que

pertençam à mesma obra.

• Entidade Score:

o O page_number tem de ser igual ou inferior à quantidade de ocorrências de objectos do tipo Score que

pertençam à mesma secção.

• Entidade Strings:

o O number_strings tem de ser maior ou igual a 1;

o A tuning tem de se encontrar no formato correcto e não pode ser uma string vazia. Sendo esse formato o

seguinte onde se deverá substituir cada valor entre os símbolos ‘<’ e ‘>’ pelas respectivas notas musicais em

notação anglo-saxónica (i.e. c, d, e, f, g, a, b):

o <nota 1> <nota 2> ...

• Entidade Vocal:

o A function não pode ser uma string vazia.

Para além das regras indicadas tem de se considerar os casos mais óbvios não detalhados, como por exemplo, preencher os campos necessários como o nome, entre outros. Não se poderia por exemplo ter um Autor em que todos os seus atributos fossem vazios. Os casos que foram aqui detalhados têm como intenção especificar os casos menos óbvios. Toda a informação necessária para identificar cada objecto deverá ser preenchida e serem apenas opcionais os atributos não necessários, como por exemplo na entidade User os atributos institution e institution_address, podendo o Utilizador não pertencer a nenhuma instituição.

Durante o desenvolvimento da aplicação foram realizadas algumas simplificações e alterações na BD até chegar a este resultado final. Essas alterações foram principalmente porque se chegou à conclusão de que algumas tabelas eram dispensáveis, não traziam qualquer valor ao sistema e eram irrelevantes relativamente aos objectivos do projecto.

Na subsecção seguinte será especificado o esquema relacional correspondente ao diagrama de classes apresentado.


71

5.2.1.1 Esquema Relacional

A partir do diagrama de classes da BD especificou-se o esquema relacional com as tabelas contendo as respectivas chaves primárias (PKs – Primary Keys) e chaves estrangeiras (FKs – Foreign Keys).

O Rails segue uma série convenções próprias relativamente ao esquema relacional, por forma a tornar mais fácil a manipulação da BD através do código da aplicação web. Para além dos atributos especiais já mencionados na secção anterior, existem ainda os seguintes pontos a ter em atenção, os quais são convenções do Rails e só devem ser modificados em caso de necessidade:

• Os nomes das tabelas têm de ser escritos no plural do nome da classe que lhe dá origem, excepto se for

uma tabela de ligação, a qual tem de ter como nome a concatenação, por ordem alfabética, dos nomes

das classes que liga com um underscore entre eles;

• Cada tabela tem como chave primária uma coluna id, que seja um inteiro automaticamente incrementado

aquando da criação de um novo objecto dessa mesma tabela, excepto se for uma tabela de ligação entre

duas ou mais tabelas;

• As chaves estrangeiras contêm o nome da tabela referenciada no singular concatenado com _id.

O Rails desta forma permite um acesso simplificado à BD eliminando a necessidade de escrita de código SQL na maioria dos casos, excepto quando se tratarem de acessos menos comuns. Por outro lado, embora à primeira vista possa também parecer um obstáculo, na realidade é uma forma de uniformizar a construção das BDs.

Outro ponto que necessita de ser mencionado é a forma como no Rails se trata preferencialmente os casos de herança, como no caso da classe User e da classe Instrument. O método utilizado foi esse mesmo, que é a herança numa única tabela, ou seja, o STI (Single Table Inheritance). Em ambos os casos utilizou-se uma coluna denominada type, a qual é também uma predefinição do Rails, e portanto a plataforma reconhece automaticamente que existe herança do tipo STI. O caso da classe User é o mais simples pois apesar de se distinguir o tipo de utilizador, não existem atributos diferentes. O segundo caso, a classe Instrument, contém diferenças entre os instrumentos que pode representar. A forma de se tratar isso foi colocando os mesmos atributos para todos os tipos de instrumento na mesma tabela. Contudo, através da aplicação só se permite atribuir valores ou não nesses mesmos atributos consoante o tipo de instrumento que seja. Quando um tipo de instrumento não possui um certo atributo atribui-se o valor null.

Todas as tabelas do esquema relacional da base de dados podem ser visualizadas nas tabelas que se seguem.

Tabela users

Atributos

id:bigserial, name:character varying(250), email:character varying(250), address:character varying, telephone:character varying(9), mobile:character varying(9), work_phone:character varying(9), institution:character varying(50), institution_address:character varying, password_hash:character(40), type:character varying(50), validated:boolean, created_on:timestamp with time zone, updated_on:timestamp with time zone, lock_version:integer

PKs id FKs N/A

Tabela 24 - Tabela users


72

Tabela works

Atributos

id:bigserial, name:character varying(250), description:character varying, creation_date:date, publishing_date:date, sections_count:integer, user_id:bigint, musical_genre_id:bigint, validated:boolean, created_on:timestamp with time zone, updated_on:timestamp with time zone, lock_version:integer

PKs id

FKs • user_id referenciando users .id (ON UPDATE CASCADE ON DELETE SET DEFAULT) • musical_genre_id referenciando musical_genres .id (ON UPDATE CASCADE ON DELETE

RESTRICT)

Tabela 25 - Tabela works

Tabela authors

Atributos id:bigserial, name:character varying(250), biography:character varying, birth_day:date, photo:bytea, photo_thumb:bytea, photo_content_type:character varying(100), user_id:bigint, validated:boolean, created_on:timestamp with time zone, updated_on:timestamp with time zone, lock_version:integer

PKs id FKs • user_id referenciando users .id (ON UPDATE CASCADE ON DELETE SET DEFAULT)

Tabela 26 - Tabela authors

Tabela authors_works

Atributos author_id:bigint, work_id:bigint, created_on:timestamp with time zone, updated_on:timestamp with time zone, lock_version:integer

PKs author_id, work_id

FKs • author_id referenciando authors .id (ON UPDATE CASCADE ON DELETE RESTRICT) • work_id referenciando works .id (ON UPDATE CASCADE ON DELETE CASCADE)

Tabela 27 - Tabela authors_works

Tabela musical_genres

Atributos id:bigserial, name:character varying(50), description:character varying(250), created_on:timestamp with time zone, updated_on:timestamp with time zone, lock_version:integer

PKs id FKs N/A

Tabela 28 - Tabela musical_genres

Tabela sections

Atributos id:bigserial, name:character varying(250), description:character varying, section_number:integer, scores_count:integer, work_id:bigint, validated:boolean, created_on:timestamp with time zone, updated_on:timestamp with time zone, lock_version:integer

PKs id FKs • work_id referenciando works .id (ON UPDATE CASCADE ON DELETE RESTRICT)

Tabela 29 - Tabela sections

Tabela scores

Atributos

id:bigserial, original_score:bytea, original_score_thumb:bytea, original_score_content_type:character varying(100), original_score_mime:character varying(4), digital_score:text, digital_score_content_type:character varying(100), page_number:integer, section_id:bigint, validated:boolean, created_on:timestamp with time zone, updated_on:timestamp with time zone, lock_version:integer

PKs id FKs • section_id referenciando sections .id (ON UPDATE CASCADE ON DELETE RESTRICT)

Tabela 30 - Tabela scores

Tabela instruments

Atributos

id:bigserial, name:character varying(250), description:character varying, photo:bytea, photo_thumb:bytea, photo_content_type:character varying(100), number_strings:integer, tuning:character varying(50), function:character varying(50), type:character varying(50), user_id:bigint, validated:boolean, created_on:timestamp with time zone, updated_on:timestamp with time zone, lock_version:integer

PKs id FKs • user_id referenciando users .id (ON UPDATE CASCADE ON DELETE SET DEFAULT)

Tabela 31 - Tabela instruments


73

Tabela instruments_sections

Atributos instrument_id:bigint, section_id:bigint, created_on:timestamp with time zone, updated_on:timestamp with time zone, lock_version:integer

PKs instrument_id, section_id

FKs • instrument_id referenciando instruments .id (ON UPDATE CASCADE ON DELETE RESTRICT) • section_id referenciando sectins .id (ON UPDATE CASCADE ON DELETE CASCADE)

Tabela 32 - Tabela instruments_sections

Tabela updates

Atributos id:bigserial, title_pt:character varying(100), title_en:character varying(100), description_pt:character varying, description_en:character varying, users_id:bigint, created_on:timestamp with time zone, updated_on:timestamp with time zone, lock_version:integer

PKs id FKs • users_id referenciando users .id (ON UPDATE CASCADE ON DELETE SET DEFAULT)

Tabela 33 - Tabela updates

Através da execução do script concebido para a criação da BD, é criado um utilizador no PostgreSQL, o omradmin, o qual será o dono dos objectos da BD. É também criado o Administrador da aplicação, cujo email por omissão é [email protected]. A senha de ambos por omissão é admin, podendo ser depois alterada através da aplicação web no caso do último. Em relação à role omradmin criada no PostgreSQL, terá de ser alterada no SGBD.

É também criado um Género Musical por omissão, por forma a existir sempre pelo menos um para se poder inserir pautas. Definiu-se com o nome “Outro”.

Existe uma última particularidade referente ao Rails necessária de se mencionar. O Rails na realidade utiliza três cópias da BD, cada uma usada num ambiente de execução diferente. Esta é uma vantagem importante porque permite executar o sistema em modo de desenvolvimento ou teste sem interferir com os dados reais. Ou seja, existem três ambientes de execução: production, development e test. Cada um desses ambientes utiliza a base de dados com o respectivo sufixo após o nome. Por outras palavras, são criadas três BDs idênticas: omrsys_production, omrsys_development e omrsys_test.

5.2.2 Aplicação Web

A aplicação web segue o modelo MVC, e como tal tem-se a aplicação dividida nas três camadas já mencionadas: model, view e controller. Nas subsecções seguintes detalha-se cada uma dessas camadas, dizendo como está organizada e os seus modelos de classes. A camada controller é descrita antes da camada view uma vez que é mais fácil explicar por essa ordem.

Uma aplicação em Rails, como é o caso, é criada com uma estrutura bem definida, que segue precisamente este modelo. No entanto existe uma parte associada ao view, os helpers, os quais servem para melhor separar a interface do código em Ruby. Podem-se criar métodos em helpers que depois podem ser usados nas vistas do view.

5.2.2.1 Model

Esta camada é a camada que acede aos dados na BD, e como tal no geral representa o conteúdo da BD, através do ActiveRecord do Rails. No entanto, por definição do Rails, contém ainda uma classe que não está relacionada com a BD. Essa classe é usada no envio de e-mails pela aplicação web, através do ActionMailer, e contém os métodos de envio das mensagens possíveis da aplicação enviar aos utilizadores.

Para toda a parte que se refere à BD, para além das validações dos dados que são inseridos antes de serem guardados na BD, existem ainda uma série de métodos em cada classe que são


74

necessários para realizar algumas tarefas a nível do model. Uma dessas tarefas encontra-se na classe User para realizar a autenticação dos utilizadores, assim como a geração de nova senha de acesso.

As validações são realizadas através de métodos próprios do Rails, como por exemplo validates_length_of, o qual valida o tamanho de uma string.

A pesquisa com a gem acts_as_ferret, que será explicada na secção 5.3, também se encontra definida a nível desta camada nas classes que sejam alvo de pesquisa, definindo também quais os campos que entram nessa pesquisa. São também definidos os métodos que realizam os vários tipos de pesquisa.

Na figura seguinte pode-se analisar o diagrama de classes desta camada, contendo os nomes dos vários métodos de cada classe, mas sem os parâmetros para simplificar o diagrama.

Figura 12 - Diagrama de classes do Model

Todo o código encontra-se documentado através do uso de RDoc, contendo as definições de todos os métodos e classes.

5.2.2.2 Controller

Nesta camada encontra-se toda a lógica da aplicação, ou seja, as classes e métodos que comunicam com o model para aceder e manipular os dados e também com o view para mostrar o output ao utilizador e receber o seu input. É também nesta camada que a aplicação comunica com a aplicação de OMR e com o editor, que nesta fase é simplesmente uma classe desta camada.

Nesta camada existe a classe ApplicationController, a qual contém filtros e métodos acessíveis por todas as outras classes do controller. É nesta classe que são definidos os métodos que controlam os acessos dos utilizadores da aplicação, assim como se faz a selecção do layout da aplicação consoante o tipo de utilizador por forma a apresentar o menu correcto.


75

Nesta mesma classe existem algumas constantes de configuração de dados na aplicação, tais como o nome do site e o endereço de e-mail.

A maior parte das classes aqui existentes vão de encontro com os módulos que se tinha definido, o que pode ser facilmente visto pelos seus nomes. No entanto, tal como a classe já descrita, existem várias outras com outras funções. Uma breve descrição de cada uma será feita de seguida.

A classe LocaleController e as suas descendentes, LocalePtController e LocaleEnController, são as classes de tratamento do idioma da aplicação, ou seja, a primeira contém um método que é chamado com uma tag e devolve a string correspondente no idioma actualmente guardado na variável de sessão. Esse método utiliza a classe correspondente ao idioma seleccionado. Esta parte está construída por forma a ser facilmente adicionada uma nova tradução, sendo apenas necessário criar uma nova classe igual às das traduções existentes, mas trocando os textos a que as tags correspondem pelos novos traduzidos. E tem de se adicionar a chamada a essa nova classe na LocaleController.

Uma outra classe, a ExpandingMenuController, tal como o nome indica faz o controlo do menu principal que é expansível através do uso de tecnologia Ajax incorporada no Rails.

Uma última classe que requer alguma explicação é a GenericController. Esta classe na realidade apenas tem uma função, que é a chamada às vistas das opções do menu inferior, através dos métodos contidos. Estas opções são genéricas e portanto apenas é mostrada a vista sem ser executado código adicional. Esta opções são necessárias de ser preenchidas por quem instalar a aplicação num servidor, uma vez que são informações próprias tais como os contactos. A única excepção é a ajuda, que poderá estar já preenchida, mas é também apenas HTML.

Em relação às classes referentes aos módulos dos casos de uso da aplicação, contêm os métodos referentes a cada caso de uso. Nas classes cujos nomes começam com Manage são disponibilizados métodos para listar, criar, editar e remover os objectos que essa classe gere. No caso das classes cujos nomes começam com Validation são disponibilizados métodos para listar, aceitar e cancelar os objectos dos quais fazem a validação. A classe SearchController permite realizar pesquisas e faz a listagem dos resultados de forma paginada. A AccountController disponibiliza métodos para realizar a autenticação com a camada model assim como métodos para fazer a gestão da própria conta de utilizador. Por último temos as classes de acesso ao módulo de OMR e a do editor de MusicXML. A primeira, OMRController, disponibiliza um método que chama a aplicação de OMR seleccionada e efectua o reconhecimento óptico da pauta em questão, guardando os resultados na BD, página a página. A classe EditorController disponibiliza métodos para visualizar as pautas e editá-las, assim como a informação associada. Por esta altura do projecto o editor é directamente em texto, no entanto a edição é feita lado a lado com a pauta original e página a página.

Em Rails os métodos que estas classes contêm são denominados de actions e em grande parte estão associados a vistas na camada view.

Na figura seguinte pode-se analisar o diagrama de classes desta camada, contendo os nomes dos vários métodos de cada classe, mas sem os parâmetros para simplificar o diagrama.


76

Figura 13 - Diagrama de classes do Controller

Todo o código encontra-se documentado através do uso de RDoc, contendo lá as definições de todos os métodos e classes.

5.2.2.3 View

Esta camada está na sua maioria organizada de acordo com o controller. No entanto não se tratam de classes como nas outras duas camadas. Como se trata de uma interface web o Rails utiliza um tipo de ficheiro, para cada vista, que contém HTML com código Ruby embutido assim como métodos de Ruby que geram HTML, que são ficheiros .rhtml. Dessa forma a estruturação é feita por pastas e ficheiros em que cada pasta corresponde a um controller (com


77

duas excepções já explicadas de seguida), e no interior de cada pasta encontra-se um ficheiro .rhtml para cada action que tem vista associada. Por exemplo, para o método list da classe ManageUserController existe a pasta manage_users e lá dentro o ficheiro list.rhtml contendo a vista para essa action. No entanto, para além desses ficheiros existem ainda outros que começam com um underscore, chamados de parcials. Esses últimos não contêm uma vista completa mas sim uma parte apenas e podem ser usados noutras vistas. Os parcials que podem ser usados em vistas fora da própria pasta são colocados numa pasta shared, e no caso desta aplicação essa pasta contém os parcials do menu expansivo.

As duas excepções mencionadas são a pasta de layouts e a pasta de vistas do envio de e-mails, ou seja, do ActionMailer. Neste último caso em vez de a associação ser ao controller é ao model. A pasta de layouts contém o layout da aplicação web, existindo um layout para cada tipo de utilizador com vista a disponibilizar as opções correctas para cada um. No que respeita à pasta advise_mailer associada à classe AdviseMailer do model, contém os templates dos e-mails que a aplicação pode enviar.

Do view fazem ainda parte também os helpers, localizados nessa mesma pasta. Tratam-se de classes especiais nas quais se pode criar métodos para utilizar nas vistas por forma a separar melhor o código Ruby do código HTML. No entanto faz parte desta camada e tal como nome indica servem para ajudar a interface, sem misturar o código demasiado. Nesta aplicação foram usados alguns helpers, sendo os principais os que se encontram no ApplicationHelper, que é o helper cujos métodos ficam disponíveis para todas as vistas. Um desses métodos é o método que devolve as strings de texto consoante o idioma, o outro é o método que define as strings do contexto. Foi feito ainda o override do método do Rails de tratamento de erros, devido à utilização de um idioma diferente na interface.

Na figura seguinte pode-se analisar o diagrama de classes de helpers desta camada, contendo os nomes dos vários métodos de cada classe, mas sem os parâmetros para simplificar o diagrama.

Figura 14 - Diagrama de classes dos helpers do View

Todo o código encontra-se documentado através do uso de RDoc, contendo lá as definições de todos os métodos e classes.

5.3 Plugins e Gems

Por forma a não se “reinventar a roda” como foi já falado no presente documento, utilizaram-se plugins e gems específicos para algumas tarefas. Um plugin é adicionado directamente na pasta do projecto, na pasta vendor/plugins/, enquanto que uma gem é um pacote de Ruby que ao ser instalado fica disponível para qualquer aplicação que o use.


78

Durante a implementação da aplicação web houve a necessidade de recorrer a um plugin e três gems para além dos que o Rails contém por omissão:

• acts_as_ferret 0.4.0 – Gem utilizada nas pesquisas, é um motor de pesquisa que suporta wildcards

inclusive. Cada classe no model incluída na pesquisa contém uma definição própria no início do código,

a qual indica os campos a pesquisar e os seus pesos. Incluem também um método da realização da

pesquisa propriamente dita;

• RMagick 1.14.1 binary gem for Ruby 1.8.5 – Esta gem foi necessária para efectuar a manipulação das

imagens por forma a gerar os thumbnails que são armazenados com as imagens em tamanho real;

• validates_multiparameter_assignments 1.0 – Este plugin foi necessário devido a uma falha do Rails que

se prende com o método de selecção de datas, que permite seleccionar datas inválidas. Com este plugin

sempre que se selecciona uma data inválida o erro é tratado e portanto o formulário é mostrado de novo

indicando esse erro, tal como nos outros casos;

• rubyzip 0.9.1 – O rubyzip foi necessário para se poder gerar arquivos zip contendo as páginas das

pautas, para permitir ao utilizador vários tipo de download.

5.4 Estruturação do Código

O código da aplicação web segue a estrutura geral de uma aplicação feita em Rails. A aplicação fica organizada através de uma estrutura de ficheiros e pastas bem definida da seguinte forma:

CHANGELOG app/ db/ log/ test/

README components/ doc/ public/ vendor/

Rakefile config/ lib/ script/

No entanto, o acts_as_ferret, apresentado na secção anterior, cria um nova pasta de nome index onde são indexadas as pesquisas efectuadas.

O código desenvolvido encontra-se na pasta app a qual por sua vez é composta pelas pastas controllers, helpers, models e views. Todas elas foram já apresentadas na secção 5.2.2. No entanto há ainda outras pastas das quais é necessário falar.

A configuração da aplicação e do ambiente de execução é realizada na pasta config. É nessa pasta que se define a configuração do acesso à BD no ficheiro database.yml. Também é nesta pasta que se configuram os envios de e-mail por parte da aplicação, no ficheiro environment.rb.

Em public/images/ localizam-se todas as imagens usadas pela aplicação (excepto as dos objectos da BD) e em public/stylesheets/ encontra-se o código CSS de definição dos estilos usados. Ainda na pasta public, temos a pasta javascripts que contém não só as funções que o próprio Rails cria na criação do projecto mas também algumas funções criadas para a aplicação. Por último, na pasta vendor está incluída a aplicação de omr para além do plugin já mencionado na secção anterior.

Após esta análise sobre a estrutura da pasta da aplicação web serão analisados alguns tópicos relativos ao código e decisões de desenho.

O suporte de mais de um idioma, já mencionado, é feito através de tags cuja definição se encontra nas classes Locale. O formato das tags devido a múltiplos contextos diferentes não é totalmente uniforme, no entanto tentou-se criá-las com lógica e fácil de entender onde


79

pertencem. Geralmente começam pelo nome do controller em que se insere, seguindo-se o nome do atributo entre outros, consoante o caso.

O contexto apresentado na interface é definido através de um método helper bastante extenso, por forma a cobrir todos os casos possíveis. Como há várias partes da aplicação às quais se pode chegar vindo de um contexto diferente, os casos possíveis são muitos. Nesse método através de uma análise dos parâmetros do browser e dos do método, através de uma sucessão de condições do tipo case constrói-se um array que no final contém três strings de contexto. São as strings do título da janela, o título de onde se está e a sucessão de ligações desde o início até ao local onde se está com os passos intermédios para se poder recuar. Por exemplo “Início > Pautas Musicais”, em que cada parte do contexto contém uma ligação para o utilizador lhe aceder.

Todo o código encontra-se documentado com RDoc, o qual permite gerar documentação navegável num browser em HTML através do código mais os comentários e descrições existentes, tendo sido totalmente documentado.

5.5 Diagrama de Componentes

No diagrama de componentes pode-se verificar a organização do sistema em termos de camadas “físicas”, ou seja, máquinas e componentes clientes e servidores. Pretende documentar a estrutura física de alto nível do sistema de software, no que respeita a máquinas, conexões, componentes de software instalados nas máquinas e dependências entre componentes.

Em relação ao local onde a base de dados e o restante sistema ficam alojados optou-se por colocá-los no mesmo servidor, pois desta forma o acesso é directo, permitindo à partida um melhor desempenho. O componente da Aplicação de OMR na realidade pode conter várias como foi já mencionado no presente documento. No entanto, por simplicidade, apenas um está representado no diagrama.


80

Figura 15 – Diagrama de Componentes da Arquitectura Física

5.6 Interface Gráfica

A descrição exaustiva da interface gráfica seria demasiado extensa e de interesse reduzido. Por esse motivo, nesta secção tentou-se apresentar e explicar exemplos que melhor demonstrem a generalidade do funcionamento e visual da aplicação, assim como os casos particulares mais importantes. Será usado um Utilizador Privilegiado a título de exemplo. Todas as imagens de fundo da aplicação foram concebidas durante o estágio.

O primeiro exemplo apresenta a autenticação do Utilizador Privilegiado. Quando um Utilizador Privilegiado ou o Administrador se autenticam aparece uma mensagem a dizer que há objectos por validar, se for esse o caso. Na Figura 16 um Utilizador Privilegiado acabou de se autenticar e existem objectos por validar. O ecrã inicial da aplicação web mostra as actualizações/notícias. No entanto, quando se trata de um Utilizador Privilegiado ou o Administrador existem botões de edição e remoção, assim como a informação de quem criou cada uma.


81

Figura 16 - Ecrã inicial após autenticação com um Utilizador Privilegiado

Figura 17 - Visualização dos dados de utilizador

Ainda relacionado com o utilizador que se autenticou, temos de seguida a visualização dos seus dados de utilizador. Por baixo dos dados temos ligações para listar os seus objectos


82

próprios no sistema, assim como a possibilidade de editar os dados e cancelar a conta. Podemos também observar a opção do menu expandida, com as suas várias opções. Esta situação encontra-se ilustrada na Figura 17.

O próximo exemplo passa pela validação de utilizadores, na qual se pode verificar como são feitas as listagens de uma forma genérica por toda a aplicação, exceptuando-se as notícias e as pesquisas totais. Sempre que se tiver um botão com uma lupa significa que se pode visualizar o objecto. Este exemplo pode ser consultado na Figura 18.

Figura 18 - Validação de utilizadores

De seguida apresenta-se a listagem de pautas musicais, na qual se pode efectuar o download por entre várias opções para o fazer. Para qualquer tipo de download que se escolha, o resultado será devolvido num ficheiro de compressão zip. Nesta listagem, assim como acontece noutras, tem-se a opção de listar somente os objectos próprios, assim como também a possibilidade de listar só as pautas cujo nome comece por uma letra que se indique em cima. Este exemplo pode ser consultado na Figura 19.

De seguida será mostrada a submissão de pautas, um exemplo fundamental do protótipo implementado. No entanto, como consiste em vários passos o layout será eliminado das imagens por forma a ocupar menos espaço. A submissão segue o diagrama de actividades mostrado na secção 4.7, seguindo uma sucessão de formulários até efectuar o reconhecimento e no final ser mostrado o resultado e dada a possibilidade de o editar, confirmando no final a submissão. Durante a criação das secções e da submissão de páginas de pauta, ambos são realizados através de um método de criação de anexos. Envia-se por exemplo uma página e volta ao mesmo formulário, até se carregar para continuar, e são listadas as que já existem, podendo-se alterar a ordem ou removê-las. Nas imagens mostradas, devido aos formulários


83

passarem o tamanho dos conteúdos, o que se pode ver pela barra de scroll, não se vêem na totalidade. É favor consultar as figuras desde a Figura 20 à Figura 26.

Figura 19 - Listagem de pautas musicais

Figura 20 - Submissão de pautas - Passo 1


84






85

Figura 25 - Submissão de pautas - Passo 6 (editor, onde se pode concluir a submissão)

Figura 26 - Submissão de pautas - Passo 6 (edição de uma página)

Por último é apresentada a pesquisa total, realizada por entre todos os objectos do sistema. No entanto, a pesquisa só inclui os utilizadores do sistema se for o Administrador a realizá-la. Esse cenário pode ser consultado na Figura 27.


86

Figura 27 - Pesquisa total


87

6 Conclusões e Perspectivas de Trabalho Futuro

Neste último capítulo são apresentadas algumas alusões aos capítulos anteriores e suas principais conclusões, assim como as conclusões finais sobre o projecto e o trabalho realizado durante o estágio. Serão também feitas algumas considerações pessoais e sobre como o trabalho decorreu.

6.1 Avaliação do Trabalho Desenvolvido

O trabalho desenvolvido no estágio deu início ao projecto complexo no qual se insere, para a criação de um sistema completo de OMR de pautas musicais manuscritas. O estágio incidiu no estudo e especificação de todo o sistema, e na implementação de uma aplicação web que serve de interface ao mesmo.

Este estágio pode ser dividido em duas grandes fases:

• Análise do problema, estado da arte e tecnologias a usar, assim como especificação de requisitos;

• Aprendizagem das tecnologias escolhidas e implementação da solução proposta.

Para a primeira grande fase foi elaborado um documento – Relatório Preliminar do Plano de Trabalhos – o qual pretendeu cobrir todo o estudo realizado, assim como toda a especificação do sistema. Na segunda grande fase, após se ter escolhido as tecnologias que iriam ser utilizadas, realizou-se inicialmente um processo de aprendizagem das mesmas, por via autodidacta com a utilização de livros e fóruns oficiais das mesmas. Após isso começou-se por desenvolver a base de dados e depois foi então realizada a implementação da aplicação web OMRSYS. No final, com base no Relatório Preliminar do Plano de Trabalhos e o trabalho desenvolvido, elaborou-se o presente documento.

Como este projecto foi iniciado no presente estágio o seu estudo e especificação de requisitos ocuparam uma grande parte do tempo útil do estágio, havendo inicialmente apenas o documento de candidatura a um projecto da FCT. Por outro lado, esse tempo deve-se ao estudo ter sido para todo o sistema e não apenas o que seria de facto implementado neste estágio. Contudo, com o tempo restante foi possível aprender a utilizar as tecnologias e desenvolver uma solução completa, funcional e demonstrável. Embora susceptível de sofrer muitas melhorias no seu desempenho e funcionamento, e algumas partes terão de ser estudadas e desenvolvidas em novas fases do projecto. Pode-se dizer, portanto, que durante o estágio se concluiu com sucesso a criação do sistema, tendo-se implementado o que era mais prioritário por forma a se ter um sistema completo e assim de futuro se poder construir as restantes partes sobre ele. Assim ter-se-á sempre um sistema demonstrável e usável.

As tecnologias que foram utilizadas revelaram-se adequadas à solução proposta, e permitem ainda realizar um melhoramento significativo numa próxima fase uma vez que dispõe de um grande leque de facilidades. Estas facilidades passam pela existência abundante de plugins, os quais devido à sua enorme quantidade e complexidade não foram possíveis de estudar durante os seis meses de estágio. No entanto, serão certamente uma mais valia no melhoramento do sistema desenvolvido.

O modelo MVC adoptado na divisão da aplicação em camadas distintas com funcionalidades bem definidas foi crucial para se realizar um melhor desenvolvimento do sistema, onde a detecção e correcção de erros foram mais facilmente realizados. Devido a isso mesmo, a


88

plataforma Ruby on Rails foi uma escolha importante uma vez que funciona precisamente com base nesse modelo.

Numa análise do ponto de vista do projecto por completo, podemos concluir que:

• As tecnologias de OMR de hoje em dia ainda contêm muitas lacunas, havendo ainda muita investigação

e desenvolvimento a realizar neste campo;

• Começam a surgir soluções livres e opensource para efectuar o reconhecimento de pautas e edição de

pautas em MusicXML;

• Uma solução como a apresentada é única em vários aspectos:

o Não dá atenção apenas ao reconhecimento óptico, mas sim a uma solução completa com vários fins;

o Preenche a lacuna do reconhecimento óptico de pautas manuscritas em notação standard, sendo dedicado a este

caso em particular, ao contrário de outros projectos;

o Disponibiliza um sistema de OMR completo e livre, disponível online, contendo de uma forma integrada todas

as soluções necessárias para efectuar o reconhecimento das partituras;

o Guarda as pautas digitalizadas em MusicXML, um formato recente em expansão;

o Permite a construção de todo um corpus, a sua preservação e estudo, e também a sua manipulação permitindo a

extracção de partes, entre outros.

• Desta forma consegue-se preservar esta parte da nossa herança musical recente, podendo finalmente

trazer a dignidade merecida a estas obras, publicando-as e permitindo o seu estudo, mantendo um

arquivo de todo o corpus.

Desta forma, o trabalho desenvolvido durante o estágio cumpriu todos os objectivos a que se propunha nesta fase inicial do projecto em que se insere.

Durante este estágio, como foi já mencionado no primeiro capítulo, foi elaborado um artigo acerca da detecção das linhas de pauta, no qual se apresenta um novo algoritmo estudado em paralelo com este estágio por outros colaboradores. Nesse artigo comparou-se esse algoritmo com um outro conhecido, do autor Ichiro Fuginaga. O artigo foi já aceite para publicação na International Conference on Automated Production of Cross Media Content for Multi-channel Distribution (AxMedis 2007).

Na conclusão deste estágio será ainda escrito um novo artigo, de maior importância para este estágio, uma vez que será com o intuito de publicar o sistema estudado e desenvolvido. O artigo será submetido para publicação na IASTED International Conference EuroIMSA 2008.

Por último, após todos os pontos enunciados, podemos concluir que o trabalho se está a revelar com sucesso para a sua área de estudo e investigação. Desta forma foi já dado um contributo considerável com este projecto, que ainda terá um longo percurso pela frente.

6.2 Perspectivas Futuras

Como foi já referido durante este documento, este sistema consiste em vários módulos por si de complexidade considerável, e portanto a implementação teve como objectivo criar um protótipo completo e demonstrável. Dessa forma a implementação centrou-se na base de dados e respectiva aplicação web, utilizando um módulo de OMR existente, criando um motor de pesquisa ainda sem considerar a metadata contida nas pautas em MusicXML e permitindo ver e editar as pautas em MusicXML directamente no seu código em texto pleno. A pesquisa


89

mencionada não foi implementada de raiz, tendo-se usado para o efeito um plugin, o acts_as_ferret, da plataforma utilizada.

Este é um projecto com várias áreas de estudo, investigação e desenvolvimento, e como tal as perspectivas de trabalho futuro abrangem diversas áreas. Podemos separar as perspectivas de trabalho futuro em duas partes distintas. Por um lado temos a continuação da aplicação web e da base de dados, com vista a melhorar ambas, os seus desempenhos e eventualmente completá-las. Por outro lado temos as áreas que não foram directamente objecto de estudo neste trabalho.

Uma das restantes partes do projecto prende-se com as técnicas, algoritmos e métodos de reconhecimento óptico das pautas manuscritas, com vista a melhorar o módulo de OMR. O objectivo é conseguir converter as pautas musicais manuscritas de forma fiável e eficaz, atingindo a qualidade necessária e desejável para os objectivos do projecto. Outra parte com trabalho futuro é o editor de MusicXML embutido na aplicação web, que será convertido num editor real ao invés da edição textual desta fase inicial do projecto. Temos ainda o motor de pesquisa avançado, que será completado para permitir de futuro utilizar a metadata contida nas partituras em formato digital.

Para além do que foi mencionado, devido ao tempo reduzido do estágio, embora se tenha realizado uma implementação em que cada nova funcionalidade foi sempre testada, não foi possível realizar testes exaustivos. Por esse motivo, de futuro será também necessário efectuar testes mais exaustivos e a completa validação das diversas funcionalidades do sistema. Dessa forma será possível encontrar e corrigir eventuais falhas na implementação e confirmar o cumprimento de todos os requisitos do sistema.

6.3 Considerações Pessoais

Em primeiro lugar gostava de afirmar que a realização do presente estágio, com a duração de seis meses, foi uma experiência não só muito gratificante como também de elevada importância, quer a nível pessoal como a nível profissional. Foi uma oportunidade única de conhecer o “mundo real” da engenharia informática.

Com este estágio tive a excelente oportunidade de trabalhar na Unidade de Telecomunicações e Multimédia do INESC Porto, que é uma unidade que desenvolve e realiza investigação em diversas áreas de elevado interesse, tal como foi indicado no capítulo introdutório deste documento. Gostaria de destacar o bom ambiente de equipa e camaradagem vivido nesta unidade, havendo apoio e entreajuda entre os vários colaboradores, ambiente no qual fui bem recebido.

Graças a ter estagiado nesta instituição tive o privilégio de melhorar significativamente os meus conhecimentos na área de concepção e desenvolvimento de sistemas de informação. A utilização da plataforma Ruby on Rails, que é bastante recente e tem suscitado um interesse crescente por toda a comunidade, foi uma mais valia conseguida na realização deste estágio. Mais valia essa que seguramente terá os seus frutos de futuro.

No entanto, a aprendizagem das tecnologias utilizadas teve de ser autodidacta, embora tenha tido sempre a disponibilidade de ajuda por parte dos colaboradores da unidade e o apoio indispensável do meu orientador no INESC Porto. Contudo, devido à aprendizagem e adaptação necessária às tecnologias, a implementação demorou um bocado mais do que aconteceria no caso de ser realizada por alguém já experiente, principalmente no início. As


90

maiores dificuldades que senti foram principalmente devidas a esse facto, ter de tomar várias decisões com as quais fui confrontado a primeira vez (escolha das tecnologias a usar) e também o estudo e implementação terem sido realizados somente por uma pessoa (excepto a adaptação do módulo de OMR usado, a cargo do orientador na instituição). Devido a isso mesmo, na parte final dos seis meses de estágio o meu desgaste foi bastante notório, pois foi um período de trabalho bastante intenso a vários níveis. Algo com o qual fiquei mais consciente foi a importância de não deixar acumular partes do trabalho, e prever melhor o tempo necessário para a realização das várias tarefas. Como foi a primeira vez que tive esta experiência geralmente demorava mais tempo do que previa. Contudo, posso dizer que o estágio foi positivo e culminou em sucesso.


91

Referências e Bibliografia

• Documento de Candidatura do Projecto à FCT

• Dave Thomas, Programming Ruby – The Pragmatic Programmers’ Guide (2nd edition), 2005

• Dave Thomas, Agile Web Development with Rails – A Pragmatic Guide, 2005

• Chad Fowler, Rails Recipes, 2006

• John McCreesh, Four Days on Rails, 2005

• The PostgreSQL Global Development Group, PostgreSQL 8.2.0 Documentation, 2006

• João Pascoal Faria, Material de Apoio de UML da cadeira de Engenharia de Software do MIEIC na

FEUP, 2001

• Manual de Acolhimento do INESC Porto, 2007

Ligações Principais

• INESC Porto – http://www.inescporto.pt

• FEUP – http://www.fe.up.pt

• UP – http://www.up.pt

• Ichiro Fuginaga – http://www.music.mcgill.ca/~ich

• Donald Byrd – http://www.informatics.indiana.edu/donbyrd

• David Brainbridge – http://www.cs.waikato.ac.nz/~davidb

• Leeds OMR – http://www.leeds.ac.uk/music/omr

• ROMA – http://alfa.ist.utl.pt/~mpinto/roma

• OMR using Gamera – http://dkc.jhu.edu/gamera/demo

• Ruby on Rails – http://www.rubyonrails.org

• Rails Forum – http://railsforum.com

• PostgreSQL – http://www.postgresql.org

• Apache – http://httpd.apache.org

• Mongrel – http://mongrel.rubyforge.org

• MusicXML – http://www.musicxml.org

• OpenOMR – http://sourceforge.net/projects/openomr

• UML – http://www.uml.org


92

ANEXO A: Acrónimos Utilizados

AIFF – Audio Interchange File Format

API – Application Programming Interface

AWE – Address Windowing Extensions

BD – Base de Dados

CVS – Concurrent Versions System

DCG – Definite Clause Grammar

DRM – Digital Rights Management

DRY – Don’t Repeat Yourself

DTD – Document Type Definition

DTS – Database Transformation Services

FAQ – Frequently Asked Questions

FCT – Fundação para a Ciência e Tecnologia

FCUP - Faculdade de Ciências da Universidade do Porto

FEUP – Faculdade de Engenharia da Universidade do Porto

FK – Foreign Key

HTML – HyperText Markup Language

HTTP – Hypertext Transfer Protocol

IDE – Integrated Development Environment

I&D – Investigação e Desenvolvimento

INESC Porto – Instituto de Engenharia de Sistemas e Computadores do Porto

IPP - Instituto Politécnico do Porto

JAI – Java Advanced Imaging

KDE – K Desktop Environment

LAG - Linear Adjacent Graphs

MIDI – Musical Instrument Digital Interface

MIEIC – Mestrado Integrado em Engenharia Informática e Computação

MusicXML – Music Extended Markup Language

MVC – Model-View-Controller

MX – Formato de representação de dados que sincroniza várias camadas de representação de uma peça de música

NIFF – Notation Interchange File Format

OCR – Optical Character Recognition


93

OLAP – On Line Analytical Processing

OMR – Optical Music Recognition

OMRSYS – OMR System

PC – Personal Computer

PDF – Portable Document Format

PK – Primary Key

PS – PostScript

Qt – Qt Toolkit, é um widget toolkit gráfico cross-platform para o desenvolvimento de programas gráficos

RIFF – Resource Interchange File Format

ROMA – Projecto de OMR de notação arcaica

RPC – Remote Procedure Call

SGBD – Sistema de Gestão de Bases de Dados

SQL – Structured Query Language

SARPMM – Sistema automático de reconhecimento de pautas musicais manuscritas

STI – Single Table Inheritance

TV – Televisão

UML – Unified Modeling Language

UP – Universidade do Porto

URL – Uniform Resource Locator

UTM – Unidade de Telecomunicações e Multimédia

WAV – Formato de dados áudio

XML – Extended Markup Language


94

ANEXO B: Diagramas de Casos de Utilização

Neste anexo são detalhados todos os pacotes de casos de utilização do sistema, através dos seus respectivos diagramas de casos de utilização. Alguns desses diagramas contêm casos de utilização mais complexos - com a descrição Extension points - que representam funcionalidades pertencentes a outros pacotes. Ou seja, são uma espécie de apontadores para outro caso de utilização existente num outro pacote. Tanto o caso de utilização como o pacote onde se encontra são especificados nesse mesmo caso de uso mais complexo.


95


96


97


98

Relatorio de estagio - INESC · PDF fileSistema automático de reconhecimento de pautas...

Documents

Transcript of Relatorio de estagio - INESC · PDF fileSistema automático de reconhecimento de pautas...