especificaÇÃo e sincronizaÇÃo de aplicaÇÕes...
TRANSCRIPT
ESPECIFICAÇÃO E SINCRONIZAÇÃO DE
APLICAÇÕES MULTIMÉDIA COM CONTROLO
DISTRIBUÍDO
Luís Filipe Lourenço Bernardo
(Licenciado)
Dissertação para a obtenção do grau deMestre em Engenharia Electrotécnica e de Computadores
Junho de 1994
ii
j ,objectos são representadas utilizando estados, que agregam uma parcela dascaracterísticas internas, as acções relacionadas com ela, e os eventos gerados peloobjecto associados a modificações nessa parcela das características.
Descreve-se como todos os conceitos relacionados com os objectos multimédiasão tipificados, sendo a informação relevante mantida numa base de dados, para quetodas as aplicações e ferramentas no sistema tenham conhecimento das possibilidadesdisponíveis em cada momento, facilitando a expansibilidade do sistema, e permitindoverificações de consistência durante as várias fases do desenvolvimento de umaaplicação.
Define-se uma linguagem de especificação de aplicações multimédia, baseadaem álgebras de processos. Para essa linguagem, descreve-se um algoritmo decompilação genérico, e um compilador que o implementa para criar máquinas deestados.
As aplicações alvo consistem em conjuntos de objectos autónomos queinteragem entre si no plano temporal, espacial e lógico. A abordagem neste trabalhofoi controlar esta interacção de um modo distribuído, dentro de cada objecto, pelainterpretação de máquinas de estado derivadas da especificação.
iii
p j ,characteristics are represented by a set of statuses. Each status combines a part of theobject internal state, the related actions and the events the object can send to theexterior to announce changes in that part of the object.
All the concepts related with multimedia objects are typed, the relevantinformation being stored in a database so that all the applications and tools in thesystem know the possibilities available at any moment. This feature can be used as asupport for expansion of the system and allows for consistency checks at each step ofthe application development.
A language based on process algebras is defined, and used to specify themultimedia applications. A generic compilation algorithm for that language is used ina compiler, to generate state machines.
A target application consists of sets of multimedia objects interacting with eachother in time, space and logically. The approach in the thesis was to control thisinteraction from a distributed point of view - Each object interprets its own statemachine derived from the overall specification.
iv
Sincronização multimédia
Composição multimédia
Classificação em tipos
KEYWORDS
Multimedia objects
Distributed multimedia systems
Distributed Control
Multimedia synchronization
Multimedia composition
Type categorization
v
dissertação, que levou a numerosos melhoramentos no estilo e na correcção.
Aos meus colegas do IST e do INESC, agradeço a amizade, a ajuda prestada e o
excepcional ambiente de trabalho. Devo referir, em especial, o Prof. Vítor Vargas, o
Eng.º Paulo Pereira e o Eng.º Nuno Correia, que contribuíram de forma decisiva para
a realização desta dissertação.
Por fim, agradeço à minha família o apoio e incentivo que sempre me deram ao
longo da minha vida de estudante.
Dedico, por isso, esta dissertação aos meus Pais.
Lisboa, Junho de 1994
Luís Filipe Lourenço Bernardo
vi
AGRADECIMENTOS......................................................................................... V
ÍNDICE ........................................................................................................... VI
LISTA DE FIGURAS ......................................................................................... X
LISTA DE TABELAS......................................................................................... XIII
NOTAÇÃO...................................................................................................... XIV
CAPÍTULO 1. INTRODUÇÃO ........................................................................... 1
1.1. INTRODUÇÃO .................................................................................. 1
1.2. OBJECTIVOS................................................................................... 2
1.3. ESTRUTURA DA DISSERTAÇÃO......................................................... 3
CAPÍTULO 2. TRABALHO RELACIONADO........................................................ 5
2.1. MODELOS DE SINCRONIZAÇÃO......................................................... 5
2.2. SISTEMAS....................................................................................... 8
2.2.1. Infra-estrutura de programação orientada a
objectos da universidade de Genebra ....................... 8
2.2.2. Modelos baseados em redes de Petri ...................... 11
2.2.3. MADE ....................................................................... 15
2.3. NORMALIZAÇÃO .............................................................................. 19
2.3.1. WWW........................................................................ 19
2.3.2. Extensões ao ODA ................................................... 23
2.3.3. HyTime ..................................................................... 25
2.3.4. MHEG....................................................................... 28
vii
3.3. MODELOS DE COMPOSIÇÃO............................................................. 40
3.4. MODELOS DE CONTROLO ................................................................ 42
CAPÍTULO 4. ARQUITECTURA ....................................................................... 47
4.1. DESCRIÇÃO GERAL DOS OBJECTOS ................................................. 47
4.2. MODELO DE SINCRONIZAÇÃO........................................................... 49
4.3. ESTADOS, EVENTOS E ACÇÕES ....................................................... 51
4.3.1. Estado Contexto ....................................................... 54
4.3.2. Estado Anotação ...................................................... 55
4.3.3. Estado Remctrl ......................................................... 56
4.3.4. Outros Estados......................................................... 56
4.4. OBJECTOS COMPONENTES.............................................................. 57
4.4.1. Criação de Componentes......................................... 58
4.5. OBJECTOS MULTIMÉDIA .................................................................. 59
4.5.1. Criação de objectos multimédia................................ 62
4.6. ARQUITECTURA GLOBAL.................................................................. 63
4.6.1. Processo de Autoria ................................................. 64
4.6.2. Gestor de Tipos ........................................................ 65
4.6.3. Gestor de Nomes ..................................................... 67
CAPÍTULO 5. LINGUAGEM............................................................................. 69
5.1. INTRODUÇÃO .................................................................................. 69
5.2. ESTRUTURA GERAL ........................................................................ 71
5.3. ESTRUTURA SINTÁCTICA ................................................................. 72
viii
CAPÍTULO 6. IMPLEMENTAÇÃO ..................................................................... 86
6.1. AMBIENTE DE DESENVOLVIMENTO.................................................... 86
6.1.1. ANSAware ................................................................ 86
6.1.2. Suporte do modelo de comunicação. ....................... 91
6.1.3. Análise do desempenho ........................................... 93
6.2. OBJECTOS MULTIMÉDIA .................................................................. 96
6.2.1. Constituição dos Objectos Multimédia e
Componentes ............................................................ 100
6.3. MÁQUINAS DE ESTADOS.................................................................. 102
6.3.1. Linguagem................................................................ 102
6.3.2. Interpretadores ......................................................... 106
6.4. COMPILADOR.................................................................................. 110
6.4.1. Algoritmo de Compilação.......................................... 111
6.4.2. Compilador ............................................................... 117
6.5. EXEMPLO ....................................................................................... 123
6.6. COMPATIBILIDADE........................................................................... 128
6.7. LIMITAÇÕES.................................................................................... 131
CAPÍTULO 7. CONCLUSÕES .......................................................................... 134
7.1. CONCLUSÕES................................................................................. 134
7.2. TRABALHO FUTURO ........................................................................ 135
ix
x
Figura 2.1 : Relações possíveis entre dois intervalos. ..................................................6
Figura 2.2 : Rede OCPN base para representação de apresentações .......................... 12
Figura 2.3 : Mapeamento do ASP e NSP no modelo de referência OSI. .................... 14
Figura 2.4 : Ambiente de desenvolvimento MADE ................................................... 16
Figura 2.5 : O Navegador de WWW da NCSA, Mosaic em X Windows,
mostrando a página com os serviços locais ao INESC. ........................... 21
Figura 2.6 : Módulo de tradução de objectos HyTime............................................... 28
Figura 2.7 : Utilização do modelo MHEG................................................................. 29
Figura 2.8 : Diferentes níveis para uma aplicação multimédia em MHEG .................. 32
Figura 3.1 : Grupo de objectos componentes que constitui uma aplicação................. 41
Figura 3.2 : Arquitectura Centralizada de Controlo................................................... 42
Figura 3.3 : Arquitectura Distribuída de Controlo ..................................................... 42
Figura 3.4 : Exemplo de recepção de mensagens não atómica. .................................. 44
Figura 3.5 : Exemplo de recepção de mensagens com violação da ordem causal........ 44
Figura 4.1 : Modelo de um objecto multimédia. ........................................................ 48
Figura 4.2 : Estrutura do interface de um objecto componente.................................. 53
Figura 4.3 : Objecto multimédia mais simples em termos de composição................... 59
Figura 4.4 : Objecto multimédia com vários eventos ................................................. 59
Figura 4.5 : Composição de um objecto multimédia. ................................................. 60
Figura 4.6 : Estrutura interna de um objecto multimédia ........................................... 61
Figura 4.7 : Estrutura de um objecto multimédia composto....................................... 61
xi
Figura 5.4: Estruturas de declaração de objectos multimédia externos à
especificação. ......................................................................................... 75
Figura 5.5: Exemplo de declaração de um objecto multimédia................................... 76
Figura 5.6: Exemplo de uma especificação de comportamento. ................................. 85
Figura 6.1 : Modelo computacional do ANSAware................................................... 88
Figura 6.2 : Interacção com o Trader em ANSAware. .............................................. 88
Figura 6.3 : Arquitectura de uma cápsula ANSAware. .............................................. 89
Figura 6.4: RPC síncrono. ........................................................................................ 90
Figura 6.5: RPC sem resposta................................................................................... 90
Figura 6.6: RPC assíncrono. ..................................................................................... 90
Figura 6.7: Tempos de transmissão [ms] em função do comprimento, para ATM e
IPC. ....................................................................................................... 94
Figura 6.8: Tempos de transmissão [ms] em função do número de destinos para
ATM com servidores na mesma cápsula e em cápsulas diferentes. .......... 96
Figura 6.9: Tempos de transmissão [ms] em função do número de destinos para
IPC com servidores na mesma cápsula e em cápsulas diferentes.............. 96
Figura 6.10: Criação de um objecto multimédia de Diapositivos.............................. 101
Figura 6.11: Estrutura da definição de uma máquina de estados. ............................. 103
Figura 6.12: Operações utilizadas durante a criação de objectos e inicialização de
referências do novo objecto.................................................................. 105
Figura 6.13: Operações usadas entre máquinas de estados concorrentes.................. 105
Figura 6.14: Exemplo de declaração de máquina de estados.................................... 106
xii
Figura 6.18: Constituição dos elementos da árvore de comportamento. .................. 119
Figura 6.19: Constituição dos elementos da lista de objectos utilizados. .................. 119
Figura 6.20: Exemplo da secção de especificação de comportamento de um script.. 119
Figura 6.21: Estrutura de nós criada a partir do exemplo da figura 6.20. ................. 120
Figura 6.22: Máquina de estados criada para o objecto A, a partir do exemplo da
figura 6.20............................................................................................ 121
Figura 6.23: Máquina de estados de arranque da aplicação criada para o exemplo
da figura 6.20. ...................................................................................... 122
Figura 6.24: Especificação de uma aplicação de apresentação do sistema
desenvolvido. ....................................................................................... 124
Figura 6.25: Modificação para ter um tempo de apresentação da terceira página. .... 125
Figura 6.26: Primeira página da aplicação de demonstração. ................................... 126
Figura 6.27: Segunda página da aplicação de demonstração, quando o vídeo não
está a correr. ........................................................................................ 126
Figura 6.28: Segunda página da aplicação de demonstração, quando o vídeo está a
correr. .................................................................................................. 127
Figura 6.29: Terceira página da aplicação de demonstração. ................................... 127
xiii
Tabela 6.1: Tempos de transmissão [ms] em função do comprimento da
mensagem. ............................................................................................. 93
Tabela 6.2: Tempos de transmissão [ms] em função do número de destinos
invocados em paralelo no mesmo servidor. ............................................. 95
Tabela 6.3: Tempos de transmissão [ms] em função do número de destinos
invocados em paralelo em servidores diferentes. ..................................... 95
Tabela 6.4: Os tipos de objectos multimédia e de componentes implementados, e
os estados associados. ............................................................................ 97
Tabela 6.5: Código intermédio gerado durante a segunda fase de compilação do
exemplo da figura 6.20. ........................................................................ 121
xiv
informação relacionada com a programação está em caracteres de
máquina de escrever.
�• Expressões em línguas estrangeiras estão em itálico.
1
1.1. INTRODUÇÃO
O tratamento de sinais de banda larga por computadores em ambientes
distribuídos começa a ser hoje uma realidade. As evoluções recentes na tecnologia estão
a abrir uma nova gama de aplicações e possibilidades para os computadores,
introduzindo o termo multimédia em muitas das áreas tradicionais da ciência de
computação e criando novos temas de investigação e desenvolvimento.
No entanto, o termo multimédia banalizou-se, estando associado a um conjunto
de diferentes significados, conforme o meio onde for utilizado. Nesta dissertação o
termo refere-se à geração, representação, processamento, armazenamento e
disseminação de informação processável por computador, expressa por múltiplos meios
dependentes ou não do tempo, tais como dados, gráficos, desenhos, voz, áudio e vídeo
[Steinmetz 90]. O termo multimédia é usado num sentido lato, que tanto inclui os meios
simples (monomédia), como a composição de múltiplos meios, que poderá ser
sincronizada a nível do tempo, do espaço ou logicamente. A composição pode ser
definida a diferentes níveis de complexidade como a hipermédia ou outros mais
complexos como gráficos animados ou realidade virtual. Hipermédia define uma forma
de composição simples, que consiste na definição de documentos globais utilizando
documentos parciais com referências para outros documentos, através das quais se pode
navegar pelas várias partes do documento global.
Nesta dissertação vai-se definir um sistema mais potente e geral do que o
hipermédia, onde a estrutura de ligação entre entidades é passível de ser especificada. É
utilizada uma abordagem orientada a objectos, onde as unidades de estruturação das
aplicações são chamadas de objectos multimédia. Como primeira abordagem à sua
2
1.2. OBJECTIVOS
O objectivo deste trabalho é o estudo e a aplicabilidade da gestão distribuída de
sincronização para um sistema de desenvolvimento e apresentação de aplicações
multimédia interactivas distribuídas. Os componentes principais do sistema estão
representados na figura 1.1.
Autor
Sc rip t
Máquina
Estadosde
Ap lic aç ão
Ob jec tos
Multiméd ia
Utilizadores
Specification
Figura 1.1 : Componentes principais dosistema de desenvolvimento deaplicações multimédia realizado.
O autor constrói as aplicações multimédia escrevendo em linguagem textual uma
descrição designada por script. Um compilador lê como entrada essa descrição, e cria
um conjunto de máquinas de estado, que realizam a especificação. Quando a aplicação é
corrida, cada máquina de estados é interpretada por um objecto, conseguindo-se assim o
controlo de todos os objectos multimédia utilizados na apresentação. Os utilizadores
3
O segundo capítulo começa por descrever alguns modelos de sincronização,
seguindo-se depois a apresentação de um conjunto de outros sistemas e algumas normas
relacionadas com o trabalho desenvolvido nesta dissertação. Para além da descrição,
inclui também alguns comentários sobre as virtudes e limitações de cada sistema ou
norma apresentado.
O terceiro capítulo introduz um conjunto de problemas resultantes da distribuição,
descrevendo as abordagens propostas neste trabalho para os resolver. Mais
especificamente, descreve os modelos de comunicação, de falhas, e de controlo
adoptados nesta dissertação. Introduz ainda os modelos de composição, e a forma como
a distribuição dos componentes é modelada.
O quarto capítulo descreve o modelo de objectos multimédia e a sua constituição.
Na última secção, inclui uma descrição sobre a arquitectura global do sistema.
O modelo apresentado no quarto capítulo é uma evolução do proposto em
[Pinto 93], tendo sido apresentado em [Pinto+ 94]:
"A Constructive Type Schema for Distributed Multimedia Applications."Paulo Pinto, Luís Bernardo, Paulo Pereira.Proceedings BRIS'94. Hamburgo, Junho 1994.
O quinto capítulo define a semântica e a estrutura da sintaxe de uma linguagem
baseada em álgebras de processos, utilizada para descrever aplicações multimédia.
O sexto capítulo descreve como foi implementado o sistema de desenvolvimento
de aplicações multimédia interactivas distribuídas. Descreve o ambiente de
desenvolvimento utilizado, os objectos multimédia realizados, o interpretador e o
compilador. No fim, apresenta um exemplo, e alguns comentários sobre a
compatibilidade e limitações do sistema realizado.
4
5
sincronização, e as características fundamentais de cada um.
Nas restantes secções apresenta-se uma amostra de trabalhos relevantes, e uma
descrição de um conjunto de normas que já existem, ou estão em fase de
desenvolvimento, na área da multimédia.
2.1. MODELOS DE SINCRONIZAÇÃO
O modelo de sincronização descreve as relações entre a ordem de apresentação
dos vários objectos que constituem a aplicação, no domínio do tempo. As principais
abordagens à descrição de sincronização conhecidas da literatura são [Blakowski+ 92]:
�• Sincronização hierárquica. Os objectos multimédia são vistos como uma árvore
onde os nós denotam a apresentação sequencial ou simultânea das subárvores.
�• Sincronização baseada num eixo temporal. Os objectos monomédia são associados
a um eixo de tempo que representa uma abstracção do tempo real.
�• Sincronização em pontos de referência. Destina-se essencialmente a modelar
objectos dinâmicos, ou seja, que apresentam uma evolução no tempo. Essa
evolução não tem de ser obrigatoriamente fixa e previsível, como é apresentado
originalmente, mas pode variar fruto de interacções externas. Os objectos
monomédia dinâmicos são vistos como uma sequência de subunidades discretas
apresentadas tipicamente em intervalos de tempo constantes. À posição de uma
subunidade no objecto chama-se ponto de referência (reference point). A
sincronização entre objectos é definida através de associações entre subunidades
de diferentes objectos que têm de ser apresentadas ao mesmo tempo.
6
Cada objecto é caracterizado pelo intervalo de tempo que dura a sua apresentação.
Se for definida a acção atraso, então este tipo de sincronização permite modelar
qualquer relação que se possa estabelecer entre dois intervalos [Allen 83], como está
representado na figura 2.1. Existem treze relações possíveis, embora apenas se
representem sete, uma vez que as seis que faltam são relações inversas das
representadas, excepto a de igualdade que não tem inversa.
X YX before Y
X equals YXY
X YX meets Y
X overlaps YX
Y
X during YX
Y
X starts YX
Y
X finishes YX
Y
Figura 2.1 : Relações possíveis entre doisintervalos.
As estruturas hierárquicas são fáceis de usar e largamente divulgadas. As
restrições resultam de só poderem ser sincronizadas no início e no fim. Se se pretender
sincronizar apenas excertos do objecto, como no caso da legendagem de um vídeo,
então o objecto tem de ser partido em vários componentes consecutivos, deixando o
objecto de ser visto como uma unidade abstracta. Uma eventual utilização do mesmo
objecto noutro contexto de sincronização implicaria uma nova subdivisão do objecto.
7
ç q , j , g
a sua posição no tempo global. Este modelo apresenta limitações, resultantes de a
sincronização só poder ser definida em pontos fixos no tempo. Assim, não é possível
modelar com facilidade objectos que não têm um tempo de apresentação determinístico,
como aqueles cuja apresentação depende da interacção com o utilizador.
A sincronização em pontos de referência é a mais poderosa de todas, permitindo
modelar qualquer uma das outras. Tal como a sincronização por eixo temporal, suporta
a sincronização em qualquer instante da apresentação de um objecto, mas não tem
limitações em relação a objectos com tempos de apresentação variáveis, pois essas
variações só afectam o instante em que os pontos de referência são atingidos. Com este
tipo de sincronização, os objectos são vistos como uma sequência de pontos de
referência, e não como intervalos, embora, para efeitos de autoria se possam definir
intervalos em relação a dois pontos de referência.
O principal problema associado a este modelo de sincronização é que, ao
contrário do modelo de sincronização hierárquico, é possível definir especificações
incoerentes, onde se declaram dependências anticausais na sincronização de eventos,
com o consequente bloqueio (deadlock) da apresentação. É assim necessário utilizar
mecanismos para detectar as incoerências deste género.
8
orientada a objectos para aplicações multimédia [Gibbs 91]. O projecto baseia-se na
utilização do paradigma de objecto para modelar praticamente tudo, desde os
componentes até aos tipos de dados, e aos tipos de ligações entre componentes.
Objecto multimédia é definido como um objecto activo (ou seja, que tem estado,
métodos, e que pode executar acções autonomamente), que produz e/ou consome
valores multimédia, de um tipo específico e a um dado ritmo. Este objecto vai ter
associada uma lista de portos, onde cada porto define um fluxo de dados multimédia
independente, caracterizado por um tipo e pela direcção (entrada ou saída). Os objectos
multimédia chamam-se fontes (sources) se só gerarem valores multimédia, destinos
(sinks) se só consumirem valores multimédia, ou filtros (filters) se gerarem e
consumirem valores multimédia.
No sistema são definidas duas hierarquias de classes: uma hierarquia de relações
supertipo/subtipo para os tipos de dados, e uma hierarquia de classes com herança para
os objectos multimédia. A primeira define os tipos de dados multimédia, e é utilizada
para testar a compatibilidade nas ligações entre portos de entrada e os portos de saída. A
hierarquia de classes define as classes de objectos multimédia primitivos disponíveis,
contendo informação sobre os portos que os compõem, métodos na sua interface e
variáveis internas, sendo definidas relações de herança de protótipos entre as várias
classes.
Os objectos multimédia podem dividir-se em dois grupos: os objectos multimédia
primitivos e os objectos multimédia compostos. Os objectos multimédia primitivos
contêm as interfaces para os elementos básicos (em software ou hardware encapsulado
por uma interface em software) do sistema, como uma câmara de vídeo, ou uma janela
X Windows a correr um visualizador de diapositivos. Os métodos dos objectos variam
entre as várias classes, havendo um conjunto de funções comuns, como run e stop, e
9
Os modelos de composição, que incluem para além das relações de sincronização
relações topológicas, modificaram-se significativamente desde a versão original
apresentada em [Gibbs 91], até à versão mais recente, apresentada em [Mey+ 92, Mey+
93].
Em [Gibbs 91] a composição é toda feita ao nível dos objectos multimédia
compostos, sendo utilizados dois modelos de composição para descrever as aplicações:
composição de fluxos de dados (configurational relationships) e composição
temporal (temporal relationships). No primeiro são especificadas as ligações entre os
portos de entrada e de saída dos vários objectos (primitivos ou compostos) que
compõem o objecto composto.
Na composição temporal, é especificado o sequenciamento temporal dos
componentes sobre uma linha de tempo (timeline). O tempo lógico de cada objecto é
mapeado no tempo do objecto composto que o envolve. A partir deste mapeamento são
calculados os pontos de transição que delimitam o intervalo de tempo em que o objecto
está activo, que depois serão utilizados pelos objectos compostos durante o controlo da
apresentação. Quando a apresentação corre, dá-se um segundo mapeamento do tempo
do objecto composto, para o tempo de apresentação, o que permite o suporte de
operações como velocidade de apresentação variável ou inversão da apresentação.
A função dos objectos compostos é controlar a conexão e desconexão dos
componentes quando os pontos de transição são atingidos, e controlar o tempo de
apresentação dos vários componentes que compõem o objecto composto. O objecto
composto controla os relógios de apresentação de cada componente, de modo a garantir
que estes não estão dessincronizados com o relógio de apresentação, sendo configurável
a política de gestão adoptada. Uma das políticas possíveis é TEST_SYNC, onde o
10
ç , q p p
Por outro lado, a arquitectura de objectos desenvolvida teve uma base tecnológica, não
existindo conceitos lógicos que permitam ver esses componentes como um interface de
funções, insensível a modificações na tecnologia utilizada.
Em [Mey+ 92, Mey+ 93] são revistos os modelos de composição, tendo sido
acrescentado um, o modelo de composição de actividades.
O modelo de composição de fluxos de dados (dataflow) manteve-se desde a
versão de [Gibbs 91], tendo sido desenvolvido um editor gráfico [Mey+ 93] para a
especificação desta componente das aplicações, criando assim uma linguagem gráfica
de especificação.
O modelo de sincronização foi inteiramente revisto, passando de uma
sincronização baseada num eixo temporal para uma sincronização em pontos de
referência. Do ponto de vista de sincronização, os objectos são vistos como actividades
(instâncias da classe Activity), que podem receber eventos de aceitação (acceptance
events), e produzir eventos de notificação (notification events). Os eventos de aceitação
correspondem a métodos dos objectos em [Gibbs 91], e permitem modificar o estado
das actividades. Os eventos de notificação não existiam em [Gibbs 91], e são usados
pelas actividades para anunciar modificações no seu estado interno. Todas as
actividades vão ter pelo menos os eventos de aceitação run e interrupt, e o evento
de notificação end, podendo ter outros como stop, reverse, dependendo do tipo de
actividade (ou seja, objecto).
No modelo de composição de actividades, a dependência temporal é especificada
introduzindo a dependência da activação de eventos de aceitação, em função da
recepção de eventos de notificação, ou conjunções e/ou disjunções desses eventos,
definindo assim um conjunto de relações de causalidade. O modelo de composição
11
p ç ç p ç
Nos modelos de composição propostos em [Mey+ 92], foram ultrapassadas
algumas das limitações do modelo anterior [Gibbs 91], nomeadamente o suporte de
interacção com o utilizador. No entanto, o facto de se especificar as aplicações
utilizando independentemente a composição temporal e a composição de actividades,
pode introduzir problemas de inconsistência a nível das especificações. Uma solução
possível para o problema, seria converter as especificações feitas com a composição
temporal nas especificações equivalentes na composição de actividades, permitindo uma
posterior edição neste modelo de composição.
Há alguns problemas comuns às duas versões desta infra-estrutura de
programação de aplicações multimédia. A semântica da interacção com o sistema foi
definida a nível da implementação, não existindo nenhuma especificação formal. Este
facto foi minimizado com o desenvolvimento de editores gráficos, para a especificação
das aplicações, que impõem uma semântica. Por outro lado, não existe a gestão dos
tipos dos objectos a nível do sistema, o que obriga cada utilizador a conhecer quais são
as características dos objectos que vai utilizar, e os seus interfaces.
Este modelo foi desenvolvido para o suporte exclusivo de objectos multimédia,
não suportando objectos que não possam ser descritos como fontes, destinos ou filtros,
ou seja, que não tratem fluxos de dados dentro do modelo. Limita assim, a possibilidade
de adaptar aplicações já existentes para funcionarem dentro do modelo.
2.2.2. Modelos baseados em redes de Petri
Nesta secção é apresentada uma técnica para a especificação formal e modelação
de relações temporais para composição multimédia, baseada na utilização de um
modelo estendido de redes de Petri, o OCPN (Object Composition Petri Net) [Little+
12
; ( g
áudio), até níveis mais elevados de sincronização (como anotações de voz em vídeo).
Esta lógica define os modos como dois intervalos de tempo podem estar
relacionados. Qualquer descrição de um documento é assim constituída por um
conjunto de transições entre lugares que representam os intervalos de tempo.
P
P P
Figura 2.2 : Rede OCPN base pararepresentação de apresentações
Em [Little+ 90a] demonstra-se que o OCPN é isomorfo em relação à lógica de
intervalos temporais, conseguindo representar-se qualquer relação entre dois intervalos
(P , P ) com a rede representada na figura 2.2. A rede é constituída por dois lugares
associados aos intervalos, de duração e , mais um lugar P que representa um
atraso de . O tipo de relação temporal definida vai depender da relação entre os três
tempos, , e .
O refinamento consecutivo das redes de Petri é o mecanismo usado para suportar
os vários níveis de abstracção, que consiste em poder substituir-se uma subrede por um
único lugar.
Nesse artigo é fornecido um exemplo de uma base de dados para objectos
persistentes e imutáveis. Neste exemplo, os objectos são guardados recorrendo a uma
árvore binária, onde os ramos são estruturas iguais às representadas na figura 2.2 e as
folhas contêm os objectos guardados. A recuperação e apresentação de informação da
base de dados é realizada por um algoritmo recursivo, que percorre a árvore e cria um
processo para cada lugar. Durante a apresentação, o algoritmo constrói uma rede de
processos que replica a rede original.
13
( ) , ( ),
aos utilizadores em terminais interactivos.
Definem-se três níveis de integração para um sistema de informação distribuído:
um nível físico (que lida com comunicação); um nível de serviço (que fornece funções
para a composição de objectos); e o nível de interface com o utilizador (ligado à
apresentação e interacção com o utilizador).
Para os obter recorre a dois tipos de sincronização:
�• A sincronização de objectos multimédia, de alto nível, é utilizada para os
níveis de integração acima do físico, recorrendo a OCPN.
�• A sincronização de fluxos de dados, de baixo nível, é utilizada para o nível
físico de integração, onde os streams são produzidos, transferidos e apresentados como
amostras de tamanho finito em intervalos de tempo fixo, e corresponde à definição da
qualidade de serviço pretendida, com parâmetros tais como atraso médio e máximo. É
utilizada com objectos que são adquiridos simultaneamente, ou para controlar erros de
comunicação, como o jitter.
Em termos de protocolos, os dois tipos de sincronização vão estar associados a
dois níveis independentes [Little+ 91], o ASP (Application Synchronization Protocol) e
o NSP (Network Synchronization Protocol).
Na figura 2.3 está representado o mapeamento dos níveis ASP e NSP no modelo
de referência OSI para interligação de sistemas abertos [Rose 90]. O NSP foi mapeado
no nível sessão pois lida com o estabelecimento de conexão ponto-a-ponto,
autenticação, etc. No entanto, caso o nível transporte não forneça funções de controlo
da qualidade de serviço, terá de ser o NSP a fornecer esses serviços, tendo então
funcionalidades características do nível transporte.
14
Nível Lóg ic oNível Físic o
de Sincronizaçãoda Aplicaçãoe da Rede
Figura 2.3 : Mapeamento do ASP e NSP no modelo de referênciaOSI.
Para permitir o controlo distribuído, a rede OCPN é serializada e decomposta em
classes de dados independentes, sendo calculados os tempos de controlo para cada
subsequenciamento, utilizando um algoritmo descrito em [Little+ 91]. O percorrer da
rede OCPN é feito através da troca de pacotes de controlo entre as fontes e o destino.
Há algumas limitações inerentes às OCPN. Embora se consiga definir
agrupamentos de estados, estes são puramente sintácticos, não existindo um conceito de
alto nível que agrupe estados, tal como os processos nas álgebras de processos. Por
outro lado, as OCPN são demasiado estáticas. A rede não permite representar
significados semânticos diferentes de relações de tempo estático, como independência
no tempo entre dois estados. Para além disso, todas as interacções com o utilizador têm
de ser consideradas na rede, o que limita bastante a interacção com o utilizador.
Houve várias tentativas para ultrapassar estas dificuldades, como a descrita em
[Prabhakaran+ 93]. A abordagem utilizada foi o aumento do modelo OCPN de modo a
incluir interrupções do utilizador que modificam o tempo de execução de um lugar de
três maneiras possíveis: terminação da execução, modificação temporária do tempo de
execução ou modificação permanente do tempo de execução.
Embora se consiga resolver alguns problemas relacionados com a estaticidade da
rede, outros continuam, como a impossibilidade de representar a dependência da
15
p j ( pp p ), p
do programa comunitário ESPRIT III, e pretende definir e realizar um ambiente de
desenvolvimento orientado a objectos para aplicações multimédia. O desenvolvimento
do MADE está a ser feito em paralelo com os trabalhos do comité da ISO (ISO/IEC
JTC 1/SC 24), encarregado de definir um standard para ambientes de apresentação para
programação multimédia, o PREMO.
O ambiente completo MADE contém um conjunto de objectos e serviços
relacionados [Herman+ 93], como está representado na figura 2.4. Todos os objectos do
modelo são activos, e dividem-se em duas categorias: toolkit (biblioteca de
componentes) e utilitários (utilities). O nível de toolkit é composto pelos objectos base
do sistema MADE. O nível de utilitários é um nível definido em cima do nível de
toolkits, e é constituído por objectos complexos, que definem um interface de
programação com um nível de funcionalidade superior. O exemplo mais significativo
são os objectos interpretadores de scripts (roteiros), que no seu conjunto vão poder
definir várias Scripting Languages. As aplicações vão poder ser desenvolvidas
directamente sobre o conjunto de objectos do toolkit utilizando a linguagem de
programação mC++, ou então utilizando componentes definidas sobre os objectos
utilitários, como seja um script. Para além disso, existem definidos um conjunto de
utilitários (User Interface Tools), que definem um interface gráfico para acesso ao
sistema, como o editor de composições, o construtor de interfaces com o utilizador
(user interface builder) ou os editores monomédia.
16
Base deDados
Comunicação
Figura 2.4 : Ambiente de desenvolvimento MADE
Destacam-se dentro do MADE toolkit, objectos destinados a fazer interface com
bases de dados, e objectos específicos para a comunicação entre processos. Os primeiros
permitem a definição de objectos permanentes, enquanto que os segundos suportam o
acesso distribuído aos objectos. Para permitir utilizar estas funcionalidades, todos os
objectos MADE estão preparados para se converterem num formato apropriado para
serem guardados em bases de dados ou serem enviados por rede, e inversamente, para
reconstruir o seu estado interno a partir de dados nesse formato.
Os restantes objectos do toolkit estão organizados em dois grandes grupos, os
objectos média (Media Objects) e os objectos de combinação (Combination Objects).
Os objectos média têm como função controlar directamente diferentes média
numa maneira única, independente do equipamento ou firmware, existindo quatro
categorias principais: gráficos (suportando 2D e 3D), de animação, som e vídeo.
Os objectos de combinação suportam a combinação dos objectos média, existindo
cinco áreas de combinação: de imagem (Imaging), estruturação (Structuring),
sincronização (Synchronization), interacção (Interaction) e gestão de restrições
(Constraint Management). A combinação de imagens é feita utilizando objectos de
imagem (image objects), que permitem combinar várias imagens produzidas por outros
objectos numa imagem única. A estruturação permite definir agregados de objectos
organizados sobre a forma de um grafo, em programas interactivos. Para tal, usa
17
p j ç g ç
utilizando objectos de restrição (constraint objects), que suportam condições nos
tópicos de animação, sincronização de médias, interface com o utilizador e
posicionamento geométrico.
O esquema fundamental de sincronização temporal usado no MADE é a
sincronização em pontos de referência (reference point synchronization) [Correia+ 93].
Para cada objecto MADE sincronizável (que tem uma evolução temporal), pode-se
definir um conjunto de pontos de referência específicos ao média (como trama de vídeo,
amostra de som, etc). Cada ponto de referência tem associada informação como
instruções internas para sincronização e referências para outros objectos sincronizáveis
que devem ser sincronizados com ele. Quando o objecto atinge o ponto de referência, a
sincronização é feita por troca de mensagens com os outros objectos activos, esperando
pela resposta. Sobre este modelo de sincronização, o MADE toolkit definiu ainda um
mecanismo de sincronização baseado no tempo. Existe um objecto temporizador (timer)
que gera eventos de tempo, que são usados para controlar acções baseadas no tempo.
Os mecanismos de interacção entre objectos no MADE são baseados na troca de
mensagens síncronas entre objectos [Arbab+ 93a]. Para cada método do objecto, pode
haver duas formas de recepção de mensagens. O método por defeito (queued) recorre a
uma fila de espera, ficando o chamador suspenso até a mensagem ser servida. Se a
mensagem não tiver parâmetros e o método não retornar valores, então poder-se-á
utilizar o método amostrado (sampled), onde o chamador não fica suspenso, excepto
durante a comunicação da mensagem. A escolha de método de recepção para cada
método do objecto é interno ao objecto, e o mundo exterior não tem conhecimento
disso. Os métodos estão classificados segundo uma prioridade, sendo processados
primeiro os pedidos sobre métodos mais prioritários.
18
p p , p
�• gerir restrições. Por exemplo, quando se pretende apresentar uma animação com
uma bola saltitante e tocar um som cuja frequência e volume depende da posição
e velocidade da bola, e se pretende definir essa relação exteriormente à animação,
ou seja, tocar esses sons mesmo quando o utilizador move a bola com o rato.
Neste caso, o objecto com a animação pode delegar o tratamento das funções que
controlam a posição e velocidade da bola para um objecto de restrição, que se
encarrega de chamar as funções do objecto animação, e as operações de controlo
do som.
�• modelar a modificação dos comportamentos de elementos em animação.
�• representação da degradação progressiva (graceful degradation) da qualidade de
objectos, em aplicações de tempo crítico.
O MADE é um dos sistemas onde a definição dos objectos foi levada mais longe,
tendo-se definido um conjunto de mecanismos internos, que tipicamente são
considerados detalhes de implementação. No entanto, ao tornar-se opaca para o
chamador a semântica de recepção de mensagens do receptor de mensagens, impediu-se
a definição formal da operação de invocação de métodos, pois o emissor não sabe a
ordem por que os eventos vão ser processados, tornando eventualmente algumas
especificações ambíguas, pois a sua semântica vai depender da implementação das
operações.
O mecanismo de delegação é poderoso e eficiente, mas para ser correctamente
utilizado é necessário ter um conhecimento profundo dos componentes do sistema.
Assim, seria preferível ter mecanismos mais simples na interface de programação do
utilizador, embora se devesse continuar a utilizar a delegação internamente para
optimizar a implementação dos sistemas.
19
p ,
2.3. NORMALIZAÇÃO
2.3.1. WWW
Embora não seja uma norma internacional, o World-Wide Web (WWW ou W3)
[Lee+ 93], está a tornar-se uma norma de facto pela grande expansão que tem entre os
utilizadores da Internet. Apesar de não estar em linha coincidente com esta dissertação,
a sua importância e popularidade justificam uma breve referência à sua estrutura.
O WWW fornece um meio uniforme para obter informação disponível na
Internet. O utilizador pode aceder aos documentos navegando através de um conjunto
de hiperligações, passando transparentemente pelos vários servidores envolvidos, ou
então, requerendo pesquisas introduzindo texto (ou um comando complexo). Os clientes
WWW correm localmente, permitindo aceder à rede através de selecções com o rato.
Os clientes apresentam um interface uniforme para um conjunto de serviços fornecidos
por servidores existentes na rede (normalmente numa máquina diferente), que de outra
maneira, teriam de ser acedidos por aplicações específicas.
O WWW define:
�• Uma linguagem de hipertexto com marcas de formatação (HTML - Hypertext
Markup Language) que todos os clientes WWW devem entender, e que é usada
para a transmissão de elementos básicos, tais como texto, menus e informação de
ajuda. Esta linguagem tem um formato compatível com o standard SGML
[ISO 86].
20
g , p ç g ,
optimizado para o suporte de saltos em hipertexto.
As apresentações em WWW estão organizadas em páginas de informação
independentes, que têm vários componentes. Cada página pode ter figuras, texto e
entradas para ligações hipertexto, sendo cada página definida independentemente das
outras. Quando uma página é apresentada, é feita a apresentação em paralelo de todos
os componentes, que são carregados um a um dos servidores respectivos. Depois, o
cliente WWW bloqueia-se à espera de receber uma ordem para ir buscar outro
documento.
A iniciativa WWW ainda está em evolução, sendo previsível o suporte de novos
tipos de protocolos. Uma limitação que deverá ser ultrapassada, é a realização de um
serviço de nomes, que permita a referência a documentos por nome independente da
localização, ao contrário do URL, onde o endereço do servidor é um campo obrigatório.
Na figura 2.5 vê-se o navegador de WWW da NCSA, Mosaic em X Windows,
mostrando a página com os serviços locais ao INESC. No topo está indicado o título do
documento e o endereço (URL). O texto sublinhado corresponde a ligações hipertexto,
bastando seleccionar um item, para se saltar para o documento correspondente. No caso
representado, as opções disponíveis são: servidores locais ao INESC de um protocolo
específico (ftp, Archie, X.500, Gopher); ligações para documentos internos; ou então
ligações para serviços externos.
21
Figura 2.5 : O Navegador de WWW da NCSA, Mosaic em XWindows, mostrando a página com os serviços locaisao INESC.
Na tabela 2.1 são comparadas algumas das características de vários sistemas de
pesquisa de informação em rede. Na tabela só são apresentados o WAIS (Wide Area
Information Server) [Addyman 93], o Internet Gopher [Anklesaria+ 93] e o WWW,
embora existam outros sistemas relevantes1.
1Em [Obraczka+ 93] é apresentada uma lista exaustiva dos sistema de pesquisa de informação
existentes na Internet.
22
externoHipertexto - - Sim
Funções:Pesquisa Sim Sim SimRefinamento dePesquisa
Sim - -
Referência a outrosservidores
- Sim Sim
Protocolos suportadospelos clientes:
WAIS Sim por gateway SimX.500 - por gateway por gatewayFTP - por gateway SimNNTP (Net News) - por gateway SimGopher - Sim SimHTTP - - Sim
Tabela 2.1: Comparação de vários sistemas de informação em rede.
Os três sistemas são baseados numa arquitectura cliente-servidor, no entanto a
forma como o utilizador acede à informação é diferente: No WWW e no Gopher o
utilizador acede à informação navegando no espaço de informação disponível, que está
ligada respectivamente por um conjunto de ligações hipertexto e um sistema de menus.
No WAIS, o utilizador acede à informação através de um mecanismo de pesquisa
baseado em perguntas a uma base de dados distribuída de índices para documentos.
Observe-se ainda a crescente compatibilidade com outros protocolos, desde o
WAIS até ao WWW, que oferece um interface para um conjunto significativo de
serviços de acesso a informação na Internet.
A versão actual de WWW é basicamente um sistema de hipertexto distribuído,
não suportando a apresentação de média com uma variação temporal, como vídeo ou
23
2.3.2. Extensões ao ODA
Nesta secção descreve-se outra aproximação à sincronização multimédia que
consiste numa extensão da norma ODA (Open Document Architecture) [ISO 89], de
forma a incluir relações temporais [Hoepner 91].
Actualmente o ODA define conteúdos de tipo carácter, gráfico e imagem. Foram
definidas extensões ao ODA para integrar tipos de dados dependentes do tempo nesta
norma, tais como áudio e vídeo.
No modelo estendido, a sincronização é representada em termos de acções
(actions), definidas entre dois eventos (unidades atómicas de acção), o startpoint e o
endpoint. Estes eventos tanto podem ser definidos em unidades absolutas de tempo,
como referidos relativamente a outras acções. As acções subdividem-se em atómicas
(se não têm pontos de referência entre o startpoint e o endpoint), que não são
subdivisíveis para efeitos de sincronização, e acções compostas, que agrupam acções
atómicas ou compostas.
O modelo de sincronização abstracto é baseado em expressões de caminho (path
expressions) [Campbell+ 74], que descrevem a sequência de operações permitidas. Os
operadores de caminho definidos são:A B (Parallel-last): As acções A e B têm um startpoint comum e são executadas
concorrentemente. A acção composta termina quando todas as acções
intervenientes terminarem.A B (Parallel-first): As acções A e B têm um startpoint comum e são executadas
concorrentemente. A acção composta termina quando pelo menos uma das acções
intervenientes terminar.
24
ç p q çAi* (Repetition): A acção é repetida o número de vezes que for especificado, ou
caso não esteja definido, será o utilizador a controlar o número de vezes.N A: (Concurrency): A acção A deve ser executada N vezes concorrentemente.
No artigo mostra-se que se se definir uma acção T (temporizador), o conjunto de
operadores (Parallel-last, Parallel-first, Sequential) permite representar qualquer
relação temporal possível entre duas acções (interpretadas como intervalos).
A integração da informação de sincronização no modelo de ODA foi feito apenas
na estrutura de exposição (layout structure), tendo sido deixada a integração dessa
informação na estrutura lógica (logical structure) para trabalho posterior.
A integração das expressões de caminho foi feita reorganizando-as, de maneira a
adaptar-se à estrutura em árvore, utilizada em ODA para representar a informação de
exposição. Cada nó da árvore contém os operadores, e as folhas contêm as acções. Para
além disso, definiu-se um conjunto de novos atributos para definir o comportamento
dos objectos face ao tempo, nos quais foram mapeados os vários operadores definidos
para as expressões de caminho:
�• CONTENT TEMPORAL TYPE (para objectos básicos), define se o objecto
conteúdo associado é invariante no tempo, ou variante no tempo.
�• DURATION (para objectos básicos), define a duração de cada acção.
�• OBJECT SYNCHRONIZATION TYPE (para objectos compostos), contém
expressões de caminho com os operadores Parallel-last, Parallel-first, Sequential
e Selective.
�• REPETITION (para objectos compostos), para representar o operador Repetition.
25
q , p ç p ç
utilizador.
Como se pode ver em [Lauer 75], debaixo de algumas condições, as expressões de
caminho podem ser vistas como equivalentes das redes de Petri. Consequentemente,
este modelo vai sofrer de problemas semelhantes aos vistos para a representação com
redes de Petri. No entanto, e em relação ao OCPN, ele apresenta uma maior
flexibilidade para representar interacções com o utilizador, permitindo representar
algumas relações de tempo não estáticas. Como as interacções com o utilizador se
encontram limitadas à activação de objectos, não é possível representar outro tipo de
sincronização, como por exemplo, modificar propriedades dos objectos.
2.3.3. HyTime
O HyTime é uma generalização da linguagem de marcação SGML (Standard
Generalized Markup Language) [ISO 86] para incluir hipermédia, de modo a permitir
representar ligações hipertexto, as relações temporais entre os diversos tipos de
documentos e novos tipos multimédia. Foi desenvolvido para permitir a troca de
documentos hipermédia entre aplicações, eventualmente desenvolvidas para diferentes
plataformas, introduzindo novas construções na linguagem SGML usando as facilidades
de DTD (document type definitions), nomeadamente algumas meta-DTDs (ou seja,
definições de tipo de documentos dentro de definições de tipo de documentos).
Em HyTime não é definido nenhum standard para a representação de dados ou
tipo de dados. Embora durante esta apresentação seja utilizada a palavra objecto como
um tipo de informação qualquer, desde texto a vídeo e scripts, esses objectos são
definidos pelas aplicações e não pela norma. Em HyTime a informação é transferida
26
ç q p ç ),
ou podem ser obtidos a partir de constantes na especificação.
O modelo de processamento convencional do HyTime põe a aplicação no controlo
de tudo o que acontece, recorrendo a serviços de apoio de um conjunto de programas
que formam a máquina HyTime (HyTime Engine). A máquina vai ser utilizada para
controlar a leitura e interpretação do documento, criando um descritor do documento,
que depois será utilizado para fazer a resolução de endereços, e sequenciamento em
termos das unidades do espaço de coordenadas.
A linguagem divide-se em seis módulos [NewComb 93], sendo os mecanismos de
composição suportados em quatro deles: módulo de endereço de Localização (Location
Address), módulo de hiperligações (HyperLink), módulo de espaço de coordenadas
finito (Finite Coordinate Space) e módulo de tradução (Rendition).
O mecanismo de SGML de endereçamento (#ID-#IDREF) foi expandido de modo
a suportar referências externas (e logo hiperligações). A informação pode ser
referenciada por nome (para entidades com nome único, como ficheiros, etc.), por
posição (para entidades num espaço mensurável, utilizando as unidades de tempo
definidas no módulo de espaço de coordenadas finito), e por semântica. Neste último
caso, pode ser por atributos ou por notação específica (semelhante a uma linguagem de
acesso a bases de dados).
O módulo de hiperligações define cinco tipos de hiperligações (hyperlinks)
[Newcomb 91]. Os mais relevantes são os plinks (property link), ligações com
propriedades, que permitem associar nomes de atributos e valores a uma ligação, e os
ilinks (independent links), ligações independentes, muito genéricas, que permitem
entre outras coisas, associar processamento ao atravessar da ligação.
27
p j p ç p ç ,
o objecto (ou vários objectos) é incorporado num intervalo, que representa a posição
inicial e extensão do objecto (ou objectos). Normalmente, os intervalos são definidos
em relação a valores do espaço de coordenadas, definindo uma sincronização baseada
num eixo temporal. No entanto, utilizando hiperligações, é possível definir a posição
inicial de um intervalo por referência a outros intervalos, assim como relacionar a
extensão de um intervalo com extensões de outros intervalos, suportando-se uma
sincronização em pontos de referência.
O atributo "EXTENT RECONCILIATION" vai permitir definir a estratégia
quando o objecto (controlado pela aplicação) não obedecer à extensão do intervalo
(controlada pela máquina HyTime). Vão existir várias estratégias possíveis como o
vamping (repetir o objecto tantas vezes até encher a extensão do intervalo) ou clipping
(se o objecto exceder a dimensão do intervalo é cortado).
O módulo de tradução, representado na figura 2.5, controla as distorções que os
objectos podem ter: projecção e modificação.
A primeira, chamada projecção, permite converter a posição e extensão de um
intervalo de um sistema de coordenadas para outro. Esta projecção poderá ser não
linear, por exemplo seleccionando apenas parte de uma imagem, ou modificando a
escala de tempo de modo a introduzir pausas ou efeitos especiais, como fading. Pode-se
estabelecer uma analogia entre esta transformação, e o que acontece num processador
de texto, quando converte um documento não formatado para uma versão formatada.
2o texto original [Newcomb 93] usa o nome event, mas esse nome é usado nesta dissertação com
outro significado distinto.
28
Objec to Ob jec toInverte c or Expande
Figura 2.6 : Módulo de tradução de objectos HyTime
A segunda distorção, chamada modificação, aplica-se a um intervalo, e consiste
numa modificação do conteúdo dos objectos nesse intervalo. O HyTime fornece uma
notação para especificar a aplicação de modificadores (externos ao HyTime) aos
objectos.
Embora esta norma seja bastante poderosa, segue uma orientação diferente da
dominante na área da multimédia. Define uma linguagem de estruturação comum para
documentos multimédia, onde todo o processamento dos tipos de dados é feito por
programas externos, em vez de os incluir na linguagem. Este facto, associado à natureza
não procedimental da linguagem, tornam difícil o acesso a facilidades específicas dos
objectos. Por outro lado, não oferece suporte para a interacção com o utilizador, que
terá de estar sempre escondida atrás de um objecto. Por fim, existem limitações
resultantes da utilização de atributos estáticos para definir a adaptação dos objectos aos
intervalos: A adaptação não é modificável no decorrer da aplicação, e está limitada ao
conjunto de valores suportados pela máquina HyTime.
2.3.4. MHEG
A sigla MHEG significa "Multimedia and Hypermedia information coding Expert
Group", e corresponde ao grupo de trabalho JTC1/SC2/WG12 da ISO/IEC, que
pretende definir uma representação codificada de informação multimédia ou
29
MHEGFormatador
MHEGAna lisador
MHEGob jec to
FormatoInternoFormato
InternoFormatoInternoFormato
Interno
FormatoInternoFormato
InternoFormatoInternoFormato
Interno
Figura 2.7 : Utilização do modelo MHEG.
A norma define uma aproximação orientada a objectos para a representação, onde
todos os detalhes internos de informação de apresentação são encapsulados debaixo da
abstracção objecto MHEG, acedendo a aplicação cliente através de funções de alto
nível (métodos). Os objectos MHEG são unidades de informação multimédia e
monomédia para efeitos de transferência pela rede, ou por memória de massa (figura
2.7). É feita uma distinção entre objectos MHEG, que contêm a estrutura de
informação reutilizável, e os visualizadores, que correspondem a uma dada
apresentação de um dado objecto. Para interpretar um objecto e inicializar um
visualizador sobre um dado objecto existe um sistema de suporte de run-time, a
máquina MHEG. Cada máquina MHEG poderá utilizar um formato interno local,
sendo o formato definido na norma [ISO 93b] usado obrigatoriamente apenas durante
transferências entre aplicações.
A interacção entre a aplicação cliente e os objectos (e internamente entre os
objectos) vai ser feita através da troca de mensagens. Embora o standard defina as
mensagens, a semântica associada ao uso e apresentação de objectos é definida ao nível
da aplicação, e não ao nível do MHEG.
30
ç p
�• Objectos de Acção que suportam a especificação de invocação de métodos
em objectos.
�• Objectos de Ligação (Link), que ligam satisfação de um conjunto de
condições sobre objectos (ou visualizadores) à execução de acções sobre um
ou mais objectos (ou visualizadores) destino. As condições são compostas
de uma condição gatilho sobre um objecto (ou visualizador) fonte, mais um
conjunto de condições adicionais (eventualmente noutros objectos ou
visualizadores).
�• Objectos Script, contêm um script codificado, mais a identificação da
linguagem de script utilizada. A classe é definida para especificar
interacções arbitrariamente complexas sobre objectos e visualizadores. O
formato dos scripts é definido externamente ao MHEG, sendo interpretados
por elementos da máquina MHEG, dedicados a suportar uma linguagem de
script.
�• Objectos Componentes que podem ser mapeados em visualizadores e interactuar
com a aplicação cliente. Definem-se três subclasses:
�• Objectos de Conteúdo (Content), correspondem a dados monomédia,
contêm a informação mais o atributo Hook, que define o formato dos
dados. Os objectos da classe Content também são utilizados para
transferir outros dados externos ao MHEG (como apresentações HyTime,
etc).
�• Objectos de Interacção correspondem a elementos de interacção com o
cliente com duas variantes: menus e entrada de dados.
31
j ç
média, métodos de codificação usados no objecto e recursos recomendados para o
sistema de apresentação.
2.3.4.2. Tipos de Acções
O norma MHEG descreve um conjunto de acções básicas, em termos do efeito
que elas têm nos estados dos objectos, e que se destinam a fornecer a estrutura mínima
para o objecto interactuar com a infra-estrutura. Para além destas, há acções específicas
para cada objecto, que fornecem um interface para a funcionalidade característica desse
objecto. As acções são suportadas pela máquina MHEG, sendo a sua semântica definida
localmente pela forma como a máquina MHEG, e a aplicação que suporta o objecto, as
interpreta.
As acções estão divididas em quatro grupos:
�• Acções de Preparação, que permitem a máquina MHEG manipular objectos.
No caso de objectos Componentes, vão controlar a instanciação de
visualizadores. Incluem as acções Prepare, Destroy, e Return, que
são comuns a todos os objectos, pois são herdadas da classe raiz da
hierarquia MHEG: MH-OBJECT.
�• Acções de Apresentação, que permitem controlar o estado dos
visualizadores, e contêm acções como Run e Stop.
�• Acções de Projecção, que permitem controlar a apresentação do objecto
num visualizador. Estas vão depender do tipo de média envolvido (texto,
som, imagem parada, gráficos, vídeo, ...).
�• Acções de Interacção, que permitem modificar os resultados de interacções,
e contêm acções como SetResponse e SetModifiability, para
32
ObjectoComposto
ObjectoComposto
aplicação multimédia em MHEG
Numa aplicação multimédia/hipermédia que utilize uma máquina MHEG, podem
existir vários níveis de controlo. A aplicação vai interactuar directamente sobre objectos
componentes através da máquina MHEG, constituindo o nível superior de controlo.
O segundo nível, será gerido pela máquina MHEG. Tipicamente, a aplicação vai
interactuar com objectos compostos, que têm definida internamente toda a informação
de sincronização necessária para gerir a apresentação dos objectos internos (em objectos
de Ligação e objectos de Script). Existe assim, uma duplicação de funções em relação à
sincronização de apresentações. Uma dada apresentação poderá ser especificada
utilizando um objecto composto, ou então, o controlo pode ser concentrado na
aplicação, que lida com objectos mais simples.
A nível da máquina MHEG, vão existir quatro níveis de sincronização :
1. Sistema. Neste nível a sincronização é muito próxima do stream de dados, como
no caso de sincronização de lábios com som de voz. A norma MHEG não suporta
este tipo de sincronização, mas vai recorrer a outras normas (como MPEG),
encapsulando este tipo de sincronização dentro de objectos de Conteúdo.
2. Espaço-Temporal. Define a posição no tempo ou espaço de um objecto em
função de outro. O MHEG vai suportar directamente este nível de sincronização
utilizando objectos de Ligação dentro de objectos Compostos. Este nível vai
suportar a definição de relações:
�• sequenciais entre dois objectos (apresentados continuamente sem atraso).
33
ç p j
�• sincronização cíclica para um ou mais objectos
3. Condicional. A satisfação de um conjunto de condições sobre objectos e
visualizadores pode desencadear acções noutros objectos. Novamente este tipo de
sincronização vai poder ser feito utilizando objectos de Ligação. Vai ser utilizado
para suportar documentos hipermédia.
4. Script. Este é o nível mais complexo, e é definido externamente à norma MHEG.
Um script poderá ter sincronização complexa que contabiliza respostas do
utilizador, valores calculados e o estado dos recursos locais à máquina MHEG. A
gestão deste nível de sincronização é feita em componentes dedicados da máquina
MHEG, a interpretar os scripts, e a interactuar com os restantes componentes da
máquina MHEG. Os scripts são guardados em objectos script, e são utilizados
internamente a objectos Compostos.
2.3.4.4. Comentários Finais
O MHEG e o HyTime são de entre todas as normas apresentadas, as mais
significativas na área da especificação de documentos multimédia. São, no entanto,
desenhadas para dois contextos diferentes. O MHEG assume implicitamente que os
utilizadores são aplicações interactivas baseadas em WANs, enquanto o HyTime não
faz assunções acerca da natureza do utilizador. No MHEG os objectos têm um interface
de funções, sendo suportada uma programação do tipo procedimental, o que é vantajoso
para tirar proveito das facilidades específicas de cada objecto. Por outro lado, suporta
directamente a interacção com o utilizador, sendo portanto mais adaptada para a
especificação final de aplicações multimédia. No entanto, as especificações não são tão
genéricas como as de HyTime, estando dependentes dos tipos de objectos que existem
definidos no momento da especificação da aplicação, e do interface que apresentam.
34
p ç , g q q
tendência será para surgirem no futuro WANs que suportam a qualidade de serviço
necessária para aplicações multimédia (como a RDIS de banda larga), observa-se que
esta norma é insuficiente para as necessidades futuras.
35
multimédia completamente funcionais. A nível comercial poder-se-á destacar o
Hypercard da Apple e o Viewer da Microsoft, ou ainda outros menos conhecidos, como
o BRAMA (Build, Run & Animate Multimedia Applications), desenvolvido no INESC.
Nesta dissertação é colocada a ênfase no suporte de aplicações onde os
componentes se encontram distribuídos geograficamente. Isso vai permitir a partilha de
recursos multimédia que ainda hoje são caros, abrindo a possibilidade de aparecer um
conjunto vasto de novas aplicações, que explorem a possibilidade de acesso de
utilizadores remotos. Mas se a distribuição traz grandes vantagens, também tem um
conjunto de problemas que é necessário resolver.
Neste capítulo são apresentados os modelos de comunicação, de falhas, de
composição e de controlo que foram adoptados nesta dissertação, sendo discutida a
influência da distribuição nas opções tomadas.
3.1. MODELOS DE COMUNICAÇÃO
Quando se desenvolve uma aplicação distribuída, ou seja, onde os vários
componentes da aplicação estão espalhados por vários locais, surge a necessidade de os
fazer interagir. É assim necessário que os componentes troquem informação entre si. O
modelo de comunicação especifica quais os modelos a adoptar para a troca de
mensagens nos vários domínios das aplicações multimédia.
Uma aplicação multimédia tem duas componentes distintas, dados e controlo, que
introduzem requisitos diferentes em termos de comunicação. Esses requisitos
introduzem a necessidade de utilizar protocolos de transporte distintos, para permitir
uma realização o mais eficiente possível.
36
vídeo e o áudio, que não suportam grandes atrasos, nem variações no ritmo de
transmissão. Em relação aos erros, existe alguma flexibilidade, podendo ser toleradas
algumas perdas, consoante o tipo de dados isócronos. Por exemplo, a perda de uma
imagem de um vídeo não comprimido, ou de alguns milisegundos de som não é
detectável por um utilizador humano. No entanto, esse facto já não se verifica com
vídeo comprimido segundo o formato MPEG [ISO 11172], onde há tramas que são
codificadas com informação diferencial, em relação a outras tramas. Se for utilizada a
classificação definida em [Andrews 91], então o modelo de comunicação para a troca
de dados isócronos que mais se aproxima do pretendido é a passagem de mensagens
assíncrona, no qual os canais têm, conceptualmente, capacidade ilimitada, pelo que o
envio de uma mensagem é não bloqueante. No entanto, este tem de ser enriquecido,
com a noção de qualidade de serviço fornecido, onde será especificada a largura de
banda mínima, o atraso e o jitter máximos.
Algumas das redes que suportam esta funcionalidade são:
�• ATM (Asynchronous Transfer Mode) [Prycker 91], modo de transferência
de informação utilizado na futura Rede Digital com Integração de Serviços
de Banda Larga (RDIS-BL). As classes A e B da Camada de Adaptação
ATM (AAL = ATM adaptation Layer) suportam a transferência de fluxos
de dados isócronos de ritmo binário respectivamente fixo e variável.
�• FDDI-II (Fiber Distributed Data Interface) [Prycker 91], uma rede local de
velocidade razoavelmente alta, que permite suportar tráfego isócrono.
�• DQDB (Distributed Queue Dual Bus) [Prycker 91], camada do nível MAC
(Medium Access Control) da norma IEEE 802.6, utilizada em redes
metropolitanas. Quando utilizada no modo PA (Pre-Arbitrated) fornece um
serviço isócrono.
37
p p , p
destinos, a um dado ritmo binário, e com características de atraso controladas.
O XTP (Xpress Transfer Protocol) [XTP 92] é um protocolo leve, concebido para
as redes de alta velocidade e que inclui as funcionalidades dos níveis rede e transporte
do modelo OSI. Este protocolo tanto pode funcionar em modo circuito virtual como em
modo datagrama, suportando controlo de erros por retransmissão selectiva, controlo de
fluxo, controlo de ritmo, e comunicação multiponto fiável.
O ATM apresenta um conjunto de características que o torna adequado para
suportar aplicações multimédia distribuídas a nível universal porque é extremamente
versátil suportando os serviços requeridos por futuros sistemas multimédia, e permite a
utilização de débitos variáveis e muito elevados. Assim, a futura RDIS-BL aparece
como uma das plataformas mais promissoras para o suporte de aplicações multimédia
distribuídas.
3.1.2. Dados de Controlo
As mensagens de controlo têm especificações opostas aos dados multimédia
isócronos. Não pode haver perdas, embora possam existir alguns atrasos. Caso se
perdesse uma mensagem de controlo utilizada para activar a apresentação de um
objecto, então a apresentação poderia ficar incompleta, ou mesmo parada. A
sensibilidade em relação aos atrasos, vai ser tanto maior, quanto mais baixo for o nível
de controlo que se está a utilizar. Se se estão a enviar mensagens de controlo para
sincronizar dois fluxos de dados multimédia de fontes distintas, então os atrasos terão
de ser mínimos. Mas, se se estão a trocar mensagens para controlar a activação de
objectos, então a tolerância pode ser maior. De qualquer modo, para assegurar a melhor
38
, j , g p p
A troca de mensagens de controlo vai ser modelada pela passagem síncrona de
mensagens, utilizando a classificação definida em [Andrews 91]: O cliente que envia
uma mensagem bloqueia-se à espera que o receptor a receba, sendo os comandos de
entrada e saída de mensagens executados sincronizadamente. Este modelo foi
introduzido por Hoare na linguagem CSP (Communicating Sequential Processes)
[Hoare 85], permitindo a definição de uma semântica bem definida para troca de
mensagens de controlo.
A passagem síncrona de mensagens pode ser obtida com um conjunto vasto de
protocolos, sobre qualquer uma das redes referidas anteriormente. A eficiência máxima
é obtida com protocolos optimizados para o suporte de RPCs (Remote Procedure
Calls), onde se minimize o número de mensagens trocadas durante uma invocação
remota, seguindo esquemas semelhantes ao proposto em [Birrel 84]. Para além disso, os
protocolos devem suportar multicast fiável e o envio de dados eficientemente. Um dos
protocolos que satisfaz estas especificações é o XTP.
Existe ainda, um conjunto de sistemas de desenvolvimento de aplicações
distribuídas, que fornecem a funcionalidade requerida para a troca de mensagens de
controlo num sistema multimédia distribuído. Entre eles podem-se referir o ANSA, o
DCE e o Isis. O ANSA [Ansa 93] consiste numa das primeiras implementações da
arquitectura do ODP (Open Distributed Processing) [ISO 93], e suporta o
desenvolvimento de aplicações num estilo orientado a objectos, usando o modelo de
interacção cliente-servidor. O DCE (Distributed Computing Environment) [OSF 93] é
um sistema composto por um conjunto de componentes integrados que fornece um
ambiente para o desenvolvimento e execução de aplicações utilizando o modelo de
interacção cliente-servidor. Entre os serviços existentes no DCE incluem-se um serviço
39
p j
modo a ser compatível com o standard CORBA (Common Object Request Broker
Architecture) [OMG 91], ainda a ser definido.
3.2. MODELOS DE FALHAS
Numa realização centralizada, quando o sistema falha, tipicamente a aplicação
falha como um todo, ou por erro de programação, ou porque a máquina onde está a
correr falhou. Numa realização distribuída, o modelo de falhas complica-se, pois as
aplicações podem estar a correr simultaneamente em diversas máquinas, que podem
falhar independentemente. Neste caso as falhas podem-se dividir em dois grupos
[Lamport+ 90]: as falhas de comunicação e as falhas de processo.
As falhas de comunicação, assumem-se habitualmente como resultantes de perda
de mensagens, e são tratadas pelos protocolos de comunicação utilizados no sistema.
As falhas de processos, resultam de algum processo não funcionar, ou funcionar
mal. Podem ser definidas utilizando vários modelos [Lamport+ 90]:
�• Falhas de paragem: o modelo mais restritivo, o processo avariado não faz nada.
�• Falhas de omissão: o processo avariado não envia nenhuma mensagem.
�• Falhas Bizantinas: o modelo mais genérico, onde apenas se assume que o
processo avariado não afecta as comunicação entre os outros processos, mas pode ter
qualquer outro comportamento anormal.
Nesta dissertação foi adoptada uma subclasse do modelo de falhas por paragem, o
modelo fail-stop, onde para além dos processos avariados não fazerem nada, os outros
processos sabem que eles estão avariados. Esta opção complica o desenvolvimento do
sistema de suporte da arquitectura, pois introduz a necessidade de utilizar processos de
40
Os modelos de composição definem os contextos e paradigmas em que os
objectos podem interagir entre si. Estes modelos são os mecanismos que o autor utiliza
para construir uma aplicação. Quando se especificam composições num sistema
centralizado, descreve-se a sequência de apresentação dos objectos que constituem a
aplicação, e que são locais à máquina onde está a correr a aplicação.
No entanto, quando se está perante um sistema distribuído, há a necessidade de
fornecer configurações adicionais, pois aqui os objectos multimédia são decompostos
num conjunto de componentes, onde alguns geram os sinais multimédia, outros
consomem e apresentam os sinais multimédia, podendo ainda existir componentes que
modificam fluxos de dados multimédia. Neste caso, define-se porto como um terminal
de transmissão ou recepção de dados multimédia.
O modelo de composição de fluxos de dados, consiste na especificação das
ligações entre os portos dos componentes, e foi proposto originalmente em [Gibbs 91].
Neste artigo, a composição de fluxos de dados e a especificação da sincronização das
aplicações são feitas a nível global da aplicação, para todos os componentes nela
utilizados.
No entanto, do ponto de vista de especificação da sincronização das aplicações, é
mais simples para o programador de aplicações continuar a ver "objectos multimédia" e
não apenas um conjunto de componentes. O suporte de objectos multimédia
distribuídos, permitire simplificar a interacção com os diversos componentes, que é
gerida automaticamente, escondendo-se a distribuição no que diz respeito à
especificação de sincronização. O modelo de composição de fluxos de dados passa
então a ser utilizado apenas internamente aos objectos multimédia distribuídos, pois as
trocas de fluxos de dados são feitas apenas entre os componentes de cada objecto
41
g p p p ç q p ,
que são utilizados para compor quatro objectos multimédia, com os respectivos
interfaces de controlo. Os componentes são representados por círculos. Os portos são
representados por quadrados, que são internos ou externos aos círculos, respectivamente
quando são portos de entrada ou de saída.
Figura 3.1 : Grupo de objectos componentesque constitui uma aplicação.
Nesta dissertação, os objectos multimédia distribuídos são utilizados como a base
do processo de composição de aplicações, chamado-se simplesmente de objectos
multimédia, por analogia aos objectos em sistemas centralizados. Definem-se assim,
dois modelos de composição:
�• Um modelo de composição de fluxos de dados que descreve a configuração
dos objectos multimédia em termos de componentes e os fluxos de dados multimédia
entre eles.
�• Um modelo de composição de controlo que descreve o comportamento das
aplicações em termos de trocas de mensagens de controlo entre objectos multimédia.
42
O modelo de controlo, define a maneira como é feito o controlo das aplicações.
Para uma aplicação ser apresentada, devem existir no sistema controladores e objectos,
que interagem através da troca de mensagens de controlo. No entanto, podem-se definir
várias arquitecturas para controlar essa aplicação, utilizando uma maior ou menor
centralização do controlo. Os dois casos limites, são uma arquitectura completamente
centralizada, onde existe uma relação estritamente do tipo cliente-servidor entre o
controlador e os objectos, e uma arquitectura completamente distribuída, onde
associado a cada objecto existe um controlador responsável pelo controlo desse objecto.
Objecto MM
Controlador
Objecto MM
Objecto MM
Figura 3.2 : Arquitectura Centralizada deControlo
ControladorObjecto MM
Controlador
ControladorObjecto MM
ControladorObjecto MM
Figura 3.3 : Arquitectura Distribuída deControlo
Numa arquitectura centralizada, representada na figura 3.2, existe um único
controlador a correr a máquina de estados que controla a aplicação. O controlador
invoca as operações dos objectos, e recebe e processa toda a informação de controlo,
gerada por eles. Os objectos desempenham um papel passivo, de servidores do
controlador.
43
ç p
ter um gestor de nomes, que providencie o registo da identificação dos controladores
activos, de modo a tornar o seu acesso conhecido no sistema. Assim, sempre que um
controlador tiver de receber informação de controlo de outros controladores, ele tem de
divulgar o seu acesso, de maneira a que outros o passam invocar.
Comparando as duas arquitecturas, verifica-se que a primeira tem uma estrutura
mais simples. Verifica-se também que é mais eficiente em termos da utilização da
largura de banda disponível, porque enquanto na arquitectura centralizada os eventos só
são enviados para o controlador central, na distribuída, um evento pode ter de ser
transmitido para praticamente todos os controladores activos.
Por outro lado, a dificuldade de construção da máquina de estados também é
significativamente maior no caso da arquitectura distribuída. Os controladores só têm
acesso ao seu estado local, o que complica o suporte de: variáveis globais, que têm de
ser partilhadas por vários controladores; e operadores de sincronização cuja semântica
faça depender a transição da ordem de chegada das mensagens de controlo, como por
exemplo, o operador escolha (choice) no LOTOS [ISO 87] (símbolo []).
O problema da gestão de variáveis globais é semelhante ao enfrentado pelos
sistemas de gestão de objectos distribuídos, como por exemplo, o COMANDOS
[Sousa+ 91], podendo-se utilizar qualquer das soluções definidas nesse contexto. Três
soluções possíveis são: encapsular cada variável num controlador, sendo acedida através
da troca de mensagens de controlo; mapear a variável em memória partilhada; ou
migrar a variável para um controlador, sempre que ela for acedida.
O problema dos operadores de sincronização como o operador escolha, deriva de
poderem ser enviadas várias mensagens de controlo para vários controladores quase no
mesmo instante, que condicionam qual é a operação que deve ser feita a seguir. Caso a
44
( ) [ ], q g ç
recepção em todos os controladores para onde a mensagem foi enviada.
B1
B2
Figura 3.4 : Exemplo de recepção demensagens não atómica.
B1
B2
Figura 3.5 : Exemplo de recepção demensagens com violação daordem causal.
O facto de haver várias máquinas de estados a correr em paralelo, utilizando um
protocolo de transmissão de mensagens com atrasos variáveis, introduz ainda algumas
dificuldades adicionais, relacionadas com a recepção de mensagens fora da ordem
causal. No exemplo da figura 3.5, representa-se o envio da mensagem para dois
controladores B1 e B2, tendo o processo B1 gerado a mensagem após a recepção
de . Se o atraso no envio para B2 for muito grande, e de B1 para B2 muito pequeno,
então B2 vai receber a mensagem antes de ter recebido , o que pode gerar
inconsistências na máquina de estados do controlador B2. Este problema pode ser
ultrapassado, utilizando protocolos de comunicação de broadcast causais (Causal
Broadcast) [Isis 92], que garantem a ordenação causal na recepção em todos os
controladores para onde a mensagem foi enviada. Estes protocolos acrescentam à
mensagem original um campo com um vector de tempo [Schwarz+ 91], que contém o
tempo lógico do instante em que a mensagem foi enviada. Ao receber uma mensagem,
45
, q p ,
indiscriminadamente para todas as mensagens, mas apenas para aquelas onde a recepção
por uma ordem anticausal puder dar origem a erros, durante a apresentação da
aplicação.
Atendendo às dificuldades apresentadas para a arquitectura distribuída de
controlo, conclui-se que a arquitectura de controlo centralizada permite realizar a
máquina de estados de maneira mais eficiente para aplicações onde um único utilizador
interage com uma aplicação multimédia, ou com um conjunto de utilizadores passivos
(que não activam nenhuma aplicação).
Mas a arquitectura de controlo centralizada tem limitações quando se está perante
uma aplicação que envolva vários utilizadores com papéis activos durante a aplicação,
porque só é suportado um controlador. Assim, não existem mecanismos para os
utilizadores poderem correr partes da aplicação localmente, mas obriga sempre à
existência de um utilizador que tem de activar o controlador da aplicação.
Um dos exemplos mais elucidativos onde estas limitações se fazem sentir, são as
aplicações de videoconferência com suporte de trabalho cooperativo, destacando-se
entre os trabalhos desenvolvidos nesta área, o sistema BERKOM. O BERKOM
(Berliner Kommunikationssystem) [Altenhofen+ 93] é um dos primeiros projectos de
teste de RDIS de banda larga a nível mundial, que na sua segunda fase teve como
objectivo, oferecer uma única infra-estrutura de comunicação uniforme para as futuras
aplicações multimédia de banda larga. O projecto compreendeu três áreas de trabalho: o
Serviço de Transporte Multimédia [Boecking+ 92], que fornece a plataforma de
comunicação audiovisual, utilizando uma versão modificada do protocolo XTP sobre o
protocolo ST-II; o Serviço de Correio Multimédia, que facilita a troca de documentos
multimédia entre participantes nas videoconferências (onde são utilizadas as extensões
46
, p q
entrem em qualquer fase numa conferência, assumam diversos papéis (moderador,
participante, observador), e lancem aplicações que são partilhadas pelos restantes
utilizadores. Ao analisar a arquitectura desenvolvida, verifica-se que grande parte da
sincronização necessária corresponde a gestão de testemunhos (tokens) e a modificação
dinâmica de ligações entre portos. Assim, ele poderia ser realizado de uma maneira
natural numa arquitectura de controlo distribuído, onde cada participante estaria a correr
uma aplicação local, que interactuava com as aplicações dos outros participantes. A
solução adoptada no BERKOM foi fazer a gestão de testemunhos em servidores
centralizados, que são acedidos pelas aplicações dos clientes, obtendo-se assim uma
arquitectura com um servidor central rodeado de servidores periféricos.
Atendendo às limitações do modelo de controlo centralizado, verifica-se que a
solução óptima passa por uma solução mista, onde se usa uma organização hierárquica,
de arquitectura descentralizada exteriormente (se esta for necessária), para suportar a
interacção entre controladores, e sincronização centralizada internamente a cada
aplicação, para maximizar a eficiência.
47
foi adoptado. No fim, descreve-se a forma como os objectos multimédia são utilizados
na arquitectura global.
4.1. DESCRIÇÃO GERAL DOS OBJECTOS
Um modelo para objectos multimédia deve exibir as seguintes características:
�• Distribuição. O modelo deve contemplar a distribuição dos componentes, de
maneira a suportar a partilha de equipamento e informação multimédia, assim como o
suporte de interacção entre utilizadores em pontos distintos da rede.
�• Permitir qualquer tipo de interacção sobre os objectos. Os objectos
multimédia não se devem limitar a ser blocos não estruturados que apenas começam e
acabam, de uma forma atómica, mas devem permitir a definição de pontos de
sincronização intermédios.
�• Uniformidade. O modelo de sincronização deve ser suficientemente poderoso,
para permitir suportar de uma forma comum, a sincronização de especificações em
domínios diferentes, como relações temporais, relações espaciais ou relações lógicas.
�• Interacção com utilizadores. O modelo deve permitir um elevado grau de
interactividade com o utilizador.
�• Evolução. O modelo deve permitir modificar e criar novas funcionalidades de
maneira a suportar as constantes evoluções da técnica, tanto a nível de equipamentos
como normas de codificação de dados e métodos de os processar. Para tal, toda a
dependência tecnológica deve ser encapsulada, e a compatibilidade deve ser definida a
um nível de abstracção suficientemente elevado, que permita limitar ao mínimo as
48
modificam o fluxo de dados. Por exemplo, um objecto de vídeo seria decomposto no
componente que gera o fluxo de tramas de vídeo, e no componente que as recebe e
apresenta, e que pode existir numa máquina diferente. Os objectos componentes
podem subdividir-se em [Gibbs 91]:
�• Fontes (Sources), se só gerarem dados multimédia.
�• Destinos (Sinks), se só consumirem dados multimédia.
�• Filtros (Filters), se gerarem e consumirem dados multimédia.
Para efeitos de composição e sincronização, é mais simples continuar a ver o
objecto como um todo, e não como um conjunto de componentes. Seguindo a
abordagem apresentada na secção três do capítulo anterior, a distribuição é escondida
do utilizador, sendo oferecido um interface único para o exterior através de um gestor.
O gestor recebe as mensagens de controlo destinadas ao objecto e encaminha-as para os
componentes convenientes.
Fonte Destino
Gestor Figura 4.1 : Modelo de um objecto multimédia.
Na figura 4.1 está ilustrada a estrutura de um objecto multimédia. Os objectos
multimédia são entidades compostas por fontes, destinos, eventualmente filtros, e pelo
gestor. Na figura utilizou-se a notação introduzida na secção três do capítulo anterior,
onde os objectos componentes são representados por círculos, e os portos, que
representam pontos de entrada ou saída de dados multimédia, estão representados por
49
4.2. MODELO DE SINCRONIZAÇÃO
A sincronização de aplicações pode ser definida a vários níveis, dependendo da
finalidade que se pretende atingir. Pode-se definir uma sincronização de baixo nível,
onde a interacção é definida ao nível das unidades de transferência de dados multimédia
(por exemplo, as imagens de vídeo), ou então, trabalhar num nível superior, onde a
interacção é definida em termos do controlo da apresentação de objectos multimédia.
Neste trabalho optou-se por não suportar directamente uma sincronização de
baixo nível como a que é apresentada em [Little+ 91], e é o foco em outros trabalhos
como [Steinmetz 90] ou [Stefani+ 92]. A preocupação essencial nestas abordagens está
ligada ao sincronismo das apresentações dos elementos básicos dos streams de dados,
estando directamente associada à comunicação de dados. Assim, na sincronização de
baixo nível, são definidos operadores como o bloqueio restrito (restricted blocking)
[Steinmetz 90], para suportar o tratamento de situações singulares entre os elementos do
stream, como por exemplo, quando um deles acaba prematuramente e é preciso definir
o comportamento dos outros.
A sincronização de baixo nível é frequentemente pouco relevante do ponto de
vista do autor de uma especificação multimédia, que o que pretende é, garantir uma
qualidade de serviço de apresentação. A sua falta pode ser superada, na maior parte dos
casos, com a existência de um conjunto de objectos componentes que suportem as
funcionalidades base. Assim, no modelo desta tese, este tipo de sincronização é
realizada externamente ao modelo de sincronização, recorrendo a objectos componentes
específicos. Um exemplo de um objecto componente que deve existir é um objecto
50
p q ç , p
utilizados dois tipos de mensagens de controlo: os eventos e as acções.
Os eventos são mensagens de controlo que são geradas pelos objectos
multimédia, para notificar alguma modificação no seu estado interno. Os eventos
podem classificar-se como: eventos determinísticos, que ocorrem sempre pela mesma
ordem durante o funcionamento de um objecto; e eventos não determinísticos, que
modelam situações que podem não ocorrer, tais como intervenções do utilizador. Dois
exemplos de eventos respectivamente determinístico e não determinístico, são o evento
tipo Ev_End, gerado quando um objecto termina a apresentação, e o evento tipo
Ev_Click, gerado quando se prime o botão do rato sobre um texto ou imagem.
Os eventos têm tipos associados, que definem qual a modificação que houve no
objecto, e quais os parâmetros do evento. O tráfego de eventos é baseado em interesse:
os controladores só recebem um evento se registarem previamente o interesse num tipo
de evento ao objecto emissor.
As acções são mensagens de controlo que são utilizadas pelos controladores para
invocar os métodos no interface dos objecto, e controlar o seu funcionamento. As
acções não retornam parâmetros, e quando é mesmo necessário retornar dados, são
usados os eventos. Existe assim uma interpenetração grande destes dois tipos de
mecanismos.
O modelo de sincronização obtido com este mecanismo de controlo é
extremamente poderoso, e permite atingir três dos objectivos que foram propostos: de
permitir qualquer tipo de interacção sobre os objectos; uniformidade no tratamento de
vários domínios; e possibilidade de interacção com utilizadores. A uniformidade deriva
de os eventos terem tipos associados, e assim, para diferentes domínios são utilizados
eventos de diferentes tipos. O suporte de interacção arbitrariamente complexa com o
51
p p ç p
modelo, é de todos os apresentados no segundo capítulo, o mais versátil, e que foi
também adoptado nos trabalhos da universidade de Genebra [Mey+ 92] e no MADE
[Arbab+ 93a]. A sua versatilidade permite suportar todos os outros métodos de
sincronização descritos na introdução (sincronização hierárquica e baseada num eixo de
tempo).
Por fim, importa ainda realçar que com este modelo de sincronização, o
tratamento de falhas é integrado no processo de autoria de uma forma natural. Como foi
adoptado o modelo de falhas fail-stop [Lamport+ 90], quando um objecto falha, os
outros objectos podem detectar a falha, podendo ser gerado um evento de detecção de
falha, que será processado como qualquer outro evento de sincronização.
4.3. ESTADOS, EVENTOS E ACÇÕES
A solução apresentada comumente para a definição de um interface para os
objectos multimédia, é a existência de um interface único. Os grupos de métodos,
quando existem, são definidos com base em relações de herança [Gibbs 91], ou então
apenas a nível da descrição textual do sistema [ISO 93b], seguindo-se geralmente a
abordagem das linguagens orientadas para objectos. Isto é, seguindo a semântica
particular das linguagens no que respeita ao modelo de tipos de dados. Esta abordagem
introduz problemas, nomeadamente em relação à possibilidade de utilizar
especificações desenvolvidas para versões mais antigas dos objectos, que entretanto
podem ter tido algumas modificações nos métodos do interface.
Neste trabalho seguiu-se uma orientação multifacetada, na linha do modelo de
referência de ODP [ISO 93]: Em vez da definição de apenas um interface, cada objecto
52
g p , q p j ,
estado como um conjunto de estado interno mais lógica associada, cuja visibilidade
externa é um conjunto de operações e um conjunto de tipos de eventos. Na arquitectura
proposta, os estados são entidades tipificadas, e a cada tipo de estado está associado um
conjunto de acções, que também são tipificadas e constituem um interface, mais um
conjunto de eventos.
Há estados para velocidade, geometria, volume, etc. Associado ao estado
velocidade, por exemplo, está o tipo de evento Ev_speed, que indica uma
modificação da velocidade de apresentação do stream de dados, e um conjunto de
acções que permite ler e modificar a velocidade de apresentação. Se um objecto não
suportar o estado para velocidade, ele não pode interactuar com o exterior para mudar a
velocidade de apresentação, nem a aplicação usar eventuais modificações da velocidade
no objecto durante a sincronização da aplicação.
A forma como os estados interagem entre eles internamente nos objectos é um
assunto interno do objecto, e o programador é livre de implementar qualquer influência
que deseje, desde que os mecanismos de comunicação necessários sejam suportados.
Um exemplo onde essa influência cruzada deve ser realizada, é com o estado
relacionado com a largura de banda disponível (qualidade de serviço). Quando se
detectar uma diminuição no valor disponível, então deverão ser tomadas medidas para
reduzir a largura de banda necessária para a transferência dos streams de dados, como
reduzir a geometria do objecto, ou reduzir a velocidade de apresentação, enviando os
eventos respectivos, para os objectos que os requereram. Comparando esta abordagem
com a utilizada no MADE verifica-se que é mais simples, pois a utilização da delegação
para resolver este problema vai implicar a existência (pelo menos virtual) de mais
objectos no sistema.
53
p j p
A interface completa de um objecto multimédia, ou componente, é o conjunto
de todos os interfaces dos estados que ele suporta.
Na figura 4.2 está representado um esquema com um objecto componente, com
três estados internos, cada um com um interface com acções associadas e podendo gerar
eventos para o exterior.
Interfac e
Evento
Figura 4.2 : Estrutura do interface de umobjecto componente
Em termos de modelo computacional, os estados não introduzem nenhum
conceito novo, mas apenas um meio para relacionar interfaces. O conceito de estado é
muito útil por quatro razões principais :
1. evita a necessidade de desenvolver um interface comum para todos os objectos.
Evita-se assim a existência de métodos vazios, ou a sobreposição (overloading) de
operações com significados não intuitivos.
2. evita a necessidade de se ter de desenvolver o interface completo de um tipo de
dados de maneira a suportar qualquer evolução futura na tecnologia do
componente. A evolução vai poder ser realizada através de adição de novos
estados ao tipo antigo, criando um novo tipo.
54
4.3.1. Estado Contexto
O estado mais importante é o Contexto, que fornece as funções básicas para os
objectos poderem interactuar com outras entidades no sistema, sendo obrigatório para
todos os objectos componentes e objectos multimédia. O interface deste estado funciona
como um identificador único para cada objecto no sistema, permitindo obter todos os
outros interfaces suportados pelo objecto.
Acções EventosPlay()Stop()Destroy()Inform()RegisterStatusInterest()UnregisterStatusInterest()ReceiveEvent()
Ev_ReadyEv_StartEv_StopEv_End
Tabela 4.1: Acções e Eventos associados ao estado Contexto.
A tabela 4.1 mostra as acções e eventos associados ao estado Contexto. As
acções Play e Stop são utilizadas para iniciar e parar a apresentação do objecto,
sendo equivalentes às acções de apresentação existentes na norma MHEG [ISO 93b]. A
acção Destroy é utilizada para destruir o objecto, libertando os recursos reservados. A
acção Inform devolve uma lista de referências para os interfaces correspondentes aos
estados fornecidos como parâmetros. A acção RegisterStatusInterest é
utilizada para registar o interesse em receber eventos, sendo passados como parâmetros,
os estados a que estão associados os eventos, e a referência para o interface onde se
pretende receber o evento. A acção UnregisterStatusInterest cancela o efeito
55
q p _ g q j
chega ao fim da apresentação, passando em seguida ao estado inactivo. O evento
Ev_Stop indica que foi invocada a operação Stop, e foi parada a apresentação. Pode
também ser gerada quando for detectada uma falha no funcionamento do objecto, antes
do objecto passar ao estado inactivo.
4.3.2. Estado Anotação
O estado Anotação suporta a definição de pontos de sincronização intermédios
durante o estado activo de um objecto. Quando um objecto suporta este estado, deixa de
ser visto como um bloco que é activado do princípio ao fim, mas passa a ter posições
intermédias, podendo-se activar o objecto apenas num excerto da apresentação total.
Quando um objecto está activo e chega à posição correspondente a uma anotação,
é enviado o evento Ev_Annotation correspondente a essa anotação para todos os
objectos que a registaram. O registo pode ser feito no interface do estado Contexto,
para todas as anotações, ou então, apenas para um subconjunto das anotações, utilizando
a acção registerEventAnnotation do estado Anotação. Neste último caso,
regista-se o interesse numa lista ordenada de anotações, e caso a ordenação fornecida na
lista não seja compatível com a evolução da apresentação do objecto, é gerado o evento
Ev_RegisterAnnotationError.
As anotações estão subdivididas em diferentes tipos, que são geridos no gestor de
tipos do sistema. O tipo de anotação define o domínio de valores dos parâmetros, e a sua
interpretação. Existe um tipo base de anotação, Locator, com um inteiro natural
como parâmetro, que representa a posição interna dos objectos na apresentação. Para
além deste, podem ser definidos outros tipos de anotação, com outros parâmetros, como
por exemplo, um tipo Label, com um nome como parâmetro. Caso não se utilize o tipo
56
4.3.3. Estado Remctrl
Quando é utilizada uma arquitectura de controlo distribuída (introduzida na secção
3.4), são utilizados vários interpretadores para controlar a sincronização das aplicações,
que correm um conjunto de máquinas de estados. Esses interpretadores precisam de
trocar referências entre si sobre os símbolos utilizados, e de gerir dados internos das
máquinas de estados que são partilhados pelas várias máquinas, como por exemplo,
variáveis distribuídas. O estado Remctrl suporta estas interacções entre
interpretadores.
Para gerir a troca de referências utiliza as acções Bind e UnBind, que permitem
respectivamente associar e desassociar uma referência para um interface a um símbolo
(nome) existente na máquina de estados.
A gestão de variáveis distribuídas utiliza as acções Set, Read, e TestAndSet,
que permitem respectivamente modificar incondicionalmente o valor da variável, pedir
uma leitura, e pedir uma leitura e modificação condicional atómica do valor da variável.
O evento Ev_var é utilizado para retornar os valores das variáveis lidas.
4.3.4. Outros Estados
Para além dos três estados apresentados anteriormente, existem outros estados
mais simples, que são usados para tratar aspectos específicos dos objectos. Tipicamente,
são estados simples, como por exemplo o estado Velocidade, com acções para
modificar o valor da variável controlada (setSpeed e changeSpeed), e acções para
ler o valor (getSpeed). Para cada estado, existem frequentemente eventos que indicam
a mudança do valor da variável (no exemplo é Ev_Speed).
57
Os objectos componentes modelam fontes, destinos e filtros, seguindo uma
abordagem já consensual na literatura, como por exemplo em [Gibbs 91]. Os filtros são
usados principalmente para ligar fontes e destinos incompatíveis, fornecendo um modo
para introduzir conversores de formatos de dados e/ou conversores de métodos de
controlo de transferência. Poderão também ser utilizados para modelar comutação
dinâmica de ligações entre portos, funcionando como nós de comutação de streams de
dados multimédia.
O interface dos objectos componentes é definido pelo conjunto de estados que
suportam, e pelos portos que têm. No mínimo, um objecto componente suporta o estado
Contexto, mas pode e deve ter outros estados, associados a características específicas
do objecto, incluindo possivelmente um estado por cada porto suportado.
Cada porto define um fluxo de dados multimédia independente, e é caracterizado
por um tipo, e pela direcção (entrada ou saída). Assim, um porto de um componente só
pode ser ligado a outro, ou outros, se tiver a direcção oposta deles, e tiver o mesmo
tipo, ou um tipo compatível. A compatibilidade de tipos significa neste domínio, a
capacidade de um porto para tratar a codificação dos dados e os mecanismos para os
transferir.
O controlo dos portos de um objecto é feito através de estados específicos para
cada tipo de porto. É definida uma relação de herança entre os interfaces desses estados,
e a classe Porto, que define os métodos connect e disconnect. Estes métodos
permitem respectivamente interligar e desligar portos. Nos estados dos portos, vão ser
acrescentados métodos que se destinam a gerir a transferência de dados entre portos de
entrada e de saída. Estes métodos específicos não são visíveis a nível dos objectos
58
disponíveis. Por exemplo, para apresentar um stream de vídeo terão de ser utilizados
pelos menos uma fonte e um destino, havendo um conjunto de opções em relação ao
protocolo utilizado na transferência, em relação à geração dos eventos (quem é
responsável por gerar o evento X), etc. A relação de compatibilidade neste espaço vai
definir se dois componentes podem ser ligados, sendo assim mais complexa do que a
mera compatibilidade entre o tipo de sinais multimédia, pois terá de ter em conta todos
estes factores.
4.4.1. Criação de Componentes
A função de criação de objectos componentes no sistema proposto é realizada por
servidores de componentes. Estes servidores só suportam o estado
VidaComponentes, que oferece funções para a criação e destruição de instâncias dos
objectos componentes. Estes servidores desempenham um papel semelhante às fábricas
(factories) no modelo ODP [ISO 93] e ANSA [Ansa 93]. Esta funcionalidade também
está implícita no MHEG [ISO 93b], onde é realizada na máquina MHEG, através das
acções de preparação.
A acção para criar novas instâncias, Prepare, recebe como parâmetros principais
a lista de portos que deve criar e um conjunto de valores de propriedades, com
significado local ao objecto. Estas propriedades são utilizadas para inicializar as variáveis
internas da instância a ser criada, correspondendo tipicamente a nomes de ficheiros,
geometria inicial de apresentação, etc. A acção devolve um conjunto de referências para
os portos criados, e para o interface do estado contexto, que permite depois aceder a
todos os outros interfaces. A instância criada só vai ser conhecida por quem invocou a
operação, que poderá então partilhar a sua utilização com outros objectos.
59
A construção de aplicações multimédia vai ser baseada em objectos multimédia
(MM_objects em [Pinto+ 94]), que definem uma vista simplificada sobre os objectos
componentes. Um objecto multimédia é uma entidade activa que começa, tem um
tempo de vida, e termina, manipulando ou não dados multimédia [Pinto+ 93b]. Tal como
os objectos componentes, a sua interface é definida pelo conjunto de estados que
suporta. No mínimo terá o estado Contexto, mas tipicamente terá mais estados.
Em termos de composição, um objecto que não suporta o estado Anotação é
extremamente simples, como está representado na figura 4.3, onde a menor unidade de
sincronização será todo o objecto multimédia. Senão, terá uma estrutura mais complexa,
podendo-se utilizar todos os intervalos possíveis entre os eventos de anotação e o
Ev_Start e Ev_End, como unidades de sincronização. Caso o objecto suporte o
estado Anotação e Click por exemplo, e o utilizador active duas zonas sensíveis do
objecto durante a apresentação, então poder-se-á ter o esquema representado na figura
4.4. Os eventos não determinísticos, da activação dos botões, estão representados com
setas pequenas.
Ev_Start Ev_End
Figura 4.3 : Objecto multimédia mais simplesem termos de composição
Ev_Start Ev_EndCapitulo1 Capitulo2Botão A Botão B
Figura 4.4 : Objecto multimédia com várioseventos
Na primeira secção deste capítulo foi apresentada uma primeira abordagem da
constituição interna dos objectos multimédia. Definiu-se os objectos multimédia como
sendo constituídos por um conjunto (eventualmente vazio) de objectos componentes
interligados mais um gestor.
60
g p , q p g
4.5.
fonte destino
c ontrolador
d ispa tcher
Figura 4.5 : Composição de um objectomultimédia.
O dispatcher (despachante) é responsável por gerir estados que se encontram
distribuídos pelos vários componentes, criando um interface comum para esses estados.
No mínimo, gerirá o estado Contexto, desde que o objecto tenha mais do que um
componente. Quando um estado é gerido unicamente por um dos componentes, então o
dispatcher vai delegar o tratamento do estado no objecto componente. Um exemplo
típico, considerando o estado velocidade, seria o componente que controla a
transferência de informação gerir o estado pelo objecto. A delegação é totalmente
transparente para o utilizador do objecto, pois ele pede a referência para o interface do
estado, sendo então retornado o interface do objecto componente. O dispatcher tem
ainda a função de gerir as ligações de streams de dados entre os portos dos vários
componentes que coordena.
O controlador utiliza os serviços do dispatcher, e monta em cima destes um
sistema reactivo de controlo de sincronização, que recebe eventos (através da função
ReceiveEvent) e activa acções em objectos multimédia. O controlador pode não
existir necessariamente, ou então não ser utilizado, dependendo do tipo de controlo
utilizado. Quando é utilizado, processa as acções dos interfaces dos estados suportados
61
, p p ,
Eventos
Interfac e
dispatcher
C 1
C 2 C 3 C 4
Figura 4.6 : Estrutura interna de um objectomultimédia
MM_ObjectMM_ObjectObjecto MMMM_ObjectMM_ObjectObjecto MM
Controlador
Eventos Acções
Objecto multimédia composto
EventosAcções
Figura 4.7 : Estrutura de um objectomultimédia composto
Nas figuras 4.6 e 4.7 são apresentados dois exemplos de objectos multimédia, que
correspondem aos dois casos limites descritos anteriormente, em relação à utilização do
controlador.
No exemplo da figura 4.6 encontra-se representado um objecto multimédia
constituído por quatro objectos componentes C1 a C4, onde não é utilizado o
controlador. Os componentes foram representados utilizando a notação definida
anteriormente nesta dissertação. Existem dois estados que foram delegados para o
componente fonte C1 e para o componente destino C4. O gestor (que neste caso só usa
o dispatcher) vai gerir o estado Contexto interactuando com os vários componentes.
No exemplo da figura 4.7 é representado o outro caso limite, o de um objecto
multimédia composto, que não tem nenhum componente. Neste caso, o objecto
multimédia é o controlador, que gere internamente um conjunto de objectos
multimédia. Observe-se que modelo apresentado de objecto multimédia é perfeitamente
62
representa o conjunto de estados suportados pelo objecto, e a lista de componentes que
podem ser utilizados para o montar. Por exemplo, um vídeo de um certo tipo pode ter
como fonte um disco, e como destino um écran numa estação de trabalho. O destino
pode ser mudado para um televisor, desde que este suporte os mesmos estados que o
objecto associado à janela do écran da estação de trabalho e utilize o mesmo protocolo
de geração de sinais de controlo, ou seja, desde que sejam de tipos de componente
compatíveis. Se se tentar trocar a fonte por uma câmara de vídeo e se o estado
velocidade fosse implementado, então a troca não poderia ser feita, pois a câmara
não vai poder realizar esta funcionalidade. Tinha-se, deste modo, construído outro tipo
de objecto multimédia.
4.5.1. Criação de objectos multimédia
A criação de objectos multimédia é feita de uma maneira similar aos objectos
componentes. Existem no sistema servidores de objectos multimédia que suportam a
criação e destruição de qualquer tipo de objecto multimédia, e que são responsáveis pela
criação de instâncias dos gestores dos objectos multimédia. Estes servidores só suportam
o estado Vida, que tem operações semelhantes ao estado VidaComponente.
O Prepare passou a ter mais parâmetros, como a identificação dos objectos
componentes a serem criados e a configuração inicial das ligações entre os portos desses
componentes. O campo com os valores de propriedades, para além de transportar dados
para os componentes, também é utilizado para passar configurações iniciais para o
gestor, como por exemplo, se deve ser activado o controlador, ou se deve utilizar
unicamente o dispatcher. Tal como nos objectos componentes, é devolvida uma
referência para o interface do estado Contexto. Se a criação do novo objecto não
puder ser executada imediatamente, e o utilizador permitir, pode-se criar o objecto
63
Na primeira parte deste capítulo, foi descrito o modelo de objectos multimédia
adoptado. Nesta secção é apresentada a arquitectura global onde os objectos se inserem,
que está representada na figura 4.8.
Máquinade estados
UtilizadoresFontes,
Destinos,etc
Sc rip t
Specification
Ed itorGrá fic o
Autor Figura 4.8 : Arquitectura do sistema dedesenvolvimento de aplicaçõesmultimédia interactivasdistribuídas.
As aplicações multimédia são constituídas por um conjunto de objectos
componentes e gestores associados, que interagem através da troca de fluxos de dados
multimédia entre portos, e da troca de eventos e acções. O controlo é feito em
controladores, que correm máquinas de estados, especificadas num formato interno ao
sistema. Os utilizadores das aplicações multimédia interagem com as aplicações através
dos objectos.
Para além dos objectos multimédia associados a elementos de apresentação, como
objectos de vídeo e objectos de som, existem um conjunto de utilitários destinados a
fornecer aos utilizadores outros níveis de interacção com os objectos multimédia.
Assim, para correr aplicações, existem objectos interpretadores de máquinas de
64
p
As aplicações são especificadas utilizando descrições em linguagem textual,
chamadas scripts. Estas especificações são processadas por compiladores, que geram as
máquinas de estado utilizadas nos controladores.
Embora o modelo seja conceptualmente simples, para aplicações razoavelmente
complexas, torna-se difícil a um autor criar directamente o script, pois tal obriga-o a ter
conhecimentos sobre os objectos que existem, e sobre os interfaces que suportam.
Assim, para simplificar essa tarefa é definido um interface de desenvolvimento de
aplicações multimédia baseado na utilização de editores gráficos, que geram os scripts
a partir de especificações gráficas. Nesta dissertação não foi desenvolvido nenhum
editor gráfico. No entanto, pode-se utilizar um editor gráfico desenvolvido noutro
trabalho [Pereira 94], que utiliza uma linguagem de script compatível com a definida
nesta dissertação.
Durante as fases de especificação e a execução das aplicações é utilizado um
gestor de tipos a nível do sistema, que reúne informações sobre todos os tipos. O
sistema de run-time, as ferramentas de especificação e os compiladores utilizam essa
informação para fazer verificações.
Durante a execução das aplicações é utilizado um gestor de nomes para obter as
referências dos interfaces do objectos a partir dos nomes.
4.6.1. Processo de Autoria
O modelo de objectos e sincronização especificados são suficientemente genéricos
para permitir uma grande variedade de usos possíveis. No entanto, o autor típico não
pretende utilizar a totalidade das possibilidades do sistema, mas apenas algumas
características, que se adaptam ao problema que quer resolver. Assim, em vez de definir
65
g , p j g g ,
seguida no MADE [Herman+ 93], e é suportada em normas como o MHEG [ISO 93b].
4.6.2. Gestor de Tipos
Em todos os sistema multimédia é necessário garantir que o utilizador que vai criar
uma aplicação tenha conhecimento dos interfaces de acesso dos componentes do
sistema. Nos sistemas analisados no segundo capítulo, esta componente foi praticamente
ignorada, sendo a abordagem dominante, a de obrigar cada utilizador a conhecer os
interfaces dos componentes (eventualmente por documentação), ou incluir essa
informação nas ferramentas utilizadas para criar as aplicações. Nas normas HyTime e
MHEG, definidas para transferir objectos entre aplicações, houve a necessidade de
incluir meios para veicular informação adicional de natureza semântica associada aos
objectos [Newcomb 93], de modo a possibilitar a passagem dessa informação entre
aplicações diferentes, e logo com sistemas de tipos distintos. Nesta dissertação, é
defendido o modelo de gestão de toda a informação referente a tipos a nível global, num
gestor de tipos, em vez de criar 'ilhas' com tipos definidos localmente.
No modelo defendido nesta dissertação, não foi utilizada a relação de herança de
linguagens orientadas a objectos para definir as relações entre tipos. Em sua substituição
são utilizadas relações genéricas de subtipo entre tipos. Permite-se assim a definição de
relações de herança de interfaces que excluem a herança de código (geralmente
associada às linguagens orientadas a objectos), e sem estarem associadas a nenhuma
linguagem de programação em particular, assim como relações entre entradas da base de
dados do gestor de tipos que reflictam particularidades específicas (por exemplo,
componentes que podem ser agrupadas para gerar um objecto multimédia).
66
p
O gestor de tipos é utilizado por todos os utilitários do sistema. O editor gráfico
utiliza a informação guardada no gestor de tipos para saber acerca dos tipos de objectos
multimédia disponíveis para o autor. O compilador usa o gestor de tipos para realizar
verificações de consistência durante a compilação, ou mesmo para controlar a máquina
de estados gerada, como por exemplo, utilizando a informação sobre a natureza dos
eventos no que diz respeito ao determinismo. Os interpretadores das máquinas de
estados e os dispatchers usam a informação do gestor de tipos para fazer verificações
em run-time e para obter os códigos de alguns tipos a partir do nome e vice-versa. Para
optimizar a eficiência do sistema, deve-se minimizar as verificações durante a
execução, aumentando-se necessariamente a quantidade de informação contida no
gestor de tipos.
Todos os tipos são identificados univocamente por um nome e por um número,
tendo um conjunto de atributos. Os atributos são constituídos por dados relacionados
com os tipos, como uma configuração por defeito para os objectos multimédia, e os
tipos de relações entre tipos, para suportar regras de compatibilidade. O gestor de tipos
guarda informação sobre os seguintes tipos:
�• Tipos de objectos multimédia. É guardada a lista dos tipos de estados que o
objecto multimédia suporta.
�• Tipos de objectos componentes. São guardados o tipo de componente (fonte,
destino, ou filtro), quais os objectos multimédia a que pode pertencer, quais os
estados que suporta e quais os nomes dos portos de entrada e saída com os tipos
de sinais associados.
67
p g p
do evento (determinístico ou não-determinístico).
�• Tipos de anotações. É guardada a assinatura dos parâmetros da anotação, que
pode ser qualquer combinação possível entre um inteiro e uma cadeia de
caracteres, pois são esses os campos disponíveis no evento Ev_Annotation,
usado para transferir anotações.
�• Tipos de acções. É guardada a assinatura dos parâmetros da acção.
4.6.3. Gestor de Nomes
O gestor de nomes gere uma base de dados de referências de objectos associadas a
nomes, e é utilizado para localizar objectos no sistema. Todos os objectos activos têm
um nome, que identifica o objecto univocamente, e têm um interface associado ao
estado Contexto.
Se um objecto quiser ser conhecido no sistema, então terá de registar o seu nome
e interface no gestor de nomes. Quando um objecto quiser interagir com outros, pede as
referências dos objectos a partir dos nomes, podendo depois interagir através do seus
interfaces.
O serviço pode ser utilizado por qualquer objecto multimédia, ou utilitário que
suporte um interface de estados, servidor de componentes, servidor de objectos, ou
ainda, pelo gestor de tipos.
Durante a criação dos objectos multimédia ou objectos componentes é necessário
localizar os servidores respectivos. Assim, os servidores activos registam referências
para os interfaces vida ou vidacomponente, no gestor de nomes. Caso a
arquitectura do servidor de nomes o permita, esta pesquisa pode ser mais complexa,
68
g
O gestor de nomes poderá ser realizado com o trader definido no modelo de
referência do ODP ou ANSA, mas nesse caso, as pesquisas terão de ser razoavelmente
simples porque o trader do ANSA foi apenas concebido para a identificação de
servidores activos no sistema. Para permitir pesquisas mais complexas, como por
exemplo localizar um servidor de componentes por nome de imagem ou vídeo, seria
necessária uma arquitectura mais poderosa, como a utilizada no serviço de directórios
X.500 [CCITT 88].
69
definir aplicações multimédia.
5.1. INTRODUÇÃO
A infra-estrutura proposta neste trabalho prevê a eventual utilização de várias
linguagens de especificação de aplicações multimédia diferentes. Essas linguagens de
especificação deverão ter um conjunto de características de maneira a simplificar a
interacção do autor com o sistema.
A linguagem deve ser expressiva de maneira a permitir descrever o máximo
número de aspectos do sistema, relevantes para o tipo de programador a que é
destinada. Deve ser simples, permitindo uma fácil aprendizagem, compreensão e
utilização, especialmente nas situações mais comuns. Deve ser eficiente, permitindo a
realização de ferramentas que gerem código eficientemente, a partir de uma
especificação nessa linguagem (script). Por fim, a linguagem deve ser abstracta e
formal. Deve ser independente da implementação, e permitir a definição precisa e sem
ambiguidades de aplicações.
No capítulo 2 desta dissertação foram introduzidas algumas linguagens de
especificação, como a OCPN, Extensões ao ODA e HyTime. Nesse capítulo foram
referidos algumas limitações, verificando-se que nenhuma das linguagens referidas
obedece completamente a todos os quatro princípios referidos. Para além dessas, pode-
se ainda referir outras linguagens de especificação relevantes como o RAVI [Kretz 90],
SMSL [ISO 93c] ou Esterel [Stefani+ 92]. O RAVI (Representation for Audio Visual
Interactive applications), é uma norma francesa para especificação de aplicações
interactivas audiovisuais, que influenciou a definição do standard MHEG, e que serve
70
p q p
composição. Por exemplo, no caso da composição de ciclos causais, não está definido
qual é o ciclo que deve ser incrementado, se o mais externo ou se o mais interno, sendo
somente definido quando se realiza um compilador ou um interpretador. O SMSL
(Standard Multimedia/Hypermedia Scripting Language) é baseado nas linguagens
SGML, e está em vias de ser proposto como uma linguagem de especificação na ISO,
mas ainda está numa fase muito primitiva de desenvolvimento. O Esterel tem uma
semântica bem definida, no entanto, foi desenvolvido para uma sincronização de baixo
nível, apresentando limitações relativamente a interacções de nível mais elevado, como:
a especificação de comunicação entre objectos; a definição de relações entre objectos
mais complexas do que causalidade entre eventos de tempo; e a especificação de
interacção com o utilizador.
Para representar aplicações multimédia de maneira a respeitar as quatro
características enunciadas, é necessário uma linguagem de programação que permita
representar facilmente a concorrência, e tenha uma definição formal. A utilização de
uma definição formal elimina as ambiguidades na interpretação da linguagem,
contribuindo para simplificar o desenvolvimento de compiladores. As álgebras de
processos obedecem às especificações requeridas, podendo-se utilizar o CCS (Calculus
of Communicating Systems) [Milner 89], o CSP (Communication Sequential Processes)
[Hoare 85], ou então variações destas, como o LOTOS (Language Of Temporal
Ordering Specification) [ISO 87] e o Occam [Gallety 90] respectivamente. Esta
abordagem não é original, tendo já sido desenvolvidas linguagens de especificação
baseadas no CCS [Eun 93], e baseadas no LOTOS [Pinto 93].
Nesta dissertação definiu-se uma linguagem baseada na álgebra de processos CSP,
com uma sintaxe semelhante à da linguagem Occam, para a definição do
71
p p ç g ,
complexidade da sintaxe e dos compiladores, à custa de algum aumento de
complexidade das especificações.
Na definição da linguagem evitou-se a utilização de operadores fortemente
assimétricos, como a interrupção, exceptuando os que são estritamente necessários,
como a execução alternativa de operações. Este facto possibilita com muitos menos
problemas a definição da inversão de apresentação de uma aplicação.
5.2. ESTRUTURA GERAL
As duas noções básicas numa álgebra de processos são a noção de processo e de
evento. Um processo é uma entidade que tem informação interna, e que pode
interactuar com outros processos. O evento é a unidade de sincronização entre dois ou
mais processos, que pode transportar dados.
Na linguagem que está a ser definida, a álgebra de processos é utilizada para
modelar o comportamento dinâmico de aplicações. Os processos são utilizados para
representar objectos multimédia (ou parte deles), que são as unidades de composição a
nível da autoria. Os eventos da álgebra de processos são utilizados para suportar os
métodos de sincronização definidos no modelo de interacções entre objectos
multimédia, que são a recepção de eventos multimédia, e a invocação de acções.
No CSP a comunicação entre processos faz-se através de canais, que têm um
identificador único. No caso da nova linguagem, eles não são considerados como
abstracções para a troca de mensagens. O receptor 'recebe' os eventos e gera as acções
referenciando o objecto multimédia emissor ou destino, conforme o caso. Este facto é
útil, pois a configuração de canais CSP depende da arquitectura de controlo que é
72
ç , p g g , p
estruturados suportam a definição de objectos multimédia compostos. Neste caso, a
utilização principal dos parâmetros é definir o conjunto de estados suportados pelo
objecto composto, e a forma como se relacionam com os estados dos objectos internos.
5.3. ESTRUTURA SINTÁCTICA
A descrição de uma aplicação multimédia é chamada de especificação. A
especificação suporta a definição de unidades de código compilável, que também
podem ser incluídas noutras especificações.
A declaração de uma especificação, é feita utilizando a estrutura representada na
figura 5.1. A declaração tem duas componentes distintas: a primeira parte contém um
conjunto de declarações; a segunda parte usa uma álgebra de processos para descrever o
funcionamento da aplicação.
SPECIFICATION NomeEspecificação [listaEventos] (listaParâmetros);
DefiniçãoAlias DefiniçãoObjectosMM DeclaraçãoVariáveis DefiniçãoProcessos
BEHAVIOUR ExpressõesComportamentoENDSPEC;
Figura 5.1: Estrutura da declaração de uma especificação
73
p ç q
especificação. A secção listaParâmetros suporta a utilização de objectos
multimédia externos à especificação, que são declarados como parâmetros.
A secção DefiniçãoAlias suporta um mecanismo puramente sintáctico de
substituição de uma cadeia de caracteres por um nome equivalente, que é interpretado e
substituído durante a compilação.
A secção DeclaraçãoVariáveis define uma variável para posterior
utilização, associando um tipo e eventualmente um valor inicial. Ao contrário do CSP
ou LOTOS, na linguagem que está a ser definida, as variáveis têm de ser declaradas
antes de serem usadas, e têm um tipo associado, que é usado para fazer verificações
semânticas durante a compilação.
A secção DefiniçãoProcessos permite atribuir nomes a processos,
permitindo a estruturação da programação e a reutilização de código. A sua estrutura é
apresentada na figura 5.2. Como se pode ver, é semelhante à estrutura das
especificações, sendo a diferença fundamental entre as duas, o facto de um processo não
ser compilável, mas apenas existir durante a fase de compilação.
PROCESS NomeProcesso [listaEventos] (listaParâmetros); DefiniçãoObjectosMM DefiniçãoAlias DeclaraçãoVariáveis DefiniçãoProcessosBEHAVIOUR ExpressõesComportamentoENDSPEC;
Figura 5.2: Estrutura da declaração de um processo.
74
Nas estruturas da definição de especificações e processos está sempre presente a
secção DefiniçãoObjectosMM, que contém a declaração dos objectos multimédia
que são utilizados. A figura 5.3 apresenta a estrutura da definição de um objecto
multimédia.
MMOBJECT NomeObjecto NomeTipo subEstrutura
listaDefiniçãoDados
listaComponentes expressõesLigaçãoENDOBJECT;
Figura 5.3: Estrutura da declaração de um objecto multimédia.
Um objecto multimédia é identificado univocamente por um nome, que é função
de NomeObjecto. O campo NomeTipo contém o nome do tipo de objecto
multimédia.
As secções listaComponentes e expressõesLigação contêm
respectivamente a lista com os componentes do objecto multimédia, e a configuração
inicial das ligações entre os portos dos vários componentes.
A secção listaDefiniçãoDados é utilizada para definir os valores iniciais
para o conjunto de variáveis de estados utilizadas no objecto, e que se encontram
distribuídas pelos componentes e pelo gestor do objecto multimédia.
Os objectos multimédia podem ter uma estrutura interna, definida por um
conjunto de eventos de anotação, que delimitam intervalos de apresentação dos
objectos. A secção subEstrutura suporta a definição de intervalos de apresentação,
75
p ç , ç p g
5.4.
MMOBJECT INLIBRARY NomeObjecto subEstrutura
listaDefiniçãoDados
identificadorBibliotecaENDOBJECT;
MMOBJECT EXTERNAL NomeObjecto NomeTipo subEstrutura
listaDefiniçãoDados
identificadorObjectoExternoENDOBJECT;
Figura 5.4: Estruturas de declaração de objectos multimédia externosà especificação.
Relativamente aos objectos externos, existem duas variantes, com duas sintaxes
ligeiramente diferentes. A primeira, identificada pela palavra chave INLIBRARY,
suporta a reutilização de especificações que foram definidas e agrupadas numa
biblioteca de especificações, identificada na secção identificadorBiblioteca.
A associação do objecto externo à aplicação é feito durante a compilação da
especificação.
Os objectos declarados com a palavra chave EXTERNAL são criados
externamente à especificação onde aparece a declaração, sendo os seus interfaces
obtidos através da consulta ao gestor de nomes do sistema. Este tipo de objectos foi
76
j
MMOBJECT viagem mpegType WITH SUB$STRUCTURE (
Primeira_parte Ev_Start <Label, ChegadaLondres> Segunda_parte <Label, AeroportoLondres> Ev_End
) FILENAME "viagem.mpg" WINDOW$X 100 WINDOW$Y 50 FRAME$RATE 25;
SOURCES mpegsrc; SINKS mpegsnk; LINK mpegsrc mpegsnk;ENDOBJECT;
Figura 5.5: Exemplo de declaração de um objecto multimédia.
A figura 5.5 apresenta um exemplo de uma declaração de um objecto multimédia
(interno) de vídeo. O objecto é composto por dois componentes, uma fonte do tipo
mpegsrc e um destino do tipo mpegsnk, que têm os portos correspondentes ligados
um ao outro. Estão definidos dois intervalos para este objecto, o intervalo
Primeira_parte, desde o início do vídeo até ao evento de anotação do tipo Label
e como o valor ChegadaLondres, e o intervalo Segunda_parte, desde o evento
de anotação com o valor AeroportoLondres até ao fim do vídeo. Em relação à
secção listaDefiniçãoDados, ela inclui o nome do ficheiro com o vídeo, a
posição inicial da janela, e o ritmo de apresentação das tramas.
77
básicas, consistindo nas operação de entrada, saída, atribuição e de abortar, onde é
seguida uma sintaxe semelhante ao CSP. O segundo grupo compreende um conjunto de
operadores que permite definir uma estrutura hierárquica de composição de operações,
onde é seguida uma sintaxe semelhante ao Occam.
Noutros trabalhos foi proposto que se separasse a declaração do comportamento
em duas secções independentes [Pinto 93], uma onde se especifica o comportamento na
ausência de intervenção do utilizador, apenas dependente de eventos determinísticos, e
outra onde são processados os eventos não determinísticos. Neste trabalho não foi
seguida essa orientação, havendo uma única declaração do comportamento. Desta
maneira, complicou-se a construção do compilador, que tem de fazer uma verificação
semântica muito mais complexa, nomeadamente para testar se existe a possibilidade de
bloqueio (deadlock); mas em contrapartida, a especificação de aplicações com muita
interacção com o utilizador torna-se mais simples.
5.5.1. Semântica
Para definir a linguagem de uma forma não ambígua, é necessário definir
formalmente a semântica dos operadores da linguagem. As semânticas operacionais
podem tomar várias formas, dependendo do aspecto a ser definido. Assim, para
representar expressões e variáveis poder-se-á utilizar uma semântica de avaliação
(evaluation Semantics) [Hennessy 90], que se limita a definir qual é o valor final
correcto para uma expressão. Mas para representar operadores complexos, é necessário
uma semântica mais completa.
Na comunidade das álgebras de processos é comum a utilização das semânticas
transicionais (transitional semantics) [Milner 89] para atribuir significado às
78
, p ), , p ç
de transição t é necessário definir um sistema de derivação transicional. Um
sistema de derivação transicional é definido por um conjunto de axiomas, regras de
inferência, e pelo menor conjunto de relações de transição que obedece a esses axiomas
e regras de inferência. A definição formal das operações da linguagem é feita através
desses axiomas e regras de inferência.
Nesta dissertação, a definição da semântica dos operadores é feita recorrendo a
uma semântica transicional. O conjunto T é definido pelos identificadores dos eventos e
acções, concatenados com os valores dos dados, sempre que esses eventos ou acções
tenham dados associados. Para além desses, inclui ainda a transição , que corresponde
à terminação com sucesso de uma operação (processo na linguagem da álgebra de
processos). A sintaxe utilizada para representar a transição do exemplo do parágrafo
anterior é :corrente próximo
5.5.2. Operadores
Para a especificação do comportamento das aplicações são utilizados um conjunto
de operadores. Em seguida apresentam-se os operadores definidos nesta dissertação, e
uma descrição não exaustiva da sua semântica. Os parêntesis rectos são utilizados na
definição das operações para declarar as partes opcionais da declaração.
5.5.2.1. Operação de Entrada
A ? µ [(var1 [... , varn])]
As operações de entrada são semelhantes aos processos primitivos de entrada do
CSP. A expressão apresentada define a recepção do evento µ enviado pelo objecto
79
5.5.2.2. Operação de Saída
! µ ! µ [(exp1 [... , expn])]
As operações de saída são semelhantes aos processos primitivos de saída do CSP.
A expressão apresentada define a invocação da acção µ do objecto multimédia A, tendo
como parâmetros opcionais de entrada as expressões exp1 a expn, que devem ter um
tipo compatível com o tipo dos parâmetros respectivos do evento. O eventual retorno de
parâmetros é feito utilizando o envio de eventos para quem invoca a acção. Caso seja
necessário utilizar esses parâmetros, então deve ser executada uma operação de entrada
logo após a operação de saída.
5.5.2.3. Operação Atribuição
variável := expressãoA operação de atribuição define a atribuição do valor da expressão à
variável.
5.5.2.4. Operação Abort
ABORT
A operação ABORT aborta toda a especificação, e destrói todos os objectos
multimédia criados por ela.
5.5.2.5. Composição Sequencial
SEQB1 ; B2 [; B3 ; ... Bn] [;]
END
Esta operação define a composição sequencial dos operadores B1 até Bn, de
maneira semelhante à composição sequencial de processos em CSP. A semântica da
operação é definida por :
80
1 ; 2 [; 3 ; n ] [;]END
Este operador define a composição paralela entre operações. Nesta operação não
se seguiu o conjunto de processos que definem paralelismo em CSP, ou mesmo CCS,
pois o tipo de parametrização utilizado não é o mais adequado para definir o
comportamento de aplicações multimédia. Um exemplo de um processo que não tem
grande significado numa aplicação multimédia é o processo P ou Q não determinístico
(P Q em CSP). No caso presente o operador paralelo deve ser parametrizável em
termos de:
�• Semântica de terminação. A operação paralelo pode terminar quando todos os
operadores que o compõem terminarem, quando o primeiro terminar, ou quando a
disjunção ou conjunção de um subconjunto dos operadores terminar.
�• Influência entre os objectos. Os objectos enquanto activos podem trocar
informação sobre um certo estado, por exemplo velocidade ou geometria, de
forma a manter uma certa relação entre eles, por exemplo a mesma velocidade ou
geometria.
�• Vida dos objectos. Quando o operador paralelo termina, os objectos que
participaram nele podem ser todos mortos, ou podem continuar activos.
�• Duração dos objectos. Os objectos que participam num operador paralelo podem
manter a sua duração original, ficar todos com a duração do maior, do mais
pequeno, ou com uma duração dada.
�• Informação espacial. O operador pode definir uma relação hierárquica, nenhuma
relação, ou pode incluir informação de composição espacial, entre os objectos que
participam no operador paralelo e têm uma representação espacial.
81
j ; q ç q ( p )
entre o primeiro objecto que aparece na especificação do paralelo, e os restantes.
Relativamente à semântica de terminação foram definidas duas variantes: o
paralelo AND, que define o comportamento por defeito, em que o processo só termina
quando todos os operandos terminarem; e o paralelo OR, onde o processo termina
quando pelo menos um dos operandos terminar. Quando a operação tem dois
operandos, a semântica da condição de terminação é definida por :
�• PAR AND :B B e B B implica
PAR B B PAR B B1 1 2 2
1 2 1 2
' '; ' ; '
�• PAR OR :B B implica
PAR B B PAR B B1 1
1 2 1 2
'; ' ;
B B implicaPAR B B PAR B B
2 2
1 2 1 2
'; ; '
Os operadores PAR OR e PAR AND gozam da propriedade distributiva um em
relação ao outro, permitindo representar conjunções e disjunções de condições de
terminação arbitrariamente complexas.Relativamente à influência entre objectos foi definido o operador SYNC, que
define a gestão de um conjunto de estados a nível do paralelo, de modo a manter o
mesmo valor para as variáveis de estado. Por defeito, não é feita a sincronização de
nenhum estado a nível do paralelo.
Este parâmetro define a semântica da recepção de eventos dos objectos que
constituem o paralelo. Seja µ qualquer evento associado a um estado não sincronizado
ao nível do paralelo, e qualquer evento associado a um estado sincronizado. Se Pi
82
A composição paralela goza da propriedade associativa e comutativa (caso se
ignore a informação espacial). Observe-se que o conjunto de operadores SEQ, PAR OR
e PAR AND pode ser adaptado para descrever a sincronização de aplicações
multimédia de uma forma hierárquica, permitindo definir qualquer relação entre dois
intervalos [Hoepner 91].
5.5.2.7. Composição Alternativa
ALTB1 ; B2 [; B3; ... Bn ] [;]
END
A composição alternativa suporta a definição de um conjunto de apresentações
alternativas, controladas pela recepção de eventos.
A semântica da operação com dois operandos B1 e B2, duas expressões com
guardas (ou seja, onde a primeira instrução executada é uma entrada), é:B B implica ALT B B B1 1 1 2 1µ µ' ; 'B B implica ALT B B B2 2 1 2 2µ µ' ; '
Esta operação goza da propriedade associativa.
5.5.2.8. Execução Condicional
IF condição THEN A [;] ELSE B
IF condição THEN A
A execução condicional de expressões faz depender a activação de uma
expressão, do valor de condição, uma expressão booleana. A condição alternativa
ELSE é opcional.
A semântica associada ao operador é :
83
5.5.2.9. Execução Repetitiva
WHILE condição DOB
A execução repetitiva de operações é suportada pela operação WHILE, que
executa a operação B enquanto a expressão booleana condição tiver o valor
verdadeiro. A expressão anterior é equivalente à expressão recursiva:B := IF boolean_expression THEN B
A semântica deste operador é idêntica à semântica do operador equivalente em
CSP : condição * p1.
5.5.2.10. Activação de Objectos Multimédia
A declaração da activação de objectos multimédia pode ser feita directamente
através da activação de acções. No entanto, para facilitar a programação foram
definidas algumas simplificações sintácticas. Um objecto, ou um intervalo de um
objecto, pode ser activado indicando apenas o seu nome, que deve ser declarado
previamente. O processo mantém-se activo até a apresentação do objecto terminar. Por
exemplo, a activação do objecto viagem e do intervalo Primeira_parte
declarados na figura 5.5, seriam convertidos em:
�• viagem :SEQ viagem ! Play(Ev_Start, Ev_End); viagem ? Ev_End;END
�• Primeira_parte :SEQ viagem ! Play(Ev_Start, <Label,ChegadaLondres>); viagem ? <Label, ChegadaLondres>;END
84
ç j p p g ç
da especificação ou processo. A recepção de eventos dos objectos compostos é
substituída pela recepção dos eventos correspondentes definida na secção
listaEventos da declaração das especificações ou processos.
5.5.3. Exemplo
A figura 5.6 apresenta um exemplo de uma especificação do comportamento de
uma especificação. Na secção de declarações, não apresentada, estava a declaração do
objecto multimédia Video, com dois intervalos Video1 e Video2, e a declaração
dos objectos multimédia Audio1, Audio2 e Audio3.
PAR SYNC (speed) // Gestão do estado velocidade no paralelo SEQ
PAR OR Video1; Audio1; SEQ /* Composição baseada em eventos */
Video?Ev_ClickAudio3;
END;END;PAR /* Composição hierarquica */ Video2; Audio2;END;
END;END
Figura 5.6: Exemplo de uma especificação de comportamento.
No exemplo são ilustrados dois tipos de composição: Sincronização baseada em
eventos não determinísticos, em que se usa uma composição baseada na recepção
explícita de eventos, no caso do exemplo, para activar a apresentação do objecto
85
,
O exemplo anterior permite ainda observar a importância das verificações
semânticas no compilador. Caso se substituísse o operador PAR OR por PAR AND
teríamos uma especificação que poderia ficar bloqueada se o intervalo Video1
terminasse, sem o utilizador ter premido o botão do rato sobre o vídeo. A solução
referida no início da secção 5.5, de ter a declaração separada em parte determinística e
não determinística, impedia a existência desse problema, mas também complicava
significativamente a definição de uma apresentação com a funcionalidade especificada
no exemplo.
CAPÍTULO 6.IMPLEMENTAÇÃO
Neste capítulo começa-se por descrever o ambiente de desenvolvimento sobre o
qual o sistema foi implementado. Depois, descreve-se sucessivamente a forma como os
objectos multimédia, o interpretador e o compilador foram realizados, descrevendo-se
sucintamente as estruturas de dados e os algoritmos utilizados. No fim, comenta-se a
compatibilidade do sistema desenvolvido em relação às normas apresentadas no
capítulo dois, e comenta-se algumas das limitações do sistema.
86
6.1.1. ANSAware
O ANSAware é uma implementação da arquitectura ANSA (Advanced Networked
Systems Architecture), que segue muito perto o trabalho de normalização em sistemas
de processamento distribuído abertos (ODP). Tal como o modelo de referência para
processamento em sistemas distribuídos abertos (RM-ODP) [ISO 93], o ANSA é
constituído pela conjunção de diferentes pontos de vista (viewpoints) sobre um sistema.
Os mais relevantes para esta dissertação são o ponto de vista computacional, que
especifica a funcionalidade da aplicação a partir da interacção entre objectos, o ponto de
vista de engenharia, que especifica os algoritmos para se conseguir essa interacção, e o
ponto de vista tecnológico, que especifica como os algoritmos anteriores são de facto
implementados sobre o hardware e o software existente.
Modelo computacional
O modelo computacional define uma interacção tipo cliente-servidor entre
objectos. Os objectos encapsulam dados e processamento, e oferecem interfaces para a
interacção com outros objectos, podendo oferecer vários interfaces. Cada interface é
composto por zero ou mais operações.
O ANSA define um conjunto de transparências destinadas a mascarar aspectos
particulares da complexidade da programação distribuída. O ANSAware implementa
quatro dessas transparências: a transparência de acesso, que permite um acesso
uniforme independentemente do objecto ser local ou remoto, e é garantida através da
definição de referências genéricas para interfaces; a transparência de localização, que
permite o acesso aos objectos sem conhecimento da sua localização, e é realizada
utilizando o Trader, um servidor de nomes; a transparência de replicação, que
permite que múltiplas instâncias de um interface sejam vistas como um único, e é
87
, g g ,
transmitTimeout, que resulta de situações de sobrecarga ou terminação de um
servidor.
Na figura 6.1 é apresentado um exemplo, com um servidor B que oferece três
interfaces, e um cliente A, que acede aos serviços da interface If1. Embora o
comportamento por defeito seja a cápsula onde A está a correr terminar quando ocorrer
uma excepção, é possível "apanhar" essas excepções, criando um sistema robusto de
acesso a funções remotas.
If1
If2
If3
A BFigura 6.1 : Modelo computacional do
ANSAware
Os objectos podem obter as referências para os interfaces, passando-as de uns
para os outros, ou através do Trader.
O Trader tem uma funcionalidade semelhante ao gestor de nomes, descrito na
secção 4.6.3: mantém uma base de dados com os interfaces dos servidores activos
existentes no sistema. Em ANSAware a interacção com o Trader é feita utilizando o
esquema representado na figura 6.2. O servidor exporta a referência para o interface
através da operação Export do Trader, que associa um tipo ao interface, e permite
associar um conjunto de propriedades opcionais. O cliente obtém no Trader a referência
para o interface do tipo de serviço que quer aceder através da operação Import. Nesta
operação podem-se impor condições na pesquisa referentes às propriedades com que os
interfaces foram registados, como seleccionar o interface mais recente, ou com o valor
88
Cliente Servidor
IfServIfClient
O ANSA é uma arquitectura fortemente tipificada, sendo utilizados tipos em
diferentes aspectos do modelo computacional. Os interfaces são descritos por tipos,
podendo-se definir relações de subtipo entre os tipos de interfaces, com herança de
protótipos das funções, ou de implementação, não permitindo no entanto, a redefinição
da implementação de funções. O tipo de invocação, com ou sem resposta, também é
categorizado com tipos. Como foi visto, o Trader também guarda os registos
organizados num espaço de tipos.
Modelo de engenharia
O modelo de engenharia suporta o modelo de computação sobre uma variedade de
modelos tecnológicos. São definidos um conjunto de conceitos de baixo nível, como o
núcleo (nucleus) e a cápsula (capsule). O núcleo é a entidade que gere os recursos
específicos dos computadores e constrói sobre eles o ambiente de computação
distribuído que é uniforme no sistema. As cápsulas correspondem aos executáveis que o
programador especifica e corre, e são constituídas por uma colecção de zero ou mais
objectos computacionais compilados. O núcleo fornece às cápsulas um ambiente
multitarefa não preemptivo, onde existem vários processos (threads) que correm
quando são atribuídos a processadores (tasks). As tasks dão o contexto para
processamento independente e podem haver tantas tasks e threads por task quantas se
queiram.
89
UDP TCPIPC
A arquitectura de uma cápsula ANSA está representada na figura 6.3. A
comunicação é definida em três níveis :
O nível mais baixo, proporciona o serviço de transporte, sendo suportados o UDP,
TCP e IPC por named pipes do Unix. A selecção do protocolo a utilizar é feito
transparentemente pelo sistema, durante a invocação de uma operação de uma interface.
A referência da interface contém informação suficiente para o sistema fazer o
emparelhamento de protocolos comuns.
O nível intermédio proporciona a semântica de interacção, e usa chamadas de
procedimento remotas (RPC). Estão definidos dois protocolos: o REX (Remote
EXecution protocol), baseado em [Birrel+ 84], suporta associações ponto a ponto, com
vários tipos de interacção (síncrona, não fiável, assíncrona); o GEX (Group EXecution
protocol) suporta o envio de multicast. Na versão de ANSAware utilizada, o GEX não é
um protocolo independente, mas utiliza os serviços do REX para enviar as mensagem
para vários destinos.
O nível superior de comunicação, o interpretador, é o serviço de sessão e
proporciona as estruturas de diálogo e sincronização. O interpretador fornece agentes
para a comunicação entre cápsulas, que podem ser: Plugs (fichas), para clientes, que
permitem aceder a interfaces remotas; e Sockets (tomadas), para servidores, que
definem os pontos de endereçamento de um interface. Os plugs suportam as operações:
call, um RPC síncrono onde a thread do cliente bloqueia enquanto o pedido está a ser
processado no servidor (figura 6.4); cast, um RPC sem resposta, sem garantias de
recepção do pedido (figura 6.5); request e collect, que iniciam e finalizam um
90
call proc.
Figura 6.4: RPC síncrono.
proc.
Figura 6.5: RPC semresposta.
proc.
collect
Figura 6.6: RPC assíncrono.
No nível superior da arquitectura da cápsula ANSAware, os objectos
computacionais compilados, interagem através dos sockets e dos plugs, utilizando
rotinas de serialização (marshalling) para codificar os parâmetros.
6.1.2. Suporte do modelo de comunicação.
O ANSAware foi seleccionado para a realização do sistema de desenvolvimento
de aplicações multimédia distribuídas porque:
�• oferece um interface para os objectos compatível com o definido nesta
dissertação.
�• permite o suporte de paralelismo interno aos processos (cápsulas), que é
necessário para o desenvolvimento de objectos activos.
�• oferece uma infra-estrutura de comunicação potente e integrada no
processamento geral através de excepções.
�• inclui um servidor de nomes.
�• suporta um contexto de tipos com verificação durante a compilação e durante a
execução das invocações de operações nas interfaces.
Por outro lado, permite que o sistema desenvolvido possa ser portado com um
esforço mínimo para o conjunto de sistemas operativos suportados pelo ANSAware,
91
ç , ç j
componentes distintas: a invocação de acções; a geração de eventos; e a transferência de
fluxos de dados multimédia.
A invocação de acções corresponde a uma invocação fiável de um método de um
objecto, prescindindo-se do retorno da chamada à aplicação por não haver parâmetros
de retorno. No ANSAware, o tipo de invocação que oferece a semântica de passagem
de mensagens, sem resposta, é o tipo cast. No entanto, não existe qualquer tipo de
controlo de erro ou fluxo, tendo de ser feito externamente. Assim, optou-se por utilizar
invocações do tipo call, que embora tenham uma semântica RPC (Remote Procedure
Call), permitem simular a semântica desejada, desde que o tempo de processamento das
operações seja reduzido. Para garantir que esta condição é verificada, nos casos onde a
operação bloquearia, (como por exemplo, a operação Play), a acção limita-se a criar
uma thread que corre a operação pretendida, e a retornar.
A geração de eventos corresponde a uma invocação fiável do método
ReceiveEvent sobre um grupo de interfaces. Aparentemente, a realização mais
simples seria utilizando invocações do tipo call sobre o protocolo GEX. No entanto,
no ANSAware versão 4.1, a utilização de interfaces de grupo ainda não está optimizada,
existindo um conjunto de limitações à sua utilização, que complicariam a realização do
sistema. Assim, optou-se pela utilização de RPCs assíncronos sobre REX para a sua
realização. O envio de um evento é iniciado pelo envio da invocação para todos os
destinos, seguindo-se depois a espera da resposta de todos os destinos.
Comparativamente à utilização do GEX, a principal desvantagem vai ser em relação às
rotinas de serialização, que vão ser chamadas para todas as invocações, em vez de ser
chamadas só uma vez. Caso se tivesse utilizado o GEX, as invocações sobre os
92
p , ;
utilizavam sockets Unix externamente ao ANSAware e se integravam no sistema,
utilizando o interface que o ANSAware oferece para esse efeito. No sistema
desenvolvido nesta dissertação, optou-se por utilizar operações RPC para transferir
esses dados, deixando para uma fase posterior, o desenvolvimento de componentes que
suportem a transferência de dados multimédia através de interfaces dedicados para o
efeito. Nessa fase, já será possível utilizar uma rede experimental ATM, que entretanto
ficou disponível no projecto, mas só na fase final do desenvolvimento do sistema.
6.1.3. Análise do desempenho
Nesta secção apresentam-se os resultados de testes de desempenho da invocação
de funções em interfaces ANSAware. Cada teste foi efectuado para invocações locais,
utilizando IPC, e para invocações remotas, utilizando uma rede Ethernet, e uma rede
ATM que funciona a 100 Mbit/s. As máquinas usadas foram duas SUN SPARCstation
10, uma com um processador, e a outra com dois processadores.
No primeiro teste efectuado, utilizaram-se RPCs síncronos, e testou-se a
dependência do tempo de transmissão de uma invocação em função do número de
octetos enviados, para os três tipos de invocação, tendo-se obtido os resultados
apresentados na tabela 6.1.
Comprimento 0 50 100 200 400 800 1600 3850 8000 16000 32000ATM 3.00 3.08 3.12 3.24 3.46 3.87 5.09 9.99 20.01 49.99 100.05Ethernet 3.00 3.09 3.13 3.24 3.46 3.87 5.18 9.99 20.04 50.00 100.06IPC 2.10 2.22 2.23 2.24 2.27 2.34 2.81 3.65 19.99 40.01 80.15
Tabela 6.1: Tempos de transmissão [ms] em função do comprimentoda mensagem.
93
p ç p , p p
significativo da rede ATM para a gama de valores testados, com o protocolo
REX/UDP.
Observando a figura 6.7, verifica-se que a evolução do tempo de atraso não é
linear. Para ATM apresenta um crescimento lento até cerca dos 1600 octetos, tendo a
partir daí, um crescimento aproximadamente linear. Para IPC apresenta um crescimento
lento até cerca de 3850 octetos, tendo um crescimento brusco perto dos 4000 octetos, e
apresentando uma variação aproximadamente linear a partir daí, com tempos próximos
dos obtidos com ATM.
A existência de um ponto de variação brusca nas comunicações locais pode ser
explicada pelo facto de serem utilizados named pipes do Unix, que têm uma memória
associada de 4 Koctetos, passando a partir daí a haver comutações de processos
adicionais, que vão afectar significativamente o desempenho, provocando um
desempenho praticamente igual à invocação remota para 8 Koctetos.
Nº Octetos
1
10
100
10 100 1000 10000 100000
ATM IPC
Figura 6.7: Tempos de transmissão [ms] emfunção do comprimento, para ATMe IPC.
Atendendo à evolução descrita anteriormente, conclui-se que o desempenho na
transferência de fluxos de informação utilizando invocação de funções é máximo,
quando se utilizam pacotes de dimensão até aos 3850 octetos. No entanto, é de admitir
que esse desempenho está longe do máximo que poderia ser obtido, caso se recorresse a
94
g p q q
testados, e que está associado principalmente às rotinas de serialização (marshalling).
No segundo teste efectuado, testou-se a dependência do tempo de transmissão em
função do número de interfaces invocados em paralelo, quando se utilizam RPCs
assíncronos. Foi testado o envio em paralelo de RPCs nulos para interfaces na mesma
cápsula, e em cápsulas diferentes, tendo-se obtido os resultados apresentados
respectivamente nas tabelas 6.2 e 6.3.
Nº destinos 1 2 3 4 5 6 7 8 9ATM 3.00 4.59 5.40 6.98 8.61 10.33 12.21 14.15 15.50Ethernet 3.00 4.61 5.40 7.02 8.67 10.38 12.25 14.19 15.50IPC 2.10 3.07 4.16 4.97 5.45 6.02 6.88 7.93 8.90
Tabela 6.2: Tempos de transmissão [ms] em função do número dedestinos invocados em paralelo no mesmo servidor.
Nº destinos 1 2 3 4 5ATM 3.00 4.61 5.74 7.94 10.18Ethernet 3.00 4.64 5.92 8.49 10.69IPC 2.10 3.22 4.75 6.30 7.87
Tabela 6.3: Tempos de transmissão [ms] em função do número dedestinos invocados em paralelo em servidoresdiferentes.
A primeira verificação é que os ganhos de performance pela utilização de RPCs
assíncronos em paralelo em relação à utilização de RPCs síncronos sequenciais são
significativos. Utilizando a regressão linear obtêm-se coeficientes de correlação
superiores a 0.99, com valores de (0.99+1.77n) e (1.00+1.59n) para ATM, e
95
q ç p q
em cápsulas (processos) diferentes, devido essencialmente à menor necessidade de
comutação de processos.
Nº Destinos
02468
1012
1 2 3 4 5
1 cápsula n cápsulas
Figura 6.8: Tempos de transmissão [ms] emfunção do número de destinospara ATM com servidores namesma cápsula e em cápsulasdiferentes.
Nº Destinos
0
2
4
6
8
1 2 3 4 5
1 cápsula n cápsulas
Figura 6.9: Tempos de transmissão [ms] emfunção do número de destinospara IPC com servidores namesma cápsula e em cápsulasdiferentes.
Observando o conjunto de resultados obtidos, verifica-se que os valores do tempo
de transmissão vão variar significativamente com o número de interfaces, podendo
atingir valores não desprezáveis com "multicasts" para um número de interfaces
superior a 5, que podem dar origem a alguns problemas do tipo dos descritos na secção
3.4 (por exemplo, recepção de mensagens não atómica ou fora da ordem causal). No
entanto, nesta dissertação o problema não foi resolvido por falta de tempo, sendo esta
uma das suas limitações. Para resolver este problema, poder-se-ia utilizar qualquer
96
Nesta dissertação foi implementado um conjunto de objectos multimédia com
características diferentes, de modo a permitir testar o sistema. Foram realizados
objectos cujos dados multimédia têm uma natureza isócrona (objectos de Vídeo e de
Áudio), e objectos sem essa natureza, que são usados sobretudo em composições de
hipertexto, (objectos de Diapositivos e de Texto). Para permitir a definição de relações
temporais fixas entre a activação dos objectos, foi implementado um objecto de
Relógio.
Na tabela 6.4 são apresentados os tipos de objectos multimédia implementados, os
estados suportados por cada um, e os tipos de componentes que foram desenvolvidos
para os realizar.
ObjectoMultimédia Estados Suportados Fontes Destinos
Vídeo Contexto Anotação mpegSource mpegSinkVelocidade Pausa
ClickDiapositivos Contexto Anotação imagSource imagSink
Click VelocidadePausa
Texto Contexto Anotação text scrolledwindowClick
Audio Contexto Anotação soundVelocidade Pausa
Relógio Contexto Anotação timerVelocidade Pausa
Tabela 6.4: Os tipos de objectos multimédia e de componentesimplementados, e os estados associados.
97
( ), p ( , , ), p, p, p,
CMU WM Raster, FBM Image, McIDAS areafile e Faces Project. Estes objectos
funcionam em dois modos: se for fornecida uma lista de nomes na propriedade
FILENAME, então mostram um conjunto de imagens em sequência; senão, mostram
apenas uma imagem. O tempo de apresentação de uma imagem pode ser infinito, nunca
sendo gerados os eventos de fim de objecto sem intervenção directa do utilizador; ou
então, limitado pelo valor especificado para a propriedade IMAGE$TIME, que
determina o tempo de duração da apresentação de cada imagem. Para implementar estes
objectos foram desenvolvidos dois servidores de componentes, que gerem todas as
fontes e destinos para a máquina onde estão a correr.
Os objectos de Vídeo também foram realizados sobre X Windows, tendo sido
utilizadas algumas rotinas do software (freeware) MPEG Video Software
Decoder versão 2.0 [Patel+ 93], que fazem a descodificação do formato MPEG
[ISO 11172]. De entre os objectos realizados, os objectos de vídeo são os mais pesados
em termos de processamento, sendo utilizada uma cápsula (processo Unix) por cada
objecto componente destino, pois a concorrência interna às cápsulas não é suficiente
para garantir a qualidade mínima de apresentação. Os dados são trocados entre a fonte e
o destino no formato MPEG, de modo a minimizar a quantidade de informação
transmitida. O valor inicial do número de imagens apresentadas por segundo é definido
na criação do objecto pelo valor da propriedade FRAME$RATE, podendo depois ser
modificado dinamicamente através do interface do estado Velocidade. Caso não seja
possível obter o ritmo especificado, são saltadas imagens, poupando-se no tempo de
98
p [ ],
estrutura semelhante aos objectos de imagem. O seu funcionamento é controlado pela
propriedade mode, que por defeito tem o valor "allfile", não sendo gerados os eventos
de fim de apresentação, excepto por ordens explícitas na interface de controlo.
O objecto de áudio foi implementado sobre os serviços do AudioFile
[Levergood+ 93]. O AudioFile permite que múltiplos clientes comuniquem com
servidores de som partilhando o acesso aos dispositivos de som de uma forma
semelhante à utilizada pelo X Windows, sendo fornecida uma biblioteca de funções e
um interface de programação de aplicações que permitem a construção de clientes.
O objecto de Relógio permite dois tipos de funcionamento, conforme o valor da
propriedade PERIODIC. Quando funciona no modo intervalo de tempo, gera um
evento isolado ao fim de um número de segundos, ou num instante de tempo pré-
definido, conforme o tipo de anotação utilizado na chamada à função Play (GMTime
para um instante de tempo fixo). Quando funciona no modo cíclico, gera um evento
com uma periodicidade definida pela propriedade TIMEOUT em milisegundos,
podendo-se modificar a escala de tempo através do interface do estado velocidade.
Em relação ao controlo da transferência dos dados das fontes para os destinos,
foram utilizadas duas soluções distintas. Nos objectos de som e imagem, o envio dos
dados é controlado pelas fontes, enquanto no objecto de vídeo, o envio dos dados é
controlado pelo destino. Em qualquer dos casos, foram utilizados RPCs ANSAware,
sobre um interface independente dos interfaces de controlo, de modo a permitir uma
posterior substituição por um mecanismo mais eficiente de comunicação. Para os
3numa primeira fase são saltadas tramas tipo B, numa segunda fase tramas tipo P, e só em último
caso tramas tipo I.
99
ç ç
controlo. No entanto, quando se utiliza um protocolo stream, tem-se uma situação
semelhante à de ter o controlo de envio na fonte, tornando assim esta solução desejável
no sentido de permitir uma adaptação futura mais fácil.
6.2.1. Constituição dos Objectos Multimédia e Componentes
A implementação dos objectos multimédia e componentes seguiu o esquema
descrito nas secções 4.4 e 4.5.
Para cada tipo de objecto componente multimédia existe pelo menos um servidor
no sistema, podendo existir um por cada máquina. Cada servidor de componentes
exporta o interface do seu estado VidaComponente para o gestor de nomes, com o
nome do componente, indicado na tabela 6.4. As instâncias dos componentes criados
num servidor correm na mesma cápsula (processo Unix) onde foram criados,
exceptuando os casos onde o paralelismo oferecido pelas threads não seja
suficientemente poderoso, como por exemplo nos componentes destino de MPEG, que
correm em processos separados.
Os objectos multimédia têm apenas um tipo de servidores, que pode gerir qualquer
tipo de objecto multimédia. No sistema deve haver pelo menos um servidor de objectos
multimédia, podendo existir um por cada máquina. Cada servidor de objectos multimédia
exporta o interface Vida para o servidor de nomes com o nome "Vida". Para cada nova
instância de objecto multimédia, o servidor cria as instâncias dos objectos componentes
que o compõem, e gere o estabelecimento das ligações entre os seus portos, mantendo
um descritor interno, que pode incluir uma máquina de estados associada ao objecto. O
estado Contexto do objecto multimédia é gerido localmente na cápsula do servidor
100
p q p j , g g
conclui a invocação, e são retornadas as respostas para quem invocou a operação,
sempre que tal é necessário. No caso das operações Play e Stop é utilizado um
semáforo ANSA, para garantir que as duas operações não correm em paralelo para um
mesmo objecto. A acção receiveEvent é a única que não é processada pelos
componentes, mas sim pelo interpretador interno aos objectos multimédia (controlador)
que corre uma máquina de estados. Caso o controlador não esteja activo, a acção é
ignorada.
Na figura 6.10 apresentam-se os passos executados durante a construção de um
novo objecto multimédia.
Server imagsrc
imagsnk
Objecto multimédia
Gestor de Nomes
Máquina
de
Estados
1
2
3
4
56
4
Figura 6.10: Criação de um objecto multimédia de Diapositivos.
A criação de objectos multimédia é feita a partir de interpretadores que correm
máquinas de estados. Os interpretadores começam por consultar o gestor de nomes (1)
101
, q g p j ç p
aceder ao gestor de nomes (3) para obter referências para os servidores dos
componentes necessários à construção do novo objecto. Em seguida, o servidor de
objectos invoca a acção Prepare do estado VidaComponentes sobre todos
servidores de componentes (4), obtendo as referências para os componentes criados, e
para os portos de cada um. No passo seguinte (5), invoca a acção Connect do estado
Porto sobre todos os portos que foram especificados nos parâmetros da invocação (2),
sendo estabelecidas todas as ligações de dados multimédia. Caso tenha sido especificada
a propriedade SELFCONTROLLED nesses parâmetros, com um nome de um ficheiro
com uma máquina de estados válida, então é criado um controlador interno ao objecto
multimédia (secção 4.5), existindo uma fase (6) onde o controlador carrega a máquina
de estados. A partir do momento em que arranca, o controlador passa a correr como
qualquer outro interpretador no sistema. Por fim, é retornado o interface do estado
Contexto do novo objecto para o interpretador que criou o objecto.
Por exemplo, no caso representado na figura 6.10, seria criado um objecto de
diapositivos, que teria três componentes a correrem em três cápsulas distintas. Este
objecto apresenta externamente cinco interfaces, tal como tinha sido indicado na tabela
6.4. Internamente, os estados estão distribuídos pelos três componentes. O componente
fonte (cápsula imagsrc) é o responsável pelo controlo do envio dos dados, assim
controla os estados Anotação, Velocidade e Pausa. O componente destino
(cápsula imagsnk) é o responsável pela apresentação das imagens no écran,
controlando o estado Click. O dispatcher e eventualmente o controlador (ambos na
cápsula Server) são responsáveis pelo estado Contexto do objecto.
102
6.3.1. Linguagem
A solução mais comum na literatura para a compilação de álgebras de processos,
é a de transformar as especificações em máquinas de estados convencionais [Karjoth
88], ou em código C que as realiza [Cardelli+ 85]. Nessas máquinas de estados, define-
se um conjunto de estados possíveis e as transições disponíveis para cada estado, só
podendo estar um estado activo em cada instante. No entanto, esta transformação não é
a mais apropriada para representar o paralelo entre processos, pois gera um espaço de
estados que é o resultado do produto cartesiano dos espaços de estados envolvidos em
cada ramo do paralelo, originando um crescimento explosivo do número de estados em
função do número de eventos de entrada na máquina de estados. Assim, optou-se por
representar directamente a álgebra de processos implementando a sua semântica e
criando um sistema onde o estado global é definido pelo número de processos activos
num dado instante. A introdução de uma composição paralela não cria novos estados,
mas apenas acrescenta mais processos à definição do estado.
O resultado final pode ser visto como uma máquina de estados definida por uma
álgebra de processos, que é traduzida durante a execução do interpretador para uma
máquina de estados tradicional, pois o interpretador só vai processar uma transição de
cada vez.
A estrutura da declaração das máquinas de estados é semelhante à definida para a
especificação de aplicações multimédia, seguindo a estrutura apresentada na figura
6.11.
103
Uma máquina de estados é identificada por um nome, NomeMáqEstados, que a
identifica univocamente. As restantes secções do cabeçalho definem a interface externa
da máquina de estados. A secção listaEventos serve para declarar a visibilidade
exterior de estados, eventos e acções, permitindo definir quais os que são processados
na máquina de estados. A secção listaParâmetros contém uma lista com os
identificadores dos objectos inicializados por outros interpretadores, que são utilizados
no código da máquina de estados.
A secção DeclaraçãoObjectosMM contém a lista de todos os objectos que
vão ser criados no âmbito da máquina de estados local, contendo todos os parâmetros
que são utilizados durante a invocação da acção Prepare. O modo como os dados são
dispostos foi optimizado, de modo a simplificar a gestão de memória no interpretador,
passando as listas a ter como primeiro parâmetro o número de elementos da lista.
A secção DeclaraçãoVariáveis define variáveis para posterior utilização,
associando um tipo e eventualmente um valor inicial a cada variável.
A secção DefiniçãoInicializações contém uma lista de inicializações
para os vários objectos utilizados na especificação. Cada elemento da lista refere-se a
um objecto, e contém a lista de interfaces de estados que deve ser obtida com a acção
Inform (precedida da palavra chave STATUS), e a lista de estados onde deve ser
registado o interesse em receber eventos com a acção RegisterStatusInterest
(precedida da palavra chave REGISTER).
Em relação à secção ExpressõesComportamento, ela define a máquina de
estados propriamente dita, utilizando uma sintaxe e semântica semelhantes às
apresentadas no capítulo cinco desta dissertação, para a linguagem de definição de
aplicações multimédia. As diferenças fundamentais residem na não existência de
104
de objectos multimédia, e para a troca de referências para interfaces de objectos
multimédia.
O primeiro tipo de interacção, representado na figura 6.12, suporta a criação de
um novo objecto multimédia, e posteriormente, a inicialização das referências para
objectos multimédia, a partir do criador do objecto. Neste tipo de interacção são
utilizadas três operações:
�• PREPARE, invoca a acção Prepare sobre o estado Vida do servidor de
objectos multimédia, criando um novo objecto. Ao retornar, deixa o interface do
objecto criado inicializado a nível da máquina de estados onde a operação foi corrida.
�• INIT, é utilizada para inicializar a referência para um objecto. Esta operação
bloqueia o processo até que se receba uma acção Bind sobre o estado Remctrl
(descrito na secção 4.3.3, página 56) que contenha o interface do objecto pretendido.
�• BIND, é utilizada para fornecer referências para objectos a outras máquinas de
estados. Provoca a invocação da acção Bind sobre o estado Remctrl do controlador
do objecto destino. Caso o objecto destino não suporte esse estado (não tenha o
controlador activado), é gerado um erro de execução.
O segundo tipo de interacção, representado na figura 6.13, permite suportar a
troca de referências para interfaces de objectos entre quaisquer interpretadores,
utilizando o gestor de nomes. Neste tipo de interacção são utilizadas duas operações:
�• EXPORT, exporta um interface conhecido na máquina de estados para o gestor
de nomes, associando-lhe um nome chave.
�• IMPORT, importa um interface do gestor de nomes, pesquisando o registo
mais recente de um nome chave. Caso a primeira pesquisa falhe, a operação bloqueia o
processo, e entra num ciclo onde adormece e torna a fazer a pesquisa ao gestor de
nomes. A operação só é concluída quando a pesquisa for bem sucedida.
105
Figura 6.12: Operações utilizadas durante acriação de objectos e inicializaçãode referências do novo objecto.
Figura 6.13: Operações usadas entremáquinas de estadosconcorrentes.
6.3.2. Interpretadores
Os interpretadores são as entidades do sistema que são utilizadas para correr
máquinas de estados, e que podem existir internamente aos objectos multimédia,
chamando-se controladores, ou então externamente, como entidades activadoras de
aplicações multimédia.
Os interpretadores guardam as máquinas de estados internamente numa estrutura
em árvore, que é criada quando a máquina de estados é lida. A cada nó da árvore está
associada uma operação, sendo a estrutura da árvore definida pelas operações de
composição (SEQ, PAR, ALT, IF e WHILE), que constituem os nós intermédios da
árvore. As folhas da árvore contêm todas as restantes operações, que dão origem a
processamento.
Por exemplo, para a máquina de estados cuja secção
ExpressõesComportamento fosse a representada na figura 6.14, seria criada a
estrutura de dados representada na figura 6.15. Observa-se que as duas operações de
composição deram origem a dois nós intermédios na árvore, que têm como ramos uma
lista duplamente ligada de nós, que correspondem aos parâmetros dos operadores de
composição.
PAR OR
106
Objecto?Ev_End
Objecto?Ev_Click
Objecto!PLAY
SEQ
PAR OR
Inic io
1
3
2
4
5
Figura 6.15: Arquitectura de nós criada a partir do exemplo da figura6.14.
Para facilitar a movimentação na árvore, cada nó tem sempre um ponteiro para o
nó que o precede hierarquicamente, excepto o nó raiz, onde esse ponteiro vale NULL.
A raiz é apontada por um ponteiro Inicio que existe no sistema.
Como o interpretador corre em apenas um processo Unix, não é possível ter
paralelismo na execução de operadores, não sendo directamente realizável a semântica
definida para a linguagem de especificação da máquina de estados. Desta forma, só se
executa uma transição de cada vez na máquina de estados, e de forma atómica. No
entanto, algumas operações podem bloquear, como a operação de entrada (recepção de
eventos). Assim, é necessário associar um estado a cada nó, que indica se a operação
que lá está representada já correu, está bloqueada à espera de ser concluída, ou
eventualmente, se houve um erro. Cada nó pode estar num de quatro estados possíveis:
�• IDLE_EXPR, é o valor com que os nós são inicializados, e significa que a
expressão ainda não foi corrida.
�• RUN_EXPR, significa que a expressão foi activada, mas ainda não terminou.
�• END_EXPR, significa que a expressão já correu.
107
entrada (recepção de eventos), INIT e IMPORT, que implicam o bloqueio da operação
até que chegue o evento ou acção pretendido, ou que alguém registe o interface
pretendido no gestor de nomes. Para gerir estas operações, são organizadas filas de
espera para cada um dos tipos de acontecimentos, onde são guardadas estruturas que
contêm a descrição da informação pretendida, e um ponteiro para o nó onde a operação
foi invocada. Quando estas operações são executadas, o descritor do acontecimento (que
é criado durante a criação da árvore de nós) é colocado na fila de espera respectiva,
parando em seguida a execução do nó, que fica no estado RUN_EXPR. Só quando é
recebido o acontecimento pretendido, é que o nó é desbloqueado, passando ao estado
END_EXPR, continuando-se então a correr os nós da árvore, a partir do ponto onde
tinha sido interrompido. Nesta realização, os eventos são processados sequencialmente,
pela ordem porque são recebidos no interpretador.
Quando uma composição paralela é iniciada, tem de se iniciar um a um todos os
seus nós filhos. Poder-se-ia sortear a ordem pela qual a inicialização seria feita para
simular não determinismo, mas optou-se, por razões de eficiência e simplicidade, por
iniciar os processos sequencialmente pela ordem por que aparecem na descrição da
máquina de estados.
Vai-se agora reutilizar a máquina de estados da figura 6.14, que é guardada
internamente na estrutura representada na figura 6.15, para exemplificar como o
interpretador corre uma máquina de estados. Quando o interpretador é activado, começa
a percorrer os nós a partir da raiz da árvore, percorrendo sucessivamente o nó 1, 2, 3, 4
e 5. No fim, o processamento fica bloqueado, pois existem duas operações pendentes
nos nós 4 e 5, que ainda não concluíram as operações de entrada, e que fazem com que
os nós 1, 2, 4 e 5 fiquem no estado RUN_EXPR. A partir daqui a execução vai
depender de qual o evento que vai ser recebido primeiro. Se for recebido primeiro um
108
_ , p p ç , q p
cancelamento das operações pendentes no nó 2, e logo do nó 4, terminando em seguida
a execução da máquina de estados, pois o nó raiz atingiu o estado END_EXPR.
A versão desenvolvida nesta dissertação apresenta algumas limitações em relação
ao que seria necessário para suportar completamente, a linguagem definida no capítulo
cinco. A principal, é não suportar ainda variáveis partilhadas por várias máquinas de
estados.
6.3.2.1. Integração dos interpretadores nos executáveis
Nesta dissertação, os interpretadores podem ser utilizados tanto como processos
independentes em objectos interpretadores de máquinas de estados (secção 4.6.1), ou
em controladores, internos a objectos multimédia, podendo existir vários na mesma
cápsula. Optou-se por implementar uma estrutura modular com um interface bem
definido, que pode ser, assim, utilizado em ambos os casos.
Os interpretadores são definidos por descritores do tipo ControllerData, que
contêm todas as variáveis de estado, listas de espera, lista de variáveis e listas de
referências para as interfaces utilizadas. A integração do código de um interpretador
noutro executável é feito através de seis funções: load_script,
init_control_data, run_script, receive_Event, finish_script e
free_control_data.
A função load_script recebe como parâmetros um ponteiro para um descritor
de interpretador e o nome do ficheiro com a máquina de estados, e é utilizada para
carregar a máquina de estados, construindo a árvore de nós, e inicializando as variáveis
do descritor respectivas.
A função init_control_data é chamada após a função load_script,
sendo utilizada para finalizar a inicialização do descritor do interpretador. Nesta função
109
p ç , ç q p , p ç
Retorna TRUE caso não tenha chegado ao fim da especificação, tendo ficado alguma
operação pendente. Senão, se houve algum erro durante a execução, ou se terminou a
execução da máquina de estados, retorna FALSE.
A função receive_Event deve ser chamada após a recepção de uma
invocação da função ReceiveEvent no interface Contexto associado ao
interpretador. Assim, é utilizada para continuar o execução da máquina de estados a
partir do ponto onde tinha ficado interrompida.
As funções finish_script e free_control_data são usadas
respectivamente para interromper a execução de uma máquina de estados, e para
destruir um descritor de interpretador, libertando a memória ocupada.
6.4. COMPILADOR
O compilador mmcompiler é o elemento do sistema de desenvolvimento de
aplicações multimédia, que se destina a transformar especificações de aplicações
multimédia (scripts) escritas na linguagem definida no capítulo cinco, em máquinas de
estado, descritas utilizando a linguagem introduzida na secção 6.3 deste capítulo.
Um dos objectivos desta dissertação foi desenvolver um sistema de geração
automática de máquinas de estados para a realização de controlo distribuído, a partir de
especificações textuais. Embora o interpretador desenvolvido seja genérico, e permita a
utilização de uma arquitectura de controlo misto, com características centralizadas ou
distribuídas, durante esta fase de desenvolvimento do compilador, optou-se por centrar
o trabalho apenas numa arquitectura de controlo distribuído, onde cada interpretador só
é utilizado para controlar um objecto multimédia. Evitou-se assim uma duplicação de
110
q p , p ç
inicialização das referências para os objectos, que em vez de ser feita com as operações
PREPARE, INIT e BIND, é feita através do gestor de nomes (Trader do ANSAware),
utilizando as operações EXPORT e IMPORT.
6.4.1. Algoritmo de Compilação
O algoritmo de compilação desenvolvido baseia-se na decomposição das
especificações num paralelo de sequências de operações independentes entre si, que
podem ser corridas em máquinas de estados diferentes. Como entrada aceita uma
especificação de uma aplicação, que compila, gerando um conjunto de máquinas de
estados.
As máquinas de estados geradas têm a estrutura representada na figura 6.16, que
define três secções: A primeira, inicializações, é utilizada para inicializar as
referências para os objectos multimédia; a segunda, expressões_em_loop, é
utilizada para gerir operações de controlo (em ciclo infinito), que podem ser geradas
durante a compilação das especificações; e a terceira, expressões_objectos,
contém o código encarregue de gerir a apresentação dos objectos multimédia.
SEQ inicializações PAR OR expressões_em_loop PAR
expressões_objectos END; END;END
Figura 6.16: Estrutura do código de uma máquina de estados geradapelo compilador.
111
p ç p ç p g p p ç ,
contém informação de sincronização suficiente para poder ser corrida em paralelo (PAR
AND) com todas as outras expressões que também foram geradas a partir da
especificação, e no conjunto, controlar uma parte da apresentação global. Caso se corra
o paralelo de todas as expressões, corre-se a aplicação definida na especificação.
Para se gerar um conjunto de máquinas de estados, que realizem o controlo
distribuído da aplicação, basta dividir as expressões por várias máquinas, podendo
depois ser feitas optimizações, de modo a simplificar a máquina de estados criada,
aproveitando as partes comuns no código das expressões em paralelo. Assim, este
método é genérico, no sentido em que permite gerar código para uma arquitectura de
controlo misto, podendo-se controlar a menor (ou maior) distribuição definindo grupos
de expressões maiores, que incluam expressões referentes a vários objectos.
Para se conseguir definir um algoritmo de conversão das especificações para um
paralelo de expressões, é necessário poder representar a condição de terminação de uma
dada expressão, que corresponde à transição na semântica da linguagem de
especificação. Assim, define-se código de terminação de uma expressão como a
composição de eventos que define univocamente o fim do processamento dessa
expressão, e representa-se por X para uma expressão X. O código de terminação vai
ser definido por expressões da linguagem que são função da recepção de eventos,
podendo ser uma expressão vazia, no caso em que uma dada expressão é instantânea do
ponto de vista de controlo, como por exemplo, no caso da invocação de uma acção.
O algoritmo desenvolvido funciona de uma forma recursiva, ou seja, começa a
construir o código compilado a partir das expressões básicas da especificação,
passando-o depois para os vários operadores de composição que envolvem essas
expressões.
112
SEQ objecto ! Play ( EventoInicio, EventoFim ) objecto ? EventoFimEND
Na expressão anterior, EventoInicio e EventoFim representam os eventos
que delimitam a apresentação que vai ser mostrada. No caso de intervalos, objecto
corresponde ao nome do objecto sobre o qual foi definido o intervalo. Caso a activação
de um objecto esteja dentro de um operador paralelo que está a fazer sincronização de
pelo menos um estado, então a expressão anterior é modificada, de acordo com o que
será descrito quando se apresentar o operador paralelo.
O código de terminação é definido pela expressão:objecto ? EventoFim
6.4.1.2. Operação de Saída
A operação de saída para objectos é compilada para uma expressão idêntica à
original, excepto que o nome da operação é substituído pelo código da operação.
Caso seja um intervalo, então é mais complexo. O algoritmo de codificação cria
uma variável auxiliar Booleana, varAux, com um nome gerado aleatoriamente, local à
máquina onde a expressão for utilizada, e que será gerida utilizando a expressão (que
será colocada na secção expressões_em_loop) :WHILE (TRUE) SEQ varAux:= FALSE;
objecto ? EventoInicio;varAux:= TRUE;objecto ? EventoFim;
END;
A operação de saída será então compilada para:IF varAux THEN objecto!Accção
Em qualquer dos casos, o código de terminação é vazio.
113
pSEQ objecto ? evento; WHILE (not varAux) DO objecto ? evento;END;
Em qualquer dos casos, o código de terminação é igual ao código após a
compilação.
6.4.1.4. Operação ABORT
A operação ABORT é compilada para a mesma operação. Ao contrário do código
gerado pelas expressões, as expressões de ABORT têm de ser incluídas em todas as
máquinas de estados geradas, de modo a garantir que todos os interpretadores utilizados
na aplicação possam abortar.
6.4.1.5. Composição Sequencial
A compilação de uma operação de composição sequencial baseia-se na
equivalência entre as duas expressões seguintes:SEQ A; B; END
PAR SEQ A ; B; END; SEQ A; B ; END;END
Assim, a compilação de uma composição sequencial consiste numa modificação
do código das expressões A e B, onde o código de B é substituído pela primeira
composição sequencial do lado direito da equivalência, e o código A é substituído pela
segunda. Caso a sequência não esteja dentro de um operador WHILE, pode ser utilizada
a simplificação de manter a expressão de A, não acrescentando B em sequência.
O código de terminação da sequência é obtido pela expressão:SEQ A ; B ; END
114
No entanto a compilação da composição paralela é mais complexa do que a
expressão sugere, pois é definida a parametrização do operador em função de muitos
mais aspectos.
Quando o operador paralelo termina, definiu-se que deveria destruir todos os
objectos que participaram nele, e ainda estão activos. A expressão anterior verifica esta
regra para a operação PAR AND, mas não para a operação PAR OR. Assim, foi
definida uma nova regra de compilação do PAR OR, para os casos onde uma expressão
A contém a activação de um objecto, designado por Aobj. Nesses casos, é utilizada a
regra de compilação apresentada a seguir, onde após ser detectada a condição de
terminação, é acrescentada uma chamada à acção Stop sobre o objecto invocado na
expressão:
PAR OR A; B; END
PAR PAR OR SEQ A ; Bobj!STOP; END; B; END; PAR OR SEQ B ; Aobj!STOP; END; A; END;END
Também se definiu a existência de uma relação hierarquica (em termos espaciais),
entre o primeiro objecto que aparece na especificação do paralelo e os restantes, desde
que a primeira expressão dê origem à activação de um objecto ou intervalo. Esta regra
foi realizada garantindo que o primeiro membro do paralelo é o primeiro a arrancar, e
logo o primeiro a criar a janela. Como os objectos geram o evento Ev_Start quando
iniciam a sua apresentação, é possível fazer a composição entre a geração deste evento e
o arranque dos restantes membros do paralelo. Se se chamar ao evento de início de
apresentação do primeiro membro do paralelo Aini, obtém-se como resultado da
compilação de um paralelo (PAR AND) entre A e B as expressões:
115
intervalos e objectos é modificado dentro da composição paralela, desde que os objectos
suportem o estado que está a ser sincronizado. Por exemplo, para a invocação de um
objecto objecto dentro de um paralelo parametrizado com SYNC(Pausa)
(sincronização do estado Pausa), é gerado o código apresentado na figura 6.17, onde é
utilizada uma variável Booleana auxiliar, local ao interpretador onde corre o código.
116
PAR ORobjecto?Ev_Start; objecto?Ev_Resume;
END; auxPausa:= FALSE; END; WHILE (TRUE) DO SEQ objecto?Ev_Paused; auxPausa:= TRUE; END; WHILE (TRUE) DO SEQ PAR OR objectoi?Ev_Paused; // para todos os outros objectos END; objecto!Pause; END; WHILE (TRUE) DO SEQ PAR OR objectoi?Ev_Resume; // para todos os outros objectos END; IF (auxPausa) objecto!Resume; END;END
Figura 6.17: Código gerado para a invocação de um objecto dentro deum PAR SYNC(Pausa).
O código de terminação do paralelo (PAR X) é obtido pela expressão:PAR X A ; B ; END
6.4.1.7. Execução Repetitiva
A compilação de uma operação de execução repetitiva baseia-se na equivalência
entre as duas expressões seguintes:
117
O código de terminação da execução repetitiva da expressão A é obtido
calculando:WHILE (expressão) A
6.4.1.8. Outras Operações
Nesta versão do compilador não foram suportadas as operações de execução
condicional, operação de atribuição e composição alternativa, embora essas operações
existam nos interpretadores. O motivo que justificou a sua não implementação, foi os
interpretadores não suportarem a gestão de variáveis distribuídas, pois essa
funcionalidade é indispensável para suportar esses operadores de uma forma genérica
em ANSAware.
6.4.2. Compilador
O compilador foi desenvolvido utilizando o LEX e o YACC [Schreiner+ 85, SUN
88], e realiza o algoritmo de compilação descrito na secção anterior. O compilador
funciona em três fases distintas.
Na primeira fase é lido o script com a especificação da aplicação multimédia, e é
criada uma estrutura em árvore com a representação do comportamento, mais uma lista
com os objectos definidos. Nesta primeira passagem são efectuados um conjunto de
testes semânticos às expressões, utilizando a informação obtida no gestor de tipos.
Nomeadamente, são validadas todas as operações de entrada e saída, sendo verificado se
o tipo de objecto suporta os estados associados aos eventos e acções. A árvore
construída é semelhante à descrita para os interpretadores (secção 6.3.2), embora os nós
tenham uma estrutura interna diferente.
118
ç ç j [ ]
Na fase final é feita a aglutinação das várias expressões nas máquinas de estados
finais, sendo ainda criada a máquina de estados de arranque da aplicação, que inclui o
código de invocação das operações PREPARE, com os parâmetros para criação dos
objectos multimédia.
Estruturas de Dados
O compilador guarda os dados em duas estruturas independentes. A primeira
estrutura é uma árvore de nós gerada a partir da especificação do comportamento, onde
se guarda a informação sobre o código, à medida que este é criado. A segunda estrutura
é uma lista com todos os objectos multimédia utilizados na especificação, e que inclui
ponteiros para os intervalos utilizados.
Na figura 6.18 é representada a estrutura de dados de um nó da árvore. Para além
dos dados que definem o tipo de operação, os nós vão ter dois campos que vão ser
utilizados durante a geração de código. O primeiro é um ponteiro para uma string com
o código de terminação. O segundo é um ponteiro para uma lista de estruturas do tipo
st_code, que são a base da geração de código. Estas estruturas contêm ponteiros para
um buffer (tampão) onde guardam o código referente a uma invocação (de um objecto,
intervalo ou operação ABORT), e um ponteiro para o objecto afectado pelo código (que
pode ser NULL). Para além de fazerem parte das listas associadas às árvores de nós,
estes nós também fazem parte de listas associadas aos descritores de objectos. O código
da expressão associada a cada nó da árvore pode ser obtido calculando o paralelo de
todas as estruturas de código na lista.
Na figura 6.19 é representada a estrutura de dados de um nó da lista de descritores
de objectos. Estas estruturas mantêm um vector de ponteiros para os intervalos que
compõem o objecto, uma estrutura com os dados internos do objecto multimédia, e uma
119
ód1 d2 d3
Código Código Código
Figura 6.18: Constituição dos elementos daárvore de comportamento.
d1 d2 d3
Código Código Código
Cache da informação do gestor de tipos
Figura 6.19: Constituição dos elementos dalista de objectos utilizados.
Exemplo de Compilação
Na figura 6.20, é representado um exemplo com um excerto de um script, onde
são utilizados três objectos multimédia: A, B e C. Após a primeira fase de compilação é
gerada a árvore de nós com a estrutura representada na figura 6.21.
PAR OR SEQ A; B; END; C;END;
Figura 6.20: Exemplo da secção deespecificação de comportamentode um script.
B
C
A
SEQ
PAR OR
Inic io
1
3
2
4
5 Figura 6.21: Estrutura de nós criada a partirdo exemplo da figura 6.20.
Durante a segunda fase de compilação a estrutura é percorrida a partir do início,
sendo gerado o código apresentado na tabela 6.5, pela ordem indicada. O primeiro nó a
ser processado é o 1, sendo criado uma estrutura do tipo st_code, que é colocada na
120
g p ç , p g
terminação do nó 5 tem a condição de terminação da apresentação, e os descritores dos
objectos A, B e C vão ter respectivamente os descritores d1, d2 e d3 da lista do nó 5.
Na terceira fase de compilação são geradas as máquinas de estados dos três
objectos, sendo acrescentado o código de inicialização das referências para os objectos.
Por exemplo, para a máquina de estados do nó A seria gerado o código apresentado na
figura 6.22.
Nó Código de Terminação Código1 A?Ev_End d1 : SEQ A!PLAY; A?Ev_End; END
2 B?Ev_End d1 : SEQ B!PLAY; B?Ev_End; END
3 SEQ
A?Ev_End; B?Ev_End;
END
d1 : SEQ A!PLAY; A?Ev_End; END
d2 : SEQ A?Ev_End; B!PLAY; B?Ev_End;
END
4 C?Ev_End d1 : SEQ C!PLAY; C?Ev_End; END
5 PAR OR
SEQ A?Ev_End; B?Ev_End;
END;
C?Ev_End;
END
d1 : PAR OR
SEQ A!PLAY; A?Ev_End; END;
SEQ C?Ev_End; A!STOP; END;
END
d2 : PAR OR
SEQ A?Ev_End; B!PLAY; B?Ev_End;
END;
SEQ C?Ev_End; B!STOP; END;
END
d3 : PAR OR
SEQ A?Ev_Start; C!PLAY;
C?Ev_End; END;
SEQ
SEQ A?Ev_End; B?Ev_End; END;
C!STOP; END;
END
Tabela 6.5: Código intermédio gerado durante a segunda fase decompilação do exemplo da figura 6.20.
STATEMACHINE A ( A MMObject Tipo, B MMObject Tipo,
121
INIT A; INIT B; INIT C; END; PAR OR /* Código gerado na fase 2 */ SEQ A!PLAY; A?Ev_End; END; SEQ C?Ev_End; C!STOP; END; END;END;ENDSM
Figura 6.22: Máquina de estados criada para o objecto A, a partir doexemplo da figura 6.20.
122
SOURCE (1, Source); FILTER (0); SINK (1, Sink);LINK (2, Source, Sink);START <1/*Locator*/,,0>; END <1/*Locator*/,,-1>;PROPERTIES (4, SELFCONTROLLED, "A.scr", FILENAME, "Exemplo");ENDOBJECT;/* Objectos B e C são semelhantes a A */
INITIALIZEA { Status (1, 41/*RemCtrl*/); Register (1, 29/*Contexto*/); }/* B e C é igual a A */END
BEHAVIOURSEQ PAR PREPARE A; PREPARE B; PREPARE C; /* Cria os objectos */ END; PAR BIND B A; BIND B C; // Inicializa as referência de A e C em B BIND C A; BIND C B; // Inicializa as referência de A e B em C END; PAR BIND A B; BIND A C; // Inicializa as referência de B e C em A END; PAR OR // Código de terminação da aplicação SEQ A?Ev_End; B?Ev_End; END; C?Ev_End; ENDEND;ENDSM
Figura 6.23: Máquina de estados de arranque da aplicação criadapara o exemplo da figura 6.20.
Observe-se que na máquina de estados de arranque gerada, o controlador em A é o
último a ter as referências para os interfaces inicializados. Como A é o primeiro objecto
a correr no paralelo, deve ser o último a ser inicializado, de modo a garantir que a
123
Na figura 6.24 apresenta-se o script de uma aplicação de demonstração do sistema
de desenvolvimento de aplicações multimédia, cujo aspecto durante a execução é
mostrado nas figuras 6.26 a 6.29.
Esta aplicação apresenta um texto, composto por três páginas. Na primeira página
apresenta um texto com uma imagem, enquanto toca uma música de fundo
continuamente. Na segunda página alterna entre um estado onde apresenta o "botão"
Tocar, e outro onde apresenta um vídeo com o som respectivo e o "botão" Parar. Na
última página torna a apresentar um texto e uma imagem. O utilizador muda de página
carregando no texto com o rato, podendo terminar a aplicação em qualquer altura
carregando no "botão" Terminar.
SPECIFICATION Demonstracao : NOEXIT ;
MMOBJECT Texto textType WITH SUB$STRUCTURE (
Introducao <Label,Pagina1> <Label,FimPagina1> Exemplo <Label,Pagina2> <Label,FimPagina2> Fim <Label,Pagina3> Ev_End )
filename "demo.txt"anotfile "demo.ant"windowname "Exemplo"
rows "40" columns "120" geometry "+50+50";
SOURCE text; SINK scrolledwindow;LINK text scrolledwindow;
ENDOBJECT;
MMOBJECT Arquitectura imageTypeWITH FILENAME "arquitec.gif"
WINDOW$NAME "void" // Janela sem nome WINDOW$X "500" WINDOW$Y "150";
SOURCE imageSource; SINK imageSink;LINK imageSource imageSink;
ENDOBJECT;
( omitida a declaração dos objectos de imagem : Terminar,Tocar, Parar, Autor )
124
MMOBJECT Musica audiotypeWITH filename "peanuts.au";SOURCE sound;
ENDOBJECT;
( omitida a declaração do objecto de audio : Audio )
BEHAVIOUR PAR OR SEQ PAR OR // Primeira Página
Introducao; Arquitectura; WHILE (TRUE) DO Musica; Texto?Ev_Click;
END; PAR OR // Segunda Página
Exemplo; WHILE (TRUE) DO SEQ PAR OR Tocar; Tocar?Ev_Click; END; PAR OR Video; Audio; Parar; Parar?Ev_Click; END; END;
Texto?Ev_Click; END; PAR // Terceira Página Fim; Autor; END; END; Terminar; Terminar?Ev_Click; END;ENDSPEC; // Demonstracao
Figura 6.24: Especificação de uma aplicação de apresentação dosistema desenvolvido.
125
ç p ç p
Neste documento, a interacção com o utilizador é feita através dos eventos do tipo
Ev_Click, associados ao premir de um botão do rato sobre uma imagem ou um texto.
Na especificação, são utilizadas operações de recepção destes eventos dentro de
operações PAR OR, de forma a interromper a acção corrente. Por exemplo, a
interrupção da aplicação é feita através da imagem Terminar, que se mantém activa
durante todo o documento. Quando for recebido o evento originado nessa imagem, a
semântica da operação PAR OR provoca a destruição de todos os objectos criados nos
restantes ramos do paralelo, onde se inclui a sequência que contém a aplicação. Para se
terminar a aplicação também se poderia ter utilizado a operação ABORT.
Na aplicação descrita, a página só muda quando o utilizador carrega com o rato
no texto. Caso se pretendesse, também poderia ter sido adicionada uma temporização,
utilizando um objecto de Relógio. Por exemplo, caso se pretendesse parar a
apresentação da terceira página ao fim de 3 segundos poder-se-ia utilizar o código
apresentado na figura 6.25.
MMOBJECT Timeout timerTypeSOURCE timer;INIT <Locator, 0>;FIM <Locator, 3000>; /* 3000 milisegundos */
ENDOBJECT;...
BEHAVIOUR...
PAR OR // Terceira Página Fim; Autor; Timeout; END;
...ENDSPEC
Figura 6.25: Modificação para ter um tempo de apresentação daterceira página.
126
Figura 6.26: Primeira página da aplicação de demonstração.
Figura 6.27: Segunda página da aplicação de demonstração, quandoo vídeo não está a correr.
127
Figura 6.28: Segunda página da aplicação de demonstração, quandoo vídeo está a correr.
Figura 6.29: Terceira página da aplicação de demonstração.
128
Comparando as características do sistema apresentado com as características da
norma MHEG (secção 2.3.4), verifica-se haver um conjunto de conceitos comuns,
embora os dois trabalhos tenham sido definidos para contextos complementares. A
norma MHEG foi definida para a troca de informação multimédia e hipermédia,
enquanto o sistema apresentado nesta dissertação foi definido para a construção de
arquitecturas de desenvolvimento de aplicações multimédia. Embora o MHEG refira a
interacção com os objectos de uma forma geral, não a especifica, sendo a
compatibilidade com a norma definida apenas em relação à capacidade do sistema para
interpretar, e poder gerar objectos de informação multimédia MHEG, para qualquer
aplicação multimédia.
Assim, para o sistema desta tese ser compatível com a norma MHEG, seria
necessário desenvolver um ou dois utilitários que no conjunto funcionassem como uma
máquina MHEG. No conjunto deveria ser suportada a funcionalidade de um formatador
e um analisador MHEG, que fizessem a conversão entre as aplicações e o formato dos
objectos de informação multimédia MHEG.
O maior problema para suportar a conversão das aplicações para objectos de
informação multimédia MHEG, seria em relação aos dados dos objectos multimédia,
pois para poderem ser transferidos, seria necessário que os servidores de componentes
soubessem encapsular os dados que existem nas suas bases de dados em objectos
MHEG de Conteúdo. Em relação às aplicações especificadas em script, elas são
directamente suportadas pelos objectos MHEG Script, que permitem transportar
qualquer formato de script.
Em relação à conversão de objectos de informação multimédia MHEG para
aplicações do sistema, havia novamente um problema em relação aos dados multimédia,
129
, g p
HyTime
Comparando as características do sistema apresentado com as características da
norma HyTime (secção 2.3.3), verifica-se que são utilizadas abordagens bastante
diferentes em relação à representação de aplicações multimédia, ao contrário do que
acontecia em relação à norma MHEG.
No entanto é possível o desenvolvimento de uma máquina HyTime, que interprete
e execute construções desta linguagem, pois os mecanismos de sincronização definidos
no sistema apresentado são suficientemente poderosos para suportar o tipo de
sincronização definido no HyTime. Essa máquina, teria de começar por carregar todo o
documento HyTime, interpretando os vários campos do documento, e correndo um
algoritmo de conversão para uma especificação, onde fosse feita a resolução dos
endereços HyTime, e a geração do código associada às ligações. Tal como no caso
anterior, este código recorreria, na maior parte dos casos, à utilização de eventos. Mas
neste caso, a conversão era mais complexa, pois ao contrário do MHEG, as ligações
HyTime apresentam uma diversidade muito grande de formas.
Os espaços de coordenadas finitos, utilizados no HyTime, são directamente
modeláveis por eventos. Para suportar a apresentação das aplicações, seriam gerados
eventos para todas as posições do espaço de coordenadas onde é necessário activar um
objecto, e onde terminam os intervalos de apresentação dos objectos. Em relação aos
vários valores possíveis do atributo EXTENT RECONCILIATION, que define a
adaptação dos objectos aos intervalos, seria gerado código específico para cada valor.
Por exemplo, para a estratégia de clipping seria utilizada uma composição paralela PAR
OR entre a invocação do objecto e o evento do fim do intervalo.
130
p ç p p (
um filtro).
Como o sistema desta tese é mais poderoso na descrição de interacções entre
objectos, uma conversão para o HyTime teria sempre de ser encarada como uma
fotografia estática de uma dada aplicação no tempo.
Extensões ao ODA
Comparando as características do sistema apresentado com as características da
extensões multimédia à norma ODA (secção 2.3.2) no que diz respeito ao modelo de
sincronização, verifica-se que as extensões ao ODA praticamente realizam um
subconjunto dos operadores, sendo directamente traduzíveis para as especificações de
sincronização na linguagem definida nesta dissertação.
O contrário já não é verdade, pois há especificações no sistema apresentado que
não são traduzíveis. O problema está directamente associado à não existência de um
interface funcional para interagir com os objectos.
WWW
Comparando as características do sistema apresentado com as características do
WWW (secção 2.3.1), verifica-se que o WWW é mais limitado.
As apresentações definidas em WWW são definidas utilizando o HTML, que só
permite representar relações estáticas, não suportando a noção de tempo. Assim, é
possível definir aplicações mais complexas no sistema apresentado, para além das que
são possíveis em HTML, pois no sistema apresentado são suportadas hiperligações. No
entanto, o WWW é um sistema aberto, que tenderá a evoluir para englobar mais
facilidades, nomeadamente com a adopção de um novo formato para representar
documentos, com funcionalidades semelhantes às descritas neste documento.
131
Ao longo do texto já foram apresentadas algumas das limitações do sistema
realizado. Nesta secção vão-se aprofundar algumas dessas limitações, sendo
apresentadas outras que ainda não foram referidas.
Num primeiro grupo, incluem-se aquelas que derivam de opções tomadas durante
o desenvolvimento do sistema. Entre elas, destaca-se a opção de ter uma estrutura
interna estática para os objectos multimédia, e de não se suportar uma sincronização de
baixo nível.
Os objectos multimédia quando arrancam têm internamente um conjunto de
componentes que é fixo e se mantém activo até à destruição do objecto. Esses
componentes são invisíveis para o utilizador e para o autor das aplicações, sendo apenas
visíveis os portos dos objectos, o que permite reconfigurar as ligações de fluxos de
dados entre os componentes. No entanto, existem aplicações onde esta estrutura pode
ser excessivamente rígida, como por exemplo, numa conferência. Caso um novo
participante pretenda entrar na conferência, vai obrigar a modificar a estrutura dos
objectos multimédia que estão activos, pois é necessário criar um componente para
servir o novo participante. A solução para este problema passaria pela definição de
novos estados, que controlassem a activação ou destruição de objectos componentes
dentro do objecto multimédia.
Nesta tese, a sincronização foi definida primordialmente para um nível do
controlo de apresentação de objectos multimédia relativamente elevado. Embora o
mecanismo utilizado seja suficientemente genérico para representar a sincronização de
baixo nível, a sua implementação é, no caso geral, ineficiente. A utilização de um
controlador numa cápsula diferente da dos componentes onde a sincronização tem de
ser feita, introduz um atraso adicional, resultante de ser necessário enviar uma acção de
132
q ç j (Q ),
depois a parametrização do operador paralelo em termos das influências entre os vários
objectos multimédia, para definir as relações entre objectos, que seriam realizadas,
através da interacção directa entre objectos componentes.
Outro conjunto de limitações resultam dos utilitários desenvolvidos, que não
realizam a totalidade das funções desejáveis para suportar integralmente o modelo
definido nesta dissertação.
O interpretador desenvolvido suporta a maior parte dos operadores definidos na
linguagem, no entanto, não suporta variáveis de estado distribuídas, e no que diz
respeito à gestão do interface de estados, a sua funcionalidade ficou aquém do que foi
originalmente pensado.
O facto de não serem suportadas variáveis distribuídas, limitou razoavelmente a
complexidade das aplicações que podem ser utilizadas. Por outro lado, não possibilitou
a sua utilização para resolver alguns problemas dos atrasos variáveis na comunicação. O
princípio seria o de utilizar a função TestAndSet do interface Remctrl que faria,
de uma forma atómica, um teste ao valor da variável, seguida de modificação. Sempre
que se quisesse ter na aplicação uma transição com recepção atómica de mensagens, era
utilizada uma variável distribuída para definir qual seria a transição. Quando o
interpretador recebesse um evento que poderia provocar uma transição, invocava a
operação TestAndSet sobre o interface do interpretador que estava a gerir a variável.
Caso fosse a primeira invocação, definia o próximo estado do sistema, senão, obtinha o
valor do próximo estado, que alguém já tinha definido anteriormente.
Em relação à gestão de interfaces de estados, as limitações decorrem do facto do
interpretador realizado:
i) não aceitar como entrada invocações de acções de estados,
133
defeito, associado à ordem causal entre as várias fases das aplicações, definida pelo
operador SEQ.
O compilador desenvolvido é razoavelmente limitado em termos de utilização
prática, pois o tipo de arquitectura de controlo utilizado não é o mais eficiente para a
grande maioria das aplicações. No entanto, nesta dissertação não se pretendia
desenvolver um compilador que gerasse código eficiente, mas sim desenvolver
algoritmos de compilação genéricos, aplicáveis à geração de máquinas de estados para
controlo distribuído. Esse objectivo foi conseguido, sendo possível utilizar o algoritmo
definido, e eventualmente estendê-lo, para construir máquinas de estados com uma
configuração mista, como a que é preconizada na secção 3.4. A modificação do
compilador para passar a gerar código eficiente, consistiria em agrupar o código
referente a vários objectos no número mínimo de máquinas de estados, e na
optimização do código gerado, que apresenta um excesso de paralelismo, e poderia ser
evitado.
134
melhoramentos e extensões, bem como indicações para investigação futura.
7.1. CONCLUSÕES
Neste trabalho foi apresentado um sistema de desenvolvimento e apresentação de
aplicações multimédia interactivas distribuídas, baseado numa arquitectura de controlo
distribuído.
Construiu-se um modelo de objectos multimédia, onde é utilizada uma visão
simplificada dos objectos componentes, que esconde alguns aspectos da distribuição. As
características dos objectos são representadas utilizando estados, que agregam uma
parcela do estado interno, as acções relacionadas com essa funcionalidade, e os eventos
gerados, associados a modificações nessa parcela do estado interno. Cada objecto
oferece um interface que é composto pelo conjunto de interfaces dos estados que
suporta, permitindo uma definição gradual do interface de cada objecto. O modelo é
fortemente tipificado, sendo mantido num gestor de tipos toda a informação sobre os
tipos existentes no sistema, para permitir que todas as aplicações e ferramentas tenham
conhecimento das possibilidades disponíveis em cada momento, e facilitar a
expansibilidade do sistema. Definiu-se uma linguagem para representar as máquinas de
estados, com a expressividade necessária para suportar uma larga gama de aplicações
multimédia, e construiu-se um interpretador que a suporta. Por fim, definiu-se uma
linguagem de especificação de aplicações multimédia, baseada numa álgebra de
processos, para permitir o desenvolvimento de aplicações tirando partido das
possibilidades do modelo de objectos. Para esta linguagem, descreveu-se um algoritmo
de compilação genérico que permite gerar qualquer arquitectura de controlo, e
135
p ç j p q q p
interacção de controlo sobre os objectos, assim como qualquer forma de interacção com
os utilizadores. Além disso, permite encapsular as dependências do equipamento e a
distribuição interna ao objecto, oferecendo a possibilidade de integração de objectos
computacionais genéricos definidos noutros contextos, com modificações mínimas. Um
sistema de tipos construtivo permite uma fácil evolução das funcionalidades
disponíveis, de uma forma gradual, mantendo-se a compatibilidade com aplicações
definidas anteriormente. Por fim, a linguagem de especificação de aplicações definida, é
suficientemente genérica para representar um conjunto vasto de especificações, desde
aplicações destinadas a serem corridas por um único utilizador, a aplicações complexas
que envolvam a interacção entre diversas aplicações menores, que interagem com
diversos utilizadores.
7.2. TRABALHO FUTURO
Pretendeu-se com o trabalho apresentado nesta tese identificar o conjunto de
problemas relacionados com o suporte de aplicações multimédia em ambientes
distribuídos. Propôs-se um modelo para este tipo de aplicações, e desenvolveu-se um
sistema baseado nesse modelo. No entanto, durante este trabalho muitos outros
problemas se levantaram, podendo ser classificados em evoluções do modelo, que são
propostas para investigação futura, e melhoramentos na implementação do sistema
resultantes da experiência obtida.
Evolução do Modelo e Áreas de Investigação Futura
Objectos multimédia de estrutura dinâmica. Na implementação só se
utilizaram objectos multimédia com topologias de uma fonte e um destino, fixas. Seria
136
q ç j (Q ),
parâmetros relacionados com sincronização de baixo nível. Poder-se-ia também definir
formas de especificar sincronização de baixo nível entre fluxos de dados multimédia
distintos.
Controlo da ordem na recepção de eventos. Na implementação apresentada não
foi considerado o controlo da ordem de recepção de eventos, que pode apresentar
algumas distorções, como se viu na secção 6.1.3. Embora já exista um conjunto de
protocolos que verifica estas condições, eles introduzem uma latência que pode não ser
compatível com as necessidades das aplicações multimédia. Seria interessante o
desenvolvimento de procedimentos para controlar estas distorções, introduzindo um
atraso mínimo.
Controlo de falhas. Na implementação apresentada, não foi realizado um
mecanismo para o controlo de falhas durante a apresentação de aplicações. Seria
interessante o desenvolvimento de um sistema de controlo de falhas a nível de sistema,
que permitisse realizar o modelo de falhas fail-stop, preconizado na apresentação do
modelo.
Inversão do sentido da apresentação e arranque a partir de um ponto
arbitrário. Os interpretadores implementados permitem apenas correr as aplicações no
sentido normal, não sendo possível aos utilizadores fazer recuar a apresentação, ou
mesmo saltar para um ponto arbitrário da apresentação, a menos que essa possibilidade
tenha sido explicitamente prevista no script. A solução destes problemas é complexa
pois exige a extensão do modelo de modo a permitir representar de uma forma não
ambígua, qualquer ponto numa apresentação, utilizando por exemplo, relógios
vectoriais [Schwarz+ 91].
137
ç q p p p p
Editor Gráfico. Para facilitar o desenvolvimento de aplicações, seria desejável o
desenvolvimento de um editor gráfico para a criação de scripts.
MHEG. Tal como é referido na secção 6.6, seria possível desenvolver um
utilitário que forneça a funcionalidade de uma máquina MHEG.
Delegação do estado Contexto dos objectos multimédia num dos componentes.
No caso geral, e principalmente nos objectos onde é utilizado apenas um componente, o
facto de se ter o servidor do estado Contexto a correr na cápsula do servidor de
objectos, implica que é sempre adicionado um atraso adicional na invocação de acções
do interface do estado Contexto do objecto. Tal seria evitado se houvesse uma
delegação deste estado.
Na secção 6.7 são apresentados um conjunto de melhoramentos possíveis em
relação aos interpretadores e em relação ao compilador. Para além destes, seria ainda
possível pensar em outros melhoramentos nas ferramentas gerais do sistema tais como,
por exemplo, a construção de editores de média, para criar ficheiros de especificação de
anotações.
138
[Allen 83] James F. Allen. Maintaining Knoledge About TemporalIntervals. Communications of the ACM, 26(11):832-843,Novembro 1983.
[Altenhofen+ 93] Michael Altenhofen, Jürgen Dittrich, Rainer Hammerschmidt,Thomas Käppner, Carsten Kruschel, Ansgar Kückes, ThomasSteinig. The BERKOM Multimedia Collaboration Service. ACMMultimedia 93, pág. 457-463.
[Anklesaria+ 93] Farhad Anklesaria, Mark McCahill, Paul Lindner, DavidJohnson, Daniel Torrey, Bob Alberti. The Internet GopherProtocol (a distributed document search and retrieval protocol).Internet RFC 1436. Março 1993.
[Ansa 93] ANSAware 4.1. System Programming in ANSAware. Doc.RM.101.02, Fevereiro 1993.
[Arbab+ 93a] F. Arbab, I. Herman, G. J. Reynolds. An Object Model forMultimedia Programming. Computer Graphics Forum(Eurographics '93 Conference Issue), 12(3), September 1993.
[Arbab+ 93b] F. Arbab, P. J. W. ten Hagen, M. Haindl, F. C. Heeman, I.Herman, G. J. Reynolds, A. Siebes. Specification of the MADEObject Model. CWI, Documento Interno, 1993.
[Birrel+ 84] A. Birrel and B. Nelson. Implementing Remote Procedure Calls.ACM Transactions on Computer Systems, 2(1):39-59, Fevereiro1984.
139
Milouscheva, Jochen Sandvoss. The BERKOM MultiMediaTransport System. BERKOM Technical Report, Outubro 1992.
[Campbell+ 74] R. H. Campbell, A. N. Habermann. The Specification of ProcessSynchronisation by Path Expressions. Em Lecture Notes inComputer Science número 16, Operating Systems, pelos editoresG. Goos e J. Hartmanis, pág. 89-102. Springer-Verlag, 1974.
[Cardelli+ 85] Luca Cardelli, Rob Pike. Squeak: a Language forCommunicating with Mice. ACM Computer Graphics,19(3):199-204, 1985.
[CCITT 88] CCITT Recommendation X.501 (ISO/IEC JTC1/SC21 ISO9594-2). The Directory Models. Março 1988.
[CIP 90] CIP Working Group, Editor: C. Topolcic. Experimental InternetStream Protocol: Version 2 (ST-II). Internet RFC 1190, SRINetwork Information Center. Outubro
[Correia+ 93] Nuno Correia, Vasco L. Paulo, Nuno Guimarães. Specificationof the MADE Time Objects. INESC, 1993.
[Eun 93] Seong Bae Eun, Eun Suk No, Hyung Chul Kim, HyunwsooYoon, Seung Ryoul Maeng. Specification of MultimediaComposition and a Visual Programming Environment. ACMMultimedia 93, 167-173.
[Gallety 90] John Gallety. Occam 2. Pitman Publishing, 1990.
[Gettys+ 87] Jim Gettys, Ron Newman, Robert W. Scheiffer. Xlib - CLanguage X Interface. X Window System, X Version 11,Release 2, Setembro 1987.
140
[Herman+ 93] Ivan Herman, Graham J. Reynolds. MADE: A MultimediaApplication Development Environment. IEEE computerSociety's International Conference on Multimedia Computingand Systems (ICMCS 94), 1994.
[Hoare 85] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985
[Hoepner 91] Petra Hoepner. Synchronizing the Presentation of MultimediaObjects - ODA Extensions. SIGOIS Bulletin, páginas 19-32,Julho 1991.
[Isis 92] The Isis Distributed Toolkit Version 3.0. User ReferenceManual. 1992.
[ISO 86] ISO 8879: Information Processing - Text and Office Systems -Standard Generalized Markup Language, 1986.
[ISO 87] ISO 8807. Information Processing Systems - Open SystemsInterconnection: LOTOS - A Formal Description TechniqueBased on the Temporal Ordering of Observational Behaviour,1987.
[ISO 89] ISO 8613: Information Processing - Text and Office Systems -Office Document Architecture (ODA) and Interchange Format,1989.
[ISO 11172] ISO 11172: Information technology - Coding of MovingPictures and Associated Audio for Digital Storage Media up toabout 1.5 Mbit/s (MPEG).
141
[ISO 93c] ISO/IEC/JTC1/SC18/WG8. SMSL Working DocumentSC29WG12.147. Abril 1993.
[Karjoth 88] Günter Karjoth. Implementing Process Algebra Specificationsby State Machines. Eighth International Symposium on ProtocolSpecification, Testing and Verification, Atlantic City, NewJersey, Junho 1988.
[Kretz 90] Francis Kretz. RAVI for the exchange of Audio VisualInteractive Scriptware. L'Echo des Recherches, 1990.
[Lamport+ 90] Leslie Lamport, Nancy Lynch. Distributed Computing: Modelsand Methods. Handbook of Theoretical Computer Science, pág.1159-1199. Elsevier Science Publishers,1990.
[Lauer+ 75] P. Lauer and R. Campbell. A description of path expressions bypetri nets. In Conf. Record 2nd ACM Symposium on Principlesof Programming Languages, pages 95-105, 1975.
[Lee+ 93] Tim Berners-Lee, Robert Cailliau, Nicola Pellow, Arthur Secret.The World-Wide Web Initiative. Proceedings INET'93.
[Levergood+ 93] Thomas M. Levergood, Andrew C. Payne, James Gettys, G.Winfield Treese, e Lawrence C. Stewart. AudioFile: ANetwork-Transparent System for Distributed AudioApplications. Proceedings of the USENIX Summer Conference,Junho 1993.
[Little+ 90a] Thomas D. C. Little and Arif Ghafoor. Synchronization andStorage Models for Multimedia Objects. IEEE Journal onSelected Areas in Communications, 8(3):413-427, April 1990.
142
IEEE Journal on Selected Areas in Communications, 9(9):1368-1382, December 1991.
[McCormack+ 91]Joel McCormack, Paul Asente, Ralph R. Swick. X ToolkitIntrisics - C Language Interface. X Window System, X Version11, Release 5, Agosto 1991.
[Mey+ 92] Vicki de Mey, Christian Breiteneder, Laurent Dami, SimonGibbs and Dennis Tsichritzis. Visual Composition andMultimedia. Proceedings Eurographics '92.
[Mey+ 93] Vicki de Mey and Simon Gibbs. A Multimedia Component Kit.ACM Multimedia 93, 291-300.
[Milner 89] Robin Milner. Communication and Concurrency. ComputerScience. Prentice-Hall, 1989.
[Newcomb+ 91] Steven R. Newcomb, Neil A. Kipp, and Victoria T. Newcomb.The HyTime: Hypermedia/Time-based Document StructuringLanguage. Communications of the ACM, 34(11):67-83,November 1991.
[Newcomb 93] Steven R. Newcomb. Multimedia Interchange Using SGML:The ISO "HyTime" Standard. SIGGRAPH 93, (V) 111- 141,August 1993.
[Obraczka+ 93] Katia Obraczka, Peter B. Danzig, Shih-Hao Li. InternetResource Discovery Services. IEEE Computer Magazine, pág.8-22, Setembro 1993.
143
[OSF 93] Open Software Foundation. OSF DCE Application DevelopmentReference, Revision 1.0. Prentice Hall, Inc, 1993.
[Patel+ 93] Ketan Patel, Brian C. Smith, and Lawrence A. Rowe.Performance of a Software MPEG Video Decoder. ACMMultimedia 93, 75-82.
[Pereira 94] Paulo Rogério Barreiros d'Almeida Pereira. Um Modelo para oDesenvolvimento de Aplicações Multimédia InteractivasDistribuídas. Dissertação de Mestrado, Instituto SuperiorTécnico, Lisboa, Portugal, Junho de 1994.
[Pinto 92] Paulo F. Pinto. Interface Definitions for Multimedia Interfaces.Palantir Internal Report n.092, University of Kent atCanterbury, October 1992.
[Pinto 93] Paulo F. Pinto. An Interaction Model for MultimediaComposition. PhD thesis, University of Kent at Canterbury,1993.
[Pinto+ 93b] Paulo F. Pinto, Peter F. Linington. A Language for theSpecification of Interactive and Distributed MultimediaApplications. Int. Conf. on Open Distributed Processing 1993,pág. 217-234.
[Pinto+ 94] Paulo Pinto, Luís Bernardo, Paulo Pereira. A ConstructiveType Schema for Distributed Multimedia Applications.Proceedings BRIS'94, pág. 419-434.
[Prabhakaran+93]B. Prabhakaran and S. V. Raghavan. Synchronization ModelsFor Multimedia Presentation With User Participation. ACMMultimedia 93, 157-166.
144
[Rose 90] Marshall T. Rose. The Open Book, a Practical Perspective onOSI. Prentice-Hall, 1990.
[Schreiner+ 85] Axel T. Schreiner, H. George Friedman. Introduction toCompiler Construction with UNIX. Prentice-Hall, Inc, 1985.
[Schwarz+ 91] Reinhard Schwarz, Friedemann Mattern. Detecting CausalRelationships in Distributed Computations: In Search of theHoly Grail. Lisboa 92: An Advanced Course on DistributedSystems, Junho 1993.
[Sousa+ 91] Paulo Sousa, Paulo Ferreira, José Monge, André Zúquete,Manuel Sequeira, Paulo Guedes, and José Alves Marques. IKImplementation Report. Technical Report, INESC-TR-0012,1991.
[Stefani+ 92] Jean-Bernard Stefani, Laurent Hazard and François Horn.Computational model for distributed multimedia applicationsbased on a synchronous programming language. ComputerCommunications, 15(2):114-128, Março 1992.
[Steinmetz 90] Ralf. Steinmetz. Synchronization Properties in MultimediaSystems. IEEE Journal on Selected Areas in Communications,8(3):401-412, Abril 1990.
[SUN 88] SUN Microsystems. Programming Utilities and Libraries.Revision A of 9 May 1988.
[XTP 92] XTP Protocol Definition 3.6. Protocol Engines Incorporated,Janeiro 1992.