Introdução ao Desenvolvimento de Aplicações para Televisão Digital

Transcrição

1 Capítulo 4 Introdução ao Desenvolvimento de Aplicações para Televisão Digital Mario Godoy Neto 1,2, Carlos André Guimarães Ferraz 2 1 Universidade Federal do Vale do São Francisco (UNIVASF) Av. Antonio Carlos Magalhães, 510, Country Club, CEP: Juazeiro-BA. 2 Centro de Informática - Universidade Federal de Pernambuco (CIn/UFPE) Av. Jornalista Anibal Fernandes, s/n, Cidade Universitária, CEP: Recife-PE mario.godoy@univasf.edu.br, {mgn, cagf}@cin.ufpe.br Autores vinculados ao projeto: RH TVD / CAPES. Abstract This book chapter aims at providing the initial bases of theories and practices necessary to enable the training of new software application developers for Digital Television. The main characteristics that make the development of software for such platform a unique experience will be exposed. In the course of this chapter, we will explain the functioning of the Brazilian Digital Terrestrial Television System (SBTVD- T), from content production, transmitting, receiving, Set-Top Box functioning, function of the Ginga-NCL middleware, installation of development environment and the development of NCL applications. Resumo Este trabalho tem por objetivo oferecer as bases iniciais de teorias e práticas necessárias para viabilizar a capacitação introdutória de novos desenvolvedores de aplicações de software para Televisão Digital. Serão expostas as principais características que tornam o desenvolvimento de software para essa plataforma uma experiência única. Ao decorrer desse capítulo, será explanado sobre o funcionamento do Sistema Brasileiro de Televisão Digital Terrestre (SBTVD-T), desde a produção de conteúdo, transmissão, recepção, funcionamento do Set-Top Box, função do middleware

2 Ginga-NCL, instalação do ambiente de desenvolvimento e o desenvolvimento de aplicações em NCL. 1. Introdução a Televisão Digital Desde a primeira transmissão televisiva no Brasil, em 18 de setembro de 1950, viabilizada por Assis Chateaubriand, os tele-espectadores estão acostumados a assistir passivamente o conteúdo que é enviado pelas retransmissoras de sinal de maneira unilateral. Diante disso, alguns paradigmas culturais devem ser levados em consideração, no processo de produção de aplicações para TV Digital (TVD). Com a forte iniciativa governamental visando a implantação do Sistema Brasileiro de Televisão Digital Terrestre (SBTVD-T), o tele-espectador deixará de ser um simples e passivo visualizador de conteúdo, e passará a ser um usuário, interagindo diretamente com aplicações, grades de programações, retransmissoras, podendo até mesmo trocar informações com outros usuários. O decreto 5.820, de 29/junho/2006 e a portaria n. 652, do Ministério das Comunicações, publicado em 10 de outubro de 2006, determinam que as emissoras e retransmissoras de sinal localizadas nas capitais e no Distrito Federal, deverão iniciar suas transmissões de sinal no formato digital até junho de As demais retransmissoras localizadas em outras localidades possuem o prazo até junho de Vale ressaltar que em 02 de dezembro de 2007, na cidade de São Paulo, iniciou o funcionamento do SBTVD-T. O SBTVD-T possui entre seus diferenciais a utilização do padrão MPEG 4, que possui maior compressão do conteúdo enviado, isso permite que sejam enviados uma maior quantidade de fluxos de sinal pela mesma frequência de banda, o que viabiliza a transmissão simultânea de múltiplos programas (multiprogramação), além da alta qualidade de imagem e som, diferente de outros sistemas de transmissão utilizados por outros países que utilizam o padrão MPEG 2, com menor capacidade de compressão. Além disso, o SBTVD-T permite a recepção de sinal televisores fixos, móveis e portáteis, convergência com Internet, e uma infra-estrutura tecnológica que possibilita a transmissão de aplicações interativas de software, gerando assim, uma crescente demanda de aplicações voltadas para contexto de TV Digital (TVD). O projeto e implantação do SBTVD-T está baseada em um formato aberto de distribuição de sinal, essa é uma característica relevante, pois garante que o sinal de TV seja gratuito para todos os usuários, tornando a demanda por aplicações ainda mais alta devido a larga quantidade de telespectadores. Essa é uma característica que se difere dos sistemas implantados em outros países, onde existem empresas que oferecem serviços pagos de TVD, normalmente, disponibilizados via cabo. Ao observar a Figura 1, é possível acompanhar as fazes do SBTVD-T desde a produção de conteúdo digital, até a recepção e exibição para o usuário.

3 Figura 1. Fluxo de funcionamento do SBTVD-T Fonte: [Laboratório TeleMídia PUC-RIO]. Diante da figura acima, é possível acompanhar a produção e início dos fluxos de vídeo, áudio e aplicativos interativos, ou seja, dados. Em seguida, esses três conteúdos passam por um multiplexador (MUX), condensando os três fluxos em apenas um chamado de Broadcasting Transport Stream [Ferreira, 2009]. Esse fluxo único é segmentado e enviado em diversos pacotes menores. Nessa fase, é utilizado um recurso chamado Carrossel de Dados, responsável por enviar e sincronizar os diversos segmentos de pacotes de dados durante um determinado período de tempo, desta forma, o Set-top Box receptor poderá organizar a recepção do sinal de forma ordenada, sem perda de dados. Esse conteúdo é transmitido via antenas terrestres até o aparelho receptor de sinal (Set-Top Box), localizado na residência do telespectador. O receptor realiza a função inversa da transmissão, demodula e demultiplexa o TS, transformando-o novamente em três fluxos distintos áudio, vídeo e aplicativos (dados). Existe também a possibilidade de interatividade entre o usuário e a emissora, com outros usuários ou outro dispositivo conectado ao sistema. Isso ocorre através do canal de interatividade, também conhecido como canal de retorno. No entanto, esse canal de interatividade ainda está na fase de definição formal de um padrão pelos órgãos competentes. Conforme citado anteriormente, o receptor de sinal digital (Set-Top Box) é responsável por receber o TS da emissora, demodular e demultplexar o sinal, separá-lo em três fluxos distintos de vídeo, áudio e dados, e encaminhar cada um desses fluxos

