Capítulo
4
Introdução ao Desenvolvimento de Aplicações para Televisão Digital
Mario Godoy Neto
1,2, Carlos André Guimarães Ferraz
21Universidade Federal do Vale do São Francisco (UNIVASF)
Av. Antonio Carlos Magalhães, 510, Country Club, CEP: 48.902-300. Juazeiro-BA.
2Centro de Informática - Universidade Federal de Pernambuco (CIn/UFPE)
Av. Jornalista Anibal Fernandes, s/n, Cidade Universitária, CEP: 50.740-560. 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
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 2012. As demais retransmissoras localizadas em outras localidades possuem o prazo até junho de 2013.
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.
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
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.
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 Ginga1 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 http://www.ginga.org.br/
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 Java2 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 http://java.sun.com/
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
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.
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
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 6.
3 http://www.ncl.org.br/
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 XML4 composto basicamente pelos elementos descritos a seguir.
Cabeçalho do arquivo XML <?xml version="1.0" encoding="iso-8859-1"?>.
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 http://www.w3.org/XML/
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
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.
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.
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:
http://downloads.vmware.com/d/info/desktop_downloads/vmware_player/3_0.
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
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: http://www.gingancl.org.br/ferramentas.html.
Existem também outras distribuições disponíveis como: Fedora Ginga, disponível em:
http://www.ncl.org.br/ferramentas/fedora-fc7-ginga-i386.zip, 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.
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.
É 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:
“192.168.10.128”. É 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: http://www.eclipse.org/downloads/. 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:
http://www.java.com/pt_BR/download/, 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.
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
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 =
“http://www.laws.deinf.ufma.br/ncleclipse/update”, 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.
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.
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
“http://luaeclipse.luaforge.net/preview/update-site/win32.win32.x86”, respectivamente, em seguida pressione o botão “Open”.
Para instalar o plugin utilizando o sistema operacional Linux, é necessário substituir o campo Location por: “http://luaeclipse.luaforge.net/preview/update- site/linux.gtk.x86”.
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.
É 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:
http://luaeclipse.luaforge.net.
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)
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
“http://download.eclipse.org/dsdp/tm/updates/3.0”, respectivamente, em seguida pressione o botão “Open”.
Escolha a versão “RSE 3.1.1” 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.
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
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.
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: http://www.linuxbrasil.org.br/, 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
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”.
Figura 28. Definição dos descritores
Em seguida, ainda dentro do escopo do cabeçalho são criados os conectores, conforme já explicado anteriormente, estes determinam quais são as condições (condition) necessárias para que um elo seja ativado e qual ação (action) será realizada quando ativado. Na Figura 29 foram determinadas duas condições básicas para ativar os elos “ao iniciar” (onBegin), e “ao selecionar” (onSelection).
Figura 29. Definição dos conectores
No escopo do corpo do documento <body>, é definida a porta <port>
responsável por executar o vídeo principal. Logo em seguida, são descritos todos os arquivos de mídia utilizados pela aplicação.
Cada mídia utilizada pelo programa precisa ser descrita pela tag <media>, note na Figura 30 que o atributo “type” é o principal diferencial entre as mídias.
Figura 30. Definição do conteúdo do corpo aplicação
Ao definir uma mídia de texto, podemos adicionar a ela uma vasta quantidade de características, transparência, estilo, altura, scroll, entre outros. No entanto, para adicionar tais características é preciso modificar alguns detalhes na declaração da mídia inserindo os elementos <property> necessários, entre as tags <media></media>, como
pode ser observado na figura acima, este elemento também pode ser utilizado para os demais atributos de mídia.
Resta ainda definir quando os objetos de mídia serão exibidos para o usuário, conforme explicado anteriormente, isso ocorre através da criação de elos <link> e conectores <connectorBase>. Diante da Figura 31 abaixo, é possível observar a definição de quatro links, como explicado anteriormente, cada um possui um atributo
“xconnector” que faz referência ao respectivo conector (um dos conectores já criados anteriormente) no cabeçalho deste programa. O primeiro link referencia o conector
“onBeginStart”, determinando que ao iniciar o nó de mídia “video”, serão também iniciadas as mídias: “txtPerg”, “cebola”, “chico” e “monica".
Figura 31. Definição dos elos de conexão
Os demais três links criados referenciam o conector “onSelectionStartStop”, deste modo, quando uma mídia for selecionada, por exemplo “cebola”, as demais mídias serão paradas (stop), e a mídia “txtConf” deve ser exibida simultaneamente, ou seja, quando o usuário escolher um personagem, as demais mídias (duas imagens e um texto) param de ser exibidas, em seguida é exibida a mensagem de texto de confirmação (txtConf). Deste modo, foi implementado um link para cada personagem.
A utilização dos elos exibido na figura acima permitiu a sincronização (start e stop), das mídias utilizadas nesse programa. No entanto, resta ainda executar e visualizar o funcionamento da aplicação desenvolvida. Será demonstrada como realizar essa atividade na próxima seção.
6.1 Execução Remota do Projeto no Set-Top Box Virtual
Resta agora enviar o projeto desenvolvido para o Set-Top Box virtual, para isso, assegure-se que o VMware e o Set-Top Box estejam em execução. Depois de finalizada a implementação da aplicação, selecione o projeto criado "projVotaDesenho" com o botão direito, selecione a opção "copy". Em seguida, abra a perspectiva Remote System Explorer (RSE), por padrão, fica localizada no canto superior direito do Eclipse (1), exibido na Figura 32. Note que após selecionado a perspectiva RES, ocorre uma mudança sutil nas informações apresentadas.
Na aba RSE exibida na Figura 32, existe um ícone com o nome da conexão remota criada anteriormente, a qual atribuímos o nome de "Set-TopBox" (2). Selecione essa opção com o botão direito do mouse e escolha a opção "connect", em seguida, informe o nome do usuário: "root", e a senha "telemidia", marque a opção "Save password", e pressione o botão "Ok".
Nesse momento já é possível enviar o projeto copiado para o Set-Top Box, para isso, selecione ainda do lado esquerdo do Eclipse a conexão criada "Set-topBox", "Sftp Files", "Root", clique sobre o ícone de diretórios, e em seguida selecione o diretório
"misc". Note que já existe uma aplicação de exemplo (ncl30).
Para organizar melhor as aplicações desenvolvidas, selecione o diretório “misc”
com o botão direito, escolha colar (Paste) (3). Nesse momento, todos os arquivos contidos no projeto local, serão copiados para o Set-Top Box virtual.
Figura 32. Eclipse conectado ao Set-Top Box remoto
Vale relembrar que os arquivos enviados para o Set-Top Box só estarão disponíveis se a Maquina virtual (MVware) e o Set-Top Box virtual estiverem em execução.
Por fim, resta apenas executar a aplicação enviada, para isso, será utilizado o
"Ssh Terminal", localizado abaixo da conexão criada "Set-TopBox", ainda a esquerda do Eclipse. Selecione o "Ssh Terminal" com o botão direito, e escolha a opção "Launch Termial", caso solicite usuário e senha, informe "root" e "telemidia" respectivamente.
Nesse momento será aberta uma nova aba no Eclipse com o nome da conexão criada, esta aba pode estar localiza abaixo ou a direita o Eclipse (4). Vale lembrar que essa aba é um terminal remoto Linux, todas as instruções utilizadas aqui deverão obedecer o padrão desse sistema operacional, como por exemplo, todos os comando são
"case sensitive", ou seja, diferenciam caracteres maiúsculos de minúsculos.
Para executar a aplicação é necessário digital no “Ssh Terminal” a seguinte instrução: “/misc/launcher.sh /misc/projVotaDesenho/principal.ncl”. Caso tenha seguido corretamente todos os passos, sua aplicação funcionará como a Figura 33 exibida a seguir. Provavelmente o vídeo e as figuras serão diferentes, mas a estrutura básica da aplicação será similar.
Figura 33. Tela inicial da aplicação desenvolvida em execução
A aplicação permite a navegar entre as figuras dos três personagens exibidos na imagem acima. Ao escolher a figura central “Chico Bento” com a tecla “Enter”, simultaneamente as duas outras figuras e o texto acima (em azul), são paradas pelo evento “Stop”. Nesse momento é exibido pelo evento “Start” a mensagem de agradecimento, conforme exibido na Figura 34.
Figura 34. Confirmação do personagem escolhido
É possível conhecer um pouco mais sobre o Set-Top Box virtual utilizando alguns comandos básicos do Linux, caso haja interesse, pesquise outros comandos e faça seus testes.
7. Conclusão
Este capítulo apresentou a base necessária para contextualizar desenvolvedores iniciantes sobre as peculiaridades que diferenciam o desenvolvimento de software para Televisão Digital (TVD) e o desenvolvimento de software para as demais plataformas tecnológicas.
Espera-se que nesse momento os leitores estejam familiarizados com as ferramentas de desenvolvimento, plugins, e o Set-Top Box virtual, estejam aptos a instalar e configurar o ambiente de desenvolvimento de aplicações, e iniciar o desenvolvimento aplicações reais utilizando a linguagem NCL.
Para finalizar, os autores agradecem ao laboratório Telmídia (PUC-RIO), pela ampla disponibilização de materiais de pesquisa utilizada como referência desse capítulo. Agradecem também ao Centro de Informática da UFPE (CIn/UFPE) e a Universidade Federal do Vale do São Francisco (UNIVASF), por viabilizar e incentivar a pesquisa que originou esse trabalho.
8. Referências
Beck, K. (1998). “Extreme Programming Explained: Embracing the Change”, Wiley.
Boehm, B.; Turner, R. (2003). “Using Risk to Balance Agile e Plan Driven Methods”.
In: IEEE Computer, Los Alamitos, v. 36, n. 6, páginas. 57-66.
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (2005). Design Patterns. Addison-Wesley.
Ferreira, J. S.; Mendes, L. L.; Gomes, G. G. R. (2009). "Técnicas para Multiplexação de Sinais de TV Digital no Padrão ISDB-TB."In: 27º Simpósio Brasileiro de Telecomunicações - SBRT'2009.
Qureshi, M. R. J. and Hussain, S. A. (2008). “A Reusable Software Component-Based Development Process Model”, In: Advances in Engineering Software, Elsevier Ltd, Amsterdam, The Netherlands. Vol. 39/2, páginas 88-94.
Scavetta, S. and Lauffer, R. (1997) “Texte, Hipertexte, Hipermedia”. Paris, Intro.
Soares, F. S. F.; Mariz, L. M. R. S.; Cavalcanti, Y. C.; Rodrigues, J. P.; Godoy Neto, M.; Bastos, P. R.; Almeida, A. C. M.; Almeida, D. T. V. (2007). “Adoção de SCRUM em uma Fábrica de Desenvolvimento Distribuído de Software”. In:
Simpósio Brasileiro de Engenharia de Software, João Pessoa, páginas: 73-80.
Soares Neto, C. S., Soares, L. F. G, Rodrigues, R. F., Barbosa, S. D. J. (2007)
"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 >. Acessado em: 08/01/2011).
Sutherland, J. (2008) “ScrumWeb - A Guide to the Scrum Development Process”, http://jeffsutherland.com/scrum. Object TechnologyWeb Page.
Curriculum Vitae
Mario Godoy Neto está cursando o doutorando em Ciência da Computação pela Universidade Federal de Pernambuco (UFPE), com a tese: "Metodologia Ágil de Desenvolvimento Aplicações para TV Digital", mestrado em Ciência da Computação pela UFPE (2009), especialista em Engenharia de Software e Web pela Faculdade de Alagoas - FAL (2007), graduação como bacharel em Sistemas de Informação - FAL (2006). Atualmente é Professor Assistente da Universidade Federal do Vale do São Francisco (UNIVASF). Possui experiência da área de Ciência da Computação, com ênfase em engenharia de software, atuando principalmente nos seguintes temas relacionados a seguir: televisão digital, desenvolvimento ágil de software, recuperação
da informação, usabilidade, e educação a distância. Currículo Lattes:
http://lattes.cnpq.br/6381727641321786.
Carlos André Guimarães Ferraz possui graduação em Ciência da Computação pela Universidade Federal de Pernambuco (1986), especialização em Software Business: The American Way pela Nova Southeastern University (1997), mestrado em Ciências da Computação pela Universidade Federal de Pernambuco (1989) e doutorado em Computer Science pela University of Kent at Canterbury (1995). Atualmente é Professor Adjunto II da Universidade Federal de Pernambuco, Revisor de periódico da IEEE Transactions on Knowledge and Data Engineering, Diretor Adjunto do Centro de Estudos e Sistemas Avançados do Recife e Coordenador de Comissão Especial - CE- RESD da Sociedade Brasileira de Computação - Porto Alegre. Tem experiência na área de Ciência da Computação, com ênfase em Sistemas de Computação. Atuando principalmente nos seguintes temas a seguir: Aplicações Distribuídas, Mídias Contínuas, Plataformas Abertas de Distribuição, Objetos Distribuídos. Currículo Lattes:
http://lattes.cnpq.br/7716805104151473.
