Sistema Brasileiro de Televisão Digital

Ministério das Comunicações

Comunicações

Título do documento
Especificação dos Testes do Objeto Informações sobre a autoria
Contratado

Subtítulo:
Convênio:
Convênio 2028/04 em atendimento a carta convite
Produto: MC/MCT/FINEP/FUNTTEL-TV Digital - 07/2004
Portal, Guia Eletrônico de Programação e
Aplicações

Tema:
Consórcio:
Serviços, Aplicações e Conteúdo para TV
Digital RFP7DFPRSP

Palavras-chave:
Testes de Integração;Aplicações;Portal de Entidades participantes do consórcio:
Acesso
Executor: BRISA
Co-executores: UnB;UFPR;Lactec;PUCPR

Intervenientes:
TVA
Classificação do documento:
SBTVD

Autoria:
Evolução:
Jorge Henrique Cabral Fernandes
Arquivo: EspTesteIntegracao_v0.9.sxw Eduardo Silva et alii
Data: 10/11/2005 Leandro Vaguetti et alii
Isaias José Amaral Soares
Éverton Vidal Vieira

Faculdade de Tecnologia
Universidade de Brasília
Informações da autoria
Nome (ordem alfabética) Telefone E-mail Instituição
Jorge Henrique Cabral +55 61 3273-3589 R.
jhcf@unb.br UnB
Fernandes 234
Eduardo Silva et alii +55 61 3323-8969 eduardo silva@brisa.org.br BRISA
+55 61 3307-2308 R.
Leandro Vaguetti et alii
218 vaguetti@ieee.org UnB
Isaias José Amaral Soares +55 41 3361-3683 isoares01@yahoo.com UFPR
Éverton Vidal Vieira +55 41 3361-3683 evv95@yahoo.com.br UFPR

Histórico de atualizações deste documento

Versão Situação Data Descrição

Impresso no Brasil

As informações contidas neste documento são confidenciais e proprietárias conforme previsto no

Convênio 2028/04, estabelecido entre a FINEP e as instituições que formam o consórcio , sendo
proibida a sua divulgação, reprodução ou armazenamento em base de dados ou sistema de
recuperação sem permissão prévia e por escrito dos detentores. Estão sujeitas a alterações sem
notificação prévia.
Os nomes de produtos, serviços ou tecnologias eventualmente mencionadas neste documento são
marcas registradas dos respectivos detentores.
Fazer cópias de qualquer parte deste documento para qualquer finalidade, além do uso pessoal,
constitui violação das leis internacionais de direitos autorais.
 Sumário
1 Introdução....................................................................................................................................... 4
1.1 Objetivos.................................................................................................................................. 4
1.2 Escopo..................................................................................................................................... 4
1.3 Definições, Acrônimos e Abreviaturas.................................................................................... 4
1.4 Documentos Relacionados......................................................................................................4
2 Visão geral do SIStema.................................................................................................................. 4
2.0.1 Solução TVGrama........................................................................................................... 4
2.0.2 Solução Portal..................................................................................................................8
2.0.3 Solução Declaração de Isento....................................................................................... 11
2.0.4 Solução Aplicação Multimídia 3D.................................................................................. 14
3 REFERÊNCIAS............................................................................................................................. 23
4 HISTÓRICO DE ALTERAÇÕES DESTE DOCUMENTO............................................................. 24

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 3/24

1 INTRODUÇÃO

1.1 Objetivos
Este documento descreve os testes que devem ser feitos visando demonstrar a integração entre as aplicações e serviços
desenvolvidas pelo Consórcio BRISA UnB UFPR Lactec com o Middleware de referência desenvolvido pelos
consórcios que atuam em RFPs de Middleware no âmbito do Sistema Brasileiro de TV Digital - SBTVD.

1.2 Escopo
O consórcio Consórcio BRISA UnB UFPR Lactec está desenvolvendo um conjunto de aplicações e serviços para
subsidiar o processo de tomada de decisão técnica acerca do desenvolvimento do SBTVD. Estas aplicações, serviços e
especificações são:
• Correio Eletrônico Unidirecional, chamado TVGrama
• Portal de acesso ao SBTVD
• Serviço de Declaração de Isento
• Serviço de manipulação de conteúdo multimídia tridimensional
• Especificação de Controle Remoto
As aplicações acima indicadas serão integradas com subsistemas de um sistema típico de TV Digital, composto por
geradores de MPEG-2-TS, gerador de carrosssel de dados, serviços web, sistemas de modulação e transmissão de sinal,
canal de interação e uma URD na qual está instalado o Middleware de Referência.

1.3 Definições, Acrônimos e Abreviaturas

MPEG-2-TS – MPEG-2 Transport Stream
Gerador de Carrossel de Dados - sistema que produz uma stream MPEG-2-TS no formato DSM-CC a partir de um
sistema de arquivos local.
Serviços Web – Sistema distribuído que se comunica por meio do protocolo HTTP.

1.4 Documentos Relacionados