4 para o componente interno responsável pela sua exibição, conforme demonstrado na Figura 2. Figura 2. Funcionamento do hardware de um Set-Top Box Fonte: [Laboratório TeleMídia PUC-RIO]. Após a demultiplexação do sinal, o fluxo de dados é enviado a uma Unidade Central de Processamento (CPU), através dela, as aplicações são processadas e disponibilizadas para o usuário. Além disso, a figura acima mostra que o Set-Top Box possui outros recursos de hardware como memória, barramentos e dispositivos de entrada e saída (In/Out). Desta forma, podemos considerar que um Set-Top Box é um computador, utilizado para um fim específico, ou seja, viabilizar a recepção do conteúdo transmitido pela emissora e permitir a interação do usuário com o SBTD-T. Partindo desse princípio, a partir desse momento, substituiremos o rótulo de telespectador de TV, por usuário de TV. No entanto, somente a infra-estrutura de hardware não basta para o funcionamento do Set-Top Box. Como qualquer outro computador, é necessário um sistema operacional para gerenciar os recursos de hardware disponíveis, e alocar esses recursos para os processos que os solicitam. Na Figura 3 abaixo são demonstradas como interagem as diferentes camadas de software com o hardware do Set-Top Box.

5 Figura 3. Funcionamento do hardware e software em um Set-Top Box Fonte: [Laboratório TeleMídia PUC-RIO]. Como explicado anteriormente, o gerenciamento do hardware do Set-Top Box, ocorre através de um Sistema Operacional (SO). Não existe uma restrição rígida para a escolha SO, essa escolha fica a critério da empresa desenvolvedora do Set-Top Box. Existem diversos fabricantes e versões de SO disponíveis para essa plataforma, como Linux, Windows CE, entre outros. Esses diferentes de fabricantes e versões poderiam acarretar em grande uma dificuldade para os desenvolvedores de software para TVD, pois as aplicações deveriam ser implementadas para cada tipo de SO. Esse foi um dos motivos que levou ao projeto e desenvolvimento do middleware open-source Ginga 1 representado na figura acima. Resumidamente, como o próprio nome já diz, um middleware é uma camada intermediária utilizado para viabilizar a interação entre dois software distintos. Desta forma, o desenvolvedor de aplicações para TVD não precisa ter conhecimento do sistema operacional instalado no Set-Top Box, ou seja, o desenvolvedor não irá implementar um aplicação para um SO e sim para o middleware Ginga. 1

6 Existem dois módulos distintos, porém interligados, do middleware Ginga, cada um focado em um paradigma de desenvolvimento distinto, são eles o Ginga-J e o Ginga-NCL. O Ginga-J oferece a infra-estrutura necessária para executar as aplicações procedurais Java 2 voltadas para TVD, no entanto, as versões de Java devem ser restritas ao Ginga-J. O Ginga-J não faz parte do foco desse trabalho. O Ginga-NCL realiza a apresentação de conteúdos multimídia para aplicações declarativas desenvolvidas tanto na linguagem NCL, como também em linguagens de script LUA. Grande parte das aplicações podem ser desenvolvidas utilizando apenas NCL/LUA, esta foi uma das motivações que levou sua escolha como linguagem de desenvolvimento desse trabalho. Mais detalhes sobre NCL e LUA no decorrer desse capítulo. A camada acima do middleware Ginga, representa as diversas aplicações de TVD que podem ser executadas sobre diferentes plataformas. Vale lembrar que o SBTVD-T possui como meios de recepção de sinal vários dispositivos como: televisores residenciais, ambientes mobile (celulares), televisores móveis (ônibus, metrô, carro) e computadores, tornando o Ginga inda mais necessário para a recepção de aplicações devido a grande variedade de plataformas. No entanto, tais plataformas possuem características distintas quanto a sua capacidade de desempenho, e interface de interação, tendo em vista tais limitações, é importante que as aplicações desenvolvidas sejam limitadas aos recursos disponíveis pelas plataformas receptoras. Outra peculiaridade inerente as aplicações de TVD, é a necessidade do seu desenvolvimento em um curto espaço de tempo, acompanhando o ritmo e a velocidade com que a informação é produzida e veiculada pela emissora. Além disso, as aplicações necessitam despertar o interesse dos usuários, caso contrário, tempo e custo despedido em seu desenvolvimento poderá não alcançar o objetivo desejado, causando prejuízo à empresa desenvolvedora, e insatisfação do usuário. Tendo em vista os conteúdos transmitidos ao vivo, como telejornais, esportes, entrevistas, notícias de última hora, entre outros, não é aceitável que a grade de conteúdo fique dependente da esperada do desenvolvimento da aplicação de software para que tais conteúdos sejam veiculados. Sendo assim, faz-se necessário que o desenvolvimento de aplicações para TVD seja extremamente ágil, eficaz e confiável, de modo que as aplicações consigam acompanhar a grade de programação de maneira aceitável tanto para a emissora, quanto para os usuários, para isso, é fundamental que os desenvolvedores conheçam as diversas peculiaridades inerentes às aplicações de TVD. 2. Peculiaridades das Aplicações Juntamente com os novos recursos disponíveis no SBTVD-T, surgem também novas necessidades relacionadas às distintas características encontradas em seu desenvolvimento, abaixo são destacadas algumas das principais. 2

