Você está na página 1de 109

UNIVERSIDADE DO ESTADO DE SANTA CATARINA

BACHARELADO EM CINCIA DA COMPUTAO

ANLISE E PROJETO DE UM SOFTWARE


SEQENCIADOR MIDI

Trabalho de concluso de curso submetido Universidade do Estado de Santa


Catarina como parte dos requisitos para a obteno do grau de Bacharel em
Cincia da Computao.

Joinville SC
2006

UNIVERSIDADE DO ESTADO DE SANTA CATARINA


BACHARELADO EM CINCIA DA COMPUTAO

Tadeu Rodrigo Becker Gois

ANLISE E PROJETO DE UM SOFTWARE


SEQENCIADOR MIDI

Trabalho de concluso de curso submetido Universidade do Estado de Santa


Catarina como parte dos requisitos para a obteno do grau de Bacharel em
Cincia da Computao.

verlin Fighera Costa Marques

Joinville, Dezembro de 2006.

ANLISE E PROJETO DE UM SOFTWARE


SEQENCIADOR MIDI

Tadeu Rodrigo Becker Gois

Este Trabalho de Concluso de Curso foi julgado adequado para a obteno do


ttulo de Bacharel em Cincia da Computao e aprovada em sua forma final pelo
Curso de Cincia da Computao do CCT/UDESC.

Banca Examinadora

_______________________________
verlin Fighera Costa Marques, M Sc.

________________________________
Dbora Cabral Nazario, M Sc.

________________________________
Isabela Gasparini, M Sc.

________________________________
Salvador Antonio dos Santos, M Sc.

RESUMO

Este trabalho descreve a anlise e projeto de um novo software seqenciador MIDI


que trabalhe com a informao musical codificada para pesquisa. Todo o projeto
documentado seguindo a metodologia de desenvolvimento de software do RUP,
abordando as suas fases iniciais. Em cada documento apresentada uma breve
descrio de como obt-lo de acordo com a metodologia abordada. Alm disso, este
trabalho tambm apresenta um breve estudo de teoria musical, padro MIDI e das
principais caractersticas de um software seqenciador MIDI.

Palavras-chave: Seqenciador MIDI, Anlise e Projeto de Sistemas, Engenharia de


Software.

II

ABSTRACT

This monograph describes the analysis and project of new MIDI Sequencer Software
that works with music information codify to search. All the project documented
following the RUP software development methodology, approaching his initials
phases. At each document is showed a short description of how to get it with the
methodology. Besides, this monograph also presents a brief of music theory, MIDI
standard and the mainly features of MIDI sequencer software.
Key-words: MIDI Sequencer, Analysis and Project of Systems, Software
Engineering.

III

LISTA DE FIGURAS
Figura 2.1 Pauta Musical.......................................................................................11
Figura 3.6a Conexo MIDI instrumento-instrumento (RATTON, 1997b). ..............22
Figura 3.6b Conexo MIDI instrumento-computador (RATTON, 1997b)...............23
Figura 4.3.1a Notation View, Winjammer (SEQUENCER, 2006) ..........................28
Figura 4.3.1b Notation View com um evento selecionado (SEQUENCER, 2006).29
Figura 4.3.2 Mixer Winjammer, (SEQUENCER, 2006).........................................29
Figura 4.3.3 Song View, Winjammer (SEQUENCER, 2006) ................................30
Figura 4.3.4 Piando Roll (Sonnar, Cakewalk)........................................................30
Figura 4.3.5 Track View , Winjammer (SEQUENCER, 2006)................................31
Figura 4.3.6 Event View (Sonnar, Cakewalk) ........................................................32
Figura 4.3.7 Controller View, Winjammer (SEQUENCER, 2006) ..........................32
Figura 4.4.1a Notas tocadas (PINTO, 2000) .........................................................33
Figura 4.4.1b Notas no Event List (PINTO, 2000) .................................................33
Figura 4.4.2 Channel Pres. No Event List (PINTO, 2000) .....................................34
Figura 4.4.3 Progam Change no Event List (PINTO, 2000)...................................35
Figura 4.4.4 Control Change no Event List (PINTO, 2000)....................................35
Figura 4.4.5 Pitch Wheel no Event List (PINTO, 2000) .........................................36
Figura 5.1 As fases e os marcos de um projeto RUP (RUP, 2003) .......................39
Figura 6.2.1 Casos de Uso. ...................................................................................73
Figura 6.2.2 Conceitos. .........................................................................................74
Figura 7.1 Casos de Uso expandidos....................................................................82
Figura 7.2a Diagrama de Seqncia gravar trilha MIDI.........................................84
Figura 7.2b Diagrama de Seqncia gravar trilha udio. ......................................84
Figura 7.2c Diagrama de Seqncia editar trilha. .................................................85

IV

LISTA DE TABELAS

Tabela 3.3 Comandos MIDI (PINTO, 2000). ..........................................................16


Tabela 3.5a Valores de Balance (RATTON, 1996b) ..............................................20
Tabela 3.5b Valores de Pan (RATTON, 1996b) ....................................................20
Tabela 3.7 Os 128 instrumentos musicais e efeitos sonoros do MIDI ...................24
Tabela 6.1.2a Levantamento de requisitos (WAZLAWICK, 2004) .........................52
Tabela 6.1.2b Requisito funcional 1 e requisitos no-funcionais. ..........................54
Tabela 6.1.2c Requisito funcional 2 e requisitos no-funcionais. ..........................55
Tabela 6.1.2d Requisito funcional 3 e requisitos no-funcionais. ..........................56
Tabela 6.1.2e Requisito funcional 4 e requisitos no-funcionais. ..........................57
Tabela 6.1.2f Requisito funcional 5 e requisitos no-funcionais. ...........................58
Tabela 6.1.2g Requisito funcional 6 e requisitos no-funcionais. ..........................59
Tabela 6.1.2h Requisito funcional 7 e requisitos no-funcionais. ..........................60
Tabela 6.1.2i Requisito funcional 8 e requisitos no-funcionais. ...........................61
Tabela 6.1.2j Requisito funcional 9 e requisitos no-funcionais. ...........................62
Tabela 6.1.2k Requisito funcional 10 e requisitos no-funcionais. ........................63
Tabela 6.1.2l Requisito funcional 11 e requisitos no-funcionais. .........................64
Tabela 6.1.2m Requisito funcional 12 e requisitos no-funcionais. .......................65
Tabela 6.1.2n Requisito funcional 13 e requisitos no-funcionais. ........................66
Tabela 6.1.2o Requisito funcional 14 e requisitos no-funcionais. ........................67
Tabela 6.1.2p Requisito funcional 15 e requisitos no-funcionais. ........................68
Tabela 6.1.2q Requisito funcional 16 e requisitos no-funcionais. ........................69
Tabela 6.1.2r Requisito funcional 17 e requisitos no-funcionais. .........................70
Tabela 6.1.2s Requisitos suplementares. ..............................................................71
Tabela 6.2.1 Descrio dos Casos de Uso. ...........................................................73
Tabela 6.2.2a Listagem de Conceitos e Operaes de Manuteno (WAZLAWICK,
2004) .........................................................................................................................74
Tabela 6.2.2b Listagem dos conceitos...................................................................75
Tabela 6.2.3 Listagem de Consultas......................................................................75
Tabela 7.1a Expanso do caso de uso Gravar Msica..........................................78
Tabela 7.1b Expanso do de caso uso Editar Msica. ..........................................80
Tabela 7.4a Contrato cadastraMusica ...................................................................87
Tabela 7.4b Contrato alteraMusica........................................................................88
Tabela 7.4c Contrato excluiMusica........................................................................88
Tabela 7.4d Contrato consultaMusica....................................................................88
Tabela 7.4e Contrato listaMusicas.........................................................................89
Tabela 7.4f Contrato gravarMensagem .................................................................89
Tabela 7.4g Contrato salvarTrilha..........................................................................89
Tabela 7.4h Contrato gravarAudio.........................................................................90
Tabela 7.4i Contrato alteraTrilha ...........................................................................90
Tabela 7.6a Caso de Uso Real Gravar msica......................................................95
Tabela 7.6b Caso de Uso Real Editar msica. ......................................................96

LISTA DE ABREVIATURAS E SIGLAS

MER Modelo Entidade Relacionamento.


MIDI Musical Instrument Digital Interface.
SQL - Structured Query Language.
RUP Rational Unified Process.
SGBD Sistema Gerenciador de Banco de Dados.
UML Unified Modeling Language.

SUMRIO
Resumo ............................................................................................................... I
Abstract .............................................................................................................. II
Lista de Figuras................................................................................................. III
Lista de Tabelas ................................................................................................ IV
Lista de Abreviaturas e Siglas ............................................................................ V
1. Introduo ................................................................................................... 8
2. Msica....................................................................................................... 10
2.1. Conceitos Bsicos ............................................................................. 10
2.2. Computer Music................................................................................. 11
3. MIDI........................................................................................................... 12
3.1. Definio............................................................................................ 12
3.2. Tipos de Mensagens MIDI ................................................................. 13
3.2.1. Mensagens que dependem de canal MIDI.................................. 13
3.2.2. Mensagens que no dependem de Canal MIDI.......................... 14
3.2.3. Mensagens transparentes......................................................... 15
3.3. Tabela com os Comandos MIDI ........................................................ 15
3.4. Status Byte e Data Byte..................................................................... 16
3.5. Control Change.................................................................................. 17
3.6. Conexes MIDI .................................................................................. 22
3.7. Os Canais de MIDI............................................................................. 23
3.8. Msica e Cincia da Computao ..................................................... 25
4. Software Seqenciador MIDI .................................................................... 26
4.1. Trilhas ................................................................................................ 27
4.2. Portas MIDI........................................................................................ 27
4.3. Caractersticas Principais .................................................................. 28
4.3.1. Notation View.............................................................................. 28
4.3.2. Mixer ........................................................................................... 29
4.3.3. Song View................................................................................... 30
4.3.4. Piano View e Piano Roll.............................................................. 30
4.3.5. Track View .................................................................................. 31
4.3.6. Event View.................................................................................. 31
4.3.7. Controller View............................................................................ 32
4.4. Exemplo Prtico................................................................................. 32
4.4.1. Notas .......................................................................................... 32
4.4.2. Channel Pres. ............................................................................. 34
4.4.3. Progam Change.......................................................................... 34
4.4.4. Control Change........................................................................... 35
4.4.5. Pitch Wheel................................................................................. 35
4.5. Estado da Arte ................................................................................... 36
5. Metodologia de Desenvolvimento RUP..................................................... 38
5.1. Conceito............................................................................................. 38
5.2. Fase de Iniciao ou Concepo....................................................... 40
5.3. Fase de Elaborao........................................................................... 42
5.4. Fase de Construo........................................................................... 44
5.5. Fase de Transio ............................................................................. 46
5.6. Definio das Tarefas e Atividades ................................................... 48
6. Concepo ................................................................................................ 50
6.1. Levantamento de Requisitos ............................................................. 50

7
6.1.1. Viso Geral do Sistema .............................................................. 50
Software Seqenciador MIDI (Viso Geral do Sistema) ........................ 50
6.1.2. Requisitos ................................................................................... 51
6.2. Organizao dos Requisitos .............................................................. 72
6.2.1. Organizao dos Requisitos em Casos de Uso.......................... 72
6.2.2. Organizao dos Requisitos em Funo de Conceitos .............. 74
6.2.3. Organizao dos Requisitos em Consultas ................................ 75
6.3. Marco dos Objetivos de Ciclo de Vida ............................................... 76
7. Elaborao ................................................................................................ 77
7.1. Expanso dos Casos de Uso............................................................. 77
7.2. Operaes e Consultas de Sistema................................................... 82
7.3. Modelagem Conceitual ...................................................................... 85
7.4. Contratos ........................................................................................... 87
7.5. Projeto da Camada de Domnio......................................................... 90
7.6. Projeto da Camada de Interface ........................................................ 92
7.7. Projeto da Camada de Persistncia................................................... 96
8. Concluso ................................................................................................. 99
Referncias .................................................................................................... 101
Anexo 1 .......................................................................................................... 103

1. INTRODUO
Com o advento da informtica e a difuso dos microcomputadores, muitas tarefas antes realizadas manualmente hoje so
realizadas com o auxlio de um software de computador.
No universo musical no diferente. Msicos profissionais que
trabalham arduamente com a partitura nas composies de jingles, trilhas para
novelas e cinema, ou at mesmo para uma nova cano, deparam muitas
vezes com desafios inerentes. Alm de pesquisar qual estilo musical, ritmo,
escala a ser usada, toda essa documentao representada atravs de
partituras. O software seqenciador MIDI surgiu com esta facilidade para o
msico. Nele possvel passar a msica diretamente do instrumento para o
computador, e do computador para o instrumento, e assim, pode-se editar,
alterar, corrigir a msica, grav-la em vrias trilhas e gerar a partitura entre
outras funcionalidades j existentes nos softwares atuais.
A Cincia da Computao na busca de melhores e mais
inovadas solues para os usurios vm em busca de mais uma. Segundo o
trabalho realizado por SCHROEDER (2005), que foi o estudo do padro MIDI e
o comparativo de softwares seqenciador MIDI existente no mercado, apontou
que existem softwares muito bons atualmente, mas todos com basicamente as
mesmas funcionalidades para o msico, mudando apenas a forma de
apresentao, sua interface e alguns outros recursos de um software para
outro, tais como mais efeitos numa trilha, entre outros. Mas todos estes
recursos levantados nesta pesquisa no foram to relevantes a ponto de
SCHROEDER (2005) apontar algumas necessidades que seriam muito
interessantes que um software seqenciador MIDI tivesse. Estas necessidades
so a busca da informao MIDI propriamente dita e a quantizao mais
inteligente. Este ltimo, um grande problema nos seqenciadores atuais. Outra
melhoria interessante seria uma interface mais intuitiva e usvel ao profissional
da msica, que nem sempre um usurio avanado em computao e
encontra algumas dificuldades para trabalhar com todas as ferramentas
contidas no software seqenciador MIDI.

9
Com o objetivo de criar um seqenciador com essas
caractersticas no encontradas, este trabalho descreve a anlise e projeto
deste software. Inicia-se no captulo 2 com um breve estudo definindo
tecnicamente o que msica, som, suas caractersticas, sua representao
atravs de smbolos numa pauta musical, e finaliza o captulo com a
apresentao e definio do conceito de computer music conforme (RATTON,
1998b).
No terceiro captulo realizado um estudo do padro MIDI,
discriminando os tipos de mensagens, os comandos e canais MIDI, e de que
maneira realizada a conexo.
O software seqenciador MIDI o tema central do captulo 4.
Mostra-se o que so trilhas e as caractersticas principais de um seqenciador
MIDI encontrado hoje em dia. Um exemplo prtico apresentado, mostrando a
maneira que ele trabalha para uma seqncia de mensagens MIDI. Finalizando
este captulo, faz-se a proposta do novo software seqenciador MIDI que foi
definida segundo as necessidades levantadas por (SCHROEDER, 2005).
No captulo 5 apresentada a metodologia de desenvolvimento
de software usada neste trabalho, o RUP. Sua conceituao e todas as fases
que ele comporta, finalizando com a definio das tarefas e atividades deste
trabalho.
Todas as atividades incumbidas concepo do software esto
descritas no capitulo 6. Ou seja, o levantamento dos requisitos e a organizao
dos requisitos em casos de uso, conceitos e consultas.
No captulo 7 contm a fase de elaborao do software.
Subdividida nas subfases de anlise, onde esta a expanso dos casos de uso,
a anlise de operaes e consultas de sistema, modelagem conceitual e o
contrato de operaes e consultas de sistema. E na subfase de projeto, que
contem o projeto da camada de domnio, interface e persistncia.

10

2. MSICA
2.1. Conceitos Bsicos
De acordo com MED (1996), msica a arte de combinar os
sons simultnea e sucessivamente, com ordem, equilbrio e proporo dentro
do tempo. Formada pela melodia que o conjunto de sons dispostos em ordem
sucessiva (concepo horizontal da msica), a harmonia que o conjunto de
sons dispostos em ordem simultnea (concepo vertical da msica), o
contraponto que o conjunto de melodias dispostas em ordem simultnea
(concepo ao mesmo tempo horizontal e vertical da msica) e o ritmo que a
ordem e proporo em que esto dispostos os sons que constituem a melodia
e a harmonia.
O som a sensao produzida no ouvido pelas vibraes de
corpos elsticos. Uma vibrao pe em movimento o ar na forma de ondas
sonoras que se propagam em todas as direes simultaneamente. As
vibraes podem ser regulares e irregulares. A vibrao regular produz sons de
altura definida, chamados sons musicais ou notas musicais, por exemplo, o
som do piano, do violino, etc. A vibrao irregular produz sons de altura
indefinida, chamados de barulhos, por exemplo, som do avio, de automvel,
de uma exploso, etc. Na msica so usados tanto os sons regulares
(instrumentos musicais como notas definidas), como os sons irregulares
(instrumentos de percusso) (MED, 1996).
As principais caractersticas do som so: a altura que
determinada pela freqncia das vibraes, isto , da sua velocidade, quanto
maior for a velocidade da vibrao, mais agudo ser o som. A durao que a
extenso de um som, determinada pelo tempo de emisso das vibraes. A
intensidade que a amplitude das vibraes, determinada pela fora ou pelo
volume do agende que o produz, portanto, o grau de volume sonoro. E o
timbre que a combinao de vibraes determinadas pela espcie do agende
que os produz. O timbre a cor do som de cada instrumento ou voz, derivado
da intensidade dos sons harmnicos que acompanham os sons principais.
Todo e qualquer som musical tem, simultaneamente, as quatro propriedades
(MED, 1996).