Refinamento dos Requisitos do Correio Eletrônico – SW - RFP 07/2004 – Serviços, Aplicações e Conteúdo para a TV
Digital - Aplicações em TV Digital - Correio Eletrônico
Plano de Evolução do Produto - RFP 07/2004 – Serviços, Aplicações e Conteúdo para a TV Digital - Software de
Correio Eletrônico – TVGRAMA
Plano de Testes – SW - RFP 07/2004 – Serviços, Aplicações e Conteúdo para a TV Digital - Aplicações em TV Digital
Correio Eletrônico (TVGrama)

2 VISÃO GERAL DO SISTEMA

Nesta seção serão apresentados todas as soluções propostas pelo consorcio, suas posições com relação ao ambiente
proposto pelo SBTVD e quais as dependências com relação a outros elementos do ambiente não desenvolvidos pelo
consórcio BRISA-UnB-UFPR-Lactec.

2.0.1 Solução TVGrama

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 4/24

 Figura1 -Visão geral de Integração SBTVD e solução TVGrama
A Figura1, acima, apresenta uma visão geral da integração necessária entre o SBTVD e a solução TVGrama. Os
elementos que compõem a solução TVGrama encontram-se destacados em vermelho. Os pontos de interface que serão
obrigatoriamente ajustados para integração sistêmica da solução encontram-se destacados em cor escura. Os pontos de
interface opcionais que podem ser ajustados para integração estão destacados em tom cinza claro. As interfaces que não
devem ser ajustadas não possuem destaques de cor.

TVGrama: Visão geral e Características de Integração Sistêmica

Os documentos de especificação de software e testes descrevem detalhes da arquitetura TVGrama. As principais
características de integração do TVGrama que o distinguem da arquitetura básica de integração do SBTVD apresentada
anteriormente são:
• Terminal TVGrama – A integração sistêmica do TVGrama depende da instalação de um nó computacional que
atuará como terminal de envio de mensagens. Neste caso, se faz necessário dispor, para os testes de integração, de
um equipamento que possua um browser web, para apresentar ao testador que desempenha o papel de remetente,
uma página HTML com um formulário.
• Central TVGrama – A integração sistêmica do TVGrama depende da instalação de um nó computacional que atuará
como Central do TVGrama. Nesta central deverão ser instalados vários componentes cujas funcionalidades são
providas de forma independente da arquitetura padrão do SBTVD de envio de mensagens. Neste caso, se faz
necessário dispor, para os testes de integração, de um equipamento que possua um browser web, para apresentar ao

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 5/24

 testador que desempenha o papel de remetente, uma página HTML com um formulário.
• Receptor Pacotes TVGrama – Módulo de software que precisa ser instalado em um container de Servlets HTTP,
responsável por receber os pacotes de mensagens para distribuição pelas geradoras. Este módulo de software precisa
ter acesso ao sistema de arquivos compatilhado com o gerador de carrossel.
• Cliente TVGrama <<xlet>> - Módulo de software que será distribuído por meio do gerador de carrossel e que será
executado no middleware da URD.

TVGrama: Requisitos e Restrições de Integração Sistêmica

