Rogério Ferreira Rodrigues Formatação e Controle de

Transcrição

Rogério Ferreira Rodrigues
Formatação e Controle de
Apresentações Hipermídia com
Mecanismos de Adaptação Temporal
TESE DE DOUTORADO
DEPARTAMENTO DE INFORMÁTICA
Programa de Pós-Graduação em Informática
Rio de Janeiro
Março de 2003
Formatação e Controle de Apresentações Hipermídia
com Mecanismos de Adaptação Temporal
Tese de Doutorado
Tese apresentada ao Programa de Pós-graduação
em Informática do Departamento de Informática da
PUC-Rio como parte dos requisitos parciais para
obtenção do título de Doutor em Informática.
Orientador: Prof. Luiz Fernando Gomes Soares
Rio de Janeiro
março de 2003
Formatação e Controle de Apresentações Hipermídia
com Mecanismos de Adaptação Temporal
Tese apresentada ao Programa de Pós-graduação
em Informática do Departamento de Informática da
PUC-Rio como parte dos requisitos parciais para
obtenção do título de Doutor em Informática.
Aprovada pela Comissão Examinadora abaixo
assinada.
Prof. Luiz Fernando Gomes Soares
Orientador
Departamento de Informática – PUC-Rio
Prof. Edward Hermann Haeusler
Prof. Marco Antonio Casanova
Prof. César Augusto Camillo Teixeira
Faculdades COC
Prof. Philippe Mahey
ISIMA – Universidade Blaise Pascal
Prof. Ney Dumont
Coordenador Setorial do Centro
Técnico e Científico – PUC-Rio
Rio de Janeiro, 27 de março de 2003
Todos os direitos reservados. É proibida a reprodução total ou
parcial do trabalho sem autorização da universidade, do autor e
do orientador.
Graduou-se em Engenharia de Computação na PUC-Rio
(Pontifícia Universidade Católica do Rio de Janeiro) em 1994.
Obteve em 1997 o Mestrado em Informática pela mesma
Universidade. Tem atuado, desde 1995, como pesquisador do
Laboratório TeleMídia, do Departamento de Informática da
PUC-Rio, sendo também professor do curso de Especialização
em Redes de Computadores, dessa mesma instituição. Ministrou
cursos em empresas como Embratel e Petrobrás e em
instituições como a Fundação Getúlio Vargas. Tem também
trabalhado na validação de terminologia de traduções dos livros
técnicos em informática da editora Campus.
Ficha Catalográfica
Rodrigues, Rogério Ferreira
Como faço para solicitar a elaboração da ficha catalográfica da
minha tese?
Além de fornecer cópia em papel ou arquivo com a folha de
rosto da publicação, o autor deverá informar:
- número total de páginas preliminares (pré-textuais);
- número total de páginas textuais e pós-textuais;
- número de volumes, quando mais de um;
- dimensão (altura) da publicação;
- se contém ilustrações e referências bibliográficas;
- palavras-chave atribuídas pelo autor; e
- e-mail ou um disquete para o envio do arquivo com a ficha
catalográfica.
Os dados podem ser enviados por e-mail - [email protected]
- ou entregues em qualquer Biblioteca do Sistema de
Bibliotecas da PUC-Rio.
A Divisão de Bibliotecas e Documentação elabora fichas
catalográficas de teses, dissertações, monografias e outras
publicações da PUC-Rio
Este trabalho é dedicado
À Paula, grande amor da minha vida.
A toda minha amada família, em
especial meus pais, Vera e Gerson, e
minha irmã Mariana.
Agradecimentos
Agradeço, em primeiro lugar, ao meu orientador, professor Luiz Fernando
Gomes Soares, por todos os seus ensinamentos, que vão muito além do trabalho
contido neste documento. Sua seriedade e ao mesmo tempo bom humor,
criatividade, dedicação e paixão pela pesquisa, e principalmente pelo ensino,
marcaram a minha formação. Serei eternamente grato por toda confiança
depositada em meu trabalho e todas as oportunidades oferecidas.
Agradeço também ao grande amigo Luiz Fernando Gomes Soares. Foi uma
felicidade encontrar esse parceiro de samba, craque de bola, sempre companheiro
e mais recentemente querido padrinho.
A toda minha família pelo amor, carinho, união e apoio incondicional.
Coloco aqui um agradecimento especial aos meus avós Rosinha, Guilherme (in
memorian), Zoé e Biel. Agradeço também à minha mais nova família Lourdinha,
Paulo, Cynthia e Grude.
Aos meus amigos, quase irmãos, Dadá, Guinle, Lu, Ricardo, Silvia, Sérgio,
Van e querida prima Carmen.
Aos amigos do Laboratório TeleMídia, em particular, Débora, Sérgio, Guido
e Tadeu. Além da amizade, estiveram sempre dispostos a cooperar e contribuir
com este trabalho. Preciso também agradecer aos telemidianos Leandro, Heron,
Marcel, Juliana e Cláudia, cujas pesquisas contribuíram diretamente na
concretização desta tese. A todos que trabalham ou trabalharam no laboratório,
formando esse ambiente e espírito muito especiais: “The Tele never sleeps” e
“Nascemu tamo pronto pra morrê”!
Aos membros da banca pelos preciosos comentários e revisões.
Agradeço a todos os professores e funcionários do Departamento de
Informática da PUC-Rio pelo excelente exemplo profissional e ajuda na realização
desta tese.
Por fim, gostaria de agradecer ao CNPq, à CAPES, à Finep e à PUC-Rio
pelo apoio financeiro fornecido ao longo deste doutorado.
Resumo
Rodrigues, Rogério Ferreira; Soares, Luiz Fernando Gomes. Formatação e
controle de apresentações hipermídia com mecanismos de adaptação
temporal. Rio de Janeiro, 2003. 156p. Tese de Doutorado – Departamento
de Informática, Pontifícia Universidade Católica do Rio de Janeiro.
A construção de sistemas hipermídia/multimídia requer a implementação de
um elemento responsável por receber a especificação de um hiperdocumento (sua
estrutura, seus relacionamentos e a descrição da forma de exibição desejada) e
concretizá-la na apresentação propriamente dita, sendo esse módulo de controle de
execução comumente denominado formatador hipermídia. O objetivo desta tese é
discutir os aspectos referentes ao projeto e desenvolvimento de formatadores
hipermídia, propondo um modelo de execução de hiperdocumentos e uma
estrutura genérica (framework) capaz de ser reutilizada na implementação de
sistemas hipermídia. Em particular, o trabalho aborda as questões referentes à
adaptação dos documentos antes e durante as suas apresentações, às estratégias de
antecipação das ações de exibição (mecanismos de pré-busca), aos mecanismos de
integração com os exibidores de mídia e aos mecanismos de integração com a
infra-estrutura de exibição (em especial, sistema operacional e rede). A proposta
apresentada segue uma especificação orientada a objetos, definindo uma
arquitetura
para
sincronização
temporal
e
espacial
na
exibição
de
hiperdocumentos, que pode ser utilizada também em outros domínios de aplicação
que necessitem de sincronização em tempo real.
Palavras-chave
Hipermídia;
multimídia;
formatadores
hipermídia;
framework
para
formatadores hipermídia; sistema HyperProp; modelo de contextos aninhados;
NCM; sincronização temporal e espacial.
Abstract
Rodrigues, Rogério Ferreira; Soares, Luiz Fernando Gomes. Formatting
and controlling hypermedia presentations with temporal adaptation
mechanisms. Rio de Janeiro, 2003. 156p. DSc Thesis – Departamento de
Informática, Pontifícia Universidade Católica do Rio de Janeiro.
The
development
of
hypermedia/multimedia
systems
requires
the
implementation of an element responsible for receiving the specification of a
hyperdocument (structure, relations and presentation descriptions) and controlling
the presentation. This execution control module is commonly known as
hypermedia formatter. The goal of this thesis is to discuss the aspects related to
the design and implementation of hypermedia formatters, proposing a
hyperdocument execution model and a framework to be reused in the
implementation of hypermedia systems. In particular, this work deals with
document adaptation issues, both before document presentation and on-the-fly,
prefetching mechanisms, integration with presentation tools, and integration with
the infrastructure (in special, operating system and network). The proposal
presented follows an object-oriented specification approach, defining an
architecture for temporal and spatial synchronization in hyperdocument
presentations. The proposal can also be used in other application domains that
need real-time synchronization.
Keywords
Hypermedia; multimedia; hypermedia formatter; hypermedia formatter
framework; HyperProp system; nested context model; NCM; spatial and temporal
synchronization.
Sumário
1
Introdução .......................................................................................... 1
1.1
Motivação....................................................................................... 1
1.2
Objetivos ........................................................................................ 8
1.3
Organização da tese.................................................................... 10
2
Modelos de Documentos Hipermídia com Recursos de Adaptação11
2.1
Adaptação em sistemas hipermídia............................................. 12
2.1.1
Documentos hipermídia .................................................... 12
2.1.2
Elementos que influenciam a adaptação dos
hiperdocumentos ............................................................................. 19
2.1.3
Local e momento da adaptação........................................ 21
2.2
Requisitos para modelos de documentos hipermídia .................. 22
2.3
Modelo de documentos para controle da execução .................... 27
2.3.1
Objetos de execução ........................................................ 28
2.3.2
Elos ................................................................................... 43
2.3.3
Suporte à adaptação no modelo de execução.................. 52
2.3.4
Agrupamentos de objetos de execução e
relacionamentos .............................................................................. 57
3
Formatadores e Ferramentas de Exibição Hipermídia ..................... 59
3.1
Estrutura básica de um formatador hipermídia............................ 60
3.2
Diagrama de classes genérico para o desenvolvimento de
formatadores hipermídia......................................................................... 67
3.3
Integração entre ferramentas de exibição e formatadores
hipermídia............................................................................................... 70
3.3.1
Interface entre formatadores e ferramentas de exibição .. 73
4 Pré-busca, Orquestração Intra-Mídia e Adaptação de Apresentações
Hipermídia ............................................................................................... 77
4.1
Pré-busca em apresentações hipermídia .................................... 77
4.1.1
Arquitetura para implementação de mecanismos
de pré-busca.................................................................................... 83
4.2
Orquestração intra-mídia em apresentações hipermídia ............. 86
4.2.1
Arquitetura para implementação da orquestração
intra-mídia........................................................................................ 95
4.3
Mecanismos de adaptação .......................................................... 97
4.3.1
Ajuste dos tempos elásticos.............................................. 99
4.3.2
Arquitetura para implementação de mecanismos de
adaptação...................................................................................... 102
5
Formatador HyperProp................................................................... 104
5.1
Conversor NCM ......................................................................... 104
5.1.1
Suporte à apresentação de documentos descritos em outros
modelos de autoria ........................................................................ 112
5.2
Compilador e executor do orquestrador de apresentação do
formatador HyperProp .......................................................................... 113
5.3
Integração entre as ferramentas de exibição e o formatador .... 116
5.3.1
Monitorando os tempos dos eventos de apresentação... 123
5.4
Mecanismo de pré-busca........................................................... 127
5.5
Ajuste dos tempos elásticos e escolha das alternativas ............ 128
6
Trabalhos Relacionados................................................................. 131
6.1
Formatadores multimídia/hipermídia ......................................... 131
6.2
Integração entre formatadores e ferramentas de exibição ........ 135
6.3
Mecanismos de pré-busca......................................................... 137
6.4
Mecanismos de adaptação ........................................................ 139
7
Conclusões..................................................................................... 142
8
Referências .................................................................................... 147
Lista de Figuras
Figura 1 – Visão geral dos elementos envolvidos em um sistema
hipermídia................................................................................................. 2
Figura 2 – Relações de Allen................................................................... 23
Figura 3 – Modelos das informações fornecidas a um formatador
hipermídia para controle da execução dos hiperdocumentos. ................ 26
Figura 4 – Diagrama de classes para os objetos de execução. .............. 28
Figura 5 – Diagrama de classes para os objetos de dados..................... 29
Figura 6 – Diagrama de classes para os descritores............................... 32
Figura 7 – Diagrama de classes para os eventos. .................................. 37
Figura 8 – Máquinas de estados dos eventos. ........................................ 42
Figura 9 – Diagrama de classes simplificado para os elos...................... 44
Figura 10 – Diagrama de classes para o elo causal................................ 45
Figura 11 – Diagrama de classes para as regras de exibição................. 52
Figura 12 – Diagrama de classes para as alternativas de objetos de
execução. ............................................................................................... 55
Figura 13 – Alternativas de objetos, pontos de interface e elos. ............. 56
Figura 14 – Suporte à adaptação de relações no modelo....................... 57
Figura 15 – Diagrama de classes para o contêiner. ................................ 57
Figura 16 – Principais elementos que compõem um formatador
hipermídia............................................................................................... 61
Figura 17 – Diagrama de classes para o desenvolvimento de
formatadores. ......................................................................................... 68
Figura 18 – Interface para integração de ferramentas de exibição e
formatadores, prevendo a utilização de adaptadores para integração com
exibidores cuja interface difere da esperada pelo formatador................. 72
Figura 19 – Fórmula geral para o cálculo do tempo de preparação de um
objeto de execução. ................................................................................ 80
Figura 20 – Diagrama de classes para implementação de mecanismos de
pré-busca em documentos hipermídia. ................................................... 84
Figura 21 – Visão simplificada da exibição de conteúdos de documentos
hipermídia representada através do modelo de
composição de serviços. ........................................................................ 88
Figura 22 – Exibição de conteúdos armazenados localmente, eliminando
a figura do provedor de infra-estrutura. ................................................... 90
Figura 23 – Ilustração dos conceitos de serviço e meta-serviço nos
ambientes de execução hipermídia. ........................................................ 91
orquestração intra-mídia.......................................................................... 96
Figura 25 – Classes de duração no modelo de execução....................... 99
Figura 26 – Exemplos de funções de custo. a) Função de custo simples.
b) Função de custo simples, porém discreta. c) Função de custo linear do
tipo piece-wise com dois segmentos. d) Função de custo linear do tipo
piece-wise com múltiplos segmentos. ................................................... 100
adaptação.............................................................................................. 103
Figura 28 – Exemplo de documento estruturado em composições....... 105
Figura 29 – Diagrama de classes das ferramentas de exibição. ........... 116
Figura 30 – Ferramenta de exibição de texto no formato HTML. .......... 118
Figura 31 – Ferramenta de exibição integrada a exibidores JMF.......... 119
Figura 32 – Máquina de estados de um exibidor JMF........................... 120
Lista de Tabelas
Tabela 1 – Sincronização temporal através de elos causais................... 49
Tabela 2 – Sincronização temporal através de elos causais, a partir de
uma especificação de sincronização utilizando composições. ................ 50
Tabela 3 – Sincronização espacial e temporal através de elo causal. .... 50
Tabela 4 – Interface que deve ser oferecida por toda ferramenta de
exibição. ................................................................................................. 74
Tabela 5 – Mapeamento entre ações solicitadas pelo formatador e os
métodos invocados no exibidor JMF. .................................................... 121
Tabela 6 – Mapeamento entre notificações do exibidor JMF e transições
de estado do evento de apresentação .................................................. 122
Tabela 7 – Regras para habilitação dos eventos de apresentação....... 125
Introdução
1
1
Introdução
Sistemas hipermídia têm se tornado cada vez mais comuns no dia-a-dia de
um grande número de pessoas, sendo a WWW (World-Wide Web) (Berners-Lee
et al., 1994a) a principal responsável pela popularização desse paradigma de
estruturação das informações. No entanto, diversos aspectos no projeto e
desenvolvimento de sistemas hipermídia permanecem como tópicos em aberto,
motivando inúmeros trabalhos de pesquisa.
Este capítulo inicialmente descreve, de uma forma genérica, os principais
ambientes que compõem as arquiteturas dos sistemas hipermídia, a fim de motivar
este trabalho e situar o contexto no qual ele se insere. Em seguida são destacados
os objetivos desta tese e é descrita a estrutura deste documento.
1.1
Motivação
Como ponto de partida, é possível salientar três ambientes como formando a
base principal do suporte ao tratamento de documentos hipermídia: o ambiente de
autoria, o ambiente de armazenamento e o ambiente de execução. A Figura 1
ilustra os componentes básicos desses ambientes e os relacionamentos entre eles.
O ambiente de autoria hipermídia deve oferecer os recursos para que os
usuários, no caso os autores, editem os hiperdocumentos, especificando, por
exemplo, os seus componentes, as propriedades desses componentes, os
relacionamentos
internos
existentes
no
documento
e,
possivelmente,
relacionamentos externos, isto é, com componentes pertencentes a outros
documentos. Mais ainda, é importante que no ambiente de autoria o autor tenha
ferramentas que permitam especificar as características de exibição para cada um
dos componentes.
Durante a edição, é interessante que o usuário possa usufruir de visões
distintas em função do contexto de autoria mais relevante. Por exemplo, em um
Introdução
2
dado momento da edição, pode ser mais útil trabalhar com uma visão estrutural
dos componentes. Em outras circunstâncias, é possível que seja mais apropriado
possuir uma visão temporal, mais próxima do formato final de apresentação do
documento. Descrições das relações espaciais, da organização de um trabalho
cooperativo e das relações de versionamento podem também justificar a existência
de outras visões. É importante observar que essas visões não precisam, e muitas
vezes não devem, funcionar isoladamente. Na maioria dos casos, as diferentes
visões podem ser consideradas como dimensões que se complementam na
constituição do documento hipermídia (Jourdan et al., 1998b; Muchaluat-Saade et
al., 1997).
Usuários
(“Leitores”)
Execução
Ferramentas
de
Exibição
Dispositivos
Autoria
Ambiente Gráfico
Edição
gráfica
Usuários
(“Autores”)
<xml>
<tag>
Edição
content...
declarativa
</tag>
</xml>
Provedor de Serviços de
Comunicação
Armazenamento
Formatador
Controle
de Versões
Suporte ao
Trabalho
Cooperativo
Adaptação
Servidores
de conteúdo
Servidores
de estruturas
Figura 1 – Visão geral dos elementos envolvidos em um sistema hipermídia.
Duas abordagens têm sido usuais nos ambientes de autoria hipermídia,
relacionadas à forma como a interface de especificação dos documentos é
oferecida aos autores. Diversos sistemas dispõem de editores gráficos com o
intuito de tornar a tarefa de especificação mais simples e natural. Nesse sentido,
podem ser citados os ambientes de autoria dos sistemas Firefly (Buchanan &
Zellweger, 1992), HyperProp (Soares et al., 2000) e Madeus (Jourdan et al.,
1998a) e os editores CMIFed (van Rossum et al., 1993) e GRiNS (Oratrix, 2002).
Introdução
3
No entanto, a WWW também popularizou o paradigma de especificação de
documentos através de linguagens estruturadas e declarativas, primeiro com a
linguagem HTML (W3C, 1999c) e posteriormente com a metalinguagem XML
(W3C, 2000). Essa abordagem traz como importante benefício o fato de não haver
necessidade do autor utilizar um software particular para autoria ou visualização
da especificação, podendo ser utilizado um editor de texto genérico. No entanto,
dependendo da complexidade da linguagem e do próprio documento, a tarefa do
autor pode se tornar árdua e ineficiente. Diversos editores de texto específicos
para linguagens declarativas trabalham nesse nível, oferecendo algumas
facilidades para que o processo de autoria se torne menos penoso, como são os
casos dos editores HomeSite (HomeSite, 2001), Arachnophilia (Lutus, 2002) e
SMILGen (SMILGen, 2002).
O fato de existirem essas duas abordagens não implica que as mesmas sejam
mutuamente excludentes; na realidade, elas se complementam. XML tem se
mostrado uma forma simples e adequada para auxiliar na descrição estruturada de
documentos. O seu formato textual pode não ser o mais eficiente, mas tem se
revelado uma maneira apropriada de representar os documentos hipermídia,
facilitando, principalmente, o intercâmbio desses documentos com os outros
ambientes de um mesmo sistema, ou mesmo entre sistemas heterogêneos. No
entanto, conforme discutido anteriormente, a complexidade de uma linguagem de
autoria, ou mesmo de um documento, pode tornar a edição puramente textual
inapropriada. Desse modo, é adequado conceber um ambiente de autoria onde haja
facilidades gráficas para a edição, mas também exista uma representação
estruturada e textual para os documentos sendo elaborados, podendo ser feita a
passagem de uma abordagem de autoria para a outra em qualquer momento. Essa
tem sido a prática adotada em alguns sistemas de autoria hipermídia (Oratrix,
2002; Jourdan et al. 1998a; Soares et al., 2000).
Retornando à divisão dos sistemas hipermídia nos três ambientes
inicialmente apresentados, o próximo a ser comentado é o ambiente de
armazenamento. A esse ambiente cabe oferecer os mecanismos para gravar,
recuperar e até mesmo adaptar os documentos. Nos sistemas hipermídia
distribuídos que seguem uma arquitetura cliente/servidor, como é o caso da grande
Introdução
4
maioria dos sistemas, o ambiente de armazenamento pode ser visto como
constituindo-se no próprio servidor hipermídia.
É possível separar o armazenamento em duas classes, que apresentam
requisitos distintos e podem operar de maneira independente: o armazenamento da
descrição dos documentos (contendo informações a respeito da estrutura,
possivelmente dos relacionamentos entre os componentes e das especificações de
apresentação) e o armazenamento do conteúdo dos objetos de mídia (arquivos de
texto, imagem, áudio, vídeo etc.). Para o armazenamento das descrições dos
documentos, é interessante que o ambiente disponha de mecanismos de controle
de versão, de controle de acesso e de métodos para organizar o trabalho
cooperativo de um conjunto de autores. É também útil que o ambiente permita que
sejam recuperadas apenas partes de um documento, sem que isso obrigue a
recuperação de um documento inteiro. Com relação ao armazenamento dos
conteúdos dos componentes de um documento, é desejável, além da existência de
mecanismos de controle de versão de conteúdo, que o serviço de entrega dos
dados seja capaz de estabelecer e manter acordos de qualidade de serviço (QoS),
principalmente para a entrega de conteúdos não convencionais, como os de
objetos de áudio e vídeo.
Outra funcionalidade desejável em ambientes de armazenamento e que
merece destaque é a capacidade de adaptar os hiperdocumentos (estrutura,
apresentação ou o próprio conteúdo dos objetos) antes de entregá-los. Essa
adaptação pode levar em consideração as características da plataforma no lado do
ambiente de armazenamento (capacidade de processamento disponível, banda
passante disponível para o acesso aos recursos gravados em memória secundária,
número de clientes conectados, banda passante para transmissão dos dados no
sistema de comunicação etc.) e também as informações provenientes do próprio
ambiente de execução (preferências e conhecimento prévio do usuário, recursos de
hardware disponíveis na plataforma de exibição, localização etc.). Todas essas
informações fazem parte do contexto de apresentação do documento (Boll & Klas,
1999; Brusilovsky, 1996; Dey et al., 2001; Schilit et al., 1994; Villard et al.,
2000). O principal objetivo da adaptação localizada no ambiente de
armazenamento é que o mesmo forneça os conteúdos (ou mesmo o documento
como um todo) com configurações que melhor atendam ao contexto em que eles
Introdução
5
venham a ser exibidos, buscando ao mesmo tempo otimizar a utilização dos
recursos que estejam situados no servidor (ambiente de armazenamento), no
caminho até o cliente hipermídia (provedor de serviços de comunicação) e no
próprio cliente (ambiente de execução). Idealmente, ao invés de prover uma única
configuração rígida, o ambiente de armazenamento deve também ser capaz de
fornecer os dados (conteúdos, descrição do documento etc.) com configurações
flexíveis, permitindo que também o cliente tenha condições de aplicar
transformações no documento, a fim de adequá-lo à sua visão do contexto de
apresentação.
Independente do tipo de dado sendo armazenado (descrição ou conteúdo de
objetos), o ambiente não deve ser restrito a um único local de gravação. É
extremamente útil que o armazenamento seja distribuído em vários servidores e o
ambiente ofereça recursos de cache, replicação, migração etc. É também desejável
que a exata localização de um objeto seja transparente para os usuários das
funcionalidades de persistência. Evidentemente, o oferecimento desses recursos e
dessa transparência, preservando a escalabilidade do sistema, acarreta uma série
de dificuldades para a manutenção da consistência dos dados.
O terceiro e último ambiente a ser comentado e que se constitui no foco
desta tese é o ambiente de execução dos documentos, também conhecido como
ambiente de apresentação. Esse ambiente normalmente encontra-se situado junto
ao cliente hipermídia e deve conter os mecanismos para interagir com os usuários,
no caso os leitores dos documentos, e controlar a exibição dos objetos (textos,
imagens, vídeos, áudios etc.) de tal forma que as intenções especificadas pelos
autores sejam respeitadas. Entre os elementos que compõem o ambiente de
execução podem ser destacados: as ferramentas de exibição e o formatador
hipermídia.
As ferramentas de exibição correspondem aos módulos de software, ou
mesmo de hardware, responsáveis por lidar com os dispositivos de entrada e saída
e controlar a exibição do conteúdo dos objetos, cuidando, por exemplo, de
questões de descompressão, tratamento de interações do usuário, controle da taxa
de exibição para o caso de objetos de mídia contínua etc.
O formatador hipermídia é o nome dado ao elemento que reúne as funções
para o controle propriamente dito da apresentação. O termo formatador hipermídia
Introdução
6
(ou simplesmente formatador) (Buchanan & Zellweger, 1993a; Rodrigues et al.,
1997; Soares et al., 2000; Villard et al., 2000) costuma ser empregado numa
analogia aos formatadores de texto1. Da mesma forma que os formatadores
textuais retiram do autor a carga de manualmente posicionar os elementos na
forma final desejada, os formatadores hipermídia idealmente efetuam um ajuste
automático da apresentação, a fim de simplificar o processo de autoria e a sua
manutenção. No entanto, a presença de objetos de mídia contínua e de
relacionamentos de sincronização temporal e espacial tornam as tarefas do
formatador hipermídia complexas de serem desempenhadas.
Em primeiro lugar, é importante que o formatador hipermídia e as
ferramentas de exibição apresentem uma forte integração, com uma interface bem
definida para a troca das mensagens, pois são essas ferramentas que decodificam
os conteúdos e são capazes de perceber o ponto exato em que a exibição de um
determinado objeto se encontra para informá-lo ao formatador. Além disso, o
usuário interage diretamente com as ferramentas de exibição e não com o
formatador, cabendo a elas repassar as informações a respeito dessas interações.
Por outro lado, o formatador deve poder enviar comandos às ferramentas para que,
por exemplo, a taxa de apresentação de um objeto seja modificada a fim de
recuperar a sincronização do documento.
Muitas vezes, a fim de manter consistente a apresentação, o formatador
precisará ajustar o hiperdocumento (estrutura ou a forma de apresentação), ou
mesmo requisitar que as ferramentas ajustem a exibição de cada conteúdo. Esses
ajustes podem ser necessários por causa da flexibilidade na descrição dos
documentos oferecida nos ambientes de autoria e de armazenamento; pela própria
navegação do usuário, gerando eventos que não puderam ser previstos antes de
iniciar a exibição do documento; por atrasos, também impossíveis de serem
previstos no sistema operacional e na rede; ou por quaisquer outras informações
provenientes do contexto de exibição (recursos de hardware disponíveis na
máquina do cliente, preferências e perfil do usuário etc.). Sendo assim, de maneira
similar ao que foi especificado para o ambiente de armazenamento, também no
ambiente de execução devem existir mecanismos de adaptação, que levem em
Player e engine são outros dois termos também comuns de serem encontrados na literatura como
denominação do elemento responsável por controlar a exibição de documentos hipermídia.
1
Introdução
7
conta as flexibilidades na especificação do documento e as características da
plataforma de exibição e do usuário.
Na realidade, os mecanismos de adaptação no ambiente de armazenamento
são úteis quando o mesmo se encontra em uma máquina diferente da máquina
onde o documento será exibido, ou seja, uma estação que difere da estação que
contém o ambiente de execução. Nesse caso, a adaptação ocorre como uma forma
de eliminar as configurações inviáveis (ou inconsistentes) de apresentação de um
documento, buscando evitar o desperdício na utilização dos recursos de
comunicação e processamento. Mais ainda, quando realizados no ambiente de
armazenamento,
esses
mecanismos
podem
simplificar
o
projeto
e
a
implementação dos ambientes de execução, facilitando inclusive a integração com
clientes simples, já desenvolvidos, sem capacidade de adaptação. No entanto, é
importante frisar que, sem estratégias de adaptação no cliente, é impossível ter um
controle adequado sobre a qualidade das apresentações dos hiperdocumentos, pois
várias das estratégias de ajuste, ou mesmo de prevenção, que são algumas das
funções dos mecanismos de adaptação, devem estar localizadas o mais próximo
possível do usuário “leitor”, que é justamente quem percebe quando ocorre uma
variação qualquer que afete a compreensão do documento. Além disso, se por um
lado a incorporação desses mecanismos aumenta a complexidade dos clientes, a
distribuição do processamento despendido com os mecanismos de adaptação, que
não é desprezível, torna a arquitetura mais escalável.
Cabe aqui comentar que as estratégias de adaptação no formatador são
desejáveis, mas mais desejável ainda é que uma vez iniciada uma apresentação, a
necessidade para que ajustes ocorram seja mínima. Dessa forma, o formatador
deve procurar sempre analisar a descrição de apresentação e a estrutura do
hiperdocumento antes da sua exibição, planejar a sua execução e, sempre que
possível, antecipar-se às ações, para diminuir as chances de ser surpreendido pelos
acontecimentos imprevisíveis anteriormente mencionados, principalmente as
questões de atraso no sistema operacional e na rede.
Idealmente, a configuração de um sistema hipermídia não deve impor
restrição à localização de cada um dos ambientes, podendo os mesmos residir em
máquinas distintas ou em uma mesma máquina. Mais ainda, cada ambiente pode
constituir-se em um conjunto de estações, formando o próprio ambiente uma
Introdução
8
arquitetura distribuída. O armazenamento é o caso mais comum e foi comentado
anteriormente. No entanto, essa configuração distribuída pode também ser útil
para autoria e apresentação. No primeiro caso, é possível considerar como
exemplo um cenário onde a autoria seja feita de maneira cooperativa envolvendo
diversos usuários (Gorini, 2001). Já um sistema de teleconferência com suporte ao
intercâmbio de documentos e à realização de anotações poderia ser considerado
como um exemplo de apresentação hipermídia distribuída (Oliveira, 1996).
A troca de informações entre os vários ambientes será sempre intermediada
por um provedor de serviços de comunicação (Colcher, 1999). Nos casos mais
comuns em que os ambientes se encontram localizados em máquinas distintas, a
própria rede juntamente com o hardware e software de comunicação presentes em
cada estação formam esse provedor. No caso particular em que todos os ambientes
encontram-se na mesma estação, o provedor de comunicação pode ser
representado pelo sistema operacional e os mecanismos utilizados localmente para
a troca de mensagens. As características desse provedor e dos serviços por ele
oferecidos (serviço de melhor esforço, serviço com reserva de recursos etc.)
exercerão influência direta no projeto dos ambientes, principalmente os de
apresentação e armazenamento, conforme será melhor discutido no Capítulo 4
deste trabalho.
1.2
Objetivos
O objetivo desta tese é abordar as questões relacionadas ao controle de
execução de documentos hipermídia no lado cliente, com destaque especial para
os mecanismos de adaptação das apresentações. Sendo assim, o foco deste
trabalho é a modelagem de ambientes de execução hipermídia (Figura 1).
Contudo, uma vez que alguns aspectos de exibição estão diretamente relacionados
às características dos provedores de comunicação (rede) e processamento (sistema
operacional), esta tese também estabelece as interfaces para junção com os
serviços oferecidos por um provedor de comunicação e processamento, baseado
em uma arquitetura com provisão e gerência de QoS (Gomes, 1999; Gomes et al.,
2001).
Introdução
9
Sendo este um trabalho para abordar os aspectos de execução das
apresentações hipermídia, será essencial estabelecer um modelo de documentos
hipermídia apropriado para o controle das apresentações. Mais ainda, este modelo
deverá permitir especificações que favoreçam a implementação de mecanismos de
ajuste das exibições, fazendo com que a formatação da apresentação seja realizada
de maneira adaptativa. O modelo proposto é baseado em máquinas de estados de
eventos, relacionamentos de causalidade e relacionamentos de restrição. Cabe
comentar que, para o desenvolvimento desta tese, as características do modelo
hipermídia NCM (Nested Context Model) (Casanova et al., 1991; Soares et al.,
1995; Souza, 1997) exerceram grande influência. Da mesma forma, o trabalho de
pesquisa realizado também trouxe diversos refinamentos para o NCM (Soares et
al., 1998a; Soares et al., 1998b; Soares et al., 1999; Soares et al., 2000; Soares et
al., 2003).
A partir da proposta de modelo hipermídia para execução dos documentos,
esta tese discute as funcionalidades que devem ser abordadas no projeto de
ambientes de execução hipermídia. Entre as principais funcionalidades de
formatação de hiperdocumentos que serão tratadas ao longo deste documento,
podemos ressaltar: a adaptação dos documentos em função das especificações de
autoria e das características da plataforma de exibição (por exemplo, ajuste das
durações dos objetos de mídia e escolha do conteúdo mais adequado), a integração
do formatador com ferramentas de exibição para diferentes tipos de mídia (vídeo,
áudio, texto etc.), a elaboração de planos para a pré-busca dos objetos, a gerência
da QoS para a transmissão e exibição dos conteúdos dos objetos e a conversão
entre modelos de documentos de autoria e o modelo de execução.
As funcionalidades apresentadas são reunidas em um framework que tem
como objetivo facilitar a implementação de ambientes de execução hipermídia.
Essas funcionalidades são estruturadas de uma maneira modular, buscando
permitir que nem todas estejam presentes em uma implementação real, sem que
isso afete a lógica de funcionamento do formatador. Mais ainda, as principais
funcionalidades são elas próprias modeladas como frameworks, objetivando que
suas implementações possam também ser reusadas em mais de uma
implementação de formatador hipermídia.
Introdução
10
A fim de validar a proposta deste trabalho, foi realizada a implementação de
um formatador seguindo a arquitetura definida e baseando-se no modelo de
documentos para execução desenvolvido. A generalidade do modelo de execução
permite acomodar modelos de documentos existentes através de instanciações de
conversores no formatador. Nesse sentido, foram também implementados dois
conversores capazes de realizar a tradução de outros dois modelos (NCM e SMIL)
para o modelo de execução proposto.
1.3
Organização da tese
Esta tese está estruturada da seguinte forma. O Capítulo 2 discute as
possibilidades de adaptação para hiperdocumentos e levanta os requisitos para os
modelos de documentos hipermídia. A partir desse estudo, o capítulo apresenta o
modelo hipermídia utilizado como ponto de partida para a construção da
arquitetura de formatação. O Capítulo 3 aborda as funcionalidades desejáveis em
um ambiente de execução hipermídia e estabelece uma arquitetura genérica para
facilitar o projeto e implementação desses ambientes. O Capítulo 4 complementa
o Capítulo 3 com uma análise dos requisitos dos mecanismos de adaptação e prébusca de objetos em formatadores hipermídia. O capítulo também trata da questão
da negociação e manutenção da qualidade de serviço (QoS) nas apresentações
hipermídia, comentando os aspectos de integração do ambiente de execução com
os provedores dos serviços de processamento e comunicação. O Capítulo 5
apresenta a instanciação da proposta para o sistema hipermídia HyperProp (Soares
et al., 2000) e comenta a respeito de dois conversores desenvolvidos. Um que
transforma especificações de documentos no modelo NCM para o modelo de
execução do formatador HyperProp, e outro que adapta, para esse mesmo
formatador, documentos especificados na linguagem SMIL (Synchronized
Multimedia Integration Language) (W3C, 1998b; W3C, 2001a), padronizada pelo
Consórcio WWW (W3C Consortium2). O Capítulo 6 traz uma comparação com os
principais trabalhos relacionados na área e o Capítulo 7 tece as considerações
finais da tese, salientando as contribuições do trabalho e as pesquisas futuras.
2
http://www.w3c.org/
Modelos de Documentos Hipermídia com Recursos de Adaptação
11
2
Modelos de Documentos Hipermídia com Recursos de
Adaptação
A computação orientada a contexto (Context-Aware Computing) (Dey et al.,
2001; Schilit et al., 1994) é um paradigma que se propõe a permitir que as
aplicações possam descobrir e tirar proveito das informações que as circundam,
tais como, perfil do usuário, localização, horário do dia, recursos próximos, infraestrutura disponível, entre outros. Muitas das propostas nessa linha de pesquisa
estão ligadas à computação móvel e à computação ubíqua; no entanto, várias das
questões que devem ser tratadas relacionadas a essa área resolvem problemas que
independem de características de mobilidade e ubiqüidade do sistema.
Conforme discutido no capítulo anterior, é desejável em sistemas hipermídia
a existência de mecanismos que realizem a adaptação dos documentos, isto é, que
apliquem algum tipo de transformação nos hiperdocumentos a fim de torná-los
mais apropriados ao contexto em que estejam sendo visualizados. Dessa forma, os
sistemas hipermídia que dispõem de técnicas de adaptação para a formatação dos
hiperdocumentos podem ser considerados como exemplos de aplicações
orientadas a contexto. Existe, contudo, uma grande quantidade de ajustes e
transformações que podem ser entendidos como formas de adaptação de um
hiperdocumento.
O objetivo deste capítulo é, inicialmente, discutir as principais
possibilidades de adaptação de documentos hipermídia. Isso é feito basicamente
respondendo a quatro perguntas: “o que adaptar?”, “em função do que adaptar?”,
“onde adaptar?” e “quando adaptar?”. Essa análise permite estabelecer as
principais características que devem permear o modelo hipermídia utilizado como
base para a elaboração dos hiperdocumentos, assim como o modelo de
informações contextuais. Além dos requisitos para favorecer a incorporação de
mecanismos de adaptação, o capítulo também apresenta uma análise geral das
características
desejáveis
de
serem
encontradas
em
um
modelo
de
hiperdocumentos. Com base em todos esses estudos, o capítulo se encerra com a
12
descrição do modelo hipermídia de execução utilizado como ponto de partida para
a construção da arquitetura de formatação apresentada no capítulo seguinte.
2.1
Adaptação em sistemas hipermídia
2.1.1
Documentos hipermídia
Para entender as possíveis formas de adaptação de documentos hipermídia,
o ponto de partida é analisar o objeto da adaptação, ou seja, os próprios
hiperdocumentos. Na realidade, mais que os documentos, é preciso compreender o
modelo hipermídia por trás de suas descrições. Todo sistema hipermídia reside
sobre pelo menos um modelo de documentos que estabelece um conjunto de
entidades, a semântica dessas entidades, os seus inter-relacionamentos e as
operações que podem ser aplicadas sobre as mesmas. É possível encontrar na
literatura
uma
variedade
de
propostas
de
modelos
de
documentos
multimídia/hipermídia. AHM (Hardman et al., 1993a), Dexter (Halasz &
Schwartz, 1994), HyTime (ISO/IEC, 1992), I-HTSPN (Willrich et al., 1996), IMD
(Vazirgiannis, 1999), Labyrinth (Díaz et al., 2001), Madeus (Jourdan et al.,
1998a), MHEG (ISO/IEC, 1996), NCM (Soares et al., 1995; Soares et al., 2000),
OCPN (Little & Ghafoor, 1990) e ZYX (Boll & Klas, 1999) são alguns exemplos.
As definições de alguns modelos podem também ser implicitamente encontradas
na especificação de linguagens declarativas, como HTML (W3C, 1999c) e SMIL
(W3C, 2001a). Além desses casos, certos sistemas como Chimera (Anderson,
1997), CMIFed (van Rossum et al., 1993), DHM (Grønbaek et al., 1997), Firefly
(Buchanan & Zellweger, 1992), Hyper-G (Andrews et al., 1995) e Microcosm
(Hall et al., 1996) também possuem definições de modelos multimídia/hipermídia
associadas.
13
2.1.1.1
Adaptação dos nós
De um modo geral, duas entidades estão presentes em todos os modelos
hipermídia: os nós e os relacionamentos entre os nós. Um nó hipermídia, também
conhecido como objeto de dados ou recurso, tem como principais atributos sua
identificação e o seu conteúdo. O principal tipo de nó encontrado em todos os
modelos hipermídia é o nó de mídia, muitas vezes denominado nó de conteúdo ou
objeto de mídia. Esses nós atômicos (ou simples) costumam ser especializados em
subclasses, tais como texto, imagem, áudio e vídeo, em função do tipo de
informação por ele contida. Normalmente, o valor do atributo conteúdo desses nós
é expresso através de uma referência para os dados propriamente ditos (URI de
um arquivo, por exemplo), mas nada impede que o conteúdo esteja inteiramente
armazenado no próprio nó. Alguns modelos hipermídia utilizam o conceito de
composição para a definição de um outro tipo de nó: o nó composto. Um nó de
composição, também chamado de objeto de dados composto, permite agrupar
diversos nós (simples ou compostos) recursivamente, oferecendo suporte para
uma especificação estruturada e muitas vezes hierárquica dos documentos.
A adaptação dos objetos de mídia (objetos de dados simples) está
diretamente relacionada com a adaptação do conteúdo do documento. A forma
mais comum desse tipo de adaptação é a escolha de partes do documento
baseando-se em diferentes alternativas de conteúdo contidas em arquivos, ou
fontes de dados3, distintos. No entanto, nada impede que as alternativas sejam
estabelecidas automaticamente pelo sistema, extraídas de uma única versão do
conteúdo; por exemplo, através de um mecanismo de descarte, ou inserção,
automático de quadros que consiga alterar a taxa de exibição de um vídeo.
Em termos das opções de alternativas que podem ser estabelecidas para os
conteúdos dos nós, é possível identificar duas principais categorias. A primeira é a
adaptação pela simples variação da qualidade da informação, por exemplo,
modificando a resolução em pixels ou as opções de cores de uma imagem. A
segunda categoria de adaptação é aquela que modifica a própria quantidade (ou
3
Exemplos de fontes de dados seriam câmeras de captura de vídeo.
14
tipo) de informação apresentada, tal como a alteração do texto de uma aula em
função dos objetivos e pré-requisitos do aluno.
Algumas observações devem ser feitas com relação às definições dos dois
parágrafos anteriores. Em primeiro lugar, o ajuste automático de um conteúdo
(estabelecimento das alternativas pelo próprio sistema a partir de uma única
versão) é mais simples de ser realizado quando a adaptação modifica apenas a
qualidade da informação, ao passo que a seleção de alternativas a partir de
diferentes versões pode ser facilmente utilizada em qualquer uma das opções.
Outra consideração importante é que as adaptações tanto da quantidade como da
qualidade da informação podem ser interessantes de serem aplicadas de modo
combinado. Por exemplo, o vídeo de uma aula a ser exibida para um aluno pode
ser escolhido dependendo do seu histórico (aula para iniciante, aula para aluno
avançado etc.) e, posteriormente, a sua taxa de exibição escolhida em função da
banda passante da conexão de rede utilizada pelo aluno.
A adaptação automática da qualidade dos conteúdos a partir de uma única
versão é uma característica desejável em um sistema de apresentação hipermídia,
pois traz como benefício, principalmente para os autores, a facilidade no reuso e
manutenção dos objetos, evitando uma proliferação de versões desses objetos.
Todavia, tal adequação automática traz consigo algumas dificuldades em termos
de implementação. Por exemplo, para que a taxa de transmissão de um vídeo na
rede efetivamente diminua, é preciso que o transmissor saiba efetuar uma
manipulação de descarte do conteúdo e que o receptor consiga processar esse
conteúdo modificado. Além disso, esse modo de adaptação limita o ajuste a uma
taxa mínima, abaixo da qual não é possível compreender a informação (Boll et al.,
1999a). Mais ainda, pode ser que o ambiente de execução do cliente não disponha
de decodificadores ou dispositivos de saída apropriados para o tipo de mídia do
conteúdo. Sendo assim, é útil que, além da adaptação automática a partir de uma
única versão, também seja possível a adaptação dos documentos através de
substituições dos conteúdos por outras alternativas, que podem, inclusive, ser de
tipos de mídia diferentes. Por exemplo, em um dado contexto, pode ser apropriado
substituir um nó de áudio por um nó de texto. Esse tipo de adaptação é também
conhecido como adaptação cross-media (Boll et al., 1999a).
15
Apesar de existir a possibilidade de transformar o tipo de mídia de um
conteúdo automaticamente, por exemplo, sintetizando um áudio a partir de um
texto, a adaptação cross-media é mais usual de ser implementada utilizando a
idéia de versões distintas previamente estabelecidas em conteúdos separados. Isso
porque a transformação automática do tipo de mídia pode impor retardos
proibitivos, principalmente para aplicações interativas.
Um caso particular de adaptação de conteúdo pela variação de qualidade que
merece destaque é a modificação na duração dos objetos, também denominada
computação dos tempos elásticos ou simplesmente ajuste elástico (Bachelet et al.,
2000; Buchanan & Zellweger, 1993b; Kim & Song, 1995). Esse tipo de adaptação
atua na apresentação dos objetos, aumentado (stretching) ou diminuindo
(shrinking) suas durações em relação aos valores originais (ou ideais), com o
objetivo de garantir a consistência temporal do documento, ou seja, respeitar as
restrições temporais entre objetos de mídia impostas pelo autor. Para as mídias
estáticas como texto ou imagem, esse tipo de ajuste é trivial de ser efetuado. No
entanto, para as mídias contínuas, tais como vídeo e áudio, esse tipo de adaptação
pode se tornar mais complexo de ser implementado. O ideal é que o sistema
(ferramentas de exibição, ambiente de armazenamento etc.) possua algoritmos que
modifiquem a duração do conteúdo dinamicamente, preservando ao máximo a
informação original. Na impossibilidade de dispor desses algoritmos, duas
soluções simples são: utilizar a idéia de seleção de alternativas (possuir o objeto
em várias versões, com durações distintas) ou realizar um simples corte
(truncamento) ou repetição (loop) de parte do conteúdo. A primeira solução,
entretanto, traz dificuldades para a autoria, obrigando a geração do conteúdo em
diversas versões, enquanto a segunda estratégia provavelmente resultará em uma
má qualidade de apresentação.
É importante observar que os conceitos em que se baseia o ajuste elástico
temporal podem ser transpostos para o arranjo espacial dos objetos, resultando em
um ajuste elástico das dimensões dos nós cujos conteúdos são baseados em mídias
visíveis. Na verdade, historicamente, a funcionalidade de ajuste espacial
automático é anterior ao ajuste elástico temporal, sendo amplamente explorada,
principalmente nos editores de texto.
16
Nem sempre o ajuste elástico está relacionado com a qualidade da mídia
exibida, mas somente esse caso será tratado neste trabalho. Apenas como título de
exemplo, suponha que para a manutenção do sincronismo temporal, fosse
primeiro determinado o tempo disponível para exibição de cada objeto, que
guiaria então a procura por uma alternativa que tratasse do assunto naquele tempo
estabelecido.
A definição de composições em modelos hipermídia pode ser de utilidade
para alguns dos tipos de adaptação comentados até aqui. Em primeiro lugar, se
essas composições tiverem tratamento similar ao dos nós de conteúdo, ou seja, se
elas também forem consideradas objetos de dados, a especificação de alternativas
para os objetos de dados simples poderia ser facilmente estendida, permitindo,
dessa forma, utilizar essa flexibilidade para, ao invés de realizar uma adaptação de
mídias particulares, efetuar uma adaptação estrutural (ou mesmo no formato de
apresentação) dos documentos. Um exemplo de substituição desse tipo seria a
troca de um vídeo por uma seqüência de imagens juntas com um texto explicativo
para acomodar a apresentação à banda passante disponível no acesso do cliente.
Um segundo aspecto relaciona-se com o ajuste temporal. As composições podem
permitir que os algoritmos de adaptação atuem de forma hierárquica, calculando
as durações de maneira global em termos de objetos compostos e, independente e
progressivamente, refinando o cálculo para os objetos contidos em cada
composição.
Um aspecto importante nos modelos de documentos hipermídia é a maneira
como os parâmetros de apresentação dos objetos de dados, tais como posição na
tela, cor de fundo, ferramenta de exibição e duração são especificados. Em alguns
modelos, essas informações são armazenadas em entidades específicas, separadas
da estrutura lógica e do conteúdo do documento. Isso permite que um mesmo
padrão de apresentação seja aplicado a vários objetos de dados, e que um mesmo
objeto seja exibido com diferentes características, oferecendo uma interessante
forma de reutilização e uma facilidade de manutenção das especificações de
autoria. Neste trabalho, denominaremos descritor a entidade responsável por
conter as informações para apresentação de um objeto de dados.
Permitir que o autor do documento especifique, ao invés de um único
descritor, uma lista de opções, torna possível ao sistema hipermídia selecionar as
17
características de apresentação mais adequadas para cada objeto de dados a ser
exibido. Com isso, os objetos do documento passam a poder ter não apenas os
seus conteúdos, mas também os seus aspectos de exibição adaptáveis. Outra
flexibilidade interessante é permitir que essas características de apresentação
sejam escolhidas também em função da navegação do usuário e de suas
preferências.
De um modo geral, todos os mecanismos de adaptação associados à
qualidade da informação devem atuar cooperativamente com o controle de
apresentação do sistema hipermídia. Dispor os ambientes de execução dos
sistemas hipermídia com esses tipos de recursos de adaptabilidade permite que o
autor crie um único documento que poderá ser exibido em uma diversidade de
plataformas. Além disso, em plataformas onde não é possível negociar e reservar
recursos, os mecanismos de adaptação da qualidade do conteúdo podem tornar o
sistema capaz de reagir e adequar a apresentação aos recursos que estiverem sendo
oferecidos em um dado instante. Mesmo em plataformas com provisão de QoS
(reserva de recursos), existe sempre a possibilidade do provedor de serviços não
conseguir manter a qualidade negociada, obrigando uma renegociação e um
conseqüente ajuste da apresentação. Tudo isso evidencia a importância de um dos
objetivos desta tese, qual seja, tratar dos mecanismos de adaptação ligados à
variação na qualidade das informações exibidas.
A adaptação do tipo (ou quantidade) de informação apresentada é, sem
dúvida, um requisito desejável em sistemas hipermídia, mas não faz parte do
escopo deste trabalho. A referência (Brusilovsky, 1996) oferece um panorama
amplo das pesquisas nessa área, e este capítulo, em particular, procura também
contribuir com a análise das diversas possibilidades de adaptação para
apresentações de hiperdocumentos.
2.1.1.2
Adaptação das relações
Conforme comentado no início da seção anterior, juntamente com os nós, os
relacionamentos entre eles constituem-se num dos conceitos mais importantes
presente em todos os modelos hipermídia. Esses relacionamentos são
normalmente representados através de elos (links) ou de composições. Exemplos
18
do uso de elos podem ser encontrados nos hiper-elos da linguagem HTML (W3C,
1999c), nos elos espaciais e temporais do modelo NCM (Soares et al., 2000), nas
transições das redes de petri dos modelos OCPN (Little & Ghafoor, 1990) e IHTSPN (Willrich et al., 1996), e nos relacionamentos temporais no sistema
Firefly (Buchanan & Zellweger, 1992). As composições paralela e seqüencial da
linguagem SMIL (W3C, 2001a), os operadores temporais do modelo ZyX (Boll &
Klas, 1999), bem como os templates da linguagem NCL (Muchaluat-Saade, 2003)
são exemplos de composições que estabelecem semânticas de relacionamentos
temporais entre os seus componentes.
Existem vários tipos de relações que podem estar presentes em um modelo
de documentos hipermídia (Soares et al., 2000): relações de referência, relações de
contextualização, relações de sincronização, relações de derivação e relações entre
tarefas. No entanto, a maioria dos trabalhos que abordam a questão da adaptação
das relações (Brusilovsky, 1996) o fazem apenas para as relações de referência,
também denominadas de relações de navegação. Na verdade, na referência citada,
a adaptação das relações de contextualização, que são aquelas que especificam a
estrutura hierárquica de organização do documento, por exemplo, a divisão de um
livro em capítulos, dos capítulos em seções e assim por diante, também são
mencionadas, porém englobadas como relações de navegação.
As técnicas de suporte à chamada navegação adaptativa procuram auxiliar
os usuários a encontrar o caminho mais apropriado de interação no documento.
Basicamente, essas técnicas se dividem em viagens guiadas, ordenação dos
relacionamentos, ocultação adaptativa dos relacionamentos, anotação adaptativa
dos relacionamentos e adaptação de mapas (Brusilovsky, 1996).
Não faz parte do foco desta tese abordar os aspectos de adaptação dos
relacionamentos. Os estudos nesse tema sofrem uma grande influência da
inteligência artificial e, na maioria das vezes, dependem de uma pesquisa em
conjunto com a área de interação humano-computador. A referência (Brusilovsky,
1996) analisa diversos trabalhos que utilizam diferentes métodos para aplicação
das cinco técnicas de adaptação citadas no parágrafo anterior. Além desse
trabalho, as referências (Muchaluat-Saade, 1996; Muchaluat-Saade et al., 1998)
mostram a utilização de visões de olho-de-peixe como técnicas de adaptação de
mapas para auxiliar tanto na autoria como na navegação de documentos
19
hipermídia. Essas duas últimas referências também tratam do uso de trilhas para
orientar os usuários em viagens guiadas.
Concluindo esta Seção 2.1.1, em termos de modelos de documentos
hipermídia, é possível resumir como sendo duas as principais entidades (ou
conceitos) que podem ser objetos de um mecanismo de adaptação: os nós (de
mídia ou compostos) e os relacionamentos entre os nós (elos ou composições).
Evidentemente, essas duas entidades podem ser ajustadas de uma maneira
combinada. Esta tese, no entanto, tem como foco apenas a adaptação de nós ligada
à qualidade da informação exibida.
2.1.2
Elementos que influenciam a adaptação dos hiperdocumentos
O objetivo desta seção é analisar as principais informações que, de alguma
maneira, podem direcionar os mecanismos de adaptação de um sistema hipermídia
na escolha da configuração mais adequada do documento. Em outras palavras,
esta seção procura responder à pergunta: em função do que deve ser feita a
adaptação dos hiperdocumentos? Na verdade, alguns exemplos da seção anterior
já mencionaram certos aspectos ligados a essa questão.
Como ponto de partida, existem dois principais conjuntos de parâmetros
externos aos documentos que podem exercer influência sobre suas adaptações: as
características do usuário e as características da infra-estrutura (Boll et al., 1999b).
Os valores desses conjuntos de parâmetros são justamente as informações que
reunidas compõem o contexto de exibição de uma aplicação hipermídia,
mencionado no capítulo anterior e no princípio deste capítulo. A adaptação às
características do usuário, também classificada como adaptação ao interesse
pessoal, pode levar em consideração o conhecimento do usuário a respeito dos
assuntos tratados no conteúdo dos documentos, os objetivos e comportamento do
usuário durante a sua navegação, a sua experiência prévia e as suas preferências.
Já a adaptação à infra-estrutura concentra-se nos aspectos relacionados à
plataforma de exibição, tais como a banda passante do sistema de comunicação, o
poder computacional e memória disponíveis nos equipamentos participantes da
transmissão e da exibição do documento, os dispositivos de E/S presentes na
máquina onde o documento é exibido etc.
20
Manter os valores desses vários parâmetros exige a introdução do conceito
de gerência de contexto nos sistemas hipermídia adaptativos. Devido ao
dinamismo de algumas das informações, tais como banda passante e recursos de
processamento e armazenamento disponíveis, é útil que haja agentes monitores
distribuídos pelos ambientes, a fim de coletar os dados pertinentes para
constituição do contexto, que pode ser mantido de uma maneira distribuída ou por
uma unidade central. Com o objetivo de tornar a gerência de contexto um
mecanismo independente e reutilizável por várias aplicações (não necessariamente
apenas aplicações hipermídia) é importante que se estabeleça um protocolo aberto
a ser utilizado na consulta às informações do contexto e também um formato
aberto e extensível para descrição dos dados. Esforços em pesquisa têm sido feitos
para tratar a questão da gerência de contexto em redes móveis (Chen & Kotz,
2000; Schilit et al., 1994) e para negociação de preferências e capacidades
(Lemlouma & Layaïda, 2001). Uma tendência que se observa, justamente com o
intuito de tornar o mecanismo o mais inter-operável possível, é a utilização de
linguagens XML para descrição dos recursos (W3C, 1999a; W3C, 1999b) e de
protocolos baseados em HTTP para consulta e negociação (Gudgin et al., 2001;
Ohto & Hjelm, 1999). Esta tese não trata dos aspectos ligados à gerência de
contexto, mas assume a sua existência para apoiar a formatação e, mais
especificamente, a adaptação das apresentações dos hiperdocumentos. Como
trabalho futuro, pretende-se integrar o formatador HyperProp, apresentado no
Capítulo 5, a mecanismos externos de gerência de contexto.
De um modo geral, as características da infra-estrutura de exibição permitem
guiar a adaptação dos documentos em termos de ajuste da qualidade dos
conteúdos dos objetos apresentados. Em algumas situações, principalmente com
relação às características dos dispositivos de E/S na plataforma de apresentação,
as informações contextuais referentes à infra-estrutura podem também direcionar a
escolha das características de apresentação (descritores) dos objetos e a escolha
entre alternativas de tipos de mídia diferentes. Em contrapartida, os parâmetros
relacionados ao usuário são mais propícios à adaptação da quantidade e tipo de
informações contidas nos conteúdos dos documentos e à adaptação dos
relacionamentos entre os objetos. Como este trabalho se propõe a focar nas
questões de ajuste de qualidade, o mesmo irá centrar seu desenvolvimento na
21
adaptação dos documentos em função das características da infra-estrutura de
exibição.
Para finalizar, é importante salientar que nem toda adaptação depende
exclusivamente de informações externas aos documentos. O ajuste elástico das
durações (ou mesmo das dimensões) dos objetos, comentado na Seção 2.1.1.1, é
um exemplo de adaptação que é feito também com base nas especificações dos
relacionamentos entre os nós.
2.1.3
Local e momento da adaptação
Para que um documento hipermídia seja adaptado em alguma das maneiras
discutidas na Seção 2.1.1, é necessário que exista no sistema hipermídia um
elemento capaz de analisar a descrição do documento em conjunto com as
informações contextuais e, com esses dados, aplicar as estratégias de adaptação.
Conforme comentado na Seção 1.1, em sistemas hipermídia distribuídos, as
estratégias podem ser executadas tanto no ambiente de armazenamento (servidor)
como no ambiente de execução (cliente), podendo inclusive estar presente nos
dois ambientes paralelamente. Em alguns casos, pode ser também interessante a
existência de um agente intermediário no sistema, atuando como um proxy, onde
será incorporada também a funcionalidade de adaptação. A adaptação nesse
elemento pode ser apropriada para reduzir o processamento em clientes e
servidores e ao mesmo tempo reutilizar os resultados para mais de um cliente,
oferecendo uma espécie de cache para os documentos já adaptados (Elson &
Cerpa, 2001). Entretanto, é importante lembrar que, como mencionado na Seção
1.1, uma vez que as técnicas de adaptação relacionadas à qualidade da informação
exibida devem estar próximas do usuário, é fundamental a presença dos
mecanismos de adaptação no cliente hipermídia, mais especificamente no
formatador.
Com relação ao momento em que a adaptação ocorre, é possível separar em
duas opções: antes da apresentação do documento e durante a sua apresentação. A
idéia principal é que as adaptações realizadas antes da exibição estão relacionadas
às informações contextuais estáticas, sendo por isso essa opção também
classificada como adaptação estática, enquanto a adaptação em tempo de execução
22
é também chamada de adaptação dinâmica, pois depende de parâmetros cujos
valores se modificam ao longo da exibição do documento (Boll et al. 1999a; Boll
et al., 1999b).
2.2
Requisitos para modelos de documentos hipermídia
Um modelo hipermídia deve, evidentemente, oferecer suporte à definição de
documentos contendo objetos de diferentes tipos de mídia. Além disso, o modelo
precisa possibilitar, ao menos, a especificação de relacionamentos entre os vários
objetos, que permitam ao usuário, através de suas interações, percorrer o conteúdo
de uma maneira não seqüencial.
Além dessas características obrigatórias, algumas outras são também
desejáveis de serem encontradas em um modelo hipermídia. Em primeiro lugar, é
interessante que o modelo permita que sejam especificadas, além das relações
baseadas na interação do usuário, relacionamentos para sincronização tanto
temporal como espacial dos objetos. Esses relacionamentos não devem ser
limitados na quantidade de seus participantes, como acontece com os tradicionais
elos de navegação da linguagem HTML, restrita a uma única origem e um único
destino. Outro ponto desejável é que o modelo permita que os relacionamentos
sejam definidos não apenas entre os objetos como um todo, mas entre partes
internas de seus conteúdos, oferecendo assim uma granularidade mais fina para a
sincronização dos nós.
A forma como as relações são definidas, principalmente as especificadas
através de elos, traz conseqüências importantes para o modelo hipermídia.
Documentos HTML, por exemplo, possuem os elos embutidos no conteúdo, o que
gera limitações significativas (Anderson, 1997; Bouvin & Schade, 1999;
Rodrigues et al., 2002). Sendo assim, é apropriado que os relacionamentos entre
os nós possam estar separados do conteúdo dos objetos, trazendo, entre outros
benefícios, uma possibilidade de reuso dos conteúdos sem uma herança
obrigatória das relações.
Ainda com relação à questão dos relacionamentos de sincronização entre os
objetos, é adequado que o modelo faça uma distinção entre dois tipos de relações:
as relações de causalidade e as de restrição. As relações de causalidade envolvem
ações
que
23
devem ser executadas quando condições estabelecidas no
relacionamento forem satisfeitas. Por exemplo, o início de um vídeo deve ocorrer
quando uma imagem deixar de ser apresentada, ou o término de um áudio deve
acontecer quando o usuário interagir com a aplicação. Como o próprio nome
sugere, as relações de restrição estabelecem regras de sincronismo que o
formatador hipermídia deve procurar respeitar. Por exemplo, um vídeo e um
áudio, quando simultaneamente exibidos, devem terminar ao mesmo tempo.
Como é possível perceber, os dois tipos de relações apresentam semânticas
distintas e se complementam no oferecimento de um maior poder de expressão aos
autores. Um exemplo da necessidade dos dois tipos de relação de sincronização
está no uso comum que se faz das relações definidas por Allen (Allen, 1983) e
ilustradas na Figura 2. Allen especificou treze possíveis relações que podem ser
definidas entre intervalos e esse resultado tem sido utilizado como base na
definição das relações de sincronismo temporal em modelos de documentos
multimídia (Little & Ghafoor, 1990).
t
X before Y
Y after X
X
X meets Y
Y met by X
X
X overlaps Y
Y overlapped by X
X during Y
Y contains X
Y
Y
X
t
t
X
X starts Y
Y started by X
Y
t
X finishes Y
Y finished by X
Y
X equals Y
X
Y
X
Y
X
Y
Figura 2 – Relações de Allen.
A questão da necessidade dos dois tipos de relação surge pelo fato das
relações de Allen não expressarem precisamente a semântica desejada pelo autor
para definir o sincronismo temporal entre dois intervalos de tempo, podendo gerar
ambigüidades para o controle da apresentação (Duda & Keramane, 1995). Por
exemplo, a relação meets apenas especifica que o final de um intervalo deve
coincidir com o princípio de um outro, mas várias interpretações podem ser dadas.
A relação pode ser considerada como sendo de restrição: o final da apresentação
de x precisa coincidir com o início da apresentação de y. Contudo a relação
poderia também ser vista com uma semântica de causalidade, permitindo inclusive
24
duas interpretações distintas: uma causalidade de iniciação (o final da exibição de
x deve causar o início da exibição de y) ou uma causalidade de encerramento (o
princípio da exibição de y deve ocasionar o término da apresentação de x). Sendo
assim, é interessante que o modelo proveja meios para a especificação explícita
dos dois tipos de relacionamentos de sincronização entre os objetos.
Outra característica em modelos de documentos hipermídia que merece
destaque como sendo desejável é a existência de entidades que permitam agrupar
os nós e seus relacionamentos, que possam ser reutilizadas em várias partes do
documento, ou até mesmo em documentos distintos. A maneira usual de oferecer
esse recurso é através da introdução nos modelos do conceito de nó de
composição, já mencionado na Seção 2.1.1.1.
Conforme também discutido na Seção 2.1.1.1, uma outra característica
desejável em modelos de documentos hipermídia é a separação dos parâmetros de
exibição, a fim de torná-los independentes do objeto de dados. A idéia é que esses
parâmetros possam ser associados aos nós conforme a conveniência. Essa
separação permite, entre outras coisas, o reuso das mesmas características de
apresentação em vários objetos e a modificação do estilo de apresentação sem que
seja preciso alterar os objetos de dados. Esse tipo de separação pode servir
também como uma facilidade para implementar adaptações de documentos pela
simples modificação das características de exibição. Exemplos importantes dessa
abordagem são as linguagens de estilo padronizadas para as páginas HTML
(W3C, 1996; W3C, 1998a) e os layouts espaciais da linguagem SMIL (W3C,
2001a).
Ainda de acordo com o que foi comentado na Seção 2.1, é desejável que o
sistema hipermídia possua recursos para a adaptação dos documentos e de suas
apresentações. Porém, para que a maioria das técnicas de adaptação possam ser
aplicadas, é necessário que o modelo permita a especificação de certas
informações de uma maneira flexível. Por exemplo, para que possa ser realizado o
ajuste das durações dos objetos, as mesmas devem ser especificadas não mais de
uma maneira rígida com um único valor, mas sim com uma faixa de valores
aceitáveis. Mais interessante ainda se esses valores forem descritos através de uma
função de custo, oferecendo assim uma métrica que permita à estratégia de
adaptação decidir qual o melhor ajuste para uma dada apresentação e contexto de
25
exibição (Bachelet et al., 2000; Buchanan & Zellweger, 1993b; Kim & Song,
1995).
Ainda com relação à adaptação, para que o sistema hipermídia possa
explorar a idéia da seleção de alternativas, é fundamental que algum tipo de metainformação esteja associado a cada uma das várias possibilidades de conteúdo, de
relacionamento ou mesmo de descrição das características de apresentação (Seção
2.1.1). Esses metadados podem ser explicitamente informados pelo autor ou
automaticamente calculados pelo sistema, devendo estar disponíveis no momento
da apresentação do documento, a fim de permitir que as técnicas de adaptação
saibam como classificar e escolher entre as diferentes alternativas. Mais ainda, é
necessária a existência de uma base de relacionamentos estabelecendo as
associações entre as várias alternativas. Essas bases podem ser simples
composições, tais como o switch das linguagens SMIL (W3C, 2001a) e NCL
(Muchaluat-Saade, 2003), ou conjuntos de relações mais amplas e complexas,
como as propostas em (Boll et al., 1999a).
Evidentemente, também é importante que exista um modelo para descrição
das informações contextuais, pois, na verdade, conforme discutido na Seção 2.1.2,
a adaptação deverá ser guiada pelos parâmetros do contexto em que a aplicação
estiver inserida. No entanto, é importante observar que o modelo para
estabelecimento das associações entre alternativas e o modelo para descrição do
contexto não precisam fazer parte diretamente do modelo de hiperdocumentos.
Esses modelos podem funcionar como camadas que venham a ser superpostas ao
modelo de documento, oferecendo diferentes níveis de visões para as informações.
Os requisitos apresentados nesta seção buscam estabelecer as características
desejáveis de serem encontradas nos modelos de dados que formam a base das
informações passadas para o ambiente de execução hipermídia (Figura 1). Esse
ambiente, por sua vez, deve ser projetado de modo a ser capaz de controlar as
apresentações dos documentos com todos os recursos mencionados.
Internamente, o ambiente de execução (em especial, o formatador) deve
estabelecer um modelo para construção de suas estruturas de dados, a fim de gerar
os documentos formatados a partir das especificações disponíveis, conforme
ilustrado na Figura 3. Esse modelo interno pode ser entendido como o modelo de
execução dos hiperdocumentos e, conforme discutido e ilustrado na figura, em
26
alguns casos, será na verdade o resultado do processamento de informações
provenientes de mais de um modelo. Dos vários modelos de entrada apresentados
na figura que podem influenciar no modelo de execução, esta tese concentra-se
nos aspectos relacionados ao modelo de documentos.
Modelo de
Documentos
Hipermídia
Modelo do
Contexto de
Exibição
informações
contextuais
Modelo de
Execução
Hipermídia
documento
hipermídia
flexível
Modelo de
Associações
descrição das
associações
entre alternativas
Ambiente de
Execução
(Formatador
Hipermídia)
documento
formatado
Figura 3 – Modelos das informações fornecidas a um formatador hipermídia para controle
da execução dos hiperdocumentos.
O modelo de documentos hipermídia normalmente corresponde ao modelo
utilizado para autoria4. Pela variedade de modelos desse tipo citados na Seção 2.1
e assumindo que seja desejável que um ambiente de execução possa controlar a
apresentação de mais de um tipo de modelo de documento, torna-se necessário
que, na maioria das vezes, a execução seja precedida por uma fase de
transformação para conversão de formatos, conforme será melhor discutido no
Capítulo 3 e exemplificado no Capítulo 5. Dois motivos justificam a necessidade
dessa transformação. O primeiro é a necessidade de colocar certas abstrações para
os autores, que podem ser eliminadas quando o documento se aproxima da
4
Muitas vezes o modelo de autoria passado ao autor pode ter um nível de abstração maior, mas
terá sempre por base um modelo de autoria tal qual os já exemplificados.
27
máquina que irá controlar a sua exibição. O segundo é uma simples questão
subjetiva de preferência, refletida na variedade de propostas e padrões de modelos.
2.3
Modelo de documentos para controle da execução
As entidades apresentadas nesta seção formam a base do modelo de
execução utilizado para a construção do framework de formatação de documentos
hipermídia. Mais especificamente, esse modelo serviu também como referência
para a implementação do formatador HyperProp, a ser apresentada no Capítulo 5.
O modelo de execução a ser descrito baseia-se em conceitos do modelo NCM
(Casanova et al., 1991; Soares et al., 1995; Souza, 1997; Soares et al., 2000;
Soares et al., 2003), Modelo de Contextos Aninhados (Nested Context Model),
mas sua aplicação é mais geral, podendo ser utilizado como modelo de execução
para outros modelos de documentos hipermídia, conforme será também
comentado no Capítulo 5, quando serão apresentados os conversores
desenvolvidos como parte deste trabalho. Maiores informações a respeito do
modelo NCM podem ser encontradas nas referências já citadas, em particular, no
relatório técnico que descreve todas as entidades do modelo de maneira detalhada
(Soares et al., 2003).
O modelo de execução proposto segue o paradigma de orientação a objetos e
baseia a lógica e o sincronismo das apresentações em máquinas de estados de
eventos, relacionamentos de causalidade entre eventos e também relacionamentos
de restrição entre eventos. O modelo define uma estrutura básica com alguns
pontos
de
flexibilização
(hotspots),
que
devem
ser
preenchidos
nas
implementações particulares dos ambientes de execução. O objetivo principal é
tornar a proposta genérica e capaz de atender a uma variedade de formatadores.
A descrição das classes do modelo e da maneira como essas classes se
relacionam é feita com o auxílio da linguagem UML (Rumbaugh et al., 1999). Os
diagramas são apresentados progressivamente, com o intuito de evitar uma
sobrecarga visual nas figuras. Além disso, também com o objetivo de tornar os
diagramas mais legíveis, apenas os principais atributos e métodos das classes
foram destacados. A descrição completa das classes, atributos e métodos do
modelo de execução pode ser encontrada em (Rodrigues, 2003).
28
2.3.1
Objetos de execução
O principal elemento no modelo é o objeto de execução, que representa uma
instância de nó hipermídia a ser exibida. Sendo assim, os objetos de execução no
formatador reúnem, para cada fragmento de informação (nó), todos os seus dados,
inclusive as informações relativas às suas características de apresentação. Um
objeto de execução (classe ExecutionObject) possui quatro atributos principais:
identificador único, objeto de dados, descritor e lista de eventos, conforme
ilustrado no diagrama da Figura 4.
O identificador único (classe UID), como o próprio nome sugere, permite
distinguir univocamente o objeto de execução dentro do ambiente de formatação.
Essa classe deve ser estendida na implementação de cada ambiente de execução
particular, precisando apenas oferecer um método que permita comparar o
identificador com um outro identificador do mesmo tipo. É responsabilidade da
implementação do formatador garantir a unicidade dos identificadores.
1
UID
1 ExecutionO bject
compareTo(UID id)
event List
1
1..*
1
1..*
Event
1
1
DataObject
Descriptor
Figura 4 – Diagrama de classes para os objetos de execução.
O atributo objeto de dados (classe DataObject) guarda uma referência para o
nó hipermídia (sem as informações de apresentação), enquanto o descritor (classe
Descriptor) contém as informações referentes à exibição do objeto. Por fim, a lista
de eventos (composta por objetos da classe Event) define as unidades básicas para
o controle dos relacionamentos de sincronização temporal e espacial.
Cabe mencionar que um mesmo objeto de dados pode ser compartilhado por
mais de um objeto de execução, oferecendo assim uma possibilidade de reuso de
suas informações. Por outro lado, descritores e eventos pertencem a um único
29
objeto de execução. Existem, no entanto, algumas informações de apresentação
contidas nos descritores que podem ser compartilhadas por mais de um descritor.
As próximas subseções trazem informações mais detalhadas das classes para
criação de objetos de dados, descritores e eventos.
2.3.1.1
Objetos de dados
Todo objeto de dados possui três atributos principais: um identificador
único, um conteúdo e uma lista de âncoras, conforme ilustrado no diagrama de
classes apresentado na Figura 5.
Da mesma forma que o objeto de execução, o objeto de dados possui um
atributo da classe UID que identifica o objeto de dados de maneira única no
ambiente de execução. Novamente, essa classe deve ser especializada em cada
implementação para definir concretamente o identificador. É possível que a
mesma especialização seja utilizada para identificar tanto os objetos de dados
como os objetos de execução. No entanto, os espaços de nomes para os
identificadores devem ser tratados de maneira independente pelo formatador.
1
UID
compareTo()
1
DataObject
anchorList
1
1
1
1..*
Content
Anchor
getType()
getSize()
SpatialAnchor
TimeIntervalAnchor
SampleIntervalAnchor
TextAnchor
UrlContent
content
getUrlContent()
RectangleSpatialAnchor
CircleSpatialAnchor
PolygonSpatialAnchor
Figura 5 – Diagrama de classes para os objetos de dados.
O conteúdo de um objeto de dados identifica um conjunto de unidades de
informação, enquanto as âncoras identificam subconjuntos de unidades de
informação marcadas desse conteúdo. As noções exatas de conteúdo (unidades de
30
informação) e de âncora (unidades de informação marcadas) dependem da classe
de nó hipermídia que venha a derivar o objeto de dados. Por exemplo, um vídeo
pode ter como unidade de informação um quadro, enquanto um texto pode ter
como unidade de informação um caractere ou uma palavra.
O modelo define uma classe abstrata Content que deve ser estendida em
função dos objetos exibidos. O modelo também define uma subclasse de
conteúdo, denominada UrlContent, que identifica as unidades de informação
através de uma URL (Berners-Lee et al., 1994b). Todavia, nada impede que outras
subclasses de conteúdo sejam definidas em implementações particulares de
formatador. Como exemplo, uma implementação de formatador pode definir uma
subclasse de conteúdo que mantenha uma cópia das unidades de informação no
próprio objeto de dados, permitindo que o objeto funcione como uma espécie de
memória cache. Uma outra subclasse de conteúdo que pode ser útil é a que
especifica uma série de outros objetos de dados, representando um nó de
composição. A idéia de criar um objeto de execução associado a uma composição
é permitir que, na apresentação do documento, a sua estruturação possa ser
exibida como parte da informação a ser oferecida ao usuário. Isso porque pode ser
útil para o usuário que, além das mídias, seja exibido um mapa do documento para
auxiliá-lo em sua navegação, reduzindo, ou mesmo eliminando, o problema de
desorientação (Muchaluat-Saade, 1996; Muchaluat-Saade et al., 1998).
Todo conteúdo deve também implementar métodos que descrevam os seus
dados. O método getType deve retornar o tipo MIME (Freed & Borenstein, 1996)
do conteúdo, enquanto o método getSize deve informar o tamanho do conteúdo
em bytes. Ambos os métodos podem retornar um valor não disponível, quando
não for possível determinar o valor de retorno. No caso da classe UrlContent,
existe o método adicional getContentUrl, que retorna o endereço e o protocolo
para respectiva localização e busca do conteúdo.
Similar ao conteúdo, o modelo define uma classe abstrata Anchor, cujas
especializações devem ser feitas em função das unidades de informação do
conteúdo passíveis de serem marcadas. As subclasses de âncora principais
também são especificadas pelo modelo, conforme ilustra o diagrama de classes da
Figura 5. A classe TextAnchor permite definir regiões em conteúdos do tipo texto,
identificando a posição e a string da âncora. As classes TimeIntervalAnchor e
31
SampleIntervalAnchor permitem descrever regiões temporais. A primeira classe o
faz pela especificação do instante de início e fim (em segundos), enquanto a
segunda utiliza a posição das amostras. A classe SpatialAnchor e suas respectivas
subclasses definem regiões espaciais em conteúdos como imagens e vídeos.
Outras subclasses de âncora para, por exemplo, identificar objetos em vídeos e
imagens podem vir a ser definidas em implementações específicas de
formatadores.
Cabe salientar que combinações desses vários tipos de âncora mencionados
no parágrafo anterior podem ser úteis, tais como a definição de uma área
retangular em um vídeo durante um determinado intervalo de tempo. Contudo,
combinações a partir das classes já definidas não requerem a criação de novas
subclasses, pois, conforme será apresentado na definição dos elos (Seção 2.3.2), a
possibilidade de definir relações entre duas ou mais âncoras (na realidade entre
dois ou mais eventos) oferece, no modelo, poder de expressão equivalente.
Uma observação relevante com respeito à definição das subclasses de
âncoras no modelo é que tanto as âncoras espaciais como as âncoras baseadas em
amostras podem identificar suas fronteiras de maneira percentual, ao invés de
discriminar os pixels ou a posição exata das amostras.
2.3.1.2
Descritores
O descritor reúne as informações referentes às características de exibição do
objeto de execução. Todo descritor possui como principais atributos a
identificação de uma ferramenta de exibição (classe PresentationTool) e de uma
região espacial de apresentação (classe LayoutRegion). O modelo permite que
uma mesma ferramenta controle a exibição do conteúdo de mais de um objeto de
execução e, da mesma forma, que uma mesma região espacial seja compartilhada
por mais de um objeto (mais de um descritor).
A
escolha
da
ferramenta
de
exibição
e
sua
instanciação
são
responsabilidades do formatador hipermídia, tendo como base a especificação do
documento e a lista de ferramentas disponíveis discriminadas na plataforma de
exibição (informação de infra-estrutura no contexto de exibição – Seção 2.1.2).
Nada impede que seja utilizada, na apresentação do conteúdo de um objeto de
32
dados, uma ferramenta de um tipo de mídia completamente diferente do tipo de
mídia do conteúdo. Por exemplo, um objeto de dados do tipo texto pode ser
associado a um descritor que defina uma ferramenta de exibição sintetizadora de
voz, e com isso ser apresentado como um áudio.
Conforme pode ser percebido na Figura 6, a região espacial (classe
LayoutRegion) faz parte de uma hierarquia de classes mais ampla, que define a
estrutura espacial da apresentação de um documento. Qualquer que seja o
hiperdocumento a ser apresentado, deve haver no ambiente de execução uma
estrutura espacial (instância da classe Layout) definida para exibição dos objetos
de execução. Essa estrutura especifica um conjunto de janelas (atributo
windowSet,
classe LayoutWindow) e uma janela
da
default
(atributo
defaultWindow). O conjunto de janelas é derivado, quando especificado, da
descrição do documento hipermídia de entrada (Figura 3), enquanto a janela
default é criada pelo próprio formatador. Sua utilidade será descrita mais adiante.
As definições apresentadas nesta seção são similares às encontradas na linguagem
SMIL e na referência (Moura, 2001).
QoS Param eters
LayoutCom ponent
E xec utionObject
0..*
1
1..*
1
regi onS et
1
D es cr iptor
1
1..*
1
1
0..*
1
Pres entationToo l
title
left, top
height, width
back groundColor
z Index
s croll
border
is V isible
is M oveable
is Res izable
open
c los e
1
1
UID
com pare To()
pa rent
0..*
ContentDependentP aram eters
0..1
0..*
LayoutRegion
fit
LayoutW indow
0..*
1
S oundP aram eters
volum eLevel
bal anc eLevel
trebleLevel
bass Level
S ty leP ar am eters
s tyl eS heet
Tem poralP aram eters
t im eB arE na bled
windo wS et
1
Layout
1
defaultW indow
Figura 6 – Diagrama de classes para os descritores.
Janelas (classe LayoutWindow) e regiões herdam de uma superclasse
comum, denominada LayoutComponent. Objetos dessa classe possuem um
identificador único (classe UID, análoga à que foi definida para os objetos de
execução e de dados) e um nome (atributo name). Além disso, a classe
33
LayoutComponent define atributos que permitem especificar largura (width) e
altura (height) de uma área retangular5 e coordenadas de posicionamento
(atributos top e left) do componente. Qualquer uma dessas informações pode ser
especificada tanto de maneira absoluta (em pixels, por exemplo) como de maneira
proporcional.
A classe LayoutComponent possui também uma série de outros atributos
referentes às propriedades de exibição dos objetos: backgroundColor, zIndex,
scroll, border, isVisible, isMoveable, isResizable, open e close. O atributo
backgroundColor serve para definir uma cor de fundo para o componente de
layout. O atributo zIndex é utilizado para determinar a prioridade de superposição
quando mais de um componente tiver que ser exibido em uma mesma área. Os
componentes com valores de zIndex menores aparecem sobrepostos aos
componentes com valores maiores. O atributo scroll define o comportamento da
barra de rolagem na exibição do componente e pode receber um, dentre cinco
valores: componente não possui barra de rolagem, componente possui barra de
rolagem apenas vertical, componente possui barra de rolagem apenas horizontal,
componente possui sempre barras de rolagem vertical e horizontal e, finalmente, o
componente só possui barra de rolagem (tanto vertical quanto horizontal) quando
for necessário. O atributo border define a espessura da borda para o componente
de layout. O valor zero significa a ausência de borda para o componente. Os
atributos, isVisible, isMoveable e isResizable informam, respectivamente, se o
componente está ou não visível, se pode ser ou não modificado de posição e se
pode ter ou não as suas dimensões alteradas. Os atributos open e close serão
comentados mais adiante.
Além das informações referentes às características de exibição, todo
componente de layout (janela ou região) possui um conjunto de regiões (atributo
regionSet). Isso também implica que toda região deve estar contida em um
componente de layout, identificado pelo atributo parent da classe LayoutRegion.
5
Para tornar o modelo mais genérico, janelas, assim como regiões, poderiam ser especificadas nas
mais diversas formas geométricas. No entanto, por entender que essa generalidade não seria de
grande utilidade e primando pela simplicidade, o modelo aqui proposto, da mesma forma que em
(Moura, 2001), limita a representação espacial de componentes de apresentação à forma
retangular.
34
Nesse momento, cabe comentar a respeito dos atributos open e close, que
determinam o comportamento de exibição de um componente de layout quando o
mesmo não se encontra ativo. Um componente de layout está ativo, se existe
algum objeto de execução a ele associado e sendo exibido, ou se alguma região
diretamente ou recursivamente contida nele tem algum objeto de execução a ela
associado e sendo exibido. Dessa forma, o atributo open determina se o
componente deve ou não ser exibido mesmo que ainda não tenha se tornado ativo
e o atributo close especifica se o componente deve continuar sendo exibido
mesmo depois que deixa de estar ativo.
A classe LayoutRegion, conforme descrito, é uma especialização de
LayoutComponent e é justamente o tipo de componente de layout ao qual os
objetos de execução estarão associados. Essa classe possui um atributo adicional
denominado fit. Esse atributo define o comportamento da região quando as suas
dimensões não coincidirem com as do conteúdo do objeto de execução associado
a ela. As possibilidades previstas pelo modelo são:
•
redimensionar o objeto para que suas dimensões coincidam com as da
região;
•
desenhar o objeto a partir do canto superior esquerdo da região e preencher
os espaços restantes com a cor de fundo da região, cortando as partes que
ultrapassem as dimensões da região e aplicando a política de rolagem
(scroll) definida;
•
desenhar o objeto a partir do canto superior esquerdo da região e
redimensioná-lo, conservando a proporção entre suas dimensões, até que
todo o objeto esteja visível na região e o espaço restante esteja preenchido
com a cor de fundo; ou
•
desenhar o objeto a partir do canto superior esquerdo da região e
redimensioná-lo, conservando a proporção entre suas dimensões, até que
toda região esteja ocupada pelo objeto. Para a área do objeto cortada, deve
ser
aplicada
a
LayoutComponent.
política
de
rolagem
definida
na
superclasse
35
A classe LayoutWindow é uma especialização de LayoutComponent que não
está contida em nenhum outro componente de layout e cujo conjunto de regiões
deve possuir pelo menos uma região especificada.
Retornando à questão da janela default no layout do documento, essa janela
é automaticamente criada pelo formatador e possui duas utilidades. Definir o
espaço para exibir objetos de execução de documentos que não possuam um
layout espacial especificado, assim como exibir os objetos de execução de
documentos que possuam um layout espacial especificado, mas para os quais o
identificador da região não possa ser encontrado nesse layout.
Uma vez que a região de layout está relacionada com as características
espaciais visuais da exibição de um objeto de execução, esse atributo é opcional
nos descritores. Objetos de áudio, por exemplo, podem dispensar a existência de
uma região, apesar de ser perfeitamente possível que se deseje exibir uma
representação visual da onda sonora.
Todo descritor possui, opcionalmente, além da ferramenta de exibição e da
região espacial, um conjunto de parâmetros de qualidade de serviço (objetos da
classe QoSParameters) que são deixados como pontos de flexibilização no
modelo e devem ser especificados em implementações particulares de
formatadores que saibam lidar com essas informações. Exemplos de atributos que
poderiam ser definidos em especializações da classe QoSParameters seriam:
latência máxima para o início da exibição do objeto, taxa de exibição desejável e o
mínimo tolerável, percentual de erro aceitável na entrega dos dados etc.
O
modelo
define
também
uma
classe
abstrata
ContentDependentParameters, que permite agrupar atributos relevantes para
exibição de tipos particulares de conteúdo. Um descritor pode possuir um ou mais
atributos dessa classe. Além disso, implementações de formatadores podem
estender a hierarquia para oferecer suporte a outros atributos. O modelo define a
subclasse SoundParameters, para reunir atributos relevantes para mídias sonoras
(áudio e vídeo), StyleParameters, para objetos que utilizem folhas de estilo (W3C,
1996; W3C, 1998a) na formatação de seu conteúdo, e TemporalParameters para
objetos que desejem possuir uma barra de controle visual do andamento da
exibição.
36
Cabe ao formatador, a partir da descrição da plataforma de exibição
(informação do contexto de exibição – Seção 2.1.2), realizar a associação entre os
descritores e os dispositivos físicos (monitor, monitor de TV, placa de som etc.).
Essa associação pode ser feita inclusive de modo distribuído, quando o ambiente
de execução for composto por mais de uma máquina. Além disso, o formatador
deve se preocupar em manter a consistência entre a ferramenta de exibição e o
descritor dos objetos de execução. Exemplo de inconsistência seria a definição de
um exibidor de imagem estática para um descritor de áudio.
2.3.1.3
Eventos
O evento é a unidade básica de sincronização definida no modelo de
execução, estando contido na lista de eventos do objeto de execução. A definição
de evento no modelo segue a proposta de Pérez-Luque (Pérez-Luque & Little,
1996), onde o mesmo é descrito como uma ocorrência no tempo que pode ser
instantânea ou durar um período de tempo. Sendo assim, existe no modelo de
execução dois tipos de eventos: aqueles que são instantâneos e aqueles que
apresentam duração não desprezível (não instantâneos). Os eventos também
podem ser classificados em relação à interação: eventos do tipo interativos
possuem sua ocorrência obrigatoriamente relacionada com alguma ação do
usuário, enquanto os eventos não interativos têm suas ocorrências desvinculadas
da interatividade do usuário, dependendo apenas do controle do próprio ambiente
de execução. Essas duas classificações dos tipos de evento podem ser combinadas.
Por
exemplo,
eventos
podem
ser
instantâneos/interativos,
não
instantâneos/interativos, instantâneos/não interativos e não instantâneos/não
interativos. Os exemplos para essas possibilidades ficarão mais claros ao longo da
seção.
Na Figura 7 é possível observar o diagrama de classes para as entidades do
modelo relacionadas à definição dos eventos. O modelo estabelece uma interface
EventInterface, a partir da qual derivam os quatro tipos de evento mencionados no
parágrafo
anterior:
NonInstantaneousEvent
e
InstantaneousEvent
para,
respectivamente, os tipos de evento não instantâneo e instantâneo, e
NonInteractiveEvent e InteractiveEvent para modelar, respectivamente, os eventos
37
do tipo não interativo e do tipo interativo. O modelo também define uma classe
Event, que implementa a interface EventInterface, a partir da qual derivam todas
as subclasses de evento do modelo, assim como novas subclasses que venham a
ser criadas.
Independente do tipo, existem duas subclasses de evento definidas no
modelo: eventos baseados em âncora (AnchorEvent) e eventos baseados em
atributo (AttributeEvent). Eventos baseados em âncora possuem um atributo que
identifica uma âncora do objeto de dados (fragmento do conteúdo do objeto de
dados), enquanto eventos baseados em atributo possuem um atributo que
identifica um outro atributo do objeto de execução. Entende-se por atributo de um
objeto de execução qualquer atributo diretamente definido no objeto ou que possa
ser alcançado pela navegação em profundidade a partir de seus atributos. Por
exemplo, tanto o atributo dataObject como o atributo descriptor.layoutRegion.top
podem ser definidos em um evento baseado em atributo.
Event
currentSt ate
occurrences
prepa re()
unpre pare()
start()
changeSt ate()
addEvent Listene r()
rem oveEventList ener()
Anchor
PresentationEvent
prepare()
prepared()
AnchorEvent
MouseClickEvent
MouseDragEvent
0..*
<<Interface>>
EventListener
update()
0..*
AttributeEvent
attributeId
FocusEvent
MouseOverEvent
ProgressiveA tt ribut ion Event
SimpleAttributionEvent
<<Interface>>
InstantaneousEvent
start()
<<Interface>>
NonInteractiveEvent
<<Interface>>
NonInstantaneousEvent
stop()
pa use()
resum e()
ab ort ()
Duration
expected
actual
<<Interface>>
Int erac tiveEve nt
getRepet itio ns()
setRepet itio ns()
getRepet itio nInterval()
setRepet itio nInterval()
start()
prepare()
<<Int erface>>
EventInt erface
Figura 7 – Diagrama de classes para os eventos.
Em uma implementação de formatador hipermídia, devem ser definidas
especializações das subclasses evento baseado em âncora e evento baseado em
38
atributo, que especifiquem semânticas para os eventos na apresentação do
documento. Algumas especializações já são definidas no próprio modelo, pois
serão necessárias em qualquer que seja o sistema hipermídia. A primeira
especialização é a classe evento de exibição (ou evento de apresentação) – classe
PresentationEvent, subclasse de evento baseado em âncora, cujo objetivo é
permitir especificar unidades básicas de sincronização associadas com a
apresentação de fragmentos dos conteúdos dos objetos de dados, ou seja, com a
apresentação dos subconjuntos de unidades de informação marcadas. A outra
especialização que deve existir em qualquer implementação de formatador é a
classe evento de seleção (MouseClickEvent), também subclasse de evento baseado
em âncora. Essa subclasse permite estabelecer sincronizações que dependam da
interação (clique, mais especificamente) do usuário sobre as âncoras dos objetos
de dados.
Além dessas duas principais classes, o modelo define outras especializações
que podem ser úteis em apresentações hipermídia. Evento de arraste (classe
MouseDragEvent), evento de foco (classe FocusEvent), evento de mouse sobre a
âncora (classe MouseOverEvent) são subclasses de evento baseado em âncora.
Para a classe de eventos baseados em atributos, o modelo define duas subclasses:
atribuição instantânea simples (SimpleAttribution), para permitir sincronizações
baseadas em valores dos atributos (ou mesmo mudança desses valores), e
atribuição progressiva (ProgressiveAttribution), para, por exemplo, definir
animações nas apresentações (Moura, 2001). Adicionalmente, novas classes
podem ser criadas em implementações particulares de formatadores, conforme as
necessidades dos documentos e de suas apresentações.
Qualquer que seja a especialização de evento, deve estar associada à
respectiva classe uma combinação dos tipos (ou interfaces) definidos no início
desta seção. Por exemplo, eventos de exibição, além de serem baseados em
âncora, são também eventos do tipo não instantâneo e não interativo. Eles são não
instantâneos porque sempre existe uma duração associada com a exibição da
âncora (mesmo que essa duração seja imperceptível para o usuário – um quadro de
vídeo, por exemplo). Além disso, eles são não interativos porque a exibição
39
efetiva independe da intervenção do usuário6. Os eventos baseados em ações do
usuário com o mouse são sempre interativos. Alguns podem ter duração (arraste,
foco, mouse-over) e outros podem ser instantâneos (clique).
Existe sempre uma máquina de estados associada ao evento, para qualquer
que seja a sua classe. Os estados e transições de estados, juntamente com os
valores de atributos dos eventos e do objeto de execução, formam a base para a
definição dos relacionamentos de sincronização, que serão detalhados na Seção
2.3.2. Além disso, toda ação executada durante a apresentação do documento é
feita sobre algum evento e, normalmente, reflete em uma transição na máquina de
estados desse evento.
As máquinas de estados dos eventos variam em função da classe de evento,
mas existem três estados que toda máquina obrigatoriamente deve possuir:
dormindo, preparado e ocorrendo. Intuitivamente, o evento encontra-se no estado
ocorrendo
quando
sua
semântica
na
apresentação
do
hiperdocumento
efetivamente acontece. Por exemplo, um evento de exibição entra no estado
ocorrendo quando o subconjunto de unidades de informação marcadas, definidas
pela âncora do evento, são apresentadas pela ferramenta de exibição. Os eventos
de atribuição permanecem no estado ocorrendo enquanto a operação de atribuição
durar. Os eventos instantâneos permanecem no estado ocorrendo por um tempo
infinitesimal (por exemplo, o instante do clique do usuário ou o instante da
atribuição). Diz-se que um evento ocorre toda vez que entra em seu estado
ocorrendo e denomina-se ocorrência do evento a fase em que o evento encontrase no estado ocorrendo.
Um evento no estado preparado encontra-se habilitado a mudar
instantaneamente para o estado ocorrendo. Por outro lado, o evento no estado
dormindo está impossibilitado de passar para o estado ocorrendo sem que antes
seja realizado um procedimento de preparação das suas unidades de informação
ou atributos, efetuada por uma chamada ao método prepare da classe Event. O
evento também pode ser colocado de volta no estado dormindo, através de uma
6
O conceito de não interatividade do evento está associado com o elemento que faz com que o
evento efetivamente mude de estado durante a execução do documento. Um vídeo pode ter a sua
apresentação condicionada à seleção de um botão por parte do usuário. No entanto, o evento de
exibição do vídeo permanece como não interativo, pois a sua exibição efetiva depende do controle
da ferramenta de exibição, e não do usuário.
40
invocação ao método unprepare, também definido na classe Event. O método
start coloca o evento no estado ocorrendo, desde que ele se encontre no estado
preparado. O comportamento padrão estabelece ainda que, quando o evento deixa
o seu estado ocorrendo, ele retorna para o estado preparado. O evento também
oferece um método setState, que pode ser útil em extensões da classe Event e do
funcionamento da máquina de estados.
Baseado na máquina de estados, todo evento possui dois atributos,
denominados estado corrente e ocorrências, cujos valores são utilizados pelo
formatador para coordenar a sincronização das apresentações. Como o próprio
nome sugere, o atributo estado corrente de um evento guarda o seu estado na
máquina em um dado momento. Já o atributo ocorrências conta o número de
vezes que o evento deixa o estado ocorrendo e retorna para o estado preparado.
Eventos do tipo não interativos (interface NonInteractiveEvent) também devem
manter dois atributos adicionais: repetições e tempo de espera entre repetições.
Repetições determina o número de vezes seguidas que ainda restam para que o
evento ocorra. Esse atributo pode conter um valor finito ou o valor indefinido, que
levará a uma execução cíclica do evento, até que a mesma seja interrompida. Toda
vez que um evento não interativo retorna para o estado preparado, o seu atributo
repetições deve ser consultado. Se o valor for maior que zero, uma nova chamada
ao método start deve ser realizada para que o evento ocorra novamente. O atributo
tempo de espera entre repetições define um intervalo de pausa entre as
ocorrências sucessivas. A interface NonInteractiveEvent também define duas
novas opções para os métodos prepare e start, que recebem como parâmetros os
valores para iniciar os dois novos atributos (repetições e tempo de espera entre
repetições) a serem mantidos.
Os eventos do tipo não instantâneos possuem a noção de duração associada.
A duração é tratada no modelo como uma classe que possui dois atributos:
duração esperada (expectedDuration) e duração efetiva (actualDuration). O
primeiro atributo (duração esperada) guarda o tempo previsto pelo formatador
para a próxima ocorrência do evento. A duração efetiva, por sua vez, guarda o
tempo efetivo da última ocorrência do evento. A duração esperada de um evento
pode ser especificada como indeterminada, quando o formatador não tiver como
prever o tempo para que o evento permaneça no estado ocorrendo.
41
Como uma classe do modelo, a duração pode ser estendida para representar
descrições temporais mais complexas. Por exemplo, uma subclasse de duração
pode ser especificada permitindo que os valores esperados sejam definidos como
intervalos. Outras subclasses podem possibilitar descrever as durações com
funções de custo (Bachelet et al., 2000; Buchanan & Zellweger, 1993b; Kim &
Song, 1995), oferecendo assim métricas para o ajuste das durações. Exemplos
dessas subclasses de durações mais flexíveis serão tratados no Capítulo 4, quando
será abordada a adaptação dos tempos elásticos dos documentos.
Os eventos não instantâneos também possuem dois novos estados definidos
em suas máquinas de estados: suspenso e abortado. Um evento é colocado no
estado suspenso, quando uma chamada a seu método pause é efetuada. O
resultado dessa chamada é a suspensão temporária da ocorrência do evento. O
método resume permite colocar o evento novamente no estado ocorrendo, a partir
do ponto em que a pausa foi realizada. A ocorrência de um evento pode também
ser abruptamente interrompida por uma invocação ao método abort. O resultado
dessa chamada é a transição do estado corrente do evento para o estado abortado
e, logo em seguida, para preparado. Nesse caso, o atributo ocorrências não é
incrementado e, sendo um evento do tipo não interativo, o atributo repetições é
colocado com valor igual a zero. O método stop dos eventos não interativos geram
a transição imediata do estado ocorrendo para o estado preparado, interrompendo
a ocorrência no ponto em que estiver, porém respeitando o comportamento dos
atributos ocorrências e repetições.
O método start dos eventos instantâneos modifica ligeiramente o método
start da superclasse Event, colocando o evento imediatamente de volta no estado
preparado.
A Figura 8 ilustra as máquinas de estados para os eventos definidos no
modelo. Conforme pode ser observado, os eventos de seleção e atribuição simples
compartilham uma mesma máquina mais simples. Uma máquina um pouco mais
complexa é compartilhada pelos eventos de foco, arraste, mouse sobre âncora e
atribuição progressiva. Uma terceira máquina, bastante similar à anterior, porém
com um estado adicional de preparação (estado preparando) é definida para o
evento de apresentação. Isso também torna necessária a redefinição do método
prepare na classe PresentationEvent, que coloca o evento no estado preparando e
42
não mais diretamente no estado preparado. Esse novo estado exige também a
criação de um método prepared, para colocar o evento no estado preparado. A
idéia é que a preparação para exibição de um objeto requer um procedimento de
busca das unidades de informação de seu conteúdo que não deve ser desprezado.
Normalmente, todos os demais eventos terão suas preparações dependentes da
preparação de algum evento de apresentação do documento.
start
prepare
dormindo
preparado
transição
instantânea
unprepare
abortado
transição
instantânea
dormindo
preparado
unprepare
abort
MouseDragEvent
MouseOverEvent
FocusEvent
ProgressiveAttributionEvent
abort
start
prepare
MouseClickEvent
SimpleAttributionEvent
ocorrendo
pause
ocorrendo
stop
start |
resume
suspenso
stop
PresentationEvent
unprepare
transição
instantânea
abortado
abort
abort
prepare
dormindo
prepared
preparando
abort
start
preparado
pause
ocorrendo
stop
suspenso
start |
resume
stop
Figura 8 – Máquinas de estados dos eventos7.
Os eventos são capazes de manter uma lista de objetos que os observam.
Esses objetos são notificados toda vez que ocorre uma transição na máquina de
estados do evento. Essa sinalização informa sempre o novo estado e o estado
anterior na máquina e é feita após os atributos estado corrente, ocorrências e,
quando existir, repetições, serem atualizados. Esse padrão de comportamento é
inspirado no design pattern denominado Observer (Gamma et al., 1995) e é
ilustrado na Figura 7. A interface EventListener define o tipo que deve ser
implementado pelas classes dos objetos que se interessem por observar os eventos.
7
Os nomes das transições estão em inglês na figura para refletir os nomes dos métodos definidos
nas classes e interfaces.
43
O método transitionUpdate é invocado no objeto observador sempre que o estado
corrente do evento tiver seu valor alterado. O método addEventListener e
removeEventListener permitem, respectivamente, que um objeto se inscreva ou se
retire do cadastro de observadores do evento8.
De acordo com o que foi definido na Seção 2.3.1, todo objeto de execução
possui uma lista de eventos. Nessa lista, devem encontrar-se apenas os eventos do
objeto de execução que participam em algum relacionamento no documento. Toda
lista deve possuir ao menos um evento de exibição (evento da classe
PresentationEvent), o qual identificará o conjunto completo de unidades de
informação do conteúdo do objeto de dados que serão apresentadas quando o
objeto de execução for exibido. Normalmente, esse evento referenciará o conteúdo
inteiro do objeto, mas nada impede que se deseje efetuar uma apresentação apenas
parcial do conteúdo. Nesse caso, o evento de exibição estará associado a uma
âncora interna do objeto de dados.
2.3.2
Elos
O elo é a entidade do modelo que possibilita a definição dos
relacionamentos entre os componentes de um documento, mais especificamente
entre os eventos definidos nos objetos de execução. Existem dois tipos de
relacionamento entre os eventos de um documento que podem ser especificados
no modelo, dando origem a duas especializações da classe elo. O primeiro tipo
corresponde a relacionamentos causais entre os eventos, onde uma asserção lógica
no elo especifica uma condição sobre determinados eventos, que quando satisfeita,
implica o disparo de ações sobre outros eventos. Essa forma de relacionamento é
definida em objetos da classe elo causal. O outro tipo de relacionamento
especifica restrições sobre os eventos, que devem ser satisfeitas durante a
apresentação do documento. Esse segundo tipo de relacionamento é especificado
utilizando objetos da classe elo de restrição.
8
Apesar desse mecanismo de observação e notificação estabelecer uma modelagem de
comportamento, que poderia ser definida no formatador, optou-se por inseri-la no modelo de
execução, entendendo que sua utilidade para reuso nas implementações é significativa.
44
A Figura 9 apresenta o diagrama de classes simplificado para os dois tipos
de elo do modelo. Todo elo possui a expressão do relacionamento contida em um
ponto de encontro (classe MeetingPoint), que é especializado em função da
subclasse de elo.
Link
MeetingPoint
1
1
1
ConstraintLink
1
CausalLink
CausalMeetingPoint
1
ConstraintMeetingPoint
1
1
1
1
1
Condition
1
Action
1
PropertyExpression
Figura 9 – Diagrama de classes simplificado para os elos.
2.3.2.1
Elos causais
Um elo causal possui como principal atributo um ponto de encontro causal
(classe CausalMeetingPoint). Esse ponto de encontro expressa uma regra de
causalidade, sendo constituído de uma condição (classe Condition) e uma ação
(classe Action). Conforme mencionado anteriormente, a satisfação da condição
implica no disparo da ação a ele associada. Tanto as condições como as ações de
pontos de encontro causais são associados a eventos dos objetos de execução. A
Figura 10 apresenta o diagrama detalhado para as classes relacionadas à definição
de elos causais.
A condição de um ponto de encontro, quando avaliada, retorna um valor
booleano e pode ser uma condição simples ou composta. Toda condição simples
(classe TransitionCondition), também chamada de condição de transição, possui
como atributos um evento E, um estado anterior (atributo previousState) e um
estado corrente (atributo newState). Esse tipo de condição avalia uma transição na
máquina de estados do evento E, retornando o valor verdade sempre que o estado
45
de E mudar do valor especificado pelo atributo estado anterior para o valor
especificado pelo atributo estado corrente.
CausalLink
CausalMeetingPoint
1
1
1
1
1
Action
waitDelay
2
Condition
delay
2
run()
1
1
evaluate()
CompoundAction
SimpleAction
operator
TransitionCondition
event
previousState
newState
event
CompoundCondition
AbsoluteAssignmentAction
newVa lue
Rela tiveAssignmentA ct ion
newValue
TransitionSimpleAction
newState
1
OrCompoundCondition
AndCompoundCondition
1
UnprepareAction
PrepareAction
1
Property
event
offset
StartAction
PropertyExpressi on
isNegated
minDelay
1
maxDelay
1
getValue() 1
StopA ct io n
2
PauseAction
evaluate()
ResumeAct ion
1
1
TransitionProperty
previousStat e
newStat e
comparisonOperator
1
AbortAction
CompoundPropertyExpression
logicalOperator
SimplePropertyExpression
EventAttributeProperty
attributeId
TransitionPropertyExpression
AttributeProperty
attributeId
1
Pro pertyToPropertyExpression
1
PropertyToValueExpression
value
Figura 10 – Diagrama de classes para o elo causal.
Para a definição de uma condição composta (classe CompoundCondition), é
necessário, inicialmente, definir o conceito de propriedade (classe Property).
Uma propriedade possui um atributo que identifica um evento E, podendo
ser especializada em uma das três subclasses: propriedade de transição (classe
TransitionProperty), propriedade de atributo de evento ou propriedade de atributo
genérico. A propriedade de transição possui, além do evento, dois atributos
adicionais que identificam os estados da transição (estado anterior e novo estado).
A diferença da propriedade de transição para a condição de transição é que,
quando avaliada, ao invés de retornar um valor booleano, a propriedade retorna o
instante em que a transição ocorreu. A propriedade de atributo de evento (classe
EventAttributeProperty) possui, além do evento E, o identificador de um atributo
de E (por exemplo, estado corrente, ocorrências, repetições, duração esperada
etc.). Quando avaliada, a propriedade retorna o valor corrente desse atributo. Por
fim, a propriedade de atributo genérico (classe AttributeProperty) é uma
46
especialização de propriedade, onde o evento E deve ser obrigatoriamente um
evento baseado em atributo. Essa subclasse de propriedade é similar à anterior,
retornando, sempre que avaliada, o valor do atributo referenciado por E. Toda
propriedade possui um atributo offset, que é somado ao seu valor quando a
propriedade é consultada. Evidentemente, essa soma pode não fazer sentido para
alguns atributos, como por exemplo, o estado corrente de um evento. Nesses
casos, o valor do atributo offset deve ser ignorado pelo formatador.
A propriedade de atributo de evento poderia ser especificada utilizando a
propriedade de atributo genérico. No entanto, isso obrigaria aumentar o número de
eventos na lista de eventos do objeto de execução, causando uma proliferação de
máquinas de estados no ambiente de execução. Por exemplo, para tratar o número
de ocorrências de um evento A, seria necessário criar um outro evento baseado em
atributo que referenciasse o atributo ocorrências de A. Por esse motivo, foi
definida uma classe de propriedade separada para tratar os atributos dos eventos.
Uma expressão de propriedades simples (classe SimplePropertyExpression)
permite comparar duas propriedades ou uma propriedade e um valor. Quando
avaliada, essa expressão retorna verdade se a comparação por ela definida for
satisfeita. Caso contrário, a expressão retorna falso. Dessa forma, toda expressão
de propriedades simples possui um atributo que identifica uma propriedade e um
outro atributo que identifica um operador de comparação (igual, diferente, menor
ou igual, maior ou igual, menor, ou maior). As expressões que comparam duas
propriedades (classe PropertyToPropertyExpression) possuem um terceiro
atributo que identifica uma segunda propriedade, enquanto as expressões que
comparam a propriedade a um valor (classe PropertyToValueExpression)
possuem um terceiro atributo que armazena o valor a ser comparado. O tipo desse
valor deve ser igual ao tipo do valor retornado pela propriedade. Da mesma forma,
na comparação entre duas propriedades, as duas devem retornar valores do mesmo
tipo.
Dependendo do tipo do atributo (genérico ou do evento) identificado pela
propriedade, alguns operadores de comparação podem não fazer sentido na
expressão de propriedades. Por exemplo, para o atributo estado de um evento só é
possível utilizar as comparações de igualdade e de diferença.
47
Outra subclasse de expressão de propriedades é a expressão de propriedades
composta (classe CompoundPropertyExpression). Essa última consiste em uma
expressão lógica binária, baseada nos operadores “E” e “OU”, envolvendo duas
expressões de propriedades (superclasse PropertyExpression).
Expressões de propriedades possuem um atributo denominado isNegated,
que determina o sinal da expressão. Esse atributo especifica se, após avaliada, o
valor retornado pela expressão deve ser ou não invertido (negado). Além disso,
toda expressão de propriedades possui dois atributos, minDelay e maxDelay, onde
minDelay deve ser menor ou igual a maxDelay e ambos os valores devem ser não
negativos. Esses atributos definem um intervalo de deslocamento para a avaliação
da expressão. Por exemplo, dado que uma expressão de propriedades P é
verdadeira em um instante t, uma outra expressão P’, definida com atributos
minDelay=”t1” e maxDelay=”t2” e a mesma expressão de P, é verdadeira no
intervalo dado por [t+t1, t+t2]. O sinal de negação da expressão deve ser aplicado
somente após essa avaliação.
Além das expressões de propriedades simples e compostas, o modelo define
uma terceira subclasse de expressão de propriedades, denominada expressão de
propriedade de transição, ou simplesmente expressão de transição (classe
TransitionPropertyExpression). Essa expressão contém uma propriedade de
transição e restringe o atributo maxDelay como devendo possuir um valor maior
que o valor do atributo minDelay. A expressão de transição permite definir
expressões de propriedades que se tornam verdadeiras durante um intervalo após a
transição na máquina de estados de um determinado evento. Esse tipo de
expressão permite que as ações dos elos causais estejam condicionadas a
intervalos onde não é garantido haver um estado de evento para ser testado. Por
exemplo, uma expressão de transição associada à mudança do estado ocorrendo
para o estado preparado de um evento de apresentação E, com atributos
minDelay=”10s” e maxDelay=”25s”, será considerada verdadeira somente 10
segundos após o término da ocorrência de E e permanecerá verdadeira durante os
15 segundos seguintes.
Uma condição composta consiste de uma expressão lógica binária, também
baseada nos operadores “E” e “OU”. A condição composta baseada no operador
“OU” (classe OrCompoundCondition) envolve duas condições (simples ou
48
composta), enquanto a condição composta baseada no operador “E” (classe
AndCompoundCondition) envolve uma condição (simples ou composta) e uma
expressão de propriedades. As definições apresentadas visam, ao mesmo tempo,
garantir que toda condição de um elo causal só possa ser satisfeita em um instante
de tempo infinitesimal e impedir a especificação de uma condição composta “E”,
contendo em cada lado da comparação condições que somente sejam satisfeitas
em instantes de tempo infinitesimais.
Opcionalmente, toda condição possui um atributo denominado retardo
(atributo delay). O atributo retardo é definido por um valor t. Quando definido em
uma condição C, a mesma é satisfeita em um instante de tempo t’, se a condição C
estiver satisfeita em um instante de tempo dado por (t’ - t).
Semelhante às condições, as ações de um ponto de encontro do elo causal
podem ser simples ou compostas. As ações oferecem um método run para que
sejam executadas e retornam um valor booleano, informando se foi possível ou
não realizar a sua execução.
Toda ação simples possui um atributo que referencia um evento (atributo
event). Essas ações podem ser de transição (classe TransitionAction), de atribuição
absoluta (classe AbsoluteAssignmentAction) ou de atribuição relativa (classe
RelativeAssignmentAction). Outras classes de ação podem ser criadas em função
da implementação do formatador.
Uma ação simples de transição possui como atributo o novo estado que o
evento deve assumir (atributo newState) em sua máquina de estados. Dependendo
do estado corrente do evento e das regras definidas pelo formatador, essa transição
pode ser ou não realizada. Subclasses para realizar as transições nas máquinas de
estados apresentadas na seção anterior são também definidas no modelo.
As ações de atribuição absoluta e relativa só se aplicam a eventos baseados
em atributo. Essas ações possuem como atributo o valor que deve ser atribuído
(absoluta) ou somado (relativa) ao atributo identificado pelo evento.
Uma ação composta é formada por uma expressão de ações baseada nos
operadores paralelo e seqüencial, definindo a ordem de execução de cada
elemento da ação. Além disso, toda ação, simples ou composta, possui um
atributo opcional denominado tempo de espera (atributo waitDelay). Esse atributo
define um tempo que deve ser aguardado antes que a ação seja executada. Da
49
mesma forma que a duração do evento, esse atributo é especificado através de um
objeto da classe duração (classe Duration), que pode inclusive ser flexível,
cabendo ao formatador escolher um valor para o tempo de espera que garanta ao
documento a melhor qualidade de apresentação possível.
De acordo com o que foi apresentado, os elos causais especificam condições
sobre eventos (normalmente transições nesses estados) que, quando satisfeitas,
devem disparar ações sobre outros (às vezes até os mesmos) eventos especificados
no documento. São justamente essas ações que irão ocasionar novas transições nas
máquinas de estados dos eventos. A seguir são ilustrados como alguns exemplos
de relacionamentos hipermídia seriam representados internamente no ambiente de
execução.
Exemplo 1
Suponha uma apresentação com um objeto de execução V1 contendo um
vídeo e um outro objeto A1 contendo um áudio, onde se deseja que o áudio seja
apresentado apenas durante um determinado trecho do vídeo, identificado por um
evento de exibição ev1. Considere que ea1 é o evento de exibição que corresponde
à apresentação de todo o objeto A1 e que a máquina de estados para os eventos de
exibição é a mesma ilustrada na Figura 8. A Tabela 1 apresenta a representação
gráfica do relacionamento e os elos causais que seriam criados no formatador.
V1
Elo
Expressão do Relacionamento
L1
ev1(preparado, ocorrendo) => start(ea1)
L2
ev1(ocorrendo, preparado) => stop(ea1)
A1
ev1
L1
L2
ea1
Tabela 1 – Sincronização temporal através de elos causais.
Exemplo 2
Esse exemplo ilustra como composições com semântica de relacionamentos
de sincronização podem ser mapeadas em elos causais. Seja uma composição
seqüencial com dois vídeos, V1 e V2, que devem ser exibidos nessa ordem. Os
eventos ev1 e ev2 correspondem à apresentação de todo o conteúdo de cada um dos
objetos, respectivamente. A Tabela 2 apresenta a representação gráfica da
composição e como o relacionamento entre seus componentes seria expresso por
uma causalidade entre eventos.
Composição
SEQ1
ev1(ocorrendo, preparado) => start(ev2)
50
V1
V2
SEQ1
Tabela 2 – Sincronização temporal através de elos causais, a partir de uma especificação
de sincronização utilizando composições.
Exemplo 3
Sejam dois objetos de execução: uma imagem I1 do mapa do Brasil e um
texto T1 com informações sobre o estado do Rio de Janeiro. Deseja-se que, quando
o usuário selecionar com o mouse o estado do Rio de Janeiro em I1, seja
apresentado T1 ao lado da imagem, com largura de 150 pixels e altura de 200
pixels. Esse relacionamento pode ser especificado entre um evento de seleção ei1,
definido em I1 sobre a região do Rio de Janeiro, e o evento de apresentação et1,
correspondendo à exibição de T1. As características espaciais da apresentação
estariam definidas na região apontada pelo descritor de T1. A Tabela 3 ilustra o
relacionamento descrito e a especificação do elo.
Elo
L1
ei1(preparado, ocorrendo) =>
start(et1)
T1
I1
O Estado do
Rio de Janeiro
200 pixels
150 pixels
ei1
seleção
Tabela 3 – Sincronização espacial e temporal através de elo causal.
Conforme
discutido
na
Seção
2.2,
relações
de causa e efeito
(condições/ações) não são suficientes para determinar todas as relações existentes
entre componentes de um documento hipermídia. Existem relações que,
semanticamente, especificam restrições (constraints) entre eventos, tais como:
dois objetos devem terminar suas exibições ao mesmo tempo. A definição desses
tipos de relacionamentos é capturada pela classe elo de restrição.
51
2.3.2.2
Elos de restrição
Um elo de restrição é um elo cujo ponto de encontro, ao invés de definir
uma regra causal, especifica restrições entre eventos. Mais especificamente, o
ponto
de
encontro
possui
uma
expressão
de
propriedades
(classe
PropertyExpression). A expressão de propriedades tem a mesma definição dada
na seção anterior, quando da especificação de condições compostas do ponto de
encontro de um elo causal. No entanto, por não fazer sentido considerar algumas
das expressões nos elos de restrição, o modelo estabelece algumas imposições.
Em primeiro lugar, não é permitido o uso de expressões de transição nos elos de
restrição. Além disso, o atributo isNegated da expressão deve ser sempre falso e
os atributos minDelay e maxDelay devem ser sempre iguais a zero. Caberá a cada
implementação particular de formatador aumentar ainda mais as observações
restritivas para aquelas expressões de propriedades que a máquina não souber, ou
não fizer sentido, monitorar.
Os elos de restrição estipulam regras que o formatador deve procurar
garantir que sejam respeitadas durante a execução do documento. Como exemplo
de ponto de encontro de restrição, suponha uma propriedade de transição P,
especificando a transição “preparado->ocorrendo”, representando o instante de
início da ocorrência de um evento de exibição A, e uma outra propriedade Q,
especificando a transição “ocorrendo->preparado”, representando o instante de
término da ocorrência de um outro evento de exibição B. Se uma expressão de
propriedades S1 definir que “P = Q”, isso implica que a relação meet de Allen
(Figura 2) deve ser satisfeita na execução do documento como uma relação
restritiva. Ou seja, se e somente se os dois eventos de exibição ocorrerem na
apresentação, o final de A deve coincidir com o início de B. Caso um dos dois
eventos não ocorra, o modelo considera que a restrição foi satisfeita.
A impossibilidade de respeitar as regras de restrição significa que existe
uma inconsistência na apresentação especificada pelo autor. Essa inconsistência
pode ser causada pelas próprias relações definidas internamente no documento, ou
pelo cenário imposto pelo contexto de exibição, externo ao documento. As
referências (Felix et al., 2002; Santos et al., 1998a; Santos et al., 1998b) discutem
aspectos de verificação de consistência em apresentações hipermídia.
52
2.3.3
Suporte à adaptação no modelo de execução
O modelo de execução proposto dispõe de alguns recursos para oferecer
suporte à adaptação das apresentações. O primeiro tipo de suporte reside na
maneira flexível que as durações são definidas, tendo sido comentado
anteriormente. O modelo permite que os tempos de um modo geral (duração dos
eventos de apresentação, intervalo entre repetições, tempo de espera para executar
ações etc.) sejam especificados através de intervalos e até mesmo métricas
(funções de custo), possibilitando a aplicação de algoritmos de ajuste dos tempos
elásticos, como será melhor explicado no Capítulo 4.
O segundo suporte que o modelo oferece para a adaptação dos
hiperdocumentos são as regras de exibição (classe PresentationRule). Apesar de
omitida na Seção 2.3.1.2, a regra de exibição é um atributo opcional dos
descritores e estabelece uma condição para que os objetos de execução
efetivamente participem da exibição do documento.
Além dos descritores, os elos também possuem como atributo opcional uma
regra de exibição que, quando não satisfeita, deve gerar a remoção do
relacionamento do documento. Nada impede que uma mesma regra seja
referenciada por mais de um descritor e mais de um elo. A Figura 11 ilustra o
diagrama de classes para as regras de exibição.
0. .*
Descriptor
0..1
Pres entationRule
2
0..1
Link
0..1
Com poundP resentationRule
logic alOperator
0..*
S im p leP res entati onRule
at ributeId
c om paris onOperator
value
Figura 11 – Diagrama de classes para as regras de exibição.
Baseado nas informações contextuais, o formatador hipermídia deve avaliar
cada uma das regras e com isso determinar se as entidades devem ou não estar
53
presentes na execução do documento. Diz-se que um objeto de execução ou elo
está desabilitado, quando a regra de exibição a ele associada é avaliada como
falsa. Caso contrário a entidade é considerada habilitada. Cabe a cada
implementação particular de formatador decidir o momento em que as regras
serão avaliadas, definindo assim se a adaptação seguirá uma estratégia estática ou
dinâmica (Seção 2.1.3). É inclusive possível que as duas estratégias sejam
combinadas em função dos parâmetros que estejam sendo testados. Nada impede
também que, em estratégias de adaptação dinâmica, algumas regras sejam
avaliadas mais de uma vez, podendo alterar o estado de habilitação das entidades
durante a exibição dos documentos.
As regras de exibição são sempre baseadas em parâmetros do contexto de
exibição. Em implementações de formatadores que não disponham de um
gerenciador de contexto, ou que o gerenciador não saiba informar o valor do
parâmetro sendo testado, as regras devem ser simplesmente ignoradas e todas as
entidades devem ser consideradas habilitadas na execução do documento. Da
mesma forma, objetos de execução e elos que não tenham uma regra de exibição a
eles associada são sempre considerados habilitados.
Com relação à consistência do documento, sempre que um objeto de
execução deve ser desabilitado em uma apresentação, alguns cuidados devem ser
tomados com os relacionamentos. Em primeiro lugar, ações de elos causais que se
apliquem a algum evento contido no objeto devem ser ignoradas. Implementações
de formatadores podem inclusive desabilitar os elos cujas ações estejam definidas
apenas sobre eventos contidos em objetos desabilitados. O segundo ponto diz
respeito às expressões de propriedades, tanto nos elos de restrição como nas
condições dos elos causais. Expressões de propriedades simples que possuam uma
propriedade cujo evento esteja contido em um objeto desabilitado devem ser
consideradas verdadeiras quando avaliadas.
As regras de exibição podem ser simples ou compostas. Uma regra de
exibição simples (classe SimplePresentationRule) é análoga à expressão que
compara uma propriedade a um valor (Figura 10) e possui três atributos: o
identificador de um atributo do contexto de exibição, um operador de comparação
e um valor. A regra de exibição composta (classe CompoundPresentationRule),
por sua vez, é uma expressão lógica binária envolvendo duas regras de exibição
54
(simples ou composta) relacionadas através do operador “E” ou do operador
“OU”.
O terceiro e último recurso que o modelo oferece para a adaptação das
apresentações são as alternativas de exibição. A alternativa é definida como uma
especialização de objeto de execução (classe ExecutionObjectAlternatives) cujos
atributos (identificador, objeto de dados, descritor e lista de eventos) não estão
ainda todos definidos. Adicionalmente, toda alternativa de exibição possui um
segundo identificador único, um conjunto de pontos de interface, um objeto de
execução default opcional, uma lista ordenada de regras de exibição e, para cada
regra da lista, um objeto de execução associado.
Na execução do documento, o formatador deve seguir a ordem da lista e
avaliar as regras para cada alternativa. Para o primeiro objeto de execução que
tiver a regra associada satisfeita, o formatador deve utilizar todos os seus atributos
(identificador, objeto de dados etc.) para preencher os atributos não resolvidos da
alternativa. Diz-se que o objeto de execução escolhido é o objeto selecionado.
Nesse momento, é como se a alternativa deixasse de existir e fosse substituída
pelo objeto de execução escolhido. Caso a lista inteira seja percorrida sem que
nenhuma regra venha a ser satisfeita, o objeto de execução default da alternativa
deve ser selecionado. Não havendo um objeto default, nenhum dos objetos de
execução devem ser considerados na apresentação do documento. O modelo
permite que alternativas sejam definidas de modo aninhado (alternativa contida
em outra alternativa). A Figura 12 ilustra as classes relacionadas à definição de
alternativas no modelo.
Como pode ser percebido na figura, a alternativa possui também um
identificador adicional (atributo uid). Esse atributo permite identificar a alternativa
no ambiente de execução e deve ser diferente dos identificadores de todos os
outros objetos de execução presentes no formatador. Além disso, a alternativa
também herda o identificador único da classe ExecutionObject. Esse identificador
irá possui o valor do identificador do objeto de execução que vier a ser
selecionado.
Os pontos de interface das alternativas (classe InterfacePoint), de acordo
com o diagrama da figura, são instâncias de uma subclasse de evento. Similar à
própria alternativa, o ponto de interface é um evento que ainda não foi preenchido
55
com os seus atributos. Todo ponto de interface contém uma lista de mapeamentos
(atributo mapList), onde é definido, para cada objeto de execução OE contido na
lista das alternativas, uma associação com algum evento do conjunto de eventos
de OE. Quando um objeto de execução é selecionado, os mapeamentos dos pontos
de interface para eventos do objeto selecionado são também escolhidos para
compor a lista de eventos da alternativa.
Prese ntation Rul e
ExecutionObject
event List
Event
1
1.. *
1..*
1.. *
0..1
0..*
defaultAlte rnat ive
1
0.. *
mapL ist
ExecutionObjectAlternatives
uid
ipSet
1
InterfacePoint
1..*
Figura 12 – Diagrama de classes para as alternativas de objetos de execução.
A definição de ponto de interface serve para que relacionamentos (elos) no
modelo possam ser especificados não apenas entre objetos de execução
tradicionais, como também entre alternativas de objetos, como ilustra a Figura 13.
O modelo permite ainda que um mesmo objeto de execução esteja contido em
mais de uma alternativa. Além disso, nada impede que alguns elos sejam definidos
no modelo diretamente conectados a um objeto de execução que esteja inserido
em uma alternativa. Quando o objeto não for selecionado, esses relacionamentos
serão provavelmente ignorados na execução do documento.
56
Objetos de Execução
Y
Elos
X
Ponto de Interface
Evento
Mapeamentos
A
B
C
Alternativa
Objetos de
Execução Alternativos
Figura 13 – Alternativas de objetos, pontos de interface e elos.
Da maneira como são definidas no modelo as alternativas de objetos, os
pontos de interface e as extremidades dos elos, é possível implementar nos
formatadores mecanismos de adaptação das relações (2.1.1.2). Para isso, basta
colocar em uma mesma alternativa cópias de um mesmo objeto de execução com
diferentes elos associados aos seus eventos. A única restrição é que cada cópia de
objeto seja tratada como um objeto de execução diferente, definindo um novo
identificador único. A Figura 14 oferece um exemplo de uso das alternativas para
adaptar as relações. No exemplo, o elo que exibe o objeto de execução Z só estará
habilitado no documento se a alternativa A’, cópia de A, for o objeto de execução
selecionado.
57
Y
X
Z
A
Elo ignorado se
a alternartiva A’
não for
selecionada
A´
Figura 14 – Suporte à adaptação de relações no modelo.
Assim como para as regras de exibição, é critério do formatador e de suas
políticas de adaptação definir o momento em que deve ser feita a avaliação de
cada uma das alternativas.
2.3.4
Agrupamentos de objetos de execução e relacionamentos
O modelo define uma classe Container, que reúne um conjunto de objetos
de execução (atributo executionObjects), um conjunto de elos causais (atributo
causalLinks) e um conjunto de elos de restrição (atributo constraintLinks),
conforme ilustrado na Figura 15.
Container
Executi onObject
0..*
Causa lLink
1.. *
getExecutionObjects()
1 getCausalLinks()
getConstraintLinks()
exec utionObjects addExecutionObject()
addCausalLink()
addConstraintLink()
removeExecutionObject()
removeCausalLink()
removeConstraintLink()
1
causalLinks
constrai ntLink s
1
ConstraintLink
0..*
Figura 15 – Diagrama de classes para o contêiner.
Além dos atributos, o contêiner oferece um conjunto de métodos para
navegação em sua estrutura, para inserção e para remoção de elementos (objetos
de execução e elos). Os elos causais e de restrição são mantidos separadamente no
58
contêiner, para favorecer implementações de funções de formatação que
necessitem manipular os diferentes tipos de relacionamentos de maneira seletiva.
O formatador hipermídia irá lidar com instâncias da classe Container para
constituir o plano de controle da apresentação dos documentos. Os contêineres
podem ser criados externamente ao ambiente de execução, por um ambiente de
autoria que trabalhe com uma abstração de modelo idêntica ao modelo de
execução, e passados diretamente como parâmetros para o formatador. A outra
opção, já comentada na Figura 3, é ter o contêiner instanciado no formatador, a
partir de um processo de conversão que traduz um outro modelo de documentos
hipermídia no modelo proposto nesta seção.
Um documento no formatador pode ser resultado de um único contêiner ou
de uma coleção deles. Quando originado de mais de um contêiner, nada impede
que os mesmos sejam entregues (pelo ambiente externo ou pelo conversor)
paulatinamente, permitindo que o plano de execução de um documento seja
construído aos poucos. Esse recurso permite ao formatador tratar documentos de
outros modelos que não apresentem claramente uma delimitação de início e fim da
apresentação, como é o caso dos documentos na Web. Páginas HTML, ao
possuírem os elos embutidos nos seus conteúdos e permitirem que esses elos
referenciem qualquer outro recurso na rede, geram teias de relacionamentos que
podem se expandir por uma quantidade imensa de nós. Mesmo em modelos (ou
linguagens) que exploram o conceito de composição e definem as fronteiras para
os documentos, a divisão em contêineres, e de forma progressiva, também pode
ser útil, pois para os documentos mais extensos pode não ser viável construir a
estrutura de execução completa antes de iniciar a exibição dos objetos.
O conceito de contêiner é análogo ao conceito homônimo definido no
padrão MHEG (ISO/IEC, 1996). No entanto, no padrão MHEG essa entidade foi
definida para transportar conjuntos de nós e elos de servidores para clientes
hipermídia, enquanto no modelo de execução, esse conceito é definido na
interface (API – Application Program Interface) para interação com os
formatadores. As duas abstrações podem até conviver em uma implementação de
cliente MHEG que siga o modelo de execução proposto nesta seção e a arquitetura
de execução que será apresentada nos próximos dois capítulos.
Formatadores e Ferramentas de Exibição Hipermídia
59
3
Como já definido no Capítulo 1, o formatador é a entidade em um sistema
hipermídia responsável por controlar a apresentação dos hiperdocumentos,
baseando-se nas suas respectivas especificações e também, sempre que possível,
na descrição do contexto de exibição (banda passante, recursos de E/S disponíveis
no cliente, perfil e preferências do usuário etc.). Este capítulo destina-se a analisar
as principais funcionalidades desejáveis de serem encontradas em um ambiente de
execução hipermídia, partindo-se de um modelo de documentos orientado a
eventos e adaptativo como o apresentado na Seção 2.3. É importante lembrar que,
apesar deste trabalho tratar apenas da formatação no lado cliente, várias das
funcionalidades discutidas neste capítulo podem ser desempenhadas também em
servidores ou mesmo proxies hipermídia.
Além das características mencionadas na Seção 2.2 como sendo desejáveis
de serem encontradas nos modelos de documentos hipermídia, as quais devem ser
previstas e suportadas pelo formatador, é importante observar que existem
também características de projeto e implementação interessantes de estarem
presentes nos formatadores hipermídia.
Em primeiro lugar, é apropriado que haja uma independência entre os
formatadores e as ferramentas de exibição (Seção 1.1), de tal modo que seja
facilitada a incorporação no sistema de novas ferramentas, e também de
ferramentas já existentes e disponíveis em outros sistemas. Tais ferramentas
devem oferecer interfaces que permitam ao usuário interagir com os conteúdos
dos objetos e ao mesmo tempo essas interações devem refletir no controle
realizado pelo formatador. É também interessante que, para conteúdos dinâmicos
(áudio e vídeo, por exemplo), o usuário possa modificar o ponto de exibição
arbitrariamente e essa alteração refletir nos relacionamentos de sincronização do
documento.
60
O segundo recurso desejável, cuja importância foi levantada nos Capítulos 1
e 2, é a existência de mecanismos capazes de adaptar as apresentações às
restrições impostas pelo autor e ao contexto de exibição da aplicação hipermídia.
Nesta tese, além dos ajustes elásticos das durações dos objetos, serão também
tratados os aspectos de adaptação ao contexto de exibição em que o formatador
executa (Seção 2.1.2), com ênfase na adaptação à plataforma. O modelo proposto
(Seção 2.3.3) também contempla adaptações simplificadas dos elos e adaptações
relacionadas ao interesse do usuário, apesar desses não serem o foco do trabalho.
A terceira funcionalidade de grande utilidade para um formatador
hipermídia é a presença de um mecanismo de pré-busca dos conteúdos dos objetos
e de antecipação às ações de exibição. Esse recurso possibilita melhorar a
qualidade das apresentações e reduzir a carga de processamento exigida dos
mecanismos de adaptação.
Por fim, é interessante que o formatador hipermídia explore, sempre que
possível, facilidades de negociação e reserva de recursos que estejam disponíveis
na infra-estrutura de execução, atuando como um usuário desses serviços com
reserva, novamente visando melhorar a qualidade das apresentações e reduzir a
carga de processamento exigida dos mecanismos de adaptação.
Este capítulo apresenta a estrutura básica para organização do formatador e
acomodação dessas funcionalidades e também analisa detalhadamente a questão
da integração do formatador com as ferramentas de exibição. As outras
funcionalidades desejáveis (pré-busca, negociação de QoS e adaptação) serão
discutidas no capítulo seguinte.
3.1
Estrutura básica de um formatador hipermídia
A Figura 16 apresenta os principais componentes que integram um
formatador hipermídia ideal, destacando também alguns dos elementos externos a
ele, com os quais é mantida uma maior interação. De fato, a figura oferece uma
visão mais detalhada do ambiente de execução apresentado na Figura 1.
A primeira etapa na apresentação de um hiperdocumento é a chegada de
uma solicitação para o início da sua exibição, na qual a descrição do documento
(ou parte dele) é passada como parâmetro (seta 1, na Figura 16). Essa descrição
61
pode ser proveniente tanto do ambiente de autoria como do ambiente de
armazenamento (Figura 1), no caso de um documento já previamente publicado
no servidor. Vale ressaltar que o formatador pode receber o documento inteiro ou
em partes, de maneira incremental.
Formatador
Conversor
2
Orquestrador de Apresentação
Compilador
1
4
Ferramentas de
Exibição
9
Executor
3
10
Plano de Execução
Título
Imagem
Imagem
Versos 01
Versos 02
Im
Versos 03
Vídeo
Versos 04
Versos 05
Música (Coisa de Pele)
Início
Adaptador
7
Compilador
Orquestrador de Pré-Busca
Compilador
Executor
12
Executor
Gerenciador
da
Orquestração
Intra-mídia
Intra-mídia
8
Proxy de
Informações
Contextuais
Plano de Pré-busca
5
6
Gerenciador
de Contexto
11
Gerenciadores de
Recursos de Comunicação
e Processamento
Figura 16 – Principais elementos que compõem um formatador hipermídia.
Na especificação do hiperdocumento serão encontradas, entre outras
informações, a descrição dos nós que compõem a apresentação, a descrição dos
relacionamentos entre esses nós (relacionamentos de estruturação, sincronização,
alternativas etc.) e a descrição das características para a exibição de cada um dos
nós. Se essa especificação não estiver de acordo com o modelo de execução
esperado pelo formatador, ela deve ser antes entregue a um módulo conversor
para transformá-la em uma descrição que siga o modelo de contêineres de objetos
de execução e elos, descrito na Seção 2.3 (seta 2). É justamente essa etapa de
conversão que permite que o ambiente de execução controle a exibição de
documentos provenientes de diferentes modelos hipermídia. Evidentemente,
algumas características do modelo de documentos de entrada podem ser perdidas,
se as mesmas não puderem ser mapeadas no modelo de execução.
62
Para auxiliar na coordenação da apresentação, o formatador normalmente irá
construir um plano de execução (ou plano de escalonamento), a partir da estrutura
de dados de entrada (montada externamente ou pelo módulo conversor). Dentre as
informações que devem estar contidas nesse plano, destacam-se as previsões das
durações de ocorrência dos eventos não instantâneos, principalmente os eventos
de exibição, e os instantes de tempo esperados para exibição dos vários objetos de
execução. No entanto, é importante que o plano não seja um simples timeline
dessas ações, mas sim que preserve as relações de dependência entre os objetos,
pois isso irá favorecer sua manutenção, quando da aplicação das técnicas de
adaptação durante a exibição do documento. Por exemplo, se as unidades de
informação do conteúdo de um objeto não forem exibidas no instante previsto (ou
com a duração prevista) por motivo de um congestionamento na rede, conhecendo
as relações de dependência, o formatador pode tentar ajustar as durações dos
eventos de exibição diretamente afetados, buscando assim recuperar a
sincronização da exibição, sem a obrigação de refazer todo o plano de execução a
partir da adaptação efetuada. Portanto, é importante que o plano de execução
mantenha um vínculo com as informações descritas nos relacionamentos de
causalidade e de restrição entre os objetos especificados no modelo de execução.
Também é importante que o plano de execução mantenha as informações
referentes às regras de exibição e às alternativas para os parâmetros dinâmicos do
contexto de exibição. Na verdade, o plano de execução complementa as
informações contidas no modelo de execução, buscando favorecer os mecanismos
de escalonamento e adaptação. A etapa em que o plano de execução é ao menos
parcialmente construído, antes que os objetos comecem a ser exibidos, é
denominada fase de compilação do documento, sendo a construção desse plano
(seta 3, na figura) responsabilidade do submódulo compilador, no orquestrador de
apresentação.
O compilador de apresentação espera como entrada contêineres do modelo
de execução (Seção 2.3.4) e, assim como os conversores do ambiente de
execução, também pode receber os dados de maneira progressiva.
Retornando à questão do cálculo das durações e tempos esperados, é
importante salientar que podem existir objetos de execução para os quais o
compilador de apresentação não consiga definir a priori os instantes de exibição
63
esperados, pois nem sempre a apresentação de um objeto é previsível. A idéia de
previsibilidade de apresentação de um objeto está associada com a previsibilidade
do evento de exibição correspondente, que por sua vez é sempre relativa a algum
outro evento da apresentação ou ao início da apresentação como um todo.
Uma estratégia interessante para a construção do plano de execução é seguir
a proposta do sistema Firefly (Buchanan & Zellweger, 1992) e estabelecer as
cadeias temporais do documento. Nessa proposta, uma cadeia é denominada a
principal e corresponde à seqüência de exibições previsíveis que começa com o
próprio princípio da apresentação de um documento. Além disso, zero ou mais
cadeias temporais auxiliares podem existir, cada uma sendo iniciada por uma
transição imprevisível na máquina de estados de algum evento do documento e
disparando uma seqüência de exibições previsíveis em relação a essa transição.
Seguindo essa abordagem, o compilador de apresentação irá calcular, para cada
cadeia temporal, os instantes de tempo esperados de uma maneira relativa ao
início da cadeia. Note assim que o plano de execução é de fato uma estrutura de
dados que reflete as diversas cadeias temporais.
Durante a fase de compilação da apresentação, se o modelo hipermídia
permitir (ou seja, oferecer informações flexíveis), estratégias de adaptação, tais
como ajuste de tempo dos objetos e escolha entre múltiplas opções de
apresentação (por exemplo, opções de resolução, de dimensão, de idioma, tipos de
mídia etc.), podem ser acionadas para encontrar a configuração que atenda as
restrições do autor e ao mesmo tempo ofereça a melhor qualidade de exibição para
o contexto em questão. Para tanto, o compilador de apresentação deve requisitar
os serviços do módulo adaptador (seta 4), que por sua vez pode precisar consultar
as informações do contexto de exibição (seta 5), antes de acionar seu submódulo
compilador. O resultado da adaptação é então refletido no plano de execução. Para
as alternativas que não possam ser resolvidas na fase de compilação, o compilador
de apresentação deve deixar indicado no plano de execução a existência de um
conjunto de alternativas e criar uma nova cadeia temporal auxiliar onde sejam
colocados os objetos cujas exibições dependam dessa adaptação dinâmica.
Nesse momento, é importante comentar a existência no formatador do
módulo denominado proxy de informações contextuais. A idéia dessa proposta é
encapsular nesse elemento a responsabilidade de buscar as informações junto ao
64
gerenciador de contexto (seta 6). A presença do proxy oferece uma interface única
para os demais componentes do formatador e desobriga que esses componentes
conheçam o protocolo para consulta às informações contextuais, em especial as
dinâmicas. Essa separação é interessante principalmente pela variedade de
cenários e protocolos que podem vir a reger esse tipo de consulta, pois o proxy
pode necessitar dialogar com mais de um gerenciador (informações do sistema
operacional, informações da rede, informações do usuário etc.) e combinar o uso
de diferentes protocolos e estruturas de dados. No entanto, nada impede que em
cenários mais simples, o proxy seja, na realidade, o próprio gerente de contexto.
A existência de um mecanismo de pré-busca no formatador é importante
para minimizar os retardos no início das exibições dos objetos e compensar as
variações nas taxas de exibição dos objetos de mídia contínua. Torna-se então
conveniente a construção de um plano de pré-busca a partir do plano de execução
(setas 7 e 8), antecipando as ações especificadas no documento. Essa tarefa é
realizada pelo módulo orquestrador de pré-busca, na Figura 16. Na construção do
plano de pré-busca, também serão extremamente úteis informações que estejam
disponíveis a respeito do contexto de exibição, tais como banda passante
disponível e probabilidades de navegação (seta 5, na figura).
Uma vez iniciada a exibição dos objetos, o formatador entra na fase de
execução, coordenada pelo submódulo executor do orquestrador de apresentação.
O executor de apresentação é o elemento responsável por monitorar a
apresentação do documento, instanciando e interagindo com as ferramentas
responsáveis pela exibição dos objetos (seta 9, na Figura 16). Cabe ao executor
escalonar as ações a fim de cumprir o plano de execução definido pelo
compilador. Além disso, toda vez que um evento imprevisível ocorrer, como a
interação do usuário, se houver uma cadeia temporal auxiliar iniciada por esse
evento, essa cadeia deve ser unida à cadeia temporal principal, gerando as devidas
correções no plano de execução. É também responsabilidade do executor de
apresentação monitorar os instantes de tempo em que as ações efetivamente
ocorrem e comparar com os tempos originalmente previstos. Sempre que o
executor perceber diferenças, é desejável que o módulo de adaptação seja
acionado a fim de realizar os ajustes possíveis de serem aplicados. O módulo de
adaptação, por sua vez, pode precisar consultar as informações dinâmicas do
65
contexto de exibição (seta 5), antes de acionar seu submódulo executor, de forma
análoga à fase de compilação.
Cabe aqui ressaltar a existência, no módulo de adaptação, de tanto um
submódulo compilador como um executor. Normalmente, as estratégias de
adaptação executadas no momento da compilação do documento podem demorar
um tempo maior para gerar o seu resultado. Na realidade, várias das funções de
compilação podem inclusive ser realizadas horas, ou mesmo dias, antes da
apresentação. Pode ser inclusive interessante que algumas dessas tarefas sejam
desempenhadas em tempo de autoria, numa fase denominada de pré-compilação
(Rodrigues et al., 1997), oferecendo um recurso na ferramenta de edição que pode
ser útil, por exemplo, para tornar mais ágil a identificação de apresentações
inconsistentes (apresentações para as quais não é possível gerar um plano de
execução). Por todas essas razões, os algoritmos de compilação, principalmente os
algoritmos de adaptação, podem apresentar uma maior complexidade, buscando
em contrapartida gerar um resultado mais próximo da qualidade ideal de exibição.
Após iniciada a exibição, os algoritmos de controle executados no
formatador precisam oferecer resultados quase que imediatos. Nesse sentido, os
algoritmos de ajuste são críticos, pois eles são requisitados não apenas para
corrigir erros e atrasos nos sistemas de comunicação e processamento, como
também lidar com os eventos imprevisíveis (principalmente interações do usuário)
inerentes aos modelos hipermídia. A própria união de uma cadeia temporal
auxiliar à cadeia principal irá resultar em novos cálculos e, provavelmente, na
necessidade de novas adaptações. Por esses motivos, os algoritmos de compilação
podem não se mostrar adequados para a fase de execução, exigindo novas técnicas
e heurísticas para as estratégias de controle e ajuste.
O submódulo executor de adaptação deve também cuidar de monitorar os
parâmetros dinâmicos do contexto de exibição, avaliando (ou reavaliando) as
regras de exibição e as alternativas de objetos de execução, para que os resultados
dessas avaliações sejam refletidas no plano de execução.
Apesar da maioria das interações do orquestrador de apresentação com a
gerência de contexto (proxy de informações contextuais) ser feita por intermédio
do adaptador, algumas ações no controle da apresentação podem exigir uma
comunicação direta entre esses elementos (seta 5, na figura), sem que seja
66
necessário ser envolvido o aspecto de adaptação. Um exemplo é a consulta, por
parte do orquestrador de apresentação, às ferramentas de exibição disponíveis na
plataforma para que possa ser iniciada a apresentação do conteúdo de um objeto.
Os mecanismos de pré-busca também podem fazer uso das informações de
contexto, independentemente do módulo de adaptação, conforme será detalhado
na Seção 4.1.
Outra função que deve ser desempenhada na fase de execução é o
escalonamento das ações de busca definidas no plano de pré-busca. Essa tarefa é
responsabilidade do executor de pré-busca, que deve também, assim como o
executor de apresentação, monitorar os tempos efetivamente gastos e compará-los
com as previsões de tempo realizadas. Quando necessário, os devidos ajustes no
plano, para garantir a sincronização da apresentação, devem ser efetuados. Se não
for possível adaptar o plano de pré-busca, o orquestrador de pré-busca deve
notificar o orquestrador de apresentação, para que as correções sejam feitas
diretamente no plano de execução (seta 10). Da mesma forma, o executor de prébusca deve estar atento a qualquer mudança no plano de execução que possa
implicar em novos cálculos dos tempos de pré-busca.
É comum que a exibição dos objetos de execução, principalmente os
baseados em mídias contínuas, exija uma alocação dos recursos da plataforma,
tais como banda passante na rede, banda passante no acesso a disco, percentual de
utilização da CPU etc. O papel do módulo gerenciador da orquestração intramídia (ou simplesmente gerenciador intra-mídia) no formatador é o de reunir as
funções de negociação e monitoramento da qualidade de serviço junto aos
provedores de comunicação e processamento (tipicamente rede e sistema
operacional), para tentar garantir a busca e exibição dos conteúdos dentro dos
limites estipulados pelo autor e aceitáveis pelo usuário (seta 11). Contudo, a
presença desse módulo só é útil quando os provedores oferecerem suporte à
reserva de recursos, que pode ser tanto imediata (Braden et al., 1997; Coulson &
Blair, 1995), como antecipada (Berson et al., 1998; Degermark et al., 1995; Wolf
et al., 1995).
A seta 12, na Figura 16, ilustra a interação do gerenciador da orquestração
intra-mídia com os planos de pré-busca e execução e com os orquestradores de
pré-busca e de apresentação. O gerenciador deve consultar os planos para decidir
67
os momentos de iniciar, para cada objeto, o processo de negociação da reserva dos
recursos junto aos provedores, e monitorar o comportamento dos provedores para
receber, caso ocorra, a sinalização de violações em parâmetros da QoS acordada.
Quando não for possível manter essa qualidade para um determinado objeto de
execução, a notificação de violação deve ser sinalizada para o orquestrador de prébusca (ou diretamente para o orquestrador de apresentação) para que, idealmente,
o problema seja corrigido através de ajustes nos planos.
Com exceção do orquestrador de apresentação, do plano de execução e da
gerência de contexto (por mais simples que ela seja), todos os demais
componentes são opcionais em um formatador. Obviamente, a presença dos
módulos opcionais traz um melhor suporte ao controle das apresentações,
proporcionando uma qualidade mais apurada nos documentos exibidos.
Complementando as tarefas de formatação no ambiente de execução, estão
as ferramentas de exibição. As ferramentas são os elementos responsáveis por
lidar diretamente com a apresentação dos conteúdos dos objetos de execução.
Sendo assim, são elas que terão a função de exercer o controle sobre as máquinas
de estados dos eventos, cuidando de gerar as transições para que os elos do
documento possam ser avaliados e o plano de execução monitorado.
A próxima seção apresenta uma proposta de diagrama de classes para o
desenvolvimento de formatadores hipermídia, seguindo a estrutura descrita nesta
seção. As questões relacionadas ao projeto de ferramentas e à integração delas
com o formatador são tratadas na seção subseqüente.
3.2
Diagrama de classes genérico
formatadores hipermídia
para
o
desenvolvimento
de
A entidade principal para o desenvolvimento de um formatador hipermídia é
a classe Formatter, apresentada na Figura 17. Como pode ser percebido, um
objeto dessa classe possui, obrigatoriamente, um compilador (classe Compiler) e
um executor (classe Executor), correspondendo respectivamente aos submódulos
compilador e executor do orquestrador de apresentação. Além disso, o formatador
também mantém um plano de execução (classe ExecutionPlan) e um gerente (ou
proxy de gerência) de contexto (classe ContextManager). O formatador possui
68
ainda, opcionalmente, um adaptador de documentos (classe DocumentAdapter),
um orquestrador de prefetch (classe Prefetcher) e um gerenciador da orquestração
intra-mídia (classe IntraMediaManager), não havendo impacto no funcionamento
se qualquer um desses componentes não estiver presente. Por fim, para cada
modelo de documentos que o formatador souber tratar, diferente do modelo de
execução, deve haver uma implementação de conversor de modelo (classe
ModelConverter).
O formatador atua, ao mesmo tempo, como uma interface para os elementos
externos ao ambiente de execução (qualquer aplicação que queira fazer uso dos
serviços de formatação hipermídia) e como um mediador para os elementos
internos ao ambiente de execução. Essa última característica permite que os
módulos se comuniquem através de chamadas ao formatador. No entanto, como
certos elementos devem manter uma interação maior, alguns relacionamentos são
estabelecidos também entre as classes internas ao formatador, como são os casos
dos relacionamentos entre o compilador e o executor com o plano de execução.
IntraM ediaM anager
M odelConverter
0..*
0..1
P refetc her
0 ..1
Docum entA dapter
1
Compil er
1
1
1
0..1
1
Form atter
1
b uilds
q uery ing
1
1
1
1
Context Man ager
1
E x ec utionP lan
mainTi meCha in
1
queries
1
s c heduling
c ontrolling
E x ec utor
1
a ux il iaryTim eChains
1
1
1
0..*
1
Ti meChain
P res entationToolM anager
1
1. .*
P res e ntat io nTool
1
Lay outM anager
s patially pres ented b y
Figura 17 – Diagrama de classes para o desenvolvimento de formatadores9.
9
Nos relacionamentos do diagrama, onde não foi colocada a multiplicidade, é porque ela é igual a
um.
69
O plano de execução é, na verdade, composto por uma cadeia temporal
principal (atributo mainTimeChain), que guarda as transições de eventos relativas
ao início da apresentação do documento, e um conjunto de cadeias temporais
auxiliares (atributo auxiliaryTimeChains), que são iniciadas por ocorrências
imprevisíveis, mas que uma vez iniciadas geram uma seqüência de transições
previsíveis. As cadeia temporais são todas modeladas pela classe TimeChain.
O executor mantém com o gerenciador de contexto uma relação direta de
consulta às informações, principalmente da plataforma. As informações
provenientes do contexto são úteis principalmente para os dois componentes do
executor destacados na Figura 17: gerenciador de layout (classe LayoutManager)
e gerenciador de ferramentas (classe PresentationToolManager).
O gerenciador de layout é responsável por mapear as janelas e regiões
definidas no documento, em componentes gráficos disponíveis na plataforma onde
o documento é exibido. É o gerenciador de layout que deve manter a instância da
classe Layout (Figura 6), controlando, inclusive, a criação da janela de exibição
default do formatador. A partir das janelas e regiões criadas, o gerenciador de
layout controla as características espaciais das ferramentas de exibição e, por
conseqüência, dos objetos de execução. É também esse gerenciador o elemento
responsável por manter a relação entre os dispositivos de saída da plataforma e os
objetos de execução.
O gerenciador de ferramentas deve possuir uma lista das ferramentas de
exibição disponíveis na plataforma e controlar suas instanciações, utilizando as
informações provenientes dos conteúdos e descritores dos objetos de execução.
Uma vez instanciadas, as ferramentas passam a interagir diretamente com o
submódulo executor do formatador.
Por lidarem diretamente com a informação apresentada ao usuário, as
ferramentas de exibição são componentes fundamentais no ambiente de execução.
Mais importante ainda é a interface de comunicação entre essas ferramentas e o
formatador hipermídia, pois a avaliação dos relacionamentos (elos) e execução das
ações depende dessa troca de mensagens. Dessa forma, a próxima seção discute as
questões referentes ao projeto e integração de ferramentas de exibição em
ambientes de execução hipermídia.
70
3.3
Integração entre ferramentas de exibição e formatadores hipermídia
As ferramentas de exibição são responsáveis pela apresentação de cada um
dos objetos de execução que compõem o documento. Sendo assim, qualquer
ferramenta precisa entender ao menos algumas das entidades definidas no modelo
de execução. Mais especificamente, as ferramentas devem saber como interpretar
as informações contidas nos objetos de dados, nos eventos que devem ser por ela
monitorados e nos descritores.
A principal informação contida no objeto de dados (Seção 2.3.1.1) que a
ferramenta deve saber tratar é o conteúdo do nó hipermídia. Na realidade, esse
entendimento passa por uma cooperação com o gerenciador de ferramentas do
formatador, que, teoricamente, só irá lhe entregar objetos cujo conteúdo possam
ser decodificados e exibidos.
Juntamente com o conteúdo, os eventos são elementos que também
precisam ser muito bem compreendidos pela ferramenta. Para os eventos baseados
em âncora, a ferramenta deve identificar a sua porção no conteúdo e controlar
diretamente as suas máquinas de estados. De modo similar, os eventos baseados
em atributos devem resultar no monitoramento dos valores dos atributos e também
no controle de suas máquinas de estados. As ferramentas precisam também
conhecer a semântica das classes de eventos definidas no formatador (exibição,
seleção, arraste etc.) para tratar as ocorrências quando as mídias são efetivamente
apresentadas.
Diferente dos objetos de dados e dos eventos, nem todas as informações
contidas nos descritores precisam ser compreendidas pela ferramenta de exibição.
A responsabilidade da interpretação da parte espacial definida na região e na
janela pode ser dividida com o gerenciador de layout, cabendo à ferramenta
utilizar o identificador da região para requisitar serviços de exibição ao
gerenciador. Nesse relacionamento, é também importante que a ferramenta
consiga monitorar os valores de certos atributos espaciais para que consiga
controlar a máquina de estados dos eventos de atribuição.
Os parâmetros de qualidade de serviço definidos nos descritores também
não precisam ser entendidos pela ferramenta, mas sim pelas estratégias de prébusca, de adaptação e pelo orquestrador intra-mídia. Evidentemente, em
71
implementações que integrem o orquestrador à ferramenta, indiretamente os
parâmetros de QoS terminarão por ser compreendidos também pela própria
ferramenta.
Outro atributo do descritor que não necessita de ser tratado pela ferramenta é
a regra de exibição. O tratamento das regras deve ser feito pelo mecanismo de
adaptação do documento, antes que a ferramenta seja acionada para exibir o objeto
de execução.
Restam como dados do descritor a serem interpretados exclusivamente pelas
ferramentas, os atributos específicos de cada conteúdo, tais como folha de estilo
principalmente em objetos do tipo texto, altura do volume para áudio e vídeo etc.
É fundamental em um ambiente de execução hipermídia que as ferramentas
estejam bem integradas ao formatador, para não somente exibir objetos de
diferentes tipos de mídia, mas também oferecer o suporte para que os
relacionamentos de sincronização especificados pelo autor do hiperdocumento
sejam obedecidos.
Conforme já comentado e ilustrado na Figura 1 e na Figura 16, uma maneira
modular de desenvolver o ambiente de execução é separar o formatador das
ferramentas. Dessa maneira, as ferramentas podem se tornar isoladas da
complexidade das funcionalidades de formatação comentadas nas duas seções
anteriores (compilação, escalonamento da execução, adaptação, pré-busca,
negociação e manutenção de QoS etc.) e concentrar seus esforços na
decodificação e exibição do conteúdo e no controle das máquinas de estados dos
eventos. Mais ainda, através de uma interface bem especificada e padronizada
para troca de mensagens entre as ferramentas e o formatador, é possível alcançar
uma independência para os projetistas desses elementos, ao mesmo tempo
garantindo uma interoperabilidade. Essa separação permite reusar implementações
de ferramentas em diferentes sistemas hipermídia e até mesmo integrar
ferramentas de implementadores distintos em um mesmo ambiente de execução.
Outro benefício dessa separação é o oferecimento de um suporte para a
implementação de relacionamentos de sincronização temporal e espacial, entre
objetos exibidos em diferentes ferramentas de exibição.
Apesar da uniformização da interface trazer os benefícios comentados no
parágrafo anterior, a proposta de integração obriga que as ferramentas conheçam o
72
modelo de execução utilizado pelo formatador. No entanto, existe uma variedade
de exibidores de mídia com interfaces e modelos próprios, tais como os exibidores
JMF (Sun, 1999), exibidores QuickTime10, exibidores da RealNetworks11 etc., que
não seguem o padrão de funcionamento esperado pelo formatador, mas que são
interessantes de serem integrados ao ambiente de execução. Para esses casos, se
for possível, a alternativa é desenvolver, como parte da ferramenta de exibição,
um módulo capaz de efetuar a ponte entre as duas interfaces, conforme ilustrado
na Figura 18.
Ferramenta de
Exibição
Interface particular
do exibidor
Formatador
Exibidor não conforme
Adaptador
Interface padrão
para troca de mensagens
Ferramenta de Exibição
Figura 18 – Interface para integração de ferramentas de exibição e formatadores,
prevendo a utilização de adaptadores para integração com exibidores cuja interface
difere da esperada pelo formatador.
A próxima subseção define, de maneira mais detalhada, a interface para
integração das ferramentas de exibição a formatadores hipermídia. A interface
proposta permite não apenas que ferramentas diversas interajam com o
formatador, como também cooperem entre si na apresentação de um
hiperdocumento.
10
http://www.apple.com/quicktime/
11
http://www.realnetworks.com/
73
3.3.1
Interface entre formatadores e ferramentas de exibição
De um modo geral, a interface entre ferramentas de exibição e formatadores
deve padronizar a maneira como as ferramentas notificam o formatador de certas
ocorrências durante a apresentação dos objetos, como por exemplo, que a exibição
de uma determinada região do conteúdo (âncora) de um objeto se encerrou, que
uma âncora foi selecionada pelo usuário, que a posição do objeto na tela se
modificou etc.
Baseando-se no modelo de execução proposto na Seção 2.3, o envio de
mensagens das ferramentas para o formatador é feito pelo próprio controle da
máquina de estados dos eventos. Sempre que a ferramenta modifica o estado de
um evento, todos os elementos que estiverem registrados como observadores do
evento serão notificados. Cabe ao executor do orquestrador de apresentação
registrar-se como observador dos eventos (implementar a interface EventListener
– Seção 2.3.1.3) e, eventualmente, ao compilador do orquestrador de apresentação
colocar também as condições de transição como observadores dos eventos.
No sentido inverso, isto é, do formatador para as ferramentas, a interface
deve especificar como solicitar que as ações sejam executadas sobre os eventos
não interativos, tais como, iniciar a exibição de um conteúdo, suspender a
exibição, alterar o valor do atributo taxa de apresentação, modificar o valor do
atributo volume do som etc. Essas ações irão por sua vez refletir em novas
transições nas máquinas de estados dos eventos.
Toda ferramenta de exibição deve ser projetada como uma subclasse de
PresentationTool (Figura 6 e Figura 17) e implementar os métodos definidos na
interface dessa superclasse. Esses métodos permitem justamente requisitar a
execução das ações sobre os eventos controlados pela ferramenta. A idéia é que
toda vez que uma ação de um elo causal tiver que ser executada, a requisição seja
feita à ferramenta de exibição, para que a ferramenta implemente a semântica
associada ao evento e gere a transição na sua máquina de estados. A Tabela 4
descreve a interface genérica que deve ser oferecida por toda ferramenta de
exibição.
Método
74
Dados de Entrada
Descrição
initialize
Objeto de execução
Coloca o objeto de execução, sob o controle da ferramenta e inicia
as estruturas de dados, principalmente as máquinas de estados
correspondentes aos eventos do objeto.
addExecutionObject
Coloca mais um objeto de execução sob o controle da ferramenta.
removeExecutionObject
Remove um objeto de execução do controle da ferramenta.
prepare
Objeto de execução,
evento
Inicia a preparação do evento passado como argumento. Esse
método pode gerar também a preparação de todos os eventos que
estejam relacionados com o evento passado como parâmetro.
unprepare
Coloca todos os eventos do objeto de execução no estado
dormindo. Se algum evento estiver ocorrendo, sua ocorrência deve
ser antes abortada.
start
evento não
interativo
Inicia a ocorrência do evento passado como parâmetro. O evento
deve pertencer ao objeto de execução também passado como
parâmetro. Se o evento não estiver preparado, a preparação deve
ser automaticamente iniciada. Se o evento estiver sendo
preparado, a ocorrência deve ser iniciada logo em seguida. Se o
evento estiver em qualquer outro estado diferente de dormindo,
preparando e preparado, a ação deve ser ignorada.
stop
evento não
instantâneo
Encerra a ocorrência do evento passado como parâmetro. O
evento deve pertencer ao objeto de execução também passado
como parâmetro. Se o evento estiver em qualquer estado diferente
de ocorrendo e suspenso, a ação deve ser ignorada. Se o evento
for nulo a ação deve ser aplicada a todos os eventos não
instantâneos do objeto de execução.
pause
evento não
instantâneo
Suspende a ocorrência do evento não instantâneo. O evento deve
pertencer ao objeto de execução passado como parâmetro. Se o
evento estiver em qualquer estado diferente de ocorrendo, a ação
deve ser ignorada. Se o evento for nulo a ação deve ser aplicada a
todos os eventos não instantâneos do objeto de execução.
resume
evento não
instantâneo
Retoma a ocorrência do evento não instantâneo. O evento deve
evento estiver em qualquer estado diferente de suspenso, a ação
deve ser ignorada. Se o evento for nulo a ação deve ser aplicada a
todos os eventos não instantâneos do objeto de execução.
abort
evento não
instantâneo
Aborta a ocorrência do evento não instantâneo. O evento deve
evento estiver em estado diferente de ocorrendo e suspenso, a
ação deve ser ignorada. Se o evento for nulo a ação deve ser
aplicada a todos os eventos não instantâneos do obj de execução.
changeEventState
evento, novo estado
Se possível, coloca o evento no novo estado passado como
argumento. O evento deve pertencer ao objeto de execução
também passado como parâmetro12.
setAttributeValue
evento de
atribuição, valor,
atribuição relativa
Atribui o valor ao atributo identificado pelo evento de atribuição.
O evento deve pertencer ao objeto de execução passado como
parâmetro. O parâmetro atribuição relativa informa se o valor
deve ser atribuído de maneira absoluta ou relativa.
getAttributeValue
evento de atribuição
Retorna o valor do atributo identificado pelo evento de atribuição.
O evento deve pertencer ao objeto de execução.
setTimeControlVisible
booleano
Habilita ou desabilita uma barra para controle temporal da
exibição do objeto de execução.
Tabela 4 – Interface que deve ser oferecida por toda ferramenta de exibição.
12
Esse método objetiva permitir que as ferramentas lidem com extensões das máquinas de estados
dos eventos, sem que seja obrigatória a criação de novos métodos na interface.
75
O método initialize recebe, como parâmetro, o objeto de execução a ser
exibido (objeto de dados, descritor e eventos). Cabe à ferramenta extrair dos
eventos os atributos e as regiões correspondentes no conteúdo do objeto (as
âncoras), para efetuar o controle das respectivas máquinas de estados. A interface
permite que uma mesma ferramenta controle a exibição de mais de um objeto de
execução. Por esse motivo todos os métodos esperam um parâmetro que identifica
o objeto de execução na ferramenta. Novos objetos são incluídos ou retirados de
uma
ferramenta
com
chamadas,
respectivamente,
aos
métodos
addExecutionObject e removeExecutionObject.
Os métodos prepare e unprepare atuam na preparação dos eventos.
Normalmente, o método prepare será chamado com o evento de apresentação que
identifica o conteúdo inteiro do objeto de execução. Geralmente, a preparação do
evento mais abrangente resultará também na preparação dos demais eventos do
objeto. A preparação dos eventos de exibição envolve a busca das unidades de
informação do conteúdo (ao menos parcialmente) e seu armazenamento em um
buffer da ferramenta. O método unprepare permite requisitar a liberação desses
espaços alocados quando não houver mais interesse por parte do formatador em
manter os eventos preparados.
O método start inicia a ocorrência do evento não interativo passado como
parâmetro. Normalmente, esse evento será o evento de exibição anteriormente
preparado. Quando for realizada uma chamada para o método start de um evento
que esteja ainda sendo preparado (encontrar-se no estado preparando), a
ferramenta deve aguardar o término da preparação e iniciar a ocorrência do evento
logo em seguida.
Os métodos stop, pause, resume e abort recebem, todos, um objeto de
execução e um evento não instantâneo como parâmetros e devem ser aplicados
conforme as descrições dadas na terceira coluna da Tabela 4. Todos esses métodos
podem também ser chamados recebendo apenas um objeto de execução como
argumento. Nesse caso, as ações desempenhadas devem ser feitas sobre todos os
eventos não instantâneos do objeto de execução que estiverem no estado
adequado.
Os métodos setAttributeValue e getAttributeValue permitem que o
formatador interaja com as ferramentas de exibição, modificando e consultando os
76
valores dos atributos dos eventos e dos objetos de execução. Supondo que a
ferramenta controle a apresentação de uma mídia contínua, uma importante
utilidade do método setAttributeValue é permitir que o formatador aumente ou
diminua a taxa de apresentação do conteúdo, para tentar garantir que as relações
de restrição especificadas pelo autor sejam respeitadas.
O método changeState na interface procura oferecer flexibilidade para que
novas máquinas de estados sejam definidas sem que isso cause impacto na
estrutura proposta. A interface também não restringe as classes dos eventos,
possibilitando
que
novas
extensões
sejam
definidas.
Obviamente,
a
implementação da ferramenta que for efetivamente controlar a exibição do objeto,
dos novos tipos de eventos e das novas máquinas de estados deverá conhecer os
detalhes das extensões.
O método setTimeControlVisible é útil para a apresentação de objetos de
execução, cujos eventos de exibição associados tenham durações bem definidas.
Isso será mais comum para os objetos associados a vídeos e áudios. O método
espera um valor booleano, que quando verdade, exibe um componente de interface
gráfica para o controle temporal da apresentação. Normalmente, esse controle irá
possuir botões e barras de progressão que permitem realizar ações sobre a
exibição do objeto, tais como iniciar, encerrar, suspender, reassumir, modificar o
ponto da exibição etc.
Antes de discorrer sobre os aspectos da implementação de ferramentas de
exibição e de um exemplo de formatador hipermídia que segue a estruturação
apresentada neste capítulo, o próximo capítulo discute os aspectos relacionados às
funcionalidades essenciais para que se busque apresentações de hiperdocumentos
com qualidade.
Pré-busca, Orquestração Intra-Mídia e Adaptação de Apresentações
Hipermídia
77
4
Pré-busca, Orquestração Intra-Mídia e Adaptação de
Apresentações Hipermídia
Este capítulo analisa os requisitos para o projeto e implementação de
mecanismos de pré-busca, orquestração de qualidade de serviço e adaptação das
apresentações em formatadores hipermídia. Apesar desses mecanismos não serem
essenciais, a presença deles no ambiente de execução contribui para uma maior
proximidade entre os resultados finais das apresentações e as especificações dos
autores.
Para cada mecanismo, a partir do levantamento de seus requisitos, o capítulo
propõe uma arquitetura genérica que possa ser reusada no desenvolvimento de
formatadores específicos. Adicionalmente, com a especificação de interfaces bem
definidas para as estruturas genéricas, pretende-se facilitar a integração de
módulos de pré-busca, orquestração e adaptação com outros componentes dos
sistemas de apresentação hipermídia, inclusive permitindo que as estratégias
desses mecanismos venham a ser incorporadas em implementações de
formatadores já existentes.
4.1
Pré-busca em apresentações hipermídia
Para que o usuário perceba uma boa qualidade em uma apresentação
hipermídia, diversos parâmetros precisam ser controlados pelo formatador. Dentre
os parâmetros temporais destacam-se: a latência para exibição dos objetos e a taxa
para apresentação dos objetos de mídia contínua. A latência de exibição
corresponde ao intervalo de tempo entre o instante em que o conteúdo de um
objeto de execução deve ser exibido e o instante em que o mesmo é efetivamente
apresentado13. Efeitos desagradáveis que podem ser percebidos pelo usuário
13
Note que o termo latência no contexto desta tese não se refere exclusivamente ao retardo de
transferência na rede, mas pode englobar também atrasos no sistema operacional e na própria
ferramenta de exibição.
Hipermídia
78
quando ocorre uma latência elevada são a perda da interatividade e a perda da
sincronização entre os objetos de execução, sem falar na própria impaciência
causada pela espera.
As taxas de apresentação são características dos objetos de mídia contínua,
tais como vídeo e áudio. Essas taxas normalmente envolvem uma quantidade de
amostras por segundo e uma resolução para cada uma das amostras. Quando
métodos de compressão são aplicados em conteúdos desse tipo, as taxas de busca
podem variar ao longo do tempo. No entanto, para as ferramentas de exibição, as
taxas de apresentação devem se manter em níveis constantes, pois variações
podem resultar em desconforto, ou mesmo na total incompreensão da informação.
O limite máximo para a latência de exibição de um objeto varia em função
do tipo de seu conteúdo (texto, imagem, áudio, vídeo etc.) e do tipo de aplicação
hipermídia onde o objeto se encontra inserido (aplicação não interativa, aplicação
interativa etc.). Na Web, por exemplo, algumas pesquisas constatam que uma
espera de até cinco segundos para carregar uma nova página no browser é tida
pelos usuários como satisfatória (Bhatti et al., 2000). No entanto, em aplicações
que requeiram transmissão de voz, esse limite pode ter de ser reduzido para cerca
de 150 milisegundos (ITU, 1996). O limite máximo para a latência de exibição vai
depender também dos relacionamentos existentes com outros objetos (elos de
sincronização, elos de restrição etc.). Flutuações na taxa de exibição (jitter) afetam
apenas as mídias contínuas e devem ser sempre evitadas.
Técnicas de cache têm sido amplamente utilizadas nas mais diversas áreas
da computação com o intuito de reduzir o tempo de resposta dos sistemas. Os
mecanismos de cache procuram posicionar os dados em uma memória que ofereça
ao sistema um tempo de acesso mais baixo que o experimentado quando os dados
são trazidos de seu local original de armazenamento. A eficiência de um
mecanismo de cache está diretamente relacionada à freqüência com que os dados
são encontrados na memória cache, quando requisitados pelo sistema (cache hit).
Áreas na memória cache (principalmente em RAM), funcionando como buffers,
também podem ser úteis no auxílio a estratégias de compensação das variações
estatísticas dos retardos, permitindo corrigir variações bruscas nas taxas de
fornecimento dos dados.
Hipermídia
79
Embora o uso da memória cache possibilite uma redução nos tempos de
resposta do sistema, estudos mostram que as técnicas de cache em sistemas
hipermídia, principalmente na Web, apresentam eficiência bem inferior (30-60%)
à obtida com as técnicas de cache em hardware (90%) (Cohen & Kaplan, 2000;
Feldmann et al., 1999; Khan & Tao, 2001a; Kroeger et al., 1997). Além dos vários
aspectos relacionados às técnicas de geração de páginas dinâmicas que
influenciam numa menor eficiência dos mecanismos de cache, existe também uma
quantidade grande de dados que são requisitados pelo ambiente de execução uma
única vez. A eficiência baixa, somada ao fato das apresentações hipermídia muitas
vezes necessitarem que os objetos possuam uma latência de exibição baixa,
mesmo na primeira vez em que são exibidos, e à questão dos próprios buffers para
compensação da variação estatística causarem um atraso adicional na exibição dos
objetos de mídia contínua, faz com que seja importante a existência de estratégias
de pré-busca (prefetch) nos formatadores.
A principal responsabilidade do mecanismo de pré-busca é procurar garantir
que o conteúdo de cada objeto (não necessariamente o objeto inteiro) esteja pronto
para a ferramenta de exibição no momento em que a mesma precise exibi-lo,
fazendo com que as latências de apresentação durante a execução dos documentos
encontrem-se dentro dos limites aceitáveis. Como conseqüência da antecipação,
para o caso de objetos de mídia contínua, o mecanismo de pré-busca também
possibilita que durante a exibição não haja uma ausência de dados (buffer
underflow) para serem consumidos pelas ferramentas de exibição.
O ponto de partida para o compilador de pré-busca é percorrer a cadeia
temporal principal no plano de execução e estimar o tempo despendido na
preparação de cada um dos objetos de execução. Para que os tempos estimados se
aproximem da realidade, é necessário que o compilador de pré-busca obtenha
informações a respeito dos objetos de execução. O compilador de pré-busca deve
consultar o conteúdo de cada objeto para tentar descobrir o seu tamanho (ou
duração). Além do tamanho, o compilador deve tentar encontrar no descritor de
cada objeto o percentual mínimo do conteúdo total que precisa estar disponível
antes do início da apresentação e a latência máxima permitida para a exibição do
objeto.
Hipermídia
80
Além das informações provenientes dos objetos de execução, o compilador
de pré-busca também precisa dispor de pelo menos três informações adicionais do
contexto de exibição, para estimar os tempos de busca. A primeira é o retardo de
propagação dos dados do local em que estão armazenados até o buffer da
ferramenta14, a segunda informação é a taxa de transmissão disponível para
transferência dos dados15 e, por fim, a terceira informação é o próprio retardo
imposto pela ferramenta de exibição para sua criação e iniciação, que muitas vezes
não deve ser desprezado. Para as informações que não estiverem disponíveis nos
objetos ou no contexto de exibição, o compilador deve utilizar heurísticas para a
elas atribuir valores. A Figura 19 apresenta a fórmula geral para o cálculo do
tempo de preparação de um objeto de execução.
T :
pc:
L :
r :
tx:
f :
tamanho do objeto (em bits)
percentual (entre 0 e 1) do tamanho total que deve estar disponível
latência máxima para exibição do objeto (em segundos)
retardo de propagação imposto pela plataforma (em segundos)
taxa de transmissão (em bits por segundo)
retardo imposto pela ferramenta (em segundos)
Tempo de preparação (s) = ((T * pc) / tx) + r + f - L
Figura 19 – Fórmula geral para o cálculo do tempo de preparação de um objeto de
execução.
Além de calcular os tempos de preparação para cada um dos objetos de
execução, a outra função do compilador de pré-busca é determinar a ordem das
preparações, para com isso realizar a construção efetiva do plano de pré-busca.
Esse procedimento deve ser feito com o uso de alguma estratégia de compilação
de pré-busca. Na realidade, é a própria estratégia que deve coordenar o cálculo das
estimativas de duração das preparações, estabelecendo inclusive as heurísticas
para determinar os valores para os parâmetros citados anteriormente que
eventualmente não estejam disponíveis.
Alguns aspectos importantes devem ser considerados na construção do
plano de pré-busca, pois é importante que haja um planejamento na escolha dos
Esse retardo pode englobar o próprio tempo para requisitar o objeto, tempo de seek no acesso a
disco etc.
14
15
Note que a taxa de transmissão na pré-busca não precisa ter qualquer relação com a taxa de
exibição do conteúdo.
Hipermídia
81
tempos e na ordenação das requisições de pré-busca. Duas situações podem
ocorrer se os instantes para iniciar a busca dos conteúdos não forem bem
escolhidos (Jeong et al., 1997; Oren, 2000): a busca pode ser iniciada tardiamente
e o objeto não estar preparado na hora da sua exibição; ou a busca pode iniciar
cedo demais e o objeto ter de permanecer armazenado na memória cache durante
muito tempo. No primeiro caso, pode ser introduzida uma latência maior que a
permitida na exibição. Se houver pelo menos um relacionamento de sincronização
temporal com paralelismo entre o objeto cuja preparação atrasou e um outro
qualquer, pode ser que a sincronização seja perdida ou então que seja necessário
retardar a exibição também do outro objeto. A antecedência exagerada na busca
pode trazer duas conseqüências desfavoráveis. O objeto pode ter de ser descartado
pela política de cache, gerando uma pré-busca inútil, ou pode obrigar que um
outro objeto em uso, ou necessário em um futuro próximo, seja descartado,
causando uma poluição na cache. A primeira situação (início tardio da busca)
pode ser amenizada impondo um retardo maior para iniciar a exibição do
documento como um todo. Isso aumenta o tempo de compilação e o tamanho
necessário para a memória cache. A segunda situação pode ser evitada por meio
de um controle mais apurado da alocação dos recursos na plataforma ou
simplesmente incrementando o tamanho da memória cache.
Essas questões acrescentam dois parâmetros que devem ser considerados
pelo compilador de pré-busca. O primeiro é o espaço disponível em memória
(espaço na cache) para trazer os conteúdos dos objetos com antecedência. O
segundo é a latência que será introduzida para iniciar a exibição do documento
como um todo. O primeiro parâmetro é uma informação que deve ser obtida do
gerente de contexto, pois está relacionado com a plataforma de exibição. Já o
segundo parâmetro pode ser definido pela própria estratégia, ou estipulado pelo
usuário do mecanismo de pré-busca.
Uma estratégia simples de compilação da pré-busca pode subtrair do
instante esperado para exibição de cada objeto, o tempo estimado para sua
preparação. Essa solução deve, no entanto, considerar as divisões da banda
quando mais de um objeto tiver que ser buscado paralelamente, evitando causar
tempos de preparação maiores que os previstos e, por conseqüência, latências
inaceitáveis.
Hipermídia
82
Para que a estratégia não precise se preocupar com divisões da banda
passante disponível, a alternativa é serializar as buscas. Nesse caso, os objetos
devem ser primeiramente ordenados em função dos instantes esperados para suas
exibições. Os objetos que devem ser apresentados primeiro, devem ser preparados
na frente. Quando mais de um objeto tiver que iniciar sua exibição ao mesmo
tempo, o melhor é que os objetos com tempos de preparação maiores sejam
deixados para depois (Jeong et al., 1997).
Além de serializar as buscas, o ideal é que a estratégia de compilação
identifique, após o plano estabelecido, quais os objetos na cadeia temporal
principal estão com uma latência de exibição ultrapassando o valor máximo
permitido. Todas as violações devem ser somadas e o resultado utilizado para
impor um retardo ao início da exibição do documento. Evidentemente, a estratégia
deve observar se esse atraso inicial respeita a exigência de retardo do usuário e a
capacidade da memória cache. Caso isso não seja possível, existem duas opções.
A primeira é simplesmente iniciar a apresentação do documento respeitando as
características do usuário e da plataforma e deixar para ajustar a apresentação
durante a sua execução. A segunda opção é requisitar, ainda em compilação, os
serviços do módulo de adaptação, para que o plano de execução do documento
seja ajustado. No entanto, é importante que a estratégia considere que os próprios
cálculos e ajustes do plano consomem o tempo da compilação.
Um outro aspecto que a estratégia de compilação da pré-busca deve levar
em conta é a escolha do momento para iniciar a preparação dos objetos contidos
em cadeias temporais auxiliares, pois é importante que, mesmo para os objetos
com exibições imprevisíveis, sempre que possível a latência seja minimizada,
como demonstram estudos anteriormente mencionados (Bhatti et al., 2000; Khan
& Tao, 2001a). O ideal é que a estratégia consiga obter, ou diretamente do plano
de execução, ou junto ao contexto de exibição, a probabilidade para que cada uma
das cadeias auxiliares tenha sua execução iniciada. De posse das probabilidades e
dos tempos estimados para preparação, o orquestrador de pré-busca pode ponderar
esses valores e, em certas ocasiões, optar por também preparar objetos com
exibições imprevisíveis de maior probabilidade.
Com o plano de pré-busca construído, o executor do orquestrador de prébusca inicia sua tarefa que consiste em consultar o plano e disparar, nos instantes
Hipermídia
83
programados, notificações ao executor para requisitar junto às ferramentas de
exibição (ou seus adaptadores) o início da preparação de cada um dos objetos.
Pode ser que, ao invés do conteúdo ser buscado pela ferramenta, exista no sistema
um módulo único que coordene de maneira centralizada as buscas e o
armazenamento dos dados.
Durante a fase de execução da pré-busca, o executor deve monitorar, junto
ao plano de execução, qualquer alteração que ocorra nos instantes de tempo
previstos para iniciar a exibição dos objetos de execução, incluindo a ocorrência
de exibições inicialmente classificadas como imprevisíveis pelo compilador de
apresentação. Quando necessários, os devidos ajustes devem ser feitos pelo
executor no plano de pré-busca. Cabe ao executor também observar os tempos
efetivamente despendidos nas preparações e compará-los com os tempos
estimados, ajustando o plano de pré-busca quando for necessário. Se por acaso o
executor de pré-busca não conseguir ajustar o plano e manter as restrições de
latência impostas pelo documento, o orquestrador de pré-busca deve informar o
fato ao orquestrador de apresentação, para que as adaptações sejam aplicadas
sobre o plano de execução.
A próxima seção ilustra o framework proposto para implementação de
mecanismos de pré-busca em formatadores hipermídia.
4.1.1
Arquitetura para implementação de mecanismos de pré-busca
A Figura 20 apresenta o diagrama de classes que visa facilitar o projeto e a
implementação de mecanismos de pré-busca em apresentações hipermídia. A
classe Prefetcher representa o orquestrador de pré-busca, correspondendo à
mesma classe já comentada na Seção 3.2 (Figura 17). Essa classe funciona como a
interface (fachada) do mecanismo oferecida aos demais componentes do
formatador, ou a qualquer outro módulo que deseje utilizar os serviços de prébusca de objetos hipermídia. O compilador (PrefethCompiler), o executor
(PrefetchExecutor) e o plano de pré-busca (PrefetchPlan) constituem-se nos três
principais componentes do orquestrador de pré-busca.
Hipermídia
Exec uti onPlan
compiles
1
Prefetche r
c ompil ePlan()
s tartPre fet chi ng()
s topPrefetching()
p auseP refet ching()
resum eP refet ching()
a ddPrefetc hLis tener()
informTi meCha inAdded ()
informO bjectBeginni ngChanged()
1
1 informO bjectRem oved()
informA ctualObjectPrefetchDuration()
g etO bj ects()
g etO bj ectPrefe tchi ngTi me ()
PrefetchCompiler
1
compilePlan()
1
b uilds
schedules
1
queries
1
PrefetchPlan
PrefetchParameterCalc ulat or
1
getPlatformDelay()
getTransmissionRate()
getPresentationToolDelay()
queries
0..*
PrefetchObject
1
84
PrefetchList ener
reachedObjectPrefetchTime()
0.. *
ob served by
1
PrefetchExecutor
startPrefetching()
stopPrefetching()
pausePrefetching()
resumePrefetching()
addPrefetchListener()
informTimeChainAdded()
informObjectBeginningChanged()
informObjectRemoved()
informActualObjectPrefetchDuration()
1
adjusts
0..1
PrefetchAdjustmentStrategy
informTimeChainAdded()
informObjectBeginningChanged()
informObjectRemoved()
informActualObjectPrefetchDuration()
1
ContextManager
ExecutionObject
Figura 20 – Diagrama de classes para implementação de mecanismos de pré-busca em
documentos hipermídia.
A classe PrefetchCompiler é, na verdade, uma estratégia (design pattern
Strategy (Gamma et al., 1995)) que deve ser especializada em cada
implementação particular de mecanismo de pré-busca. O compilador é
responsável por efetuar a construção do plano de pré-busca a partir do plano de
execução (ExecutionPlan) e dos dados provenientes do proxy de informações
contextuais (ContextManager). Para tanto, ele deve utilizar os serviços de um
elemento calculador (PrefetchParameterCalculator) que, para um determinado
objeto de execução, informa os valores de cada um dos parâmetros da plataforma
de exibição, relevantes na estimativa das durações de preparação (Figura 19).
Implementações dessa classe de cálculo também devem prover heurísticas que
definam valores para os vários parâmetros, quando não for possível obtê-los do
gerenciador de contexto. A obtenção dos parâmetros relacionados aos objetos de
execução e o cálculo efetivo do tempo de preparação devem ser realizados pela
própria estratégia de compilação. Também cabe a essa estratégia observar se os
limites de tamanho dos buffers e da latência para iniciar a exibição estão sendo
cumpridos. Tanto o compilador (estratégia de compilação) como o calculador são
pontos de flexibilização (hotspots) do framework, que devem ser preenchidos em
função dos requisitos de formatação.
Hipermídia
85
O executor de pré-busca (PrefetchExecutor) reúne as ações que devem ser
desempenhadas após a construção, ao menos parcial, do plano de pré-busca.
Sendo assim, a principal função do executor é escalonar o plano e notificar os
objetos que tenham se registrado como observadores do mecanismo de pré-busca.
Esse registro é feito através de uma chamada ao método addPrefetchListener do
orquestrador, que por sua vez repassa a chamada ao executor. Na invocação do
método, o objeto observador deve ser passado como parâmetro. Para isso, classes
que desejem atuar como observadores do mecanismo devem ser do tipo
PrefetchListener e implementar o método reachedPrefetchTime com o código
para o tratamento das notificações. O método reachedPrefetchTime informa para
os seus observadores o objeto de execução que teve o seu instante de preparação
atingido.
O escalonamento do plano é iniciado com uma chamada ao método
startPrefetching do orquestrador de pré-busca, que simplesmente repassa essa
chamada para o executor. A qualquer momento, chamadas aos métodos
pausePrefetching
e
resumePrefetching
podem
ser
invocadas
para,
respectivamente, suspender ou retomar o escalonamento. Além disso, o método
stopPrefetching permite que o processo de pré-busca seja encerrado.
Além de escalonar as ações de busca e preparação dos conteúdos, é
desejável, porém não obrigatório, que o executor de pré-busca também possua
uma estratégia de ajuste (PrefetchAdjustStrategy). A função dessa estratégia é
estar atenta a modificações no plano de execução e distorções entre os tempos de
preparação previstos e os tempos efetivamente gastos, para realizar correções no
plano de pré-busca quando for necessário. A estratégia de ajuste pode ser
informada, através de uma chamada ao seu método informTimeChainAdded, que
uma cadeia temporal auxiliar foi associada à cadeia principal, como resultado da
ocorrência de um evento imprevisível ou de uma adaptação dinâmica do
formatador. Além desse tipo de modificação do plano de execução, a estratégia
também pode ser notificada da alteração no instante previsto para iniciar a
exibição de um objeto de execução, por meio de uma chamada ao método
informObjectBeginningChanged e da remoção de um objeto do plano de
execução, por intermédio de uma chamada ao método informObjectRemoved. Por
fim, o método setActualObjectPrefetchDuration permite que a estratégia de ajuste
Hipermídia
86
seja avisada do tempo efetivamente gasto na preparação de um determinado objeto
de execução. Se no executor de pré-busca não estiver disponível a estratégia de
ajuste, as chamadas a esses métodos devem ser simplesmente ignoradas. Do
mesmo modo que no compilador, a estratégia de ajuste é um ponto de
flexibilização na arquitetura proposta.
Como pode ser percebido, todos os métodos oferecidos na interface do
orquestrador de pré-busca comentados até o momento terminam sempre por serem
repassados aos componentes internos do mecanismo. Isso é feito com o intuito de
evitar que usuários dos serviços de pré-busca precisem tomar conhecimento de
todas as classes internas e de seus funcionamento, podendo interagir apenas com a
classe Prefetcher.
O método getExecutionObjects, oferecido pelo orquestrador, retorna a lista
dos objetos de execução inseridos no plano de pré-busca, já ordenados pelos
respectivos instantes programados de preparação. Esses instantes podem ser
obtidos através de invocações ao método getObjectPrefetchingTime, passando o
objeto como parâmetro. Esses métodos podem ser úteis, principalmente, em
plataformas que permitam reservar recursos antecipadamente, pois evitam que o
processo de negociação da QoS para transmissão do conteúdo seja iniciado
somente no instante que o escalonador (executor) notifica que a preparação deve
ser começada. Os aspectos de negociação e manutenção da QoS nas transmissões
dos conteúdos dos objetos são comentados na próxima seção.
4.2
Orquestração intra-mídia em apresentações hipermídia
O conceito de orquestração da qualidade de serviço está relacionado com a
gerência integrada da alocação dos recursos e do escalonamento de suas
utilizações, quando os mesmos encontram-se distribuídos por mais de um
subsistema (Gomes, 1999). No controle de apresentações de documentos
hipermídia, a questão da orquestração da qualidade de serviço aparece em dois
níveis distintos: orquestração da QoS inter-mídia e orquestração da QoS intramídia.
A orquestração inter-mídia refere-se à manutenção dos relacionamentos de
sincronização, tanto causais como de restrição, sendo responsabilidade do
Hipermídia
87
orquestrador de apresentação, conforme já discutido no Capítulo 3. Também de
acordo com o que já foi comentado, na tarefa de orquestração inter-mídia, os
mecanismos de adaptação e de pré-busca atuam como importantes colaboradores.
O segundo nível de orquestração de qualidade de serviço, que é justamente o
foco desta seção, é a orquestração intra-mídia. Essa orquestração está diretamente
relacionada com a tarefa de buscar e exibir cada um dos objetos de execução,
procurando fazer com que a qualidade de suas apresentações sejam mantidas. Para
que isso seja possível, recursos devem ser reservados tanto nas estações cliente
(formatador) e servidora de conteúdo, como também no provedor de comunicação
entre essas estações. Caberá ao formatador negociar a QoS necessária junto aos
provedores de comunicação e processamento, dando início ao processo de
orquestração e reserva de recursos, tais como CPU e banda passante.
No formatador, o gerenciador intra-mídia é o módulo responsável por
desempenhar esse papel de negociador. Na realidade, além de negociar a QoS para
as exibições, o orquestrador deve também procurar monitorar se os acordos
estabelecidos estão sendo respeitados, notificando os executores de apresentação e
de pré-busca, sempre que não for possível manter a exibição de um objeto com a
qualidade desejada.
Para cada conteúdo de objeto de execução a ser exibido, o gerenciador deve
solicitar que um orquestrador intra-mídia tente distribuir a reserva de recursos
desde o servidor onde o conteúdo encontra-se no momento gravado, passando
pelo provedor de comunicação, até o buffer do formatador (ou da própria
ferramenta de exibição), que servirá de memória cache para armazenar o conteúdo
localmente. Além disso, se possível, a orquestração e reserva deve também
procurar alocar recursos no sistema operacional da máquina onde executa a
ferramenta de exibição, a fim de garantir que ela terá à sua disposição a
capacidade de processamento necessária. Vale salientar que, nos casos em que a
preparação não coloca previamente em cache todo o conteúdo do objeto, a reserva
dos recursos no caminho até o local original de armazenamento das unidades de
informação deve ser mantida durante a fase de apresentação do objeto de
execução, até que todo o conteúdo do objeto seja obtido.
Note que, para completar o processo de reserva, pode ser necessário que se
faça também uma negociação de alocação de recursos no sistema operacional da
Hipermídia
88
máquina servidora de conteúdo, para que o processo servidor tenha garantidos,
entre outros parâmetros, o retardo máximo e a banda passante no acesso aos dados
armazenados. Como já colocado na Seção 3.1, a presença do gerenciador intramídia no formatador está condicionada à existência de algum suporte à reserva de
recursos na rede ou nos sistemas operacionais.
A Figura 21 utiliza a proposta do Modelo de Composição de Serviços (SCM
– Service Composition Model), definido em (Colcher, 1999), para ilustrar os
componentes e provedores envolvidos na transmissão e exibição do conteúdo de
um objeto de execução em uma apresentação hipermídia.
Ferramenta
de
Exibição
Mídia
(conteúdo)
Provedores
de
Acesso
Servidor
de Conteúdo
Formatador
Provedor de infra-estrutura
Figura 21 – Visão simplificada da exibição de conteúdos de documentos hipermídia
representada através do modelo de composição de serviços16.
O SCM define dois elementos básicos: os componentes de usuário, que
correspondem às entidades que fazem uso direto dos serviços (na figura,
representados como círculos), e os provedores, que são responsáveis pela provisão
do serviço (representados como nuvens). Uma abstração especial do modelo,
denominada MediaPipe (ilustrada como cilindros), permite capturar a idéia de
uma associação entre componentes de usuário, sobre a qual especificações de QoS
podem ser definidas e gerenciadas. Para que possa ser estabelecido um MediaPipe
entre dois componentes, o provedor poderá ser formado por outros componentes
de serviço (entidades de software ou hardware que implementem o serviço). Esses
16
Para não sobrecarregar o desenho, foi ilustrada a associação apenas entre uma ferramenta e um
conteúdo de objeto.
Hipermídia
89
componentes, por sua vez, provavelmente utilizarão os serviços de um provedor
de nível mais baixo de abstração, formando assim uma estruturação aninhada de
provisão de serviços, que pode se repetir sucessivamente até que sejam alcançados
os recursos físicos propriamente ditos (enlace de comunicação, CPU etc.). Os
provedores do modelo podem ser classificados em provedores de infra-estrutura e
provedores de acesso. O primeiro tipo permite o estabelecimento de MediaPipes
entre componentes localizados em um mesmo nível de abstração, enquanto o
segundo tipo possibilita o estabelecimento dessas associações entre um
componente de usuário do serviço e um componente interno do provedor do
serviço. Nada impede que os componentes de usuário sejam componentes
compostos, constituídos de outros componentes de usuário e provedores
interligando esses componentes.
Na Figura 21, o formatador, ou mesmo a ferramenta, deve conter um
componente responsável por recuperar as unidades de informação do servidor de
conteúdo e armazená-las em um buffer do formatador ou direto da ferramenta.
Essa busca dos dados deve seguir uma implementação de protocolo que o servidor
de conteúdo compreenda, tais como HTTP, RTP etc.
Quando o conteúdo de um objeto de execução encontrar-se armazenado na
mesma máquina onde a ferramenta de exibição executa, o provedor de infraestrutura deixa de existir no processo de busca do conteúdo e os papéis de servidor
e formatador se fundem em um único componente, conforme ilustra a Figura 22.
Nesse caso, embora desenhados como dois provedores de acesso, existirá apenas
um provedor intermediando todas as comunicações, que será justamente o sistema
operacional da máquina.
As duas figuras anteriores retratam o caminho percorrido pelos dados no
serviço de apresentação das mídias. Atuando em um outro plano estão as
orquestrações de QoS inter-mídia e intra-mídia, procurando garantir que o serviço
de apresentação dos conteúdos encontre-se dentro dos limites desejados pelo autor
e pelo usuário. Sendo assim, a orquestração de QoS pode ser considerada como
um meta-serviço que age sobre o serviço de transmissão e exibição dos conteúdos.
Meta-serviços são modelados pelo SCM utilizando os mesmos conceitos de
componentes e provedores, em um plano separado. Através de interfaces meta nos
componentes e provedores do plano de serviços (ou plano de dados), os
Hipermídia
90
componentes do plano de meta-serviços (ou plano de controle) têm condições de
manipular as entidades que implementam o serviço e suas associações
(MediaPipes). Exemplo de aplicação dos conceitos de plano de meta-serviços e
plano de serviços são encontrados, respectivamente, nas pilhas de controle e de
dados das redes ATM. Outro exemplo são os protocolos de construção de tabelas
de rotas (por exemplo: RIP, OSPF, BGP etc.) que atuam sobre o serviço de
roteamento das informações (por exemplo: IP).
Ferramenta
de
Exibição
Mídia
(conteúdo)
Provedores
de
Acesso
Formatador
Figura 22 – Exibição de conteúdos armazenados localmente, eliminando a figura do
provedor de infra-estrutura.
A Figura 23 ilustra os conceitos de serviço e meta-serviço no projeto de
ambientes de execução hipermídia, estendendo e detalhando as informações
anteriormente apresentadas na Figura 21 e na Figura 22. A figura é também uma
nova visão para a Figura 16, descrita na Seção 3.1, mas com um destaque para o
posicionamento das funções de formatação nos dois planos.
Hipermídia
91
Plano de Serviços
Ferramentas
de Exibição
Mídias
Escalonador de
Apresentação
Plano de
Pré-busca
Escalonador
de Pré-busca
Servidores
Plano de
Execução
Componente
de busca
Base de
Base de Documentos
SMIL
Contextos
NCM
Sistema de
Comunicação
ML
ML
Solicitador/
Conversor
Orquestrador
Intra-mídia
Adaptador
Orq. Pré-busca
Ger. Orq.
Intra-mídia
Orq.
Apresentação
PIC
Gerente de
Contexto
Neg. de Orq.
Inter-mídia
Provisão e Gerência
de QoS
Plano de Meta-Serviços
Figura 23 – Ilustração dos conceitos de serviço e meta-serviço nos ambientes de
execução hipermídia.
A Figura 23 permite rever de uma forma sistemática os procedimentos
desempenhados no controle da apresentação dos hiperdocumentos, enumerados a
seguir. Como alguns dos procedimentos podem ocorrer de maneira concorrente, a
ordem de apresentação não deve ser entendida como uma seqüência de execução.
procedimento 1:
O Solicitador busca um documento (ou parte de um
documento) e, caso seu modelo seja diferente do modelo de execução
esperado pelo formatador, entrega o documento para ser traduzido por
um conversor. Na figura, por simplificação, solicitador e conversor estão
representados em um mesmo componente. Além da tradução, o
solicitador pode também unir à descrição do documento de entrada,
especificações oriundas de outros modelos, como discutido na Figura 3.
procedimento 2:
De posse de uma especificação fiel ao modelo de
execução, contendo as especificações de QoS intrínsecas ao documento
(relacionamentos entre as mídias, parâmetros das características de
exibição de cada objeto etc.), o solicitador passa a requisição da
apresentação de um contêiner para o negociador de orquestração inter-
Hipermídia
92
mídia. Além das especificações intrínsecas ao documento, restrições de
QoS podem ser impostas pelo próprio usuário leitor, se o ambiente de
navegação assim permitir. Além disso, o pedido deve também informar
o ponto de entrada no contêiner (evento de apresentação) por onde a
exibição deve ser iniciada.
procedimento 3:
O Negociador de Orquestração Inter-mídia (o análogo
de um bandwidth broker intra-mídia, só que para orquestração intermídia) tem como função dividir as responsabilidades de formatação
entre os vários módulos de orquestração (inter-mídia) de apresentação
que estiverem presentes no sistema (cliente, servidor, proxy etc.). Nessa
etapa, o negociador pode, por exemplo, aplicar transformações sobre a
especificação dos documentos, restringindo as possibilidades de
formatação para cada adaptador do sistema. Como este trabalho trata
apenas da formatação no lado cliente, essa etapa foi omitida na Seção
3.1, fazendo com que toda a responsabilidade de orquestração recaia
sempre sobre o orquestrador de apresentação no cliente.
procedimento 4:
O compilador do Orquestrador de Apresentação recebe
a descrição do documento, juntamente com as informações adicionais do
solicitador (ponto de entrada, restrições de QoS do usuário, hora prevista
para iniciar a exibição etc.), e constrói o plano de execução. Para isso, o
orquestrador consulta, com auxílio do proxy de informações contextuais
(componente PIC), os parâmetros que definem o contexto de exibição, e
requisita ao componente Adaptador que implemente os ajustes cabíveis
(normalmente, estáticos), tais como seleção de alternativas e ajuste dos
tempos elásticos. Também pode ser realizada nessa etapa a verificação
da consistência temporal e espacial do documento. Se o mecanismo de
pré-busca estiver presente no formatador, o compilador de apresentação
aciona o compilador do orquestrador de pré-busca (procedimento 5),
caso contrário, essa próxima etapa é ignorada.
procedimento 5:
Considerando a existência de um mecanismo de pré-
busca no formatador, o compilador de pré-busca aplica sua estratégia
para construir o Plano de Pré-Busca, sendo para isso consultadas as
características do Plano de Execução e do Contexto de Exibição.
Hipermídia
procedimento 6:
93
O controle retorna para o orquestrador de apresentação
para encerrar a fase de compilação. Se a hora prevista para iniciar a
exibição tiver sido informada pelo solicitador e mecanismos de reserva
antecipada estiverem disponíveis no formatador, o compilador de
apresentação aciona o gerenciador intra-mídia (procedimento 10),
obviamente, se existir no formatador uma implementação desse
componente. Caso a hora de início não esteja informada, o gerenciador
intra-mídia só é acionado na fase de execução do documento
(procedimento 7). De todo modo, o resultado final é a construção, por
parte do orquestrador de apresentação, das diversas cadeias temporais do
hiperdocumento e o retorno de um identificador que permite disparar a
apresentação propriamente dita a partir do ponto de entrada
originalmente informado pelo solicitador de exibição.
procedimento 7:
O controle da apresentação propriamente dita do
documento inicia sob a demanda do usuário. Isso implica iniciar a
execução do componente Gerenciador Intra-Mídia no plano de metaserviços (se isso ainda não tiver sido feito), do componente Escalonador
(ou Executor) de Apresentação no plano de serviços e do componente
Escalonador (ou Executor) de Pré-busca também no plano de serviços.
Evidentemente, se os mecanismos de pré-busca e orquestração intramídia não estiverem disponíveis, a última iniciação não será feita.
procedimento 8:
Uma vez iniciado, o Escalonador de Apresentação
(plano de serviços) consulta o plano de execução e, sempre que
necessário, instancia uma nova ferramenta de exibição. O escalonador
também controla as transições nos estados dos eventos, avalia os elos e
envia comandos de ação para as ferramentas sempre que a condição de
um elo causal é satisfeita. Ainda como responsabilidade do serviço de
execução da apresentação, encontram-se os envios de comandos para
acelerar ou desacelerar a taxa de exibição das mídias contínuas, quando
algum ajuste estiver programado no plano.
procedimento 9:
O Escalonador de Pré-busca, no plano de serviços, ao
ser iniciado, passa a observar o plano de pré-busca e, toda vez que
Hipermídia
94
encontra uma nova busca programada, requisita ao componente de busca
que a inicie.
procedimento 10:
O Gerenciador Intra-mídia, no plano de meta-serviços,
consulta o plano de pré-busca, ou mesmo de execução, para descobrir os
momentos programados para iniciar as buscas. Para cada busca, o
gerenciador solicita a um Orquestrador Intra-mídia que negocie a
qualidade de serviço para a sua transferência. No processo de
negociação, o orquestrador intra-mídia pode dividir as responsabilidades
por mais de um orquestrador de QoS (sistema operacional, rede etc.). O
Orquestrador
Intra-mídia
também
permanece
monitorando
os
orquestradores de QoS com os quais estabeleceu negociações, a fim de
identificar qualquer violação (ou possibilidade de violação) no acordo
firmado. Quando uma violação é notificada, primeiro o orquestrador
tenta redistribuir as responsabilidades entre os orquestradores de QoS e,
com isso, sintonizar a QoS intra-mídia. Se isso não for possível, o
orquestrador intra-mídia reporta o problema para o gerenciador que,
provavelmente, repassará a notificação ao orquestrador de pré-busca ou
diretamente ao orquestrador de apresentação.
procedimento 11:
O Executor do Orquestrador de Pré-busca, no plano de
meta-serviços, permanece monitorando o contexto de exibição, o plano
de execução, o plano de pré-busca e o gerenciador intra-mídia. Qualquer
alteração ou violação informada, o orquestrador procura compensar
direto no plano de pré-busca. Se isso não for possível, o orquestrador de
pré-busca notifica o executor do orquestrador de apresentação a respeito
do problema.
procedimento 12:
O Executor do Orquestrador de Apresentação, no plano
de meta-serviços, permanece monitorando o contexto de exibição, o
plano de execução, o orquestrador de pré-busca e o gerenciador intramídia. Qualquer alteração ou violação informada, o executor procura
ajustar o plano de execução. Quando necessário, o executor pode
requisitar também os serviços do componente adaptador.
A próxima seção define a interface para utilização dos serviços de
orquestração intra-mídia no formatador.
Hipermídia
95
4.2.1
Arquitetura para implementação da orquestração intra-mídia
A modelagem proposta nesta seção faz uso do framework de orquestração
de recursos (ou framework de QoS) proposto em (Gomes 1999; Gomes et al.,
2001). As classes preenchidas com a cor cinza, na Figura 24, destacam os
componentes do framework de QoS que influenciaram e foram diretamente
utilizados na proposta de suporte à implementação de mecanismos de
orquestração intra-mídia em formatadores hipermídia. De acordo com o diagrama
de classes da figura, o gerenciador (classe IntraMediaManager) é a fachada do
mecanismo e é definido como sendo composto por um orquestrador intra-mídia
(classe IntraMediaOrchestrator).
O gerenciador intra-mídia oferece em sua interface cinco principais
métodos. O método prepareOrchestration recebe o plano (de busca ou de
execução,
podendo
inclusive
monitorar
ambos)
a
ser
monitorado
e,
opcionalmente, a hora prevista para a chamada ao seu método startOrchestration.
Esse último parâmetro é útil apenas em cenários com suporte à reserva antecipada,
pois permite que o gerenciador tenha conhecimento dos instantes programados
para iniciar as buscas. O método startOrchestration deve ser chamado para
acionar a orquestração intra-mídia; sua chamada pressupõe que o plano passado na
preparação começou a ser executado. O método stopOrchestration encerra o
processo de orquestração intra-mídia e limpa as estruturas de dados do
gerenciador.
Por
fim,
os
métodos
addIntraMediaListener
e
removeIntraMediaListener permitem, respectivamente, acrescentar ou remover
um objeto da lista de observadores do mecanismo de gerência da orquestração
intra-mídia
(objetos
da
classe
IntraMediaOrchestrationListener).
Esses
observadores serão notificados da impossibilidade de estabelecer um novo
contrato (chamada ao método notifyAdmissionFail) ou violações em contratos já
estabelecidos (chamada ao método notifyTuningFail). As chamadas a esses
métodos informam o objeto de execução com o qual o problema foi identificado.
Hipermídia
96
IntraM ediaM anager
IntraM ediaOrchestrationLis tener
prepa reOrc hestrat ion()
s tar tOr c hest rat ion ()
s topOr c hest rat io n()
addIntr aMe diaL is t ener ()
rem oveIntraM ediaListener()
getS t atist ic s()
1..*
n otify Ad miss i onFai l()
n otify Tuni ngFail()
QoS Negotiator
M onitor
IntraM ediaOrchestrator
request()
c onfirm ()
1
1
1
1
getStatis tics ()
lowerLe velTuner
1
sam eLevelTuner
1..*
A dm is s io nContr oller
1..*
adm it()
com m it ()
1
QoSTuner
a lert()
tune()
higherLevelM onitor
Figura 24 – Diagrama de classes para implementação de mecanismos de orquestração
intra-mídia.
A partir de uma análise dos planos, para cada objeto de execução, o
gerenciador deve iniciar, junto ao orquestrador, um processo de negociação de
reserva de recursos. Essa negociação resultará em uma chamada ao método
request do negociador do orquestrador (classe QoSNegotiator). Cabe ao
negociador separar as responsabilidades entre os vários controladores de admissão
(classe AdmissionController) dos provedores que estejam envolvidos na provisão
do serviço e repassar aos mesmos um pedido de admissão. A partir daí, o processo
assume o comportamento recorrente definido pelo framework de orquestração de
recursos (Gomes, 1999; Gomes et al., 2001). O negociador de QoS fica
aguardando que todos os controladores de admissão retornem se foi possível ou
não estabelecer a reserva. Em caso afirmativo, o negociador passa então a esperar
um pedido de confirmação da reserva (chamada ao método confirm) que é então
repassada aos controladores de admissão. Se algum dos controladores de admissão
não conseguir reservar os recursos solicitados, o negociador pode tentar uma nova
distribuição das responsabilidades, até que, sendo impossível concluir a
negociação com sucesso, o gerenciador é informado pelo orquestrador e notifica
seus observadores (objetos da classe IntraMediaOrchestrationListener).
O acionamento da orquestração intra-mídia faz com que seja também
iniciado o monitor intra-mídia (classe Monitor) do orquestrador intra-mídia. Esse
Hipermídia
97
monitor permanece observando os sintonizadores dos provedores de serviço
(objetos da classe QoSTuner) e é notificado de qualquer violação nos contratos de
QoS já firmados. Essa notificação se dá através de uma chamada ao método
getStatistics do monitor intra-mídia. Isso faz com que o monitor acione o
sintonizador de QoS intra-mídia (chamada ao método alert do objeto da classe
QoSTuner do orquestrador intra-mídia) que deve tentar uma nova distribuição das
responsabilidades de qualidade de serviço entre os provedores. Se isso não for
possível, o sintonizador intra-mídia notifica o gerenciador da violação. Note que o
gerenciador da orquestração intra-mídia no formatador atua como monitor do seu
orquestrador intra-mídia.
Quando informado da violação, o gerenciador pode realizar uma nova
tentativa de negociação sem que seja preciso notificar os orquestradores de prébusca e de apresentação. Caso não tenha sucesso, o orquestrador de pré-busca, ou
o orquestrador de apresentação, deve ser informado, para que as correções sejam
efetuadas diretamente no respectivo plano, pois, nesse caso, para corrigir o erro na
orquestração intra-mídia, a única solução é sintonizar a orquestração inter-mídia.
4.3
Mecanismos de adaptação
Com o intuito de obter uma qualidade próxima da ideal durante a execução
de um documento, as técnicas de pré-busca procuram antecipar as ações e
previamente preparar o sistema e os dados dos conteúdos dos objetos. Nesse
sentido, o principal objetivo da orquestração de pré-busca é ter os eventos de
exibição já preparados, para que, quando necessária, a transição para o estado
ocorrendo seja sempre imediata, ou dentro de limites aceitáveis.
A orquestração intra-mídia aparece como uma segunda funcionalidade,
atuando na gerência dos recursos necessários para manter a exibição, ou mesmo a
preparação, do conteúdo de cada um dos objetos de execução do documento. Mais
uma vez, o objetivo é manter a qualidade da execução dos documentos em níveis
aceitáveis, diminuindo a probabilidade de que as especificações do autor não
venham a ser respeitadas.
Apesar de serem recursos importantes, apenas os mecanismos de pré-busca e
orquestração intra-mídia não são suficientes para garantir a boa qualidade das
Hipermídia
98
apresentações. Sempre pode haver situações que impeçam continuar a exibição do
documento de modo satisfatório. No caso da pré-busca, a memória cache pode não
ter espaço suficiente para armazenar todos os dados necessários. No caso da
orquestração intra-mídia, a rede e o sistema operacional (provedores de serviços
de comunicação e processamento) podem não conseguir oferecer, ou garantir, a
qualidade de serviço solicitada. Pode ser, inclusive, que algum provedor não
ofereça suporte para que a QoS seja negociada, restando apenas como opção um
serviço de melhor esforço. Em todos esses casos, para que o formatador recupere a
sincronização da apresentação, é necessário que sejam acionadas estratégias de
adaptação para, por exemplo, diminuir a duração (ou a taxa de exibição) de alguns
objetos, substituir objetos por outros de menores exigências de QoS, ou mesmo
descartar alguns objetos.
Conforme já discutido na Seção 2.1, são muitas as motivações para a
existência de mecanismos de adaptação em apresentações hipermídia. A
adaptação pode ser interessante, não apenas como um mecanismo reativo a
situações que possam causar impacto na qualidade da apresentação, como um
mecanismo que, antes de iniciar a apresentação, procura adequar o documento às
informações do contexto de exibição e às especificações do autor.
De acordo com os conceitos apresentados na Seção 4.2, os mecanismos de
adaptação, de um modo geral, podem ser vistos como parte integrante do processo
de orquestração inter-mídia da apresentação. Quando utilizada como um
mecanismo de reação e ajuste a violações no plano de execução originalmente
previsto, a adaptação atua como um auxiliador à estratégia de sintonização,
enquanto que, quando aplicada na fase de compilação, a adaptação apóia a
estratégia de negociação.
O restante desta seção aborda, de maneira mais detalhada, a questão da
adaptação através do ajuste elástico das durações dos objetos. Os aspectos
relacionados à seleção de alternativas não serão tratados, pois foram discutidos no
Capítulo 2 (Seções 2.1 e 2.3.3). Contudo, no final, a seção trata da interface do
adaptador para atuar integrado aos demais componentes do formatador,
oferecendo serviços de ajuste dos tempos elásticos e de seleção de alternativas.
Hipermídia
99
4.3.1
Ajuste dos tempos elásticos
Mecanismos de ajuste dos tempos elásticos (elastic time computation),
termo formalmente definido em (Kim & Song, 1995), procuram adaptar as
apresentações dos objetos a fim de garantir a consistência temporal dos
documentos. O objetivo é alcançado através de diminuições (shrinking) ou
aumentos (stretching) nas durações ideais dos eventos de apresentação.
Evidentemente, para que se possa aplicar esse tipo de mecanismo de adaptação, é
preciso que o modelo de execução ofereça flexibilidade na especificação das
durações dos eventos.
A especificação da duração, como uma classe extensível no modelo de
execução (Seção 2.3.1.3), permite à arquitetura de formatação explorar a definição
de durações flexíveis para as ocorrências dos eventos não instantâneos (em
particular os de apresentação) e, com isso, aplicar os mecanismos de ajuste
elástico. O diagrama de classes da Figura 25 ilustra as extensões já definidas no
modelo de execução para a classe Duration.
Duration
expected
actual
INDETERMINATE
UnflexibleDuration
value
FlexibleDuration
minValue
maxValue
CostFunctionDuration
idealValue
minValueCost
maxValueCost
getValueCost()
SimpleDiscreteDuration
ConvexPieceW iseLinearCostFunction
Figura 25 – Classes de duração no modelo de execução.
1
LinearSegment
2.. n beginValue
endValue
beginCost
coefficient
Hipermídia
100
De acordo com a figura, o modelo define uma duração como podendo ser de
dois tipos: inflexível (classe UnflexibleDuration), que não permite que ajustes
sejam feitos sobre o valor esperado, ou flexível (classe FlexibleDuration), que
especifica uma faixa de possíveis valores para escolha do valor esperado. São
justamente as durações derivadas dessa classe (ou de subclasses dela) que devem
ser utilizadas pelos mecanismos de ajuste dos tempos elásticos.
Uma subclasse especial de FlexibleDuration é definida para permitir a
especificação
de
durações
flexíveis
como
funções
de
custo
(classe
CostFunctionDuration). Uma função de custo possui, além dos limites para
escolha do valor esperado, a especificação de pelo menos um valor ideal e
medidas de custos, que permitem inferir a degradação da qualidade quando se
escolhe um valor esperado diferente do ideal. A Figura 26a ilustra graficamente a
descrição de uma instância de CostFunctionDuration com valores mínimo, ideal e
máximo respectivamente iguais a θmin, θid e θmax. No exemplo, o custo do valor
mínimo é dado por c1 e o custo do valor máximo é dado por c2. Na realidade, uma
função desse tipo define dois custos de degradação: um para durações abaixo da
ideal e maiores ou iguais à duração mínima, e outro para durações acima da ideal
e menores ou iguais à duração máxima.
c2
c2
c2
c2
c1
c1
c1
c1
0
θmin
θid
θmax
0
(a)
θmin
θid
θmax
0
θmin
(b)
θid
θmax
0
θid
θmin
(c)
θmax
(d)
Figura 26 – Exemplos de funções de custo. a) Função de custo simples. b) Função de
custo simples, porém discreta. c) Função de custo linear do tipo piece-wise com dois
segmentos. d) Função de custo linear do tipo piece-wise com múltiplos segmentos.
A
Figura
26b
ilustra
um
exemplo
de
instância
da
classe
SimpleDiscreteDuration. A diferença é que, nesse caso, apesar de flexível, a
duração esperada precisa ser escolhida como sendo uma das três opções (mínima,
ideal ou máxima), representando uma função de custo discreta.
O modelo define ainda uma classe ConvexPieceWiseLinearCostFunction,
para representar funções de custo convexas que sejam compostas de múltiplos
segmentos lineares. Cada segmento (classe LinearSegment) possui uma duração
Hipermídia
101
inicial e uma duração final, o custo da duração inicial e o coeficiente angular do
segmento. Os gráficos da Figura 26c e da Figura 26d são exemplos de funções de
custo lineares, piece-wise e convexas. Novos tipos de durações, e principalmente
de funções de custo, podem ser facilmente incorporados ao formatador através de
extensões das classes apresentadas na Figura 25.
Em certos casos, é útil que alguns dos atributos das durações (por exemplo,
duração ideal, os limites para a duração etc.) sejam especificados como valores
indeterminados. Um nó cujo conteúdo é apresentado até que alguma ação externa
interrompa a sua exibição ou um nó que termina por si próprio a sua apresentação
são exemplos de objetos de execução, cujos eventos de apresentação possuem
durações imprevisíveis. Sendo assim, a classe Duration define uma constante
INDETERMINATE, com um valor negativo, que serve para especificar atributos
da duração como sendo indeterminados.
O objetivo de um mecanismo de ajuste dos tempos elásticos é procurar
calcular as durações esperadas para os eventos de apresentação dos objetos,
respeitando os valores válidos para a duração de cada evento e, ao mesmo tempo,
os relacionamentos impostos pelo autor. Contudo, em algumas situações, o
mecanismo de ajuste pode encontrar mais de uma solução para o problema
colocado. Se as durações forem especificadas como funções de custo, o algoritmo
de ajuste pode tentar aplicar uma função objetiva, que calcule as durações
esperadas para cada objeto, de tal maneira que o custo total dos ajustes seja
minimizado (Bachelet et al., 2000; Buchanan & Zellweger, 1993b; Kim & Song,
1995). No entanto, esse pode não ser o único parâmetro para escolha da melhor
configuração das durações para o documento. Outros critérios que o mecanismo
de ajuste pode levar em conta são:
•
Minimizar o número de objetos com eventos de exibição com duração
esperada diferente da duração ideal. A idéia desse critério é diminuir o
número de objetos que tenham as suas durações modificadas, assumindo
que modificar a duração de um objeto pode impor um custo computacional
elevado na plataforma exibição.
•
Minimizar a soma dos desvios em relação às durações ideais. Quando
houver mais de uma solução para o critério anterior, esse critério pode
servir como um complemento. No entanto, se aplicado como primeiro
Hipermídia
102
critério, ele tende a ser contrário ao critério anterior, pois a idéia é
distribuir ao máximo as alterações, buscando torná-las o menos perceptível
possível.
O mecanismo de ajuste pode também se guiar por restrições externas ao
documento, como por exemplo, encontrar o menor custo de ajuste a partir de uma
duração total de apresentação que venha a ser definida. Uma aplicação prática
desse tipo de restrição seria na programação de TV, onde os tempos de alguns
programas ou comerciais podem precisar ser ajustados dinamicamente, devido a
atrasos imprevisíveis na grade. Outra restrição externa que pode vir a ser imposta
é o número máximo de objetos que podem ter suas durações recalculadas.
É útil também que uma estratégia de ajuste saiba, não apenas encontrar uma
solução ótima, como também responder qual seria a menor e a maior duração
válida para a exibição do documento, ou de um de seus trechos. Melhor ainda se a
estratégia for capaz de manter essas informações atualizadas, conforme transcorre
a apresentação do documento, pois pode auxiliar quando o ajuste precisar ser feito
em tempo de execução (Seção 3.1).
4.3.2
Arquitetura para implementação de mecanismos de adaptação
O módulo adaptador no formatador (classe DocumentAdapter) responde por
três funções básicas: avaliar as regras de exibição (Seção 2.3.3), definir o objeto
de execução a ser selecionado em um conjunto de alternativas (Seção 2.3.3) e
ajustar as durações dos eventos não instantâneos (Seção 2.3.1.3) contidos em uma
cadeia temporal que seja passada como parâmetro.
As duas primeiras funções podem ser desempenhadas pela própria
implementação do módulo de adaptação, utilizando as informações coletadas do
proxy de informações contextuais (classe ContextManager). O ajuste dos tempos
elásticos, devido a sua maior complexidade e variedade de possibilidades para
realizar a tarefa, é modelado como um ponto flexível, através de uma estratégia
genérica. O adaptador pode, inclusive, possuir estratégias distintas para o ajuste
em tempo de compilação e o ajuste em tempo de execução. O método de ajuste
dos tempos (adjustTimeChain) recebe como parâmetro, além da cadeia temporal,
Hipermídia
103
um atributo que informa se o cálculo deve ser realizado com a estratégia de
compilação (atributo compileTimeStrategy) ou com a estratégia de execução
(atributo
executionTimeStrategy)
do
adaptador.
Além
desses
atributos,
opcionalmente, o método de ajuste pode ser informado sobre a restrição de
duração imposta pelo autor (ou pelo usuário) e o número máximo de objetos que
podem ter suas durações modificadas. O método adjustTimeChain retorna um
valor booleano dizendo se foi possível, ou não, encontrar uma configuração
consistente.
Docum entA dapter
queries
Context Mana ger
s olves
Ex ecutionObjec tA lternatives
evaluateP resentationRule()
selectA l ter native()
adjustTim eChain ()
getParam eterValue()
com pileTim eS trategy
evaluates
executionTim eStrategy
Ti m eCh ain
P resentationRule
getEx pec tedDuration()
getM inim um Duration()
getM axim um Duration()
0..1
0 ..1
Elastic Tim eCom putationS trategy
adjust()
Figura 27 – Diagrama de classes para implementação de mecanismos de adaptação.
Uma vez executada e conseguindo encontrar uma solução para a cadeia
temporal, a estratégia de ajuste deve gravar na cadeia a duração programada para
sua exibição completa. Se possível, a estratégia deve especificar também os
limites mínimo e máximo para a duração da cadeia. Esses valores podem,
posteriormente,
ser
consultados
através
de
chamadas
aos
métodos
getExpectedDuration, getMinimumDuration e getMaximumDuration da própria
cadeia temporal. Da mesma forma, os eventos não instantâneos no modelo
possuem dois atributos adicionais que podem guardar a duração mínima e máxima
para sua ocorrência que não infringe a consistência temporal do documento. Esses
valores, se possível, são calculados pelas estratégias de ajuste e podem se
modificar ao longo da exibição do documento.
Formatador HyperProp
104
5
Este capítulo descreve a implementação do ambiente de execução do
sistema hipermídia HyperProp (Soares et al., 2000), feita com base no modelo de
execução definido no Capítulo 2 e na arquitetura proposta nos Capítulos 3 e 4.
Com efeito, o trabalho de implementação serviu para refinar e validar as
definições do framework para construção de formatadores hipermídia. Java foi a
linguagem de programação escolhida para o desenvolvimento do ambiente de
execução, buscando uma solução independente de plataforma.
5.1
Conversor NCM
Esta seção comenta os principais aspectos da tradução de documentos NCM
(Casanova et al., 1991; Soares et al., 1995; Soares et al., 2000; Soares et al., 2003)
para o modelo de execução do formatador HyperProp, cuja implementação baseiase no modelo descrito na Seção 2.3. A razão dessa conversão deve-se ao fato do
NCM ser o modelo conceitual utilizado pelos ambientes de autoria e
armazenamento do sistema HyperProp. Uma vez que o modelo de execução
descrito no Capítulo 2 foi diretamente influenciado pelas propostas do modelo
NCM, muitas das entidades são facilmente convertidas, conforme tornar-se-á mais
claro ao longo desta seção.
O NCM é um modelo orientado a objetos, baseado nos conceitos usuais de
nós e elos. Nós representam fragmentos de informação, enquanto elos permitem
estabelecer relacionamentos de sincronização espacial e temporal entre os nós.
Um nó NCM pode ser simples ou composto. O nó simples, denominado nó
de conteúdo (ou nó terminal), representa um nó de mídia usual, podendo ser
especializado em classes como texto, imagem, vídeo, áudio etc. O nó composto,
denominado nó de composição, é utilizado para organizar logicamente os
105
componentes do documento, sendo útil também para oferecer suporte ao reuso de
partes de um documento17.
A Figura 28 ilustra um exemplo de documento estruturado com o uso de
composições. O nó de composição Coisa de Pele representa o documento, sendo
constituído por duas outras composições, Beth Carvalho e Jorge Aragão, que
organizam a interpretação de uma mesma música (“Coisa de Pele”) por dois
diferentes cantores. A composição Beth Carvalho contém o nó composto Letra,
além de um nó de conteúdo texto música-Beth e um nó de conteúdo vídeo clipBeth; enquanto a composição Jorge Aragão contém a mesma composição Letra e
outros dois nós de conteúdo: o texto música-Jorge e o vídeo clip-Jorge. A
composição Letra possui nós de conteúdo que contêm os versos da música em
fragmentos separados. Relações diferentes das relações de estruturação são
representadas no NCM por elos. Por exemplo, um relacionamento de
sincronização temporal entre os objetos música-Beth e versos-01 é definido
através do elo lb1. O elo NCM é muito similar ao elo do modelo de execução e seu
tratamento será comentado mais adiante.
lb1
lj1
v1
lb2
lb3 v2
lb4
v1
lj2
lj3
lj4
v2
Figura 28 – Exemplo de documento estruturado em composições.
17
O NCM define composição como uma classe abstrata, de onde derivam diversas subclasses
(contexto do usuário, contexto de versões, base privada etc.), que definem diferentes semânticas
para a estruturação dos nós (Soares, 2000). Por simplificação, esta seção tratará os nós compostos
genericamente como composições, a não ser que seja necessário referir-se a uma determinada
especialização.
106
Como é possível perceber pelo exemplo, o modelo possui um importante
recurso de reuso que permite que um mesmo nó (de conteúdo ou de composição)
esteja contido em mais de uma composição diferente (por exemplo, o nó Letra
contido nas composições Beth Carvalho e Jorge Aragão). Uma vez que o modelo
também permite que nós de composição estejam aninhados em qualquer
profundidade (composição Letra contida na composição Beth Carvalho, que por
sua vez está contida na composição Coisa de Pele), existe definido no NCM o
conceito de perspectiva do nó. Intuitivamente, a perspectiva de um nó identifica
através de que seqüência de nós de composição aninhados uma dada instância de
um nó N é observada, podendo haver diferentes perspectivas para um mesmo nó
N, se esse nó estiver contido em mais de uma composição. Por exemplo, na figura,
o nó versos-01 possui duas perspectivas distintas: P1=/Coisa de Pele/Beth
Carvalho/Letra/versos-01 e P2=/Coisa de Pele/Jorge Aragão/Letra/versos-01.
Essa flexibilidade do modelo de autoria, juntamente com o fato dos elos não
estarem embutidos nos conteúdos dos nós, constitui-se em um suporte à adaptação
estática dos relacionamentos da apresentação, pois os relacionamentos de um
objeto poderão variar em função da perspectiva que o nó estiver sendo
apresentado. No exemplo, dependendo da perspectiva, o relacionamento que o nó
versos-01 participa como condição é diferente (lb4 em P1 e lj4 em P2). Para toda
perspectiva, o modelo denomina o nó mais interno (no caso do exemplo, o nó
versos-01) como sendo o nó base da perspectiva.
De um modo geral, a operação do conversor NCM consiste em receber
como entrada a perspectiva de um nó e retornar um contêiner de execução (Seção
2.3.4). Se o nó base da perspectiva for um nó de conteúdo, o contêiner gerado irá
possuir os objetos de execução criados a partir desse nó18, os elos de restrição
(Seção 2.3.2.2) dos quais o nó participa, os elos causais (Seção 2.3.2.1) nos quais
o nó atua como condição e os objetos de execução derivados a partir das
perspectivas dos nós que ancoram nesses mesmos elos que o nó (e perspectiva)
passado como parâmetro. O processo não é recursivo, ou seja, novos elos que
ancorem nesses outros nós não são analisados nesse momento pelo conversor. Os
objetos de execução derivados desses nós são marcados pelo conversor como
18
Mais adiante ficará claro que um nó NCM pode resultar em mais de um objeto de execução.
107
parcialmente construídos. Esse tratamento é útil em um processo incremental de
conversão, compilação e execução dos documentos.
Se o nó base da perspectiva for um nó de composição, o conversor irá
estender o procedimento de criar os objetos de execução, elos e objetos de
execução relacionados também para cada nó que esteja contido, ou recursivamente
contido, na composição.
No exemplo da Figura 28, se fosse entregue ao conversor a perspectiva
/Coisa de Pele/Beth Carvalho/música-Beth, o conversor iria gerar os objetos de
execução derivados do nó música-Beth, na perspectiva passada como parâmetro,
iria tratar os elos lb1, lb2 e lb3, e iria gerar objetos de execução parcialmente
construídos para os nós versos-01, versos-02 e versos-03, nas respectivas
perspectivas Coisa de Pele/Beth Carvalho/Letra/versos-01, Coisa de Pele/Beth
Carvalho/Letra/versos-02 e Coisa de Pele/Beth Carvalho/Letra/versos-03. Por
outro lado, se o conversor recebesse a perspectiva /Coisa de Pele, todos os nós,
elos e perspectivas do exemplo seriam tratados pelo conversor.
No processo de conversão, cada nó NCM (simples ou composto) é
diretamente mapeado em um objeto de dados no modelo de execução19. Pelo fato
da perspectiva de um nó condicionar as relações de sincronização das quais ele
participa, a criação dos objetos de execução leva em consideração as perspectivas
dos nós. Para cada perspectiva diferente, o conversor NCM cria um objeto de
execução separado. Vale lembrar que o modelo de execução permite que
diferentes objetos de execução contenham um mesmo objeto de dados.
Além da perspectiva, uma outra entidade fundamental na criação e
diferenciação dos objetos de execução é o descritor NCM. O descritor NCM
reúne as características de apresentação de um nó e é idêntico, em seus atributos,
ao descritor definido no modelo de execução (Seção 2.3.1.2). Todavia, devido à
maneira flexível que o NCM especifica as associações entre nós e características
da apresentação, o processo de criação dos descritores no modelo de execução não
ocorre de maneira direta.
Na realidade, o termo objeto de dados faz parte da definição do NCM, correspondendo a uma
abstração do nó em uma aplicação cliente NCM (Soares, 1998a; Soares, 1998b; Soares, 2003).
Essa definição é útil no esquema de tratamento de versões do modelo. Sendo assim, a conversão é,
na verdade, de um objeto de dados NCM para um objeto de dados de execução.
19
108
Descritores NCM podem ser definidos como atributos do nó, na composição
que contém o nó ou nas extremidades dos elos (Soares et al., 2000; Soares et al.,
2003). Em todas essas opções, o NCM define, na realidade, uma lista de
descritores alternativos, que pode inclusive encontrar-se vazia. Os descritores de
execução são gerados pelo conversor NCM como uma união dessas
possibilidades, seguindo uma regra de cascateamento explicada a seguir.
Para cada nó (em uma dada perspectiva) que ancora na extremidade de um
elo NCM (por exemplo, o nó música-Beth, na perspectiva /Coisa de Pele/Beth
Carvaho/música-Beth, ancorando no elo lb1), o cascateamento dos descritores é
calculado através da união dos dados contidos no descritor do nó base da
perspectiva (música-Beth), no descritor da composição que diretamente contém o
nó base da perspectiva (Beth Carvalho) e no descritor da extremidade do elo (lb1).
Se, por acaso, dois descritores definirem um mesmo atributo com valores
diferentes, o conversor resolve o conflito considerando que o descritor do elo tem
prioridade sobre o descritor da composição que, por sua vez, tem precedência
sobre o descritor do nó. Os atributos do descritor resultante são então utilizados
para compor o descritor do objeto de execução. Quando em qualquer uma das
opções (elo, composição ou nó), não houver um descritor definido, a opção é
simplesmente ignorada no cascateamento. Por outro lado, se em qualquer uma
delas, houver uma lista de descritores com mais de uma opção, ao invés de criar
um único objeto de execução, o conversor utiliza cada alternativa de descritor para
gerar um descritor de execução distinto e, conseqüentemente, criar objetos de
execução diferentes. Nesse caso, o conversor cria também uma alternativa de
objetos de execução (Seção 2.3.3) reunindo as várias possibilidades de objetos de
execução geradas. As regras de exibição da alternativa de objetos são obtidas dos
atributos de teste definidos para cada descritor NCM (Muchaluat-Saade, 2003;
Soares et al., 2003). Se houver no cascateamento mais de uma lista com mais de
uma opção, o conversor gera objetos de execução para todas as combinações
possíveis. Evidentemente, esse comportamento pode levar a uma explosão no
número de objetos de execução. Uma solução seria resolver a escolha do descritor
estaticamente no próprio conversor. Contudo, isso dificultaria que uma mesma
conversão fosse reusada em plataformas distintas, por mais de uma vez e por mais
de um usuário. Como, na prática, apenas o nó possui descritor definido e, além
109
disso, dificilmente encontra-se uma lista com mais de dois descritores, a
implementação atual de conversor NCM não se preocupa com essa questão.
Um outro suporte a alternativas que o NCM oferece são as alternativas de nó
(nó de composição do tipo switch) (Muchaluat-Saade, 2003; Soares et al., 2003).
Esse nó especial de composição contém uma lista ordenada de nós, com atributos
de teste associados. A idéia é que os testes sejam analisados na ordem dos nós e o
primeiro nó que tiver o teste satisfeito seja selecionado, oferecendo semântica
idêntica à do elemento switch da linguagem SMIL (W3C, 2001a). Esses nós
alternativos NCM são mapeados diretamente e na mesma ordem em alternativas
de objetos de execução, com os atributos de teste sendo convertidos nas regras de
exibição a serem associadas aos objetos de execução. Quando um primeiro nó
NCM é encontrado em um nó switch sem um atributo de teste associado, esse nó é
traduzido no objeto de execução default. A partir desse ponto os nós NCM
restantes são ignorados pelo conversor. Se, por acaso, uma das alternativas de nó
NCM em um nó de composição switch tiver uma lista de descritores com mais de
uma alternativa, a conversão desse nó resultará em uma alternativa de objetos de
execução, que por sua vez será inserida na alternativa de objetos de execução
sendo construída para os nós. Nesse caso, o resultado no documento de execução
será um aninhamento de alternativas.
O ponto de partida do processo de tradução feito pelo conversor é a análise
dos elos NCM que ancoram no nó base da perspectiva que lhe foi passada como
parâmetro. No caso do nó base ser uma composição, a análise feita também se
estende aos elos NCM que ancoram nos nós recursivamente contidos na
composição (sempre considerando a perspectiva de cada nó). O resultado dessa
etapa é a criação dos elos de execução e dos objetos de execução (podendo esses
objetos serem alternativas de objetos de execução) que participam dos
relacionamentos, com as suas inserções no contêiner de resposta do conversor.
Evidentemente, essa análise também identifica os eventos envolvidos nas
sincronizações e os insere na lista de eventos de cada objeto de execução.
O elo NCM é definido como estando contido em um nó de composição e
sendo constituído por um conector e um conjunto de associações entre os nós e o
conector (Muchaluat-Saade & Soares, 2001; Muchaluat-Saade et al., 2002;
Muchaluat-Saade, 2003). O conector contém a expressão do relacionamento e as
110
associações representam as extremidades dos elos, identificando os seus
participantes. Essa separação permite que um mesmo conector seja reusado em
mais de um elo, favorecendo a autoria e manutenção das relações nos documentos
hipermídia (Muchaluat-Saade & Soares, 2001). O modelo NCM define dois tipos
de conector: conector causal e conector de restrição. Elos NCM que usam
conectores causais são convertidos em elos de execução causais (Seção 2.3.2.1),
enquanto os que usam conectores de restrição são transformados em elos de
execução de restrição (Seção 2.3.2.2). As informações contidas no conector são
utilizadas pelo conversor para construir o ponto de encontro do elo de execução. A
perspectiva do nó de composição que contém o elo juntamente com os dados das
associações são utilizados pelo conversor para criar os objetos de execução e
respectivos eventos que participam de um relacionamento.
Toda associação em um elo NCM contém a identificação de um nó NCM, a
definição de uma seqüência de nós de composição recursivamente contidos na
composição que contém o elo20 e a especificação de uma lista de descritores
alternativos. Dessas informações deriva ao menos um objeto de execução. O
objeto de dados de execução é obtido diretamente do nó NCM, o descritor de
execução é extraído da regra de cascateamento dos descritores NCM explicada
anteriormente e, por fim, o identificador único do objeto de execução (Seção
2.3.1) deriva de uma concatenação de identificadores. A concatenação é formada
pelos identificadores dos nós NCM que compõem a perspectiva do nó de
composição que contém o elo, seguidos dos identificadores dos nós que formam o
mapeamento, seguidos do identificador do nó NCM que participa do elo, seguido
dos identificadores dos descritores que compõem o descritor resultante (resultado
do cascateamento). Sendo assim, dois objetos de execução são considerados
diferentes pelo conversor, se tiverem alguma distinção na perspectiva ou no
cascateamento de descritores. Para todo objeto de execução criado pelo conversor,
ele cria também um evento de apresentação que é inserido na lista de eventos do
objeto. Esse evento representa a exibição do conteúdo do objeto como um todo.
20
O NCM permite que uma composição defina mapeamentos de suas âncoras (pontos de interface)
para âncoras de nós que estejam nela contidos. Se esses nós forem composições, o processo pode
se repetir em vários níveis de aninhamento. Isso obriga que elos apontem para nós contidos, ou
recursivamente contidos, em composições apenas através de pontos de interface bem definidos,
garantindo a propriedade de composicionalidade do modelo.
111
Retornando ao exemplo da Figura 28 para ilustrar as definições
apresentadas, o elo lb1 está contido no nó de composição Beth Carvalho, que
possui uma única perspectiva no documento dada por Coisa de Pele/Beth
Carvalho. O elo possui ainda duas associações, uma com o nó música-Beth e
outra com o nó versos-01, sendo que essa última associação passa por um
mapeamento definido entre o nó de composição Letra e o nó de conteúdo versos01. Assumindo que para esses nós de conteúdo existam apenas dois descritores
definidos no documento: desc-beth como atributo do nó música-Beth e descversos-01 como atributo do nó versos-01, os identificadores dos objetos de
execução relacionados pelo elo de execução, resultado da tradução do elo NCM
lb1, seriam: Coisa de Pele+Beth Carvalho+música-Beth+desc-Beth e Coisa de
Pele+Beth Carvalho+Letra+versos-01+desc-versos-01.
Além do nó, dos mapeamento para alcançar o nó e da lista de descritores,
toda associação no elo NCM possui também a especificação de um tipo de evento
(exibição, clique do mouse, atribuição etc.) e o identificador de uma âncora, ou de
um atributo, do nó NCM. O conversor utiliza essas informações para descobrir o
evento de execução (Seção 2.3.1.3) que deve participar do elo. Em seguida, caso o
evento ainda não exista, o conversor o insere na lista de eventos do objeto de
execução21.
Após a análise de todos os elos e criação dos objetos de execução e eventos,
o conversor percorre todas as perspectivas de nós que devam ser tratadas pelo
conversor, e cria os objetos de execução (ou alternativas de objetos de execução),
para cada nó base de perspectiva, aplicando a mesma regra de cascateamento
apresentada anteriormente, porém, desconsiderando a lista de descritores dos elos.
Essa etapa pode, ou não, resultar na inserção de mais alguns objetos de execução
no contêiner a ser respondido.
21
Os eventos NCM também são baseados em máquinas de estados e seus tipos e máquinas são
traduzidos diretamente nas classes de evento e máquinas de estados definidas no modelo de
execução. A única exceção são os eventos de preparação NCM, que no modelo de execução são
tratados como fazendo parte da máquina de estados do evento de apresentação.
112
5.1.1
Suporte à apresentação de documentos descritos em outros
modelos de autoria
O conversor NCM implementado junto ao formatador cria uma nova
possibilidade para o controle de apresentações hipermídia no sistema HyperProp.
Documentos definidos em outros modelos de autoria podem ser apresentados pelo
ambiente de execução do sistema HyperProp, se houver um mapeamento do
modelo em questão para o NCM. Seguindo essa lógica de integração, foram
desenvolvidos e implementados um conversor de documentos SMIL versão 1.0
(W3C, 1998) para documentos NCM (Rodrigues et al., 1999; Rodrigues, 2000;
Rodrigues et al., 2002) e um conversor da linguagem NCL para documentos NCM
(Antonacci et al., 2000; Rodrigues et al., 2002; Muchaluat-Saade, 2003).
A principal vantagem de efetuar a conversão entre os modelos no nível da
autoria é permitir que as funcionalidades de um modelo com maior poder de
expressão sejam acrescidas ainda na fase de edição dos documentos (Rodrigues et
al., 2002). Evidentemente, entidades que não possam ser mapeadas de um modelo
para o outro geram uma perda de características e recursos na conversão. Outra
vantagem da conversão nesse nível é explorar as ferramentas de edição
disponíveis para um determinado modelo, na autoria de documentos descritos em
modelos diferentes. Nesse caso, o ideal é que a conversão entre modelos possa ser
feita nos dois sentidos, novamente estando sujeita à perda de expressividade na
passagem de um modelo para o outro.
Existe, por outro lado, uma desvantagem em termos de eficiência quando a
conversão para apresentação é primeiro feita no nível de autoria, pois duas
conversões em seqüência precisam ser aplicadas para simplesmente exibir (sem
editar) um documento descrito em um modelo diferente do NCM. Por essa razão,
como trabalho futuro, pretende-se desenvolver um conversor que faça diretamente
a tradução de documentos escritos na versão 2.0 da linguagem SMIL (W3C,
2001a) para o modelo de execução definido nesta tese. Obviamente, a arquitetura
possibilita que outros conversores também sejam desenvolvidos, desde que exista
um mapeamento das características básicas para o modelo de execução.
113
5.2
Compilador e executor do orquestrador de apresentação do
formatador HyperProp
Os dois principais componentes do formatador no controle da apresentação
são o compilador de apresentação e o executor de apresentação, denominados
simplesmente de compilador e executor. Esses componentes implementam as
funções tanto do plano de serviços como do plano de meta-serviços descritas na
Seção 4.2 e ilustradas na Figura 23.
O compilador HyperProp é o ponto de entrada no processo de orquestração
das apresentações no sistema. O compilador dispõe de um método que espera
como parâmetros um contêiner de execução, a identificação de um objeto de
execução contido no contêiner e a identificação de um evento de apresentação
contido no objeto de execução. O contêiner informa para o compilador a descrição
do documento, enquanto o objeto de execução e o evento permitem que seja
conhecido o ponto de entrada a partir do qual o documento será iniciado.
Futuramente, pretende-se estender a interface para permitir que o usuário informe
o tempo máximo permitido para que a compilação seja feita e o instante
programado para que a execução do documento seja iniciada.
De posse das informações recebidas, o compilador constrói as cadeias
temporais do documento, que são implementadas como grafos temporais, onde os
nós representam transições nas máquinas de estados dos eventos e as arestas são
relações síncronas e previsíveis entre os nós. Cada aresta possui associada uma
informação de duração, que é modelada como uma função de custo do tipo piece
wise convexa e linear em todas as suas subdivisões (Seção 4.3.1).
O compilador HyperProp também analisa os elos causais e registra cada elo
como observador dos eventos que estejam associados a condições de transição em
seu ponto de encontro. Isso faz com que as transições nas máquinas de estados só
exijam a avaliação dos elos que realmente dependam daquele evento.
Outro tipo de associação de observação que o compilador estabelece é entre
a propriedade de transição e o seu evento. Isso permite que quando a transição
ocorra, a propriedade registre o instante da ocorrência para posterior avaliação por
parte dos elos. O controle de deslocamento utilizando os atributos minDelay e
maxDelay das expressões de propriedades (Seção 2.3.2.1) ainda é um ponto em
114
aberto na implementação do formatador, sendo os valores desses atributos
desconsiderados na implementação atual. A única exceção é para as expressões de
propriedades de transição. Nesse caso, o formatador sabe como manter a
semântica estabelecida pelo modelo de execução.
Na fase de construção do plano de execução, o compilador avalia todas as
alternativas de objetos de execução que podem ser resolvidas estaticamente e o faz
com o auxílio do proxy de informações contextuais. Na implementação corrente,
esse proxy é uma implementação simples de gerente de contexto que mantém
informações da plataforma, carregadas a partir de arquivos locais. Como trabalho
futuro, pretende-se integrar esse componente a um mecanismo real de gerência do
contexto de exibição e incluir a manutenção de informações a respeito do usuário.
Após a construção do plano de execução, o compilador inicia, se estiverem
presentes, as tarefas de ajuste dos tempos elásticos e compilação do plano de prébusca, que serão comentadas mais adiante. A funcionalidade de gerência da
orquestração intra-mídia é outro recurso que não está implementado e que deve
ser abordado futuramente.
Durante a apresentação do documento, o executor identifica e instancia as
ferramentas de exibição. Esse controle é feito com o auxílio do gerenciador de
ferramentas (Seção 3.2). O gerenciador obtém do proxy de informações
contextuais a relação das ferramentas disponíveis no sistema e os tipos MIME
(Freed & Borenstein, 1996) que as ferramentas sabem tratar. Quando um objeto de
execução precisa ser exibido, o gerenciador de ferramentas verifica primeiro se
existe uma ferramenta especificada no descritor. As ferramentas devem ser
identificadas pelo nome da classe Java que contém a implementação propriamente
dita. Se não houver uma ferramenta especificada no descritor, ou se a ferramenta
especificada não estiver disponível na plataforma, o gerenciador consulta o tipo
MIME do conteúdo em procura de uma ferramenta que saiba lidar com o formato
identificado. Se não for possível exibir o conteúdo, o gerenciador retorna o erro e,
na implementação atual, o executor simplesmente desabilita o objeto de execução
no documento. A maneira como está implementada a descoberta e instanciação
das ferramentas permite que sejam instaladas novas ferramentas na plataforma,
sem precisar que o gerente de ferramentas seja recompilado.
115
Para a disposição espacial das ferramentas, o executor utiliza um gerente de
layout, que converte as informações descritas nas janelas e regiões do layout do
documento (Seção 2.3.1.2) para janelas (classe javax.swing.JFrame) e painéis
(classe javax.swing.JPanel) oferecidos pela plataforma Java 2. O gerenciador
mantém também uma janela e uma região default que são utilizadas para exibir os
objetos que não apresentem a identificação correta da região em seus descritores.
O executor permanece como um observador dos elos causais, sendo
notificado toda vez que uma condição é satisfeita. O executor então coordena o
disparo das ações, cuidando de requisitar os serviços do gerenciador de
ferramentas, quando for necessário instanciar um novo exibidor. Se o executor
percebe que um objeto de execução parcialmente construído precisa ter o evento
de apresentação do seu conteúdo preparado, ou mesmo ter sua ocorrência iniciada,
o executor gera uma notificação ao formatador, que a repassa para objetos que
tenham se registrado como interessados nessa notificação. O formatador fica então
esperando que um novo contêiner lhe seja entregue contendo o objeto de execução
em questão completamente construído. A princípio, essa espera é independente do
transcorrer do restante da apresentação.
O executor possui implementado um elemento que monitora o início da
ocorrência dos eventos de apresentação e registra no plano de execução o instante
efetivo. O próximo passo do trabalho é desenvolver estratégias de ajuste que
corrijam o plano quando diferenças significativas entre os tempos programados e
os tempos efetivamente ocorridos forem percebidas. No entanto, é importante
destacar que, apesar de não dispor de adaptações e ajustes dos tempos na fase de
execução, o fato do plano de execução não ser um simples timeline, o fato do
disparo das ações ser baseado em um modelo de observação dos eventos e a
maneira como as ferramentas de exibição monitoram as máquinas de estados (o
monitoramento será explicado no final da próxima seção) já oferecem um suporte
a uma execução adaptativa das apresentações.
É também função do executor observar se as ações a serem disparadas
devem iniciar a execução de uma cadeia temporal parcial. Nesse caso, o executor
realiza a junção dessa cadeia auxiliar à cadeia principal do documento.
O formatador HyperProp oferece em sua interface botões que permitem
controlar a exibição como um todo. É permitido pausar, retomar e encerrar a
116
exibição a qualquer momento. O próximo passo é investigar a viabilidade de
dispor o formatador de meios para avançar ou adiantar o ponto da apresentação,
sem que isso comprometa em demasia a qualidade da apresentação.
5.3
Integração entre as ferramentas de exibição e o formatador
O sistema HyperProp possui implementadas ferramentas de exibição para
tratar o conteúdo dos principais tipos de mídia (texto, imagens, áudio e vídeo)
(Rodrigues, 2000; Rodrigues et al., 2001). A Figura 29 ilustra um resumo do
diagrama de classes para implementação das ferramentas de exibição. Todas as
ferramentas herdam, direta ou indiretamente, os atributos e métodos definidos na
classe PresentationTool, apresentada no Capítulo 3.
O sistema dispõe de uma ferramenta para exibição de texto HTML (classe
HtmlTextPresentationTool) que, para realizar a interpretação e formatação dos
conteúdos, utiliza as classes HTMLEditorKit e HTMLDocument, disponíveis nos
pacotes javax.swing.text.html e javax.swing.text.html.parser da plataforma padrão
Java 2 (J2SE). Além disso, a ferramenta implementa a interface HyperlinkListener
que lhe permite ser avisada sempre que ocorre algum evento de interação sobre
uma âncora HTML (elemento <a> da linguagem HTML) (W3C, 1999c).
<<Int erface>>
Controller
addControllerListener()
<<Interface>>
observation
realiz e()
ControllerList ener
prefetc h()
0..*
0..*
stop()
controllerUpdate()
setM ediaTime()
setStopTime()
deallocat e()
close()
PresentationTool
ExecutionObject
1..*
1
ImagePresentationTool
JmfPresentationTool
<<Int erface>>
Player
1
HtmlTextPresentationTool
1
1
1
1
FixedEventMonitor
start()
eventTable
Event
1
MediaPlayer
JmfAudioPresentat ionTool
JmfVideoPresentationTool
AdjustableEventMonitor
granularity
Figura 29 – Diagrama de classes das ferramentas de exibição.
event Table
117
Na etapa de preparação do objeto de execução, a ferramenta utiliza os
atributos posição e string das âncoras textuais contidas nos eventos relacionados a
ações do usuário (eventos das classes MouseClickEvent, MouseOverEvent e
FocusEvent – Seção 2.3.1.3), para identificar no conteúdo as regiões do texto que
devem estar sensíveis às respectivas interações. A ferramenta então insere,
dinamicamente, no conteúdo, as marcações HTML que oferecem os pontos de
interação. Essas marcações são incluídas no texto da seguinte forma: <a href =
”hprop://eventId”>âncora textual</a>. Toda vez que ocorre uma ação sobre
âncora, a ferramenta é sinalizada por uma chamada à sua implementação do
método hyperlinkUpdate, definido na interface HyperlinkListener. A ferramenta
então identifica o evento que foi selecionado (eventId) e gera em sua máquina de
estados a transição correspondente. A partir daí, o mecanismo de observação dos
elos faz com que o executor seja notificado da transição e, caso um ou mais elos
causais tenham suas condições satisfeitas, as ações dependentes dessa interação
sejam disparadas.
Essa abordagem permite reusar conteúdo HTML e inserir elos de outros
modelos, sem que seja necessário editar o conteúdo do objeto (Rodrigues &
Soares, 1998). A forma como os elos são colocados no nó também permite que
uma mesma página, dependendo da perspectiva (ou seja, do objeto de execução),
apresente diferentes regiões selecionadas ou mesmo diferentes ações para a
mesma região. A Figura 30 ilustra a interface da ferramenta de exibição para a
mídia texto, onde a palavra cantor(a) é uma âncora HTML inserida
dinamicamente pela ferramenta.
Textos podem ser exibidos com duração pré-definida, bastando para isso
que o evento de apresentação do conteúdo como um todo tenha uma duração
estipulada. Nesses casos, a ferramenta utiliza um monitor que controla os tempos
dos eventos de apresentação e gera as transições quando transcorre a duração
estipulada. Monitores de eventos serão discutidos em mais detalhes na descrição
das ferramentas para exibição de mídias contínuas.
Para imagens estáticas, o sistema possui uma ferramenta (classe
ImagePresentationTool), que utiliza o suporte da classe Image, presente no pacote
java.awt, para controlar a exibição das figuras. A ferramenta permite que sejam
definidas âncoras espaciais e temporais (Seção 2.3.1.1) e monitora a máquina de
118
estados para os eventos correspondentes. Da mesma forma que a ferramenta de
texto, imagens também podem ser apresentadas com durações pré-definidas,
sendo, para isso, utilizado o mesmo tipo de monitor citado anteriormente.
Trecho do código HTML
correspondente. Em
itálico e negrito está o
código inserido
dinamicamente pela
ferramenta
...
<p align=“right”>
<a href=“hprop://1>cantor(a)</a>
...
Figura 30 – Ferramenta de exibição de texto no formato HTML.
Para mídias contínuas, as ferramentas do sistema foram implementadas
utilizando exibidores JMF (Java Media Framework), disponíveis no framework
oferecido pela Sun Microsystems (Sun, 1999). O JMF é um pacote de classes e
interfaces que oferece suporte à apresentação dos principais formatos de conteúdo
dinâmico (PCM, MPEG-1, MP3 etc.).
Foi criada no sistema uma classe, chamada JmfPresentationTool, que reúne
as características comuns às ferramentas baseadas nos exibidores JMF. Essa classe
herda
da
classe
PresentationTool
e
dela
herdam
duas
subclasses:
JmfAudioPresentationTool (para exibição de áudio) e JmfVideoPresentationTool
(para exibição de vídeo). Como essas ferramentas utilizam os próprios exibidores
JMF (os players JMF), as respectivas classes atuam, na verdade, como
adaptadores para a API oferecida pelo framework da Sun, realizando o
mapeamento entre a interface definida na Seção 3.3.1 e a API oferecida pelo JMF.
A Figura 31 ilustra a ferramenta de exibição JMF exibindo um vídeo no formato
MPEG-1.
119
Figura 31 – Ferramenta de exibição integrada a exibidores JMF.
No diagrama da Figura 29, as classes e interfaces com fundo cinza fazem
parte do pacote da Sun. A interface Player é implementada pelos exibidores JMF
(classes que herdam de MediaPlayer). A função de um Player é processar um
fluxo de dados de uma mídia contínua e apresentá-lo nos dispositivos de saída,
eventualmente oferecendo alguns componentes gráficos para permitir que o
usuário interaja com a apresentação. Todo Player estende a interface Controller.
Um Controller define uma máquina de estados, ilustrada na Figura 32, que
descreve o funcionamento do exibidor JMF e, por conseqüência, o evento de
apresentação do conteúdo do objeto de execução sendo exibido. Transições na
máquina de estados são notificadas para aqueles que tenham se registrado como
observadores
do
exibidor
JMF,
através
da
chamada
ao
método
addControllerListener. Todo observador deve ser instância de uma classe que
implemente a interface ControllerListener, pois as notificações ocorrem através de
chamadas
ao
método
controllerUpdate.
Dessa
forma,
a
classe
JmfPresentationTool implementa a interface ControllerListener, já que, como um
adaptador, ela necessita monitorar o estado do exibidor JMF.
realize
Unrealized
deallocate
120
RealizeCompleteEvent
Realizing
prefetch
Realized
PrefetchCompleteEvent
Prefetching
deallocate
setMediaTime
start
Prefetched
Started
stop
StopEvent
Figura 32 – Máquina de estados de um exibidor JMF
Quando um exibidor JMF é criado, ele se encontra no estado unrealized. A
chamada ao método realize, faz com que o exibidor passe para o estado realizing,
iniciando o processo de verificação e alocação de alguns dos recursos necessários.
Ao final desse processo, seu estado torna-se realized, onde já possui informação
sobre o tipo de mídia que irá apresentar. O método prefetch leva o exibidor para o
estado prefetching, onde é iniciado o processo de carregamento do conteúdo a ser
apresentado. Ao passar para o estado prefetched, o exibidor está pronto para
iniciar a apresentação da mídia. No momento em que o método start é invocado, o
exibidor passa para o estado started, quando efetivamente começa a apresentação.
Um exibidor JMF no estado started retorna ao estado prefetched quando o método
stop é chamado, quando atinge o fim da apresentação ou quando a transmissão dos
dados é interrompida. Além de notificar as transições em seus estados, um
exibidor também notifica seus observadores quando é destruído e quando ocorrem
alterações nos valores de seus atributos, tais como duração e taxa de exibição.
Além dos métodos que geram transições na máquina de estados (realize,
prefetch, start e stop), o exibidor JMF oferece outros dois importantes métodos
em sua interface: setMediaTime, que permite alterar a posição corrente no fluxo da
mídia, e setStopTime, que possibilita estabelecer a posição no fluxo da mídia onde
a apresentação será interrompida22.
Como pode ser percebido, é grande a semelhança entre a máquina de estados
dos eventos de apresentação (Figura 8) e a máquina de estados de um exibidor
JMF. Conseqüentemente, são também similares os métodos oferecidos pela classe
PresentationTool (Tabela 4) e pela interface Controller. A Tabela 5 resume a
22 Os métodos setMediaTime, setStopTime e stop são, na realidade, definidos na interface Clock,
da qual deriva a interface Controller. Porém, essa e algumas outras interfaces e classes do JMF
foram omitidas para que os diagramas não ficassem sobrecarregados.
121
maneira como é feita a conversão entre as duas interfaces, destacando apenas os
métodos definidos na Seção 3.3.1 relevantes para o mapeamento.
Métodos de PresentationTool
Métodos correspondentes para o exibidor JMF
initialize(exObj)
realize()
prepare(exObj, evt)
setMediaTime(Ti) + setStopTime(Tf) + prefetch()
start(exObj, evt)
start()
stop(exObj, evt)
stop() + setMediaTime(Ti)
pause(exObj, evt)
stop()
resume(exObj, evt)
start()
abort(exObj, evt)
stop() + setMediaTime(Ti)
Unprepare(exObj, evt)
deallocate() + close()
Ti = instante de início da apresentação de E, Tf = instante de término da apresentação de E
Tabela 5 – Mapeamento entre ações solicitadas pelo formatador e os métodos invocados
no exibidor JMF.
A iniciação da ferramenta JMF reflete na preparação do exibidor JMF,
representada pela chamada ao seu método realize. A ação prepare resulta na
chamada a três métodos do exibidor. O método setMediaTime estabelece a
posição no fluxo de mídia onde a apresentação será iniciada, enquanto o método
setStopTime especifica a posição de término da apresentação. Chamadas a esses
dois métodos são realizadas com base nos instantes de início e término do evento
passado como parâmetro na preparação (ou mesmo pedido de disparo da
exibição). Se o evento for o objeto inteiro e a duração não estiver explicitada, os
métodos setMediaTime e setStopTime não precisam ser chamados, fazendo com
que a apresentação seja conduzida do princípio do conteúdo até o seu término
natural, ou até que seja interrompida pelo usuário. Após a definição das posições
de início e fim da apresentação, o método prefetch é acionado para disparar a
busca do conteúdo. A ação start causa uma chamada ao método start do exibidor
JMF, enquanto a ação stop gera uma chamada ao método stop do exibidor,
seguida de uma chamada ao método setMediaTime, para recolocar a exibição em
seu ponto inicial, pois o método stop do JMF possui a semântica de simples pausa.
Por esse motivo, a ação pause gera apenas uma chamada ao método stop do
exibidor. Por sua vez, a ação resume reinicia a exibição a partir do ponto onde ela
foi interrompida, através de uma nova chamada ao método start do exibidor JMF.
A ação abort finaliza a apresentação, de modo semelhante à ação stop, porém
fazendo com que os eventos que estejam no estado ocorrendo ou suspenso passem
122
instantaneamente pelo estado abortado antes de retornar ao estado preparado. Por
fim, a ação unprepare libera os recursos ocupados pelo exibidor, sendo ignorada
se algum evento estiver ocorrendo ou suspenso. Para os métodos unprepare, stop,
pause, resume e abort o evento passado como parâmetro pode ser nulo, pois o
mesmo não é considerado. Essas ações são sempre aplicadas em todos os eventos
passíveis de terem em suas máquinas de estados as respectivas transições
realizadas.
Outra função importante da ferramenta/adaptador JMF é interceptar as
notificações geradas pelo exibidor JMF e efetuar a tradução para o modelo de
máquinas de estados de eventos utilizado pelo formatador. Os principais tipos de
notificação gerados pelos exibidores JMF são: final do carregamento do conteúdo
necessário para iniciar a exibição (PrefetchCompleteEvent); início da exibição
(StartEvent); suspensão da exibição por chamada explícita ao exibidor
(StopByRequestEvent); final da exibição por alcance do tempo de término
previamente estabelecido (StopAtTimeEvent); final da exibição por término
natural (EndOfMediaEvent); e destruição do exibidor (ControllerClosedEvent). A
Tabela 6 apresenta o mapeamento dos diferentes tipos de sinalizações dos
exibidores JMF para as transições correspondentes na máquina de estados dos
eventos de apresentação.
Sinalizações do exibidor JMF
Transições no estado do evento de apresentação
PrefetchCompleteEvent
preparando preparado
StartEvent
preparado | suspenso ocorrendo
StopByRequestEvent
em resposta ao método stop
ocorrendo | suspenso preparado
em resposta ao método pause
ocorrendo suspenso
em resposta ao método abort
ocorrendo | suspenso abortado preparado
StopAtTimeEvent
ocorrendo preparado
EndOfMediaEvent
ocorrendo preparado
ControllerClosedEvent
ocorrendo | suspenso abortado preparado
Tabela 6 – Mapeamento entre notificações do exibidor JMF e transições de estado do
evento de apresentação
Nesse ponto cabe destacar uma importante distinção entre a API JMF e a
interface para integração com formatadores proposta neste trabalho. Enquanto as
ferramentas de exibição devem controlar uma máquina de estados para cada
123
evento/âncora do objeto sendo exibido, de uma forma mais limitada, os exibidores
JMF trabalham com apenas uma máquina de estados, correspondendo, na maioria
das vezes, ao objeto como um todo. As ferramentas JMF implementadas no
formatador HyperProp utilizam monitores temporais, descritos a seguir, para
alcançar esse controle mais granular das exibições dos objetos.
5.3.1
Monitorando os tempos dos eventos de apresentação
Enquanto um evento de apresentação, definido por um intervalo temporal I
(evento externo), permanece no estado ocorrendo, outros eventos de apresentação
do mesmo objeto, definidos em subintervalos de I (eventos internos), podem
ocorrer também. Uma funcionalidade que deve estar presente nas ferramentas de
exibição, principalmente as de mídia contínua, é a capacidade de sinalizar o início
e o fim da exibição de todos os eventos de apresentação que venham a ocorrer na
exibição de um objeto. Isso permite definir relações de sincronização entre subregiões temporais dos objetos, conforme ilustrado no Exemplo 1 da Seção 2.3.2.1.
No exemplo, a apresentação do vídeo V1 corresponde ao evento externo, enquanto
ev1 corresponde a um evento interno. Entretanto, esse controle granular, que é
oferecido de uma forma simples pela interface proposta nesta tese, não é trivial de
ser obtido através da API dos exibidores JMF. Sendo assim, efetuar essa
adaptação
constitui-se
em
uma
tarefa
importante
para
a
classe
JmfPresentationTool e uma das principais contribuições dessa implementação. De
fato, é essa adaptação que permite transformar a máquina de estados única do JMF
nas várias máquinas de estados dos eventos de um objeto de execução.
Quando iniciada, a ferramenta percorre a lista de eventos do objeto de
execução e identifica as âncoras dos eventos de apresentação que precisam ter
suas ocorrências controladas. A maneira como são especificados os tempos que
delimitam o intervalo da âncora de um evento de apresentação pode variar e é
importante que seja tratada pela ferramenta. Os delimitadores da região podem
definir explicitamente unidades de tempo medidas em relação ao início da
apresentação do objeto como um todo, sem levar em consideração variações na
taxa de exibição da mídia (eventos fixos – âncoras da classe TimeIntervalAnchor,
definida na Seção 2.3.1.1). Nesse caso, a ferramenta precisa guiar-se apenas pelo
124
relógio do sistema (relógio da máquina em que estiver executando). De uma outra
forma, as extremidades da região temporal podem estar associadas a unidades de
informação específicas do conteúdo, como por exemplo quadros de um vídeo ou
amostras
de
um
áudio
(eventos
ajustáveis
–
âncoras
da
classe
SampleIntervalAnchor, definida na Seção 2.3.1.1). Nesse modo de definição, a
ferramenta deve ter um controle exato sobre a taxa de apresentação da mídia, pois
variações devem refletir em atualizações nos instantes de delimitação do intervalo
temporal que o evento especifica.
Para auxiliar no controle dos eventos de apresentação, a ferramenta
JmfPresentationTool possui dois monitores (Figura 29). O monitor não ajustável
(FixedEventMonitor) auxilia no controle dos eventos fixos do objeto, enquanto o
monitor ajustável (AdjustableEventMonitor) controla os eventos ajustáveis.
Ambos os monitores constróem tabelas com registros que contêm as seguintes
informações: a identificação do evento, o tipo da transição (início ou fim da
apresentação da região em questão), o instante de tempo esperado para que a
transição aconteça e se a transição está ou não habilitada. As tabelas de eventos
têm seus registros ordenados de forma crescente pelos instantes de tempo
esperados para as transições.
A habilitação de uma transição depende do ponto em que o conteúdo do
objeto começa a ser exibido, pois dependendo do evento de apresentação inicial,
algumas máquinas de estados não devem ser consideradas pela ferramenta de
exibição. A Tabela 7 resume as regras adotadas pelos monitores das ferramentas
JMF para decidir quais transições devem ou não estar habilitadas na tabela de
eventos. Essas regras são baseadas nas relações entre o intervalo do evento
solicitado para ser apresentado (evento α) e o intervalo de qualquer outro evento
de apresentação do objeto (evento β). Na tabela, é considerado que os eventos α e
β possuem intervalos de duração [Tαi, Tαf] e [Tβi, Tβf], respectivamente.
Os monitores de eventos são implementados como threads, disparadas pela
própria ferramenta. O monitor não ajustável possui um funcionamento bastante
simples. Quando iniciado, ele procura o primeiro registro na tabela que esteja
habilitado e consulta o tempo esperado para a transição. Em seguida, ele se coloca
para dormir até que esse instante seja alcançado. Quando acorda, o monitor
simplesmente coloca o evento no estado adequado (ocorrendo se for uma
125
transição de início e preparado se for uma transição de fim), procura na tabela o
próximo registro habilitado e volta a dormir até que o novo instante de tempo
previsto seja atingido.
Relação
Temporal
Ilustração da Relação
Tαi > Tβi
α
OU
β
β
α permanecerão habilitadas. As
α
β
α
β
As transições de início e de fim de
α
α
α
Tαf ≤ Tβi
β
Regra
β
transições
α
do
evento
β
serão
desabilitadas, pois a máquina de
β
estados
de
β
deverá
ser
desconsiderada.
Tαi ≤ Tβi < Tαf
Todas as transições permanecerão
α
E
α
β
habilitadas. No entanto, o fim da
β
ocorrência de α irá causar o corte
Tαf < Tβf
na apresentação de β. Dessa forma,
o evento β retornará para o estado
preparado prematuramente.
Tαi ≤ Tβi
E
Tαf ≥ Tβf
β
α
β
α
β
α
α
Todas as transições permanecerão
β
habilitadas e serão notificadas se
não houver uma intervenção externa
do usuário.
Tabela 7 – Regras para habilitação dos eventos de apresentação.
O monitor ajustável possui um funcionamento mais elaborado. Essa maior
complexidade vem do fato da taxa de exibição do objeto de mídia poder variar por
fatores imprevisíveis, tais como atrasos nos sistemas de comunicação e
operacional ou interações diretas do usuário com os botões de controle da
ferramenta (barra de controle inferior na Figura 31). Isso torna impossível para o
monitor estimar, de maneira precisa, o tempo que deve dormir até uma próxima
transição. Além disso, a API JMF não oferece uma forma para que os
observadores de seus exibidores se registrem para serem notificados quando
pontos internos da exibição do objeto forem atingidos. Por essas razões, o monitor
ajustável realiza sucessivas verificações junto ao exibidor JMF para saber o
instante de exibição corrente do conteúdo. O intervalo entre verificações é dado
pela variável granularity do monitor, que pode ser configurada. Evidentemente, se
126
a freqüência de verificação for alta, ocorrerá uma sobrecarga na utilização da
CPU. Por outro lado, se a freqüência for baixa, poderá haver uma imprecisão nos
instantes de notificação. Quando a ferramenta tem a taxa de apresentação da mídia
alterada, tanto pela ação do usuário como do formatador, a granularidade
configurada no monitor é também modificada proporcionalmente.
Após cada verificação, o monitor ajustável procura por transições
habilitadas cujo tempo esperado tenha sido alcançado, ou mesmo ultrapassado, e
que ainda não tenham sido sinalizadas para o formatador. Se houver alguma, o
monitor efetua a transição correspondente na máquina de estados do evento, da
mesma forma que o monitor não ajustável.
Os monitores também observam alguns aspectos imprevisíveis da
apresentação para corrigir suas posições correntes nas tabelas, recalcular os
tempos em que devem dormir e acertar os estados dos eventos que estão sendo
monitorados. Um caso que exige correção é quando o usuário modifica o ponto de
apresentação da mídia.
Os monitores oferecem métodos que permitem que eles sejam pausados,
retomados no controle ou tenham sua execução encerrada. Esse controle é feito
pela ferramenta JMF, respondendo a chamadas aos seus métodos pause, resume,
abort e stop.
Por uma questão de simplificação, quando a apresentação de um evento
acaba de ser preparada pela ação prepara, todos os eventos de apresentação cujas
transições permaneceram habilitadas são também colocados no estado preparado.
Isso permite que, à medida que as suas regiões sejam apresentadas, os eventos
associados passem diretamente do estado preparado para o estado ocorrendo.
Por fim, cabe mencionar que as ferramentas de exibição desenvolvidas
também são capazes de tratar os eventos de seleção em regiões espaciais dos
objetos, assim como a especificação de eventos que combinam apresentação e
seleção. Maiores detalhes podem ser obtidos na referência (Rodrigues, 2000).
127
5.4
Mecanismo de pré-busca
Uma instanciação simplificada do framework apresentado na Seção 4.1.1 foi
realizada com o intuito de incorporar mecanismos de pré-busca ao formatador do
sistema HyperProp (Rodrigues & Soares, 2002).
O trabalho de instanciação do framework resultou nas implementações de
estratégias de compilação e de escalonamento para o plano de pré-busca e de um
módulo que estima os parâmetros para o cálculo dos tempos de busca
simplificado. O formatador HyperProp dispõe de duas estratégias de compilação
da pré-busca: uma que não leva em consideração o paralelismo das buscas e outra
que coloca as buscas em série e impõe um retardo inicial para o início da
apresentação do documento, para compensar as latências de exibição excedentes
já antevistas pelo compilador de pré-busca. A heurística para o cálculo das
durações de busca leva em conta, não apenas os tempos gastos na transmissão e
carregamento em memória dos conteúdos, mas também o custo de criação e
preparação das próprias ferramentas (principalmente os players JMF). Na
implementação atual, o plano de pré-busca leva em consideração apenas a cadeia
temporal principal, não prevendo a busca para os objetos inseridos nas cadeias
auxiliares.
A execução da pré-busca é feita com um escalonador que opera sinalizando
para o executor HyperProp os momentos para requisitar a instanciação (se for o
caso) de uma ferramenta e a preparação do evento de apresentação correspondente
ao conteúdo do objeto que deve ser buscado.
Os próximos passos do trabalho envolvem a integração do módulo que
estima os parâmetros de busca com um suporte real de gerência de contexto, a
implementação dos mecanismos de ajuste do plano de pré-busca em tempo de
execução, a integração com mecanismos de reserva e, futuramente, a investigação
do uso de mecanismos de reserva antecipada. Esses dois últimos pontos envolvem
também a implementação do módulo de gerência de orquestração intra-mídia no
formatador.
Ainda como trabalhos futuros, pretende-se incluir no formatador HyperProp
estratégias que construam o plano de pré-busca levando em consideração a
128
probabilidade de navegação do usuário e que desempenhem uma gerência da
ocupação dos buffers.
5.5
Ajuste dos tempos elásticos e escolha das alternativas
O principal recurso de adaptação disponível na implementação atual do
formatador HyperProp é o ajuste das durações flexíveis, feito em tempo de
compilação. Para desempenhar essa tarefa, o compilador de adaptação possui uma
estratégia de ajuste que utiliza um programa externo, integrado ao formatador em
um projeto de cooperação que vem sendo desenvolvido com o grupo francês de
pesquisa em otimização da Universidade Blaise Pascal (Bachelet et al., 2000).
O compilador HyperProp constrói as cadeias temporais e as entrega, uma a
uma, para o módulo adaptador, que repassa o pedido de adaptação para a
estratégia de ajuste de tempo de compilação (Seção 4.3.2). A estratégia de ajuste
então utiliza as relações impostas pelo autor e as funções de custo definidas para
as durações dos eventos para obter as durações esperadas. O cálculo é feito de tal
maneira que o custo total para deslocar as durações dos seus valores ideais seja
minimizado.
A implementação da estratégia de adaptação é, na verdade, dividida em duas
partes:
um
programa
executável
(ferramenta
solve_tension.exe)23,
que
efetivamente calcula a solução ótima para as durações, e uma classe Java, que faz
a ponte entre a ferramenta externa e o formatador HyperProp. A troca dos dados
entre esses dois componentes é feita através de dois arquivos, um que contém a
descrição do grafo esperado pela ferramenta e outro que possui os resultados da
otimização. As informações obtidas são então utilizadas pela classe Java para
iniciar o valor esperado das durações dos eventos não instantâneos e até mesmo
dos tempos de espera para execução das ações dos elos causais (Seção 2.3.2.1).
A ferramenta de otimização utilizada pelo formatador HyperProp resolve o
problema de minimização do custo total de reduzir ou aumentar a duração dos
objetos como um problema de custo mínimo em um grafo de tensões (Bachelet et
al., 2000). A ferramenta espera as informações de duração nas arestas do grafo,
23
http://www.nawouak.net/?doc=bpp_library+ch=bpp_tools
129
que devem ser descritas como funções de custo lineares, piece-wise e do tipo
convexa. O grafo construído pela classe Java que realiza a comunicação com a
ferramenta é uma simplificação de cada uma das cadeias temporais. Cada nó do
grafo representa a transição na máquina de estados de um evento não interativo
(normalmente, eventos de apresentação, mas outros eventos como os de atribuição
também podem estar presentes). Para cada objeto de execução que deve ser
exibido, apenas o evento de apresentação mais externo (Seção 5.3.1) é inserido no
grafo, sendo colocada uma aresta entre as transições de início e fim da ocorrência,
contendo a função de custo que descreve a duração do evento. Arestas entre
transições relacionadas como condições e ações de elos causais, ou entre
transições que façam parte de uma mesma restrição temporal, também são
acrescentadas ao grafo.
A estratégia de ajuste dos tempos elásticos também pode receber,
opcionalmente, uma função de custo para a duração da cadeia como um todo.
Quando presente, essa informação resulta na inserção de uma aresta paralela ao
grafo inteiro.
A utilização do algoritmo de ajuste como uma ferramenta externa e
dependente de plataforma limita a portabilidade do formatador. Além disso, a
necessidade de iniciar um processo externo e trocar os dados através de arquivos
impõe retardos que provavelmente inviabilizarão o uso do algoritmo para ajustar
as durações em tempo de execução. Por outro lado, ter a ferramenta em código
executável diminui o tempo de resposta do cálculo. Como nesse primeiro estágio,
o foco do trabalho era a integração das pesquisas e a colocação do formatador
como uma aplicação usuária das propostas de otimização desenvolvidas no projeto
de cooperação, os objetivos iniciais foram alcançados. A perda da portabilidade é
minimizada com a disponibilidade do código da ferramenta e das bibliotecas
utilizadas, que podem ser compiladas para outras plataformas alvo.
Como próximo passo na integração das implementações, está a eliminação
dos arquivos como meio para troca dos dados entre os dois sistemas e a inclusão
de uma API implementada em Java pela ferramenta de otimização para receber os
dados e devolver o resultado do ajuste. Outra modificação para favorecer o ajuste
em tempo de execução é procurar manter a ferramenta de otimização em memória,
sem que um novo processo tenha que ser iniciado a cada vez. Finalmente, cabe
130
uma tentativa de implementar uma versão da ferramenta em Java e estabelecer
uma comparação da eficiência com a abordagem utilizando código nativo.
Além do ajuste dos tempos elásticos, o módulo de adaptação oferece um
método para realizar a seleção de uma alternativa de objeto de execução. As regras
de exibição são avaliadas com base nos valores de parâmetros retornados pelo
proxy de informações contextuais. Na versão atual, os parâmetros são mantidos de
maneira estática, mas com a integração ao mecanismo de gerência de contexto,
espera-se que seja possível realizar adaptações dinâmicas, sem que isso implique
em modificações na estrutura e implementação do formatador.
Trabalhos Relacionados
131
6
Este capítulo busca oferecer uma visão das pesquisas relacionadas ao tema
desta tese e compará-las com as proposições que foram colocadas ao longo deste
trabalho. Com o objetivo de organizar as comparações, o capítulo as divide em
quatro seções. A primeira seção comenta os trabalhos que tratam da questão da
estruturação dos formatadores e orquestração das apresentações de uma maneira
geral. As outras três seções tratam das características mais específicas do projeto
de ambientes de execução: a segunda seção comenta os esforços para a integração
de ferramentas de exibição em ambientes de apresentação hipermídia; a terceira
seção apresenta uma comparação com os trabalhos que focam nos mecanismos de
pré-busca para exibição de hiperdocumentos; e, por fim, a quarta e última seção
do capítulo comenta a respeito dos trabalhos que oferecem suporte à adaptação
das apresentações, com interesse maior no ajuste dos tempos elásticos.
6.1
Formatadores multimídia/hipermídia
Para praticamente todos os modelos, linguagens e sistemas citados no
princípio do Capítulo 2 (Seção 2.1.1.1), existe pelo menos um protótipo de
formatador implementado. No entanto, como são diversas propostas na literatura,
esta seção restringiu os comentários e comparações apenas às propostas cujas
idéias contribuíram diretamente para a constituição da arquitetura definida nesta
tese.
O sistema Firefly (Buchanan & Zellweger, 1992; Buchanan & Zellweger,
1993a; Buchanan & Zellweger, 1993b) foi desenvolvido com o objetivo de
fornecer facilidades para criação, edição, manutenção e apresentação de
documentos multimídia/hipermídia. Pioneiro na definição do termo formatador
como denominação ao controlador das apresentações, o sistema trouxe várias
contribuições para esta tese.
132
O sistema é baseado em um modelo constituído por objetos de execução
(media items), compostos por um conteúdo, um conjunto de procedimentos e uma
lista de eventos. Os eventos podem ser síncronos ou assíncronos e são sempre
instantâneos, correspondendo, na maioria das vezes, às transições do modelo de
execução definido no Capítulo 2. Para cada par de eventos adjacentes, o sistema
permite definir durações como funções de custo lineares do tipo piece-wise, com
apenas dois segmentos, similar à função ilustrada na Figura 26c. Os
relacionamentos no modelo são definidos como restrições temporais entre
eventos, podendo ser especificados como equações ou inequações. Além disso,
cada evento pode ter a ele associada uma lista de operações que permitem
controlar os aspectos de apresentação do objeto de execução.
A arquitetura do formatador Firefly separa o controle da apresentação em
duas fases, uma de compilação e outra de execução e estabelece a noção de
cadeias temporais, sendo uma principal (main schedule) e as outras auxiliares
(auxiliary schedules). Cada cadeia relaciona todos os eventos síncronos
associados por alguma restrição temporal, ou pertencentes a um mesmo objeto de
execução que tenha tido algum evento inserido na cadeia. Conforme já
comentado, essa proposta exerceu influência sobre a definição da arquitetura de
formatação e dos planos de execução descritos neste trabalho.
O compilador, com base nas restrições temporais e nas funções de custo das
durações, calcula os tempos esperados para ocorrência de cada evento. Isso é feito
para cada cadeia de maneira independente.
Uma vez iniciada a apresentação, o módulo de execução inicia um
escalonador e um tratador de eventos. O escalonador monitora a cadeia principal
e, com base em um relógio de execução, envia comandos para as ferramentas de
exibição (media managers), quando os tempos programados pelo compilador são
alcançados. O tratador de eventos observa as sinalizações dos eventos informados
pelas ferramentas e, quando percebe que uma cadeia auxiliar deve ser iniciada,
requisita ao escalonador a sua junção com a cadeia principal. O escalonador
também realiza, baseado nas listas de operações, um controle de ativação e
desativação dos eventos, mantendo o tratador informado para que não seja
solicitada uma junção a partir de eventos que não estejam ativos no momento.
133
Como pode ser percebido, uma vez iniciada a apresentação do documento, o
plano de execução torna-se um timeline das ações a serem desempenhadas. A
arquitetura simples do formatador não dispõe de componentes para ajustar a
exibição em função de variações na banda passante, por exemplo. O modelo de
documentos também não prevê adaptações diferentes do ajuste elástico dos
tempos, tais como seleção de alternativas. Módulos para pré-busca dos conteúdos
também não são considerados como fazendo parte do formatador.
Madeus (Jourdan et al., 1998a; Jourdan et al., 1998b; Sabry-Ismail et al.,
1999) é um sistema para autoria e apresentação de documentos multimídia com
interatividade, baseado em um modelo de restrições temporais e espaciais entre os
objetos de execução (media objects).
As restrições espaciais utilizam os operadores alinhar, centralizar e
deslocar tanto em relação ao eixo horizontal como o eixo vertical, enquanto as
restrições temporais baseiam-se nas relações de Allen (Allen, 1983). O modelo
permite que os objetos sejam sincronizados simultaneamente no tempo e no
espaço. O modelo também oferece hiper-elos para a especificação de
relacionamentos de navegação tradicionais entre os objetos.
Todo objeto tem a ele associada uma duração flexível, que informa limites
inferior e superior para a sua apresentação. O ambiente de execução do sistema
Madeus possui um formatador (Sabry-Ismail et al., 1999) que calcula, em uma
fase de compilação, o valor esperado para a duração de cada objeto, denominada
duração nominal. O modelo define como objetos incontroláveis aqueles que não
podem ter a sua duração esperada conhecida até que sua exibição termine. De
maneira oposta, os objetos que possuem uma duração nominal calculada pelo
compilador são classificados como controláveis.
A compilação e o controle da execução do documento são feitos a partir da
construção de um grafo temporal, denominado HTSP (Hypergraph of Simple
Temporal Problems), que funciona como o plano de execução do formatador
Madeus (Jourdan et al., 1998a).
Na fase de execução, o formatador observa os tempos efetivos das durações
e os compara com as durações programadas. Quando alguma variação que cause
uma perda de sincronização na apresentação é identificada, o formatador aplica
um algoritmo de ajuste. O executor Madeus também observa os instantes em que
134
os objetos incontroláveis terminam de ser exibidos para verificar se isso resulta na
necessidade de algum ajuste das durações.
O formatador Madeus não aborda as questões relacionadas à orquestração da
pré-busca. O mecanismo de adaptação do formatador permite recuperar o
sincronismo da apresentação sempre que percebe alguma divergência com o plano
programado, no entanto, esse ajuste é feito buscando restabelecer o sincronismo o
mais rapidamente possível, sem que seja utilizada qualquer medida de qualidade.
Outras técnicas de adaptação orientada ao contexto, como seleção de alternativas,
não são comentadas nas referências citadas.
O formatador CMIFed, denominado CMIFed player, é o elemento
responsável pelo controle da apresentação de documentos CMIF (CWI Multimedia
Interchange Format) (van Rossum et al., 1993; Hardman et al., 1993b). As
entidades presentes nesse modelo são praticamente as mesmas da linguagem
SMIL (W3C, 1998; W3C, 2001a), e o seu formatador deu origem a um dos
principais formatadores SMIL (ou player SMIL): o sistema GRiNS da Oratrix
(Oratrix, 2002). Além do GRiNS, outro exemplo de formatador implementado
para a linguagem SMIL versão 2.0 é a plataforma RealOne, da RealNetworks.
Existe ainda um suporte oferecido pelo browser Internet Explorer 6.0 à proposta
de padrão XHTML+SMIL Profile (W3C, 2001b), também baseada na linguagem
SMIL. A comparação nesta seção será feita com relação às funcionalidades do
formatador CMIFed.
Quando um usuário requisita a exibição de um documento CMIF, o
formatador entra em uma fase de compilação, onde um grafo de dependências
temporais é construído. No grafo, os nós representam transições em estados dos
eventos de apresentação (pontos de sincronização) e as arestas são relações
temporais entre os eventos. Inicialmente, o grafo é construído percorrendo a
hierarquia do documento em profundidade, utilizando apenas as restrições
temporais especificadas pelas composições paralelo e seqüencial oferecidas pelo
modelo de documentos (van Rossum et al. 1993; W3C, 1998; W3C, 2001a). Em
um passo seguinte, arestas representando os relacionamentos especificados por
sync arcs (do modelo CMIF) são acrescidas. Quando um arco de sincronismo é
definido utilizando uma marcação que não seja o início ou fim de um evento, um
novo nó e novas arestas ligando a marcação a outras marcações do mesmo evento
135
são acrescidos ao grafo. Finalmente, dois nós especiais são definidos no plano de
execução (grafo), o start node e o end node. O start node é conectado, através de
uma aresta com duração nula, ao nó representando o início do primeiro evento a
ser exibido no documento. Da mesma forma, uma aresta também com duração
nula liga o nó que define o fim do último evento ao end node.
Construído o grafo, o formatador entra na fase de execução. Um relógio
interno é disparado e a execução feita utilizando um algoritmo que percorre o
grafo criado. Inicialmente, o start node é marcado. Quando um nó é marcado,
todas as arestas que partem desse nó recebem o valor do relógio de execução no
momento da marcação. Quando a duração especificada na aresta é completada, a
aresta é marcada. Quando todas as arestas que chegam em um nó são marcadas, o
nó é marcado. A execução termina quando o end node é marcado.
Ao simular uma execução e percorrer o grafo de dependências temporais, o
sistema é capaz de descobrir erros na especificação temporal, através da detecção
de caminhos fechados, e também conflitos por recursos. O grafo também permite
que o formatador faça pré-busca do conteúdo dos objetos. O formatador CMIF
realiza uma pré-busca simplificada, utilizando os momentos em que o formatador
encontra-se ocioso. A utilização de heurísticas de busca para eventos gerados por
pontos de sincronização imprevisíveis, bem como negociações de QoS para busca
dos conteúdos não são abordados na implementação. O sistema também não
aborda a questão dos ajustes das durações, trabalhando com tempos inflexíveis nas
arestas dos arcos. Na versão mais recente da linguagem SMIL (versão 2.0), essa
limitação foi eliminada com a introdução de um intervalo para especificação das
durações. No entanto, da mesma forma que no sistema Madeus, essa flexibilidade
não carrega consigo métricas para direcionar a qualidade do ajuste.
6.2
Integração entre formatadores e ferramentas de exibição
Os principais browsers WWW possuem uma API (Application Program
Interface) para programação de plug-ins, originalmente proposta pela Netscape
(Netscape, 1998), que permite que aplicações externas sejam incorporadas ao
ambiente de navegação da Web, principalmente para que formatos não
reconhecidos pelo browser sejam tratados em um ambiente único. Porém, plug-ins
136
não são ferramentas de exibição hipermídia e sim apenas ferramentas de exibição,
pois a sua API não oferece suporte para definição de relacionamentos entre
objetos apresentados em diferentes plug-ins, e até mesmo entre plug-ins e páginas
HTML. Na realidade, existem alguns mecanismos, como LiveConnect e ActiveX,
que permitem a integração de páginas HTML com plug-ins, e até mesmo com
outras tecnologias como scripts e applets. No entanto, esses mecanismos são
dependentes do browser utilizado (Netscape ou Internet Explorer) e baseados em
códigos de programação não triviais que devem ser embutidos nos próprios
objetos de mídia. Uma outra limitação da tecnologia é o fato do plug-in ter seu
ciclo de vida amarrado ao ciclo de vida da página HTML que o contém.
Bouvin e Schade (Bouvin & Schade, 1999) propõem extensões à API de
plug-ins com o principal objetivo de permitir a criação de elos entre objetos e subregiões desses objetos, independente da ferramenta (plug-in) que os exibe. Uma
vez que não era possível alterar a API utilizada pelos browsers existentes, os
autores implementaram um sistema, denominado Mimicry, utilizando applets Java
para emular os relacionamentos. Um proxy específico do sistema, chamado
DHMProxy, encarrega-se de substituir as marcações de plug-ins das páginas
(EMBED e OBJECT) por referências aos applets do sistema Mimicry. No entanto,
os elos que o sistema permite criar são sempre elos de interatividade, não havendo
suporte para a definição de relacionamentos de sincronização temporal entre os
objetos. Além disso, os autores não abordam os aspectos relacionados ao
desenvolvimento das ferramentas e suas integrações com o formatador hipermídia,
como foi feito com o framework apresentado no Capítulo 3 desta tese.
O modelo de execução do sistema Madeus (Jourdan et al., 1998a) define os
objetos de execução como sendo a própria ferramenta de exibição, adotando um
mecanismo de plugin para permitir a integração com objetos que devam ser
apresentados por aplicações externas. No entanto, a interface para comunicação é
uma simplificação da interface padrão para os objetos de execução que o ambiente
de execução sabe controlar. Essa simplificação obriga que os objetos de execução
controlados por plugins sejam tratados como objetos com durações imprevisíveis
(objetos incontroláveis), dificultando a manutenção das relações de restrição
temporal que o Madeus utiliza.
137
Diferente dos trabalhos anteriormente mencionados, esta tese propôs um
modelo de interface, genérico e adaptável, para integração de ferramentas de
exibição e formatadores hipermídia, que permite tratar igualmente todos os
objetos sendo exibidos, independente da aplicação exibidora que os controla. O
framework de integração das ferramentas permite que novas ferramentas de
exibição venham a ser incorporadas, e outras tantas existentes possam ser
adaptadas, funcionando de maneira integrada entre si e com o formatador
hipermídia. A construção de adaptadores para ferramentas que utilizam o JMF foi
apenas um exemplo de como o framework apresentado pode ser aplicado. No
momento, encontram-se, também em desenvolvimento, especializações para
integrar o formatador HyperProp a exibidores QuickTime e RealOne.
6.3
Mecanismos de pré-busca
Jeong et al. (Jeong et al., 1997) desenvolveram um mecanismo para efetuar
o pré-escalonamento de apresentações multimídia. O módulo de pré-busca,
denominado EPS (Event Pre-Scheduler), estima os tempos máximos para
recuperação de cada um dos objetos por inteiro e constrói um plano de pré-busca
para que todos os objetos estejam prontos antes de suas exibições. O algoritmo
para construção do plano de pré-busca retarda o início da apresentação do
documento como um todo, para evitar que durante a exibição ocorram “gaps” e
perdas de sincronização. A estrutura de dados do plano de execução, utilizada
como entrada para a construção do plano de pré-busca, baseia-se na divisão dos
objetos de mídia em segmentos mínimos que satisfazem, entre si, a condição de
igualdade (equals) de Allen (Allen, 1983). Durante a execução, existe um monitor
que compara o tempo de pré-busca de cada objeto com o tempo previsto no plano.
Sempre que esse tempo ultrapassa o limite previsto, um procedimento para
recalcular as durações de apresentação dos objetos é disparado a fim de manter a
sincronização dos segmentos. Quando necessário, o algoritmo sacrifica as mídias
estáticas, reduzindo suas durações. O aspecto interessante desse algoritmo é que
ele serve também para corrigir atrasos que tenham sido causados não apenas pelo
sistema operacional, mas pelo próprio processamento do mecanismo de pré-busca.
138
O EPS é um trabalho interessante porque apresenta, de uma maneira prática,
vários dos requisitos que devem ser considerados na elaboração de uma estratégia
de pré-busca. No entanto, a proposta considera apenas objetos com exibições
previsíveis e todos os conteúdos devem estar armazenados localmente (em disco)
e de maneira contígua, não sendo abordados aspectos referentes a transmissões na
rede. Além disso, o mecanismo funciona sempre carregando o conteúdo inteiro
dos objetos em memória antes das exibições, não existindo a possibilidade da
ferramenta de exibição consumir os dados em paralelo com a busca do conteúdo.
A proposta também limita o reajuste, em tempo de execução, apenas do plano de
execução do documento, não sendo previsto pela estratégia a possibilidade de
realizar correções no próprio plano de pré-busca.
Khan e Tao (Khan & Tao, 2001a; Khan & Tao, 2001b) estabelecem um
modelo que permite determinar a melhor seqüência de pré-busca para páginas
compostas na Web. Páginas compostas são aquelas que incluem, além do
tradicional texto HTML, referências a outros objetos como imagens, applets,
animações, vídeo, áudio etc. Essas páginas compostas são denominadas
composições hipermídia. Os autores definem uma classificação em três perfis para
os conteúdos dos elementos de uma composição, considerando os aspectos de
transmissão na rede: objetos de taxa constante (mídia CBR: áudio, vídeo etc.),
objetos de uma única rajada (mídia impulsiva: página HTML, imagens estáticas,
applets JAVA etc.) e objetos de múltiplas rajadas (mídia impulsiva em série:
documentos PDF de várias páginas, animações, apresentações em slides etc.). Um
modelo matemático permite calcular, para cada composição hipermídia, a
quantidade mínima de dados que deve ser trazida antes de sua exibição.
Juntamente com a informação de probabilidade de navegação em cada elo, o
trabalho demonstra qual é a melhor escolha para a construção do plano de
escalonamento, ou seja, qual a melhor ordem de busca para as páginas compostas.
Um algoritmo divide a largura de banda da rede para que as requisições de prébusca convivam com as requisições dos conteúdos sendo efetivamente
apresentados, sem que o desempenho dessas últimas requisições seja prejudicado.
O trabalho, no entanto, não contempla, a possibilidade de existirem
relacionamentos de sincronização temporal entre as mídias, na construção do
plano de pré-busca.
139
É importante observar que tanto o EPS como a proposta de Khan e Tao
poderiam ser implementados como instanciações do framework de pré-busca
definido nesta tese. As propostas poderiam estar presentes principalmente nas
implementações das estratégias de construção dos planos de pré-busca e de
estimativa do tempo de busca.
Em (Revel et al., 1996) foi desenvolvida a implementação de um módulo de
pré-busca, denominado Prefetcher, para copiar antecipadamente, do disco para a
memória principal, o conteúdo das aplicações multimídia, em especial vídeos
MPEG. O Prefetcher é implementado como um módulo integrado ao sistema
operacional, oferecendo uma interface para que as aplicações multimídia possam
descrever o padrão de acesso aos dados (tamanho dos quadros, taxa em que os
quadros serão consumidos, padrão de repetição dos quadros I, P e B etc.) e o
instante de tempo em que os dados serão necessários. A proposta permite que as
aplicações multimídia, após agendarem a apresentação, utilizem chamadas
tradicionais de entrada e saída para ter acesso aos dados. Internamente, o
Prefetcher cuida de enviar chamadas assíncronas ao sistema operacional, que
resultam numa pré-busca dos dados pelo próprio sistema operacional. Contudo, a
interface oferecida é bastante limitada, não prevendo chamadas para aplicações
que possuam uma quantidade mais variada de tipos de conteúdo e que permitam
exibições imprevisíveis. Além disso, o estudo da extensão da arquitetura para
ambientes distribuídos em rede é deixado como trabalho futuro.
Diferente da proposta desta tese, nenhum dos trabalhos comentados nesta
seção aborda a questão de integrar o mecanismo de pré-busca a funções de
provisão e gerência de QoS. Um outro ponto identificado é, com exceção do EPS,
as outras duas propostas não mencionam a possibilidade de que os resultados das
pré-buscas realimentem os planos de execução dos documentos.
6.4
Mecanismos de adaptação
Propostas para computação dos tempos elásticos em apresentações
multimídia/hipermídia têm sido endereçadas na literatura (Buchanan & Zellweger,
1993a; Kim & Song, 1995; Sabry-Ismail et al., 1999).
140
O algoritmo de ajuste do formatador Firefly (Buchanan & Zellweger, 1993a)
realiza o cálculo das durações ótimas através de programação linear e fazendo uso
do método simplex. No modelo de documentos utilizado pelo sistema, as durações
são definidas como funções de custo lineares, similares à exemplificada na Figura
26c.
Abordagem semelhante é utilizada pelo formatador do sistema Isis (Kim &
Song, 1995). No entanto, o cálculo de otimização das durações acrescenta a noção
de justiça na distribuição dos ajustes pelos objetos de mídia, procurando soluções
que minimizem o quanto cada objeto tem sua duração modificada, em troca de
uma maior quantidade de objetos tendo seus tempos de apresentação ajustados. O
mecanismo de ajuste também permite que o usuário imponha uma restrição de
duração global para uma cadeia temporal e é capaz de retornar não apenas a
solução ótima como também os limites de tempo mínimo e máximo possíveis para
a duração da apresentação da cadeia.
Tanto o formatador Firefly como o formatador Isis realizam o ajuste dos
tempos elásticos apenas na fase de compilação do documento. Além disso, a
utilização do método simplex de maneira eficiente para o cálculo da solução,
normalmente requer o uso de bibliotecas que necessitam de uma grande
quantidade de memória e disco, o que dificulta sua integração à aplicação. Outro
ponto a ser considerado é que pode ser que o aumento do número de objetos que
têm suas durações modificadas não seja uma boa estratégia, podendo ser mais
interessante em termos de esforço computacional, manter os ajustes em uma
quantidade mínima de elementos.
Diferente das abordagens anteriores, a ferramenta de ajuste utilizada pelo
formatador HyperProp não é baseada em programação linear, mas sim na
utilização de algoritmos para distribuir, com um custo mínimo, tensões e fluxos
em grafos de tensões (Bachelet et al., 2000). Essa abordagem faz com que as
estruturas de dados e bibliotecas necessárias para o cálculo sejam bem inferiores
às normalmente exigidas pela programação linear, com o custo de uma eficiência
aproximadamente duas vezes pior (Bachelet et al., 2000).
Apesar do pior desempenho, a utilização de grafos de tensão para modelar o
problema de ajuste dos tempos elástico trouxe uma nova visão e novas
perspectivas de algoritmos para solução do problema. Os métodos out-of-kilter
141
(Fulkerson, 1961) e dual cost scaling (Ahuja et al., 2000) são atualmente
suportados pela ferramenta utilizada no formatador HyperProp. Além disso, o uso
de novos métodos para os documentos com topologia do tipo série-paralelo
(Duffin, 1965) estão sendo investigados. Acredita-se que essa abordagem viabilize
a aplicação dos ajustes durante a execução dos documentos. Para isso, é preciso
que a estratégia de ajuste seja capaz de identificar nas cadeias temporais estruturas
que respeitem essa topologia.
O formatador do sistema Madeus (Sabry-Ismail et al., 1999) descreve uma
solução para ajuste em tempo de execução (on-the-fly) Uma vez que as durações
dos objetos são flexíveis, mas não dispõem de métricas de custo de alteração, a
estratégia de ajuste utiliza uma abordagem diferente. Quando o formatador
percebe uma violação nos tempos programados, o algoritmo de correção é
acionado para tentar encontrar uma nova configuração que reestabeleça os tempos
originalmente programados o mais rapidamente possível. A idéia da estratégia é
minimizar o período que o documento se encontra fora do sincronismo idealmente
imposto pelo autor, respeitando os limites para duração de cada objeto.
A característica de adaptação através de seleção de alternativas é possível de
ser encontrada nos formatadores SMIL, explorando o uso do elemento switch da
linguagem (W3C, 1998; W3C, 2001a), no formatador CMIFed, explorando o
conceito de canais e a possibilidade de torná-los habilitados ou não (Hardman et
al., 1993a; Hardman et al., 1993b; van Rossum et al., 1993) e na aplicação CardioOP (Klas et al., 1999), explorando os elementos de adaptação switch e query do
modelo de documentos ZyX (Boll & Klas, 1999).
Conclusões
142
7
Conclusões
Esta tese apresenta uma análise detalhada das principais questões envolvidas
no projeto e implementação de sistemas para controle de apresentações
hipermídia. Primeiramente (Capítulo 1), o trabalho posiciona a função de controle
da execução (formatação) dentro da arquitetura dos sistemas hipermídia. Em
seguida (Capítulo 2), a tese conduz um estudo das características comuns e
também das características desejáveis de serem encontradas nos modelos para
definição de hiperdocumentos. Foi possível constatar que, não somente a
descrição dos documentos, mas também informações contextuais externas aos
documentos são desejáveis de estarem disponíveis no momento da execução da
apresentação, pois é natural que a formatação dos documentos seja tratada como
uma aplicação orientada a contexto. A partir dos requisitos levantados, foi
definido um modelo de documentos orientado à máquina de controle
(formatador), baseado nos conceitos de eventos e elos. O modelo proposto permite
que as especificações dos documentos sejam flexíveis, buscando favorecer a
exploração das informações contextuais e a aplicação de técnicas de adaptação. O
modelo também procura ser genérico e extensível para acomodar o controle de
apresentações descritas em modelos de autoria hipermídia.
O passo seguinte do trabalho foi levantar os requisitos para o ambiente de
execução hipermídia e, em especial, as funcionalidades desejáveis de serem
encontradas nas implementações de formatadores. Nesse sentido, os Capítulos 3 e
4 discutem a estruturação dos componentes de formação, a integração entre
ferramentas de exibição e formatadores, a integração entre ferramentas de
diferentes desenvolvedores, a incorporação de mecanismos de pré-busca, a
orquestração da qualidade de serviço das apresentações, tanto inter-mídia como
intra-mídia, e o projeto e implementação de mecanismos de ajuste temporal dos
componentes de um hiperdocumento.
Conclusões
143
As análises realizadas e a modelagem proposta para o projeto de ambientes
de execução hipermídia são as duas principais contribuições desta tese. O
resultado final foi uma arquitetura que integra três tipos de orquestração
(orquestração da apresentação propriamente dita, orquestração da pré-busca e
orquestração intra-mídia), mecanismos de adaptação das apresentações e
mecanismos de consulta a informações contextuais. Todos esses aspectos de
controle estão organizados de maneira modular e independentes das ferramentas
responsáveis por exibir os conteúdos. O objetivo é facilitar a integração de
formatadores, tanto a novas ferramentas de exibição que venham a ser
desenvolvidas, como a adaptadores para exibidores que já existam e sejam
utilizados em outros sistemas de apresentação hipermídia. A arquitetura proposta
para o ambiente de execução também procura viabilizar a integração entre
ferramentas de diferentes desenvolvedores (Rodrigues et al., 2001).
De um modo mais detalhado, é possível desmembrar as duas principais
contribuições descritas no parágrafo anterior nos seguintes itens:
•
especificação de um modelo hipermídia de execução propício à
implementação de estratégias de adaptação;
•
modelagem de um ambiente de execução hipermídia genérico;
•
definição de uma API para integração de formatadores com exibidores
genéricos;
•
análise dos requisitos e modelagem de uma arquitetura genérica para
mecanismos de pré-busca;
•
mecanismos de orquestração intra-mídia, integrada ao framework de
orquestração de QoS proposto em (Gomes, 1999; Gomes et al., 2001);
•
mecanismos de adaptação dos documentos. O módulo de adaptação
proposto prevê a incorporação de estratégias de ajuste dos tempos elásticos
e de adaptação dos objetos em função das características da plataforma de
exibição. Conforme discutido no Capítulo 2, o foco da pesquisa foi a
adaptação em relação à infra-estrutura, mas adaptações simples orientadas
ao perfil do usuário também podem ser aplicadas.
Conclusões
144
Adicionalmente, esta tese contribui com a implementação de um formatador
hipermídia e de ferramentas de exibição para o sistema HyperProp (Capítulo 5).
Essa implementação foi útil na validação das propostas desta pesquisa e, ao
mesmo tempo, permitiu refinar as análises com uma visão das questões práticas
no desenvolvimento de um ambiente de execução. Da mesma maneira que nas
contribuições anteriores, é possível enumerar de modo mais detalhado os
resultados obtidos com a implementação:
•
implementação de ferramentas de exibição para os tipos básicos de mídia.
No caso das mídias contínuas foram desenvolvidos adaptadores para o
Java Media Framework da Sun;
•
implementação de um módulo conversor que faz a tradução do modelo de
documentos NCM para o modelo hipermídia de execução definido para o
formatador;
•
implementação de módulos conversores que fazem a tradução das
linguagens NCL e SMIL (versão 1.0) para o modelo de documentos NCM;
•
implementação de um módulo de pré-busca para melhorar a qualidade das
apresentações hipermídia. Nesse caso, foram desenvolvidas estratégias
para a compilação dos planos e escalonamento das ações;
•
implementação de um módulo de adaptação integrado a um conjunto de
algoritmos para cálculo de ajuste dos tempos elásticos, desenvolvidos em
um projeto de cooperação com o grupo de pesquisa em otimização da
Universidade Blaise Pascal.
A pesquisa realizada nesta tese também contribuiu para o refinamento do
Modelo de Contextos Aninhados (Soares et al., 1998a; Soares et al., 1998b;
Soares et al., 1999; Soares et al., 2000; Soares et al., 2003) e para a definição de
um conjunto de módulos para autoria declarativa de documentos hipermídia
(Antonacci et al., 2000; Muchaluat-Saade et al., 2002; Muchaluat-Saade, 2003;
Rodrigues, 2002a). Além disso, o trabalho realizado colaborou para o estudo do
uso de model checker na verificação formal da consistência temporal de
apresentações (Felix et al., 2002) e para a definição de heurísticas para o ajuste
das apresentações em tempo de execução (Medina et al., 2001).
Conclusões
145
Como trabalho futuro, pretende-se implementar um módulo gerente da
orquestração intra-mídia, integrado a mecanismos de orquestração da QoS em
sistemas operacionais e redes. Nesse sentido, o próximo passo é efetuar a junção
com o controlador de admissão para sistemas operacionais Linux, desenvolvido
por (Moreno, 2002), e também com a API para reserva de recursos em redes
TCP/IP, definida em (Mota, 2001). Pretende-se também explorar o recurso da
orquestração de pré-busca para integrar o formatador HyperProp a provedores
com suporte à reserva de recursos antecipada (Berson et al., 1998; Degermark et
al., 1995; Wolf et al., 1995).
Outro trabalho futuro é a atualização do conversor SMIL para oferecer
suporte a especificações realizadas na versão 2.0 da linguagem (W3C, 2001a) e
para tradução dos documentos diretamente no modelo de execução. Nessa linha,
esforços também podem ser feitos para implementar conversores para outros
modelos de entrada.
Um terceiro trabalho interessante é a implementação do proxy de
informações contextuais do formatador HyperProp como um usuário de um
mecanismo de gerência de contexto externo.
Ainda em termos de implementação, com a concretização dos serviços de
informação contextual, estratégias mais precisas para a estimativa dos tempos de
preparação podem ser desenvolvidas e incorporadas ao mecanismo de pré-busca
do formatador HyperProp. Pretende-se também, embutir no formatador, técnicas
de ajuste do plano de pré-busca em tempo de execução e estratégias que, na
construção do plano, considerem as probabilidades de interatividade do usuário e
a gerência do espaço em memória no cliente para armazenamento prévio dos
conteúdos.
Dando continuidade à cooperação com o grupo de otimização da
Universidade Blaise Pascal, pretende-se investigar o uso, na prática, dos diversos
algoritmos propostos e implementados para ajuste otimizado dos tempos elásticos,
não só em compilação, como também durante a execução dos documentos. Os
estudos futuros pretendem considerar, além da minimização dos custos, outros
critérios, como o número de objetos modificados e a distribuição dos ajustes entre
os objetos. Uma investigação dos mecanismos de construção dos grafos de tensão
também se faz necessária. É preciso estender a função geradora do grafo para que
Conclusões
146
considere não apenas os eventos externos, como também eventos de apresentação
internos a um objeto. Outro aspecto que requer um estudo maior é o mapeamento
das condições e restrições compostas, previstas pelo modelo de execução do
formatador, nos nós e arestas do grafo de tensões. Talvez também seja preciso
fazer uso no formatador de algoritmos que decomponham a cadeia temporal em
estruturas que respeitem a topologia série-paralelo.
Ligada à questão da adaptação, está também o estudo da adequação do
framework de formatação proposto nesta tese para acomodar técnicas de
adaptação dos documentos orientadas ao usuário e orientadas à manipulação da
quantidade de informação, discutidas na Seção 2.1.1.1.
Em andamento, encontra-se o projeto para realizar uma nova instanciação
do framework para construção de ambientes de execução adequados para
equipamentos receptores (set-top boxes) de sinais de televisão digital, a fim de
utilizar os vários mecanismos de orquestração definidos nesta tese no controle de
programas de TV interativa. Da mesma forma, poderia ser realizado um estudo da
adequação do framework de formatação para instanciar formatadores que
controlem a apresentação em clientes distribuídos, isto é, clientes cujos
dispositivos de entrada e saída encontram-se espalhados em mais de uma estação,
interligadas por um sistema de comunicação.
A idéia de distribuir os mecanismos de controle das apresentações
hipermídia pode ser estendida, colocando o formatador como um conjunto de
mecanismos que executam cooperativamente na plataforma cliente, na plataforma
servidora e também em possíveis elementos intermediários (proxies, caches etc.).
Esse tipo de generalização é um tópico em aberto, que merece um estudo mais
detalhado. No entanto, espera-se que os resultados obtidos com este trabalho
possam contribuir na busca de soluções para essa questão.
Por fim, espera-se que, com o refinamento dos componentes e das interfaces
definidas na arquitetura proposta nesta tese, seja possível obter uma plataforma
aberta para teste de novos algoritmos envolvidos no controle de apresentações de
hiperdocumentos.
Referências
147
8
Referências
AHUJA, R.K.; HOCHBAUM, D.; ORLIN, J.B. Solving the Convex Cost
Integer Dual Network Flow Problem. Management Science, 2000.
ALLEN, J.F. Maintaining Knowlegde about Temporal Intervals.
Communications of the ACM, v. 26, n. 11, Novembro de 1983, p. 832-843.
ANDERSON, K.M. Integrating Open Hypermedia Systems with the World
Wide Web. VIII ACM International Hypertext Conference, Southampton,
1997, p. 157-166.
ANDREWS, K.; KAPPE, F.; MAURER, H. Serving Information to the Web
with Hyper-G. Computer Networks and ISDN Systems, v. 27, n. 6, 1995, p.
919-926.
ANTONACCI, M.J. et al. Improving the Expressiveness of XML-Based
Hypermedia Authoring Languages. VII Multimedia Modeling Conference
- MMM’2000, Nagano, Japão, Novembro de 2000, p. 71-88.
BACHELET, B. et al. Elastic Time Computation for Hypermedia Documents.
VI Simpósio Brasileiro em Sistemas Multimídia e Hipermídia SBMídia’2000, Natal, Brasil, Junho de 2000, p. 47-62.
BERNERS-LEE, T.J. et al. The World-Wide Web. Communications of the
ACM, v. 37, n. 8, Agosto de 1994, p. 76-82.
BERNERS-LEE, T.J.; MASINTER, L.; MCCAHILL, M. Uniform Resource
Locators (URL). IETF Request for Comments (RFC) 1738, Dezembro de
1994.
BERSON, S.; LINDELL, R.; BRADEN, R. An Architecture for Advance
Reservations in the Internet. Relatório Técnico, USC Information
Sciences Institute, Julho de 1998.
BHATTI, N.; BOUCH, A.; KUCHINSKY, A. Integrating User-Perceived
Quality into Web Server Design, WWW Conference, 2000.
BOLL, S.; KLAS, W. ZYX – A Semantic Model for Multimedia Documents
and Presentations. VIII IFIP Conference on Data Semantics, 1999.
Referências
148
BOLL, S.; KLAS, W.; WANDEL, J. A Cross-Media Adaptation Strategy for
Multimedia Presentation. ACM Multimedia, Orlando, EUA, Outubro de
1999.
BOLL, S.; KLAS, W.; WESTERMANN, U. Multimedia Document Models –
Sealed Fate or Setting Out for New Shores? IEEE International
Conference on Multimedia Computing and Systems (ICMCS), Florença,
Itália, Junho de 1999.
BOUVIN, N.O.; SCHADE, R. Integrating Temporal Media and Open
Hypermedia on the World Wide Web. VIII International World Wide
Web Conference, 1999, p. 375-387.
BRADEN, R. et al. Resource ReSerVation Protocol (RSVP): Version 1
Functional Specification. IETF Request for Comments (RFC) 2205,
Setembro de 1997.
BRUSILOVSKY, P. Methods and Techniques of Adaptive Hypermedia.
Journal of User Modelling and User-Adaptive Interaction, v. 6, n. 2-3, 1996,
p. 87-129.
BUCHANAN, M.C.; ZELLWEGER, P.T. Specifying Temporal Behavior in
Hypermedia Documents. European Conference on Hypertext - ECHT'92,
Milão, Itália, Dezembro de 1992.
BUCHANAN, M.C.; ZELLWEGER, P.T. Automatic Temporal Layout
Mechanisms. ACM International Conference on Multimedia, Anaheim,
EUA, 1993, p. 341-350.
BUCHANAN, M.C.; ZELLWEGER, P.T. Automatically Generating Consistent
Schedules for Multimedia Documents. ACM Multimedia Systems Journal,
v. 1, n. 2, Springer-Verlag, Setembro de 1993, p. 55-67.
CASANOVA, M.A. et al. The Nested Context Model for Hyperdocuments.
Hypertext’91, San Antonio, EUA, Dezembro de 1991, p. 193-201.
CHEN, G.; KOTZ, D. A Survey of Context-Aware Mobile Computing
Research. Department of Computer Science. Dartmouth College,
Novembro de 2000.
COHEN, E.; KAPLAN, H. Prefetching the Means for Document Transfer: A
New Approach for Reducing Web Latency. IEEE INFOCOM 2000, TelAviv, Israel, Março de 2000.
COLCHER, S. Um Meta Modelo para Aplicações e Serviços de Comunicação
Adaptáveis e com Qualidade de Serviço. Tese de Doutorado,
Departamento de Informática, PUC-Rio, Rio de Janeiro, Brasil, Novembro
de 1999.
Referências
149
COULSON, G.; BLAIR, G. Architectural Principles and Techniques for
Distributed Multimedia Application Support in Operating Systems.
ACM Operating System Review, v. 29, n. 4, Outubro de 1995, p. 17-24.
DEGERMARK, M. et al. Advance Reservation for Predictive Service. 5th
International Workshop on Network and Operating System Support for
Digital Audio and Video, Durham, Abril de 1995.
DEY, A.K.; SALBER, D.; ABOWD, G.D. A Conceptual Framework and a
Toolkit for Supporting the Rapid Prototyping of Context-Aware
Applications. Human-Computer Interaction (HCI) Journal - special issue on
Context-Aware Computing, v. 16, n. 2-4, 2001, p. 97-166.
DÍAZ, P.; AEDO, I.; PANETSOS, F. Modeling the Dynamic Behavior of
Hypermedia Applications. IEEE Transactions on Software Engineering, v.
27, n. 6, Junho de 2001, p. 550-572.
DUDA, A.; KERAMANE, C. Structured Temporal Composition of
Multimedia Data. Proceedings of the IEEE International Workshop on
Multimedia Database Management Systems, Blue Mountain Lake, EUA,
Agosto de 1995.
DUFFIN, R.J. Topology of Series-Parallel Graphs. J. Math. Anal. Appl., vol.
10, 1965, p. 303-318.
ELSON J.; CERPA, A. (eds.). ICAP the Internet Content Adaptation Protocol.
ICAP White Paper V1.01, ICAP Forum, 2001.
FELDMANN, A. et al. Performance of Web Proxy Caching in Heterogeneous
Bandwidth Environments. IEEE INFOCOM’99, 1999.
FELIX, M.F.; HAEUSLER, E.H.; SOARES, L.F.G. Validating Hypermedia
Documents: a Timed Automata Approach. Monografia em Ciência da
Computação, Departamento de Informática, PUC-Rio, Rio de Janeiro,
Brasil, 2002.
FREED, N.; BORENSTEIN, N. Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies. IETF Request
for Comments 2045, Novembro de 1996.
FULKERSON, D.R. An Out-of-Kilter Method for Minimal Cost Flow
Problems. SIAM Journal on Applied Math., vol. 9, 1961, p. 18-27.
GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented
Software. Addison Wesley, 1995.
GOMES, A.T.A. Um Framework para Provisão de QoS em Ambientes
Genéricos de Processamento e Comunicação. Dissertação de Mestrado,
Departamento de Informática, PUC-Rio, Rio de Janeiro, Brasil, Maio de
1999.
Referências
150
GOMES, A.T.A.; COLCHER, S.; SOARES, L.F.G. Modeling QoS provision on
Adaptable Communication Environments. International Conference on
Communications - ICC2001, Helsinque, Finlândia, Junho de 2001.
GORINI, R.A.C. Um Ambiente de Suporte à Autoria Cooperativa de
Documentos Hipermídia. Dissertação de Mestrado, Departamento de
Informática, PUC-Rio, Rio de Janeiro, Brasil, Setembro de 2001.
GRØNBAEK, K.; BOUVIN, N.O.; SLOTH, L. Designing Dexter-based
hypermedia services for the World Wide Web. VIII ACM International
Hypertext Conference, Southampton, 1997, p. 146-156.
GUDGIN, M. et al. SOAP Version 1.2. W3C Working Draft, 2001.
HALASZ, F.; SCHWARTZ, M. The Dexter Hypertext Reference Model.
Communications of the ACM, v. 37, n. 2, Fevereiro de 1994.
HALL, W.; DAVIS, H.C.; HUTCHINGS, G.A. Rethinking hypermedia: the
Microcosm approach. Kluwer Academic Press, Amsterdam, Holanda,
1996.
HARDMAN, L.; BULTERMAN, D.C.A.; VAN ROSSUM, G. The Amsterdam
Hypermedia Model: extending hypertext to support real multimedia.
Hypermedia Journal, v. 5, n. 1, 1993, p. 47-69.
HARDMAN, L.; VAN ROSSUM, G.; BULTERMAN, D.C.A. Structured
Multimedia Authoring. Proceedings of ACM Multimedia’93, Anaheim,
EUA, Agosto de 1993, p. 283-289.
HOMESITE
5.
Macromedia,
2001.
Disponível
em
http://www.macromedia.com/software/homesite/. Acesso em 2 jul. 2003
ISO/IEC - Information Technology. Hypermedia/Time-based Structuring
Language (HyTime). International Standard (IS) 10744, 1992.
ISO/IEC - Information Technology. Coding of Multimedia and Hypermedia
Information – Part 6: Support for Enhanced Interactive Applications.
International Standard (IS) 13522-6, 1996.
ITU - International Telecommunications Union. One-way transmission time.
Recomendação G.114, Fevereiro de 1996.
JEONG, T.; HAM, J.; KIM, S. A Pre-scheduling Mechanism for Multimedia
Presentation Synchronization. IEEE International Conference on
Multimedia Computing and Systems, Ottawa, Canadá, 1997, p. 379-386.
JOURDAN, M. et al. Madeus, an Authoring Environment for Interactive
Multimedia Documents. ACM Multimedia Conference 98, Inglaterra,
Setembro de 1998, p. 267-272.
Referências
151
JOURDAN, M.; ROISIN, C.; TARDIF, L. Multiviews Interfaces for
Multimedia Authoring Environments. V Conference on Multimedia
Modeling, Lausanne, Suiça, Outubro de 1998, p. 72-79.
KHAN, J.; TAO, Q. Partial Prefetch for Faster Surfing in Composite
Hyprmedia. USENIX Symposium on Internet Technology and Systems,
São Francisco, EUA, Março de 2001.
KHAN, J.; TAO, Q. Prefetch Scheduling for Composite Hypermedia. IEEE
International Conference on Communications - ICC 2001, Helsinque,
Finlândia, Junho de 2001.
KIM, M.; SONG, J. Multimedia Documents with Elastic Time. Proceedings of
ACM Multimedia’95, São Francisco, EUA, Novembro de 1995.
KLAS, W.; GREINER, C.; FRIEDL, R. Cardio-OP – Gallery of Cardiac
Surgery. IEEE International Conference on Multimedia Computing and
Systems (ICMS’99), Florença, Itália, Junho de 1999.
KROEGER, T.; LONG, D.D.E.; MOGUL, J. Exploring the Bounds of Web
Latency Reduction from Caching and Prefetching. USENIX Symposium
on Internet Technology and Systems, Monterey, Dezembro de 1997, p. 319328.
LEMLOUMA, T.; LAYAÏDA, N. The Negotiation of Multimedia Content
Services in Heterogeneous Environments. VIII Multimedia Modeling:
Modeling Multimedia Information and Systems, Amsterdam, Holanda,
Novembro de 2001, p. 187-206.
LITTLE, T.; GHAFOOR, A. Synchronization and Storage Models for
Multimedia Objects. IEEE Journal Selected Areas of Communications, v.
8, n. 3, Abril de 1990, p. 413-427.
LUTUS, P. Arachnophilia 5.0. Paul Lutus Copyright, 2002. Disponível em
http://www.arachnoid.com/arachnophilia/index.html. Acesso em 2 jul. 2003.
MEDINA, M.T.; RIBEIRO, C.C.; SOARES, L.F.G. Automatic Scheduling of
Hypermedia Documents with Elastic Time. Monografias em Ciência da
Computação – MCC08/01, Departamento de Informática, PUC-Rio, Rio de
Janeiro, Brasil, 2001.
MORENO, M.F. Framework para Provisão de Qualidade de Serviço em
Sistemas Operacionais. Dissertação de Mestrado, Departamento de
Informática, PUC-Rio, Rio de Janeiro, Brasil, Agosto de 2002.
MOTA, O.T.J. Uma Arquitetura Adaptável para Provisão de QoS na
Internet. Dissertação de Mestrado, Departamento de Informática, PUC-Rio,
Rio de Janeiro, Brasil, Maio de 2001.
Referências
152
MOURA, M.S.A. Relações Espaciais em Documentos Hipermídia. Dissertação
de Mestrado, Departamento de Informática, PUC-Rio, Rio de Janeiro,
Brasil, Agosto de 2001.
MUCHALUAT-SAADE, D.C. Browsers e Trilhas para Documentos
Hipermídia Baseados em Modelos com Composições Aninhadas.
Dissertação de Mestrado, Departamento de Informática, PUC-Rio, Rio de
Janeiro, Brasil, Março de 1996.
MUCHALUAT-SAADE, D.C. Relações em Linguagens de Autoria
Hipermídia: Aumentando Reuso e Expressividade. Tese de Doutorado,
Departamento de Informática, PUC-Rio, Rio de Janeiro, Brasil, Março de
2003.
MUCHALUAT-SAADE, D.C. et al. Graphical Structured-Editing of
Multimedia Documents with Temporal and Spatial Constraints. IV
Multimedia Modeling Conference - MMM’97, Cingapura, Cingapura,
Novembro de 1997.
MUCHALUAT-SAADE, D.C.; RODRIGUES, R.F.; SOARES L.F.G. WWW
Fisheye-View Graphical Browser. V Multimedia Modeling Conference MMM98, Lausanne, Suiça, Outubro de 1998, p. 80-89.
MUCHALUAT-SAADE, D.C.; RODRIGUES, R.F.; SOARES L.F.G.
XConnector: Extending XLink to Provide Multimedia Synchronization.
II ACM Symposium on Document Engineering – DocEng’2002, McLean,
EUA, Novembro de 2002, p. 49-56.
MUCHALUAT-SAADE, D.C.; SOARES, L.F.G. Hypermedia Spatio-Temporal
Synchronization Relations Also Deserve First Class Status. VIII
Multimedia Modeling Conference - MMM2001, Amsterdam, Holanda,
Novembro de 2001, p. 73-90.
NETSCAPE Communications Corporation. Plug-in Guide. 1998. Disponível em
http://developer.netscape.com/docs/manuals/communicator/plugin/index.htm.
Acesso em 2 jul. 2003.
OHTO, H.; HJELM, J. CC/PP exchange protocol based on HTTP extension
framework. W3C Note, 1999.
OLIVEIRA, J.C. TVS: Um Sistema de Videoconferência. Dissertação de
Mestrado, Departamento de Informática, PUC-Rio, Rio de Janeiro, Brasil,
Agosto de 1996.
ORATRIX. GRiNS Pro Editor for SMIL 2.0: Reference Manual. Oratrix
Development, Fevereiro de 2002.
OREN, N. A Survey of Prefetching Techniques. Relatório Técnico, Julho de
2000. Disponível em http://citeseer.nj.nec.com/334350.html. Acesso em 2
jul. 2003.
Referências
153
PÉREZ-LUQUE, M.J.; LITTLE, T.D.C. A Temporal Reference Framework for
Multimedia Synchronization. IEEE Journal on Selected Areas in
Communications (Special Issue: Synchronization Issues in Multimedia
Communication), v. 14, n. 1, Janeiro de 1996, p. 36-51.
REVEL, D. et al. An Architecture for Flexible Multimedia Prefetching.
Workshop on Resource Allocation Problems in Multimedia Systems,
Washington DC, EUA, Novembro de 1996.
RODRIGUES, L.M. et al. Improving SMIL Documents with NCM Facilities.
VI Multimedia Modeling Conference - MMM99, Ottawa, Canadá, Outubro
de 1999, p. 19-38.
RODRIGUES, L.M. Integração de Documentos SMIL ao Sistema HyperProp
e Desenvolvimento de Ferramentas para Exibição de Objetos com
Relacionamentos de Sincronização. Dissertação de Mestrado,
Departamento de Informática, PUC-Rio, Rio de Janeiro, Brasil, Novembro
de 2000.
RODRIGUES, L.M. et al. Improving SMIL with NCM Facilities. Journal of
Multimedia Tools and Applications, Kluwer Academic Publishers, v. 16, n.
1, Janeiro de 2002, p. 29-54.
RODRIGUES, R.F. Documentação Eletrônica (Javadoc) da Implementação na
Linguagem Java do Modelo de Execução Hipermídia, Relatório Técnico,
Laboratório TeleMídia, PUC-Rio, Rio de Janeiro, Março de 2003.
Disponível em http://www.telemidia.puc-rio.br. Acesso em 2 jul. 2003.
RODRIGUES, R.F.; RODRIGUES, L.M.; SOARES, L.F.G. A Framework for
Event-Driven Hypermedia Presentation Systems. VIII Multimedia
Modeling Conference - MMM’2001, Amsterdam, Holanda, Novembro de
2001, p. 169-185.
RODRIGUES, R.F.; SOARES, L.F.G. Integração dos Sistemas HyperProp e
WWW, IV Simpósio Brasileiro em Sistemas Multimídia e Hipermídia SBMídia’98, Rio de Janeiro. Maio de 1998, p. 175-186.
RODRIGUES, R.F.; SOARES, L.F.G. A Framework for Prefetching
Mechanisms in Hypermedia Presentations. IEEE 4th International
Symposium on Multimedia Software Engineering, Newport Beach, EUA,
Dezembro de 2002.
RODRIGUES, R.F.; SOUZA, G.L.; SOARES, L.F.G. Authoring and
Formatting of Documents Based on Event-Driven Hypermedia Models.
IEEE International Conference on Protocols for Multimedia Systems and
Multimedia Networking - Proms-MmNet’97, Santiago, Chile, Novembro de
1997, p.74-83.
RUMBAUGH, J.; JACOBSON, I.; BOOCH, G. The Unified Modeling
Language: Reference Manual. Addison-Wesley, 1999.
Referências
154
SABRY-ISMAIL, L.; LAYAÏDA, N.; ROISIN, C. Dealing with uncertain
durations in synchronized multimedia presentations. Multimedia Tools
and Applications Journal, Kluwer Academic Publishers, 1999.
SANTOS, C. et al. Design Methodology and Formal Validation of
Hypermedia Documents. ACM Multimedia 98, Bristol, Inglaterra, Outubro
de 1998.
SANTOS, C. et al. Formal Specification and Verification of Hypermedia
Documents based on the Nested Context Model. V Multimedia Modeling
Conference - MMM98, Lausanne, Suiça, Outubro de 1998.
SCHILIT, B.; ADAMS, N.; WANT, R. Context-aware computing applications.
IEEE Workshop on Mobile Computing Systems and Applications, Santa
Cruz, EUA, Dezembro de 1994, p. 85-90.
SMILGen. RealNetworks, 2002. Disponível em http://www.smilgen.org. Acesso
em 2 jul. 2003.
SOARES, L.F.G. et al. Versões de Representação em Modelos com
Composições Aninhadas. IV Simpósio Brasileiro de Sistemas Multimídia e
Hipermídia – SBMídia’98, Rio de Janeiro, Brasil, Maio de 1998, p. 225236.
SOARES, L.F.G. et al. Propagação e Proliferação de Versões em Modelos
Conceituais Hipermídia com Composições. Simpósio Brasileiro de Banco
de Dados – SBBD’98, Maringá, Brasil, Outubro de 1998, p. 351-365.
SOARES, L.F.G. et al. Versioning Support in the HyperProp System. Journal
of Multimedia Tools and Applications, v. 8, n. 3, Kluwer Academics, Maio
de 1999, p. 325-339.
SOARES, L.F.G.; CASANOVA, M.A.; RODRIGUEZ, N.L.R. Nested Composite
Nodes and Version Control in an Open Hypermedia System. IEEE
Transaction on Information Systems, v. 20, n. 6, Elsevier Science Ltd, GrãBretanha, 1995, p. 501-519.
SOARES, L.F.G.; RODRIGUES, R.F.; MUCHALUAT-SAADE, D.C. Authoring
and Formatting Hypermedia Documents in the HyperProp System.
ACM Multimedia Systems Journal, v. 8, n. 2, Springer-Verlag, Março de
2000, p. 118-134.
SOARES, L.F.G.; RODRIGUES, R.F.; MUCHALUAT-SAADE, D.C. Modelo de
Contextos Aninhados – versão 2.3. Relatório Técnico, Laboratório
TeleMídia,
PUC-Rio,
Março
de
2003.
Disponível
em
http://www.telemidia.puc-rio.br. Acesso em 2 jul. 2003.
SOUZA, G.L. Sincronismo na Modelagem e Execução de Apresentações de
Documentos Multimidia. Tese de Doutorado, Departamento de
Informática, PUC-Rio, Rio de Janeiro, Brasil, Setembro de 1997.
Referências
155
SUN Microsystems. Java Media Framework, v2.0 API Specification. 1999.
Disponível em http://java.sun.com/products/java-media/jmf/. Acesso 2 jul.
2003.
VAN ROSSUM, G. et al. CMIFed: A Presentation Environment for Portable
Hypermedia Documents. ACM Multimedia’93, Anaheim, EUA, Agosto de
1993.
VAZIRGIANNIS, M. Interactive Multimedia Documents. Lecture Notes in
Computer Science, n.1564, Springer-Verlag, 1999.
VAZIRGIANNIS, M.; MOURLAS, C. An Object Oriented Model for
Interactive Multimedia Applications. The Computer Journal, v. 36, n. 1,
British Computer Society, Janeiro de 1993.
VILLARD, L.; ROISIN, C.; LAYAÏDA, N. An XML-based multimedia
document processing model for content adaptation. VIII International
Conference on Digital Documents and Electronic Publishing, Setembro de
2000.
W3C - World-Wide Web Consortium. Cascading Style Sheets, level 1. W3C
Recommendation, Dezembro de 1996.
W3C - World-Wide Web Consortium. Cascading Style Sheets, level 2. W3C
Recommendation, Maio de 1998.
W3C - World-Wide Web Consortium. Synchronized Multimedia Integration
Language (SMIL) 1.0 Specification. W3C Recommendation, Junho de
1998.
W3C - World-Wide Web Consortium. Composite Capability/Preference
Profiles (CC/PP): A user side framework for content negotiation. W3C
Note, Junho de 1999.
W3C - World-Wide Web Consortium. Resource Description Framework
(RDF) Model and Syntax Specification. W3C Recommendation,
Fevereiro de 1999.
W3C - World-Wide Web Consortium. HyperText Markup Language (HTML)
4.01. W3C Recommendation, Dezembro de 1999. Disponível em
http://www.w3.org/TR/html4/. Acesso em 2 jul. 2003.
W3C - World-Wide Web Consortium. Extensible Markup Language (XML)
1.0 – (Second Edition). W3C Recommendation, Outubro de 2000.
Disponível em http://www.w3c.org/TR/2000/REC-xml-20001006. Acesso
em 2 jul. 2003.
W3C - World-Wide Web Consortium. Synchronized Multimedia Integration
Language (SMIL 2.0) Specification. W3C Recommendation, Agosto de
2001. Disponível em http://www.w3.org/TR/smil20. Acesso em 2 jul. 2003.
Referências
156
W3C - World-Wide Web Consortium. XHTML+SMIL Profile. W3C Working
Draft, Agosto de 2001. Disponível em http://www.w3.org/TR/2001/WDXHTMLplusSMIL-20010807/. Acesso em 2 jul. 2003.
WILLRICH, R. et al. Towards Hypermedia Documents Design. XIV Simpósio
Brasileiro em Redes de Computadores, Fortaleza, Brasil, Maio de 1996, p.
473-491.
WOLF, L. et al. Issues of Reserving Resources in Advance. Proc. 5th
International Workshop on Network and Operating System Support for
Digital Audio and Video, Abril de 1995.

Rogério Ferreira Rodrigues Formatação e Controle de

Transcrição

Documentos relacionados

Ativar modo de compatibilidade IE9 e IE10

Modo de Compatibilidade no Internet Explorer 10

Pocahontas

Artes do Pop tem espaÃ§o na Semana Cultural Brasil

o labirinto da elfa: produção de um game didático para o ensino

Nos bastidores:

TV Digital Interativa

Tablet - Conahpa - Universidade Federal de Santa Catarina

Criação do Módulo Web para Suporte ao Guri: Software de Autoria

Transporte ainda mais flexível