11
A notao musical so os sinais que representam a escrita
musical, tais como, pauta (Figura 2.1), claves, notas, etc.
Clave

Notas
Figura 2.1 Pauta Musical
Na escrita musical as propriedades do som so representadas
pela altura que a posio da nota no pentagrama1 e pela clave2. A alternncia
de notas de alturas diferentes resulta em melodia. A simultaneidade de sons de
alturas diferentes resulta em acordes, que so a base da harmonia; a durao
representada pela figura da nota e pelo andamento. A alternncia de notas
de duraes diferentes resulta em ritmo; Intensidade representada pelos
sinais de dinmica. A alternncia de notas de intensidades diferentes resulta
em dinmica; O timbre pela indicao da voz e instrumento que deve
executar a msica. A alternncia e a combinao de timbres diferentes resulta
em instrumentao (MED, 1996).

2.2. Computer Music


RATTON (1998b), define computer music como "informtica
musical", isto , no a msica que computadorizada, mas na realidade so
os recursos do computador (e da informtica como um todo) que so aplicados
para a criao, manipulao, execuo e reproduo da msica. Ou seja, todo
o universo tecnolgico vinculado ao computador (e informtica em geral) que
dispomos para fazer nossa arte, a msica.
Mas o uso do computador s se tornou verdadeiramente
intensivo a partir da dcada de 80, por duas razes: o barateamento e
conseqente popularizao dos microcomputadores, e o advento do MIDI
(RATTON, 1998b).
__________________
1

Pentagrama ou Pauta Musical a disposio de cinco linhas paralelas horizontais e quatro


espaos intermedirios, onde se escrevem as notas musicais (MED, 1996).
2
Clave um sinal colocado no inicio da pauta que da seu nome nota escrita em sua linha
(MED, 1996).

12

3. MIDI
3.1. Definio
A notao musical atravs da pauta musical e seus smbolos
como claves, notas, entre outros, permitem que a msica seja descrita e
representada de uma maneira simblica. Com base nesta representao, o
padro MIDI (Musical Instrument Digital Interface) usa tcnicas similares s
pautas musicais e define como codificar todos os elementos musicais.
MIDI um sistema de transmisso digital de informaes
voltado para aplicaes musicais. Criado a partir de um acordo entre
fabricantes de instrumentos musicais eletrnicos japoneses e americanos,
permitiu a interconexo de instrumentos musicais eletrnicos, e tornou
realidade a automao musical pelo computador atravs do uso de
seqenciadores e inmera outros aplicativos de controle (RATTON, 2005).
Pode-se dizer que o MIDI uma maneira computacional de
representao do som. Pois o MIDI no transmite udio, apenas mensagens
que comandam aparelhos que sejam capazes de entend-las.
O sistema MIDI usa digitais (bits e bytes), levando informaes
que dizem respeito a execuo musical, como notas musicais, volume,
acionamento de pedais, troca de timbres, etc (na verdade, h tambm algumas
outras informaes no-musicais, como configuraes de equipamentos de
estdio, por exemplo) RATTON (1998b). Os arquivos MIDI so muito
compactos. Um arquivo MIDI pode ser 1000 vezes menor que um arquivo CD
udio. Alm disso, a representao MIDI modificvel.
Por outro lado, o padro, apesar de fixo em seu carter bsico,
vem tendo vrias adies ao longo dos anos, fazendo-o cada vez mais
abrangente e capaz de lidar com as mais diversas caractersticas de
instrumentos que venham a implementar MIDI, de simples teclados at
sistemas de iluminao, passando pela indstria cinematogrfica, alm dos
mais modernos controladores musicais, muitos at mesmo sem teclado
(PINTO, 2000).

13

3.2. Tipos de Mensagens MIDI


3.2.1. Mensagens que dependem de canal MIDI
So as mensagens que, quando enviadas, afetam apenas o
canal MIDI selecionado. De acordo com PINTO (2000), so elas:

Note On comando para tocar uma determinada nota,

com uma determinada velocidade velocidade, que na prtica significa


intensidade.

Note Off comando para desligar a nota que est

sendo tocada. Tambm h dentro do comando a velocidade de desligamento


da nota, mas poucos teclados a usam, e so mais raros os seqenciadores que
deixam que manipulemos estes dados. Muito comum, porm, usar o
comando Note On com velocidade zero para desligar a nota. Por qu? Para
economizar alguns bytes, num processo chamado running status.

Aftertouch

um

comando

que

disparamos

ao

colocarmos presso na tecla em que tocamos. Note que, para cada tecla pode
ser colocada uma presso diferente, gerando, portanto, mensagens diferentes.

Control Change comandos que podem controlar

diversas partes do teclado, como o volume (control 7) e o pedal de sustain


(control 64). Basicamente, h 128 comandos para serem usados, sem contar
algumas combinaes por exemplo, o Control 0 e Control 32 em conjunto
formam, poderamos dizer, um Control 129. por causa dessa enorme
possibilidade de combinaes de controles que o padro MIDI no ficou
obsoleto.

Program Change (patch) o comando que muda de

um timbre para outro. Este comando tem um alcance de, no mximo, 128
timbres.

Channel Pressure Outra forma de Aftertouch, mas

que monofnica, isto , atua indistintamente para todas as notas do teclado.


Por ser mais barato de se construir, a forma de aftertouch mais comum nos
teclados mais baratos, e tambm nos que tm peso, isto , imitam a ao do
piano acstico.

14

Pitch Wheel uma mensagem especfica para a

rodinha que normalmente est do lado esquerdo do teclado e muda a sua


afinao.

3.2.2. Mensagens que no dependem de Canal MIDI


Estas mensagens tm mais relao com o contexto em que
esse instrumento deve ser tocado, ou seja, elas so utilizadas para o MIDI
tocar o instrumento. De acordo com PINTO (2000) so:

System Exclusive Muitas vezes quer-se mandar

outro tipo de informao ao instrumento mudar a velocidade do vibrato, ou


mesmo mandar um timbre inteiramente novo que pegamos na Internet e no
havia no teclado neste caso usada uma mensagem system exclusive,
que transmite essas e outras informaes mais exotricas. A nica coisa que
uma mensagem exclusive tem em comum com outra so os bytes de comeo e
fim. Elas podem ter qualquer tamanho. Praticamente todo o aparelho MIDI tem
seu cdigo exclusive, e, como uma impresso digital, nico para cada
modelo de instrumento. Desta forma, no h chance de uma mensagem
destinada a um instrumento ser interpretada por outro. Exclusive pode ser
acessado normalmente por um computador, mas por assumir formas to
diversas de aparelho para aparelho, uma das mensagens mais difceis de se
dominar.
Existem algumas mensagens exclusive que no so to
exclusivas assim, pois a maioria dos instrumentos atuais responde a elas, e
so estas:

GM System Enable/Disable Um comando exclusive

que pe o instrumento receptor no modo GM.

Master Volume No confundir com a mensagem

control change, que controla o volume de cada canal MIDI. Este controla o
volume global do instrumento, com todos os seus canais de uma vez.

15

3.2.3. Mensagens transparentes


So mensagens que normalmente no so manipuladas pelo
msico, mas que existem para controle de diversos sistemas PINTO (2000):

MIDI Clock mensagem usada para que dois

sequencers andem no mesmo andamento. Basicamente, h 24 delas para


cada semnima. Numa msica de andamento constante, elas iro aparecendo
tambm a uma velocidade constante. Mas num ralentando, por exemplo, elas
iro ter um espaamento maior entre uma e outra. A maior desvantagem dessa
mensagem , depois de gravar uma msica com sincronismo baseado em MIDI
Clock, qualquer alterao de andamento ser impossvel. Hoje em dia, ela
quase no mais usada, em favor de outra mensagem.

MIDI Time Code mensagem que carrega em si o

tempo absoluto da msica. Isto quer dizer que ela vai aparecendo a intervalos
regulares, independente do andamento da msica. A sua grande vantagem
que, se quisermos mudar este andamento depois, ela no atrapalhar em
nada, pois estava apenas marcando o tempo, e o sequencer poder se mover
livremente por cima dessa marcao. Seu uso mais comum em conjunto com
o padro SMPTE, de sincronismo de vdeo.

Song

Position

Pointer

Quando

tem-se

dois

sequencers funcionando juntos por exemplo, um computador e uma bateria


eletrnica com o ritmo programado internamente, essa mensagem faz com
que, ao tocar-se uma msica no meio dela no sequencer mestre, o outro
comece a tocar sua parte no mesmo compasso daquele.

3.3. Tabela com os Comandos MIDI


Na terceira coluna da tabela 3.3 esto todos os comandos MIDI
existentes. A quarta coluna mostra quantos bytes compem cada comando
(cada < > representa um byte) (PINTO 2000).

16
Tabela 3.3 Comandos MIDI (PINTO, 2000).
Note On
<Note On><Key Number> <Velocity>
Note Off
<Note Off><Key Number> <Velocity>
Poly Key
<PolyKeyPress><Key Number> <Pres
Pressure
Value>
Channel Pressure <Chanel Pres> <Value>
Voice
Program Change <Prog Change> <Prog Number>
<ControlChange>
Control Change
<Control#><Contr.Val>
CHANNEL
Pitch Bend
<Pitch Wheel Change> <LSB><MSB>
Change
<Control Change>
Local Control
<122><0/127>(off/on)
All Notes Off
<Control Change> <123><0>
Omni Mode Off
<Control Change> <124><0>
Mode
Omni Mode On
<Control Change> <125><0>
Mono Mode On <Control Change><126><0 a 16>
Poly Mode On
<Control Change> <127><0>
Song Position
242> <pointer LSB> <pointer MSB>
Pointer
<243> <song number>
Common Sont Select
Tune Request
<246>
EOX
<247>
Timing Clock
<248>
SYSTEM
Start
<250>
Stop
<252>
Real
Time
Continue
<251>
Active Sensing
<254>
System Reset
<255>
System exclusive messages <240> <manufacturer ID> *** <247>

3.4. Status Byte e Data Byte


Todas as mensagens MIDI s tm dois tipos de bytes: o status
e o data.
Numa mensagem MIDI, o primeiro byte sempre distingue qual a
mensagem que est sendo transmitida, e os demais levam os valores desta
mensagem. Este primeiro byte o chamado status byte. Ele sempre maior
que 127. Ou seja, o primeiro bit sempre "1". Com isso, tem-se que todo byte
de mensagem (Data byte) menor que 127, ou seja, o primeiro bit "0"
(PINTO, 2000).

17
Status Bytes (MSB 1XXXXXXX) -> isto , o nmero maior que
127 (Em outras palavras, pode ser um nmero entre 128 at 255). Lembrando
que 10000000 em binrio o equivalente a 128 em decimal.
Data Byte (MSB 0XXXXXXX) -> isto , o nmero no maior
que 127 (isto , entre 0 e 127), e usado para transmitir o contedo da
mensagem, caso haja algum. Por esse motivo o nmero 128 redondo em
MIDI: tem-se 128 notas, 128 timbres possveis com Program Change, 128
velocidades para uma determinada nota, e assim por diante.
A taxa de transmisso de 31,25 Kbaud (31250 bits por
segundo, precisando 10 bits para cada poro de informao. Uma nota tem
trs bytes para tocar, portanto consegue-se mais ou menos 1000 notas por
segundo).
Tocando-se uma nota em um sintetizador ele transmitir 3
bytes, caso transmita outra nota, sem mexer em mais nada, o teclado ir
transmitir apenas mais dois bytes data sem o status byte. O aparelho que
estiver recebendo, por sua vez, ir entender que aqueles dois bytes seguintes
no so outra coisa alm de mais uma nota. Esta conveno chamada de
running status. Com ela, o aparelho receptor presume que bytes data (que ele
conhece por serem menores que 128) sem o status so do mesmo tipo que a
ltima mensagem recebida. Num acorde de quatro notas, portanto, sero
transmitidas 9 bytes (tres bytes para a primeira nota e dois para cada uma das
outras trs notas), e no 12 - uma economia de 25%. Em certas situaes este
tipo de comportamento permite um trfego de informao bem menos
congestionado (PINTO, 2000).

3.5. Control Change


Quando foi criado o padro MIDI, no s foram definidas as
caractersticas eltricas da transmisso de informaes entre equipamentos,
como tambm foram estabelecidos os cdigos digitais para diversas
mensagens de comando a serem transferidas de um instrumento para outro,
como a execuo de notas, por exemplo. Dentre essas mensagens, h uma
categoria que engloba todos os tipos de controles, como ajuste de volume e de

18
pan, posio do pedal de sustain, ajuste de tempo do portamento, de
intensidade de efeitos, etc, e essas mensagens so chamadas de control
change messages, ou mensagens de alterao de controle (RATTON, 1996b).
Os comandos de control change se subdividem em dois
subgrupos: controles contnuos (cujo valor pode variar gradualmente), e
controles liga/desliga (que atuam como chaves de dois estados).Todas as
mensagens de control change contm identificao de canal, para que possam
ser dirigidas ao instrumento desejado, que est configurado para receber no
mesmo canal em que a mensagem est sendo transmitida (RATTON, 1996b).
Quando o msico move algum dos dispositivos de controle de
seu instrumento (pedal de volume, alavanca de modulation, etc), so
transmitidas mensagens correspondentes de control change, que contm trs
cdigos, compondo o seguinte formato (RATTON, 1996b): control change /
canal, nmero do controle, valor do controle.
O primeiro cdigo identifica que a mensagem MIDI de control
change, e tambm informa qual o nmero do canal de MIDI em que ela est
sendo transmitida; o segundo cdigo identifica qual o controle (volume, pan,
etc) que se est ajustando; o terceiro cdigo indica qual o valor do ajuste a ser
feito naquele controle (RATTON, 1996b).
A seguir so apresentados alguns comandos de control change
com seus respectivos valores:
Controle N 0 Bank Select: Esta mensagem tem a funo de
selecionar determinado timbre em um banco de timbres. Atravs da qual podese selecionar via MIDI um banco especfico de timbres e ento, no banco
selecionado, escolher qual dos 128 timbres dele se deseja selecionar.
Controle N 1 Modulation: O controle de modulation um
dos mais antigos dispositivos a ser implementado nos sintetizadores. Usado
desde os primeiros Moogs, no final da dcada de 60, em quase todos os
instrumentos o modulation est localizado esquerda do teclado. Ao se mover
o dispositivo de controle de modulation, so geradas inmeras mensagens
MIDI de control change n1, cada uma indicando cada posio em que passa o
controle.

19
Controle N 2 Breath Controller: O controle por sopro ou
breath controller um dispositivo que permite ao msico usar o sopro para
controlar algum parmetro do som do sintetizador.
Hoje, muitos equipamentos que no implementam breath
controller usam o control change 2 para outra funo, em geral controlado por
um boto deslizante (slider) no painel, de funo programvel.
Controle N 4 Foot Controller: O control change 4 foi
definido na especificao original como um comando para ser gerado por um
dispositivo de pedal de ao contnua (gradual), e sua atuao especfica (o
parmetro que altera) pode ser programada no instrumento. O movimento do
pedal gera mensagens MIDI de control change 4, que transmitem a sua
posio fsica, identificada por valores de 0 (pedal totalmente para trs) a 127
(pedal totalmente para a frente). J no E-mu Proteus, o comando MIDI de
control change 4 no tem funo especfica, e ao ser recebido via MIDI pode
ser direcionado para atuar em um dentre diversos parmetros.
Controle N 5 Portamento Time: Este controle foi idealizado
para ajustar, via MIDI, o tempo do portamento, que um efeito semelhante ao
pitchbend, obtido quando se passa da freqncia de uma nota para a de outra.
o efeito que o violinista faz ao deslizar o dedo da mo esquerda na corda,
enquanto passa o arco sobre ela. O tempo do portamento , portanto, o
intervalo de tempo que decorre para ir da nota inicial at a nota final (RATTON,
1996b).
Controle N 6 Data Entry MSB: Este controle serve para
efetuar ajustes de parmetros diversos via MIDI. o controle onde se faz o
ajuste fino de valores de parmetros de edio. Em muitos instrumentos e
equipamentos ele designado por Value (RATTON, 1996b).
Controle N 7 Volume: A mensagem MIDI de control change
n7 destinada ao controle de volume. Quando se move um boto deslizante ou um pedal - de controle de volume, o equipamento transmite inmeras
mensagens de control change n7 correspondentes s posies que o boto ou
pedal passam no decorrer do movimento. Mas, se o objetivo efetuar uma
alterao imediata de volume, ento, no caso de se estar trabalhando com um
seqenciador, muito mais conveniente criar este valor exato atravs do
software, e no gravando-o a partir do equipamento transmissor. Isso porque

20
no software pode-se inserir um nico comando de control change n7 com o
valor desejado, enquanto que pelo equipamento controlador provavelmente
sero gerados inmeros comandos, que acabaro por ocupar memria
desnecessariamente (RATTON, 1996b).
Controle N 8 Balance: O control change n8 usado como
comando de Balance (equilbrio), que determina o equilbrio de volume entre
dois sons diferentes (Tabela 3.5a), um situado esquerda e outro direita
(RATTON 1996b).

