Vivemos tempos difíceis com restrições a todos os níveis e com o tempo super acelerado. Neste contexto, ser-se competitivo é cada vez difícil e exigente.

Quando se pensa no mercado de desenvolvimento de software é cada vez mais difícil descobrir nichos de mercado ainda virgens. No entanto, é sempre possível descobrir nichos de necessidades específicas: muitas vezes as instituições adquirem grandes soluções que estão concebidas para o grande mercado genérico e que descuram as necessidades mais específicas. Ora, se rapidamente fosse possível desenvolver um componente que interoperasse com a grande aplicação e que resolvesse aquelas necessidades específicas poderiam sair daqui alguns pequenos produtos com uma economia de escala associada.

É neste contexto microaplicacional que se vem propôr este projeto.

Para tal fixou-se um tema (estando no entanto os alunos livres de contrapôr outros se o entenderem) que resultou de algumas conversas e vivências de um dos docentes: uma escola de música. Já existem várias aplicações para a gestão de escolas mas nenhuma resolve bem as especificidades de uma escola de música. Assim, depois de uma reunião com a direção de uma escola de música identificaram-se algumas necessidades específicas que poderão ser solucionadas por microaplicações: um gestor de audições/concertos e um gestor de programas específicos.

Praticamente nenhuma das aplicações existentes para gerir escolas tem a funcionalidade de gerir audições ou concertos. Esta é uma necessidade específica de uma escola de música que ao longo de um ano letivo poderá ter que organizar dezenas ou centenas de audições e concertos.

O gestor de audições deverá ter as funcionalidades básicas de um sistema de informação:

Criar:

cria uma audição a partir de informação fornecida pelo utilizador;

Alterar:

permite alterar a informação associada a uma audição desde que esta ainda não tenha ocorrido;

Consultar:

permite consultar toda a informação relativa a uma audição;

Listar:

permite listar todas as audições armazenadas, distinguindo as que ocorreram das que ainda irão ocorrer e paginando quando o número de audições for elevado.

A estas funcionalidades básicas acrescem as seguintes relativas à interoperabilidade e disseminação de informação:

Importar alunos:

importar a informação dos alunos a partir de um ficheiro externo (CSV ou XML);

Importar professores:

importar a informação dos professores a partir de um ficheiro externo (CSV ou XML);

Importar audições:

Deverá ser possível fazer, a qualquer momento, uma importação de uma audição, para tal deverá ser definida uma linguagem/modelo para este formato.

Exportar audições:

Deverá ser possível fazer, a qualquer momento, uma exportação de uma audição, para tal deverá ser definida uma linguagem/modelo para este formato.

Gerar página Web:

gerar uma página web para a audição com design apelativo;

Gerar PDF:

gerar um documento PDF com o programa da audição (usando XSL-FO);

Redes sociais:

gerar o anúncio do evento nalgumas redes sociais (para já o facebook).

Primeiro há que especificar o modelo de dados de uma audição.

Uma audição é composta por:

• um conjunto de metadados: título, subtítulo, tema associado, data e hora, local, organizador/responsável, duração máxima;
• uma lista de atuações;
• cada atuação é realizada por um ou mais alunos que pode ser acompanhado ou dirigido por um ou mais professores e é composta por uma lista de peças a executar (no caso da atuação ser em grupo, este recebe uma designação tipo "orquestra de sopros" ou "grupo de música de câmara Opus32");
• cada peça é composta pelo título da peça, compositor e data (nascimento e morte, opcional) e duração aproximada.

Do exposto, pode-se concluir que apesar de simples este componente terá de suportar a gestão de alguns subsistemas de informação: gestão de peças, gestão de alunos (já implícita em cima), gestão de professores e gestão de audições.

Comece por especificar o modelo para o problema.

Nesta secção propõe-se um conjunto de campos de informação base para cada entidade. É apenas uma ajuda, poderá acrescentar ou retirar os campos que entender. Esta descrição é feita em bruto, poderá ter que trabalhar a nível da normalização dos dados.

A audição já foi descrita acima vamos descrever um pouco as outras entidades.

Aluno

Um aluno pode ser constituído por:

• código/identificador único;
• nome;
• data de nascimento;
• curso em que está matriculado;
• ano do curso que frequenta;
• instrumento que toca;
• opcionalmente, lista de grupos em que participa (orquestras, grupos de música de câmara);
• lista de professores com quem tem aulas (aula individual de instrumento, aulas de grupo nas orquestras, ...);

Curso/Aula

Um curso pode ser constituído por:

• código/identificador único;
• designação;
• lista de professores que lecionam nesse curso;
• lista de alunos matriculados nesse curso;
• exemplos:
  • Curso individual de percussão;
  • Curso individual de trombone;
  • Curso livre de violino;
  • Orquestra académica;
  • Ensemble de acordeões;

Professor

Um professor pode ser constituído por:

• código/identificador único;
• nome;
• data de nascimento;
• habilitação académica (que nível de formação tem e em quê);
• lista de cursos/aulas que leciona: cursos individuais de instrumento, e cursos de agrupamentos;

Obra musical

Uma obra pode ser constituída por:

• código/identificador único;
• nome/designação;
• compositor ou quem fez o arranjo;
• data aproximada da sua criação (se não existir deve ser usado o intervalo de datas associado ao compositor);
• período histórico (opcional): Medieval, Renascimento, Barroco, Clássico, Contemporâneo, Moderno.
• duração aproximada;
• lista de instrumentos para os quais há partituras.

Compositor

Um compositor pode ser constituído por:

• código/identificador único;
• nome,
• ano de nascimento;
• ano de óbito;
• período histórico (opcional) a que se encontra associado: Medieval, Renascimento, Barroco, Clássico, Contemporâneo, Moderno.
• breve descrição biográfica
• lista de obras que compôs registadas neste sistema de informação.

Em projetos semelhantes, a existência de datasets é muito importante podendo ser até determinante para o sucesso do projeto. Nesse sentido, a última aula foi dedicada à geração de datasets.

O objetivo foi criar datasets que se aproximassem da realidade mas que não usassem dados pessoais reais. Assim, fez-se uma colheita a várias fontes de dados, desde pautas de avaliação do curso até à DBpedia. Usaram-se esses dados, aos quais se adicionaram alguns processos aleatórios de geração de datas e de combinação de hipóteses para se obter um conjunto final de informação interessante e com o qual podem desenvolver e testar o projeto.

Colocaram-se online os datasets obtidos pelo aluno Tiago Conceição, que após a aula ainda os trabalhou mais acrescentando mais informação relevante para o projeto. O Tiago disponibilizou para todos, os datasets iniciais, as scripts de transformação e os datasets finais. Aproveitem, alterem a gosto e façam avançar os vossos projetos.