NCL Eclipse: Ambiente Integrado para o Desenvolvimento de Aplicações para TV Digital Interativa em Nested Context Language Roberto Gerson de Albuquerque Azevedo 1,2, Mário Meireles Teixeira 1, Carlos de Salles Soares Neto 1,2 1 Laboratory of Advanced Web Systems Departamento de Informática - UFMA Av. dos Portugueses s/n - Campus do Bacanga São Luís/MA CEP: 65085-580 Brasil. 2 Laboratório Telemídia Departamento de Informática PUC-Rio Rua Marquês de São Vicente, 255. Rio de Janeiro, RJ CEP: 22453-900 Brasil. roberto@laws.deinf.ufma.br, {mario, csalles}@deinf.ufma.br Abstract. This paper presents the NCL Eclipse textual integrated environment whose aim is to help the development of interactive multimedia applications in Nested Context Language (NCL), the standard declarative language of the Brazilian Digital Terrestrial TV System. The NCL Eclipse is a plugin for the Eclipse IDE that offers some user-centered features, such as automatic and contextual code suggestion, NCL documents validation, and XML elements and reserved words coloring. Resumo. Este trabalho apresenta o NCL Eclipse, um ambiente integrado de autoria que visa apoiar o desenvolvimento de aplicações multimídia interativas em Nested Context Language (NCL), linguagem declarativa padrão do Sistema Brasileiro de Televisão Digital Terrestre (SBTVD-T). O NCL Eclipse é um plug-in para a IDE Eclipse que oferece diversas funcionalidades centradas nas necessidades de autores NCL, tais como a sugestão de código automática e contextual, validação de documentos NCL, coloração de elementos XML e de palavras reservadas da linguagem. 1. Introdução Há diversas ferramentas de autoria para linguagens de marcação baseadas no tempo, em especial, aquelas voltadas à concepção de documentos hipermídia [Guimarães et al 2007] [Bulterman et al 1998] [Manalee 2008]. Todas essas ferramentas possuem em comum a incapacidade de abstrair ou excluir completamente a autoria textual do processo de desenvolvimento. Atualmente, não existe uma única abstração gráfica ou visual capaz de expressar por completo todas as especificidades de uma dessas linguagens. Um exemplo de tais abstrações é a representação gráfica do paradigma de linha de tempo, comumente usado neste tipo de ferramentas. Este paradigma, entretanto, não é satisfatório ou conveniente para modelar a interação do usuário. Primeiro, porque é
impossível precisar, ainda em tempo de autoria, o exato instante em que tal interação ocorrerá. Segundo, porque o suporte à interação do usuário resulta em múltiplas linhas do tempo e não em uma única. Na prática, as aplicações interativas devem ser tratadas como uma linha de tempo principal e diversas linhas secundárias, tantas quantas as interações de usuário determinar [Costa e Soares 2007]. Resultando assim, em um ambiente confuso ou difícil de representar visualmente. Outras abstrações gráficas já foram exploradas como forma de racionalizar sobre o código-fonte de linguagens baseadas no tempo. Em [Coelho et al 2004] e [Moreno et al 2008], grafos compostos são usados para a descrição de modelos hipermídia, mas também não são suficientes para expressá-los por completo. Nesse caso, a estratégia sugerida para ferramentas de edição é o uso de diversas abstrações gráficas sincronizadas entre si, onde cada uma delas trata de um aspecto específico da autoria. Esta parece ser a abordagem mais adequada em ferramentas de autoria de aplicações hipermídia. Ainda assim, a autoria textual sempre se mantém como uma das abordagens sugeridas. Em muitos casos, o uso de tais abstrações gráficas ou visuais é tido como mais fácil de entender e mais natural para os seres humanos interagirem com o computador do que a programação textual. Isto é válido, mas não pode ser generalizado para todos os casos, conforme demonstrou [Green e Petre 1992]. Ao se tomar como base as linguagens SMIL [W3C 2005] e Nested Context Language (NCL) [ABNT 2007], ambas linguagens voltadas para a criação de documentos hipermídia, novamente todas as suas ferramentas de autoria se baseiam em parte na edição textual de documentos. Tais indícios sugerem que a edição textual e não apenas a gráfica ou visual deve ser considerada com atenção no desenvolvimento de ferramentas de autoria para tais linguagens. No que se refere à criação de códigos-fonte textualmente através de um editor nãoespecializado, sem dúvida, este é um processo árduo para o autor e que requer bastante cuidado, pois deixa o autor muito suscetível a erros. Entretanto, tal problema pode ser minimizado com a utilização de ferramentas especializadas para auxiliar no desenvolvimento textual. O tipo de ferramenta mais utilizado com este objetivo é o Ambiente Integrado de Desenvolvimento (IDE ou Integrated Development Enviroment). Cada IDE fornece um conjunto de funcionalidades para um determinado grupo de usuários. São exemplos destas funcionalidades: desenvolvimento visual através de menus, janelas ou desenhos, dependendo da linguagem à qual a IDE auxilia, editores de texto com coloração de sintaxe, sugestão de código, validação de código-fonte, indicação de erros sintáticos e semânticos, dentre outras. A linguagem NCL permite a criação de apresentações hipermídia interativas e foi adotada como linguagem declarativa padrão pelo Sistema Brasileiro de TV Digital Terrestre (SBTVD-T). NCL atua como uma linguagem de aglutinação, que orquestra objetos de mídia de vários tipos diferentes, como áudio, vídeo, texto, imagem e até códigos imperativos, como aqueles escritos em Lua [Ierusalimschy 2006] ou em Java [ETSI 2006]. A NCL tem dois grandes públicos: produtores de conteúdo para TV e programadores de software. Os primeiros são designers, profissionais de artes e TV, ávidos por abstrações gráficas e preferencialmente ferramentas WYSIWYG (What You See is What You Get); o segundo grupo está habituado a IDEs e a usar linguagens de programação textual
como interface para o desenvolvimento. Visando suprir as necessidades do grupo de usuários de NCL formado por programadores de software, é proposto neste trabalho um editor textual de código livre para a linguagem, denominado NCL Eclipse. O NCL Eclipse é implementado como um plug-in para a IDE Eclipse [Eclipse.org 2008], visando reusar todo este ambiente já utilizado por uma ampla comunidade de desenvolvedores. O foco deste trabalho é desenvolver uma ferramenta que auxilie o máximo possível o desenvolvimento textual. As abstrações gráficas são deixadas um pouco de lado, mas podem futuramente ser incorporadas, assim como será exemplicado com uma visão de Leiaute. O perfil de usuários de NCL a que se destina a ferramenta NCL Eclipse é aquele que tende a desenvolver aplicações com requisitos mais especializados, como aquelas residentes no receptor de TV digital. São também esses usuários que detêm os conhecimentos necessários de programação para o desenvolvimento de aplicações NCL, fazendo uso de scripts Lua ou da ponte para Java 1. O Eclipse se mostra uma ferramenta natural para integrar as diversas necessidades desse perfil, haja vista ser um ambiente que também oferece plugins para Lua como, por exemplo, o LuaEclipse [LuaEclipse 2008] e ser um dos mais utilizados para o desenvolvimento em Java. Este artigo está dividido da seguinte forma: Na Seção 2, são apresentados os trabalhos relacionados. Na Seção 3, é discutida a forma como se dá a autoria para a TV Digital atualmente, especificando quais as necessidades de uma ferramenta textual. A Seção 4 apresenta o NCL Eclipse, discutindo sua arquitetura, interação com Eclipse e também as funcionalidades implementadas. A Seção 5 apresenta como o NCL Eclipse auxilia as tarefas do usuário. E a Seção 6 traz as principais conclusões deste trabalho e seus desdobramentos. 2. Trabalhos Relacionados 2.1 Composer O Composer [Guimarães et al 2007] é uma ferramenta de autoria hipermídia voltada para o desenvolvimento de programas audiovisuais interativos em NCL. Desenvolvido pelo Laboratório TeleMídia da Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio), o Composer encontra-se atualmente na versão 2.2.1. Seu principal objetivo é possibilitar que usuários possam produzir programas interativos através de abstrações visuais, o que requer menos conhecimento especializado de NCL. Para que isso seja possível, a filosofia utilizada pelo Composer é a de que o usuário que irá construir o programa poderá fazê-lo através de visões. Cada visão mostra uma parte do programa NCL e uma alteração em uma das visões atualiza automaticamente as outras visões. Existem quatro visões definidas: Estrutural (1), Temporal (2), Leiaute (3) e Textual (4), conforme a Figura 1. 1 Mais informações sobre NCL, Lua e Java podem ser encontradas em [ABNT 2007]
Figura 1 Diferentes visões do Composer A Visão Estrutural mostra os nós e os elos entre os nós. Através desta visão é possível criar e visualizar nós de mídia, nós de contexto e elos. A representação gráfica dos nós e elos, contudo, mapeiam diretamente os elementos da linguagem NCL, o que resulta em um ambiente de autoria no qual o autor preenche vários formulários que são, na verdade, mapeados diretamente para os atributos daqueles elementos na linguagem. A Visão Temporal mostra como o sincronismo está definido pelo documento com base em uma linha de tempo e quais as opções de interatividade. Já que não é possível representar a interatividade em uma única linha do tempo, esta visão então divide o programa em quantas linhas do tempo tantos quantos são os pontos de interatividade. A Visão de Leiaute ilustra as regiões definidas para os dispositivos de exibição. Pode-se alterar o tamanho ou a posição das regiões visualmente, sem a necessidade de especificar os valores das propriedades diretamente. A Visão Textual é um editor de texto que apresenta o código NCL em si. A Visão Textual do Composer, na versão atual, é um simples editor de texto XML, com coloração de tags e valores de atributos, sem nenhuma funcionalidade especial de tratamento da linguagem NCL. O NCL Eclipse pode ser utilizado em conjunto com o Composer, mesmo sem nenhuma integração ainda automatizada. Os usuários que preferem utilizar a Visão Textual do Composer na autoria são os mais suscetíveis a migrarem para o NCL Eclipse, visto que com esta última ferramenta há novas funcionalidades textuais que podem atender melhor a suas expectativas. Como ambos são ferramentas de software livre, há também a possibilidade de incorporar, futuramente, as visões do Composer ao NCL Eclipse, ou vice-versa. 2.2. GriNS O GriNS [Bulterman et al 1998] é um sistema de autoria e apresentação para documentos SMIL. Assim como o Composer, o Grins também é voltado para autores com pouco conhecimento da linguagem hipermídia (no caso, SMIL) e também utiliza a abordagem de visões, embora de uma forma um pouco diferente da abordagem do Composer. O GRiNS
possui basicamente quatro visões: Visão de Estrutura Lógica (logical structure view), Visão de Linha de Tempo Virtual (virtual timeline view), Visão de Playout (playout view) e Visão Textual (Textual View) A logical structure view permite ao autor construir um documento SMIL em termos de uma hierarquia aninhada de objetos de mídia. Nesta visão, os atributos dos nós são preenchidos em um formulário, representando, basicamente, os nós <par> e <seq> da linguagem SMIL. A virtual timeline view tem o propósito de tornar mais visível as relações com os atributos DURATION e REPEAT, que não ficam muito claras na logical structure view. Nesta visão, é mostrada a cronometragem lógica das relações calculadas a partir da logical structure view. A playout view ou presentation view permite tocar o documento SMIL, além de alterar dinamicamente os valores dos atributos. Já a textual view é um simples editor de textos e oferece apenas recursos básicos. A coloração sintática é bem restrita, visto que somente as composições com semântica temporal (<par>, <seq> e <excl>) recebem cor em destaque. A sugestão de código não está presente no GriNS. A Figura 2, a seguir, mostra o ambiente de autoria Grins. Figura 2 Grins Editor 2.3. SMOX Pad O SMOX Pad [Manalee 2008] é um editor de texto avançado voltado para a linguagem SMIL. Algumas das características presentes no SMOX Pad são: coloração sintática, sugestão de código e validação de erros. O SMOX Pad é uma ferramenta proprietária, produzida pela Manalee. Além do SMOX Pad, a Manalee também possui a ferramenta SMOX Editor que é uma ferramenta WYSIWYG para a criação de apresentações SMIL. É possível, assim, atingir duas classes de usuários, os que se sentem mais à vontade na criação visual (com o SMOX Editor) e os que se sentem mais à vontade com a especificação textual das apresentações (com o SMOX
Pad). A existência do SMOX Pad é mais um indício de que ferramentas que atingem esta classe de usuário são bem recebidas e até mesmo rentáveis no contexto de criação de documentos hipermídia. Uma desvantagem encontrada no SMOX Pad é o fato de que a sugestão de código não é contextual em muitos casos. Um exemplo disso é quando se define um elemento filho de um <head> e o editor sugere <head>, ou até mesmo <body>, o que não condiz com a especificação do SMIL, veja a Figura 3. Outra desvantagem encontrada no SMOX Pad é o fato de ser voltado para um sistema operacional específico. Figura 3 SMOX Pad 3. Autoria de Programas Interativos para TV Digital Há dois principais paradigmas para a autoria de aplicações interativas para TV digital: o imperativo e o declarativo. O uso de linguagens imperativas se baseia na especificação de aplicações como sequências de comandos ou como algoritmos, da mesma forma como a maioria dos programas de computador são criados. Por outro lado, as linguagens declarativas têm como meta fornecer abstrações de alto nível mais próximas do domínio do problema cuja finalidade é a de concentrar o autor em especificar o resultado final esperado e não os passos necessários para se alcançar esse objetivo. Este trabalho se insere no contexto da autoria com base no uso de linguagens declarativas. Na maioria dos casos, a linguagem declarativa tende a ser a preferencial no desenvolvimento de aplicações interativas de TV digital. Mais ainda, como em tais aplicações o sincronismo intermídia sem a interação do usuário deve ser tão ou mais importante que a
interatividade, o sincronismo de mídias em sua forma mais ampla, e não a interatividade deve ser o foco das linguagens declarativas. Outro aspecto importante para as aplicações de TV digital é a adaptabilidade. Ao agregar capacidade computacional à TV, torna-se possível fazer com que o receptor adapte o conteúdo que está sendo apresentado de acordo com informações de contexto referentes às preferências ou localização do usuário, ou ainda à disponibilidade atual do receptor (capacidade de processamento, memória disponível, etc.). A adaptação pode envolver não apenas o conteúdo de cada objeto de mídia individualmente, mas também o próprio formato ou leiaute de apresentação. O suporte a múltiplos dispositivos de exibição também é uma característica importante no tocante à interatividade em um sistema de TV digital. Através do uso de múltiplos dispositivos será possível, por exemplo, que a interação de um usuário com o programa de TV exiba conteúdo exclusivamente para ele em seu dispositivo pessoal, não atrapalhando a audiência de outras pessoas a seu redor e tornando a experiência de ver TV mais individualizada. Resumindo, uma linguagem declarativa voltada para a concepção de programas interativos de TV digital deve ter o foco no sincronismo de mídias (onde a interatividade é apenas um caso particular), adaptabilidade e suporte a múltiplos dispositivos. NCL tem como característica dar suporte a estes requisitos. Por outro lado, também há padrões que baseiam a autoria declarativa no uso de XHTML como alternativa para a formatação espacial. Nesse caso, o sincronismo temporal é feito por meio de scripts (como o ECMAScripts [ECMA 1999]). BML [ARIB 2004] é um exemplo de linguagem que faz uso dessa abordagem. 3.1. Autoria em Nested Context Language NCL é a linguagem padrão do Sistema Brasileiro de TV Digital e é baseada no Nested Context Model [Soares et al 2006]. Nesta seção são discutidos seus principais conceitos e como se dá o processo de autoria de programas interativos utilizando-a. Não é viável apresentar neste trabalho uma descrição de todos os conceitos do modelo NCM (Nested Context Model) [Soares et al 2006], no qual a linguagem NCL é baseada. Ao invés disso, os conceitos do NCM mais comumente usados na autoria são apresentados nesta seção. Vários elementos NCL possuem um atributo id obrigatório que identifica univocamente aquele elemento no documento. Essa identificação é utilizada recorrentemente em vários atributos para que um elemento possa fazer referência a outro. Esta técnica é comumente utilizada em linguagens XML como, por exemplo, XHTML, SMIL, etc. Geralmente, isso exige que o autor navegue pelo documento em busca da identificação correta do elemento ao qual ele deseja referenciar, ou que memorize os identificadores dos outros elementos. Os dois principais conceitos de NCL são os de nós e elos. Nós podem estar associados com os objetos de mídia que compõem a aplicação ou serem composições de nós. Composições de nós, por sua vez, podem conter recorrentemente outros nós ou elos. Uma composição utilizada para estruturar e encapsular partes de aplicações é chamada de
contexto. Uma composição empregada na adaptação de conteúdo é chamada de switch ou nó de alternativa. Elos representam relacionamentos de causa e efeito entre nós. Um elo descreve uma sentença em que, dada que uma condição é satisfeita, uma ação resultante é disparada. Os elos expressam o sincronismo de mídias da aplicação e as possibilidades de interação do usuário (também descritas pelo módulo de navegação de teclas da linguagem). Os nós de composição encapsulam outros nós e elos internos. Isso significa que um nó declarado dentro de uma composição só é acessível por elos contidos naquela mesma composição, salvo se houver uma porta para aquele nó, caso em que elos externos podem acessá-lo. Uma porta de uma composição representa um ponto de interface. Ela externaliza uma interface interna daquela composição de forma que elos externos possam atuar sobre nós internos. A Figura 4, mostra um exemplo onde a Porta 2 externaliza o vídeo 1 que está no contexto 2. No contexto 1, por sua vez, existe uma Porta 1, que externaliza a Porta 2, do contexto 2. De outra forma não seria possível acessar o nó de mídia a partir do contexto 1, ou até mesmo fora dele. Há também as portas de alternativa em switches, que podem mapear para uma de várias interfaces internas, dependendo de certas regras. Outro tipo de interface é a âncora, que pode representar intervalos de tempo, áreas espaciais ou espaço-temporais de um nó de mídia. Há também as propriedades de nós, que atuam como variáveis para armazenar certos valores em um nó. Quando se define um nó de mídia, geralmente é necessário associá-lo a um descritor, que carrega as informações de inicialização do nó, incluindo a região dos múltiplos dispositivos em que nós usando aquele descritor são exibidos. Os elos especificam relacionamentos entre nós. Tais relacionamentos são baseados em relações descritas em conectores. A separação entre relação e relacionamento na especificação do sincronismo de mídias e da interação do usuário é importante por promover um maior nível de reuso e isolamento. Um autor mais especializado pode se restringir a criar uma base de relações que são reutilizadas comumente na criação de aplicações interativas. Em NCL, quando se descreve um conector, são descritos papéis de condição e de ação, que formam uma sentença seguindo o modelo: quando a condição ocorrer, faça a ação ocorrer. Um elo nada mais é do que a associação de nós a cada um desses papéis especificados na relação. O conceito de perspectiva não está presente na maioria das linguagens XML, sendo assim, uma das particularidades de NCL. Uma perspectiva é definida como o aninhamento de contextos através do qual um nó está definido. Na Figura 4, por exemplo, a perspectiva do elemento Video 01 é <Contexto 01, Contexto 02>. A constante referência aos identificadores de outros elementos e o fato de que muitas vezes estes elementos devem estar em perspectivas válidas, levando em conta o aninhamento dos contextos e a posição na qual o autor está editando, torna o processo de autoria textual bastante árduo em NCL. Isto traz a necessidade de uma ferramenta especializada que possa
sugerir apenas valores de elementos válidos sintática e semanticamente. Como será discutido na próxima seção, o NCL Eclipse dá suporte a esta sugestão de conteúdo contextual. Figura 4 Aninhamento de contextos NCL 4. NCL Eclipse Esta seção traz uma visão geral do NCL Eclipse, evidenciando as características desenvolvidas, bem como uma discussão sobre a relevância de cada uma dessas funcionalidades. Dentre as principais características implementadas pelo NCL Eclipse estão: coloração de tags e atributos XML, auto-formatação do código XML, validação do documento NCL, sugestão de código NCL de forma contextual (autocomplete), navegação no documento como uma árvore, execução do documento NCL e uma visão de Leiaute. Essas funcionalidades foram identificadas durante a fase de levantamento de requisitos e são baseadas nas funcionalidades comumente encontradas em ambientes de programação voltados à criação de arquivos-fonte para as mais diversas linguagens de marcação encontradas no mercado. Como será visto, a sugestão de código, totalmente contextual, refletindo a estrutura sintática e semântica da linguagem NCL, é o grande diferencial dessa ferramenta quando comparada a outras existentes. A Figura 5 mostra a visão geral da arquitetura do NCL Eclipse.
Figura 5 NCL Eclipse arquitetura visão geral 4.1. NCL Wizard Um wizard, no Eclipse, é um fluxo passo-a-passo que auxilia o usuário na realização de uma tarefa. É comum sua utilização para a criação de novos projetos ou documentos. Os wizards são organizados em categorias, sendo que tanto as categorias quanto eles próprios são definidos pelos plug-ins que fazem parte do ambiente. O NCL Eclipse fornece dois wizards padrões, ambos classificados na categoria NCL. Um para a criação de um documento NCL básico e outro para a criação de uma base de conectores que pode ser reutilizada por outros documentos. O NCL Document cria um novo documento NCL, com o elemento <ncl> e seus filhos <head> e <body>. O Connector Base Document tem a mesma funcionalidade do anterior, só que não gera o elemento <body>, desnecessário em uma base de conectores. 4.2. Validação Sintática e Semântica Uma das características mais úteis que os ambientes de desenvolvimento baseados em linguagem de programação disponibilizam para os seus usuários é a identificação e marcação de erros durante a autoria dos arquivos-fonte. Esta é uma funcionalidade disponível na maioria das IDEs existentes no mercado e ajuda a diminuir muito o tempo de autoria, já que diminui a necessidade de "tentar executar" o documento para evidenciar que o mesmo possui erros sintáticos e/ou semânticos. O NCL Eclipse reusa o NCL Validator [Araújo, Azevedo e Soares 2008] com o objetivo de identificar e marcar erros em documentos NCL, em tempo de autoria. Possibilitando assim que, caso exista erro no documento, o autor possa identificá-lo e
consertá-lo, sem a necessidade de executar a aplicação. A linha do erro é sublinhada e uma descrição do erro pode ser visualizada passando-se o mouse sobre o texto ou na Problem View (padrão do Eclipse). 4.3. Coloração sintática A coloração sintática é útil na medida em que auxilia o autor a se situar no texto. Esta é uma característica básica da maioria dos editores de texto voltados à criação de arquivos-fonte. Como a linguagem NCL é baseada em XML, a coloração sintática do NCL Eclipse foi desenvolvida para diferenciar os elementos XML, seus atributos e os valores dos atributos, bem como alguns conteúdos textuais e comentários. Por padrão, os elementos XML aparecem na cor azul, os valores dos atributos na cor verde e os comentários na cor vermelha. A coloração sintática, disponibilizada por um editor de texto do Eclipse é feita através da divisão do documento em um conjunto de tokens, cada um descrevendo uma seção do documento que possui cor do texto (foreground), cor de fundo (background) e estilo de fontes diferentes. Esta divisão é feita por um presentation reconciler. Isto é muito similar ao particionamento de documento, que será discutido na subseção 4.6, com a ressalva que o presentation reconciler permite um controle mais fino do que seria a partição do documento. Por meio do presentation reconciler, seria possível, por exemplo, modificar as cores de cada uma das palavras reservadas da linguagem. 4.4. Visão Outline (Outline View) A visão outline é a visão padrão do Eclipse para apresentar a estrutura do documento que está sendo editado atualmente. A JDT (Java Development Tool), por exemplo, mostra as classes, atributos e métodos do arquivo que está sendo editado. O NCL Eclipse também utiliza a visão outline para mostrar a estrutura do documento NCL. Um documento XML pode ser representado como uma árvore. Visando aproveitarse dessa característica de documentos XML, o Outline view presente no NCL Eclipse permite que se navegue pelo documento NCL como uma árvore. O evento de clicar sobre um nó da árvore leva o editor a selecionar a linha daquele nó. A visão Outline estende a visão padrão do Eclipse. Caso a mesma não esteja ativa, é possível ativá-la através do menu Window > Show View > Other... > General > Outline. Cada vez que o documento é salvo, a visão Outline é atualizada. 4.5. Folding Colapsar partes de um código é uma característica presente em muitos editores de texto usualmente chamada de folding que torna o trabalho de ler e entender o código mais fácil. Esta característica, também chamada de visão de olho-de-peixe, permite esconder a parte do código em que não se está interessada no momento, mostrando apenas o que é mais relevante. O NCL Eclipse implementa o folding baseado na estrutura dos elementos XML, ou seja, é possível esconder um elemento, juntamente com todos os seus filhos, se necessário.
4.6. Sugestão de código Contextual A sugestão contextual automática de texto (autocomplete) é uma característica presente em muitos editores e processadores de texto, bem como navegadores web. A sugestão automática envolve o processo de o programa predizer uma palavra ou frase que o usuário deseje inserir no texto sem que seja necessário digitá-la por inteiro. Em editores de texto específicos para linguagens de programação, esta característica é extremamente útil, pois diminui bastante o tempo necessário para a programação, ajudando o usuário a criar um documento correto e a digitar menos do que o que seria necessário sem esta funcionalidade, além de indiretamente auxiliar no aprendizado da linguagem. O NCL Eclipse implementa a sugestão para todos os elementos e atributos da linguagem NCL, a qual pode ser acessada através da combinação de teclas Ctrl+Espaço, totalmente baseado no contexto em que o autor está posicionado no arquivo-fonte. Três cenários principais foram analisados neste trabalho: a sugestão de elementos, a sugestão de atributos de um determinado elemento e a sugestão de valores dos atributos de um elemento. Para tornar possível o tratamento de cada um desses cenários, separadamente, utilizou-se o particionamento de documento, disponibilizado pelo editor de texto do Eclipse. Usando-se a API do Eclipse, é possível definir regras de particionamento do documento e tratar cada uma dessas partições de forma totalmente independente. É possível, por exemplo, definir coloração sintática, formatação, bem como sugestão de textos diferentes e independentes para cada uma das partições. No NCL Eclipse foram definidas algumas partições úteis para documentos XML, as quais são destacadas na Figura 6. Figura 6 Partições do documento NCL definidas pelo NCL Eclipse.
A sugestão de elementos baseia-se na estrutura da linguagem e na posição atual do cursor. Assim, quando se está com o cursor entre uma partição de start tag <ncl> e uma de end tag </ncl>, o NCL Eclipse sugere os elementos que são filhos de <ncl> (<body> e <head>). Isto acontece para todos os elementos da linguagem, refletindo sempre a estrutura da linguagem. Para os elementos que possuem atributos obrigatórios, tais atributos também são incluídos no texto gerado pela sugestão automática. O segundo cenário, que se refere aos atributos de um determinado elemento, está relacionado exclusivamente a uma partição de start tag. Ao ativar a sugestão automática dentro de uma partição de start tag, que já possui o nome de um elemento definido, a sugestão automática, baseada no nome dessa tag, sugere ao usuário os possíveis valores dos atributos desse elemento. Caso um atributo já tenha sido preenchido, o mesmo não é sugerido novamente. No terceiro cenário, onde o usuário está digitando o valor de um atributo, existem duas possibilidades: na primeira, os valores dos atributos são pré-definidos pela linguagem é o que acontece, por exemplo, com o atributo operator do elemento <compoundaction>, que só pode assumir os valores par ou seq. E, na segunda, os valores referenciam outros nós definidos pelo próprio usuário no documento ou importados de outro documento. Pode-se citar como exemplo o atributo xconnector do elemento <link>, que deve ser o valor de um identificador de um conector definido pelo elemento <causalconnector>. Quando o valor é pré-definido pela linguagem, a lista dos valores possíveis é mostrada. Já quando o valor deve ser uma referência a outro nó definido pelo próprio usuário, o parsing do documento é realizado em tempo de autoria para descobrir os valores possíveis. Outras particularidades de NCL também influenciam nas sugestões dadas pelo NCL Eclipse e são considerados como o principal diferencial dessa ferramenta em relação a outras existentes, tais como as perspectivas em que os elementos estão. A Seção 5, ao mostrar como o NCL Eclipse auxilia o usuário, evidencia alguns exemplos de tais particularidades. 4.7. Execução de um documento NCL Adicionalmente, o NCL Eclipse também permite a execução de um documento NCL, através do comando Run do Eclipse. Para isso, basta clicar com o botão direito sobre o documento e depois em Run -> NCL Presentation. A execução do documento permite que, no momento da autoria, o autor possa ter uma idéia prévia de como o documento será visualizado pelo telespectador final, podendo até mesmo simular as interações que possam ocorrer no decorrer da apresentação. 4.8. Visão de Leiaute A visão de Leiaute foi incluída no NCL Eclipse como uma forma de exemplificar como novas visões podem ser facilmente adicionadas ao ambiente de autoria. Nesta visão é possível criar regiões nas quais as mídias deverão aparecer. É possível, por exemplo, redimensionar e aninhar as regiões de forma visual.
Os elementos <region> da linguagem NCL são mapeados em elementos visuais que podem ser alterados visualmente. O framework Graphical Editing Framework (GEF) [Eclipse.org GEF 2008] é utilizado como plataforma para o desenvolvimento dessa visão. A Figura 7 mostra a visão de Leiaute. Figura 7 Visão de Leiaute do NCL Eclipse. 5. NCL Eclipse auxiliando as tarefas do usuário Esta seção discute como as funcionalidades do NCL Eclipse auxiliam nas tarefas comuns do seu principal usuário, que é o autor (programador) de documentos hipermídia em NCL. Em especial, destacam-se os diferenciais do ambiente: a sugestão de código baseada no contexto, a validação do documento e a execução do documento, simulando a apresentação no receptor de TV digital. A sugestão de código contextual, além de auxiliar na criação de um documento (diminuindo a necessidade de memorização dos elementos e atributos), também auxilia o aprendizado da linguagem e pode funcionar até mesmo como um guia de consulta no momento da autoria (eliminando assim a necessidade de guias impressos ou de consultas externas). Se o programador, por exemplo, necessitar saber quais os filhos de um determinado elemento, ele precisa simplesmente colocar o cursor na posição certa no editor de texto e teclar Ctrl+espaço para visualizar uma sugestão de elementos filhos possíveis. Através da sugestão de código contextual também é possível conhecer a obrigatoriedade dos atributos e a cardinalidade dos elementos. Conforme comentado na Seção 3, na linguagem NCL os atributos frequentemente fazem referências a identificadores de outros elementos, o que pode tornar o documento confuso para um autor menos experiente. A sugestão de código também permite que o autor se situe no documento, na medida em que sugere apenas os valores possíveis que aquele
atributo pode assumir. A Figura 8 mostra um exemplo no qual o NCL Eclipse sugere os descritores, já definidos pelo usuário no próprio documento, como possíveis valores do atributo descriptor do elemento <media>. Figura 8 Sugestão de código contextual: exemplo de sugestão de referência a descritores definidos no próprio documento. A idéia de contexto, encapsulamento e perspectiva são alguns dos pontos diferenciais da linguagem NCL, visto que não existe na maioria das outras linguagens XML. Tal especificidade também é contemplada pelo NCL Eclipse. Assim, ao sugerir o valor de um determinado atributo, este valor sempre estará em um contexto válido. Como exemplo, podese citar o atributo component do elemento port. Este atributo faz referência a um elemento media, context ou switch que esteja no mesmo contexto daquele elemento port. A Figura 9 ilustra este exemplo. Todos os atributos de NCL que exigem que o seu valor seja uma referência válida em um determinado contexto são contemplados pelo NCL Eclipse. Um caso particular de sugestão de código apóia a separação feita conceitualmente na linguagem entre elo e conector. Ao descrever um elo, o autor o relaciona a seu conector por meio do atributo xconnector do elemento <link>. Quando o faz, a ferramenta obtém a lista de possíveis valores de papéis daquele conector. Essa lista é usada como sugestão do atributo role na associação dos papéis aos nós. Isso ajuda a isolar ainda mais o autor habitual de NCL da necessidade de conhecer a autoria de conectores.
Figura 9 Sugestão de código contextual: exemplo baseado no contexto do elemento. No que se tange à validação do código, as particularidades de NCL também são contempladas pelo NCL Eclipse. Quando existe algum erro no documento, a linha do erro é marcada e o local do erro é sublinhado, acompanhado por uma descrição do erro na Problem View do Eclipse, facilitando encontrar e corrigir o erro. Ao fazer um duplo clique na descrição do erro, na aba Problems, o documento é aberto, selecionando a linha do erro. A Tabela 1, a seguir, apresenta um quadro comparativo resumido entre os trabalhos relacionados discutido na Seção 2 e o NCL Eclipse. Nele, é possível observar como o presente trabalho vem suprir as necessidades de um público de NCL (programadores) que anteriormente não dispunham de uma ferramenta especializada para a autoria textual de forma avançada em NCL. Todas as ferramentas analisadas, em diferentes níveis de funcionalidades, dão suporte à autoria de forma textual. Isso nos leva a concluir que por mais intuitiva que uma abstração gráfica para linguagens hipermídia possa ser, pelo menos até o momento, ela não acaba totalmente com a necessidade da autoria baseada diretamente no texto, seja pelo fato do ambiente visual não representar todas as funcionalidades da linguagem hipermídia textual ou, simplesmente, porque existem usuários que se sentem mais a vontade com a autoria textual.
Tabela 1. Quadro comparativo entre as ferramentas de autoria hipermídia para NCL e SMIL. Ferramenta Foco Múltiplas Sugestão de Coloração Licença Principal Visões código sintática Multiplataforma Composer Visual Sim GPLv2 Não Sim Sim NCL Eclipse Textual Sim GPLv2 Sim (contextual) Sim Sim GriNS Visual Sim Comercial Não Sim (fraca) Sim SMOX Pad Textual Não Freeware Sim (não-contextual Sim Não 6. Conclusão Este trabalho apresenta um ambiente integrado de autoria para o desenvolvimento de aplicações hipermídia interativas na linguagem NCL, denominado NCL Eclipse. O NCL Eclipse é software livre e seu código encontra-se disponível no Portal do Software Público Brasileiro (http://www.softwarepublico.gov.br). O site oficial da ferramenta (http://www.laws.deinf.ufma.br/ncleclipse) disponibiliza tutoriais e os binários das versões mais atuais. Essa ferramenta foi desenvolvida como um plug-in para o ambiente multiplataforma Eclipse e pretende atender a um público de desenvolvedores (programadores) na linguagem NCL, os quais não dispunham de uma ferramenta textual avançada voltada especificamente a essa linguagem. Tais programadores estavam, portanto, limitados a utilizar editores específicos de XML que não reconhecem características próprias da NCL, como os contextos e perspectivas. O NCL Eclipse apresenta diversas funcionalidades que auxiliam os programadores em suas tarefas, tais como: coloração de tags e atributos XML, auto-formatação de código XML, wizards para a criação de documentos NCL, validação do documento NCL, sugestão código automática e contextual, navegação na árvore do documento NCL e execução da aplicação NCL. Dentre elas, destaca-se como uma das principais contribuições deste trabalho a sugestão contextual de código NCL, a qual guia o programador apenas nos elementos, atributos de elementos e valores de atributos que façam sentido em um determinado contexto de edição do documento. Em uma linguagem de certa complexidade, como é o caso da NCL, esta funcionalidade torna-se decisiva para o aumento da produtividade dos desenvolvedores. O modo de sugestão automático implementado permite até mesmo sugerir partes de código baseadas em conectores definidos no próprio documento ou importados de um terceiro. Visando tornar a linguagem ampla o bastante para funcionar tanto em dispositivos com maior poder de processamento, quanto em dispositivos com recursos mais restritos, a linguagem NCL define três perfis principais: TVD Básico, Linguagem NCL e TVD Avançado. Atualmente, o perfil suportado pelo NCL Eclipse, tanto na sugestão de código, quanto na validação, é o TVD Avançado [ABNT 2007], o qual abrange os perfis Linguagem NCL e alguns módulos SMIL. Embora este perfil englobe tudo que o padrão da linguagem NCL pode oferecer o autor sempre trabalhará com este perfil e não tem a garantia, por exemplo, que receberá sugestões baseadas em um perfil mais simplificado (como é o caso do TVD Básico) quando assim desejar. Isto é deixado como trabalho futuro. Outras
possibilidades de continuidade deste projeto são: a definição de uma API de mais alto nível para a criação de novas visões e a integração do NCL Eclipse com repositórios públicos de aplicações NCL (como é o caso do Clube NCL http://www.clube.ncl.org.br), permitindo ao desenvolvedor publicar suas aplicações nesses locais, se assim o desejar, compartilhandoas com a comunidade. 7. Referências ABNT - Associação Brasileira de Normas Técnicas (2007) Televisão Digital Terrestre - Codificação de dados e especificações de transmissão para radiodifusão digital. Parte 2: Ginga-NCL para receptores fixos e móveis Linguagem de aplicação XML para codificação de aplicações. Araújo, E. C., Azevedo, R. G. A., e Soares, C. S. (2008) NCL-validator: um processo para validação sintática e semântica de documentos multimídia NCL. II Jornada de Informática do Maranhão São Luís, Brasil. ARIB (2004) Association of Radio Industries and Businesses. Data Coding and Transmission Specifications for Digital Broadcasting Volume 2: XML-Based Multimedia Coding Schema, STD-B24 Versão 4, Fevereiro de 2004. Bulterman, D. C. A., Hardman, L., Mullender, K. S., e Rutledge, L. (1998) Grins: A graphical interface for creating and playing smil documents. WWW7 Conference Computer Networks and a ISDN Systems. Coelho, R.M., Rodrigues, R.F., e Soares, L.F.G. (2004) Integração de Ferramentas Gráficas e Declarativas na Autoria de Arquiteturas Modeladas através de Grafos Compostos (Português). X Simpósio Brasileiro de Sistemas Multimídia e Web WebMedia Ribeirão Preto, Brasil. Costa, R.M.R., e Soares, L.F.G. (2007) Modelo Temporal Hipermídia para Suporte a Apresentações em Ambientes Interativos (Português). XIII Simpósio Brasileiro de Sistemas Multimídia e Web - WebMedia, Gramado, Brasil. ECMA (1999) Standardizing Information and Communication Systems. ECMAScript Language Specification, Padrão ECMA 262, 3a Edição, 1999. Eclipse.org (2008) Eclipse IDE. Disponível em: http://www.eclipse.org Eclipse.org GEF (2008) Graphical Editing Framework. Available at http://www.eclipse.org/gef/ ETSI (2005) European Telecommunications Standards Institute. Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1.1, Especificação Técnica ETSI TS 102 B12, Maio de 2005. Green, T. R. and Petre, M. (1992) When visual programs are harder to read than textual programs. ECCE-6 (6th European Conference on Cognitive Ergonomics). Guimarães, R. L., de Resende Costa, R. M., e Soares, L. F. G. (2007) Composer: Ambiente de autoria de aplicações declarativas para a tv digital interativa. WEBMEDIA: Brazilian Symposion on Multimedia and the Web.
Ierusalimschy, Roberto (2006) Programming in Lua, Second Edition, Lua.org. LuaEclipse (2008). Luaeclipse: An integrated development environment for the lua programming language. http://luaeclipse.luaforge.net/. Manalee (2008). Smox Pad Version 1.0. Disponível em: http://www.manalee.com/product_details.php?idproduct=19 Moreno, M. F., Costa, R. M. R, e Soares, L. F. G. (2008) Sincronismo entre Fluxos de Mídia Contínuas e Aplicações Multimídia em Redes de Difusão. Webmedia 2008. Soares, L. F. G. Rodrigues, R. F. Costa, R. M. R., Moreno, M. F. (2006) Nested Context Model 3.0: Part 1- NCM Core. Rio de Janeiro, Brasil. W3C (2005) Synchronized multimedia integration language (smil 2.1). Disponível em: http://www.w3.org/tr/rec-smil/.