Tabela 3.5a Valores de Balance (RATTON, 1996b)


Valor
Situao
Volume mximo para o som da direita.

Volume mnimo para o som da esquerda.


Volumes iguais para ambos os sons

64

Volume mnimo para o som da direita.

127

Volume mximo para o som da esquerda.

Controle

10

Pan:

Controle

que

determina

posicionamento de um som no estreo, campo esquerda-direita (Tabela 3.5b).

Tabela 3.5b Valores de Pan (RATTON, 1996b)


Valor
Situao
Som todo para esquerda.

Som no centro (igualmente na esquerda e na

64
direita).

127

Som todo para direita.

importante perceber que alguns equipamentos usam uma


notao diferente da apresentada acima, de forma que o valor 0 muitas vezes
indica a posio central, e os extremos seriam representados por -64 e +63. H
tambm equipamentos que no possuem 63 ou 64 nveis para cada lado, de
forma que o ajuste se d em passos mais largos, de forma anloga ao controle
de volume (RATTON 1996b).

21
Controle N 11 Expression: O comando de Expression
(expresso) uma forma de acentuao do volume principal. Atua como uma
espcie de volume global, aps o controle de volume normal (control change
7). Dessa forma, se for transmitido um valor baixo de control change 11, pode
ocorrer do som de um equipamento ficar muito baixo, mesmo que se altere o
volume (control change 7) (RATTON, 1996b).
Controle N 64 Sustain On/Off: O control change 64 o
pedal de sustain (s vezes designado como damper pedal ou hold pedal). Sua
funo ativar ou no a sustentao do som, que, dependendo da
caracterstica deste, pode ter efeitos ligeiramente diferentes. Os movimentos
(pressionar ou soltar) feitos pelo msico no pedal de sustain so codificados
como comando de control change n 64, que a mensagem de Sustain Pedal
On/Off. Ao pressionar o pedal, o equipamento transmite um comando de
control change 64 com valor 127, e ao soltar o pedal o equipamento transmite
um comando de control change 64 com valor 0 (RATTON, 1996b).
Controle N 65 Portamento On/Off: O portamento um
efeito obtido nos instrumentos musicais no-cromticos como o violino, por
exemplo, onde o msico executa a nota deslizando o dedo sobre a corda,
subindo ou descendo continuamente a afinao, para ir de uma nota a outra.
Em muitos instrumentos musicais eletrnicos, tambm possvel conseguir
esse efeito, desde que seja ativada a funo especfica. Isso pode ser feito
atravs de uma tecla no painel do equipamento ou por um pedal. Ao se ligar o
efeito de portamento, o equipamento transmite o comando (mensagem) MIDI
de control change n 65, com valor 127 (On), e ao se desligar o efeito,
transmitido o comando de control change n 65, com valor 0 (Off) (RATTON,
1996b).
Controle N 68 Legato On/Off: O controle de Legato On/Off
usado para ligar ou desligar a funo de legato monofnico. Quando esta
funo est ligada, o instrumento passa a operar em modo monofnico (s
executa uma nota de cada vez - no faz acordes), e atua de acordo com o
seguinte procedimento: se uma nota j est sendo executada e o msico tocar
outra nota, soar somente a nota nova (a antiga deixar de tocar), mas sem
que haja um novo ataque de envoltria. Ao se desligar a funo de legato
monofnico, o instrumento volta ao modo polifnico normal.

22
possvel ativar ou desativar via MIDI o modo legato
monofnico, enviando para o instrumento o comando de control change 68
(Legato On/Off). Sendo este tambm um comando do tipo liga/desliga, o valor
127 significa On (ativar legato), enquanto o valor 0 significa Off (desativar
legato) (RATTON, 1996b).
Controle N 98 e 99 RPN e NRPN: Os parmetros
registrados (RPN - "Registered Parameters Numbers") e os parmetros noregistrados (NRPN - "Non-Registered Parameters Numbers") so usados para
representar parmetros do som ou de performance nos instrumentos, sendo
que os parmetros registrados so aqueles que j foram definidos em comum
acordo entre os fabricantes participantes da MMA (MIDI Manufacturers
Association) e JMSC (Japan MIDI Standard Comittee). Os comandos NRPN,
por sua vez, tm sido usados pelos fabricantes para atuar sobre parmetros
ainda no padronizados (RATTON, 1996b).

3.6. Conexes MIDI


Dentre as formas de conexo de equipamentos MIDI uma delas
(figura 3.6a), quando a sada de um instrumento MIDI Out conectada a
entrada de outro instrumento MIDI In.

Figura 3.6a Conexo MIDI instrumento-instrumento (RATTON, 1997b).


Outra forma de conexo MIDI (figura 3.6b) entre o computador
e o instrumento. Nesta, porm, o computador pode funcionar tanto como
receptor quanto como transmissor.

23

Figura 3.6b Conexo MIDI instrumento-computador (RATTON, 1997b).


Porm a conexo fsica com o cabo MIDI no a nica coisa
que tem que ser feita para que equipamentos possam operar interligada via
MIDI. preciso selecionar corretamente os canais de MIDI, bem como verificar
alguns outros parmetros relativos transmisso e recepo das
informaes (RATTON, 1997b).

3.7. Os Canais de MIDI


Para transmitir informaes de notas e outros eventos musicais
(como o acionamento de pedais, por exemplo), o sistema MIDI dispe de 16
canais. O sistema funciona de forma bastante semelhante ao sistema de TV:
se o transmissor utiliza um determinado canal MIDI (diga-se, canal 1), o
equipamento receptor s poder efetivamente receber as informaes se
estiver ajustado tambm para mesmo canal MIDI (no caso, o canal 1). Os
equipamentos atuais possuem ajustes separados de canal de transmisso e de
recepo, o que significa, por exemplo, que um sintetizador pode estar
configurado para transmitir MIDI pelo canal 2, e receber pelo canal 4. Na
verdade, como os instrumentos mais modernos so "multitimbrais", podem
receber em vrios canais simultneos, independentemente do ajuste do seu
canal de transmisso (RATTON, 1998a).
Ento, uma providncia essencial ao se conectar dois ou mais
equipamentos MIDI verificar se eles esto configurados corretamente quanto
aos canais de transmisso e recepo.

24
O nmero mximo de canais de MIDI "trafegando" pelo cabo
16, mas esse limite no significa que no poder trabalhar com mais do que 16
instrumentos individuais. Nos estdios profissionais, para se ultrapassar o limite
dos 16 canais, usam-se equipamentos (ex: interfaces MIDI) com mltiplas
portas de sada MIDI Out, de forma que por cada uma so transmitidos
simultaneamente 16 canais MIDI. Assim, um sistema com oito sadas MIDI Out
pode trabalhar com at 128 canais de MIDI, o que significa poder comandar at
128 instrumentos diferentes, ao mesmo tempo. Na verdade, como o MIDI
utilizado para controlar outros equipamentos alm dos instrumentos musicais,
alguns canais so usados para controlar processadores de efeitos, mesas de
mixagem e outros recursos de estdio (RATTON, 1998a).
A tabela 3.7, mostra a conveno utilizada para definir os
efeitos sonoros do MIDI num respectivo cdigo.

Tabela 3.7 Os 128 instrumentos musicais e efeitos sonoros do MIDI


Nmero de
Programa

Tipos de Instrumentos

Exemplos

1-8
9-16

Pianos
Percusso Cromtica

1= Grande Acstico, 7= Cravo


10= Sistro, 14=Xilofone

17-24
25-32
33-40
41-48
49-56
57-64
65-72
73-80
81-88
89-96
97-104
105-112
113-120
121-128

rgos
Violes
Baixo
Cordas
Conjunto de Cordas
Metais
Palhetas
Flautas
Introduo Sintetizada
Enchimento Sintetizado
Efeitos Sintetizados
tnico
Percusso
Efeitos Sonoros

19= rgo de Rock, 23= Harmnica


25= Violo Acstico (Nylon)
33= Baixo Acstico
41= Violino, 43= Violoncelo
49= Conjunto de Cordas 1
57= Trompete, 61= Trompa Francesa
65= Sax Soprano
73= Piccolo, 76= Flauta Pan
81= Introduo 1, 82= Introduo 2
89= Enchimento 1 (New Age)
97= FX (chuva), 102= FX 6 (Duendes)
105= Ctara, 106= Banjo, 111= Rabeca
113= Tringulo, 116= Bloco de madeira
123= Beira-mar, 126= Helicptero

Quando o seqenciador manda uma nota via MIDI para ser


executada por um instrumento, codifica esse comando numa mensagem digital,
que leva quatro informaes bsicas (RATTON 1998a):
-

tipo de comando (neste caso: execuo de nota - note on)

25
-

nmero do canal de MIDI (1 a 16) em que est sendo transmitido o


comando

nmero da nota a ser executada (de 0 a 127; o d central a nota


60)

intensidade (key velocity) com que a nota deve ser executada (de 0 a
127)

Assim, o nmero do canal funciona como se fosse uma


identificao do destinatrio da mensagem e somente os equipamentos que
estejam configurados para receber mensagens naquele canal de MIDI (MIDI
Receive Channel) que ir efetuar o respectivo comando (RATTON, 1998a).
Na grande maioria dos seqenciadores, possvel indicar qual
o canal de MIDI que ser usado para se transmitir os eventos de cada trilha.
Essa indicao feita numa das colunas de parmetros existentes na janela
principal das trilhas (Tracks), geralmente designada como Channel (ou
abreviada como Chn). O nmero do canal de MIDI no tem qualquer ligao
com o nmero da trilha, podendo, inclusive, haver duas ou mais trilhas
operando no mesmo canal de MIDI (RATTON, 1998a).

3.8. Msica e Cincia da Computao


Neste captulo foi apresentado o padro MIDI e os tipos de
mensagens MIDI. Observa-se que atravs deste padro, dispositivos musicais
distintos podem trocar informaes entre si, pois estas informaes musicais
so transferias pelas mensagens MIDI seguindo um padro. Ou seja, uma nova
forma de representao da msica atravs de uma seqncia de mensagens
MIDI.
O programa de computador que armazena estas mensagens
para posterior alterao, execuo das mesmas, capacidades estas que no
so possveis caso a msica seja gravada em udio, o Software
Seqenciador MIDI. Este ser apresentado no captulo 4, com as suas
funcionalidades bsicas encontradas atualmente. Alm de um exemplo prtico
da forma como o software trabalha com as mensagens MIDI.

26

4. SOFTWARE SEQENCIADOR MIDI


O Software Seqenciador MIDI chamado de seqenciador
porque grava seqncias de mensagens MIDI, comandos de notas (note on,
note off), ou comandos de controle (ajuste de volume, pan, pitchbend, pedais,
etc). Dentre vrias funes disponveis para o msico sua funo bsica
gravar a informao MIDI, seja ela, de um sintetizador (podendo ser alterada
pelo software antes da execuo), ou, atravs da entrada de notas
manualmente. Estas mensagens podem ser reproduzidas pelo prprio software
no computador ou ento enviadas a um sintetizador para que o mesmo as
reproduza.
Como se sabe a mensagem MIDI no transmite som, somente
instrues para que se possa fazer som. E o conjunto de vrias mensagens
MIDI forma uma msica. Vale frisar que, estas mensagens no so enviadas
em paralelo, ou seja, uma mensagem enviada sempre uma em seguida da
outra.
As mensagens so armazenadas pelo seqenciador, medida
que executada (teclado, guitarra MIDI). E no final da execuo, a seqncia
conter todas as mensagens registradas cronologicamente, um a um
(RATTON, 1997a).
No entanto, o software seqenciador MIDI possui muitas outras
funcionalidades do que apenas um seqenciador de mensagens MIDI. Em
alguns softwares pode-se gravar trilhas de udio digital junto com outra trilha
MIDI, operando como gravador de udio. Ou seja, uma msica pode ter numa
trilha uma seqncia em MIDI e em outra em udio digital.
E como afirma RATTON (1997a) o seqenciador MIDI tem um
papel fundamental na msica atual, pois traz imensos recursos para a criao e
experimentao de idias, mas tambm pelo fato de agilizar o processo
criativo, aumentando a eficincia do trabalho, condio extremamente
importante no mercado cada vez mais competitivo da msica profissional.

27

4.1. Trilhas
Para facilitar o processo de armazenamento, o seqenciador
organiza os eventos em trilhas (pistas), de forma que o msico escolhe uma
trilha para gravar a execuo, e todos os comandos enviados pelo instrumento
ficaro registrados naquela trilha. Assim, cada parte do arranjo pode ser
registrada numa trilha separada: ao criar um arranjo de trs instrumentos
(timbres), como, por exemplo, piano, baixo e bateria, o msico executa cada
parte separadamente, registrando-as em trilhas individuais (ao gravar uma
nova trilha, o msico pode ouvir simultaneamente a execuo das trilhas j
gravadas) (RATTON, 1997a).
A separao da seqncia em trilhas oferece grandes
facilidades (RATTON, 1997a):

Desativar (mute) uma ou mais trilhas, de forma que as partes do


arranjo registradas nelas no sejam executadas; isso timo para
se ouvir isoladamente certas partes do arranjo;

Escolher outro timbre para executar a mesma trilha; permite


experimentar a mesma execuo com outras sonoridades;

Efetuar algum tipo de edio somente numa trilha, como efetuar a


transposio de um ou mais instrumentos do arranjo, sem alterar
os demais;

Efetuar uma mixagem inicial entre as trilhas, indicando valores de


controles de volume e pan;

4.2. Portas MIDI


As portas MIDI so os caminhos que o seqenciador dispe
para

receber/transmitir

os

eventos

MIDI

de/para

os

instrumentos

equipamentos MIDI. Elas esto diretamente relacionadas com as tomadas de


MIDI In e MIDI Out das interfaces MIDI instaladas no computador (RATTON,
1997a).
A grande maioria dos softwares seqenciadores pode manipular
mltiplas portas MIDI, de forma que se voc tiver uma placa de som e mais
uma interface MIDI de mltiplas sadas, todas as portas MIDI aparecero

28
disponveis no software. Os seqenciadores tambm podem reconhecer
mltiplas portas de entrada MIDI simultneas (RATTON, 1997a).

4.3. Caractersticas Principais


Dentre

as

principais

caractersticas

de

um

software

seqenciador MIDI, pode-se constatar que basicamente a maioria composta


por estes: notation view ou window, mixer, measure ou song view, piano view,
piano roll view, song view, track view, event view, controller view SEQUENCER
(2006). Que so explicados a seguir.

4.3.1. Notation View


A Figura 4.3.1a mostra a janela onde exibida a informao da
msica em notao musical, ou seja, na partitura. Ela chamada de Notation
View.

Figura 4.3.1a Notation View, Winjammer (SEQUENCER, 2006)


Nesta janela, notation view, tambm possvel digitar as notas,
modificar a altura, intensidade, durao e velocidade.

29

Figura 4.3.1b Notation View com um evento selecionado (SEQUENCER,


2006)
Como se observa na figura 4.3.1b quando uma nota for
selecionada, o seqenciador traz os seguintes dados:

O volume/velocidade 122

a nota E (mi), na 5 oitava

Esta sendo tocada no canal 2

Sua durao de 1 quarto de tempo, semnima

4.3.2. Mixer
A janela apresentada na figura 4.3.2 a figura de uma pequena
mesa mixer, semelhantes a de estdios, com controles tais como volume,
reverb e chorus.

Figura 4.3.2 Mixer Winjammer, (SEQUENCER, 2006)

30

4.3.3. Song View


Song view janela no qual mostra toda a msica em uma
matriz ou tabela. apresenta na figura 4.3.3.

Figura 4.3.3 Song View, Winjammer (SEQUENCER, 2006)


Esta janela (figura 4.3.3) mostra nas linhas as trilhas e nas
colunas toda a msica. Esta janela til para grandes alteraes na msica.
Lembrando que no necessariamente todas as trilhas devem ser MIDI,
podendo algumas ser udio digital.

4.3.4. Piano View e Piano Roll


O piano view um teclado virtual no qual podemos selecionar
as teclas que deveram ser tocadas pelo computador.
O piano roll (figura 4.3.4) contem retngulos em certas posies
e em certos tamanhos, correspondendo a notas e a durao da notas.

Figura 4.3.4 Piando Roll (Sonnar, Cakewalk)

31
Qualquer outro elemento MIDI tambm pode ser representado
pelo piano roll (figura 4.3.4).

4.3.5. Track View


A Track View que esta na figura 4.3.5 mostra todas as
informaes das trilhas da msica, como o nmero de notas e outros eventos,
o nome da trilha, qual instrumento/patch usado primeiro, qual canal e porta
utilizada.

Figura 4.3.5 Track View , Winjammer (SEQUENCER, 2006)


Nesta janela (Figura 4.3.5) tambm pode se observar quais
trilhas esto em formato MIDI e quais esto em formato udio.

4.3.6. Event View


O Event View, mostrada na figura 4.3.6 a lista de todos os
itens da trilha. Mostra a intensidade, compasso, velocidade (volume) da nota, a
durao e todos os marcadores e valores de controle. onde se obtm com
maior detalhe as informaes MIDI.

32

Figura 4.3.6 Event View (Sonnar, Cakewalk)

4.3.7. Controller View


Por intermdio de um grfico ou histograma as notas da msica
so apresentadas. Como se observa na figura 4.3.7, a altura no grfico traz o
valor do que se esta observando. Pode se observar um pitch bend, a
velocidade das notas, ou outra informao.

