Suporte a aplicações sensíveis ao contexto no cenário do Sistema Brasileiro de Televisão Digital

Texto

(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, 1983Suporte 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.

(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 2012.. 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. . . . . . . . . . . . . . . . .. 2.2. Modelo simplificado de um sistema de TV Digital. Fonte: (SOARES; BARBOSA,. 36. 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) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3.2. Ferramenta de Autoria de Aplicações Sensíveis ao Contexto. Fonte: (CARVALHO; FERRAZ, 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3.3. . . . . . . . . . . . . . . . . . . . . . . . . .. 61. Modelo da biblioteca Properties para comunicação com o documento NCL. Fonte: (MIELKE, 2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4.1. 60. Modelo da biblioteca TCPEventHandler para comunicação com o canal de interatividade. Fonte: (MIELKE, 2010). 3.4. 58. 62. Exemplo de modelagem contextual que utiliza os elementos de modelagem definidos 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.

(16) 4.4. Padrão Event-Control-Action (ECA). Fonte: (COSTA, 2007) . . . . . . . . . . .. 4.5. Componentes da Plataforma de Manipulação de Contexto (Context Handling Plat-. 77. 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 Informaçõ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.

(17) 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; GUAITOLINI; 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.

(18)

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

(20)

(21) 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.

(22)

(23) 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. 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. 49. 2.3. Arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

(24) 2.3.2.2. Modelagem de Contexto, Situações e Comportamento Reativo .. 50. 2.3.2.3. Metodologia de Desenvolvimento . . . . . . . . . . . . . . . . . .. 50. Aquisição de Informações Contextuais . . . . . . . . . . . . . . . . . . . .. 51. 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. Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 55. 2.3.3 2.4. 2.5. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3.2.2. Um Framework Sensível ao Contexto para Sistemas de Tomadas de Decisão de Governança em Saúde . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3.2.3. 3.2.7. 60. Abordagem Orientada a Modelos para o Desenvolvimento de Aplicações Sensíveis ao Contexto para a TV Digital . . . . . . . . . . . . . . . . . . .. 3.2.6. 59. Desenvolvimento de Aplicações Sensíveis ao Contexto no Ambiente Declarativo do Sistema Brasileiro de TV Digital . . . . . . . . . . . . . . . . . .. 3.2.5. 59. Contextual Ginga: Uma Ferramenta de Autoria de Aplicações Interativas Sensíveis ao Contexto de TV digital para Ginga-NCL . . . . . . . . . . . .. 3.2.4. 57. 62. Integração entre o Middleware Brasileiro de TV Digital e Serviços de Dispositivos Eletrônicos em Redes OSGi . . . . . . . . . . . . . . . . . . . . .. 63. Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 64.

(25) 3.3. 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. Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 69. 4 Suporte Arquitetural para Aplicações Sensíveis ao Contexto e o Gerenciador de Contexto do Ginga. 71. 4.1. Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 71. 4.2. Modelagem de Contexto e Situações . . . . . . . . . . . . . . . . . . . . . . . . .. 72. 4.3. ECA-DL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 75. 4.4. Padrões Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 77. 4.4.1. Padrão Arquitetural Event-Control-Action . . . . . . . . . . . . . . . . . .. 77. 4.4.2. Padrão Arquitetural de Hierarquia de Fontes e Gerenciadores de Contexto. 78. 4.4.3. Padrão Arquitetural de Ações . . . . . . . . . . . . . . . . . . . . . . . . .. 78. Arquitetura Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 79. 4.5.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 79. 4.5.2. Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 80. 4.5.3. Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 81. Arquitetura Conceitual para o Gerenciador de Contexto do Ginga . . . . . . . . .. 82. 4.6.1. Arquitetura Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 82. 4.6.1.1. Modelo da Arquitetura . . . . . . . . . . . . . . . . . . . . . . .. 82. 4.6.1.2. Detalhamento da Arquitetura . . . . . . . . . . . . . . . . . . . .. 83. 4.7. Componentes Gerenciadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 85. 4.8. Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 87. 4.5. 4.6. 5 Gerenciador de Fontes de Contexto. 89.

(26) 5.1. Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 89. 5.2. Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 90. 5.3. Serviços e Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 91. 5.4. Abordagem Escolhida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 92. 5.5. Arquitetura Implementada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 94. 5.5.1. Elementos do Gerenciador de Fontes Contextuais . . . . . . . . . . . . . .. 96. 5.5.2. Acessando os Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 98. 5.6. Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100. 6 Abordagem Orientada a Modelos para o Desenvolvimento de Aplicações Sensíveis ao Contexto para a TV Digital. 103. 6.1. Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103. 6.2. Elementos de Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104. 6.3. 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. 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.

(27) 6.4. Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116. 7 Metodologia de Desenvolvimento de Aplicações Sensíveis ao Contexto para a TV Digital. 119. 7.1. Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119. 7.2. Abordagem Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.2.1. 7.2.2. 7.3. 7.4. 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. 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. 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. Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136. 8 Estudo de Caso. 137. 8.1. Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137. 8.2. Cenário: John Popcorn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137.

(28) 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.3. 8.3. 8.2.2.1. Dispositivo de sensoriamento . . . . . . . . . . . . . . . . . . . . 141. 8.2.2.2. Bundle OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142. 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. Conclusões do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150. 9 Conclusões 9.1. 151. Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151. 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) 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 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 2.2.1. 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.. 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.

(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 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 inclusã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 GingaNCL (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 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 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.. 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 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.. 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.

(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 2.3.1. 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.. 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) 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.