7 Usabilidade existem significativas limitações como a interação do usuário com as aplicações, pois isso ocorre apenas por meio do controle remoto da TV. Assim faz-se necessário voltar à atenção para desenvolvimento de aplicações intuitivas e de fácil assimilação do usuário. Desempenho os Set-Top Box possuem limitações de hardware e software como: processamento, armazenamento, memória, e ainda a velocidade e disponibilidade do canal de retorno. Tais limitações tornam o desenvolvimento das aplicações diferenciado das aplicações tradicionais, que podem utilizar infra-estruturas mais robustas como computadores desktops. Confiabilidade as aplicações enviadas para os usuários devem ser totalmente confiáveis, são inaceitáveis erros como: travar a plataforma receptora do usuário, ausência de imagem ou de áudio. É necessário considerar que os usuários não possuem conhecimento técnico, e possivelmente não saberão resolver erros de aplicativos, o que pode gerar uma eventual aversão às aplicações de TVD. Para aumentar a confiabilidade das aplicações, é fundamental que seja elaborada uma bateria de testes. Os testes de aplicações de TVD devem considerar as particularidades das plataformas a serem instaladas. Deve-se também considerar diferentes estágios e tipos de teste, tanto em emuladores que permitam o teste preliminar das aplicações diretamente por seus desenvolvedores, quanto em redes de teste que permitam simular o ambiente real no qual as aplicações irão funcionar, e finalmente, chegando ao estágio do teste da aplicação diretamente no ambiente de produção do cliente. Diferente do desenvolvimento de software tradicional (computador pessoal, notebook ou celular) uma aplicação que está em funcionamento em uma televisão, normalmente, pode ser visualizada por mais de um usuário, como por exemplo, uma família assistindo sua programação preferida, uma televisão em locais públicos, entre outras diversas possibilidades. Essa característica não pode ser ignorada no momento de desenvolver uma aplicação, pois, ao interagir com a aplicação, um usuário normalmente não deseja exibir seus dados pessoais aos demais telespectadores, podendo gerar desconforto. É comum que surja a necessidade de mais de um usuário interagir com a aplicação. Pensando nessa característica, existem algumas pesquisas em andamento que pretendem enviar uma versão customizada da aplicação via bluetooth aos aparelhos celulares dos demais usuários. 3. Possíveis Metodologias de Desenvolvimento de Aplicações. Quando se pretende desenvolver uma aplicação de software, um dos primeiros passos é se planejar uma forma de coleta de requisitos. No contexto de TVD isso também se faz necessário devido a grande variedade de usuários com as mais diferentes características sócio culturais. Devido ao amplo alcance desse meio de comunicação, a definição e entendimento do público-alvo da aplicação a ser desenvolvida são de suma importância. Apenas aplicações muito simples podem ser genéricas o suficiente para atender muitos públicos. Fatores como classe social podem indicar maior/menor índice de escolaridade

8 e disponibilidade de um canal de retorno de qualidade associado ao equipamento. A idade pode indicar facilidade ou dificuldade de interação com o controle remoto. Tais fatores são, portanto, fundamentais na escolha dos mecanismos de interação com o usuário para o desenvolvimento de um aplicativo ou jogo com conteúdo textual, por exemplo. Dificilmente, uma aplicação atende a todos os grupos de usuário. Além da questão do público-alvo, a análise e especificação de requisitos deve já levar em consideração a plataforma de TVD a ser desenvolvida, para entender melhor os recursos disponíveis e limitações existentes para desenvolvimento de aplicações naquela plataforma em específico. Como citado anteriormente, uma aplicação de TVD se difere significativamente de uma aplicação para desktop. Existem uma série de restrições no que se refere a recursos disponíveis (tamanho e resolução de tela, quantidade de cores, formas e dispositivos de interação com o usuário, contexto dos usuários, e baixa memória e poder de processamento). Semelhante ao desenvolvimento de software tradicional, as aplicações para TVD também necessitam de disciplinas técnicas de engenharia de software, como: análise, especificação de requisitos, arquitetura e padrões de projetos, implementação e testes [Gamma, 1995]. Outra dificuldade enfrentada pelos desenvolvedores de aplicações para TVD é o tempo gasto no desenvolvimento e teste de aplicações que serão enviadas para as plataformas receptoras de sinal digital dos usuários. Embora existam metodologias ágeis citadas e comparadas por [Qureshi, 2008], estas são voltadas para o desenvolvimento de software convencional, ou seja, software utilizado em plataformas tradicionais com estruturas robustas como desktops/pcs. Para auxiliar o processo de desenvolvimento de aplicações, é possível adaptar características encontradas nas metodologias Scrum [Sutherland, 2008], [Soares, 2007], Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Extreme Programming (XP) [Beck, 1998] entre outras, escolher as boas práticas mais adequadas ao projeto em desenvolvimento. Segundo [Boehm, 2003], métodos ágeis oferecem maior aceitação, possuem curto tempo de desenvolvimento, menor quantidade de defeitos e são mais adequados a mudanças constantes do projeto. Segundo o autor, cinco fatores são fundamentais na seleção de metodologias ágeis, são eles: tamanho do time de desenvolvimento, nível de segurança necessário para a aplicação, nível de possibilidades de mudança do projeto, nível de qualificação de recursos humanos e cultura de aceitação ao caos. Para definir uma metodologia de engenharia de software adequada ao contexto de TVD, é necessário que estas sejam estudadas a fundo, quando necessário, adaptadas pelo time de desenvolvimento ao projeto de software levando em consideração todas as peculiaridades encontradas em aplicações para TVD e dificuldades levantadas dentro do seu ciclo de desenvolvimento. Tais metodologias podem ser utilizadas para minimizar as dificuldades enfrentadas pelos desenvolvedores de aplicações, relatadas no início desse capítulo, porém, não fazem parte do foco do presente trabalho. Interessados devem procurar as referências supracitadas.