Figura 4.3.7 Controller View, Winjammer (SEQUENCER, 2006)

4.4. Exemplo Prtico


4.4.1. Notas
No necessrio administrar os comandos de note on e note
off separadamente. Na maioria dos seqenciadores mostra-se a nota, no lugar
que ela comea (em termos de compasso, tempo e a subdiviso de tempo,

33
chamada tick) e quanto esta nota dura (tambm em termos de compasso,
tempo e ticks) (PINTO, 2000).
Supondo-se que tenha tocado esta seqncia (figura 4.4.1a).

Figura 4.4.1a Notas tocadas (PINTO, 2000)


A seqncia tocada foi: d no primeiro tempo, mi no segundo e
um acorde de trs notas em dois tempos.
No

seqenciador

as

mensagens

aparecero

conforme

apresentado na figura 4.4.1b. O seqenciador est trabalhando com uma


resoluo de 120 divises por semnima, isto , entre um tempo e outro existe
uma grade de 120 buraquinhos para que ele possa colocar algum evento
(PINTO, 2000).

Figura 4.4.1b Notas no Event List (PINTO, 2000)


Observando a figura 4.4.1b da direita para a esquerda. A
primeira coluna da direita tem sempre trs valores: o nome da nota, a
velocidade e finalmente sua durao. O primeiro do ento dura 119 espaos,
praticamente igual a uma semnima, bem como o mi. A coluna esquerda
desta mostra qual tipo da mensagem MIDI, no caso notas. Seguindo
esquerda temos o canal MIDI em que esses comandos esto gravados, e, alm
disso, temos a coluna que indica em que lugar da msica, em termos de
compasso, tempo do compasso e tick. (no exemplo, uma nota no comeo do

34
primeiro tempo, uma no comeo do segundo e trs no terceiro tempo). A
coluna seguinte mostra em termos de tempo de relgio, isto , horas, minutos,
segundos e frames, quando as notas aparecem. Por fim, a ltima coluna nos
diz que tudo isto est apenas no track 1 do seqenciador (PINTO, 2000).

4.4.2. Channel Pres.


Suponha que, ao tocar o acorde eu aperto mais o teclado
gerando um aftertoutch. Isto ficaria registrado mais ou menos assim (figura
4.4.2):

Figura 4.4.2 Channel Pres. No Event List (PINTO, 2000)


Aps o acorde, vrios comandos de aftertoutch so registrados,
j que este tipo de modulao feito de modo contnuo. Percebe-se que
apesar de a modulao continuar aps o espao que h na janela, a
modulao no passou nem do terceiro tempo do compasso. Modulaes
assim contnuas gastam muita memria, geralmente (PINTO, 2000).

4.4.3. Progam Change


Suponha que se quisesse mudar o som do instrumento na hora
em que fosse tocar o acorde: isso se faz com o comando program change. No
exemplo (figura 4.4.3) muda-se o timbre para o nmero 2 (que neste teclado
corresponde ao som chamado Celesta). No caso o acorde estaria soando com
este som (PINTO, 2000).

35

Figura 4.4.3 Progam Change no Event List (PINTO, 2000)

4.4.4. Control Change


Neste exemplo (Figura 4.4.4) mostra-se como abaixar o som
usando. Para isso usa-se o comando Control Change.

Figura 4.4.4 Control Change no Event List (PINTO, 2000)


Na coluna que identifica o tipo de mensagem (Figura 4.4.4) est
especificado contrl, ou seja, control change. Tem-se em seguida sua
identificao (no 7, ou seja, volume) seguida do valor. No caso, o volume est
no mximo e sendo abaixado.

4.4.5. Pitch Wheel


Semelhantemente ao caso anterior, as mensagens contnuas
so colocadas seguidamente. Tem-se aqui (Figura 4.4.5) um exemplo de um
glissando para o grave do acorde (PINTO, 2000).

36

Figura 4.4.5 Pitch Wheel no Event List (PINTO, 2000)

4.5. Estado da Arte


Como apresentado na seo anterior, o software seqenciador
MIDI possui algumas caractersticas bsicas. E o que muda de um software
para outro a maneira como estas caractersticas so apresentadas, e o modo
como cada software trabalha.

Porm h softwares com inmeros outros

recursos, que alm da gravao de udio e MIDI em trilhas distintas, contm


vrios efeitos a ser aplicados na msica. Como um exemplo de um bom
seqenciador, o software Sonnar da Cakewalk, considerado o melhor na
pesquisa realizada por (SCHROEDER, 2005).
Mas, no entanto, segundo SCHROEDER (2005), h algumas
necessidades levantadas que atualmente no h em nenhum software
seqenciador que so:

Pesquisa por seqncia armazenada. Considerando um


banco de msicas grande, no existem recursos para
busca de uma seqncia j gravada. Poderia ser chamado de reconhecimento MIDI;

Quantizao3

mais

inteligente.

Os

algoritmos

de

quantizao dos seqenciadores so limitados, uma se-

__________________
3

Quantizao uma ferramenta de edio que existe na maioria dos seqenciadores, e que
permite ao msico acertar no tempo adequado as notas MIDI gravadas na seqncia. Ao se
determinar ao seqenciador que quantize determinado trecho de notas, necessrio definir
qual a figura musical de referncia (colcheia, semicolcheia, etc) que deve ser usada, isto ,
para quais tempos (ou fraes de tempos) as notas devero ser movidas (RATTON, 1996c).

37
qncia de notas rpidas executadas no quantizada
muito inteligentemente pelo computador. Evolues neste
sentido so necessrias;

Trabalhos em paralelo esto sendo realizados nesta rea de


Tecnologia Musical do CCT/UDESC. Um destes o trabalho que envolve o
armazenamento MIDI em banco de dados que de suma importncia para o
projeto final, e que vem como complemento a este.
O presente trabalho uma fase de um projeto maior que um
software seqenciador MIDI, contemplando todas essas necessidades levantas, e com o diferencial de ter o uso efetivo da informao musical codificada
para a pesquisa SCHROEDER (2005), o que facilitar muito o trabalho do msico, principalmente se este conta com um banco de dados de msica muito
grande. Assim o msico poder buscar seqncias de msicas j gravadas,
podendo reutilizar algumas partes, ou para servir como modelo para outras, ou
da melhor maneira como este novo recurso venha lhe convir.

38

5. METODOLOGIA DE DESENVOLVIMENTO RUP


5.1. Conceito
A metodologia de desenvolvimento na qual se baseia este trabalho o RUP (Rational Unified Process), tambm chamado de UP (Unified
Process), Processo Unificado, que est fortemente associado notao UML.
De acordo com RUP (2003), o RUP um processo de engenharia de software que oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organizao de desenvolvimento. Sua meta garantir a produo de software de alta qualidade que
atenda s necessidades dos usurios dentro de um cronograma e de um oramento previsvel. A figura 5.1a exibi uma viso geral dos processos envolvido no RUP.

Figura 5.1a RUP, viso geral (RUP, 2003)


O RUP oferece uma abordagem baseada em disciplinas para
atribuir

tarefas

responsabilidades

dentro

de

uma

organizao

de

desenvolvimento. Sua meta garantir a produo de software de alta


qualidade que atenda s necessidades dos usurios dentro de um cronograma
e de um oramento previsveis (RUP, 2003).

39
A figura 5.1a mostra a arquitetura geral do RUP, com suas
dimenses:

O eixo horizontal representa o tempo e mostra os


aspectos do ciclo de vida do processo medida que se
desenvolve.

O eixo vertical representa as disciplinas, que agrupam as


atividades de maneira lgica, por natureza.

A primeira dimenso representa o aspecto dinmico do


processo quando ele aprovado e expressa em termos de fases, iteraes e
marcos. A segunda dimenso representa o aspecto esttico do processo, como
ele descrito em termos de componentes, disciplinas, atividades, fluxos de
trabalho, artefatos e papis do processo (consulte Conceitos-chave). O grfico
mostra como a nfase varia atravs do tempo. Por exemplo, nas iteraes
iniciais, dedicamos mais tempo aos requisitos. J nas iteraes posteriores,
gastamos mais tempo com implementao.
O RUP comporta, em suas recomendaes, as antigas fases de
estudo de viabilidade, anlise de requisitos, anlise de domnio, e o projeto em
mltiplas camadas (WAZLAWICK, 2004).
O ciclo de vida de software do RUP dividido em quatro fases
seqenciais (Figura 5.1), cada uma concluda por um marco principal, ou seja,
cada fase basicamente um intervalo de tempo entre dois marcos principais.

Figura 5.1b As fases e os marcos de um projeto RUP (RUP, 2003)

40
A fase de iniciao ou concepo incorpora o estudo de viabilidade e uma parte da anlise de requisitos. A fase de elaborao incorpora a
maior parte da anlise de requisitos, a anlise de domnio e projeto. A fase de
construo corresponde programao e testes, e a fase de transio consiste
na instalao e manuteno do sistema (WAZLAWICK, 2004).

5.2. Fase de Iniciao ou Concepo


A fase de concepo, (inception), deve ser a primeira do processo de desenvolvimento de software, na qual se procura levantar os principais requisitos e compreender o sistema de forma abrangente (WAZLAWICK,
2004).
Esta fase inicial indica o nascimento da idia sobre um novo
software. Pode consistir da discusso sobre um problema que ocorre na empresa ou nos clientes e que eventualmente poderia ser resolvido ou minimizado
com o desenvolvimento de um sistema informatizado (QUADROS, 2002).
Nesta etapa, no realizado nenhum tipo de estudo aprofundado sobre o sistema, no entanto, podem ser feitas algumas projees grosseiras que permitam inferir, ainda que com pouca preciso QUADROS (2002):
Quanto tempo o software levaria para ser desenvolvido? Quanto o software
custaria para ser desenvolvido? Quais benefcios o projeto traria para a empresa ou para o cliente?
Segundo RUP (2003)

os principais objetivos da fase de

concepo incluem:
a) Estabelecer o escopo do software do projeto e as
condies limite, incluindo uma viso operacional, critrios de aceitao e o
que deve ou no estar no produto.
b) Discriminar os casos de uso crticos do sistema, os
principais cenrios de operao e o que direcionar as principais trocas de
design.
c) Exibir, e talvez demonstrar, pelo menos uma opo de
arquitetura para alguns cenrios bsicos.

41
d) Estimar o custo geral e a programao para o projeto
inteiro (e estimativas detalhadas para a fase de elaborao imediatamente a
seguir).
e) Estimar riscos em potencial (as origens de imprevistos).
f) Preparar o ambiente de suporte para o projeto.

As atividades bsicas incluem (RUP, 2003):


I. Formular o escopo do projeto. Isso envolve capturar o
contexto, bem como os requisitos e as restries mais importantes, para que
seja possvel depreender critrios de aceitao para o produto final.
II. Planejar e preparar um caso de negcio. Avaliar
alternativas para o gerenciamento de riscos, a organizao da equipe, o plano
do projeto e as mudanas de custo/programao/lucros.
III. Sintetizar uma

possvel

arquitetura,

avaliando

as

mudanas no design e em fazer/comprar/reutilizar, para que seja possvel


estimar custo, programao e recursos. O objetivo aqui demonstrar a
possibilidade de execuo atravs de alguma forma de prova de conceito. Isso
pode ter a forma de um modelo que simula o que exigido, ou de um prottipo
inicial que explora as reas consideradas de alto risco. O esforo do prottipo
durante a iniciao deve se limitar a ganhar confiana na possibilidade de uma
soluo - a soluo ser executada durante a elaborao e a construo.
IV. Preparar o ambiente para o projeto, avaliando o projeto
e a organizao, selecionando ferramentas e decidindo quais partes do
processo devem ser melhoradas.

Esta etapa a de definio do escopo do projeto. Ao final desta,


tem-se o primeiro Marco (milestone), o Lifecycle Objective Milestone, onde os
seguintes resultados devem ser apresentados (QUADROS, 2002):

Sumrio Executivo ou Documento de viso Geral do


Sistema, incluindo requerimento, recursos principais e
restries.

Glossrio do projeto, explicando os termos peculiares ao


desenvolvimento do mesmo (opcional).

Caso de uso inicial (descrito utilizando a UML).

42

Levantamento dos requisitos.

Um ou mais prottipos.

5.3. Fase de Elaborao


No incio da elaborao, o profissional tem uma vaga idia dos
requisitos que o software dever atender. Nesta fase, o profissional dever
investigar a fundo os obstculos (riscos) que o projeto pode encontrar. Tais
riscos como: Riscos de requisitos, riscos tecnolgicos, riscos de habilidades,
riscos polticos (QUADROS, 2002).
Alm da anlise dos riscos, a elaborao marcada pela
definio detalhada do escopo e dos requerimentos do software a ser
desenvolvido. Esta definio dos requerimentos deve ser formalizada por
escrito atravs de um documento denominado Documento de Levantamento e
Especificao de Requerimentos de Usurio (DLERU). O DLERU deve ser
submetido ao usurio/cliente sempre que possvel para que ele seja avaliado
(QUADROS, 2002).
A meta da fase de elaborao criar a baseline (a base de
sustentao) para a arquitetura do sistema a fim de fornecer uma base estvel
para o esforo da fase de construo. A arquitetura se desenvolve a partir de
um exame dos requisitos mais significativos (aqueles que tm grande impacto
na arquitetura do sistema) e de uma avaliao de risco. A estabilidade da
arquitetura avaliada atravs de um ou mais prottipos de arquitetura (RUP,
2003).
Segundo RUP (2003), os objetivos primrios da etapa de
elaborao incluem:
a) Assegurar que a arquitetura, os requisitos e os planos
sejam estveis o suficiente e que os riscos sejam suficientemente diminudos a
fim de determinar com segurana o custo e a programao para a concluso
do desenvolvimento. Para a maioria dos projetos, ultrapassar essa marca
tambm corresponde transio de uma operao rpida e de baixo risco para
uma operao de alto custo e alto risco com uma inrcia organizacional
freqente.

43
b) Tratar todos os riscos significativos do ponto de vista da
arquitetura do projeto.
c) Estabelecer uma arquitetura da baseline derivada do
tratamento dos cenrios significativos do ponto de vista da arquitetura, que
normalmente expem os maiores riscos tcnicos do projeto.
d) Produzir um prottipo evolutivo dos componentes de
qualidade de produo, assim como um ou mais prottipos descartados para
diminuir riscos especficos como:
a. Trocas de design/requisitos
b. Reutilizao de componentes
c. Possibilidade
demonstraes

de

produo

para

do

investidores,

produto
clientes

ou
e

usurios finais.

e) Demonstrar que a arquitetura de baseline suportar os


requisitos do sistema a um custo justo e em tempo justo.
f) Estabelecer um ambiente de suporte.

E as suas atividades bsicas so (RUP, 2003):


I.

Definir, validar e criar a baseline da arquitetura com

rapidez e eficincia.
II.

Refinar a Viso, com base nas informaes novas

obtidas durante a fase, estabelecendo uma compreenso slida dos casos de


uso mais crticos que conduzem as decises de arquitetura e planejamento.
III.

Criar planos de iterao detalhados e baselines para

a fase de construo.
IV.

Refinar o caso de desenvolvimento e posicionar o

ambiente de desenvolvimento, incluindo o processo, as ferramentas e o


suporte de automatizao necessria para dar assistncia equipe de
construo.

O objetivo dessa etapa analisar o domnio do problema,


estabelecer uma fundao, desenvolver o plano de projeto e eliminar os
elementos de maior risco do projeto. Ao final dela, tem-se o segundo Marco

44
(milestone), o Lifecycle Architecture Milestone, onde os seguintes resultados
devem ser apresentados (QUADROS, 2002):

Um caso de uso praticamente pronto com uma descrio

completa dos atores e cenrios de uso.

Descrio das operaes e consultas de sistema.

Modelagem Conceitual

Os Contratos de operaes e consultas de sistema.

5.4. Fase de Construo


A construo a fase do processo cujo final marcado pela
disponibilizao do produto de software (um arquivo executvel ou uma pgina
Web, por exemplo) para os clientes ou usurios (QUADROS, 2002).
Durante essa etapa, os profissionais estaro primeiramente
modelando o software utilizando alguma notao, tais como a definida pela
UML. Aps a modelagem, a fase de construo marcada pela codificao do
software, onde os desenvolvedores estaro fazendo uso de alguma ferramenta
de programao, bem como criando as estruturas de apoio, tais como o banco
de dados com suas tabelas e outros elementos (QUADROS, 2002).
A fase de construo tambm composta pela homologao
que consiste na realizao de testes de garantia de qualidade como o produto
antes do envio para o cliente. A documentao do produto encerra essa fase
do processo de desenvolvimento, juntamente com a disponibilizao de todo o
conjunto do produto para o cliente (software, manuais de treinamento e
referncia). A vantagem desta abordagem est em se permitir definir deadlines
(limites) intermedirios pra os vrios subprojetos, impedindo que os problemas
e os atrasos se evidenciem apenas no final do projeto (QUADROS, 2002).
A meta da etapa de construo esclarecer os requisitos
restantes e concluir o desenvolvimento do sistema com base na arquitetura da
baseline. A fase de construo de certa forma um processo de manufatura,
em que a nfase est no gerenciamento de recursos e controle de operaes
para otimizar custos, programaes e qualidade. Nesse sentido, a mentalidade
do gerenciamento passa por uma transio do desenvolvimento da propriedade

