Rodrigo Laiola Guimarães
Composer: um ambiente de
autoria de documentos NCL
para TV digital interativa
DISSERTAÇÃO DE MESTRADO
DEPARTAMENTO DE INFORMÁTICA
Programa de Pós-Graduação em Informática
Rio de Janeiro, junho de 2007
Rodrigo Laiola Guimarães
Composer: um ambiente de
autoria de documentos NCL
para TV digital interativa
Dissertação de Mestrado
Dissertação apresentada ao Programa de Pósgraduação em Informática da PUC-Rio como
requisito parcial para obtenção do título de Mestre
em Informática.
Orientador: Luiz Fernando Gomes Soares
Rio de Janeiro
Junho de 2007
Rodrigo Laiola Guimarães
Composer: um ambiente de
autoria de documentos NCL
para TV digital interativa
Dissertação apresentada como requisito parcial para
obtenção do título de Mestre pelo Programa de PósGraduação em Informática da PUC-Rio. Aprovada pela
Comissão Examinadora abaixo assinada.
Prof. Luiz Fernando Gomes Soares
Orientador
Departamento de Informática - PUC-Rio
Prof. Rogério Ferreira Rodrigues
Departamento de Informática - PUC-Rio
Prof. Simone Diniz Junqueira Barbosa
Departamento de Informática - PUC-Rio
Prof. José Eugenio Leal
Coordenador Setorial do Centro
Técnico Científico - PUC-Rio
Rio de Janeiro, 13 de junho de 2007
Todos os direitos reservados. É proibida a reprodução total
ou parcial do trabalho sem autorização da universidade, do
autor e do orientador.
Rodrigo Laiola Guimarães
Graduado em Engenharia de Computação pela
Universidade Federal do Espírito Santo (UFES) em 2004.
Atualmente, integra o grupo de pesquisadores do
Laboratório TeleMídia da PUC-Rio, desenvolvendo
pesquisa na área de Sistemas Hipermídia.
Ficha Catalográfica
Guimarães, Rodrigo Laiola
Composer: um ambiente de autoria de documentos
NCL para TV digital interativa / Rodrigo Laiola Guimarães;
orientador: Luiz Fernando Gomes Soares. – Rio de
Janeiro: PUC, Departamento de Informática, 2007.
v., 106 f.: il. ; 29,7 cm
1. Dissertação (mestrado) – Pontifícia Universidade
Católica do Rio de Janeiro, Departamento de Informática.
Incluí referências bibliográficas.
1. Informática – Teses. 2. Ferramentas de autoria. 3.
Interatividade. 4. Sincronismo. 5. TV digital. 6. NCL. I.
Soares, Luiz Fernando Gomes. II. Pontifícia Universidade
Católica do Rio de Janeiro. Departamento de Informática.
III. Título
CDD: 004
Este trabalho é dedicado aos
meus pais Célia e Antônio, e as
minhas irmãs Rafaela e
Roberta.
A toda Família Laiola e
Guimarães (Queridos avós, tios
e primos).
“A todos àqueles que acreditam
que a ousadia e o erro são
caminhos para as grandes
realizações”.
Agradecimentos
Agradeço à minha família pelo incentivo e pela compreensão durante toda minha
vida e trajetória acadêmica.
Aos professores da Universidade Federal do Espírito Santo (UFES) por minha
formação na graduação, sem a qual não teria chegado até aqui. Em especial ao
professor Flávio Miguel Varejão por sempre ter acreditado no meu potencial.
Minha sincera gratidão e admiração pelo meu orientador Luiz Fernando Gomes
Soares por sua tamanha dedicação e incessante esforço em me ajudar durante o
desenvolvimento deste trabalho de pesquisa científica.
Aos meus colegas do TeleMídia pelo companheirismo e ajuda prestados. Em
especial ao Rogério, ao Rogerinho (Jr.) e ao Romualdo pela atenção, paciência e
boa vontade em ensinar, tendo sido guias para o desenvolvimento deste trabalho.
Ao Rafael Savignon pela ajuda na visão estrutural, ao Márcio Bolinha pela ajuda
na edição ao vivo, ao Carlão pelas discussões sobre NCL e ao Moreno por manter
a rede funcionando.
Ao Rodrigo Pernambucano, Marcelo Malcher, Jordan Janeiro, Rafael Lambão e
Vinícius Fontes pela amizade e momentos de descontração.
À equipe do SERG pela ajuda na interface gráfica e no módulo de ajuda do
Composer. Em especial a Simone, Carol, Ariane e Eurico.
Agradeço a todos os funcionários e alunos da PUC-Rio pela boa convivência que
tivemos durante estes 2 (dois) anos.
Aos meus companheiros da República Les Misérables, André Fialho (Tião), Dany
Boy (Daniel Xavier) e Renato (Caculé) pela boa convivência durante este período.
À Dona Inês, minha lavadeira, e ao porteiro Gilberto.
Ao oráculo (Google) por me ajudar com as referências e trabalhos relacionados.
À CAPES, ao CNPq e ao TeleMídia pelo apoio financeiro.
Acima de tudo e todos, agradeço a Deus por sempre ter iluminado meu caminho.
Resumo
Guimarães, Rodrigo Laiola; Soares, Luiz Fernando Gomes (Orientador).
Composer: um ambiente de autoria de documentos NCL para TV
digital interativa. Rio de Janeiro, 2007. 106p. Dissertação de Mestrado Departamento de Informática, Pontifícia Universidade Católica do Rio de
Janeiro.
Com o advento da adoção de um padrão de TV digital interativa pelo Brasil,
tem crescido o interesse pela análise das possíveis alternativas nas mais diversas
áreas que compõem um sistema de TV digital. No caso do Brasil, NCL é a
linguagem declarativa adotada para modelagem de aplicações interativas no
Sistema Brasileiro de TV Digital Terrestre (ISDTV-T – International System for
Digital TV). Nesse contexto, este trabalho apresenta a ferramenta Composer, um
ambiente de autoria voltado para a criação de programas NCL para TV digital
interativa. Da mesma forma como no editor HyperProp, no qual é baseado, no
Composer as abstrações são definidas nos diversos tipos de visões que permitem
simular um tipo específico de edição (estrutural, temporal, leiaute e textual). Essas
visões funcionam de maneira sincronizada, a fim de oferecer um ambiente
integrado de autoria. Além de ter sua interface gráfica e funcional remodelada,
principalmente a visão temporal, problemas de representação e edição de objetos
de mídia, relacionamentos de sincronismo entre objetos, dentre eles os
relacionamentos interativos, e edição ao vivo são tratados. Em resumo, o sistema
proposto visa facilitar e agilizar a criação de aplicações voltadas para TV digital
abstraindo do autor toda, ou pelo menos parte da complexidade de se programar
em NCL através desse ambiente de autoria.
Palavras-chave
Ferramentas de autoria; Interatividade; Sincronismo; TV digital; NCL
Abstract
Guimarães, Rodrigo Laiola; Soares, Luiz Fernando Gomes (Advisor).
Composer: an authoring tool of NCL documents for interactive digital
TV. Rio de Janeiro, 2007. 106p. MSc. Dissertation - Departamento de
Informática, Pontifícia Universidade Católica do Rio de Janeiro.
With the advent of adoption of an interactive digital TV standard by the
Brazilian government, the interest for the analysis of possible alternatives in
several areas that compose a digital TV system has increased. In the case of
Brazil, NCL is the declarative language adopted for modeling interactive
applications in the Brazilian Terrestrial Digital TV System (ISDTV-T –
International System for Digital TV). In that context, this work presents
Composer, an authoring tool to create NCL documents for interactive digital TV.
In the same way that in the HyperProp editor, in which it is based, in Composer
the abstractions are defined using views that allow to simulate a specific type of
edition (structural, temporal, layout and textual). Those visions work in a
synchronized way, in order to offer an integrated authoring tool. Besides having
the user and the functional interface remodeled, mainly its temporal view,
problems of representation and edition of media objects, relationship problems,
amongst then the interactive relationships, and live edition are treated. In
summary, the proposed system tries to make easier the creation of documents for
digital TV abstracting from the author all, or at least some complexity of
programming in NCL using this authoring tool.
Keywords
Authoring tools; Interactivity; Synchronism; Digital TV; NCL
Sumário
1 Introdução
13
1.1. Motivação
13
1.2. Objetivos
16
1.3. Estrutura da Dissertação
17
2 Trabalhos Relacionados
18
2.1. JAME Author
18
2.2. Cardinal Studio
21
2.3. AltiComposer
24
2.4. GRiNS
28
2.5. LimSee2
31
2.6. Macromedia Flash
32
2.7. Análise Comparativa
34
3 Autoria em NCL para TV digital interativa
36
3.1. Arquitetura do Composer
37
3.2. Sincronismo Temporal
40
3.2.1. Modelo de Grafo de Cadeias Temporais Hipermídia
41
3.3. Edição ao Vivo
50
4 Implementação
52
4.1. Interface Gráfica
52
4.1.1. Módulo de Localização
54
4.1.2. Enhanced Items
55
4.2. Suporte ao Usuário
56
4.2.1. Módulo de Preferências
57
4.2.2. Módulo de Mensagens
57
4.2.3. Módulo de log
58
4.2.4. Módulo de Ajuda
58
4.3. Visões
59
4.3.1. Visão estrutural
59
4.3.2. Visão de leiaute
61
4.3.3. Visão textual
63
4.3.4. Visão temporal
65
4.3.5. Sincronização entre visões
72
4.4. Módulo de Edição ao Vivo
73
5 Conclusões
77
5.1. Análise Comparativa
78
5.2. Trabalhos Futuros
80
6 Referências Bibliográficas
84
A
91
Linguagens, Sincronismo e Interatividade
A.1. Linguagens nos padrões de TV digital
91
A.1.1. Linguagens baseadas em Java
91
A.1.2. Linguagens baseadas em HTML
96
A.2. Linguagens Declarativas
101
A.2.1. Sincronismo e Interatividade nas linguagens declarativas
102
Lista de figuras
Figura 1 - Interface gráfica do JAME Author (Fraunhofer, 2007c)
19
Figura 2 - Transferência de foco no JAME Author (Fraunhofer, 2007b) 21
Figura 3 - Interface gráfica do Cardinal Studio
23
Figura 4 - Arquitetura de componentes do AltiComposer (Alticast, 2007c)
25
Figura 5 - Modelo de autoria do AltiComposer (Alticast, 2007c)
26
Figura 6 - Interface gráfica do AltiComposer
27
Figura 7 - Visão temporal do GRiNS
28
Figura 8 - Visão espacial do GRiNS
29
Figura 9 - Visão textual do GRiNS
30
Figura 10 - Interface gráfica do LimSee2
31
Figura 11 - Interface gráfica do Macromedia Flash
33
Figura 12 - Visões do Composer
37
Figura 13 - Integração entre visões no Composer
39
Figura 14 - Evento de apresentação no modelo de cadeias temporais
hipermídia
43
Figura 15 - Relacionamentos causais no modelo de cadeias temporais
hipermídia
45
Figura 16 - Interatividade no modelo de cadeias temporais hipermídia
46
Figura 17 - Pausa no modelo de cadeias temporais hipermídia
48
Figura 18 - Diagrama de classes da interface gráfica do Composer
53
Figura 19 - Interface gráfica do Composer
54
Figura 20 - Barra de menus e barra de ferramentas do Composer
54
Figura 21 - Configuração de um Enhanced Item
56
Figura 22 - Visão estrutural do Composer
60
Figura 23 - Visão de leiaute do Composer
62
Figura 24 - Visão textual do Composer
63
Figura 25 - Diagrama de classes da visão temporal
65
Figura 26 - Visão temporal do Composer
67
Figura 27 - Especificação de relacionamentos temporais na visão
temporal
68
Figura 28 - Especificação de relacionamentos interativos na visão
temporal
69
Figura 29 - Simulação de eventos interativos
71
Figura 30 - Diagrama de classes do mediador no Composer
73
Figura 31 - Comandos de edição ao vivo no Composer
75
Figura 32 - Edição de relacionamentos espaciais no Composer
82
Figura 33 - Ciclo de vida de um Xlet
93
Figura 34 - Exemplo do controle de eventos no DVB-J
96
Figura 35 - Ciclo de vida de uma aplicação DVB-HTML
98
Figura 36 - Exemplo de chamada de aplicativo DVB-J no DVB-HTML
99
Figura 37 - Tratamento de stream events no DVB-HTML
100
Figura 38 - Elo de interatividade no DVB-HTML
100
Figura 39 - Proposta de uma arquitetura SMIL para TV digital
105
Figura 40 - Gerenciamento de Xlets contendo interpretadores SMIL
106
Lista de tabelas
Tabela 1 - Análise comparativa entre ferramentas de autoria
34
1
Introdução
Com o advento da adoção de um padrão de TV digital interativa pelo Brasil,
tem crescido o interesse pela análise das possíveis alternativas nas mais diversas
áreas que compõem um sistema de TV digital.
Este capítulo descreve as motivações e os objetivos desta dissertação, a qual
é focada em um ambiente de autoria de aplicações para TV digital. O capítulo
também apresenta a estrutura do restante deste documento.
1.1.
Motivação
Aplicações para TV digital são casos particulares de aplicações
multimídia/hipermídia e devem lidar com a sincronização espacial e temporal de
objetos de diferentes tipos de mídia, além dos objetos de vídeo e áudio que
compõem o fluxo principal.
Em um sistema de TV digital, a capacidade de difusão de informação em
várias mídias diferentes, tais como o áudio principal, o vídeo principal e outros
dados (como texto, imagens e outros vídeos e áudios), faz com que esse ambiente
possa oferecer diversos tipos de serviços, desde a simples distribuição de
conteúdo áudio-visual da programação atual da TV analógica por difusão, até
serviços antes não disponíveis, com o destaque para os serviços interativos.
Muitas vezes, o sincronismo existente nesses documentos (aplicações) é
baseado em eventos onde o tempo e local de suas ocorrências não são exatamente
previstos. A interatividade e a edição ao vivo são exemplos de eventos
imprevisíveis, onde a interação do usuário telespectador ou do autor,
respectivamente, pode dar início a um outro evento. Documentos multimídia onde
é possível estabelecer o sincronismo entre a interação do usuário e outros objetos
que compõem o documento são usualmente denominados documentos hipermídia.
Mais recentemente, no contexto de TV digital, a mesma analogia pode ser
Introdução
14
postergada para a edição ao vivo, neste caso devido à interação do autor em tempo
de apresentação.
Os principais padrões de TV digital (Soares et al., 2004) oferecem
linguagens para a especificação da interatividade e do sincronismo nas aplicações.
Essas aplicações, usualmente classificadas em procedurais e de marcação, são
concebidas, em sua maioria, por linguagens baseadas em Java (Sun, 1994) e
HTML (HyperText Markup Language) (W3C, 1999a), respectivamente1.
Aplicações desenvolvidas em Java são criadas a partir de um conjunto de
classes (pacotes) oferecidas pelo middleware (elemento capaz de fornecer uma
abstração do sistema para as aplicações e os usuários, escondendo toda a
complexidade dos mecanismos definidos pelos padrões, protocolos de
comunicação e até mesmo do sistema operacional instalado no terminal de acesso
- set-top box). Para desenvolver essas aplicações, é necessário que o autor conheça
as funcionalidades das classes do middleware. Além disso, também é necessário
que o autor possua conhecimentos de programação e orientação a objeto, como
encapsulamento, herança, polimorfismo, etc.
Complementarmente, as aplicações desenvolvidas em HTML (na verdade
XHTML - eXtensible HyperText Markup Language (Pemberton et al., 2002), a
princípio, favorecem a autoria ao permitir a especificação das aplicações através
de marcações XML (eXtensible Markup Language) (W3C, 2004a). No entanto, a
aplicabilidade do HTML restringe-se à formatação da apresentação e à definição
de relações de referência entre documentos. Para aplicações mais elaboradas,
incluindo o sincronismo e outros tipos de interatividade, são utilizadas
adicionalmente linguagens baseadas em script. Essas linguagens definem
estruturas de controle, variáveis e procedimentos que podem, eventualmente,
acessar funções oferecidas pelo middleware.
Além das linguagens Java e HTML, as especificações de relacionamentos
entre eventos de objetos de mídia podem ser feitas por linguagens declarativas, as
quais têm como foco principal a descrição de tais relacionamentos. Nessas
linguagens, as relações entre eventos podem ser especificadas sem que seja
1
Nesse caso, as nomenclaturas das aplicações não correspondem às classes das linguagens
utilizadas para a concepção. A linguagem Java é destinada à criação de aplicações orientadas a
objeto, enquanto HTML é voltada para a formatação de documentos.
Introdução
15
necessário definir estruturas complexas, como estruturas de controle, de repetição,
variáveis, observadores etc., favorecendo assim o processo de autoria.
Atualmente, linguagens declarativas, que não as linguagens só de marcação,
não são encontradas nos padrões de TV digital. No entanto, essas linguagens são
amplamente difundidas para a modelagem de aplicações multimídia/hipermídia,
com destaque para as linguagens SMIL (Bulterman & Rutledge, 2004) e NCL
(Muchaluat-Saade et al., 2003).
A linguagem SMIL (Synchronized Multimedia Integration Language) é uma
linguagem bastante intuitiva para o desenvolvimento de apresentações, pois nela é
possível definir de forma simples como os objetos de mídia estarão dispostos no
tempo através de um conjunto básico de composições que possuem semântica de
sincronização.
A NCL (Nested Context Language) é uma linguagem para autoria de
documentos hipermídia baseada no modelo conceitual NCM (Nested Context
Model) (Soares et al., 2003). No modelo NCM um documento hipermídia é
representado por um nó de composição, podendo este conter um conjunto de nós,
que podem ser objetos de mídia ou outros nós de composição, recursivamente, e
ainda elos relacionando esses nós.
Nós de composição no modelo NCM não têm nenhuma semântica embutida,
diferente das composições SMIL que, por exemplo, têm semântica temporal. A
semântica dos relacionamentos entre os componentes de um documento é feita
através dos elos NCM, que podem especificar, por exemplo, relações de
sincronização. Elos NCM são definidos fazendo referência a um conector
hipermídia que pode representar qualquer tipo de relação. Além da referência a
um conector, um elo define um conjunto de binds (associações) mapeando papéis
do conector a nós do documento.
Considerando a complexidade das linguagens baseadas em Java e em
HTML + script para a especificação de aplicações para TV digital, o uso de
ferramentas para autoria gráfica faz-se muito importante. Como a linguagem Java
e as linguagens de script possuem várias características de linguagens de propósito
geral, as ferramentas de autoria para essas linguagens devem suportar os recursos
oferecidos pelas linguagens e, simultaneamente, criar abstrações para o
desenvolvimento de aplicações voltadas para TV digital. Nesse aspecto, nota-se
uma tendência em definir estruturas auxiliares para ajudar no desenvolvimento
Introdução
16
mental do autor na criação, abstraindo as estruturas originais das linguagens. A
mesma observação pode ser considerada quando o que está em foco são as
linguagens declarativas.
Existem diversas ferramentas de autoria para TV digital. Alguns exemplos
são: JAME Author (Fraunhofer, 2007a), Cardinal Studio (Cardinal, 2007) e
AltiComposer (Alticast, 2007a) para criação de aplicações procedurais para o
middleware MHP (Multimedia Home Platform - ES 201 812 (ETSI, 2003));
Dreamweaver (Adobe, 2007a) e Microsoft FrontPage (Microsoft, 2007a) para
criação de documentos HTML. Já para as linguagens declarativas, pode-se
destacar o ambiente GRiNS (Bulterman et al., 1998) para SMIL, e o editor
HyperProp (Coelho & Soares, 2004) para criação de aplicações hipermídia em
NCL main profile (Soares et al., 2006), um perfil mais geral dessa linguagem.
No caso do Brasil, NCL é a linguagem declarativa adotada para modelagem
de aplicações interativas no Sistema Brasileiro de TV Digital Terrestre (ISDTV-T
– International System for Digital TV). Nesse contexto, surge a demanda por uma
ferramenta de autoria de documentos NCL nos seus perfis (profiles) para TV
digital (Soares & Rodrigues, 2006).
1.2.
Objetivos
Esta dissertação apresenta a ferramenta Composer, um ambiente de autoria
voltado para a criação de documentos NCL para TV digital interativa. Da mesma
forma que no editor HyperProp, no qual é baseado, no Composer as abstrações
são definidas nos diversos tipos de visões que permitem simular um tipo
específico de edição (estrutural, temporal, leiaute e textual). Essas visões
funcionam de maneira sincronizada, a fim de oferecer um ambiente integrado de
autoria.
O objetivo deste trabalho é remodelar o editor HyperProp, tendo a edição
temporal como principal foco. A intenção é solucionar problemas de
representação e edição de objetos de mídia, relacionamentos de sincronismo entre
objetos, dentre eles os relacionamentos interativos, e edição ao vivo. Este trabalho
contempla também a sincronização da visão temporal com as demais visões do
Introdução
17
ambiente de autoria de modo a fazer que alterações realizadas em uma
determinada visão também sejam refletidas na visão temporal, e vice-versa.
Em resumo, o sistema proposto visa facilitar e agilizar a criação de
aplicações voltadas para TV digital abstraindo do autor toda, ou pelo menos parte
da complexidade de se programar em NCL, através desse ambiente de autoria.
1.3.
Estrutura da Dissertação
Esta dissertação encontra-se organizada como a seguir. O Capítulo 2
apresenta algumas ferramentas de autoria pertinentes ao escopo deste trabalho.
Algumas
dessas
ferramentas
são
voltadas
à
produção
de
conteúdo
multimídia/hipermídia para TV digital interativa, outras não. Nesse capítulo são
analisadas as principais características de cada uma delas.
O Capítulo 3 destaca melhorias do ambiente de autoria Composer com
relação ao editor HyperProp para adequação ao contexto de TV digital interativa.
São apresentados detalhes da estrutura de dados utilizada para representar as
cadeias temporais da visão temporal. Esse capítulo contempla ainda características
da edição ao vivo através do Composer.
O Capítulo 4 foca na implementação dos pontos levantados no Capítulo 3, a
fim de tornar o Composer mais atraente para criação de programas NCL para TV
digital interativa.
Já o Capítulo 5 tece as conclusões, fazendo ainda uma análise comparativa
do Composer com as ferramentas analisadas no Capítulo 2 e o editor HyperProp, e
descrevendo trabalhos futuros. O Capítulo 6 sumariza as referências bibliográficas
utilizadas na elaboração desta dissertação.
Não menos importante, o Apêndice A faz uma discussão sobre os
mecanismos de sincronização e interatividade nos padrões de TV digital, com
destaque para as linguagens utilizadas na especificação desses eventos. Uma parte
específica trata de linguagens declarativas e da possibilidade de uso dessas
linguagens pelos padrões.
2
Trabalhos Relacionados
Ferramentas de autoria podem ser empregadas a fim de abstrair do autor
toda, ou pelo menos parte da complexidade de se utilizar uma linguagem de
programação na criação de aplicações voltadas para TV digital. Através dessas
ferramentas, o autor pode se concentrar, principalmente, no processo de criação.
Para dar suporte a usuários de todos os níveis de expertise, as ferramentas de
autoria devem oferecer os recursos existentes nas linguagens e, simultaneamente,
criar abstrações para facilitar e agilizar o desenvolvimento das aplicações. Nesse
aspecto, nota-se uma tendência em definir estruturas auxiliares. É importante
ressaltar que essas estruturas auxiliares não são necessárias nas linguagens dos
padrões para TV digital, sendo apenas estruturas de apoio ao desenvolvimento. No
caso das ferramentas de autoria para linguagens baseadas em modelos hipermídia,
geralmente, as abstrações são definidas nos diversos tipos de visões, que permitem
simular um tipo específico de edição (temporal, leiaute, estrutural etc.).
Existem diversas ferramentas de autoria para TV digital, e inúmeras outras
para Web (World-Wide Web ou WWW) (Berners-Lee et al., 1994) e linguagens
declarativas. Este capítulo faz uma análise de algumas dessas ferramentas,
levantando suas principais características. Como complemento, o Apêndice A
apresenta informações sobre as linguagens subjacentes às ferramentas de autoria
apresentadas neste capítulo.
2.1.
JAME Author
O JAME Author (Fraunhofer, 2007a) é um ambiente de autoria para a
criação de aplicativos voltados para TV digital interativa no middleware
MHP/OCAP (OpenCable Application Platform) (ETSI, 2003; CableLabs, 2006),
e faz parte de um grupo de soluções para iTV (interactive TV) do Fraunhofer
Institute for Media Communication IMK.
Trabalhos Relacionados
19
Essa ferramenta visa facilitar a criação de programas atendendo a uma
classe especial de aplicativos, chamados de page-based services (serviços
baseados em páginas). Esses aplicativos são compostos por páginas, nas quais é
possível se navegar de maneira muito semelhante à navegação na Web. Essas
páginas são descritas através de uma linguagem chamada JAME PDL (JAME
Page Description Language) (Fraunhofer, 2007c), a qual é baseada em XML.
O JAME Author lida com dois tipos básicos de página. No primeiro tipo, o
funcionamento é similar ao das páginas Web, onde a ativação de um link (elo)
carrega uma nova página, e esta substitui a página corrente. No segundo, é
utilizada sobreposição com transparência, e efeitos mais interessantes podem ser
obtidos.
Todo projeto no JAME Author possui páginas de sistema pré-definidas para,
por exemplo, lidar com tratamento de erro. Durante a elaboração de um projeto
(aplicativo) outras páginas podem ser criadas a fim de caracterizar o tipo de
aplicação que está sendo desenvolvida. A Figura 1 apresenta a interface gráfica do
JAME Author.
Figura 1 - Interface gráfica do JAME Author (Fraunhofer, 2007c)
O Project Manager é a região onde são listadas as páginas de um aplicativo,
e o Page Preview é a região de pré-visualização de uma página selecionada no
Project Manager. Quando um componente de uma página aberta na Work Area é
selecionado, suas propriedades são exibidas na região Property Editor. Além de
serem exibidas, essas propriedades também podem ser editadas. Já a região Layer
Manager lista as camadas suportadas (Graphic, Vídeo e Background Layer, em
Trabalhos Relacionados
20
concordância com o modelo de referência do MHP), e em qual delas cada
componente está.
O processo de edição se dá quando uma página listada no Project Manager
é aberta na Work Area. Existem dois modos de edição: o modo de design e o
modo de navegação.
No modo de design, componentes da barra de componentes (Component
Bar) podem ser selecionados e inseridos na página em edição. Um conjunto
padrão de componentes já vem especificado na ferramenta de autoria, mas outros
componentes podem ser definidos pelo autor como modelos (templates). Tanto os
modelos de componentes quanto os de página podem ser inseridos em um
documento a partir da região Multifunction Field. Essa região funciona tanto
como um repositório de páginas, componentes e figuras, que podem ser inseridos
no projeto em tempo de criação, quanto como uma região informativa onde
mensagens de validação são apresentadas ao usuário.
No modo de navegação, é possível definir a estrutura navegacional intra e
entre páginas. No primeiro caso, a navegação é definida através de regras de
transferência de foco entre componentes. Essas regras definem como a mudança
de foco deve ocorrer quando as teclas do controle remoto forem pressionadas. Um
link de navegação é criado através do arraste do mouse desde o componente
origem até o componente destino. Além dos componentes envolvidos (origem e
destino), é preciso definir também qual a tecla do controle remoto que disparará o
evento de mudança de foco. Como ilustração, a Figura 2 exibe um link que define
a transferência de foco entre os componentes “Menu Item 1” e “Menu Item 2”. O
processo para se definir a navegação entre páginas é semelhante. A diferença é
que o destino deixa de ser um componente e passa a ser uma página.
Trabalhos Relacionados
21
Figura 2 - Transferência de foco no JAME Author (Fraunhofer, 2007b)
Esse ambiente de autoria possui um emulador (simulador) MHP integrado.
Isso permite que o autor execute e valide seu trabalho à medida que esse é
desenvolvido.
Pode ser observado que a criação de documentos hipermídia nessa
ferramenta é similar à criação de documentos HTML, o que vem a facilitar
bastante a sua utilização por usuários não programadores em Java. Entretanto, o
JAME Author não oferece suporte nem à especificação de sincronismo
espacial/temporal entre objetos de mídia, nem a qualquer outra computação em
Java, além das pré-definidas. Basicamente, a interatividade se resume à definição
de relacionamentos de referência entre documentos e à mudança de foco entre
componentes. Ademais, essa ferramenta de autoria não fornece mecanismos para
que seja feita a edição ao vivo de documentos, nem a edição temporal.
2.2.
Cardinal Studio
O Cardinal Studio (Cardinal, 2007) é uma ferramenta de autoria da Cardinal
Systems para a criação de aplicativos de TV digital interativa voltados para o
middleware MHP.
O modelo de autoria do Cardinal Studio tem como abstração de mais alto
nível os “Atos” (Acts). Essas entidades servem para fazer a estruturação de um
aplicativo e podem ser entendidas como cenas.
Os atos são compostos por componentes que podem ser de dois tipos:
visíveis e invisíveis. O primeiro grupo contempla elementos visuais básicos como
Trabalhos Relacionados
22
painéis, áreas de texto e botões. Esse grupo ainda é classificado em componentes
de background e componentes focáveis. Praticamente todos os componentes de
um conjunto possuem um componente equivalente no outro. A diferença é que
componentes focáveis podem ser usados na navegação com o controle remoto,
enquanto os componentes de background não.
Componentes invisíveis, como o próprio nome sugere, não são desenhados
na tela. Esses componentes usualmente são utilizados como estruturas auxiliares
que ajudam a aplicação (documento) a funcionar. Alguns exemplos de
componentes invisíveis são o canal de retorno, uma conexão HTTP (Hypertext
Transfer Protocol) (W3C, 1999b), um stream event (detalhes no Apêndice A), um
botão do controle remoto, entre outros.
Dentro dos atos, os componentes são estruturados em camadas, sendo que
uma camada pode ser compartilhada entre atos. A camada invisível é definida
como um contêiner de componentes invisíveis. Já a camada gráfica é definida
como o local onde ficam os componentes visíveis. A camada de vídeo é definida
como o local para exibição do vídeo especificado pela propriedade Video source.
Caso essa propriedade seja definida como nula, o vídeo principal do canal
corrente é exibido. Finalmente, a camada background exibe um I-frame como
plano de fundo. Cabe ressaltar que dentro de um ato os componentes só podem ser
adicionados de acordo com as características da camada corrente. Como exemplo,
somente componentes invisíveis podem ser inseridos na camada invisível.
No Cardinal Studio, toda interatividade é definida através de eventos
disparados pelos componentes, como, por exemplo, o evento actionPerformed de
um componente focável. Nesse caso, o evento é disparado quando o componente
tem o foco e um botão do controle remoto é pressionado. A ação executada pode
ser personalizada de acordo com as intenções do autor.
A Figura 3 apresenta a interface gráfica do Cardinal Studio. Os números
dentro dos círculos, todos em vermelho, não fazem parte da interface gráfica,
servindo apenas para destacar uma região ou elemento de interesse. Essa notação
será utilizada ao longo de toda a dissertação.
Trabalhos Relacionados
23
Figura 3 - Interface gráfica do Cardinal Studio
Na figura acima, a região 1 (um) é formada pelo editor de eventos e pelo
editor de timeline (linha do tempo), os quais são usados para monitorar eventos e
propriedades de componentes baseados no tempo, respectivamente. Cabe destacar
que o editor de timeline é muito simples, não dando uma noção clara de como a
apresentação decorrerá ao longo do tempo, muito menos permitindo a simulação
de eventos interativos.
A região 2 (dois) da Figura 3, chamada de Canvas, é utilizada para definir
como os componentes estarão espacialmente dispostos na tela. Já a região 3 (três)
exibe a lista de camadas de um ato. Nela é possível adicionar e remover atos e
camadas. A região 4 (quatro) é o local onde são exibidas as propriedades de um
componente selecionado (tanto componentes visíveis quanto invisíveis possuem
propriedades). Por fim, a região 5 (cinco) é um repositório de componentes que
podem ser adicionados ao documento durante o processo de criação.
Esse ambiente de autoria configura automaticamente a navegação entre
componentes focáveis de acordo com a ordem que esses componentes são criados.
Para modificar essa ordem, a ferramenta oferece o modo de navegação. Esse
modo exibe setas de um componente para outro, mostrando como será realizada a
transferência de foco através do controle remoto. Se desejar, o autor tem a
liberdade para definir qual será a seqüência a ser utilizada no seu documento.
O Cardinal Studio dá suporte tanto a usuários avançados quanto a iniciantes.
Para os não-programadores, a ferramenta oferece uma interface de mais alto nível
de abstração, que permite aos autores investirem a maior parte do seu tempo no
Trabalhos Relacionados
24
processo de criação. Por sua vez, usuários avançados podem desenvolver
componentes e integrá-los à ferramenta a fim de estender suas funcionalidades.
Esse ambiente foca principalmente na especificação de eventos interativos.
Contudo, a definição de relacionamentos de sincronismo espacial/temporal entre
objetos de mídia é suportada através da personalização dos eventos dos
componentes, e isso demanda codificação.
O Cardinal Studio não fornece recursos diretos para a edição ao vivo de
documentos, mas permite a especificação de stream events, que podem vir a ser
usados na edição ao vivo (Apêndice A). Por fim, é importante destacar que esse
ambiente de autoria possui um emulador para testar e validar as funcionalidades
dos aplicativos desenvolvidos.
2.3.
AltiComposer
O AltiComposer (Alticast, 2007a) é um ambiente de autoria para criação de
aplicativos em conformidade com o DVB-MHP (Digital Video Broadcast)
(Soares et al., 2004). Essa ferramenta foi desenvolvida para dar suporte tanto a
usuários não-programadores quanto aos que possuem conhecimento de
programação em Java. Para o primeiro grupo, a ferramenta oferece uma interface
gráfica intuitiva e funcional, onde vários recursos podem ser utilizados através do
mouse. Usuários mais avançados, por sua vez, podem criar componentes
personalizados, estendendo a API (Application Programming Interface)
Component Development Kit (CDK) da ferramenta.
Visando tornar o processo de autoria mais intuitivo e atrativo para os
profissionais de TV digital, o ambiente AltiComposer utiliza um modelo definido
em concordância com a industria de TV e cinema. Os componentes existentes e
suas relações de dependência são apresentados na Figura 4.
Nesse modelo, uma cena (Scene) contém planos que podem ser
compartilhados com outras cenas. Um plano (Plane) contém vários shots e atores
(Actors), mas não pode compartilhá-los com outros planos.
Trabalhos Relacionados
25
Figura 4 - Arquitetura de componentes do AltiComposer (Alticast, 2007c)
Na implementação da ferramenta, um ator é um objeto Java que pode ter um
comportamento próprio. Esse comportamento define como o objeto responde, por
exemplo, a uma interação do usuário através do controle remoto. São dois os tipos
de atores: visual e não-visual. Um ator visual atua como um elemento gráfico que
é apresentado ao telespectador, enquanto que um ator não-visual serve para ajudar
os aplicativos a funcionarem devidamente. Caixas de texto e figuras são exemplos
de atores visuais, enquanto que a abstração de um botão do controle remoto é um
exemplo de ator não-visual.
O Shot é a unidade básica na qual os usuários podem navegar no conteúdo
interativo. Pode-se entendê-lo como sendo um contêiner de atores. Em um dado
instante de tempo, um shot é visto como um snapshot (uma foto) da aplicação.
O plano é a unidade básica para salvar e carregar conteúdo para
apresentação. Já a cena é a unidade básica para se fazer a pré-carga de conteúdo
para apresentação. Dessa forma, todos os atores, shots e planos são carregados
junto à cena, antes do aplicativo ser iniciado.
O modelo de autoria dessa ferramenta define, além da arquitetura de
componentes apresentada, um comportamento (behavior). O nome desse behavior
é definido pelo elemento ao qual ele está associado, como por exemplo, o Actor
Behavior, que está associado a um ator. O comportamento é um script que diz
como cada componente deve responder a um determinado evento. A Figura 5
exibe o modelo de autoria do AltiComposer.
Trabalhos Relacionados
26
Figura 5 - Modelo de autoria do AltiComposer (Alticast, 2007c)
Um efeito (effect) é um objeto Java que leva um ator de um estado para
outro. Basicamente, efeitos são usados para mudar propriedades ou a aparência
visual de um ator. Uma transição de shot (shot transition) é um recurso
geralmente usado para dar um efeito visual mais interessante a um aplicativo. É
possível definir qual o tipo e quanto tempo durará a transição.
Efeitos e transições podem ser vistos como recursos, ou behaviors, que
estão prontos para serem usados. Não obstante, behaviors podem ser editados
(codificados) em tempo de criação para realizar uma operação desejada. Essa
codificação é facilitada pelo uso de uma janela (Script Editor) que exibe através
de sua interface gráfica as opções que podem ser utilizadas, permitindo a geração
de código em mais alto nível. A linguagem de programação utilizada é a
AltiComposer Script Language (Alticast, 2007b), um subconjunto da ECMA-262
(ECMA, 1999). Assim, usuários avançados podem programar de forma mais
específica, tirando o máximo de proveito do modelo da ferramenta.
A Figura 6 exibe a interface gráfica do ambiente AltiComposer. A região 1
(um) é conhecida como Project Window (Janela de Projeto). Do seu lado esquerdo
são listadas hierarquicamente as cenas e planos. Na parte inferior direita são
listados os shots de um plano, e se um deles for selecionado, seus atores são
mostrados na região acima (superior à direita da região 1). A região 2 (dois)
representa a Library Window, um repositório de recursos que podem ser utilizados
durante a elaboração de um aplicativo.
Trabalhos Relacionados
27
Figura 6 - Interface gráfica do AltiComposer
Ainda com relação à Figura 6, a região 3 (três), conhecida como Stage,
serve como área de trabalho para criação do aplicativo. A região 4 (quatro), por
sua vez, é a janela de propriedades, onde um elemento selecionado na área de
trabalho pode ter suas propriedades editadas. Por fim, a região 5 (cinco)
representa a janela de transição, na qual pode ser definida e visualizada a transição
de shots. O AltiComposer não fornece uma edição na linha do tempo, na qual seja
possível especificar e verificar a disposição de objetos de mídia no tempo.
Nessa ferramenta, a sincronização temporal e espacial são contempladas
através da codificação do behavior de um determinado componente. Já a
interatividade é definida através da utilização de componentes que representam os
botões do controle remoto, e da especificação de seus behaviors.
Assim como no Cardinal Studio, no AltiComposer não são oferecidos
mecanismos para a edição ao vivo de documentos, mas esse ambiente prevê a
especificação de stream events, os quais podem vir a ser utilizados para edição ao
vivo (Apêndice A). Vale ainda ressaltar que esse ambiente de autoria possui um
emulador MHP que permite que o autor depure seu trabalho à medida que esse é
desenvolvido.
Trabalhos Relacionados
28
2.4.
GRiNS
Uma forma de eximir o autor da necessidade de conhecer profundamente a
linguagem SMIL é a utilização de uma ferramenta de autoria durante o processo
de criação. O GRiNS (Bulterman et al., 1998) é um ambiente de autoria para
SMIL que possui várias visões integradas (temporal, espacial e textual), se
destacando por sua visão temporal para concepção de documentos. A abordagem
de visões será discutida no próximo capítulo, na apresentação da arquitetura do
Composer. Neste ponto, pode-se considerar uma visão como uma abstração que
permite visualizar um programa hipermídia sob uma determinada perpectiva,
como por exemplo, a linha do tempo.
Na visão temporal é possível montar e manipular a apresentação de um
documento multimídia no decorrer do tempo de forma bastante intuitiva.
Diferentemente da edição na linha do tempo normal, o paradigma de linha do
tempo estruturado (structured timeline) exibe composições estruturadas que
definem as relações lógicas entre os objetos de mídia. Todas as composições com
semântica temporal do SMIL são exibidas em cores diferentes na visão temporal,
e isso permite ao autor identificar facilmente de qual tipo se trata. A Figura 7
apresenta a visão temporal do GRiNS.
Figura 7 - Visão temporal do GRiNS
A visão espacial tem por objetivo fornecer ao autor um modo prático e ágil
de criar e manipular as regiões nas quais os objetos de mídia serão apresentados
no espaço. Por permitir apenas a especificação inicial das regiões, essa visão
Trabalhos Relacionados
29
poderia ser chamada de visão de leiaute2. A Figura 8 apresenta a visão espacial do
GRiNS.
Figura 8 - Visão espacial do GRiNS
Na figura acima, a região 1 (um) exibe uma árvore que lista
hierarquicamente as regiões definidas, e os objetos de mídia que serão exibidos
em cada uma delas. Já a região 2 (dois) representa o espaço onde o autor pode
definir e manipular graficamente as regiões. Como propriedades importantes que
precisam ser definidas nessa visão, pode-se citar o z-index, as coordenadas
espaciais e o tipo de ajuste da mídia à região. Nessa última propriedade, os
possíveis valores são meet e fill. No primeiro caso, a mídia mantém sua resolução
(tamanho), e se ela for maior que a região somente parte da mídia aparece. Com o
valor “fill”, a mídia se ajusta à área da região.
Mesmo que na maior parte do tempo seja mais fácil trabalhar nas visões
gráficas, editar o código SMIL também pode ser bastante útil. É com essa
intenção que a visão textual do GRiNS permite que o código seja não só
visualizado como também editado, de forma que qualquer alteração nessa visão
seja refletida nas demais.
O editor textual é bem simples, e oferece somente recursos básicos. A
Figura 9 exibe o código fonte de um documento nessa visão. Para que as
modificações feitas possam ser aplicadas nas outras visões, é necessário que o
usuário clique no botão Apply. Caso haja algum erro, o usuário é prontamente
informado, e se optar por desfazer as alterações, deve clicar no botão Revert.
2
Geralmente uma visão espacial permite ao autor visualizar graficamente como os objetos
de mídia estarão dispostos no espaço em um dado instante da apresentação do documento.
Trabalhos Relacionados
30
Figura 9 - Visão textual do GRiNS
Um ponto fraco da visão textual é que somente as composições com
semântica temporal (seq, par e excl) recebem cores de destaque, e isso pode fazer
com que o autor tenha que despender de um maior esforço para identificar o que
está procurando. Uma alternativa interessante a ser trabalhada seria o uso de
filtros de cores que permitissem destacar o foco de interesse do autor de maneira
mais conveniente.
A existência de várias visões permite ao usuário lançar mão das suas
características da forma que mais lhe convém, e se usadas complementarmente,
pode ser explorado o que de melhor existe em cada uma delas.
A existência de um player (exibidor) associado à ferramenta de autoria é de
grande valia, pois, em tempo de criação, é possível ter noção de como está ficando
a apresentação. Isso agiliza o processo de desenvolvimento e diminui
consideravelmente o retrabalho.
Vale destacar que o GRiNS privilegia fortemente a sincronização,
diferentemente do que acontece nas ferramentas de autoria vistas anteriormente.
Por outro lado, quando o assunto é interatividade, é muito mais fácil de se
implementar graficamente naquelas ferramentas. No GRiNS, a especificação de
relacionamentos interativos é mais fácil na visão textual. Dado que a
interatividade é um requisito importante a ser atendido em sistemas de TV digital
interativa, uma alternativa seria incorporar uma nova visão que permitisse definir
relacionamentos interativos de forma mais intuitiva.
É importante ressaltar ainda que a linguagem SMIL, e conseqüentemente o
GRiNS, não fornece suporte à edição ao vivo (não foi previsto o seu uso para TV
Trabalhos Relacionados
31
digital). Além disso, sua visão temporal não permite a simulação de eventos
interativos em tempo de criação.
2.5.
LimSee2
O LimSee2 (WAM, 2007) é uma ferramenta de autoria para documentos
SMIL desenvolvida pelo grupo de pesquisa WAM (Web Adaptation and
Multimedia) do Institut National de Recherche en Informatique (INRIA).
Assim como o GRiNS, o LimSee2 é um ambiente de autoria com múltiplas
visões integradas, de modo que uma modificação em uma visão é refletida nas
demais. A Figura 10 apresenta a interface gráfica do ambiente LimSee2.
Figura 10 - Interface gráfica do LimSee2
Na figura acima, a região 1 (um) representa a visão estrutural, na qual o
documento SMIL é organizado na forma de uma árvore. A região 2 (dois) é a
visão espacial, utilizada para criação e manipulação de regiões. Nela, os objetos
de mídia também podem ser pré-visualizados em um dado instante de tempo
(somente imagens e textos).
Ainda com relação à Figura 10, a região 3 (três) representa a visão temporal.
Nessa visão os elementos são representados por retângulos cujo comprimento está
relacionado à sua duração. Esses objetos temporais podem ser movidos e
redimensionados na linha do tempo. Além disso, nessa visão é possível
especificar um determinado instante de tempo para visualizar na visão espacial o
estado da apresentação. Esse recurso é de grande valia, pois permite verificar
Trabalhos Relacionados
32
como está ficando a apresentação durante a criação. Cabe ressaltar que na versão
do LimSee2 analisada, a visão espacial não estava funcionando completamente.
A região 4 (quatro) da Figura 10, chamada de visão de atributos, exibe e
permite a edição das propriedades de um elemento selecionado na visão temporal,
estrutural ou espacial. Por fim, a região 5 (cinco) representa a visão textual, na
qual o código fonte SMIL pode ser visualizado e alterado.
Esse ambiente de autoria não possui um exibidor integrado, mas reconhece
os exibidores nativos instalados no sistema, e permite que o autor escolha qual
utilizar.
Da mesma forma que o GRiNS, o LimSee2 privilegia a especificação da
sincronização temporal à interatividade, sendo essa última mais fácil de definir
através da visão textual. É importante destacar que pela linguagem SMIL não ser
voltada para TV digital, o LimSee2 não fornece nenhum suporte à edição ao vivo
de documentos SMIL. Além disso, a visão temporal dessa ferramenta não permite
que novos objetos de mídia sejam inseridos no tempo. Para isso, é necessário
utilizar ou a visão estrutural ou a visão espacial. Outra carência fica por conta da
falta de suporte à simulação de eventos interativos.
2.6.
Macromedia Flash
O Macromedia Flash (Adobe, 2007b), atualmente chamado de Adobe Flash,
ou simplesmente Flash, é uma ferramenta de autoria gráfica vetorial utilizada para
criação de conteúdo para Web, jogos, filmes, entre outros. Estima-se que a
tecnologia Flash atinja mais de 98% dos usuários da Internet3.
Uma das principais características desse ambiente é que, além de oferecer
uma interface gráfica bastante intuitiva para criação de animações e aplicações
interativas, também permite ao desenvolvedor lançar mão de recursos mais
interessantes através da linguagem de programação ActionScript (Williams,
2002). Essa linguagem, que é uma variação da ECMAScript (ECMA, 1999), é
usada, por exemplo, para manipulação de dados e para especificação da
interatividade em aplicações Flash.
3
Fonte: http://www.adobe.com/products/player_census/flashplayer/. Acesso em 23 de abril
de 2007.
Trabalhos Relacionados
33
A ferramenta de autoria Macromedia Flash é composta pela IDE (Integrated
Development Environment) e por um exibidor. Esse exibidor (player) é usado para
depurar e apresentar as aplicações criadas, e possui, dentre outras coisas, uma
máquina virtual para processar scripts, a ActionScript Virtual Machine (AVM). A
Figura 11 apresenta a interface gráfica do Macromedia Flash.
Figura 11 - Interface gráfica do Macromedia Flash
Na figura acima, a região 1 (um) representa a barra de ferramentas. Nela
estão compreendidas funcionalidades básicas que são bastante utilizadas, como
por exemplo, recursos de desenho e zoom. A região 2 (dois), conhecida como
Stage, é utilizada para definir como os elementos estarão dispostos visualmente
em um dado instante (visão espacial). É nessa região que os recursos da barra de
ferramentas são aplicados.
Já a região 3 (três) da Figura 11 destaca componentes que podem ser usados
para criação de uma aplicação. São definidos, entre outros, componentes gráficos,
como botões e campos de texto. A região 4 (quatro) apresenta como as entidades
de uma aplicação estão dispostas na linha do tempo. Em conjunto com a região
Stage funcionam como uma poderosa ferramenta de edição espaço/temporal. Os
pontos negativos ficam por conta de não ser dado suporte à simulação da interação
do usuário durante o processo de criação, e de ser possível somente a
especificação do instante absoluto da apresentação de uma mídia na linha do
tempo. Além disso, a especificação de relacionamentos espaço/temporais e
interatividade só é possível através da codificação de scripts.
Trabalhos Relacionados
34
A região 5 (cinco) é um editor de ActionScript. Nele, por exemplo, pode ser
especificada a ação a ser desempenhada por um determinado componente em
resposta a um evento interativo. Para ajudar na codificação, são oferecidos dicas e
recursos de destaque do código (highlight). Por fim, a região 6 (seis) exibe e
permite a edição das propriedades de um componente selecionado.
O produto da autoria nesse ambiente é um ou mais arquivos executáveis,
chamados de "SWF" (Shockwave Flash File). Esses arquivos podem ser
visualizados em um navegador Web, ou utilizando-se o Flash Player.
Por fim, vale destacar que o Macromedia Flash, por não ser voltado para TV
digital, não fornece nenhum suporte à edição ao vivo de documentos.
2.7.
Análise Comparativa
A seguir, a Tabela 1 sumariza as principais características das ferramentas
de autoria discutidas neste capítulo.
Tabela 1 - Análise comparativa entre ferramentas de autoria
Visão
Ferramenta
Paradigma /
Modelo
Foco
temporal /
Suporte a
Edição
simulação
usuários
ao vivo
interatividade
Procedural
Disposição
JAME
(DVB-J) /
espacial de
Author
page-based
componentes /
services
interatividade
Procedural
Cardinal
Studio
(DVB-J) /
Baseado em
atos, camadas e
componentes
Procedural
Alti
Composer
(DVB-J) /
Baseado em
cenas, planos,
shots e atores
Declarativo
GRiNS
(SMIL) / AHM
(Hardman et al.,
1994)
Disposição
espacial de
componentes /
interatividade
Não suporta
Não tem
usuários
Não
avançados
timeline
simples /
Todos
Não
Todos
Não
Médio
Não
Não
Disposição
espacial de
componentes /
Não tem
interatividade
Estruturação /
structured
Sincronismo de
timeline /
mídias
Não
Trabalhos Relacionados
LimSee2
Declarativo
(SMIL) / AHM
Macromedia
Procedural /
Flash
ActionScript
35
Estruturação /
structured
Sincronismo de
timeline /
mídias
Não
Disposição
espacial/
interatividade
Médio
Não
Todos
Não
timeline
sincronizada
com espacial /
Não
3
Autoria em NCL para TV digital interativa
O editor HyperProp (Coelho & Soares, 2004) foi projetado inicialmente
como um ambiente de autoria para criação de aplicações hipermídia em NCL
main profile (Soares et al., 2006). A fim de se adequar ao contexto de TV digital,
essa ferramenta passou por diversas modificações, o que culminou na criação do
Composer.
Com base nos pontos positivos e negativos de cada uma das ferramentas
analisadas, são listados alguns requisitos e/ou aspectos desejáveis para o
Composer no âmbito de TV digital interativa:
• Necessidade de representação de documentos contendo objetos de
duração indeterminada, como conteúdos produzidos ao vivo ou
adaptados em função do contexto da apresentação do documento, e
eventos de interatividade sobre os objetos de mídia apresentados;
• Exibição das cadeias parciais (trechos de duração previsível) e interações
entre elas;
• Suporte à simulação de eventos interativos e adaptação de conteúdo em
tempo de criação;
• Exibição das composições com semânticas temporais;
• Suporte à edição espaço/temporal;
• Possibilidade de exibição de um documento a partir de qualquer ponto;
• Suporte à edição ao vivo de documentos NCL;
• Elaboração de uma interface gráfica que facilite e agilize a criação de
programas NCL para TV digital.
Este capítulo apresenta novidades do Composer para a criação de programas
NCL, versão 3.0 (Soares & Rodrigues, 2006), para TV digital interativa.
Autoria em NCL para TV digital interativa
37
3.1.
Arquitetura do Composer
Um ambiente de autoria hipermídia deve oferecer 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. É importante ainda que no ambiente de autoria o autor tenha
ferramentas que permitam especificar as características de exibição para cada um
dos componentes (Rodrigues & Soares, 2003).
Da mesma forma que no editor HyperProp, no Composer as abstrações são
definidas nos diversos tipos de visões que permitem simular um tipo específico de
edição. O Composer é composto por quatro visões: uma visão gráfica estrutural,
uma visão gráfica temporal, uma visão gráfica de leiaute e uma visão textual. As
quatro visões funcionam de maneira sincronizada, a fim de oferecer um ambiente
integrado de autoria. A Figura 12 apresenta as visões do Composer.
Figura 12 - Visões do Composer
A visão estrutural permite ao autor criar a estrutura lógica do documento
NCL, ou seja, nela o autor pode criar, editar e apagar composições, objetos de
mídia e elos. Na visão estrutural, os nós de contexto e os nós de mídia são
representados por vértices de um grafo (compostos e atômicos, respectivamente).
Já os elos, são representados por arestas entre vértices do grafo.
No editor HyperProp, a visão espacial, ainda que não implementada
completamente, previa a possibilidade de especificação de leiautes, e a edição de
Autoria em NCL para TV digital interativa
38
relacionamentos espaciais (Coelho & Soares, 2004). No Composer, a definição
das regiões deixou de ser feita na visão espacial, ficando a cargo da visão de
leiaute. Através dessa visão, o autor pode criar, editar e apagar regiões, assim
como manipulá-las graficamente. Quando uma região é movimentada, todas as
suas sub-regiões (regiões filhas) também o são, mantendo suas posições relativas.
A visão espacial, ainda que não implementada na atual versão do Composer, deve
permitir a definição e edição de relacionamentos espaciais entre componentes de
um documento. A visão espacial será discutida posteriormente como trabalho
futuro (Subseção 5.2).
Já a visão temporal, um dos principais focos deste trabalho, permite a
especificação e edição de relacionamentos de sincronização temporal entre
entidades de um documento NCL, definindo suas posições relativas no tempo. Por
fim, a visão textual (declarativa) permite ao autor editar diretamente o código
NCL do documento no qual ele está trabalhando.
Para cada visão gráfica, diferentes elementos da linguagem NCL ganham
destaque. Por exemplo, os elementos region são os elementos fundamentais
utilizados na visão de leiaute. Já na visão temporal, os relacionamentos temporais,
juntamente com as âncoras temporais presentes nos nós de mídia (por exemplo,
um nó de áudio), são entidades chaves para a visualização do documento no eixo
do tempo. No caso da visão estrutural, os nós de composição ganham destaque,
pois são responsáveis pelo agrupamento lógico das entidades presentes no
documento.
É desejável que o usuário tire proveito de visões distintas em função do
contexto de autoria mais relevante. Por exemplo, em um dado momento da edição,
pode ser mais útil trabalhar com a visão estrutural dos componentes. Em outras
circunstâncias, é possível que seja mais apropriado trabalhar na visão temporal,
mais próxima do formato final de apresentação do documento. É 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
(Rodrigues & Soares, 2003).
Para a sincronização entre as visões do Composer, este trabalho propõe a
arquitetura de integração apresentada na Figura 13, a qual deriva da arquitetura
utilizada em (Coelho & Soares, 2004). A diferença principal fica por conta do
Autoria em NCL para TV digital interativa
39
modelo de dados utilizado para integração entre as visões do Composer ser o Java
NCM (Silva et al., 2004), e não diretamente a árvore DOM (Document Object
Model) (W3C, 2004c), do editor HyperProp.
O modelo DOM é utilizado para armazenar e manipular árvores XML, no
caso, a árvore que descreve a estrutura do documento NCL. Além de lançar mão
das vantagens da estruturação do documento NCL através da árvore DOM, o
modelo Java NCM fornece uma API de mais alto nível para manipulação das
entidades do modelo NCM. Com isso, tem-se uma estrutura de dados mais robusta
para integração entre as visões.
Figura 13 - Integração entre visões no Composer
Para
cada
visão,
existe
um
par
de
compiladores
responsáveis,
respectivamente, por traduzir a representação de um documento NCL no modelo
Java NCM para estrutura de dados utilizada na visão, e por converter essa
estrutura de dados na representação do modelo de integração, no caso o Java
NCM.
Além dos compiladores, cada visão tem um par de observadores (um para
cada compilador). Sempre que o modelo Java NCM é modificado, os
observadores obs1 (vide Figura 13) são notificados e acionam os respectivos
compiladores para que a partir do modelo Java NCM seja gerado um novo modelo
para cada uma das visões.
Autoria em NCL para TV digital interativa
40
Por sua vez, os observadores obs2 (Figura 13) são notificados caso haja
alterações no modelo da visão em questão (resultantes de ações do usuário sobre a
ferramenta de edição) e acionam os compiladores correspondentes para que
reflitam essas mudanças no modelo de integração.
Apesar de possuir uma arquitetura de visões muito próxima da já existente
no editor HyperProp, o Composer teve grande parte da sua interface gráfica
remodelada, a fim de facilitar e agilizar a criação de aplicações voltadas para TV
digital. Além de tornar essa ferramenta mais atrativa, a nova interface visa ajudar
o autor, permitindo que ele possa se concentrar, principalmente, no processo de
criação. Para isso foi realizada uma avaliação formativa, por inspeção, por uma
equipe de IHC (Interface Homem-Computador) de toda a interface do editor
HyperProp e do Composer.
O editor HyperProp é um ambiente de autoria que está muito aquém de
atender a demanda dos mais variados tipos de usuários. Isso se deve em grande
parte à falta de diálogo do ambiente com seu parceiro mais importante, o autor. Se
por um lado essa ferramenta atende satisfatoriamente a usuários que conhecem
profundamente a linguagem, por outro, não dá suporte a usuários leigos em NCL.
O Composer visa ajudar o autor no processo de autoria de aplicações voltadas
para TV digital abstraindo toda, ou pelo menos parte da complexidade de se
programar em NCL. Para isso, além da abstração de visões, o Composer fornece
outros mecanismos de suporte ao usuário, como por exemplo, mecanismos de
ajuda e mensagens de erro, conforme será apresentado no próximo capítulo.
3.2.
Sincronismo Temporal
Segundo (Bulterman & Hardman, 2005), a autoria gráfica através de uma
visão temporal é a melhor maneira de mostrar quando os objetos de mídia são
exibidos, bem como de visualizar os relacionamentos entre eles. No entanto,
devido às restrições da representação no tempo, geralmente, a visão temporal é
aplicável somente na autoria de documentos não interativos e não adaptativos, por
restrições do paradigma utilizado para exibição da sincronização.
Surge assim a necessidade de alternativas para contornar problemas de
representação de eventos imprevisíveis, de forma a tornar a autoria através da
Autoria em NCL para TV digital interativa
41
visão temporal, e todo ambiente Composer, mais atrativa para desenvolvedores de
programas para TV digital.
Uma forma de solucionar o problema levantado é através da definição de
uma estrutura de dados que permita a representação de documentos contendo
objetos de duração indeterminada, como conteúdos produzidos ao vivo ou
adaptados em função do contexto da apresentação do documento, e eventos de
interatividade sobre os objetos de mídia apresentados.
Essa estrutura de dados deve ser capaz de preservar a representatividade do
modelo NCM, e ainda favorecer a representação da apresentação na escala do
tempo, permitindo que a visão temporal seja capaz de facilitar o processo de
edição de hiperdocumentos.
A próxima subseção apresenta detalhes da estrutura de dados adotada como
base para a visão temporal do Composer. Ao final, são feitas considerações sobre
a utilização dessa estrutura nos ambientes HyperProp e Composer.
3.2.1.
Modelo de Grafo de Cadeias Temporais Hipermídia
O modelo de grafo de cadeias temporais hipermídia (Costa & Soares, 2005)
é formado por um conjunto de nós e arcos unidirecionais dirigidos, onde os nós
são especializados em nós de início, nós de término e nós conectores. Vale
ressaltar que toda a discussão sobre a representação de documentos NCL no
modelo de cadeias temporais hipermídia é feita seguindo a máquina de estados de
eventos definida na especificação da NCL versão 3.0 (Soares & Rodrigues, 2006).
Os nós de início podem, por exemplo, representar uma transição de início
(start) ou de recomeço (resume) de um evento, enquanto os nós de término podem
representar uma transição de término (stop) ou de pausa (pause). Já os nós
conectores são utilizados como pontos de união em relacionamentos multiponto,
conforme será apresentado em um exemplo mais adiante4.
Nesse modelo, os arcos podem ser utilizados, por exemplo, para representar
o estado de ocorrendo (occurring) ou de pausado (paused) de um evento de
4
Nós conectores poderiam ser usados também em relacionamentos ponto-a-ponto, mas isso
não é relevante para o modelo, uma vez que a não utilização desse tipo de nó para esses
relacionamentos torna o modelo mais simples.
Autoria em NCL para TV digital interativa
42
apresentação (presentation). O arco que representa o estado de ocorrendo tem
origem em um nó de início (transição de começo ou recomeço) e destino em um
nó de término (transição de término ou pausa). O estado de pausado, por sua vez,
é representado por um arco com origem em um nó de término (transição de
pausa), e destino em um nó de início (transição de recomeço).
Além de representarem o estado de ocorrendo e de pausado de eventos, os
arcos podem ser utilizados para definir relacionamentos de causalidade. Os arcos
causais unem nós (transições de eventos) no grafo. A transição origem do arco
causal corresponde a uma condição que deve ser satisfeita. Já a transição destino
corresponde a uma ação disparada em função de a condição definida na origem ter
sido alcançada. Além dos relacionamentos causais, relacionamentos de restrição
também podem ser representados. Não obstante, no contexto de TV digital, os
relacionamentos de restrição não serão considerados5.
Outra característica importante é que, no modelo de cadeias temporais
hipermídia, os arcos definem sempre intervalos de tempo, que podem ser
referentes, por exemplo, à duração da apresentação de um objeto de mídia.
Diferentemente dos arcos, o valor do tempo de execução de um nó é sempre
absoluto. Na realidade, o valor do tempo de cada nó no modelo não é
especificado, e sim calculado a partir da soma dos tempos do conjunto de arcos
utilizados para alcançar o nó, a partir de um ponto inicial qualquer no grafo,
conhecido como ponto de entrada.
Cabe ressaltar que a apresentação de um documento (Rodrigues & Soares,
2003) pode ser iniciada a partir de qualquer nó do grafo (um mesmo documento
pode ser visto por diferentes perspectivas). Considerando que, em um grafo, um
nó pode ser alcançado por vários caminhos, formados pela combinação de arcos, o
valor do tempo atribuído a um nó será sempre o menor valor calculado. Esse valor
corresponde ao caminho mais curto até o nó considerado, a partir de um ponto de
entrada pré-definido.
Nesse modelo, os pontos de indeterminação são os limites entre as cadeias
temporais hipermídia que formam o grafo. Esses pontos podem, por exemplo,
indicar a existência de relacionamentos interativos, onde os tempos das
5
Para tornar a especificação dos relacionamentos mais simples, sem perder muito em
expressividade, elos de restrição não são considerados no contexto de TV digital.
Autoria em NCL para TV digital interativa
43
ocorrências não podem ser previstos antes da apresentação do documento. Os nós
do grafo que só possuem arestas de entrada (incidentes) com origem em pontos de
indeterminação não podem ter os tempos de suas ocorrências calculados. Em
(Buchanan & Zelweger, 1992), uma cadeia temporal é definida como uma
seqüência de exibições previsíveis, sendo que a cadeia formada a partir do início
da execução do documento é definida como cadeia principal. No modelo de
cadeias temporais hipermídia, a cadeia principal é aquela formada pelos nós onde
são conhecidos os tempos de execução a partir do ponto de entrada escolhido.
Ainda em (Buchanan & Zelweger, 1992), as cadeias iniciadas por transições
imprevisíveis na máquina de estados de algum evento são denominadas cadeias
auxiliares. No modelo de cadeias temporais hipermídia, as cadeias auxiliares são
aquelas onde os pontos de indeterminação, gerados por arcos cujo valor não é
determinístico, impedem o cálculo dos tempos de execução dos nós. Quando os
pontos de indeterminação em uma cadeia temporal auxiliar são resolvidos, essa
cadeia deixa de existir e passa a integrar a cadeia principal.
A conversão de especificações temporais do modelo NCM para o modelo de
cadeias temporais hipermídia, e vice-versa, é exemplificada na Figura 14. Essa
figura apresenta um trecho de um documento NCL onde o objeto de mídia audio1,
contendo duas âncoras temporais, é especificado e também representado no
modelo de cadeias temporais hipermídia.
<ncl>
...
I
<media id=”audio1” src=”samba.mp3”>
<area id=”ancora1” begin=”5s” end=”8s”/>
<area id=”ancora2” begin=”15s” end=”21s”/>
</media>
...
</ncl>
15s
W
T
5s (W-8)s
3s T
I
U
I
(W-21)s
6s
T
Figura 14 - Evento de apresentação no modelo de cadeias temporais hipermídia
Para facilitar o entendimento da explanação que segue, os arcos, que
representam o estado de ocorrendo e o estado de pausado do evento de
apresentação, serão chamados simplesmente de (arco de) apresentação e (arco de)
pausa, respectivamente. Nesse e nos próximos exemplos, os nós I e os nós T
representam nós de início e de término, respectivamente.
Na Figura 14, a apresentação do objeto de áudio é representada pelo arco W,
onde o valor de W corresponde à duração da exibição desse objeto. Ademais, tem-
Autoria em NCL para TV digital interativa
44
se que o objeto audio1 possui duas âncoras temporais, denominadas ancora1 e
ancora2. No modelo de cadeias temporais hipermídia, as âncoras associadas aos
objetos também são modeladas através de arcos de apresentação, que são
iniciados e terminados pelo início e pelo fim, respectivamente, da apresentação do
objeto no qual essas âncoras foram definidas. Como exemplo, as arestas (arcos) de
apresentação que representam as âncoras definidas sobre o objeto audio1 têm
início no nó de início e término no nó de término do arco de apresentação relativo
a esse objeto.
Para especificar a duração da apresentação das âncoras, além da definição
do tempo no arco que representa a sua apresentação, é necessário definir os
tempos nas arestas que unem o arco de apresentação do objeto de mídia ao arco de
apresentação da âncora (como exemplo, a aresta U). Na Figura 14, a aresta de
apresentação da âncora ancora1 possui duração de 3 (três) segundos. A aresta que
une o nó de início da apresentação do objeto de mídia ao nó de início da
apresentação
da
âncora
possui
duração
de
5
(cinco)
segundos.
Complementarmente, os arcos que unem os nós de término da apresentação das
âncoras ao nó de término da apresentação do objeto de mídia possuem duração de
(W-8) segundos e (W-21) segundos.
A Figura 15 apresenta um trecho de um documento NCL que estende o
exemplo da Figura 14. Nesse documento são definidos dois relacionamentos
causais entre o objeto audio1 e outro objeto, denominado video1. Os
relacionamentos são definidos através de dois elos, associados à âncora temporal
ancora2, do objeto audio1. O primeiro elo, denominado link1, relaciona o início
da apresentação da âncora ancora2 à ação de início da apresentação do objeto
video1. O segundo elo, denominado link2, relaciona o término da apresentação da
âncora ancora2 à ação de término da apresentação do objeto video1.
Autoria em NCL para TV digital interativa
45
<ncl>
...
<media id=”audio1” src=”samba.mp3”>
<area id=”ancora1” begin=”5s”
end=”8s”/>
<area id=”ancora2” begin=”15s”
end=”21s”/>
</media>
<media id=”video1”
src=”trailer.mpg”/>
W
T
I
5s
...
<link id=”link1”
xconnector=”onBeginStart”>
<bind role="onBegin"
interface="ancora2"
component="audio1"/>
<bind role="start"
component="video1"/>
</link>
<link id=”link2”
xconnector=”onEndStop”>
<bind role="onEnd"
interface="ancora2"
component="audio1"/>
<bind role="stop"
component="video1"/>
</link>
15s
I
(W-8)s
3s
T
(W-21)s
I
0s
I
6s
link1
T
0s
link2
W’
T
...
</ncl>
Figura 15 - Relacionamentos causais no modelo de cadeias temporais hipermídia
Na Figura 15, o objeto de mídia video1 é representado pela aresta W’, onde
o valor de W’ corresponde à duração da exibição desse objeto. Nessa mesma
figura, as arestas que representam os elos link1 e link2 são indicadas. Neste
exemplo, os elos causais têm duração igual a zero, no entanto, caso o
relacionamento definido no documento especificasse um tempo de duração para a
ocorrência da ação ou para avaliação da condição, esse tempo seria atribuído a
essas arestas.
O modelo de cadeias temporais hipermídia permite ainda a representação de
relacionamentos interativos. A Figura 16 exibe o mesmo trecho de documento
NCL apresentado nos exemplos anteriores, complementado de um elo de
interatividade.
Autoria em NCL para TV digital interativa
46
<ncl>
...
<media id=”audio1” src=”samba.mp3”>
<area id=”ancora1” begin=”5s”
end=”8s”/>
<area id=”ancora2” begin=”15s”
end=”21s”/>
</media>
<media id=”video1”
src=”trailer.mpg”/>
<media id=”ads1” src=”ads.mpg”/>
W
5s
(W-8)s
...
<link id=”link1”
xconnector=”onBeginStart”>
<bind role="onBegin"
interface="ancora2"
component="audio1"/>
<bind role="start"
component="video1"/>
</link>
<link id=”link2”
xconnector=”onEndStop”>
<bind role="onEnd"
interface="ancora2"
component="audio1"/>
<bind role="stop"
component="video1"/>
</link>
<link id=”link3”
xconnector=”onSelectionStart”>
<bind role="onSelection"
component="video1">
<bindParam value="BLUE"
name="keyCode"/>
</bind>
<bind role="start"
component="ads1"/>
</link>
T
I
15s
3s
I
T
(W-21)s
6s
I
T
0s
0s
W’
I
0s
I
0s
I
T
(W’-S)s
S
T
link3
W’’
T
...
</ncl>
Figura 16 - Interatividade no modelo de cadeias temporais hipermídia
Neste exemplo, o elo link3 representa um relacionamento onde o
acionamento do botão azul (BLUE) do controle remoto6, durante a apresentação
do vídeo video1, dispara a exibição do objeto de vídeo ads1. No modelo da Figura
16, a apresentação do objeto ads1 é representada pela aresta W’’, onde o valor de
W’’ corresponde à duração da exibição desse objeto.
Ainda no exemplo da Figura 16, a aresta S é chamada de aresta de
interatividade. Em virtude de representar um ponto de interatividade, o intervalo
de tempo da aresta S é indeterminado. Se o evento relativo a essa aresta ocorrer, o
tempo destinado a ela será no mínimo zero e no máximo igual ao tempo da aresta
W’. Como o tempo da aresta S é desconhecido, o nó de término dessa aresta é um
ponto de indeterminação. Nesse exemplo, duas cadeias temporais podem ser
6
A menção ao botão azul é uma mera ilustração, que será utilizada ao longo desta
dissertação.
Autoria em NCL para TV digital interativa
47
identificadas. Considerando o ponto de entrada do modelo como sendo o nó de
início da aresta W, a partir desse nó até o nó de término da aresta S é definida a
cadeia principal. A partir do ponto de término da aresta S até o ponto de término
da aresta W’’ é definida uma cadeia auxiliar. Na Figura 16, a cadeia principal é
indicada pelo retângulo tracejado verde, enquanto a cadeia auxiliar é indicada pelo
retângulo tracejado azul.
Os tempos dos nós na cadeia auxiliar do exemplo da Figura 16 somente
podem ser exatamente definidos durante a execução do documento. Caso o
usuário não realize a ação de interatividade, os tempos dos nós na cadeia auxiliar
não serão definidos (terão valor indeterminado), e esta cadeia não será
incorporada à cadeia principal. Caso o usuário realize a ação de interatividade, o
valor da aresta S será definido com o tempo transcorrido desde o início da
apresentação da aresta W’. Complementarmente, o tempo da aresta que une o nó
de término da aresta S ao nó de término da aresta W’ deverá ser devidamente
atualizado.
A Figura 17 apresenta um trecho de um documento NCL contendo um
relacionamento multiponto, representado através do elo link3. Esse elo define um
relacionamento, onde a apresentação do objeto ads1 e a pausa do objeto audio1
são disparadas através de uma ação de interatividade. Já o elo link4 define um
relacionamento onde o término da execução do objeto ads1 dispara o recomeço do
objeto audio1.
Autoria em NCL para TV digital interativa
48
<ncl>
...
<media id=”audio1”
src=”samba.mp3”>
<area id=”ancora1” begin=”5s”
end=”8s”/>
<area id=”ancora2” begin=”15s”
end=”21s”/>
</media>
<media id=”video1”
src=”trailer.mpg”/>
<media id=”ads1” src=”ads.mpg”/>
...
<link id=”link1”
xconnector=”onBeginStart”>
<bind role="onBegin"
interface="ancora2"
component="audio1"/>
<bind role="start"
component="video1"/>
</link>
<link id=”link2”
xconnector=”onEndStop”>
<bind role="onEnd"
interface="ancora2"
component="audio1"/>
<bind role="stop"
component="video1"/>
</link>
<link id=”link3”
xconnector=
”onSelectionStartPause”>
<bind role="onSelection"
component="video1"/>
<bind role="start"
component="ads1"/>
<bind role="pause"
component="audio1"/>
<linkParam value="BLUE"
name="keyCode"/>
</link>
W1
I
5s
I
15s
I
3s
6s
I
S
I
W2
T
T
T
link4
W
I
P
T
T
T
I
link3
W”
C
T
<link id=”link4”
xconnector=”onEndResume”>
<bind role="onEnd"
component="ads1"/>
<bind role="resume"
component="audio1"/>
</link>
...
</ncl>
Figura 17 - Pausa no modelo de cadeias temporais hipermídia
Na Figura 17, a aresta S, que representa o evento de interatividade, dispara
duas ações simultâneas através do nó conector, representado pelo nó C. Uma das
ações corresponde ao início da exibição da aresta representada por W’’ (objeto
ads1). A outra ação corresponde ao disparo da aresta P, que representa a pausa
sobre a exibição do objeto audio1. A aresta P é criada com o valor inicial igual a
zero. Essa aresta é posicionada entre duas arestas de apresentação (W1 e W2). Na
Figura 16, a apresentação do objeto audio1 é representada pela aresta W. Já na
Autoria em NCL para TV digital interativa
49
Figura 17, a apresentação desse objeto é representada por duas arestas
complementares W1 e W27.
Ainda com relação à Figura 17, o ponto de indeterminação no nó de término
da aresta S não permite o cálculo do tempo exato da apresentação dos nós de
início relativos às arestas W’’, P e W2. No modelo de cadeias temporais
hipermídia, as arestas relativas à pausa não são utilizadas para o cálculo do tempo
dos nós. Na realidade, essas arestas são atualizadas com a diferença dos valores
dos tempos dos nós que elas unem, a fim de manter a consistência do modelo.
Dessa forma, se o evento de interatividade representado pela aresta S não for
disparado pelo usuário, o valor da aresta P permanecerá zero e o evento de pausa
não ocorrerá. Caso contrário, os valores do nó de término de W1 e do nó de início
de W2 serão atualizados e o valor de P será calculado a partir da diferença do
valor do tempo entre esses dois nós.
Como pode ser notado, o modelo de cadeias temporais hipermídia define
uma estrutura de dados bastante robusta para representação temporal de
documentos NCL. Esse modelo é adotado como base da visão temporal tanto do
editor HyperProp quanto do Composer. Entretanto, na visão temporal do
HyperProp, não é possível nem a manipulação de objetos de mídia no tempo, nem
a especificação de relacionamentos temporais entre objetos. Em outras palavras, a
visão temporal do editor HyperProp só serve para visualização de como os objetos
de mídia estarão dispostos no tempo.
A visão temporal do Composer contempla a criação e manipulação de
objetos de mídia no tempo, bem como a especificação de relacionamentos entre
eles. A sincronização da visão temporal permite ainda que as modificações feitas
nessa visão possam ser refletidas no documento e em todas as outras visões.
Além disso, a visão temporal do Composer dá suporte à simulação de
eventos interativos. Deve ser ressaltado que tal funcionalidade permite ao autor
visualizar como se dará a apresentação em tempo de criação, sem a necessidade
7
O estado de ocorrendo (occurring) do evento de apresentação (presentation) de um objeto
de mídia, no modelo de cadeias hipermídia, é representado por um ou mais arcos de apresentação.
Quando o objeto é exibido sem pausas, um único arco de apresentação corresponde ao tempo total
de apresentação do objeto. No entanto, quando o objeto é pausado, são necessários dois arcos de
apresentação, o primeiro para o intervalo antes da mudança do estado do objeto e o segundo após o
recomeço da apresentação do objeto.
Autoria em NCL para TV digital interativa
50
de recorrer ao formatador (ferramenta de apresentação de documentos NCL)
(Rodrigues & Soares, 2003) para apresentar o documento. A simulação faz com
que pontos de indeterminação do modelo possam assumir valores determinísticos
mediante interação do autor.
Detalhes da implementação da visão temporal do ambiente Composer serão
apresentados no próximo capítulo.
3.3.
Edição ao Vivo
No contexto de TV digital, a autoria e a apresentação de documentos
hipermídia são usualmente tratadas em fases distintas. Entretanto, muitas vezes
essas fases precisam ser consideradas em conjunto. Esse é o caso, por exemplo,
dos programas editados ao vivo, onde não só alguns conteúdos são desconhecidos
a priori, como também alguns relacionamentos espaço/temporais entre objetos de
mídia podem não ter ainda sido definidos (Moreno et al., 2005).
Muitos ambientes de autoria dispõem de um emulador, que permite ao autor
visualizar a apresentação de um documento durante o processo de criação.
Contudo, quando o documento é modificado, a apresentação geralmente precisa
ser reiniciada para que o resultado possa ser constatado. Diferente desse cenário, a
edição ao vivo demanda outros requisitos, e para atendê-los, um sistema de TV
digital interativa, e conseqüentemente um ambiente de autoria, deve prover meios
para se definir uma especificação inicial do documento, e meios para modificar essa
especificação em tempo de apresentação, no ambiente do cliente telespectador.
Em (Costa et al., 2006) é proposta e implementada uma solução para edição
textual ao vivo, que se aplica a documentos NCL. Nela é apresentado um
mecanismo para edição de documentos hipermídia declarativos, que visa
preservar a semântica da estrutura lógica definida pelo autor enquanto modifica a
apresentação do documento.
Essa proposta (Costa et al., 2006) ainda integra algumas funcionalidades dos
ambientes de autoria e de execução, abstraindo do autor a criação e a semântica
dos mecanismos necessários (Apêndice A, Subseção A.2.1) para o envio dos
comandos de edição, cujo controle fica completamente a cargo do ambiente de
autoria e do exibidor. Com isso, o autor precisa apenas se preocupar com a
Autoria em NCL para TV digital interativa
51
semântica do documento e não com a forma com que o sincronismo será
implementado.
Para dar suporte à edição ao vivo, o Composer, além de monitorar os
eventos de edição através da sua interface gráfica, principalmente de suas visões,
utiliza a infraestrutura implementada em (Costa et al., 2006). Detalhes de como
isso é feito são apresentados no próximo capítulo.
4
Implementação
O Composer é um ambiente de autoria implementado em Java, que visa
auxiliar autores com diferentes níveis de conhecimento na construção de
documentos NCL nas suas profiles para TV digital (NCL 3.0).
Neste capítulo são apresentados detalhes de implementação das melhorias e
inovações do ambiente de autoria Composer, mostrando, assim, o que este
trabalho tem a acrescentar com relação ao editor HyperProp. Cabe ressaltar que a
implementação do editor HyperProp foi utilizada como base para o
desenvolvimento do Composer.
4.1.
Interface Gráfica
O ambiente de autoria Composer (classe ComposerEditor) é composto por
uma barra de menus (classe EnhancedMenu) e por uma barra de ferramentas
(classe ToolBar), conforme apresentado no diagrama de classes da Figura 18.
A barra de menus pode possuir itens de menu simples (classe
EnhancedMenuItem)
e/ou
caixas
de
seleção
(classe
EnhancedCheckBoxMenuItem). Já a barra de ferramentas é composta por botões
(classe EnhancedButton). Detalhes do funcionamento das classes com prefixo
Enhacend serão apresentados na Subseção 4.1.2. No editor HyperProp, cada visão
possui uma barra de menus e uma barra de ferramentas. No Composer, essas
barras foram retiradas das janelas das visões, sendo concentradas em uma única
barra. Assim, funcionalidades comuns às visões, como por exemplo, zoom in e
zoom out, são ativadas de acordo com a visão que está em foco.
Na atual implementação do Composer é possível que o autor trabalhe com
mais de um documento NCL ao mesmo tempo, diferentemente do editor
HyperProp (Coelho & Soares, 2004). Para isso, o Composer trabalha com a
abstração de projeto (classe IProject), que pode conter um ou mais documentos
NCL (classe EditorDocument). Visando permitir que projetos criados em versões
Implementação
53
mais antigas possam ser utilizados em versões mais recentes, cada versão do
Composer deve, se necessário, implementar de forma diferente seus projetos
(classe ProjectImpl). Nesse caso, a idéia é manter a implementação da versão
antiga, por exemplo, ProjectImpl_1 do Composer versão 1.0, e acrescentar a
implementação da nova versão, por exemplo, ProjectImpl_2 para o Composer
versão 2.0. Desta forma, projetos da versão 1.0 poderiam ser abertos na versão 2.0
do Composer utilizando a API da classe IProject.
Figura 18 - Diagrama de classes da interface gráfica do Composer
A Figura 19 apresenta a janela principal do Composer. Nessa figura, a
região 1 (um) exibe um projeto e os documentos NCL que o compõem, na forma
de uma árvore. A região 2 (dois) é a área de trabalho onde um documento pode ser
visualizado e editado através das visões. Já a região 3 (três), não existente no
editor HyperProp, é uma área multifuncional que serve para dar suporte ao autor
na construção de seus documentos NCL. Essa região é usada, por exemplo, para
notificação de erros. O acesso aos recursos da área multifuncional é feito através
de abas. Detalhes da utilização dessa área serão apresentados mais adiante.
Implementação
54
Figura 19 - Interface gráfica do Composer
A Figura 20 apresenta a barra de menus e a barra de ferramentas da interface
gráfica do Composer. A barra de menus contém várias funcionalidades para
manipulação de projetos e para criação e edição de documentos NCL. Já a barra
de ferramentas é composta por algumas funcionalidades comumente usadas,
como, por exemplo, criar projeto, abrir projeto e salvar projeto.
Figura 20 - Barra de menus e barra de ferramentas do Composer
O restante desta seção continua destacando outras melhorias e inovações
implementadas na interface gráfica do Composer.
4.1.1.
Módulo de Localização
Por opção de implementação, todos os textos exibidos na interface gráfica
do editor HyperProp se encontram dentro do código fonte, vinculados diretamente
aos elementos de interface. Dessa forma, qualquer modificação nesses textos
implica fatalmente a alteração do código. Isso, além de prejudicar a
manutenibilidade e o reuso, dificulta bastante o suporte a vários idiomas.
Para contornar esses problemas, no Composer foi criado o módulo de
localização. Na nova implementação, os itens de interface gráfica deixaram de
referenciar diretamente o texto a ser exibido, e passaram a utilizar uma chave
(string) para obter esse texto junto ao módulo de localização. A utilização dessas
Implementação
55
chaves abstrai o vínculo existente entre os itens de interface e os textos
localizados, permitindo que a manutenção desses textos seja feita sem ser preciso
alterar o código fonte.
Para cada idioma suportado é definido um arquivo (properties) contendo as
chaves e seus respectivos valores (textos). Cabe ressaltar que os arquivos de
properties devem possuir o mesmo conjunto de chaves, sendo que o que muda é o
valor para cada chave, ou seja, os textos localizados. Assim, para um botão de
confirmação, que referencia a chave button.yes, por exemplo, poderíamos ter
definido button.yes=Yes no arquivo de properties para o idioma inglês, e
button.yes=Sim no arquivo para português. Escolhido um idioma, o módulo de
localização simplesmente busca o valor da chave dentro do arquivo de properties
apropriado.
Além de fornecer o valor de uma chave, o módulo de localização também
permite a alteração desse valor durante a execução do Composer. Isso é útil, por
exemplo, para guardar o estado de um item de menu que fica habilitado ou não, de
acordo com mudanças de propriedades dentro de uma visão. Cabe ressaltar que os
valores modificados só têm validade durante a execução, não sendo persistidos ao
sair da ferramenta.
Na atual implementação é possível a troca entre os idiomas inglês e
português em tempo de execução.
4.1.2.
Enhanced Items
Durante a implementação do Composer, alguns componentes foram
desenvolvidos com o objetivo de tornar a criação e manutenção da interface
gráfica mais simples.
Esse conjunto de elementos personalizados, chamados Enhanced Items, é
composto por botões, menus e itens de menu. Todos eles estendem as respectivas
classes oferecidas pela API Java, mas possuem um processo de configuração
diferenciado.
Na criação de um Enhanced Item é passada uma chave (string) referente à
ação que o elemento irá desempenhar. Para criar o botão de abrir projeto da barra
de ferramentas (Figura 20), por exemplo, é passada a chave openProject. De posse
Implementação
56
dessa chave, o construtor do Enhanced Item lança mão do módulo de localização
para buscar outras informações importantes, como por exemplo, o ícone associado
àquela chave, o atalho do teclado, o mnemônico e se o item deve iniciar habilitado
ou não. No caso de itens de menu que são selecionáveis (caixas de seleção), no
construtor ainda é conferido se o item deve começar selecionado ou não.
Na Figura 21 é apresentado um exemplo com informações que poderiam ser
utilizadas para criar um botão que executa a ação de abrir projeto (chave
openProject). Neste exemplo, essas informações estariam contidas no arquivo de
properties do idioma inglês.
...
label.openProject=$Open Project...
icon.openProject=editorConfig/images/open.png
shortcut.openProject=Ctrl+O
enabled.openProject=true
...
Figura 21 - Configuração de um Enhanced Item
Na figura acima, label.openProject especifica o texto que é exibido como
tooltip (dica) do botão criado. Ainda com relação a essa chave, a primeira letra
após o símbolo $ é adotada como mnemônico, no caso de o Enhanced Item ser um
item de menu. Já a chave icon.openProject especifica o ícone a ser utilizado no
botão, enquanto que a chave shortcut.openProject define a tecla de atalho que
pode ser utilizada para executar a ação. Por fim, a chave enabled.openProject
especifica se o botão deve ser ou não habilitado na barra de ferramentas. Se
alguma dessas opções não estiver definida no arquivo de properties, um valor
padrão é utilizado.
Cabe destacar que no construtor do Enhanced Item, além da chave relativa à
ação a ser desempenhada, é preciso fornecer um observador (listener), que é
responsável por monitorar e tratar o evento de acionamento desse elemento de
interface. Por fim, é importante ressaltar que os Enhanced Items foram
vislumbrados após a análise do código fonte da ferramenta LimSee2 (WAM,
2007), a qual usa recursos muito semelhantes para configuração da sua interface
gráfica.
4.2.
Suporte ao Usuário
Esta seção apresenta detalhes das melhorias e inovações referentes a suporte
ao usuário que foram implementadas neste trabalho.
Implementação
57
4.2.1.
Módulo de Preferências
O módulo de preferências é uma novidade do Composer em relação ao
editor HyperProp, e tem como objetivo capturar algumas propriedades da
interface gráfica modificadas pelo autor. Exemplos das propriedades monitoradas
são: as últimas visões ativas, as dimensões e posicionamento de cada visão, o
posicionamento da barra de tarefas, e o tamanho da janela principal.
Sempre que o usuário encerra o Composer, todas essas propriedades são
salvas em um arquivo (properties). Se, ao iniciar o ambiente de autoria, o arquivo
de properties estiver em um local pré-estabelecido, as propriedades monitoradas
são restabelecidas com os valores da última sessão. Caso esse arquivo não exista,
as propriedades de interface são configuradas com seus valores default (padrão).
O mecanismo utilizado para obter os valores das propriedades de interface é
similar ao adotado no módulo de localização. Assim, dentro do código fonte os
elementos de interface fazem referência a chaves, e buscam os valores delas junto
ao módulo de preferências. A grande diferença com relação ao módulo de
localização fica por conta da persistência.
Ainda cabe ressaltar que, além de guardar propriedades de interface, o
módulo de preferências também armazena a lista dos últimos projetos utilizados.
Essa lista, exibida sob um menu da barra de menus, permite o acesso rápido ao
projeto selecionado. Sempre que um novo projeto é aberto ou criado, essa lista é
devidamente atualizada.
4.2.2.
Módulo de Mensagens
Um problema sério existente no ambiente HyperProp diz respeito às
mensagens de compilação, que são pouco descritivas. Além disso, a maior parte
dessas mensagens só é impressa no console de execução. Tal comportamento
demanda que o console seja verificado constantemente, e pode deixar o autor
perdido caso haja algum erro no documento.
No Composer, todas as mensagens de compilação são exibidas em uma aba
(Problems) da área multifuncional. As mensagens podem ser de erro, de aviso ou
Implementação
58
informativas. Uma mensagem pode especificar ainda o tipo da entidade da NCL à
qual faz referência (por exemplo, uma região ou uma âncora), o id (identificador)
dessa entidade, a descrição da mensagem de compilação, e a qual arquivo a
mensagem está ligada.
O duplo clique em uma mensagem que tenha o campo id definido coloca a
visão textual em foco (se ela já não estiver), e seleciona a linha na qual o elemento
com o id informado está. Isso facilita a detecção e a solução de um possível
problema de compilação.
4.2.3.
Módulo de log
O módulo de log (ou registro) tem por objetivo fornecer suporte adicional
no processo de autoria e no funcionamento do Composer. Isso inclui capturar as
mensagens endereçadas à saída padrão do sistema, como, por exemplo, chamadas
explícitas feitas pelo programador no código fonte, ou mesmo exceções geradas
pelo mau funcionamento do Composer.
Essas mensagens são sempre impressas em uma aba (Console) da área
multifuncional. Por uma opção de implementação, mensagens de erro são
impressas em vermelho, enquanto que mensagens informativas são impressas em
verde, e mensagens de aviso são impressas em amarelo. As chamadas dentro do
código fonte podem ser feitas utilizando diretamente a API do Java, ou então a
classe que implementa o módulo de log.
Além de direcionar todas as mensagens da saída padrão para uma região da
interface gráfica, o módulo de log as guarda em um arquivo (log). Isso pode ser
bastante útil para a notificação e rastreamento de bugs, uma vez que esse arquivo
pode ser enviado à equipe de suporte do Composer para aperfeiçoamento da
ferramenta.
4.2.4.
Módulo de Ajuda
No Composer, o módulo de ajuda permite ao autor consultar conceitos
relativos à linguagem NCL e funcionalidades do ambiente de autoria. O conteúdo
Implementação
59
exibido pelo módulo de ajuda foi elaborado de modo que o autor possa fazer um
melhor uso e tirar melhor proveito de todas funcionalidades do Composer8.
Outra característica importante é que o módulo de ajuda identifica o
contexto do autor. Se, por exemplo, o usuário pressionar a tecla F1, a janela de
ajuda é exibida em um tópico relativo à parte da interface gráfica em foco naquele
instante. Caso não tenha sido especificado um tópico relacionado àquela parte da
interface, a janela de ajuda é aberta em uma página padrão.
Para a implementação do módulo de ajuda foi utilizada a tecnologia
JavaHelp (Sun, 2003), o que facilitou a integração com o Composer.
4.3.
Visões
Conforme discutido anteriormente, no Composer as abstrações são definidas
nos diversos tipos de visões que permitem simular um tipo específico de edição.
Nas próximas subseções serão apresentadas as visões do Composer, bem como
suas principais características.
4.3.1.
Visão estrutural
Praticamente toda visão estrutural foi remodelada. No editor HyperProp,
sempre que dois vértices são unidos por mais de uma aresta, uma única aresta é
exibida com um rótulo identificando a quantidade de arestas entre esses vértices.
No Composer, essa representação foi alterada, de modo a desenhar arestas
paralelas, conforme pode ser visto na Figura 22. Isso foi feito com o objetivo de
dar ao autor uma melhor percepção de como o documento está estruturado.
8
O conteúdo do módulo de ajuda foi elaborado em conjunto com o laboratório
SERG/PUC-Rio (http://www.serg.inf.puc-rio.br).
Implementação
60
Figura 22 - Visão estrutural do Composer
A atual visão estrutural continua não representando as portas existentes nas
composições. Contudo, para cada nó de mídia, que é porta do documento, é
atribuído um outro ícone, diferenciando-o dos demais nós de mídia do mesmo
tipo.
Operações de manipulação do grafo continuam sendo permitidas, tais como,
expandir e colapsar composições. As operações de adicionar, editar e remover nós
e elos também são permitidas, sendo que nesse caso, as alterações realizadas por
essas operações são refletidas nas demais visões do Composer. A maior parte das
operações pode ser acessada utilizando o mouse, teclado ou menus. Uma novidade
fica por conta da possibilidade de criação de elos através do arraste do mouse de
um elemento origem até um elemento destino. Essa operação está habilitada
somente para relacionamentos um para um e para nós de mídia no mesmo
contexto, sendo acionada através do arraste do mouse com a tecla Ctrl pressionada
do centro de um nó de mídia para outro. Quando isso é feito, é aberta uma caixa
de diálogo para criação do elo. Cabe lembrar que para o perfil de TV digital,
somente os elos causais estão sendo considerados.
Conforme proposto em (Coelho & Soares, 2004), a visão estrutural do
Composer foi implementada utilizando como base a biblioteca JGraph (Alder,
2003), para representação do documento NCL como um grafo. O JGraph trabalha
com o padrão de projeto MVC (Model-View-Controller) (Gamma et al., 1997),
onde o “modelo” é a implementação das entidades da linguagem NCL, a “visão”
Implementação
61
são os objetos responsáveis pela apresentação do grafo para o usuário, e o
“controlador” são os objetos que definem como alterações na visão são refletidas
no modelo, e vice-versa.
No HyperProp, sempre que uma das visões, que não a estrutural, é
atualizada, o grafo da visão estrutural é reorganizado, de modo que toda a
disposição anterior dos nós é perdida. No Composer, sempre que uma visão
gráfica é atualizada, ou mesmo quando o autor muda de um documento para outro
ou fecha um projeto, as posições dos nós e o estado (expandido/colapsado) das
composições são guardados. Dessa forma, ao atualizar ou ao voltar a trabalhar
com um determinado documento, os nós de mídia e composições do grafo
permanecerão no mesmo estado em que estavam antes.
Ademais, visando melhorar a representação gráfica, sempre que possível, a
visão estrutural tenta evitar que nós (vértices) do grafo sejam sobrepostos. Para
isso, quando um nó é movimentado, se houver colisão com outros nós, é
executado um método iterativo que tem por objetivo repelir os nós afetados. Esse
método tem um número máximo de passos pelo fato de que em determinadas
ocasiões, o grafo pode ser tão denso que ao repelir os nós sobrepostos, esses
podem sobrepor outros nós, e o processo pode continuar indefinidamente.
Atualmente, a visão estrutural do Composer trabalha apenas com o
algoritmo Spring (Kamada & Kawai, 1989) para disposição de grafos. Como
trabalho futuro, outros algoritmos podem ser acrescentados à ferramenta.
4.3.2.
Visão de leiaute
A nova visão de leiaute permite ao autor movimentar livremente uma região
filha para fora da região definida como seu pai. Nessa situação, somente a
interseção da região filha com a região pai é pintada, enquanto que a área disjunta,
não. Se a área da região filha estiver totalmente disjunta com relação à área de seu
pai, somente os contornos da região filha são desenhados. Isso vale também para a
região pai com relação a seu primeiro ascendente, e assim por diante. Seguindo
esse raciocínio, conclui-se que somente aparecerá pintada a interseção de uma
região com todos os seus ascendentes. Isso não significa que em tempo de
apresentação aparecerá somente parte da mídia que usa aquela região. Na verdade,
Implementação
62
a exibição da mídia ligada a uma determinada região vai depender da estratégia
adotada na implementação do formatador.
A Figura 23 apresenta a visão de leiaute do Composer. Nela, a área à
esquerda exibe uma árvore com as regiões definidas pelo autor. Muitas vezes, essa
hierarquia não fica explicitada através do desenho da região do lado direito
(Canvas) da visão de leiaute. Ao selecionar um nó da árvore, a região
correspondente é imediatamente selecionada do lado direito.
Figura 23 - Visão de leiaute do Composer
Outra inovação implementada permite ao autor despoluir a visão de leiaute,
exibindo ou não regiões. Para isso, basta clicar sobre a imagem do “olho”
correspondente à região de interesse, no lado esquerdo da visão de leiaute. Se o
olho referente à região estiver aberto, após o clique com o mouse, ele se fechará e
a região deixará de ser exibida do lado direito. Para reverter o processo, basta
clicar sobre o olho fechado, e ele se abrirá na árvore à esquerda, sendo a região
correspondente novamente exibida do lado direito.
Abaixo do Canvas foi inserida uma região que exibe as propriedades top,
left, width e height de uma região selecionada. Isso é bastante útil, pois informa
instantaneamente as propriedades da região quando ela está sendo movimentada.
Cabe destacar que as manipulações realizadas pelo autor são devidamente
refletidas nas demais visões. Ao Canvas da visão de leiaute também foram
adicionadas uma régua horizontal e outra vertical (vide Figura 23), que dão uma
idéia da ordem de grandeza das regiões (em pixels).
Implementação
63
Atualmente, as dimensões da visão de leiaute se baseiam na resolução do
monitor no qual o Composer está sendo executado. Como trabalho futuro, é
importante a definição dessas dimensões baseado no dispositivo no qual o
documento NCL será exibido, como por exemplo, a resolução da tela de um
televisor ou de um celular.
4.3.3.
Visão textual
A interface da visão textual do Composer é dividida em duas partes,
conforme apresentado na Figura 24. A área da esquerda exibe a árvore XML do
documento, na qual os elementos compostos podem ser expandidos ou
colapsados. Já a área da direita apresenta o código do documento NCL. Se o autor
selecionar um elemento na árvore XML, seu correspondente no código NCL é
automaticamente selecionado e ganha o foco do lado direito da visão textual.
Figura 24 - Visão textual do Composer
O texto apresentado no lado direito do editor é exibido com o recurso de
destaque (highlight), no qual os elementos, seus atributos e valores aparecem em
cores diferentes. Alterações feitas no código NCL são refletidas na árvore XML e
nas demais visões. Essa sincronização é feita através da tecla F5 do teclado ou
através de uma opção na barra de menus. Para que as modificações sejam
devidamente aplicadas, o código do documento precisa ser verificado de acordo
com as regras de formação XML e validado com o schema da linguagem NCL
(Coelho & Soares, 2004). Caso haja algum erro, esse é reportado ao usuário,
conforme relatado na subseção referente ao módulo de mensagens.
Implementação
64
Se o autor modificar o código NCL e tentar mudar para outra visão ou
documento, sem sincronizar, o ambiente de autoria o informa que o código foi
alterado e o pergunta que ação deve ser tomada. Se optar por aplicar as
atualizações antes de trocar de visão (ou documento), todas as visões são
sincronizadas. Caso contrário, as alterações não têm efeito. Essa notificação é uma
novidade do Composer, e visa auxiliar o autor durante o processo de edição.
Apesar de na época ter sido uma importante inovação, o editor textual do
ambiente HyperProp é muito simples, e só dá suporte a funcionalidades básicas,
como por exemplo, copiar, colar e recortar texto. Almejando tornar a edição
textual mais atraente, a visão textual do Composer foi totalmente remodelada.
Nesse processo, praticamente toda implementação existente anteriormente foi
descontinuada. Essa decisão foi motivada pelo fato de já existirem vários editores
código aberto disponíveis na Internet, fazendo com que a implementação de novas
funcionalidades na visão textual do editor HyperProp não trouxessem grandes
benefícios inovadores.
Entre alguns editores textuais analisados, o JEdit (Pestov, 2007) foi
escolhido como base para a atual visão textual. A incorporação desse editor ao
ambiente Composer demandou um profundo estudo do seu código fonte, e a
adaptação desse para atender as necessidades da nova visão textual. Como
resultado, com o JEdit vieram vários recursos, como por exemplo, exibição do
número das linhas do código, recursos de seleção de texto, recursos de
endentação, recursos de autocompletar, opções de cor e fonte do código NCL,
recurso de impressão do código, dentre outros.
Seria interessante ainda a implementação de uma funcionalidade para fazer
wrap (quebra) das linhas de código na visão textual. Isso permitiria que as linhas
fossem ou não quebradas de acordo com a preferência do usuário. Além disso,
seria útil uma funcionalidade que permitisse colapsar blocos NCL na região à
direita (Figura 24), assim como permite o Internet Explorer (Microsoft, 2007c) na
exibição de arquivos XML.
Implementação
65
4.3.4.
Visão temporal
A Figura 25 apresenta um diagrama das principais classes utilizadas na
implementação da visão temporal. Nesse diagrama, a interface Drawable
especifica que todas as suas subclasses devem possuir o método draw(), definindo
como desenhar as entidades na escala temporal.
Figura 25 - Diagrama de classes da visão temporal
A conversão de um documento NCL para o modelo de cadeias temporais
hipermídia correspondente é feita utilizando um compilador já existente no editor
HyperProp. Nesse ponto, o que interessa é que, ao ser gerada uma cadeia, a visão
temporal a varre, e instancia de maneira adequada os objetos que representam
graficamente as entidades do documento.
Os arcos do modelo de cadeias temporais hipermídia, que correspondem à
apresentação dos objetos de mídia, são representados por retângulos preenchidos
com uma cor que identifica o tipo da mídia (áudio, texto, vídeo etc.). Além da
identificação através de cores, cada retângulo possui um ícone relativo ao tipo da
mídia, e um nome (id). O comprimento desses retângulos indica suas durações de
exibição/execução. Objetos da classe TemporalObject (vide Figura 25) são
responsáveis por representar graficamente a apresentação de objetos de mídia.
A exibição de âncoras e elos, não contemplada na visão temporal do editor
HyperProp, conforme descrito em (Coelho & Soares, 2004), é realizada no
Composer. As âncoras temporais, representadas por arcos de apresentação no
modelo de cadeias temporais, são desenhadas como retângulos tracejados não
preenchidos, e ficam dentro do objeto de mídia a que pertencem. As âncoras
possuem um ícone de identificação e um id. No diagrama da Figura 25, as âncoras
são representadas por instâncias da classe AnchorObject.
Implementação
66
Já as arestas, que representam relações causais no modelo de cadeias
temporais hipermídia (elos NCM), são desenhadas como flechas unidirecionais
dirigidas, com origem e destino nos retângulos onde os relacionamentos são
definidos. A classe LinkObject (Figura 25) é responsável pelos elos causais na
visão temporal. Com relação aos elos multiponto, na atual implementação, só é
dado suporte a elos com um elemento origem (uma condição). Nesse caso, uma
flecha unidirecional sai do retângulo origem para cada um dos destinos. A
generalização para elos multiponto e o tratamento de auto-elos (entidade de
origem igual à de destino) ficam como melhorias futuras.
Além de serem responsáveis pela representação gráfica das entidades do
documento, as classes apresentadas na Figura 25 dão suporte à manipulação direta
pelo usuário. Com um duplo clique do mouse, por exemplo, é possível editar as
propriedades de qualquer uma das entidades da visão temporal.
Para mover uma âncora temporal, o autor deve selecioná-la com o mouse e
arrastá-la até a posição desejada. Uma âncora só pode ser movida dentro dos
limites
do
objeto
de
mídia ao
qual
pertence.
O mesmo
vale no
redimensionamento. Na implementação atual, âncoras inconsistentes estão sendo
tratadas somente no caso de sua duração exceder a duração do objeto de mídia ao
qual pertence. Nessa situação, a âncora é desenhada até o limite da duração do
objeto de mídia.
O redimensionamento de objetos de mídia é tratado de modo a preservar a
consistência das âncoras. Assim, se um objeto for redimensionado, e uma de suas
âncoras não couber dentro dele, ela também é redimensionada. Cabe ressaltar que
toda manipulação de objetos na visão temporal atualiza os tempos das arestas no
modelo de cadeias temporais hipermídia, e conseqüentemente, o documento NCL.
A Figura 26 ilustra a interface gráfica da visão temporal. O número 1 (um)
destaca a escala temporal à qual os objetos estão associados. Essa escala é
atualizada de acordo com o fator de zoom utilizado. O número 2 (dois) se refere à
barra de status, que possui campos que informam o nome e os tempos inicial e
final de um objeto selecionado. Através dessa barra também é possível escolher a
partir de qual porta de entrada o documento será exibido na visão temporal.
Implementação
67
Figura 26 - Visão temporal do Composer
Como trabalho futuro, pode ser interessante que um documento seja
apresentado a partir de um ponto qualquer, de acordo com o instante definido por
uma barra de tempo. Na Figura 26, a barra de tempo da visão temporal é
representada pelo número 3 (três).
Ainda com relação à Figura 26, o elemento 4 (quatro) indica a representação
gráfica da âncora temporal anchor0. O elemento 5 (cinco), por sua vez,
corresponde à representação de um elo causal, que relaciona a âncora anchor0 e o
objeto de mídia node1 (número 6). Os elementos 4, 5 e 6 estão relacionados a
instâncias
das
classes
AnchorObject,
LinkObject
e
TemporalObject,
respectivamente. Já o número 7 (sete), referente ao ícone do “raio”, indica a
existência de um relacionamento de interatividade. No caso da Figura 26, a
seleção de um determinado botão do controle remoto, durante a apresentação do
objeto de mídia node0, dispara uma ação, como por exemplo, o término da
apresentação do objeto de mídia node1. Por fim, o número 8 (oito) destaca o ícone
do “relógio” sobre o objeto de mídia node1. Esse ícone indica que o objeto de
mídia, sobre o qual está, possui duração indeterminada (no exemplo da Figura 26,
não foi especificado um relacionamento de término para a imagem node1, e uma
vez iniciada sua apresentação, essa imagem será exibida até que uma ação externa
a termine).
Nas próximas subseções é dado destaque à especificação e edição de
relacionamentos através da visão temporal, bem como ao suporte à simulação de
eventos interativos.
Implementação
68
4.3.4.1.
Especificação e edição de relacionamentos temporais
Na visão temporal, a especificação do sincronismo temporal é definida
através de relações de alto nível, como por exemplo, “exiba ao início de” e
“termine ao recomeço de”. Para isso, a criação de relacionamentos temporais foi
dividida em 2 (dois) grupos: o dos relacionamentos de começo/fim e o dos
relacionamentos de pausa/recomeço. Para cada um desses grupos foi criada uma
caixa de diálogo que permite ao autor especificar relacionamentos temporais entre
objetos de mídia.
A Figura 27 ilustra a caixa de dialogo para criação de relacionamentos de
começo/fim. Os parâmetros especificados nessa figura informam que o objeto de
mídia video1 será iniciado quando começar (start) a âncora ancora2 do objeto de
mídia audio1. Analogamente, o objeto video1 terminará ao fim (end) da âncora
ancora2. Um delay (atraso), desde o acontecimento do evento até a execução da
ação, poderia ser definido através do campo Time. O mesmo raciocínio serve para
criação dos relacionamentos de pausa/recomeço.
Figura 27 - Especificação de relacionamentos temporais na visão temporal
Ainda com relação à Figura 27, se não fosse especificada nenhuma transição
de início, o objeto de mídia seria definido como uma porta do documento.
Ademais, caso não seja definida a transição de fim, mas mesmo assim seja
Implementação
69
especificado um valor no campo Time (caixa End Time), esse valor é usado para
definir a duração explícita do descritor do objeto de mídia em questão. Pelo fato
do campo Time poder representar dois conceitos distintos, a interface gráfica
dessa caixa de diálogo precisa ser revisada para não confundir o autor.
Na visão temporal, o suporte à especificação de relacionamentos interativos
é dado através da caixa de diálogo apresentada na Figura 28. Os parâmetros
definidos nessa figura informam que se o telespectador pressionar o botão azul do
controle remoto, durante a exibição do objeto de mídia video1, o objeto de mídia
ads1 será iniciado. Outras ações, como por exemplo, a ação de pausa, de
recomeço ou de fim, também podem ser utilizadas. Uma vez especificado o
relacionamento interativo, o objeto de mídia ou âncora, que foi definido como
gatilho, nesse exemplo o objeto video1, é desenhado com o ícone de interatividade
(ícone do “raio” apresentado na Figura 26). A atual implementação só permite a
criação de relacionamentos interativos um para um.
Figura 28 - Especificação de relacionamentos interativos na visão temporal
É importante destacar que graficamente o autor pode alterar os
relacionamentos temporais entre objetos da visão temporal, desde que seja
mantida a consistência do sincronismo. A interface da visão temporal não permite,
por exemplo, que um objeto de mídia iniciado por um único elo seja posicionado
antes da condição que o dispara.
A análise da manipulação das entidades na visão temporal pode ser dividida
em duas partes principais. Na primeira, quando a entidade é movimentada ou
redimensionada, todas as outras entidades a ela relacionadas também devem ser
devidamente movidas ou redimensionadas, de modo a manter o relativismo dos
Implementação
70
relacionamentos. Assim, se o início de uma âncora dispara o início de um vídeo,
quando essa ancora é movimentada, o vídeo também deve ser movido junto. Na
verdade, o que muda são os tempos de início e/ou fim da apresentação dos objetos
dependentes, sendo preservados os relacionamentos.
A segunda parte da análise diz respeito aos relacionamentos que incidem
sobre a entidade que está sendo movimentada ou redimensionada. Nesse caso, ao
invés das entidades de onde se originam os relacionamentos também serem
movidas ou redimensionadas, a estratégia adotada foi a de modificar os
relacionamentos, o que parece ser mais intuitivo para o autor.
A alteração de relacionamentos, na verdade, corresponde à alteração do
tempo que uma ação levará para ser executada após o acontecimento de um
evento. Assim sendo, cabe à visão temporal verificar se o conector (relação)
utilizado no elo (relacionamento), que precisa ser modificado, dá suporte à
configuração de um delay (atraso) na execução da ação. Em caso positivo, o
conector é mantido, e o novo valor do atraso é definido através de um parâmetro
de bind (bindParam) ou de um parâmetro de elo (linkParam). Se o conector não
der suporte, existem duas alternativas. A primeira seria modificar o conector, e
depois salvá-lo na base de conectores. Essa alternativa não é viável porque outros
elos podem estar referenciando o conector em questão, tanto dentro do mesmo
documento NCL, quanto em outros documentos. A segunda alternativa, que é a
adotada pela visão temporal, consiste em criar uma cópia do conector, inserindo
as especificações para que seja possível a configuração do atraso na ação. Nesse
caso, o novo conector é inserido na base de conectores do próprio documento que
está sendo editado. Uma vez criado o conector, o elo passa a referenciá-lo, e o
valor do atraso pode agora ser configurado.
Quando o autor remove um elo ou âncora na visão temporal, o elemento
correspondente também é removido do documento. Já na remoção de um objeto
de mídia, o autor tem a opção de removê-lo do documento ou simplesmente da
visão temporal. O primeiro caso funciona do mesmo jeito que para elos e âncoras.
Já no segundo, o objeto de mídia não é removido do documento, mas sim os
relacionamentos que iniciam esse objeto.
Por fim, cabe lembrar que o objetivo da manipulação de objetos na visão
temporal, e a conseqüente alteração dos relacionamentos temporais, é abstrair do
autor a necessidade de codificação em NCL, fazendo com que todo código seja
Implementação
71
gerado automaticamente. É importante destacar também que toda a especificação
e a edição de relacionamentos na visão temporal são devidamente refletidas nas
demais visões do Composer. Detalhes de como isso é feito serão apresentados
mais adiante.
4.3.4.2.
Simulação de eventos interativos
A simulação de eventos interativos permite ao autor visualizar como se dará
a apresentação em tempo de criação, sem a necessidade de recorrer ao formatador
para apresentar o documento. A simulação faz com que pontos de indeterminação
do modelo assumam valores determinísticos mediante interação do autor.
Interagindo com o mouse sobre um objeto de mídia que é gatilho de um
relacionamento interativo, o autor pode simular a interação do telespectador.
Definido com o mouse o ponto (tempo) da interação, a visão temporal atualiza o
modelo, e é novamente desenhada. Em outras palavras, mediante interação do
autor, cadeias parciais (trechos de duração previsível cuja ocorrência não pode ser
exatamente prevista) deixam de existir, sendo integradas à cadeia principal. A
Figura 29 apresenta um exemplo da simulação de evento interativo.
Antes da interação
Depois da interação
Figura 29 - Simulação de eventos interativos
Nesse exemplo, ao pressionar o botão azul do controle remoto durante a
apresentação do objeto de mídia node0, é disparada a ação de finalizar a exibição
Implementação
72
do objeto de mídia node1. Nesse caso, o elo que especifica o relacionamento
interativo é representado, coincidentemente, em azul, para diferenciá-lo dos
demais relacionamentos. Interagindo com o mouse nos objetos definidos como
gatilhos, o autor pode voltar ao estado inicial quando desejar.
À medida que cadeias parciais são adicionadas à cadeia principal, outros
eventos interativos, especificados nas cadeias parciais, podem ser simulados
sucessivamente. Cabe ressaltar ainda que, se no instante escolhido para
acontecimento da interatividade, outros objetos de mídia também forem gatilhos
para o mesmo botão do controle remoto, seus relacionamentos interativos têm
suas ações disparadas. Esse comportamento dá ao autor uma visão bem próxima
da que o telespectador vai ter durante a apresentação do documento.
A implementação da visão temporal dá suporte à exibição de objetos de
mídia, âncoras e elos. A representação de outras entidades do NCL, como por
exemplo, nós de switch, fica como sugestão de trabalho futuro.
4.3.5.
Sincronização entre visões
Um problema existente na implementação do editor HyperProp diz respeito
à sincronização das visões gráficas com a visão textual, conforme relatado em
(Coelho & Soares, 2004), onde um evento de sincronização disparado por uma
das visões gráficas faz com que a organização do documento NCL seja perdida.
Para resolver esse problema no Composer, a biblioteca que implementa a árvore
DOM foi estendida, de modo a manter a ordem especificada pelo autor.
Na implementação da arquitetura apresentada na Figura 13, os compiladores
utilizados foram os mesmos que já haviam sido desenvolvidos no editor
HyperProp. A exceção fica por conta da visão temporal, na qual foi necessária a
implementação do compilador responsável por atualizar o modelo de cadeias
temporais hipermídia, e conseqüentemente, as entidades no modelo Java NCM.
A Figura 30 apresenta o diagrama de classes da arquitetura de integração do
Composer, a qual é baseada no padrão de projeto Mediator (Gamma et al., 1997).
Esse padrão define um mediador (classe ComposerEditor) que encapsula como as
visões (classe TextualView, StructuralView, LayoutView e TemporalView)
interagem. Quando uma visão é modificada, ela notifica ao mediador do ambiente
Implementação
73
de autoria, e fica a cargo desse mediador acionar os compiladores das demais
visões para que as modificações sejam refletidas. O mediador evita que as visões
referenciem umas as outras explicitamente, e isso permite que outras visões
possam ser acopladas sem necessidade de modificação nas visões já existentes.
Figura 30 - Diagrama de classes do mediador no Composer
A arquitetura acima visa permitir a especificação de uma API para que
outros desenvolvedores possam criar novas visões para o Composer. Da mesma
forma que as visões apresentadas, as novas visões utilizariam como modelo de
integração o Java NCM ou a árvore DOM correspondente.
4.4.
Módulo de Edição ao Vivo
Para dar início ao processo de edição ao vivo, o autor precisa informar ao
Composer, e conseqüentemente ao módulo de edição ao vivo, que as modificações
pertinentes devem ser monitoradas. Isso pode ser feito através de uma opção na
barra de menus.
Uma vez ativado o modo de edição ao vivo, a visão textual é desabilitada,
não sendo possível a sua utilização durante esse período. Essa medida foi tomada
devido à complexidade de se mapear as modificações feitas nessa visão em
comandos de edição. A análise de alternativas para se contornar esse problema
fica como trabalho futuro.
A implementação do Composer gera comandos de edição na criação e
remoção de regiões, descritores, objetos de mídia, composições, conectores e elos.
Implementação
74
É possível ainda chamar os comandos de preparar e iniciar apresentação de um
documento NCL, no ambiente de apresentação do telespectador. À medida que
são gerados, os comandos de edição podem ser visualizados através de uma aba
na área multifuncional (Figura 19).
Para manter equivalência na consistência do documento NCL, tanto no
ambiente de autoria, quanto no ambiente de apresentação, os comandos de edição
não são guardados seguindo somente a ordem de geração. Se, por exemplo, um
objeto de mídia é criado, e só depois é criado o seu descritor, o documento estaria
consistente no ambiente de autoria, mas não no ambiente de apresentação. O
módulo de edição ao vivo organiza os comandos de edição seguindo,
primeiramente, a prioridade da entidade que o comando referencia, e
posteriormente, a ordem na qual o comando foi gerado. A prioridade das
entidades é dada na seguinte ordem: região, descritor, nó de mídia, nó de contexto,
conector e elo. Comandos complementares sobre uma mesma entidade, como por
exemplo, um comando de adicionar, seguido posteriormente por outro de
remover, se anulam e, uma vez identificados, são removidos da lista de comandos
de edição.
Concluído o processo de edição, o próximo passo é enviar as alterações para
que elas possam ser refletidas no ambiente de apresentação dos telespectadores.
Através de uma opção na barra de menus, o autor pode exportar os comandos de
edição para um arquivo. Esse arquivo recebe o nome do documento NCL editado,
acrescido da extensão .seq. Para o documento documento1.ncl, por exemplo, o
arquivo de edição se chamaria documento1.seq. Se for o caso, quando o arquivo
de comandos é exportado, também são criados, no mesmo diretório, os arquivos
que contêm trechos NCL relativos às entidades que estão sendo adicionadas no
documento.
A Figura 31 descreve, através de expressões regulares, os comandos de
edição, que podem estar contidos no arquivo exportado. Nesse arquivo, cada linha
corresponde a um comando. Os comandos de edição e seus parâmetros foram
definidos baseados na API especificada em (Costa et al., 2006).
Implementação
75
PREPARE_NCL
START_NCL
ADD_REGION [parent region perspective]? [NCL file of the new region]
REMOVE_REGION [region perspective]
ADD_DESCRIPTOR [NCL file of the new descriptor]
REMOVE_DESCRIPTOR [descriptor id]
ADD_NODE [parent context perspective] [NCL file of the new node]
REMOVE_NODE [node perspective]
ADD_CONNECTOR [NCL file of the new connector]
REMOVE_CONNECTOR [connector id]
ADD_LINK [parent context perspective] [NCL file of the new link]
REMOVE_LINK [link perspective]
Figura 31 - Comandos de edição ao vivo no Composer
Na Figura 31, os comandos de PREPARE_NCL e START_NCL informam ao
ambiente de apresentação que a exibição de um determinado documento NCL
deve ser preparada e iniciada, respectivamente. Já o comando de criação de região
(ADD_REGION) tem como parâmetros a perspectiva da região pai, se houver, e o
nome do arquivo que contém a especificação NCL da região a ser criada. Um
exemplo de comando seria ADD_REGION newRegion.ncl, para inserção da região
definida em newRegion.ncl diretamente na base de regiões, ou ADD_REGION
r0/r1 newRegion.ncl, para inserir a nova região dentro da região r1, cujo pai é a
região r0. Para remover uma região, o único parâmetro necessário é a perspectiva
da região a ser removida. O comando REMOVE_REGION r3/r4, por exemplo,
define que a região r4, cujo pai é r3, deve ser removida.
Os comandos de inserção e remoção de descritor e conector são parecidos.
No caso da criação, basta passar o nome do arquivo que contém a especificação
NCL do descritor ou conector a ser criado. Já no comando de remoção, basta
informar o id (identificador) do elemento.
Os comandos de edição para nós e elos possuem a mesma regra de
formação. O comando ADD_NODE doc1/context1 node2.ncl, por exemplo, define
que o nó contido no arquivo node2.ncl deve ser inserido no contexto context1 do
documento doc1. Já o comando REMOVE_NODE doc1/node3 especifica que o nó
node3 deve ser excluído do documento doc1. A mesma analogia serve para a
criação e remoção de elos.
Atualmente, existe um multiplexador, responsável por enviar os comandos
de edição, juntamente com o áudio e vídeo principal, implementado em C++. Para
fazer a integração com o ambiente de autoria, implementado em Java, foi criado
um programa em C++, que fica monitorando um determinado diretório, passado
como parâmetro, em busca de arquivos que contenham comandos de edição. Cabe
ressaltar que para que os arquivos sejam processados, e, conseqüentemente, os
comandos enviados, o multiplexador precisa estar sendo executado.
Implementação
76
Como trabalho futuro sugere-se a implementação do multiplexador em Java
ou a utilização de JNI (Sun, 1997) para que o Composer possa se comunicar
diretamente com o multiplexador implementado em C++. De forma geral, precisa
ser trabalhada a integração do Composer com ambientes de transmissão. Além
disso, também pode ser interessante que o instante de envio de cada comando seja
especificado e armazenado, permitindo assim, que o arquivo de comandos de
edição seja processado em lote (batch).
5
Conclusões
O objetivo desta dissertação foi apresentar o ambiente de autoria Composer,
o qual é voltado para a criação de programas NCL, versão 3.0, para TV digital
interativa. Da mesma forma que no editor HyperProp, no qual foi baseado, no
Composer as abstrações são definidas nos diversos tipos de visões que permitem
simular um tipo específico de edição. Conforme foi apresentado neste documento,
essas visões funcionam de maneira sincronizada, a fim de oferecer um ambiente
integrado de autoria.
A metodologia empregada para a execução deste trabalho envolveu uma
ampla análise da literatura em ambientes de autoria (Capítulo 2), a proposta de
melhorias (Capítulo 3), principalmente para a arquitetura da visão gráfica
temporal, bem como sua implementação (Capítulo 4).
Como foco principal, a criação e manipulação de objetos de mídia dispostos
na visão temporal foram contempladas. A criação de objetos de mídia no tempo e
seus relacionamentos com os demais objetos foram tratados de forma a tornar a
especificação da apresentação mais intuitiva para o autor. Problemas de
representação e edição de objetos de mídia, relacionamentos entre objetos,
relacionamentos interativos e edição ao vivo também foram tratados. De forma
geral, o Composer integra técnicas a fim de facilitar o processo de edição de
documentos NCL para TV digital interativa.
Na próxima subseção é feita uma análise comparativa dos recursos,
principalmente os de sincronização temporal e edição ao vivo, entre as
ferramentas apresentadas no Capítulo 2 e o Composer, levando em conta as
características de cada uma, além de serem sumarizadas as principais melhorias
do Composer com relação ao editor HyperProp. Por fim, são discutidos pontos
que ficam em aberto para serem tratados em trabalhos futuros, visando tornar o
ambiente de autoria Composer mais atrativo para profissionais de TV digital.
Conclusões
78
5.1.
Análise Comparativa
Os ambientes JAME Author, Cardinal Studio, AltiComposer e Macromedia
Flash dão um maior suporte ao autor do ponto de vista de abstração com relação
ao modelo e linguagem utilizados. Através de seus modelos de autoria e interfaces
gráficas, é mais simples pensar nas abstrações de botão, menu etc. Nesses
ambientes, o processo de autoria se caracteriza principalmente pela especificação
da disposição espacial das mídias do documento, dando ao autor uma noção de
como os objetos serão apresentados na tela.
Contudo, esses ambientes deixam a desejar quanto à definição do
sincronismo entre mídias. O JAME Author, por exemplo, não possui uma visão
temporal e não oferece nenhum suporte à definição do sincronismo temporal. O
Cardinal Studio e o AltiComposer demandam conhecimentos avançados para
configuração do sincronismo através da personalização do comportamento de
componentes. Ademais, O Cardinal Studio possui uma visão temporal muito
simples, enquanto o AltiComposer nem possui uma. Nesse contexto, o
Macromedia Flash, apesar de só permitir a definição de relacionamentos através
da utilização de scripts, lança mão de sua visão temporal (timeline) em conjunto
com a visão espacial para fornecer ao autor uma poderosa ferramenta de edição.
As abstrações fornecidas pelas ferramentas de autoria GRiNS, LimSee2 e
Composer são mais ligadas à linguagem hipermídia na qual esses ambientes se
apóiam (GRiNS e LimSee2 em SMIL, e o Composer em NCL). No GRiNS e no
LimSee2, o processo de autoria foca na configuração temporal dos objetos de
mídia da apresentação. O LimSee2 tenta ainda utilizar uma visão espacial, que em
conjunto com a visão temporal, permite a edição de relacionamentos
espaço/temporais. Contudo, na versão analisada, a implementação da visão
espacial não funcionava efetivamente.
O Composer, por sua vez, além de fornecer todos os recursos para
organização lógica de documentos (através da visão estrutural), permite agora que
o sincronismo temporal seja especificado e editado através da visão temporal.
Além disso, O Composer é o único desses ambientes que permite a simulação de
eventos interativos em tempo de autoria, sem a necessidade de apresentação do
documento.
Conclusões
79
Quanto ao suporte a usuários com diferentes níveis de conhecimento, a
ferramenta JAME Author tem como recurso mais avançado a especificação da
navegação entre páginas e componentes. Os ambientes Cardinal Studio,
AltiComposer e Macromedia Flash dão suporte a usuários iniciantes através de
suas abstrações, e a usuários avançados através da possibilidade de personalização
de componentes e seus comportamentos. Já o GRiNS, o LimSee2 e o Composer
podem ser considerados ferramentas que dão suporte a usuários que conhecem
bem as linguagens nas quais esses ambientes se baseiam. Ao longo deste trabalho,
a interface gráfica do Composer foi remodelada, contudo, ainda é preciso se
trabalhar em abstrações que visem tirar do usuário a necessidade de conhecer a
linguagem NCL.
Ainda é importante ressaltar que nenhum dos ambientes estudados dá
suporte ao monitoramento e envio de comandos de edição ao vivo, como faz o
Composer. O Cardinal Studio e o AltiComposer permitem a utilização de stream
events, que podem ser utilizados para tal finalidade. Não obstante, esses ambientes
não fornecem um mecanismo simples e direto que possibilite ao autor enviar suas
modificações em tempo de apresentação de um documento. Nesse quesito, o
Composer é único, devido a todas as características discutidas (Seção 3.3 e 4.4).
Um ponto positivo é que todos os ambientes analisados possuem um
emulador associado à ferramenta de autoria, e isso permite que o autor teste sua
aplicação sem a necessidade de um set-top box, evitando que problemas sejam
percebidos tardiamente.
Com relação ao editor HyperProp, primeiramente cabe destacar que essa
ferramenta é voltada para a autoria de aplicações hipermídia em NCL main profile
(versão 2.3), enquanto o Composer tem por objetivo dar suporte à criação de
programas NCL versão 3.0 (perfis de TV digital).
O Composer teve grande parte da sua interface gráfica remodelada a fim de
tornar essa ferramenta mais atrativa para o autor. Nesse processo, foram
desenvolvidos os Enhanced Items e o módulo de localização, os quais facilitam o
reuso e a manutenção dos itens de interface. Visando suprir ainda outras carências
do editor HyperProp, foram desenvolvidos o módulo de ajuda, de mensagens, de
registro, e o módulo de preferências.
O Composer é baseado praticamente na mesma arquitetura de visões do
HyperProp. Contudo, todas as visões foram remodeladas, a fim de melhorar o
Conclusões
80
processo de edição de hiperdocumentos. A visão espacial que no HyperProp só
permite a especificação de leiautes, no Composer passou a se chamar visão de
leiaute. Já a nova visão temporal permite a criação e manipulação de objetos de
mídia no tempo, bem como a especificação de relacionamentos entre eles,
diferente do que acontece no HyperProp. A visão temporal do Composer ainda dá
suporte à simulação de eventos interativos, permitindo que o autor visualize como
se dará a apresentação em tempo de criação. No editor HyperProp, a visão
temporal só permite a visualização de como os objetos de mídia estarão dispostos
no tempo. Por fim, a edição ao vivo, requisito importante no contexto de TV, é
mais uma novidade presente somente no Composer.
5.2.
Trabalhos Futuros
Alguns pontos do trabalho realizado nesta dissertação podem ser explorados
como trabalhos futuros.
Em determinadas situações, a exibição de composições com semânticas
temporais pode ajudar o autor na especificação dos relacionamentos entre os
objetos de mídia. Tal funcionalidade enriqueceria a visão temporal, tornando-a
mais atraente no desenvolvimento de documentos NCL através do Composer.
Para isso, templates podem ser utilizados, por exemplo, para obter a semântica das
composições SMIL, que possuem semântica paralela, seqüencial ou exclusiva.
Apresentações um pouco mais complexas, como por exemplo, com muitos
elos de sincronismo, não são triviais de se elaborar. Elas, geralmente, demandam a
criação de conectores, o que requer do autor um conhecimento mais profundo da
linguagem. No Composer ainda não é dado suporte a esse tipo de problema.
Os mecanismos de filtragem baseados na técnica olho-de-peixe, conforme
descritos em (Coelho & Soares, 2004), precisam ser reimplementados em todas as
visões do Composer. Uma alternativa interessante seria implementar as visões se
baseando na abordagem ZUI (Zoomable User Interfaces). No caso da visão
temporal, os mecanismos de filtragem nunca existiram, e são muitos os problemas
que precisam ser tratados. Dentre eles, pode-se destacar a utilização de templates
e a exibição de composições como múltiplas cadeias.
Conclusões
81
Ademais, seria importante a especificação de uma API que permitisse que
novas visões fossem adicionadas ao Composer, tendo como base o modelo Java
NCM ou a árvore DOM que representa um documento, mantendo assim as
características de edição e sincronismo. Isso permitiria que o Composer fosse
personalizado de acordo com as necessidades do autor.
Atualmente, projetos do Composer são salvos como objetos serializados.
Seria interessante que esses projetos fossem salvos como arquivos XML para
tornar mais fácil a compatibilidade de projetos entre versões do ambiente de
autoria.
Um ponto que ainda precisa ser tratado é o suporte à criação de outras
entidades da NCL através da interface gráfica, como por exemplo, os nós de
switch. Além disso, devem ser implementados mecanismos de suporte a ações de
desfazer (undo) e refazer (redo), e melhorado o verificador de documentos NCL,
o qual, na atual implementação, não tem detectado todos os erros de compilação.
Para isso, uma alternativa interessante é o uso de Schematron (ISO, 2006).
Sugere-se ainda o estudo de alternativas para contemplar a especificação da
navegação, de transições e de animação através da interface do Composer.
Na visão temporal, no caso de um objeto de mídia contínua, seria
interessante exibir sua duração natural mesmo que o objeto termine antes ou
depois desse tempo. Além disso, na atual implementação do modelo de cadeias
temporais hipermídia não é dado suporte a documentos com ciclos (loops).
Alternativas para se contornar esse problema devem ser estudadas.
Para testar sua autoria, o autor pode querer iniciar a apresentação a partir de
um determinado instante, especificado pela barra de tempo da visão temporal. É
esperado que além de iniciar o documento a partir de qualquer instante, seja
possível o disparo de eventos interativos anteriores ou posteriores a esse ponto,
para verificação de como se dará o restante da apresentação. Para isso, um
exibidor simulado (formatador) que permita tal funcionamento deve ser
implementado e integrado à ferramenta de autoria. A utilização do modelo de
cadeias hipermídia será de grande valia nesse processo, uma vez que para
apresentar um documento a partir de um determinado instante será necessário
caminhar no grafo definido pelo modelo, simulando a apresentação de entidades e
a ocorrência de eventos até tempo especificado.
Conclusões
82
A visão espacial, anteriormente definida em (Costa & Soares, 1996),
(Moura & Soares, 2001) e (Coelho & Soares, 2004), precisa ser implementada no
Composer para dar suporte à especificação e edição do sincronismo espacial em
documentos NCL. Essa visão permitirá ao autor visualizar graficamente como os
objetos de mídia estarão dispostos no espaço em um dado instante da apresentação
do documento. Trabalhando de forma coordenada, a visão espacial e a visão
temporal podem ser úteis para criação e edição de relacionamentos
espaço/temporais. A Figura 32 ilustra o funcionamento da visão espacial.
Barra de tempo
t
Vídeo futebol
Vídeo jornal
Âncora temporal
left
z-index
top
Edição espacial
Figura 32 - Edição de relacionamentos espaciais no Composer
Na figura acima, a edição do posicionamento e das dimensões (da região) de
um objeto de mídia, como por exemplo, o vídeo do futebol, deve ser refletida no
documento NCL. Para que isso ocorra, o Composer deve ser capaz de transformar
as ações do autor em relacionamentos espaciais.
A visão espacial deve ainda permitir a visualização e edição do volume do
áudio de objetos de mídia, conforme proposto em (Costa & Soares, 1996). Nesse
caso, barras indicariam os percentuais do volume usado na reprodução dos objetos
que estão sendo apresentados em um determinado instante de tempo. Da mesma
forma que no caso da edição espacial, a alteração do volume do áudio também
deve ser refletida no documento.
Conclusões
83
Para concluir, a realização de testes de usabilidade permitirão verificar
como o sistema produzido contribui para apoiar as necessidades inerentes ao
processo de autoria de documentos hipermídia. Isso será muito importante para
rastrear bugs e para que novas funcionalidades possam ser desenvolvidas para que
o ambiente de autoria Composer se adapte às necessidades dos profissionais de
TV digital.
O código-fonte do Composer foi publicado no portal do software público
brasileiro
(http://www.softwarepublico.gov.br)
e,
portanto,
contribuições da comunidade de software livre para a sua evolução.
pode
receber
6
Referências Bibliográficas
[Adobe, 2007a] Adobe Systems, Dreamweaver 8. Disponível em
http://www.macromedia.com/software/dreamweaver/. Acesso em 22 de fevereiro
de 2007.
[Adobe, 2007b] Adobe Systems, Macromedia Flash MX Professional 7 –
Disponível em http://www.adobe.com/products/flash/flashpro/. Acesso em 27 de
fevereiro de 2007.
[Alder, 2003] Alder, G., Design and Implementation of the JGraph Swing
Component, Technical Report, Fevereiro de 2003. Disponível em
http://ontwerpen1.khlim.be/projects/netsim/jgraph-paper.pdf. Acesso em 16 de
março de 2007.
[Alticast, 2007a] Alticast Inc, AltiComposer 2.0 - USA. Disponível em
http://www.alticast.com. Acesso em 22 de fevereiro de 2007.
[Alticast, 2007b] Alticast Inc, Script Guide - AltiComposer 2.0, USA.
Disponível em http://www.alticast.com. Acesso em 27 de fevereiro de 2007.
[Alticast, 2007c] Alticast Inc, User Guide – AltiComposer 2.0, USA. Disponível
em http://www.alticast.com. Acesso em 27 de fevereiro de 2007.
[Berners-Lee et al., 1994] Berners-Lee, T. J.; Cailliau, R.; Luotonen, A.; Nielsen,
H. F.; Secret, A., The World-Wide Web, Communications of the ACM, v. 37, n.
8,
Agosto
de
1994,
p.
76-82.
Disponível
em
http://portal.acm.org/citation.cfm?id=179671. Acesso em 3 de abril de 2007.
[Buchanan & Zelweger, 1992] Buchanan, M. C.; Zelweger, P. T., Specifying
Temporal Behavior in Hypermedia Documents, European Conference on
Hypertext - ECHT'92, Milão, Itália, Dezembro de 1992. Disponível em
http://citeseer.ist.psu.edu/cache/papers/cs/4389/http:zSzzSzwww.parc.xerox.comz
SzistlzSzmemberszSzpollezzSzpaperszSzfireflyecht92.pdf/buchanan92specifying.pdf. Acesso em 18 de março de 2007.
[Bulterman & Hardman, 2005] Bulterman, D.; Hardman, L., Structured
Multimedia Authoring, ACM Transactions on Multimedia Computing
Communications, and Applications (TOMCCAP), v. 1, i. 1, p. 89-109, Fevereiro
de
2005.
Disponível
em
http://portal.acm.org/citation.cfm?id=1047943&dl=ACM&coll=&CFID=1515151
5&CFTOKEN=6184618. Acesso em 18 de março de 2007.
Referências Bibliográficas
85
[Bulterman & Rutledge, 2004] Bulterman, D.; Rutledge, L., Livro SMIL 2.0:
Interactive Multimedia for Web and Mobile Devices. Springer, Abril de 2004.
[Bulterman et al., 1998] Bulterman, D. C. A.; Hardman, L.; Jansen, J.; Mullender,
K. S.; and Rutledge, L. GRiNS: A GRaphical INterface for creating and
playing SMIL documents. In WWW7 Conference, Computer Networks and
ISDN Systems, v. 30, i. 1-7, p. 519-529, Brisbane, Australia, Abril de 1998.
Disponível em http://epubs.cclrc.ac.uk/bitstream/428/GRiNS_final.pdf. Acesso
em 20 de abril de 2007.
[CableLabs, 2006] CableLabs, OpenCable Application Platform Specification
(OCAP) 1.1. Issued I01, Dezembro de 2006. Disponível em
http://www.opencable.com/downloads/specs/OC-SP-OCAP1.1-I01-061229.pdf.
Acesso em 23 de fevereiro de 2007.
[Canonical, 2007] Canonical Ltd, Ubuntu 6.10 (Linux distribution). Disponível
em http://www.ubuntu.com/. Acesso em 23 de maio de 2007.
[Cardinal, 2007] Cardinal Information Systems Ltd, Cardinal Studio 4.0 –
Finland. Disponível em http://www.cardinal.fi. Acesso em 22 de fevereiro de
2007.
[Coelho & Soares, 2004] Coelho, R. M.; Soares, L. F. G., Integração de
Ferramentas Gráficas e Declarativas na Autoria de Arquiteturas Modeladas
através de Grafos Compostos - Dissertação de mestrado, Pontifícia
Universidade Católica do Rio de Janeiro - PUC-Rio - 2004. Disponível em
ftp://ftp.telemidia.puc-rio.br/pub/docs/theses/2004_08_coelho.pdf. Acesso em 18
de março de 2007.
[Costa & Soares, 1996] Costa, F. R.; Soares, L. F. G., Um Editor Gráfico para
Definição e Exibição do Sincronismo de Documentos Multimídia/Hipermídia,
Dissertação de Mestrado, Departamento de Informática, PUC-Rio, Agosto de
1996.
Disponível
em
ftp://ftp.telemidia.pucrio.br/pub/docs/theses/1996_08_COSTA.pdf. Acesso em 3 de abril de 2007.
[Costa & Soares, 2005] Costa, R. M. R.; Soares, L. F. G., Modelos Temporais
para Especificação de Sincronismo em Documentos Hipermídia, monografia
apresentada como requisito de avaliação da disciplina Estudo Orientado, 2º
semestre de 2005.
[Costa et al., 2006] Costa, R. M. R.; Moreno, M. F.; Rodrigues, R. F.; Soares, L.
F. G., Live Editing of Hypermedia Documents, Proceedings of the 2006 ACM
symposium on Document engineering - DocEng'06, Amsterdam, The
Netherlands,
2006.
Disponível
em
http://delivery.acm.org/10.1145/1170000/1166202/p165costa.pdf?key1=1166202&key2=1513054711&coll=&dl=ACM&CFID=1515151
5&CFTOKEN=6184618. Acesso em 21 de março de 2007.
Referências Bibliográficas
86
[ECMA, 1999] ECMA Standardizing Information and Communication Systems.
ECMAScript Language Specification, Standard ECMA 262, 3rd Edition,
Dezembro
de
1999.
Disponível
em
http://www.ecmainternational.org/publications/standards/Ecma-262.htm. Acesso em 22 de
fevereiro de 2007.
[ETSI, 2003] ETSI, ES 201 812: Multimedia Home Platform (MHP)
Specification 1.0.3. ETSI Standard, Dezembro de 2003. Disponível em
http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=18800.
Acesso em 22 de fevereiro de 2007.
[FLEXTV, 2004] FLEXTV, TV Digital: Análise das Alternativas
Tecnológicas. Relatório em atendimento ao Requisito 4.1.3 – RFP04/2004 –
MCT/FINEP, produto 1A, Dezembro de 2004.
[Fraunhofer, 2007a] Fraunhofer Institute for Media Communication IMK, JAME
Author 1.0, Schloss Birlinghoven – Germany. Disponível em http://www.jame.tv.
Acesso em 22 de fevereiro de 2007.
[Fraunhofer, 2007b] Fraunhofer Institute for Media Communication IMK, Quick
Start - JAME Author 1.0, Schloss Birlinghoven - Germany. Disponível em
http://www.jame.tv. Acesso em 27 de fevereiro de 2007.
[Fraunhofer, 2007c] Fraunhofer Institute for Media Communication IMK, User
Manual - JAME Author 1.0, Schloss Birlinghoven – Germany. Disponível em
http://www.jame.tv. Acesso em 27 de fevereiro de 2007.
[FSF, 2007] Free Software Foundation, GNU Lesser General Public License.
Disponível em http://www.gnu.org/copyleft/lgpl.html. Acesso em 23 de março de
2007.
[Gamma et al., 1997] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J., Design
Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley
Publishing Company, 11a. edição, Maio de 1997.
[Hardman et al., 1994] Hardman, L.; Bulterman, D. C. A.; Van Rossum, G., The
Amsterdam hypermedia model: adding time and context to the Dexter
model, Communications of the ACM, v. 37, i. 2, 1994, p. 50-62. Disponível em
http://citeseer.ist.psu.edu/cache/papers/cs/17548/ftp:zSzzSzftp.cwi.nlzSzpubzSzm
mpaperszSzcacm.pdf/the-amsterdam-hypermedia-model.pdf. Acesso em 23 de
abril de 2007.
[ICE-CREAM, 2007] ICE-CREAM Consortium, Interactive Consumption of
Entertainment in Consumer Responsive, Engaging & Active Media.
Disponível em http://www.hitech-projects.com/euprojects/icecream. Acesso em
23 de fevereiro de 2007.
[ISO, 1998] ISO/IEC TR 13818-6. Information technology - Generic coding of
moving pictures and associated audio information - Part 6: Extensions for
DSM-CC, ISO Standard, 1998. Disponível em http://www.iec.ch/cgibin/getcorr.pl/isoiec13818-6-amd1-cor1%7Bed1.0%7Den.pdf?file=isoiec138186-amd1-cor1%7Bed1.0%7Den.pdf. Acesso 18 de março de 2007.
Referências Bibliográficas
87
[ISO, 2000] ISO/IEC 13818-1. Information technology - Generic coding of
moving pictures and associated audio information - Part 1: Systems. ISO
Standard, 2000. Disponível em http://webstore.iec.ch/preview/info_isoiec138181%7Bed2.0%7Den.pdf. Acesso em 29 de março de 2007.
[ISO, 2001] ISO/IEC 14496-1. Information technology - Coding of audiovisual objects - Part 1: Systems, ISO Standard, 2001. Disponível em
http://webstore.ansi.org/ansidocstore/product.asp?sku=INCITS%2FISO%2FIEC+
14496-1-2001%2FAM1-2001. Acesso em 18 de março de 2007.
[ISO, 2006] ISO/IEC 19757-3. Information technology - Document Schema
Definition Languages (DSDL) - Part 3: Rule-based validation - Schematron,
ISO
Standard,
2006.
Disponível
em
http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757
-3_2006(E).zip. Acesso em 17 de maio de 2007.
[Kamada & Kawai, 1989] Kamada, T.; Kawai, S., An algorithm for drawing
general undirected graphs, Information Processing Letters, v. 31, i. 1, p. 7-15,
Abril, 1989.
[Lamdon et al., 2003] Lamdon, J. L.; Cesar, P.; Herrero, C.; Vuorimaa, P., Usages
of a SMIL player in digital television, Proceedings of the VII International
Conference on Internet and Multimedia Systems and Applications – IASTED,
USA,
Agosto
de
2003.
Disponível
em
http://lib.tkk.fi/Diss/2005/isbn951227888X/article5.pdf. Acesso em 18 de março
de 2007.
[Microsoft, 2007a] Microsoft Corporation, Microsoft FrontPage. Disponível em
http://www.microsoft.com/frontpage/. Acesso em 22 de fevereiro de 2007.
[Microsoft, 2007b] Microsoft Corporation, Microsoft Windows XP
Professional.
Disponível
em
http://www.microsoft.com/windowsxp/pro/default.mspx. Acesso em 23 de maio
de 2007.
[Microsoft, 2007c] Microsoft Corporation, Windows Internet Explorer.
Disponível
em
http://www.microsoft.com/windows/products/winfamily/ie/default.mspx. Acesso
em 25de abril de 2007.
[Moreno et al., 2005] Moreno, M. F.; Costa, R. M. R.; Rodrigues, R. F.; Soares,
L. F. G., Edição de Documentos Hipermídia em Tempo de Exibição, X
Simpósio Brasileiro de Sistemas Multimídia e Hipermídia, Poços de Caldas,
Brasil, Dezembro de 2005. Disponível em ftp://ftp.telemidia.pucrio.br/pub/docs/conferencepapers/2005_12_moreno_webmedia.pdf. Acesso em 18
de março de 2007.
[Moura & Soares, 2001] Moura, M. S. A.; Soares, L. F. G., Relações Espaciais
em Documentos Hipermídia, Dissertação de Mestrado, Departamento de
Informática, PUC-Rio, Agosto de 2001. Disponível em ftp://ftp.telemidia.pucrio.br/pub/docs/theses/2001_08_moura.pdf. Acesso em 3 de abril de 2007.
Referências Bibliográficas
88
[Muchaluat-Saade et al., 2003] Muchaluat-Saade, D. C.; Silva, H. V. O; Soares, L.
F. G., Linguagem NCL versão 2.0 para Autoria Declarativa de Documentos
Hipermídia, IX Simpósio Brasileiro de Sistemas Multimídia e WEB - WebMídia
2003, Salvador, Brasil, Novembro de 2003. Disponível em ftp://ftp.telemidia.pucrio.br/pub/docs/conferencepapers/2003_11_muchaluat_webmidia.pdf. Acesso em
18 de março de 2007.
[Pemberton et al., 2002] Pemberton, S.; Austin, D.; Axelsson, J.; et al. XHTML
1.0 The Extensible HyperText Markup Language (Second Edition), 2002.
Disponível em http://www.w3.org/TR/xhtml1/. Acesso em 22 de fevereiro de
2007.
[Peng & Vuorimaa, 2001] Peng, C.; Vuorimaa, P., Digital Television
Application Manager, Proceedings of the IEEE International Conference on
Multimedia and Expo, 2001, Japão, Agosto de 2001. Disponível em
http://lib.tkk.fi/Diss/2002/isbn9512261723/article8.pdf. Acesso em 18 de março
de 2007.
[Peng et al., 2001] Peng, C.; Cesar, P.; Vuorimaa, P., Integration of Applications
into Digital Television Environment, Proceedings of the VII International
Conference on Distributed Multimedia Systems, Taiwan, Setembro de 2001.
Disponível em http://lib.tkk.fi/Diss/2002/isbn9512261723/article7.pdf. Acesso em
18 de maio de 2007.
[Pestov, 2007] Pestov, S., JEdit - Programmer’s Text Editor. Disponível em
http://www.jedit.org/. Acesso em 15 de março de 2007
[Pihkala et al., 2002] Pihkala, K.; Cesar, P.; Vuorimaa, P., A Cross-Platform
SMIL Player, Procedings of the International Conference on Communication,
Internet and Information - IASTED, USA, Novembro de 2002. Disponível em
http://lib.tkk.fi/Diss/2003/isbn9512268043/article7.pdf. Acesso em 18 de março
de 2007.
[Rodrigues & Soares, 2003] Rodrigues, R. F.; Soares, L. F. G., 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. Disponível em
ftp://ftp.telemidia.puc-rio.br/pub/docs/theses/2003_03_rodrigues.pdf. Acesso em
03 de abril de 2007.
[Silva et al., 2004] Silva, H. V.; Rodrigues, R. F.; Soares, L. F. G., Frameworks
para Processamento de Linguagens XML Modulares, Relatório Técnico,
Laboratório TeleMídia, PUC-Rio, Brasil, 2004.
[Soares & Rodrigues, 2006] Soares, L. F. G.; Rodrigues, R. F., Nested Context
Language 3.0 - Part 8 – NCL Digital TV Profiles. Monografias em Ciência da
Computação, n? 35/06, Departamento de Informática, PUC-Rio, Brasil, Outubro
de 2006. Disponível em http://www.ncl.org.br/documentos/NCL3.0-DTV.pdf.
Acesso em 24 de abril de 2007.
Referências Bibliográficas
89
[Soares et al., 2003] Soares, L. F. G.; Rodrigues, R. F.; Muchaluat-Saade, D. C.,
Modelo de Contextos Aninhados – versão 3.0, Relatório Técnico, Laboratório
TeleMídia, Departamento de Informática, PUC-Rio, 2003.
[Soares et al., 2004] Soares, L. F. G.; Colcher, S., Rodrigues; R. F., Relatório TV
Digital: Identificação dos Cenários Tecnológicos de Interesse, Laboratório
TeleMídia, PUC-Rio, 2004.
[Soares et al., 2006] Soares, L. F. G.; Rodrigues, R. F.; Costa, R. M. R., Part 6 NCL (Nested Context Language) Main Profile. Monografia no 15/06,
Departamento de Informática, PUC-Rio, Abril de 2006. Disponível em
http://www.ncl.org.br/documentos/ncl23-mainprofile.pdf. Acesso em 12 de março
de 2007.
[Sun, 1994] Sun Microsystems, Java Technology.
http://www.java.sun.com. Acesso em 22 de fevereiro de 2007.
Disponível
em
[Sun, 1997] Sun Microsystems, Java Native Interface (JNI). Disponível em
http://java.sun.com/j2se/1.5.0/docs/guide/jni/. Acesso em 23 de março de 2007.
[Sun, 2000] Sun Microsystems, Java TV API. Disponível
http://java.sun.com/products/javatv/. Acesso em 24 de fevereiro de 2007.
em
[Sun, 2003] Sun Microsystems, JavaHelp System. Disponível em
http://java.sun.com/products/javahelp/index.jsp. Acesso em 15 de abril de 2007.
[Vignoni, 2007] Vignoni, D., Nuvola 1.0 for KDE 3.x. Disponível em http://iconking.com/?p=15. Acesso em 14 de março de 2007.
[W3C, 1999a] W3C - World-Wide Web Consortium, HTML 4.01 Specification.
W3C
Recommendation,
Dezembro
de
1999.
Disponível
em
http://www.w3.org/TR/html401/. Acesso em 22 de fevereiro de 2007.
[W3C, 1999b] W3C - World-Wide Web Consortium, Hypertext Transfer
Protocol -- HTTP/1.1. RFC2616, Junho de 1999. Disponível em
http://www.w3.org/Protocols/rfc2616/rfc2616.html. Acesso em 24 de abril de
2007.
[W3C, 2001] 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 23 de
fevereiro de 2007.
[W3C, 2004a] W3C - World-Wide Web Consortium, Extensible Markup
Language
(XML)
1.1,
Fevereiro
de
2004.
Disponível
em
http://www.w3.org/TR/2004/REC-xml11-20040204/. Acesso em 22 de fevereiro
de 2007.
[W3C, 2004b] W3C - World-Wide Web Consortium, Cascading Style Sheets
(CSS), Fevereiro de 2004. Disponível em http://www.w3.org/Style/CSS/. Acesso
em 22 de fevereiro de 2007.
Referências Bibliográficas
90
[W3C, 2004c] W3C - World-Wide Web Consortium, Document Object Model
(DOM) Level 3, W3C Recommendation, Abril de 2004. Disponível em
http://www.w3.org/TR/DOM-Level-3-Core/. Acesso em 22 de fevereiro de 2007.
[WAM, 2007] WAM (Web Adaptation Multimedia), LimSee2 - The crossplatform SMIL2.0 authoring tool, INRIA - Grenoble, France. Disponível em
http://wam.inrialpes.fr/software/limsee2/. Acesso em 27 de fevereiro de 2007.
[Williams, 2002] Williams, M., ActionScript Coding Standards, Macromedia
White
Paper,
Março
de
2002.
Disponível
em
http://www.adobe.com/devnet/flash/whitepapers/actionscript_standards.pdf.
Acesso em 24 de abril de 2007.
A
Linguagens, Sincronismo e Interatividade
Este capítulo está organizado da seguinte forma. A Seção A.1 apresenta
como as linguagens Java e HTML (XHTML) são adotadas no desenvolvimento de
aplicações voltadas para TV digital. A Seção A.2 apresenta algumas linguagens
que representam modelos hipermídia, as linguagens declarativas, e como elas
podem ser usadas pelos padrões de TV digital interativa.
A.1.
Linguagens nos padrões de TV digital
Os padrões atuais de TV digital (Soares et al., 2004) oferecem linguagens
para a especificação da interatividade e do sincronismo nas aplicações. Em
comum, as aplicações especificadas em Java, e em XHTML + linguagens de
scripts, como ECMAScript (ECMA, 1999), apresentam restrições à autoria, pois
requerem
conhecimentos
de
programação
para
serem
utilizadas
no
desenvolvimento de aplicações. As Subseções A.1.1 e A.1.2 apresentam como as
linguagens Java e XHTML, respectivamente, são adotadas pelos principais
padrões de TV digital, apresentando suas características.
A.1.1.
Linguagens baseadas em Java
As linguagens DVB-J, ACAP-J e ARIB-B23, relativas, respectivamente,
aos padrões DVB (Digital Video Broadcast), ATSC (North-America/US
Advanced Television Systems Committee) e ISDB (Integrated Services Digital
Broadcasting) (Soares et al., 2004), têm como principal diferença os conjuntos de
classes que cada padrão implementa. Em todas essas linguagens, que são
linguagens procedurais baseadas na tecnologia Java, sem exceção, o programador
deve modelar o conjunto de objetos da aplicação e a relação entre esses objetos.
Na especificação dos objetos através de uma linguagem orientada a objetos,
é função do programador definir a estrutura de dados interna de cada objeto e as
Apêndice A: Linguagens, Sincronismo e Interatividade
92
interfaces que serão utilizadas na comunicação com os outros objetos da aplicação
(encapsulamento). Nesse paradigma de linguagem, objetos podem ser
instanciados a partir de um conjunto hierárquico de classes definidas pelo
middleware, herdando a estrutura de dados dessas classes e suas respectivas
interfaces (herança). Além disso, durante a execução, um objeto pode ser
instanciado a partir de uma das diversas classes dentro da hierarquia na qual ele
foi definido, adquirindo um comportamento distinto de acordo com a instância
escolhida (polimorfismo).
Nas linguagens DVB-J, ACAP-J e ARIB-B23, as relações entre os objetos
são especificadas através de métodos, onde o programador deve especificar uma
sucessão de passos a serem seguidos utilizando estruturas de controle, variáveis e
chamadas a outros métodos. As linguagens desses padrões são, portanto, baseadas
em uma linguagem de programação de propósito geral, onde o programador
dispõe de muitos recursos para a especificação da aplicação. Em contrapartida,
existe uma razoável complexidade na especificação dessas aplicações.
Por assim serem, as linguagens DVB-J, ACAP-J e ARIB-B23, não
apresentam mecanismos diretos para a especificação de sincronismo e
interatividade na construção de aplicações hipermídia. Essas especificações
devem ser realizadas pelo programador de acordo com os métodos existentes nos
conjuntos de classes (pacotes) oferecidas pelo middleware.
Entre os conjuntos de classes que podem ser encontrados nos diversos
middlewares dos padrões DVB, ATSC e ISDB, podem ser destacadas as classes
para o desenvolvimento de interfaces gráficas AWT (Abstract Window Toolkit) e
JMF (Java Media Framework), além das classes para transmissão de dados
DAVIC (Digital Audio Video Interactive Consortium) e para interconexão de
dispositivos HAVi (Home Audio/Video Interoperability). Maiores detalhes sobre a
especificação desses pacotes podem ser encontrados no relatório “Análise das
Alternativas Tecnológicas” (FLEXTV, 2004).
Os pacotes da implementação JavaTV (Sun, 2000) também são usualmente
encontrados nos middlewares dos padrões de TV digital. As classes definidas no
pacote javax.tv.xlet merecem destaque por implementarem o ciclo de vida das
aplicações. As aplicações criadas a partir das classes definidas nesse pacote são
genericamente denominadas Xlets. Os Xlets são controlados por um gerenciador
de aplicações (application manager) que faz parte do middleware e reside no set-
Apêndice A: Linguagens, Sincronismo e Interatividade
93
top box (Peng & Vuorimaa, 2001). As principais funções do gerenciador de
aplicações são: sinalizar as mudanças de estados dos Xlets e controlar os recursos
do middleware a partir da programação do Xlet.
Os Xlets podem estar residentes no set-top box ou serem recebidos por
carrossel (transporte cíclico) de objetos ou de dados (Soares et al., 2004). Todo o
controle dos Xlets é realizado pelo gerenciador de aplicações, incluindo a
iniciação, que pode ocorrer de duas formas: o Xlet pode estar temporalmente
sincronizado com o fluxo de transporte MPEG-2 (ISO, 2000), correspondente ao
fluxo de áudio e vídeo principal, ou pode ser iniciado pela ação do usuário. Em
ambas as formas, é importante que os Xlets possuam baixa latência de iniciação
(Peng et al., 2001), a fim de preservar a sincronização da aplicação com o
conteúdo audiovisual principal.
A Figura 33 apresenta os quatro estados de um Xlet: carregado (loaded),
pausado (paused), iniciado (started) e destruído (destroyed) (Soares et al., 2004).
O gerenciador de aplicações é capaz de controlar múltiplas aplicações
simultâneas, no entanto, somente uma aplicação é visível em um dado instante de
tempo. No contexto dos estados, somente um Xlet, em um dado instante de tempo,
pode se encontrar no estado iniciado.
Figura 33 - Ciclo de vida de um Xlet
Quando o gerenciador de aplicações recebe um novo Xlet, o construtor desse
Xlet é executado. Durante a execução do construtor, o Xlet encontra-se no estado
carregado. Posteriormente, quando uma das condições de iniciação do Xlet ocorre,
o método initXlet() da aplicação é executado, tendo como parâmetro o contexto9
9
As informações do contexto incluem, principalmente, os recursos alocados por um Xlet,
como arquivos ou acesso a dispositivos de entrada e saída. Esses recursos somente são liberados
quando o Xlet é destruído.
Apêndice A: Linguagens, Sincronismo e Interatividade
94
do Xlet. Nesse momento, o Xlet passa para o estado pausado. A partir desse ponto,
quando o método startXlet() é executado, o Xlet passa para o estado iniciado. A
qualquer momento, durante o estado iniciado de um Xlet, o gerenciador de
aplicações pode solicitar a execução do método pauseXlet() e retornar a aplicação
para o estado pausado. Quando um Xlet termina sua execução, o seu método
destroyXlet() é executado e os recursos alocados são liberados. As condições de
término de um Xlet são idênticas às condições de iniciação.
A.1.1.1.
Sincronismo e Interatividade nas linguagens baseadas em Java
Conforme mencionado no início deste capítulo, para definir o sincronismo e
interatividade em aplicações através da linguagem Java, é necessário que o autor
tenha conhecimentos de programação. Nessa linguagem, os eventos de
sincronismo e interatividade, bem como os demais eventos que podem ocorrer em
uma aplicação multimídia, são, em sua maioria, implementados através de
observadores (listeners). Esses observadores são instanciados nos Xlets que
constituem as aplicações.
Os observadores nas aplicações Java para TV digital podem ser utilizados
desde o início da apresentação. Para receber o conteúdo dos objetos, preservando
o controle sobre a aplicação, os Xlets podem utilizar threads Java para realizar o
carregamento do conteúdo dos objetos de mídia de forma assíncrona.
Como exemplo de acesso assíncrono aos objetos de mídia, a linguagem
DVB-J, através da classe org.dvb.dsmcc.DSMCCObject, implementa o acesso aos
objetos transmitidos por carrossel. A classe DSMCCObject deve receber no seu
construtor o objeto Java que instancia o carrossel e o caminho (path) do objeto de
mídia solicitado pela aplicação. O acesso ao objeto de mídia pode ser feito de
forma assíncrona utilizando o método asynchronousLoad(), do objeto da classe
DSMCCObject. Esse método recebe como parâmetro um observador, cuja classe é
definida a partir da especificação da classe java.util.EventListener. Essa classe
deve ser projetada para avisar a aplicação (Xlet), quando o objeto de mídia estiver
carregado.
Para implementar os pontos de sincronização pertencentes a um fluxo
(stream events), as linguagens baseadas em Java também utilizam observadores.
Apêndice A: Linguagens, Sincronismo e Interatividade
95
Como exemplo, na linguagem DVB-J, o controle dos stream events é realizado
pela classe org.dvb.dsmcc.DSMCCStreamEvent. Para instanciar um objeto dessa
classe, deve ser passado como parâmetro ao seu construtor, um objeto da classe
DSMCCObject. Nesse caso, a aplicação irá monitorar os pontos de sincronização
que forem recebidos e que estejam relacionados ao objeto passado como
parâmetro ao construtor da classe.
Para cada tipo de stream event definido pela aplicação, deve ser definido um
observador correspondente. Os observadores, definidos a partir da especificação
da classe java.util.EventListener, devem ser associados aos tipos de stream events
através do método subscribe() do objeto da classe DSMCCStreamEvent. Caso um
tipo de stream event seja considerado irrelevante pela aplicação, o observador a
ele associado deve ser desativado através da chamada ao método unsubscribe().
Além dos eventos de sincronização do DSM-CC (Digital Storage Media
Command and Control) (ISO, 1998), as aplicações para TV digital, especificadas
através das linguagens DVB-J, ACAP-J e ARIB-B23 podem capturar eventos de
interatividade originados pelo usuário. Para definir esses eventos, podem ser
utilizadas as classes definidas no pacote HAVi, como por exemplo, a classe
org.havi.ui.event.HRcEvent que especifica os eventos das teclas do controle
remoto.
Para exemplificar o controle de eventos relacionados à interatividade,
considere um aplicativo (Xlet) na linguagem DVB-J, que instancia um repositório
relativo aos tipos de teclas cujo pressionamento deve ser monitorado. Esse
repositório é instanciado através da classe org.dvb.event.UserEventRepository, e
pode, por exemplo, conter os eventos relativos às teclas coloridas, através do
método addAllColorKeys(), ou os eventos relativos às teclas numéricas, através do
método addAllNumericKeys(), bem como outros eventos, relativos às demais
teclas encontradas em controles de televisores.
Nesse Xlet, a partir da definição do repositório, deve ser definido um
gerenciador de eventos (event manager) para controlar, através de um observador,
a ocorrência dos eventos relativos às teclas definidas no repositório. O
gerenciador de eventos é instanciado através do método estático getInstance(),
definido na classe org.dvb.EventManager. O observador, que implementa a classe
org.dvb.UserEventListener, deve ser passado como parâmetro ao objeto da classe
EventManager, através do método addUserEventListener(). Os eventos retornados
Apêndice A: Linguagens, Sincronismo e Interatividade
96
ao observador são definidos na classe org.dvb.event.UserEvent. A Figura 34
apresenta, como exemplo, um trecho de uma classe que especifica o controle de
eventos no DVB-J.
class App implements UserEventListener{
public App () {
EventManager em ;
UserEventRepository repository ;
em = EventManager.getInstance () ;
repository = new UserEventRepository ("R1") ;
repository.addKey (UserEvent.VK_ENTER) ;
em.addUserListener ((UserEventListener) this, repository) ;
em.addResourceStatusEventListener (this) ;
}
/**
* método definido pela interface UserEventListener.
*/
public void UserEventReceived (UserEvent e) {
/* tratamento do evento */
}
}
Figura 34 - Exemplo do controle de eventos no DVB-J
Na Figura 34, a classe denominada App implementa o observador de
eventos (UserEventListener). No construtor da classe App são instanciados o
gerenciador de eventos, através do objeto em, e o repositório R1, através do objeto
repository. Ao repositório é adicionado apenas o evento da tecla de confirmação
(VK_ENTER). Quando essa tecla é pressionada, o método UserEventReceived()
do observador é chamado, recebendo como parâmetro o objeto e da classe
UserEvent. A classe UserEvent define métodos que caracterizam os eventos,
como o método getCode(), que retorna o código da tecla pressionada. Esse
método seria útil, por exemplo, se mais de uma tecla fosse especificada no
repositório, permitindo um tratamento diferenciado de acordo com a tecla
acionada pelo usuário.
A.1.2.
Linguagens baseadas em HTML
Adicionalmente às linguagens baseadas em Java, são definidas linguagens
baseadas em HTML para a especificação de aplicações nos padrões de TV digital.
As linguagens baseadas em HTML favorecem, a princípio, a autoria, em função
da simplicidade e da difusão do HTML como linguagem para formatação de
documentos na Web (World-Wide Web ou WWW) (Berners-Lee et al., 1994). No
entanto, é importante ressaltar que as funcionalidades do HTML são restritas,
Apêndice A: Linguagens, Sincronismo e Interatividade
97
quando é necessário realizar especificações de sincronismo e de interatividade
(que não só a de relacionamentos de referência). Para superar essa limitação o
HTML é adotado em conjunto com linguagens de script. Nesse caso, a
complexidade da especificação torna-se próxima à complexidade da programação
procedural ou orientada a objetos10.
De forma similar às linguagens baseadas em Java, as linguagens dos
padrões de TV digital baseadas em HTML utilizam um conjunto de recursos
oferecidos pelos middlewares. Entre esses recursos, podem ser destacados os
interpretadores de tecnologias relacionadas ao HTML, como o DOM (Document
Object Model) (W3C, 2004c) e CSS (Cascading Style Sheets) (W3C, 2004b). Em
relação às linguagens (baseadas em HTML) DVB-HTML, ACAP-X e BML/BXML definidas pelos padrões DVB, ATSC e ISDB, respectivamente, pode haver
variações quanto à versão ou a disponibilidade dos recursos no middleware,
porém, no contexto geral, todas elas suportam os recursos já citados e,
adicionalmente, uma linguagem de script.
As aplicações nas linguagens baseadas em HTML possuem um ciclo de vida
similar ao ciclo das aplicações baseadas em Java. No DVB-HTML, por exemplo,
podem haver várias aplicações simultâneas, controladas por uma entidade
denominada agente do usuário (user agent), residente no middleware (Soares et
al., 2004). A Figura 35 apresenta os cinco estados de uma aplicação DVB-HTML:
carregando (loading), pausado (paused), ativo (active), destruído (destroyed) e
finalizado (killed).
10
As linguagens de script, como o ECMAScript, usualmente podem ser definidas através
de construções típicas do paradigma procedural, ou, em alguns casos, utilizando objetos e as
características do paradigma orientado a objetos.
Apêndice A: Linguagens, Sincronismo e Interatividade
98
Figura 35 - Ciclo de vida de uma aplicação DVB-HTML
Quando uma aplicação DVB-HTML é recebida, ela encontra-se no estado
carregando. Nesse estado, a aplicação deve realizar o acesso ao conteúdo dos
objetos de mídia referenciados. Se todos os conteúdos iniciais estiverem
disponíveis, a aplicação é alterada para o estado ativo. Uma vez no estado ativo,
uma aplicação pode ser transferida para o estado pausado, em virtude de alguma
restrição nos recursos necessários à aplicação ou ainda, devido ao fato da
aplicação ter provocado alguma violação das permissões de acesso aos recursos.
Uma aplicação no estado pausado pode ser reativada e voltar para o estado ativo,
quando terminarem as restrições que levaram a aplicação a esse estado. Quando a
aplicação é removida do sistema, por exemplo, pela perda de um recurso, definese que ela encontra-se no estado destruído (destroyed). Finalmente, quando a
aplicação termina sua execução, ela muda para o estado finalizado (killed). Nesse
estado todos os recursos utilizados pela aplicação são liberados.
As linguagens baseadas em HTML utilizadas nos padrões de TV digital são,
no geral, integradas às linguagens baseadas em Java do mesmo padrão. Nos
padrões DVB e ATSC, todos os recursos do middleware disponíveis para as
aplicações Java, estão disponíveis para as aplicações baseadas em HTML. O
acesso às APIs (Application Programming Interface) dos middlewares é oferecido
através de chamadas usando a linguagem ECMAScript.
Além do acesso às APIs Java, nos padrões DVB e ATSC, as linguagens
baseadas em HTML podem exibir aplicações construídas nas linguagens DVB-J e
ACAP-J, respectivamente, como se fossem mais um conteúdo sincronizado ao
áudio e vídeo principal. Como exemplo, a Figura 36 apresenta um trecho de
programa especificado em DVB-HTML, onde o elemento object, é responsável
Apêndice A: Linguagens, Sincronismo e Interatividade
99
pela exibição de aplicações especificadas em DVB-J. Nesse exemplo, o Xlet
MyApplication.class é exibido na região delimitada pelo elemento object e
receberá como parâmetros os valores passados por arg_0 e arg_1.
<object type = “application/dvbj” id = “myApplication”
codetype = “application/javatv-xlet”
classid = “MyApplication.class”
codebase = “myApplication/”
height = “200” width = “150”>
<param name = “arg_0” value = “param1” />
<param name = “arg_1” value = “param2” />
<embed height = “200” width = “150”
arg_0 = “param1” arg_1 = “param2”>
</embed>
</object>
Figura 36 - Exemplo de chamada de aplicativo DVB-J no DVB-HTML
A.1.2.1.
Sincronismo e Interatividade nas linguagens baseadas em HTML
No contexto geral, as linguagens baseadas em HTML, DVB-HTML,
ACAP-X e BML/B-XML, tratam os eventos de sincronismo e interatividade de
forma similar às linguagens baseadas em Java, DVB-J, ACAP-J e ARIB-B23,
respectivamente. Essa característica deve-se ao uso do HTML em conjunto com o
ECMAScript, que possui características do paradigma orientado a objetos.
Para implementar os pontos de sincronização pertencentes a um fluxo
(stream events), as linguagens baseadas em HTML, no geral, também utilizam
observadores (listeners). Em ECMAScript, os observadores podem ser definidos
em relação a eventos DOM. Para permitir o uso desses eventos em aplicações
especificadas em HTML, os middlewares realizam a conversão de stream events
para eventos DOM.
Como exemplo, no middleware do DVB a conversão de stream events para
eventos DOM é realizada através das especificações contidas em um arquivo
XML denominado event factory. Esse arquivo deve ser colocado no mesmo
diretório DSM-CC do arquivo DVB-HTML, com o mesmo nome, porém com a
extensão lnk. A Figura 37 apresenta um código DVB-HTML que define uma
função a ser executada quando o evento denominado myTriggerEvent for
recebido. Nesse exemplo, quando o arquivo DVB-HTML é carregado, a função
setupEventListeners() é executada. Essa função apenas informa ao observador do
documento, através do método addEventListener(), que a função handleEvent()
deve ser executada quando o evento denominado myTriggerEvent for recebido.
Apêndice A: Linguagens, Sincronismo e Interatividade
100
Conforme mencionado, a associação entre o nome myTriggerEvent e os stream
events que são recebidos pela aplicação é definida no arquivo event factory.
<?xml version =”1.0”?>
<!DOCTYPE html PUBLIC “//DVB//DTD XHTML DVB-HTML 1.0//EN”
“http://www.dvb.org/mhp/dtd/dvbhtml-1-0.dtd” >
<html xmlns = “http://www.w3.org/1999/xhtml”
xmlns:dvbhtml = “http://www.dvb.org/mhp” >
<head>
<script type = ”text/ecmascript”>
function handleEvent(evt) {
/*código do evento*/
}
function setupEventListeners() {
var htmlNode = document.documentElement;
htmlNode.addEventListener(
“myTriggerEvent”, handleEvent, true);
}
</script>
</head>
<body dvbhtml:
</body>
</html>
Figura 37 - Tratamento de stream events no DVB-HTML
Nas linguagens baseadas em HTML, os eventos de interatividade podem, a
princípio, ser definidos através de relacionamentos de referência, utilizando os
elos HTML. Os elos são disparados por eventos de interatividade, como o
pressionamento de uma tecla específica do controle remoto, e podem ter como
ação a exibição de um novo documento. Outras ações também podem ser
executadas, como, por exemplo, a execução de funções ECMAScript.
A Figura 38 mostra, como exemplo, um trecho de um documento DVBHTML contendo um elo que define um relacionamento de referência para outro
documento. No exemplo, o elo definido pela tag a, tem configurado o atributo
accesskey com valor &VK_GUIDE; que equivale a ação de pressionar a tecla do
guia de programação no controle remoto. No DVB-HTML, os mnemônicos
relativos às teclas do controle remoto são definidos na DTD (Document Type
Definition) dessa linguagem.
<?xml version =”1.0”?>
<!DOCTYPE html PUBLIC “//DVB//DTD XHTML DVB-HTML 1.0//EN”
“http://www.dvb.org/mhp/dtd/dvbhtml-1-0.dtd” >
<html xmlns = “http://www.w3.org/1999/xhtml”
xmlns:dvbhtml = “http://www.dvb.org/mhp” >
<head> </head>
<body>
<a accesskey=”&VK_GUIDE;” href=”guide/contents.html”>
informações do guia de serviços
</a>
</body>
</html>
Figura 38 - Elo de interatividade no DVB-HTML
Mais detalhes sobre linguagens nos padrões de TV digital podem ser
encontrados em (Soares et al., 2004).
Apêndice A: Linguagens, Sincronismo e Interatividade
101
A.2.
Linguagens Declarativas
Para superar a complexidade no desenvolvimento de aplicações para TV
digital utilizando linguagens baseadas em Java ou em HTML + scripts, linguagens
declarativas podem ser utilizadas. As linguagens declarativas favorecem a autoria,
pois permitem representar as relações entre eventos em documentos
multimídia/hipermídia sem que seja necessário especificar estruturas complexas,
como estruturas de controle, repetição, variáveis, observadores etc. Em outras
palavras, além de possuírem uma estrutura de marcação (XML), cada marcação
tem um significado semântico que permite representar, inclusive, eventos de
sincronismo e interatividade.
Atualmente, as linguagens declarativas não são encontradas, de forma
efetiva, nos padrões de TV digital. No entanto, essas linguagens são amplamente
difundidas para a modelagem de aplicações multimídia/hipermídia, com destaque
para as linguagens SMIL (Bulterman & Rutledge, 2004) e NCL (Muchaluat-Saade
et al., 2003)11.
A linguagem SMIL (Synchronized Multimedia Integration Language) é uma
linguagem baseada em XML, e especificada pelo W3C (W3C, 2001), que permite
a descrição de apresentações multimídia interativas. Essa linguagem é bastante
intuitiva para o desenvolvimento de apresentações, pois é possível definir de
forma simples como os objetos de mídia estarão dispostos no tempo através de um
conjunto básico de composições que possuem semântica de sincronização. São
três os tipos de composições de sincronização temporal:
• Seqüencial (seq): os objetos de mídia são executados seqüencialmente,
onde um objeto nunca começa antes que seu predecessor termine;
• Paralela (par): os objetos de mídia são executados em paralelo. Isso não
significa que eles terminarão juntos, mas sim que esses objetos são
iniciados simultaneamente;
11
Além dessas linguagens, outras poderiam ser citadas. A linguagem declarativa do padrão
MPEG-4, XMT-O [ISO, 2001] poderia ser utilizada para especificar eventos nas aplicações para
TV digital. No caso específico do XMT-O, os módulos de sincronismo e interatividade são
praticamente os mesmos da linguagem SMIL. Dessa forma, as definições de SMIL para TV digital
também podem ser aplicadas no caso do XMT-O.
Apêndice A: Linguagens, Sincronismo e Interatividade
102
• Exclusiva (excl): somente um objeto de mídia que compõe esse tipo de
composição pode estar ativo por vez. A ativação desses objetos é
geralmente feita sob demanda, como por exemplo, ao ocorrer um
evento de clique (begin=”button1.activateEvent”).
Vale ressaltar que as composições SMIL podem ser aninhadas para
elaboração de uma apresentação, ou seja, uma composição pode ser composta por
objetos de mídia e/ou outras composições, e assim recursivamente.
Já a NCL (Nested Context Language) é uma linguagem para autoria de
documentos hipermídia baseada no modelo conceitual NCM (Nested Context
Model) (Soares et al., 2003). Para compreender as características dessa linguagem,
é importante compreender as características do modelo no qual ela é baseada. No
modelo NCM um documento hipermídia é representado por um nó de
composição, podendo este conter um conjunto de nós que podem ser objetos de
mídia ou outros nós de composição, recursivamente, e ainda elos relacionando
esses nós.
Nós de composição no modelo NCM não têm nenhuma semântica embutida,
diferente das composições SMIL que, por exemplo, têm semântica temporal. A
semântica dos relacionamentos entre as entidades de um documento é feita através
dos elos NCM, que podem especificar relações de referência, relações de
sincronização, relações de derivação, relações entre tarefas de um trabalho
cooperativo etc. Os elos NCM são definidos fazendo referência a um conector
hipermídia, que pode representar qualquer tipo de relação. Além da referência a
um conector, um elo define um conjunto de binds associando papéis do conector a
nós do documento. Elos ainda podem representar relacionamentos multiponto
entre vários nós de um documento.
A.2.1.
Sincronismo e Interatividade nas linguagens declarativas
As linguagens SMIL e NCL são compostas por um conjunto de módulos
que agrupam elementos com funcionalidades semelhantes. Ambas as linguagens
definem um conjunto de módulos destinados a suportar eventos de sincronismo e
de interatividade.
Apêndice A: Linguagens, Sincronismo e Interatividade
103
Na linguagem SMIL, as composições são definidas nos módulos
BasicTimeContainers (par e seq) e ExclTimeContainers (excl). Além das
composições com semântica de sincronização, os relacionamentos também podem
ser definidos pela igualdade de eventos. Utilizando eventos de início da
apresentação do nó (begin), término da apresentação do nó (end), seleção espacial
(click) e alguns outros (Bulterman & Rutledge, 2004), é possível estabelecer
relacionamentos de sincronização entre nós (objetos de mídia, por exemplo) de
um documento.
O módulo BasicInlineTiming define os atributos begin e end, que podem ser
utilizados nos elementos que representam os objetos de mídia e as composições.
Nesse ponto vale destacar que os eventos de início e término de apresentação
(begin e end, respectivamente) desempenham papéis muito parecidos ao de elos
NCM. No módulo BasicInlineTiming também é definido o atributo dur, que
especifica a duração explicita de um objeto de mídia ou de uma composição.
Em relação à interatividade, SMIL define eventos relativos às ações do
mouse (mouse up, down, out e over) no módulo SyncbaseTiming, e do teclado no
módulo AccessKeyTime12.
Na linguagem NCL, os relacionamentos entre eventos são definidos através
do perfil XConnector (Muchaluat-Saade et al., 2003), o qual permite especificar
conectores definindo relações entre eventos. Existem diversos tipos de eventos
que podem ser referenciados nos conectores, incluindo eventos de sincronismo e
de interatividade.
Um conector especifica a relação, sem mencionar os nós que irão participar
do relacionamento. Elos definem um relacionamento fazendo referência a um
conector hipermídia e a um conjunto de associações, que definem os participantes
do relacionamento.
A princípio, no SMIL a especificação de relacionamentos de sincronização é
mais fácil, pois as composições possuem semântica de sincronização. No entanto,
esse benefício é limitado pela existência de um conjunto simples de composições
(seqüencial, paralela e exclusiva), e isso pode dificultar a definição de
12
Em XMT-O, adicionalmente a SMIL, é definido o módulo XMTEvents com outros
eventos relativos à apresentação, tais como: colisão e aproximação de objetos em animações,
visibilidade etc.
Apêndice A: Linguagens, Sincronismo e Interatividade
104
relacionamentos complexos, podendo ser necessário, para esses casos, estabelecer
composições com vários níveis de aninhamento, ou o uso de eventos SMIL, que
podem fazer com que a composição perca sua semântica associada.
Na linguagem NCL, as composições podem herdar a semântica definida em
um outro perfil da linguagem denominado XTemplate (Muchaluat-Saade et al.,
2003). Nesse perfil, os templates de composição especificam tipos de
componentes, tipos de relações, componentes e relacionamentos que uma
composição possui ou pode possuir, sem identificar todos os componentes e
relacionamentos, pois essa especificação fica sob responsabilidade da composição
que utilizar o template. Como caso particular pode ser definida a semântica das
composições SMIL.
Em relação aos stream events que podem ser recebidos pelo middleware
estabelecendo pontos de sincronização em relação a um fluxo, a linguagem SMIL
não define um perfil que manipule esse tipo de evento através da linguagem. De
forma similar, na linguagem NCL não existem elementos nos módulos que
possam formar um perfil voltado para o tratamento de stream events. No entanto,
o uso da linguagem NCL para aplicações de TV digital prevê a recepção dos
stream events pelo middleware, onde esses metadados serão interpretados para
modificação da especificação da linguagem durante a exibição.
Em (Costa et al., 2006) é proposta uma arquitetura onde os stream events
são tratados como metadados para edição do modelo que a especificação em NCL
de uma aplicação qualquer representa. É relativamente comum a interpretação dos
stream events pelo middleware nas linguagens dos padrões para TV digital
descritas na Seção A.1. Nessas linguagens, os stream events são convertidos em
eventos detectáveis aos observadores das linguagens, que, por sua vez, podem
definir métodos para implementar as ações correspondentes aos eventos
recebidos.
Na linguagem NCL, os stream events podem ser criados a partir de
operações de edição realizadas durante a apresentação das aplicações (edição ao
vivo). Entre outras vantagens, essa proposta preserva a estrutura original do
documento no ambiente de execução.
A proposta apresentada em (Costa et al., 2006) evita também a necessidade
de operações complexas de programação para definir métodos ou funções
condicionais em relação aos stream events recebidos. Essa proposta integra os
Apêndice A: Linguagens, Sincronismo e Interatividade
105
ambientes de autoria e de execução, abstraindo do autor a criação ou a semântica
dos stream events, cujo controle fica completamente a cargo do editor e do
exibidor. Com isso, o autor precisa apenas se preocupar com a semântica do
documento e não com a forma com que o sincronismo será implementado.
Em algumas propostas de middleware para SMIL, como em (Pihkala et al.,
2002), (Lamdon et al., 2003) e (ICE-CREAM, 2007), não é mencionado como os
stream events podem ser tratados. Nessas propostas, a linguagem SMIL é
utilizada em conjunto com um middleware procedural definido nos padrões de TV
digital. A Figura 39 apresenta a arquitetura proposta em (ICE-CREAM, 2007).
Figura 39 - Proposta de uma arquitetura SMIL para TV digital
A proposta apresentada na Figura 39 define um Xlet capaz de interpretar
especificações de um documento SMIL. O Xlet, por sua vez, é implementado em
Java, sobre um middleware MHP. O Xlet acessa as funções do middleware,
através da sua API, com o objetivo de interpretar e obedecer às especificações de
um perfil SMIL voltado para TV digital. O perfil em questão é similar aos perfis
SMIL que podem ser normalmente definidos através da linguagem. Nesse caso, a
diferença consiste em alguns módulos, como o módulo AccessKeyTime, da área
funcional Timing, que tem alguns elementos estendidos a fim de capturar eventos
gerados pelas teclas do controle remoto.
A Figura 40 ilustra a arquitetura proposta em (Pihkala et al., 2002) e
(Lamdon et al., 2003). Na realidade, as características dessa arquitetura são
similares às características apresentadas em (ICE-CREAM, 2007). Nela o
gerenciador de aplicações controla Xlets que podem ser interpretadores SMIL ou
outras aplicações quaisquer.
Apêndice A: Linguagens, Sincronismo e Interatividade
Figura 40 - Gerenciamento de Xlets contendo interpretadores SMIL
106