9 4. Introdução a NCL O Nested Context Language (NCL) 3 é uma linguagem de declarativa baseada no modelo Nested Context Model (NCM), que obedece os princípios determinados pela W3C para elaborar documentos de hipermídia. Esta seção é baseada no seguinte trabalho [Soares Neto, 2007]. O conceito de hipermídia foi definido inicialmente como uma reunião de várias mídias viabilizadas por algum suporte computacional [Scavetta, 1997], e desta forma se mantém até os dias atuais. A linguagem NCL oferece diversos recursos, os principais são descritos abaixo. Manipular as relações de hipermídia, permitindo gerar sincronismo e referências independentes dos relacionamentos existentes. Utilizar conectores de hipermídia na criação de elos. Reutilizar os elos existentes em documentos distintos. Definir portas e mapear os nós de composição. Especificar a semântica e o reuso das estruturas e restrições sobre documentos, através da elaboração de templates de composição hipermídia. Elaborar documentos com diferentes possibilidades de conteúdos. Elaborar de diferentes possibilidades de apresentação. Utilizar de layout espacial, o que permite definir o posicionamento dos objetos e do dispositivo de saída. A NCL oferece módulos utilizados para especificar conectores e templates de composição, conhecidos respectivamente como XConnector e XTemplate, estas estruturas podem facilmente ser incorporadas as outras linguagens utilizadas na web, como: XLink, XHTML e SMIL Um documento de hipermídia normalmente é formado por nós (nodes) e elos (links). Conforme citado anteriormente, a linguagem NCL auxilia a construção de documentos de hipermídia seguindo o modelo NCM, desta forma, os grafos podem ser aninhados, permitindo assim uma subdivisão do documento de hipermídia, para isso, existe a função dos nós de composição ou contexto, conforme exibido na Figura 4. Figura 4. Representação de elos e contexto

10 Desta forma, podemos ter dois tipos de nós: nó de conteúdo (ou nó de mídia) - vinculado diretamente a um objeto de mídia (vídeo, áudio, imagem, texto); nó de composição (ou nó de contexto) define um sub-conjunto de elementos, um escopo restrito. 4.1 Estrutura de um Documento de Hipermídia Existem alguns pontos fundamentais na criação de um documento de hipermídia, são eles: o que se pretender exibir; onde (em qual região da tela) se pretende exibir; como se pretende exibir; quando se pretende exibir. O que se pretender exibir (nós de mídia) - os conteúdos de mídias como vídeo, áudio e imagem, são as primeiras atividades a serem definidas. Para representar esses conteúdos, são utilizados nós de mídia. Cada nó de mídia está contido dentro de algum contexto. Na linguagem NCL, o contexto principal é definido pelo elemento <body>, contendo todos os nós de mídia ou sub-contextos do documento em questão, Diante da Figura 5 exibida abaixo, é possível visualizar a representação do corpo de um documento com dois contextos internos. Figura 5. Representação de contextos Onde se pretende exibir (regiões) - assim que determinado o conteúdo a ser exibido, surge a necessidade de escolher um local, ou seja, a região na tela onde cada uma das mídias será exibida. Ao criar uma região, é determinada a sua posição e as dimensões da área que irá ocupar, como representado na Figura

11 Figura 6. Representação da definição de regiões Como se pretende exibir (descritor) - para se exibir uma mídia é necessário criar uma associação entre uma mídia e uma região através de um descritor, permitindo assim a definição de algumas características de exibição, como volume do áudio, transparência de uma imagem, entre outros. Quando se pretende exibir (portas e links) - uma das características de uma porta é indicar por qual dos nós de mídias será o primeiro a ser exibido. Para isso, é necessário que seja criado no contexto principal <body> uma porta inicial. É possível iniciar dois nós de mídia em paralelo, para isso, basta inserir duas portas no contexto <body> para dois nós de mídia distintos. Desta forma, as portas são utilizadas para tornar tanto os nós de mídia, como os nós de contexto, acessíveis a outro contexto qualquer. Para determinar quando um nó de mídia será exibido e seu sincronismo entre os demais nós de mídias, são utilizados os elos <links>, o comportamento desses elos é definido pelos conectores detalhados nas próximas seções. 4.2 Estrutura de um Documento NCL Um documento NCL é um arquivo escrito no padrão XML 4 composto basicamente pelos elementos descritos a seguir. Cabeçalho do arquivo XML <?xml version="1.0" encoding="iso "?>. Início do documento NCL <ncl id="meudocncl">. Seção de cabeçalho <head> são definidos os seguintes elementos: regiões <regionbase>; descritores <descriptorbase>; conectores <connectorbase>; Corpo do programa <body> são definidos os seguintes elementos: portas <port>; 4

12 contextos necessários <context>; nós de mídia <media>; elos <link>; entre outros elementos. Ao observar a figura abaixo, dentro da tag base de regiões <regionbase>, são definidas duas regiões identificadas por regtela e a regmidia. Observe na Figura 7 que estas regiões estão aninhadas, ou seja, a região regmidia está posicionada dentro da região regtela. Figura 7. Definição de região Note na figura acima que na região "regtela" existem três atributos, são eles: width (largura em pixels), height (altura em pixels) e id (identificador), e esta região representa a área total disponível pela tela. Já na região "regmidia", existem também outros dois atributos, left (posição referente ao lado esquerdo) e top (posição referente ao lado superior), as posições aqui definidas estão relacionadas diretamente as margens da região mãe regtela. O elemento descritor <descriptorbase> exibido na Figura 8, determina o comportamento do nó de mídia associado a ele. Este elemento possui dois atributos, o primeiro é a "region", que deve fazer referência a uma região previamente criada, nesse exemplo chamamos essa região de "regmidia", ou seja, será nessa posição/região da tela, que a mídia será exibida. O segundo é o id (identificador do descritor). Figura 8. Definição de um descritor Na Figura 9 um conector é definido pelo comando <connectorbase>, através dele, é possível determinar como os elos são ativados, e o que eles executam, como por exemplo: exibir duas mídias simultaneamente, terminá-las simultaneamente, controlar sua duração, entre outras possibilidades. Similar a muitas outras linguagens (XLS, CSS), é comum que os conectores sejam definidos através um arquivo externo ao código NCL, facilitando o reuso de código. Este conector possui um elemento chamado <importbase>, responsável por importar o arquivo externo de conectores chamado "connectorbase.ncl", que está especificado através do atributo "documenturi". Já o atributo "alias" é um