45
intelectual durante a iniciao e elaborao, para o desenvolvimento dos
produtos que podem ser implantados durante a construo e transio (RUP,
2003).
Segundo RUP (2003) os objetivos principais da etapa de
construo incluem:
a) Minimizar os custos de desenvolvimento, otimizando
recursos e evitando retalhamento e retrabalho desnecessrios.
b) Atingir a qualidade adequada com rapidez e eficincia.
c) Atingir as verses teis (alfa, beta e outros releases de
teste) com rapidez e eficincia.
d) Concluir a anlise, o design, o desenvolvimento e o teste
de todas as funcionalidades necessrias.
e) Desenvolver de modo iterativo e incremental um produto
completo que esteja pronto para a transio para a sua comunidade de
usurios. Isso implica descrever os casos de uso restantes e outros requisitos,
incrementar o design, concluir a implementao e testar o software.
f) Decidir se o software, os locais e os usurios esto
prontos para que o aplicativo seja implantado.
g) Atingir certo nvel de paralelismo entre o trabalho das
equipes de desenvolvimento. Mesmo em projetos menores, normalmente h
componentes que podem ser desenvolvidos um independente do outro,
permitindo o paralelismo natural entre as equipes (se os recursos permitirem).
O paralelismo pode acelerar bastante as atividades de desenvolvimento; mas
tambm aumenta a complexidade do gerenciamento de recursos e da
sincronizao dos fluxos de trabalho. Uma arquitetura sofisticada ser
essencial para atingir um paralelismo significativo.

E as suas atividades bsicas so (RUP, 2003):


I. Gerenciamento de recursos, otimizao de controle e
processo.
II. Desenvolvimento completo do componente e teste dos
critrios de avaliao definidos.
III. Avaliao dos releases do produto de acordo com os
critrios de aceitao para a viso.

46
Ao final desta etapa, temos o terceiro Marco (milestone), o Initial
Operational Capability Milestone, onde os seguintes resultados devem ser
apresentados (QUADROS, 2002):

O produto (software) completamente operacional.

Os manuais do produto.

O marco Capacidade Operacional Inicial determina se o produto


est pronto para ser implantado em um ambiente de teste beta (RUP, 2003).

5.5. Fase de Transio


Nesta fase, o produto j foi entregue e so feitas as
manutenes corretivas e as otimizaes de pequeno porte (que no envolvam
uma completa reconstruo do software) (QUADROS, 2002).
O foco da Fase de Transio assegurar que o software esteja
disponvel para seus usurios finais. A Fase de Transio pode atravessar
vrias iteraes e inclui testar o produto em preparao para release e ajustes
pequenos com base no feedback do usurio. Nesse momento do ciclo de vida,
o feedback do usurio deve priorizar o ajuste fino do produto, a configurao, a
instalao e os problemas de usabilidade; todos os problemas estruturais mais
graves devem ter sido trabalhado muito antes no ciclo de vida do projeto (RUP,
2003).
No fim do ciclo de vida da Fase de Transio, os objetivos
devem ter sido atendidos e o projeto deve estar em uma posio para
fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o
incio de outro ciclo de vida no mesmo produto, conduzindo nova gerao ou
verso do produto. Para outros projetos, o fim da Transio pode coincidir com
uma liberao total dos artefatos a terceiros que podero ser responsveis pela
operao, manuteno e melhorias no sistema liberado (RUP, 2003).
A Fase de Transio entra quando uma baseline estiver
desenvolvida o suficiente para ser implantada no domnio do usurio final. Isso
normalmente requer que algum subconjunto usvel do sistema tenha sido
concludo com nvel de qualidade aceitvel e documentao do usurio, de

47
modo que a transio para o usurio fornea resultados positivos para todas as
partes (RUP, 2003).
Segundo RUP (2003) os objetivos principais da Fase de
Transio so:
a) Teste beta para validar o novo sistema em confronto com
as expectativas do usurio.
b) Teste beta e operao paralela relativa a um sistema
legado que est sendo substitudo.
c) Converso de bancos de dados operacionais.
d) Treinamento de usurios e equipe de manuteno.
e) Introduo a marketing, distribuio e equipe de vendas.
f) Engenharia voltada para implantao, como preparao,
empacotamento e produo comercial, introduo a vendas, treinamento de
pessoal em campo.
g) Atividades de ajuste, como correo de erros, melhoria
no desempenho e na usabilidade.
h) Avaliao das baselines de implantao tendo como
base a viso completa e os critrios de aceitao para o produto.
i) Obteno de auto-suportabilidade do usurio.
j) Obteno do consentimento dos envolvidos de que as
baselines de implantao esto completas.
k) Obteno do consentimento dos envolvidos de que as
baselines de implantao so consistentes com os critrios de avaliao da
viso.

E as suas atividades bsicas so (RUP, 2003):


I. Executar planos de implantao.
II. Finalizar o material de suporte para o usurio final.
III. Testar o produto liberado no local do desenvolvimento.
IV. Criar um release do produto.
V. Obter feedback do usurio.
VI. Ajustar o produto com base em feedback.
VII. Disponibilizar o produto para os usurios finais.

48
No fim na etapa de transio est o quarto marco mais
importante do projeto, o Product Release Milestone. Onde so apresentados os
seguintes resultados (QUADROS, 2002):

Distribuio do produto para Beta-testers.

Operao em paralelo com sistemas legados do cliente


(legacy system).

Com base na anlise feita neste Marco, a empresa poder


decidir finalmente pela disponibilizao do produto para os clientes. Ao final do
projeto, deve ser feita tambm uma reviso do cronograma fsico-financeiro de
forma a avaliar a adequao final do projeto com relao ao planejamento
inicial. A fase de transio poder, dependendo do feedback dos usurios,
coincidir com o incio de um novo ciclo de desenvolvimento (QUADROS, 2002).

5.6. Definio das Tarefas e Atividades


Com base no Processo Unificado de desenvolvimento de
software, apresentado na seo anterior este trabalho vai ater-se s fases de
concepo e elaborao, deixando as fases de construo e transio para
trabalhos futuros.
A fase de concepo onde se buscam as primeiras informaes
sobre o sistema a ser desenvolvido vai ter as seguintes atividades:

Levantamento de requisitos

Organizao dos requisitos.

A etapa de levantamento de requisitos corresponde a buscar


junto ao usurio, seus sistemas e documentos, todas as informaes possveis
sobre as funes que o sistema deve executar e as restries sob as quais o
sistema deve operar. O produto desta etapa ser o documento de requisitos,
primeiro componente do anteprojeto de software (WAZLAWICK, 2004).
A etapa de organizao dos requisitos serve para estruturar os
requisitos para que possam ser abordados nos ciclos de desenvolvimento.
Grande parte dos requisitos ser acomodada em processos de negcio
conhecidos como casos de uso. Outros requisitos podero ser associados a

49
operaes simples (como cadastros), outros ainda sero meramente consultas.
Os casos de uso, cadastros e consultas sero abordados nos diferentes ciclos,
priorizando-se os elementos mais crticos (normalmente casos de uso), e
deixando-se para o final os mais elementares (cadastros e consultas)
(WAZLAWICK, 2004).
A fase de elaborao se inicia com uma subfase anlise e
prossegue com uma subfase de projeto. A subfase de anlise em si comporta
trs atividades distintas realizadas na seguinte ordem (WAZLAWICK, 2004):

Expanso dos casos de uso e determinao dos eventos


de sistema.

Construo do modelo conceitual.

Elaborao dos contratos de operaes de sistema.

A expanso dos casos de uso corresponde ao aprofundamento


da anlise de requisitos. J a modelagem conceitual corresponde anlise de
domnio em seus aspectos estticos. Por fim, a elaborao dos contratos
corresponde especificao funcional dos aspectos dinmicos da anlise de
domnio (WAZLAWICK, 2004).
A subfase de projeto pode se dividir em diversas tarefas com
objetivos distintos WAZLAWICK (2004). As tarefas sero:

Projeto da camada de domnio.

Projeto da camada de interface.

Projeto da camada de persistncia.

O projeto da camada de domnio compe-se basicamente de


duas atividades: definir os diagramas de colaborao e elaborar o diagrama de
classes de projeto (WAZLAWICK, 2004).
O projeto da camada de interface mostra como manter a
independncia entre a camada de domnio e a interface do software. O projeto
da camada de persistncia mostra como implementar um sistema de
persistncia que automatiza o salvamento e a recuperao de dados em disco
(WAZLAWICK, 2004).

50

6. CONCEPO
6.1. Levantamento de Requisitos
Na fase de concepo ou iniciao, a anlise de requisitos
rpida e genrica: feita em extenso e no em profundidade. O analista deve
entender a extenso do que o sistema deve fazer, mas sem detalhar como ele
vai fazer (WAZLAWICK, 2004).
Esta fase produz dois documentos: a viso geral do sistema e
os requisitos funcionais e no-funcionais.

6.1.1. Viso Geral do Sistema


A viso geral do sistema, ou sumrio executivo, um
documento que descreve aquilo que se consegue descobrir de relevante sobre
o sistema aps as conversas com clientes e usurios. No so propostas
regras aqui sobre como deve ser escrito esse documento. Mas sugere-se que
no seja longo demais. Uma a duas pginas so suficientes para descrever de
maneira resumida a maioria dos sistemas. apenas uma descrio
desestruturada, onde existem informaes de nvel gerencial e de nvel
operacional (WAZLAWICK, 2004).
A seguir apresentada a viso geral do sistema seqenciador
MIDI.
Software Seqenciador MIDI (Viso Geral do Sistema)
proposto o desenvolvimento de um software seqenciador
MIDI que tenha o uso efetivo da informao musical codificada para a
pesquisa. Contemplar todas as caractersticas bsicas principais pesquisadas
que um software seqenciador MIDI contm atualmente. Estas funcionalidades
so encontradas em janelas como o Notation View, Mixer, Song View, Piano
View, Piano Roll, Track View, Event View, Controller View. Tambm ter a
possibilidade de gravaes em trilhas distintas, tanto de udio digital quanto de
seqncias MIDI. Sendo o objetivo principal ter o diferencial de trabalhar com a

51
informao MIDI propriamente dita, ou seja, armazenamento e recuperao
das mensagens MIDI em um banco de dados, e conseqentemente usufruir
das facilidades do mesmo para efetuar pesquisas pela informao musical
desejada. Outro objetivo ter uma quantizao mais inteligente, que a
ferramenta onde permite acertar o tempo adequado das notas. E por fim ter-se
uma interface com tima usabilidade seguindo critrios ergonmicos.
Utilizando-se de ferramentas freewares para todo o desenvolvimento.

6.1.2. Requisitos
Os requisitos so a definio do que o programa precisa fazer
dentro de quais restries ANQUETIL (2002). E, de acordo com WAZLAWICK
(2004), os requisitos podem ser classificados em duas grandes categorias:
a) Os requisitos funcionais correspondem listagem de tudo
que o sistema deve fazer.
b) Os requisitos no-funcionais so restries colocadas sobre
como o sistema deve realizar seus requisitos funcionais.

Os requisitos funcionais podem ser ainda classificados em dois


grupos:
a) Os requisitos funcionais evidentes, que so efetuados com
conhecimento do usurio. Esses requisitos usualmente correspondero a
eventos do sistema e respostas do sistema, ou seja, qualquer troca de
informao que ocorram pela interface do sistema com o meio exterior.
b) Os requisitos funcionais ocultos que so efetuados pelo
sistema sem o conhecimento explicito do usurio.

Os requisitos no-funcionais podem ser classificados em


obrigatrios e desejados, isto , aqueles que devem ser obtidos de qualquer
maneira e aqueles que podem ser obtidos caso isso no cause maiores
transtornos no processo de desenvolvimento.

52
Alm

disso,

os

requisitos

no-funcionais

podem

ser

classificados por atributo: se so requisitos de interface, de implementao, de


eficincia, de tolerncia a falhas, etc.
Ainda em relao aos requisitos no-funcionais, existem
aqueles diretamente associados a uma funo e outros que so gerais para o
sistema. Normalmente ser til ter duas tabelas: uma que relacione os
requisitos funcionais e suas restries associadas e outra que relacione os
requisitos

no-funcionais

gerais,

tambm

chamados

de

requisitos

suplementares.
Uma ltima classificao til para os requisitos no-funcionais
indicar se so permanentes ou transitrios (WAZLAWICK, 2004).
Como se observa na tabela 6.1.2a, onde temos as descries
dos requisitos. Onde, F1 quer dizer Funcional 1, ou seja, o Requisito Funcional
1 seguido do seu ttulo. Pode ser oculto ou no, isso quer dizer se um
requisito que o usurio vai ver ou apenas para o sistema. Alm da descrio
do dado requisito funcional e a listagem dos requisitos no-funcionais (NF)
relacionados ao requisito funcional em questo, a sua categoria, e se ele
desejvel e permanente.
Tabela 6.1.2a Levantamento de requisitos (WAZLAWICK, 2004)
Oculto ( )
F1 Registra emprstimos
Descrio: O sistema deve registrar emprstimos de fitas, indicando o cliente e
as fitas que foram emprestadas, bem como a data do emprstimo e o valor
previsto para pagamento na devoluo.
Requisitos No-Funcionais
Nome
NF1.1
Controle
Acesso

Restrio

Categoria

A funo s pode ser Segurana


de acessada por usurio
com
perfil
de
operador ou superior.
NF1.2
As fitas devem ser Interface
Identificao identificadas por um
de Fitas
cdigo de barras.
NF1.3
O cliente dever ser Interface
Identificao identificado a partir
do Cliente
de seu nome.

Desejvel

Permanente

( )

(X)

( )

(X)

(X)

( )

53
NF1.4 Tempo O
tempo
para Performance
de Registro
registro de cada fita
deve ser inferior a um
segundo.
NF1.5 Janela Todas as funes Interface
nica
relacionadas
a
emprstimos devem
ser efetuadas em
uma nica janela.

(X)

( )

(X)

( )

A seguir so apresentas as tabelas com os requisitos levantados para o


software Seqenciador MIDI.

Tabela 6.1.2b Requisito funcional 1 e requisitos no-funcionais.


Oculto ( )
F1 Gravao de uma seqncia MIDI
Descrio: O sistema deve gravar uma seqncia MIDI do instrumento que esteja conectado no computador.

Requisitos No-Funcionais
Nome

Restrio

NF1.1 Conexo MIDI

Dever ter uma interface de configurao Configurao


para conexes MIDI.

( )

(X)

NF1.2 Gravao em trilhas

Ter a opo para a escolha da trilha.

Interface

( )

(X)

de O usurio poder a qualquer momento Interface


interromper/prosseguir a gravao.

( )

(X)

Cada trilha deve ser mostrada em uma interface


janela diferente.

( )

(X)

( )

( )

NF1.3
Possibilidade
interrupo
NF1.4 Janelas Distintas

Categoria

Desejvel

Permanente

54

Tabela 6.1.2c Requisito funcional 2 e requisitos no-funcionais.


Oculto ( )
F2 Gravao de udio digital
Descrio: O sistema dever ter a opo de tambm gravar udio digital atravs de um dispositivo de udio que o
computador tenha.
Requisitos No-Funcionais
Nome
NF2.1 Configurao
dispositivo de udio

Restrio

NF2.4 Janelas Distintas

Desejvel

Permanente

( )

(X)

Interface

( )

(X)

de O usurio poder a qualquer momento Interface


interromper/prosseguir a gravao.

( )

(X)

Cada trilha deve ser mostrada em uma Interface


janela diferente.

( )

(X)

( )

( )

de Dever ter uma interface de configurao Configurao


dos dispositivos de udio.

NF2.2 Gravao em trilhas

NF2.3
Possibilidade
interrupo

Categoria

Ter a opo para a escolha da trilha.

55

Tabela 6.1.2d Requisito funcional 3 e requisitos no-funcionais.


Oculto ( X )

F3 Gerao de partitura
Descrio: O sistema ir gerar a partitura de uma seqncia MIDI.

Requisitos No-Funcionais
Nome
NF3.1 Partitura
trilha MIDI

Restrio
de

Categoria

uma Ser gerada a partitura de uma seqncia Especificao


MIDI de uma trilha

NF3.2 Partitura da msica

Ser gerada a partitura da msica, ou seja, Interface


das trilhas que sejam seqncia MIDI.

Desejvel

Permanente

( )

(X)

(X)

( )

( )

( )

( )

( )

( )

( )

56

Tabela 6.1.2e Requisito funcional 4 e requisitos no-funcionais.


F4 Exibir a seqncia MIDI na partitura
Descrio: O sistema exibir a seqncia MIDI de uma trilha ou de todas as trilhas da msica.

Oculto ( )

Requisitos No-Funcionais
Nome
NF4.1
trilha

Restrio
Partitura

de

Categoria

uma Ter uma janela com a exibio da partitura Interface


da trilha MIDI selecionada.

NF4.2 Partitura da msica

Ter uma janela com a exibio da partitura Interface


de todas as trilhas MIDI da msica.

Desejvel

Permanente

( )

(X)

( )

(X)

( )

( )

( )

( )

( )

( )

57

Tabela 6.1.2f Requisito funcional 5 e requisitos no-funcionais.


Oculto ( )
F5 Informar o valor das notas na partitura
Descrio: O sistema tambm dever ser capaz de gerar a partitura atravs do usurio informando manualmente as notas.

Requisitos No-Funcionais
Nome

