Thiago Paris Salviato. Suporte a Aplicações Sensíveis ao Contexto no Cenário do Sistema Brasileiro de Televisão Digital

Transcrição

1 Thiago Paris Salviato Suporte a Aplicações Sensíveis ao Contexto no Cenário do Sistema Brasileiro de Televisão Digital Vitória 2012

2

3 Thiago Paris Salviato Suporte a Aplicações Sensíveis ao Contexto no Cenário do Sistema Brasileiro de Televisão Digital Dissertação apresentada à Universidade Federal do Espírito Santo, para a obtenção de Título de Mestre em Informática. Orientador:José Gonçalves Pereira Filho Vitória 2012

4 Dados Internacionais de Catalogação-na-publicação (CIP) (Biblioteca Central da Universidade Federal do Espírito Santo, ES, Brasil) S184s Salviato, Thiago Paris, Suporte a aplicações sensíveis ao contexto no cenário do Sistema Brasileiro de Televisão Digital / Thiago Paris Salviato 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

5 Thiago Paris Salviato Suporte a Aplicações Sensíveis ao Contexto no Cenário do Sistema Brasileiro de Televisão Digital Dissertação submetida ao Programa de Pós-Graduação em Informática do Centro Tecnológico da Universidade Federal do Espírito Santo, como requisito parcial para a obtenção do título de Mestre em Informática. Aprovada em 27 de Janeiro de Banca Examinadora: Prof. Dr. José Gonçalves Pereira Filho Universidade Federal do Espírito Santo Profª. Drª. Patrícia Dockhorn Costa Universidade Federal do Espírito Santo Prof. Dr. Luiz Fernando Gomes Soares Pontifícia Universidade Católica do Rio de Janeiro Vitória 2012

6

7 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.

8

9 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.

10

11 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, particularmente 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 gerenciamento 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.

12

13 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 interface 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 infrastructure. Keywords: Context-Aware Applications, Digital TV, Ginga, OSGi

14

15 Lista de Figuras 2.1 Modelo simplificado de um sistema de TV analógica Modelo simplificado de um sistema de TV Digital. Fonte: (SOARES; BARBOSA, 2008) Arquitetura do Ginga. Fonte: (SOARES, 2009) Exemplo de código NCL Aplicação sensível ao contexto e suas interações. Fonte: (COSTA, 2007) Navegador Web Sensível ao Contexto e suas interações Arquitetura de Serviço para Avaliação de Contextos em Redes de TV Digital. Fonte: (LEITE et al., 2007) Ferramenta de Autoria de Aplicações Sensíveis ao Contexto. Fonte: (CARVALHO; FERRAZ, 2010) Modelo da biblioteca TCPEventHandler para comunicação com o canal de interatividade. Fonte: (MIELKE, 2010) Modelo da biblioteca Properties para comunicação com o documento NCL. Fonte: (MIELKE, 2010) Exemplo de modelagem contextual que utiliza os elementos de modelagem definidos por Costa (2007). Fonte: (VALE; GUAITOLINI; COSTA, 2009) Situação SituationMakingPopcorn. Fonte: (VALE; GUAITOLINI; COSTA, 2009) Situação SituationDisplayingMovie. Fonte: (VALE; GUAITOLINI; COSTA, 2009) 74

16 4.4 Padrão Event-Control-Action (ECA). Fonte: (COSTA, 2007) Componentes da Plataforma de Manipulação de Contexto (Context Handling Platform). Fonte: (COSTA, 2007) Gerenciador de Contexto dando apoio a duas aplicações sensíveis ao contexto Interações relevantes para o Gerenciador de Contexto Padrão ECA aplicado ao Gerenciador de Contexto Gerenciador de Contexto após a aplicação dos padrões arquiteturais Arquitetura proposta para o Gerenciador de Contexto Interações entre uma aplicação, o gerenciador de fontes contextuais implementado e dispositivos diversos Detalhamento do Gerenciador de Fontes Contextuais Biblioteca ContextManager.lua para acesso aos serviços do Gerenciador de Informações Contextuais Utilizando a biblioteca ContextManager.lua Mapeamento de Entidades e Contexto Intrínseco para mídias NCLua. Fonte: (VALE, 2011) Mapeamento do Contexto Relacional e Entidades envolvidas para mídias NCLua. Fonte:(VALE, 2011) Mapeamento de Situações Contextuais e elementos envolvidos para mídias NCLua. Fonte: (VALE, 2011) Exemplo de mapeamento entre modelagem contextual e mídias NCLua Mapeamento da cláusula When SituationTVOn(TV.TV1) para NCL. Fonte: (VALE, 2011) Exemplo de mapeamento entre regra ECA-DL TVD e código NCL Cenário Ideal