13 identificador, utilizada pelos elos localizarem e referenciarem essa base importada, conforme figura abaixo. Figura 9. Importar base de conectores No corpo <body> do programa é possível encontrar todos os elementos multimídia que compõe toda a aplicação NCL, estes elementos são sincronizados através de um conjunto de comandos como nós de mídias, portas, elos e âncoras. Conforme citado anteriormente, os nós podem ser de dois tipos, nós de conteúdos ou nós de contexto. Os nós de conteúdos são representados pelo elemento <media>, funcionam como links que apontam para os arquivos de mídia como: imagem, texto puro, texto HTML, vídeo, entre outros. O elemento <media> possui alguns atributos como: "src" (origem/enderço do arquivo), "type" (tipo de mídia), que pode fazer referências a outros tipos de mídia como: image/gif, image/jpeg, image/bmp, video/mpeg, text/plain, text/html e audio/mp3. Estes nós de mídia precisam ainda determinar qual será o descritor que determina seu funcionamento, na Figura 10, isso é realizado através do atributo descriptor="descmidia". Figura 10. Definição de um nó mídia e âncoras Uma âncora de conteúdo é especificada através de uma tag <area>, envolvida pelas tags <media>... </media>, são utilizadas para inserir marcações em nós me mídia ou de contexto, ou seja, realizar um mapeamento de partes desses nós, separado através da definição de um intervalo de tempo. Esses segmentos mapeadas poderão ser utilizados como origem ou destino dos elos. No exemplo da figura acima, existem cinco exemplos de âncoras de conteúdo utilizadas como sincronização de legenda um nó de vídeo. O elemento área é composto pelos atributos "begin" que define o tempo no qual a âncora será ativada e o atributo "end", que determina o tempo final da âncora. Já uma âncora de propriedade é determinada pelo elemento <property> dentro da tag <media>. Esta âncora é utilizada para descrever características inerentes a um nó, estas, podem ser manipuladas pelos elos, como por exemplo: dimensões de uma imagem, volume do áudio, entre outras características.

14 Conforme mostrado na Figura 11, um elo é definido através do elemento <link>, com ele é possível sincronizar os eventos que serão exibidos em um programa NCL, como realizar uma cascata de exibições, iniciar duas mídias em paralelo, iniciar uma mídia após finalizar a outra, entre outras sequências possíveis, para essa sincronização, são utilizados os conectores, que já foram explicados anteriormente. Figura 11. Definição de link Na figura acima, o valor atributo "xconnector" é composto pela referência (alias) "connectors" definindo na base de conectores que será utilizada, juntamente com o nome do conector "onbeginstartn" dessa base deverá ser utilizado. O elemento <bind> especifica o comportamento de cada nó que esse elo está associado. Para isso são necessários os atributos "role" que determina o evento acionado, e o atributo "component", que determina o nó de mídia que será exibido. Ao observar a Figura 12, uma porta é definida pelo elemento <port>, utilizada para acessar um nó que se encontra dentro de um determinado contexto. O tributo id identifica a porta criada, já o tributo component, indica o nome de qual elemento será exibido, nesse exemplo será exibido o contexto1. Figura 12. Definição de porta e contexto A Figura 12 mostra ainda um exemplo de nó de contexto, definido através da tag <context>, os principais atributos de um contexto é o identificador "id", e o atributo opcional "refer", que define uma possível referência a outro contexto. Vale ressaltar que é fundamental que cada elemento NCL possua um identificador id único, similar aos nomes de variáveis utilizadas em linguagens de programação. Agora que já foi detalhada a estrutura básica de um arquivo NCL, a seguir, será detalhado passo a passo como instalar e configurar o ambiente necessário para o desenvolvimento de aplicações para TVD. 5. Instalação e Configuração o Ambiente de Desenvolvimento. A configuração do ambiente de desenvolvimento de aplicações é composta pela instalação das seguintes ferramentas: máquina virtual VMware player, Set-Top Box virtual, configuração da IDE Eclipse, e a instalação dos Plugins NCL, LUA e RSE.

15 5.1 Instalação do VMware O primeiro passo para configurar um ambiente de desenvolvimento de aplicações, é instalar os software necessários para que sua aplicação seja visualizada, para isso, utilizaremos nesse trabalho um player de um maquina virtual chamada de VMware. Essa máquina virtual será necessária para simular o Set-Top Box virtual, onde serão exibidas as aplicações interativas desenvolvidas, os detalhes da instalação do Set- Top Box serão exibidos na próxima seção. Caso já exista uma maquina virtual instalada em seu computador, não há a necessidade de instalar outra, siga para a próxima seção para a instalação do Set-Top Box virtual. Caso contrário, existem algumas versões freeware do VMware, estas podem facilmente adquiridas diretamente site do fabricante através do endereço: A instalação da máquina virtual VMware segue o mesmo padrão da instalação de qualquer outra máquina virtual, no entanto, ao utilizar uma máquina virtual deve-se lembrar os recursos de hardware são divididos com o sistema operacional nativo utilizado no computador, desta forma, é recomendado que o computador possua ao menos 1GB de memória RAM para que sua distribuição não implique em baixo desempenho do sistema. Ao instalar o VMware não há a necessidade de alterar as configurações padrão sugeridas pelo assistente de instalação. Após a instalação, reinicie o computador conforme sugerido pelo assistente, assim que o computador for reiniciado, o VMware já estará pronto para utilização conforme demonstra a Figura 13. Figura 13. Tela inicial do VMware Com a máquina virtual instalada, o próximo passo será instalar o Set-Top Box virtual no VMware, detalhado na seção a seguir. 5.2 Instalação do Set-Top Box virtual Como vimos anteriormente, um Set-Top Box é um computador composto de diversos dispositivos de hardware, software e também dispositivos de entrada e saída. Desta

