Player para Sincronização Multimídia Utilizando a Especificação

Transcrição

ÁLVARO NUNES PRESTES
PLAYER PARA SINCRONIZAÇÃO MULTIMÍDIA
UTILIZANDO A ESPECIFICAÇÃO BASEADA EM REDES
DE PETRI HTSPN
Palmas-TO
2003
DE PETRI HTSPN
“Monografia
apresentada
como
requisito parcial da disciplina Prática de
Sistemas de Informação II (TCC) do curso de
Sistemas de Informação, sob orientação do
Prof°. M.Sc. Fabiano Fagundes”
Palmas-TO
2003
DE PETRI HTSPN
“Monografia
apresentada
como
requisito parcial da disciplina Prática de
Sistemas de Informação II (TCC) do curso de
Sistemas de Informação, sob orientação do
Prof°. M.Sc. Fabiano Fagundes”
Aprovado em julho de 2003.
BANCA EXAMINADORA
____________________________________
Prof°. Fabiano Fagundes, M.Sc.
Centro Universitário Luterano de Palmas
____________________________________
Profª. Parcilene Fernandes de Brito, M.Sc.
____________________________________
Prof°. Jackson Gomes de Souza
AGRADECIMENTOS
Agradeço, primeiramente a Deus, e não vejo como poderia ser diferente, pois Ele é que me
tem dado sustento e alegria todos os dias da minha vida!
Meus agradecimentos à família maravilhosa que Deus me deu: meu paizão Argeu;
mãe Jandira; as manas Ludi e Cris; meus brothers Lúcio e Lindomar. Vocês são “A
Família”.
Agradeço, também, pelos amigos que, nestes anos, conquistei. Seria impossível
listar todos, mas não poderia deixar de mencionar aqueles que, junto comigo, lutam para
vencer a batalha que é concluir um curso de graduação: Shreck (Michael Schuenck) - com
seu comportamento Nerd; Danoninho (Danilo Noleto) - o mais ilustre de nós cinco, por ser
agora, uma autoridade policial; Marquim (Marcus Pinto) - o mais atleta de todos, lutando
para se recuperar depois de haver quebrado o braço numa partida de handball, uma semana
antes da entrega de seu Trabalho de Conclusão de Curso; Polly (Pollyane Lustosa) –
agradeço muito a Deus, porque no meio deste bando de marmanjos, foi colocada esta pedra
preciosa que, mesmo com seu jeitinho frágil, mostrou ser uma pessoa bastante forte (não
estamos brincando quando a chamamos de “O Quinto Elemento”).
Não poderia deixar de mencionar, também, os “culpados” pela minha formação:
meu professor e irmão em Cristo Jack Tequila (Jackson) pela ajuda; professora Deise pelas
gargalhadas, Piveta pelos momentos de descontração; Gasparzinho (professor Leal) pelas
partidas de futebol; tia Cris (Cristina) pelas reclamações; Tetê (Thereza) pelo socorro (não
sei se ela vai lembrar da ocasião, mas valeu assim mesmo); Parcy (Parcilene) pelas cartas
de recomendação; Andrés pela companhia no LARC; Mádia (Madianita) pelos risos; e
especialmente, meu Papito (Fabiano) pelo grande apoio, dedicação, conselhos e mais
ainda, pelas horas de “zuera”. Pode até não parecer, mas vocês me ensinaram muito! Meu
agradecimento a todos.
“Confia no Senhor e faze o bem; habitarás na terra, e verdadeiramente serás
alimentado. Deleita-te também no Senhor, e te concederá os desejos do teu coração.
Entrega o teu caminho ao Senhor; confia nele, e o mais ele fará.” Salmo 37: 3,4 e 5.
SUMÁRIO
1. INTRODUÇÃO ................................................................................................... 10
2. REVISÃO DE LITERATURA............................................................................ 12
2.1. Sistemas Multimídia ..................................................................................... 12
2.2. Sincronização Multimídia............................................................................. 13
2.3. Modelo de Referência................................................................................... 14
2.4. Métodos de Especificação de Sincronização ................................................ 16
2.4.1. Especificação baseada em intervalos..................................................... 16
2.4.2. Especificação baseada em eixos ............................................................ 18
2.4.2.1. Sincronização baseada em um timer global.................................... 19
2.4.2.2. Sincronização baseada em eixos virtuais........................................ 20
2.4.3. Especificação Baseada em Controle de Fluxo....................................... 20
2.4.3.1. Especificação de hierarquia básica ................................................. 21
2.4.3.2. Pontos de referência........................................................................ 22
2.4.3.3. Especificação Multimídia Baseada em Redes de Petri Temporizadas
................................................................................................................................. 23
2.5. Object Compose Petri Net (OCPN) .............................................................. 24
2.6. Time Stream Petri Net (TSPN)..................................................................... 26
2.7. Hierarchical Time Stream Petri Net (HTSPN) ............................................. 28
2.7.1. Modelagem de Componentes Hipermídia ............................................. 29
2.7.2. Modelagem de Componentes Atômicos ................................................ 30
2.7.3. Modelagem de Componentes Compostos.............................................. 30
2.7.4. Modelagem de Ligações (Links) ........................................................... 31
2.7.5. Visão Global da Modelagem Hipermídia .............................................. 33
2.7.6. Considerações sobre HTSPN................................................................. 34
2.8. Java Media Framework (JMF)...................................................................... 35
2.8.1. Package javax.media.............................................................................. 37
2.8.1.1. Interfaces......................................................................................... 38
2.8.1.2. Classes ............................................................................................ 39
2.8.2. Interface Player ...................................................................................... 40
2.8.2.1. Métodos da interface Player ........................................................... 41
2.8.3. Classe ControllerAdapter....................................................................... 48
2.8.3.1. Eventos............................................................................................ 49
2.8.4. Classe MediaPlayer................................................................................ 50
2.8.4.1. Atributos e Métodos........................................................................ 51
3. MATERIAIS E MÉTODOS................................................................................ 54
4. RESULTADOS E DISCUSSÃO......................................................................... 56
4.1. PNSched - Net Scheduling Language........................................................... 56
4.2. Templates HTSPN ........................................................................................ 61
4.2.1. Template para o elemento net ................................................................ 64
4.2.2. Template para o elemento arc_place...................................................... 65
4.2.3. Template para o elemento ivt................................................................. 65
4.2.4. Template para o elemento media ........................................................... 65
4.2.5. Template para o elemento place............................................................. 66
4.2.6. Template para o elemento transition...................................................... 66
4.2.7. Template para o elemento strategy ........................................................ 66
4.3. Implementação.............................................................................................. 67
4.3.1. Classe Net .............................................................................................. 69
4.3.2. Classe Place ........................................................................................... 71
4.3.2.1. Atributos ......................................................................................... 72
4.3.2.2. Métodos .......................................................................................... 74
4.3.2.3. Classe PlayerEventHandler............................................................. 76
4.3.3. Classe ArcPlace ..................................................................................... 77
4.3.3.1. Atributos ......................................................................................... 77
4.3.3.2. Métodos .......................................................................................... 78
4.3.4. Classe Transition.................................................................................... 78
4.3.4.1. Atributos ......................................................................................... 79
4.3.4.2. Métodos .......................................................................................... 79
4.3.5. Classe Strategy....................................................................................... 80
4.3.5.1. Atributos ......................................................................................... 80
4.3.5.2. Métodos .......................................................................................... 81
4.3.6. Classe MediaPlace ................................................................................. 81
4.3.6.1. Atributos ......................................................................................... 82
4.3.6.2. Métodos .......................................................................................... 82
4.3.7. Classe IVT ............................................................................................. 83
4.3.7.1. Atributos ......................................................................................... 83
4.3.7.2. Métodos .......................................................................................... 84
5. CONSIDERAÇÕES FINAIS .............................................................................. 85
6. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................ 88
LISTA DE FIGURAS
Figura 1:Modelo de referência para sincronização (BLAKOWSKI, 1996)........................ 14
Figura 2: Relações temporais binárias (ALLEN, 1983). ..................................................... 16
Figura 3: Operações do modelo avançado de sincronização baseado em intervalos (WAHL,
1994)............................................................................................................................ 17
Figura 4: Especificação de sincronização baseada em um timer global (BLAKOWSKI,
1996)............................................................................................................................ 19
Figura 5: Especificação de sincronização baseada em eixos virtuais (BLAKOWSKI, 1996).
..................................................................................................................................... 20
Figura 6: Exemplo de especificação utilizando o modelo de Hierarquia Básica. ............... 21
Figura 7: Sincronização através de pontos de referência (BLAKOWSKI, 1996)............... 22
Figura 8: Diagrama de uma OCPN...................................................................................... 26
Figura 9: Exemplo de uma Rede de Petri utilizando o modelo TSPN. ............................... 28
Figura 10: Modelagem dos componentes do modelo Dexter. ............................................. 29
Figura 11: Links temporizados (SÉNAC, 1995).................................................................. 32
Figura 12: Camadas de sincronização em HTSPN (SÉNAC, 1995)................................... 33
Figura 13: Represnetação das classes é método do pacote javax.media (resumido)........... 37
Figura 14: Adicionando um ControllerAdapter (JMF, 2002). ............................................ 49
Figura 15: DTD Petri-Net Scheduling Language (PNSched).............................................. 57
Figura 16: Representação de uma Rede de Petri em XML utilizando a linguagem PNSched.
..................................................................................................................................... 60
Figura 17: Representação HTSPN do documento da Figura 16.......................................... 60
Figura 18:Template para a geração de código Java............................................................. 64
Figura 19: Código Java gerado a partir da aplicação dos Templates HTSPN sobre o
documento da Figura 16. ............................................................................................. 67
Figura 20: Diagrama de classes do HTSPN Player. ............................................................ 68
Figura 21: Exemplo do código Java da classe Net. ............................................................. 71
Figura 22: Trecho da DTD PNSched – definição dos elementos place e subnet. ............... 86
Figura 23: Trecho de um documento XML PNSched. ........................................................ 86
LISTA DE TABELAS
Tabela 1: Interfaces do pacote javax.media (JMF, 2002).................................................... 38
Tabela 2: Classes do pacote javax.media (JMF, 2002). ...................................................... 39
Tabela 3: Métodos da interface Player (JMF, 2002)........................................................... 41
Tabela 4: Eventos da classe ControllerAdapter (JMF, 2002). ............................................ 49
Tabela 5: Atributos da classe MediaPlayer (JMF, 2002).................................................... 51
Tabela 6: Métodos da classe MediaPlayer (JMF, 2002). .................................................... 51
LISTA DE ABREVIATURAS
API
- Application Programming Interface
AWT
- Abstract Window Toolkit
DTD
- Definition Type Document
GUI
- Graphical User Interfaces
HTSPN
- Hierarchical Time Stream Petri Net
JMF
- Java Media Framework
OCPN
- Object Compose Petri Net
QoS
- Quality of Service
STSPN
- Structured Time Stream Petri Net
TSPN
- Time Stream Petri Net
XML
- Extensible Markup Language
XSLT
- Extensible Stylesheet Language
ANEXOS
ANEXO 1: Código Java da Classe Place........................................................................... 90
ANEXO 2: Código Java da Classe ArcPlace. ..................................................................... 93
ANEXO 3: Código Java da Classe IVT. .............................................................................. 93
ANEXO 4: Código Java da Classe MediaPlace.................................................................. 94
ANEXO 5: Código Java da Classe Transition. ................................................................... 94
ANEXO 6: Código Java da Classe Strategy........................................................................ 95
RESUMO
Este trabalho apresenta o desenvolvimento de um player, que faz parte de um projeto
maior que é o desenvolvimento de um ambiente para especificação de sincronização
multimídia baseado em Redes de Petri utilizando o modelo HTSPN (Hierarchical Time
Stream Petri Net). O processo de desenvolvimento envolve a modificação da linguagem
PNSched, proposta inicialmente por FAGUNDES (2002), a modelagem para classes Java
dos conceitos tratados pelo modelo HTSPN (lugares, arcos, transições etc.), a utilização da
API JMF (Java Media Framework) e a criação de um tradutor de XML PNSched para
linguagem Java. A proposta é o que o player interprete documentos XML PNSched e gere
as apresentações sincronizadas de acordo com as restrições especificadas no documento.
ABSTRACT
This work presents the development of a player, which is part of a project named
'Development of an environment for specifying multimedia synchronization based on Petri
Nets using HTSPN (Hierarchical Teams Stream Petri Net) model. The development
process involves the modification of PNSched Language (proposed by Fagundes 2002), the
modeling of HTSPN concepts in Java (places, arcs, transitions etc), the use of API JMF
(Java Media Framework) and the creation of a XML PNSched to Java wrapper. The
player interprets XML PNSched documents and generates synchronized presentations
according to the specified restrictions in the document.
10
1. INTRODUÇÃO
Este trabalho apresenta o desenvolvimento de um player para sincronização multimídia
utilizando a especificação HTSPN (Hierarchical Time Stream Petri Net), o HTSPN Player.
O HTSPN Player, que está sendo proposto nesse trabalho, está inserido no contexto
de um projeto maior que é o desenvolvimento de um sistema de sincronização multimídia
tendo como objetivo prover um ambiente para a modelagem (através de um Editor Gráfico)
de sincronização multimídia utilizando Redes de Petri, um Parser para a validação do
ambiente de sincronização, um módulo para o controle da Qualidade de Serviço (QoS Quality of Service) (este estará auxiliando diretamente o player), um simulador de Redes
de Petri, em que seja possível analisar o ambiente modelado e um player (tocador) que
interprete e realize a apresentação do ambiente modelado. Cada uma destas partes deverá
estar sendo desenvolvida como um módulo isolado. Quando concluído, o HTSPN Player
deve oferecer suporte a apresentação de mídias distribuídas.
A proposta é que as especificações de sincronização feitas através do Editor Gráfico
sejam representadas em um documento XML PNSched (documento XML válido de acordo
com a DTD PNSched) que estará sendo interpretado pelo HTSPN Player gerando uma
apresentação corretamente sincronizada.
O desenvolvimento do HTSPN Player envolve, portanto, uma série de tecnologias,
tais como o XML (eXtensible Markup Language), que foi a linguagem escolhida, dadas as
suas características, para a especificação das restrições de sincronização; o XSLT
(eXtensible Stylesheet Language Transform), que é uma linguagem de transformação que,
aplicada sobre um documento XML, gera uma saída em código HTML ou outro que se
fizer necessário; a linguagem orientada a objetos Java, escolhida devido às suas
características e o suporte ao tratamento de mídias; a API JMF (Java Media Framework),
que é um dos mecanismos que o Java disponibiliza para o tratamento e apresentação de
mídias; e o modelo de especificação de sincronização HTSPN. O processo de
11
desenvolvimento envolveu a modificação da DTD PNSched, proposta originalmente por
FAGUNDES (2002); o mapeamento dos conceitos do HTSPN para classes Java e a
construção de um template XSLT para a geração de código Java a partir de um documento
XML PNSched.
Este trabalho está organizado em seções sendo que, na Seção 2 será apresentada
uma introdução sobre sistemas multimídia e sua sincronização, bem como o modelo de
referência e a utilização da especificação de sincronização multimídia baseada em Controle
de Fluxo, neste trabalho, utilizando Redes de Petri. Ainda nesta Seção, estará sendo
apresentada a API JMF que foi utilizada na implementação do HTSPN Player.
A Seção 3 descreve os materiais e os métodos que foram utilizados no
desenvolvimento e a Seção 4 apresenta os resultados e as discussões gerados a partir deste
trabalho. Por fim, na Seção 5 serão apresentadas as considerações finais e os trabalhos que
poderiam estar sendo desenvolvidos a partir deste.
12
2. REVISÃO DE LITERATURA
Nesta seção, é apresentado um resumo dos conceitos que foram estudados durante o
desenvolvimento deste trabalho.
Na próxima seção, serão apresentados os conceitos de sistemas multimídias e, neste
mesmo contexto, conceitos de sincronização multimídia. A Seção seguinte apresentará os
métodos de especificação de sincronização com enfoque no método baseado no controle de
fluxo, mais especificamente, baseado em Redes de Petri Temporizadas (Seção 2.4.3.3). Por
fim, será apresentada uma descrição da API JMF, juntamente com a apresentação das
principais classes e interfaces que compõem a mesma.
2.1. Sistemas Multimídia
Um sistema que utiliza duas ou mais mídias (áudio, imagem, animação, vídeo, texto) é, de
forma geral, chamado de sistema multimídia. Segundo BLAKOWSKI (1996), um sistema
multimídia é um sistema ou uma aplicação que suporta o processamento integrado de
vários tipos de mídia (contínuas e discretas), com ao menos uma mídia contínua.
Mídias contínuas são aquelas dependentes de uma linha de tempo, como exemplos
podem ser citados áudios, vídeos ou animações. Mídias discretas, por definição,
independem de uma linha de tempo como, por exemplo, textos, imagens ou hipertextos.
O termo “multimídia” pode ser definido como a junção de mídias tradicionais como
texto, gráficos, imagens, animações, clipes de vídeo e áudio, em forma digital. Mas isto é
apenas uma parte, pois multimídia digital pode incluir outros elementos como visões
panorâmicas em duas dimensões, animações bidimensionais, moldes e cenas 3D como, por
exemplo, animações num ambiente, filmes interativos e componentes interativos em todas
as mídias. No entanto, muitos elementos podem nem ser notados como, por exemplo,
técnicas de desenho, material cartográfico, recursos de multilinguagem etc (PATHAK,
13
2000). Baseado nesta definição, um sistema multimídia pode ser entendido como um
sistema para a apresentação e/ou utilização de multimídias.
No tópico seguinte, são apresentados os conceitos de sincronização multimídia,
bem como algumas condições necessárias para que a sincronização desejada seja
alcançada.
2.2. Sincronização Multimídia
A sincronização multimídia depende da especificação das relações temporais entre os
objetos de mídias, que podem ser implícitas, como no caso da aquisição simultânea de voz
e vídeo, ou podem ser formuladas explicitamente, como no caso de documentos multimídia
compostos de texto e voz (STEINMETZ, 1995).
As relações temporais implícitas correspondem à sincronização intra-objeto
(sincronização de mídias contínuas) e as explícitas correspondem à sincronização
interobjeto (sincronização de mídias com características temporais diferentes como texto e
áudio).
Para sincronização intra-objeto, os requisitos para que se tenha uma apresentação
corretamente sincronizada compreendem a precisão quanto aos atrasos na apresentação das
LDU’s (Logical Data Units - seqüências de unidades de informação que constituem estes
objetos, como os quadros ou frames de uma imagem de vídeo, por exemplo), evitando as
falhas (inserção ou remoção de espaços na apresentação de uma seqüência de LDU's)
decorrentes da variação no atraso da entrega de LDU's na apresentação de LDU’s
consecutivos. No caso da sincronização interobjetos, os requisitos para que se tenha uma
mídia corretamente sincronizada, estão na precisão da apresentação, em paralelo, dos
objetos de mídia.
Além de apresentar as mídias corretamente sincronizadas, é indispensável que esta
apresentação atenda a um certo requisito de qualidade. Para fazer o controle da qualidade
do serviço oferecido, é proposto o desenvolvimento de um módulo de QoS que atue de
forma a garantir o máximo de qualidade nas apresentações, evitando, por exemplo,
interrupções indesejadas na apresentação das mídias.
14
Na seção seguinte, é apresentado o Modelo de Referência de BLAKOWSKI (1996)
que auxilia no entendimento dos requisitos e mecanismos que devem oferecer suporte à
execução da sincronização multimídia.
2.3. Modelo de Referência
BLAKOWSKI (1996) apresenta um modelo de referência de quatro camadas, como ilustra
a Figura 1, útil para entender os requisitos e os mecanismos que devem oferecer suporte a
execução da sincronização. Cada camada implementa mecanismos de sincronização que
são dotados de interfaces apropriadas para especificar e reforçar relacionamentos
temporais. Cada interface pode ser usada pela aplicação diretamente ou pela camada
superior. Camadas superiores apresentam abstrações de programação e de QoS mais
elevadas.
Figura 1:Modelo de referência para sincronização (BLAKOWSKI, 1996).
Na camada de mídia, uma aplicação opera em uma única seqüência de mídia
contínua, que é tratada como uma seqüência de LDU’s. A abstração fornecida nesta
camada é uma interface independente de dispositivo, com operações como read
(deviceHandle, LDU) e write (deviceHandle, LDU) (FAGUNDES, 2002).
A camada de stream trabalha tanto com uma seqüência de mídia contínua, como
com grupos de seqüências. Em um grupo, todas as seqüências são apresentadas em paralelo
utilizando mecanismos de sincronização intra-stream. A abstração oferecida nesta camada
é a noção de streams com parâmetros de tempo relativos a QoS para sincronização intra-
15
stream em um stream e sincronização inter-stream entre streams de um grupo
(BLAKOWSKI, 1996). Exemplos de operações desta camada são: start(stream),
stop(stream), create_group(list_of_streams), start(group) e stop(group).
A camada de objeto trabalha com todos os tipos de mídias e oculta as diferenças
entre mídias contínuas e discretas. A abstração aqui oferecida é a de uma apresentação
completamente
sincronizada
(BLAKOWSKI,
1996).
Esta
camada
recebe
uma
especificação de sincronização como entrada e é responsável pelo correto escalonamento
de toda a apresentação. As funções dessa camada são calcular e executar escalas de
apresentação completas que incluem a apresentação de objetos de mídia não contínuos e as
chamadas para a camada de stream (FAGUNDES, 2002). Além disso, a camada de objeto
é responsável por iniciar ações preparativas que são necessárias para permitir uma
apresentação sincronizada. Esta camada não manipula as sincronizações inter e intrastream; para isso ela se utiliza dos serviços da camada de stream. A tarefa da aplicação que
utiliza a camada de objetos é fornecer uma especificação de sincronização (BLAKOWSKI,
1996).
A camada de especificação é uma camada aberta e não oferece uma interface
explícita. Esta camada contém aplicações e ferramentas que permitem criar especificações
de sincronização, e é responsável também por mapear requisitos de QoS do nível do
usuário para as qualidades oferecidas na interface da camada de objeto. Os métodos de
especificação podem ser classificados nas seguintes categorias (STEINMETZ, 1995):
•
especificações baseadas em intervalos, que permitem a especificação de
relações temporais entre intervalos de tempo das apresentações de objetos de
mídia;
•
especificações baseadas em eixo de tempo, que relaciona eventos de
apresentação a eixos que são compartilhados pelos objetos da apresentação;
•
especificações baseadas no controle de fluxo, onde o fluxo das apresentações é
sincronizado em pontos de sincronização fornecidos;
•
especificações baseadas em eventos, onde os eventos na apresentação da mídia
disparam ações da apresentação.
As subseções seguintes descrevem cada um destes métodos de especificação.
16
2.4. Métodos de Especificação de Sincronização
Nesta seção estarão sendo apresentados os principais métodos de especificação de
sincronização multimídia, que são:
•
método baseado em intervalos;
•
método baseado em eixos temporais;
•
método baseado em controle de fluxo.
Para cada um destes métodos de especificação, estarão sendo apresentadas as
principais características.
2.4.1. Especificação baseada em intervalos
Na especificação de sincronização baseada em intervalo, a duração da apresentação de um
objeto é chamada intervalo (LITTLE, 1993). Dois intervalos de tempo podem ser
sincronizados em treze diferentes formas, as quais podem ser descritas por apenas sete,
uma vez que seis dessas relações são o inverso de outras, como, por exemplo, A before B é
a relação inversa de B after A (ALLEN, 1983). A Figura 2 ilustra estas relações.
Figura 2: Relações temporais binárias (ALLEN, 1983).
17
Com base nas treze relações temporais binárias básicas identificadas por (ALLEN,
1983), (WAHL, 1994) propôs o modelo avançado de sincronização baseado em intervalos
no qual vinte e nove relações entre intervalos foram identificadas. A Figura 3 ilustra as
relações propostas por (WAHL, 1994).
Figura 3: Operações do modelo avançado de sincronização baseado em
intervalos (WAHL, 1994).
A partir dessas relações, foram definidos dez operadores para a especificação de
relações entre os intervalos. Dos operadores definidos por WAHL (1994), quatro utilizam
um único parâmetro de atraso. São eles:
•
before – antes;
•
beforeendof – antes do fim de;
•
cobegin- inicia junto de;
•
coend – termina junto de;
Além destes, foram definidos outros cinco operadores, sendo que estes utilizam
dois parâmetros de atraso:
•
while – enquanto B, execute A;
18
•
delayed – iniciado o A, depois de certo tempo, inicia B e depois de certo tempo
do fim de A, termina B;
•
startin – A começa depois do inicio de B e termina antes do fim de B;
•
ending – A termina depois do início de B e antes do fim;
•
cross – o termino de um está ligado ao começo do outro.
Por último, tem-se o operador overlaps (B tem seu inicio e fim ligado ao inicio e
fim de A e o fim de A está ligado ao início de B) que utiliza três parâmetros de atraso.
A vantagem deste modelo está em permitir a manipulação de LDU’s, além de tornar
possível a definição da duração de uma interação com o usuário. É possível, ainda,
especificar relações temporais não determinísticas adicionais através da definição de
intervalos por duração e por atraso (FAGUNDES, 2002). Uma outra característica é a
possibilidade de se fazer disjunções de operadores. A disjunção de operadores pode ser
usada para especificar relações como não paralelo, por exemplo. Este modelo é bastante
flexível e permite a especificação de apresentações sujeitas a diversas variações em tempo
de execução (STEINMETZ, 1995).
No entanto, mesmo possibilitando a especificação direta de relações de tempo entre
objetos de mídia, este modelo não permite a especificação de relações temporais
diretamente entre sub-unidades de objetos que seria, por exemplo, especificar uma
determinada relação temporal para uma parte da mídia apenas (FAGUNDES, 2002).
2.4.2. Especificação baseada em eixos
Na especificação baseada em eixos, os objetos que compõem uma apresentação são
colocados sobre um eixo de tempo (real ou virtual). A posição de um objeto no eixo é que
define o momento de sua apresentação.
Esta especificação pode ser trabalhada de duas formas: utilização de um eixo de
tempo global e utilização de eixos de tempo virtuais. As duas abordagens são apresentadas
na seqüência.
19
2.4.2.1. Sincronização baseada em um timer global
Através deste modelo, todos os objetos de uma só mídia são ligados a um eixo de tempo
global (timer global), que representa uma abstração do tempo real (STEINMETZ, 1995).
Neste modelo, remover um objeto não altera a sincronização dos demais objetos.
No entanto, a utilização de um timer global pode não ser suficiente para expressar
as relações de sincronização entre diferentes seqüências de apresentação pois, dependendo
dessas seqüências, essa sincronização pode ser muito forte ou muito fraca (FAGUNDES,
2002). Uma solução possível pode ser a utilização de um parâmetro QoS para cada par de
seqüências de mídias (BLAKOWSKI, 1996). A Figura 4 ilustra a utilização do modelo de
especificação baseado em timer global.
Figura 4: Especificação de sincronização baseada em um timer global
(BLAKOWSKI, 1996).
Como ilustrado na Figura 4, esta abordagem não possibilita, ou não suporta, a
modelagem das ações do usuário, pois todos os objetos que compõem a apresentação
devem ter um tempo de duração definido. O desconhecimento da duração de algum objeto
(no caso, a interação com o usuário) impede a determinação do posicionamento dos objetos
que o seguem (FAGUNDES, 2002).
20
2.4.2.2. Sincronização baseada em eixos virtuais
Este modelo, onde é possível especificar um sistema de coordenadas com unidades de
medidas definidas pelo usuário, é utilizado pelo padrão HyTime (ISO, 1992). Toda a
especificação de sincronização é realizada sobre esses eixos virtuais.
Figura 5: Especificação de sincronização baseada em eixos virtuais
(BLAKOWSKI, 1996).
O modelo de sincronização baseado em eixos virtuais permite que sejam definidos
diferentes eixos, criando um espaço virtual de coordenadas (BLAKOWSKI, 1996). Com
isso, pode-se utilizar eixos específicos para tratar a interação com o usuário, bem como um
eixo de tempo tradicional (FAGUNDES, 2002). Desta forma, o exemplo da Figura 4 pode
ser modelado, para tratar a interação com o usuário, como apresentado na Figura 5.
2.4.3. Especificação Baseada em Controle de Fluxo
Para a especificação da sincronização multimídia baseado no controle de fluxo, três
abordagens merecem destaque: a especificação de hierarquia básica, baseada em pontos de
referência e a baseada em Redes de Petri Temporizadas.
Nos sub-tópicos que se seguem, estas abordagens estarão sendo apresentadas,
recebendo maior enfoque a especificação baseada em Redes de Petri Temporizadas, na
seqüência, estarão sendo, ainda, apresentadas em três modelos, a saber, OCPN (Object
21
Compose Petri Net), TSPN (Time Stream Petri Net) e HTSPN (Hierarchical Time Stream
Petri Net). Este enfoque se faz necessário, visto que esta foi a especificação utilizada no
desenvolvimento deste trabalho.
2.4.3.1. Especificação de hierarquia básica
Aqui as descrições são baseadas em duas operações de sincronização: sincronização serial
e sincronização paralela de ações (STEINMETZ, 1995).
Nesta especificação, os objetos multimídia são trabalhados como uma árvore com
nós que denotam a apresentação serial ou paralela das sub-árvores filhas. Uma ação pode
ser atômica ou composta. Uma ação atômica manipula a apresentação de um objeto de
mídia única, uma entrada do usuário ou um atraso. Ações compostas correspondem à
combinação de operadores de sincronização e ações atômicas. As estruturas hierárquicas
são fáceis de manipular. Essa estrutura, no entanto, faz com que cada ação seja
sincronizada somente em seu início ou fim (FAGUNDES, 2002). Para obter sincronização
em uma parte de uma animação, por exemplo, que não seja seu início ou fim, deve-se
dividir a animação em partes que, essas sim, serão dispostas na árvore. A Figura 6 ilustra
este modelo de especificação.
Figura 6: Exemplo de especificação utilizando o modelo de Hierarquia Básica.
22
Caso a animação tenha sido obtida como uma unidade indivisível, essa forma de
sincronização não poderá ser obtida. Ou seja, não há suporte para abstração da estrutura
interna dos objetos multimídia (STEINMETZ, 1995).
2.4.3.2. Pontos de referência
Neste modelo, objetos de mídia contínua são trabalhados como seqüências de LDU’s
(BLAKOWSKI, 1996). O tempo inicial e final da apresentação de um objeto de mídia,
bem como o tempo inicial das sub-unidades dos objetos de mídia contínua, são os
chamados pontos de referência. A sincronização é obtida através da conexão dos pontos de
referência dos objetos de mídia, como pode ser observado na Figura 7. Caso ocorram
atrasos ou inconsistências, por exemplo, na apresentação de algum objeto, pode-se utilizar,
em conjunto com este modelo, o modelo baseado em um timer global sobre o qual os
objetos podem ser escalonados (FAGUNDES, 2002).
Figura 7: Sincronização através de pontos de referência (BLAKOWSKI,
1996).
Esse modelo permite a sincronização em qualquer ponto, durante a apresentação de
um objeto, da mesma forma que a sincronização baseada em eixo de tempo, com a
vantagem de permitir a inserção de objetos com duração desconhecida, pois a condição
para que um objeto de mídia seja ativado é que o objeto anterior a ele “chegue” ao ponto de
sincronização, independente da sua duração (FAGUNDES, 2002).
Neste trabalho, a ênfase será dada à camada de especificação, mais especificamente
na Especificação Baseada em Controle de Fluxo com sincronização baseada em Redes de
Petri utilizando o modelo HTSPN. Esta foi escolhida para implementação do sistema por
possuir certas particularidades, por exemplo:
23
o na especificação baseada em intervalos, a sincronização multimídia é
trabalhada com relações binárias, ou seja, duas mídias ser sincronizadas
entre elas através de relações como A before B, por exemplo (ALLEN,
1983). Já em Redes de Petri, é possível trabalhar a sincronização com n
objetos de mídias;
o na especificação baseada em eixo, em que todos os objetos de uma só
mídia são ligados a um eixo de tempo que representa uma abstração do
tempo real (STEINMETZ, 1995) a definição do tempo, destinado à
interação com o usuário, fica prejudicada, visto que, é impossível de
definir um tempo para essa interação, além disso, se a interação não
ocorrer, o sistema tem sua execução interrompida. Em HTSPN é
possível estipular em tempo mínimo e máximo de interação do usuário,
assim, caso essa interação não ocorra, o sistema terá sua execução
continuada após o esgotamento do tempo máximo.
Além destas vantagens, vale ressaltar que a idéia básica do modelo HTSPN é a
possibilidade de se definir lugares especiais que podem ser expandidos em outras redes,
criando uma estrutura semelhante à das composições, a fim de diminuir a quantidade de
lugares e transições visíveis durante a fase de especificação (SOUZA, 97).
2.4.3.3. Especificação Multimídia Baseada em Redes de Petri Temporizadas
A apresentação de múltiplas mídias envolve tarefas com atividades paralelas e seqüenciais.
Este tipo de apresentação possui características específicas de sincronização, dependendo
de como a relação temporal dos dados é formulada (ou pré-orquestrada). Tais
características dizem respeito, por exemplo, à ordem de exibição dos objetos, ao instante
inicial de exibição e à duração de exibição de cada objeto, à taxa de exibição dos objetos
isócronos, à exibição simultânea de objetos relacionados no tempo etc. Desta forma, faz-se
necessária a representação ou especificação das características de sincronização, através de
um método para modelar as dependências temporais dos objetos envolvidos na
apresentação (FAGUNDES, 2002).
24
As Redes de Petri consistem de quatro elementos básicos: tokens, lugares,
transições e arcos além de um conjunto de regras que governam a operação da rede como
um todo. A operação das Redes de Petri é baseada na visão de tokens movendo-se em uma
rede abstrata (MURATA, 1989). As regras de disparo especificam o comportamento das
transições, isto é, as condições sob as quais processos ou eventos podem ocorrer. Três
regras governam o disparo das transições (MURATA, 1989):
•
quando todos os lugares anteriores às transições são ocupados pelo menos por
um token, a transição está habilitada;
•
uma vez habilitada, a transição dispara;
•
quando a transição disparar, exatamente um token é removido de cada lugar
anterior e exatamente um token é colocado em cada lugar posterior às
transições.
Como uma evolução das Redes de Petri, LITTLE (1990) propôs um modelo para
composição de objetos multimídias, baseado em redes de Petri temporizadas (Object
Composition Petri Net - OCPN). Tendo o modelo de (LITTLE, 1990) como base, DIAZ
(1993) propõe o modelo TSPN (Time Stream Petri Net) que acrescenta ao modelo OCPN
uma tupla (x,n,y) em cada um dos arcos da rede e também um tipo de transição em cada
uma das transições. SÉNAC (1995) propõe ainda o modelo HTSPN (Hierarchical Time
Stream Petri Net) que realiza algumas modificações no modelo TSPN. Estes modelos são
apresentados de forma mais detalhada na seqüência.
2.5. Object Compose Petri Net (OCPN)
O modelo OCPN tem como objetivo especificar formalmente os requisitos de
sincronização de documentos multimídia, permitindo a representação da duração de
recursos como sendo lugares da rede. O modelo OCPN foi elaborado a partir dos modelos
de redes de Petri temporizadas pelo fato destes possuírem atributos de representação de
eventos concorrentes e assíncronos.
As redes de Petri temporizadas atribuem um tempo de duração de disparo para cada
transição. No modelo OCPN, os lugares estão relacionados com a utilização de recursos e
possuem um tempo de duração. O disparo de uma transição na OCPN é assumido como
25
sendo um evento instantâneo. Através da OCPN, é possível especificar as diversas relações
temporais entre objetos multimídias (LITTLE, 1991), já que ela descreve efetivamente
relações temporais do tipo "antes", "depois", "durante", "inicia junto", "termina junto" etc.
Os recursos associados aos lugares da OCPN são relacionados com os tipos de objetos, tais
como áudio, vídeo, texto etc. As OCPNs são redes do tipo série-paralela, ou seja, a
sincronização pode ocorrer de forma serial (uma apresentação após a outra) ou paralela
(duas ou mais mídias sendo apresentadas simultaneamente) não possuindo realimentação
(possibilidade de repetir a apresentação a partir de um lugar determinado), representadas
por grafos e especificadas pela tupla {T, P, A, D, R, M}, em que (SCÉNAC, 1995):
•
T = {t1, t2,..., tn} é um conjunto de n transições;
•
P = {p1, p2,..., pm} é um conjunto de m lugares;
•
A = {TxP} U {PxT} → I, I = {1, 2,...} é um conjunto de arcos diretos;
•
D: P → Re é um mapeamento a partir do conjunto de lugares para os números
reais (durações);
•
R: P → {r1, r2,..., rk} é um mapeamento a partir do conjunto de lugares para um
conjunto de recursos, correspondendo a objetos de vídeo, áudio, imagem,
gráfico ou texto;
•
M: P → I, I = {0, 1, 2,...} é um mapeamento a partir do conjunto de lugares para
o conjunto de inteiros, que representam o número de fichas em um lugar
especificado.
A Figura 8 ilustra uma reapresentação da sincronização de mídias utilizando o
modelo OCPN.
26
Figura 8: Diagrama de uma OCPN.
Na Figura 8, tem-se um exemplo de uma rede OCPN simples. Nesta ilustração, três
mídias são executadas sendo que um vídeo e um áudio (ambos com duração de cinco
tempos) são executados ao mesmo tempo (em paralelo); após a apresentação destes, iniciase a apresentação de um texto que tem a duração de sete tempos. A execução destas mídias
tem uma duração total de 12 tempos.
De uma forma geral, a execução de mídias representadas por um modelo OCPN
ocorre da seguinte forma:
•
uma transição dispara quando cada um dos lugares de entrada contiver um
token;
•
após o disparo, os tokens serão removidos dos lugares de entrada e adicionados
aos lugares de saída;
•
após receber um token, o lugar permanece no estado ativo pelo intervalo de
tempo especificado. Durante esse intervalo, o token estará bloqueado até que o
lugar se torne inativo, ou pela expiração da duração do intervalo, então o token
será desbloqueado.
O modelo OCPN tem como objetivo especificar formalmente os requisitos de
sincronização de documentos multimídia, permitindo a representação da duração de
recursos como sendo lugares da rede (LITTLE, 1990). Nesse mesmo sentido trabalha o
TSPN acrescentando ao modelo uma tupla (x,n,y) em cada um dos arcos da rede e também
um tipo de transição em cada uma das transições.
2.6. Time Stream Petri Net (TSPN)
Tendo o modelo OCPN como base, o TSPN acrescenta ao modelo uma tupla (x,n,y) em
cada um dos arcos da rede e também um tipo de transição em cada uma das transições. A
tupla (x,n,y), denominada IVT (Intervalo de Validade Temporal), corresponde ao tempo
mínimo de apresentação, tempo ideal de apresentação e tempo mais atrasado de
apresentação da mídia, respectivamente. (DIAZ, 1993) define que a sincronização pode ser
27
obtida através de nove tipos de transições, segundo o modelo: strong_or, weak_and, or,
and, strong_master, weak_master, or_master, and_master.
A estratégia strong_or especifica que a apresentação de uma das mídias (ou
cadeias) é suficiente para que a apresentação seja considerada completa, desde que as
demais mídias tenham sido apresentadas por um tempo mínimo especificado nos
respectivos arcos. A estratégia weak_and só é considerada completa quando as
apresentações de todas as cadeias são realizadas; enquanto a master necessita que somente
a cadeia master esteja completamente apresentada para que o token seja liberado.
A estratégia and especifica que uma transição t só pode iniciar os places seguintes
depois da maior duração mínima (valor min do IVT do arco) e antes da menor duração
máxima (valor max do IVT do arco) de todos os arcos que apontam para t. Para a estratégia
or a transição pode ser efetivada entre a menor duração mínima e a maior duração máxima
(RODRIGUES, 1997).
RODRIGUES (1997) descreve ainda as seguintes estratégias:
•
or-master: disparada em um intervalo entre a menor duração mínima de todos
os arcos que apontam para t e a duração máxima do arco master;
•
and-master: disparada em um intervalo entre a maior duração mínima de todos
os arcos e a duração máxima do arco master;
•
strong-master: disparada em um intervalo entre a duração mínima do arco
master e a menor duração máxima de todos os arcos;
•
weak-master: só pode ser disparada num tempo entre a duração mínima do arco
master e a maior duração máxima de todos os arcos.
Quando apenas um arco aponta para uma transição, nenhuma estratégia especial de
sincronização é utilizada. Esta representação pode ser vista na Figura 9 que mostra um
exemplo de uma rede TSPN.
28
Figura 9: Exemplo de uma Rede de Petri utilizando o modelo TSPN.
No exemplo da Figura 9 pode ser visto que a transição “trans2” possui o rótulo
master, que como foi dito anteriormente, necessita que apenas a cadeia master esteja
completa para que a rede continue sua execução. Definindo que a cadeia que possui o lugar
“placeB” é a cadeia master da rede, tem-se que o lugar “placeC” terá sua execução iniciada
assim que a cadeia citada terminar, independente da outra cadeia estar terminada.
2.7. Hierarchical Time Stream Petri Net (HTSPN)
O modelo HTSPN (SÉNAC, 1995) permite a modelagem formal, com extensões
temporais, dos três principais conceitos do modelo Dexter (HALASZ, 1994): os
componentes atômicos; as ligações (links); e componentes compostos. Estes conceitos são
relevantes pela possibilidade de ser possível, através deles, especificar relações entre
mídias, com a utilização ou não de links de interação com o usuário, em um
hiperdocumento. Estes conceitos e sua utilização em Redes de Petri ficam claros quando
WILLRICH (1997) descreve como o modelo HTSPN suporta cada um destes conceitos,
respectivamente:
•
um componente atômico é modelado por um arco com um Intervalo de
Validade Temporal (IVT) e um lugar do tipo atômico associado a um recurso. O
IVT é uma tupla (α,η,β) onde α,η e β especificam, respectivamente, a duração
mínima, ideal e máxima admissível do tratamento associado ao componente
atômico para um lugar determinado;
29
•
uma ligação (link) é modelada por um arco temporizado (Link1, T3), onde
Link1, na Figura 10, é um lugar do tipo ligação (link);
•
um componente composto é modelado por um lugar abstrato, chamado lugar
composto, que representa uma sub-rede. O lugar C1, na Figura 10, é um
exemplo de lugar composto.
A Figura 10 apresenta um exemplo de Rede de Petri utilizada para especificação de
sincronização multimídia.
Figura 10: Modelagem dos componentes do modelo Dexter.
A representação gráfica, juntamente com uma fácil modelagem de esquemas de
sincronização e a possibilidade de analisar propriedades importantes faz das Redes de Petri
boas candidatas para modelagem de documentos multimídia e hipermídia (WILLRICH,
1997).
2.7.1. Modelagem de Componentes Hipermídia
As extensões do modelo TSPN levaram ao modelo HTSPN que permite modelar
facilmente tanto a sincronização lógica quanto a temporal em sistemas hipermídia
(SÉNAC, 1995).
30
2.7.2. Modelagem de Componentes Atômicos
As apresentações de componentes atômicas são submetidas às durações nominais,
intrínsecas ou dependentes de aplicação. Os últimos estão sujeitos a variações inesperadas,
e conseqüentemente, uma técnica modelando com intervalos do tempo é recomendada
(SÉNAC, 1995). Em HTSPN, um componente atômico é modelado usando um arco com
um IVT, bem como um lugar do tipo atômico associado com um recurso.
O modelo HTSPN possibilita que cenários multimídia de complexidade arbitrária
sejam construídos usando uma semântica de sincronização que combina as restrições de
sincronização dos componentes atômicos (SÉNAC, 1995).
2.7.3. Modelagem de Componentes Compostos
O HTSPN utiliza a substituição de lugares para a modelagem hierárquica, mas as Redes de
Petri oferecem, ainda, outros construtores para modelagem hierárquica (JENSEN, 1990):
•
substituição de transição;
•
substituição de lugar;
•
invocação de transição;
•
fusão de lugares e fusão de transições.
Lugares do tipo Composto são introduzidos no HTSPN para representar
componentes compostos. Um arco de saída de um lugar composto especifica o IVT do
componente composto. Um lugar composto é um lugar abstrato que especifica uma subrede TSPN. A sub-rede associada com o lugar composto especifica um cenário de
sincronização multimídia (SÉNAC, 1995). As sub-redes são chamadas Structured Time
Stream Petri Net (STSPN).
As regras de disparo do HTSPN, para um lugar composto, trabalham da seguinte
forma:
•
quando um token entra num lugar composto, o lugar de entrada da sub-rede
STSPN também é marcado;
31
•
quando um token libera um lugar composto, todos os tokens relacionados à subrede são, recursivamente removidos.
Um lugar composto é equivalente a uma STSPN relacionada a ele, tanto estrutural
quanto temporalmente. Esta noção de equivalência temporal é introduzida com a ajuda do
algoritmo de redução que possibilita reduzir qualquer STSPN a um arco temporizado.
Qualquer arco de saída de um lugar do tipo composto é associado ao IVT obtido pela
aplicação do algoritmo de redução no STSPN relacionado (SÉNAC, 1995).
Como exemplo, pode-se considerar uma sub-rede STSPN qualquer composta por
cinco lugares com determinadas restrições de sincronização. A aplicação do algoritmo de
redução sobre esta sub-rede resultará num único lugar C, do tipo composto. As
características de sincronização da sub-rede são refletidas no lugar C, ou seja, o resultado
da apresentação dos cinco lugares da sub-rede será equivalente ao resultado da
apresentação do lugar composto C.
O conceito de lugar composto possibilita criar Redes de Petri hierarquicamente,
usando um acesso bottom-up (da raiz para o topo) ou top-down (partindo do topo para a
raiz). Além disso, lugares compostos abstraem tanto o comportamento dinâmico quanto o
temporal de uma rede subjacente (SÉNAC, 1995).
2.7.4. Modelagem de Ligações (Links)
No modelo de referência Dexter, ligações (links) possibilitam especificar n relações diretas
entre partes dentre muitos componentes. Links ajudam na definição do comportamento
dinâmico de sistemas hipermídia.
Usando o modelo HTSPN, um link é modelado por um arco temporizado (L,t) e um
lugar do tipo link. O IVT associado com um link introduz o conceito de link temporizado:
links são automaticamente disparados em função, tanto da lógica, quanto da condição
temporal. Esta característica introduz a noção de sistemas hipermídia ativos, isto é,
sistemas que são automaticamente habilitados par reagir em função de restrições temporais.
As
sistemas
semânticas
hipermídia,
de
sincronização
exigem
esquemas
lógica,
de
tradicionalmente
sincronização
nos
utilizadas
links
em
guiados
unicamente por condições lógicas e/ou temporais. Usando o modelo HTSPN um esquema
32
de sincronização pode ser facilmente mapeado para um arco master associado a um lugar
do tipo link. A semântica de sincronização master especifica que a transição relacionada
será disparada no IVT do arco master.
Por exemplo, o lugar link L, na Figura 10 especifica um link com [x,*,y] como IVT.
Vale ressaltar que a duração normal de um evento assíncrono não pode ser conhecida
antecipadamente. Então, a duração de um link é representada por “*”. Numa mesma
situação, se o arco master (L,t1) está habilitado com um tempo t então, a transição t1 deve
ser disparada no IVT [t+x,t+y]. Se a lógica do disparo do link não for satisfeita antes do
tempo t+y, então o link é automaticamente disparado com o tempo.
A integração das restrições temporais de componentes numa condição de disparo do
link poderá prover uma sincronização lógica guiada não somente por links temporizados,
mas também pelas restrições temporais nos componentes.
O modelo HTSPN disponibiliza esta capacidade através de cinco semânticas de
sincronização derivadas das regras de disparo master (master, or-master, and-master,
strong-master, weak-master).
O não-determinismo expresso por múltiplas escolhas entre vários links, é uma
característica fundamental em sistemas hipermídia. O não-determinismo pode ser
facilmente especificado usando o modelo HTSPN. Por exemplo, na Figura 11, são
especificadas duas escolhas de links disparando de um componente C , respectivamente
modelado pelos arcos (L,t1) e (L,t2).
Figura 11: Links temporizados (SÉNAC, 1995).
As regras de disparo do TSPN combinados com lugares compostos e lugares links
possibilitam eventos assíncronos e um alto nível de interrupção que pode ser facilmente
modelado. O disparo de uma transição faz com que todos os tokens marquem as sub-redes
associadas direta ou indiretamente com o lugar composto da transição prefixada para ser
33
fechada. Uma sub-rede relacionada a um lugar composto pode ser interrompida neste
caminho, sem levar em consideração a marcação da sub-rede (SÉNAC, 1995).
2.7.5. Visão Global da Modelagem Hipermídia
Restrições de sincronização de componentes links podem ser especificadas com arcos
temporizados compostos pelo lugar do tipo link e transições tipadas. Restrições de
sincronização de componentes compostos podem ser especificadas com arcos
temporizados feitos de lugares do tipo composto e estes relacionados à sub-redes
equivalentes temporal e estruturalmente. Restrições de sincronização de componentes
atômicos podem ser especificadas com arcos temporizados. Além disso, restrições
temporais dentro de componentes atômicos podem ser expressas pela associação das subredes com os lugares atômicos.
Esta capacidade envolve um modelo de três camadas que expressam as restrições de
sincronização em sistemas hipermídia (SÉNAC, 1995). A Figura 12 ilustra a hierarquia e o
relacionamento entre estas camadas.
Figura 12: Camadas de sincronização em HTSPN (SÉNAC, 1995).
Camada de sincronização Link. Os links são usados para especificar a semântica
transversal do documento hipermídia. Nesta camada, lugares com seus arcos de saída
34
relacionados representam componentes do tipo links, atômicos ou compostos. Vale lembrar
que cenários hipermídia descrevem como a camada de sincronização link tem uma forma
livre, em particular o não-determinismo e os ciclos podem ser usados.
A Camada de sincronização Composta: nesta camada, lugares atômicos e
compostos possibilitam que componentes que compõem a estrutura hierárquica de Dexter
sejam modelados. Na camada de sincronização composta, cenários multimídia são
modelados usando TSPN.
A Camada de Sincronização Atômica: tem o objetivo de descrever as restrições
de sincronização em componentes atômicos pela especificação das restrições de
sincronização intramídia.
2.7.6. Considerações sobre HTSPN
Experiências com o modelo OCPN esclarecem o interesse das extensões Redes de Petri
Temporizadas na modelagem hipermídia e tem mostrado que métodos formais são
ferramentas poderosas e úteis para controlar a adição de complexidade em sistemas de
informação.
O modelo HTSPN oferece um framework único para o projeto de cenário
hipermídia, baseados no modelo formal TSPN para a modelagem da sincronização de
cenários multimídia.
O novo modelo HTSPN trouxe contribuições importantes para modelagem de
sistemas hipermídia. Por exemplo:
•
possibilita uma especificação fácil e formal dos conceitos fundamentais do
modelo Dexter. Componentes (i.e. componentes links, compostos e atômicos)
são uniformemente modelados como arcos temporizados e a definição recursiva
de compostos tem um mapeamento imediato na hierarquia do modelo HTSPN;
•
traz um melhor entendimento de sincronização hipermídia por possibilitar que
esquemas de sincronização que combinam a sincronização lógica e temporal
sejam especificados. Além disso, o modelo HTSPN considera o não
determinismo temporal em sistemas hipermídia distribuídos;
35
•
com HTSPN é possível expressar como eventos assíncronos interrompem um
cenário multimídia.
O modelo HTSPN é um método eficiente para a simulação e prototipação de
sistemas hipermídia.
2.8. Java Media Framework (JMF)
A linguagem Java possui algumas APIs (Application Program Interface - Interface para
Programação de Aplicações) para aplicações multimídia que permitem aos programadores
desenvolver aplicativos Java com recursos multimídia, áudio e vídeo, por exemplo. Nos
últimos anos, o segmento de multimídia digital do setor de computadores obteve um
grande crescimento, como demonstra a quantidade de conteúdo multimídia disponível na
Internet. Os sites da Web foram transformados de páginas HTML (Hypertext Markup
Language) baseadas em texto em páginas com variado conteúdo multimídia. Os avanços
nas tecnologias de hardware e de software permitiram que os desenvolvedores integrassem
multimídia aos aplicativos mais simples.
Reconhecendo que os aplicativos Java deveriam suportar recursos de vídeo e áudio
digitais, a Sun Microsystems, a Intel e a Silicon Graphics trabalharam juntas para produzir
uma API para o desenvolvimento de aplicações multimídia: o Java Multimedia Framework
(JMF) (JMF, 2002). A API JMF é uma das várias APIs para multimídia em Java e
possibilita o desenvolvimento de aplicações Java capazes de reproduzir, editar e capturar
diversos formatos de mídias (JMF, 2002). Entre outras, pode-se citar a API Java Sound que
disponibiliza classes para o tratamento de mídias de áudio, por exemplo.
Nesta seção estará sendo apresentada a API JMF que é normalmente utilizada na
reprodução de clipes de mídia em aplicativos Java e foi utilizada para a implementação do
player. Muitos aplicativos, como os gerenciadores financeiros, as enciclopédias e os jogos,
usam conteúdo multimídia para ilustrar os seus recursos, apresentar conteúdo educacional e
divertir os usuários. A utilização de objetos que implementam a interface Player (pacote
javax.media) é um dos mecanismos disponibilizados pelo JMF para a reprodução de
mídias. A interface Player estende a classe Controller, que é um tratador para mídia
suportada por JMF (JMF, 2002).
36
De forma geral, as seguintes etapas são necessárias para reproduzir um clipe de
mídia, com a utilização da API JMF (JMF, 2002):
•
especificar a fonte da mídia;
•
criar um player para a mídia;
•
obter a mídia de saída e os controles de player;
•
exibir a mídia e os controles.
Na especificação da fonte da mídia, pode ser utilizada tanto uma String contendo o
caminho no sistema de arquivos (path), em que se encontra o arquivo de mídia, quanto
uma URL. Este path é utilizado na instanciação de um objeto MediaLocator, que é
utilizado pela classe Manager na criação de um player (classe MediaPlayer). Um player
possui métodos que possibilitam a obtenção de controles para a mídia e de um display
apropriado para sua apresentação.
Desde a especificação de uma mídia até a sua efetiva apresentação, várias etapas
são realizadas. Estas etapas podem ser identificadas através de estados que indicam a tarefa
que está sendo realizada pelo player. Por exemplo, quando uma apresentação é iniciada,
um dos primeiros passos é localizar a mídia que será apresentada e conectar-se ela. Esta
etapa é identificada pelo estado realizing. O passo seguinte é fazer a alocação dos recursos
de hardware e iniciar o carregamento dos dados da mídia. O player entra, então, no estado
prefetching. Detalhes sobre troca de estados e as interfaces e classes responsáveis pelo seu
gerenciamento serão vistos nos tópicos seguintes.
A IBM e a Sun desenvolveram a mais recente especificação de JMF – versão 2.0. A
Sun oferece uma implementação de referência – JMF 2.1.1 – da especificação de JMF que
suporta tipos de arquivo de mídia como arquivos Microsoft Audio/Video Interleave (.avi),
Macromedia Flash 2 movies (.swf), Future Splash (.spl), MPEG Layer 3 Audio (.mp3),
Musical Instrument Digital Interface (MIDI; .mid), vídeos MPEG-1 (.mpeg, .mpg) entre
outros (JMF, 2002).
No próximo tópico é apresentado o pacote (package) Java javax.media,
descrevendo algumas das principais interfaces e classes deste pacote que foram utilizadas
neste trabalho.
37
2.8.1. Package javax.media
O pacote javax.media disponibiliza as interfaces e classes que possibilitam o
desenvolvimento de aplicações Java que façam o tratamento, manipulação e apresentação
de mídias. A Figura 13 apresenta um diagrama de classes resumido do pacote javax.media,
permitindo a visualização das interações entre as classes que compõem o pacote.
Figura 13: Representação das classes e métodos do pacote javax.media
(resumido).
38
Na Figura 13 tem-se uma visão geral das classes e interfaces (bem como os
relacionamentos de dependência, associação e herança entre elas) que foram utilizadas no
desenvolvimento deste trabalho. Vale ressaltar que nem todos os métodos estão
representados na figura, mas, ainda assim, é possível visualizar a estruturação das classes e
interfaces. A seguir, é apresentada uma descrição das interfaces e classes utilizadas neste
trabalho.
2.8.1.1. Interfaces
As principais interfaces do pacote javax.media, utilizadas no desenvolvimento deste
trabalho são descritas na Tabela 1.
Tabela 1: Interfaces do pacote javax.media (JMF, 2002).
Interface
Descrição
Implementada por objetos que suportam o modelo de tempo
Clock
Java Media. Por exemplo, objetos que codifiquem e
renderizem filmes MPEG
Estende a interface Clock e provê informações sobre a
Controller
alocação de recursos, geração de eventos, além de um
mecanismo para obtenção de objetos que provêem um
controle adicional sobre um Controller
ControllerListener
Controls
É uma interface para o tratamento de eventos assíncronos
gerados pelos Controllers
Provê uma interface para a obtenção de objetos pela interface
ou pelo nome da classe
É uma interface base para objetos que lêem e gerenciam
conteúdo da mídia fornecida por um DataSource, que é uma
MediaHandler
abstração para protocolos personalizados de mídia. Este
gerencia o ciclo de vida da mídia provendo um protocolo de
conexão simples
Player
Estende a interface MediaHandler (interface base para
39
objetos que lêem e gerenciam conteúdo de mídia de um
DataSource) e provê métodos para a apresentação e controle
de mídia baseadas em tempo
A interface Clock foi utilizada no desenvolvimento do player proposto neste
trabalho, pelas suas características de controle temporal, uma vez que esta disponibiliza
métodos que permitem a definição de restrições temporais para as mídias como, por
exemplo, a definição de um tempo final para a mídia, que seja diferente do seu tempo total.
As interfaces ControllerListener, Controller e Controls foram utilizadas, de uma forma
geral, na obtenção de componentes visuais para o controle das mídias e na geração de
eventos que possibilitam o acompanhamento da apresentação da mídia como, por exemplo,
“mídia pronta para ser apresentada” ou “apresentação iniciada”. Na maior parte da
implementação, as demais interfaces são acessadas através da interface Player, pois esta
herda os métodos das demais interfaces.
2.8.1.2. Classes
As classes mais relevantes para este trabalho, dadas as suas características, e que são
oferecidas pelo pacote javax.media são apresentadas na Tabela 2.
Tabela 2: Classes do pacote javax.media (JMF, 2002).
Classe
ControllerAdapter
Descrição
Adaptador de eventos que recebe os ControllerEvents e os
envia para o método apropriado
Classe base para eventos gerados por um Controller, por
ControllerEvent
exemplo, eventos de troca de estado e de mudança de
velocidade da apresentação
EndOfMediaEvent
Manager
Evento que indica que o Controller alcançou o fim desta
mídia e parou a execução
É o ponto de acesso para a obtenção dos recursos do
sistema
necessários
para
Players,
DataSources,
40
Processors e TimeBase, por exemplo
MediaEvent
É a classe base para eventos de mídia
MediaPlayer
Classe que implementa a interface Player
MediaTimeSetEvent
Evento enviado por um Controller quando o media-time é
definido através do método setMediaTime
Evento enviado quando um Controller finaliza o
PrefetchCompleteEvent
Prefetching (alocação de recursos de hardware e inicia o
carregamento dos dados da mídia para a apresentação da
mesma).
RealizeCompleteEvent
StartEvent
TransitionEvent
Evento que é enviado quando um Controller finaliza o
Realizing (conectando-se à fonte da mídia)
É um evento de transição (TransitionEvent) indicando que
um Controller entrou no estado Started
É um evento de controle (ControllerEvent) que indica que
um Controller mudou de estado
Um player é criado pela invocação do método estático cretatePlayer da classe
Manager. MediaPlayer é a classe que implementa a interface Player, retorno do método
createPlayer. A classe ControllerAdapter é a responsável pela captura e distribuição
apropriada dos eventos gerados por um ControllerEvent As demais classes representam
eventos gerados. Por exemplo, quando uma apresentação é iniciada, um evento
“apresentação iniciada” (StartEvent) é disparado e capturado pelo ControllerAdapter que
invoca o método que define o comportamento que deverá ser adotado.
A interface Player e as classes ControlleAdapter e MediaPlayer, que tiveram uma
importância bastante grande na implementação deste trabalho, são apresentadas, em mais
detalhes, nos tópicos que se seguem.
2.8.2. Interface Player
A interface Player estende a interface MediaHandler, que é a interface base para objetos
que lêem e gerenciam conteúdos de uma fonte de mídia (representada por um DataSource)
41
e possui apenas o método setSource, que define a fonte onde a mídia deverá ser obtida.
Player é implementada pela classe MediaPlayer e utilizada para a apresentação e controle
de mídias. Esta interface estende, ainda, a interface Controller e provê métodos para a
obtenção de componentes AWT (Abstract Window Toolkit), controles de processamento de
mídias e um meio para gerenciar outros Controllers (utilização de listeners) (JMF, 2002).
Um Controller fornece informações sobre o estado da alocação de recursos, geração de
eventos e um mecanismo para obtenção de objetos que disponibilizam controles adicionais
sobre um Contoller.
Dentre os métodos disponibilizados por esta interface, alguns tiveram maior
relevância para este trabalho e estão descritos na seqüência.
2.8.2.1. Métodos da interface Player
Além dos métodos da interface Player, são descritos também os métodos que esta herda,
tanto da interface Clock quanto de Controller. Os métodos da interface estão descritos na
Tabela 3.
Tabela 3: Métodos da interface Player (JMF, 2002).
Método
Descrição
Método público que diz ao Player para assumir o controle de
addController
outro Controller. Este método é definido na interface Player
e recebe como parâmetro o Controller que será gerenciado
Aborta a operação atual e cessa qualquer atividade que esteja
deallocate
consumindo recursos do sistema. Este método é herdado da
interface Controller
Método público que obtém um Component que provê ao
usuário uma interface para o controle do Player. Se este
getControlPanelComponent
Player
não
tiver
um
painel
retorna
de
controle
nada.
O
padrão,
método
getControlPanelComponent é definido na interface Player e
retorna um painel de controle GUI (Graphical User
42
Interfaces - Interfaces Gráficas para Usuários) padrão para
este Player
Obtém a latência de um Controller em nanosegundos. A
latência representa, no pior caso estimado, a quantidade de
tempo em que o primeiro frame do dado será apresentado.
getStartLatency
Este método retorna o tempo (objeto Time) que deverá ser
esperado para a apresentação do primeiro frame da mídia.
Este é um método público e é herdado da interface
Controller.
Método público que obtém o último valor definido com
sucesso pelo setStopTime. Retorna a constante Clock.RESET
getStopTime
se o tempo de parada não tiver sido definido. Retorna o
tempo de parada atual. Este método é herdado da interface
Clock.
Retorna uma instância TimeBase correspondente ao tempo-
getTimeBase
base atual do Clock. Este é um método público. Este método
é herdado da interface Clock.
Método público que obtém um display Component
(componente visual) para o Player. O display Component é
onde as mídias são exibidas. Se este Player não tiver nenhum
getVisualComponent
display Component, getVisualComponent retorna nada. Por
exemplo, getVisualComponent retorna nada se a mídia a ser
apresentada
for
somente
um
áudio.
O
método
getVisualComponent é definido na interface Player.
Método público que remove um Controler atribuído a um o
removeController
player pela invocação do método addController. Este método
recebe como parâmetro a Controller que deverá ser
removido.
Método público que define o Clock do tempo da mídia. Este
setMediaTime
método pode ser chamado somente com o Clock Stopped
(Clock
parado). Um ClockStartedError
setMediaTime é chamado com o Started
é gerado
se
Clock (Clock
43
iniciado). Recebe como parâmetro o novo tempo para a
mídia. Este método é herdado da interface Clock.
Método público que define a velocidade de apresentação de
uma mídia. Recebe como parâmetro um valor float que será
setRate
atribuí como novo fator de velocidade e retorna um valor
float correspondente à velocidade atual. Este método é
herdado da interface Clock.
Método público que define o tempo que deve durar a
apresentação da mídia. O Clock irá parar quando o tempo
desta mídia passar o stop-time (tempo de parada). Para zerar
o tempo de parada, o Clock deve ser definido para
setStopTime
Clock.RESET. O método setStopTime sempre pode ser
chamado com o Clock parado (Stopped). Com o Clock
Started, o stop-time pode ser definido uma única vez. Este
método é herdado da interface Clock e recebe como
parâmetro o tempo em que a execução da mídia deve parar.
Este método é público de recebe como parâmetro uma
setTimeBase
instância de TimeBase que irá definir o tempo base para um
determinado Clock. Este método é herdado da interface
Clock.
Método público que
inicia o MediaPlayer tão logo seja
possível. Se o MediaPlayer não tiver um Player existente,
então um Player é criado e iniciado. O método start pode ser
invocado antes do Prefetched Player, pois força a transição
start
do Player para o estado Started a partir do estado atual. Por
exemplo, se o Player está no estado Unrealized, start
implicitamente invoca os métodos realize, prefetch, e
Clock.syncStart. A transição apropriada TransitionEvents é
enviada conforme o Player é movido através de cada estado,
até o Started.
syncStart
Método público que sincroniza o tempo da mídia (mediatime) atual para o tempo-base especificado e inicia o Clock.
44
Este método define o time-base, o start-time e coloca o Clock
no estado Started (iniciado). Recebe como parâmetro um
Time que será igualado ao tempo atual da mídia. Este método
é herdado da interface Clock.
Com a utilização dos métodos disponibilizados pela interface Player, é possível a
construção de um display para a apresentação das mídias, bem como a obtenção de
controles como, por exemplo, volume e velocidade.
Além da obtenção de componentes visuais, são disponibilizados métodos que
possibilitam a definição/obtenção de restrições e informações temporais para as mídias
como, por exemplo, a definição do tempo final para a apresentação, a obtenção da latência
para o início da mídia que seria o tempo entre a ação iniciar e o início da apresentação
propriamente dito.
A interface Player utiliza algumas restrições que um Controller impõe, no qual
métodos podem ser chamados com o Controller iniciado (Started Controller), além de
oferecer um meio para gerenciar grupos de Controllers. Os seguintes métodos não podem
ser invocados com o Player iniciado (Started Player) (JMF, 2002):
•
setTimeBase;
•
syncStart;
•
deallocate;
•
addController;
•
removeController.
Diferentemente de um Controller, os métodos abaixo podem ser invocados com o
Player em execução (JMF, 2002):
•
setMediaTime;
•
setRate.
Invocando estes métodos com o Started Player, pode-se iniciar um consumo
significativo de tempo e processamento, dependendo da localização e do tipo da mídia em
processamento. Estes métodos podem também causar a mudança de estado do Player. Se
45
esta mudança acontecer, um TransitionEvents (representa eventos gerados em decorrência
da troca de estados) apropriado será enviado pelo Player quando este mudar de estado
(JMF, 2002). Por exemplo, um Player pode entrar no estado Prefetching para processar a
invocação do método setMediaTime e, neste caso, o Player envia um evento
RestartingEvent, um PrefetchCompleteEvent e um StartEvent, deste modo, o estado
Started é alterado para Prefetching, volta para Prefetched e, finalmente, volta ao estado
Started.
Em algumas situações, pode ser interessante que uma aplicação utilize um único
Player para controlar outros Players ou Controllers. Um único controlador de Player pode
ser usado para invocar os métodos start, stop, setMediaTime e outros métodos. O
controlador do Player gerencia todas as transições de estado e envio de eventos. Com isto,
é possível construir um Controller para atualizar animações, informar o progresso da linha
de tempo da mídia, ou prover outras funções temporalmente relacionadas (JMF, 2002).
Para fazer com que um Player assuma o controle de um Controller, utiliza-se o
método addController. Um Controller não pode ser adicionado em um Player que esteja
no estado Started ou no estado Unrealized. Se o Player estiver no estado Started, e o
método addController for invocado, um ClockStartedError será gerado; e se Player estiver
no estado Unrealized, um NotRealizedError será gerado. Um Controller pode ser
adicionado uma única vez e, na sua adição, o Player realiza as seguintes etapas de
processamento (JMF, 2002):
•
invoca setTimeBase do Controller passando como parâmetro o TimeBase do
Player;
•
sincroniza o Controller com o Player usando setMediaTime, setStopTime e
setRate;
•
obtém e adiciona a latência do Controller na conta quando o Player calcular a
latência do start. Quando getStartLatency for chamado, o Player retorna o
cálculo da diferença entre a latência antes do Controller ser adicionado e a
latência com a adição do Controller;
•
obtém e adiciona a duração do Controller na conta quando o Player calcular a
duração. Quando getDuration é chamado, o Player retorna a diferença entre a
duração antes da adição do Controller e a duração com o Controller adicionado.
46
Se contudo, o valor da duração for desconhecido, getDuration retorna
DURATION_UNKNOWN. Se o valor é DURATION_UNBOUNDED,
getDuration retorna DURATION_UNBOUNDED;
•
se auto-adiciona como um ControllerListener para o Controller adicionado de
forma que este possa gerenciar os eventos gerados pelo Controller;
•
invoca métodos de controle no Controller adicionado em resposta a invocação
dos métodos no Player.
Os métodos de um Controller poderão ser chamados semente através do
gerenciador Player. Não é definido como o Controller ou o Player se comportarão se os
métodos forem chamados diretamente num Controller adicionado (JMF, 2002).
Quando o método start é chamado por um determinado Player, todos os
Controllers gerenciados por este Player têm seus estados modificados para Prefetched.
Quando os Controllers estão no estado Prefetched, o Player chama syncStart com um
tempo referente à latência de cada Controller gerenciado. Quando o método close é
chamado, todos os Controllers também são fechados (JMF, 2002).
Quando os métodos realize, prefetch, stop, ou deallocate são chamados num
Player, o Player invoca os métodos em todos os Controllers gerenciados por ele e somente
troca de estado quando todos estes Controllers tiverem alcançado tal estado. Por exemplo,
um Player no estado Prefetching não faz a transição para o estado Prefetched até que todos
os Controllers gerenciados estejam no estado Prefetched. O Player envia TransitionEvents
(eventos de transição) como mudança de estado (JMF, 2002).
Na remoção de um Controller, o gerenciador Player deve estar no estado Stopped
ou um ClockStartedError será gerado. Para remover um Controller de um Player, basta
invocar o método removeController. Quando um Controller é removido o Player realiza o
seguinte processamento (JMF, 2002):
•
reinicia o Controller TimeBase;
•
recalcula a duração e envia um DurationUpdateEvent se a duração do Player é
diferente sem o Controller;
•
recalcula a latência.
47
O método setMediaTime, pode ser chamado num Player que gerencia outros
Controllers, mesmo não estando no estado Started. Caso o Player não está Started, o
setMediaTime será invocado normalmente e caso esteja no estado Started, é enviado um
RestartingEvent e executadas as seguintes tarefas para cada Controller gerenciado (JMF,
2002):
•
invoca o método stop no Controller;
•
invoca o setMediaTime no Controller;
•
invoca prefetch no Controller;
•
aguarda pelo PrefetchCompleteEvent de um Controller;
•
invoca syncStart no Controller.
Quando o syncStart ou setStopTime são chamados, o Player invoca o método para
todos os Controllers que este gerencia. O Player deve estar no estado correto (estado em
que a invocação do método é permitida) ou um erro é gerado (JMF, 2002). Por exemplo, o
Player deve estar no estado Prefetched antes da invocação de syncStart.
Quando setTimeBase é chamado, o Player invoca setTimeBase em todos os
Controllers por este gerenciado (JMF, 2002). Se setTimeBase falhar para algum
Controller, um IncompatibleTimeBaseException é gerado e o último TimeBase será
restaurado para todos os Controllers.
Além dos métodos, a interface Player utiliza eventos que são enviados por um
Controller que um determinado Player gerencia. Os eventos são enviados diretamente de
um Controller através de um Player e os listeners (ouvintes) registrados com o Player
(JMF, 2002).
Para eventos personalizados que um Controller gerenciado pode gerar, o Player
registra um listener com o Controller quando este é adicionado. Outros listeners que são
registrados com o Controller não devem invocar métodos no Controller enquanto a
gerência deste, pelo Player, está sendo iniciada. Quando um Controller é removido da lista
de Controllers do Player, o Player remove da lista o listener do Controller.
Um Player envia TransitionEvents (Eventos de Transição) normalmente quando se
move entre estados, mas os Controllers são afetados quando o Player muda de estado.
48
Geralmente, um Player não faz o envio de um evento de transição até que todos os
Controllers tenham enviado seus eventos.
2.8.3. Classe ControllerAdapter
Esta classe é o adaptador de eventos (event adapter) que recebe o ControllerEvents e os
envia
para
um
stub-método
apropriado.
A
classe
ControllerAdapter
estende
java.lang.Object e implementa ControllerListener, java.util.EventListener. Os principais
método da classe ControllerAdapter para este trabalho são (JMF, 2002):
•
endOfMedia – método invocado quando um evento EndOfMediaEvent é
disparado;
•
mediaTimeSet – método invocado quando um evento MediaTimeSetEvent que é
enviado por um Controller;
•
prefetchComplete
-
método
invocado
quando
um
evento
PrefetchCompleteEvent é disparado;
•
realizeComplete – método invocado quando um evento RealizeCompleteEvent é
gerado;
•
start – método invocado quando um evento StartEvent é gerado;
•
stop – método invocado quando um evento StopEvent é disparado;
•
stopAtTime – método invocado quando um evento StopAtTimeEvent é
disparado.
Classes que estendem este adapater podem substituir somente as mensagens que
sejam de seu interesse. Por exemplo, o código mostrado na Figura 14 estende um
ControllerAdapter com uma classe interna anônima que faz com que o próprio player
reinicie e faça a desalocação dos recursos quando chegar ao final da mídia.
1
2
3
4
5
player.addControllerListener(
new ControllerAdapter(){
public void endOfMedia(EndOfMediaEvent e){
Controller controller = e.getSource();
controller.stop();
49
6
7
8
9
10
controller.setMediaTime(0);
controller.deallocate();
}
}
);
Figura 14: Adicionando um ControllerAdapter (JMF, 2002).
Conforme mostra a Figura 14, na linha 1, a instância player está adicionando como
listener, um ControllerAdapter (linha 2). Para o controller adicionado, foi implementado
somente o método endOfMedia (linha 3) que define que, quando a mídia apresentada por
player chegar ao seu final, este deve obter a fonte da mídia (linha 4), parar a execução
(linha 5), definir o tempo da mídia para zero (linha 6) e liberar os recursos alocados (linha
7).
No tópico seguinte, são apresentados os eventos gerados por um Controller que
foram utilizados no desenvolvimento deste trabalho.
2.8.3.1. Eventos
A classe ControllerAdapter disponibiliza vários métodos que são invocados de acordo com
os eventos gerados. Estes métodos podem ser implementados conforme a necessidade da
aplicação. A Tabela 4 apresenta uma descrição dos eventos que foram utilizados na
realização deste trabalho.
Tabela 4: Eventos da classe ControllerAdapter (JMF, 2002).
Eventos
MediaEvent
MediaTimeSetEvent
Descrição
É a interface base para eventos de mídia;
Este evento é enviado pelo Controller quando o media-time é
definido com a invocação do método setMediaTime;
Um evento PrefetchCompleteEvent é enviado quando um
PrefetchCompleteEvent
Controller termina o processo de Prefetching. Isto ocorre
quando um Controller sai do estado Prefetching para
Prefetched, ou como um reconhecimento de que o método
50
prefetch foi chamado e o Controller já se encontrava no estado
Prefetched. Este evento indica que a mídia está pronta para ser
apresentada;
RealizeCompleteEvent
Este evento é enviado quando um Controller finaliza o
Realizing, ou seja, quando a conexão com a mídia foi efetuada;
É um TransitionEvent que indica que um Controller entrou no
StartEvent
estado Started. Entrar neste estado implica que syncStart será
invocado, provendo um novo time-base para a mídia.
StartEvent provê o tempo time-base e o media-time;
Evento que indica que o Controller está parado porque
StopAtTimeEvent
alcançou o tempo definido pela invocação do método
setStopTime;
StopEvent
EndOfMediaEvent
É um ControllerEvent que indica que um Controller está
parado (stopped);
Estende a classe StopEvent e indica que o Controller alcançou
o fim da mídia e será parado.
A utilização de eventos permite que uma aplicação Java possa monitorar passo a
passo os processos realizados desde a captura da mídia (ou a localização da fonte da mídia)
até a sua apresentação. É possível, ainda, gerenciar as possíveis falhas nestes processos
fazendo com que a aplicação assuma um determinado comportando dependendo do evento
gerado.
2.8.4. Classe MediaPlayer
A classe MediaPlayer está contida no pacote javax.media.bean.playerbean, é uma extensão
da classe Container do pacote java.awt e implementa a interface Player. A classe
MediaPlayer encapsula um player em um componente JavaBeans (componentes escritos
em Java sendo que uma das vantagens é o reuso). Um MediaPlayer pode ser usado como
um Player com os controles padrões ou mesmo controles customizados (JMF, 2002).
A seguir, são apresentados os atributos e métodos da classe MediaPlayer, bem
como uma descrição de cada um deles.
51
2.8.4.1. Atributos e Métodos
A classe MediaPlayer oferece diversos atributos e métodos que possibilitam uma
apresentação
personalizada.
Por
exemplo,
utilizando
os
atributos
e
métodos,
disponibilizados, pode-se definir se o filme será apresentado repetidamente, a localização
do display na tela e o nível do volume. Os atributos de um MediaPlayer são listados na
Tabela 5.
Tabela 5: Atributos da classe MediaPlayer (JMF, 2002).
Atributo
Descrição
curVolumeLevel
Uma string que indica o nível atual do volume
curVolumeValue
Atributo do tipo float que indica o valor atual do volume
curZoomLevel
Uma string que informa o nível atual do zoom
curZoomValue
Um valor do tipo float que indica o zoom atual
gainControl
mediaTime
Atributo do tipo GainControl que é uma interface para a
manipulação do áudio
Atributo do tipo Time que informa o tempo da mídia durante
a apresentação
Para se poder alterar o valor dos atributos, deve-se utilizar os métodos get e set
apropriados, uma vez que todos os atributos da classe são privados. Além dos métodos para
a manipulação dos valores dos atributos, existem também métodos que realizam tarefas um
pouco mais complexas como, por exemplo, a obtenção de um display apropriado para uma
determinada mídia. Dentre os métodos disponibilizados pela classe MediaPlayer, a Tabela
6 descreve os que foram utilizados no desenvolvimento deste trabalho.
Tabela 6: Métodos da classe MediaPlayer (JMF, 2002).
52
Métodos
Descrição
Método construtor que constrói um MediaPlayer com
MediaPlayer
seu painel principal preparando-se para controles de
eventos caching e em seguida a exibição visual;
getVisualComponent
Obtém um display Component para o Player;
Obtém um Component que provê ao usuário uma
interface para o controle do Player;
start
Inicia o MediaPlayer tão logo seja possível;
addController
Adiciona um Controller a um Player;
Monta a mídia em partes dependentes do Controller.
Isto pode incluir o exame do dado da mídia e deve levar
algum tempo para completar. O método realize coloca o
realize
Controller no estado Realizing e retorna imediatamente.
Quando o realize estiver completo e o Controller estiver
no estado Realized, o Controller dispara o evento
RealizeCompleteEvent.
Processa tantos dados quantos forem necessários para
reduzir a latência do início dos Controller's para que o
tempo seja o mais curto possível. Isso envolve exame da
mídia e deve levar algum tempo para ser completo. O
prefetch
método prefetch coloca o Controller no estado
Prefetching
e
retorna
imediatamente.
Quando
o
Prefetching estiver completo e o Controller no estado
Prefetched,
o
Controller
dispara
o
evento
PrefetchCompleteEvent.
Método público que libera todos os recursos e pára toda
close
atividade. O método close indica que o Controller não
será usado. Um ControllerClosedEvent é enviado.
Método público que especifica um ControllerListener
addControllerListener
para o qual este Controller deverá enviar eventos. Um
Controller pode ter vários ControllerListeners. Este
método recebe como parâmetros o listener para o qual o
53
Controller enviará os eventos.
Método público que pára o Clock. Chamando o método
stop o Clock é liberado da sincronização com o
TimeBase. Depois que esta requisição é feita, o Clock
stop
vai para o estado Stopped. Se o stop é chamado com o
Clock parado, a requisição é ignorada.
setStopTime
getStopTime
Define o tempo que deve durar a apresentação da mídia;
Obtém o último valor definido com sucesso pelo
setStopTime;
setMediaTime
Define o Clock do tempo da mídia;
getMediaTime
Obtém o Clock para o tempo atual da mídia.
Com a utilização da API JMF o desenvolvimento de aplicações em Java para
apresentação de mídias é bastante facilitado. É possível se trabalhar com mídias
distribuídas e de vários formatos, sejam elas áudio ou vídeo.
54
3. MATERIAIS E MÉTODOS
Este trabalho envolveu diversas tecnologias, tais como XML, XSLT, API JMF e a
linguagem Java. Seu desenvolvimento foi realizado no espaço físico do Laboratório de
Redes de Computadores (LARC) do Centro Universitário Luterano de Palmas –
CEULP/ULBRA, no segundo semestre de 2003.
Inicialmente, foram realizados estudos sobre os conceitos que abordados, por
exemplo, sistemas multimídias, métodos de especificação de sincronização e a linguagem
PNSched. Posteriormente, foi realizado um estudo sobre a API JMF, analisando os
recursos oferecidos para a manipulação e tratamento de mídias e como esta seria utilizada
no trabalho. Foi definido, então, quais funcionalidades da aplicação proposta estariam
sendo focadas e, tendo sido feitas estas definições, foi realizada a modificação da DTD
PNSched, conforme a necessidade, e iniciou-se o mapeamento dos conceitos do HTSPN
para classes Java. Após ter dado a implementação por encerrada, iniciou-se a escrita do
relatório.
Para o desenvolvimento deste trabalho foram utilizados os seguintes softwares:
•
XML Spy: ferramenta desenvolvida pela ALTOVA (http://www.altova.com) que
possibilita a edição e validação de documentos XML, além de disponibilizar um
editor visual para construção de DTDs e Schema’s;
•
Stylesheet Designer: módulo fornecido juntamente com o XML Spy que
possibilita a construção e edição visual de documentos XSLT. Este módulo
disponibiliza, ainda, operações XPATH que podem ser utilizadas no
documento;
•
JCreator LE: editor de código para a linguagem Java
•
Eclipse: editor de código para a linguagem Java, versão 2.1 com o plugin para a
geração de modelagem UML.
55
A estação de trabalho utilizada foi um microcomputador Pentium III, 750MHz com
128MB de memória RAM e 20GB disco rígido, equipada com o Sistema Operacional
Wndows 2000 Server – Service Pack 4, navegador Web Microsoft Internet Explorer 6.0 – e
pacotes de correções/atualizações até Junho de 2003, J2SDK versão 1.4.1 de 2002 e JMF
versão 2.1.1e.
As bibliografias utilizadas estavam disponíveis na biblioteca do Laboratório de
Redes de Computadores (LARC), Laboratório de Multimídia (LABMIDIA) e na Internet.
56
4. RESULTADOS E DISCUSSÃO
Nesta seção, são apresentados os resultados que foram obtidos a partir do desenvolvimento
deste trabalho, bem como, as discussões geradas.
4.1. PNSched - Net Scheduling Language
Utilizando-se a linguagem XML (eXtensible Markup Language) foi desenvolvido o DTD
(Document Type Definition) PNSched baseado na proposta original definida em
(FAGUNDES, 2002) que, para a modelagem de Redes de Petri, se utilizou dos elementos
que permitem a especificação de lugares, arcos e transições.
A linguagem PNSched permite definir os elementos do modelo HTSPN e como os
mesmos podem ser utilizados na especificação de uma aplicação multimídia com requisitos
de sincronização. A Figura 15 apresenta a linguagem PNSched com algumas modificações.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<!ELEMENT net (place+,transition*,subnet*)>
<!ATTLIST net name ID #REQUIRED >
<!ELEMENT place (arc_place, media)>
<!ATTLIST place
name ID #REQUIRED
type (atomic | compose | link) "atomic"
mode (normal | final) "normal"
target_subnet IDREF #IMPLIED >
<!ELEMENT arc_place (ivt)>
<!ATTLIST arc_place target_transition IDREF #REQUIRED >
<!ELEMENT ivt EMPTY>
<!ATTLIST ivt
min CDATA #REQUIRED
ideal CDATA #REQUIRED
max CDATA #REQUIRED
>
<!ELEMENT media EMPTY>
<!ATTLIST media
type (image | audio | video | text) "image"
57
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
src CDATA #REQUIRED
>
<!ELEMENT transition (strategy,arc_transition*)>
<!ATTLIST transition name ID #REQUIRED >
<!ELEMENT arc_transition EMPTY>
<!ATTLIST arc_transition target_place IDREF #REQUIRED >
<!ELEMENT strategy EMPTY>
<!ATTLIST strategy
name CDATA #REQUIRED
type (strong_or | weak_and | or | and |
master |strong_master | weak_master |
or_master | and_master) "and"
target_place IDREF #IMPLIED
>
<!ELEMENT subnet (subplace+, transition*)>
<!ATTLIST subnet name ID #REQUIRED >
<!ELEMENT subplace (arc_place, midia)>
<!ATTLIST subplace
name ID #REQUIRED
>
Figura 15: DTD Petri-Net Scheduling Language (PNSched).
Conforme pode ser visto na Figura 15, a linguagem PNSched inicia definindo o
elemento net que representa toda uma apresentação multimídia (linha 1) e é composto
pelos elementos:
•
place - pelo menos um;
•
transition - sua ocorrência pode variar de 0 a n;
•
subnet – sua ocorrência pode variar de 0 a n.
Além dos elementos citados acima, o elemento net deve conter, obrigatoriamente
um atributo name (linha 2).
O elemento place representa um lugar do modelo HTSPN e é composto por um
elemento arc_place e um elemento media (linha 4). Um place deve ter, ainda os atributos:
•
name – obrigatório e é utilizado como identificador único para o elemento
(linha 6);
58
•
type – os valores podem ser atomic, compose ou link. Este atributo é obrigatório
e informa qual a natureza do lugar, se é um lugar atômico, composto ou um
lugar do tipo link (linha 7);
•
mode – pode assumir o valor normal ou final e também é obrigatório. Um place
que tem o atributo mode definido com o valor final indica que após este place a
apresentação deve ser encerrada (linha 8);
•
target_subnet – atributo opcional que corresponde a uma referência a uma subrede (elemento sub_net – linha 9).
As transições do modelo HTSPN são modeladas para o elemento transition. Este
elemento é composto pelos elementos arc_transition - que pode aparecer 0 ou n vezes no
documento; e strategy que deve aparecer uma única vez (linha 23). Além dos elementos
que o compõem, o elemento transition possui ainda um atributo chamado name que é o
identificador único para uma determinada transição (linha 24).
A linguagem PNSched possui também um elemento para a representação das
estratégias de sincronização que é o elemento strategy (linha 28). Este possui os atributos
name, que é um nome identificador da estratégia (linha 30); type, que armazena o tipo da
estratégia que a transição deverá utilizar (linha 31); e target_place, que é uma referência a
um elemento place que deverá ser iniciado após a transição (linha 34).
Os elementos place e transition, segundo o modelo HTSPN possuem arcos para a
sua ligação. Estes arcos estão representados na linguagem PNSched pelos elementos
arc_place (linha 10) e arc_transition (linha 26), respectivamente.
O elemento arc_transition pode aparecer no documento 0 ou mais vezes e possui
apenas o atributo target_place (linha 27) que é uma referência a um determinado elemento
place. Após a realização de uma transição, os places referenciados pelos elementos
arc_transition são iniciados. O elemento arc_place é composto por um elemento ivt e
possui um atributo obrigatório chamado target_transition (linha 11) que é uma referência à
transição que o referido arco está apontando. O elemento ivt (linha 12) possui as
especificações de restrição temporal descritas pelos atributos obrigatórios min – especifica
o tempo mínimo para a execução do place (linha 14); ideal – tempo ideal para a execução
de um certo place (linha 15); e max – tempo máximo para a execução de um determinado
place (linha 16).
59
O elemento media (linha 18) representa uma determinada mídia que estará sendo
apresentada. Este elemento possui os atributos obrigatórios type – (linha 20) informa se a
mídia a ser apresentada é um áudio (valor audio), um vídeo, uma imagem (valor image) ou
um texto (valor text); e src – especifica a fonte da mídia (linha 21).
Segundo o modelo HTSPN, lugares podem ser modelados como sendo compostos
por uma STSPN. Buscando oferecer suporte a esta modelagem, a linguagem PNSched
possui o elemento subnet (linha 37). Este elemento é composto por elementos subplace e
transition além de possuir um atributo name que é o identificador do elemento (linha 38).
Uma vez que um documento XML PNSched possua um elemento subnet, este deve ter,
obrigatoriamente, pelo menos um elemento subplace. Os elementos subplace são
compostos pelos elementos arc_place e media, e possuem os atributos name e mode, com a
mesma definição descrita para o elemento place (linha 39).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
<?xml version='1.0'?>
<!DOCTYPE net SYSTEM "PNSched.dtd">
<net name = "n1">
<place name = "video" type = "atomic" >
<arc_place target_transition = "t1">
<ivt min = "3" ideal = "5" max = "7" />
</arc_place>
<midia type = "video" src = "video1.mpeg" />
</place>
<place name="L" type="link">
<ivt min = "5" ideal = "*" max = "16.5" />
</arc_place>
<midia type = "image" src = "image1.gif" />
</place>
<place name = "C" type = "compose" target_subnet="sub1">
<ivt min = "13" ideal = "14" max = "15" />
</arc_place>
<midia type = "video" src = "videoC.avi" />
</place>
<transition name = "t1">
<arc_transition target_place = "L" />
<arc_transition target_place = "C" />
<strategy type = "and" />
</transition>
<transition name = "t2">
60
32
33
34
35
36
37
38
39
40
41
42
43
44
<strategy type = "master" target_place = "L" />
</transition>
<subnet name="sub1">
<subplace name="subp1" >...
<transition name = "subt1">...
<transition name = "subt2">...
<subplace name="subp4" mode = "final">...
</subnet>
</net>
Figura 16: Representação de uma Rede de Petri em XML utilizando a
linguagem PNSched.
A Figura 17, apresenta um exemplo de Rede de Petri utilizada para especificação de
sincronização multimídia, e a sua representação em XML, utilizando a linguagem
PNSched, é mostrada na Figura 16. O exemplo apresenta um documento XML
representando uma Rede de Petri, que foi construído através da linguagem PNSched. Cada
elemento da linguagem é representado através de marcações em um documento XML.
Figura 17: Representação HTSPN do documento da Figura 16.
A marcação net (linha 3 da Figura 16) indica o início da modelagem de uma rede
em um documento XML. A partir dela será representado todo o conteúdo de uma Rede de
61
Petri. As marcações place (linha 4, 11 e 18) e trasition (linha 25 e 31) representam,
respectivamente, os lugares e as transições. Os arcos são representados pelas marcações
arc_place (linhas 5, 12 e 19) e arc_transition (linhas 26 e 27). A diferença destes dois
arcos é que o primeiro é um arco de saída de um determinado lugar para uma transição e
possui uma marcação ivt (linhas 6, 13 e 20), que armazena o intervalo de validade
temporal do arco. O segundo arco é um arco de saída de uma transição para um
determinado lugar. A marcação subnet (linha 35) representa uma sub-rede, ou seja, os
lugares compostos contêm uma outra rede e esta é representada pela marcação subnet. Esta
marcação contém praticamente todos os elementos de uma rede comum, a diferença é que
ela possui uma nova definição para o elemento place que é o subplace. Vale ressaltar que
uma sub-rede não pode possuir uma segunda sub-rede.
4.2. Templates HTSPN em XSLT
A proposta deste trabalho é que se tenha um documento XML baseado na linguagem
PNSched, onde estejam especificadas todas as restrições de sincronização para uma
determinada apresentação. Cada documento XML corresponde a uma apresentação, sendo
que esta pode ser composta por várias mídias. Devido ao fato de o HTSPN Player ter sido
desenvolvido sobre o JMF, este executa, portanto, código Java. Sendo assim, para que uma
apresentação possa ser realizada de fato, torna-se necessário a geração de classes Java a
partir de um documento XML.
Nesta seção será apresentado o template que foi desenvolvido com o objetivo de
gerar, a partir de um documento XML baseado na linguagem PNSched, classes Java que
possam ser executadas pelo HTSPN Player. Um template pode ser definido como um
modelo para a apresentação de elementos que compõem um documento XML. Num
template, por exemplo, pode-se definir que, quando um elemento <place>
for
identificado, a string “Place p = new Place( )” deve ser mostrada.
Um conjunto de classes Java foi desenvolvido com o propósito de gerenciar a
apresentação das mídias de forma a mantê-las sincronizadas. Dentre as classes
desenvolvidas, tem-se a classe Net que tem como responsabilidade a instanciação dos
objetos que compõem uma apresentação, bem como o início da mesma. Desta forma, para
cada apresentação, deve ser gerada uma implementação diferente para a classe Net.
62
Objetivando a geração automática da implementação da classe Net, foi desenvolvido o
HTSPN Template em XSLT. A Figura 18 mostra o template XSLT desenvolvido.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<head/>
<body style="font-family:Courier New; font-size:14; bold;">
 
<xsl:apply-templates select="net"/>
 
</body>
</html>
</xsl:template>
<xsl:template match="net">
package htspnPlayer; 
public class Net{
   
public static void main(String Args[]){
      
<xsl:apply-templates select="place"/>
<xsl:apply-templates select="media"/>
<xsl:apply-templates select="transition"/>
      
<xsl:apply-templates select="//arc_place"/>
      
<xsl:for-each select="//arc_place">
<xsl:value-of select="../@name"/>.setArcPlace(
arcPlace_<xsl:value-of select="../@name"/>
<xsl:value-of select="@target_transition"/> );
      
</xsl:for-each>
      
<xsl:for-each select="//transition">
<xsl:if test="count(arc_transition) < 1">
<xsl:value-of select="@name"/>.addTargetPlace(null);
</xsl:if>
<xsl:if test="count(arc_transition) > 0">
<xsl:for-each select="arc_transition">
<xsl:value-of select="../@name"/>.addTargetPlace(
<xsl:value-of select="@target_place"/>);
      
</xsl:for-each>
</xsl:if>
</xsl:for-each>
 
      
<xsl:value-of select="place[1]/@name"/>.startPlace();
63
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
   
} 
}
</xsl:template>
<xsl:template match="arc_place">
<xsl:variable name="aPlace" select="../@name"/>
ArcPlace arcPlace_<xsl:value-of select="$aPlace"/>
<xsl:value-of select="@target_transition"/>=
new ArcPlace(<xsl:value-of select="@target_transition"/>
,new IVT(<xsl:apply-templates select="ivt"/>));
      
</xsl:template>
<xsl:template match="ivt">
"<xsl:value-of select="@min"/>",
"<xsl:value-of select="@ideal"/>",
"<xsl:value-of select="@max"/>"
</xsl:template>
<xsl:template match="media">
<xsl:variable name="aMedia"
select="concat('media',../@name)"/>
MediaPlace <xsl:value-of select="$aMedia"/>
= new MediaPlace("<xsl:value-of select="@type"/>
","<xsl:value-of select="@src"/>");
      
<xsl:value-of select="../@name"/>.setMediaPlace(
<xsl:value-of select="$aMedia"/>);
</xsl:template>
<xsl:template match="place">
Place 
<xsl:value-of select="@name"/>
= new Place("<xsl:value-of select="@type"/>
","<xsl:value-of select="@mode"/>");
        
<xsl:apply-templates select="media"/>
 
      
</xsl:template>
<xsl:template match="subnet">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="subplace">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="transition">
Transition <xsl:value-of select="@name"/>=
new Transition(<xsl:apply-templates select="strategy"/>);
      
</xsl:template>
<xsl:template match="strategy">
64
104
new Strategy(
105
"<xsl:value-of select="@type"/>"
106
<xsl:if test="string-length(@target_place) > 0">
107
<xsl:value-of select="concat(',',@target_place)"/>
108
</xsl:if>)
109
</xsl:template>
110 </xsl:stylesheet>
111
112
Figura 18:Template para a geração de código Java.
Os tópicos apresentados na seqüência descrevem, em detalhes, o processamento
realizado em cada template.
4.2.1. Template para o elemento net
Nas linhas de 14 a 53 da Figura 18 tem-se a definição de um template para o elemento net.
Segunda a definição, deve ser apresentada, inicialmente, uma referência ao package java e
em seguida o nome da classe (linhas 15 e 16) que deve ser Net.
Na linha 18 é iniciada a definição do método main e na linha 20 o template do
elemento place é invocado. Na linha 22 é invocado o template do elemento transition e em
seguida o template do elemento arc_place (linha 24). O resultado da aplicação dos
tamplates place, transition e arc_place são partes do método main.
Após a aplicação do template arc_place é realizada, ainda, para cada elemento
arc_place, a escrita da sintaxe de invocação do método setArcPlace da classe Place (limas
de 27 a 29) onde o nome da instância que invoca o método é obtido do atributo name do
elemento pai. O parâmetro passado é o nome da instância da classe ArcPlace que é
montado a partir da string “arc_place_” concatenada com o valor do atributo do elemento
pai mais o atributo target_transition (linha 29).
Para cada elemento transition do documento XML, é escrita a sintaxe da invocação
do método addTargetPlace da classe Transition (linhas de 34 a 45) . O nome da instância
que invoca o método é obtido do atributo name do elemento pai. O parâmetro passado para
este método é o valor do atributo target_place do elemento arc_transition. Caso um
elemento transition possua nenhum elemento arc_transition, o parâmetro para o método
setArcPlace será null (linhas de 35 a 37).
65
Na última etapa, o template escreve a sintaxe da invocação do método startPlace da
classe Place para o place raiz (linha 49). O nome da instância é obtido a partir do atributo
name do primeiro elemento place presente do documento XML.
4.2.2. Template para o elemento arc_place
Para o elemento arc_place foi desenvolvido um template onde é criada uma variável
chamada aPlace que contém o valor do atributo name do elemento pai (o elemento place –
linha 55) e em seguida escreve a sintaxe da instanciação de um objeto da classe ArcPlace
que recebe como nome o resultado da concatenação da string “arcPlace_” com a variável
aPlace e o atributo target_transition (linhas 56 e 57). São passados como parâmetros para
o construtor o atributo target_place e uma nova instância da classe IVT (linhas 58 e 59). É
passado, como parâmetro, para o construtor da classe IVT, o resultado da aplicação do
template do elemento ivt (linha 59).
4.2.3. Template para o elemento ivt
O template ivt coloca cada um dos os atributos (min, ideal e max) entre aspas e separados
por “vírgula”.
4.2.4. Template para o elemento media
No template media, é criada uma variável chamada aMedia que contém o resultado da
concatenação da string “media” com o atributo name do elemento place, pai da respectiva
media (linhas de 70 e 71). Da linha 72 até a linha 74, é escrita a sintaxe de instanciação de
um objeto MediaPlace cujo nome é o conteúdo da variável aMedia e o construtor recebe
como parâmetro o atributo type e src do elemento media.
Em seguida, o template escreve a sintaxe de invocação do método setMediaPlace
onde o nome da instância que invoca o método é obtido do atributo name do elemento
place, pai de media (linha 76). É passado como parâmetro para o método setMediaPlace o
conteúdo da variável aMedia (linha 77).
66
4.2.5. Template para o elemento place
O template place (linhas de 80 a 89) escreve a sintaxe da criação de uma instância da
classe Place chamada segundo o atributo name do elemento place (linha 82). Na
instanciação, o construtor recebe como parâmetro o atributo type (linha 83) e mode (linha
84) do elemento place e o resultado da aplicação do template do elemento media (linha
86).
4.2.6. Template para o elemento transition
Sua definição se encontra nas linhas de 98 a 102 e define a criação de um objeto Transition
chamado segundo o atributo name do elemento transition do documento XML (linha 99).
Na instanciação do objeto, é passado para o construtor o resultado da aplicação do template
para o elemento strategy (linha 100).
4.2.7. Template para o elemento strategy
Nas linhas de 103 a 110 é tem-se a definição do template do elemento strategy que escreve
a sintaxe para instanciação de um objeto Strategy
passando como parâmetro para o
construtor o valor do atributo type (linha 105), especificado no documento XML e, se
estiver contido no documento, o nome do place destino (linhas de 106 a 108).
Aplicando o Template PNSched (Figura 18) sobre o documento da Figura 16, temse o resultado conforme mostra a Figura 19.
1 package htspnPlayer;
2 public class Net{
3
public static void main(String Args[]){
4
Place V = new Place("atomic", "normal");
5
MediaPlace mediaV =
6
new MediaPlace("video", "file:video1.mpeg");
7
V.setMediaPlace(mediaV);
8
Place L = new Place("link", "normal");
9
MediaPlace mediaL =
10
new MediaPlace("image", "image1.jpg");
11
L.setMediaPlace(mediaL);
67
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37 }
38
Place C = new Place("compose", "normal");
MediaPlace mediaC =
new MediaPlace("video", "file:video1.mpeg");
C.setMediaPlace(mediaC);
Transition T1 =
new Transition( new Strategy( "and" ) );
Transition T2 =
new Transition( new Strategy( "and" ) );
ArcPlace arcPlace_VT1 =
new ArcPlace(T1 ,new IVT( "0", "2", "6" ));
ArcPlace arcPlace_LT2 =
new ArcPlace(T2 ,new IVT( "6", "*", "8" ));
ArcPlace arcPlace_CT2 =
new ArcPlace(T2 ,new IVT( "8", "14", "16" ));
V.setArcPlace( arcPlace_VT1 );
L.setArcPlace( arcPlace_LT2 );
C.setArcPlace( arcPlace_CT2 );
}
T1.addTargetPlace(L);
T1.addTargetPlace(L);
T2.addTargetPlace(null);
V.startPlace();
Figura 19: Código Java gerado a partir da aplicação dos Templates HTSPN
sobre o documento da Figura 16.
O código da Figura 19 é gerado a partir da aplicação do Template HTSPN sobre o
documento XML PNSched da Figura 18. O código da Figura 19 deve ser compilado e sua
execução resultará numa apresentação multimídia sincronizada.
4.3. Implementação
Esta seção apresenta a primeira etapa do desenvolvimento de um player chamado HTSPN
Player, para a sincronização multimídia baseada em Redes de Petri. A implementação
deste player corresponde a um dos módulos de um projeto maior que é o desenvolvimento
de um ambiente para modelagem, validação e apresentação de cenários multimídias
baseados em Redes de Petri.
68
Na implementação do HTSPN Player, procurou-se modelar os conceitos abordados
pelo modelo HTSPN (lugares, arcos e transições) para classes em Java. Para cada um dos
conceitos, foram propostas classes correspondentes. A Figura 20 apresenta a modelagem
UML das classes propostas.
Figura 20: Diagrama de classes do HTSPN Player.
A implementação do HTSPN Player se limita, no entanto, à parte funcional de um
player, ou seja, o desenvolvimento de uma interface para o mesmo não é apresentado neste
trabalho, mas é citado, na seqüência, como sugestão de trabalho futuro. Nesta primeira
abordagem, foram considerados apenas os lugares atômicos. Lugares do tipo link e lugares
compostos não foram implementados; o mesmo ocorre com as estratégias de sincronização,
69
apesar de ambos aparecem na DTD proposta e na modelagem. Uma outra limitação desta
implementação é o fato de o HTSPN Player suportar a apresentação somente de áudio e
vídeo; imagens estáticas, por exemplo, não foram tratadas neste primeiro momento.
É importante ressaltar também, que algumas propriedades e/ou métodos que,
mesmo não sendo tratados pelo HTSPN Player, neste primeiro momento, aparecem na
modelagem devido à sua provável utilização na conclusão da implementação. Por outro
lado, outros métodos, eventos e/ou atributos podem vir a ser acrescentados.
O HTSPN Player é um player simples para a sincronização multimídia baseado em
Redes de Petri e foi desenvolvido com base no JMF, sendo este o responsável pela
apresentação das mídias.
Nas seções seguintes, são apresentadas, em detalhes, as classes Java que foram
propostas, bem como seus atributos e métodos. O código completo é disponibilizado na
Anexo 1.
4.3.1. Classe Net
Possui apenas o método public static void main( ) e tem a responsabilidade de fazer as
instanciações e iniciar a apresentação das mídias. Para o início da apresentação, é chamado,
apenas, o método startPlace do place (instância da classe Place) raiz. A partir deste
instante, os outros places serão iniciados no momento apropriado, ou seja, quando todas as
condições de sincronização para este place forem satisfeitas.
Na classe Net, são instanciados todos os lugares, transições, arco do lugar e arcos
das transições que compõem a apresentação multimídia. O código Java da classe Net é
gerado pela aplicação do template HTSPN sobre o documento XML. A Figura 21 mostra
um exemplo da classe Net gerada a partir de um documento XML.
A organização da classe Net está definida da seguinte forma:
•
inicialmente, é feita a instanciação dos lugares (instâncias de Place; linhas 3, 6 e
8 da Figura 21) ;
•
em seguida, é instanciado um objeto da classe MediaPlace que corresponde á
mídia que um determinado place estará executando (linhas 4 e 9);
70
•
na seqüência, um determinado MediaPlace é atribuído a um Place (linhas 6 e
11). Este processo se repete para cada elemento <place> contido no
documento XML;
•
instanciação de todas as transições (classe Transition) especificadas no
documento XML, passando como parâmetro para o construtor, um objeto da
classe Strategy, que é a estratégia de sincronização que esta transição irá utilizar
(linha 13);
•
depois de instanciadas as transições, todos os arcos que saem de um place para
uma transição são instanciados. Estes arcos são instâncias da classe ArcPlace e
o construtor recebe como parâmetro uma instância de Transition, que
corresponde à transição que deverá ser iniciada após a apresentação, e uma
instância da classe IVT com as especificações do intervalo de validade temporal
para este arco (linhas 15 e 18);
•
depois de instanciados os arcos, estes são atribuídos, através do método
setArcPlace da classe Place, a uma determinada instância da classe Place
(linhas 21 e 22). Neste momento, todos os arcos são atribuídos a seus
respectivos places;
•
na próxima ação, os lugares que deverão entrar em execução após uma
determinada transição, são adicionados a uma determinada instância da classe
Transition, com o método addTargetPlace da classe Transition (linha 24). Uma
mesma transição pode iniciar n places ao mesmo tempo;
•
o último passo invoca, para o place raiz, o método startPlace da classe Place,
que iniciará a execução das mídias (linha 25). Após o início da apresentação do
place raiz, todos os demais places serão iniciados no momento próprio,
conforme as restrições de sincronização especificadas.
1 public class Net{
2
public static void main(String args[]){
3
Place P1 = new Place("atomic", "normal");
4
MediaPlace mediaP1 =
5
new MediaPlace("video", "file:yellowcard.mpeg");
6
P1.setMediaPlace(mediaP1);
7
8
Place P2 = new Place("atomic","final");
71
9
MediaPlace mediaP2 =
10 new MediaPlace("audio","file:midia.mid");
11
P2.setMediaPlace(mediaP2);
12
13
Transition T1 = new Transition(new Strategy("and"));
14
Transition T2 = new Transition(new Strategy("and"));
15
ArcPlace arcPlace_P1T1 =
16
new ArcPlace(T1, new IVT("0", "3", "10"));
17
18
ArcPlace arcPlace_P2T2 =
19
new ArcPlace(T2, new IVT("10", "15", "23"));
20
21
P1.setArcPlace(arcPlace_P1T1);
22
P2.setArcPlace(arcPlace_P2T2);
23
T1.addTargetPlace(P2);
24
T2.addTargetPlace(null);
25
P1.startPlace();
26
}
27 }
Figura 21: Exemplo do código Java da classe Net.
A seqüência com que as instanciações são feitas, não é uma seqüência fixa, ou seja,
a implementação pode ser alterada conforme desejado, desde que respeite a sintaxe da
linguagem e a estrutura lógica. Por exemplo, pode-se iniciar com a instanciação de todas as
transições, depois as mídias e então os places. O que não se pode fazer, por exemplo, é
invocar um método setArcPlace da classe Place se não existe uma instância de ArcPlace
que deve ser passada como parâmetro; este tipo de modificação estaria “quebrando” a
estrutura lógica.
4.3.2. Classe Place
A classe Place estende a classe JFrame que disponibiliza métodos e propriedades que
facilitam a obtenção de um painel para a apresentação das mídias. Dentre estes recursos
tem-se, por exemplo, propriedades que permitem dimensionar o painel de apresentação,
determinar sua localização na tela (coordenadas x e y) e definir o modo visível/invisível.
Cada instância da classe Place possui uma instância de MediaPlace associada.
MediaPlace possui informações sobre a mídia que deverá ser executada pelo place. Além
de um MediaPlace, a classe Place possui também um ArcPlace que contém informações
72
sobre a transição que deverá ser iniciada e o IVT para este arco. Vale lembrar que o IVT
define restrições de sincronização temporal para as mídias.
Para fazer o gerenciamento dos eventos relacionados à execução de uma mídia, foi
implementada, como classe interna de Place, a classe PlayerEventHandler. Dentre os
possíveis eventos gerados pela execução de uma mídia, foram considerados apenas os
eventos gerados pela conexão à fonte da mídia (RealizeCompleteEvent), preparação da
mídia para a apresentação (PrefetchCompleteEvent), fim da mídia (EndOfMediaEvent) e o
fim da mídia num tempo determinado (StopAtTimeEvent) diferente do tempo total da
mídia. Para cada um dos eventos acima citados, foi definido um comportamento que
deverá ser tomado para manter a sincronização.
Os métodos e atributos da classe Place serão apresentados em mais detalhes na
seqüência, mas de uma forma geral, quando um Place é iniciado (método startPlace), é
feita a alocação dos recursos de hardware necessários para a apresentação da mídia, um
Player é criado, os componentes visuais são carregados e o processamento da mídia é
iniciado. Ao final da apresentação, o método startTransitionEvent é invocado, dando
seqüência à apresentação dos demais places. Antes, porém, os recursos que foram
utilizados na apresentação da mídia são liberados.
Até o momento, foi apresentada uma visão geral do funcionamento da classe Place.
Na seqüência, são apresentados, em detalhes, os atributos e métodos que compõem esta
classe.
4.3.2.1. Atributos
Os atributos da classe Place são utilizados no armazenamento de uma série de valores que
variam desde tipos primitivos como string até objetos complexos como Container. Os
atributos desta classe descritos, individualmente, na seqüência têm seu nome sempre
precedido do tipo do dado.
Container container: um container onde estão agrupados os componentes necessários para
a apresentação da mídia como, por exemplo, os componentes visuais da mídia
(visualComponent) e o painel de apresentação obtido pelo método getContentPane(). Este
atributo é protegido (protected).
73
Player player: atributo protegido que corresponde a uma instância da classe Player
necessária para a apresentação das mídias. Através deste atributo, gera a apresentação de
uma mídia, bem como gerencia sua apresentação, por exemplo, monitorando os eventos
gerados por esta. Cada instância de Place terá um objeto da classe Player responsável pela
apresentação da mídia deste place.
Component visualMedia: corresponde ao display que será utilizado na exibição de um
vídeo. Formatos de vídeos diferentes podem ter um display diferente. Caso a mídia a ser
executada for um áudio, será atribuído null para o atributo visualMedia, pois um áudio não
possui componentes visuais. Este atributo é protegido e definido pela invocação do método
getVisualComponent da interface Player.
ArcPlace arcPlace: atributo privado que corresponde a uma instância da classe ArcPlace.
Este atributo é definido e obtido através da invocação dos métodos setArcPlace e
getArcPlace, respectivamente. Um arcPlace corresponde ao arco que saindo de um
determinado place dispara uma transição.
Component mediaControl: atributo privado obtido pela invocação do método
getControlPanelComponent da interface Player, que retorna os controles da GUI conforme
a mídia que será apresentada. A GUI normalmente fornece os seguintes controles (JAVA
CD, 2002):
•
um controle deslizante de posicionamento, para pular para certos pontos no
clipe de mídia;
•
um botão de pausa;
•
um botão de volume que fornece os controles de volume;
•
um botão de propriedades da mídia que fornece informações detalhadas sobre a
mídia.
O atributo mediaControl pode representar diferentes controles, dependendo da
mídia. Por exemplo, o conteúdo de mídia com stream, diretamente de uma conferência ao
vivo, não tem uma barra de andamento porque o comprimento da mídia não é conhecido
(JAVA CD, 2002).
74
MediaPlace mediaPlace: atributo privado que contém uma referência a uma instância da
classe MediaPlace. Seu valor é definido e obtido pela invocação dos métodos
setMediaPlace e getMediaPlace da classe Place, respectivamente.
String mode: atributo privado que contém uma String informando se o place é normal,
final (o último a ser apresentado). Seu valor é definido e obtido pela invocação dos
métodos setMode e getMode da classe Place, respectivamente.
String type: atributo privado que contém uma String informando se o place é atomic
(apresentação de áudio ou vídeo, por exemplo), link (um place que faz a ligação com outro
place) ou compose (um place que corresponde a uma sub-rede). Seu valor é definido e
obtido pela invocação dos métodos setType e getType da classe Place, respectivamente.
Alguns atributos são utilizados no processo de sincronização como, por exemplo, o
atributo transition que especifica qual transição deverá ser ativada; e outros podem ser
utilizados no processo de apresentação das mídias como o atributo visualMedia que
representa um display. O tópico seguinte descreve os métodos definidos para a classe
Place.
4.3.2.2. Métodos
Na seqüência, são listados os métodos definidos para a classe Place. Os métodos aqui
listados estão precedidos do seu tipo de retorno e quando este não for informado, o método
retorna nada.
Place(String, String): método construtor da classe e recebe como parâmetro duas strings,
sendo que a primeira refere-se ao type (tipo) da mídia, se video, audio ou image; e a
segunda string refere-se ao mode (modo) do place, se final, normal ou compose. Um place
no modo final indica que este é o último place a ser apresentado e, após a sua execução, o
Player pode ser finalizado ou a apresentação reiniciada. As strings recebidas como
parâmetros são atribuídas aos atributos type e mode, respectivamente. A atribuição é feita
através da invocação dos métodos setType(String), para type e setMode(String), para mode.
ArcPlace getArcPlace( ): retorna uma referência a uma instância da classe ArcPlace. O
retorno deste método corresponde ao arco que sai do place que invocou o método.
75
getMediaComponents( ): método público que retorna nada. Invoca, internamente os
métodos getVisualComponent e getControlPanelComponent da interface Player e adiciona
os componentes visuais (visualMedia) e os controles (mediaControl) da mídia a ser
executada. Neste método, é também definido o tempo máximo de execução da mídia
(conforme especificado no intervalo de validade temporal do arco), pela invocação do
método setStopTime da interface Player.
MediaPlace getMediaPlace( ): método público que retorna uma referência à instância da
classe MediaPlace, atribuía a um place.
String getMode( ): retorna uma String informando o valor definido para o atributo mode.
Este é um método público.
String getType( ): retorna uma String informando o valor definido para o atributo type.
Este é um método público.
makePlayer(String): este método tem a responsabilidade de criar um player para o arquivo
de mídia que é informado no parâmetro. A String recebida como parâmetro será utilizada
na instanciação de um MediaLocator que é o parâmetro necessário para a invocação do
método createPlayer da classe Manager. O atributo player recebe o retorno na chamada do
método createPlayer. O método makePlayer faz, ainda, a adição do ControllerListener
para o qual o player deverá enviar os eventos gerados. Esta adição é feita através da
invocação do método addControllerListener, passando como parâmetro uma instância de
PlayerEventHandler. Por fim, o método makePlayer invoca o método realize do player.
removePlayerComponents( ): remove o mediaControl e visualMediai do container, fecha
o player pela invocação do método close e define o painel como invisível. Este é um
método público e retorna nada.
setArcPlace(ArcPlace): define o valor para o atributo arcPlace conforme a instância de
ArcPlace que é recebida como parâmetro. Este é um método público e retorna nada.
setMediaPlace(MediaPlace): define o valor para o atributo mediaPlace conforme a
instância de MediaPlace que é recebida como parâmetro. Este é um método público e
retorna nada.
setMode(String): método público que define o conteúdo do atributo mode conforme a
String recebida como parâmetro. Este método retorna nada.
76
setType(String): método público que define o conteúdo do atributo type conforme a String
recebida como parâmetro. Este método retorna nada.
startPlace( ): define as dimensões e posição do display na tela, define o display com visível
se a mídia a ser exibida for um vídeo. Internamente ainda, este método define o conteúdo
do atributo container pela invocação do método getContentPane; obtém o arquivo de mídia
que deverá ser apresentada invocando o método getSrc de MediaPlace e invoca o método
makePlayer, passando como parâmetro o nome do arquivo obtido. O método startPlace é
público e retorna nada.
startTransitionEvent( ): invoca o método startTransition da classe Transition. A instância
de Transition é obtida através do método getTransition do atributo arcPlace. Este é um
método público e retorna nada.
Os métodos definidos são, na sua grande maioria, utilizados para a definição (set) e
obtenção (get) de valores para os atributos da classe, com algumas exceções como é o caso
dos métodos startPlace e startTransitionEvent. O primeiro é utilizado para iniciar a
execução de um determinado place e o segundo realiza as tarefas necessárias para a efetiva
transição de um place.
Além dos métodos e atributos descritos anteriormente, a classe Place possui uma
classe interna chamada PlayerEventHandler que implementa o comportamento que deverá
ser assumido pelo place em determinadas situações. Esta classe é apresentada na
seqüência.
4.3.2.3. Classe PlayerEventHandler
A classe PlayerEventHandler é uma classe interna de Place e nela estão definidos os
comportamentos que o player deverá assumir para os eventos gerados pelo Controller. Os
eventos tratados pela classe PlayerEventHandler estão descritos abaixo:
•
endOfMedia(EndOfMediaEvent) – este método invoca, internamnete, o método
stop do player e os métodos removePlayerComponents e startTransitionEvent
de Place. Este método é invocado quando um place, executando uma
determinada mídia, alcança o fim da mídia;
77
•
prefrechComplete(PrefetchCompleteEvent) – este método é invocado quando os
preparativos para a execução da mídia foram concluídos. Ao ser chamado, este
invoca o getMediaComponents e validate e, ainda, o método start do player;
•
realizeComplete(RealizeCompleteEvent) – este método é invocado quando o
realize de uma determinada mídia foi concluído. Ao ser chamado, este invoca o
método prefrech do player;
•
stopAtTime(StopAtTimeEvent) -
este método é invocado quando o tempo
definido para a execução da mídia através do método setStopTime de Player, foi
alcançado. Ao ser chamado, este método invoca internamente o método stop de
player e os métodos removePlayerComponents e startTransitionEvent de Place.
Os eventos aqui apresentados satisfazem as necessidades da aplicação proposta,
mas outros eventos, também gerados pelo Controller, podem ser implementados, conforme
a necessidade.
No tópico seguinte, é apresentada a classe ArcPlace que representa um arco de um
place para uma transição, conforme especificado no modelo HTSPN.
4.3.3. Classe ArcPlace
Os atributos e métodos da classe ArcPlace são descritos nos tópicos subseqüentes. Como
mencionando anteriormente, na descrição de cada atributo, o nome mesmo é precedido do
seu tipo de dado.
4.3.3.1. Atributos
Na seqüência estão descritos os atributos definidos para a classe ArcPlace.
Transition transition: atributo privado que contém uma referência a um objeto da classe
Transition. Este atributo informa qual é a transição destino do arco. O valor deste atributo
pode ser definido e atribuído através dos métodos setTransition e getTransition,
respectivamente.
78
IVT ivt: contém as especificações de restrição temporal (tempo mínimo, ideal e máximo)
para o arco. Este é um atributo privado e pode ser definido através do método setIVT, e
obtido pelo método getIVT.
A definição dos atributos procurou transferir para a classe, as informações contidas
num arco, segundo o modelo HTSPN. O tópico seguinte descreve os métodos definidos
para a classe ArcPlace.
4.3.3.2. Métodos
A definição dos métodos listados abaixo tem por objetivo prover meios de se obter e
definir valores para os atributos da classe.
ArcPlace(Transition, IVT): método construtor e recebe como parâmetro um objeto
Transition que corresponde a transição para a qual este arco aponta; e um objeto IVT que
especifica as restrições de sincronização temporal para o arco.
IVT getIVT( ): este é um método público que retorna um objeto da classe IVT
correspondente ao ivt do arco.
Transition getTransition( ): método público que retorna uma referência ao atributo
transition.
setIVT(IVT): método público utilizado na redefinição do atributo ivt. O objeto recebido
como parâmetro á atribuído ao ivt do arco.
setTransition(Transition): recebe como parâmetro um objeto Transition que é atribuído ao
atributo transition.
O tópico seguinte descreve a classe Transition que representa a transição de um
place para outro.
4.3.4. Classe Transition
A classe Transition procura mapear para código Java, o conceito de transição definido no
modelo HTSPN. Os atributos e os métodos definidos para esta classe são descritos na
seqüência.
79
4.3.4.1. Atributos
Segundo o modelo HTSPN, as transições possuem uma estratégia e determinadas
estratégias estão relacionadas a um arco em específico como é o caso da estratégia master
em que um place deve ser escolhido para ser o place master; e um conjunto de places que
devem ser ativados após a transição. Mapeando estes conceitos,
foram definidos os
atributos descritos na seqüência.
Strategy strategy: atributo privado que especifica, para uma determinada transição, qual a
estratégia utilizada e, dependendo da estratégia adotada, que outra transição está envolvida.
Por exemplo, na utilização da estratégia master, é necessário definir qual a transição que
será tratada como master. Como strategy é uma instância de Strategy, mais detalhes podem
ser vistos na descrição da classe Strategy.
Vector targetPlaces: este é um atributo do tipo Vector que contém uma referência para
todos os places que devem ser iniciados após a transição. Cada elemento do vetor
corresponde a um place. Os places são adicionados ao vetor através do método
addTargetPlace e quando uma transição é dispara, este vetor é lido e o método startPlace é
chamado, para cada elemento do vetor. Este atributo é privado.
Objetivando a manipulação (obtenção e definição) dos atributos definidos, foram
criados os métodos descritos no tópico seguinte.
4.3.4.2. Métodos
Os métodos definidos para a classe Transition, juntamente com seus parâmetros e tipos de
retorno, são apresentados na seqüência.
Transition(Strategy): método construtor que recebe como parâmetro uma instancia de
Strategy. Internamente, o construtor invoca o método setStrategy passando como
parâmetro a instância recebida e, ainda, inicializa o vetor targetPlaces.
addTargetPlace(Place): método público que adiciona um place no vetor de places que
devem ser iniciados após uma determinada transição. Este método recebe como parâmetro
uma instância de Place e a adiciona no vetor targetPlaces.
80
Strategy getStrategy( ): método público que retorna uma referência ao atributo strategy.
Vector getTargetPlaces( ): método público que retorna uma referência ao atributo
targetPlaces.
setStrategy(Strategy): recebe como parâmetro uma instância da classe Strategy que é
atribuída ao atributo strategy.
startTransition( ): este método é invocado quando da necessidade de se iniciar uma
transição da places. Internamente este método percorre todo o vetor targetPlace invocando
o método startPlace para cada elemento.
O tópico seguinte apresenta a classe Strategy que é o mapeamento para código Java
do conceito de estratégia, apresentado na descrição do modelo HTSPN.
4.3.5. Classe Strategy
A classe Strategy representa as estratégias de sincronização definidas no modelo HTSPN.
Os métodos e atributos definidos para esta classe são descritos nos tópicos subseqüentes.
4.3.5.1. Atributos
Segundo o modelo HTSPN, nove são as estratégias de sincronização. No mapeamento
realizado, foi definido o atributo type que estará referenciando uma destas nove
possibilidades. Os atributos para a classe Strategy são listados abaixo.
Place targetPlace: atributo privado que faz referência a um determinado place. Este
atributo é utilizado quando, devido a estratégia escolhida, é necessário especificar um
determinado place.
String type: este atributo corresponde ao tipo de estratégia que será utilizado na transição.
Os possíveis valores para type são: or, and, master, strong-or, strong-master, or-master,
and-master, weak-master e weak-and.
Algumas estratégias de sincronização exigem, além da especificação do tipo, um
parâmetro que corresponde a um place sobre o qual a estratégia estará sendo aplicada,
como é o caso da estratégia master em que é necessário especificar o place master.
81
Procurando satisfazer esta necessidade, a classe Strategy possui o atributo targetPlace. O
tópico seguinte descreve os métodos da classe Strategy.
4.3.5.2. Métodos
Os métodos da classe Strategy são descritos na seqüência.
Strategy(String): método construtor utilizado quando há a necessidade de se especificar
somente a estratégia utilizada. A string que é recebida como parâmetro é, internamente,
atribuída ao atributo type, através da invocação do método setType.
Strategy(String, Place): método construtor utilizado quando, além da estratégia, é
necessário especificar o place em que a estratégia será aplicada.
String getType( ): método público que retorna uma string informando qual que estratégia
que está sendo utilizada.
setTargetPlace(Place): método público utilizado ara definir em qual place a estratégia
será aplicada.
setType(String): método público utilizado na definição do atributo type onde este recebe o
valor da string recebida como parâmetro.
O tópico seguinte apresenta a descrição da classe MediaPlace juntamente com sues
respectivos atributos e métodos.
4.3.6. Classe MediaPlace
Instâncias da classe MediaPlace contêm informações sobre a fonte e o tipo da mídia que
um determinado place estará apresentando, sendo que o tipo pode variar de um simples
texto a um clipe de filme. Os atributos e métodos desta classe são descritos na seqüência.
82
4.3.6.1. Atributos
Os atributos definidos para a classe MediaPlace, src e type, armazenam informações sobre
a fonte em que a mídia deverá ser buscada e o tipo de mídia (áudio, vídeo etc),
respectivamente. Os atributos são descritos na seqüência.
String src: atributo privado que contém uma string informando a localização do arquivo de
mídia que deverá ser apresentado. O valor deste atributo pode ser definido através do
método setSrc; e obtido através do método getSrc.
String type: atributo privado que contém uma string informando o tipo da mídia de um
objeto MediaPlace. Este atributo pode conter os valores audio, video ou image. O valor
deste atributo pode ser definido e obtido pela invocação dos métodos setType e getType,
respectivamente.
4.3.6.2. Métodos
Os métodos da classe MediaPlace são utilizados na construção de objetos da classe,
obtenção e definição de valores para os atributos. Estes estão descritos na seqüência.
MediaPlace(String, String): método construtor que recebe como parâmetro duas strings. A
primeira, corresponde ao tipo da mídia que será apresentada e é atribuída ao atributo type.
A segunda, corresponde a localização do arquivo de mídia que deverá ser apresentado e é
atribuída ao atributo src.
String getSrc( ): método público que retorna uma string correspondente ao valor do
atributo src.
String getType( ): método público que retorna uma string correspondente ao valor do
atributo type.
setSrc(String): método público que recebe como parâmetro uma string que é atribuída ao
atributo src.
setType(String): método público que recebe como parâmetro uma string que é atribuída ao
atributo type.
83
O tópico seguinte apresenta a classe IVT que corresponde ao intervalo de validade
temporal, apresentado na descrição do modelo HTSPN.
4.3.7. Classe IVT
A classe IVT é o resultado do mapeamento para código Java, do intervalo de validade
temporal apresentado na descrição do modelo HTSPN. Os atributos e os métodos descritos
nas seções subseqüentes são recursos utilizados para o armazenamento e obtenção das
informações de um IVT.
4.3.7.1. Atributos
Os atributos da classe IVT foram definidos como String, porque dependendo do tipo (type)
do place, estes atributos podem receber o caractere “*” quando um tempo ideal para um
determinado arco não for conhecido, como é o caso de places do tipo link. Os atributos
para a classe IVT estão descritos na seqüência.
String ideal: atributo privado que contém um valor que corresponde ao tempo ideal de
duração da apresentação de uma mídia. O tempo é contado em segundos e o valor deste
atributo pode ser definido e obtido pela invocação dos métodos setIdeal e getIdeal,
respectivamente.
String max: atributo privado que contém um valor que corresponde ao tempo máximo de
duração da apresentação de uma mídia. No processo de criação de um player, este atributo
é utilizado (através do meto setStopTime da classe Player) para definir a duração máxima
da apresentação. Caso o tempo máximo seja alcançado, o player assume o comportamento
definido. O tempo é contado em segundos e o valor deste atributo pode ser definido e
obtido pela invocação dos métodos setMax e getMax, respectivamente.
String min: atributo privado que contém um valor que corresponde ao tempo mínimo de
duração da apresentação de uma mídia. A apresentação da mídia não pode ser encerrada
antes do tempo definido por este atributo. Se por algum motivo, a apresentação encerrar
antes do tempo mínimo especificado, o place deve aguardar até o tempo ser alcançado e
então prosseguir, disparando a transição apropriada. O tempo é contado em segundos e o
84
valor deste atributo pode ser definido e obtido pela invocação dos métodos setMin e
getMin, respectivamente.
O tópico seguinte descreve os métodos definidos para a classe IVT.
4.3.7.2. Métodos
Os métodos descritos na seqüência são utilizados na inicialização de instâncias da classe,
obtenção e definição de valores para os atributos.
IVT(String, String, String): o método construtor recebe três Strings como parâmetro. A
primeira corresponde ao tempo mínimo e é, internamente atribuída ao atributo min. A
segunda corresponde ao tempo ideal de duração para a apresentação e é, internamente,
atribuída ao atributo ideal. A última corresponde ao tempo máximo de duração da
apresentação da mídia e é atribuída ao atributo max.
String getIdeal( ): método público que retorna uma string correspondente ao valor do
atributo ideal.
String getMax( ): método público que retorna uma string correspondente ao valor do
atributo max.
String getMin( ): método público que retorna uma string correspondente ao valor do
atributo min.
setIdeal(String): método público que recebe como parâmetro uma string que é atribuída ao
atributo ideal.
setMax(String): método público que recebe como parâmetro uma string que é atribuída ao
atributo max.
setMin(String): método público que recebe como parâmetro uma string que é atribuída ao
atributo min.
A seção seguinte apresenta algumas conclusões acerca do trabalho desenvolvido.
São apresentados, ainda, como sugestões, trabalhos que podem vir a serem desenvolvidos
tendo este como base.
85
5. CONSIDERAÇÕES FINAIS
O modelo HTSPN para especificação de sincronização em sistemas multimídia mostrou-se
bastante eficiente, capaz de modelar interações com o usuário e combinar a sincronização
lógica com a temporal. Estas são características bastante interessantes. A utilização de
estratégias de sincronização tais como strong-or, weak-and e strong-master, permite uma
sincronização não dependente de um valor temporal determinado, mas de um conjunto de
valores obtidos a partir de um conjunto de arcos, desta forma, mesmo que ocorra algum
problema com uma das mídias, por exemplo, a apresentação toda não será comprometida.
As ligações do modelo HTSPN (places do tipo link) fornecem uma maior liberdade, uma
vez que é possível, de um ponto determinado da rede, repetir toda a apresentação, fazendo
uma ligação com o place inicial.
O JMF apresentou grandes possibilidades no que diz respeito a apresentação e
gerenciamento de mídias. Esta API fornece um conjunto bastante amplo de classes e
interfaces que fornecem meios de se trabalhar tipos de mídias, desde o processo de
download (se for o caso) até a sua apresentação.
A modelagem dos conceitos do modelo de Dexter, utilizados no HTSPN (lugares,
arcos e transições), para classes Java mostrou-se bastante interessante. O próprio código
Java, que é gerado a partir de um documento XML PNSched, é simples e fácil de ser
entendido, o que facilita a manutenção e mesmo a adição de novas funcionalidades. Outra
vantagem obtida com esta modelagem é o fato de se ter um conjunto definido de classes
necessitando implementar apenas o código que cria as instâncias e utiliza os métodos. Este
ponto está relacionado à classe Net, pois esta é a única classe que necessita ser modificada
para apresentações diferentes. Vale lembrar que, para a geração da implementação da
classe Net, na linguagem Java, foi desenvolvido um conjunto de templates.
Ao longo da implementação, percebeu-se que a DTD PNSched possibilita uma fácil
especificação de sincronização, mas mostrou-se incapaz de satisfazer a todos os requisitos
86
de especificação, dependendo, às vezes, mais da validação e processamento, do que da
própria especificação. Por exemplo, o elemento place pode assumir o comportamento de
um lugar composto, do tipo link ou atômico, mas para cada um destes, existem
propriedades e comportamentos diferentes. Da forma como está especificado na DTD, é
possível definir um lugar do tipo atômico e, ao mesmo tempo, que este referencia uma subrede (elemento subnet). A Figura 22 mostra um trecho da DTD PNSched onde é feita a
definição dos elementos place e subnet.
<!ATTLIST place
name ID #REQUIRED
type (atomic | compose | link) "atomic"
target_subnet IDREF #IMPLIED
>
<!ELEMENT subnet (subplace+, transition*)>
<!ATTLIST subnet
name ID #REQUIRED
>
Figura 22: Trecho da DTD PNSched – definição dos elementos place e subnet.
Baseado na DTD da Figura 22, um documento XML como mostra a Figura 23 é um
documento XML PNSched bem formado e válido de acordo com a DTD especificada, mas
conceitualmente, um lugar do tipo atômico não pode referenciar uma sub-rede.
<subnet name=”Sub1”>
<subplace>... </subplace>
<transition>...</transition>
</subnet>
<place name=”P1”
type=”atomic”
mode=”normal”
target_subnet=”Sub1” />
Figura 23: Trecho de um documento XML PNSched.
Este problema pode ser resolvido na implementação da classe Place, verificando o
tipo do place e as respectivas restrições, ou mesmo através de um parser, mas isso seria
87
forçar uma restrição que não é definida na DTD PNSched. Modelar separadamente os tipos
de places proporcionaria uma melhor especificação das restrições dos mesmos e,
conseqüentemente, da rede como um todo.
O HTSPN Player é parte de um projeto maior que está sendo iniciado que é o
desenvolvimento de um sistema de sincronização multimídia que possui módulos como,
por exemplo, um Editor Gráfico de Redes de Petri conforme o modelo HTSPN, um Parser,
um Simulador de Redes de Petri Temporizadas (que irá trabalhar em conjunto com o
Editor) e um módulo para o controle de QoS. Estes módulos estarão auxiliando diretamente
o HTSPN Player.
Como trabalhos futuros, tem-se a conclusão e mesmo a modificação da
implementação do HTSPN Player como, por exemplo, a implementação das estratégias de
sincronização e dos demais tipos de places; o desenvolvimento de uma interface para o
mesmo e mecanismos que possibilitem o acesso a mídias distribuídas.
O desenvolvimento deste trabalho possibilitou uma melhor visão das possibilidades
oferecidas pela API JMF e, também, da dimensão e complexidade do projeto no qual o
player, aqui apresentado, está inserido.
88
6. REFERÊNCIAS BIBLIOGRÁFICAS
(ALLEN, 1983) ALLEN, J. F. Maintaining knowledge about temporal intervals.
Communications of the ACM, 1983.
(BLAKOWSKI, 1996) BLAKOWSKI, G. e STEINMETZ, R. “A Media
Synchronization Survey: Reference Model, Specification, and Case Studies,” IEEE J.
Select. Areas Commun., Volume 14, 1996.
(DIAZ, 1993) DIAZ, M; SCÉNAC, P. Time stream Petri nets, a model for
multimedia streams synchronization proceedings of MultiMedia modeling'93, Singapura,
novembro 1993.
(FAGUNDES, 2002) FAGUNDES, F. Especificação de uma Meta-Linguagem para
Sincronização Multimídia. Dissertação (Mestrado em Informática) 2002. Programa de PósGraduação em Ciências da Computação da Universidade Federal de Santa Catarina –
UFSC. UFSC, Florianópolis, julho de 2002.
(HALASZ, 1994) HALASZ, F; SCHWARTZ, M. The Dexter Hypertext Reference
Model. Communication of ACM 37(2), 1994.
(ISSO, 1992) ISO/IEC88744 Hypermedia/Time-Based Structuring LanguageHyTime, 1992.
(JENSEN, 1990) JENSEN, K. Coloured Petri Nets: A High Level Language for
System Design and Analysis. Advances in Petri nets 1990. LNCS 483, Springer-Verlag,
1990.
(JMF, 2002) SUN, Microsystems. API Java Media Framework. Disponível em: <
http://java.sun.com/products/java-media/jmf/2.1.1/apidocs/>, 2002. Acesso em 28 de
agosto de 2003.
(LITTLE, 1990) LITTLE, T. D. C., GHAFOOR, A. Synchronization and storage
models for multimedia objects. IEEE JSAC, v. 8, novembro 1990.
89
(LITTLE, 1991) LITTLE, T.D.C. e GHAFOOR, A., "Multimedia Synchronization
Protocols for Broadband Integrated Services", IEEE J. Select. Areas in Commun, vol. 9,
dezembro de 1991.
(MURATA, 1989) MURATA, T. Petri nets: properties, analysis and applications;
Proceedings of IEEE, vol.77, no.4, pp.541-580, 1989.
(PATHAK, 2000) PATHAK, R; PATEL, D. Synchronization in Distributed
Multimedia Applications. Advanced Programming Languages, 2000. Kent State
University.
(RODRIGUES, 1997) RODRIGUES, R. F. Formatação Temporal Espacial no
Sistema Hyperprop. Dissertação (Mestrado em Informática) 1997. Departamento de
Informática da Universidade PUC-Rio. PUC-Rio, Rio de Janeiro.
(SÉNAC, 1995) SÉNAC, P; SAQUI-SANNES, P; WILLRICH, R. Hierarchical
Time Stream Petri Net: a Model for Hypermedia Systems. 1995.
(SOUZA, 1997) SOUZA, G. L. de F. “Sincronismo na Modelagem e Execução de
Apresentações de Documentos Multimídia”. Tese de doutorado. Departamento de
Informática. Pontifícia Universidade Católica do Rio de Janeiro. Rio de Janeiro, 1997.
(STEINMETZ, 1995) STEINMETZ, R., NAHRSTEDT, K. Resource Management
in Networked Multimedia Systems. IEEE Computer, maio 1995.
(WAHL, 1994) WAHL, T.; ROTHERMEL, K. Representing Time in MultimediaSystems. In Proc. IEEE International Conference on Multimedia Computing and Systems,
Boston, Maio 1994.
(WILLRICH, 1997) WILLRICH, R; SANNES, P. de S. Concepção Formal de
Aplicações Multimídia Java. In: XV SIMPÓSIO BRASILEIRO DE REDES DE
COMPUTADORES (SBRC’97), São Carlos. Anais do XV Simpósio Brasileiro de Redes
de Computadores.
90
ANEXO 1: Código Java da Classe Place.
package htspnPlayer;
import java.awt.*;
import java.awt.event.*;
import java.io.*;
import javax.swing.*;
import javax.media.*;
public class Place extends JFrame{
private String type;
private String mode;
private ArcPlace arcPlace;
private MediaPlace mediaPlace;
//--------------------------------protected Player player;
protected Component visualMedia;
protected Container container;
private Component mediaControl;
public void makePlayer( String mediaLocation ){
System.out.println(mediaLocation);
MediaLocator
mediaLocator = new
MediaLocator(mediaLocation);
try {
player = Manager.createPlayer(mediaLocator);
player.addControllerListener(new
PlayerEventHandler());
player.realize();
}
catch ( NoPlayerException noPlayerException ) {
noPlayerException.printStackTrace();
}
catch ( IOException ioException ) {
ioException.printStackTrace();
}
}
public void removePlayerComponents(){
if ( mediaControl != null )
container.remove( mediaControl );
if ( visualMedia != null )
container.remove( visualMedia );
player.close();
setVisible(false);
}
91
public void getMediaComponents(){
visualMedia = player.getVisualComponent();
if (visualMedia != null )
container.add(visualMedia, BorderLayout.CENTER );
mediaControl = player.getControlPanelComponent();
if ( mediaControl != null ){
container.add( mediaControl, BorderLayout.SOUTH );
double
stopTime
=
Double.parseDouble(((IVT)((ArcPlace)getArcPlace()).getIVT()).getMa
x());
System.out.println("setStopTime("+stopTime+")
...");
player.setStopTime(new Time(stopTime));
}
{
}
protected class PlayerEventHandler extends ControllerAdapter
public
realizeDoneEvent){
void
realizeComplete(RealizeCompleteEvent
player.prefetch();
System.out.println("Realize completo...");
}
public
prefetchDoneEvent){
}
void
prefetchComplete(PrefetchCompleteEvent
getMediaComponents();
System.out.println("prefetch completo...");
validate();
player.start();
public void endOfMedia(EndOfMediaEvent mediaEndEvent){
System.out.println("Fim da Apresentacao...");
player.stop();
removePlayerComponents();
startTransitionEvent();
}
public void stopAtTime(StopAtTimeEvent stopMediaEvent){
System.out.println("Fim da Apresentacao...");
player.stop();
removePlayerComponents();
startTransitionEvent();
92
}
}
//-------------------------------------------------------------public Place(String aType, String aMode){
super("HTSPN Player");
System.out.println("new Place ...");
setType(aType);
setMode(aMode);
}
public Place(){
System.out.println("new Place(null)..");
}
public void startPlace(){
setSize(300,300);
setLocation(300,300);
setDefaultCloseOperation(EXIT_ON_CLOSE);
if(((MediaPlace)getMediaPlace()).getType() != "audio")
setVisible(true);
container = getContentPane();
makePlayer(((MediaPlace)getMediaPlace()).getSrc());
}
public
}
public
mode;
}
public
arcPlace; }
public
mediaPlace;
type;
}
String
getType()
{
return
String
getMode()
{
return
{
return
ArcPlace getArcPlace()
MediaPlace
}
getMediaPlace()
{
return
public void
setType(String aType)
{
type
=
aType;
public void
setMode(String aMode)
{
mode
=
aMode;
public void
setArcPlace(ArcPlace arc)
{ arcPlace = arc;
}
}
public void
mediaPlace = m;
setMediaPlace(MediaPlace m)
}
public void startTransitionEvent(){
System.out.println("startTransitionEvent..");
Transition T;
{
93
null");
if(this.getMode() != "final"){
ArcPlace P = getArcPlace();
if(P != null){
T = P.getTransition();
if(T != null)
T.startTransition();
else
System.out.println("P.getTransition
}
else
System.out.println("getArcPlace = null");
}else{
System.out.println("Modo Final");
System.exit(0);
}
}
}
ANEXO 2: Código Java da Classe ArcPlace.
class ArcPlace{
private Transition transition;
private IVT ivt;
public ArcPlace(Transition aTransition, IVT aIvt){
setTransition(aTransition);
setIVT(aIvt);
}
public void setTransition(Transition aTransition){
transition = aTransition;
}
public void setIVT(IVT aIvt){
ivt = aIvt;
}
public IVT getIVT(){
return ivt;
}
public Transition getTransition(){
return transition;
}
}
ANEXO 3: Código Java da Classe IVT.
=
94
public class IVT{
private String min;
private String max;
private String ideal;
public IVT(String aMin,String aIdeal,String aMax){
setMin(aMin);
setIdeal(aIdeal);
setMax(aMax);
}
public void setMin(String aMin)
{ min = aMin;
}
public void setIdeal(String aIdeal){ ideal = aIdeal;}
public void setMax(String aMax)
{ max = aMax;
}
public String getMin()
public String getIdeal()
public String getMax()
}
{ return min;
{ return ideal;
{ return max;
}
}
}
ANEXO 4: Código Java da Classe MediaPlace.
public class MediaPlace{
private String type;
private String src;
public MediaPlace(String aType, String aSrc){
setType(aType);
setSrc(aSrc);
}
public void setType(String aType){
type = aType;
}
public String getType(){
return type;
}
public void setSrc(String aSrc){
src = aSrc;
}
public String getSrc(){
return src;
}
}
ANEXO 5: Código Java da Classe Transition.
95
import java.util.Vector;
public class Transition{
private Vector targetPlaces;
private Strategy strategy;
public Transition(Strategy aStrategy){
System.out.println("new Transition...");
setStrategy(aStrategy);
targetPlaces = new Vector();
}
public void addTargetPlace(Place targetPlace){
System.out.println("addtargetPlace["
targetPlaces.size()+"]");
targetPlaces.addElement(targetPlace);
}
public Vector getTargetPlaces(){
return targetPlaces;
}
public void setStrategy(Strategy aStrategy){
strategy = aStrategy;
}
public Strategy getStrategy(){
return strategy;
}
public void startTransition(){
System.out.println("startTransition..");
Vector v;
v = getTargetPlaces();
for(int i=0;i<v.size();i++){
if(v.elementAt(i) != null)
((Place)v.elementAt(i)).startPlace();
else
System.exit(0);
}
}
}
ANEXO 6: Código Java da Classe Strategy.
public class Strategy{
String type;
Place targetPlace;
+
96
public Strategy(String aType){
setType(aType);
}
public Strategy(String aType, Place p){
setType(aType);
setTargetPlace(p);
}
public void setTargetPlace(Place p){
targetPlace = p;
}
public String getType(){
return type;
}
public void setType(String aType){
type = aType;
}
}

Player para Sincronização Multimídia Utilizando a Especificação

Transcrição

Documentos relacionados

Proprietário do maior acervo de desenhos animados do mundo, o

Mega Teen 5: Mente Antenada, Coração Sincronizado • Lição 05

EasyNote E2530_Portugal.cdr

Digital Signage Player

FORMATO – VÍDEO 360

Instalação Grátis para o seu Som ou DVD Automotivo em São Paulo

Informações do produto

Transferência de Atleta - Federação Catarinense de Basketball

Actualizar versão do Adobe Flash Player

Newsletter n.4