universidade do vale do itajaÍ centro de ciÊncias ...siaibib01.univali.br/pdf/leandro...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
FERRAMENTA DE APOIO À CONSTRUÇÃO DE PROGRAMAS À TV DIGITAL INTERATIVA BASEADOS EM NCL
Área de TV Digital Interativa
por
Leandro Lourenci
Júlia Marques Carvalho da Silva, M.Sc. Orientadora
Itajaí (SC), dezembro de 2009
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
FERRAMENTA DE APOIO À CONSTRUÇÃO DE PROGRAMAS À TV DIGITAL INTERATIVA BASEADOS EM NCL
Área de TV Digital Interativa
por
Leandro Lourenci Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Júlia Marques Carvalho da Silva, M.Sc.
Itajaí (SC), dezembro de 2009
ii
SUMÁRIO
LISTA DE ABREVIATURAS ................................................................ iv
LISTA DE FIGURAS .............................................................................. v
LISTA DE TABELAS ............................................................................ vii
RESUMO ............................................................................................... viii
ABSTRACT ............................................................................................. ix
1. INTRODUÇÃO.................................................................................... 1 1.1. PROBLEMATIZAÇÃO ................................................................................... 4 1.1.1. Formulação do Problema............................................................................... 4 1.1.2 Solução Proposta ............................................................................................ 5 1.2 OBJETIVOS ..................................................................................................... 5 1.2.1 Objetivo Geral ................................................................................................ 5 1.2.2 Objetivos Específicos...................................................................................... 6 1.3 METODOLOGIA ............................................................................................. 6 1.4 ESTRUTURA DO TRABALHO ..................................................................... 7
2. FUNDAMENTAÇÃO TEÓRICA ...................................................... 8 2.1 TV DIGITAL .................................................................................................... 8 2.1.1 Cenário no Brasil ........................................................................................... 8 2.1.2 Equipamentos necessários ........................................................................... 10 2.1.3 Padrões para o Desenvolvimento de Programas Interativos no Brasil ..... 14 2.1.3.1 Ginga-J ................................................................................................... 15 2.1.3.2 Ginga-NCL............................................................................................. 17 2.1.4 Modelo Conceitual de Dados da Linguagem NCL - NCM ......................... 19 2.1.5 Estrutura de um documento Hipermídia - NCL ........................................ 20 2.1.5.1 Cabeçalho do arquivo NCL................................................................... 22 2.1.5.2 Cabeçalho do programa ........................................................................ 22 2.1.5.3 Corpo do programa ............................................................................... 27 2.1.6 Ferramentas de auxilio para o desenvolvimento de documentos NCL ..... 31 2.1.6.1 Composer ............................................................................................... 31 2.1.6.2 NCL Eclipse - Plug-in do Eclipse .......................................................... 33 2.1.7 Ginga-NCL Emulator .................................................................................. 34 2.1.8 Ginga-NCL Virtual STB .............................................................................. 34 2.1.9 Exemplos de Programas para a TV Digital baseados em NCL ................. 35 2.1.9.1 Exemplo 1 ............................................................................................... 36 2.1.9.2 Exemplo 2 ............................................................................................... 37 2.1.10 Tecnologias para desenvolvimento de ferramentas web ............................ 40 2.1.10.1 Tecnologias especiais ............................................................................. 42 2.2 PROJETO OBAA ........................................................................................... 42
iii
3 DESENVOLVIMENTO .................................................................... 46 3.1.1 Requisitos Funcionais .................................................................................. 46 3.1.2 Diagrama de Casos de Usos ......................................................................... 47 3.1.2.1 Pacote 01: Módulo Administrador ....................................................... 48 3.1.2.2 Pacote 02: Módulo Usuário ................................................................... 48 3.1.3 Diagrama de atividades................................................................................ 49 3.1.4 Diagrama de Entidade-Relacionamento ..................................................... 50 3.1.5 Implementação ............................................................................................. 51 3.1.6 Funcionamento da ferramenta .................................................................... 52 3.1.7 Dificuldades encontradas ............................................................................. 58 3.2 TESTES E VALIDAÇÕES ............................................................................ 58
4. CONSIDERAÇÕES FINAIS ............................................................ 61
ARTIGO ACEITO PARA PUBLICAÇÃO .......................................... 64
REFERÊNCIAS BIBLIOGRÁFICAS .................................................. 65
A. PROJETO .......................................................................................... 69
A.1 Casos de Usos ........................................................................... 69
A.1.1 Pacote 01: Módulo Administrador ......................................... 69
A.2.1 Pacote 02: Módulo Usuário ..................................................... 71
A.2 Tutorial de construção de uma aplicação interativa na ferramenta desenvolvida ........................................................................ 80
iv
LISTA DE ABREVIATURAS
ABNT Associação Brasileira de Normas Técnicas ADSL Asymmetric Digital Subscriber Line API Application Programming Interface CESTA Coletânea de Entidades de Suporte ao uso de Tecnologia na Aprendizagem CSS Cascading Style Sheets DTV Digital TV ER Entidade-Relacional HDMI High-Definition Multimedia Interface HDTV High-Definition Television HTML HyperText Markup Language IBGE Instituto Brasileiro Geografia e Estatística IDE Integrated Development Environment IP Internet Protocol ISDB-T Integrated Services Digital Broadcasting Terrestrial ISDB-TB International System for Digital Broadcasting – Terrestrial Brazilian LAVID Laboratório de Aplicações de Vídeo Digital LIA Laboratório de Inteligência Aplicada MC Ministério das Comunicações MPEG Moving Picture Experts Group NCL Nested Context Language NCM Nested Context Model OBAA Objetos de Aprendizagem Baseados em Agentes PC Personal Computer PDA Personal digital assistants PHP Hypertext Preprocessor PUC-Rio Pontifícia Universidade Católica do Rio de Janeiro RBS TV Rede Brasil Sul de Televisão SACCA Sistema Automático de Catalogação de Conteúdo Audiovisual SBTVD Sistema Brasileiro de TV Digital Terrestre TCC Trabalho de Conclusão de Curso TVD TV Digital UFPB Universidade Federal da Paraíba UHF Ultra High Frequency UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí URI Uniform Request Identifier VHF Very High Frequency XHTML Extensible HyperText Markup Language XML Extensible Markup Language
v
LISTA DE FIGURAS
Figura 1. Cobertura da TV Digital no Brasil .................................................................................... 9 Figura 2. Modelo de set top box ..................................................................................................... 10 Figura 3. Modelo de um sistema de televisão digital Interativa ...................................................... 11 Figura 4. Arquitetura do set top box ............................................................................................... 12 Figura 5. Etapas da recepção.......................................................................................................... 13 Figura 6. Modelo de um controle remoto para a TV Digital Interativa............................................ 14 Figura 7. Arquitetura Ginga. .......................................................................................................... 15 Figura 8. Contexto do Ginga-J. ...................................................................................................... 16 Figura 9. Modelo conceitual NCM básico ...................................................................................... 19 Figura 10. Relacionamento entre nós e elos. .................................................................................. 20 Figura 11. Estrutura básica de um documento NCL. ...................................................................... 21 Figura 12. Cabeçalho básico de um arquivo NCL. ......................................................................... 22 Figura 13. Exemplo de região na linguagem NCL. ......................................................................... 23 Figura 14. Visão espacial de uma região aninhada na linguagem NCL. .......................................... 23 Figura 15. Exemplo de descritor na linguagem NCL. ..................................................................... 24 Figura 16. Exemplo de definição de apresentação de um nó de conteúdo na linguagem NCL. ........ 24 Figura 17. Conector ligando três nós. ............................................................................................. 25 Figura 18. Máquina de estados de eventos. .................................................................................... 26 Figura 19. Definição básica de um connector com condição e ação simples. .................................. 26 Figura 20. Definição básica de um nó de conteúdo. ....................................................................... 28 Figura 21. Definição básica de um nó de contexto. ........................................................................ 28 Figura 22. Definição de um elo. ..................................................................................................... 29 Figura 23. Exemplo de porta. ......................................................................................................... 29 Figura 24. Definição de uma porta. ................................................................................................ 30 Figura 25. Definição de uma âncora de conteúdo. .......................................................................... 30 Figura 26. Definição de uma âncora de propriedade. ...................................................................... 31 Figura 27. Ferramenta Composer ................................................................................................... 32 Figura 28. NCL Eclipse ................................................................................................................. 33 Figura 29. Ginga-NCL Emulator ................................................................................................... 34 Figura 30. Ginga-NCL Virtual STB ............................................................................................... 35 Figura 31. Exemplo 1 de um programa para a TV Digital baseados em NCL. ................................ 36 Figura 32. Exemplo 01 em execução no emulador ......................................................................... 37 Figura 33. Exemplo 2 de um programa para a TV Digital baseados em NCL. ................................ 38 Figura 34. Base de conectores do Exemplo 2 ................................................................................. 39 Figura 35. Exemplo 02 em execução no emulador ......................................................................... 40 Figura 36. Conceitos e tecnologias relacionadas ao projeto ............................................................ 44 Figura 37. Ferramenta no contexto do projeto OBAA. ................................................................... 45 Figura 38. Diagrama de pacotes dos casos de usos ......................................................................... 48 Figura 39. Casos de usos do módulo administrador ........................................................................ 48 Figura 40. Casos de usos do módulo usuário .................................................................................. 49 Figura 41. Diagrama de atividades da visão geral do uso da ferramenta. ........................................ 50 Figura 42. Diagrama de Entidade-Relacionamento ........................................................................ 51 Figura 43. Tela principal da ferramenta ......................................................................................... 53 Figura 44. Tela de listagem de aplicações interativas desenvolvidas pelo usuário .......................... 53 Figura 45. Termos de Uso da ferramenta. ...................................................................................... 54 Figura 46. Tela de envio de mídias ................................................................................................ 55
vi
Figura 47. Repositório de mídias ................................................................................................... 56 Figura 48. Tela de desenvolvimento de aplicações à TV Digital Interativa ..................................... 56 Figura 49. Diagrama de pacotes dos casos de usos ......................................................................... 69 Figura 50. Casos de usos do módulo administrador ........................................................................ 70 Figura 51. Casos de usos do módulo usuário .................................................................................. 72 Figura 52. Mídias carregadas no menu. .......................................................................................... 80 Figura 53. Propriedades da mídia inicial ........................................................................................ 81 Figura 54. Mídia inserida no workspace......................................................................................... 82 Figura 55. Configuração da mídia HTML ...................................................................................... 83 Figura 56. Hierarquia de uso. ......................................................................................................... 84 Figura 57. Finalização do projeto ................................................................................................... 84 Figura 58. Arquivo compactado a ser executado no ambiente Ginga. ............................................. 85 Figura 59. Região na ferramenta Composer. .................................................................................. 86 Figura 60. Descritor na ferramenta Composer. ............................................................................... 87 Figura 61. Mídia na ferramenta Composer. .................................................................................... 88 Figura 62. Structural View na ferramenta Composer. ..................................................................... 89 Figura 63. Criar links na ferramenta Composer. ............................................................................. 90 Figura 64. Exemplo desenvolvido na ferramenta Composer. .......................................................... 91
vii
LISTA DE TABELAS
Tabela 1. Mídias aceitas pela ferramenta a ser desenvolvida .......................................................... 69 Tabela 2. Papéis de condições ........................................................................................................ 93 Tabela 3. Papéis de ações .............................................................................................................. 93
viii
RESUMO
LOURENCI, Leandro. Ferramenta de apoio à construção de programas à TV Digital Interativa baseados em NCL. Itajaí, 2009. 103 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009. Com o modelo brasileiro de TV Digital aprovado pelo governo, a televisão deixa de ser somente um meio de comunicação assistido. As pessoas deixam de ser tratadas de forma passiva, na qual só recebem as informações não agregando valor algum a estas e, passam a poderem atuar ativamente com a televisão, interagindo diretamente com a mesma e agregando valores às informações por elas recebidas. Neste cenário, o telespectador deve se adaptar a tecnologia da TV Digital através de set top boxes ou TVs que aceitem o sinal digital, assim como as emissoras devem adequar as suas transmissões para esta tecnologia. No Brasil, a TV Digital começa a ter impulso neste século XXI, já cobrindo grandes centros urbanos do território nacional com a transmissão digital. Paralelamente, pesquisadores trabalham na padronização da interatividade na TV Digital com o middleware Ginga, na qual facilitará o processo de desenvolvimento de aplicações interativas sem os desenvolvedores se preocuparem com a plataforma de hardware em que o Ginga esta acoplado. O middleware Ginga oferece dois contextos distintos de programação, sendo um voltado à forma declarativa, conhecido como Ginga-NCL e outro na forma imperativa, Ginga-J. Independente do contexto usado é indispensável o estudo da linguagem utilizada por eles, fazendo com que somente desenvolvedores trabalhem na construção de aplicações interativas. Contudo, algumas ferramentas tentam se adequar à construção destas aplicações à realidade de mais usuários, facilitando ou até eliminando a necessidade de codificação por eles, porém, são ferramentas em inglês e de difícil manuseio para usuários leigos, não eliminando o estudo das linguagens utilizadas pelo ambiente da TV Digital Interativa. Sendo assim, o presente trabalho de conclusão de curso teve como objetivo pesquisar e desenvolver uma ferramenta web para o auxílio na criação de aplicações interativas para o middleware Ginga, no ambiente declarativo NCL. Pretende-se que a ferramenta facilite todo o processo da construção de aplicações para a TV Digital, e seja capaz de fornecer, um repositório centralizado de mídias para uso comum entre usuários. Palavras-chave: TV Digital. Ferramenta Web. Ginga.
ix
ABSTRACT
With the approve of Brazilian model of Digital TV by the govern, the television is not just a box where the people watch a content in a passive form, just receiving the information and not adding any value to them. Now, they can start to act actively with the television, interacting directly with it and adding value to the information received by them. In this scenario, the viewer should adapt himself to the Digital TV technology through the set top boxes or TVs that accept the digital signal, as the station should adjust their transmissions for this technology. In Brazil, the Digital TV starts to have impulse in this century XXI, already covering the big urban centers of the national territory with the digital transmission. Parallel, researchers work in the standardization of the interactivity in the Digital TV with the Ginga middleware, which will facilitate the development process of interactive application without the developers worry about the hardware platform in which the Ginga is joined. The Ginga middleware offers two distinct contexts of programs, and one being directed to the declarative form, knowing as Ginga-NCL and another in the imperative form, Ginga-J. Independent of the used context, it is indispensable the language study used by them, making with that only developers work in the construction of interactive applications. However, some tools try to adjust to the application constructions to the reality of more users easing or eliminating necessity of codification by them, therefore, that are tools in English and of difficult handling for common users so it don’t eliminate the studying of languages used to Digital TV interactive environment. In this way, this work aims to research and develop a web tool that helps the development of interactive applications for the Ginga middleware, in the declarative ambient NCL, and besides that facilitating all the process of the applications construction for the Digital TV, and that also to supply a centralized repository of medias for common use among users. Keywords: Digital TV. Web Tool. Ginga.
1
1. INTRODUÇÃO
A televisão é um dos meios de comunicação mais abrangente no mundo. No Brasil, estima-
se que 94,8% (IBGE, 2007) dos domicílios brasileiros, independente de classe social, contenham ao
menos um aparelho televisor, tornando-se um meio indispensável na vida de muitas pessoas.
Portanto, é normal e importante que esta esteja envolvida em um processo de constantes melhorias.
A televisão brasileira foi oficialmente inaugurada no dia 18 de setembro de 1950, ao
pioneirismo do jornalista Assis Chateaubriand que investiu na primeira estação televisiva, a TV
Tupi. Naquela época o rádio ainda era o veículo de comunicação mais abrangente no país
(MATTOS, 1990).
Como todo meio de comunicação, a Televisão já passou por diversas mudanças, desde as
menos significativas, como a invenção do controle remoto, onde dispensou a locomoção e
aumentou o conforto do telespectador, sendo este o primeiro componente digital integrado aos
aparelhos de receptores, até as mais significativas, como a televisão colorida, ainda na década de
1950 (MONTEZ; BECKER, 2005). Mas, deste tempo até os dias de hoje, ainda é transmitida para a
maioria dos telespectadores na forma analógica. Desta forma, neste século XXI, a televisão aberta
no Brasil começa a sofrer mudanças em seu meio de transmissão, começando a migrar do formato
da TV analógica para o formato da TV Digital.
No dia 2 dezembro de 2007, o Brasil entrou definitivamente na era da TV Digital (DTV,
2009). Segundo Montez e Becker (2005, p. 24): “A TV digital nada mais é do que a transmissão
digital dos sinais audiovisuais”. O formato analógico que é usado até os dias atuais, passa a ser
representado por uma sequência de bits.
Ao telespectador, muitas vantagens são oferecidas com a transmissão em sistema digital. A
mais perceptiva, está na conservação da qualidade do sinal. No sinal analógico tem-se uma perda
significativa no sinal que representa quase que 50%, no sinal digital, a imagem e som é muito mais
imune a interferências e ruídos Dessa forma, pode-se obter uma qualidade de imagem em alta
2
definição (HDTV) e um som estéreo mais envolvente, com até seis canais de áudio (áudio
surround1 5.1) (MONTEZ; BECKER, 2005).
Dentre as vantagens que são oferecidas, deve-se destacar a interatividade. Na TV analógica
o contato entre o telespectador e a emissora do sinal, tem que ser feito através de linhas secundárias
de comunicação, como o telefone, internet e/ou cartas. Com a TV Digital, toda a interatividade
estará unificada a televisão e ao controle remoto. O telespectador terá um contato mais rico com a
televisão. Para votar em uma enquete, não será mais preciso usar o telefone. Para enviar dados
pessoais como o seu nome e endereço à uma emissora, não será mais preciso postar cartas.
Para se beneficiar da interatividade, da imagem sem perda de capacidade, a comunicação
entre o sinal digital e a televisão do telespectador é realizado através de conversores chamados set
top boxes (DTV, 2009). Os set top boxes são responsáveis por receber os fluxos da TV Digital e
decodificá-los para a televisão, além de permitir a interatividade (MONTEZ; BECKER, 2005).
No caso da interatividade para o padrão brasileiro, o set top box tem que implementar uma
camada de middleware chamado Ginga. Através do middleware Ginga, os programadores estão
aptos à programar a interatividade sem precisar conhecer detalhes do hardware, no caso, os set top
boxes (ABNT, 2007).
O Ginga é um projeto aberto, desenvolvido e coordenado pelos laboratórios Telemídia da
PUC-Rio (Pontifícia Universidade Católica do Rio de Janeiro) e LAVID (Laboratório de
Aplicações de Vídeo Digital) da UFPB (Universidade Federal da Paraíba). Segundo o site oficial do
projeto (GINGA, 2009), o Ginga é um middleware “subdividido em dois subsistemas principais
interligados, que permitem o desenvolvimento de aplicações seguindo dois paradigmas de
programação diferentes”. Através de uma análise das funcionalidades de projeto, se verifica qual
paradigma é mais adequado ao mesmo. Esses dois subsistemas são chamados de Ginga-J (Java) e
Ginga-NCL (NCL/LUA).
Dentre os softwares já conhecidos, para a criação de conteúdos interativos, pela comunidade
da TV Digital Interativa, destaca-se o Composer (GINGA-NCL, 2009). O Composer é uma
ferramenta gráfica para criação da interatividade entre as mídias, sendo este, desenvolvido pelos
mesmos laboratórios de desenvolvimento do middleware Ginga. Porém, o Composer é uma 1 Sistema de áudio multicanal, fazendo com que o som venha de mais de uma direção.
3
ferramenta feita na linguagem Java, exclusivamente para desktop, em inglês e de difícil manuseio
para usuários leigos.
O NCL-Eclipse é outra ferramenta também conhecida (GINGA-NCL, 2009). Trata-se de um
plug-in para o ambiente Eclipse de Java, que permite o desenvolvimento de aplicações em NCL
(Nested Context Language). Ela é responsável somente pelo auxílio da criação do código fonte,
onde todo o trabalho é feito por um programador apto a criação das mídias.
Tanto o Composer, quanto o NCL-Eclipse, são ferramentas responsáveis por auxiliar na
criação de um arquivo .ncl. Elas orientam a sequência e forma de interação das mídias. Para
executar o arquivo é necessário o set-top-box ou, um emulador, neste caso o Ginga-NCL Emulator.
Dentro do contexto Ginga-NCL, este trabalho de conclusão de curso teve como propósito o
desenvolvimento de uma ferramenta via Web, para auxilio na criação de mídias interativas para o
middleware Ginga. Acredita-se que ferramentas computacionais possam acelerar o processo de
criação de programas interativos e, acima de tudo, facilitar o mesmo processo, ajudando
desenvolvedores, analistas e até mesmo pessoas que tenham afinidade para com a área, a estarem
aptos a criarem programas interativos para a TV Digital.
O presente trabalho de conclusão de curso encontra-se situado dentro do projeto OBAA
(Objetos de Aprendizagem Baseados em Agentes), cuja pesquisa é desenvolvida por diversos
pesquisadores de outras universidades, tendo como base a da Universidade Federal do Rio Grande
do Sul. Tal projeto de pesquisa visa especificar um modelo para conteúdos digitais educacionais
(em Web, dispositivos móveis e TV digital).
O propósito na criação de uma nova ferramenta, especialmente desenvolvida para este fim,
visou, além de melhorar e facilitar o processo de criação dos programas interativos, oferecer um
repositório de mídias. Uma mídia previamente usada, se autorizada pelo autor, poderá ser usada por
outra pessoa, criando assim, um repositório compartilhado de mídias.
Para isto, a ferramenta desenvolvida foi baseada em Web, buscando a maior independência
de plataforma, evitando a instalação e permitindo o controle centralizado.
Desta forma, o presente TCC pesquisou e desenvolveu uma ferramenta web que permita a
construção / organização de arquivos NCL baseados na especificação Ginga, que agregue e indique
as interações entre mídias, além de permitir o compartilhamento de mídias. Com o trabalho foi
4
possível realizar uma prova de conceito do que o modelo brasileiro de TV Digital Interativo é capaz
através da demonstração da possibilidade de produção de conteúdos interativos para a mesma. A
ferramenta permite ao usuário à flexibilidade na criação de aplicações interativas baseadas em
objetos de mídias (vídeos, imagens, sons e textos) enviadas pelo próprio usuário, ou, objetos que já
tenham sido enviados ao compartilhamento de mídias e que seu uso esteja autorizado. Funções
como a transição entre mídias, aparição de blocos com textos informativos sobre a mídia após a
interação do telespectador são permitidas. Pela finalidade de tornar a ferramenta o mais simples
possível ao usuário, o desenvolvimento da mesma não teve como pretensão contemplar todas as
funcionalidades possibilitadas pela linguagem NCL, sendo que para uso de alguns dos seus
recursos, mais experiência é exigida do usuário, não sendo este o foco principal da ferramenta.
1.1. PROBLEMATIZAÇÃO
1.1.1. Formulação do Problema
A TV brasileira está passando por constantes melhorias tecnológicas. O sistema clássico de
TV analógica gradativamente vem sendo substituído pelo modelo digital de transferência de dados.
As estações televisivas passarão a não usar ondas eletromagnéticas analógicas em suas transmissões
e sim, dados binários, sendo estes mais resistentes a interferências no seu sinal gerando uma
imagem fiel ao telespectador, além de permitir que a estação envie outros tipos de dados, como
informações sobre a programação do canal ou aplicações interativas, por exemplo, juntamente com
os dados referentes à imagem. Essas características são possíveis graças à tecnologia da TV Digital.
Com a crescente popularização da TV Digital brasileira e, conseqüentemente da
interatividade que ela oferece, cada vez mais será exigido ferramentas de apoio ao desenvolvedor e
até mesmo a um usuário “aventureiro” para a criação das aplicações interativas.
Atualmente, todo o processo de criação de uma aplicação interativa é feito de forma manual
ou por uma ferramenta mais especializada na forma visual, chamada de Composer. Na forma
manual, o usuário terá que desenvolver suas aplicações interativas através de linhas de códigos que
somente um programador apto, depois de estudar toda a complexidade que envolve o processo de
criação da interatividade na TV Digital, pode desenvolver. Com isso, gerando dificuldade ou até
mesmo, impossibilitando a criação por pessoas que não são desenvolvedores. Já na forma visual, o
desenvolvimento das aplicações interativas é mais dinâmica do que a forma manual, a necessidade
em escrever linhas de códigos pode ser eliminada por parte do usuário, mas mesmo desta forma, a
5
ferramenta acaba sendo complexa, pois para realizar tarefas simples como adicionar uma mídia no
seu trabalho, o usuário deve estudar e entender toda a estrutura que compõe um documento NCL,
estrutura esta, que será citada no decorrer deste trabalho. Com essa complexidade e, além da
ferramenta Composer ser uma ferramenta em inglês e usar muitos termos técnicos não presentes no
cotidiano de usuários que não estão envolvidos diretamente com a TV Digital e/ou computação,
acaba tornando o seu acesso especifico as pessoas mais especializadas.
1.1.2 Solução Proposta
Este projeto teve como proposta o desenvolvimento e a pesquisa de algumas ferramentas
que auxilie na produção de conteúdos interativos para a TV Digital seguindo o modelo brasileiro.
Com ela, usuários leigos, que não estão envolvidos diretamente com a TV Digital e/ou computação,
poderão criar suas próprias aplicações interativas, possibilitando que estes possam gerar aplicações
de forma visual e fácil, sem a necessidade de contato direto com a linguagem fonte na qual o
software foi originalmente desenvolvido, desde que estes usuários tenham conhecimentos do
conceito que envolve o modelo NCM, modelo este que será fundamentado adiante.
As mídias que farão parte da aplicação interativa de um usuário ficarão guardadas, se
permitido, em um repositório centralizado de mídias, permitindo o uso futuro por qualquer outro
usuário em suas aplicações. Desta forma, o usuário ao usar uma mídia compartilhada por outro
usuário, o mesmo deve estar ciente que esta mídia poderá ser removida pelo usuário que a
disponibilizou causando impacto direto em sua aplicação. Com isso, a ferramenta foi desenvolvida
e totalmente voltada para a Web, onde o ambiente já é propício no sentido de compartilhamento de
dados entre usuários e, também já visando à facilidade no processo de configuração da ferramenta,
já que não é necessário qualquer instalação para que a mesma execute na máquina do usuário.
Ao final do processo, o usuário fará download de um arquivo compactado com todas as
mídias usadas na aplicação, juntamente com o(s) arquivo(s) .ncl necessários para o usuário executar
no emulador e/ou na máquina virtual, citados mais abaixo, sendo estas, necessário estar previamente
instalado na máquina do usuário.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
6
Desenvolver uma ferramenta web que desenvolva documentos NCL na TV Digital Interativa
no padrão Ginga-NCL.
1.2.2 Objetivos Específicos Pesquisar e analisar ferramentas similares;
Compreender o middleware Ginga;
Compreender e estudar o subsistema Ginga-NCL;
Implementar a ferramenta;
Avaliar a ferramenta; e
Documentar a ferramenta e seus resultados.
1.3 Metodologia
A metodologia utilizada para o desenvolvimento deste trabalho teve como base um total de
cinco etapas: Estudo, Modelagem, Implementação, Testes e, Documentação.
Na etapa do estudo, adquiriram-se conhecimentos necessários e conceitos teóricos da
tecnologia da TV Digital Brasileira. Estudaram-se os conceitos tecnológicos envolvidos no processo
de criação de aplicativos interativos através do middleware brasileiro Ginga. O estudo também se
estendeu à pesquisa sobre soluções e ferramentas similares já existentes.
Na etapa de modelagem, foi especificado o funcionamento da ferramenta a ser desenvolvida
e o seu relacionamento com o banco de dados a fim de se obter o melhor funcionamento do sistema
e, ter um melhor aproveitamento na qualidade do desenvolvimento do software. Para esta etapa
foram utilizados diagramas de casos de uso da linguagem UML (Unified Modeling Language) que
serviram como base para o desenvolvimento do projeto. A modelagem do banco de dados foi
realizada na notação ER (Entidade-Relacionamento) com o auxilia da ferramenta MySQL
Workbench.
A próxima etapa foi implementar a ferramenta. Durante a execução desta, foram utilizados
conceitos da fase de modelagem, entretanto, várias modificações foram necessárias no projeto
inicial que aumentou de forma significa a qualidade da ferramenta final desenvolvida, além de
diminuir a quantidade de controles presentes na mesma.
7
Com o desenvolvimento em fase final, foram realizados testes e avaliações da ferramenta
através do desenvolvimento de diversas aplicações interativas a fim de localizar resultados
inesperados na ferramenta. Os resultados foram sendo exportados e executados com sucesso no
ambiente virtual Ginga-NCL, onde se comprovou a utilidade da ferramenta. Além dos resultados
obtidos com sucesso no teste ao usar a ferramenta, pode-se obter facilitadores no processo de
desenvolvimento pelo usuário que inicialmente não estavam agregados a mesma, sendo estes,
implementados na versão final do software.
Na última etapa, todos os registros dos processos referentes às etapas anteriores foram sendo
documentados, tendo todo o material desenvolvido como base para a documentação final.
1.4 Estrutura do trabalho
Este trabalho foi estruturado em quatro capítulos: Introdução, Fundamentação Teórica,
Desenvolvimento e, Considerações Finais. No primeiro capítulo é apresentado a introdução do
trabalho, onde foi descrito um panorama geral do projeto descrevendo a solução proposta na qual se
propõe a desenvolver. Foram citados algumas ferramentas similares e os problemas nelas existentes.
No segundo capítulo, é feito a descrição das pesquisas bibliográficas, apresentando conceitos
básicos sobre o padrão brasileiro de TV Digital e sobre o desenvolvimento em NCL. No terceiro
capítulo é apresentada a descrição da análise da ferramenta, incluindo sua especificação e
modelagem UML. Esta etapa consta também, dados a respeito da codificação utilizada, além dos
resultados obtidos com os testes e validação do sistema. Finalmente, no quarto capítulo serão
apresentadas as considerações finais a respeito do desenvolvimento do TCC.
8
2. FUNDAMENTAÇÃO TEÓRICA
A televisão, como meio de comunicação, teve impacto na vida de milhões de pessoas em
todo o mundo, exercendo uma influência impressionante no modo de percepção da cultura. Desde a
década de 1950, a televisão surgiu como um catalisador global para as mudanças políticas e sociais,
afetando o modo de aprender e se comunicar (KELLISON; GERHARDT, 2007).
O conteúdo (programas, notícias, informações, música) da televisão chega aos aparelhos de
TV através de sinais de transmissão, que contém dados (imagens, sons, elementos gráficos, títulos e
créditos) que são recriados nos aparelhos de televisão como imagens e sons (KELLISON;
GERHARDT, 2007).
2.1 TV DIGITAL
A televisão digital vem trazendo novas possibilidades de transmissão, como uma melhor
qualidade de imagem e áudio e, a possibilidade de interação com as informações. A HDTV (High-
Definition Television) contém uma imagem nitidamente superior com o formato atual, sua resolução
de imagem contém cerca de duas vezes mais pixels do que o formato atual (MONTEZ; BECKER,
2005). Recentemente, o Brasil iniciou suas transmissões nesta modalidade a partir dos grandes
centros urbanos. Paralelamente, projetos vêm sendo apoiados com o objetivo de padronizar os mais
diversos aspectos que cercam esta nova tecnologia (DTV, 2009). Cabe ressaltar, que o modelo de
TV Digital apresentado por esse TCC, é o modelo que deverá ser seguido como padrão por todas as
emissoras de TV aberta. O Brasil, já apresenta outras modalidades de TV Digital, incluindo também
a interatividade, através das operadoras de TVs a cabo e TVs via satélites.
2.1.1 Cenário no Brasil
No Brasil, a TV Digital estreou oficialmente no dia 2 de dezembro de 2007 em um evento
onde ficou marcado pela ação de um clique em um controle remoto pelo presidente Luiz Inácio
Lula da Silva, na presença dos mais importantes veículos de comunicação do Brasil. Nesta data, se
teve a primeira transmissão em HDTV no país para a cidade de São Paulo - SP. A partir de então,
diversos brasileiros passam a poder usufruir do sinal digital em suas residências, desde que tivessem
o equipamento adequado (que será abordado mais para frente) (CORREIO DO POVO, 2009).
9
Inicialmente, a transmissão digital estava presente somente na cidade de São Paulo - SP,
passando a ser expandida mais tarde para várias outras cidades e estados do Brasil. Belo Horizonte -
MG foi o segundo estado do país à contar com a cobertura digital. Santa Catarina contou com a TV
Digital em Florianópolis no dia 5 de fevereiro de 2009 pela RBS TV, afiliada da Rede Globo
(CORREIO DO POVO, 2009). A Figura 1 ilustra o mapa com a cobertura da TV Digital.
Figura 1. Cobertura da TV Digital no Brasil Fonte: TELECO (2009)
A transmissão analógica no Brasil terá seu fim no dia 29 de junho de 2016, onde até esta
data, ainda continuará sendo transmitida simultaneamente com a transmissão digital. Nesse período
todos os brasileiros terão que adquirir os equipamentos necessários para receber o sinal digital em
suas residências (DTV, 2009).
O Sistema Brasileiro de TV Digital Terrestre (SBTVD), tecnicamente conhecido como
ISDB-TB (International System for Digital Broadcasting – Terrestrial Brazilian), foi desenvolvido
com base no modelo japonês Integrated Services Digital Broadcasting Terrestrial (ISDB-T). O
SBTVD permitiu juntar a base técnica de transmissão do ISDB-T com padrões de compreensão de
áudio e vídeo introduzidos pelo Brasil, gerando assim uma série de diferenciais dos modelos
adotados por outros países (DTV, 2009).
10
Uma das características que a SBTVD oferece é a questão da interatividade, que será
possível através de um middleware que está sendo especificado para este fim. Este middleware,
chamado Ginga, terá que vim implantado nos conversores digitais (que será abordado mais para
frente) em caso de querer usufruir dos recursos da interatividade (DTV, 2009).
No momento, os brasileiros só podem usufruir de uma melhor qualidade de imagem e áudio,
já que o middleware Ginga ainda está em fase de especificação para os telespectadores (DTV,
2009).
2.1.2 Equipamentos necessários
Para usufruir do sinal digital enviado pela difusora (emissora) é necessário ter na residência
um captador de sinal, no caso do sinal enviado por satélite uma antena específica para o fim e, um
conversor digital chamado de set top box (MONTEZ; BECKER, 2005). A Figura 2 ilustra um
modelo de set top box.
Figura 2. Modelo de set top box Fonte: POSITIVO (2009)
Set top box
O set top box ou conversor digital é um computador projetado com o propósito de receber o
sinal da TV Digital e exibi-lo na TV. Nas televisões digitais, o mesmo pode já estar embutido. Seu
funcionamento básico é receber o sinal do captador de sinal, que por sua vez é recebido pela
difusora e, converter esses sinais digitais em um meio que pode ser lido pelas televisões
convencionais (MONTEZ; BECKER, 2005). Esse modelo é referenciado na Figura 3.
11
Figura 3. Modelo de um sistema de televisão digital Interativa Fonte: Montez e Becker (2005)
O set top box também é responsável por tratar do canal de retorno da televisão com a
difusora do sinal. Nos conversores mais completos vendidos atualmente, esse canal é agregado ao
mesmo via modem usando a linha telefônica como seu canal de retorno. Tecnologias como a
ADSL, satélite, rádio e até mesmo o celular, também podem ser empregadas para tratar do canal de
retorno com a difusora. Essa função permite uma nova experiência de interatividade entre o
telespectador com os serviços oferecidos pela emissora (MONTEZ; BECKER, 2005).
A arquitetura de um set top box é dividida em camadas (PICCOLO, 2005), como mostra a
Figura 4.
12
Figura 4. Arquitetura do set top box Fonte: PICCOLO (2005)
Na camada superior têm-se os serviços e conteúdos desenvolvidos em linguagens
declarativas (NCL) ou procedurais, que oferecem ao telespectador serviços específicos de
interatividade como jogos interativos ou a grade de programação do canal, por exemplo, que podem
ser transmitidos em uma transmissão digital. A API (Applications Programming Interface) compõe
a interface de acesso ao middleware de modo que os desenvolvedores de aplicações interativas não
precisam entrar em detalhes sobre a implementação de linguagem do middleware. A camada de
middleware tem a finalidade de fornecer ao desenvolvedor de programas interativos à possibilidade
de programar as aplicações interativas sem precisar se estender a qualquer especificação de
hardware do set top box (PICCOLO, 2005).
Na camada de hardware do set top box é aonde o sinal digital vai ser tratado antes de chegar
à visão do telespectador, passando por diversas etapas de processamento como explanado na Figura
5. Nessa camada é comum conter tecnologias comuns em PCs, como processador, memória,
modems e discos rígidos, pois além de um conversor, o set top box pode permitir ao telespectador
um outro nível de interatividade como navegar na internet (MONTEZ; BECKER, 2005).
13
Figura 5. Etapas da recepção
Fonte: Montez e Becker (2005)
A primeira etapa do processamento do sinal digital é no sintonizador. O sintonizador é
responsável por captar corretamente um canal de VHF (Very High Frequency) ou UHF (Ultra High
Frequency) difundido pela emissora. A segunda etapa ocorre no demodulador, o mesmo é
responsável por converter o sinal digital sintonizado em fluxos de transportes MPEG-2 (Moving
Picture Experts Group). O fluxo extraído no demodulador é carregado no demultiplexador, na qual,
todos os fluxos de dados elementares (vídeo em alta definição, áudio e dados de aplicações) são
extraídos. A etapa de acesso condicional é responsável por decifrar os fluxos de dados elementares,
caso seja necessário e o receptor tenha permissão de acesso, pois alguns serviços podem ser
restringidos a determinados tipos de clientes. Após, os dados de áudio e vídeo são encaminhados
14
para o decodificador que os converte para o formato apropriado de exibição utilizado pelo sistema
televisivo (MONTEZ; BECKER, 2005; PICCOLO, 2005).
A conectividade entre o conversor e a televisão pode ser feita por interfaces como HDMI
(High-Definition Multimedia Interface), vídeo composto, vídeo componente, etc. sendo a HDMI a
mais indicada para a TV Digital, pois a mesma é capaz de transferir mídias digitais sem perda de
qualidade, como vídeo em HDTV e áudio de 6 canais (surround de 5.1 canais) em uma única
interface. (HDMI, 2009).
Controle remoto
O controle remoto é o dispositivo pela qual o telespectador interage com as funcionalidades
da televisão, aumentando e diminuindo o seu volume, trocando de canal, etc. Na TV Digital
Interativa, o controle remoto é o dispositivo pelo qual o telespectador interage com o set top box,
permitindo o controle das aplicações interativas através das setas direcionais e dos botões coloridos
com funções programáveis pela aplicação (PICCOLO, 2005). A Figura 6 ilustra um modelo de
controle remoto para a TV Digital.
Os comandos selecionáveis pelo telespectador é enviado ao set top box através de sinais
infravermelhos. Dados binários sobre o comando é enviado ao receptor onde o mesmo decodifica e
executa estes sinais (HOWSTUFFWORKS, 2009).
Figura 6. Modelo de um controle remoto para a TV Digital Interativa.
Fonte: POSITIVO (2009)
2.1.3 Padrões para o Desenvolvimento de Programas Interativos no Brasil
Para usufruir de programas interativos, os set top box usados no Brasil têm que implementar
a camada de middleware com o projeto Ginga, o qual que faz parte das normas brasileiras de
especificações para a TV Digital Interativa. Através do Ginga, os set top box passam a prover de um
15
conjunto de API que facilitam o desenvolvimento de programas interativos abstraindo a plataforma
de hardware.
Segundo o site oficial do projeto (GINGA, 2009): “O middleware Ginga pode ser dividido
em dois subsistemas principais, que permitem o desenvolvimento de aplicações seguindo dois
paradigmas de programação diferentes. Dependendo das funcionalidades requeridas no projeto de
cada aplicação, um paradigma possuirá uma melhor adequação que o outro.”. Esses dois
subsistemas são chamados de Ginga-J, para programação procedural em Java e, Ginga-NCL para
aplicações declarativas em NCL.
A arquitetura do Ginga pode ser representada basicamente por dois importantes
componentes: a máquina de execução (execution engine), responsável pela execução de arquivos
Xlet do Ginga-J, e a máquina de apresentação (presentation engine), responsável pela execução de
arquivos NCL do Ginga-NCL. Estas duas máquinas são dependentes entre elas, sendo definidas
pontes apropriadas a comunicação. (ABNT, 2007). A arquitetura e ambiente de execução do Ginga
são apresentados na Figura 7.
Figura 7. Arquitetura Ginga.
Fonte: ABNT/CEET (2007)
2.1.3.1 Ginga-J
O Ginga-J é composto por uma API que permite ao desenvolvedor ter funcionalidades para
a implementação de conteúdo interativo para a TV Digital. Ele é um subsistema lógico do sistema
Ginga responsável pelo processamento de conteúdo procedural (Xlet Java). A máquina de execução
16
do conteúdo procedural é considerada como um componente-chave do ambiente de aplicação, o
qual é composta por uma Máquina Virtual Java (ABNT/CEET, 2007).
A Figura 8 apresenta o contexto em que a pilha do software Ginga-J é executada. O Ginga-J
é uma especificação de middleware distribuído, que reside em um dispositivo Ginga (dispositivo
que embarque o middleware Ginga, no caso, um conversor digital), com possibilidade de possuir
componentes de software nos dispositivos de interação (celular, PDA, etc.) (ABNT/CEET, 2007).
Figura 8. Contexto do Ginga-J. Fonte: ABNT/CEET (2007).
O dispositivo Ginga deve ter acesso a fluxos de vídeo, áudio, dados e outros recursos de
mídia, que devem ser transmitidos através do ar, cabo, satélite ou através de redes IP. As
informações recebidas devem ser processadas e apresentadas aos telespectadores (ABNT/CEET,
2007).
O telespectador pode interagir com o dispositivo Ginga através de dispositivos de interação
que podem conter componentes de software Ginga, de forma que o dispositivo de interação possa
enviar informações para o dispositivo Ginga utilizando as funcionalidades providas na
especificação Ginga. Componentes de software podem ser instalados nos dispositivos de interação
permitindo que as funcionalidades dos mesmos sejam exploradas, utilizando funcionalidades da
API Ginga-J por aplicações nos dispositivos Ginga. Para que um dispositivo de interação possa ser
utilizado, ele deve estar registrado com o dispositivo Ginga e, durante esse processo, o dispositivo
de interação pode receber o componente de software necessário para viabilizar a comunicação com
o dispositivo Ginga (ABNT/CEET, 2007).
Como resposta à informação enviada pelo telespectador, o dispositivo Ginga deve apresentar
a saída de vídeo e áudio utilizando seu próprio monitor e auto-falantes, no caso do set top box, na
17
TV na qual o mesmo esta conectado, ou os dos dispositivos de interação. Um único dispositivo
pode ter capacidade de entrada e saída simultâneas (ABNT/CEET, 2007).
Um dispositivo de interação pode também ter capacidades de captura e reprodução de som,
de forma que o telespectador possa enviar fluxos de áudio e vídeo para o dispositivo Ginga,
utilizando os dispositivos de interação que dêem suporte à essa funcionalidade (ABNT/CEET,
2007).
Vários telespectadores podem interagir com a plataforma Ginga simultaneamente. Nesse
caso, cada telespectador pode ter um dispositivo de interação e a plataforma deve distinguir os
comandos enviados por e para cada dispositivo. O dispositivo Ginga pode também enviar
informações para os transmissores de conteúdo quando da existência de um canal de retorno
(ABNT/CEET, 2007).
2.1.3.2 Ginga-NCL
O Ginga-NCL é um subsistema lógico do middleware Ginga responsável pelo
processamento de arquivos declarativos NCL. Um componente-chave do Ginga-NCL é a máquina
de interpretação do conteúdo declarativo (NCL Formatter). Outros módulos importantes e o
exibidor (User Agent) XHTML (eXtensible Hypertext Markup Language), que inclui
interpretadores CSS (Cascading Style Sheets) e ECMAScript2, e a máquina de apresentação Lua,
que é responsável pela interpretação dos scripts Lua (ABNT, 2007).
O NCL Formatter (máquina de interpretação) é responsável por interpretar a linguagem de
declaração NCL, essa que por sua vez é baseada em XHTML. Somente baseada, pois, diferente de
XHTML, a linguagem NCL define uma separação bem demarcada entre o conteúdo e a estrutura de
um aplicativo, oferecendo um controle não invasivo da ligação entre o conteúdo e sua apresentação
e leiaute (ABNT, 2007).
A linguagem NCL não é responsável pela definição do objeto de mídia em si, e sim, na
apresentação tempo-espaço e no comportamento desses objetos dentro de uma apresentação
multimídia. Sendo assim, ela não restringe ou prescreve os tipos de conteúdos dos objetos de mídia,
2 ECMAScript é uma linguagem de script (procedural) padronizada pela ECMA International muito utilizada em tecnologias para Internet (ECMA, 1999).
18
que podem ser de imagem (GIF, JPEG, etc.), de vídeo (MPEG, AVI, etc.), de áudio (MP3, AAC,
etc.), texto (PDF, TXT, etc.), entre outros, e sim, como esses objetos são estruturados e relacionados
no tempo e espaço. A prescrição e a restrição de tipos de objetos de mídias relacionam-se aos
exibidores, definidos e tratados por ferramentas de terceiros, que são acoplados ao NCL Formatter.
Um desses exibidores é o decodificador MPEG-4, normalmente implementado em hardware no set
top box (ABNT, 2007; LABORATÓRIO TELEMÍDIA, 2007).
Outro objeto de mídia que deve ser suportado obrigatoriamente é o objeto de mídia baseado
em XHTML. A NCL não tem a finalidade de substituir a linguagem XHTML, e sim, complementá-
la no que ela seja incapaz de cumprir como linguagem declarativa. O suporte ao tipo de linguagem
XHTML, depende do navegador que é incorporado ao NCL Formatter, este que também pode
fornecer suporte à linguagem procedural ECMAScript (ABNT, 2007; LABORATÓRIO
TELEMÍDIA, 2007).
Segundo o laboratório TeleMídia da PUC-Rio, além do objeto XHTML com sua linguagem
procedural ECMAScript, outros objetos de execução são permitidos em NCL, como objetos XLet,
que fazem parte da ponte entre o ambiente declarativo e procedural do Ginga (LABORATÓRIO
TELEMÍDIA, 2007).
Ainda segundo o Laboratório de TeleMídia da PUC-Rio, outro objeto procedural que tem
suporte em Ginga é o objeto LUA, através de uma máquina virtual (engine) acoplada ao NCL
Formatter. Com isso, além de sintaxe e semântica, LUA fornece uma API que permite as aplicações
NCL trocar dados com programas LUA. Segundo o site oficial do projeto (LUA, 2008) “Lua é uma
linguagem de programação de extensão [funciona somente embarcada em aplicações clientes que
invocam funções em LUA] projetada para dar suporte à programação procedimental em geral e que
oferece facilidades para a descrição de dados.”. Lua é totalmente integrado com Java através da
biblioteca LuaJava, através desta, é possível ter acesso a qualquer classe Java a partir de Lua. Sendo
possível, também através do LuaJava, a manipulação do ambiente de Lua a partir de Java, tornando-
se, assim, parte da ponte entre os ambientes declarativo e procedural do middleware Ginga.
Durante a exibição, pelos diversos exibidores de conteúdos dos objetos de mídias, eventos
são gerados. Apresentação de parte do conteúdo de um objeto de mídia, seleção de parte do
conteúdo de um objeto são exemplos de eventos. Estes podem gerar ações sobre outros objetos de
mídias, tais como iniciar, parar, pausar, terminar suas apresentações. Sendo assim, estes eventos
devem, obrigatoriamente, ser relatados pelos exibidores de mídia ao NCL Formatter, que por sua
19
vez, pode gerar ações a serem aplicadas a esses ou a outros exibidores de mídia (ABNT, 2007;
LABORATÓRIO TELEMÍDIA, 2007). Segundo o Laboratório de TeleMídia da PUC-Rio (2007, p.
8): “O padrão Ginga define uma API padrão que todo o exibidor acoplado ao sistema deve obedecer
para reportar seus eventos e serem comandados por ações geradas pelo Formatador [NCL
Formatter].”. Todo o relacionamento entre condições de eventos e ações é especificado pela
linguagem NCL, a qual é melhor detalhada nas seções a seguir.
2.1.4 Modelo Conceitual de Dados da Linguagem NCL - NCM
Segundo Barbosa e Soares (2008, p. 18),
Toda linguagem declarativa é baseada em um modelo conceitual de dados. Um modelo conceitual deve representar os conceitos estruturais dos dados, assim como os eventos e relacionamentos entre os mesmos. O modelo deve também definir as regras estruturais e as operações sobre os dados para manipulação e atualização das estruturas.
Dessa forma, a linguagem declarativa NCL é baseada no modelo conceitual NCM (Nexted
Context Model), sendo este modelo, centrado na representação e tratamento de documentos de
hipermídia. A Figura 9 apresenta um modelo básico de classes das entidades do NCM.
Figura 9. Modelo conceitual NCM básico Fonte: Barbosa e Soares (2008).
A definição de documentos hipermídia do modelo NCM é baseada no conceito de
relacionamento entre os nós (nodes), sendo este distinguido em nós de conteúdo (content nodes) e
nós de composição (composite nodes), através dos elos (links). Esse relacionamento é mostrado na
20
Figura 10. Define-se como nó, todo e qualquer fragmento de informação, e elos, como links de
relacionamentos entre os nós (SOARES; RODRIGUES, 2005).
Figura 10. Relacionamento entre nós e elos.
Sendo o NCL uma linguagem baseada em NCM, o NCL foi desenvolvido para auxiliar na
construção de documentos hipermídia baseado neste modelo. Os elementos da linguagem, assim
como sua estrutura, são apresentados na sequencia.
2.1.5 Estrutura de um documento Hipermídia - NCL
Um documento NCL é um arquivo no formato em XML (Extensible Markup Language).
Como definição básica do NCL, todo documento possui um cabeçalho de arquivo NCL, uma seção
de cabeçalho do programa (head), o corpo do programa (body), uma porta para a entrada do
programa (port) e o término do documento. Sua estrutura básica é visualizada na Figura 11. Cabe
ressaltar que atualmente a especificação da linguagem NCL se encontra na versão 3.0, tendo este
trabalho com base nessa versão.
Os elementos da linguagem NCL aqui ressaltados, serão explanados de forma básica a fim
de se ter uma ideia quanto a conceitos e a codificação da mesma. Para uma profunda e completa
referência da linguagem NCL deve-se consultar a norma técnica brasileira ABNT NBR 15606-2.
Entenda-se que se tenha como pré-requisito conhecimentos básicos da linguagem HTML e XML.
21
Figura 11. Estrutura básica de um documento NCL.
Fonte: NETO et al. (2007).
Geralmente, para se construir um documento NCL segue-se passos que envolvem definir:
Os cabeçalhos básicos do arquivo NCL e do programa;
As regiões da tela onde aparecerão os elementos visuais (regionBase);
Como e onde os nós de mídia serão exibidos, através de descritores
(descriptorBase);
O conteúdo (nós de mídia – media) e a estrutura (contextos – context) do
documento (seção body), associando-os aos descritores;
A porta de entrada do programa (nó), bem como, as portas para os contextos, visando
à construção dos elos entre os contextos e nós de mídia (port);
Âncoras para os nós de mídia; visando a construção dos elos entre nós (area e
attribute);
Elos para o sincronismo e interatividade entre os nós de mídia e contextos (link); e
22
Os conectores que especificam o comportamento dos elos do documento
(connectorBase).
Todas essas definições são vistas ao longo nas subseções a seguir.
2.1.5.1 Cabeçalho do arquivo NCL
O cabeçalho do arquivo NCL deve, obrigatoriamente, estar incluído em um documento
NCL. O cabeçalho do arquivo tem como objetivo identificar os elementos da norma e a versão na
qual o documento NCL está de acordo (ABNT, 2007). A Figura 12 ilustra o cabeçalho básico de um
programa NCL.
<?xml version="1.0" encoding="ISO-8859-1"?> <ncl id="qualquer string" xmlns="http://www.ncl.org.br/NCL3.0/profileName">
Figura 12. Cabeçalho básico de um arquivo NCL.
Fonte: ABNT (2007).
No elemento ncl, na URI3 (Uniform Resource Identifier) do xmlns, a versão é escrita
imediatamente após a siga NCL. Segundo a norma ABNT (2007, p. 32), “O nome do perfil
(profileName) no URI deve obrigatoriamente ser EDTVProfile (Perfil TVD Avançado) ou
BDTVProfile (Perfil TVD Básico).”. O perfil de linguagem é usado para ajustar a linguagem às
características do ambiente de radiodifusão de televisão com seus vários dispositivos de
apresentação, sendo estes, aparelhos de televisão, dispositivos móveis etc (ABNT, 2007).
2.1.5.2 Cabeçalho do programa
O cabeçalho do programa deve, obrigatoriamente, ser incluído em um documento NCL. O
cabeçalho do programa é responsável por definir as regiões, os descritores, os conectores e as regras
utilizadas pelo programa NCL (NETO et al., 2007); diferentemente do cabeçalho do arquivo NCL,
que descreve as informações gerais do arquivo. Um cabeçalho do programa é delimitado pelo
elemento head. Todos os elementos citados serão vistos nas subseções a seguir.
3 URI (Uniform Resource Identifier) se refere a uma pequena sequencia de caracteres usada para identificar um recurso, seja ele físico ou abstrato (URI, 2005).
23
Regiões
Define-se uma região (region) como uma área no dispositivo de saída que um nó de
conteúdo será exibido. Sua função é controlar a posição e as dimensões da área onde o nó de
conteúdo será apresentado. Na linguagem NCL, a seção para a definição de regiões é delimitada
pelos elementos <regionBase> e </regionBase>, sendo o primeiro elemento responsável em
marcar o início da seção de códigos da região e o segundo para marcar a finalização da seção de
códigos da região. Todas as regiões devem ser definidas dentro desta seção. Para organizar o leiaute
das diversas partes de um documento hipermídia, as regiões podem ser aninhadas, assim, uma
região pode conter outras regiões, sendo que estas podem conter outras regiões e assim,
recursivamente. A Figura 13 ilustra a definição básica de uma região em NCL (NETO et al., 2007).
<region id="rgTV" width="1920" height="1080"> <region id="rgVideo1" left="448" top="156" width="1024" height="768" />
</region>
Figura 13. Exemplo de região na linguagem NCL. Fonte: NETO et al. (2007).
Nota-se que na Figura 13 são definidas duas regiões aninhadas. “rgTV” tendo como
atributos sua largura (width) de 1920 pixels e altura (height) de 1080 pixels. Dentro desta, uma
região “rgVideo1” que além dos atributos já mencionados, atributos quem definem sua posição em
relação à região pai, neste caso “rgTV”, em pixels. A Figura 14 apresenta uma visão espacial de
como esse código se apresentará.
Figura 14. Visão espacial de uma região aninhada na linguagem NCL. Fonte: NETO et al. (2007).
Segundo Neto et al. (2007, p. 28), “Todo documento NCL, possui pelo menos uma região,
que define a dimensão e as características do dispositivo [...]”. Sendo assim, para um dispositivo de
24
dimensões 1920 pixels horizontal por 1080 pixels vertical, uma região com essas mesmas
características deve ser definida, pelo menos, no cabeçalho do programa NCL.
As propriedades de dimensões e posicionamentos, incluindo a configuração de
sobreposição, estão implementadas na ferramenta.
Descritores
Descritores são responsáveis pela definição de como um nó de conteúdo irá se apresentar,
incluindo a sua associação com uma região. Um descritor de mídia de áudio pode definir o seu
volume, um descritor de uma mídia de imagem definir a sua transparência, etc. Na linguagem NCL,
a seção para a definição de descritores é delimitada pelos elementos <descriptorBase> e
</descriptorBase>, sendo o primeiro elemento responsável em marcar o inicio da seção de
códigos do descritor e o segundo para marcar a finalização da seção de códigos do descritor. Todos
os descritores devem ser definidos dentro desta seção (NETO et al., 2007). A Figura 15 ilustra a
definição básica de um descritor “dVideo1” associado à região “rgVideo1”.
<descriptor id="dVideo1" region="rgVideo1" />
Figura 15. Exemplo de descritor na linguagem NCL.
Fonte: NETO et al. (2007).
Para a definição de como uma mídia irá se apresentar, o descritor deve conter um elemento
filho denominado <descriptorParam>. Um atributo name deve ser definido para a definição do que
se irá alterar e um atributo value para a definição de como irá se alterar (NETO et al., 2007). Na
Figura 16 tem-se um exemplo que define que o nó de conteúdo correspondente deva ser
reproduzido com o volume máximo de 90%.
<descriptor id="dVideo1" region="rgVideo1" > <descriptorParam name="soundLevel" value="0.9" /> </descriptor>
Figura 16. Exemplo de definição de apresentação de um nó de conteúdo na linguagem NCL. Fonte: NETO et al. (2007).
Segundo Neto et al. (2007, p. 14) “Mesmo que não se queira alterar a forma como uma
mídia [nó de conteúdo] será apresentada, é necessário um descritor para associar a mídia à região
onde deverá ser apresentada.”.
25
Na ferramenta desenvolvida, o descritor somente é usado para associar um nó a uma região.
Conectores
Os conectores são responsáveis em definir a relação entre os nós de origem do elo e os nós
de destino do elo. Os conectores definem papéis (roles) que os nós de origem e de destino exercem
nos elos que utilizam o conector. Segundo Neto et al. (2007, p. 56), “[...] o sincronismo não é feito
por marcas de tempo (timestamps), mas sim por mecanismos de causalidade e restrição definidos
nos conectores (connectors).”. Dessa forma, para todo e qualquer sincronismo do tempo e espaço
deve-se usar conectores. Na linguagem NCL, a seção para a definição de conectores é delimitada
pelos elementos <conectorBase> e </conectorBase>, sendo o primeiro elemento responsável em
marcar o inicio da seção de códigos dos conectores e o segundo para marcar a finalização da seção
de códigos dos conectores. Todos os conectores devem ser definidos dentro desta seção (NETO et
al., 2007).
Um conector define condições (condition) sob as quais os elos podem ser ativados e, as
ações (action) que serão realizadas quando o elo for ativado. Um conector deve possuir pelo menos
uma condição e uma ação. Cada condição ou ação é associada a um papel, sendo este, atuando
como um ponto de interface dos mapeamentos dos elos. Os papéis de condições e ações podem ser
vistos na seção anexo. A Figura 17 ilustra um conector ligando três nós, cujo primeiro nó (N1) tem
uma condição (Con1) que dependendo do resultado o fluxo continuará para o nó 2 (N2) ou nó 3
(N3).
Figura 17. Conector ligando três nós.
Fonte: NETO et al., (2007).
26
Tanto os papéis de condição quanto os de ação, estão associados a transições de estados
baseados numa máquina de eventos, como ilustrado na Figura 18.
Figura 18. Máquina de estados de eventos.
Fonte: NETO et al. (2007).
A definição básica de um connector é visto na Figura 19. Nela é criado um connector que
define uma ação para quando algo iniciar. Um exemplo seria quando um nó de conteúdo aparecer
na tela apareça outro no mesmo instante.
<connectorBase> <causalConnector id="onBeginStart"> <simpleCondition role="onBegin"/> <simpleAction role="start"/> </causalConnector> </connectorBase>
Figura 19. Definição básica de um connector com condição e ação simples. Fonte: BECKER (2009)
As condições e ações podem ser simples ou compostas. Uma condição simples possui
apenas uma condição, o mesmo equivale para a ação. Uma condição composta
(compoundCondition) possui diversas condições simples (simpleCondition), sendo a composta
qualificada com operadores lógicos “or” e “and”. No caso do operador lógico “or” uma das
condições devem ser atendidas, enquanto no “and” todas devem ser atendidas. Um exemplo deste
tipo de condição seria que, ao telespectador apertar o botão vermelho do controle remoto e o vídeo
estiver redimensionado, um joguinho deve começar. Só o fato de o usuário apertar o botão do
controle remoto não inicia o joguinho, o vídeo deve estar redimensionado para a condição ser
satisfeita e acionar a ação (BECKER, 2009).
27
Uma ação composta (compoundAction) possui diversas ações simples (simpleAction) que
podem ser executadas de forma paralela ou, seqüencialmente (BECKER, 2009). Este trabalho não
será hábil no desenvolvimento de condições e ações compostas.
2.1.5.3 Corpo do programa
O corpo do programa deve, obrigatoriamente, ser incluído em um documento NCL. O corpo
do programa é responsável por definir o conteúdo do programa NCL. Aqui são definidos os nós de
conteúdo e suas âncoras, os nós de contexto e suas portas, os elos e outros elementos. O corpo do
programa é delimitado pelo elemento <body> (NETO et al., 2007). Todos os elementos citados
serão vistos nas subseções a seguir.
Nós
A base de um programa NCL são as mídias que irão compreendê-la. Em um programa NCL,
deve-se definir o tipo de conteúdo que será apresentado. Todo e qualquer conteúdo de mídia é
representado através de nós. O conteúdo de um nó é composto por uma coleção de unidades de
informação. (BARBOSA; SOARES, 2008; SOARES; RODRIGUES, 2005).
Na linguagem NCL, um nó pode ser distinguido em dois tipos:
i. Nó de conteúdo (nó de mídia) e,
ii. Nó de composição (nó de contexto).
Nós de conteúdo, também chamado de nó de mídia, são os nós que representam um objeto
de mídia usual (vídeo, áudio, texto, linguagem imperativa LUA, etc.). Nós de conteúdo devem ser
especializados em subclasses para melhor interpretação do seu conteúdo. Por exemplo, em um nó
de vídeo, o conjunto de informações pode ser formado por quadros que, em sequência, compõe seu
conteúdo. O conteúdo de um nó de mídia pode ser definido como uma referência para o conteúdo
propriamente dito ou, como uma sequência de bytes (SOARES; RODRIGUES, 2005). Cada
definição de um nó de conteúdo deve apresentar além do arquivo de origem da mídia, o descritor
que será responsável por controlar a mídia e associá-la a uma região. Essa definição é representada
na Figura 20.
28
<media type="video" id="video1" src="media/video1.mpg" descriptor="dVideo1"/>
Figura 20. Definição básica de um nó de conteúdo. Fonte: NETO et al. (2007)
Como já explanado, o tipo do nó de conteúdo compatível em um documento NCL é definido
pelos exibidores acoplados ao NCL Formatter do Ginga-NCL.
Nós de composição, neste trabalho tratado como nó de contexto, são nós cujo conteúdo é
composto por um conjunto de nós, seja de conteúdo ou de contexto, recursivamente. Um nó de
contexto é utilizado para estruturar um documento hipermídia. Segundo Neto et al. (2007, p. 13),
“Todo nó de mídia [nesse trabalho, tratado como nó de conteúdo] é definido dentro de um contexto.
Na NCL, o elemento body é o contexto que contém todos os nós do documento, sejam nós de
mídia ou contextos.”. Sendo assim, todo e qualquer nó, seja de conteúdo ou de composição, são
definidos dentro de um contexto, sendo <body> definido como um caso particular de contexto. Na
linguagem NCL, um nó de contexto é definido conforme a Figura 21.
<context id=”ctxNome”> ...
</context>
Figura 21. Definição básica de um nó de contexto.
Fonte: NETO et al. (2007)
Elos
Os elos são responsáveis por associar os nós através dos conectores, sendo estes,
responsáveis por definir a semântica da associação entre os nós, como definido nas seções acima.
Dessa forma, na declaração de um elo é necessário também definir o conector que ficará
responsável pela semântica da associação entre os nós. Na linguagem NCL, conforme a Figura 20,
um elo é definido através do elemento <link> e o conector através do atributo xconnector (NETO
et al., 2007).
29
<link id="lnkElo" xconnector="onBeginStart"> <bind component="botao" role="onBegin"/> <bind component="botao2" role="start"/> </link>
Figura 22. Definição de um elo. Fonte: BECKER (2009)
Conforme Neto et al. (2007), um elo deve conter pelo menos um <bind> para cada papel
definido no conector. Os binds são responsáveis por indicar as mídias envolvidas no elo indicando
o seu papel (role) no elo, conforme as semânticas declaradas no conector (xconnector). Um
exemplo de <bind> também é mostrado na Figura 22. Nela é criado um elo definindo o conector
com id “onBeginStart”, indicando que as mídias “botao” e “botao2” estão envolvidas com o elo
“lnkElo”, sendo que os papeis definem que quando o nó “botao” começar, deve iniciar também o nó
“botao2”, conforme semântica declarada no conector “onBeginStart”.
Portas
Portas são responsáveis para dar acesso a nós internos a um contexto. Dessa forma, para um
elo apontar para um nó interno a um contexto, este contexto deve possuir uma porta que leve a
algum nó interno. Esta definição é mais bem explanada na Figura 23. Nela, é definida uma porta
“pVideo1” no contexto “ctx1”, definindo “video1” como o seu nó de entrada. Para definir qual é o
primeiro nó do programa NCL a ser apresentado, deve-se criar uma porta no contexto <body> para
este nó. (NETO et al., 2007)
Figura 23. Exemplo de porta.
Fonte: NETO et al. (2007)
30
Na linguagem NCL, uma porta é definida conforme Figura 24. O atributo component é
usado para especificar o nó de entrada.
<port id=”pVideo1” component=”video1” />
Figura 24. Definição de uma porta.
Fonte: NETO et al. (2007)
Âncora
Âncora é uma entidade associada à unidade de informação de um nó. Qualquer subconjunto
de unidades de informação de um nó pode ser marcado, sendo que a definição exata do que pode ser
marcado é dependente do seu tipo de conteúdo (SOARES; RODRIGUES, 2005). Segundo Neto et
al. (2007, p. 70), “O objetivo de se utiliza âncoras é utilizar segmentos ou propriedades de um nó de
mídia ou contexto, seja como origem ou destino de elos.”
Na linguagem NCL, as âncoras podem ser diferenciadas em dois tipos:
Âncora de conteúdo e,
Âncora de propriedade.
A âncora de conteúdo é responsável por marcar as unidades de informação do nó que poderá
ser utilizado como ponto de ativação dos elos. Na linguagem NCL, uma âncora de conteúdo é
definida como um elemento area dentro do elemento media (NETO et al., 2007). Conforme Figura
25, são definidas três âncoras de conteúdo para um nó de vídeo “video1”.
<media type=”video” id=”video1” src=”media/video1.mpg” descriptor=”dVideo1”> <!--âncoras de conteúdo no vídeo que devem ser sincronizadas com a legenda-->
<area id=”aVideoLegenda01” begin=”5s” end=”9s”/> <area id=”aVideoLegenda02” begin=”10s” end=”14s”/> <area id=”aVideoLegenda03” begin=”15s” end=”19s”/> </media>
Figura 25. Definição de uma âncora de conteúdo.
Fonte: NETO et al. (2007)
As âncoras de propriedades são responsáveis em se referir à propriedade de um nó de
origem ou de destino, que podem ser manipuladas pelos elos. Exemplos de propriedades são: o
31
volume de áudio de um nó de áudio ou vídeo, coordenadas e dimensões de exibição de um nó
visual, etc (NETO et al., 2007).
Na linguagem NCL, uma âncora de propriedade é definida como um elemento property
dentro de um nó seja de conteúdo ou de contexto. Na Figura 26 são definidas cinco âncoras de
propriedades.
<media type=”video” id=”video1” src=”media/video1.mpg” descriptor=”dVideo1”> <!--âncoras de propriedade que serão manipuladas pelos elos--> <property name=”top”/> <property name=”left”/>
<property name=”right”/> <property name=”width”/> <property name=”height”/>
</media>
Figura 26. Definição de uma âncora de propriedade. Fonte: Adaptado de: NETO et al. (2007)
A ferramenta desenvolvida por este trabalho de conclusão de curso não é hábil à criação de âncoras
tendo como intuito, deixar a ferramenta o mais simples possível ao usuário.
2.1.6 Ferramentas de auxilio para o desenvolvimento de documentos NCL
Para facilitar no desenvolvimento de programas interativos em NCL, várias propostas de
ferramentas estão disponíveis e sendo utilizadas pela comunidade. Dentro destas ferramentas,
podemos destacar a ferramenta Composer e o plug-in NCL para o ambiente Eclipse, um IDE
(Integrated Development Environment) para o desenvolvimento em Java.
2.1.6.1 Composer
O Composer é uma ferramenta para o auxilio no desenvolvimento de programas interativos
NCL. Com ela, é possível ao usuário desenvolver programas interativos com pouco conhecimento
da linguagem NCL. Esta é uma ferramenta desenvolvida pelo mesmo laboratório criador do projeto
Ginga, o Laboratório TeleMídia do Departamento de Informática da PUC-Rio. A Figura 27
apresenta uma tela do Composer.
32
Figura 27. Ferramenta Composer
Conforme Figura 27, a ferramenta Composer dispõe de quatro visões. Uma visão gráfica
estrutural (Structural View), uma visão gráfica temporal (Temporal View), uma visão gráfica de
leiaute (Layout View) e uma visão textual (Textual View).
A visão gráfica estrutural é aonde são apresentados ao usuário os nós e suas ligações através
dos elos. Esta visão é aonde o usuário cria a estrutura lógica do documento NCL e define as
propriedades dos nós de conteúdo, dos nós de contexto e dos elos. (GUIMARÃES, 2007; NETO et
al., 2007).
A visão gráfica temporal ilustra o sincronismo temporal entre as mídias de um documento
NCL, definindo suas posições relativas no tempo e, as oportunidades de interatividade do usuário.
Já a visão gráfica de leiaute apresenta as regiões da tela onde as mídias interativas serão
apresentadas, tendo como foco, os elementos da regionBase (GUIMARÃES, 2007; NETO et al.,
2007).
A visão textual apresenta o código NCL em si. Todo o trabalho realizado pelo usuário nas
visões citadas acima é traduzido para o seu respectivo código NCL, podendo o usuário, também
editá-lo. Toda alteração realizada no código é apresentada nas suas respectivas visões. O usuário ao
adicionar um nó, este é apresentado na tela gráfica estrutural, o mesmo acontece ao adicionar uma
33
região, onde esta é apresentada na visão gráfica de leiaute. Dessa forma, todas as visões do
Composer são sincronizadas, a alteração em uma região refletirá nas outras visões.
2.1.6.2 NCL Eclipse - Plug-in do Eclipse
Diferentemente da ferramenta Composer, o NCL Eclipse é um plug-in para o ambiente
Eclipse que tem como objetivo facilitar a codificação da linguagem NCL pelo usuário e não abstraí-
la. Seu foco é oferecer recursos ao usuário que tornam a codificação da linguagem NCL menos
propícia a erros.
Coloração da sintaxe, formatação automática de código, identificação de erros sintáticos e
semânticos, visualização do documento NCL através de uma árvore e assistência de código sensível
ao contexto, são algumas das características oferecidas pelo plug-in. A Figura 28 apresenta uma tela
de desenvolvimento do NCL-Eclipse.
Figura 28. NCL Eclipse
Sendo um plug-in para o ambiente Java Eclipse, é necessário o ter instalado como pré-
requisito.
34
2.1.7 Ginga-NCL Emulator
Como os documentos NCL são executados dentro do ambiente middleware Ginga, que
deverá estar presente em todos os set top boxes comercializados no Brasil. Para simular este
ambiente, necessita-se que o middleware seja emulado no computador em que o usuário queira
executar os arquivos .ncl. A ferramenta Ginga-NCL Emulator é responsável por emular o
subsistema declarativo NCL do middleware Ginga.
Figura 29. Ginga-NCL Emulator
A Figura 29, apresenta o emulador em execução. O controle remoto apresentado na figura é
usado para a interação do usuário com o emulador. Através dele, é possível ao usuário controlar as
mídias em execução e suas possíveis interações, simulando uma ação do usuário com a televisão o
mais real possível de um sistema de TV Digital Interativa.
Tanto a Ginga-NCL Emulator quanto o Composer, são ferramentas desenvolvidas em Java.
Para executá-las, é necessário ter como pré-requisito a Máquina Virtual Java.
2.1.8 Ginga-NCL Virtual STB
O Ginga-NCL Virtual STB é outra ferramenta responsável por simular o ambiente do
middleware Ginga. Sua funcionalidade é basicamente a mesma do Ginga-NCL Emulator.
Conhecido como set top box virtual, o Ginga-NCL Virtual STB é uma máquina virtual
35
desenvolvida para facilitar o processo de distribuição e implantação do Ginga-NCL em versão C++.
Esta versão, conta com recursos avançados de apresentação de aplicações declarativas,
apresentando melhor desempenho e maior proximidade de uma implementação embarcada em set
top boxes reais (SOFTWARE PÚBLICO, 2009). A Figura 30 apresenta o Ginga-NCL Virtual STB
instalado em um software de virtualização e pronto para o funcionamento.
Figura 30. Ginga-NCL Virtual STB Fonte: SOFTWARE PÚBLICO (2009)
Uma máquina virtual é uma implementação em software de um computador, podendo
utilizar recursos de hardware da máquina real na qual a virtual está instalada, cabe ao software de
virtualização controlar essa funcionalidade. Desta forma, para executar o Ginga-NCL Virtual STB é
necessário ter como pré-requisito um software de virtualização, neste caso, o WMWare
(SOFTWARE PÚBLICO, 2009).
2.1.9 Exemplos de Programas para a TV Digital baseados em NCL
Abaixo, serão explanados exemplos de aplicações funcionais baseados em NCL. Cabe
ressaltar, que os exemplos aqui explanados são para fim de mostrar a referência da linguagem, não
tendo vínculo algum com a ferramenta a ser desenvolvida.
36
2.1.9.1 Exemplo 1
Conforme Figura 30, um vídeo com nome video1.mpg é exibido em uma região da tela com
dimensões de 320 por 240 pixels. Não há sincronismo ou interação alguma com o usuário.
<?xml version=”1.0” encoding=”ISSO-8859-1”?> <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ! CABEÇALHO NCL: define as URIs dos esquemas da NCL
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> <ncl id="exemplo01" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ! CABEÇALHO DO PROGRAMA !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-->
<head> <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! BASE DE REGIÕES: define as regiões onde as mídias são apresentadas !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> <regionBase>
<region id="rgVideo1" left="200" top="168" width="320" height="240" /> </regionBase>
<!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ! BASE DE DESCRITORES: define como as mídias são apresentadas !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> <descriptorBase> <descriptor id="dVideo1" region="rgVideo1" />
</descriptorBase> </head>
<!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ! CORPO DO PROGRAMA: define as mídias e estrutura do programa !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> <body> <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ! PONTO DE ENTRADA: indica o componente onde o programa inicia !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-->
<port id="pInicio" component="video1"/> <!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ! MÍDIAS: define o local dos arquivos de mídia e as
! associa com seus descritores !++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-->
<media type="video/mpeg" id="video1" src="media/video1.mpg" descriptor="dVideo1"/> </body>
</ncl>
Figura 31. Exemplo 1 de um programa para a TV Digital baseados em NCL. Fonte: Adaptado de NCL (2009)
37
A Figura 32 apresenta o exemplo 01 em execução no emulador do ambiente Ginga.
Figura 32. Exemplo 01 em execução no emulador
2.1.9.2 Exemplo 2
Na Figura 33, tem-se um título e um vídeo sendo exibido simultaneamente, conforme
semântica definida na Figura 34 (base dos conectores). Quando o vídeo1.mpg começar a ser
exibido, o titulo1.html deve também aparecer na tela. O mesmo acontece pra quando o video1.mpg
terminar de ser exibido, onde o titulo1.html termina também de ser exibido. Um descritor
informando que o video1.mpg deve ser exibido com 100% do seu volume também é declarado.
Neste exemplo, também não há interação alguma do usuário com a aplicação.
38
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl id="exemplo02" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile">
<head>
<regionBase>
<region id="rgTV" width="1920" height="1080">
<region id="rgTitulo1" left="448" top="116" width="1024" height="40" />
<region id="rgVideo1" left="448" top="156" width="1024" height="768" />
</region>
</regionBase>
<descriptorBase>
<descriptor id="dTitulo1" region="rgTitulo1">
<descriptorParam name="border" value="none" />
</descriptor>
<descriptor id="dVideo1" region="rgVideo1">
<descriptorParam name="soundLevel" value="1" />
</descriptor>
</descriptorBase>
<!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! BASE DE CONECTORES:
! Uma base de conectores externa está sendo importada.
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-->
<connectorBase>
<importBase alias="connectors" documentURI="connectorBase.ncl" />
</connectorBase>
</head>
<body>
<port id="pInicio" component="video1" />
<media type="text/html" id="titulo1" src="media/titulo1.html" descriptor="dTitulo1" />
<media type="video/mpeg" id="video1" src="media/video1.mpg" descriptor="dVideo1" />
<!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
! ELOS
! define os elos que regem o sincronismo entre as mídias
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-->
<!-- video1 deve ser iniciado simultaneamente a titulo1 -->
<link id="lVideo1Titulo1Start" xconnector="connectors#onBegin1StartN">
<bind component="video1" role="onBegin" />
<bind component="titulo1" role="start" />
</link>
<!-- titulo1 deve ser terminado simultaneamente a video1 -->
<link id="lVideo1Titulo1Stop" xconnector="connectors#onEnd1StopN">
<bind component="video1" role="onEnd" />
<bind component="titulo1" role="stop" />
</link>
</body>
</ncl>
Figura 33. Exemplo 2 de um programa para a TV Digital baseados em NCL.
Fonte: Adaptado de NCL (2009)
39
<!--++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ! conectorBase.ncl
!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--> <?xml version="1.0" encoding="ISO-8859-1"?> <ncl id="connectorBase" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProfile http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd">
<head>
<connectorBase>
<causalConnector id="onBegin1StartN"> <simpleCondition role="onBegin"/> <simpleAction role="start" max="unbounded" qualifier="par"/> </causalConnector>
<causalConnector id="onEnd1StopN"> <simpleCondition role="onEnd"/>
<simpleAction role="stop" max="unbounded" qualifier="par"/> </causalConnector> </connectorBase> </head>
</ncl>
Figura 34. Base de conectores do Exemplo 2 Fonte: Adaptado de NCL (2009)
A Figura 35 apresenta o exemplo 2 em execução no emulador do ambiente Ginga. Por
motivos de incompatibilidade com o computador na qual o programa foi testado, o código fonte
com a definição da região com o tamanho da mídia teve que ser alterado.
40
Figura 35. Exemplo 02 em execução no emulador
2.1.10 Tecnologias para desenvolvimento de ferramentas web
Este Trabalho de Conclusão de Curso foi desenvolvido usando as tecnologias de
desenvolvimento JavaScript, PHP e MySQL. O CSS (Cascading Style Sheets) foi utilizado para
estrutura o layout do sistema.
O JavaScript é uma linguagem interpretada, de script, voltada para o desenvolvimento web.
É uma linguagem derivada da linguagem de script ECMAScript. Sua sintaxe básica é
propositalmente similar a Java e C++, para diminuir a quantidade de novos conceitos requeridos
para aprendê-la. Com Javascript pode-se desenvolver tanto em programação estrutural quanto em
programação Orientada a Objetos (MOZILLA, 2009).
A variante mais comum do JavaScript é a incorporação do seu interpretador aos navegadores
web, tornando estes, totalmente responsável pela execução do lado cliente. Dessa forma, através do
modelo de objeto de documento (DOM), responsável pela interação dos elementos que compõe
HTML, pode-se obter uma nova geração de HTML conhecido como DHML (Dynamic HTML)
(FLANAGAN, 2004).
Com o JavaScript é possível utilizar uma metodologia conhecida como AJAX
(Asynchronous JavaScript and XML). Através do AJAX, é possível evitar que a cada solicitação do
41
cliente ao servidor a página precise ser completamente recarregada no navegador do cliente
(MORONI, 2007). Neste trabalho de conclusão de curso, tanto DHML quanto AJAX são conceitos
amplamente explorados para o desenvolvimento dos aplicativos interativos em NCL. Para tal, foi
utilizado uma biblioteca de terceiro conhecida como jQuery, sendo esta, melhor abordada da
subseção a seguir.
No lado do servidor, o sistema foi desenvolvido usando a tecnologia PHP em sua versão
5.2.10, sendo esta, uma linguagem open source bastante conhecida, rápida e difundida para o
desenvolvimento web. Segundo o site oficial do projeto (PHP, 2009), o PHP é uma linguagem de
script embutida no HTML. Seu código é delimitado por tags iniciais e finais (<?php ?>) que lhe
permite desenvolver dentro do PHP ou fora do PHP. Sua sintaxe de desenvolvimento é emprestada
de C, Java e Perl, com algumas características específicas do PHP. O principal objetivo da
linguagem PHP é permitir que desenvolvedores web escrevam páginas geradas dinamicamente.
Com o PHP é possível desenvolver tanto em programação estrutural quanto em programação
Orientada a Objetos.
Diferente de JavaScript, que é executada no cliente, o PHP é uma linguagem interpretada
executada em um servidor. Seu código é executado no servidor, gerando um HTML que é enviado
para o usuário cliente. Dessa forma, o cliente somente recebe o resultado da execução desse script,
não sabendo o código fonte que o compreende. Para tal, é necessário um servidor web executando o
PHP. Segundo o site oficial do projeto, o PHP é suportado pela grande maioria dos servidores web
atuais, incluindo Apache, Microsoft Internet Information Server (IIS), Personal Web Server, etc.
(PHP, 2009).
A linguagem PHP é uma linguagem muito extensível, uma gama de bibliotecas para
manipulação dinâmica de imagens, XML, banco de dados, documentos PDF, arquivos compactados
zip, entre outras, são encontrados no site oficial do projeto, muitas inclusive, já vem no pacote de
download padrão da linguagem, bastando somente ativá-las em seu arquivo de configuração (PHP,
2009). Nesse projeto de conclusão de curso é necessário ativar a biblioteca GD, biblioteca esta,
responsável pela manipulação de imagens e, a biblioteca ZIP, responsável pela manipulação de
arquivos de arquivos compactados.
Uma das mais fortes características do PHP é o seu amplo suporte a uma grande variedade
de banco de dados. Para este trabalho de conclusão de curso foi utilizado o banco de dados gratuito
42
MySQL. Sendo este, um SGBD (Sistema de Gerenciamento de Banco de Dados) amplamente
utilizado na web (PHP, 2009).
2.1.10.1 Tecnologias especiais
Nesta subseção são apresentadas as tecnologias especiais que foram empregadas para
facilitar no desenvolvimento deste Trabalho de Conclusão de Curso. Chama-se de especial, neste
Trabalho de Conclusão de Curso, as tecnologias que tem a finalidade de oferecer um suporte de
complementos com facilidades para o desenvolvimento de outra tecnologia.
jQuery
O jQuery é uma biblioteca JavaScript, open source que tem como objetivo simplificar o
desenvolvimento de scripts em JavaScript. A biblioteca jQuery prove um conjunto de
funcionalidade com o propósito de abstrair camadas de scripts comuns no desenvolvimento web em
JavaScript. O núcleo original da biblioteca prove diversas facilidades para se trabalhar com o
JavaScript, entre estas pode-se destacar funcionalidades para acessar e alterar elementos no
documento HTML (DOM), modificar a aparência do documento HTML através de CSS, realizar
animações em elementos do HTML, facilidade para realizar tarefas comuns como percorrer arrays,
além de uma ampla facilidade em se trabalhar com AJAX (CHAFFER; SWEDBERG, 2009)
Além das funcionalidades presentes no núcleo original. O jQuery é uma biblioteca
amplamente extensível através de plug-ins que podem ser baixados diretamente no site oficial do
projeto (CHAFFER; SWEDBERG, 2009).
A biblioteca jQuery foi amplamente utilizada neste trabalho de conclusão de curso, toda e
qualquer manipulação de eventos e elementos HTML, incluindo requisições AJAX, foram
realizados através da biblioteca. Em alguns casos foi necessário plug-ins extras, como é o caso da
interface de integração visual com o usuário, onde para tal, foi utilizado uma biblioteca de expansão
ao jQuery chamada jQueryUI.
2.2 Projeto OBAA
O projeto a ser desenvolvido por esse trabalho de conclusão de curso encontra-se situado
dentro do projeto OBAA (Objetos de Aprendizagem Baseados em Agentes), cuja pesquisa é
43
desenvolvida por diversos pesquisadores de outras universidades, tendo como base a da
Universidade Federal do Rio Grande do Sul.
O projeto OBAA tem como objetivo reunir as tecnologias dos objetos de aprendizagem e
sistemas multiagentes. Os objetos de aprendizagem são construídos baseados em agentes para
prover maior flexibilidade, adaptabilidade e interatividade com os ambientes educacionais. O
objetivo geral do projeto é desenvolver uma especificação para que objetos de aprendizagem
interativos possam operar nas plataformas web, televisão digital e dispositivos móveis, e que
atendam requisitos pedagógicos e de acessibilidade (OBAA, 2009).
Dentre os objetivos específicos estão a convergência da tecnologia de agentes para os
objetos de aprendizagem e a computação pervasiva para a construção e recuperação de objetos de
aprendizagem em tempo aceitável e em contextos variados; desenvolvendo uma especificação para
a distribuição de objetos de aprendizagem que permitem a fácil identificação pelos mecanismos de
buscas da web atuais, isto é, eles precisam ser codificados em um formato interoperável (OBAA,
2009).
Inicialmente, o projeto buscou reunir esforços em permitir a interoperabilidade entre
conteúdos web e da televisão digital interativa. Em um segundo momento, a pesquisa será
continuada para os dispositivos móveis (OBAA, 2009).
O projeto OBAA foi inicialmente dividido em quatro grupos de trabalho: pedagógico,
televisão digital, aspectos inteligentes e gerenciamento do conteúdo. O grupo pedagógico estuda as
especificações, analisa os objetos de aprendizagem existentes em alguns repositórios, e
desenvolvem objetos de aprendizagem operáveis na web e TV digital. O grupo da televisão digital é
responsável pelo estudo dos padrões para a televisão digital, com o foco no ISDB-TB, e apoio na
adaptação do objeto de aprendizagem selecionado pelo grupo pedagógico, permitindo que as
definições brasileiras para a televisão digital sejam compatíveis com a tecnologia web. O grupo de
aspectos inteligentes é responsável pela definição e implementação de uma arquitetura multiagente.
Por fim, o grupo de gerência de conteúdo estuda os objetos de aprendizagem nos repositórios
CESTA (Coletânea de Entidades de Suporte ao uso de Tecnologia na Aprendizagem) e SACCA
(Sistema Automático de Catalogação de Conteúdo Audiovisual). A Figura 36 apresenta a estrutura,
conceitos e tecnologias utilizadas no projeto OBAA (OBAA, 2009).
44
Figura 36. Conceitos e tecnologias relacionadas ao projeto
Fonte: OBAA (2009)
Sendo assim, a ferramenta à ser desenvolvida por este trabalho de conclusão de curso irá
facilitar e auxiliar na produção de conteúdos para a televisão digital interativa inseridos dentro do
projeto OBAA, podendo ser estes conteúdos, objetos de aprendizagem. A Figura 37 explana melhor
esse conceito.
45
Figura 37. Ferramenta no contexto do projeto OBAA. Fonte: OBAA (2009)
3 DESENVOLVIMENTO
Hoje, para o desenvolvimento de aplicações interativas, vários softwares são conhecidos
pela comunidade da TV Digital Interativa. Dentro destes, destaca-se a ferramenta Composer e o
NCL-Eclipse, onde ambas são ferramentas feitas exclusivamente para se trabalhar no desktop, não
tendo qualquer função que possa permitir o compartilhamento de trabalho entre os usuários das
ferramentas. E para se trabalhar em ambas, é indispensável conhecimento técnico do usuário pelo
middleware Ginga.
A ferramenta foi desenvolvida e seu funcionamento está totalmente voltado para a web,
onde o ambiente já é propício no sentido de compartilhamento de dados entre usuários e, também já
visando à facilidade no processo de configuração da ferramenta. A ferramenta foi desenvolvida em
PHP por ser uma linguagem bastante conhecida e difundida para a web, já visando o
aperfeiçoamento da mesma. Foi usado MySQL como seu banco de dados, por ser também bastante
difundido e, rápido no ambiente web.
A usabilidade do programa está focada na simplicidade. O usuário enviará ou, buscará do
repositório, as mídias que irá compor o seu aplicativo interativo, os tipos de mídias que serão
aceitas pela ferramenta estão citadas no Apêndice A. Arquivos procedurais como LUA e Java não
serão aceitos pela ferramenta. O nível de interatividade imposto na ferramenta permite ao usuário
definir como uma mídia iniciará em seu projeto, se por consequência do início ou do término de
alguma outra mídia ou, permitirá ao usuário, definir interações entre as mídias através do botão
vermelho, azul, verde ou amarelo do controle remoto. O tamanho limite de uma mídia a ser enviada
ficará por conta da infra-estrutura a ser usada, não terá limite neste sentido imposto pela ferramenta.
Após definir as mídias a serem usadas, o usuário especificará como elas irão se relacionar
vinculando-as.
3.1.1 Requisitos Funcionais
RF01: O sistema deve permitir ao administrador remover uma mídia enviada pelo usuário.
RF02: O sistema deve permitir ao administrador remover um usuário do sistema.
RF03: O sistema deve permitir que os usuários se cadastrem no sistema.
47
RF04: O sistema deve permitir o usuário e/ou administrador fazer login no sistema através
dos dados cadastrados.
RF05: O sistema deve permitir que os usuários e administradores recuperem suas senhas.
RF06: O sistema deve permitir o usuário enviar mídias de imagem, vídeo e/ou som ao
repositório de mídias.
RF07: O sistema deve permitir ao usuário remover as mídias enviadas por ele.
RF08: O sistema deve permitir ao usuário criar seu programa interativo usando as suas
mídias enviadas ao repositório ou as de outros usuários, desde que a mídia esteja compartilhada
pelo usuário que a enviou.
RF09: O sistema deve permitir ao usuário realizar o download dos programas interativos
criados.
RF10: O sistema deve permitir que o usuário liste e use as mídias que estão no repositório de
mídias.
RF11: O sistema deve permitir ao usuário compartilhar como publica ou privada as suas
mídias enviadas ao repositório de mídias.
RF12: O sistema deve permitir ao usuário modificar seus programas interativos.
3.1.2 Diagrama de Casos de Usos
A modelagem dos casos de uso deste projeto está definida em dois módulos. O módulo do
administrador e o módulo do usuário, conforme explanado na Figura 38.
48
Figura 38. Diagrama de pacotes dos casos de usos
3.1.2.1 Pacote 01: Módulo Administrador
Este pacote apresenta os casos de usos referentes ao módulo do administrador. Este pacote é
composto pelo ator Administrador que além de ter as responsabilidades de administrar o sistema,
tem características herdadas do ator Usuário, este que será citado mais adiante, conforme Figura 39.
Figura 39. Casos de usos do módulo administrador
3.1.2.2 Pacote 02: Módulo Usuário
Este pacote apresenta os casos de usos referentes ao módulo do usuário. Este pacote é
composto pelo ator Usuário, ator que interage com o propósito do sistema em si conforme Figura
40.
49
Figura 40. Casos de usos do módulo usuário
No caso de uso Adicionar Mídias e Manipular programa interativo, serão cadastrados
metadados relacionados à mídia e ao programa final. Tais metadados serão definidos por um projeto
de pesquisa que está em andamento e, assim que definidos farão parte deste trabalho de conclusão
de curso.
3.1.3 Diagrama de atividades
Nesta seção é apresentado o diagrama de atividades que o usuário pode realizar na
ferramenta. Conforme Figura 41, primeiramente o usuário necessita realizar um cadastro no
sistema, sendo este, utilizado pelo usuário para realizar o seu login e trabalhar no desenvolvimento
de seus programas interativos. Enquanto o usuário esta manipulando o seu programa interativo, o
repositório pode ser acessado para selecionar as mídias que poderão compor o seu programa
interativo.
50
Figura 41. Diagrama de atividades da visão geral do uso da ferramenta.
3.1.4 Diagrama de Entidade-Relacionamento
Nesta seção é apresentado o modelo final de Entidade-Relacionamento (ER). A Figura 42
ilustra as entidades participantes do projeto e seus respectivos relacionamentos no banco de dados.
O modelo final aqui apresentado sofreu modificações ao longo do desenvolvimento do TCCII para
o modelo apresentado inicialmente. As mudanças foram realizadas a fim de melhorar e simplificar o
modelo ER do projeto final.
51
Figura 42. Diagrama de Entidade-Relacionamento
3.1.5 Implementação
A etapa de implementação compreendeu a codificação deste trabalho de conclusão de curso
consolidando todo o trabalho em uma ferramenta final. O processo de codificação do sistema foi
realizado utilizando uma ferramenta de codificação livre chamada Komodo Edit, disponível para
download em http://www.activestate.com/komodo_edit/. A opção por esta ferramenta se deu pelo
motivo de ser leve, livre e pela facilidade de se integrar-se à diversas tecnologias como a linguagem
52
de programação PHP e JavaScript, incluindo um módulo que oferece facilidades de auto-completar
funções e verificador de sintaxe válida para a biblioteca jQuery.
Durante a implementação da ferramenta foram realizados testes em ambiente local. Por se
tratar de uma ferramenta desenvolvida exclusivamente para o ambiente web, é necessário ter este
servidor instalado e configurado no ambiente de teste. Para este cenário, foi utilizado o servidor
Apache com o módulo PHP devidamente configurado. O banco de dados MySQL também precisa
estar instalado e configurado.
O presente trabalho buscou seguir rigorosamente os padrões estabelecidos pelo consórcio
W3C. O W3C é responsável por estabelecer padrões a serem seguidos no desenvolvimento web.
Assim, pode-se manter a compatibilidade em diversos navegadores que implementam estes padrões,
como o Firefox, Opera, Safari e, Internet Explorer 8.
3.1.6 Funcionamento da ferramenta
Com o objetivo de explanar o melhor funcionamento da ferramenta desenvolvida por esse
trabalho de conclusão de curso, nesta seção são apresentados os passos básicos para a utilização e
desenvolvimento de uma aplicação à TV Digital Interativa baseados em NCL. Os passos serão
baseados nas telas da ferramenta no módulo do usuário, já que o módulo de administração conta
com as mesmas finalidades incluindo permissões administrativas de remoção de usuário, mídias e
aplicações.
Para iniciar o processo de uso da ferramenta o usuário terá que abrir o seu navegador e
acessar o endereço em que a ferramenta foi instalada. Ao acessar, será requisitada a autenticação na
ferramenta, caso o usuário não tenha cadastro no sistema, o mesmo poderá se cadastrar
selecionando a opção Novo Usuário. Tendo efetuado o login com sucesso, será exibida a tela
principal da ferramenta com as opções disponíveis, conforme apresentado na Figura 43.
53
Figura 43. Tela principal da ferramenta
Na tela Programas NCLs, são listados todos os programas previamente criados pelo usuário
na ferramenta. É através desta tela que o usuário poderá remover, modificar e/ou realizar o
download do seu programa interativo. A Figura 44 ilustra os programas criados pelo usuário.
Figura 44. Tela de listagem de aplicações interativas desenvolvidas pelo usuário
Antes de desenvolver a sua aplicação NCL, o usuário terá que selecionar no repositório as
mídias que poderão fazer parte de sua aplicação interativa. Para tal, o mesmo poderá enviar ao
repositório suas próprias mídias, selecionando a opção Enviar mídia ou, selecionar as mídias já
existentes no mesmo bastando selecionar a opção Repositório.
Na tela de envio de mídias, apresentada na Figura 46, antes do envio de qualquer mídia, caso
a mesma não seja de sua autoria, o usuário deve ter a permissão para publicação da mídia. Antes de
entrar na tela de envio de mídias o Termo de Uso lhe é exibido, conforme Figura 45.
54
Figura 45. Termos de Uso da ferramenta.
Para cada mídia a ser enviada o usuário deverá especificar um título para a mesma,
escolher a própria mídia a ser enviada, um screenshot para a mídia, adicionar tags que permitirá
uma melhor localização desta no repositório e, permitir a visibilidade pública ou não da mídia para
outros usuários. Assim como o título da mídia, o screenshot é utilizado para uma melhor referência
da mídia no projeto. A imagem que representa o screenshot poderá ser enviada para mídias do tipo
vídeo, áudio, texto ou HTML, já que para esses elementos, com as tecnologias utilizadas para o
desenvolvimento deste trabalho de conclusão de curso, não é possível exibi-los na tela na forma de
um preview como uma referencia a mídia.
55
Figura 46. Tela de envio de mídias
Na tela que representa o repositório, conforme Figura 47, o usuário terá a sua disposição
para usar em seu projeto, todas as mídias enviadas ao repositório que foram definidas com
visibilidade pública e, todas as suas mídias enviadas ao mesmo, sejam elas definidas como públicas
ou não. O usuário deve selecionar as mídias que poderão fazer parte do seu projeto. As mídias
selecionadas são gravadas em cookies, desta forma, têm-se total liberdade de navegação por parte
do usuário, seja na ferramenta ou em outros sites, desde que o navegador não seja fechado, sem
perder as mídias que foram selecionadas.
56
Figura 47. Repositório de mídias
Após selecionar as mídias no repositório, o usuário poderá selecionar a opção Desenvolver
NCL no menu principal, opção esta, que lhe apresentará a tela com o propósito da ferramenta em si,
onde o mesmo poderá desenvolver toda a sua aplicação baseada em NCL à TV Digital Interativa.
Figura 48. Tela de desenvolvimento de aplicações à TV Digital Interativa
57
A Figura 48, apresenta a tela de desenvolvimento de aplicações. Sua composição é dividida
em três visões, são elas: (i) Workspace; (ii) Menu com as mídias selecionadas do repositório e, (iii)
Opções aplicáveis ao projeto em desenvolvimento.
Na visão 1 é exibida a área de trabalho do usuário, conhecida como workspace, é nessa
visão que o usuário realizará o desenvolvimento do seu projeto com as mídias disponíveis no menu.
Após as mídias estarem aqui disponíveis, todo o controle de visão espacial é realizado através da
interface Drag-and-drop (arrastar e soltar). Com um duplo clique sobre a mídia pode-se facilmente
acessar as suas propriedades aplicadas e modificá-las. Questões de posicionamento e
redimensionamento são aqui aplicados. Cabe ressaltar que tanto os valores de posicionamento
quanto os valores de redimensionamento são valores calculados em porcentagem com os valores da
dimensão do workspace, será esse o valor exportado no arquivo .ncl à ser executado no ambiente
Ginga.
Na visão 2 é exibido um menu com as mídias selecionadas do repositório. Essas mídias
poderão fazer parte do projeto do usuário. Ao selecionar uma mídia presente no menu, uma janela
com propriedades é exibida para aplicá-las àquela mídia, onde após a configuração, essa
automaticamente fará parte do workspace do usuário. A primeira mídia a ser adicionada ao
workspace é considerada como uma mídia inicial, sendo esta, a porta do contexto de entrada da
aplicação.
Na visão 3 são exibidas as opções aplicáveis ao projeto. O item 1, representado por uma
“placa”, refere-se a hierarquia de uso da aplicação desenvolvida pelo workspace, nessa opção é
exibido os links dos conectores criados de forma implícita pelo usuário ao, pelo menu, adicionar
uma mídia com sua ação de início em relação a outra mídia, dessa forma, exibindo como as mídias
se comportarão no tempo. O item 2 exibe as mídias presentes no workspace permitindo alterar as
propriedades da mesma, tendo por objetivo, facilitar para o usuário quando há diversas mídias
presentes no workspace dificultando o duplo clique na mesma. O item 3 permite ao usuário
visualizar e/ou adicionar links dinâmicos. Este item tem como finalidade não deixar o usuário preso
aos links implícitos que são criados ao adicionar uma nova mídia no workspace, deixando o usuário
mais livre às restrições que podem ser impostas por uma ferramenta de autoria. Cabe resaltar que os
links criados por este item não são exibidos no item hierarquia de uso. Através do item 4 o usuário
pode abrir o repositório direto da tela de desenvolvimento sem precisar sair da mesma. As mídias
selecionadas por essa opção são automaticamente adicionadas ao menu para uso imediato pelo
58
usuário. O item 5 tem o objetivo de finalizar o desenvolvimento de sua aplicação interativa. Através
deste item, o usuário poderá salvar o seu desenvolvimento para conclusão ou modificação posterior,
baixar o arquivo compactado em formato .zip para uso no emulador ou na máquina virtual Ginga,
ou, voltar a tela principal da ferramenta.
Para uma melhor compreensão sobre o funcionamento da ferramenta desenvolvida por este
trabalho de conclusão de curso, encontram-se situado no Apêndice, exemplos de construção de
algumas aplicações interativas. O mesmo exemplo é desenvolvido na ferramenta Composer para
fins de comparação.
3.1.7 Dificuldades encontradas
Durante todo o processo de implementação da ferramenta diversas dificuldades foram sendo
encontradas pelo caminho. Dificuldades estas que vão desde em tarefas que inicialmente tinham um
grau de complexidade simples à dificuldades já esperadas em tarefas consideradas complexas.
Diversas dificuldades foram sendo encontradas ao longo do desenvolvimento da interface
usuário com JavaScript. Sendo esta uma linguagem totalmente executada no browser cliente,
tornando totalmente dependente da plataforma sobre a qual esta executando, problemas de
compatibilidade foram surgindo ao trabalhar com o modelo DOM. Após diversas pesquisas,
constatou-se que a biblioteca jQuery, além de facilitar o desenvolvimento em JavaScript, resolve
problemas de compatibilidade entre navegadores, partindo desse tópico a adoção da biblioteca neste
trabalho de conclusão de curso.
Dificuldades também foram encontradas com a linguagem declarativa NCL ao ser emulado
no ambiente virtual Ginga. Alguns bugs foram sendo encontrados na máquina virtual no decorrer
dos testes de execução da linguagem NCL gerada pela ferramenta, o que levou a interrogação de: “o
quê a ferramenta está fazendo de errado?” Depois de testes, foi constatado como erros na máquina
virtual. Um exemplo é na declaração de um nó em NCL. Inicialmente, a ferramenta estava
declarando em NCL as mídias enviadas pelo usuário sem extensão alguma, considerando apenas o
atributo type para especificar o que é aquela mídia. Quando a mídia era um vídeo em MP4 este não
era executado no ambiente virtual. Constatou-se que a NCL não lê o atributo type e sim, a extensão
do arquivo para chamar o exibidor necessário acoplado ao NCL Formatter.
3.2 Testes e validações
59
A etapa de testes e validações foi dividida em duas etapas, sendo que uma delas foi
ocorrendo em paralelo com a codificação da ferramenta e a segunda etapa ocorreu na fase final do
desenvolvimento.
Durante a primeira etapa de testes e validações, testes de compatibilidade e de
funcionalidades da ferramenta foram sendo realizados durante a sua codificação. Os testes de
compatibilidade realizados tiveram o propósito de verificar o comportamento da ferramenta nos
diversos tipos de navegadores disponíveis no mercado. Dentro dos testados, estão o Firefox na sua
versão 3.5, Internet Explorer 8 e o Google Chrome 3. Nesses navegadores testados, todos foram
hábeis a executaram a ferramenta em uma versão funcional, o que leva a conclusão de que qualquer
navegador que implementam os padrões estabelecidos pelo consórcio W3C é hábil à execução da
ferramenta.
Os testes de funcionalidades, ainda na primeira etapa, tiveram como propósito verificar se as
funcionalidades da ferramenta tiveram como resultado final, os resultados planejados antes de sua
implementação. A cada implementação de uma nova funcionalidade, novos testes foram sendo
realizados sobre esta, onde vários erros foram sendo encontrados e já corrigidos antes da
implementação de uma próxima funcionalidade. Seguindo esta metodologia de testes, pôde-se obter
uma melhor confiabilidade dos resultados finais da ferramenta após esta ter sido desenvolvida.
A segunda etapa dos testes e validações ocorreu ao final do processo de desenvolvimento da
ferramenta. Esta etapa teve como propósito verificar se a ferramenta desenvolvida atingiu os
resultados esperados. Os testes se deram pela construção de 20 aplicações interativas, sendo estas,
divididas em três grupos. O primeiro grupo se deu pela construção de 2 aplicações, sendo estas
aplicações, com somente 2 mídias contidas em cada uma delas. O segundo grupo se deu pela
construção de 8 aplicações interativas contendo mais de 5 mídias presentes em cada aplicação
contendo diversos tipos de relacionamentos entre essas mídias. O terceiro grupo, se deu pela
construção de 10 aplicações interativas contendo mais de 5 mídias presentes em cada aplicação
contendo diversos tipos de relacionamentos entre essas mídias, e contendo também, os links
dinâmicos. Após a construção, estas foram sendo executadas no ambiente virtual Ginga. O resultado
esperado tinha que ser exibido conforme a aplicação construída na ferramenta. Aqui, observou-se o
impacto que os testes realizados durante a primeira etapa ocasionou, todas as aplicações
desenvolvidas foram exibidas fielmente no ambiente virtual Ginga.
60
Ainda durante a segunda etapa dos testes e validações, teve como meta disponibilizar a
ferramenta para testes à usuários externos, através de um servidor web. Esta fase, além de verificar
se a ferramenta atingiu os resultados esperados, teve também como objetivo identificar possíveis
pontos fracos na usabilidade da ferramenta. Com os resultado obtidos, algumas melhorias apontadas
foram implementadas na ferramenta, como é o caso dos balões de tooltips que aparecem ao mover o
mouse por certos ícones.
4. CONSIDERAÇÕES FINAIS
Nas referências bibliográficas, destacaram-se conceitos como a interatividade presente no
modelo brasileiro da TV Digital com seu middleware Ginga. Mesmo este sendo tratado de caráter
normativo nos dias de hoje, com o estudo e a modelagem da ferramenta proposta neste projeto, tem-
se a conclusão que o middleware brasileiro já se mostra de forma bem hábil e madura quanto ao seu
funcionamento, não ingressando já nas residências dos brasileiros, talvez, por questões que não
sejam técnicas.
Com o estudo das ferramentas similares, constatou-se que as mesmas são complexas e
voltadas a usuários que compreendam a base técnica que compõe um documento hipermídia, não
levando em conta que muitas pessoas entusiastas da televisão, não têm noção de teorias e/ou
práticas no desenvolvimento computacional.
Acredita-se que com a ferramenta desenvolvida pode-se acelerar e facilitar o processo de
desenvolvimento das aplicações interativas, através de uma interface que dispense qualquer
codificação por parte do usuário tornando até os mais leigos aptos a criarem aplicações interativas,
e, permitindo o reuso das mídias enviadas por outros usuários, se permitida por estes, criando assim
um repositório compartilhando de mídias. Desta forma, espera-se que a ferramenta desenvolvida
por este trabalho de conclusão de curso, seja bastante proveitosa para o uso por profissionais, como
jornalistas por exemplo, e aperfeiçoamento por diversos meios científicos, como laboratórios, que
pretendem realizar estudos e trabalhos aproveitando o que a interatividade no modelo brasileiro de
TV Digital tem a oferecer.
A modelagem no sistema proposto foi elaborada seguindo os padrões da UML. Foram
apresentados apenas os diagramas na qual se achou relevante para o projeto. Tendo estes diagramas,
como base do funcionamento da ferramenta que foi desenvolvido ao longo de todo o TCC II.
Durante a implementação da ferramenta e um maior aprofundamento nas bibliografias
referentes à linguagem NCL, várias modificações foram necessárias no projeto inicial, devido ao
fato de que muitas funcionalidades da linguagem NCL que inicialmente estavam previstas, não
seriam contempladas no desenvolvimento do TCC II, tendo como finalidade, deixar a ferramenta o
mais simples possível ao usuário. Essas modificações aumentaram de forma significativa a
qualidade da ferramenta final desenvolvida.
62
Uma das principais mudanças está na forma como os conectores seriam tratados. No TCCI
foi descrito que toda a especificação e controle de uso dos conectores seriam implementadas e
controladas no SGDB, durante o andamento de implementação da ferramenta no TCCII, a
especificação foi realizada em um arquivo externo sendo este anexado à aplicação do usuário
quando o mesmo realizar o download, bastando somente controlar no SGDB os links da aplicação
do usuário que utilizará estes conectores. Desta forma, têm-se um melhor nível de aproveitamento e
um melhor controle de manutenção, já que para qualquer modificação, seja ela alteração ou
adicionar uma nova regra de semântica para links, basta somente realizar a manutenção neste
arquivo.
Uma das mudanças mais visíveis está na apresentação das telas em comparação aos
protótipos apresentados no TCCI. No TCCII, toda a interface foi modelada para o usuário trabalhar
com interface drag-and-drop (método arrastar e soltar). Isso permite um melhor controle da
aplicação por parte do usuário e uma usabilidade mais favorável do que a apresentada nos
protótipos, já que agora, todo o controle de desenvolvimento da aplicação pode ser realizado em
uma interface apenas. Desta forma, eliminam-se todos os formulários que o usuário teria que
utilizar em diversas telas.
Enfim, as atividades previstas para o TCCII foram realizadas e os seus resultados podem ser
verificados no decorrer deste trabalho. Todos os objetivos específicos previstos para esta fase foram
cumpridos, entretanto, o resultado final deste trabalho de conclusão de curso poderá ser melhorado
com a inclusão de novas funcionalidades à ferramenta.
Alguns trabalho futuros sugeridos são:
Aceitar conteúdo procedural Java e/ou LUA: com a ferramenta aceitando este tipo de
conteúdo, o usuário experiente em desenvolver aplicações à TV Digital poderá
definir recursos de scripts que somente uma aplicação procedural é capaz de
fornecer;
Melhoramento das funcionalidades referentes à interação do telespectador com a
aplicação: o único nível de interação do usuário com as mídias, disponível na
ferramenta desenvolvida por este Trabalho de Conclusão de Curso, é através dos
botões vermelho, verde, amarelo e azul do controle remoto. Atualmente não é aceito
as setas direcionais para a navegação entre as mídias;
63
Emular a aplicação desenvolvida diretamente no servidor: com a possibilidade de
emular a aplicação direta no servidor, elimina-se a necessidade de o usuário realizar
o download de sua aplicação compactada em formato .zip a fim de realizar os testes
em seu ambiente Ginga;
Aceitar a utilização de vídeos de ferramentas como o YouTube: o YouTube é
considerado um enorme repositório de vídeos;
Adicionar as propriedades aceitas aos descritores à ferramenta: os descritores
fornecem um melhor controle da mídia pelo usuário, com isso, o mesmo poderá
definir a transparência de exibição de uma imagem ou o controle de volume de um
arquivo de áudio, por exemplo;
Melhorar os recursos de pré-visualização das mídias presentes no workspace: a
ferramenta desenvolvida por este Trabalho de Conclusão de curso só aceita preview
em mídias do tipo imagem. Para mídias do tipo áudio, HTML, texto e vídeo, o
usuário terá que se localizar pelo título declarado a ela, dificultando assim, a
localização imediata da mídia na qual procura.
64
ARTIGO ACEITO PARA PUBLICAÇÃO
A publicação abaixo é decorrente ao trabalho realizado durante o período de
desenvolvimento deste trabalho de conclusão de curso:
LOURENCI, Leandro; SILVA, Júlia Marques Carvalho da; WEBER, Mathias Henrique. Proposta
de Ferramenta de Apoio à Construção de Programas para a TV Digital Interativa
baseados em NCL, 2009, Florianópolis. XX Simpósio Brasileiro de Informática na Educação,
2009.
REFERÊNCIAS BIBLIOGRÁFICAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 15606-2. Televisão digital terrestre: Codificação de dados e especificações de transmissão para radiodifusão digital: Parte 2: Ginga-NCL para receptores fixos e móveis: Linguagem de aplicação XML para codificação de aplicações. Rio de Janeiro, 2007.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS; COMISSÃO DE ESTUDO ESPECIAL TEMPORÁRIA DE TELEVISÃO DIGITAL. PROJETO 00:001.85-006/4. Televisão digital terrestre: Codificação de dados e especificações de transmissão para transmissão digital: Parte 4: Ginga-J - Ambiente para a execução de aplicações procedurais. Rio de Janeiro, 2007.
BARBOSA, Simone Diniz Junqueira; SOARES, Luiz Fernando Gomes. TV digital interativa no Brasil se faz com Ginga: Fundamentos, Padrões, Autoria Declarativa e Usabilidade. In: BARBOSA, Simone Diniz Junqueira; SOARES, Luiz Fernando Gomes. TV digital interativa no Brasil se faz com Ginga: fundamentos, padrões, autoria declarativa e usabilidade. Rio de Janeiro: PUC-Rio, 2008. Cap. 3, p. 105-174.
BECKER, Valdecir. Trabalhando com links e conectores na linguagem NCL. Disponível em: <http://imasters.uol.com.br/artigo/12446/tvdigital/trabalhando_com_links_e_conectores_na_linguagem_ncl/>. Acesso em: 13 jun. 2009.
CHAFFER, Jonathan; SWEDBERG, Karl. Learning jQuery 1.3. Birmingham: Packt Publishing. 2009.
CORREIO DO POVO. TV Digital faz sua estréia no Brasil. Disponível em: <http://www.mc.gov.br/jornais-e-revistas/tv-digital-faz-sua-estreia-no-brasil>. Acesso em: 13 jun. 2009.
DTV. SITE OFICIAL DA TV DIGITAL BRASILEIRA. Disponível em <http://www.dtv.org.br/>. Acesso em: 06 mar. 2009.
ECMA. ECMASCRIPT LANGUAGE SPECIFICATION. Disponível em <http://www.ecma-international.org/>. Acesso em: 11 mar. 2009.
FLANAGAN, David; Javascript: O Guia Definitivo. 4ª Edição. Bookman. 2006.
GINGA. GINGA DIGITAL TV MIDDLEWARE SPECIFICATION. Disponível em <http://www.ginga.org.br/>. Acesso em: 11 mar. 2009.
GINGA-NCL. GINGA-NCL – DECLARATIVE DTV MIDDLEWARE. Disponível em <http://www.gingancl.org.br/>. Acesso em: 11 mar. 2009.
66
GUIMARÃES, Rodrigo Laiola. Composer: um ambiente de autoria de documentos NCL para TV digital interativa. 2007. 106 f. Dissertação (Mestrado) - Puc-rio, Rio de Janeiro, 2007.
HDMI. High-Definition Multimedia Interface. Disponível em: <http://www.hdmi.org/manufacturer/technology.aspx >. Acesso em: 13 jun. 2009.
HOWSTUFFWORKS. Como funcionam os controles remotos. Disponível em: <http://eletronicos.hsw.uol.com.br/controle-remoto.htm>. Acesso em: 13 jun. 2009.
IBGE. Pesquisa Nacional por Amostra de Domicílios. Disponível em <http://www.ibge.gov.br/home/presidencia/noticias/noticia_visualiza.php?id_noticia=1230&id_pagina=1>. Acesso em: 11 mar. 2009.
KELLISON, Cathrine; GERHARDT, Natalie. Produção e direção para TV e vídeo. Rio de Janeiro: Elsevier: Campus. 2007.
LABORATÓRIO TELEMÍDIA; Ambiente para Desenvolvimento de Aplicações Declarativas para a TV Digital Brasileira. Disponível em: <http://www.ncl.org.br/documentos/MDIC2007.pdf>. Acesso em: 13 jun. 2009.
LUA; Manual de Referência de Lua 5.1; Disponível em: <http://www.lua.org/manual/5.1/pt/>. Acesso em: 13 jun. 2009.
MATTOS, Sérgio. Um perfil da TV Brasileira: 40 anos de história. Associação Brasileira de Agências de Propaganda. Salvador. 1990.
MONTEZ, Carlos; BECKER, Valdecir. TV Digital Interativa: conceitos, desafios e perspectivas para o Brasil. 2ª Edição. Florianópolis: UFSC. 2005.
MORONI, Hebert. Criação de Sites em Ajax. Digerati Editorial. 2007.
MOZILLA. MOZILLA DEVELOPER CENTER. Disponível em: <https://developer.mozilla.org/en/about_javascript>. Acesso em: 4 nov. 2009.
NCL. NESTED CONTEXT LANGUAGE. Disponível em: <http://www.ncl.org.br/>. Acesso em: 14 jun. 2009.
NETO, Carlos de Salles Soares et al. Construindo Programas Audiovisuais Interativos Utilizando a NCL 3.0 e a Ferramenta Composer. Disponível em: <http://www.ncl.org.br/documentos/TutorialNCL3.0-2ed.pdf>. Acesso em: 14 jun. 2009.
OBAA. Relatório parcial do projeto OBAA: objetos de aprendizagem baseados em agentes. Porto Alegre, Universidade Federal do Rio Grande do Sul, 2008.
PHP. Hypertext Preprocessor. Disponível em: <http://www.php.net>. Acesso em 4 nov. 2009.
67
PICCOLO, Lara Schibelsky Godoy. Arquitetura do Set-top Box para TV Digital Interativa. Disponível em: <http://www.ic.unicamp.br/~rodolfo/Cursos/mo401/2s2005/Trabalho/039632-settopbox.pdf>. Acesso em: 13 jun. 2009.
POSITIVO. DigiTV Positivo. Disponível em: <http://www.digitvpositivo.com.br/>. Acesso em: 13 jun. 2009.
SOARES, Luiz Fernando Gomes; RODRIGUES, Rogério Ferreira; Nested context model 3.0: part 1 – NCM Core, Rio de Janeiro, 2005.
TELECO. Lançamento da TV Digital no Brasil. Disponível em: <http://www.teleco.com.br/tvdigital_cronog.asp >. Acesso em: 13 jun. 2009.
URI; UNIFORM RESOURCE IDENTIFIER; Disponível em: <http://labs.apache.org/webarch/uri/rfc/rfc3986.html>. Acesso em: 13 jun. 2009.
APÊNDICES
A. PROJETO
Tabela 1. Mídias aceitas pela ferramenta a ser desenvolvida
Tipo de mídia Extensão de arquivo text/html htm, html text/plain txt image/png png image/gif gif image/jpeg jpg, jpeg audio/mp3 mp3 audio/mpeg mpeg, mpg video/mpeg mpeg, mpg
A.1 CASOS DE USOS
A modelagem dos casos de uso deste projeto está definida em dois módulos. O módulo do
administrador e o módulo do usuário, conforme explanado na Figura 38.
Figura 49. Diagrama de pacotes dos casos de usos
A.1.1 Pacote 01: Módulo Administrador
70
Este pacote apresenta os casos de usos referentes ao módulo do administrador. Este pacote é
composto pelo ator Administrador que além de ter as responsabilidades de administrar o sistema,
tem características herdadas do ator Usuário, este que será citado mais adiante, conforme Figura 39.
Figura 50. Casos de usos do módulo administrador
UC1.01. Remover mídia
Caso de uso responsável por remover uma mídia do sistema.
Relações
RF01: O sistema deve permitir ao administrador remover uma mídia enviada pelo
usuário.
Condições
Pré Condição: O administrador deve estar autenticado no sistema.
Pós Condição: A mídia é removida.
Cenário
Fluxo Principal: Remover mídia
1. O sistema exibe a tela com todas as mídias enviadas pelos usuários.
2. O administrador seleciona uma mídia.
3. O administrador clica em remover mídia.
71
4. O sistema remove a mídia.
Fluxo de Exceção 1: Selecionar mídia
No passo 2 se o administrador não selecionar uma mídia, o sistema exibe a mensagem "Uma
mídia deve ser selecionada".
UC1.02. Remover usuário
Caso de uso responsável por remover um usuário do sistema.
Relações
RF02: O sistema deve permitir ao administrador remover um usuário do sistema.
Condições
Pré Condição: O administrador deve estar autenticado no sistema.
Pós Condição: O usuário é removido.
Cenário
Fluxo Principal: Remover usuário
1. O sistema exibe a tela com todos os usuários cadastrados no sistema.
2. O administrador seleciona o usuário.
3. O administrador clica em remover usuário.
4. O sistema remove o usuário.
Fluxo de Exceção 1: Selecionar usuário
No passo 2 se o administrador não selecionar um usuário o sistema exibe a mensagem "Um
usuário deve ser selecionado".
A.2.1 PACOTE 02: Módulo USUÁRIO
72
Este pacote apresenta os casos de usos referentes ao módulo do usuário. Este pacote é
composto pelo ator Usuário, ator que interage com o propósito do sistema em si conforme .
Figura 51. Casos de usos do módulo usuário
UC2.01. Realizar cadastro
Caso de uso responsável pelo cadastro do usuário no sistema.
Relações
RF03: O sistema deve permitir que os usuários se cadastrem no sistema.
Condições
Pós Condição: O usuário é cadastrado.
Cenário
Fluxo Principal: Realizar cadastro
1. O sistema apresenta uma tela solicitando o login e senha do usuário.
73
2. O usuário escolhe a opção de criar um cadastro.
3. O sistema apresenta a tela de cadastro.
4. O usuário preenche seus dados.
5. O usuário clica no botão cadastrar.
6. O sistema valida o cadastro.
7. O sistema emite a mensagem “Usuário cadastrado”.
Fluxo de Exceção 1: Campos obrigatórios
Se no passo 6 os campos não forem preenchidos, o sistema emite a mensagem: "Todos os
campos são de preenchimento obrigatório!"
Fluxo de Exceção 2: Usuário existente
Se após o passo 6 o sistema identificar que já existe os dados cadastrados, o sistema emite a
mensagem: "Usuário já cadastrado!".
UC2.02. Efetuar login
Caso de uso responsável pelo autenticado do usuário no sistema.
Relações
RF04: O sistema deve permitir o usuário e/ou administrador fazer login no sistema
através dos dados cadastrados.
Condições
Pré Condição: O usuário e/ou administrador deve estar previamente cadastrado no
sistema.
Pós Condição: O usuário e/ou administrador efetua o login no sistema.
Cenário
74
Fluxo Principal: Efetuar login
1. O sistema apresenta uma tela solicitando o login e a senha do usuário.
2. O usuário digita seu login e senha.
3. O usuário clica no botão efetuar login.
4. O sistema valida o login e a senha fornecida.
5. O sistema apresenta a tela principal do usuário.
Fluxo de Exceção 1: Campos obrigatórios
Se no passo 4 os campos não forem preenchidos, o sistema emite a mensagem: "Todos os
campos são de preenchimento obrigatório!" retornando ao passo 1.
Fluxo de Exceção 2: Dados inválidos
Se no passo 4 o usuário e/ou senha fornecida não poderem ser validados, o sistema apresenta
a mensagem "Usuário e/ou senha inválidos" retornando ao passo 1.
UC2.03. Recuperar senha
Caso de uso responsável pela recuperação da senha pelo usuário e/ou administrador.
Relações
RF05: O sistema deve permitir que os usuários e administradores recuperem suas senhas.
Condições
Pré Condição: O usuário e/ou administrador deve estar previamente cadastrado no
sistema.
Pós Condição: A senha é enviada para o e-mail do usuário e/ou administrador.
Cenário
Fluxo Principal: Recuperar senha
75
1. O sistema apresenta uma tela solicitando o login do usuário.
2. O usuário deve preencher seu login previamente cadastrado.
3. O usuário clica no botão enviar senha.
4. O sistema valida o login fornecido.
5. A senha é enviada para o e-mail previamente cadastrado.
6. O sistema emite a mensagem: "Senha enviada!".
Fluxo de Exceção 1: Campos obrigatórios
Se no passo 4 os campos não forem preenchidos, o sistema emite a mensagem: "Todos os
campos são de preenchimento obrigatório!" retornando ao passo 1.
Fluxo de Exceção 2: Dados inválidos
Se no passo 4 o usuário fornecido não poder ser validado, o sistema apresenta a mensagem
"Usuário inválido" retornando ao passo 1.
UC2.04. Adicionar mídias
Caso de uso responsável por adicionar as mídias ao repositório de mídias.
Relações
RF06: O sistema deve permitir o usuário enviar mídias de imagem, vídeo e/ou som ao
repositório de mídias.
Condições
Pré Condição: O usuário deve estar autenticado no sistema.
Pós Condição: A mídia é adicionada ao repositório de mídias.
Cenário
Fluxo Principal: Adicionar mídias
76
1. O sistema apresenta a tela para o usuário escolher uma mídia de seu computador e
preencher as opções referentes a mesma.
2. O usuário seleciona uma mídia de seu computador, preenche as opções e clica em
enviar.
3. O sistema apresenta a mensagem "Enviando mídia" ao usuário.
4. O sistema valida a mídia enviada e a envia para o servidor.
5. O sistema exibe a mensagem "Mídia enviada".
Fluxo de Exceção 1: Campos obrigatórios
No passo 2 se uma mídia não for selecionada para envio, o sistema apresenta uma
mensagem "É obrigatório selecionar uma mídia".
Fluxo de Exceção 2: Mídia incompatível
No passo 4 caso a mídia enviada não seja compatível com o sistema, a mensagem "A mídia
não pode ser enviada" é exibida ao usuário.
UC2.05. Remover mídias
Caso de uso responsável por remover as mídias ao repositório de mídias.
Relações
RF07: O sistema deve permitir ao usuário remover as mídias enviadas por ele.
Condições
Pré Condição: O usuário deve estar autenticado no sistema.
Pré Condição: O usuário deve ter enviado uma mídia ao repositório.
Pós Condição: A mídia é removida do repositório de mídias.
Cenário
77
Fluxo Principal: Remover mídias
1. O sistema apresenta a tela de repositório com as mídias enviadas pelo usuário.
2. O usuário seleciona a mídia que deseja apagar e clica em apagar mídia.
3. O sistema valida as informações e remove a mídia.
4. O sistema exibe a mensagem "Mídia apagada".
Fluxo de Exceção 1: Campos obrigatórios
No passo 2, caso o usuário não selecione a mídia o sistema apresenta a mensagem "Uma
mídia deve ser selecionada".
UC2.06. Manipular programa interativo
Caso de uso responsável pela criação e modificação do programa interativo.
Relações
RF08: O sistema deve permitir ao usuário criar seu programa interativo usando as suas
mídias enviadas ao repositório ou as de outros usuários, desde que a mídia esteja
compartilhada pelo usuário que a enviou.
RF12: O sistema deve permitir ao usuário modificar seus programas interativos.
Condições
Pré Condição: O usuário deve estar autenticado no sistema.
Pós Condição: O sistema disponibiliza o programa desenvolvido para o download do
usuário.
Cenário
Fluxo Principal: Manipular programa interativo
1. O usuário seleciona se deseja criar um novo programa interativo ou, modificar um
existente.
78
2. No caso de modificação, a tela para selecionar os seus programas criados é
apresentada.
3. A tela para o desenvolvimento do programa interativo é apresentada.
4. O usuário desenvolve ou modifica a sua aplicação interativa criando vínculos entre
as mídias.
5. O usuário clica em salvar.
6. O sistema valida e salva o programa interativo do usuário.
7. O sistema exibe a mensagem "Programa interativo salvo".
UC2.07. Realizar download
Caso de uso responsável por realizar o download do programa interativo.
Relações
RF09: O sistema deve permitir ao usuário realizar o download dos programas interativos
criados.
Condições
Pré Condição: O usuário deve estar autenticado no sistema.
Pré Condição: O usuário deve ter criado algum programa interativo.
Pós Condição: O download do programa interativo é realizado pelo usuário.
Cenário
Fluxo Principal: Realizar download
1. O sistema apresenta a tela de programas criados pelo usuário.
2. O usuário seleciona o programa que deseja realizar o download e clica em realizar
download.
79
3. O sistema valida as informações e envia o programa.
Fluxo de Exceção 1: Selecionar programa
No passo 2 se um programa não for selecionado, o sistema apresenta a mensagem "É
necessário selecionar um programa.”.
UC2.08. Manipular as mídias do repositório
Caso de uso responsável por listar, classificar o compartilhamento das mídias e permitir que
as mídias presentes no repositório de mídias sejam usadas.
Relações
RF10: O sistema deve permitir que o usuário liste e use as mídias que estão no
repositório de mídias.
RF11: O sistema deve permitir ao usuário compartilhar como pública ou privada as suas
mídias enviadas ao repositório de mídias.
Condições
Pré Condição: O usuário deve estar autenticado no sistema.
Pós Condição: A mídia é usada no programa do usuário ou o compartilhamento da mídia
é classificado.
Cenário
Fluxo Principal: Manipular as mídias do repositório
1. O sistema apresenta a lista de mídias do repositório de mídias.
2. O usuário seleciona a mídia a ser usada ou classificada e seleciona a opção que
deseja realizar..
3. O sistema valida as informações e insere a mídia no projeto ou classifica a mídia,
dependendo da opção selecionada.
Fluxo de Exceção 1: Selecionar mídia
80
No passo 2 se o usuário não selecionar uma mídia, o sistema exibe a mensagem "É
necessário selecionar uma mídia".
A.2 TUTORIAL DE CONSTRUÇÃO DE UMA APLICAÇÃO INTERATIVA NA FERRAMENTA DESENVOLVIDA
Para uma melhor compreensão sobre o funcionamento da ferramenta desenvolvida por este
trabalho de conclusão de curso, nesta seção é apresentado um exemplo de desenvolvimento de uma
aplicação interativa na ferramenta. Para tal, foi utilizada a aplicação desenvolvida na Figura 33,
sendo esta aplicação, um bom exemplo de sincronia entre mídias. A fim de simplificar o exemplo,
leva-se em consideração que as mídias já foram enviadas ao repositório e as mesmas selecionadas.
Ao selecionar Desenvolver NCL, as mídias são carregadas no menu, conforme Erro! Fonte
de referência não encontrada., e então, prontas para serem usadas no workspace.
Figura 52. Mídias carregadas no menu.
O primeiro passo é selecionar a mídia de entrada (porta) da aplicação NCL, no caso deste
exemplo, é selecionada a mídia de vídeo. Conforme Erro! Fonte de referência não encontrada.,
antes de a mídia ser inserida no workspace algumas opções são apresentadas na tela para a
configuração pelo usuário.
81
Figura 53. Propriedades da mídia inicial
Na tela de configuração da mídia, o usuário deverá definir um nome à mídia que será usado
no workspace. Como padrão definido na ferramenta, a primeira mídia a ser inserida no projeto
sempre é definida como mídia inicial. O usuário também pode definir se deseja que a mídia fique
em loop, dessa forma cria-se implicitamente um link para o conector que representa semanticamente
um loop. A opção de sobreposição das mídias também pode ser configurada, sendo esta, utilizada
para definir qual mídia ficará sobreposta sobre outra. Sendo este número mais elevado, mais
sobreposta a mídia ficará em relação a outras menos sobrepostas. Nota-se que valores negativos são
aceitos. Ao selecionar Inserir mídia a mesma é adicionada ao workspace, conforme Erro! Fonte de
referência não encontrada..
82
Figura 54. Mídia inserida no workspace
Após a mídia vídeo estar inserido no workspace, o segundo passo é inserir a mídia do tipo
HTML e configurar para que a mesma se inicie imediatamente ao início da mídia de vídeo,
conforme exibido na Erro! Fonte de referência não encontrada..
83
Figura 55. Configuração da mídia HTML
Ao selecionar a opção hierarquia de uso é exibido quando as mídias serão iniciadas em
relação a outras no projeto. Conforme a Erro! Fonte de referência não encontrada., a mídia
“vídeo” está indicada como a mídia inicial do projeto e a mesma tem um conector indicando que
deve ficar em loop. A mídia “html” juntamente com um desenho de play, imediatamente
apresentada a direita e abaixo da mídia que ela esta usando como referencia para início, indica que a
mesma será executada ao iniciar a mídia “vídeo”.
84
Figura 56. Hierarquia de uso.
Com as duas mídias necessárias para a execução deste exemplo inseridas no workspace, o
projeto está pronto para ser compactado em formato .zip e realizado o download pelo usuário. Para
isto, deve-se selecionar o ícone indicado por uma “bandeira” na área de opções. Na tela de
finalização de projeto, o usuário terá que selecionar a opção de compactar e realizar o download
deste arquivo compactado, essa ação é indicada por uma “caixa”, conforme Erro! Fonte de
referência não encontrada..
Figura 57. Finalização do projeto
Após realizar o download, basta somente executar o arquivo executar.ncl,apresentado na
Erro! Fonte de referência não encontrada.na máquina virtual ou no emulador do ambiente
Ginga.
85
Figura 58. Arquivo compactado a ser executado no ambiente Ginga.
À fins de comparações com a ferramenta desenvolvida, o mesmo exemplo será desenvolvido
no Composer.
No Composer, diferente da ferramenta desenvolvida por este trabalho de conclusão de curso,
para inserir uma mídia ao projeto primeiramente tem-se que definir uma região. Conforme já
apresentado na fundamentação teórica, a região é responsável por controlar a posição e as
dimensões da área onde a mídia será apresentada. Para tal, na tela principal do programa, o usuário
deve selecionar a opção Insert presente no menu, após, Region. Conforme apresentado na Figura 59
uma região chamada “rgVideo”, com dimensões de 300 pixels de altura e 400 pixels de largura,
posicionamento de 400 pixels de acordo com a margem superior e de 300 pixels com a margem
esquerda, é adicionada ao projeto.
86
Figura 59. Região na ferramenta Composer.
Após inserir a região, o próximo passo é definir o descritor, sendo este, responsável pela
definição de como uma mídia irá se apresentar, incluindo a sua associação com uma região. Para
tal, na tela principal do programa, o usuário deve selecionar a opção Insert presente no menu, após,
Descriptor. Conforme apresentado na Figura 60 um descritor chamado “dsVideo”, associado a
região “rgVideo”, é adicionada ao projeto.
87
Figura 60. Descritor na ferramenta Composer.
O próximo passo é inserir a mídia e associá-la ao descritor. Para tal, na tela principal do
programa, o usuário deve selecionar a opção Insert presente no menu, após, Media. Conforme
apresentado na Figura 61, uma mídia chamada “video”, associada ao descritor “dsVideo”, é inserida
ao projeto.
88
Figura 61. Mídia na ferramenta Composer.
Para executar o exemplo proposto a ser desenvolvido por este tutorial, é necessário inserir a
mídia do tipo HTML. A fim de simplificar o processo, os passos serão omitidos, sendo que para tal,
os mesmos procedimentos já executados para a mídia “vídeo” são necessários. Após inseridas, as
mesmas são apresentadas na visão Structural View, conforme Figura 62.
89
Figura 62. Structural View na ferramenta Composer.
Após adicionar as mídias com os seus devidos descritores e regiões, é necessário definir
como uma mídia irá se relacionar a outra. Para tal, na Structural View o usuário deve selecionar as
mídias que farão parte do relacionamento e, na tela principal do programa, o usuário deve
selecionar a opção Insert presente no menu, após, Causal Link.. Conforme apresentado na Figura
63, é definido um link chamado “aoIniciar_Inicia”, pertencente aos regras “onBegin” e “start”,
sendo que quando iniciar a mídia “vídeo” também deva iniciar a mídia “html”.
90
Figura 63. Criar links na ferramenta Composer.
Após inserir os conectores, a aplicação já esta pronta para ser executada no ambiente Ginga.
A Figura 64 apresenta o resultado final na ferramenta Composer da aplicação exemplo
desenvolvida.
91
Figura 64. Exemplo desenvolvido na ferramenta Composer.
Com o mesmo exemplo desenvolvido na ferramenta desenvolvida por este trabalho de
conclusão de curso e na ferramenta Composer, nota-se um perceptível ganho na usabilidade e
facilidade para usuários leigos. Com a ferramenta desenvolvida, usuários leigos estão aptos a
desenvolverem aplicações interativas para a TV Digital, desde que estes usuários tenham
conhecimentos básicos do modelo NCM, modelo este, como já explanado, é baseado no conceito de
relacionamento entre os nós através dos elos.
92
ANEXOS
CONECTORES
Tabela 2. Papéis de condições
Papel Descrição (o elo será ativado quando...) onBegin ... a apresentação do nós de mídia associado ao papel onBegin for iniciada onEnd ... a apresentação do nós de mídia associado ao papel onEnd for terminada onAbort ... a apresentação do nós de mídia associado ao papel onAbort for abortada onPause ... a apresentação do nós de mídia associado ao papel onPause for pausada onResume ... a apresentação do nós de mídia associado ao papel onResume for retomada onSelection ... uma tecla <key> for pressionada, ou quando a tecla OK for pressionada
enquanto um nó de mídia estiver com o foco onAttribution ... um valor <value> for atribuído
Fonte: NETO et al. (2007).
Tabela 3. Papéis de ações
Papel Descrição (quando o elo for ativado...) Start ... inicia a apresentação do nó de mídia associado ao papel start stop ... termina a apresentação do nó de mídia associado ao papel stop abort ... aborta a apresentação do nó de mídia associado ao papel abort pause ... pausa a apresentação do nó de mídia associado ao papel pause resume ... retoma a apresentação do nó de mídia associado ao papel resume (caso esteja
em pausa) set ... estabelece um valor <value> à âncora associada ao papel set onAttribution ... um valor <value> for atribuído
Fonte: NETO et al. (2007)