17 7.2 Cenário Atual Cenário utilizando a metodologia definida em Vale (2011) Exemplo de mapeamento entre modelagem contextual e mídias NCLua Código da mídia NCLua referente a entidade TVProgram Passagem de valores de propriedades entre objetos NCLua Exemplo de implementação de um contexto relacional em Lua Exemplo de implementação de um contexto relacional em Lua Modelagem contextual para o cenário John Popcorn. Fonte: (VALE; GUAITO- LINI; COSTA, 2009) Modelagem da situação SituationMakingPopcorn para o cenário John Popcorn. Fonte: (VALE; GUAITOLINI; COSTA, 2009) Modelagem da situação SituationDisplayingMovie para o cenário John Popcorn. Fonte: (VALE; GUAITOLINI; COSTA, 2009) Estados do sensor UPnP que monitora o status de um Microondas Implementação do bundle OSGi para acesso ao sensor UPnP Implementação do bundle OSGi para acesso ao sensor UPnP Mapeamento dos elementos da modelagem envolvidos na regra ECA-DL TVD Mapeamento das cláusulas que compõem a regra ECA-DL TVD Propagação das informações contextuais entre Fontes de Contexto e Fontes de Situação Implementação da mídia MicrowaveOven1.lua Implementação da mídia TV1.lua Implementação da mídia TVProgram1.lua Implementação da mídia SituationMakingPopcorn_MicrowaveOven Implementação da mídia SituationDisplayingMovie_TV1_TVProgram

18

19 Lista de Tabelas 6.1 Eventos primitivos de ECA-DL TVD e suas correspondências em NCL. Fonte: adaptado de (VALE, 2011) Eventos primitivos de ECA-DL TVD e suas correspondências em NCL. Fonte: adaptado de (VALE, 2011) Eventos primitivos de ECA-DL TVD e suas correspondências em NCL. Fonte: adaptado de (VALE, 2011)

20

21 Nomenclatura ECG GPS NCL OCL Eletrocardiograma Sistema de Posicionamento Global (Global Positioning System) Nested Context Language 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 XML Universal Markup Language extensible Markup Language

22

23 Sumário 1 Introdução Motivação Objetivos Metodologia Organização Referencial Teórico Introdução Televisão Digital Introdução Interatividade Ginga: O middleware do SBTVD Aplicações Declarativas para o Ginga Linguagem NCL Objetos NCLua Aplicações Sensíveis ao Contexto Introdução Desenvolvimento de Aplicações Sensíveis ao Contexto Arquiteturas

24 Modelagem de Contexto, Situações e Comportamento Reativo Metodologia de Desenvolvimento Aquisição de Informações Contextuais Home Networks Introdução Jini UPnP OSGi Conclusões do Capítulo Trabalhos Relacionados Introdução Trabalhos Analisados Uma Arquitetura de Serviço para Avaliação de Contextos em Redes de TV Digital Um Framework Sensível ao Contexto para Sistemas de Tomadas de Decisão de Governança em Saúde Contextual Ginga: Uma Ferramenta de Autoria de Aplicações Interativas Sensíveis ao Contexto de TV digital para Ginga-NCL Desenvolvimento de Aplicações Sensíveis ao Contexto no Ambiente Declarativo do Sistema Brasileiro de TV Digital Abordagem Orientada a Modelos para o Desenvolvimento de Aplicações Sensíveis ao Contexto para a TV Digital Integração entre o Middleware Brasileiro de TV Digital e Serviços de Dispositivos Eletrônicos em Redes OSGi Discussão

25 Modelagem de Contexto Arquiteturas Aquisição de Informações contextuais Conclusões do Capítulo Suporte Arquitetural para Aplicações Sensíveis ao Contexto e o Gerenciador de Contexto do Ginga Introdução Modelagem de Contexto e Situações ECA-DL Padrões Arquiteturais Padrão Arquitetural Event-Control-Action Padrão Arquitetural de Hierarquia de Fontes e Gerenciadores de Contexto Padrão Arquitetural de Ações Arquitetura Conceitual Requisitos Arquitetura Serviços Arquitetura Conceitual para o Gerenciador de Contexto do Ginga Arquitetura Conceitual Modelo da Arquitetura Detalhamento da Arquitetura Componentes Gerenciadores Conclusões do Capítulo Gerenciador de Fontes de Contexto 89

26 5.1 Introdução Escopo Serviços e Requisitos Abordagem Escolhida Arquitetura Implementada Elementos do Gerenciador de Fontes Contextuais Acessando os Serviços Conclusões do Capítulo Abordagem Orientada a Modelos para o Desenvolvimento de Aplicações Sensíveis ao Contexto para a TV Digital Introdução Elementos de Modelagem Entidades e Contextos Intrínsecos Contextos Relacionais Situações Contextuais Exemplo dos Mapeamentos Elementos das Regras ECA-DL TVD Cláusula Upon Eventos Primitivos Eventos de Situação Cláusula When Cláusula Do Exemplo dos Mapeamentos Discussão