Restrio

Categoria

Desejvel

Permanente

NF5.1 Informao das notas Haver botes nas quais o usurio clicar e Interface
depois informar na pauta o seu respectivo
valor.

( )

(X)

NF5.2 Digitao das notas

(X)

( )

( )

(X)

(X)

( )

(X)

( )

NF5.3 Valores default

O usurio tambm poder informar as notas Interface


por teclas de atalho, pr-configuradas.

A pauta j ter alguns valores j pr- Configurao


definidos, como clave de Sol, e compasso
4/4. Mas podendo altera-los.
NF5.4 Desfazer alteraes Ter uma lista com as ultimas alteraes, Usabilidade
assim o usurio poder selecionar qual ao
deseja desfazer.
NF5.5 Configuraes da Todas as funes relacionadas a pauta Configurao
pauta
podero ser configuradas.

58

Tabela 6.1.2g Requisito funcional 6 e requisitos no-funcionais.


Oculto ( )
F6 Alterar os valores das notas na partitura
Descrio: O usurio poder alterar os valores das notas na partitura, de seqncias MIDI j gravadas ou mesmo da
seqncia que ele esteja criando.
Requisitos No-Funcionais
Nome

Restrio

Categoria

Desejvel

Permanente

NF6.1 Alterao atravs dos Ter botes com valores pr-definidos para Interface
botes
alterao na partitura.

( )

(X)

NF6.2
Alterao Ter a opo para a escolher determinado Interface
aumentando ou diminuindo elemento dentro da pauta e aumentar ou
a intensidade.
diminuir seu respectivo valor.

(X)

( )

( )

( )

( )

( )

( )

( )

59

Tabela 6.1.2h Requisito funcional 7 e requisitos no-funcionais.


F7 Ajustar efeitos nas trilhas (timbre, pan, volume, pitch, etc...)
Descrio: O usurio poder ajustar vrios efeitos com relao s trilhas.

Oculto ( )

Requisitos No-Funcionais
Nome

Restrio

Categoria

Desejvel

Permanente

NF7.1 Ajuste de efeito da Haver uma mesa de controle para ajuste Configurao
trilha
dos efeitos de uma trilha especifica.

( )

(X)

NF7.2 Ajuste de efeito da Haver uma mesa de controle para ajuste Configurao
msica
dos efeitos com relao a toda msica.

( )

(X)

NF7.3 Janelas Distintas

(X)

( )

( )

( )

( )

( )

O ajuste de efeitos de uma trilha e de toda a Interface


msica ser efetuada em janelas distintas

60

Tabela 6.1.2i Requisito funcional 8 e requisitos no-funcionais.


Oculto ( )
F8 Informar as notas e seus valores atravs de um teclado e de um brao de violo virtual
Descrio: O usurio poder no sistema informar as notas de uma seqncia MIDI atravs de um teclado e brao do violo
virtual, com seu respectivo, tempo, valor e durao.
Requisitos No-Funcionais
Nome

Restrio

Categoria

NF8.1 Teclado Virtual

Haver um teclado como se fosse um real, Interface


com o mesmo esquema de teclas.

( )

(X)

NF8.2 Violo Virtual

Haver um violo como se fosse um real, Interface


com o mesmo esquema de cordas.

( )

(X)

NF8.3 Emitir o som das Ao definir a nota, o sistema emitira o Interface


notas
respectivo som.

(X)

(X)

NF8.4 Configurao
instrumento

(X)

( )

( )

( )

do Pode-se mudar a afinao do instrumento e Configurao


afinao das cordas (violo).

Desejvel

Permanente

61

Tabela 6.1.2j Requisito funcional 9 e requisitos no-funcionais.


F9 Exibir informaes das trilhas da msica.
Descrio: O sistema exibir todas as informaes das trilhas da msica, seja elas udio ou MIDI.

Oculto ( )

Requisitos No-Funcionais
Nome

Restrio

Categoria

Desejvel

Permanente

NF9.1 Trilhas da msica

Ter a exibio de todas as trilhas com seus Interface


valores que fazem parte da msica.

( )

(X)

NF9.2 Informaes da trilha Ser exibida informao das trilhas, tais Interface
como se MIDI ou udio.

( )

(X)

( )

( )

( )

( )

( )

( )

62

Tabela 6.1.2k Requisito funcional 10 e requisitos no-funcionais.


Oculto ( )
F10 Listar e editar toda a informao de uma seqncia MIDI de uma trilha
Descrio: O sistema exibir com as informaes de uma seqncia MIDI de determinada trilha para edio.

Requisitos No-Funcionais
Nome

Restrio

Categoria

NF10.1 Exibir informaes

Ter a exibio dos dados como vem da Interface


mensagem MIDI em uma janela.

Desejvel

Permanente

( )

(X)

NF10.2 Editar mensagem Ser possvel editar cada dado exibido da Configurao
MIDI.
mensagem MIDI.

( )

(X)

NF10.3
Verificao
da Todos os dados a serem entrados na edio Confiabilidade
edio da mensagem MIDI da mensagem MIDI sero verificados.

(X)

( )

( )

( )

( )

( )

63

Tabela 6.1.2l Requisito funcional 11 e requisitos no-funcionais.


Oculto ( )
F11 Exibir uma seqncia MIDI num grfico ou histograma
Descrio: O sistema exibir as alteraes de valor de determinado dado de uma seqncia MIDI num grfico ou
histograma.
Requisitos No-Funcionais
Nome

Restrio

NF11.1 Exibio dos dados

Os dados no grfico devero ser exibidos Interface


em uma janela.

( )

(X)

do Poder ser escolhido um elemento MIDI da Interface


seqncia para ser exibido no grfico.

( )

(X)

( )

(X)

( )

( )

( )

( )

NF11.2
elemento

Escolha

Categoria

Desejvel

Permanente

64

Tabela 6.1.2m Requisito funcional 12 e requisitos no-funcionais.


F12 Alterao de valores de uma seqncia pelo grfico ou histograma
Descrio: O sistema poder alterar as informaes que foram exibidas num grfico ou histograma.

Oculto ( )

Requisitos No-Funcionais
Nome

Restrio

Categoria

Desejvel

Permanente

NF12.1 Tipo de alterao

Poder alterar qualquer elemento MIDI, Configurao


atravs desta janela no grfico.

( )

(X)

NF12.2 Forma de alterao

A alterao ser clicando e arrastando com Interface


o mouse para o prximo valor.

( )

(X)

( )

( )

( )

( )

( )

( )

65

Tabela 6.1.2n Requisito funcional 13 e requisitos no-funcionais.


Oculto ( )
F13 Reproduo de uma seqncia MIDI
Descrio: O sistema reproduzir uma seqncia MIDI no prprio computador ou em um teclado conectado.

Requisitos No-Funcionais
Nome

Restrio

NF13.1 Dispositivo de som

O sistema dever verificar quais


dispositivos
de
som instalados
computador.

Categoria
os Confiabilidade
no

NF13.2 Reproduo do som O sistema reproduzir a seqncia Interface


desejada considerando as informaes
MIDI.
NF13.3 Reproduo MIDI O sistema poder reproduzir a mensagem Configurao
MIDI no somente no computador, mas
no no software
envi-la para outro dispositivo.
NF13.4
Interrupo
da A reproduo da seqncia MIDI poder ser Desempenho
reproduo
interrompida a qualquer momento.

Desejvel

Permanente

( )

(X)

( )

(X)

( )

(X)

(X)

( )

( )

( )

66

Tabela 6.1.2o Requisito funcional 14 e requisitos no-funcionais.


Oculto ( )
F14 Reproduo da msica com todas as trilhas
Descrio: O sistema reproduzir o som da msica com todas as suas trilhas, considerando as trilhas de udio e trilhas de
MIDI.
Requisitos No-Funcionais
Nome

Restrio

NF14.1 Dispositivo de som

O sistema dever verificar quais


dispositivos
de
som
instalados
computador.

Categoria

Desejvel

Permanente

( )

(X)

NF14.2 Reproduo do som O sistema reproduzir a msica tanto das Interface


trilhas em MIDI quanto das de udio.

( )

(X)

NF14.3
Interrupo
reproduo

(X)

( )

( )

( )

( )

( )

os Confiabilidade
no

da A reproduo da seqncia MIDI poder ser Desempenho


interrompida a qualquer momento.

67

Tabela 6.1.2p Requisito funcional 15 e requisitos no-funcionais.


Oculto ( X )
F15 Envio de uma seqncia MIDI para um instrumento
Descrio: O sistema poder enviar as informaes MIDI de uma seqncia em uma trilha para o dispositivo conectado.

Requisitos No-Funcionais
Nome

Restrio

Categoria

NF15.1 Conexo MIDI

Dever ter uma interface de configurao Configurao


para conexes MIDI.

Desejvel

Permanente

( )

(X)

NF15.2
Verificao
dispositivo

do Verificar se o dispositivo conectado pode Confiabilidade


reproduzir MIDI.

( )

(X)

NF15.3 Possibilidade
interrupo

de O usurio poder a qualquer momento Interface


interromper/prosseguir o envio da seqncia
MIDI.

( )

(X)

( )

( )

( )

( )

68

Tabela 6.1.2q Requisito funcional 16 e requisitos no-funcionais.


Oculto ( )
F16 Pesquisa por uma seqncia MIDI armazenada
Descrio: O sistema poder efetuar pesquisas por informaes musicais em seqncias MIDI armazenadas.

Requisitos No-Funcionais
Nome

Restrio

NF16.1 Tipo da pesquisa

A pesquisa poder ser efetuada por Especificao


qualquer informao musical que o MIDI
possui.

NF16.2 Opes de pesquisa A pesquisa poder ter algumas restries


impostas pelo usurio, como tipo de
instrumento, por exemplo.
NF16.3
Resultado
da Dada a pesquisa feita, o sistema vai
pesquisa
informar qual trilha e msica foi encontrada
tal ocorrncia.
NF16.4 Tempo de Pesquisa A pesquisa ter um limite de 15 segundos
de durao, podendo prosseguir se usurio
assim desejar.
NF16.5
Interrupo
da O usurio poder parar a qualquer momento
pesquisa
a pesquisa.

Categoria

Desejvel

Permanente

( )

(X)

Especificao

( )

(X)

Interface

( )

(X)

Desempenho

(X)

( )

Interface

(X)

( )

69

Tabela 6.1.2r Requisito funcional 17 e requisitos no-funcionais.


Oculto ( )
F17 Quantizao de uma seqncia MIDI
Descrio: O sistema dever quantizar um intervalo de uma seqncia MIDI seguindo algum critrio definido pelo usurio.

Requisitos No-Funcionais
Nome

Restrio

Categoria

Desejvel

Permanente

( )

(X)

O sistema dever ter a opo de desfazer a Interface


ltima quantizao efetuada.

(X)

( )

NF17.3
Tempo
quantizao

de O tempo para quantizao no dever Desempenho


ultrapassar 15 segundos.

(X)

( )

NF17.4
ao

da Dever ser solicita uma confirmao ao Interface


usurio da quantizao efetuada.

(X)

( )

( )

( )

NF17.1
parmetros

Informando O sistema solicitar em qual elemento de Configurao


durao de tempo dever ser quantizado no
intervalo da seqncia MIDI.

NF17.2 Desfazer ao

Confirmao

70

Tabela 6.1.2s Requisitos suplementares.


Requisitos Suplementares
Nome
S1 Tipo de Interface

S2
Armazenamento
Dados
S3
Ferramentas
Desenvolvimento

Restrio

Categoria

As interfaces do sistema devem ser Interface


implementadas
seguindo
critrios
ergonmicos de usabilidade.
de A camada de persistncia deve ser Persistncia
implementada Banco de Dados relacional/
orientado a objetos.
de Devero
ser
utilizadas
ferramentas Implementao
freewares, tais como Java, Ajax, PHP,
Postgres.

Desejvel

Permanente

(X)

( )

( )

(X)

( )

(X)

71

72

6.2. Organizao dos Requisitos


Aps os requisitos serem levantados, cabe organiz-los em
grupos correlacionados. Os requisitos podem ser agrupados do seguinte modo
(WAZLAWICK, 2004):
a) Casos de Uso.
b) Conceitos.
c) Consultas.

6.2.1. Organizao dos Requisitos em Casos de Uso


Na fase de concepo necessrio identificar os grandes
processos da empresa. Eles so chamados de casos de uso e devem cobrir as
principais atividades da empresa ligadas ao sistema que ser implementado. O
objetivo de listar os casos de uso levantar informaes sobre como o sistema
interage com possveis usurios e quais consultas e transformaes da
informao so necessrias alm daquelas j identificadas na fase de
levantamento de requisitos. Cada caso de uso ser associado a um conjunto
de requisitos funcionais do sistema. Para no definir processos muito longos ou
muito triviais como casos de uso, pode-se levar em conta os seguintes limites
(WAZLAWICK, 2004):
a) Um caso de uso deve ser monossesso, isto , executado
em uma nica interao e no se estendendo ao longo de vrios dias.
b) Um caso de uso deve ser interativo, com informaes fluindo
para dentro e para fora do sistema. Operaes elementares como cadastrar um
cliente ou alterar informaes da fita dificilmente sero casos de uso, pois so
efetuadas em um nico passo.
c) Um caso de uso deve produzir uma alterao consistente na
informao armazenada. Isso exclui a possibilidade de consultas serem casos
de uso, pois no alteram a informao, apenas exibem os dados j existentes
com alguma formatao especfica. Alm disso, um fragmento de um caso de
uso que no produza uma informao consistente no poder ser considerado
um caso de uso. Deve-se considerar que o caso de uso uma transao com

73
incio e fim bem delimitados. Por bem delimitado entenda-se que o usurio
poderia ativar o sistema, executar o caso de uso e desligar o sistema em
seguida, e a operao estaria completa e consistente. Excluem-se desse
processo procedimentos de login e logoff.
Os casos de uso identificados para o software seqenciador
encontram-se na figura 6.2.1, que so gravar msica e editar msica.

Figura 6.2.1 Casos de Uso.


As descries dos casos de uso encontradas esto na tabela
6.2.1.
Nome

Tabela 6.2.1 Descrio dos Casos de Uso.


Atores Descrio
Ref. Cruzadas

Gravar
Msica

Msico

Editar
Msica

Msico

O msico vai gravar a msica


tanto em udio digital ou em MIDI,
e em MIDI podendo ser de um
instrumento conectado ao
computador ou pelo prprio
software.
O msico poder editar a msica
dentre os recursos que vo estar
disponveis no software.

F1, F2, F3, F8

F5, F6, F7, F8,


F10, F12, F17

74

6.2.2. Organizao dos Requisitos em Funo de Conceitos


Algumas operaes relativamente simples e elementares (de
um nico passo) no devem ser consideradas casos de uso por si s: no h
necessidade de estudar seu processo interativo que de um nico passo.
Alm disso, essas operaes elementares possivelmente podero fazer parte
de algum caso de uso propriamente dito (WAZLAWICK, 2004).
Uma vez identificados os conceitos principais, pode-se definir
uma tabela (Tabela 6.2.2a) que indicar se eles devem sofrer insero (I),
alterao (A), excluso (E) ou consulta (C).

Tabela 6.2.2a Listagem de Conceitos e Operaes de Manuteno


(WAZLAWICK, 2004)
Conceito I A E C Observao
Ref. Cruzada
Cliente
X X X X S possvel excluir se no houver F13
emprstimos associados.

Os conceitos (classes em um nvel mais geral) do software


seqenciador MIDI est na figura 6.2.2.

Figura 6.2.2 Conceitos.

75

A seguir na tabela 6.2.2b apresenta a listagem dos conceitos encontrados.

Conceito
Msica

Trilha
MIDI
udio

Tabela 6.2.2b Listagem dos conceitos.


I A E C Observao
X X A insero e a alterao de uma
msica feita atravs dos casos de
uso gravar e editar msica.
X X X X A insero s pode ocorrer se tiver
associado com uma msica.
X X X X A insero s pode ocorrer se tiver
associado com uma trilha.
X X X X A insero s pode ocorrer se tiver
associado com uma trilha.

Ref. Cruzada
F14

F7, F9
F1,F4,F6,F10,
F11,F12,F16
F2

6.2.3. Organizao dos Requisitos em Consultas


A identificao correta dos relatrios desejados na fase de
concepo pode ajudar muito no levantamento dos requisitos e na elaborao
do sistema. E no necessrio trat-los como casos de uso porque o resultado
ser o mesmo todas as vezes, variando apenas os parmetros e resultados
exibidos. Alm disso, um dos princpios de casos de uso que eles produzem
no sistema uma mudana de estado, ou seja, uma modificao na informao
armazenada. Desse modo, os relatrios e consultas s sero listados na fase
de concepo, visando uma construo em etapa posterior (WAZLAWICK,
2004).
A tabela 6.2.3 contm a listagem de consultas do software
seqenciador MIDI.
Tabela 6.2.3 Listagem de Consultas.
Nome
Referncias Cruzadas
Trilhas de determinada msica
F9
Mensagens MIDI pela trilha
F4, F10, F11
Mensagens MIDI pelo tipo
F16
udio pela trilha
F9

76

6.3. Marco dos Objetivos de Ciclo de Vida


Dentre todos os objetivos a alcanar no final da fase de
Concepo, tem-se os seguintes resultados alcanados:

O sumrio executivo ou documento de viso geral do


sistema.