16 forma, é necessário que o Set-Top Box possua um sistema operacional para gerenciar a comunicação entre esses dispositivos. Em um Set-Top Box podem ser utilizados diversos sistemas operacionais, como Linux, Windows, entre outros. A escolha do sistema operacional depende do fabricante do Set-Top Box. No entanto, esta escolha não interfere no desenvolvimento de aplicações para TVD, pois como dito anteriormente, o middleware Ginga funciona como uma camada intermediária, onde os desenvolvedores de aplicações precisam apenas desenvolver para o middleware, e não para o sistema operacional, este fato é de suma importância para viabilizar a produção de software para as mais diversas plataformas. Existem algumas versões open-source disponíveis para sua instalação, como: Ubuntu Server Ginga, disponível em: Existem também outras distribuições disponíveis como: Fedora Ginga, disponível em: esta última foi adotada no presente trabalho. Após baixar o Set-Top Box virtual escolhido, descompacte-o utilizando qualquer software a sua escolha (winrar, winzip, etc) para iniciar sua instalação. Inicie a máquina virtual VMware, escolha a opção Abra uma máquina virtual (Open a Virtual Machine), indique o diretório onde a imagem do Set-Top Box virtual se encontra, selecione o arquivo descompactado, e pressione o botão abrir (open). Nesse momento, sua máquina virtual deve estar com a aparência similar a Figura 14 mostrada a seguir. Figura 14. Set-Top Box instalado no VMware Para executar o Set-Top Box virtual, basta pressionar o botão Play virtual machine destacado na figura acima. É possível que durante a execução da máquina virtual o VMware sugira algumas atualizações de software, no entanto, isso não se faz necessário para as práticas realizadas no presente trabalho.

17 Vale lembrar que, graças a maquina virtual, nesse momento existem virtualmente dois computadores independentes funcionamento em paralelo. A Figura 15 exibida a seguir representa a tela inicial do Set-Top Box virtual já em funcionamento, que está emulado utilizando o sistema operacional Linux Fedora, deste modo, eventualmente quando for utilizado Set-Top Box virtual, será necessário utilizar comandos de manipulação do sistema operacional Linux, porém, todos os comandos necessários para a execução de aplicações serão mostrados no decorrer deste capítulo. Figura 15. Tela inicial do Set-Top Box Utilizar uma máquina virtual é relativamente simples, porém, iniciantes podem se depara com algumas situações exclusivas dessa atividade. Para utilizar o Set-Top Box (ou o sistema operacional) instalado na máquina virtual, basta selecionar a imagem do Set-Top Box com o mouse. Nesse momento, todos os dispositivos de entrada (mouse, teclado) estão atuando sobre o Set-Top Box, e não mais sobre o sistema operacional nativo, instalado no computador. No VMware, para voltar a utilizar o sistema operacional instalado no computador, basta pressionar as teclas Ctrl e Alt simultaneamente. Na tela inicial do Set-Top Box exibida na Figura 15 existem algumas informações importantes, como: usuário root e senha telemedia, estas informações serão solicitadas sempre aberta um conexão remota com o Fedora Ginga, veremos a utilização desses dados mais adiante. É possível encontrar também o local padrão para upload (transferência) dos arquivos de mídia e das aplicações e desenvolvidas /misc/ncl30, veremos mais adiante como proceder para realizar esse upload.

18 É informado ainda que depois de enviadas as aplicações para o Set-Top Box virtual, a aplicação poderá ser executada utilizando o launcher script já disponível no Linux, através da instrução: /misc/launcher.sh /misc/ncl30/exemplos/teste1.ncl. Dentro do diretório ncl30, é possível criar uma estrutura de diretórios de acordo com a necessidade do desenvolvedor, facilitando assim a organização de suas aplicações. Para interagir com as aplicações, o controle remoto da televisão digital é simulado através do teclado, para isso são utilizadas as teclas setas direcionais acima, abaixo, esquerda, direita, para navegação nas aplicações. São utilizadas também as seguintes teclas de ação: "Enter", "F1", "F2", "F3" e "F4", que representam respectivamente "Ok", Vermelho, Verde, Amarelo e Azul. A qualquer momento que julgar necessário finalizar uma, basta pressionar a tecla F11. Uma última informação, mas não menos importante, disponibilizada na figura acima, é o endereço IP do Set-Top Box virtual, no exemplo citado, temos: É através desse endereço será aberta uma conexão remota com o Set- Top Box, esse passo também será detalhado a seguir. Vale ressaltar que o Linux é case sensitive, ou seja, diferencia caracteres maiúsculos de caracteres minúsculos, deste modo, é necessário redobrar a atenção ao digitar as instruções. 5.3 Configuração da IDE Eclipse A IDE de desenvolvimento Eclipse é de larga utilização dentre os desenvolvedores de software, pois oferece recursos adicionais que auxiliam a programação em diversos paradigmas de linguagens de programação. Para os desenvolvedores de aplicações de TVD não é diferente, o Eclipse oferece uma estrutura satisfatória de auxílio ao desenvolvimento. No presente trabalho, serão utilizados ao máximo os recursos disponíveis no Eclipse para gerenciar o desenvolvimento de aplicações para TVD, serão evitadas outras ferramentas externas, no entanto, vale destacar que é possível utilizar outras ferramentas desvinculadas do Eclipse para executar algumas atividades relatadas a seguir. Para iniciar a utilização do Eclipse é necessário apenas realizar o download da ultima versão disponível no site do fabricante: Após concluído o download, basta descompactar o arquivo, e iniciar o programa executando o arquivo eclipse.exe. Caso não exista um Maquina Virtual Java (Java Virtual Machine) instalada no computador, é necessário instalá-la, esta pode ser adquirida gratuitamente no site: após seu download, siga a instalação padrão sugerida pelo assistente. Ao abrir a IDE Eclipse o assistente solicita a definição de um diretório padrão para o desenvolvimento de aplicações, vamos escolher o diretório local C:\workspace. A Figura 16 mostra a tela de abertura da IDE Eclipse.

19 Figura 16. Definição do workspace de desenvolvimento A partir desse momento, todas as aplicações desenvolvidas ficarão localizadas no diretório c:\workspace. A Figura 17 mostra a tela inicial do Eclipse.. Figura 17. Tela inicial da IDE Eclipse Assim que definido o diretório padrão para o desenvolvimento das aplicações, o próximo passo será instalar os plugins necessários para iniciar desenvolvimento, todos