27 6.4 Conclusões do Capítulo Metodologia de Desenvolvimento de Aplicações Sensíveis ao Contexto para a TV Digital Introdução Abordagem Utilizada Modificações nos Mapeamentos Entidades e Contextos Contextos Relacionais Situações Aquisição e Propagação das Informações Contextuais Fontes de Contexto Fontes de Contexto da Aplicação Propagação das Informações entre as Mídias Mídias de Contextos Relacionais Situações a partir de Invariantes OCL Ações Proposta de Metodologia Modelagem de Contexto e Situações Desenvolvedores de Serviços de Acesso à Informação Contextual Desenvolvedores de Aplicações para TV Digital Conclusões do Capítulo Estudo de Caso Introdução Cenário: John Popcorn

28 8.2.1 Modelagem de Contexto e Situações Desenvolvedores de Serviços de Acesso à Informação Contextual Dispositivo de sensoriamento Bundle OSGi Desenvolvedores de Aplicações para TV Digital Comportamento Reativo em ECA-DL TVD Mapeamento da Regra ECA-DL TVD Propagação da Informação Contextual Implementação das mídias NCLua Conclusões do Capítulo Conclusões Considerações Finais Referências Bibliográficas 155

29 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 interaçã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 proliferaçã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 Computing ) (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 adquiridos 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éstica (home network), ou mesmo sinais de ECG adquiridos por um holter ligado a um paciente cardíaco.

30 28 Com o advento da televisão digital aberta no Brasil, um dos possíveis cenários para o desenvolvimento 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 poder 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 necessidade 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, à manipulaçã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 aplicaçã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 contextaware. 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

31 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 funcionalidades 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 desafiadora, 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 comunicar 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 à execuçã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 modelagem 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 integraçã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-

32 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 implementaçã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 consideram 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; poré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.

33 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 informações contextuais, independentemente das tecnologias utilizadas por esses dispositivos. Como visto, uma questão fundamental no desenvolvimento de aplicações sensíveis ao contexto é 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 comunicaçã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 sensíveis ao contexto no cenário do Sistema Brasileiro de TV Digital, que utilize a infraestrutura implementada.

34 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 domí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; poré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 utilizar 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 desenvolvida 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.

35 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 especificamente 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.

36 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.

37 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 importantes 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 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.

38 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

39 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 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

40 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 Nacional de Amostras por Domicílio (PNAD) mostram que em % 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 inclusão digital e social. Sendo assim, foi instituído em 26 de Novembro de 2003, via decreto presidencial número (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 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

41 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 compatibilidade 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 documentos NCL (Nested Context Language). NCL é uma linguagem de aplicação XML (extensible Markup Language) com facilidades para a especificação de aspectos de interatividade, sincronismo 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 exibiçã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

42 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/xginga-settings (Seção ). É 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 Gerenciador 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

43 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 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 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 funcionalidade (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

44 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 percebida 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 propriedades 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 envolvidos 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.

45 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 elementos. 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 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

46 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 objetos 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 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

47 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 automaticamente, 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

48 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 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) automaticamente 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

49 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 seguranç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 utilizaçã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 entidades 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 enviadas 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 dispositivos 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 disponibilizados.

50 48 Implementar como e quando esses dados devem ser apresentados para os telespectadores. 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 preocupar com a seguinte questão: Implementar os protocolos de comunicação específicos de uma entidade de atendimento médico para acionar um serviço de emergência. A emissora deveria se preocupar com todos esses aspectos, além, é claro, dos aspectos inerentes 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 monitoramento 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

51 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 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 solucionar 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 utilizaçã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

52 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 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 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

53 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 desenvolvimento 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 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 televisivo, 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 contextuais, 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.

54 52 A arquitetura definida em (COSTA, 2007) permite a generalização do acesso a essas informaçõ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 infraestrutura 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 interaçã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 dinamicamente, 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 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

55 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, Ethernet, 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 implementaçõ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 implementaçã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 justificativa pela escolha do OSGI como tecnologia de framework na implementação do Gerente de Contexto do Ginga Jini Jini é uma arquitetura de rede, baseada na tecnologia Java, para construção de sistemas distribuí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 publicar 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.

56 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 documentos 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, deferentemente 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 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- acharconectar ). 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

57 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 contextuais 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 permite 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, implementaçõ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 complexidade, 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 homogê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 trabalho. 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.

58

59 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 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

60 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 ambiente. 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).

61 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), permitindo 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) Contextual Ginga: Uma Ferramenta de Autoria de Aplicações Interativas 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-

62 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 implementaçã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 Desenvolvimento de Aplicações Sensíveis ao Contexto no Ambiente Declarativo 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