suporte a aplicações sensíveis ao contexto no cenário do sistema
TRANSCRIPT
Thiago Paris Salviato
Suporte a Aplicações Sensíveis ao Contextono Cenário do Sistema Brasileiro de Televisão
Digital
Vitória2012
Thiago Paris Salviato
Suporte a Aplicações Sensíveis ao Contextono Cenário do Sistema Brasileiro de Televisão
Digital
Dissertação apresentada à UniversidadeFederal do Espírito Santo, para a obten-ção de Título de Mestre em Informática.
Orientador:José Gonçalves Pereira Filho
Vitória2012
Dados Internacionais de Catalogação-na-publicação (CIP) (Biblioteca Central da Universidade Federal do Espírito Santo, ES, Brasil)
Salviato, Thiago Paris, 1983- S184s Suporte a aplicações sensíveis ao contexto no cenário do
Sistema Brasileiro de Televisão Digital / Thiago Paris Salviato. – 2012.
159 f. : il. Orientador: José Gonçalves Pereira Filho. Dissertação (Mestrado em Informática) – Universidade
Federal do Espírito Santo, Centro Tecnológico. 1. Televisão digital. 2. NCL (Linguagem de Marcação de
Documento). 3. Ginga (Middleware para TV digital). 4. Sistema Brasileiro de Televisão Digital. I. Pereira Filho, José Gonçalves. II. Universidade Federal do Espírito Santo. Centro Tecnológico. III. Título.
CDU: 004
Thiago Paris Salviato
Suporte a Aplicações Sensíveis ao Contextono Cenário do Sistema Brasileiro de Televisão
Digital
Dissertação submetida ao Programa de Pós-Graduação em Informática do Centro Tecno-lógico da Universidade Federal do Espírito Santo, como requisito parcial para a obtençãodo título de Mestre em Informática.
Aprovada em 27 de Janeiro de 2012.
Banca Examinadora:
Prof. Dr.José Gonçalves Pereira FilhoUniversidade Federal do Espírito Santo
Profª. Drª.Patrícia Dockhorn CostaUniversidade Federal do Espírito Santo
Prof. Dr.Luiz Fernando Gomes SoaresPontifícia Universidade Católica do Rio de Janeiro
Vitória2012
Dedico este trabalho ao meu grande e eterno amigo Bruno Pandolfi.Acredite: mesmo daí você me dá força e incentivo para superar meus desafios.
Agradecimentos
Agradeço ao meu orientador por todo o apoio; à CAPES, pelo financiamento da minha
pesquisa; à equipe e à coordenação do projeto GingaFrEvo & GingaRAP, pela oportunidade; aos
meus colegas de trabalho, pela compreensão; aos meus amigos, por, não sem reclamar, aceitarem
meu sumiço; à minha família, por me dar apoio incondicional e aguentar meu mau humor; ao
meu grande amor, por me mostrar o que é a feliciadade e me fazer querer ser uma pessoa melhor;
e a Deus, pela vida e por colocar todas essas pessoas dentro dela.
Resumo
Aplicações sensíveis ao contexto usam informações contextuais para customizar serviços de
acordo com as situações e as necessidades dos seus usuários. Um dos cenários promissores para
o desenvolvimento dessa classe de aplicações é aquele proporcionado pelo ambiente de televisão
digital interativa, em particular no âmbito do Sistema Brasileiro de Televisão Digital (SBTVD).
Apesar de apresentar funcionalidades que facilitam o desenvolvimento dessas aplicações, como o
suporte à adaptação da apresentação de conteúdo dependendo do valor de variáveis de ambiente
e suporte a múltiplos dispositivos, o Ginga, padrão de middleware do SBTVD, ainda carece de
uma infraestrutura de gerenciamento de contexto mais adequada ao suporte de aplicações desse
tipo mais elaboradas, independentes de domínio e voltadas ao reuso.
Dentre os diversos desafios de se construir essa infraestrutura, dotar o Ginga de um serviço
genérico de aquisição de informações contextuais pode ser uma tarefa desafiadora, particular-
mente devido à natureza heterogênea dos dispositivos de captura de contexto utilizados e das
informações variadas por eles obtidas.
A partir de uma proposta de arquitetura conceitual genérica para o módulo “Gerenciador
de Contexto” do Ginga, definida em projeto anterior, o trabalho apresenta a implementação do
componente “Gerenciador de Fontes de Contexto”, elemento da arquitetura cuja função é prover
uma interface padronizada para a comunicação entre o middleware e dispositivos heterogêneos
responsáveis pela aquisição de informações contextuais. A implementação realizada baseia-se na
utilização de scripts NCLua, linguagem imperativa do padrão, e no OSGI, framework de geren-
ciamento de dispositivos para home networks. O trabalho propõe ainda uma metodologia para
o desenvolvimento de aplicações sensíveis ao contexto utilizando a infraestrutura desenvolvida.
Palavras-chave: Sensibilidade ao Contexto, TV Digital, Ginga, OSGi.
Abstract
Context-aware applications use contextual information to customize services according to
the dynamicity of the situations and needs of its users. One of the promising scenarios for the
development of this class of applications is that provided by the interactive digital television,
particularly in the context of the Brazilian Digital Television System (SBTVD). Even though it
presents features which can be used to facilitate the development of context-aware applications,
such as content presentation adaptation and multiple devices support, the current middleware
standard for the SBTVD, named Ginga, still lacks a context management infrastructure that
favors the development of complex, domain independent and designed to reuse context-aware
applications.
Among the many challenges of building this infrastructure, providing Ginga with a generic
service for the acquisition of contextual information can be a major task, particularly due to the
heterogeneous nature of context sources devices and their varying data.
Starting from a generic conceptual architecture defined for the Ginga’s Context Manager
component in a earlier project, this work presents an implementation for the ”Context Sources
Manager”, a key element of architecture, whose responsibility is to provide a standardized in-
terface for the communication between the middleware and the heterogeneous devices that are
responsible for the acquisition of contextual information. The implementation is carried out
based on the use of scripts NCLua, the Ginga’s imperative language, and OSGI, a framework for
the management of electronic devices in home networks. The dissertation also proposes a new
methodology for the development of context-aware applications using the developed infrastruc-
ture.
Keywords: Context-Aware Applications, Digital TV, Ginga, OSGi
Lista de Figuras
2.1 Modelo simplificado de um sistema de TV analógica. . . . . . . . . . . . . . . . . 36
2.2 Modelo simplificado de um sistema de TV Digital. Fonte: (SOARES; BARBOSA,
2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3 Arquitetura do Ginga. Fonte: (SOARES, 2009) . . . . . . . . . . . . . . . . . . . 39
2.4 Exemplo de código NCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5 Aplicação sensível ao contexto e suas interações. Fonte: (COSTA, 2007) . . . . . 45
2.6 Navegador Web Sensível ao Contexto e suas interações. . . . . . . . . . . . . . . . 46
3.1 Arquitetura de Serviço para Avaliação de Contextos em Redes de TV Digital.
Fonte: (LEITE et al., 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2 Ferramenta de Autoria de Aplicações Sensíveis ao Contexto. Fonte: (CARVALHO;
FERRAZ, 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3 Modelo da biblioteca TCPEventHandler para comunicação com o canal de inte-
ratividade. Fonte: (MIELKE, 2010) . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4 Modelo da biblioteca Properties para comunicação com o documento NCL. Fonte:
(MIELKE, 2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1 Exemplo de modelagem contextual que utiliza os elementos de modelagem defini-
dos por Costa (2007). Fonte: (VALE; GUAITOLINI; COSTA, 2009) . . . . . . . 73
4.2 Situação SituationMakingPopcorn. Fonte: (VALE; GUAITOLINI; COSTA, 2009) 74
4.3 Situação SituationDisplayingMovie. Fonte: (VALE; GUAITOLINI; COSTA, 2009) 74
4.4 Padrão Event-Control-Action (ECA). Fonte: (COSTA, 2007) . . . . . . . . . . . 77
4.5 Componentes da Plataforma de Manipulação de Contexto (Context Handling Plat-
form). Fonte: (COSTA, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.6 Gerenciador de Contexto dando apoio a duas aplicações sensíveis ao contexto. . . 82
4.7 Interações relevantes para o Gerenciador de Contexto . . . . . . . . . . . . . . . . 83
4.8 Padrão ECA aplicado ao Gerenciador de Contexto . . . . . . . . . . . . . . . . . 84
4.9 Gerenciador de Contexto após a aplicação dos padrões arquiteturais. . . . . . . . 85
4.10 Arquitetura proposta para o Gerenciador de Contexto. . . . . . . . . . . . . . . . 86
5.1 Interações entre uma aplicação, o gerenciador de fontes contextuais implementado
e dispositivos diversos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2 Detalhamento do Gerenciador de Fontes Contextuais. . . . . . . . . . . . . . . . . 97
5.3 Biblioteca ContextManager.lua para acesso aos serviços do Gerenciador de Infor-
mações Contextuais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.4 Utilizando a biblioteca ContextManager.lua. . . . . . . . . . . . . . . . . . . . . . 99
6.1 Mapeamento de Entidades e Contexto Intrínseco para mídias NCLua. Fonte:
(VALE, 2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2 Mapeamento do Contexto Relacional e Entidades envolvidas para mídias NCLua.
Fonte:(VALE, 2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.3 Mapeamento de Situações Contextuais e elementos envolvidos para mídias NCLua.
Fonte: (VALE, 2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.4 Exemplo de mapeamento entre modelagem contextual e mídias NCLua. . . . . . 108
6.5 Mapeamento da cláusula When SituationTVOn(TV.TV1) para NCL. Fonte: (VALE,
2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.6 Exemplo de mapeamento entre regra ECA-DL TVD e código NCL. . . . . . . . . 115
7.1 Cenário Ideal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
7.2 Cenário Atual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.3 Cenário utilizando a metodologia definida em Vale (2011). . . . . . . . . . . . . . 123
7.4 Exemplo de mapeamento entre modelagem contextual e mídias NCLua. . . . . . 126
7.5 Código da mídia NCLua referente a entidade TVProgram. . . . . . . . . . . . . . 128
7.6 Passagem de valores de propriedades entre objetos NCLua. . . . . . . . . . . . . . 129
7.7 Exemplo de implementação de um contexto relacional em Lua. . . . . . . . . . . 130
7.8 Exemplo de implementação de um contexto relacional em Lua. . . . . . . . . . . 132
8.1 Modelagem contextual para o cenário John Popcorn. Fonte: (VALE; GUAITO-
LINI; COSTA, 2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
8.2 Modelagem da situação SituationMakingPopcorn para o cenário John Popcorn.
Fonte: (VALE; GUAITOLINI; COSTA, 2009) . . . . . . . . . . . . . . . . . . . . 140
8.3 Modelagem da situação SituationDisplayingMovie para o cenário John Popcorn.
Fonte: (VALE; GUAITOLINI; COSTA, 2009) . . . . . . . . . . . . . . . . . . . . 140
8.4 Estados do sensor UPnP que monitora o status de um Microondas. . . . . . . . . 142
8.5 Implementação do bundle OSGi para acesso ao sensor UPnP. . . . . . . . . . . . 142
8.6 Implementação do bundle OSGi para acesso ao sensor UPnP. . . . . . . . . . . . 143
8.7 Mapeamento dos elementos da modelagem envolvidos na regra ECA-DL TVD. . 145
8.8 Mapeamento das cláusulas que compõem a regra ECA-DL TVD. . . . . . . . . . 146
8.9 Propagação das informações contextuais entre Fontes de Contexto e Fontes de
Situação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
8.10 Implementação da mídia MicrowaveOven1.lua. . . . . . . . . . . . . . . . . . . . . 147
8.11 Implementação da mídia TV1.lua. . . . . . . . . . . . . . . . . . . . . . . . . . . 148
8.12 Implementação da mídia TVProgram1.lua. . . . . . . . . . . . . . . . . . . . . . . 148
8.13 Implementação da mídia SituationMakingPopcorn_MicrowaveOven1. . . . . . . . 149
8.14 Implementação da mídia SituationDisplayingMovie_TV1_TVProgram1. . . . . . 149
Lista de Tabelas
6.1 Eventos primitivos de ECA-DL TVD e suas correspondências em NCL. Fonte:
adaptado de (VALE, 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.2 Eventos primitivos de ECA-DL TVD e suas correspondências em NCL. Fonte:
adaptado de (VALE, 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.3 Eventos primitivos de ECA-DL TVD e suas correspondências em NCL. Fonte:
adaptado de (VALE, 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Nomenclatura
ECG Eletrocardiograma
GPS Sistema de Posicionamento Global (Global Positioning System)
NCL Nested Context Language
OCL Object Constraint Language
OWL Web Ontology Language
PNAD Pesquisa Nacional de Amostras por Domicílio
SBTVD Sistema Brasileiro de Televisão Digital
SRWL Semantic Web Rule Language
STB Set-Top Box
TVDi Televisão Digital Interativa
UML Universal Markup Language
XML eXtensible Markup Language
Sumário
1 Introdução 27
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.4 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2 Referencial Teórico 35
2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2 Televisão Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2.2 Interatividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.3 Ginga: O middleware do SBTVD . . . . . . . . . . . . . . . . . . . . . . . 38
2.2.4 Aplicações Declarativas para o Ginga . . . . . . . . . . . . . . . . . . . . . 41
2.2.4.1 Linguagem NCL . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.4.2 Objetos NCLua . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3 Aplicações Sensíveis ao Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3.2 Desenvolvimento de Aplicações Sensíveis ao Contexto . . . . . . . . . . . 46
2.3.2.1 Arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.3.2.2 Modelagem de Contexto, Situações e Comportamento Reativo . 50
2.3.2.3 Metodologia de Desenvolvimento . . . . . . . . . . . . . . . . . . 50
2.3.3 Aquisição de Informações Contextuais . . . . . . . . . . . . . . . . . . . . 51
2.4 Home Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.4.1.1 Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.4.1.2 UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.4.1.3 OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.5 Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3 Trabalhos Relacionados 57
3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2 Trabalhos Analisados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.1 Uma Arquitetura de Serviço para Avaliação de Contextos em Redes de TV
Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.2 Um Framework Sensível ao Contexto para Sistemas de Tomadas de Decisão
de Governança em Saúde . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2.3 Contextual Ginga: Uma Ferramenta de Autoria de Aplicações Interativas
Sensíveis ao Contexto de TV digital para Ginga-NCL . . . . . . . . . . . . 59
3.2.4 Desenvolvimento de Aplicações Sensíveis ao Contexto no Ambiente Decla-
rativo do Sistema Brasileiro de TV Digital . . . . . . . . . . . . . . . . . . 60
3.2.5 Abordagem Orientada a Modelos para o Desenvolvimento de Aplicações
Sensíveis ao Contexto para a TV Digital . . . . . . . . . . . . . . . . . . . 62
3.2.6 Integração entre o Middleware Brasileiro de TV Digital e Serviços de Dis-
positivos Eletrônicos em Redes OSGi . . . . . . . . . . . . . . . . . . . . . 63
3.2.7 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.7.1 Modelagem de Contexto . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.7.2 Arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.7.3 Aquisição de Informações contextuais . . . . . . . . . . . . . . . 67
3.3 Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4 Suporte Arquitetural para Aplicações Sensíveis ao Contexto e o Gerenciador
de Contexto do Ginga 71
4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2 Modelagem de Contexto e Situações . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.3 ECA-DL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.4 Padrões Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.4.1 Padrão Arquitetural Event-Control-Action . . . . . . . . . . . . . . . . . . 77
4.4.2 Padrão Arquitetural de Hierarquia de Fontes e Gerenciadores de Contexto 78
4.4.3 Padrão Arquitetural de Ações . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.5 Arquitetura Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.5.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.5.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.5.3 Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.6 Arquitetura Conceitual para o Gerenciador de Contexto do Ginga . . . . . . . . . 82
4.6.1 Arquitetura Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.6.1.1 Modelo da Arquitetura . . . . . . . . . . . . . . . . . . . . . . . 82
4.6.1.2 Detalhamento da Arquitetura . . . . . . . . . . . . . . . . . . . . 83
4.7 Componentes Gerenciadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.8 Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5 Gerenciador de Fontes de Contexto 89
5.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2 Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3 Serviços e Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.4 Abordagem Escolhida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.5 Arquitetura Implementada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.5.1 Elementos do Gerenciador de Fontes Contextuais . . . . . . . . . . . . . . 96
5.5.2 Acessando os Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.6 Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6 Abordagem Orientada a Modelos para o Desenvolvimento de Aplicações Sen-
síveis ao Contexto para a TV Digital 103
6.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2 Elementos de Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.2.1 Entidades e Contextos Intrínsecos . . . . . . . . . . . . . . . . . . . . . . . 105
6.2.2 Contextos Relacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2.3 Situações Contextuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.2.4 Exemplo dos Mapeamentos . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.3 Elementos das Regras ECA-DL TVD . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.3.1 Cláusula Upon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.3.1.1 Eventos Primitivos . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.3.1.2 Eventos de Situação . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.3.2 Cláusula When . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.3.3 Cláusula Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.3.4 Exemplo dos Mapeamentos . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.3.5 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.4 Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7 Metodologia de Desenvolvimento de Aplicações Sensíveis ao Contexto para a
TV Digital 119
7.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.2 Abordagem Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
7.2.1 Modificações nos Mapeamentos . . . . . . . . . . . . . . . . . . . . . . . . 124
7.2.1.1 Entidades e Contextos . . . . . . . . . . . . . . . . . . . . . . . . 124
7.2.1.2 Contextos Relacionais . . . . . . . . . . . . . . . . . . . . . . . . 124
7.2.1.3 Situações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
7.2.2 Aquisição e Propagação das Informações Contextuais . . . . . . . . . . . . 127
7.2.2.1 Fontes de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.2.2.2 Fontes de Contexto da Aplicação . . . . . . . . . . . . . . . . . . 128
7.2.2.3 Propagação das Informações entre as Mídias . . . . . . . . . . . 129
7.2.2.4 Mídias de Contextos Relacionais . . . . . . . . . . . . . . . . . . 130
7.2.3 Situações a partir de Invariantes OCL . . . . . . . . . . . . . . . . . . . . 131
7.2.4 Ações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.3 Proposta de Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.3.1 Modelagem de Contexto e Situações . . . . . . . . . . . . . . . . . . . . . 134
7.3.2 Desenvolvedores de Serviços de Acesso à Informação Contextual . . . . . . 134
7.3.3 Desenvolvedores de Aplicações para TV Digital . . . . . . . . . . . . . . . 135
7.4 Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8 Estudo de Caso 137
8.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8.2 Cenário: John Popcorn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8.2.1 Modelagem de Contexto e Situações . . . . . . . . . . . . . . . . . . . . . 138
8.2.2 Desenvolvedores de Serviços de Acesso à Informação Contextual . . . . . . 141
8.2.2.1 Dispositivo de sensoriamento . . . . . . . . . . . . . . . . . . . . 141
8.2.2.2 Bundle OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
8.2.3 Desenvolvedores de Aplicações para TV Digital . . . . . . . . . . . . . . . 144
8.2.3.1 Comportamento Reativo em ECA-DL TVD . . . . . . . . . . . . 144
8.2.3.2 Mapeamento da Regra ECA-DL TVD . . . . . . . . . . . . . . . 145
8.2.3.3 Propagação da Informação Contextual . . . . . . . . . . . . . . . 146
8.2.3.4 Implementação das mídias NCLua . . . . . . . . . . . . . . . . . 146
8.3 Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
9 Conclusões 151
9.1 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Referências Bibliográficas 155
Capítulo 1
Introdução
1.1 Motivação
Sistemas sensíveis ao contexto formam uma categoria emergente de software que se utiliza da
dinamicidade do contexto do usuário e do ambiente físico que o cerca para enriquecer a inte-
ração humano-computador, adequando os serviços de acordo com a situação e as necessidades
dinâmicas do usuário. A característica de adaptatividade ao contexto torna essa classe de aplica-
ções extremamente interessante, abrindo a possibilidade de explorar novos serviços, muito mais
flexíveis, adaptativos e centrados no usuário.
Com o grande desenvolvimento das tecnologias de comunicação e computação móvel e a pro-
liferação de dispositivos portáteis multifuncionais (ex: smartphones, tablets), contexto tornou-se
um tópico destacado de pesquisas na comunidade de Ciência da Computação, recebendo especial
interesse da área de pesquisa em Computação Ubíqua e Pervasiva (“Ubiquitous / Pervasive Com-
puting”) (WEISER, 1991). Dentre as classes de aplicações imaginadas no cenário da Computação
Ubíqua, destacam-se as Aplicações Sensíveis ao Contexto (Context-Aware Applications). Essas
aplicações tentam explorar as mudanças de contexto ocorridas dentro de um domínio dinâmico
para aprimorar a interação com seus usuários. São exemplos de dados contextuais aqueles ad-
quiridos por sensores, como a localização atual do usuário adquirida por um dispositivo GPS ,
a temperatura e a luminosidade de um ambiente adquiridas por sensores de uma rede domés-
tica (home network), ou mesmo sinais de ECG adquiridos por um holter ligado a um paciente
cardíaco.
28
Com o advento da televisão digital aberta no Brasil, um dos possíveis cenários para o desen-
volvimento de aplicações sensíveis ao contexto é aquele proporcionado pelo ambiente de Televisão
Digital interativa (TVDi ), no âmbito do Sistema Brasileiro de Televisão Digital (SBTVD ). Esse
cenário passa a chamar a atenção devido ao fato da característica de sensibilidade ao contexto po-
der enriquecer ainda mais a experiência do usuário de assistir televisão. Além disso, a emergência
da TV digital como uma nova plataforma de mídia, aliada à familiaridade do público em geral
com a mídia televisiva, abre novas possibilidades para a melhoria e a implantação de diferentes
tipos de serviços interativos em diversos domínios – potencialmente enriquecidos com informa-
ções contextuais – em domínios diversos, por exemplo, nas áreas da Saúde (e.g., aplicações de
“personal healthcare”) e Governo Eletrônico (e.g., aplicações de inclusão digital).
As aplicações sensíveis ao contexto, independentemente de domínio, compartilham da ne-
cessidade de uma infraestrutura de serviços “context-aware” básicos, como o suporte à aquisição
de dados de múltiplas fontes de informações contextuais, à interpretação de contexto, à mani-
pulação de contextos com diferentes níveis de abstração, à inclusão de novos tipos de contexto
e/ou novos tipos de fontes de dados contextuais, ao controle do comportamento reativo da apli-
cação na presença de um dada situação contextual, dentre outros, sendo que esses serviços são
normalmente providos por partes, ou entidades, diferentes. Por exemplo, a aquisição de dados é
provida por fabricantes de dispositivos eletrônicos, enquanto que a definição do comportamento
reativo da aplicação pode ser provida por especialistas no domínio da aplicação.
Um dos empecilhos para uma maior difusão de aplicações sensíveis ao contexto no cenário
do SBTVD é a ausência de uma infraestrutura sensível ao contexto adequada na arquitetura
conceitual do seu padrão de middleware, o Ginga (ABNT, 2007b). O componente “Gerenciador
de Contexto” (Context Manager), pertencente ao Núcleo Comum (Common-Core) do Ginga, é
o elemento da arquitetura descrito no padrão como o responsável por prover o suporte “context-
aware”. Em tese, este componente deveria ser o responsável por prover elementos que poderiam
ser utilizados para capturar informações de contexto relevantes em comum, ou, ainda, reutilizar
outras funções comumente utilizadas por meio do oferecimento de serviços genéricos. Contudo,
possivelmente por ser um componente opcional da arquitetura (SOARES, 2009), o Gerenciador de
Contexto ainda não foi significativamente explorado nos modelos e implementações de referência
para o Ginga. Em (CRUZ; MORENO; SOARES, 2008) é realizada uma implementação do
Ginga para dispositivos portáteis, na qual o Gerenciador de Contexto implementado gerencia
29
somente informações sobre o sistema embarcado no dispositivo receptor e sobre o perfil do usuário
telespectador.
Certamente, a criação de uma infraestrutura sensível ao contexto no Ginga, dotada de fun-
cionalidades genéricas para prover serviços “context-aware”, e que permita a distribuição da
responsabilidade do desenvolvimento de aplicações por todas as partes envolvidas no processo
de criação, facilitaria o trabalho do desenvolvedor e poderia impulsionar o surgimento de novas
e interessantes aplicações sensíveis ao contexto no SBTVD.
Dentre os diversos desafios de se construir essa infraestrutura, incluir no Ginga um serviço
genérico de aquisição de informações contextuais pode ser, particularmente, uma tarefa desafi-
adora, devido à natureza heterogênea dos dispositivos de captura de contexto utilizados e dos
variados tipos de informações por eles obtidas. Cada dispositivo fonte de contexto pode utilizar
um protocolo de comunicação diferente e enviar a informação em um formato particular; logo, a
infraestrutura deve ser capaz de fornecer ao desenvolvedor uma forma homogênea de se comu-
nicar com dispositivos heterogêneos, provendo para as aplicações dados contextuais no formato
desejado. O gerenciamento de dispositivos fontes de contexto é um dos problemas específicos
tratados nesta dissertação e constitui uma de suas contribuições.
Há na literatura uma série de trabalhos que propõem arquiteturas para dar suporte à exe-
cução de aplicações sensíveis ao contexto (DEY, 2000), (CHEN, 2004), (GU; PUNG; ZHANG,
2005), (PESSOA, 2006), (COSTA, 2007), as quais trazem contribuições importante e podem ser
tomados como base para a definição de uma arquitetura conceitual de gerenciamento de contexto
para o Ginga.
A arquitetura definida por Costa (2007), em particular, é de especial interesse para esta
dissertação, pois propõe soluções para os principais desafios impostos pelo desenvolvimento e
instalação de aplicações sensíveis ao contexto, incluindo abstrações que permitem uma mode-
lagem formal de contexto, situações e comportamento reativo da aplicação independentemente
do domínio. Além disso, a arquitetura proposta por (COSTA, 2007) também permite a inte-
gração de aplicações possivelmente implementadas por entidades de negócio diferentes, o que é
particularmente útil para o cenário do SBTVD.
Uma das iniciativas mais abrangentes para dotar o Ginga de uma infraestrutura adequada
para a manipulação de informações contextuais é o projeto “GingaFrEvo & GingaRAP – Sub-
30
projeto: Suporte à Modelagem de Contexto no Ambiente de TV Digital Interativa” (UFES, 2010),
projeto de pesquisa financiado pelo CTIC/RNP. Um dos resultados deste projeto é a definição
de uma arquitetura conceitual para o módulo “Gerenciador de Contexto” (Context Manager) do
Ginga, que tem como base a proposta de Costa (2007).
A presente dissertação, concebida no âmbito deste projeto, apresenta o processo de concepção
dessa arquitetura e, tomando-a como referência, descreve em detalhes o projeto e a implemen-
tação de um componente “Gerenciador de Fontes de Contexto para o Ginga. Observa-se que o
autor desta dissertação participou da equipe que concebeu a nova arquitetura de gerenciamento
de contexto do Ginga, desenvolvida durante o projeto “GingaFrEvo & GingaRAP”.
Adicionalmente, usando a infraestrutura implementada, o trabalho também propõe uma nova
abordagem para o desenvolvimento de aplicações sensíveis ao contexto, a partir da adaptação da
metodologia proposta por Vale (2011), que também utiliza conceitos definidos em Costa (2007).
A necessidade de uma metodologia para o desenvolvimento de aplicações sensíveis ao contexto
no SBTVD se dá por várias razões. Em especial, no ambiente de TV Digital, onde existe o
potencial de desenvolvimento de aplicações em diferentes domínios, aliado ao fato da aplicação
poder ser desenvolvida com a contribuição de diferentes entidades do negócio, defendemos ser
adequada a utilização de modelos de contexto formais que não limitem os cenários que podem
ser modelados e que o desenvolvimento de cada parte da aplicação, concebida por cada entidade,
se comprometa com esses modelos.
A maioria dos trabalhos que trata da manipulação de informação contextual, seja através
da definição de modelos de contexto seja pela definição de elementos arquiteturais, não consi-
deram essa abordagem formal e integrada de desenvolvimento de aplicações sensíveis contexto
(SALVIATO et al., 2011). O trabalho descrito em (VALE, 2011) utiliza tal abordagem; po-
rém, possui limitações no que diz respeito à aquisição de informações contextuais de dispositivos
heterogêneos. Assim, sua abordagem pode ser adaptada para aproveitar a implementação do
Gerenciador de Fontes de Contexto realizada nesta dissertação, resultando numa metodologia
formal e integrada que pode ser aplicada a diferentes cenários de uso do Ginga.
31
1.2 Objetivos
Este trabalho tem como objetivo geral implementar alterações no middleware do Sistema
Brasileiro de Televisão Digital, o Ginga, de modo a dotá-lo de uma infraestrutura
adequada para a manipulação de informações contextuais. Essa infraestrutura deve
permitir a criação de uma metodologia que facilite o desenvolvimento de aplicações
sensíveis ao contexto de diferentes domínios na plataforma Ginga.
Esse objetivo geral pode ser detalhado nos seguintes objetivos específicos:
1. Projetar e implementar um Gerenciador de Fontes de Contexto para o Ginga.
Este elemento deve dar suporte à comunicação entre as aplicações sensíveis ao
contexto e os dispositivos fontes de contexto para permitir a aquisição de in-
formações contextuais, independentemente das tecnologias utilizadas por esses
dispositivos.
Como visto, uma questão fundamental no desenvolvimento de aplicações sensíveis ao con-
texto é a implementação de uma interface de comunicação com as fontes de contexto, tanto
para obtenção de informações de contexto como para realização de ações. Uma aplicação
sensível ao contexto no Ginga pode utilizar recursos e serviços internos ou externos ao
receptor para realizar essas tarefas - estes últimos podendo ser providos por sensores e
outros dispositivos eletrônicos, por exemplo, de uma home network. Pode-se perceber que
a utilização de serviços externos pelo receptor é uma tarefa desafiadora devido a fatores
como a complexidade dos serviços oferecidos, heterogeneidade de dispositivos provedores
de serviço e suas diferentes tecnologias de comunicação. Abstrair os aspectos específicos
sobre a forma de acesso e controle dos dispositivos fontes de contexto presentes na aplicação
é, portanto, uma tarefa essencial em qualquer middleware sensível ao contexto. Investigar
opções tecnológicas que permitam criar um ambiente adequado para a gerência da comuni-
cação e troca de serviços entre o Ginga e esses dispositivos e, a partir desse estudo, projetar
e implementar um Gerenciador de Fontes de Contexto para o Ginga é um dos objetivos e
contribuições deste trabalho.
2. Definir uma metodologia apropriada para o desenvolvimento de aplicações sen-
síveis ao contexto no cenário do Sistema Brasileiro de TV Digital, que utilize
a infraestrutura implementada.
32
Como visto, no ambiente de TV Digital existe o potencial de desenvolvimento de aplicações
sensíveis ao contexto em diferentes domínios, as quais geralmente são construídas com a
contribuição de várias entidades. Uma possível abordagem de desenvolvimento, adotada
neste trabalho, requer o uso de uma metodologia de desenvolvimento integrada, que parta
de um modelo formal de contexto, permita a modelagem de cenários em diferentes do-
mínios, e direcione adequadamente o trabalho de desenvolvimento de todas as entidades
envolvidas, o qual deve sempre se comprometer com o modelo formal de contexto criado
para a aplicação. Um trabalho em particular (VALE, 2011) utiliza tal abordagem; po-
rém, possui restrições no que se diz respeito à aquisição de informações contextuais de
dispositivos heterogêneos. Adaptar a abordagem definida por Vale (2011) de forma a utili-
zar a implementação do Objetivo Específico 1 com vistas a definir uma metodologia mais
apropriada para o desenvolvimento de aplicações sensíveis ao contexto para a TV Digital
compõe o segundo objetivo deste trabalho.
1.3 Metodologia
Para atingir os objetivos acima, os seguintes passos foram realizados:
1. Estudo sobre computação ubíqua e sensibilidade ao contexto com o objetivo de promover
o entendimento sobre a natureza deste novo paradigma, os requisitos das plataformas de
suporte a contexto e os desafios no desenvolvimento dessa classe de aplicações.
2. Estudo das tecnologias de televisão digital, SBDTV e do Ginga visando o entendimento
das tecnologias envolvidas no cenário de TV digital interativa e daquelas adotadas no
SBTVD em particular, bem como o conhecimento da arquitetura conceitual do middleware
Ginga. Os estudos envolveram uma avaliação crítica do Ginga como plataforma de suporte
a aplicações sensíveis ao contexto.
3. Definição das modificações arquiteturais necessárias para tornar o Ginga uma plataforma
genérica de suporte a aplicações sensíveis ao contexto. Essa etapa do trabalho foi desen-
volvida durante o projeto “GingaFrEvo & GingaRAP”.
4. Investigação de opções de comunicação entre o Ginga e dispositivos heterogêneos com o
intuito de definir a melhor tecnologia para a implementação do Gerenciador de Contexto.
33
5. Implementação de um protótipo da infraestrutura idealizada durante o passo 4
6. Definição de uma metodologia para o desenvolvimento de aplicações sensíveis ao contexto
que utilize o protótipo a infraestrutura implementada.
7. Desenvolvimento de um estudo de caso com o objetivo de avaliar o protótipo desenvolvido
e a metodologia proposta.
8. Elaboração do texto e defesa da dissertação.
1.4 Organização
Este trabalho é organizado da seguinte maneira:
• O Capítulo 2 introduz o referencial teórico do trabalho, apresentando os conceitos básicos
das áreas de Televisão Digital, Sensibilidade ao Contexto e Home Networks, necessários
para a contextualização e entendimento do trabalho.
• O Capítulo 3 descreve alguns trabalhos relacionados reportados na literatura focando espe-
cificamente o desenvolvimento de aplicações sensíveis ao contexto para a Televisão Digital e
a comunicação entre dispositivos eletrônicos e middleware utilizados na recepção dos sinais
de TV Digital Interativa.
• O Capítulo 4 introduz os principais pontos descritos no trabalho de Costa (2007), sobre os
quais esta dissertação está apoiada. O capítulo apresenta, ainda, a arquitetura conceitual
definida para o Gerenciador de Contexto do Ginga.
• O Capítulo 5 descreve a implementação do Gerenciador de Fontes de Contexto, componente
da arquitetura do Gerenciador de Contexto do Ginga apresentada no Capítulo 4. São
apresentados também as motivações que justificam as escolhas das ferramentas utilizadas
na implementação.
• O Capítulo 6 apresenta um resumo dos principais pontos do trabalho desenvolvido por Vale
(2011). É feita também uma breve discussão desse trabalho visando propor melhorias na
sua abordagem com a adoção do gerenciador apresentado no Capítulo 5.
34
• O Capítulo 7 descreve as modificações na abordagem utilizada por Vale (2011) e define a
metodologia de desenvolvimento de aplicações sensíveis ao contexto proposta para o cenário
do SBTVD.
• O Capítulo 8 descreve um estudo de caso que demonstra a viabilidade da utilização da
metodologia proposta nessa dissertação..
• O Capítulo 9 conclui o trabalho descrevendo as suas considerações finais e perspectivas de
trabalhos futuros.
Capítulo 2
Referencial Teórico
2.1 Introdução
Este capítulo introduz os principais conceitos das áreas de Televisão Digital, Sensibilidade ao
Contexto e Home Networks considerados necessários para a contextualização deste trabalho.
Na Seção 2.2 são destacados a arquitetura do middleware Ginga e abordados aspectos im-
portantes sobre a programação de aplicações para a TV Digital, com ênfase nas linguagens NCL
e NCLua; na Seção 2.3, são introduzidos conceitos sobre o universo das aplicações sensíveis ao
contexto, e discutidos aspectos e desafios importantes relacionados ao desenvolvimento dessas
aplicações para a TV Digital, como a aquisição de informações contextuais e a necessidade de
divisão de responsabilidades de desenvolvimento, bem como possíveis soluções; e na Seção 2.4,
finalmente, são apresentados conceitos básicos sobre as “Home Networks”, nas quais podem ser
encontradas soluções interessantes para os desafios envolvendo a aquisição e a manipulação de
fontes de dados contextuais.
2.2 Televisão Digital
2.2.1 Introdução
Televisão Digital é o nome comumente utilizado para definir a “nova” tecnologia adotada no
sistema de produção, transmissão e recepção de conteúdo televisivo que vem substituindo a
tecnologia mais antiga: a TV Analógica.
36
A Figura 2.1 mostra um modelo simplificado do sistema de TV Analógica tradicional.
Figura 2.1: Modelo simplificado de um sistema de TV analógica.
Como ilustrado na Figura 2.1, num sistema de TV Analógica tradicional, um programa
televisivo sendo transmitido ao vivo, por exemplo, tem seu áudio e vídeo capturados por câmeras
e microfones transformados em sinais eletromagnéticos e enviados via broadcast utilizando-se um
meio de comunicação, comumente o ar. Telespectadores em suas residências são capazes de
receber esse sinal que é captado pela antena do televisor e este utiliza as informações contidas
no sinal para exibir cada pixel de cada frame que compõe o vídeo na tela, e reproduzir cada
elemento de frequência e amplitude do som no sistema de áudio.
A primeira diferença entre o sistema de TV Analógica e o de TV Digital é em relação à
utilização de algoritmos de compressão de dados para a codificação do sinal capturado pelas
câmeras e microfones. Esses algoritmos são baseados nas características de percepção de sons e
imagens do ser humano. Esse processo proporciona duas vantagens principais: (i) permite que
seja possível a criação de mecanismos de correção de erros a serem utilizados na decodificação
feita no aparelho receptor, fazendo com que som e imagem recebidos sejam exatamente iguais
aos enviados, garantindo qualidade de som e imagem; e (ii) diminui a banda necessária para a
transmissão dos sinais capturados, permitindo o envio de som e imagem com uma maior resolução
e, principalmente, que sejam enviados outros tipos de dados, como outros vídeos, figuras e até
mesmo aplicações, as quais podem ser utilizadas como meio de interação entre usuário e a TV
para permitir, por exemplo, que o usuário pause filmes, veja informações sobre a programação,
etc. A esse tipo de aplicação é dado o nome de aplicações interativas e ao processo de interação
37
dá-se o nome interatividade.
A Figura 2.2 ilustra um típico sistema de TV Digital.
Figura 2.2: Modelo simplificado de um sistema de TV Digital. Fonte: (SOARES; BARBOSA,2008)
Como se pode ser visualizado na Figura 2.2, nesse novo paradigma, um programa de TV
pode ser considerado uma aplicação utilizada para gerenciar conteúdo multimídia sendo enviado.
Nesse caso, a aplicação e seu conteúdo (áudio e vídeo principais e demais mídias), produzidos
pela emissora, são multiplexados e enviados via broadcast. No sistema receptor, que pode ser um
Set-Top Box (STB) - aparelho receptor do sinal de TV Digital - ou um celular, por exemplo,
o sinal é demultiplexado, sendo que áudio e vídeo principais são enviados para os sistemas de
som e imagem do televisor e a aplicação é enviada para o middleware de TV Digital (destacado
na Figura 2.2), elemento do sistema receptor de TV Digital responsável por abstrair aspectos
específicos das plataformas receptoras e dar o suporte necessário para a execução das aplicações
sendo, portanto, elemento essencial para prover interatividade.
2.2.2 Interatividade
A interatividade é, sem dúvida alguma, um dos maiores benefícios providos pela TV digital, pois,
além de interações simples entre telespectador e aparelho televisor, como o controle das mídias
sendo exibidas, por exemplo, a interatividade pode permitir funcionalidades adicionais, como o
38
acesso a serviços disponíveis na Internet.
Dado o fato de que quase todos os domicílios brasileiros possuem pelo menos uma televisão,
enquanto poucos possuem computadores com acesso à internet (estatísticas da Pesquisa Naci-
onal de Amostras por Domicílio (PNAD) mostram que em 2009 95% dos domicílios brasileiros
possuíam televisão, mas apenas 27,4% possuíam computadores com acesso à internet (TELECO,
2011)), foi vislumbrada a possibilidade de transformar a TV Digital num meio essencial de in-
clusão digital e social. Sendo assim, foi instituído em 26 de Novembro de 2003, via decreto
presidencial número 4.901 (DP4901, 2003), o Sistema Brasileiro de Televisão Digital (SBTVD),
cujo padrão de middleware, definido posteriormente, pode ser utilizado para prover ao brasileiro
comum o acesso a serviços públicos digitais, como serviços de educação à distância, serviços
governamentais, serviços de saúde ou “simplesmente” o acesso à internet.
2.2.3 Ginga: O middleware do SBTVD
Ginga é o nome do middleware do SBTVD. Como discutido na seção anterior, sua principal
função é abstrair aspectos específicos das plataformas receptoras, que podem ser de tecnologias
variadas, e dar o suporte necessário para a execução das aplicações, de acordo com os requisitos
estabelecidos no padrão do SBTVD.
A arquitetura do Ginga foi estabelecida de acordo com as necessidades que os aplicativos
de TV digital demandam. Em geral, estes aplicativos podem ser desenvolvidos seguindo dois
paradigmas de programação: o imperativo e o declarativo. A escolha do paradigma depende
exclusivamente das necessidades e do tipo de aplicativo em questão. O middleware Ginga possui
dois subsistemas lógicos para lidar com estas possibilidades: a Máquina de Apresentação Ginga-
NCL (SOARES; RODRIGUES; MORENO, 2007), para o paradigma declarativo e a Máquina
de Execução Ginga-J (FILHO; LEITE; BATISTA, 2007), para o paradigma imperativo.
Estes subsistemas compartilham um terceiro componente arquitetural denotado por Common
Core (ou Ginga-CC). A Figura 2.3 apresenta uma visão macro da arquitetura, relacionando
estes três componentes. Percebe-se que embora Ginga-J (Ambiente de execução) e Ginga-NCL
(ambiente de apresentação) sejam componentes distintos, existe uma relação entre eles, de modo
que aplicações declarativas podem fazer referência às imperativas e vice-versa.
O Ginga-J, ilustrado na parte superior esquerda da Figura 2.3, é o subsistema lógico do
39
Figura 2.3: Arquitetura do Ginga. Fonte: (SOARES, 2009)
Ginga responsável pelo processamento de aplicativos para TV digital escritos em Java (também
conhecidos como Xlets). Esta especificação incorpora novas funcionalidades, mas mantém com-
patibilidade com a maior parte dos middleware de TV digital compatíveis com o GEM, uma
especificação unificada proposta pelo grupo europeu DVB para middleware de TV digital).
Pelo fato de não ser obrigatória a implementação do subsistema Ginga-J em todos os tipos
de dispositivos receptores (ABNT, 2007a, pág.14), este trabalho considera apenas o ambiente
declarativo Ginga-NCL e o paradigma declarativo.
O Ginga-NCL, ilustrado na parte superior direita da Figura 2.3, é o subsistema responsável
pelo ambiente declarativo do Ginga. Sua principal funcionalidade é o processamento de docu-
mentos NCL (Nested Context Language). NCL é uma linguagem de aplicação XML (eXtensible
Markup Language) com facilidades para a especificação de aspectos de interatividade, sincro-
nismo espaço-temporal entre objetos de mídia, adaptabilidade, suporte a múltiplos dispositivos
e suporte à produção ao vivo de programas interativos não-lineares. NCL aceita também objetos
imperativos chamados NCLua, os quais devem ser escritos em linguagem Lua (LUA, 1993).
O suporte a múltiplos dispositivos foi originalmente inserido no padrão do Ginga motivado,
principalmente, pelas vantagens proporcionadas pela utilização de múltiplos dispositivos de exi-
bição, como a possibilidade de se obter múltiplas navegações individuais em dispositivos variados
de um mesmo conteúdo recebido pela TV (COSTA; MORENO; SOARES, 2009). O padrão define
dois tipos de classes de dispositivos utilizados para este fim: a classe passiva, cujos dispositivos
40
exibem o mesmo conteúdo sob controle de navegação único; e a classe ativa, onde o controle da
apresentação é feito individualmente. Essa característica é refletida na linguagem NCL, onde é
possível direcionar as mídias a serem exibidas para os dispositivos cadastrados em uma dessas
classes (a implementação de novas classes é possível, porém específica da implementação, assim
como a implementação dos mecanismos de registro e gerenciamento de dispositivos).
A função do Common Core é prover serviços comuns necessários para o funcionamento dos
ambientes declarativo e imperativo. Dentre estes serviços podem ser citados como exemplos
a decodificação e demultiplexação do conteúdo transportado via MPEG-2 Transport Stream e
decodificação/apresentação de mídias em diversos formatos.
Apesar de serem componentes opcionais da arquitetura do Ginga-CC, o Gerenciador de
Contexto e o Canal de Interatividade são elementos essenciais para enriquecer a execução de
aplicações interativas na TV Digital. O Gerenciador de Contexto é o elemento responsável por
colher e armazenar informações sobre o receptor, o telespectador e sua localização e disponibilizá-
las para que as aplicações as utilizem para adaptar seu comportamento, ou para exibí-las na tela
(SOARES, 2009). A forma com que essas informações devem ser adquiridas não é padronizada;
logo, depende da implementação específica do middleware. Quais informações são armazenadas e
como elas devem ser acessadas pelas aplicações, porém, são padronizados. O acesso, por exemplo,
deve ser feito por meio da utilização do nó settings, elemento de mídia do tipo application/x-
ginga-settings (Seção 2.2.4.1). É importante ressaltar que a restrição imposta pelo padrão sobre
as informações a serem utilizadas restringe também a gama de domínios a serem explorados por
aplicações sensíveis ao contexto. Uma forma de adquirir essas e outras informações utilizando
apenas funcionalidades do padrão é por meio do Canal de Interatividade via protocolo TCP/IP
(ABNT, 2008), o qual pode ser acessado pela aplicação por meio de objetos NCLua, o que ajuda a
contornar as restrições impostas pelo Gerenciador de Contexto padrão citadas anteriormente. Ao
longo deste trabalho às informações sobre receptor, telespectador, localização, e a qualquer outra
que possa ser utilizada para caracterizar o contexto em que uma aplicação está sendo apresentada,
dá-se o nome de “informação contextual”, e às aplicações que utilizam essa informação para
adaptar seu comportamento dá-se o nome de “aplicações sensíveis ao contexto” (ver Seção 2.3).
Numa aplicação interativa sensível ao contexto no domínio de saúde, por exemplo, o Geren-
ciador de Contexto poderia interagir com o Canal de Interatividade para recuperar informações
sobre os sinais vitais do telespectador cardíaco e disponibilizá-las para a aplicação. Caso a
41
aplicação detecte alguma anomalia, ela pode automaticamente acionar um serviço médico de
emergência provido por algum hospital público, o que também poderia ser feito pela utilização
do Canal de Interatividade.
Pode-se dizer, então, que aplicações sensíveis ao contexto para a TV Digital podem ser
implementadas nas linguagens NCL e Lua e devem utilizar os componentes Gerenciador de
Contexto e Canal de Interatividade do Ginga-CC.
2.2.4 Aplicações Declarativas para o Ginga
As aplicações do ambiente declarativo da TV Digital, como já dito anteriormente, devem ser
escritas em NCL. Em NCL há uma separação entre os conteúdos, ou mídias, a serem exibidos,
como textos, vídeos, áudios, etc, e a estrutura da exibição dessas mídias, ou seja, a especificação
de qual mídia deve ser exibida, quando ela deve ser exibida e onde (região da tela, ou até mesmo
outros dispositivos).
Caso seja necessária a execução de código imperativo, para acesso ao Canal de Interatividade,
por exemplo, deve ser incluída na aplicação NCL uma mídia NCLua apontando para seu arquivo
de implementação, chamado de script Lua, que, quando inicializada pela aplicação, executa seu
código.
2.2.4.1 Linguagem NCL
A linguagem NCL é baseada em módulos, que são “coleções de elementos, atributos e valores
de atributos XML semanticamente relacionados que representam uma unidade de funcionali-
dade” (ABNT, 2007b). Os módulos de NCL são agrupados em áreas funcionais que definem os
elementos da linguagem e suas funcionalidades.
A área funcional Presentation Control, por exemplo, pode ser utilizada para controlar e
adaptar a exibição de conteúdo. Isso é feito com a utilização de seus elementos switch, que
utilizam regras lógicas por meio de elementos rule que operam sobre variáveis, cujos valores
determinam se a aplicação terá este ou aquele comportamento. Essas variáveis são, por padrão,
propriedades de um nó settings, elemento do tipo mídia (discutido à seguir) que, como já exposto
anteriormente, é gerenciado pelo Gerenciador de Contexto padrão. Esses recursos podem ser
utilizados para a implementação de aplicações que manipulam contextos simples, que dependam
42
apenas das informações contidas no padrão, como perfil do usuário e localização. Esses recursos,
porém, não são suficientes para atender à maioria dos requisitos associados ao desenvolvimento
de aplicações sensíveis ao contexto mais complexas (Seção 2.3).
Ao longo de outros trabalhos que também visam a implementação de uma infraestrutura
adequada para manipulação de contexto no Ginga (VALE, 2011) (MIELKE, 2010), foi perce-
bida a importância de outras áreas funcionais para o desenvolvimento de aplicações sensíveis ao
contexto: Components, Interfaces, Connectors e Linking.
Components são os elementos de NCL utilizados para encapsular os objetos de mídia, cujos
aspectos espeço-temporais são controlados pela aplicação. Cada objeto de mídia pode possuir
um id, um atributo src indicando de onde a mídia pode ser carregada, um type indicando o tipo
da mídia (áudio, vídeo, ts, script Lua etc.), e um descriptor, elemento de outra área funcional
que descreve como a mídia deve ser apresentada.
Interfaces são os elementos de NCL utilizados para a definição de interfaces nos objetos de
mídia que podem ser acessadas por outros objetos da linguagem para permitir, por exemplo, o
controle dessas mídias. Um exemplo de interface são as âncoras de propriedades, que definem
propriedades relacionadas às mídias. No caso de uma mídia NCLua, por exemplo, essas propri-
edades podem ser alteradas por outros elementos da linguagem alterando a execução do script
referente a essa mídia.
Connectors e Linking são os elementos de NCL que podem ser combinados para definir, o
relacionamento causal entre elementos de mídia. Assim eles podem ser utilizados para definir,
por exemplo, que o texto “a” deve ser exibido assim que o vídeo “b” terminar, ou ainda, que se o
valor da propriedade “sinais_vitais” da mídia NCLua “joao” for alterado para “alerta”, as mídias
de vídeo “vídeo_primeiros_socorros” e NCLua “web_service_hospital” devem ser inicializadas.
Elementos dos connectors, os conectores causais causalConnectors definem os papéis envol-
vidos na relação de causa e efeito, ou condição e ação, que podem ser simples (simpleCondition
e simpleAction) ou compostas (compoundCondition e compoundAction). As condições podem
ser utilizadas para monitorar eventos de transição simples, como o início ou o fim de um vídeo,
por meio de condições simples monitorando transições de mídia (transition), ou avaliação de
valores de atributos das mídias, ou de expressões, por meio dos elementos assessmentStatement
e compoundStatement.
43
Esses papéis são preenchidos por elementos de mídia, por exemplo, com a utilização do links
por meio do seu elemento bind.
A Figura 2.4 mostra um exemplo de código NCL para exemplificar a utilização desses ele-
mentos.
Figura 2.4: Exemplo de código NCL
O código NCL apresentado na Figura 2.4 é utilizado para manipular duas mídias: um vídeo,
e uma imagem que contém uma mensagem de pause. Essas mídias estão localizadas na pasta
media, como pode ser visualizado no campo src das mesmas (linhas 21 e 24). Informações sobre
como e onde essas mídias serão exibidas são definidas pelos elementos descritores (descriptors)
que apontam para nós de região (region), que podem indicar a região da tela e as dimensões das
mídias a serem exibidas. O conector causal onPauseStart define os papéis de condição e ação
onPause e start que são preenchidos pelas mídias video e pause por meio de um link, fazendo
com que sempre que o vídeo é pausado, a imagem de pause seja exibida.
2.2.4.2 Objetos NCLua
Como já visto anteriormente, caso seja necessária, por parte da aplicação, a execução de código
imperativo, isso pode ser feito pela inclusão de objetos NCLua via nós de mídia de NCL.
Objetos NCLua são utilizados para permitir que a aplicação NCL principal seja estendida
por meio de scripts escritos na linguagem NCLua - resultado da extensão da linguagem Lua
44
(LUA, 1993) para prover funcionalidades necessárias para atender os requisitos do padrão do
SBTVD (ABNT, 2007b). Aplicações NCL devem, por exemplo, fazer uso de scripts NCLua para
acessar o Canal de Interatividade. Nesse caso, os scripts geralmente são responsáveis por efetuar
a troca de dados, processar informações e realizar comunicação com o documento NCL.
O ambiente de NCLua adota um mecanismo de comunicação assíncrono, baseado em eventos.
Os objetos NCLua, por meio de seus scripts, atuam como tratadores de eventos, enviando eventos
para, e recebendo de, outros elementos. Para isso deve ser utilizado o módulo event, da biblioteca
padrão. Um script pode receber eventos vindos da Emissora (eventos da classe si) e do Controle
Remoto (eventos da classe key), além de enviar e receber eventos do Canal de Interatividade
(eventos da classe tcp) e do Formatador NCL (eventos da classe ncl), que nesse caso representa
o documento NCL que inicia o script NCLua. Um script NCLua pode, também, enviar eventos
a si mesmo por meio de eventos da classe user.
Devido à capacidade de comunicação com o meio externo provida pela interação entre ob-
jetos NCLua e o Canal de Interatividade via eventos tcp, pode-se dizer que esses elementos são
essenciais para o desenvolvimento de aplicações sensíveis ao contexto para a TV Digital.
2.3 Aplicações Sensíveis ao Contexto
2.3.1 Introdução
No início dos anos 90, Weiser (1991) introduziu o termo “Computação Ubíqua” para representar
um novo paradigma na interação entre usuário e computadores ao vislumbrar ambientes que, por
meio de dispositivos distribuídos e objetos acrescidos de recursos computacionais, são capazes
de prover serviços e informações quando e onde desejados pelo usuário (everywhere, everytime
computing) (WEISER, 1991). Dentre as novas classes de aplicações que surgiram a partir desse
cenário, estão as Aplicações Sensíveis ao Contexto: aplicações cujo comportamento é afetado
pelo contexto do usuário e do ambiente que o cerca. Evidentemente, essa definição não diz muito
sem que seja definido, também, o conceito de contexto.
A definição de contexto mais referenciada na literatura diz que contexto é aquela apresentada
por (DEY, 2000), que diz que contexto é “qualquer informação que pode ser utilizada para
caracterizar a situação de entidades que seja considerada relevante para a interação entre usuário
45
e aplicação”. Uma definição mais abrangente, proposta por Costa (2007), diz que contexto é
“um conjunto de condições, possivelmente relacionadas, nas quais uma entidade existe”. Esta
é a definição adotada neste trabalho. Ao primeiro conceito é dado o nome de “Informação
Contextual” (COSTA, 2007).
A Figura 2.5 ilustra uma aplicação sensível ao contexto e suas interações com um usuário e
seu contexto.
Figura 2.5: Aplicação sensível ao contexto e suas interações. Fonte: (COSTA, 2007)
Na Figura 2.5, a seta “a” representa as interações explícitas entre o usuário e a aplicação: o
usuário entra com um comando, ou informação, e a aplicação executa ações e/ou retorna informa-
ções ao usuário. Aplicações “tradicionais”, ou seja, que não suportam sensibilidade ao contexto,
oferecem apenas esse tipo de interação, e suas ações e resultados apresentados como respostas
aos comandos do usuário são baseados apenas nas informações já existentes na aplicação, ou nas
que foram informadas pelo usuário.
Aplicações sensíveis ao contexto suportam também interações implícitas com o contexto do
usuário, representadas na Figura 2.5 pela seta “b”. Essas interações podem ser feitas automa-
ticamente, por exemplo, por meio da interação da aplicação com sensores, outros dispositivos
eletrônicos, ou serviços web.
Para exemplificar uma aplicação sensível ao contexto e suas interações com um usuário e seu
contexto, propõe-se o seguinte cenário:
“João possui um smartphone com um navegador web sensível ao contexto. João é um ótimo
cozinheiro e quando está na cozinha, ele costuma utilizar o navegador do seu telefone para
acessar seu site de receitas predileto. Por ser sensível ao contexto, o navegador é capaz de abrir
46
diretamente o site de receitas quando João acessa o navegador da cozinha.”
A Figura 2.6 instancia a ilustração genérica da Figura 2.5 para representar o cenário proposto.
Figura 2.6: Navegador Web Sensível ao Contexto e suas interações.
Na ilustração da Figura 2.6 tem-se que o usuário é João, a aplicação é o Navegador, as
interações explícitas são os comandos efetuados por João para navegar no Browser e as interações
implícitas podem ser feitas por sensores espalhados pelos cômodos da casa se comunicando com
o telefone de João e que indicam exatamente em qual cômodo ele se encontra.
Ao se analisar o exemplo ilustrado pela Figura 2.6, pode parecer que o desenvolvimento de
aplicações sensíveis ao contexto não se difere muito do das tradicionais. Porém, ao se aumentar a
complexidade dos cenários vislumbrados e, consequentemente, das aplicações desenvolvidas para
atendê-los, o desenvolvimento dessas aplicações pode se tornar bastante complexo.
2.3.2 Desenvolvimento de Aplicações Sensíveis ao Contexto
Em geral, uma aplicação sensível ao contexto deve ser capaz de (i) captar o contexto do usuário,
por meio de várias fontes, como sensores, outros dispositivos eletrônicos, ou serviços web, por
exemplo; (ii) utilizar o contexto captado para compor informação contextual; (iii) automatica-
mente detectar mudanças no contexto que sejam relevantes para a aplicação; (iv) reagir a essas
mudanças adaptando seu comportamento e/ou invocando ações; e (v) interoperar com serviços
47
providos por terceiros (COSTA, 2007).
Essas funcionalidades, impõem vários desafios para o desenvolvimento de aplicações sensíveis
ao contexto. Pessoa (2006) apresenta uma lista não exaustiva de tais desafios: (i) a definição de
um modelo adequado de contexto; (ii) o suporte à adaptabilidade das aplicações; (iii) a resolução
de conflitos e a suporte à colaboração entre aplicações; (iv) a descoberta, seleção e composição
dinâmica de serviços; (v) o estabelecimento de mecanismos de controle de privacidade e segu-
rança das informações contextuais; (vi) a definição de estratégias de aquisição, armazenamento
e interpretação de contexto; (vii) o acesso e a integração de dados provenientes de sensores e
dispositivos distribuídos e heterogêneos; (xiii) o apoio à personalização de serviços; (ix) a utili-
zação de mecanismos de persistência dos dados contextuais; (x) o uso adequado de linguagens
de subscrição e de solicitação de serviços; além de muitos outros.
Muitas vezes, aplicações sensíveis ao contexto, oferecem serviços implementados por enti-
dades provedoras de serviços distintas. O desenvolvimento de tais aplicações integralmente por
apenas uma dessas entidades pode, portanto, ser inviável (COSTA, 2007). Isso fica bem claro ao
se considerar cenários envolvendo a TV Digital, onde as aplicações sensíveis ao contexto são envi-
adas via broadcast e devem ser capazes, por exemplo, de se comunicar com dispositivos residentes
na casa dos telespectadores.
Suponha, por exemplo, que uma emissora de TV “X” com a programação direcionada a
idosos deseja enviar junto a sua programação uma aplicação que monitore alguns sinais vitais do
telespectador a fim de apresentá-los na tela do televisor e, ainda, automaticamente acionar algum
serviço médico caso o mesmo apresente algum sinal de necessidade de atendimento médico de
emergência. Se a emissora se propusesse a desenvolver integralmente tal aplicação, ela deveria:
• Desenvolver na aplicação um mecanismo para permitir que ela se comunique com dispositi-
vos médicos, como holters, ou monitores de sinais vitais, a fim de coletar dados (contextuais)
para apresentá-los na tela e para que a aplicação possa prever a iminência de um ataque.
Para isso, a emissora deve se preocupar com as seguintes questões:
– Implementar os protocolos de comunicação específicos dos equipamentos utilizados
para a aquisição das informações de sinais vitais no formato em que eles são disponi-
bilizados.
48
– Implementar como e quando esses dados devem ser apresentados para os telespecta-
dores.
• Desenvolver na aplicação um mecanismo para processar os dados adquiridos para identificar
quando o telespectador necessita de atendimento. Para isso, a emissora ainda deveria se
preocupar com a seguinte questão:
– Implementar o processamento necessário, por meio de uma determinada tecnologia
que utilize conhecimentos da área de medicina, para identificar um eventual problema
de ordem médica a partir de dados de sinais vitais específicos.
• Desenvolver na aplicação um mecanismo para acionar um serviço médico de emergência
para atender o telespectador caso necessário. Para isso, a emissora ainda deveria se preo-
cupar com a seguinte questão:
– Implementar os protocolos de comunicação específicos de uma entidade de atendi-
mento médico para acionar um serviço de emergência.
A emissora deveria se preocupar com todos esses aspectos, além, é claro, dos aspectos ineren-
tes ao próprio conteúdo televisivo enviado por ela. Percebe-se, portanto, que o desenvolvimento
dessa aplicação é extremamente complexa para ser feita unicamente pela emissora, até porque
existem várias entidades envolvidas nesse processo, como fabricantes de dispositivos de monito-
ramento médico, especialistas na área médica e serviços hospitalares, dentre outros. Logo, vê-se
que o desenvolvimento de aplicações sensíveis ao contexto deve envolver todas as entidades que
fazem parte do negócio da aplicação, e cada entidade geralmente concentra os seus esforços na
resolução de apenas uma parte dos desafios impostos pelo desenvolvimento dessas aplicações,
não sendo responsável por todos eles.
No cenário apresentado, o desenvolvimento poderia ser dividido da seguinte maneira:
• Empresas de equipamentos médicos poderiam disponibilizar um software embarcado em
seus dispositivos que disponibilizasse os dados contextuais adquiridos para as aplicações,
abstraindo a tecnologia utilizada para a sua aquisição.
• Empresas especializadas no domínio médico poderiam disponibilizar um serviço que pudesse
ser acessado por dispositivos receptores de sinais de TV que utilizasse os dados adquiridos
49
pelos equipamentos e disparasse ações indicando a possibilidade de uma futura emergência
médica.
• Hospitais, públicos ou privados, podem disponibilizar um webservice que seria utilizado
para o acionamento de emergências médicas, podendo ser acessado por uma aplicação de
TV Digital via Canal de Interatividade.
Nesse caso a emissora “X” pode se preocupar apenas com o seu conteúdo televisivo e com o
acesso à plataforma para simples exibição de dados de contexto na tela, caso fosse de interesse
do telespectador.
Soluções para a divisão de responsabilidades, assim como para outros desafios impostos pelo
desenvolvimento dessas aplicações podem ser encontradas na literatura por meio de soluções
arquiteturais para suportar o desenvolvimento e a execução das mesmas.
2.3.2.1 Arquiteturas
A fim de facilitar o desenvolvimento de aplicações sensíveis ao contexto, ao levar em consideração
os desafios impostos pela realização dessa tarefa, são definidas na literatura algumas arquiteturas
de middleware que permitem que o desenvolvedor se preocupe apenas com os aspectos específicos
da aplicação, ou seja, com as interações tradicionais entre usuário e software, e possa delegar
as funcionalidades de sensibilidade ao contexto para o middleware. Alguns exemplos dessas
arquiteturas podem ser encontrados em (DEY, 2000), (CHEN, 2004), (GU; PUNG; ZHANG,
2005), (PESSOA, 2006) e (COSTA, 2007).
Mais especificamente, para viabilizar a divisão de responsabilidades do desenvolvimento de
aplicações sensíveis ao contexto pelas entidades envolvidas no negócio da aplicação, para solucio-
nar os problemas causados pelos desafios encarados por cada entidade ao lidar com sua respectiva
parte da implementação, e para facilitar o desenvolvimento de tais aplicações como um todo,
Costa (2007) define uma arquitetura conceitual orientada a serviços chamada “Plataforma de
Manipulação de Contexto” (Context Handling Platform).
A plataforma proposta por Costa (2007) provê elementos de software definidos com a utili-
zação de padrões arquiteturais, que oferecem serviços genéricos e que podem ser especializados
de forma a se adaptar aos requisitos de uma determinada aplicação. Seus elementos e respectivos
50
serviços podem ser implementados pelas diferentes entidades envolvidas no negócio da aplicação,
e uma aplicação sensível ao contexto que utilize a plataforma poderia delegar-lhe o controle do
seu comportamento reativo.
Para que seja possível a configuração automática da plataforma, já que seus elementos são
implementados por entidades diferentes, é necessário que haja o mesmo entendimento do domí-
nio da aplicação entre todas as partes envolvidas no desenvolvimento e que toda as etapas da
implementação estejam comprometidas com o mesmo entendimento. Esse entendimento pode
ser viabilizado pela utilização de modelos de contexto e situações, além da especificação do
comportamento reativo da aplicação.
2.3.2.2 Modelagem de Contexto, Situações e Comportamento Reativo
A modelagem de contexto, situações e regras deve permitir definir e especificar formalmente
o domínio da aplicação, assim como o comportamento reativo das aplicações, abstraindo-se
quaisquer características referentes à implementação.
A modelagem de contexto e situações permite a especificação das entidades envolvidas na
aplicação, quais são as informações contextuais dessas entidades e as situações que as envolvem
que são relevantes para a aplicação, onde situações podem ser consideradas informações de
mais alto nível, com características temporais, que indicam quando um conjunto de informações
contextuais estão dentro de um certo intervalo de valores relevantes. Um exemplo de informação
contextual seria “temperatura ambiente”, enquanto que a situação “está calor” existiria para os
casos onde “temperatura ambiente” possui valores acima de 30 graus.
Observa-se que a utilização de um modelo formal, como o adotado em (COSTA, 2007),
apresenta uma série de vantagens, pois possibilita: (i) a definição de modelos não ambíguos;
(ii) a delimitação precisa do escopo dos estados contextuais possíveis da aplicação; e (iii) o
entendimento entre os envolvidos no desenvolvimento de aplicações sensíveis ao contexto.
2.3.2.3 Metodologia de Desenvolvimento
Para que haja sucesso na utilização de uma plataforma que suporte o desenvolvimento e a
execução de aplicações sensíveis ao contexto, levando em consideração que os elementos dessa
plataforma serão implementados por entidades diferentes e que a plataforma deve ser capaz de
51
se auto-configurar para controlar o aspectos relativos à sensibilidade ao contexto, é necessário
que a metodologia de desenvolvimento de cada parte da aplicação seja integrada. Ou seja, a
especificação do comportamento reativo da aplicação deve levar em consideração a modelagem
de contexto e de situações, assim como a implementação dos elementos da plataforma proposta
para suportar tais aplicações também deve se comprometer à essa modelagem.
Costa (2007) define ferramentas que possibilitam uma abordagem integrada para o desenvol-
vimento de aplicações sensíveis ao contexto, partindo da definição de abstrações para modelagem
contextual e de situações, passando pela definição de uma linguagem baseada em regras para
a especificação do comportamento reativo das aplicações até a definição de uma arquitetura
conceitual para uma plataforma que dê suporte a essas aplicações.
Um resumo do trabalho de Costa (2007) é apresentado no Capítulo 4. Seus conceitos são
utilizados para a definição de uma arquitetura conceitual para o Gerenciador de Contexto do
Ginga e para a definição de uma metodologia de desenvolvimento de aplicações sensíveis ao
contexto que utilizem essa arquitetura.
2.3.3 Aquisição de Informações Contextuais
Dey (2000) diz que uma das razões pelas quais aplicações sensíveis ao contexto ainda não se
tornaram mais comuns, é que não existe uma forma padronizada de adquirir e tratar informações
contextuais e, comumente, isso é feito de forma “ad hoc”, de acordo com cada dispositivo de
hardware a ser utilizado, na medida em que os desenvolvedores das aplicações escolhem a forma
mais fácil de implementar, sob pena da perda da generalidade e do reuso.
Especificamente no cenário da TV Digital, onde aplicações sensíveis ao contexto são enviadas
via broadcast e devem se comunicar com dispositivos interagindo com os receptores do sinal tele-
visivo, essa abordagem não funciona: um receptor “A”, por exemplo, pode obter uma informação
de localização pela interação com um dispositivo da tecnologia “X”, enquanto que um receptor
“B”, recebendo o mesmo sinal com a mesma aplicação, pode obter essa mesma informação pela
interação com um dispositivo da tecnologia “Y”.
É necessário, portanto, que exista um serviço genérico de aquisição de informações contex-
tuais, que possa ser utilizado pelos receptores para abstrair aspectos específicos da tecnologia
utilizada pelos dispositivos para a aquisição e encapsulamento das informações.
52
A arquitetura definida em (COSTA, 2007) permite a generalização do acesso a essas infor-
mações pela aplicação ao definir serviços que podem ser implementados por especialistas nos
dispositivos específicos a serem utilizados pela aplicação. Deve existir, portanto, uma infraestru-
tura que permita que esses serviços sejam cadastrados e acessados pelas aplicações.
Funcionalidade padrão do Ginga, o suporte a múltiplos dispositivos poderia ser explorado
de forma a prover tal infraestrutura. Como já exposto na Seção 2.2.3, esse suporte foi incluído
no padrão motivado, principalmente, pelas vantagens proporcionadas pela exibição de conteúdo
distribuída; porém, já existem trabalhos no sentido de estender essas funcionalidades para a inte-
ração entre o Ginga e dispositivos variados como os de redes de dispositivos domésticos (UPnP,
OSGi, etc). Em Batista, Soares e Filho (2010), por exemplo, é proposta uma implementação
do Ginga onde novas classes de dispositivos e suas características podem ser cadastradas dina-
micamente, permitindo que o receptor acesse serviços de dispositivos nessas redes. Essa nova
implementação, porém, demanda a utilização de implementações de módulos NCLua que não
estão no padrão (LuaTV (ANDO et al., 2010)); logo, essa alternativa não será considerada no
contexto deste trabalho.
Como alternativa, essa infraestrutura pode ser baseada, por exemplo, na comunicação entre
o Ginga, via módulos NCLua do padrão, e frameworks utilizados em Home Networks, como
UPnP, Jini ou OSGi, utilizados para controle e interação entre dispositivos heterogêneos, e que
são introduzidos brevemente a seguir.
2.4 Home Networks
2.4.1 Introdução
Home Networks é um termo comumente utilizado para se referir a redes de dispositivos dos mais
diversos tipos que interagem entre si, independentemente da tecnologia por eles utilizada, para
prover serviços que podem ser acessados num ambiente doméstico. Entre os serviços oferecidos
podem ser citados os de conexão entre redes internas e externas; serviços de entretenimento,
normalmente associados ao uso de mídias; serviços de comunicação; e serviços de controle e
acesso remoto de dispositivos da residência.
Nesse ambiente tão heterogêneo, envolvendo a necessidade de interação entre dispositivos
53
de tantas tecnologias diferentes, um de seus elementos, chamado Home Gateway, ou Residential
Gateway, é o responsável por prover o ambiente para execução de aplicações e entrega de serviços,
locais ou remotos, relacionados a dispositivos da residência (VIANA, 2009).
Devido à complexidade dos serviços entregues às Home Networks e a heterogeneidade dos
dispositivos, Home Gateways agregam uma infinidade de interfaces de comunicação (USB, Ether-
net, Serial, Wi-fi etc.) e implementam componentes de software que agregam serviços providos
pelos diversos dispositivos a ele conectados via rede ou diretamente. Esses componentes são im-
plementações de elementos dos chamados frameworks para Home Networks, dos quais podem ser
citados UPnP, Jini e OSGi, que abstraem aspectos específicos sobre a forma de acesso e controle
dos dispositivos.
Frameworks para Home Gateways surgem como uma solução interessante para o controle do
acesso a dispositivos heterogêneos, que passam a abstrair seus aspectos específicos de implemen-
tação pelo oferecimento de serviços disponibilizados na rede.
Vislumbrou-se então neste trabalho a possibilidade de se utilizar da interação entre aparelhos
receptores de TV Digital e frameworks de Home Gateways para permitir a abstração, para as
aplicações sensíveis ao contexto enviadas pelas emissoras de TV Digital, do acesso a informações
contextuais disponíveis por esses dispositivos heterogêneos.
Uma apresentação sucinta desses frameworks é apresentada a seguir, acompanhada da jus-
tificativa pela escolha do OSGI como tecnologia de framework na implementação do Gerente de
Contexto do Ginga.
2.4.1.1 Jini
Jini é uma arquitetura de rede, baseada na tecnologia Java, para construção de sistemas distri-
buídos na forma de serviços modulares que cooperam entre si. A base de sua arquitetura está
na implementação do paradigma publish-find-bind das arquiteturas orientadas-a-serviços. Jini
oferece um serviço de lookup, ou descoberta, centralizado. O desenvolvedor que pretende publi-
car serviços oferecidos por seu dispositivo deve implementar um Network Service, que procura o
serviço de descoberta oferecido pelo Jini e os cadastra para que outro elemento, que pode ser um
programa, ou outro dispositivo, que implemente um Network Client possa descobrir seus serviços
e acessá-los.
54
2.4.1.2 UPnP
O Universal Plug and Play é uma iniciativa da Microsoft para estender o paradigma do Plug
and Play, que simplifica a inclusão de periféricos aos computadores, para plataformas de rede
distribuídas, habilitando o registro, descoberta e controle de dispositivos.
Os componentes básicos do UPnP são Dispositivos, Serviços e Pontos de Controle. Um
dispositivo contém serviços e dependências com outros dispositivos, que são descritos em docu-
mentos XML. Um serviço consiste em uma tabela de estados, que mantem o estado dos serviços
e de variáveis; um servidor de controle, que atualiza os estados e invoca ações de acordo com as
requisições; e um servidor de eventos que disponibiliza os serviços na rede. Pontos de Controle
são os mecanismos por meio dos quais dispositivos são descobertos na rede. Como, deferente-
mente do Jini, não existe um elemento central de registro e descoberta de serviços, isso deve ser
feito no próprio dispositivo via Ponto de Controle. Os elementos do UPnP são implementados
sobre os protocolos de rede tradicionais, como TCP/IP, DHCP, HTTP, etc. O desenvolvedor
que pretende publicar serviços oferecidos por seu dispositivo numa rede UPnP deve, portanto,
implementar seus elementos (Dispositivo, Serviços e Pontos de Controle) e utilizar as pilhas de
protocolo de rede tradicionais.
2.4.1.3 OSGi
OSGi é a especificação de um framework definido pelo consórcio Open Service Gateway initiative
com suporte à implementação de aplicações Java no modelo orientado a serviços. No topo da
arquitetura do OSGi se encontram os bundles, que correspondem às implementações, por parte
dos programadores, dos serviços citados anteriormente.
Logo abaixo existe a camada de Serviços, onde se encontra o Registry Service, usado para
conectar os bundles dinamicamente através do paradigma publish-find-bind (“publicar- achar-
conectar”). O Registry Service provê um serviço de registro, onde cada bundle pode publicar
os seus serviços disponíveis, e um de descoberta de serviços, no qual um bundle descobre quais
outros serviços estão disponíveis para utilização. No OSGi, um serviço é uma interface Java
associada à operações implementadas pelo bundle que oferece o serviço.
O desenvolvedor que pretende publicar serviços oferecidos por seu dispositivo no OSGi pode
fazê-lo implementando um bundle, que trate dos aspectos específicos de comunicação com seu
55
dispositivo para executar o serviço quando requisitado.
Assim como o Jini e o UPnP, o OSGi possibilita a abstração de aspectos específicos dos
dispositivos por meio do oferecimento de serviços, que podem ser descobertos na rede. Essas
características são fundamentais para garantir a possibilidade de aquisição de informações con-
textuais providas por dispositivos heterogêneos independentemente da tecnologia de comunicação
e de forma transparente para o usuário. O grande diferencial do OSGi, porém, é que ele per-
mite que os elementos dos outros frameworks sejam implementados por bundles, promovendo a
integração entre diversos outros frameworks, como o Jini e o UPnP. Existem, por exemplo, imple-
mentações das especificações Jini Driver e UPnP Base Driver, que permitem a integração entre
redes Jini, UPnP e OSGi. Este fator foi determinante para a escolha do OSGI como tecnologia
de implementação do Gerente do Contexto proposto.
2.5 Conclusões do Capítulo
Este capítulo apresentou conceitos relacionados a três áreas distintas que apresentam um grande
potencial de integração no cenário atual da computação. Inicialmente, pode-se destacar o grande
diferencial que a TV Digital oferece aos para seus usuários ao permitir a execução de aplicações
interativas. Essas aplicações interativas podem ser enriquecidas com informações contextuais,
constituindo as chamadas aplicações sensíveis ao contexto. Essas aplicações, devido a sua com-
plexidade, possuem requisitos que demandam a utilização de técnicas e ferramentas específicas
para seu desenvolvimento. Um desses requisitos é a necessidade de um suporte para acesso ho-
mogêneo a informações contextuais, para o qual a utilização de tecnologias de frameworks de
Home Networks surge como bastante conveniente.
A convergência dessas três áreas, portanto, é bastante oportuna os propósitos do presente tra-
balho. Iniciativas que propõem essa integração, porém, ainda são muito incipientes. O próximo
capítulo traz uma breve descrição de alguns trabalhos que tratam dessa tentativa de integração.
Capítulo 3
Trabalhos Relacionados
3.1 Introdução
Este capítulo apresenta alguns trabalhos encontrados na literatura que propõem algum tipo de
infraestrutura visando facilitar o desenvolvimento de aplicações sensíveis ao contexto para a
Televisão Digital.
Uma investigação da literatura das áreas de Computação Sensível ao Contexto e TV Digital
revela que o estudo sobre infraestruturas de suporte a aplicações sensíveis ao contexto no cenário
da TV Digital só recentemente passou a ser explorado, existindo ainda poucos trabalhos sobre o
assunto. Destes, são considerados neste capítulo apenas aqueles inseridos no cenário do SBTVD.
3.2 Trabalhos Analisados
3.2.1 Uma Arquitetura de Serviço para Avaliação de Contextos em Redes de
TV Digital
Ao gerar conteúdo televisivo, é interessante para as emissoras de TV saber qual é o grau de
adequação entre o conteúdo sendo gerado e as características envolvendo o seu público alvo.
Com essa informação, as emissoras podem adaptar suas futuras transmissões visando aumentar
o número e a satisfação de seus telespectadores.
Leite et al. (2007) percebe que no mundo da TV Digital, onde várias mídias com conteúdo e de
58
qualidades diferentes podem ser enviadas via broadcast junto com aplicações que as manipulam,
essa adaptação pode ser feita em tempo real.
Tendo isso em vista, Leite et al. (2007) define uma arquitetura de serviço para avaliação
do grau de adequação do conteúdo televisivo de acordo com informações de contexto - utilizado
por Leite et al. (2007) como sendo conceitos relativos ao telespectador, à plataforma e ao ambi-
ente. Essas informações podem, então, ser utilizadas para adaptar o comportamento dos XLets,
aplicativos imperativos do padrão do SBTVD, e, logo, do conteúdo sendo exibido.
Nessa arquitetura (Figura 3.1), cada dispositivo receptor oferece um Web Service que é
utilizado pelas emissoras, ou produtores de conteúdo, para enviarem uma descrição de como as
informações de contexto adquiridas pela plataforma devem ser utilizadas para avaliar o grau de
adequação do conteúdo sendo apresentado. Essa descrição forma uma base de conhecimento, que
juntamente com uma base de fatos, formada pelas informações contextuais obtidas pelo receptor,
são processadas por um motor de inferência baseado em lógica fuzzy que envia a avaliação de
volta para a emissora.
Figura 3.1: Arquitetura de Serviço para Avaliação de Contextos em Redes de TV Digital. Fonte:(LEITE et al., 2007)
As informações contextuais utilizadas tanto para descrição das regras de avaliação quanto
para a armazenagem na base de fatos devem estar de acordo com uma ontologia de domínio para
a TV Digital, definida por Leite et al. (2007) em OWL (Web Ontology Language) .
59
3.2.2 Um Framework Sensível ao Contexto para Sistemas de Tomadas de
Decisão de Governança em Saúde
O controle de epidemias e doenças infecto-contagiosas representa um grande desafio para os
gestores dos Sistemas de Saúde, pois necessitam de soluções eficientes e de baixo custo. Outro
desafio no âmbito dos Sistemas de Saúde é o grande número de atendimentos presenciais em
centros de emergência e de internações.
Nesse cenário, um sistema de monitoramento de saúde remoto poderia ser utilizado. No
primeiro caso, as informações obtidas por esse monitoramento poderiam ser utilizadas para
auxiliar as tomadas de decisão dos gestores de saúde, enquanto, no segundo, informações sobre
aspectos da saúde de pacientes poderiam ser monitorados e o tratamento poderia ser feito à
distância, diminuindo o fluxo de pessoas nos hospitais.
Tendo isso em vista, Oliveira et al. (2010) propõe um framework para suporte de aplicações
sensíveis ao contexto para apoio à tomada de decisão de governança em saúde que utiliza o
dispositivo receptor de TV Digital para aquisição de informações contextuais que são enviadas
via canal de interatividade. Essas informações devem estar de acordo com uma ontologia de
domínio definida em OWL-DL que as divide em contexto local e global.
Baseada nessa ontologia, são criadas regras no modelo ECA (Event-Condition-Action) para
descrever regras lógicas que são traduzidas para SRWL (Semantic Web Rule Language) , per-
mitindo a inferência de informações contextuais de mais alto nível e a tomada automática de
decisão (ou o auxílio dela).
3.2.3 Contextual Ginga: Uma Ferramenta de Autoria de Aplicações Intera-
tivas Sensíveis ao Contexto de TV digital para Ginga-NCL
Como visto, a característica de sensibilidade ao contexto pode tornar aplicações interativas de TV
Digital mais atrativas. Além disso, a velocidade em que o conteúdo televisivo deve ser produzido
faz com que essas aplicações precisem de ter um ciclo de desenvolvimento mais curto, o que pode
ser feito por meio de ferramentas de autoria.
Dessa forma, Carvalho e Ferraz (2010) implementa uma ferramenta de autoria que permite a
produção de aplicações interativas sensíveis ao contexto para a TV Digital brasileira. Essa ferra-
60
menta provê uma interface gráfica para a construção dessas aplicações que podem ser adaptadas
pelas informações de faixa etária e sexo do telespectador; data, hora e dia da semana em que a
aplicação é acessada; e código postal de onde ela é exibida.
A Figura 3.2 apresenta a interface gráfica dessa ferramenta sendo utilizada para a imple-
mentação de um EPG que se adapta às informações contextuais definidas.
Figura 3.2: Ferramenta de Autoria de Aplicações Sensíveis ao Contexto. Fonte: (CARVALHO;FERRAZ, 2010)
Carvalho e Ferraz (2010) define, ainda, qual deve ser o processo de criação das aplicações
desenvolvidas nessa ferramenta. São elas: (i) identificar os tipos de informações contextuais de
interesse para a aplicação, (ii) criar todos os componentes da aplicação (mídias), (iii) definir o
conjunto de valores das informações contextuais identificadas que caraterizam os perfis (personas)
para os quais a aplicação será adaptada, (iv) definir o comportamento da aplicação direcionada
a cada perfil e (v) geração de código NCL referente a mesma.
3.2.4 Desenvolvimento de Aplicações Sensíveis ao Contexto no Ambiente De-
clarativo do Sistema Brasileiro de TV Digital
Mielke (2010) também é motivado pelos benefícios trazidos pela inserção de sensibilidade ao
contexto no cenário de TV Digital para fazer uma avaliação dos elementos da plataforma Ginga-
NCL com o objetivo de identificar os elementos que podem ser utilizados para facilitar a realização
de aplicações sensíveis ao contexto.
Considerando que informações contextuais podem ser adquiridas por meio de sensores, Mielke
(2010) identifica que isso deve ser feito por meio da comunicação entre uma aplicação NCL e o
61
Canal de Interatividade por meio de scripts NCLua. Para isso, estes devem fazer uso do serviço
de eventos desse ambiente, disponibilizado por meio do módulo event. Nesse caso, o script pode
se comunicar com o Canal de Interatividade por meio de eventos da classe “tcp” para adquirir
uma informação da rede e, em seguida, atualizar uma âncora de propriedade da aplicação NCL
por meio de eventos da classe “ncl”.
De acordo com Mielke (2010), muitas vezes o mecanismo de tratamento de eventos do NCLua
impõe dificuldades ao desenvolvimento de alguns tipos de aplicações, como é o caso daquelas
que necessitam gerenciar várias conexões TCP (MIELKE, 2010), ou das que necessitam da
utilização de protocolos de camadas acima da camada de transporte, como HTTP ou SOAP
(FILHO; GONDIM, 2011). Além disso, não existe uma correspondência direta entre âncoras de
propriedades em documentos NCL e variáveis nos scritps NCLua (MIELKE, 2010).
É percebido por Mielke (2010), então, que os eventos utilizados pelo mecanismo padrão de
tratamento eventos de NCLua podem ser traduzidos como funções de componentes da aplicação
NCL. Por exemplo, o evento de solicitação de conexão pode ser representado por um método de
conexão em um objeto que representa um cliente no Canal de Interatividade.
Baseado nisto, Mielke (2010) apresenta as bibliotecas NCLua TCPEventHandler e Properties
que facilitam, respectivamente, o acesso ao Canal de Interatividade e a comunicação entre scripts
NCLua e documentos NCL, o que pode auxiliar na distribuição e no tratamento de eventos
contextuais na plataforma Ginga. Estas bibliotecas abstraem a estrutura dos eventos de NCLua
e disponibilizam funcionalidades por meio de conceitos de orientação a objetos, como métodos e
tratadores de eventos específicos, que lidam, por exemplo, com a atribuição de uma variável no
documento NCL ou a chegada de dados em uma conexão.
As Figuras 3.3 e 3.4 mostram o diagrama de classes conceitual dessas duas bibliotecas.
Figura 3.3: Modelo da biblioteca TCPEventHandler para comunicação com o canal de interati-vidade. Fonte: (MIELKE, 2010)
Como representado pela Figura 3.3, o objeto Connection da biblioteca TCPEventHandler
62
implementa o comportamento necessário para realizar o controle da comunicação com o Canal de
Interatividade, cabendo ao tratador de eventos apenas implementar o comportamento específico
da aplicação, que deve ser implementado no script NCLua que utiliza a biblioteca.
Figura 3.4: Modelo da biblioteca Properties para comunicação com o documento NCL. Fonte:(MIELKE, 2010).
Como representado na Figura 3.4, a biblioteca Properties.lua disponibiliza métodos para
atribuir valores a âncoras de propriedades no documento NCL, obter valores dessas propriedades e
registrar funções para serem executadas quando o valor de propriedades específicas são alteradas.
Por realizarem o controle da comunicação com o Canal de Interatividade e o documento
NCL em um nível mais alto de abstração, essas bibliotecas podem ser reutilizadas em diversos
cenários, como para aquisição de informações contextuais de dispositivos externos à plataforma.
Para validar sua abordagem, Mielke (2010) apresenta dois estudos de caso em domínios diferentes:
um medidor de audiência para adequação de conteúdo, um e monitor cardíaco para acionamento
de serviços de emergência.
3.2.5 Abordagem Orientada a Modelos para o Desenvolvimento de Aplica-
ções Sensíveis ao Contexto para a TV Digital
Como já dito, o desenvolvimento de aplicações sensíveis ao contexto deve ser feito de forma
integrada, ou seja, cada etapa, da modelagem de contexto e situações, passando pela especificação
do comportamento reativo da aplicação, até a implementação, deve se comprometer com a etapa
anterior. Além disso, é natural se pensar que a implementação de componentes dessas aplicações
no cenário do SBTVD seja feita em NCL e NCLua, já que são linguagens padrão.
Nesse sentido, Vale (2011) observa que uma regra escrita em ECA-DL, linguagem utilizada
para especificar o comportamento reativo de aplicações sensíveis ao contexto (Seção 4.3), possui
uma correspondência com os elementos da linguagem NCL. Contudo, uma simples regra ECA-
DL, que normalmente, por ser específica de domínio, pode ser escrita em poucas linhas, gera uma
63
grande quantidade de linhas de código NCL e, geralmente, muitas dessas linhas são semelhantes
em várias aplicações (MIELKE, 2010).
Com base nisso, Vale (2011) define uma nova linguagem baseada na ECA-DL, mas que
incorpora conceitos do domínio da TV Digital, chamada ECA-DL TVD, e utiliza técnicas da
área de Desenvolvimento Orientado a Modelos (MDA) [Almeida, Pires & Sinderen 2004] a fim de
permitir a geração automática de código NCL a partir de regras especificadas nessa linguagem.
MDA permite que isso seja feito a partir do mapeamento dos elementos dos metamodelos de
ECA-DL TVD e NCL e de frameworks de transformação de modelos.
Assim como a ECA-DL, a ECA-DL TVD se baseia nos modelos contextuais e de situação
definidos por Costa (2007) (Seção 4.2) para a definição do comportamento reativo da aplicação,
o que mantém uma relação direta entre a etapa de modelagem de contexto, situações e regras,
e a geração de código responsável pelo comportamento reativo da aplicação. Vale (2011) define,
então, os mapeamentos tanto entre elementos da linguagem ECA-DL TVD e da NCL, quanto
entre elementos da linguagem de definição da modelagem contextual e da NCL.
Como prova de conceito, Vale (2011) utiliza sua abordagem para implementar duas aplicações
sensíveis ao contexto: uma no domínio das “Casas Inteligentes”, na qual uma mensagem de aviso
é apresentada para um telespectador assistindo um filme, quando sua pipoca fica pronta no
microondas; e uma no domínio de segurança para “Home Banking”, onde a imagem que exibe o
saldo da conta corrente do usuário é ocultada quando é identificada a presença de mais de uma
pessoa na sala.
3.2.6 Integração entre o Middleware Brasileiro de TV Digital e Serviços de
Dispositivos Eletrônicos em Redes OSGi
Com o desenvolvimento de novos dispositivos e novas tecnologias de comunicação, aumentou con-
sideravelmente a quantidade de serviços oferecidos e compartilhados por dispositivos eletrônicos
com elevado poder de processamento, como smartphones e ipads, assim como dispositivos que
comumente não tinham essa capacidade, como ar condicionados e controladores de iluminação e
portas (VIANA, 2009).
Com o advento da TV Digital, a TV também pode ser considerado um desses dispositivos.
Além disso, devido a possibilidade de prover várias interfaces de comunicação, ela pode ser
64
utilizada para centralizar o controle de dispositivos numa rede doméstica e para prover acesso a
serviços externos à residência via canal de interatividade.
Motivado por esse cenário, foram desenvolvidos vários trabalhos abordando a integração entre
os padrões existentes para TVD (ACAP, MHP, Ginga, etc.) e frameworks de Home Networks.
Um trabalho em particular (VIANA, 2009) analisa e compara várias dessas diferentes abordagens
para essa integração, levando em consideração características como (i) o tipo de integração (se
são separados ou integrados numa mesma arquitetura); (ii) a necessidade de modificação dos
padrões utilizados; e (iii) as formas de comunicação (uni ou bi direcionais).
Feita a análise, Viana (2009) define e implementa uma arquitetura Ginga-OSGi para inte-
gração entre as duas plataformas, tanto para o ambiente Ginga-J, quanto para o Ginga-NCL.
Considerando-se apenas o ambiente GingaNCL-OSGi, essa integração é possibilitada pela imple-
mentação de novos Adapters, elementos do Ginga-NCL que associados aos Players são respon-
sáveis por executar as mídias controladas pelas aplicações.
Esses novos Adapters, chamados GingaNCL2OSGiAdapter e OSGiGingaNCLAdapter, são
utilizados para dar acesso a serviços cadastrados no OSGi, como os providos por dispositivos
eletrônicos variados, para serem acessados via aplicação NCL, e dar acesso a elementos do Ginga,
como regiões na tela e propriedades das mídias, para serem utilizados por bundles cadastrados
no OSGi.
3.2.7 Discussão
Após uma breve descrição dos trabalhos analisados, é feita uma discussão à luz dos seguintes as-
pectos de interesse para esta dissertação: (i) abordagem usada para modelagem de contextos; (ii)
existência de suporte arquitetural para manipulação de contextos; (iii) estratégia para aquisição
de informações contextuais.
3.2.7.1 Modelagem de Contexto
Partindo das abordagens menos interessantes para as mais interessantes, no que se diz respeito
à modelagem contextual, pode-se dizer que Carvalho e Ferraz (2010) faz apenas uma categori-
zação das informações que podem ser utilizadas para a adaptação das aplicações geradas pela
sua ferramenta utilizando as dimensões Who, When e Where. Além disso, ao propor uma me-
65
todologia para utilização de sua plataforma, não é proposto nenhum tipo de modelagem para
o comportamento reativo da aplicação. Essa abordagem restringe muito os cenários abrangidos
pelas aplicações desenvolvidas para sua plataforma e dificulta o desenvolvimento das mesmas, já
que o comportamento reativo pode ser bastante complexo. Um ponto interessante do trabalho é
a própria ideia de uma ferramenta de autoria para aplicações sensíveis ao contexto, o que pode
resultar num trabalho futuro para esta dissertação.
Mielke (2010) utiliza diagramas de classes UML (Universal Markup Language) para modelar
as entidades e as informações contextuais envolvidas em suas aplicações sensíveis ao contexto e
um diagrama de sequência para modelar seu comportamento reativo. Essa abordagem permite
a modelagem de uma maior gama de cenários, e facilita o entendimento sobre o comportamento
reativo da aplicação. A utilização de diagramas de classe UML, porém, permite a criação de
modelos ambíguos (GUIZZARDI, 2005). Além disso, existem outras formas mais interessantes
para a modelagem de comportamento reativo, como a utilização de regras, que aliadas a mo-
delos baseados em ontologias, permitem o processamento automático dessas regras para gerar
informações de contexto de mais alto nível e, automaticamente, adaptar as aplicações.
Pelo fato de atuar no domínio de TV Digital, Leite et al. (2007) define uma ontologia para
esse domínio utilizando a linguagem OWL que deve ser utilizada para classificar as informações
contextuais que podem ser utilizadas nas aplicações. Da mesma forma, Oliveira et al. (2010)
define uma ontologia OWL, mas, nesse caso, para definir o domínio em que se insere sua apli-
cação (relacionada à saúde). Essa abordagem é bastante interessante por permitir a modelagem
do comportamento reativo da aplicação em forma de regras, assim como é proposto por ambos
os trabalhos, as quais podem ser processadas automaticamente facilitando o trabalho do de-
senvolvedor e potencializando a criação de novas aplicações. Além disso, pela avaliação desses
trabalhos, OWL parece poder ser utilizada para a modelagem de aplicações sensíveis ao contexto
em domínios diferentes.
A utilização da OWL, porém, é interessante para facilitar o raciocínio lógico automático, não
para a representação do mundo real (GUIZZARDI, 2005), a qual é característica desejável para
a etapa de modelagem. A utilização da OWL pode, assim como a utilização de UML, resultar
na criação de modelos ambíguos, dificultando o entendimento entre os interessados na aplica-
ção. Uma solução para esse problema poderia ser a utilização de ontologias de fundamentação
(GUIZZARDI, 2005) (Seção 4.2), que restringem a utilização dos elementos das ontologias de
66
domínio, promovendo a criação de modelos que representam fielmente elementos do mundo real,
possibilitando a criação de modelos não ambíguos.
Para a etapa de modelagem contextual Vale (2011), utiliza elementos de uma ontologia de
fundamentação propostos por Costa (2007), possibilitando a definição de modelos não ambí-
guos, a delimitação precisa do escopo da aplicação e o entendimento entre os envolvidos no seu
desenvolvimento. Um dos elementos, chamado de Situação, permite a modelagem dos estados
das entidades e contextos que sejam de interesse da aplicação. Vale (2011) utiliza, ainda, uma
linguagem específica de domínio que se baseia nos elementos da modelagem para a criação de
regras para a especificação do comportamento reativo da aplicação, facilitando o entendimento
e o desenvolvimento dessas aplicações.
Esta dissertação usa a mesma abordagem utilizada por Vale (2011) para a modelagem de
contexto, situações e regras de comportamento reativo, por se mostrar a melhor abordagem a ser
utilizada para a realização dessa etapa no desenvolvimento de aplicações sensíveis ao contexto
para a TV Digital.
3.2.7.2 Arquiteturas
Dos trabalhos apresentados, os únicos que apresentam soluções arquiteturais para dar suporte
à execução de aplicações sensíveis ao contexto no dispositivo receptor do sinal de TV Digital,
são Leite et al. (2007) e Vale (2011). Oliveira et al. (2010) também apresenta uma arquitetura,
contudo ele utiliza o dispositivo receptor apenas para a aquisição de informação contextual,
mantendo o restante da arquitetura centralizado num servidor remoto. Uma arquitetura no
próprio receptor que pré processasse informações contextuais poderia ser interessante nesse caso
para desafogar o processamento no servidor.
Apesar de ter sido definida especificamente para detecção, por parte das emissoras, do grau de
adequação do conteúdo televisivo enviado para cada receptor, a arquitetura apresentada por Leite
et al. (2007) possui elementos interessantes para dar suporte a aplicações sensíveis ao contexto
de domínios variados. São eles: Base de Fatos, Base de Conhecimento e Motor de Inferência.
Para serem utilizados em outros domínios, basta que seja utilizadas outras ontologias.
Leite et al. (2007), porém, não define os elementos dessa arquitetura que devem realizar
ações de interação com o Ginga para permitir que os resultados do processamento das infor-
67
mações contextuais sejam utilizados para adaptar a execução das aplicações. Além disso Leite
et al. (2007) não define um elemento arquitetural que seja responsável por compor informações
contextuais a partir de outras, característica normalmente necessária em aplicações sensíveis ao
contexto.
Vale (2011) utiliza uma arquitetura conceitual baseada na definida por Costa (2007) que
provê elementos arquiteturais genéricos e reutilizáveis que podem ser especializados de acordo
com os requisitos das aplicações. Esses elementos oferecem serviços comuns para suporte de
aplicações sensíveis ao contexto, como provisionamento de informações contextuais, inferência
de contexto, execução de regras de comportamento reativo e execução de ações. Contudo, Vale
(2011) realiza esses elementos nas próprias aplicações, ao invés de fazer isso no receptor, tornando
a reutilização desses elementos mais difícil por parte do programador.
Aqui advoga-se, porém, que essa arquitetura deve ser realizada na própria plataforma Ginga,
o que permite uma abordagem de desenvolvimento voltado ao reuso e a distribuição da respon-
sabilidade do desenvolvimento da aplicação por todos os envolvidos, o que facilita e promove o
desenvolvimento de aplicações sensíveis ao contexto mais elaboradas e em diferentes domínios.
3.2.7.3 Aquisição de Informações contextuais
Dos trabalhos apresentados, Carvalho e Ferraz (2010), Oliveira et al. (2010), Mielke (2010) e
Vale (2011) se preocupam com a forma em que os dados contextuais devem ser adquiridos pela
aplicação.
Carvalho e Ferraz (2010), por utilizar apenas informações contextuais que devem ser dispo-
nibilizadas pelo Ginga, por padrão, consegue adquirir todas as informações necessárias para as
aplicações sensíveis ao contexto apenas pela forma padrão, por exemplo pela utilização do mó-
dulo settings de NCLua. Esta dissertação, porém, admite a utilização de informações contextuais
das mais variadas, que muitas vezes só podem ser adquiridas por meio de sensores.
Oliveira et al. (2010) utiliza a solução proposta por Oliveira et al. (2009) para a obtenção de
sinais vitais dos telespectadores. Oliveira et al. (2009) propõe que isso seja feita pela comunicação
via USB com um dispositivo que agrega os sinais vitais adquiridos de vários dispositivos (um para
cada tipo de sinal), e que envia esses dados para o receptor. Como em sua abordagem Oliveira et
al. (2010) utiliza os receptores apenas para aquisição de dados, não é proposta uma forma para
68
permitir que as aplicações de TV Digital utilizem essa informação. Além disso, essa aquisição
é feita especificamente para o dispositivo utilizado, o que não é desejável dada a variedade de
dispositivos disponíveis que se propõem a adquirir um mesmo tipo de informação.
A melhor abordagem encontrada para permitir a aquisição de informações contextuais pelas
aplicações NCL foi a proposta por Mielke (2010). As bibliotecas propostas por ele facilitam
bastante a aquisição de informação contextual por parte de aplicações NCL por meio da comu-
nicação com dispositivos via Canal de Interatividade. Essa abordagem também foi utilizada por
Vale (2011) em seu trabalho. Um desenvolvedor que utilize essa abordagem, porém, deve imple-
mentar uma forma de comunicação específica para cada dispositivo fonte de contexto, trazendo
os mesmos problemas já mencionados no parágrafo anterior.
Esta dissertação pretende criar uma forma para permitir que aplicações de TV Digital uti-
lizem informações contextuais que possam ser acessadas genericamente, ou seja, independente-
mente do dispositivo sendo utilizado para adquirir essas informações. Para isso foi, vislumbrada
a possibilidade de se usar da abordagem definida por Mielke (2010) junto à utilização de fra-
meworks de Home Networks.
Como visto no Capítulo 2, frameworks para Home Gateways surgem como soluções para
acesso a dispositivos heterogêneos que passam a abstrair seus aspectos específicos de imple-
mentação pelo oferecimento de serviços disponibilizados na rede. Esses serviços poderiam ser
utilizados, por exemplo, para preencher o gap existente entre o sensoriamento de informações
contextuais por esses dispositivos e seu acesso pelas aplicações sensíveis ao contexto no cenário
do SBTVD.
A implementação proposta por Viana (2009) é bastante interessante e oportuna, pois abrange
os dois ambientes providos pelo Ginga (declarativo e imperativo) e trata do problema acima
mencionado. O trabalho propõe uma solução completa para STB’s residenciais; integra o Ginga
e o OSGi em uma única plataforma, permitindo a centralização do controle de dispositivos;
e permite a comunicação bi-direcional, permitindo tanto a utilização quanto o provimento de
serviços pelo STB.
Levando em consideração o escopo desta dissertação, o trabalho de (VIANA, 2009) traz
contribuições interessantes, pois mostra que a integração entre Ginga e OSGi possui um grande
potencial para ser utilizada como uma forma de aquisição de informação contextual via consumo
69
de serviços oferecidos por dispositivos.
(VIANA, 2009), porém, modifica a implementação do Ginga de forma a adicionar novos
elementos (tipos de Adapters) não existentes no padrão, de forma que suas aplicações de geren-
ciamento de dispositivos deixam de ser genéricas e passam a rodar somente em sua plataforma.
Além disso sua implementação considera que existe uma máquina Java instalada na plataforma
(isso pode não acontecer em alguns receptores), o que deixa a implementação dependente de
plataforma, indo contra os requisitos considerados nesta dissertação.
Uma possível solução de contorno para essas questões poderia ser a desvinculação entre o
Ginga e o OSGi, fazendo com que a comunicação entre uma aplicação sendo executada no Ginga
e serviços de acesso a informações contextuais providos por dispositivos cadastrados no OSGi
seja feita por meio do Canal de Interatividade. Essa comunicação poderia ser feita com o auxílio
das bibliotecas TCPEventHandler e Properties propostas por Mielke (2010).
3.3 Conclusões do Capítulo
Este capítulo apresentou alguns trabalhos descritos na literatura envolvendo o desenvolvimento
de aplicações sensíveis ao contexto para a Televisão Digital e a comunicação entre dispositivos
eletrônicos e middleware utilizados na recepção dos sinais de TV Digital Interativa.
A avaliação desses trabalhos consistiu uma etapa importante desta dissertação, pois permitiu
uma definição mais precisa dos objetivos e do escopo do trabalho, das tecnologias a serem usadas
e das referências teóricas sobre o qual a proposta deveria ser apoiar, discutidas em mais detalhes
nos próximos capítulos.