Universidade Federal do Maranhão
Centro de Ciências Exatas e Tecnologia
Curso de Ciência da Computação
ROBERTO GERSON DE ALBUQUERQUE AZEVEDO
NCL Eclipse: editor textual para desenvolvimento de
programas Hipermı́dia Interativos em NCL
São Luı́s
2008
ROBERTO GERSON DE ALBUQUERQUE AZEVEDO
NCL Eclipse: editor textual para desenvolvimento de
programas Hipermı́dia Interativos em NCL
Monografia apresentada ao Curso de Ciência da
Computação da UFMA, como requisito parcial para
a obtenção do grau de BACHAREL em Ciência da
Computação.
Orientador: Mário Antonio Meireles Teixeira
Doutor em Ciência da Computação – UFMA
Co-orientador: Carlos de Salles Soares Neto
Mestre em Informática – PUC-Rio
São Luı́s
2008
Azevedo, Roberto Gerson de Albuquerque
NCL Eclipse: editor textual para desenvolvimento de programas
Hipermı́dia Interativos em NCL / Roberto Gerson de Albuquerque
Azevedo - 2008
45.p
1.Ciência da Computação 2. Sistemas Hipermı́dia 3. Nested Context Language 4. Editor Textual. I.Tı́tulo.
ROBERTO GERSON DE ALBUQUERQUE AZEVEDO
NCL Eclipse: editor textual para desenvolvimento de
programas Hipermı́dia Interativos em NCL
Monografia apresentada ao Curso de Ciência da
Computação da UFMA, como requisito parcial para
a obtenção do grau de BACHAREL em Ciência da
Computação.
Aprovado em 10 de julho de 2008
BANCA EXAMINADORA
Mário Antonio Meireles Teixeira
Doutor em Ciência da Computação – UFMA
Anselmo Cardoso de Paiva
Doutor em Informática – UFMA
Maria Auxiliadora Freire
Mestre em Engenharia Civil – UFMA
À meus pais.
Aos meus irmãos e à minha irmãzinha querida.
Agradecimentos
Agradeço à minha famı́lia e a todos que direta ou indiretamente guiaram os
meus passos até este momento. Em especial, às duas pessoas que sempre estiveram
presentes na minha vida, os quais tive a sorte grande de ter como pais. Agradeço e dedico
à minha mãe, Virgı́nia Carminda de Paula Albuquerque Azevedo – pessoa a quem admiro
e amo bastante principalmente por ser sempre companheira, amiga, conselheira, carinhosa
e amorosa – e à meu pai, José Tarcı́sio Braga de Azevedo – a quem não deixo de admirar
e amar da mesma forma, por ser quem me ensinou e me ensina até hoje, principalmente
através do seu exemplo, a viver dignamente, a ter caráter e a respeitar o próximo.
Agradeço também a todos os professores do Departamento de Informática. Em
especial, aos meus orientadores, Carlos de Salles e Mário Meireles, com quem tive a honra
e o prazer de trabalhar. Ambos, sempre acreditaram neste trabalho e ofertaram muitos
conselhos sábios, o que facilitou muito a sua realização.
Resumo
Uma boa ferramenta é essencial para se desenvolver aplicações de forma rápida e confiável.
Como não poderia ser diferente, isto também se aplica às linguagens hipermı́dia declarativas, entre as quais está a linguagem padrão para desenvolvimento de programas do
Sistema Brasileiro de Televisão Digital Terrestre (SBTVD-T): a NCL - Nested Context
Language. Esta monografia apresenta um editor textual que visa auxiliar o desenvolvimento de aplicações em NCL, desenvolvido na forma de um plug-in para a IDE Eclipse.
Este editor textual, denominado NCL Eclipse traz funcionalidades como auto-completação
de código automática e contextual, validação de documentos escritos em NCL e/ou XConnector, coloração de tags XML e palavras reservadas da linguagem, dentre outras.
Palavras-chaves: Sistemas Hipermı́dia, NCL, editor textual, plug-in, Eclipse.
Abstract
A good development tool is essential to a quick and reliable applications development. It
is also useful to hypermedia declarative languages, like the standard language to Brazilian
Terrestrial Digital Television System (SBTVD-T) programs development - Nested Context
Language (NCL). This work presents a textual editor to aid the application development
in NCL, developed as an Eclipse plug-in. This textual editor is called NCL Eclipse and
has various functionalities, such as contextual automatic completion, document validation,
syntax colorization and so on.
Keywords: Hypermedia Systems, NCL, textual editor, plug-in, Eclipse.
“Se você acha que pode, está certo. Se
você acha que não pode, também está certo.”.
Henry Ford
Sumário
Lista de Figuras
8
Lista de Siglas
10
1 Introdução
11
1.1
Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Trabalhos Relacionados
14
2.1
Composer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2
Grins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3
SMOX Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 A Linguagem NCL
18
3.1
Linguagens Hipermı́dia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2
Linguagens Procedurais X Linguagens Declarativas . . . . . . . . . . . . . 19
3.3
NCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1
Módulos e Perfis NCL . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4
Conceitos básicos em NCL . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5
A estrutura de um documento NCL . . . . . . . . . . . . . . . . . . . . . . 23
3.6
NCL e a TV Digital
4 Validador NCL
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
28
4.1
Validacão com XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2
Processo NCL Validator 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3
Implementação do Processo NCL Validator 3.0 . . . . . . . . . . . . . . . . 31
4.3.1
NCL Validator 3.0 - Front End . . . . . . . . . . . . . . . . . . . . 32
4.3.2
Reutilização do NCL Validator 3.0 . . . . . . . . . . . . . . . . . . 32
5 Ambiente Eclipse
5.1
Conceitos básicos no Ambiente Eclipse . . . . . . . . . . . . . . . . . . . . 36
5.1.1
5.2
36
Perspectivas, Visões e Editores
. . . . . . . . . . . . . . . . . . . . 36
Visão geral da arquitetura do Eclipse . . . . . . . . . . . . . . . . . . . . . 38
5.2.1
Infra-estrutura dos Plug-ins . . . . . . . . . . . . . . . . . . . . . . 39
5.2.2
SWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.3
JFace
5.2.4
Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.5
Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.6
Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3
Criação de plug-ins para o Eclipse . . . . . . . . . . . . . . . . . . . . . . . 43
5.4
Um Exemplo: Java Perspective . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4.1
Criando um projeto -New Project Wizard . . . . . . . . . . . . . . . 45
5.4.2
Editor Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6 NCL Eclipse
48
6.1
Levantamento de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2
Funcionalidades Implementadas . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3
Infra-estrutura
6.4
Funcionamento do NCL Eclipse . . . . . . . . . . . . . . . . . . . . . . . . 51
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.4.1
NCL Wizard e Connector Base Wizard . . . . . . . . . . . . . . . . 51
6.4.2
Coloração sintática . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4.3
Outline view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.4.4
Folding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4.5
Autocomplete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6
6.4.6
Integração NCL Eclipse e NCL Validator . . . . . . . . . . . . . . . 59
6.4.7
Execução de um documento NCL - Integração NCL Eclipse e Ginga
Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7 Considerações Finais
62
Referências Bibliográficas
64
Glossário
67
A NCL Eclipse - Diagrama de Classes e Pontos de Extensão
70
Lista de Figuras
2.1
Visões do Composer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2
SMOX Pad, um editor textual para a linguagem SMIL . . . . . . . . . . . 17
3.1
Nós, elos e nós de composição. Fonte: [Neto et al. 2007]
3.2
Estrutura da linguagem NCL - Exemplo de código . . . . . . . . . . . . . . 24
3.3
Arquitetura do middleware Ginga. . . . . . . . . . . . . . . . . . . . . . . . 27
4.1
Ilustração do Processo NCL Validator . . . . . . . . . . . . . . . . . . . . . 30
4.2
Diagrama de sequência da implementação do NCL Validator 3.0 . . . . . . 31
4.3
NCL Validator 3.0 sendo utilizado como front-end . . . . . . . . . . . . . . 33
4.4
Reutilizando o NCL Validator 3.0 - Exemplo de código . . . . . . . . . . . 34
4.5
NCL Validator sendo reutilizado pelo Composer . . . . . . . . . . . . . . . 35
5.1
Java Perspective - identificação de algumas visões e do editor Java. . . . . 37
5.2
Java Perspective - Menu do topo e barra de ferramentas . . . . . . . . . . 37
5.3
Java Perspective - exemplos de menus contextuais . . . . . . . . . . . . . . 38
5.4
Arquitetura do ambiente Eclipse. Fonte: [Eclipse Foundation 2008] . . . . 39
5.5
PDE - wizard para a criação de plug-ins . . . . . . . . . . . . . . . . . . . 44
5.6
PDE - gerenciamento de dependências . . . . . . . . . . . . . . . . . . . . 44
5.7
PDE - gerenciamento de pontos de extensão . . . . . . . . . . . . . . . . . 45
5.8
Exemplo de um arquivo .project . . . . . . . . . . . . . . . . . . . . . . . . 45
5.9
Editor Java - evidenciando autocomplete. . . . . . . . . . . . . . . . . . . . 47
6.1
Diagrama do NCL Eclipse interligado com o Eclipse . . . . . . . . . . . . . 50
6.2
Criação de um novo documento NCL . . . . . . . . . . . . . . . . . . . . . 51
. . . . . . . . . . 23
6.3
Criação de um novo documento NCL . . . . . . . . . . . . . . . . . . . . . 52
6.4
Fragmento do plugin.xml que define os wizards . . . . . . . . . . . . . . . . 53
6.5
Coloração sintática e Outline View . . . . . . . . . . . . . . . . . . . . . . 54
6.6
Colapsar (Folding) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.7
Principais partições do XML definidas pelo NCL Eclipse . . . . . . . . . . 56
6.8
Autocomplete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.9
Autocomplete – sugestão de referências . . . . . . . . . . . . . . . . . . . . 58
6.10 Marcação de erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.11 Execução de um documento NCL . . . . . . . . . . . . . . . . . . . . . . . 61
A.1 Diagrama de classes do NCL Eclipse - visão geral . . . . . . . . . . . . . . 71
A.2 Diagrama especı́fico da implementação dos Wizards . . . . . . . . . . . . . 72
A.3 Diagrama de classes especı́fico da implementação da visão Outline . . . . . 72
A.4 Diagrama de classes especı́fico da implementação do parsing NCL, utilizado
para manter informações na memória e sugerı́-las quando necessário . . . . 73
A.5 Arquivo plugin.xml - Customização dos pontos de conexão . . . . . . . . . 74
10
Lista de Siglas
Para o efeito deste trabalho as seguintes abreviaturas são utilizadas:
API Application Programming Interface
APT Annotation Processing Tool
BDTV Basic Digital Television - é um perfil NCL. Básico TV Digital.
DOM Document Object Model
DTD Document Type Definition
DTV Digital Television
DVB Digital Video Broadcasting
EDTV Enhanced Digital Television - é um perfil NCL. Avançado TV Digital.
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
IDE Integrated Development Enviroment
JDT Java Development Tools
NCL Nested Context Language
NCM Nested Context Model
PDE Plug-in Development Enviroment
SBTVD-T Sistema Brasileiro de Televisão Digital Terrestre
SDK Standard Development Kit
SMIL Synchronized Multimedia Integration Language
UI User Interface
URI Universal Resource Identifier
URL Universal Resource Locator
XHTML eXtensible HTML
XML Extensible Markup Language
WYSIWYG What You See Is What You Get
W3C World-Wide Web Consortium
11
1 Introdução
A programação textual é tida em muitos casos como mais fácil de entender e natural
para os seres humanos interagirem com o computador. Isto é válido mas não pode ser
generalizado para todos os casos, conforme demonstrou [Green e Petre 1992]. A avaliação
do quão fácil e produtiva é uma linguagem de programação deve também levar em conta o
público-alvo ao qual esta linguagem se destina. Para um matemático, por exemplo, pode
ser mais natural representar um cı́rculo através do tamanho de seu raio, textualmente,
enquanto que para um desenhista, desenhar este mesmo cı́rculo através do mouse ou de
uma tela touch screen, de forma visual, pode deixá-lo mais a vontade.
Tendo isto em mente, quando se analisa a programação para a TV Digital,
é possı́vel distinguir dois públicos-alvo distintos. Os primeiros são os produtores de
conteúdo, entre os quais estão os designers, pessoal de arte, de TV, etc. O segundo
grupo são programadores. Linguagens visuais, principalmente em um ambiente WYSIWYG, estão mais próximos do primeiro grupo e linguagens textuais – linguagens de
programação – são mais naturais para o segundo grupo. Este trabalho foca no desenvolvimento de uma ferramenta que auxilia a programação textual, notadamente mais bem
aceita pelos programadores, e visa adicionar funcionalidades que tornem o trabalho de
criação de códigos mais produtivo.
A especificação de programas de forma textual geralmente é um processo árduo
e que requer bastante cuidado, pois um pequeno erro pode fazer com que toda a solucão
desenvolvida esteja errada. Isto faz com que sejam necessárias ferramentas para auxiliar
neste desenvolvimento. A ferramenta mais utilizada com este objetivo – bem conhecida
dos programadores – é a IDE – Integrated Development Enviroment ou Ambiente Integrado de Desenvolvimento. Cada IDE fornece um conjunto de funcionalidades para um
determinado grupo de usuários. São exemplos destas funcionalidades: desenvolvimento
visual, - através de menus, janelas, ou mesmo com desenhos, dependendo da linguagem
à qual a IDE auxilia - editores de texto com coloração de sintaxe, auto-completação de
código, etc. validação de código-fonte e indicação de erros sintáticos e semânticos.
Existem também ambientes de programação, onde o programador utiliza-se de
1.1 Estrutura
12
formulários para preencher lacunas do programa, sendo que a IDE produz o código-fonte
final. Neste tipo de ambiente é possı́vel que também seja necessário alterar o código-fonte
de forma textual. Isto porque, geralmente as linguagens, que neste caso são textuais,
trazem muito mais possibilidades de especificação de problemas do que as IDEs permitem
expressar através do desenvolvimento baseado em formulários. Existem casos também
em que o desenvolvedor sente-se mais à vontade para exercer sua função através da especificação textual, o que em muitos casos pode ser mais rápido, principalmente quando o
editor o auxilia.
A linguagem NCL permite a criação de apresentações hipermı́dia interativas
e foi adotada como linguagem declarativa padrão pelo Sistema Brasileiro de TV Digital
(SBTVD-T). Por ser uma linguagem relativamente nova e ainda com poucos usuários, a
carência de ferramentas para a criação de documentos NCL ainda é grande. O ambiente
Composer[Guimarães, Costa e Soares 2007], que será melhor discutido nos trabalhos relacionados, é uma ferramenta que auxilia na criação destes documentos e tem como foco o
desenvolvimento visual, ou seja, seu público-alvo principal são os produtores de conteúdo.
Embora o Composer possibilite que o autor edite o texto do documento NCL, ele não
traz auxı́lio algum com este objetivo. Caracterı́sticas como autocompletação de código e
auto-formatação não estão implementadas no Composer. Sendo assim, quando o autor
encontra-se em uma situação em que é necessário atuar diretamente no código-fonte do
documento, o mesmo terá que fazê-lo sem nenhum auxı́lio da ferramenta.
Visando suprir essa necessidade é proposta nesta monografia um editor textual
que auxilia o autor na criação de documentos NCL, denominado NCL Eclipse. O NCL
Eclipse é implementado como um plug-in para a IDE Eclipse, visando reusar todo este
ambiente já consagrado, bem como outros plug-ins. Não é objetivo do NCL Eclipse ser um
concorrente do Composer. O principal objetivo é atender uma outra classe de usuários,
que possuem conhecimento de NCL e preferem criar documentos hipermı́dia através da
especificação textual.
1.1
Estrutura
Esta monografia está dividida da seguinte forma: No capı́tulo 2 são apresentados os
trabalhos relacionados. No capı́tulo 3 é feito uma visão geral da linguagem NCL. Já no
1.1 Estrutura
13
capı́tulo 4 é discutido o processo de validação de documentos NCL desenvolvido como
parte desta monografia e que será reutilizado pelo editor NCL aqui proposto. O capı́tulo
5 apresenta o ambiente Eclipse que serviu como base para a implementação do NCL
Eclipse. Seguindo, o capı́tulo 6 discute as caracterı́sticas implementadas no NCL Eclipse
e os detalhes desta implementação. Por fim, no capı́tulo 7 apresenta-se a conclusão do
trabalho, juntamente com propostas de trabalhos futuros.
14
2 Trabalhos Relacionados
Neste capı́tulo são apresentados alguns trabalhos relacionados à esta monografia.
2.1
Composer
O Composer é uma ferramenta de autoria hipermı́dia voltada para o desenvolvimento de
programas audiovisuais interativos em NCL. Desenvolvido pelo Laboratorio TeleMı́dia da
PUC-Rio (Pontifı́cia Universidade Católica do Rio de Janeiro). O Composer encontra-se
atualmente na versão 2.2.1. Seu principal objetivo é possibilitar que usuários com pouco
conhecimento de NCL possam produzir programas. Para que isso seja possı́vel a filosofia
utilizada pelo Composer é a de que o usuário que irá construir o programa poderá fazê-lo
através de visões. Cada visão mostra uma parte do programa NCL e uma alteração em
uma das visões atualiza automaticamente as outras visões.
Existem basicamente 4 visões: Visão Estrutural (1), Visão Temporal (2),
Visão de Leiaute (3) e Visão Textual (4), conforme a Figura 2.1.
A Visão Estrutural mostra os nós e os elos entre os nós. É através desta visão
que se pode criar nós de mı́dia, nós de contexto e elos. A Visão Temporal mostra como
o sincronismo temporal está definido pelo documento e quais as opcões de interatividade.
A Visão de Leiaute ilustra as regiões definidas pelos elementos region da NCL. Pode-se
alterar o tamanho e/ou a posicão das regiões através do mouse, sem a necessidade de
especificar os valores das propriedades diretamente. A Visão Textual é um editor de texto
que apresenta o código NCL em si. A Visão Textual do Composer, na versão atual é um
simples editor de texto XML, com coloracão de tags e valores de atributos.
Em [Neto et al. 2007] pode-se encontrar uma introdução à ferramenta Composer. Este tutorial ensina como criar programas interativos utilizando-a. As versões mais
atuais da ferramenta bem como a documentação referente a ela podem ser encontradas
no site http://www.ncl.org.br. Maiores detalhes sobre o Composer também podem ser
encontrados em [Guimarães, Costa e Soares 2007].
A presente monografia se propõe a fazer um editor que poderia ser entendido
2.2 Grins
15
Figura 2.1: Visões do Composer
como a Visão Textual do Composer. A maior diferença, entretanto, é que a ferramenta
aqui proposta se propõe a ajudar o usuário na medida em que o mesmo está editando o
código do documento NCL, o que não existe, pelo menos na versão atual, do Composer.
O NCL Eclipse poderá ser utilizado em conjunto com o Composer, mesmo sem
nenhuma integracão ainda automatizada. É fácil sugerir aos usuários que se sintam melhor
utilizando a Visão Textual do Composer para que migrem para o NCL Eclipse. Visto que
com a ferramenta aqui sugerida muitas novas funcionalidades serão adicionandas a um
editor de código NCL.
2.2
Grins
O GRiNS [Bulterman et al. 1998] é um sistema de autoria e apresentação para documentos SMIL [W3C 2005]. Assim como o Composer, o Grins também é voltado para
autores com pouco conhecimento da linguagem hipermı́dia (no caso, SMIL) e também
utiliza a abordagem de visões, embora de uma forma um pouco diferente da abordagem
2.3 SMOX Pad
16
do Composer.
O GRiNS possui basicamente três visões: Visão de Estrutura Lógica (logical
structure view ), Visão de Linha de Tempo Virtual (virtual timeline view ), Visão de
‘Playout’ (playout view ) e Visã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 visão os atributos dos nós
são preenchidos em formulário, representando a grosso modo os nós < par > e < seq >.
A virtual timeline view tem o propósito de tornar mais visı́veis relações com os
atributos DURATION e REPEAT, que não ficam muito claras na logical structure view.
Nesta visão é mostrada a cronometragem lógica das relações calculadas a partir da logical
structure view.
A playout view ou presentation view permite tocar o documento SMIL, além
de permitir alterar dinamicamente os valores dos atributos.
A textual view é um simples editor de textos e oferece apenas recursos básicos.
A coloração sintática é bem restrita, visto que somente as composições com semântica
temporal (<par>, <seq> e <excl>) recebem cor em destaque. A sugestão de código não
está presente no GRiNS.
Mais informações sobre o GRiNS podem ser encontradas em [Oratrix 2008].
Mais informações sobre SMIL podem ser encontradas em [Refsnes Data 2008].
2.3
SMOX Pad
O SMOX Pad [Manalee 2008] é um editor de texto avançado voltado para a linguagem
SMIL. Muitas das caracterı́sticas sugeridas para a ferramenta proposta por esta monografia são suportadas pelo SMOX Pad. Algumas delas são:
• Coloração sintática
• Auto-completação de código
• Identificação de erros
O SMOX Pad é uma ferramenta proprietária, produzida pela Manalee. Além
do SMOX Pad, a Manalee também possui a ferramenta SMOX Editor, uma ferramenta
2.3 SMOX Pad
17
WYSIWYG para a criação de apresentações SMIL. É possı́vel assim, atingir duas classes
de usuários, os que se sentem mais à vontade na criação visual (com o SMOX Editor) e
os que se sentem mais à vontade com a especificação textual das apresentações (com o
SMOX Pad).
A existência do SMOX Pad é mais um indı́cio de que ferramentas que atingem
esta classe de usuário são bem recebidas e até mesmo rendáveis no ambiente de criação
de documentos Hipermı́dia. Esta é mais uma justificativa para a criação da ferramenta
proposta por esta monografia.
Uma desvantagem encontrada no SMOX Pad é o fato de que o autocomplete
não é contextual em muitos casos. Um exemplo disto é quando estamos definindo um
filho de uma tag head e o editor nos sugere head, ou até mesmo body. Fatos estes que
não condizem com a especificação do SMIL. Outra desvantagem encontrada no SMOX
Pad é o fato de que só existe versão deste para a plataforma Windows. Estes fatos foram
levados em conta para a criação do NCL Eclipse. O caráter multiplataforma do ambiente
Eclipse foi mais um fator que contribuiu para a sua escolha como base deste trabalho.
Figura 2.2: SMOX Pad, um editor textual para a linguagem SMIL
18
3 A Linguagem NCL
Neste capı́tulo a estrutura da linguagem NCL é discutida. Primeiramente, se discutirá o
que é uma hipermı́dia e o que é uma linguagem hipermı́dia. Posteriormente, o conceito
de linguagem declarativa. Por fim, um exemplo de um documento NCL será apresentado,
onde serão discutido os principais elementos de NCL.
3.1
Linguagens Hipermı́dia
Os conceitos de hipermı́dia e multimı́dia muitas vezes são utilizados como sinônimos,
erroneamente. Na realidade, o conceito de hipermı́dia surge da década de 1960, com o
filósofo e sociólogo estadunidense Ted Nelson [Nelson 1965], como uma extensão lógica
do conceito de hipertexto, na qual áudio, vı́deo, texto e hiperlinks se interrelacionam
para criar um meio geral não-linear de informação. Caracterı́stcas como hibridismo, nãolinearidade, interatividade e navegabilidade estão presentes no conceito de hipermı́dia. A
multimı́dia, por outro lado, é uma mı́dia que se utiliza de uma combinação de conteúdos
em formas diferentes. Uma multimı́dia, geralmente é gravada e tocada ou acessada por
dispositivos de processamento de informações.
Atualmente a World Wide Web pode ser entendida como um meio hipermı́dia.
Contudo, na WWW existe apenas um tipo de hiperlink, o ‘vai-para’. Este hiperlink
possibilita apenas que ao se clicar em uma mı́dia que tem a propriedade de hiperlink, o
sistema nos leve à outra.
Além do hiperlink ‘vai para’ é possı́vel que novos tipos de hiperlinks sejam
idealizados, por exemplo, hiperlinks temporais e espaciais. Neste contexto, uma linguagem que permite estruturar estas informações: conteúdo, estrutura e hiperlinks dos mais
variados é o que denomina-se linguagem hipermı́dia. Conforme será visto mais a frente,
a linguagem NCL dá suporte a estruturação de informações em um sistema hipermı́dia.
3.2 Linguagens Procedurais X Linguagens Declarativas
3.2
19
Linguagens Procedurais X Linguagens Declarativas
Existem várias formas de classificar as linguagens de programação. Aqui estamos interessados em uma classificação em particular que distingue as linguagens de programação
em linguagens procedurais (ou imperativas) e linguagens declarativas. As linguagens procedurais são aquelas que exigem que o programador especifique explicitamente todos os
passos que o programa deve executar. Por outro lado, as linguagens declarativas são
aquelas onde o programador especifica uma definição da tarefa a ser executada, sem se
preocupar como ‘exatamente’ esta tarefa será executada pelo computador.
Em outras palavras pode-se afirmar que a diferença entre linguagens procedurais e declarativas é que, na primeira, se especifica como obter a resposta, enquanto, na
segunda, se especificam as condições que devem ser satisfeitas para se obter a resposta.
Programação declarativa envolve o que deve ser computado, mas não necessariamente
como será computado.
As linguagens procedurais, ao necessitarem que sejam especificados todos os
passos da execução do programa, terminam por tornar-se complexas para a criação de
documentos hipermı́dia. Devido a isso, geralmente utilizam-se linguagens declarativas
com este propósito, as quais permitem um maior nı́vel de abstração. Para que estes
documentos sejam executados, é necessário um interpretador (ou no caso especı́fico de
linguagens hipermı́dia, um formatador ou player ), o qual é o responsável por aplicar um
algoritmo pré-definido às especificações feitas para produzir o resultado desejado.
A NCL é uma linguagem declarativa que visa a criação de documentos hipermı́dia. A seção a seguir dá uma visão geral da linguagem.
3.3
NCL
NCL - Nested Context Language - é uma linguagem declarativa, baseada em XML, para
especificação de apresentações hipermı́dia interativas. A NCL tem como base o modelo
NCM [Soares e Rodrigues 2005]. Ela age como um elemento de ‘cola’ entre os diversos
elementos multimı́dia atômicos, tais como texto, som, vı́deo, imagem, etc. Seu objetivo
não é especificar o conteúdo das mı́dias, mas sim como as mı́dias interagem entre si no
3.3 NCL
20
espaço e no tempo, possibilitando assim a separação mais acurada entre o conteúdo e a
estrutura.
[ABNT 2007, Separar o conteúdo da estrutura é útil na medida em que torna a
linguagem NCL bastante ampla, tornando possı́vel que mı́dias de diversos tipos diferentes
possam ser relacionadas com o mesmo documento NCL, desde que é claro, o formatador
que vá tocar o documento saiba como disparar o tocador daquela mı́dia em particular.]
3.3.1
Módulos e Perfis NCL
A linguagem NCL é modular. Isto quer dizer que toda a sua estrutura é dividida em
módulos, os quais são especificados através de XML Schema. Especificar a linguagem em
módulos provê um maior reuso, visto que tanto podem ser adicionados novos módulos
facilmente à linguagem, como os módulos da linguagem podem ser facilmente inseridos
em outras linguagens.
Um perfil de uma linguagem é uma combinação de módulos. Normalmente,
uma linguagem define um perfil que abrange todos os módulos da linguagem, no caso da
NCL este é o perfil Linguagem NCL. A NCL também define outros perfis, o perfil BTVD,
por exemplo, é um subconjunto do perfil Linguagem NCL, e o perfil ETVD é um perfil
que inclui alguns módulos SMIL. Uma abordagem similar também é encontrada em outras
linguagens ([W3C 2005] e [W3C 2002])
A NCL 3.0 é particionada em 13 áreas funcionais, que são novamente particionadas em módulos. A partir das 13 áreas funcionais, 12 são utilizadas para definir os
perfis TVD Avançado e TVD Básico. Além das 12 áreas funcionais de NCL 3.0, 2 áreas
funcionais foram importadas de SMIL 2.0 para compor o perfil TVD Avançado. As 14
áreas funcionais utilizadas e seus módulos correnspondentes são:
1. Structure
• Módulo Structure
2. Layout
• Módulo Layout
3. Components
3.3 NCL
• Módulo Media
• Módulo Context
4. Interfaces
• Módulo MediaContentAnchor
• Módulo CompositeNodeInterface
• Módulo PropertyAnchor
• Módulo SwitchInterface
5. Presentation Specification
• Módulo Descriptor
6. Linking
• Módulo Linking
7. Connectors
• Módulo ConnectorCommonPart
• Módulo ConnectorAssessmentExpression
• Módulo ConnectorCausalExpression
• Módulo ConnectorTransitionAssessment
• Módulo CausalConnector
• Módulo CausalConnectorFunctionality
• Módulo ConnectorBase
8. Presentation Control
• Módulo TestRule
• Módulo TestRuleUse
• Módulo ContentControl
• Módulo DescriptorControl
9. Timing
21
3.4 Conceitos básicos em NCL
22
• Módulo Timing
10. Reuse
• Módulo Import
• Módulo EntityReuse
• Módulo ExtendedEntityReuse
11. Navigational Key
• Módulo KeyNavigation
12. Animation
• Módulo Animation
13. SMIL Transition Effects
• Módulo TransitionBase
• Módulo BasicTransition
• Módulo TransitionModifiers
NOTA: O módulo TransitionBase é um módulo definido pela NCL 3.0; não existe
na SMIL 2.0.
14. SMIL Meta-Information
• Módulo Metainformation
Não está no escopo desta monografia discutir os detalhes de cada um dos
módulos, mais informações podem ser obtidas em [Soares e Rodrigues 2006] e [ABNT 2007].
Para que o leitor possa se familiarizar com a linguagem NCL, na seção seguinte será mostrado um documento NCL e se discutirá a estrutura da linguagem de uma forma prática.
3.4
Conceitos básicos em NCL
Esta seção discute os principais conceitos do modelo NCM (e consequentemente de NCL)
que são necessários para a criação de documentos hipermı́dia. São eles: nós, nós de
composição, elos e conectores.
3.5 A estrutura de um documento NCL
23
Os dois principais conceitos de NCL são os de nós e elos. Nós podem estar
associados com os objetos de mı́dia que compõem a aplicação ou serem composições de
nós. Composições de nós, por sua vez, podem conter recorrentemente outros nós ou elos.
Uma composição utilizada para estruturar e encapsular partes de aplicações é chamada de
contexto. Uma composição empregada na adaptação de conteúdo é chamada de switch.
A Figura 3.1 mostra um exemplo de um documento hipermı́dia, onde existem nós, elos e
nós de composição.
Figura 3.1: Nós, elos e nós de composição. Fonte: [Neto et al. 2007]
O conceito de conector hipermı́dia está relacionado com o tipo de relacionamento entre os nós que fazem parte de um elo. Esta separação permite o reuso de conectores para vários elos diferentes além de aumentar muito a expressividade da linguagem,
visto que o autor pode criar novos conectores (novos tipos de elos).
3.5
A estrutura de um documento NCL
Para um total entendimento desta seção é necessário um conhecimento básico de XML,
que pode ser obtido através de [Moultis e Kirk 1998].
Nesta seção será discutido um exemplo de um documento NCL simples, apenas
para que o leitor se familiarize com a estrutura da linguagem NCL. A especificação completa da linguagem pode ser encontrada em [ABNT 2007]. Mais informações da linguagem
bem como alguns exemplos práticos são encontrados em [Neto et al. 2007], [NCL 2008] e
[PUC-Rio 2008].
3.5 A estrutura de um documento NCL
24
O exemplo aqui apresentado é uma apresentação que possui dois vı́deos. A
lógica é: o primeiro vı́deo será disparado no inı́cio da apresentação. Quando este terminar
sua exibição, a apresentação deverá disparar o segundo vı́deo. Quando este segundo
terminar sua exibição, a apresentação deverá disparar, novamente, o primeiro vı́deo, e
assim sucessivamente. O código NCL da Figura 3.2 mostra como é possı́vel especificar
esta apresentação em NCL.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<?xml version=” 1 . 0 ” e n c o d i n g=”UTF−8” ?>
<n c l i d=” exemplo01 ” xmlns=” h t t p : //www. n c l . o r g . br /NCL3. 0 / EDTVProfile ”>
<head>
<r e g i o n B a s e>
<r e g i o n i d=” r g V i d e o ” h e i g h t=” 600 ” width=” 800 ” />
</ r e g i o n B a s e>
<d e s c r i p t o r B a s e>
<d e s c r i p t o r i d=” dVideo ” r e g i o n=” r g V i d e o ” />
</ d e s c r i p t o r B a s e>
<c o n n e c t o r B a s e>
<importBase documentURI=” c o n n e c t o r B a s e . n c l ” a l i a s=” connBase ” />
</ c o n n e c t o r B a s e>
</ head>
<body>
<p o r t i d=” p o r t a ” component=” v i d e o 0 1 ” />
<media i d=” v i d e o 0 1 ” s r c=” media / v i d e o 0 1 . mpg” d e s c r i p t o r=” dVideo ” />
<media i d=” v i d e o 0 2 ” s r c=” media / v i d e o 0 2 . mpg” d e s c r i p t o r=” dVideo ” />
<l i n k x c o n n e c t o r=” connBase#onEndStart ”>
<bind component=” v i d e o 0 1 ” r o l e=”onEnd” />
<bind component=” v i d e o 0 2 ” r o l e=” s t a r t ” />
</ l i n k>
<l i n k x c o n n e c t o r=” connBase#onEndStart ”>
<bind component=” v i d e o 0 2 ” r o l e=”onEnd” />
<bind component=” v i d e o 0 1 ” r o l e=” s t a r t ” />
</ l i n k>
</ body>
</ n c l>
Figura 3.2: Estrutura da linguagem NCL - Exemplo de código
Todo documento NCL possui uma tag principal < ncl >, a qual é subdividida
em duas novas tags < head > e < body >. No < head > são definidos os elementos
relacionados com reuso, as regiões (dentro da tag < regionBase >, linha 4 a 6), descritores
(dentro da tag descriptorBase, linha 7 a 9) e conectores (dentro da tag connectorBase,
linha 10 a 12). Uma região define onde as mı́dias poderão aparecer na tela. Caracterı́sticas
como altura, largura, distância da borda à esquerda, direita, topo e abaixo e zIndex podem
ser especificados em uma região. Separando a definição da região da especificação da
mı́dia, se favorece o reuso à medida que uma mesma região pode ser utilizada por várias
mı́dias. Por outro lado, um descritor permite que atributos opcionais com definições
espaço-temporais possam ser especificados. Um dos atributos do descriptor é o region,
o qual permite dizer à qual região aquele descritor está ligado. São outros atributos de
descriptor: explicitDur, player, focusSelSrc, moveUp, moveDown, entre outros.
Ainda como filho do elemento < head >, o < connectorBase > define a
base de conectores que o autor do documento pode utilizar. Os conectores podem ser
3.5 A estrutura de um documento NCL
25
entendidos como os tipos de relações que temos entre as mı́dias. Diferente de HTML,
onde o único tipo de relação é o ‘vai para’, a linguagem NCL permite que novas relações
possam ser definidas. Estes conectores são especificados na linguagem XConnector, cujos
módulos fazem parte de todos os perfis NCL.
Mais uma vez favorecendo o reuso, estes conectores, podem ser especificados em
outro arquivo e reusados por qualquer documento, conforme feito no exemplo, utilizandose a tag < importBase >. Para diminuir a complexidade para o autor final é recomendado
que esta base de connectores seja disponibilizada junto com a ferramenta de autoria. O
autor, assim, não necessita nem ao menos saber como se cria um conector. A idéia
principal é que ele reuse os conectores padrões. Mesmo assim, caso exista a necessidade
o autor poderá criar novos conectores.
O < body > é outro filho do elemento < ncl >. No < body > são definidos os
nós de mı́dia, os relacionamentos entre estes nós (elos), os nós de contexto (< context >)
e de alternativa (< switch >). Estes dois últimos nós não serão comentados pois esta
seção é apenas uma introdução à estrutura da linguagem NCL. Vejamos então os nós de
mı́dia e elos.
Na linha 16 é especificado o nó de mı́dia com identificador video01. Um nó de
mı́dia faz referencia explı́cita a uma mı́dia através do atributo src. O atributo descriptor
especifica a qual descritor aquela mı́dia está associada, o qual deve ser o valor de um
identificador dos descritores definidos em < descriptorBase >. Na linha 17 é especificado
o outro nó de mı́dia que se deve tocar, com identificador video02.
Já foram especificadas as duas mı́dias que serão tocadas, bem como onde elas
aparecerão na tela (region) e com quais caracterı́sticas (descriptor ). Falta agora definir
os relacionamentos entre estas mı́dias. Primeiro, deve-se definir a ‘porta de entrada’ na
apresentação. Isto é feito através do elemento < port > que especifica através do atributo
component qual será o ponto de entrada. Do ponto de vista do usuário, esta será a
primeira mı́dia a ser tocada.
Sabendo que o video01 será a primeira mı́dia a ser tocada, deve-se agora definir
que quando esta mı́dia acabar a outra deve começar. Isto é feito das linhas 18 à 21. No
elemento < link > é especificada que tipo de relação está sendo usada, através do atributo
xconnector. Este tipo de relação deve estar definido na base de conectores. E então se
define que papéis são exercidos por cada mı́dia através os elementos < bind >, filhos de
3.6 NCL e a TV Digital
26
< link >. No exemplo, é utilizada a relação onEndStart, que possui os papéis onEnd e
start. Definimos que nesta relação o video01 exerce o papel de onEnd e o video02 de start.
Resumindo, é descrito que quando o video01 terminar o video02 começa. Das linhas 22
à 25 se especifica o outro elo: quando o video02 acabar, inicia-se o video01 novamente.
Embora tenha sido um exemplo simples - do ponto de vista das possibilidades
que a linguagem NCL oferece, como reuso, interatividade, especificação de novos conectores, etc - este serviu para que o leitor se familiarize com a linguagem NCL. Na seção
seguinte, será discutido um pouco da relação entre NCL e TV Digital.
3.6
NCL e a TV Digital
Embora a linguagem NCL não tenha sido criada com o intuito restrito de ser utilizada
para o desenvolvimento de programas interativos para a TV Digital ela se encaixa perfeitamente a este propósito. Tanto é que a mesma foi escolhida como padrão para a criação
de programas interativos declarativos no Sistema Brasileiro de TV Digital. A parte 2 da
Norma Brasileira - NBR 15606 - Televisão digital terrestre - Codificação dados e especificações de transmissão para radiodifusão digital especifica a linguagem NCL 3.0 para a
TV Digital [ABNT 2007].
O Ginga-NCL [NCL 2008] é um ambiente completo para apresentação de uma
aplicação de TV Digital escrita em linguagem NCL. Ele é o midlleware que fará parte do
Sistema Brasileiro de Televisão digital. A Figura 3.3 mostra a arquitetura do middleware
Ginga, evidenciando o Ginga-NCL.
Alternativamente, também é possı́vel integrar a NCL com linguagens de scripts,
que permitem embutir comandos procedurais à linguagem. Um exemplo desta possibilidade é mostrada por NCLua[PUC-Rio 2008], que integra a linguagem NCL, com scripts
Lua. Isto aumenta muito as possibilidades de expressão que a linguagem tem, permitindo
tratamento de eventos como clique do mouse, aperto de um botão do controle remoto,
etc.
3.6 NCL e a TV Digital
Figura 3.3: Arquitetura do middleware Ginga.
27
28
4 Validador NCL
Há várias razões pelas quais se faz necessário algum processo de validação sintática e
semântica durante a concepção de documentos hipermı́dia. É fácil perceber que há um
ganho significativo de tempo no processo de autoria quando uma ferramenta oferece ao
autor um retorno descritivo sobre erros no documento antes mesmo de exibı́-lo. Um
indicador de possı́veis erros (ou avisos) também é importante para garantir ao autor que
o documento está de acordo com a semântica esperada.
Em um contexto especı́fico como o da transmissão de documentos declarativos
no ambiente de TV digital, onde o receptor móvel ou fixo tem poder de processamento bem
restrito, o processo de validação também é imprescindı́vel. Nesse cenário, o processo pode
ocorrer tanto no lado da emissora, onde as restrições de processamento são bem menos
rı́gidas ou ainda no próprio set-top box, na casa do telespectador. Nesse segundo caso,
a validação pode contribuir em muito para diminuir a complexidade na implementação
da máquina de apresentação do middleware de TV digital. Isso porque o processo de
validação do documento pode ser feito como uma fase isolada e inicial na execução da
aplicação interativa, simplificando a implementação dos passos seguintes ao garantir que
o documento está correto.
Este capı́tulo apresenta um processo de validação sintática e semântica exclusivamente para documentos NCL (Nested Context Language) que é denominado NCL
Validator. Juntamente com o processo também é apresentada uma implementação do
NCL Validator para a versão 3.0 da linguagem NCL. A implementação aqui mostrada é
reutilizada pelo NCL Eclipse, possibilitando que erros sejam dinamicamente apresentados
ao autor durante a concepção do documento NCL.
4.1
Validacão com XML Schema
Ao trabalhar-se com linguagens baseadas no padrão XML[W3C 2008] é comum o pensamento de que a validação com XML Schema[W3C 2003] é a melhor abordagem a ser
utilizada para validar estes documentos, visto que existem bibliotecas disponı́veis com
4.2 Processo NCL Validator 3.0
29
este objetivo. Esta foi a primeira abordagem a ser levada em consideração para se validar
um documento NCL. Contudo, como foi possı́vel evidenciar à medida que nos familiarizamos mais com a linguagem, NCL possui várias particularidades que não podem ser
especificadas através de um XML Schema. Dois motivos principais motivaram a criação
de um processo de validação especı́fico para a linguagem:
• As bibliotecas disponı́veis não oferecem mensagens suficientemente ilustrativas ao
autor (o que já remeteu à criação do Schematron [ISO 2008]);
• Esta não é uma abordagem útil para algumas especificidades de NCL, como o escopo
baseado nas perspectivas.
Para ilustrar a segunda restrição, é importante salientar que, por meio da abordagem XML Schema, é possı́vel definir, segundo a terminologia XML, a cardinalidade dos
elementos e seus filhos e os tipos dos atributos, mas não seria possı́vel validar semanticamente atributos que fazem referência a identificadores de tipos especı́ficos de elementos,
ou ainda que referenciem elementos que são filhos do mesmo contexto em que se encontra
um elo (a idéia de perspectiva).
A Seção a seguir discute o processo NCL Validator, cujo objetivo é verificar se
um documento NCL está conforme a Norma [ABNT 2007].
4.2
Processo NCL Validator 3.0
O processo proposto para a validação de um documento NCL é dividido em quatro fases:
Validação Léxica e Sintática, Validação Estrutural, Validação Contextual e de
Referências e Validação Semântica.
Sendo a linguagem NCL baseada em XML, o primeiro passo de validação
em um documento é a estrutura léxica e sintática do XML. Com este objetivo existem
várias bibliotecas que podem ser utilizadas e que fazem o parsing de um documento
XML. Para economia de tempo e esforço o processo sugere que alguma destas bibliotecas seja reutilizada. São exemplos de bibliotecas que fazem parsing de XML: o Xerces
[Apache Software Foundation 2002] e a bilibioteca padrão Java DOM.
O próximo passo do processo é validar a estrutura do documento. Neste passo
é verificado se todos os atributos presentes em um elemento são válidos, se todos os
4.2 Processo NCL Validator 3.0
30
atributos obrigatórios estão presentes, se os filhos de um determinado elemento estão
definidos na norma e se estão conforme a cardinalidade especificada na norma.
Componentes NCM [Soares e Rodrigues 2005] possuem um id que os identificam univocamente no documento, este atributo freqüentemente é utilizado para fazer
referência a estes elementos. Saber se o elemento referenciado existe, se é do tipo que o
atributo ‘requer’ e se está no mesmo contexto do elemento que o referencia são os pontos de validação que mais necessitam de cuidado e os mais necessários também. Estas
validações são realizadas no Passo 3.
Por fim, pode-se ainda ter um passo adicional de validação, aqui chamado
de Semântica, que tem por função gerar alertas ao usuário caso sejam detectadas inconsistências do ponto-de-vista da apresentação do documento. Como exemplos citam-se:
a existência de trechos do documento que não são alcançáveis por um elo ou ainda elementos internos de um nó de alternativa que nunca são selecionados. Este passo envolve
uma simulação da apresentação do documento e mesmo sendo útil não compromete a
utilidade de uma implementação que não o cobre. A Figura 4.1 ilustra esquematicamente
como funciona o processo NCL Validator. As mensagens de erro e/ou alertas são geradas
durante cada uma das fases, ficando disponı́vel para serem acessadas após o término da
validação.
Figura 4.1: Ilustração do Processo NCL Validator
4.3 Implementação do Processo NCL Validator 3.0
4.3
31
Implementação do Processo NCL Validator 3.0
Visando comprovar o processo pela seção anterior e disponibilizar uma solução completa,
uma implementação do NCL Validator foi desenvolvida em Java. Para fazer o parsing do
documento NCL utilizou-se a biblioteca XML padrão do Java. Por não comprometer o
processo, o passo 4 proposto acima, não foi implementado, deixando-se como um trabalho
futuro. A implementação realizada está disponı́vel de duas formas diferentes: através de
um software front-end (voltada para o usuário final); ou através de uma biblioteca que
pode ser reutilizada por outros softwares (como os de autoria ou os de apresentação).
A Figura 4.2 apresenta o diagrama de sequência da implementação do processo
NCL Validator 3.0. Neste diagrama é possı́vel verificar as principais classes envolvidas no
processo de validação - NCLValidator, DTDValidator, Semantics, Message e MessageList
- e quais as principais mensagens trocadas entre objetos destas classes.
Estruturalmente existe um pacote - br.ufma.deinf.laws.ncl - no qual as classes
são responsáveis pela modelagem da estrutura da linguagem NCL 3.0 (NCLStructure)
e pela validação dos tipos básicos - entre os quais estão identificador, inteiro, URI, size,
etc. - (DataType). A classe NCLValidatorDocument é responsável pela modelagem de um
documento NCL 3.0 e também pelo primeiro passo na validação proposta pelo processo:
validação léxica.
Figura 4.2: Diagrama de sequência da implementação do NCL Validator 3.0
A validação estrutural é realizada pela classe DTDValidator. Esta classe
utiliza-se da classe NCLStructure para verificar se o documento está de acordo com a
estrutura da linguagem. Verificações como atributos válidos, obrigatórios, filhos válidos,
4.3 Implementação do Processo NCL Validator 3.0
32
obrigatórios e a ordem destes filhos são validadas por esta classe. A validação dos tipos
de dados também é feita por esta classe - utilizando a classe DataType.
A validação de contextos e referências é feita pelas subclasses de Semantics. A Semantics é responsável por fazer o parsing do elemento e chamar a função de
validação para cada constituinte do elemento - atributo, tagname, etc. Para cada elemento da linguagem existe uma classe associada. Esta classe é responsável por verificar a
existência dos elementos referenciados por estes elementos bem como se estes elementos
referenciados estão em contextos válidos e são de tipos válidos.
Visando unificar as mensagens de erros, provendo uma única interface de acesso
para o cliente, existem as classes Message e MessageList. A primeira representa uma
mensagem de erro individual, constituı́da por: a mensagem para o usuário, a localização
no arquivo e também qual o elemento XML no qual ocorre o erro. A segunda, por sua
vez, atua como um repositório de Messages. À medida que o processo de validação vai
evoluindo, novas mensagens vão sendo adicionadas neste repositório, possibilitando assim
que no final do processo de validação estas mensagens possam ser recuperadas pelo cliente.
É importante ainda salientar que as mensagens podem ser de dois tipos: mensagens de
erros ou de alertas (warnings).
Alternativamente, a implementação aqui apresentada também permite a escolha da lı́ngua na qual as mensagens serão mostradas. Atualmente existe suporte para o
Inglês e para o Português.
4.3.1
NCL Validator 3.0 - Front End
Como front-end, o NCL Validator 3.0 pode ser acessado através da linha de comando de
qualquer sistema operacional com a máquina virtual Java 1.6 ou superior instalada. A
sintaxe do comando é: java -jar ncl30-validator.jar pathDoArquivo lingua. Caso a lı́ngua
não seja especificada as mensagens serão por padrão apresentadas em inglês. A Figura
4.3 mostra o front-end do NCL Validator 3.0 sendo executado em um shell Linux.
4.3.2
Reutilização do NCL Validator 3.0
A implementação do NCL Validator 3.0 também pode ser reutilizada por outros softwares.
Com este objetivo foi disponibilizada uma API simples que permite chamar o processo de
4.3 Implementação do Processo NCL Validator 3.0
33
Figura 4.3: NCL Validator 3.0 sendo utilizado como front-end
validação (passando um arquivo) e recuperar as mensagens de erros no final no processo.
O exemplo de código da Figura 4.4 mostra como é possı́vel reutilizar o NCL Validator
3.0.
A classe NCLValidator possui um método estático validate. Este método recebe um vetor de NCLValidatorDocument e tem por função executar o processo NCL
Validator. À medida que erros são encontrados em cada um dos documentos passados
para o método validate as mensagens de erros vão sendo carregadas na classe MessageList. Ao final do processo de validação é possı́vel acessar as mensagens de erros através do
método estático getErrors da classe MessageList e os alertas através do método getWarnings. Cada um destes métodos retorna um vetor de Message.
É possı́vel também alterar a lı́ngua na qual as mensagens serão apresentadas
através do método setLanguage da classe MessageList. É importante salientar que este
método só tem efeito se utilizado antes do inı́cio do processo de validação.
A Figura 4.5 ilustra a implementação do NCL Validator sendo reutilizada pelo
Composer [Guimarães, Costa e Soares 2007]. O NCL Eclipse, apresentado nesta mono-
4.3 Implementação do Processo NCL Validator 3.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
34
p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
F i l e d o c F i l e = new F i l e ( ” t e s t e . n c l ” ) ;
Document doc = n u l l ;
MessageList . c l e a r ( ) ;
M e s s a g e L i s t . s e t L a n g u a g e ( M e s s a g e L i s t . ENGLISH ) ;
try {
DocumentBuilderFactory d b f = DocumentBuilderFactory . n e w I n s t a n c e ( ) ;
DocumentBuilder db = d b f . newDocumentBuilder ( ) ;
N c l P a r s e E r r o r H a n d l e r p = new N c l P a r s e E r r o r H a n d l e r ( ) ;
p . s e t F i l e ( docFile . getAbsolutePath ( ) ) ;
db . s e t E r r o r H a n d l e r ( p ) ;
doc = db . p a r s e ( d o c F i l e ) ;
V e c t o r <NclValidatorDocument> documents = new V e c t o r<NclValidatorDocument> ( ) ;
NclValidatorDocument n c l V a l i d a t o r D o c u m e n t = new NclValidatorDocument ( doc ) ;
documents . add ( n c l V a l i d a t o r D o c u m e n t ) ;
NCLValidator . v a l i d a t e ( documents ) ; // chama o p r o c e s s o de v a l i d a c a o
}
catch ( Exception e ) {
M e s s a g e L i s t . addError ( d o c F i l e . g e t A b s o l u t e P a t h ( ) , e . g e t M e s s a g e ( ) ,
n u l l , M e s s a g e L i s t . ENGLISH ) ;
}
V e c t o r <Message> w a r n i n g s = NCLValidator . getWarnings ( ) ; // r e c u p e r a a l i s t a de a l e r t a s
V e c t o r <Message> e r r o s = NCLValidator . g e t E r r o r s ( ) ;
// r e c u p e r a a l i s t a de E r r o s
}
Figura 4.4: Reutilizando o NCL Validator 3.0 - Exemplo de código
grafia, também reutiliza o NCL Validator. Esta integração será melhor discutida no
capı́tulo 6.
4.3 Implementação do Processo NCL Validator 3.0
Figura 4.5: NCL Validator sendo reutilizado pelo Composer
35
36
5 Ambiente Eclipse
Neste capı́tulo, o Ambiente Eclipse1 é apresentado. Os principais conceitos deste ambiente
serão discutidos e serão úteis a seguir, no desenvolvimento do NCL Eclipse.
”Para milhões de desenvolvedores, engenheiros e usuários de todo o mundo,
o Eclipse é uma plataforma extensı́vel para integração de ferramentas. Para centenas
de vendedores comerciais que usam o Eclipse para desenvolver plug-ins ou ferramentas
de plataformas completas, o Eclipse representa uma provada, rendável e escalável tecnologia para produtos comerciais que podem ser facilmente projetados, desenvolvidos e
construı́dos.
Para milhares de estudantes e pesquisadores, o Eclipse representa uma plataforma estável para inovação, liberdade e experimentação. Para todos estes indivı́duos,
grupos e organizações o Eclipse é uma plataforma de padronização neutra para integrar
ferramentas suportadas por um diverso Ecossistema Eclipse.”[Clayberg e Rubel 2004]
5.1
5.1.1
Conceitos básicos no Ambiente Eclipse
Perspectivas, Visões e Editores
Para prover uma melhor organização do ambiente de desenvolvimento, o Eclipse é divido em unidades. Uma perspectiva é um conjunto de visões e de editores. Visões
são geralmente usadas para navegar em arquivos e mudar suas propriedades. De forma
contrária, um editor é utilizado para alterar o conteúdo de um arquivo especı́fico. A Figura 5.1 mostra um exemplo da Perspectiva Java, na qual é possı́vel identificar 1 como
sendo Visão e 2 como sendo Editor.
As visões Problems e Outline são padrões do ambiente Eclipse e serão utilizadas
no desenvolvimento do NCL Eclipse.
1
O site principal do Eclipse é http://www.eclipse.org. No momento da escrita deste trabalho versão
disponibilizada no site é a 3.3, sendo que no decorrer do presente trabalho esta será a versão utilizada.
O processo de instalação é simples, basta descompactar o arquivo baixado através do site.
5.1 Conceitos básicos no Ambiente Eclipse
37
Figura 5.1: Java Perspective - identificação de algumas visões e do editor Java.
São exemplos de perspectivas padrões já instaladas no Eclipse: Resource Perspective, Java Perspective, Debug Perspective e CVS Perspective. São exemplos de Visões:
Navigator, Outline e Tasks.
Adicionalmente aos Editores e às Visões, o Eclipse também provê outras áreas
de visualização entre as quais estão um grande número de menus e barras de ferramentas
que representam os vários comandos e ações disponı́veis no sistema. A figura 5.2 mostra
o menu do topo, juntamente com a barra de ferramentas; a figura 5.3 mostra exemplos de
menus contextuais que podem ser visualizados clicando-se com o botão direito em algum
editor e/ou visão.
Figura 5.2: Java Perspective - Menu do topo e barra de ferramentas
5.2 Visão geral da arquitetura do Eclipse
38
Figura 5.3: Java Perspective - exemplos de menus contextuais
5.2
Visão geral da arquitetura do Eclipse
A plataforma Eclipse é estruturada através do conceito de plug-ins. Plug-ins são pacotes
de código e/ou dados estruturados que contribuem funcionalmente para o sistema e podem
ser distribuı́dos separadamente. As funções exercidas pelos plug-ins podem estar na forma
de biblioteca de códigos (classes Java com API pública), extensões da plataforma, ou até
mesmo documentação.
Do ponto de vista do usuário, são os plug-ins que determinam a funcionalidade final da plataforma. O Eclipse provê um Workbench comum onde são ‘plugados‘
os plug-ins. Isto é feito usando ‘portas’ bem definididas chamadas pontos de extensão
(extension points). A construção do Eclipse é feita em camadas de plug-ins de tal forma
que cada plug-in, ele mesmo, possa definir pontos de extensão, permitindo assim que o
mesmo possa ser customizado por outro desenvolvedor. Este modelo de extensão permite
que desenvolvedores de plug-ins adicionem uma grande variedade de funcionalidades à
plataforma básica.
A Figura 5.4 ilustra a arquitetura do Eclipse, onde é possı́vel destacar o núcleo
runtime e os subsistemas básicos da arquitetura. Cada subsistema é estruturado como
um conjunto de plug-ins que implementam algumas funções chaves. Alguns plug-ins
5.2 Visão geral da arquitetura do Eclipse
39
adicionam caracterı́sticas visı́veis para a plataforma, utilizando o modelo de extensão.
Outros adicionam bibliotecas de classes que podem ser usados para implementar extensões
do sistema.
Figura 5.4: Arquitetura do ambiente Eclipse. Fonte: [Eclipse Foundation 2008]
Eclipse SDK (Standard Development Kit) inclui a plataforma básica mais duas
ferramentas úteis para o desenvolvimento de plug-ins. A Java Development Tool implementa um completo ambiente de desenvolvimento Java. O Plug-in Development Enviroment adiciona ferramentas especializadas que racionalizam o desenvolvimento de plug-ins
e extensões. Estas ferramentas não apenas possuem um objetivo útil, como também
provêem um bom exemplo de como novas ferramentas podem ser adicionadas à plataforma através da construçao de plug-ins que estendem o sistema.
5.2.1
Infra-estrutura dos Plug-ins
Os plug-ins são codificados em Java. Um plug-in tı́pico consiste de códigos Java em
uma biblioteca JAR, juntamente com arquivos como imagens, templates, catálogos de
messagens, etc. Cada plug-in tem um arquivo manifest que especifica sua interconexão
com outros plug-ins. No seu manifest um plug-in declara seus pontos de extensão e quais
pontos de extensão de outros plug-ins ele customiza.
5.2 Visão geral da arquitetura do Eclipse
40
Ao ser carregada, a Plataforma Runtime descobre o conjunto de plug-ins disponı́veis, lê os seus arquivos manifest e constrói, na memória, uma estrutura com estas
informações. Qualquer problema, tais como extensões faltando, são detectados e escritos
no log do sistema. Os plug-ins não podem ser adicionados depois da plataforma carregada. Assim, ao instalar um plug-in é necessário que a plataforma seja recarregada para
que o mesmo entre em funcionamento.
Um plug-in é ativado, na realidade, quando o seu código necessita executar.
Uma vez ativado, um plug-in utiliza-se do seu registro feito em memória pela Plataforma
Runtime para descobrir e acessar os pontos de extensão que este estende. Depois de
ativado, um plug-in permanece ativo até que a plataforma seja encerrada. Existe uma
API reduzida que pode ser utilizada para explicitamente carregar um plug-in, o que pode
ser útil em alguns casos.
A cada plug-in é atribuı́do seu próprio carregador de classes Java que é unicamente responsável por carregar as classes e arquivos deste plug-in. Cada plug-in declara
explicitamente suas dependências de outros plug-ins dos quais ele espera acessar diretamente as classes. Um plug-in controla a visibilidade para o público de suas classes e
interfaces em sua biblioteca. Estas informações são declaradas no arquivo manifest do
plug-in. As regras de visibilidade são executadas em tempo de execução pelo carregador
de classes do plug-in.
5.2.2
SWT
O SWT[Eclipse Foundation 2008] (Standard Widgets Toolkit) é um componente de software que proporciona widgets avançados, nativos e independentes de plataforma para a
plataforma Eclipse. O SWT é análogo ao AWT[Zukowski 1997]/Swing[Loy et al. 2002],
com a diferença que usa um conjunto de widgets nativos. Além de ser usado integrado
com a plataforma Eclipse é possı́vel também usar o SWT em qualquer programa Java.
Para isto basta baixar a biblioteca no site do projeto. Um pouco da história do SWT em
comparação com o AWT e Swing podem ser encontrados em [Clayberg e Rubel 2004].
O SWT é escrito totalmente em Java e mesmo assim é nativo (diferentemente
do Swing onde ele mesmo desenha a interface). Para mostrar os elementos da interface,
o SWT implementa acesso a bibliotecas nativas do sistema operacional utilizando JNI
(Java Native Interface) [Sun Microsystems 2008] em uma forma similar àquela feita por
5.2 Visão geral da arquitetura do Eclipse
41
programa escritos usando APIs especı́ficas do sistema operacional. JNI é o mecanismo
padrão usado por todos os programas Java para invocar códigos escritos em C. O SWT,
entretanto, vai um passo mais longe ao impor um mapeamento um-para-um entre métodos
Java nativos e chamadas ao sistema operacional. Este fato permite que o programador
possa fazer chamadas ao sistema operacional a partir de métodos Java ao mesmo tempo
que pode utilizar os widgets avançados do SWT, tais como Browser (mostra páginas
HTML), Shell, StyledText, Toolbar, Tray, etc.
Na Figura 5.4 é possı́vel identificar como o SWT está na base da infra-estrutura
do Eclipse. Ao fazer plug-ins para o Eclipse, também é comum a criação de componentes
utilizando-se os widgets SWT.
5.2.3
JFace
O SWT ao possibilitar uma interface direta aos widgets nativos é limitado à utilização de
tipos de dados simples - strings, números, imagens, etc. Isto é crı́tico principalmente para
programadores do paradigma de Orientação a Objetos (OO) que necessitam apresentar
widgets utilizando estruturas de dados como listas, tabelas, árvores e textos. O JFace
é uma camada de abstração no topo do SWT que provê ‘OO wrappers’ sobres os seus
widgets associados. O JFace inclui os componentes usuais de interface com o usuário
(imagens, fontes, preferências, janelas de diálogo, etc.).
Duas das caracterı́sticas mais interessantes do JFace são as ações (actions)e os
visualizadores (viewers). O mecanismo de tratamento de ações permite que os comandos
do usuário sejam definidos independentemente do local exato onde a interface irá executálo. Uma ação representa um comando que pode ser desencadeado por um usuário via um
botão, um item de menu ou um item em uma barra de ferramentas. Cada ação conhece as
propriedades chaves do componente da interface (label, icon, tool tip) que são usados para
construir widgets apropriados para a ação atual. Esta separação permite que a mesma
ação seja usada em vários lugares na UI.
Os Visualizadores são adaptadores baseados em modelos para certos widgets
SWT. Os Visualizadores controlam os comportamentos comuns e provêem uma semântica
de mais alto nı́vel do que os widgets SWT. Existem visualizadores padrões para listas,
árvores e tabelas. Estes visualizadores são configurados com um provedor de conteúdo
(content provider ) e um provedor de nomes (label provider ). O content provider sabe como
5.2 Visão geral da arquitetura do Eclipse
42
mapear o elemento da entrada do visualizador para o elemento esperado pelo visualizador
de conteúdo. O label provider sabe como produzir o texto especı́fico que aparecerá na
interface (label ) e o ı́cone necessário para mostrar um determinado elemento no widget.
É possı́vel também configurar os visualizadores com filtros e ordenadores baseados em
elementos. Os clientes são notificados quando ocorrem eventos (seleção, clique duplo, etc.).
Os visualizadores padrões para texto suportam operações comuns como comportamento
de clique duplo, voltar (undo), coloração e navegação pelo ı́ndice do caracter ou número
de linha. Os visualizadores de texto provêem um modelo de documento para o cliente e
administram a conversão do documento para a informação requerida pelo widget de texto
SWT. Múltiplos visualizadores podem ser abertos no mesmo modelo ou documento; todos
são atualizados automaticamente quando o modelo ou documento é alterado em qualquer
um deles.
5.2.4
Actions
Uma Ação no Eclipse é composta de várias partes, incluindo a declaração XML no arquivo
manifest do plug-in, o objeto IAction instanciado pelo Eclipse UI para representar a ação,
e o IActionDelegate definido na biblioteca do plug-in e contendo o executor da ação. Esta
separação permite que o Eclipse represente a mesma ação em um menu, ou uma barra de
ferramentas sem necessariamente carregar o plug-in que contém a ação.
5.2.5
Workspace
Os vários plug-ins da plataforma Eclipse operam sobre arquivos na área de trabalho
(workspace) do usuário. O workspace consiste de um ou mais nı́veis de projetos, onde
cada projeto mapeia um diretório correspondente, especificado pelo usuário no sistema
de arquivos. Os diferentes projetos no workspace podem mapear diferentes diretórios ou
drivers. Todos os arquivos no workspace são acessados diretamente pelos programas e
ferramentas padrões do sistema operacional subjacente. Ferramentas integradas com a
plataforma utilizam-se de uma API para manusear os recursos do workspace (a coleção
de projetos, arquivos e pastas). Recursos do workspace são representados por objetos
adaptáveis, possibilitando, assim, a extensão de seu comportamento.
5.3 Criação de plug-ins para o Eclipse
5.2.6
43
Workbench
Diferentemente do SWT e do JFace, os quais são toolkits de interface gráfica para propósitos
gerais, o workbench provê os componentes de interface com o usuário personalizados para
a plataforma Eclipse e fornece a estrutura na qual as ferramentas interagem com o usuário.
Devido à este papel central, o workbench é sinônimo da interface com o usuário da plataforma Eclipse. A API do workbench é dependente tanto do SWT quanto do JFace; Java
AWT e Swing não são usados.
A interface com o usuário da plataforma Eclipse é baseada em editores, visões e
perspectivas (Veja subseção 5.1.1). Do ponto de vista do usuário uma janela do workbench
consiste visualmente de visões e editores. As perspectivas mostram uma seleção e um
arranjo de editores e visões dispostos na tela. Uma janela do workbench pode possuir
várias perspectivas separadas, das quais apenas uma é visı́vel em um dado momento.
5.3
Criação de plug-ins para o Eclipse
A JDT (Java Development Toolkit) e o PDE (Plug-in Development Environment), juntos,
constituem um ambiente completo para a criação de novos plug-ins para a IDE Eclipse.
A JDT e o PDT vêm por padrão na SDK do Eclipse.
A JDT é um conjunto de plug-ins que adicionam funcionalidades que auxiliam
o desenvolvimento utilizando a linguagem Java à plataforma Eclipse. Os plug-ins JDT
provêem APIs que também podem ser reutilizadas por outros desenvolvedores. Os plug-ins
JDT são dividos em:
• JDT APT: adiciona o suporte à anotação para projetos Java 5 no Eclipse.
• JDT Core: define uma infra-estrutura não relacionada com a interface com o
usuário, incluindo: Java Builder, assistente de código, etc.
• JDT Debug: implementa o suporte à Debug para Java.
• JDT Text: provê o editor Java.
• JDT UI: implementa contribuições ”visuais”para o workbench, tais como: Package Explorer, Type Hierarchy View, Java Outline View, Wizards para a criação de
elementos Java.
5.4 Um Exemplo: Java Perspective
44
O PDE disponibiliza um conjunto de ferramentas que auxiliam o desenvolvedor
em cada estágio do desenvolvimento de plug-ins. O PDE provê wizards para a criação
de projetos de plug-ins (Figuras 5.5), editores para os arquivos manifest e plugin.xml
que permitem gerenciar as dependências (Figura 5.6), pontos de extensões (Figura 5.7) e
visibilidade do código definido pelo plug-in.
Figura 5.5: PDE - wizard para a criação de plug-ins
Figura 5.6: PDE - gerenciamento de dependências
5.4
Um Exemplo: Java Perspective
Nesta subseção será apresentada a perspectiva Java padrão do Eclipse. O objetivo é
identificar algumas caracterı́sticas desejáveis para o projeto aqui em questão.
5.4 Um Exemplo: Java Perspective
45
Figura 5.7: PDE - gerenciamento de pontos de extensão
5.4.1
Criando um projeto -New Project Wizard
Criar um novo projeto no Eclipse é muito simples, para cada tipo de projeto suportado
pela plataforma existe um wizard que auxilia o usuário a criar este tipo de projeto. Para
criar um novo projeto Java, por exemplo, basta selecionar F ile > N ew > P roject.
Ao criar um novo projeto no Eclipse é criado um arquivo .project no diretório raiz do
projeto (especificado no wizard ). O arquivo .project é um arquivo XML que descreve as
caracterı́stica do projeto ao qual se refere, o que permite recriá-lo no workbench. O código
da Figura 5.8 mostra o exemplo de um arquivo .project. O wizard Java também cria um
arquivo .classpath que traz informações relativas aos paths dos sources e dos outputs.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?xml version=” 1 . 0 ” e n c o d i n g=”UTF−8” ?>
<p r o j e c t D e s c r i p t i o n>
<name>xml</name>
<comment></comment>
<p r o j e c t s>
</ p r o j e c t s>
<b u i l d S p e c>
<buildCommand>
<name>o r g . e c l i p s e . j d t . c o r e . j a v a b u i l d e r</name>
<arguments>
</ arguments>
</buildCommand>
</ b u i l d S p e c>
<n a t u r e s>
<n a t u r e>o r g . e c l i p s e . j d t . c o r e . j a v a n a t u r e</ n a t u r e>
</ n a t u r e s>
</ p r o j e c t D e s c r i p t i o n>
Figura 5.8: Exemplo de um arquivo .project
No arquivo .project são especı́ficadas caracterı́sticas, tais como, qual o comando
para construir o projeto (tag buildCommand ), que tipo de projeto é este (tag nature), o
nome do projeto (tag name) e a quais projetos este pode referenciar (tag projects).
5.4 Um Exemplo: Java Perspective
5.4.2
46
Editor Java
O Editor Java (Figura 5.9)é uma ferramenta moderna para a criação de classes Java em
modo texto que provê muitas caracterı́sticas voltadas ao trabalho de editar código. São
exemplos destas caracterı́sticas:
• Coloração de palavras reservadas;
• Assistência de código sensı́vel ao contexto;
• Templates;
• Formatação automática de código definida pelo usuário;
• Execução de um documento NCL.
A coloração de palavras reservadas ajuda o usuário a se situar no código Java
e é configurável através do menu Java > Editor > Syntax. Caracterı́sticas como cor
e estilo de fonte das palavras reservadas, comentários, strings, caracteres, etc podem ser
configurados através deste menu.
A assistência de código sensı́vel ao contexto - autocomplete - é uma das caracterı́sticas que mais ajudam ao usuário no momento da edição de código. O autocomplete
do editor Java pode ser acionado através de Ctrl + Espaço. A figura 5.9 mostra como o
autocomplete aparece na tela. Caso existam mais de uma opção para completar o texto
que se está editando um menu é mostrado para o usuário para que este possa escolher a
opção certa, caso exista apenas uma opção esta opção aparece no texto. Além do autocomplete convencional, o editor Java também define templates que podem ser adicionados
ao código.
Estas duas caracterı́sticas (muito úteis) foram identificados no editor Java e
serão implementadas no NCL Eclipse, conforme será visto no capı́tulo 6.
5.4 Um Exemplo: Java Perspective
Figura 5.9: Editor Java - evidenciando autocomplete.
47
48
6 NCL Eclipse
Este trabalho tem como principal objetivo implementar um plug-in textual para a IDE
Eclipse visando auxiliar no desenvolvimento de apresentações interativas em NCL. Para
tanto, inicialmente foi realizado um estudo básico da linguagem NCL (Capı́tulo 3). Posteriormente, e não com o intuito restrito de servir apenas para este plug-in foi desenvolvido
o NCL Validator, um software que tem como objetivo validar se um documento está ou
não conforme a norma NCL (Capı́tulo 4). Seguindo neste objetivo, foi então realizado
um estudo aprofundado da IDE Eclipse, sempre ressaltando os pontos que poderiam ser
aproveitados para a implementação do plug-in e como seria possı́vel a integração deste
plug-in com o ambiente Eclipse (Capı́tulo 5). Enfim, o plug-in foi desenvolvido. Este
capı́tulo traz as caracterı́sticas desenvolvidas bem como os principais pontos do código e
uma discussão sobre a relevância de cada uma das funcionalidades.
6.1
Levantamento de Requisitos
Os requisitos básicos do NCL Eclipse são os comumente encontrados em ambientes de
desenvolvimentos para linguagens textuais. As seguintes funcionalidades básicas devem
estar presentes no NCL Eclipse:
1. Gravar o documento em disco – Salvar
2. Voltar alterações (undo) – disponı́vel através de Ctrl+z
3. Coloração Sintática
4. Auto-formatação de código
5. Validação do código-fonte
6. Rodar em sistemas operacionais diferentes - ser multiplataforma
7. Sugestão de código contextual
8. Navegação no documento como uma árvore
6.2 Funcionalidades Implementadas
49
9. Colapsar elementos XML – Folding
6.2
Funcionalidades Implementadas
Com base nos requisitos básicos da seção anterior, foram implementados as seguintes
funcionalidades no NCL Eclipse:
• Gravar o documento em disco – Disponı́vel pelo Eclipse – requisito 1.
• Voltar alterações – Disponı́vel pelo Eclipse – requisito 2.
• Coloração de tags e atributos XML – requisito 3.
• Auto-formatação do código XML – requisito 4.
• Validação do documento NCL – requisito 5.
• Auto-completação contextual de código NCL – requisito 7.
• Navegação no documento como uma árvore – requisito 8.
• Executar o documento NCL – Não estava nos requisitos
O Requisito 6 – Rodar em sistemas operacionais diferentes – é automaticamente suprido pelo ambiente Eclipse que já é um ambiente multiplataforma.
As seções seguintes discutirão cada uma destas funcionalidades implementadas,
qual a sua relevância e, sempre que possı́vel, uma discussão sobre como se deu esta
implementação no Eclipse.
6.3
Infra-estrutura
A Figura 6.1 demonstra, estruturalmente, como o NCL Eclipse interage com a plataforma
Eclipse. As dependências do NCL Eclipse são:
• org.eclipse.core.runtime
• org.eclipse.core.resources
6.3 Infra-estrutura
50
• org.eclipse.ui
• org.eclipse.ui.workbench.texteditor
• org.eclipse.ui.editors
• org.eclipse.ui.ide
• org.eclipse.ui.views
• org.eclipse.jface.text
Figura 6.1: Diagrama do NCL Eclipse interligado com o Eclipse
Dentre os pontos de extensão, destaca-se o org.eclipse.jface.text que permite
a customização de editores de texto no ambiente Eclipse. Este é o principal ponto de
extensão reutilizado pelo NCL Eclipse.
O apêndice A mostra os principais diagramas de classes do NCL Eclipse.
6.4 Funcionamento do NCL Eclipse
6.4
6.4.1
51
Funcionamento do NCL Eclipse
NCL Wizard e Connector Base Wizard
Um wizard, no Eclipse, é um passo-a-passo que auxilia o usuário na realização de uma
tarefa. É comum sua utilização para a criação de novos projetos ou de novos documentos.
Os wizards são organizados em categorias. Sendo que tanto as categorias como eles
próprios são definidos pelos plug-ins que fazem parte do ambiente.
O NCL Eclipse provê dois wizards padrões classificados na categoria NCL.
Um para a criação de um documento NCL básico e outro para a criação de uma base
de conectores que deve ser reutilizada por outros documentos. O NCL Document cria
um novo documento NCL - com a tag < ncl > e seus filhos < head > e < body >.
O Connector Base Document tem a mesma funcionalidade do anterior com a diferença
de não criar o elemento < body >. A figura 6.2 mostra como acessar o NCL Document
Wizard e a Figura 6.3 mostra o NCL Document Wizard.
Figura 6.2: Criação de um novo documento NCL
6.4 Funcionamento do NCL Eclipse
52
Figura 6.3: Criação de um novo documento NCL
Curiosidades da Implementação
Para que um plug-in possa adicionar um novo wizard à plataforma é necessário a customização do ponto de extensão org.eclipse.ui.newWizards. Através do arquivo plugin.xml é
possı́vel definir novas categorias bem como novos wizards. O trecho do arquivo plugin.xml
da Figura 6.4, mostra como o NCL Eclipse define a categoria NCL e os wizards NCL
Document e Connector Base Document. As classes NCLNewWizard e ConnectorBaseNewWizard estendem a classe org.eclipse.jface.wizard.Wizard e implementam a interface
org.eclipse.ui.INewWizard, customizando apenas as caracterı́sticas que são especı́ficas do
NCL Eclipse.
6.4.2
Coloração sintática
A coloração sintática é útil na medida em que auxilia o autor a se situar no texto. Ela
é uma caracterı́stica básica da maioria dos editores de texto voltados para a criação de
arquivos-fonte. Como a linguagem NCL é baseada em XML, a coloração sintática do NCL
6.4 Funcionamento do NCL Eclipse
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
53
<p l u g i n>
...
<e x t e n s i o n
p o i n t=” o r g . e c l i p s e . u i . newWizards ”>
<c a t e g o r y
i d=” n c l e c l i p s e ”
name=”NCL”>
</ c a t e g o r y>
<w i z a r d
c a t e g o r y=” n c l e c l i p s e ”
c l a s s=” br . ufma . d e i n f . l a w s . n c l e c l i p s e . w i z a r d s . NCLNewWizard”
i c o n=” i c o n s / sample . g i f ”
i d=” n c l e c l i p s e . w i z a r d s . NCLNewWizard”
name=”NCL Document”>
</ w i z a r d>
<w i z a r d
c a t e g o r y=” n c l e c l i p s e ”
c l a s s=” br . ufma . d e i n f . l a w s . n c l e c l i p s e . w i z a r d s . ConnectorBaseNewWizard ”
i c o n=” i c o n s / sample . g i f ”
i d=” n c l e c l i p s e . w i z a r d s . ConnectorBaseNewWizard ”
name=” Connector Base Document”>
</ w i z a r d>
</ e x t e n s i o n>
...
</ p l u g i n>
Figura 6.4: Fragmento do plugin.xml que define os wizards
Eclipse foi desenvolvida para diferenciar as tags XML, atributos e os valores dos atributos,
bem como alguns conteúdos textuais e comentários. Por padrão, as tags XML aparecem
na cor azul, os valores dos atributos na cor verde e os comentários na cor vermelha.
A coloração sintática disponibilizada por um editor de texto do JFace é feita
através da divisão do documento em um conjunto de tokens, cada um descrevendo uma
seção do documento que tem cor do texto (foreground ), cor de fundo (background ) e
estilo de fonte diferentes. Esta divisão é feita por um presentation reconciler. Isto é muito
similar ao particionamento de documento – que será discutido na subseção 6.4.5 – com a
diferença de que o presentation reconciler permite um controle mais fino do que a partição
de documento. Através do presentation reconciler é possı́vel, por exemplo, modificar as
cores de cada uma das palavras reservadas da linguagem.
6.4.3
Outline view
A visão outline é a visão padrão do Eclipse para apresentar a estrutura do documento
que está sendo editado atualmente. A JDT, por exemplo, mostra as classes, atributos
e métodos do arquivo que está sendo editado. O NCL Eclipse também utiliza a visão
outline para mostrar a estrutura do documento NCL.
Um documento XML pode ser representado como uma árvore. Esta representação permite navegar mais facilmente sobre o documento. Visando aproveitar-se
dessa caracterı́stica de documentos XML, o Outline view desenvolvido pelo NCL Eclipse
6.4 Funcionamento do NCL Eclipse
54
representa o documento NCL como uma árvore, permitindo assim navegar sobre o documento. O evento de clicar sobre um nó da árvore leva o editor a selecionar a linha daquele
nó. Veja a Figura 6.5.
A visão outline estende a visão padrão do Eclipse. Caso a mesma não esteja
ativa é possı́vel ativá-la através do menu Window > Show View > Other... > General >
Outline. Cada vez que o documento é salvo a visão Outline é atualizada.
Figura 6.5: Coloração sintática e Outline View
Curiosidades da Implementação
Para que um plug-in possa customizar a visão outline é necessário que este estenda a
classe org.eclipse.ui.views.contentoutline.ContentOutlinePage. Dois métodos, em especial,
merecem destaque e foram reimplementados pelo NCL Eclipse: createControl – instancia
a TreeViewer, bem como adiciona os Listeners – e selectionChanged – no caso do NCL
Eclipse, seleciona a linha na qual este elemento está definido. Além destes método, foi
adicionado também o update – que atualiza a árvore da visão outline quando o documento
é gravado no disco.
6.4 Funcionamento do NCL Eclipse
6.4.4
55
Folding
Colapsar partes de um código é uma caracterı́stica presente em muitos editores de texto –
usualmente chamada de folding – que torna o trabalho de ler e entender este código mais
fácil. Esta caracterı́stica permite esconder a parte do código em que não se está interessados no momento, mostrando assim apenas o que é mais importante naquele contexto.
O NCL Eclipse implementa o folding baseado nas tags XML. Ou seja, é possı́vel
esconder um elemento, juntamente com todos os seus filhos. A figura 6.6 evidencia esta
caracterı́stica do NCL Eclipse.
Figura 6.6: Colapsar (Folding)
6.4.5
Autocomplete
A sugestão automática de texto - autocomplete - baseada em contexto é uma caracterı́stica
presente em muitos editores e processadores de texto, bem como navegadores web. O
autocomplete envolve o processo do programa predizer uma palavra ou frase que o usuário
quer inserir no texto sem que este usuário precise digitá-la por inteiro. Em editores de
6.4 Funcionamento do NCL Eclipse
56
texto especı́ficos para linguagens de programação esta caracterı́stica é extremamente útil,
pois diminui bastante o tempo necessário para a programação, ajudando o usuário a
sempre criar um documento correto e a digitar menos do que o que seria necessário sem
esta funcionalidade.
O NCL Eclipse implementa o autocomplete baseado no perfil Enhanced Digital
Television da linguagem NCL, disponı́vel através de Ctrl+Espaço. Três cenários principais
foram analisados: a sugestão de tags, a sugestão de atributos de uma determinada tag e
a sugestão de valores dos atributos de uma tag. Para poder implementar separadamente
cada um destes cenários, o particionamento do documento, disponibilizado pelo JFace
text editor, foi extremamente útil.
Através da API do Eclipse é possı́vel definir regras de particionamento do
documento e tratar cada uma destas partições de forma totalmente independente. É
possı́vel, por exemplo, definir coloração sintática, formatação, bem como sugestão de
texto diferentes para cada uma destas partições. No NCL Eclipse foram definidas algumas
partições úteis para documentos XML. A figura 6.7 apresenta as principais partições do
XML definida pelo NCL Eclipse.
Figura 6.7: Principais partições do XML definidas pelo NCL Eclipse
A sugestão de tags baseia-se na estrutura da linguagem e na posição atual na
qual o cursor está posicionado. Sendo assim, quando estamos com o cursor entre uma
partição de start tag <ncl> e uma de end tag < /ncl>, o NCL Eclipse sugere as tags que
6.4 Funcionamento do NCL Eclipse
57
são filhas de <ncl> (<body> e <head>). Isto acontece para todas as tags da linguagem.
Para as tags que possuem atributos obrigatórios, estes atributos também são incluı́dos no
texto quando a mesma é inserida pelo autocomplete.
O segundo cenário, que se refere aos atributos de uma determinada tag, está
relacionado exclusivamente a uma partição de start tag. Ao ativar o autocomplete dentro
de uma partição de start tag que já possui o nome de uma tag definida, o autocomplete,
baseado neste nome, sugere ao usuário os valores possı́veis de atributos desta tag. Caso
um atributo já tenha sido preenchido o mesmo não é sugerido novamente.
No terceiro cenário, onde o usuário está digitando o valor de um atributo,
existem duas possibilidades principais. Na primeira, os valores dos atributos são prédefinidos pela linguagem – é o que acontece, por exemplo, com o atributo operator do
elemento <compoundAction> que só pode assumir os valores par ou seq. E, na segunda,
os valores são referência a outros nós definidos pelo próprio usuário no documento (ou
em outro importado) – podem-se citar como exemplos o atributo xconnector do elemento
<link> que deve ser o valor de um identificador de um conector definido através do
elemento <causalConnector>. As Figuras 6.8 e 6.9 mostram exemplos deste terceiro
cenário.
Na Figura 6.8, o usuário está digitando o papel que um nó vai exercer em um
elo. Este elo é do tipo onBegin1StatN, – o qual está especificado na base de connectores
(connBase) – conforme definido pelo atributo xconnector. Este tipo de atributo, que na
verdade é um conector definido na base de connectores, tem como papéis possı́veis onBegin
e start. O NCL Eclipse faz o parsing do documento, encontra a definição do connector e
sugere os papéis possı́veis para este conector.
Na Figura 6.9, os valores possı́veis para o atributo descriptor do elemento media são os identificadores dos elementos descriptor, definidos na base de descritores. Da
mesma forma que o anterior, quando o usuário está digitando o valor do atributo descriptor, NCL Eclipse faz o parsing do documento e descobre quais os descritores definidos
pelo usuário e sugere seus identificadores.
Quando o valor é pré-definido pela linguagem a lista dos valores possı́veis é
mostrada. Já quando o valor deve ser uma referência a outro nó definido pelo próprio
usuário o parsing do documento é realizado em tempo de execução para saber quais os
valores possı́veis.
6.4 Funcionamento do NCL Eclipse
Figura 6.8: Autocomplete
Figura 6.9: Autocomplete – sugestão de referências
58
6.4 Funcionamento do NCL Eclipse
59
Outros problemas, tais como o tipo do atributo sugerido deve ser do tipo
que aquele atributo aceita e o contexto no qual os elementos estão, também influem nas
sugestões dadas pelo NCL Eclipse. Estes dois pontos estão implementados no NCL Eclipse
e são vistos como diferencial desta ferramenta em relação a outras existentes.
6.4.6
Integração NCL Eclipse e NCL Validator
Uma das caracterı́sticas mais úteis que os ambientes de desenvolvimento baseados em linguagem de programação disponibilizam para os seus usuários é a identificação e marcação
de erros no momento da autoria dos arquivos-fonte. Esta é uma funcionalidade disponı́vel
na maioria das IDEs existentes no mercado e ajuda a diminuir o tempo de autoria, visto
que diminui a necessidade de executar o documento para evidenciar que o mesmo possui
erros sintáticos e/ou semânticos.
Como foi visto no capı́tulo 4, o NCL Validator foi desenvolvido com o objetivo
de identificar erros em documentos NCL e retornar uma lista de mensagens ao usuário.
Outro objetivo do NCL Validator é ser reutilizado por outras ferramentas (como as de
autoria ou os formatadores). O NCL Eclipse, assim, reutiliza o NCL Validator para
identificar e marcar erros em documentos NCL. A reutilização do NCL Validator dá-se
como visto na subseção 4.3.2.
A Figura 6.10 mostra como o NCL Eclipse apresenta os erros gerados pelo
NCL Validator. A marcação de erros no próprio documento (o sublinhado sob a posição
do erro) também é suportado pelo NCL Eclipse.
6.4.7
Execução de um documento NCL - Integração NCL Eclipse
e Ginga Emulator
Além de tornar possı́vel a construção de documentos NCL de forma textual, com as
funcionalidades discutidas acima, através do NCL Eclipse, também é possı́vel executar o
documento NCL. Veja a Figura 6.11.
A execução do documento é feita através do Ginga NCL Emulator que está
disponı́vel como software público em [Governo do Brasil 2008]. O NCL Eclipse utilizase do ponto de extensão org.eclipse.debug.ui.launchShortcuts da plataforma Eclipse para
disponibilizar a execução através do menu contextual Run as > NCL Presentation.
6.4 Funcionamento do NCL Eclipse
60
Figura 6.10: Marcação de erros
A ferramenta NCL Eclipse, portanto, traz várias funcionalidades que auxiliam
o processo de criação de apresentações interativas em NCL. Estas funcionalidades tornam
a autoria mais prática e rápida. Ao ser implementado sobre o ambiente Eclipse é também
possı́vel que o autor utilize-se de outros plug-ins que podem auxiliá-lo, como plug-ins para
controle de versão, comparação de arquivos e mesmo plug-ins voltadas para linguagens
procedurais como o JDT e o LuaEclipse [PUC-Rio 2008] – um conjunto de plug-ins para
a criação de scripts Lua.
6.4 Funcionamento do NCL Eclipse
Figura 6.11: Execução de um documento NCL
61
62
7 Considerações Finais
Este trabalho teve como objetivo principal a criação de um editor textual que auxilie o desenvolvimento de programas interativos em NCL. Este editor foi desenvolvido na forma de
um plug-in para Eclipse, visando reutilizar todo este ambiente já bem conhecido por muitos programadores, e outros plug-ins que também podem ser úteis para o desenvolvimento
de aplicações para a TV Digital Brasileira (como é o caso do LuaEclipse [PUC-Rio 2008].
Algumas caracterı́sticas comuns em IDEs, como coloração sintática, folding,
auto-formatação, identificação e marcação de erros, sugestão de conteúdo baseado no
contexto (autocomplete) e execução do documento, foram implementadas neste plug-in.
Tornando-o assim, um ambiente completo para o desenvolvimento de programas em NCL.
O aprendizado da linguagem NCL também é favorecido com a utilização da ferramenta,
permitindo assim que apenas com Ctrl+Espaço, seja possı́vel, por exemplo, descobrir os
filhos de uma determinada tag ou os valores possı́veis de um determinado atributo da
linguagem.
Como forma de avaliar o NCL Eclipse e conhecer a sua receptividade pelo
público-alvo (conhecedores da linguagem NCL) está sendo realizada uma pesquisa qualitativa com alguns membros selecionados na comunidade Ginga NCL [Governo do Brasil 2008].
Infelizmente, a pesquisa ainda não teve resultados conclusivos, por isso não está sendo
apresentada aqui.
Como crı́tica à ferramenta é evidenciado o fato de que esta não traz funcionalidades que poderiam auxiliar outros públicos (leigos em NCL), principalmente os
produtores de conteúdo, que são mais próximos de ferramentas WYSIWYG. Este é deixado como um trabalho futuro. O autocomplete baseado nos perfis da linguagem NCL,
também é deixado como trabalho futuro – atualmente o perfil Enhanced Digital Television
é o suportado.
Em breve, o NCL Eclipse será disponibilizado como software livre na comunidade Ginga NCL, o que permitirá que os membros desta comunidade também adicionem
novas funcionalidades à ferramenta e a utilizem livremente. Esta é mais uma contribuição
da Universidade Federal do Maranhão a esta comunidade – a primeira contribuição foi o
7 Considerações Finais
63
NCL Validator (Capı́tulo 4), reutilizado pelo Composer [Guimarães, Costa e Soares 2007]
que inclusive foi a primeira contribuição pública a comunidade Ginga.
Referências Bibliográficas
[ABNT 2007]ABNT. Televisão Digital Terrestre - Codificação de dados e especificações
de transmissão para radiodifusão digital. [S.l.], 2007.
[Apache Software Foundation 2002]Apache Software Foundation. Xerces Java Parser.
2002. Http://xerces.apache.org/xerces-j/.
[Bulterman et al. 1998]BULTERMAN, D. C. A. et al. Grins: A graphical interface for
creating and playing smil documents. WWW7 Conference Computer Networks anda
ISDN Systems, 1998.
[Clayberg e Rubel 2004]CLAYBERG, E.; RUBEL, D. Eclipse: Building CommercialQuality Plugins. [S.l.]: Addison-Wesley, 2004.
[Eclipse Foundation 2008]Eclipse Foundation. Eclipse documentation - Latest Release Eclipse 3.3. 2008. Http://help.eclipse.org/help33/index.jsp.
[Eclipse Foundation 2008]Eclipse Foundation. SWT: The Standard Widget Toolkit. 2008.
Http://www.eclipse.org/swt/.
[Governo do Brasil 2008]Governo do Brasil. Comunidade Ginga-NCL. 2008. URL:
http://www.softwarepublico.gov.br.
[Green e Petre 1992]GREEN, T. R.; PETRE, M. When visual programs are harder to read
than textual programs. ECCE-6 (6th European Conference on Cognitive Ergonomics),
1992.
[Guimarães, Costa e Soares 2007]Guimarães, R. L.; Costa, R. M. de R.; Soares, L. F. G.
Composer: Ambiente de autoria de aplicações declarativas para a tv digital interativa.
WEBMEDIA: Brazilian Symposion on Multimedia and the Web, 2007.
[ISO 2008]ISO. The Schematron - An XML Structure Validation Language using Patterns
in Trees. 2008. Http://xml.ascc.net/resource/schematron/.
[Loy et al. 2002]LOY, M. et al. Java Swing. [S.l.]: O Reilly, 2002.
REFERÊNCIAS BIBLIOGRÁFICAS
65
[Manalee 2008]MANALEE. SMOX Pad. 2008. URL: http://www.manalee.com/.
[Moultis e Kirk 1998]MOULTIS, N. P.; KIRK, C. XML Black Book Solução e Poder. [S.l.]:
Makron Books, 1998.
[NCL 2008]NCL. Site NCL. 2008. Http://www.ncl.org.br.
[Nelson 1965]NELSON, T. H. A file structure for the complex, the changing and the
indeterminate. In: . [S.l.]: ACM Press, 1965. p. 84–100.
[Neto et al. 2007]NETO, C. S. S. et al. Construindo Programas Audiovisuais Interativos
Utilizando a NCL 3.0 e a Ferramenta Composer. [S.l.], 2007.
[Oratrix 2008]ORATRIX. Site na Web da Oratrix. 2008. URL: http://www.oratrix.com/.
[PUC-Rio 2008]PUC-RIO.
Documentação
de
NCLua.
2008.
URL:
http://www.telemidia.puc-rio.br/ francisco/nclua/index.html.
[PUC-Rio 2008]PUC-RIO. LuaEclipse: An integrated development environment for the
Lua programming language. 2008. Http://luaeclipse.luaforge.net/.
[Refsnes Data 2008]Refsnes
Data.
DTD
Tutorial.
2008.
Http://www.w3schools.com/DTD/default.asp.
[Refsnes Data 2008]Refsnes
Data.
Tutorial
sobre
SMIL.
2008.
URL:
http://www.w3schools.com/smil/default.asp.
[Soares e Rodrigues 2005]SOARES, L. F. G.; RODRIGUES, R. F. Nested Cotext Model
3.0 Part 1 - NCM Core. [S.l.], 2005.
[Soares e Rodrigues 2006]SOARES, L. F. G.; RODRIGUES, R. F. Nested Context Language 3.0 Part 8 - NCL Digital TV Profiles. [S.l.], 2006.
[Sun Microsystems 2008]Sun Microsystems. Java Native Interface Specification. 2008.
Http://java.sun.com/j2se/1.3/docs/guide/jni/spec/jniTOC.doc.html.
[W3C 2002]W3C. XHTML 1.0 The Extensible HyperText Markup Language (Second Edition). 2002. Http://www.w3.org/TR/xhtml1/.
[W3C 2003]W3C. XML Schema. 2003. Http://www.w3.org/XML/Schema.
REFERÊNCIAS BIBLIOGRÁFICAS
66
[W3C 2005]W3C. Synchronized Multimedia Integration Language (SMIL 2.1). 2005. URL:
http://www.w3.org/TR/REC-smil/.
[W3C 2008]W3C. XML 1.0 Extensible Markup Language (XML) 1.0 (Fourth Edition).
2008. Http://www.w3.org/TR/REC-xml.
[Zukowski 1997]ZUKOWSKI, J. Java AWT Reference. [S.l.]: O Reilly, 1997.
67
Glossário
Atributo
Os atributos em XML são usados para descrever os elementos XML ou
para fornecer uma informação adicional sobre os elementos. São definidos
sempre nas tags de aberturas, da seguinte forma <tag attributo1=“valor”
atributo2=“valor”...>.
Autor
pessoa que interage com o editor / formatador NCL visando a criação de
um documento hipermdia.
Conector hipermı́dia
tem a função de representar relações entre os componentes de um documento hipermı́dia.
Documento hipermı́dia
Um documento hipermı́dia é composto por nós e elos. Um documento hipermı́dia contém imagens, vı́deos, áudios e textos. Além disso, usa ligações
de hipertexto para permitir que o usuário salte de um trecho para outro do
documento ou até mesmo para um documento diferente.
DOM
API definida pelo W3C que define como acessar, ou manipular, um documento XML. Esta API é independente de plataforma e/ou linguagem e é
baseada no modelo DOM (Document Object Model).
Elo
De uma forma simplificada, um elo pode ser entendido como o relacionamento entre mı́dias.
Linguagem de marcação
É representada por um conjunto de códigos empregados a dados e a textos,
com a finalidade de adicionar informações especı́ficas sobre esse dado ou
texto. A linguagem de marcação é utilizada em diferentes segmentos, em
especial na indústria editorial onde a marcação e a formatação de páginas
são feitas a partir desse recurso. XML, HTML, SMIL e NCL são exemplos
de linguagens de marcação.
REFERÊNCIAS BIBLIOGRÁFICAS
68
Linguagem de script
É uma linguagem de programação interpretada, ou seja, executada em um
interpretador.
Módulos XML
são coleções de elementos, atributos e valores de atributos XML semanticamente relacionados que representam uma unidade de funcionalidade.
Módulos são definidos em conjuntos coerentes. Essa coerência é expressa
por meio da associação de um mesmo namespace aos elementos desses
módulos. Os módulos são atômicos, isto é, não podem ser subdivididos
quando incluı́dos em um perfil de linguagem.
Middleware é a camada de software localizada entre as aplicações (programas de usuário
ou uso final) e o sistema operacional. Seu objetivo é oferecer às aplicações
suporte necessário para seu rápido e fácil desenvolvimento, além de esconder os detalhes das camadas inferiores, bem como a heterogeneidade entre
os diferentes sistemas operacionais e hardwares, definindo, para os que produzem conteúdo, uma visão única de aparelho. O Ginga é o middleware
brasileiro da televisão digital terrestre.
Nó (de um documento hipermı́dia)
Representa um objeto de mı́dia abstraindo como seu conteúdo está representado.
Nó NCL
Qualquer elemento definido Pela linguagem NCL.(elemento < media >,
< context >, < body > ou < switch > de NCL)[ABNT 2007]
NCL (Nested Context Language)
Linguagem de marcação, declarativa, baseada em XML, para especificação
de apresentações hipermı́dia.
Perfil XML Um perfil de linguagem é uma combinação de módulos. Além disso, a
especificação de um módulo pode incluir um conjunto de requisitos para
integração, com o qual os perfis de linguagem, que incluem o módulo, devem
obrigatoriamente ser compatı́veis. [ABNT 2007]
Plug-in
Plug-in é um termo que significa ”de encaixe”, pode ser utilizados em situações cotidianas, como aparelhos eletrônicos, máquinas ou qualquer coisa.
Na informática, um plugin ou plug-in é um (geralmente pequeno e leve)
REFERÊNCIAS BIBLIOGRÁFICAS
69
programa de computador que serve normalmente para adicionar funções
a outros programas maiores, provendo alguma funcionalidade especial ou
muito especı́fica.
Schema (XML)
Descreve a estrutura de um documento XML. A linguagem XML Schema
é também denominada como XML Schema Definition (XSD). É uma alternativa aos DTDs (Document Type Definition) [Refsnes Data 2008].
Tag (XML) Em XML, uma tag é o que está escrito entre ”menor que”e ”maior que- (< isto é uma tag >). As tags podem ser de abertura (<tag>) ou de
fechamento </tag>.
Uniform Resource Identifier (URI)
método de endereçamento tido como universal. Permite, por exemplo, o
acesso a objetos em uma rede.
Usuário ou Usuário final
pessoa que interage com o programa em execução. Se estivermos falando
de TV digital, podemos entender como sendo o telespectador.
Validador
software cuja finalidade é verificar se um dado documento segue os padrões
sintáticos e semânticos definidos na especificação da linguagem na qual
este documento é criado. É muito utilizado para validar linguagens de
programação. Um bom validador além de dizer se existe ou não erros no
documento deve ter a capacidade de identificar o possı́vel local do erro, bem
como mostrar um mensagem que auxilie o autor a consertá-los.
70
A NCL Eclipse - Diagrama de Classes e
Pontos de Extensão
Este anexo tem como objetivo mostrar a estrutura do NCL Eclipse. Para isto são apresentados os diagramas de classes mais explicativos do sistema e o arquivo plugin.xml.
A NCL Eclipse - Diagrama de Classes e Pontos de Extensão
Figura A.1: Diagrama de classes do NCL Eclipse - visão geral
71
A NCL Eclipse - Diagrama de Classes e Pontos de Extensão
Figura A.2: Diagrama especı́fico da implementação dos Wizards
Figura A.3: Diagrama de classes especı́fico da implementação da visão Outline
72
A NCL Eclipse - Diagrama de Classes e Pontos de Extensão
73
Figura A.4: Diagrama de classes especı́fico da implementação do parsing NCL, utilizado
para manter informações na memória e sugerı́-las quando necessário
A NCL Eclipse - Diagrama de Classes e Pontos de Extensão
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
<?xml version=” 1 . 0 ” e n c o d i n g=”UTF−8” ?>
<? e c l i p s e version=” 3 . 2 ” ?>
<p l u g i n>
<e x t e n s i o n
p o i n t=” o r g . e c l i p s e . u i . e d i t o r s ”>
<e d i t o r
c l a s s=” br . ufma . d e i n f . l a w s . n c l e c l i p s e . NCLEditor ”
c o n t r i b u t o r C l a s s=” br . ufma . d e i n f . l a w s . n c l e c l i p s e . NCLActionContributor ”
default=” t r u e ”
e x t e n s i o n s=” n c l , conn ”
i c o n=” i c o n s / sample . g i f ”
i d=” br . ufma . d e i n f . l a w s . n c l e c l i p s e . e d i t o r s . NCLEditor ”
name=”NCL E c l i p s e ”>
</ e d i t o r>
</ e x t e n s i o n>
< !−−E d i t o r A c t i o n s −−>
< !−− End o f E d i t o r A c t i o n s −−>
<e x t e n s i o n
p o i n t=” o r g . e c l i p s e . u i . newWizards ”>
<c a t e g o r y
i d=” n c l e c l i p s e ”
name=”NCL”>
</ c a t e g o r y>
<w i z a r d
c a t e g o r y=” n c l e c l i p s e ”
c l a s s=” br . ufma . d e i n f . l a w s . n c l e c l i p s e . w i z a r d s . NCLNewWizard”
i c o n=” i c o n s / sample . g i f ”
i d=” n c l e c l i p s e . w i z a r d s . NCLNewWizard”
name=”NCL Document”>
</ w i z a r d>
<w i z a r d
c a t e g o r y=” n c l e c l i p s e ”
c l a s s=” br . ufma . d e i n f . l a w s . n c l e c l i p s e . w i z a r d s . ConnectorBaseNewWizard ”
i c o n=” i c o n s / sample . g i f ”
i d=” n c l e c l i p s e . w i z a r d s . ConnectorBaseNewWizard ”
name=” Connector Base Document”>
</ w i z a r d>
</ e x t e n s i o n>
<e x t e n s i o n
p o i n t=” o r g . e c l i p s e . u i . commands”>
<command
c a t e g o r y I d=” o r g . e c l i p s e . j d t . u i . c a t e g o r y . s o u r c e ”
d e s c r i p t i o n=”%A c t i o n D e f i n i t i o n . f o r m a t . d e s c r i p t i o n ”
i d=” br . ufma . d e i n f . l a w s . n c l e c l i p s e . a c t i o n s . f o r m a t ”
name=”%A c t i o n D e f i n i t i o n . f o r m a t . name”>
</command>
</ e x t e n s i o n>
<e x t e n s i o n
i d=” n c l e r r o r ”
name=”NCL E r r o r ”
p o i n t=” o r g . e c l i p s e . c o r e . r e s o u r c e s . markers ”>
<s u p e r
t y p e=” o r g . e c l i p s e . c o r e . r e s o u r c e s . markers . problemmarker ”>
</ s u p e r>
<s u p e r
t y p e=” o r g . e c l i p s e . c o r e . r e s o u r c e s . markers . t e x t m a r k e r ”>
</ s u p e r>
<p e r s i s t e n t
v a l u e=” t r u e ”>
</ p e r s i s t e n t>
</ e x t e n s i o n>
<e x t e n s i o n p o i n t=” o r g . e c l i p s e . debug . u i . l a u n c h S h o r t c u t s ”>
<s h o r t c u t l a b e l=”NCL P r e s e n t a t i o n ”
i c o n=” i c o n s / sample . g i f ”
modes=” run ”
c l a s s=” br . ufma . d e i n f . l a w s . n c l e c l i p s e . l a u n c h . LaunchShortcut ”
i d=” br . ufma . d e i n f . l a w s . n c l e c l i p s e . l a u n c h . LaunchShortcut ”>
<c o n t e x t u a l L a u n c h>
<enablement>
<with v a r i a b l e=” s e l e c t i o n ”>
<count v a l u e=” 1 ” />
</ with>
</ enablement>
<c o n t e x t L a b e l mode=” run ” l a b e l=”NCL P r e s e n t a t i o n ” />
</ c o n t e x t u a l L a u n c h>
<p e r s p e c t i v e i d=” o r g . e c l i p s e . j d t . u i . J a v a P e r s p e c t i v e ” />
<p e r s p e c t i v e i d=” o r g . e c l i p s e . debug . u i . D e b u g P e r s p e c t i v e ” />
</ s h o r t c u t>
</ e x t e n s i o n>
</ p l u g i n>
Figura A.5: Arquivo plugin.xml - Customização dos pontos de conexão
74
Download
NCL Eclipse: editor textual para desenvolvimento de

Apresentação NCL

Ginga Live CD

Suporte à Edição Colaborativa de Documentos

NCL Eclipse: editor textual para desenvolvimento de

Apresentação NCL

Ginga Live CD

Suporte à Edição Colaborativa de Documentos

pôster apresentado

Curso básico: Marcas Michele Copetti - NUTE

Eclipse Lunar

TCC

Interface Gráfica Online para Geração Automática de Arquivos NCL

Roteiro WS

Desenvolvimento de plataformas para produção e difusão - PUC-SP
