Suporte a Aplicações Sensíveis ao Contexto no Cenário do Sistema ...

Thiago Paris Salviato

Suporte a Aplicações Sensíveis ao Contextono Cenário do Sistema Brasileiro de Televisão

Digital

Vitória2012



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



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


adaptado de (VALE, 2011). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111


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


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


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


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


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


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


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.

Suporte a Aplicações Sensíveis ao Contexto no Cenário do Sistema ...

Documents

Transcript of Suporte a Aplicações Sensíveis ao Contexto no Cenário do Sistema ...