Documento com o levantamento dos requisitos funcionais


e no-funcionais do sistema

Caso de uso inicial (descrito utilizando a UML).

Identificao dos conceitos principais.

A identificao dos relatrios e consultas desejados.

A prxima etapa a ser realizada ser a fase de Elaborao que


dividide-se em duas sub-fases: anlise e projeto.
Na sub-fase de anlise, ocorrero as tarefas de expanso dos
casos de uso, construo do modelo conceitual e elaborao dos contratos e
operao de sistema. E na de projeto, as atividades a serem realizadas sero a
camada de domnio, interface e persistncia.

77

7. ELABORAO
A fase de elaborao contm duas sub-fases. A sub-fase de
anlise prossegue com a sub-fase de projeto. E a sub-fase de anlise
subdivide-se em trs atividades, a expanso dos casos de uso e determinao
dos eventos de sistema, a construo do modelo conceitual e a elaborao dos
contratos e operaes de sistema.
A seguir, esta a expanso dos casos dos casos de uso
encontrados na fase de concepo.

7.1. Expanso dos Casos de Uso


Segundo WAZLAWICK (2004), a expanso dos casos de uso
corresponde ao aprofundamento da anlise de requisitos. Quando se est
expandindo um caso de uso preciso proceder a um exame detalhado do
processo de negcio. Deve-se descrever o caso de uso passo a passo: como
ele ocorre, como a interao entre os usurios e o sistema. Ele descrito
com as seguintes sees:
Atores: A seo atores lista quais tipos de entidades do mundo
real interagem com o sistema por meio do caso de uso. Atores podem ser tipos
de pessoas como clientes, fornecedores, vendedores, operadores, alm de
poder ser classes de sistemas externos ao sistema desenvolvido, mas que
interagem com ele.
Interessados (stackholdens): nem sempre apenas os atores
so interessados em um caso de uso. Outros setores da empresa podero ter
interesse nos resultados produzidos pelo caso de uso.
Precondies: so fatos considerados verdadeiros antes do
incio do caso de uso. No se deve confundir precondies com as excees,
em virtude de essas ltimas no serem necessariamente verdadeiras antes do
incio do caso de uso. As excees podem ocorrer durante a execuo
justamente porque no se pode garantir que elas no ocorram.
Ps-condies: estabelecem normalmente os resultados do
caso de uso, isto , o que ser verdadeiro aps a execuo do caso de uso.

78
Requisitos Correlacionados: a correlao entre requisitos e
os casos de uso que podem permitir ao analista perceber se ainda existem
requisitos no abordados.
Variaes Tecnolgicas: algumas vezes pode ser interessante
registrar, para a fase de projeto, possveis variaes tecnolgicas que
poderiam ser utilizadas para realizar o caso de uso.
Questes em aberto: questes em que o analista trabalhando
sem a presena do cliente, no sabe como decidir sobre determinado assunto
que pode depender de polticas da empresa.
Fluxo principal: Todos os casos de uso tm passos
obrigatrios. Esses passos envolvem informaes que passam dos atores para
o sistema e do sistema para os atores, sem as quais o caso de uso no faz
sentido ou no pode prosseguir.
Tratamento de excees: depois de descrever o fluxo principal
do caso, devem-se imaginar o que poderia dar errado em cada um dos passos
descritos, gerando assim, os fluxos alternativos responsveis pelas excees.
Variantes: algumas vezes pode ser til representar o caso de
uso de uma forma no to plana. E as variantes so variaes no qual o fluxo
principal pode ter, no tem o status de caso de uso, embora sejam
representadas pelo mesmo smbolo nos diagramas de UML.
A figura 7.1 apresenta o resultado da expanso dos casos de
uso e nas tabelas 7.1a e 7.1b a descrio destas.

Tabela 7.1a Expanso do caso de uso Gravar Msica.


Caso de Uso: Gravar Msica
Atores: Msico
Interessados: Usurios do software.
Precondies: Os dispositivos de hardware devero estar previamente
configurados: placa de som, entrada/sada para instrumento MIDI.
Ps-condies: A entrada da msica tanto pelo software ou por instrumento
musical conectado pela entrada MIDI sero armazenadas no banco de dados.
Requisitos correlacionados: F1, F2, F8.
Variaes Tecnolgicas: Os formatos de msica a serem gravados sero a

79
informao MIDI e o udio digital em formato WAV. No entanto, uma msica
pode ter em vrios canais, com tipos distintos de formatos. E neste pode-se
abranger outros formatos como WMV e MP3.
Questes em aberto:
1. Os arquivos em udio digital sero armazenados no banco de dados
com o formato BLOB ou apenas a sua referncia (caminho de onde se
encontra)?
Fluxo Principal:
1. O msico seleciona opo de nova gravao.
2. O msico escolhe qual formato da gravao. MIDI ou udio digital.
3. O msico comea a gravar a trilha da msica.
4. [EV] O msico toca o instrumento ou informa as notas para a gravao
da seqncia da trilha (udio ou MIDI).
5. [EV] O msico informa os dados relacionados a trilha da msica e salva
as informaes no banco de dados.
6. [RS] O sistema informa que os dados da trilha foram salvos
corretamente.
7. A gravao da trilha esta finalizada e o sistema est pronto para novas
interaes.
Tratamento de excees:
3a. Dispositivo de udio no configurado.
3a.1 [RS] O sistema informa que no tem nenhum dispositivo de udio
configurado.
3a.2 [EV] O msico configura o dispositivo corretamente.
3a.3 Retorna ao fluxo principal no passo 3.
3b. Nenhum dispositivo MIDI configurado.
3b.1 [EV] o msico configura a conexo MIDI.
3b.2 Retorna ao passo 3.
Variantes
4.1 Gravao instrumento MIDI:
4.1.1 [EV] O msico comea a execuo do instrumento MIDI.
4.1.2 [RS] As informaes MIDI aparecem na tela do sistema.

80
4.2 Gravao MIDI pelo software
4.2.1 [EV] O msico informa a nota, a intensidade, durao entre outras
informaes musicais disponveis para a gravao da msica.
4.2.2 [RS] As informaes MIDI aparecem na tela do sistema.

4.3 Gravao de udio digital:


4.3.1 [EV] O msico comea a execuo do instrumento.
4.3.2 [RS] As informaes aparecem na tela do sistema.

Tabela 7.1b Expanso do de caso uso Editar Msica.


Caso de Uso: Editar Msica
Atores: Msico
Interessados: Usurios do software.
Precondies: A trilha da msica escolhida para edio j deve estar
previamente cadastrada no banco de dados.
Ps-condies: As alteraes e efeitos ajustados da trilha de acordo com o
usurio sero salvas.
Requisitos correlacionados: F5, F6, F7, F8, F12, F17.
Variaes Tecnolgicas: tipos diferentes de efeitos a ser aplicados as trilhas.
Questes em aberto:
2. Todas as informaes de uma seqncia MIDI podem ser alteradas?
3. Todos os usurios do sistema podem alterar qualquer informao na
msica?
Fluxo Principal:
1. Dada a msica, o msico escolhe determinada trilha.
2. Nesta trilha, o msico faz as alteraes dentre as opes dadas pelo
sistema.
3. [EV] O msico altera determinada informao musical ou ajusta algum
efeito.
4. [RS] Se o msico optar o software executa a trilha com as novas
alteraes.
5. O msico salva as alteraes da trilha.

81
Tratamento de excees:
2a. Alteraes musicais de uma trilha de udio.
2a.1 [RS] O sistema informa que determinadas alteraes somente so
possveis em uma seqncia MIDI.
2a.2 Retorna ao fluxo principal no passo 2.
Variantes
3.1 Alterao em uma seqncia MIDI:
3.1.1 O msico ajusta algum dado dentre todas as possibilidades que uma
seqncia MIDI permite.

3.2 Alterao de uma trilha de udio:


3.2.1 O msico ajusta algum efeito dentre todas as possibilidades que uma
trilha de udio permite.

A figura 7.1 apresenta a expanso dos casos de uso no seu


respectivo diagrama. Nele, observa-se alm dos casos de uso, gravar msica e
editar msica encontrada na fase anterior de concepo, o acrscimo do caso
de uso chamado de variantes, estes so: variante seqncia MIDI e variante
udio digital.

Tanto no caso de uso gravar msica quanto no editar msica


em um software seqenciado MIDI, as nicas variaes que ocorrem nos
procedimentos de gravao e edio, so os nos casos de MIDI e udio digital.
Ou seja, uma gravao pode ser tanto de udio como de uma seqncia MIDI.

82

Figura 7.1 Casos de Uso expandidos.

7.2. Operaes e Consultas de Sistema


Nesta seo sero apresentadas as operaes e consultas do
sistema da fase de anlise. E como nesta fase no considera ainda os objetos
internos ao sistema, ser necessrio representar o sistema como um nico
objeto, do tipo caixa preta. Porm, poder ser mais til representar o sistema
como dois objetos genricos, indicando dois nveis da futura arquitetura. O
primeiro objeto representa a interface do sistema, ou a classe de aplicao, e
o segundo objeto, mais interno, representa o controlador do sistema, classe
seqenciador. O ator s pode se comunicar diretamente com a aplicao e
esta, por sua vez, comunica-se com o controlador.
Os casos de uso so excelentes fontes para encontrar
operaes e consultas de sistema, embora no sejam as nicas. Nestes,
encontram-se operaes de sistema a partir da observao de aes do

83
usurio que produzem modificaes no sistema (possivelmente estaro
marcadas com [EV], Eventos de Sistema), ou seja, as aes que levam
informao dos atores para o sistema. J as consultas so identificadas por
passos que trazem informao do sistema para os atores (possivelmente
marcada por [RS], Resposta de Sistema). O diagrama de seqncia pode ser
construdo para o fluxo principal do caso de uso e eventualmente tambm para
alguns cenrios com fluxos alternativos. Sendo que o importante nesta fase
no ter o diagrama em si, mas identificar corretamente que operaes e
consultas de sistema so necessrias. A existncia dos diagramas completos
com o fluxo de informaes entre os atores e do sistema para os atores ser
interessante na fase de projeto da interface, mas por enquanto, na anlise,
suficiente saber quais as informaes repassadas dos atores para o sistema e
vice-versa (WAZLAWICK, 2004).
A UML possui um diagrama que pode ser til para representar
eventos de sistema em um cenrio de um caso de uso, nas figuras 7.2a, 7.2b e
7.2c esto representados os diagramas de seqncia dos casos de uso gravar
trilha MIDI, trilha udio e editar trilha. O diagrama de seqncia tem como
elementos

instncias

de

atores,

representados

por

figuras

humanas

esquematizadas, e instncias de objetos constituintes do sistema.


Na figura 7.2a est o diagrama de seqncia do caso de uso
gravar trilha com a variante MIDI. Neste diagrama procura-se descrever todo o
processo de uma gravao de entrada MIDI. Deste a entrada descrita pela
mensagemMIDI que mostra o processo de envio de mensagens MIDI do
instrumento tocado pelo msico para a aplicao e desta para o software,
dentro da rotina chamada iteration, que nada mais do que o loop que se
repete at que haja uma interrupo, at o encerramento ocorrendo com a
finalizao da gravao da trilha MIDI salvando os dados relacionados a ela.
E na figura 7.2b, o diagrama de seqncia com a variante
udio, que muito semelhante ao diagrama da figura 7.2a de gravao de uma
trilha MIDI.
O diagrama de seqncia para editar trilha esta descrito na
figura 7.2c.

84

Figura 7.2a Diagrama de Seqncia gravar trilha MIDI.

Figura 7.2b Diagrama de Seqncia gravar trilha udio.

85

Figura 7.2c Diagrama de Seqncia editar trilha.

7.3. Modelagem Conceitual


Segundo WAZLAWICK (2004), o modelo conceitual deve
descrever a informao que o sistema vai gerenciar. Trata-se de um artefato do
domnio do problema e no do domnio da soluo. Portanto, o modelo
conceitual no deve ser confundido com a arquitetura do software (diagrama de
classes de projeto), pois esta, embora inicialmente derivada do modelo
conceitual, pertence ao domnio da soluo, e, ento, serve a um objetivo
diferente. Tambm no deve ser confundido com o modelo de dados, pois o
modelo de dados enfatiza a representao e a organizao dos dados
armazenados, enquanto o modelo conceitual visa representar a compreenso
da informao e no sua representao fsica.
O modelo conceitual procura mostrar quais so os elementos de
informao tratados pelo sistema, para que mais adiante se possa mostrar
ainda como essa informao transformada pelo sistema a partir das
diferentes requisies do usurio (operaes de sistema).
A figura 7.3 apresenta a modelagem conceitual do seqnciador
MIDI. A obteno desta modelagem partiu dos conceitos encontratos na fase

86
de concepo, que foi a anlise dos dados na sua forma esttica dentro do
dominio do sistema. Como esta fase de sub-anlise (modelagem conceitual)
baseia-se no domnio do problema e no da soluo que sub-fase de projeto
dentro da etapa de elaborao, pode-se obter alguns conceitos a mais do que
a concepo mas no todos que o software deve possuir, estes devero ser
encontrados no diagrama de classes na sub-fse de projeto.
Para tanto por se tratar de um sofware que trabalha com msica
relevante guardar informaes relevantes que se relacionem com a msica
de forma bem organizada, como compositor, artista, lbum e gnero.
Conseqentemente, ter-se um banco de dados conciso e coerente com o
universo musical, proporcionando uma busca na sua forma mais completa
possvel, tratando-se de msica. Nesta modelagem observa-se tambm os
fatos de considerar os comandos MIDI para cada mensagem MIDI de uma
trilha. Ou seja, a preocupao de tratar de cada comando MIDI.

Figura 7.3 Modelagem Conceitual.

87

7.4. Contratos
Nesta seo encontra-se a anlise dos contratos e operaes
de sistema do seqenciador MIDI. Sendo que na fase de expanso dos casos
de uso tambm foram identificadas as operaes e consultas de sistema. As
operaes de sistema correspondem a inseres de informao no sistema
input e as consultas de sistema correspondem ao acesso informao
armazenada output. Cada operao ou consulta desse tipo implica a existncia
de uma inteno por parte do usurio, a qual capturada pelos contratos de
operaes de sistema e nos contratos de consulta de sistema (WAZLAWICK,
2004).
Um contrato de operao de sistema tem pelo menos trs
sees:
a) Precondies.
b) Ps-condies.
c) Excees.

J um contrato para uma consulta de sistema poder ter as


seguintes sees:
a) Precondies.
b) Resultados

Os contratos das tabelas 7.4a a 7.4e so das operaes mais


simples e bsicas de insero, alterao, excluso e consultas. Mais adiante
estaro os contratos de operao e consultas relacionados aos casos de uso.

Tabela 7.4a Contrato cadastraMusica


Classe Seqenciador
Operao: cadastraMusica(nomeM:String, compositorM, artistaM, albumM,
generoM:Int)
Pr:
No existe nenhuma msica com nome = nomeM.
Os cdigos compositorM, artistaM, albumM, generoM j esto vlidos
pois j foram previamente cadastrados.

88
Ps:
Foi criada uma msica e adicionada ao cadastro.
E alteradas as associaes compositorM, artistaM, albumM, generoM.

Tabela 7.4b Contrato alteraMusica


Classe Seqenciador
Operao:

alteraMusica(nomeM:String,

compositorM,

artistaM,

albumM,

generoM:Int)
Pr:
Existe uma msica com nome = nomeM.
Os cdigos compositorM, artistaM, albumM, generoM j esto vlidos
pos j foram previamente cadastrados.
Ps:
E alteradas as associaes compositorM, artistaM, albumM, generoM.

Tabela 7.4c Contrato excluiMusica


Classe Seqenciador
Operao: excluiMusica(nomeM:String)
Pr:
Existe uma msica com nome = nomeM.
Ps:
A msica com nome = nomeM foi destruda, assim como suas trilhas
relacionadas.

Tabela 7.4d Contrato consultaMusica


Classe Seqenciador
Operao: consultaMusica(nomeM:String)
Pr:
Existe uma msica com nome = nomeM.
Ps:
Retorna os dados da msica.

89
Tabela 7.4e Contrato listaMusicas
Classe Seqenciador
Operao: listaMusicas()
Pr:
Ps:
Retorna os nomes de todas as msicas.

A seguir, nas tabelas 7.4f a 7.4i, esto os contratos de operao


e consultas relacionados aos casos de uso. Para elaborao dos mesmos
toma-se como base a expanso dos casos de uso onde se encontram [EV]
Eventos de Sistema e [RS] Respostas de Sistema juntamente com a
modelagem conceitual e os diagramas de seqncia abordados anteriormente.

Tabela 7.4f Contrato gravarMensagem


Classe Seqenciador
Operao: gravarMensagem(mensagemMidi:MIDI)
Pr:
A mensagemMidi uma mensagem MIDI vlida.
Ps:
A mensagemMidi gravada na trilha corrente.

Tabela 7.4g Contrato salvarTrilha


Classe Seqenciador
Operao: salvarTrilha(dadosTrilha:Trilha)
Pr:
Os dadosTrilha so dados vlidos de uma Trilha.
Ps:
Os dadosTrilha so gravados na trilha corrente.

90
Tabela 7.4h Contrato gravarAudio
Classe Seqenciador
Operao: gravarAudio(audio:Audio)
Pr:
O udio uma varivel da classe udio vlido.
Ps:
O udio gravado na trilha corrente.