Destacam-se como requisitos específicos e restrições da integração sistêmica do TVGrama:
• Disponibilidade de equipamento para atuar como Terminal TVGrama, que pode ser um computador convencional
com acesso a internet
• Disponibilidade de equipamento para atuar como Servidor da Central TVGrama. Este equipamento precisa ter um
servidor HTTP (TOMCAT) e um SGBD relacional (MYSQL instalados e configurados para constituirem uma
aplicação em duas camadas. Este mesmo equipamento precisa estabelecer conexão a um servidor HTTP instalado no
subsistema que faz o papel da Geradora.
• Disponibilidade de servidor HTTP com container de servlets instalados na rede local de equipamentos que
constituem a instalação da geradora de sinal de TV. Este servidor HTTP (container de Servlets) precisa ter acesso ao
sistema de arquivos do Gerador de Carrossel. Além disso, existe um um módulo de software que permite o cadastro
de retransmissoras e CEP nas geradoras.

TVGrama: Descrição do ambiente e perfil dos envolvidos, inclusive usuários

Os seguintes usuários formam o perfil dos envolvidos com o uso e operação da solução TVGrama:
• Remetente TVGrama – Responsável por acessar um browser http no terminal e enviar mensagens.
• Administrador da Central TVGrama – Responsável por realizar atualizações nos cadastros de usuários e geradoras.
• Destinatário TVGrama – Consumidor de serviços de TV Digital Pseudo-interativa, que recebe e lê na URD as
mensagens enviadas por meio do TVGrama.
• Administrador Geradora – Responsável pela manutenção do cadastro das estações que transmitem o sinal televisivo.

TVGrama: Especificação da arquitetura, diagramas, fluxos de dados, tabelas e interfaces

A especificação da arquitetura, diagramas, fluxos de dados, tabelas e interfaces contendo todas as informações
suficientes e necessárias para a compreensão da interação que há entre os sistemas/subsistemas já se encontra descritas
no documento Plano de Testes da aplicação TVGrama.

TVGrama: Testes de APIs suportadas pelo Middleware

São apresentadas nesta seção todas as classes JAVA testadas para que a aplicação TVGrama obtenha exito de
funcionamento quando executada sobre o Middleware de referência. As classes JAVA serão apresentadas através de
tabelas que destacam na primeira coluna o pacote utilizado e na segunda coluna as classes necessárias dentro dos
pacotes. Considera-se neste caso que todas as classes básicas fornecidas pela máquina virtual java estão sendo
atendidas, ou seja, as classes que não necessitam de importação declarativa.

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 6/24

java.awt.* Component
Color
Container
Font
FontMetrics
Graphics
Image
Toolkit
Dimension
Rectangle

java.awt.event.* KeyEvent
KeyListener

java.util.* Properties

javax.tv.xlet.* Xlet
XletContext
XletStateChange Exception

javax.tv.service.selection.* ServiceContentHandler
ServiceContext
ServiceContextFactory

javax.media.* Control
Player

java.io.* DataInputstream
File
FileInputStream
FileNotFoundException
IOException
BufferedReader
InputStreamReader

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 7/24

org.havi.ui.* HScene
HSceneFactory
HSceneTemplate
HScenePoint
HText
HBackgroundConfigTemplate
HBackgroundConfiguration
HBackgroundDevice
HBackgroundImage
HScreen
HStillImageBackgroundconfiguration

org.dvb.media.* BackgroundVideoPresentetionControl
VideoTransformation

org.dvb.dsmcc.* Todas as classes e interfaces previstas

org.davic.resources.* Todas as classes e interfaces previstas

2.0.2 Solução Portal

Figura 2 -Visão geral de Integração SBTVD e solução Portal

O diagrama acima apresenta uma visão geral da integração necessária entre o SBTVD e a Solução Portal de Acesso. Os
elementos que compõem a Solução Portal encontram-se destacados em vermelho.
A aplicação Portal de Acesso é transmitida pelo SBTVD como uma outra aplicação comum, com a diferença da
sinalização feita: o Portal é sinalizado como sendo AUTO_START, sem ligação com os serviços e persistente entre os
canais.

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 8/24

Portal: Visão geral e Características de Integração Sistêmica
Os documentos de especificação de software e testes descrevem detalhes da arquitetura do Portal de Acesso. As
principais características de integração do Portal de Acesso que o distinguem da arquitetura básica de integração do
SBTVD apresentada anteriormente são:
• A integração sistêmica do Portal de Acesso depende da URD previamente configurada, recebendo uma Transport
Stream completa com fluxos de áudio e vídeo e as informações preenchidas das tabelas de SI.
• Portal de Acesso <<xlet>> - Módulo de software que será distribuído por meio do gerador de carrossel e que será
executado no middleware da URD.

Portal: Requisitos e Restrições de Integração Sistêmica

Destacam-se como requisitos específicos e restrições da integração sistêmica do Portal de Acesso:
• Disponibilidade de equipamento para atuar como Terminal do Portal de Acesso. Este equipamento consiste em:
uma URD (adequadamente recebendo a Transport Stream completa) e controle remoto com interface definida
conforme o documento Especificações Técnicas do Objeto – SW: Serviços, Aplicações e Conteúdo para TV Digital
Terrestre – Portal de Acesso para o Middleware de Referência.
• Disponibilidade de equipamento para atuar como gerador da Transport Stream. Este equipamento consite em
Gerador MPEG-2 – TS Conteúdo A/V, Gerador de Carrossel de Dados, Gerador das tabelas de SI e multiplexador.

Portal: Descrição do ambiente e perfil dos envolvidos, inclusive usuários

Os seguintes usuários formam o perfil dos envolvidos com o uso e operação da solução Portal de Acesso:
• A – Telespectador – Usuário da aplicação Portal de Acesso.
• B – Administrador Gerador – Responsável pela manutenção e envio das tabelas de SI.
• C – Administrador Conteúdo – Responsável por gerenciar o conteúdo das Transport Streams enviadas.

Portal: Especificação da arquitetura, diagramas, fluxos de dados, tabelas e interfaces

A especificação da arquitetura, diagramas, fluxos de dados, tabelas e interfaces contendo todas as informações
suficientes e necessárias para a compreensão da interação que há entre os sistemas/subsistemas já se encontram descritas
no documento Plano de Testes da aplicação Portal.

Portal: Testes de APIs suportadas pelo Middleware

São apresentadas nesta seção as classes JAVA testadas para que a aplicação Portal obtenha exito de funcionamento
quando executada sobre o Middleware de referência. As classes JAVA serão apresentadas através de tabelas que
destacam na primeira coluna o pacote utilizado e na segunda coluna as classes necessárias dentro dos pacotes.
Considera-se neste caso que todas as classes básicas fornecidas pela máquina virtual java estão sendo atendidas, ou seja,
as classes que não necessitam de importação declarativa.
As classes do pacote javax.tv ainda não foram especificadas individualmente e, por isso, são apontados os pacotes que
serão utilizados.

java.awt.* Color
Component
Font
FontMetrics
Graphics
Image
Toolkit

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 9/24

java.awt.event.* KeyEvent
KeyListener

java.io.* DataInputStream
DataOutputStream
FileInputStream
FileOutputStream
IOException

java.util.* ArrayList
Calendar
Date
GregorianCalendar
HashMap
Iterator
LinkedList
ListIterator
Locale
MissingResourceException
ResourceBundle
StringTokenizer
TreeMap

javax.tv.xlet.* Xlet
XletContext
XletStateChangeException

org.havi.ui.* HScene
HSceneFactory
HSceneTemplate
HScreenDimension
HScreenPoint

javax.tv.carousel.*

javax.tv.graphics.*

javax.tv.locator.*

javax.tv.media.*

javax.tv.media.protocol.*

javax.tv.net.*

javax.tv.service.*

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 10/24

javax.tv.service.guide.*

javax.tv.service.navigation.*

javax.tv.service.selection.*

javax.tv.service.transport.*

javax.tv.util.*

2.0.3 Solução Declaração de Isento

Figura 3 -Visão geral de Integração SBTVD e solução Portal de Acesso

A Figura 3, acima, apresenta uma visão geral da integração necessária entre o SBTVD e a solução Declaraçao de Isento.
Os elementos que compõem a solução Declaração de Isento encontram-se destacados em vermelho.

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 11/24

Declaração de Isento: Visão geral e Características de Integração Sistêmica
Os documentos de especificação de software e testes descrevem detalhes da arquitetura Declaração de Isento. As
principais características de integração do Declaração de Isento que o distinguem da arquitetura básica de integração do
SBTVD apresentada anteriormente são:
• A integração sistêmica do Declaração De Isento depende da URD previamente configurada, com uma canal de
Retorno configurado para uma conexão segura com o Servidor Da Receita
• Declaração De Isento <<xlet>> - Módulo de software que será distribuído por meio do gerador de carrossel e que
será executado no middleware da URD.
• Servidor Da Receita - Módulo de software que precisa ser instalado em um servidor com um canal seguro para
receber as declarações e gerar uma resposta da URD sobre a aceitação ou recusa da Declaração.

Declaração de Isento: Requisitos e Restrições de Integração Sistêmica

Destacam-se como requisitos específicos e restrições da integração sistêmica da Declaração de Isento:
• Disponibilidade de equipamento para atuar como Servidor de Recebimento da Declaração de Isento . Este
equipamento precisa ter suporte à conexão segura utilizando o protocolo TLS.
• Disponibilidade de URD com um canal de retorno e a ter suporte à conexão segura utilizando o protocolo TLS .

Declaração de Isento: Descrição do ambiente e perfil dos envolvidos, inclusive usuários

Os seguintes usuários formam o perfil dos envolvidos com o uso e operação da solução Declaração de Isento:

• Declarante – Usuário que envia a sua declaração de Isento para o servidor da Receita Federal
• Receita Federal– Responsável pela manutenção do servidor de Recebimento da Declaração de Isento

Declaração de Isento: Especificação da arquitetura, diagramas, fluxos de dados, tabelas e

interfaces
A especificação da arquitetura, diagramas, fluxos de dados, tabelas e interfaces contendo todas as informações
suficientes e necessárias para a compreensão da interação que há entre os sistemas/subsistemas já se encontram descritas
no documento Plano de Testes da aplicação Declaração de Isento

Declaração de Isento: Testes de APIs suportadas pelo Middleware

São apresentadas nesta seção todas as classes JAVA disponiveis para aplicação Declaração de Isento pelo Middleware
de Referência.

java.awt.* Component
Color
Container
Font
FontMetrics
Graphics
Image
Toolkit
Dimension

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 12/24

java.awt.event.* KeyEvent
KeyListener

java.util.* Properties
Locale
ResourceBundle
MissingResourceException
LinkedList
ListIterator
Calendar
Date
GregorianCalendar

java.net.* Socket
UnknownHostException

javax.tv.xlet.* Xlet
XletContext
XletStateChange Exception

javax.net.ssl.* SSLSocket
SSL

java.io.* DataInputstream
DataOutputStream
File
FileInputStream
FileNotFoundException
IOException
IntererruptedIOException
BufferedReader
InputStreamReader
Serializable

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 13/24

org.havi.ui.* HScene
HSceneFactory
HSceneTemplate
HscenePoint
HSceneDimension

2.0.4 Solução Aplicação Multimídia 3D

O produto foi desenvolvido para que se pudesse realizar a visualização de objetos tridimensionais eficientemente no
terminal de acesso. Este produto, além de efetuar a visualização, poderá futuramente apresentar enquetes para o usuário,
permitindo expor mais informações interativamente acerca do modelo ou assunto em questão.
O módulo construído deve ser capaz de:
1. Apresentar ao usuário uma janela na qual é exibido um único modelo tridimensional que pode ser movimentado
utilizando as setas de navegação do teclado (cima, baixo, esquerda, direita).
2. Exibir por meio dessa janela cenas interiores (como interiores de museus, edifícios históricos, ocas indígenas e
outros objetos que possam ser vistos a partir do interior), as quais podem conter diversos modelos. Esse modo de
operação é capaz de proporcionar uma experiência imersiva do usuário num ambiente 3D.
3. Permitir a navegação do usuário por entre esses modelos, através de links que podem ser acessados pelo botão
“OK”.
4. Permitir o retorno do usuário a um modelo anterior através do pressionamento do botão “VOLTAR”.
5. Permitir a navegação entre salas contíguas.
6. Exibir um texto informativo do modelo que está sendo exibido.
7. Apresentar tempo de resposta baixo quando em operação.
8. Realizar as tarefas anteriores com baixo consumo de memória e baixo processamento de CPU.
O Museu Virtual é composto de dois módulos principais: um módulo servidor, responsável pela renderização das
imagens dos modelos 3D a serem visualizados, e um módulo cliente, responsável pela exibição destas imagens ao
usuário. Nossa tarefa de desenvolvimento consiste em entregar o módulo cliente completo e simular o módulo servidor
por meio de síntese digital de objetos 3D. Isso porque a construção de um acervo digital requer muito mais do que o
prazo estabelecido para o término do projeto e também porque a síntese 3D pode ser feita a partir de outros objetos,
utilizando programas comerciais, como 3D Studio Max, Maya, AutoCad, Blender, PovRay e tantos outros disponíveis
no mercado. A seguir, apresentamos um diagrama que apresenta uma visão geral da integração necessária entre o
SBTVD e o Museu Virtual 3D. Os elementos que compõem a aplicação encontram-se destacados em vermelho.

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 14/24

 Figura 4 -Visão geral de Integração SBTVD e solução Museu Virtual 3D

Aplicação Multimídia 3D: Visão geral e Características de Integração Sistêmica

A integração do sistema com o SBTVD depende basicamente da implementação em middleware das classes
utilizadas pelo aplicativo. Os testes em XletViewer atestaram o correto funcionamento caso esta condição seja
respeitada. Outro fator que pode ser crítico é a latência do carrossel, mas sua influência também depende do tamanho do
modelo e/ou da quantidade de modelos que se quer carregar para exibição. Em geral, a quantidade de memória utilizada
é um pouco superior ao tamanho ocupado em disco pelos modelos, que, no caso de nossa aplicação, são constituídos de
figuras compactadas jpeg.
As principais características de integração do Museu Virtual 3D que o distinguem da arquitetura básica de integração
do SBTVD apresentada anteriormente são:
• A integração sistêmica do Museu Virtual 3D depende do correto funcionamento das classes utilizadas pela
aplicação.
• A aplicação deve estar apta para o acesso ao carrossel de dados (requisito a ser cumprido presumivelmente pelo
middleware).
• <<MuviClient>> - Módulo de software que será distribuído, juntamente com classes associadas, por meio do
gerador de carrossel e que será executado no middleware da URD.

Aplicação Multimídia 3D: Requisitos e Restrições de Integração Sistêmica

Destacam-se como requisitos específicos e restrições da integração sistêmica do Museu Virtual 3D:
• Disponibilidade de 8 Mb de memória para exibição de modelos com até duas salas contendo 4 modelos por sala, ou
até 5Mb para exibição de um único modelo com conjunto completo de vistas (toda esfera ao redor do modelo).
• Capacidade de processamento adequada para decodificação das imagens JPEG
• Integração eficiente entre middleware e placa gráfica para que a exibição das imagens seja feita com eficiência.

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 15/24

Aplicação Multimídia 3D: Descrição do ambiente e perfil dos envolvidos, inclusive usuários
Os seguintes usuários formam o perfil dos envolvidos com o uso e operação da solução Museu Virtual 3D:
• Usuários comuns: telexpectadores que usam o sistema para manipular um objeto tridimensional e possivelmente
responder a enquetes utilizando o controle remoto.
• Alunos e professores: utilizam o sistema para visualizar e manipular informações pertinentes a alguma área
específica de conhecimento na qual se tenha interesse em estudar.
• Desenvolvedores: podem utilizar o sistema como base para criação de outros visualizadores tridimensionais, bem
como jogos ou outras aplicações relacionadas.
• Empresas: podem utilizar o sistema para fornecer réplicas a fim de permitir ao consumidor conhecer e/ou escolher
modelos de produtos antes de adquiri-los.
• Produtores de conteúdo: podem criar programas que utilizem navegação tridimensional a fim de atrair a atenção do
expectador e/ou atingir outro objetivo específico (como, por exemplo, entretenimento ou enquetes).

Aplicação Multimídia 3D: Especificação da arquitetura, diagramas, fluxos de dados, tabelas e

interfaces
A aplicação cliente do museu virtual (MuviClient) é um módulo integrante do museu virtual responsável pela
visualização dos dados na set-top-box do usuário final. Além desse módulo, o sistema deve possuir um servidor de
renderização, e um banco de dados. Os modelos 3D são armazenados no banco de dados e carregados pelo servidor de
renderização quando solicitado pelo produtor de conteúdo. De posse dos modelos, o servidor de renderização cria
imagens 2D (a partir dos modelos tridimensionais) para serem transmitidas para o módulo cliente via carrossel de dados
(transmissão). Neste ponto, podemos notar que o servidor de renderização só é necessário para construir as imagens 2D
que serão exibidas no cliente para dar a ilusão de tridimensionalidade. Uma vez as imagens prontas, elas constituem-se
no único requisito para a perfeita visualização na STB do usuário, dispensando a necessidade do uso direto dos modelos
tridimensionais. Essa necessidade só surgiria no caso do produtor de conteúdo querer criar novas representações de
modelos 3D. Assim, não só poupa-se espaço de armazenamento, como também o uso de imagens 2D permite que o
módulo cliente simule perfeitamente a visualização de objetos tridimensionais e ao mesmo tempo poupe processamento
local. A seguir, apresentamos duas arquiteturas possíveis do sistema, seguidas do diagrama de classes da solução:

Figura 5 -Uma possível arquitetura do Museu Virtual 3D

Figura 6 -Outra possível arquitetura do Museu Virtual 3D

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 16/24

 Figura 7 -Diagrama de Classes do Módulo de Visualização

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 17/24

 O módulo cliente, ou MuviClient, como o chamaremos a partir de agora, é composto de uma classe principal e de
diversas outras que juntas integram a solução. Cada classe é definida abaixo, juntamente com seu papel no módulo:

• MuviClient: Xlet que representa o corpo principal da solução;

• Mouse: Classe responsável por capturar os eventos de mouse e transmiti-los à aplicação;
• Keyboard: Classe responsável por capturar os eventos de teclado e transmiti-los à aplicação;
• Action: Interface criada para representar as ações a serem executadas por botões ou outros elementos gráficos.
• CloseAction: Classe que implementa a interface Action que realiza o encerramento do aplicativo;
• BackAction: Classe que implementa a interface Action que realiza o retorno a um modelo anterior durante a
navegação do usuário em um ambiente com múltiplos modelos;
• FollowAction: Classe que implementa a interface Action que realiza o avanço de posição do usuário de um modelo
a outro durante a navegação do usuário em um ambiente com múltiplos modelos;
• DescriptionContainer: Classe responsável pela exibição das descrições dos modelos na interface com o usuário;
• ImageButton: Classe responsável por exibir botões gráficos na tela, bem como controlar seus eventos, como
pressionamentos e mudanças de estado;
• Model: Classe criada para representar um modelo tridimensional, bem como operações intrinsecamente relacionadas
a esse modelo;
• ImageMatrix: Classe responsável por armazenar uma matriz de imagens correspondente a todas as vistas possíveis
de um modelo 3D. Armazena itens do tipo ImageElement;
• ImageElement: Armazena um elemento de imagem (uma imagem compactada carregada do carrossel). Representa
uma sequência de bytes que será descompactada dinamicamente para gerar as imagens que serão visualizadas pelo
usuário durante a navegação;
• LinkList: Classe criada para representar um nó de uma lista duplamente ligada, bem como a lista inteira. Ela
armazena todos os links de um objeto a outro, permitindo a navegação entre os objetos;
• ConfigReader: Esse classe é responsável pela leitura do arquivo de configuração da cena e criação da estrutura em
memória que irá representar essa cena;
• ResourceManager: Classe responsável pelo carregamento das imagens. Esse carregamento é realizado dando
prioridade a elementos mais próximos da imagem que está em exibição no momento;
• ViewManager: Classe responsável por receber as entradas de dados (mouse e teclado) e de tomar as ações cabíveis a
cada entrada, levando em conta as condições atuais do sistema;
• Viewer : Classe responsável pela exibição eficiente do elemento de imagem que deve ser apresentado ao usuário no
momento atual. É gerenciado pelo ViewManager.
O sistema começa lendo o arquivo de configuração cena.cfg no diretório da aplicação. A partir da leitura desse
arquivo, o configReader cria uma estrutura em memória para representar a cena e verifica a consistência dos dados
fornecidos. Quaisquer avisos ou erros são reportados na saída padrão do console Java. Em seguida, o viewManager
recebe a estrutura da cena e monta uma lista de carregamento, dando prioridade aos objetos mais próximos ao objeto
inicial. Esta lista, juntamente com a posição no objeto inicial são passados para o resourceManager, que inicia o
carregamento das imagens a partir da imagem inicial, em seguida pelas circunvizinhas no raio 1, depois no raio 2, e
assim até concluir o carregamento deste objeto. Em seguida, inicia o carregamento das imagens dos outros objetos
conforme determinado pelo viewManager. A visualização é desvinculada do carregamento, o qual é feito por uma
thread em segundo plano, assim como o tratamento das entradas de dados pelo viewManager.
Ao pressionar uma tecla, um evento é capturado pela classe Keyboard, que o envia à classe principal, MuviClient e
que pode ou não tratar esse evento, propagando-o em seguida para o viewManager, que tratará o evento adequadamente.
O viewManager avalia a entrada e realiza as modificações necessárias na posição atual do observador no objeto em
questão, bem como informa ao viewer a nova imagem a ser vista, que realiza a troca imediatamente. Se for necessária
alguma modificação no estado dos botões, o viewManager informa aos botões o seu novo estado, que se encarregam de

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 18/24

alterar seu aspecto na interface com o usuário.
Os botões direcionais são utilizados para visualizar as outras vistas de um mesmo objeto, enquanto que os botões
“OK” e “VOLTAR” permitem seguir um link para outro objeto ou voltar ao objeto anterior, respectivamente. É
possível, no arquivo de configuração da cena, especificar quais imagens de quais objetos serão interpretadas como links
para qual posição do objeto-alvo. Quando é possível seguir um link em uma imagem, o botão “OK” se torna habilitado,
e quando é possível voltar para uma imagem anterior, o botão “VOLTAR” se torna habilitado. Esse sistema de
movimentação ainda está em análise e pode mudar sensivelmente até o prazo final de entrega.
Não há limitações para o número de links em um modelo, pois cada imagem disponível pode servir de link para
outro objeto. Também não há limitações para a quantidade de imagem por objeto, ou de quantas salas podem ser
carregadas ao mesmo tempo, sendo que o fator preponderante nas escolhas acerca desses fatores é a memória ocupada
pelos objetos e a memória disponível no STB.
Atualmente, todos os objetos de uma cena são carregados em memória. E, ainda que compactados, os dados podem
chegar a ocupar um espaço considerável de memória, dependendo das configurações da cena. Com a evolução, espera-
se que seja possível carregar uma cena apenas parcialmente, poupando memória. No entanto, esta alternativa depende de
uma análise mais aprofundada do funcionamento real do sistema de TV digital e, sobretudo, da latência do carrossel.
Museus inteiros poderiam ser disponibilizados, com diversas salas, andares e peças, possivelmente animações 3D, tudo
isso desde que se tenha um rápido fluxo de informações entre o provedor de conteúdo e a STB (possivelmente cenário
3). Se a latência for baixa o suficiente, talvez isso pudesse ser feito até mesmo no cenário 1. Mas, como ressaltamos,
essa alternativa necessita de mais dados experimentais para que possa ser considerada viável ou não.
A aplicação cliente caracteriza-se por ser bem flexível e por permitir uma ampla gama de combinações possíveis
tanto na criação de cenário quanto na própria arquitetura do sistema. Um gerador de conteúdo pode utilizar o programa
que desejar para gerar os modelos, assim como pode montar a cena das maneiras mais diversas, permitindo que o
aplicativo de visualização 3D sirva tanto para fins específicos quanto genéricos. Além disso, a arquitetura do cliente em
si favorece a construção de outros aplicativos similares baseados na mesma tecnologia.
Interfaces com Usuário

A interface do Museu Virtual 3D não varia muito, as maiores mudanças estão no comportamento do aplicativo e na
imagem visualizada, tudo de acordo com as entradas fornecidas pelo usuário. A seguir, apresentamos algumas telas que
nos permitem ter uma idéia de como o programa se comporta nas diferentes fases da navegação.

Figura 8 – Interface de navegação do Museu Virtual 3D – tela inicial

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 19/24

 Figura 9 – Interface de navegação – detalhe de um objeto

Figura 10 – Interface de navegação – outra vista de um objeto

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 20/24

 Figura 11 – Interface de navegação – trocando de sala

Figura 12 – Interface de navegação - “caminhando” no museu

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 21/24

 Devemos ressaltar que os modelos apresentados nesta fase são apenas ilustrativos, pois a demora na entrega do
scanner 3D nos impossibilitou a construção de modelos reais. Esperamos que até a entrega final do projeto, possamos
apresentar modelos que foram gerados pelo uso do próprio scanner, o que já está em andamento.

Aplicação Multimídia 3D: Testes de APIs suportadas pelo Middleware

São apresentadas nesta seção todas classes JAVA testadas para que o Museu Virtual 3D obtenha exito de
funcionamento quando executada sobre o Middleware de referência.

java.awt.* Component
Color
Dimension
Font
Graphics
Image
Label
MediaTracker
Panel
Rectangle
Toolkit

java.awt.image.* ImageObserver

java.awt.event.* KeyEvent
KeyAdapter
MouseEvent
java.util.* ArrayList
Iterator
StringTokenizer

xjavax.tv.xlet.* Xlet
XletContext
XletStateChange Exception

javax.swing.event.* MouseInputListener

java.io.* FileInputStream
FileNotFoundException
IOException
BufferedReader
InputStreamReader

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 22/24

org.havi.ui.* HScene
HSceneFactory
HSceneTemplate
HText
Hstate
HdefaultTextLayoutManager
Hcontainer
HComponent

org.dvb.ui.* DVBColor

3 REFERÊNCIAS

[1] Del Bimbo, Al. Visual Information Retrieval. Morgan Kaufmann, 1999.
[2] Sistema de Busca de Imagens/Fotos por Conteúdo, baseado em MPEG-7 e Java.http://caliph-emir.sourceforge.net/
[3] IBM MARVEL - sistema de busca de conteúdo multimídia (vídeo) baseado em MPEG-7.
http://www.research.ibm.com/marvel/
[4] Nack, F.; Lindsay, A. Everything you wanted to know about MPEG-7: Part II. IEEE MultiMedia, October -
December 1999,pp.64-73, IEEE Computer Society.
[5] Nack, F.; Lindsay, A. Everything you wanted to know about MPEG-7: Part I. IEEE MultiMedia, July - September
1999,pp. 65 - 77, IEEE Computer Society.
[6] Pfeiffer, S.; Srinivasan, U. TV Anytime as an application scenario for MPEG-7 Workshop on Standards,
Interoperability and Practice, Proc. ACM Multimedia 2000, Los Angeles, October 2000.
[7] The OpenGL Programming Guide - The Official Guide to Learning OpenGL. Addison-Wesley Professional; 3rd
edition 1999.
[8] Baeza-Yates, R., Ribeiro-Neto, B. Modern Information Retrieval, Addison Wesley Professional, 1999.
[9] Fernando, R. GPU Gems: Programming Techniques, Tips, and Tricks for Real-Time Graphics. Addison-Wesley,
2004.
[10]GPU Gems 2: Programming Techniques for High-Performance Graphics and General-Purpose Computation. Matt
Pharr 2005.
[11]Santos, J. B. dos; Moreira, E. S.; Bengtson, M. D. Modelagem de Ambientes Interativos Cientes de Contexto: Uma
Abordagem Baseada nos Padrões MPEG-4 e MPEG-7. anais do SEMISH’2003 – Seminário Integrado de Harware
e Software, 2003.
[12] Westermann, U.; Klas, W. An analysis of XML database solutions for the management of MPEG-7 media
descriptions. ACM Computing Surveys (CSUR) archive, volume 35 , issue 4, pages: 331 – 373, 2003.
[13] EVAIN, J. P. TV-Anytime metadata – a preliminary specification on schedule. EBU Technical Review, 2000
[14] Chun-Shien et al. Watermarking on compressed/uncompressed video using communications with side information
mechanism. Idea Group Publishing Series archive. Distributed multimedia databases: techniques & applications
archive. Section: Watermark techniques table of contents, pages: 173 – 189, 2002.
[15] Smeulders et al. Content-Based Image Retrieval at the End of the Early Years. IEEE Transactions on Pattern
Analysis and Machine Intelligence archive, volume 22 , Issue 12, pages 1349 – 1380, 2000.

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 23/24

[16] Draper, D.. Mapping between XML and Relational Data. URL:
http://www.informit.com/articles/article.asp?p=169590&seqNum=2&rl=1 . Feb/2004. Acessado em Jun/2005
[17] Rene Reitsma et al. Digital Libraries & XML-Relational Data Binding. Dr. Dobbs Journal, April 2005. URL:
http://www.ddj.com/documents/s=9603/ddj0504f/0504f.html
[18] Ojala, T. et al, CMRS : Architecture for Content Based Multimedia Retrieval, Infotech oulu International
Workshop on Information Retrieval (http://www.ir2001.oulu.fi/demonstrations/), texto disponível em
http://www.mediateam.oulu.fi/publications/pdf/90.pdf, acesso em 11/06/05.
[19] Chia-Hung, W.; Chang-Tsun, L. Design of Content-based Multimedia Retrieval, International Conference on
Multimedia, (06/08) 2005, Amsterdã. disponível em http://www.dcs.warwick.ac.uk/~ctli/papers/Chapter3.pdf, acesso
em 10/06/05.

4 HISTÓRICO DE ALTERAÇÕES DESTE DOCUMENTO

Data Versão Responsável Alterações

20/Ago/2005 0.1 Jorge H C Fernandes Criação do documento com indicação da
arquitetura geral do sistema sob teste.
02/set/2005 0.2 Leandro Vaguetti, Ana Dytz, Requisitos de Integração (TVGrama),
Paulo Gondim compatibilização com Testes TVGrama
12/set/2005 0.3 Eduardo Silva, Renato Iida, Requisitos do Portal de Acesso e
Rogério Cardoso Declaração Anual de Isento
28/out/2005 0.8 Isaias José Amaral Soares Requisitos de Integração do
Museu Virtual 3D
01/11/2005 0.9 Everton Vidal Vieira Revisão dos requisitos do Museu Virtual

CONSÓRCIO BRISA-Unb-UFPR-Lactec – Todos os direitos reservados Confidencial 24/24