20 os plugins necessários serão instalados pela própria IDE, os passos necessário serão mostrados nas seções a seguir. 5.4 Instalação do Plugin NCL Para o desenvolvimento de aplicações NCL, é preciso instalar o plugin que agregue a IDE Eclipse tal funcionalidade. Para isso, é necessário acessar o menu Help, em seguida selecionar a opção Install New Software. Em seguida, será aberta uma nova janela onde é preciso pressionar o botão adicionar (Add). Nesse momento, será aberto um pop-up com dois campos a serem preenchidos, Name = NCL e Location = conforme exibido na Figura 18. Figura 18. Instalação do plugin NCL Depois de preenchidos os dois campos, pressione o botão Ok. O próximo passo será escolher qual a versão do NCL desejado, marque a versão 1.5.1, conforme exibido na Figura 19, pressione o botão Next e siga a instalação padrão.

21 Figura 19. Escolha da versão do plugin NCL que será instalada Normalmente, após a conclusão da instalação de um plugin, o assistente solicita que o Eclipse seja reiniciado, aceite a sugestão para todos os plugins instalados. As instalações dos demais plugins seguem os mesmos passos introdutórios, são alterados apenas os campos referentes ao repositório de atualizações Name e Lacation, conforme exibido a seguir. Agora que o NCL está instalado, é possível criar um novo projeto e posteriormente, um novo documento NCL através do menu File, New, Other ou pressionando as teclas de atalho (Ctrl + N) conforme exibido na Figura 20.

22 Figura 20. Criação de um novo projeto ou documento NCL Ao criar um novo projeto NCL o Eclipse gera automaticamente um diretório com o mesmo nome do projeto em seu workspace. Esse diretório é composto por um arquivo padrão de base de conectores ConnectorBase.ncl auxiliando seu reuso, e um diretório media como sugestão de organização de arquivos de mídia. 5.5 Instalação do Plugin LUA Neste trabalho não iremos trabalhar com exercícios práticos em LUA, no entanto, deixaremos o ambiente de desenvolvimento já configurado, facilitando a evolução gradativa dos experimentos para aqueles que pretendem se aprofundar em programação para TVD. A instalação do plugin LUA é similar a instalação do plugin NCL visto anteriormente, para isso, é preciso acessar o menu Help, em seguida Install New Software. A seguir, será aberta uma nova janela onde será preciso pressionar o botão adicionar (Add). Nesse momento, surgirá um pop-up com dois campos, são eles Name e Location, a serem preenchidos pelos seguintes valores LUA Eclipse e respectivamente, em seguida pressione o botão Open. Para instalar o plugin utilizando o sistema operacional Linux, é necessário substituir o campo Location por: Selecione a versão LuaEclipse 1.3.1, pressione "Next", e siga a instalação padrão. Após a conclusão da instalação será necessário reiniciar o Eclipse.

23 É possível definir o interpretador de instruções da linguagem LUA como padrão para os aplicativos desenvolvidos. Na janela principal da IDE Eclipse, selecione o menu "Window", em seguida "preferences", conforme exibido na Figura 21. Figura 21. Definindo o interpretador LUA como padrão A estrutura de diretórios definido no path exibida na figura acima, refere-se ao local onde se encontra a IDE Eclipse descompactada. Agora que o plugin responsável pelo funcionamento do ambiente de desenvolvimento LUA já foi instalado, é possível criar um novo projeto e um novo arquivo LUA de modo similar ao projeto NCL explicado anteriormente, acessando o menu File, New, Other e New Lua Project. Para executar um arquivo LUA, basta ir ao menu executar Run, escolher a opção Run as, e em seguida Lua application. A instalação do plugin Lua Eclipse torna a IDE Eclipse uma ferramenta eficiente para desenvolver aplicações utilizando a linguagem LUA, mais informações sobre programação utilizando essa linguagem no site dos desenvolvedores, no endereço: Neste momento, o ambiente de desenvolvimento já está configurado, no entanto, é necessário que depois de finalizada as implementações das aplicações, estas devem ser enviadas ao Set-Top Box virtual, emulado na maquina virtual VMware. Para isso, é necessário abrir uma conexão entre o Eclipse, e o Set-Top Box virtual, isso será feito através da instalação do plugin RSE, detalhado a seguir. 5.6 Remote System Explorer (RSE)

24 A ferramenta RSE é uma solução eficiente e prática para viabilizar o acesso ao Set-Top Box virtual (Ginga Fedora). A instalação do plugin RSE segue os mesmos passos do plugin NCL e LUA. É necessário acessar o menu Help, em seguida Install New Software. A seguir será aberta uma nova janela, onde é preciso pressionar o botão adicionar (Add). Nesse momento, será aberto um pop-up com dois campos, são eles Name e Location, a serem preenchidos pelos os seguintes valores RSE e respectivamente, em seguida pressione o botão Open. Escolha a versão RSE e siga a instalação padrão. Como de costume, a IDE Eclipse deve ser reiniciada após a instalação de um novo plugin. Assim que instalado o plugin RSE, poderemos começar a interagir com sua perspectiva, para isso, é necessário acessar o menu "Window", "Open Perspective", "Other", e por fim, selecionar a opção "Remote System Explorer". A partir desse momento já é possível enviar aplicações para o Set-Top Box virtual através do RSE, para isso, é fundamental que o VMware esteja aberto e o Set- Top Box esteja em execução. Para se criar uma conexão com um host remoto, é necessário acessar o nome menu Remote Systems, escolher a opção New Connection, e em seguida SSH Only, conforme demonstrado na Figura 22. Figura 22. Criando conexão com Set-Top Box virtual Em seguida é necessário preencher o IP do Set-Top Box exibido em sua tela inicial quando este é executado, em seguida, inserir um nome Set-TopBox para a conexão e finalizar no botão Finish, conforme exibido na Figura 23.

25 Figura 23. Inserção de dados para a conexão remota Ainda é necessário executar a conexão criada para ter acesso ao Set-Top Box, para isso, basta pressionar o botão direito do mouse sobre o nome da conexão criada Set-TopBox, que é exibida do lado esquerdo do Eclipse, em seguida, é necessário informar nome de usuário root e a senha telemidia. Para facilitar o acesso a conexão remota, selecione a opção Save password, caso contrário, sempre que necessitar conectar ao Set-Top Box será solicitado seu usuário e senha. Observe na Figura 24 a perspectiva RSE e a estrutura de diretórios do Set-Top Box. Figura 24. Estrutura da arvore de diretórios do Set-Top Box