Tabela 7.4i Contrato alteraTrilha


Classe Seqenciador
Operao: alteraTrilha(valor:MIDI)
Pr:
O valor uma mensagem MIDI vlida.
Ps:
A trilha corrente alterada com valor correspondente.

7.5. Projeto da Camada de Domnio

A partir da modelagem conceitual obteve-se o seguinte


diagrama de classes (figura 7.5). Com base na tabela 3.3 observa as
classificaes das mensagens MIDI e que esto descritas neste diagrama de
classes.

91

Figura 7.5 Diagrama de Classes.


Observa-se

acrscimo

das

classes

ComCanalMidi,

SemCanalMidi, e Transparente, para melhor especificar o modo de como as


mensagens MIDI so divididas. Por exemplo, a mensagem que depende de
canal MIDI, dada pela classe ComCanalMidi tem 3 valores, sendo que no caso
de ser uma mensagem note on o valor1 ser o valor da nota( d, r, mi, entre
outras) o seu key number e a sua velocidade. Diferente se for uma mensagem
que no depende de canal MIDI, por exemplo a de Master Volume que ter
como valor 1 que indica que o comando de master volume e valor 2 o seu
respectivo valor do volume.

92

7.6. Projeto da Camada de Interface


Segundo WAZLAWICK (2004) o projeto da camada de interface
pode ser dividido em duas subcamadas:
a)

Apresentao.

Uma

camada

com

as

classes

que

representam os objetos grficos de interface e cujas responsabilidades se


resumem a receber dados e comandos do usurio e apresentar resultados a
ele.
b) Aplicao. Uma camada que controla a lgica de interface,
abrindo e fechando janelas, habilitando e desabilitando botes etc.

Ao considerar uma interface baseada em janelas, as tarefas do


projeto de interface so compostas basicamente de:
a) Determinar quais so as janelas do sistema e as
possibilidades de navegao entre uma janela e outra.
b) Fazer o projeto grfico das janelas, associando controles a
eventos de navegao, operaes de sistema e seus parmetros, consultas de
sistema com seus parmetros e resultados e operaes de controle de
transao (commit, rollback, entre outros).
c) Determinar os possveis estados de janelas modais,
indicando quais controles de interface estaro habilitados e/ou visveis nos
diferentes estados.
d) Indicar quais funes devero estar habilitadas nos diferentes
nveis de segurana.
e) Definir os casos de uso reais da aplicao.

O diagrama de estado de navegao est a seguir na figura


7.6a.

93
Principal

Gravar Trilha

Trilha MIDI

Trilha udio

Editar Trilha

Trilha MIDI

Localizar Msica

Trilha udio

Listagem de
Msicas

Figura 7.6a Diagrama de navegao do sistema


Como se observa no diagrama da figura 7.6 o software
seqenciador MIDI possui basicamente trs momentos de interaes com o
usurio. No momento de gravar uma trilha, editar uma trilha e localizar uma
msica. Este ltimo sendo o diferencial deste projeto.
A interface de edio se assemelha com as apresentadas no
captulo 4, como a da figura 4.31a o notation view, a figura 4.3.4 Piano Roll, e a
figura 4.3.6 event view.
Com relao interface de gravao pode-se basear com a do
software Sonnar apresentado na figura 7.6b.
Como se observa nesta figura 7.6b a interface de gravao
basicamente dividida em algumas partes, sendo elas uma rea para
configurao das trilhas e outra onde se exibi em forma grfica. Tambm
observa o fato da gravao de vrias trilhas em uma msica e estas sendo
tanto em MIDI como em udio.

94

Figura 7.6b Interface de gravao (Sonnar, Cakewalk)


A figura 7.6c apresenta a interface para a localizao de uma
msica por uma informao musical.

Figura 7.6c Layout para a pesquisa de uma msica.


A seguir um exemplo de pesquisa nesta interface figura 7.6d.

95

Figura 7.6d Exemplo de uma pesquisa pela informao musical.


O caso de uso real apresentado a seguir, baseando no caso
de uso expandido da tabela 7.1a.

Tabela 7.6a Caso de Uso Real Gravar msica.


Fluxo Principal:
1. O msico vai ao menu arquivo e na opo nova gravao.
2. O msico escolhe qual formato da gravao. MIDI ou udio digital na
combo.
3. O msico comea a gravar a trilha da msica.
4. [EV] O msico toca o instrumento ou informa as notas para a gravao
da seqncia da trilha (udio ou MIDI) atravs da janela de piano roll ou
notation view.
5. [EV] Clicando em salvar o msico informa os dados relacionados a
trilha da msica e salva as informaes no banco de dados.
6. [RS] O sistema informa que os dados da trilha foram salvos
corretamente por uma janela de aviso.
7. A gravao da trilha esta finalizada e o sistema est pronto para novas
interaes.

96

Tabela 7.6b Caso de Uso Real Editar msica.


Fluxo Principal:
1. Dada a msica o msico escolhe determinada trilha.
2. Nesta trilha o msico faz as alteraes dentre as opes dadas pelo
sistema, ou seja, pela janela notation view, alterando os valores das notas
pelos botes e diretamente na partitura, ou se for pelo piano roll informano
a respectiva no teclado do piano.
3. [EV] O msico altera determinada informao musical ou ajusta algum
efeito atravs da janela mixer da respectiva trilha, mudando volume, pan,
etc...
4. [RS] Se o msico optar o software executa a trilha com as novas
alteraes, clicando no boto play na barra de ferramentas ou no menu por
trilha->play.
5. O msico salva as alteraes da trilha clicando no boto salvar na barra
de ferramentas ou no menu por arquivo->salvar.

7.7. Projeto da Camada de Persistncia


O seguinte projeto tem como objetivo a implementao em um
banco de dados relacional. O MER (Modelo Entidade Relacionamento) foi
desenvolvido (figura 7.7) tendo como idia bsica o objetivo deste trabalho que
o armazenamento da informao musical codificada para pesquisa. Ou seja,
ter esses dados musicais, que j constam em uma mensagem MIDI,
organizados em um banco de dados relacional de tal forma que proporcione
maior flexibilidade para o software seqenciador MIDI e conseqentemente
para o msico usurio do software.
Dada esta modelagem, por exemplo, podem-se localizar todas
as msicas que sejam do tom G (sol maior). Pois esta informao esta na
mensagem MIDI e devidamente relacionada com a sua trilha, msica e tipo de
mensagem MIDI.

97

Figura 7.7 Modelo Entidade Relacionamento

Como observa-se nesta modelagem figura 7.7, na tabela


comando_midi constam todos os comandos MIDI, e este se relaciona n:n com
a mensagem MIDI. Neste se relacionamento consta o valor dessa mensagem.
Por exemplo, comando MIDI de note on na mensagem MIDI um com valor G
(sol).
O anexo 1 contm a lista de tabelas criadas em comandos SQL
(Structured Query Language).
Vale destacar a melhoria que esta modelagem representa. Pois
os softwares seqenciadores at ento, contam com uma srie de recursos e
efeitos a serem ajustados e inseridos em uma determinada trilha, mas nenhum
com esse recurso de armazenar a informao MIDI em um banco de dados
relacional. E assim, desfrutar de todas as funcionalidades de um SGBD

98
(Sistema Gerenciador de Banco de Dados), principalmente na execuo de
querys SQL, alm de outros recursos, tais como transaes num sistema
distribudo.
Portanto, nesta modelagem como nos demais diagramas
apresentados melhorias so cabveis de ser agregadas em trabalhos futuros.

99

8. CONCLUSO

Tendo em vista os aspectos apresentados neste trabalho, que


se iniciou com um breve estudo de teoria musical e sua representao em uma
partitura, formalizando o que msica e apresentou a idia de represent-la
em notao escrita, ou seja, a msica de forma esttica e no em sua forma
natural, ou seja, o udio.
Para a fuso de duas cincias distintas e muito fascinantes, a
msica e a cincia da computao, foram realizadas o estudo do padro MIDI e
do software seqenciador MIDI. Desta forma mostrou como as mensagens
MIDI levam toda a informao musical em forma de dados, e tambm como o
computador traduz para uma partitura ou at mesmo para sua execuo da
trilha atravs do software seqenciador.
De grande valia para este projeto foi o estudo realizado com as
funcionalidades encontradas nos seqenciadores MIDI. Que atravs deste
estudo pode-se aproveitar o que de melhor tem em um, com o melhor de outro
e utilizar para o projeto do novo software seqenciador MIDI. E este ento
conter as funcionalidades bsicas de um software seqenciador e mais as
funcionalidades levantadas por SCHROEDER (2005).
A engenharia de software vem de suma importncia tanto para
a qualidade, organizao e documentao de um projeto quanto para a
formalizao e descrio dos processos envolvidos. E este trabalho utiliza-se
do Processo Unificado de Desenvolvimento de software, o RUP, no qual
fortemente ligada a UML que usa o paradigma de orientao a objetos.
Atravs do RUP, as tarefas e as atividades foram bem definidas
para cada fase do desenvolvimento. Isto proporcionou uma tima organizao
para este projeto, sendo que o mesmo aborda as fases de Concepo e
Elaborao.
A fase de concepo gerou os seguintes documentos: Sumrio
Executivo ou Viso Geral do Sistema; as tabelas com os requisitos funcionais e
no-funcionais no levantamento de requisitos; os casos de uso, conceitos e
consultas do sistema na organizao dos requisitos.

100
A fase de elaborao resultou na expanso dos casos de uso,
as operaes de consultas de sistema, modelagem conceitual e os contratos.
Alm dos projetos da camada de domnio, interface e persistncia.
Portanto, esta monografia deu incio a proposta de um novo
software seqenciador MIDI que trabalhe com a informao musical codificada
para pesquisa. Atravs da documentao e das modelagens obtidas
desenvolvendo as fases de concepo e elaborao dentro do Processo
Unificado de desenvolvimento de software, o RUP. Os trabalhos futuros que
venham a ser realizados sero a fases de construo e transio. Alm de
estudar algoritmos para uma melhor quantizao de uma seqncia MIDI. A
fase de construo interativa com a elaborao. Ou seja, na mesma poder
haver alteraes e melhorias nos projetos ou nas modelagens da fase de
elaborao desenvolvidos nesta monografia.

101

REFERNCIAS
ANQUETIL, Nicolas. Desenvolvimento de Software Orientado a Objetos.
Braslia, 2002. Disponvel em
<http://www.ucb.br/ucbtic/mgcti/paginapessoalprof/Nicolas/Disciplinas/UML/
uml.pdf> Acessado em 30/05/2006.

MED, Bohumil. Teoria da Msica. Braslia: MusiMED, 1996.

MIDI SEQUENCER, 2004. Disponvel em <http://www.computermusic.com/articles/artcl002-03.htm> Acessado em 13/04/2006.


PINTO, Theophilo Augusto. MIDI: Musical Instrument Digital Interface. 2000.
Disponvel em: <http://www.eca.usp.br/prof/iazzetta/tutor/midi/midi1.html>.
Acessado em: 08/03/2006.
QUADROS, Moacir. Gerncia de Projetos de Software. Tcnicas e
Ferramentas. So Paulo: Visual Books, 2002.

RATTON, Miguel B. Especificao MIDI 1.0. 1996a. Disponvel em:


<http://www.music-center.com.br/midispec.htm>. Acessado em: 07/03/2006.

RATTON, Miguel B. Seqenciadores: Conceitos Bsicos. 1997a. Disponvel


em:

<http://www.music-center.com.br/wkshop09.htm>.

Acessado

em:

08/03/2006.

RATTON, Miguel B. Seqenciadores: Canais MIDI. 1998a. Disponvel em:


<http://www.music-center.com.br/wkshop10.htm>.

Acessado

em:

09/03/2006.

RATTON,

Miguel

B.

Conexo

MIDI.

1997b.

<http://www.music-center.com.br/wkshop02.htm>.
12/03/2006.

Disponvel
Acessado

em:
em:

102
RATTON, Miguel B. Os Comandos MIDI de Control Change. 1996b.
Disponvel em: <http://www.music-center.com.br/ctrlchge.htm>. Acessado
em: 08/03/2006.
RATTON, Miguel B. MIDI: duas dcadas de (r) evoluo. 2005. Disponvel
em: <http://www.music-center.com.br/midi_20anos.htm>. Acessado em:
08/03/2006.
RATTON, Miguel B. O que Computer Music?. 1998b. Disponvel em:
<http://www.music-center.com.br/wkshop01.htm>.

Acessado

em:

08/03/2006.
RATTON, Miguel B. Quantizao, Princpios Bsicos. 1996c. Disponvel em:
<http://www.music-center.com.br/groove.htm>. Acessado em: 06/04/2006.
RUP.

Rational

Unified

Process.

2003.

Disponvel

em

<http://www.wthreex.com/rup>.Acessado em: 24/04/2006.

SCHROEDER, Tobias. O Padro MIDI e Um Estudo Comparativo entre


Softwares

Seqenciadores

MIDI.

Joinville:

UDESC,

2005, 65

p.

Monografia, Bacharelado em Cincias da Computao, Universidade do


Estado de Santa Catarina, Joinville, 2005.

SEQUENCER, The. Disponvel em <http://www.midisite.com/info/info_seq.htm>


Acessado em 13/04/2006.

WAZLAWICK, Raul Sidnei. Anlise e Projeto de Sistemas de Informao


Orientados a Objetos. Rio de Janeiro: Ed Campus Ltda, 2004.

103

ANEXO 1

CREATE TABLE comando_midi (


cd_comando_midi INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
ds_comando_midi VARCHAR(50) NULL,
PRIMARY KEY(cd_comando_midi)
);

CREATE TABLE compositor (


cd_compositor INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
nm_compositor VARCHAR(50) NULL,
PRIMARY KEY(cd_compositor)
);

CREATE TABLE genero (


cd_genero INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
ds_genero VARCHAR(50) NULL,
PRIMARY KEY(cd_genero)
);

CREATE TABLE album (


cd_album INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
nm_album VARCHAR(50) NULL,
dt_album DATE NULL,
PRIMARY KEY(cd_album)
);

CREATE TABLE artista (


cd_artista INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
nm_artista VARCHAR(50) NULL,
PRIMARY KEY(cd_artista)
);

104
CREATE TABLE musica (
cd_musica INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
cd_genero INTEGER UNSIGNED NOT NULL,
cd_album INTEGER UNSIGNED NOT NULL,
cd_artista INTEGER UNSIGNED NOT NULL,
cd_compositor INTEGER UNSIGNED NOT NULL,
nm_musica VARCHAR(50) NULL,
ds_duracao TIME NULL,
PRIMARY KEY(cd_musica),
INDEX musica_FKIndex1(cd_compositor),
INDEX musica_FKIndex2(cd_artista),
INDEX musica_FKIndex3(cd_album),
INDEX musica_FKIndex4(cd_genero),
FOREIGN KEY(cd_compositor)
REFERENCES compositor(cd_compositor)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
FOREIGN KEY(cd_artista)
REFERENCES artista(cd_artista)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
FOREIGN KEY(cd_album)
REFERENCES album(cd_album)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
FOREIGN KEY(cd_genero)
REFERENCES genero(cd_genero)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);

CREATE TABLE trilha (


cd_trilha INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
cd_musica INTEGER UNSIGNED NOT NULL,

105
ds_numero INTEGER UNSIGNED NULL,
ds_patch INTEGER UNSIGNED NULL,
ds_pan INTEGER UNSIGNED NULL,
ds_chorus INTEGER UNSIGNED NULL,
ds_volume INTEGER UNSIGNED NULL,
ds_canal INTEGER UNSIGNED NULL,
PRIMARY KEY(cd_trilha),
INDEX trilha_FKIndex1(cd_musica),
FOREIGN KEY(cd_musica)
REFERENCES musica(cd_musica)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);

CREATE TABLE midi (


cd_midi INTEGER UNSIGNED NOT NULL,
cd_trilha INTEGER UNSIGNED NOT NULL,
ds_nome VARCHAR(50) NULL,
PRIMARY KEY(cd_midi),
INDEX midi_FKIndex1(cd_trilha),
FOREIGN KEY(cd_trilha)
REFERENCES trilha(cd_trilha)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);

CREATE TABLE audio (


cd_audio INTEGER UNSIGNED NOT NULL,
cd_trilha INTEGER UNSIGNED NOT NULL,
nm_audio VARCHAR(50) NULL,
ds_tamanho VARCHAR(50) NULL,
ds_caminho VARCHAR(50) NULL,
PRIMARY KEY(cd_audio),
INDEX audio_FKIndex1(cd_trilha),

106
FOREIGN KEY(cd_trilha)
REFERENCES trilha(cd_trilha)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);

CREATE TABLE midi_has_comando_midi (


cd_midi INTEGER UNSIGNED NOT NULL,
cd_comando_midi INTEGER UNSIGNED NOT NULL,
ds_valor1 NUMERIC(10,2) NULL,
ds_valor2 NUMERIC(10,2) NULL,
ds_valor3 NUMERIC(10,2) NULL,
PRIMARY KEY(cd_midi, cd_comando_midi),
INDEX midi_has_comando_midi_FKIndex1(cd_midi),
INDEX midi_has_comando_midi_FKIndex2(cd_comando_midi),
FOREIGN KEY(cd_midi)
REFERENCES midi(cd_midi)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
FOREIGN KEY(cd_comando_midi)
REFERENCES comando_midi(cd_comando_midi)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);