26 A estrutura de diretório exibida na figura acima representa a árvore de diretórios existente no sistema operacional Linux Fedora. O gerenciamento e manipulação de arquivos e diretórios é bastante simplificado, através da perspectiva RSE é possível editar ou criar novos diretórios e arquivos diretamente no Set-Top Box virtual pressionando o botão direito do mouse, e selecionado a opção New, Folder, como no exemplo, foi criado o diretório meuprimeiroteste. Através da mesma interface, é possível copiar qualquer arquivo de aplicação local, e colá-lo no diretório remoto escolhido. O Eclipse oferece outro recurso interessante, trata-se da execução remota de comandos através de um terminal SSH. Para isso, é necessário pressionar o botão direito sobre o ícone Ssh Terminals e selecione a opção Launch Terminal, deste modo é possível executar as aplicações remotamente no Set-Top Box virtual, como mostrado na Figura 25. Figura 25. Execução remota de aplicações É possível navegar pela árvore de diretórios do Set-Top Box virtual, no entanto, faz-se necessário conhecer alguns comandos básicos do Linux, como: ls listar arquivos e pastas; cd <diretório> - acessa um determinado diretório; cd.. retorna ao diretório filho (anterior); pwd exibe a estrutura de diretório atual.

27 No entanto, para realizar a execução de uma aplicação pode ser utilizado o caminho absoluto da localização do arquivo.ncl, ou seja, o endereço do arquivo descrito a partir da raiz de diretórios, como no exemplo da figura acima: /misc/launcher.sh /misc/meuprimeiroteste/main.ncl. Demais comandos Linux podem ser encontrados facilmente em diversos tutoriais na Internet. Interessados podem acessar o site: para adquirir mais informações. Vale ressaltar que conhecer o sistema operacional Linux não é o objetivo desse trabalho. 6. Desenvolvimento de Aplicações em NCL. Conforme já explicado anteriormente, a linguagem NCL é bastante sofisticada, deste modo, o presente trabalho não pretende explorar todas as funcionalidades e recursos dessa linguagem, pretende apenas introduzir novos desenvolvedores, oferecendo uma visão inicial, indicando os caminhos a serem trilhados para uma evolução nos estudos sobre o desenvolvimento de aplicações para TVD. O primeiro passo para desenvolver uma aplicação NCL é criar um novo projeto, como explicado anteriormente, isso é possível através do menu File, New, Other, NCL Project, defina o seguinte nome para o projeto projvotadesenho. O Eclipse cria automaticamente a pasta media para ser usada como um repositório de arquivos de mídia. Também é criado um arquivo de base de conectores padrão para reutilização de conectores. Agora que já foi criado um projeto, deve ser criado o arquivo NCL, seguindo os mesmo passos citados anteriormente, File, New, Other, NCL Document. Preencha o campo id (nome do arquivo) com o valor principal, pois este será o principal arquivo utilizado para implementar a aplicação. Note na Figura 26 que a IDE Eclipse já cria automaticamente uma estrutura básica ao criarmos um novo arquivo NCL. Figura 26. Estrutura de um novo arquivo NCL O Eclipse oferece também o auto complemento de código, que pode auxiliar de forma significativa o desenvolvimento, facilitando sua implementação e sintaxe. Outra facilidade é o assistente de sugestões, pressionando simultaneamente as teclas Crtl e Espaço, utilizada para adicionar atributos e seus valores. A seguir será exibido passo a passo a construção da aplicação NLC utilizada como exemplo nesse capítulo. Essa aplicação consiste na exibição de três personagens

28 de histórias em quadrinhos, onde, dentre estes, o usuário deverá eleger o seu preferido. Para isso, utilizaremos diversos recursos da linguagem NCL que poderão facilmente ser expandidos para outras futuras aplicações. Para implementar essa aplicação serão necessárias as seguintes mídias: um arquivo de vídeo videoprincipal.mpeg contendo qualquer conteúdo. Ele será utilizado para simular o conteúdo transmitido pela emissora, neste exemplo utilizaremos um arquivo com extensão.mpeg. três arquivos de imagens no formato.jpg de personagem de história em quadrinhos, estes arquivos devem ter os seguintes nomes imgcebolinha.jpg, imgchico.jpg e imgmonica.jpg. É recomendado que todas essas imagens tenham o mesmo tamanho (100 x 140 pixel). dois arquivos de texto simples.txt, a aplicação os carregará e exibirá seu conteúdo na tela. O primeiro arquivo chamado txtpergunta.txt, com o seguinte conteúdo QUAL SEU PERSONAGEM DE DESENHOS FAVORITO?. O segundo arquivo chamado txtconfirma.txt, com o seguinte conteúdo SUA ESCOLHA FOI CONFIRMADA! OBRIGADO!. Para adicionar os arquivos de mídia ao projeto NCL, basta acessar o gerenciador de arquivos do sistema operacional, copiar e colar da pasta c:\workspace\projvotadesenho\media todos os arquivos necessários. Isso deve ser feito nesse momento, pois, caso contrário, o Eclipse acusará erro ao referenciar tais arquivos. Sobre a estrutura básica do arquivo NCL, serão adicionadas as delimitações de regiões da tela onde será exibido o arquivo de vídeo principal, iremos também adicionar as regiões onde os três personagens serão exibidos, conforme exibido na Figura 27. Figura 27. Definição de regiões No conjunto de descritores definidos na Figura 28, merece destaque os atributos focusindex e move, utilizados para determinar a sequência de objetos que receberão o foco da seleção, o atributo focusindex="1" refere-se o primeiro objeto selecionado. Já o atributo moveright determina qual índex ira receber o foco se pressionada a tecla seta para a direita. O atributo moveleft funciona de forma similar, determinando para qual índex irá receber o foco se pressionada a seta para a esquerda.