TrendTV: Uma Arquitetura para Mudança Automática de Canais ... · TrendTV, uma arquitetura em camadas que permite a formação de redes sociais entre te- lespectadores de programas

UNIVERSIDADE DO RIO GRANDE DO NORTEFEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA

Hugo Tácito Azevedo de Sena

TrendTV: Uma Arquitetura para MudançaAutomática de Canais de TV Baseada em Redes

Sociais Virtuais com Graus de Amizade eSuporte a Múltiplos Dispositivos no Cenário da

TV Digital Brasileira

Orientador: Prof. Dr. Aquiles Medeiros Filgueira Burlamaqui

Natal, RN, fevereiro de 2012

UNIVERSIDADE DO RIO GRANDE DO NORTEFEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA





Orientador: Prof. Dr. Aquiles Medeiros Filgueira Burlamaqui

Dissertação de Mestradoapresentada aoPrograma de Pós-Graduação em Engenha-ria Elétrica da UFRN (área de concentração:Engenharia de Computação) como parte dosrequisitos para obtenção do título de Mestreem Ciências.

Número de ordem PPgEE: M343Natal, RN, fevereiro de 2012

Divisão de Serviços Técnicos

Catalogação da Publicação na Fonte. UFRN / Biblioteca Central Zila Mamede

Sena, Hugo Tácito Azevedo de.TrendTV: Uma arquitetura para mudança automática de canaisde TV baseada

em redes sociais virtuais com graus de amizade e suporte a múltiplos dispositivosno cenário da TV digital brasileira / Hugo Tácito Azevedo de Sena - Natal, RN,2012

82 f.; il.

Orientador: Aquiles Medeiros Filgueira Burlamaqui

Dissertação (Mestrado) - Universidade Federal do Rio Grandedo Norte. Cen-tro de Tecnologia. Programa de Pós-Graduação em EngenhariaElétrica.

1. Televisão digital - Dissertação. 2. Redes sociais virtuais - Dissertação. 3.Guias de programação eletrônicos - Dissertação. 4. Programas de TV - Classi-ficação. I. Burlamaqui, Aquiles Medeiros Filgueira. II. Universidade Federal doRio Grande do Norte. III. Título.

RN/UF/BCZM CDU 621.397





Dissertação de Mestrado aprovada em 13 de fevereiro de 2012 pela banca examinadoracomposta pelos seguintes membros:

Prof. Dr. Aquiles Medeiros Filgueira Burlamaqui (orientador) . . . . ECT/UFRN

Prof. Dr. José Carlos Aronchi de Souza . . . . . . . . . . . . . . . . . . . .. . . . . . . SECGSP

Prof. Dr. Sérgio Queiroz de Medeiros . . . . . . . . . . . . . . . . . . . .. . . . DCOMP/UFS

Prof. Dr. Luiz Eduardo Cunha Leite . . . . . . . . . . . . . . . . . . . . . . .. . . . ECT/UFRN

Agradecimentos

Ao meu amigo Ricardo pelo apoio e incentivo durante a realização deste trabalho.

Ao meu orientador, professor Aquiles Medeiros Filgueira Burlamaqui, sou grato pelaorientação.

À minha família, especialmente meus pais, pela paciência durante esta jornada.

Ao Ministério da Cultura pelo apoio financeiro.

Resumo

Devido à grande quantidade de conteúdo televisivo, que surgiu junto com a TV Di-gital, os telespectadores estão diante de um novo desafio, saber como procurar conteúdointeressante de maneira intuitiva e eficiente. Os guias eletrônicos de programação per-sonalizada (pEPG) surgem como uma resposta para esse complexo desafio. Propomos aTrendTV, uma arquitetura em camadas que permite a formação de redes sociais entre te-lespectadores de programas de TV Digital Interativa baseada em microblog de conteúdoon-line. Associado a um pEPG, esta rede social permite que um telespectador realizefiltragens de conteúdo sobre um determinado assunto a partirdas indicações feitas poroutros telespectadores de sua rede. Isto permite que o telespectador crie sua própriaindicação para um determinado conteúdo no momento em que eleé exibido, ou aindaanalisar a importância de um determinado programaon-line, baseado nessas indicações.Isto permite que qualquer usuário possa realizar filtros no conteúdo, além de gerar e tro-car informações com os outros usuários de modo flexível e transparente, utilizando váriosdispositivos diferentes(TVs,Smartfones, Tablets ou PCs).Além disso, essa arquiteturadefine um mecanismo para realizar a mudança automática de canais baseado no melhorprograma que está passando no momento, sugerindo novos componentes a serem agre-gados ao middleware do Sistema Brasileiro de TV Digital (Ginga). Como resultado éconstruída uma base de dados dinâmica e que contém a classificação de vários programasde TV, bem como uma aplicação que permite mudar automaticamente para o melhor canaldo momento.

Palavras-chave: TV Digital, Redes Sociais Virtuais, Guias de Programação Eletrôni-cos, Classificação de Programas de TV.

Abstract

Due to the large amount of television content, which emergedfrom the Digital TV,viewers are facing a new challenge, how to find interesting content intuitively and ef-ficiently. The Personalized Electronic Programming Guides(pEPG) arise as an answerto this complex challenge. We proposeTrendTV a layered architecture that allows theformation of social networks among viewers of Interactive Digital TV based ononlinemicroblogging. Associated with a pEPG, this social networkallows the viewer to per-form content filtering on a particular subject from the indications made by other viewersof his network. Allowing the viewer to create his own indications for a particular contentwhen it is displayed, or to analyze the importance of a particular programonline, basedon these indications. This allows any user to perform filtering on content and generateor exchange information with other users in a flexible and transparent way, using severaldifferent devices (TVs, Smartphones, Tablets or PCs). Moreover, this architecture definesa mechanism to perform the automatic exchange of channels based on the best programthat is showing at the moment, suggesting new components to be added to the middlewareof the Brazilian Digital TV System (Ginga). The result is a constructed and dynamic da-tabase containing the classification of several TV programsas well as an application toautomatically switch to the best channel of the moment.

Keywords: Digital TV, Virtual Social Networks, Electronic Program Guides, TVShows Classification.

Sumário

Sumário i

Lista de Figuras iii

Lista de Tabelas v

1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Estrutura deste trabalho . . . . . . . . . . . . . . . . . . . . . . . . . .. 6

2 Embasamento Teórico 72.1 Interação Humano-computador . . . . . . . . . . . . . . . . . . . . . .. 72.2 Sistemas Distribuídos . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

2.2.1 Arquitetura Cliente Servidor . . . . . . . . . . . . . . . . . . . . 82.2.2 Arquitetura Multi-Camadas . . . . . . . . . . . . . . . . . . . . 92.2.3 Comunicação em Grupos . . . . . . . . . . . . . . . . . . . . . . 92.2.4 Paradigma MVC . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Redes Sociais Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 Interações Sociais . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.2 Métricas nas Redes Sociais . . . . . . . . . . . . . . . . . . . . . 13

2.4 Televisão Digital e Interatividade . . . . . . . . . . . . . . . . .. . . . . 142.4.1 TV Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.2 Interatividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.3 Arquitetura Geral da TV Digital . . . . . . . . . . . . . . . . . . 17

2.5 Middleware Ginga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.1 Ginga Common Core . . . . . . . . . . . . . . . . . . . . . . . . 192.5.2 Ginga-NCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5.3 Ginga-J . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Trabalhos Relacionados 233.1 PTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Mass Personalization. . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Tribler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

i

3.4 AmigoTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5 CollaboraTVware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.6 EPG-Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.7 Miso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.8 TA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.9 Comparação Entre Trabalhos . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Arquitetura TrendTV 314.1 Solução Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 Trend4Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.2 Trend4Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.3 Trend4TV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.4 Protocolo de Comunicação para a Mudança Automática de Canais 334.1.5 Cálculo Para Aplicação de Pesos às Notas dos Programas .. . . . 34

5 Cenários da Arquitetura TrendTV 355.1 Cadastrar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2 Adicionar Amigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3 Indicar Grau de Amizade . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 Conversar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.5 Indicar Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.6 Receber Meta-Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.7 Enviar Meta-Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.8 Mudar Canal Automaticamente . . . . . . . . . . . . . . . . . . . . . . . 40

6 Implementação e Resultados 416.1 Aplicação Trend4Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2 Aplicação Trend4Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . 426.3 Aplicações Trend4TV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3.1 Melhorias na Usabilidade . . . . . . . . . . . . . . . . . . . . . 456.3.2 Modelagem da Base de Dados . . . . . . . . . . . . . . . . . . . 456.3.3 Protocolo de Comunicação da Arquitetura TrendTV . . . . .. . 476.3.4 Implementação do Protocolo de Comunicação para a Mudança

Automática de Canais . . . . . . . . . . . . . . . . . . . . . . . 486.3.5 Estrutura das Mensagens JSON . . . . . . . . . . . . . . . . . . 49

7 Considerações Finais 557.1 Perspectivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Referências Bibliográficas 58

Lista de Figuras

1.1 Primeira página Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Exemplo deCSSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Exemplo de Aplicação daDTV . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Arquitetura Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . .. . 82.2 Arquitetura Multi-Camadas . . . . . . . . . . . . . . . . . . . . . . . . .92.3 Modelos de Comunicação em Grupos . . . . . . . . . . . . . . . . . . . 102.4 Fluxo de Execução do ParadigmaMVC . . . . . . . . . . . . . . . . . . 112.5 Exemplo de Comunidade em Redes Sociais Virtuais . . . . . . . . .. . . 122.6 Exemplo de Grafo de Rede Social . . . . . . . . . . . . . . . . . . . . . 132.7 Arquitetura Geral da TV Digital . . . . . . . . . . . . . . . . . . . . .. 172.8 Arquitetura do middleware Ginga . . . . . . . . . . . . . . . . . . . .. 182.9 Camada Ginga Common Core . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 Arquitetura do ProjetoPTV . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Arquitetura do ProjetoMass Personalization . . . . . . . . . . . . . . . 243.3 Arquitetura do ProjetoTribler . . . . . . . . . . . . . . . . . . . . . . . 253.4 Modelo de Funcionamento doAmigoTV . . . . . . . . . . . . . . . . . 263.5 Diagrama de Casos de Uso doCollaboraTVware . . . . . . . . . . . . . 27

4.1 Arquitetura Geral -TrendTV . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Fluxo de Comunicação para a Mudança Automática de Canais . .. . . . 33

5.1 Cenário geral da ArquiteturaTrendTV . . . . . . . . . . . . . . . . . . . 355.2 CenárioCadastrar Usuário . . . . . . . . . . . . . . . . . . . . . . . . 365.3 CenárioAdicionar Amigo . . . . . . . . . . . . . . . . . . . . . . . . . 365.4 CenárioIndicar Grau de Amizade . . . . . . . . . . . . . . . . . . . . 375.5 CenárioConversar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.6 CenárioIndicar Programa . . . . . . . . . . . . . . . . . . . . . . . . . 385.7 CenárioReceber Meta-Dados. . . . . . . . . . . . . . . . . . . . . . . 395.8 CenárioEnviar Meta-Dados . . . . . . . . . . . . . . . . . . . . . . . . 395.9 CenárioMudar Canal Automaticamente . . . . . . . . . . . . . . . . . 40

6.1 Arquitetura Implementada -TrendTV . . . . . . . . . . . . . . . . . . . 426.2 Classificação de Programas de Acordo com as Indicações dosUsuários . 436.3 Classificação de Programas na AplicaçãoTrend4Mobile . . . . . . . . . 446.4 Mudança Automática de Canais na AplicaçãoTrend4Mobile . . . . . . . 446.5 Mudança de Canais na AplicaçãoTrend4TV . . . . . . . . . . . . . . . 45

iii

6.6 DiagramaEntidade Relacionamento . . . . . . . . . . . . . . . . . . . 466.7 Exemplo de comunicação HTTP comCookies. . . . . . . . . . . . . . . 476.8 Exemplo deJSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Lista de Tabelas

2.1 Tipos de Interatividade . . . . . . . . . . . . . . . . . . . . . . . . . . .16

3.1 Comparação entre os trabalhos relacionados . . . . . . . . . . .. . . . . 30

6.1 Mensagens do Protocolo de Mudança Automática de Canais . .. . . . . 496.2 MensagemJSON com informações de umCanal . . . . . . . . . . . . . 496.3 MensagemJSON com informações de umPrograma . . . . . . . . . . . 506.4 MensagemJSON com informações sobre asTendências do Momento . 516.5 MensagemJSON com informações sobre asConversas . . . . . . . . . 52

v

Capítulo 1

Introdução

Quando começaram a surgir os primeiros computadores, cada pessoa usava o compu-tador isoladamente em frente a um monitor e um teclado. Para ajudar as pessoas a lidaremde maneira mais fácil com os computadores, o campo InteraçãoHumano-Computador(IHC ) foi criado, provendo interfaces e softwares mais fáceis deusar para o usuário co-mum.

Na década de 1960, houve uma revolução quando as pessoas começaram a enviarmensagens de máquina para máquina, utilizando uma rede criada pelo Departamento deDefesa dos Estados Unidos, aARPANET , que permitiu associar os grandes computado-res das universidades americanas a alguns de seus usuários [Cerf 1993].

Em seguida a comunicação se espalhou rapidamente através das barreiras organizaci-onais. A proliferação do correio eletrônico (e-mail) e doBBS (Bouletim Board System)na década de 80 permitiu a interligação entre computadores usando a linha telefônicae uma central de comunicação, denominada host. Estes hosts começaram a se associaruns com os outros através da rede mundial de computadores (World Wide Web) usandoa comunicação entre redes distintas (Internet). Esse termose tornou tão difundido quealguns chamam simplesmente deNet ou Web. A primeira página da web pode ser vistana Figura 1.1 [Berners-Lee & et al. 1992] :

A expansão da internet em 1990 (baseada na Web e e-mail) se tornou tão evidente queter um computador se tornou sinônimo de estar conectado a internet. Seu rápido cresci-mento e a estrutura de uma rede formada de redes torna difícilmensurar a sua quantidadede usuários.

Com o surgimento da internet começou a surgir nas pessoas a necessidade de criaremrelacionamentos virtuais de maneira mais dinâmica e para suprir essa necessidades foramcriadas asCSSN(Computer Supported Social Networks) [Wellman et al. 1996]. Assimestas redes se tornaram uma base importante para uma série deinterações humanas, como:trabalho colaborativo, trabalho a distância, comunidadesvirtuais, além de agregar maisum meio de comunicação as pessoas. A comunicação nas redes sociais é mais desinibida,criativa, informal e pode ou não estar fechada de pessoa parapessoa. Um exemplo derede social pode ser observado na Figura 1.2 [Twitter 2010] :

As redes sociais virtuais são diferentes de outras formas decomunicação mediadapor computador pois elas permitem manter os laços sociais estabelecidos no mundo off-line. Portanto, são considerados sites de redes sociais: osfotologs (Flicker e Picasa

2 CAPÍTULO 1. INTRODUÇÃO

Figura 1.1: Primeira página Web

Figura 1.2: Exemplo deCSSN

3

Web), weblogs(Wordpress e Blogger), microblogs (Twitter e Jaiku), além dos sites derelacionamento.

A televisão, por sua vez, é um dos maiores meios de comunicação em massa e umagrande ferramenta de influência social, pois ela muda o sistema de valores de uma soci-edade. A televisão também altera as atitudes pessoais individuais e também oferece aspessoas um sentimento de pertencer a uma comunidade global.

O modelo de transmissão original da televisão, e o mais utilizado até hoje, envolve atransmissão de som e imagens em movimento por ondas de radio-frequência (RF), quesão captadas por um receptor (o televisor). Neste sentido, éuma extensão do rádio.

A programação é o conteúdo da transmissão dos canais de televisão que são freqüen-temente dirigidos a uma determinada audiência que estará mais presente em um determi-nado horário. Exemplos programas sobre notícias locais/nacionais/internacionais(CNN,BBC),esportes (ESPN, SPORTV), filmes (HBO, Telecine), músicas(MTV ) entre outros.

Além disso, muitas redes de televisão produzem programasprimetime(horário nobre)para suas emissoras próprias ou afiliadas veicularem entre 19:00 e 23:00. Fora do horárionobre, grande parte das emissoras tem sua programação produzida localmente.

Recentemente estão sendo observadas mudanças no setor da televisão em várias fren-tes, como a migração para o conteúdo digital em alta definição. O advento da TV Digital(DTV ), ofereceu ao consumidor uma grande quantidade de canais e conteúdos de progra-mação além de permitir a utilização de serviços interativos. Um exemplo de aplicaçãopara TV Digital pode ser observado na figura 1.3:

Figura 1.3: Exemplo de Aplicação daDTV

Como parte de uma pesquisa de programas em serviços de TV personalizados, estãosendo desenvolvidas técnicas de recomendação e personalização que são interessantes aodomínio da TV [Smyth & Cotter 2001][Smeaton et al. 2001].

Partindo-se do pressuposto que a televisão digital possui interatividade e uma grandequantidade de conteúdo, propomos neste trabalho uma arquitetura para avaliação de pro-gramas de TV baseada na utilização de redes sociais para indicar a qualidade de umdeterminado programa em tempo real, que servirá como um guiapara um conteúdo maisrelevante com as necessidades de seus telespectadores. Utilizando-se dessa arquitetura ousuário poderá saber a opinião dos amigos que compõem a sua rede social sobre algum


programa que esteja passando na TV no momento e assim obter uma maior satisfação nahora de escolher um determinado canal.

Uma aplicação construída segundo esse paradigma deverá permitir que o usuário te-nha acesso a opinião de qualquer amigo que faça parte da sua rede social sobre algumprograma que esteja passando naquele instante. A partir da opinião de seus amigos ousuário pode mudar para o canal mais interessante ou ainda permitir que o sistema realizea mudança automática de canais, baseado nestas informações. O usuário poderá tambémse guiar pelos comentários de todos os usuários dessa aplicação para saber de maneirageral se o conteúdo que ele está assistindo no momento é interessante.

1.1 Motivação

Com o advento da TV Digital Interativa, surgiram inúmeras novas oportunidades deinteração com o usuário. A conexão com a internet promovida pelo canal de retorno tor-nou a interatividade ainda mais dinâmica, permitindo que diversos usuários pudessem secomunicar. Devido à possibilidade de muitos canais oferecerem conteúdos interessan-tes, fica difícil para o telespectador escolher o canal que possui o melhor programa domomento. Desta maneira, usuários iniciantes tendem a querer assistir muitos canais aomesmo tempo, e acabam por mudar constantemente de canal. Ao invés disso o usuáriodeveria aproveitar os programas e utilizar o controle remoto apenas para interação. As-sim, surge a necessidade de uma ferramenta que auxilie o telespectador nesse sentido.Dessa maneira, quanto maior a relevância dos resultados produzidos por esta ferramentamaior a satisfação do usuário.

Outro fator de motivação deste trabalho foi o fato de que estudos indicam que as redessociais (tanto reais como virtuais) possuem uma grande influência sobre as escolhas queuma pessoa faz [Hiltz et al. 1986][Kiesler et al. 1984][Rice &Love 1987][Adrianson &Hjelmquist 1991][Weisband et al. 1995]. Desse modo um sistema de indicação de con-teúdo televisivo baseado em redes sociais com suporte a multidispositivos seria bastanteinteressante.

Além da necessidade que os humanos tem de se comunicar, das facilidades que asredes sociais virtuais trouxeram, somado ao fato de a TV ser um meio de comunicação emmassa, o conteúdo que a televisão oferece funciona como uma espécie de "moeda social",no qual grupos de amigos tendem a assistir a mesma programação com o objetivo de gerarassuntos para conversas posteriormente, tanto no ambientereal como no ambiente virtual.

1.2 Definição do Problema

Devido à grande quantidade de conteúdo televisivo, que surgiu junto com a TV Di-gital, os consumidores estão diante de um novo desafio, sabercomo procurar conteúdointeressante de maneira intuitiva e eficiente. O guia eletrônico de programação perso-nalizado (pEPG) [Smyth & Cotter 2001] e uma biblioteca de vídeos digitais [Smeatonet al. 2001] compreendem parte de uma resposta para esse complexo desafio, e juntoseles podem direcionar os usuários para suprir suas necessidades. Tais sistemas empregam

1.3. OBJETIVOS 5

o uso de históricos e perfis do usuário nas suas técnicas de filtragem de conteúdo paraaprender mais sobre as preferências do usuário de maneira a oferecer conteúdo relevantea seus usuários.

Embora esses dois sistemas de filtragem de conteúdo sejam eficientes, eles apenasindicam a seus usuários os programas que foram classificadosde acordo com suas carac-terísticas mais gerais, não oferecendo a troca de opiniões pessoais entre seus usuários emtempo real, o que torna a sua classificação menos dinâmica e desatualizada. Além disso,esses sistemas de filtragem podem apresentar os problema decold-start(novos usuáriosnão conseguem recomendações por parte do sistema) efirst-rater (novos conteúdos nãopodem ser recomendados por ainda não possuírem classificação) [Sullivan et al. 2004].

Portanto o ponto de partida para o desenvolvimento das teorias abordadas neste traba-lho foi a construção de uma arquitetura que permita que usuários possam trocar opiniõespessoais em tempo real com outros usuários, tornando a classificação dos programas deTV mais dinâmica e atualizada, além de evitar os problemas defiltragem que foram cita-dos anteriormente.

A Internet surgiu para interconectar diversos ambientes distintos, permitindo aos seususuários navegarem por ela e utilizarem a grande diversidade de recursos que ela disponi-biliza. O crescimento vertiginoso da internet [Cisco 2010] ea evolução dos protocolos decomunicação associada ao barateamento da banda-larga permitem agora que não apenasusuários, mas também dispositivos possam realizar comunicação e troca de mensagens demaneira automática, sem o apoio do usuário.

Para permitir uma arquitetura que tenha suporte a multi-dispositivos é necessário cons-truir um padrão de comunicação comum a todos os dispositivos, disponibilizando assimuma maneira de realizar a troca de mensagens entre esses dispositivos sem a interferênciahumana, independentemente do fato de os dispositivos possuírem interfaces gráficas dis-tintas para o usuário. Este tipo de solução necessita que a lógica de funcionamento e asinformações não relacionadas a interface sejam consistentes, ou seja, a lógica e as infor-mações precisam ter o mesmo comportamento independente do dispositivo. Deste modo,podemos afirmar que esta solução segue o paradigmaMVC (Model-View-Controller) paraisolarmos os dados e informações das interfaces com o usuário.

1.3 Objetivos

O presente trabalho possui um objetivo principal e dois secundários.

* O principal objetivo deste trabalho é criar uma arquitetura que permite aos teles-pectadores da TV Digital indicar a qualidade de um determinado programa de TVem tempo real utilizando o conceito de redes sociais, para facilitar o processo dedecisão de um usuário baseado na influência de amigos que participam da sua redesocial.

* O primeiro objetivo secundário deste trabalho é realizar um comparativo entre asindicações realizadas por todos os usuários, e as indicações baseadas por sua redesocial, realizando um comparativo com as estratégias de classificação já existentes.


* O segundo objetivo secundário deste trabalho é desenvolver uma aplicação que va-lide a arquitetura proposta, incluindo uma aplicação que permita a troca automáticade canais, baseado nas indicações realizadas por seus usuários em tempo real.

1.4 Metodologia

Para modelar a arquitetura TrendTV foi utilizada a ferramentaUML Astah* Commu-nity [Change-Vision 2010], bem como a ferramenta de construção dediagramas onlineGliffy [Gliffy 2010].

Para realizar o desenvolvimento da aplicação, foi utilizada a abordagem de desenvol-vimento de software incremental, usando a metodologia ágilassociada aXP (eXtremeProgramming) [Beck & Andres 2004], que é ideal para pequenas equipes de desenvol-vimento com requisitos em constante mudança. Para validar aarquitetura, cada um dosmódulo foi implementado.

As linguagens de programação que foram utilizadas para o desenvolvimento da apli-cação para a TV foram as linguagensNCL [TeleMidia 2006],Lua [Ierusalimschy et al.2006] ouJava [Oracle 2010], utilizando omiddlewareGinga [LAViD 2006] ou o emu-ladorGinga-J [LAViD 2006] para a execução das aplicações. A interface de desenvolvi-mento dessas aplicações foi o ambiente de programaçãoEclipse[Campbell 2010].

A linguagem utilizada para o desenvolvimento da aplicação via Web foi a linguagemPHP, pois além de sua facilidade de desenvolvimento é muito utilizada para gerar con-teúdo dinâmico para a Internet [Dall’oglio 2007]. Em conjunto será utilizado oframeworkCodeIgniter, que permite desenvolver rapidamente aplicações web robustas e com baixaconfiguração [Upton 2007].

Para que haja troca de informações entre os usuários da aplicação, a aplicação fará usoda internet, pois além de receber, o usuário irá enviar informações. Assim, para executaressa aplicação na TV Digital existe a necessidade de se utilizar o canal de retorno.

1.5 Estrutura deste trabalho

Apresentamos no capítulo 2 um embasamento teórico sobre os conceitos que são im-portantes ao entendimento do trabalho que está sendo proposto.

No capítulo 3 discutimos os trabalhos relacionados, falando dos pontos fracos e fortesde cada um, além de realizar uma comparação com este trabalho.

O trabalho proposto será finalmente descrito no capítulo 4, no qual exibe o modelo eestruturas que compõem esta arquitetura.

O contexto em que essa arquitetura está inserida e quando e como ela pode ser usadaestá definido no capítulo 5 que descreve os cenários desta arquitetura.

No capítulo 6 apresentamos as implementações da nossa arquitetura, e os resultadosobtidos a partir dessas implementações.

E finalmente, no capítulo 7, apresentamos as considerações finais, bem como as pers-pectivas e trabalhos futuros relacionados ao tema.

Capítulo 2

Embasamento Teórico

O trabalho proposto baseia-se em uma série de conceitos que serão agrupados em 4tópicos principais: Interação Humano-Computador, Sistemas Distribuídos, Redes Soci-ais Virtuais, Televisão Digital e Interatividade. Esses tópicos e outros sub-tópicos serãoabordados a seguir.

2.1 Interação Humano-computador

A Interação Humano-computador (IHC ), como o próprio nome diz, é o estudo da inte-ração ou relação entre pessoas (usuários) e computadores. Suas áreas de estudo abrangema ciência da computação, ciência comportamental,design, artes, além de outros camposde estudo, sendo portanto um campo multidisciplinar. As interações entre usuários e com-putadores ocorrem através de uma interface de usuário, que inclui tanto hardware quantosoftware, e este é o principal foco de estudo, embora valha a pena ressaltar também queoutro aspecto importante da IHC é garantir a satisfação do usuário.

Entre as áreas que a IHC estuda podemos relacionar a usabilidade e a inclusão digital.O conceito de usabilidade surgiu na psicologia, associada àfisiologia e depois foi incor-porada à área de IHC. O estudo da inclusão digital envolve áreas como sociologia, ciênciapolítica, dentre outras.

A usabilidade é uma área de estudo doDesign, que trata sobre a facilidade com queuma pessoa pode empregar uma ferramenta ou um objeto criado pelo homem para alcan-çar um determinado objetivo. Na IHC, a usabilidade estuda a facilidade e clareza comque uma determinada aplicação interage com um usuário.[Nielsen 2003]

A inclusão digital surgiu para democratizar o acesso aos recursos digitais como ocomputador e aInternet, permitindo a inserção da população em geral na sociedadeda informação, que antes era restrita apenas às camadas maisfavorecidas da sociedade.[da Silva Filho 2003]

2.2 Sistemas Distribuídos

Um sistema distribuído nada mais é que uma referência à computação descentralizadae paralela que ocorre através da conexão entre dois ou mais computadores em uma rede,objetivando realizar uma mesma tarefa. De acordo com AndrewTanenbaum [Tanenbaum

8 CAPÍTULO 2. EMBASAMENTO TEÓRICO

& van Steen 2006] se trata de uma "coleção de computadores independentes que se apre-senta ao usuário como um sistema único e consistente".

A computação distribuída consiste em adicionar o poder computacional realizadopor todas as máquinas envolvidas para processar colaborativamente uma determinadatarefa de forma coerente e transparente, fazendo com que o usuário tenha a impressãoque apenas um único e centralizado computador estivesse executando a tarefa [Andrews2000][Dolev 2000][Ghosh 2007].

Diferentemente de sistemas multi-thread ou multi-tarefa,que utilizam mais de um pro-cessador para realizar suas operações mas compartilham o mesmo espaço de memória, ossistemas distribuídos se utilizam da comunicação inter-processos, e geralmente consistemde diferentes computadores distribuídos geograficamente se comunicando através de umarede [Lynch 1996]. Embora hoje em dia este seja um conceito impreciso pois podemoster um sistema distribuído dentro de um mesmo computador interagindo seus processosatravés de passagem de mensagem [Andrews 2000].

Para que ocorra a comunicação inter-processos num determinado sistema distribuído,é necessário que um modelo ou arquitetura seja definido, paraque seja possível a trocade mensagem entre esses diferentes processos. O modelo de comunicação utilizado nessetrabalho é o modelo cliente-servidor que será apresentado no sub-tópico 2.2.1.

2.2.1 Arquitetura Cliente Servidor

A arquitetura cliente-sevidor é uma estrutura de aplicações distribuídas que divideas tarefas entre os provedores de serviço, chamados de servidores e os consumidores deserviços, chamados de clientes [Reese 2000].

A figura 2.1 mostra a troca de mensagens da arquitetura cliente-servidor. Nesta figurapodemos perceber que vários clientes de um determinado serviço realizam requisições aum servidor, e em seguida o servidor envia as respostas a essarequisições realizadas pelosclientes.

Serviços que utilizam este tipo de arquitetura são os mais comuns dentre os sistemasdistribuídos. Alguns exemplos de serviços são os protocolos HTTP, FTP, DNS, bancosde dados, jogos on-line, dentre outros. Como estes serviços podem ter vários clientes, énecessário algumas alterações na infra-estrutura dessa arquitetura para dar suporte a umagrande quantidade de requisições.

Figura 2.1: Arquitetura Cliente-Servidor

2.2. SISTEMAS DISTRIBUÍDOS 9

2.2.2 Arquitetura Multi-Camadas

A arquitetura multi-camadas é uma arquitetura cliente-servidor na qual a apresenta-ção, o processamento da aplicação e o gerenciamento de dadossão processos separa-dos logicamente. Por exemplo, uma aplicação que usa uma camada de serviço inter-mediária entre o usuário e uma base de dados emprega esta arquitetura [Fowler 2002].As aplicações que utilizam essa arquitetura possuem em sua grande maioria 3 camadas[Eckerson 1995].

A arquitetura multicamadas provê um modelo aos desenvolvedores de criar aplicaçõesflexíveis e reusáveis, proporcionando um baixo-acoplamento e evitando que a aplicaçãoseja inteiramente reconstruída caso algum erro grave aconteça.

A figura 2.2 mostra a troca de mensagens de uma arquitetura multi-camadas, ondea camada de apresentação (que mostra a interface com o usuário) realiza requisições àcamada de lógica de negócios, que contém as lógicas de funcionamento das aplicações.A camada da lógica de negócios realiza requisições à camada de persistência, que contémos modelos de dados das aplicações. A camada de persistênciarealiza uma requisição abase de dados sobre as informações obtidas através das camadas superiores e finalmenteas respostas são devolvidas em cadeia para as camadas superiores.

Figura 2.2: Arquitetura Multi-Camadas

2.2.3 Comunicação em Grupos

Andrew Tanembaum [Tanenbaum & van Steen 2006] define que um agrupamento nacomunicação é "uma coleção de processos que agem juntos em algum sistema ou de al-guma forma específica". Nos sistemas distribuídos a comunicação interprocessos podevariar desde uma simples troca de mensagens entre dois processos até a troca de dadosentre milhares de processos. Assim surge a necessidade de organizar a estrutura de comu-nicação entre esses processos. Para isso são criadas estruturas de coordenação, definindoos modelos de comunicação entre grupos de processos e para que juntos forneçam umdeterminado serviço. Os três agrupamentos de comunicação mais comuns são [Soareset al. 1995]:


• Modelo Broadcast: a mensagem é transmitida para todos os processos, indepen-dente se a mensagem interessa ou não. Quem realiza a filtragemsão os processosinteressados naquela mensagem.

• Modelo Multicast: a mensagem é enviada apenas para os componentes de um grupoem particular.

• Modelo Unicast: a troca de mensagens é realizada ponto-a-ponto, onde o emissorenvia uma mensagem apenas para um destino.

A figura 2.3 exemplifica a troca de mensagens nesses 3 tipos de modelos de comuni-cação em grupos.

Figura 2.3: Modelos de Comunicação em Grupos

2.2.4 Paradigma MVC

O paradigmaMVC é uma arquitetura ou padrão arquitetural de software utilizado naengenharia de software para isolar a lógica de negócio da lógica de apresentação, atravésde três componentes distintos de forma que as modificações emum componente nãocausem impacto nos demais, dessa maneira aumentamos a coesão de cada componentee diminuímos o acoplamento, permitindo o desenvolvimento,teste e manutenção isoladodestes. Embora oMVC seja um padrão arquitetural, neste capítulo escolhemos tratá-locomo um paradigma, pois este foi o termo utilizado para defini-lo num dos primeirosartigos sobre oMVC [Burbec 1987].

Quem primeiro descreveu o paradigmaMVC foi o pesquisador daXeroxTrygve Re-enskaug em 1979, enquanto desenvolvia a interface doSmalltalk-80. Neste paradigma,as interações do usuário, a modelagem do mundo externo, e as lógicas do negócio estãoexplicitamente isoladas e cada uma delas é controlada por umcomponente de softwaredistinto. Estes componentes são especializados na execução de uma determinada tarefa.

A visão (View) apresenta o modelo num formato adequado ao utilizador, na saída dedados, e diferentes visões podem existir para um mesmo modelo, para diferentes propó-sitos.

O controlador (Controller) interpreta as informações transmitidas pelo usuário atravésdos periféricos de entrada e se encarrega de transmitir estas informações aoView ou aoModel, caso seja necessário. Ele também é responsável pela validação e filtragem daentrada de dados.

Finalmente, o modelo (Model) administra o comportamento e os dados de domínioda aplicação, responde aos eventuais pedidos de informaçãosobre o seu estado atual

2.3. REDES SOCIAIS VIRTUAIS 11

Figura 2.4: Fluxo de Execução do ParadigmaMVC

(geralmente requisitados pelo visão), e transmite instruções sobre eventuais mudanças deestado (geralmente requisitadas pelo controller).

A figura 2.4 demonstra o fluxo de execução doMVC :

1: O usuário faz uma requisição ao controlador.

2: O controlador filtra e processa os dados, e envia ao modelo que faz a lógica denegócios.

3: O modelo retorna os dados já processados de volta ao controlador

4: O controlador pode processar novamente os dados e então repassa esses dados pós-processaados a visão

5: Finalmente a visão retorna para o usuário os dados na interface desejada.

Ao se utilizar o paradigma MVC, é possível refazer o componente de visão, sem alte-rar nada dos outros componentes. Como cada dispositivo que foi utilizado neste trabalho(celulares, set-top-boxes, televisão e computadores) possui linguagem própria então alémda interface também é necessário refazer também os componentes de controle para cadadispositivo. Além de refazer os componentes de controle e devisão, os diferentes dispo-sitivos precisam se comunicar de maneira transparente e porisso, utilizar apenas o MVCnão servirá para solucionar o nosso problema, já que esse padrão arquitetural não trata deprotocolos de comunicação.

2.3 Redes Sociais Virtuais

As redes sociais virtuais são estruturas sociais compostaspor indivíduos, que estãoligados por um ou mais tipos de interdependência, tais como amizade, interesses co-muns, negócios, relações intimas, parentesco, fé, conhecimento, prestígio, dentre outros[Rheingold 1993]. Estes indivíduos interagem utilizando algum tipo de mídia (na maioriadas vezes a própria internet), partilhando dados e informações das mais variadas maneiras


e nos mais variados formatos (como fotos, vídeos, músicas, textos, etc) podendo atraves-sar inclusive barreiras geográficas e limites políticos [ComScore.com 2007].

A grande maioria das redes sociais virtuais também permite que grupos de pessoascom a mesma afinidade por um determinado assunto possam criarcomunidades virtuaise espaço para discussões, debates e apresentações de temas variados (comunidades e fó-runs) [Hof et al. 1997]. Um exemplo de comunidade virtual está apresentado na figura2.5:

Figura 2.5: Exemplo de Comunidade em Redes Sociais Virtuais

2.3.1 Interações Sociais

Uma interação social é uma associação entre duas ou mais pessoas que podem ser pas-sageiras ou duradouras. Estas interações podem ser baseadas em paixão, amor e simpatia,negócios, ou outros tipos de comprometimento social. As interações sociais ocorrem emuma grande variedade de contextos, como família, amigos, trabalho, clubes, religiões,dentre outros. Essas interações são a base para os grupos sociais e a sociedade como umtodo.

Estes relacionamentos geralmente envolvem algum nível de interdependência. Pes-soas em relacionamentos tendem a influenciar umas as outras,compartilhando seus pen-samentos e emoções, e realizar atividades juntas. Por causadessa interdependência, sealgo afeta um membro do relacionamento os outros membros também sofrem algum tipode impacto [Berscheid & Peplau 1983].

Quando as redes de computadores começaram a criar relacionamentos entre as pes-soas, começaram a surgir as interações sociais virtuais, e daí surgiu o conceito dasComputer-Supported Social Networks.

A partir daí, pesquisas em IHC começaram a ser realizadas sobre como grupos depessoas são mediados por sistemas de computadores. Muitos desses estudos examinaramcomo a presença social limitada (em comparação ao contato empessoa) da comunica-ção por computador afeta as interações entre as pessoas e alteram suas decisões. Estas

2.3. REDES SOCIAIS VIRTUAIS 13

pesquisas apontam que as características técnicas da comunicação por computador paratarefas em grupo produzem uma maior participação do grupo, de maneira mais igualitária,e com mais ideias sendo oferecidas, tornando a liderança menos centralizada [Hiltz et al.1986][Kiesler et al. 1984][Rice & Love 1987][Adrianson & Hjelmquist 1991][Weisbandet al. 1995]. A presença social limitada também encorajou aspessoas a se comunica-rem com mais liberdade e criatividade do que em pessoa, algumas vezes até cometendoexcessos de liberdade [Kiesler et al. 1984].

2.3.2 Métricas nas Redes Sociais

Para analisar o comportamento de uma rede social, os indivíduos devem ser considera-dos nós e cada nó é ligado ou conectado com outro através dos relacionamentos, formandodessa maneira grafos [Freeman 2006], que permitem diversostipos de métricas. A figura2.6 exemplifica um grafo de uma rede social utilizando a métricaCentrality.

Figura 2.6: Exemplo de Grafo de Rede Social

Algumas métricas freqüentemente utilizadas para analisaro comportamento de redessociais são:Centralization, Centrality, Closeness, Degree, Bridge, Reach, dentre muitasoutras [Wasserman & Faust 1994].

• Centralization: uma rede centralizada terá muitos de seus relacionamentosem tornode um ou poucos nós, enquanto uma rede descentralizada é aquela em que há poucavariação entre o número de ligações que cada nó possui.

• Centrality: esta medida dá uma indicação aproximada do poder social de um indi-víduo com base em quão bem ele se conecta a uma rede. Algumas métricas comoClosenesseDegreesão todas medidas deCentrality.

• Closeness: o grau de amizade de um indivíduo em relação a todos os outrosindiví-duos próximos na rede social (direta e indiretamente). Istoreflete na habilidade de


acessar informações mais relevantes e importantes entre osmembros da rede. Destamaneira, a métricaClosenessé inversamente proporcional a soma das menores dis-tâncias entre cada indivíduo e outra pessoa nessa rede.

• Degree: indica simplesmente a quantidade de relacionamentos que um indivíduotem em sua rede. Esta é a métrica mais usada pelas redes sociais virtuais.

• Bridge: um relacionamento é ditoBridge, quando ele conecta dois grupos distin-tos dentro de um grafo e caso este relacionamento seja apagado, isto irá causar aseparação destes grupos em dois grafos distintos.

• Reach: esta métrica calcula o grau que qualquer membro de uma rede pode alcançaroutro membro de uma rede.

2.4 Televisão Digital e Interatividade

A Televisão Digital (TVD ) é um modelo de transmissão de áudio e vídeo através desinal digital, em contraste com o sinal analógico utilizadopelas TVs analógicas. Mui-tos países estão substituindo a transmissão analógica pelatransmissão digital pois estapermite um melhor uso do espectro do sinal de TV.

A TV Digital proporcionou a divisão da transmissão em três categorias principais:SDTV (Standard Definition Television),HDTV (High Definition Television) e aEDTV(Enhanced Definition Television). A primeira é um serviço deáudio e vídeo digitais,parecida com a TV analógica, na relação de aspecto 4:3 (largura:altura da imagem), cujosaparelhos receptores possuem 408 linhas, com 704 pontos em cada uma. AHDTV , cujaimagem possui formato 16:9, é recebida em aparelhos com 1080linhas de definição e1920 pontos. Entre esses dois sistemas existe aEDTV , TV de média definição, quepossibilita a utilização de aparelhos com 720 linhas de 1280pontos. Dependendo dalargura de banda disponível para a transmissão, é possível mesclar essas modalidadesde TV digital, uma vez que a qualidade da imagem no receptor é proporcional à bandautilizada pela transmissão [Montez & Becker 2004].

A TVD tem diversas vantagens sobre a TV analógica, a mais significativa é que oscanais digitais ocupam menos largura de banda, e as necessidades de banda variam conti-nuamente, dependendo da redução realizada na qualidade da imagem e os níveis de com-pressão da imagem transmitida. Isto significa que os transmissores podem transmitir maiscanais digitais utilizando o mesmo espaço ou prover serviços de TV de alta-definição, ouainda prover serviços não televisivos como transmitir multimídia ou realizar interativi-dade. ATVD também permite serviços especiais tais como multiplexação(mais de umprograma no mesmo canal), guias eletrônicos de programaçãoe suporte a nacionalização(dublagens ou legendas). A venda de serviços também poderá ser mais uma fonte de lucropara as transmissoras [Montez & Becker 2004].

Além disso, os sinais digitais possuem comportamento diferente com relação a in-terferência do sinal em relação ao sinal analógico. Na TV analógica problemas como"fantasmas"ou imagens borradas podem acontecer, mas ainda assim é possível continuarassistindo a TV. No sinal digital o áudio e o vídeo precisam estar sincronizados digital-mente, então a recepção do sinal precisa ser quase perfeita,do contrário não é possivelassistir a programação [Montez & Becker 2004].

2.4. TELEVISÃO DIGITAL E INTERATIVIDADE 15

2.4.1 TV Social

A TV Social surgiu como uma tecnologia que suporta a comunicação e interação so-cial entre os usuários no contexto do ambiente televisivo. Este contexto envolve o estudodo comportamento social relacionado à televisão, além de redes e dispositivos. SegundoMarie-Jose Montpetit a TV social "não é apenas sobre pessoas serem sociais; é tambémsobre dispositivos e até redes sendo sociais."[Montpetit 2009]. Sistemas de TV Sociaisdispõe de facilidades para o telespectador assistir à televisão enquanto realiza interaçõessociais, podendo integrar por exemplo sistemas de recomendação e classificação de pro-gramas, chat de texto, comunicação por voz, navegação na webou até mesmo video-conferências utilizando equipamentos auxiliares [Gross et al. 2009].

Pode parecer uma surpresa, mas o conceito de socializar utilizando a televisão não énovo, a TV já é social e sempre foi. Assistir à TV é um evento coletivo e centralizado paraa família, assim como à cinqüenta anos atrás. Mas devido ao seu barateamento, estudosmostram que mais da metade das residências americanas possuem três ou mais aparelhosde TV com mais de 250 canais [Nielsen.com 2010], tornando a TVuma experiênciaindividual. Numa tentativa de recuperar este aspecto social de assistir televisão juntos,a TV Social tenta conectar os telespectadores e seus amigos mesmo quando estes nãoassistem à mesma tela.

Embora exista essa fragmentação no consumo, ainda não existe mecanismo de co-municação em massa que se compare à TV como experiência social. Estudos realizadospelo Grupo Nielsen, demonstram que cerca de metade da população online comenta sobreassuntos relacionados à televisão, além de que entre 10 e 17%das tendências online domomento falam sobre programas de TV [Nielsen.com 2011]. Futebol, Copa do Mundo,Olimpíadas, Novelas, Seriados são todos programas de TV quedemonstram que a TVsempre foi social na medida que reúne pessoas em torno das experiências que eles que-rem compartilhar.

Um sistema de TV Social que utiliza uma ou mais telas pode permitir consumo para-lelo e interação com o conteúdo da televisão, criando experiências mais interessantes. Porexemplo, os telespectadores poderiam realizar uma seleçãodos pré-candidatos a entrarnum programa dereality-show, através de dispositivos como tablets, smartphones ou aprópria televisão utilizando a web, ao invés de simplesmente escolher quem irá vencer oprograma. Desta maneira, os telespectadores teriam a experiência de fazer parte do iníciodo ciclo de produção de um programa, causando impacto inclusive sobre o valor destamídia para os patrocinadores, na medida em que através de estudos de comportamento,pode-se criar propagandas altamente focadas no usuário [Rempt 2010].

Nos Estados Unidos, cerca de 25% dos novos modelos de televisão acessam a web[Albrecht 2009]. A convergência de mídias já está acontecendo, e em um futuro próximonão haverá distinção entre o conteúdo web e o conteúdo para TV, pois as aplicações webe mobile irão se associar à TV para interagirem com formatos econteúdos.

Como esta tecnologia irá evoluir ainda não está claro, pois existem muito desafios, queenvolvem tanto problemas relacionados à tecnologia (como padrões, plataformas), comoproblemas associados à adequação de conteúdo, monetizaçãoe propriedade intelectual[Rempt 2010].


2.4.2 Interatividade

A interatividade na TV surgiu junto com os sistemas deTVD e permite a interaçãoentre o telespectador e o aparelho de TV. Ela pode ser entendida de várias maneiras deacordo com o sistema deTVD que está sendo utilizado. A interação pode ocorrer simples-mente entre oSet-Top-Box(STB) e o usuário, para mudar o canal ou visualizar oEPG.OsmiddlewaresparaTVD mais modernos, como é o caso doGinga, também permitema interação entre o telespectador e a emissora através de canais de retorno e aplicaçõescriadas pela própria emissora [Machado 1999].

O canal de retorno permite a comunicação bidirecional entreo telespectador, as apli-cações interativas e o provedor de conteúdo, que no caso daTVD pode ser a própriaemissora ou um terceiro. O canal de retorno oferece a transmissão de informações perso-nalizadas de cada usuário, enviando dados pessoais do telespectador, como uma mensa-gem de correio eletrônico, agenda de tarefas ou acesso ahome-banking. [Machado 1999]cita os diferentes tipos de interação na tabela 2.1:

Classe de Interatividade MeioInteração Forte: transmissão

bidirecional, simétricaRedes de Comunicação de Dados e

Sistema de RadiodifusãoInteração Forte: transmissão assimétrica

bidirecional, de retorno solicitada pelousuário

Sistema de Radiodifusão

Interação Média: transmissãoassimétrica bidirecional, de retorno

solicitada pela emissoraSistema de Radiodifusão

Interação Fraca: transmissãoassimétrica bidirecional, de retorno

off-lineSistema de Radiodifusão

Interação sem canal de retorno:transmissão unidirecional, sendo oterminal um servidor de aplicações

Sistema de Radiodifusão

Tabela 2.1: Tipos de Interatividade

A interação forte com transmissão de dados simétrica possuitaxas de transmissão se-melhantes nos canais de retorno e de ida, trafegando dados normalmente, esse modelogeralmente é usado em transmissões de TV a cabo que utilizam canais de interação si-métricos para dados. Já a classe de interação forte utilizando o sistema de radiodifusãocompartilha o canal de retorno entre diversos usuários (usando multiplexadores das redesde celulares, como por exemploTDMA , FDMA ou CDMA ). A interação média é usadana forma de "coleta"através de algumas opções dadas aos usuários. Na interação fraca, ousuário envia informações para a emissora sem possibilidade de alterações na programa-ção ou lógica que está recebendo. Na interação sem canal de retorno, o sinal é transmitidopela emissora, já com a aplicação e os dados armazenados na memória. O telespectadorinterage, embora apenas escolha apenas opções que já estão predefinidas pela aplicação[Barrér & Leite 2009].

2.4. TELEVISÃO DIGITAL E INTERATIVIDADE 17

2.4.3 Arquitetura Geral da TV Digital

A arquitetura de um sistema de televisão digital interativaé dividido em 5 camadas:(1) aplicação; (2) middleware; (3) codificação; (4) transporte; (5) transmissão. A ideiacentral da arquitetura em camadas é cada uma oferecer serviços para a camada superior eusar os serviços oferecidos pela inferior [Oliveira & Lacerda 2008]. A figura 2.7 apresentacada uma destas camadas [Fernandes et al. 2004], que serão descritas a seguir.

Figura 2.7: Arquitetura Geral da TV Digital

A Camada de Aplicaçãoresponde pela captura e formatação dos sinais de áudio evídeo, bem como pela execução dos aplicativos multimídias desenvolvidos. As aplicaçõescomportadas vão desde jogos e internet até aplicações governamentais e de comércioeletrônico.

A Camada de Middlewareé uma camada usada para ocultar do programador diferen-ças de protocolos de comunicação, plataformas e dependências do sistema operacional.É geralmente constituída por módulos dotados com APIs de alto nível que proporcionama sua integração com aplicações desenvolvidas em diversas linguagens de programação einterfaces de baixo nível que permitem a sua independência em relação ao dispositivo.

A Camada de Codificação e Decodificaçãoremove redundâncias nos sinais de áu-dio e vídeo, reduzindo assim a taxa de bits necessária para transmitir essas informações[Mendes 2007].

A Camada de Transporteé responsável por realizar a multiplexação e demultiplexa-ção dos fluxos elementares de áudio, vídeo e dados. A idéia da multiplexação é agruparáudio, vídeo e dados em um único fluxo a ser transmitido e demultiplexá-lo quando estefluxo chegar no receptor [Oliveira & Lacerda 2008].

A Camada de Transmissão e Recepçãoleva as informações digitais da emissoraaté a casa dos telespectadores. Contudo, as informações não podem ser enviadas dire-tamente pelo sistema de comunicação sem antes sofrer uma modulação no envio, e umademodulação na recepção [Mendes 2007].


2.5 Middleware Ginga

O middleware brasileiro (o sistema que irá funcionar nosSet-Top Boxesfornecendoas funções previstas nas normas regulamentadoras doSBTVD) Ginga é resultado deuma ação conjunta entre a Universidade Federal da Paraíba (UFPB), criadora do móduloresponsável pela interpretação de códigoJava (Ginga-J) nosSTBsque incorporam asespecificaçõesGlobally ExecutableMHP (GEM , que atualmente não faz mais parte daespecificação do Ginga), e a Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio), responsável pelo desenvolvimento da linguagem de marcaçãoNCL e a linguagemde scriptLua e da especificação de seu motor de apresentação(Ginga-NCL) [Morenoet al. 2011][Melo & Araújo 2008].

O Ginga é uma camada de software intermediária, situada entre o sistema operacionale as aplicações. A primeira função dele é tornar as aplicações independentes da plata-forma de hardware e a segunda função é comportar à interatividade, através do suporteao desenvolvimento de aplicações. O sistema é composto por três módulos ou camadasprincipais (Ginga-CC, Ginga-NCL e Ginga-J), permitindo que aplicações sejam desen-volvidas usando modelos de programação diferentes. A figura2.8 mostra a arquitetura doMiddleware Ginga.

O middleware Ginga surgiu como uma tecnologia que leva ao cidadão todos os meiospara que ele obtenha acesso à informação, educação a distância e serviços sociais, uti-lizando apenas sua TV. O Ginga é uma especificação aberta, de fácil aprendizagem elivre de royalties, possibilitando que qualquer programador produza conteúdo interativo,impulsionando a programação de TVs comunitárias, por exemplo. Quando o Ginga foidesenvolvido, o Brasil foi o primeiro pais a possuir uma solução em software livre pra TVDigital.

Figura 2.8: Arquitetura do middleware Ginga

2.5. MIDDLEWARE GINGA 19

2.5.1 Ginga Common Core

O Ginga-CC (Ginga Common-Core) é a camada do middlewareGinga que ofereceo suporte básico tanto para os ambientes procedurais quantodeclarativos e é responsávelpor permitir a utilização de imagens (PNG, JPG e GIF), sons (MP3, WAV e MIDI) evídeo (MPEG4). Ele também fornece métodos para o controle e obtenção dos fluxosde transmissão (ISDB-TB) e do Canal de Retorno, módulo responsável por controlar oacesso à camada de rede. A figura 2.9 mostra a estrutura desta camada e seus componentesque serão descritos a seguir [Damasceno 2008].

Figura 2.9: Camada Ginga Common Core

* Acesso Condicional: restringe os conteúdos considerados inapropriados garan-tindo segurança ao middleware.

* Canal de Retorno: ele provê a interface das camadas superiores com o canal deinteração (ou canal de retorno). Além disso, ele deve gerenciar o canal de retornode forma que dados sejam transmitidos assim que o canal esteja disponível, ou"forçar"a transmissão caso o usuário ou uma aplicação tenha definido o horárioexato [Damasceno 2008].

* Gerenciamento de Contexto: captura o perfil do usuário, alertando os outros com-ponentes. O perfil pode conter informções como os horários emque o usuárioassiste a TV, ou bloqueio e desbloqueio de canais, entre outros.

* Interface com o Usuário: gerencia os eventos gerados pelo usuário como coman-dos do controle remoto, e alertar outros módulos interessados.

* Exibidor de Mídia : ferramentas para exibir e tratar arquivos de mídias recebidos,como por exemplo, os tipos MPEG, JPEG, TXT, MP3, GIF, HTML, etc.

* Gerenciador de Atualizações: componente que gerencia as atualizações feitas nosistema, verificando, baixando e atualizando o middleware sempre que necessário,


para correção de possíveis erros encontrados em versões anteriores. Isto deve serfeito em tempo de execução, sem incomodar o uso normal da TV pelo usuário[Damasceno 2008].

* Gerenciador de Gráfico: os padrões de middleware definem como as imagens,vídeos,dados, etc, são apresentados para os usuário, gerenciando as apresentações da mesmaforma que é definida no padrão ARIB [ARIB-B-24 2004]

* Iniciador de Aplicações: carregar, configura, inicializa e executa aplicações dosambientes declarativos e procedurais, além de controlar o ciclo de vida dessas apli-cações e os recursos utilizados.

* Persistência: dá suporte ao gerenciamento de arquivos, mesmo depois do processoque o criou tenha sido finalizado, para que este possa ser aberto em outra oportuni-dade.

* Processador de Dados: gerencia os dados recebidos pela camada física, além denotificar os componentes sobre qualquer evento que tenha sido recebido.

* Filtro de Seções: uma vez sintonizado, o middleware deve ser capaz de acessarpartes específicas do fluxo de transporte. Para isso, o Filtrode Seção pode procurarno fluxo a parte exata que as APIs necessitam para suas execuções, deixando passarapenas as informações requeridas pela API [Damasceno 2008].

* Sintonizador/Tuner: como o próprio nome diz, este módulo "sintoniza"o canal,escolhendo um canal físico e um dos fluxos de transporte que estão sendo enviadosneste canal.

* Adaptador do A/V Principal : permite que as aplicações consigam enxergar ofluxo de áudio e vídeo. Permitindo que uma aplicação possa controlar suas ações,de acordo com o que está sendo transmitido.

2.5.2 Ginga-NCL

O Ginga-NCL foi desenvolvido pela PUC-Rio com o objetivo de prover uma infra-estrutura de apresentação para aplicações declarativas escritas na linguagem NCL (Nes-ted Context Language) [15606-2 2007] [ITU-T Recommendation H.761 2009], que é umamodelo XML com facilidades para a especificação de aspectos de interatividade, sincro-nismo espacial e temporal em sua forma mais geral, adaptabilidade de conteúdo e formasde apresentação de conteúdo, suporte a múltiplos dispositivos, dentre outros. Para algunscasos, como por exemplo a geração dinâmica de conteúdo, NCL provê o suporte de sualinguagem de script Lua [NCL.org.br 2009].

2.5.3 Ginga-J

O Ginga-J foi desenvolvido pela UFPB para suprir todas as funcionalidades necessá-rias para a implementação de aplicações baseadas na linguagem Java, com modificações

2.5. MIDDLEWARE GINGA 21

voltadas para o ambiente de TV digital, provendo APIs e ferramentas que incluem desdea manipulação de dados multimídia até protocolos de acesso.Este módulo é respon-sável pelo processamento de componentes procedurais definidos como objetos Xlet. Omódulo é composto por, dentre outros, uma máquina virtual Java desenvolvida especial-mente para funcionar em sistemas embarcados com baixo poderde processamento [Melo& Araújo 2008].


Capítulo 3

Trabalhos Relacionados

Guias de Programação Eletrônicos que indicam as grades de programação das emis-soras de TV existem desde a década de 1980 e seu objetivo principal é ajudar o usuário aencontrar programas com mais rapidez. Contudo, hoje em dia, com a grande quantidadede emissoras e programas de TV, se torna difícil descobrir com facilidade um programade televisão que seja interessante mesmo com o auxílio da grade de programação. Paradiminuir a quantidade de informação gerada pelo crescimento no número de programas,muitos projetos utilizaram guias de programação personalizados baseados em predição ourecomendação. Mas considerando que um processo de decisão não é realizado apenas pe-las preferências pessoais mas também pelos relacionamentos [Berscheid & Peplau 1983],estes guias de programação personalizados não são os mais adequados para ajudar osusuários. No contexto da TV Digital Brasileira, é necessárioainda que seja possível ava-liar um programa de televisão utilizando vários dispositivos, devido a limitação de acessoà banda larga no Brasil.

Este capítulo apresenta alguns trabalhos que tentam solucionar os problemas apresen-tados anteriormente. A arquitetura TrendTV surge para solucionar esses mesmos proble-mas e será apresentada no próximo capítulo. Este capítulo também irá exibir as soluçõese problemas apresentados pelos trabalhos discutidos.

3.1 PTV

Uma das primeiras tentativas de ferramenta para o direcionamento dos usuários atra-vés de um guia de programação personalizado foi o projetoPTV [Smyth & Cotter 2001].Um sistema multidispositivo (celulares e PDAs), baseado emperfis de usuário e inteligên-cia artificial. Mas apesar de ser considerado um guia de programação personalizável, estesistema não permitia o acesso direto através da TV, funcionando apenas em clientes web.A medida que o usuário vai assistindo aos programas e alimentando o móduloProfilerdo sistema, ele guarda os programas mais assistidos do usuário e traça um perfil. A partirde uma base de dados contendo programas cadastrados e o perfildo usuário, o móduloRecommenderconstrói uma lista com todos os programas recomendados. Finalmente, omóduloGuide Compiler gera um guia de programação online personalizável a partir dalista gerada pelo móduloRecommendere uma base de dados com grade de programaçãodo momento. A figura 3.1 mostra a arquitetura do ProjetoPTV.

24 CAPÍTULO 3. TRABALHOS RELACIONADOS

Figura 3.1: Arquitetura do ProjetoPTV

3.2 Mass Personalization

Figura 3.2: Arquitetura do ProjetoMass Personalization

Como a televisão é uma experiência social e o processo de decisão se baseia em grandeparte por influência e sociabilidade, as tendências das pesquisas são a integração das redes

3.3. TRIBLER 25

sociais no contexto da televisão. Um exemplo dessa tendência é o projetoMass Perso-nalization [Fink et al. 2006]. Este é um framework que combina televisãocom umaexperiência personalizada baseada na web. Ela unifica quatro aplicações distintas: taxasde popularidadeon-line, serviços de bibliotecas de mídias virtuais, comunidades sociaisad-hoc (que é um chat com os usuários que estão assistindo o mesmo programa de TV) ecamadas de conteúdo personalizado (que é uma camada extra com informações relacio-nadas a um programa de TV). Como neste trabalho, oMass Personalizationoferece umsistema de classificação de programas de TV, mas são serviçosapenas baseados na web.Então o usuário tem que interagir apenas com o computador e não com uma televisão.Este único modelo de interação pode causar problemas com o usuário, pois ele precisadividir sua atenção entre a televisão e o computador. A figura3.2 mostra a arquitetura doProjetoMass Personalization.

3.3 Tribler

Figura 3.3: Arquitetura do ProjetoTribler

O projetoTribler [Wang et al. 2006] também descreve uma rede social para a TV, naqual a troca de mensagens é baseada na arquitetura de redepeer-to-peer. Ele apresenta umesquema de relacionamento, chamado deBuddyCast, que constrói uma rede social para atroca de interesses entre os perfis de usuários. Essas informações do perfil de usuário sãoconstruídas baseadas em classificações dos conteúdos pelosusuários ou por análises dohistórico das mudanças de canal realizadas pelo usuário. Essas classificações e históricossão usadas então para sugerir conteúdo personalizado ao usuário. No trabalho que nósapresentamos, o comportamento do usuário é usado como um sistema de classificaçãocomunicando a comunidade de amigos desse usuário às suas preferências, já que nossasescolhas são em sua grande maioria determinadas pelas influências de outras pessoas que


fazem parte da sua rede social. A figura 3.3 mostra a troca de mensagens do sistemaTribler .

3.4 AmigoTV

Figura 3.4: Modelo de Funcionamento doAmigoTV

A importância na comunicação no contexto da TV também foi abordado pelo projetoAmigoTV [Coppens et al. 2004]. Este projeto permite comunicação utilizando a própriavoz, através da televisão. Especificamente, os usuários podem falar com seus amigosque estão identificado através do uso de avatares. Este projeto utiliza uma abordageminovadora pois ele suporta a comunicação em tempo real. Nós preferimos a comunicaçãotextual, pois ela continuará a ser exibida na tela caso o usuário não esteja na frente da TVno momento que a mensagem é enviada. A figura 3.4 mostra o modelo de funcionamentodo protótipo de arquiteturaAmigoTV .

3.5 CollaboraTVware

O projetoCollaboraTVware [Alves 2008] têm como principal objetivo propor e im-plementar uma infra-estrutura de software no cenário da TV Digital Interativa para orien-tar os usuários na escolha de programas e serviços interativos através da participação co-laborativa de outros usuários com perfis e contextos similares, baseando-se inteiramenteno comportamento dos perfis de usuário e utilizando técnicasde inferências para reali-zar as recomendações. Dessa maneira, trata-se de um projetobastante parecido com osGuias Eletrônicos de Programação Personalizáveis que foram discutidos anteriormente.A figura 3.5 mostra o diagrama de casos de uso do projetoCollaboraTVware.

3.6 EPG-Board

O projetoEPG-Board [Iatrino & Modeo 2007], também realiza um sistema de clas-sificação de programas de televisão incorporando a influência das redes sociais. Elesdescrevem um sistema voltado para centros de mídia (media centers), desenvolvendo umEPG social que integra um quadro de mensagens, um sistema de indicação compartilhado

3.6. EPG-BOARD 27

Figura 3.5: Diagrama de Casos de Uso doCollaboraTVware

e um sistema de etiquetagem (tagging). Eles utilizam oOmegaBox1, um sistema paracentros de mídia baseado em Linux. E assim como nesse trabalho, o objetivo deste projetoé influenciar na decisão das pessoas no momento da escolha de um determinado programade televisão baseado na opinião de outros usuários.

O quadro de mensagens é uma aplicação que permite que o usuário se comunique comoutros usuárioson-linemas de maneira assíncrona e funciona da mesma maneira que nonosso trabalho.

O sistema de indicação compartilhado envia a opinião de um usuário sobre um de-terminado programa para a sua rede de amigos, onde é possívelclassificar apenas comobom ou ruim, diferentemente do modelo de classificação por notas proposto neste traba-lho, permitindo uma maior precisão na classificação. Além disso o sistema não leva emconsideração a força dos laços de confiança dos usuários, quepossuem pesos diferentesquanto à influência que realizam.

No sistema de etiquetagem apresentado pelo projetoEPG-Board, qualquer usuáriopode definir os metadados sobre um determinado programa de televisão, como gênero,diretor, entre outros, o que poderia causar problemas de inconsistência nos dados. Nonosso trabalho, os metadados sobre um determinado programasão manipulados apenaspor usuários credenciados (como as próprias emissoras por exemplo).

O projetoEPG-Board especifica também os elevados requisitos dehardwareparao funcionamento doOmegaBox, tornando-o muito custoso e portanto proibitivo para ocontexto de inclusão digital proposto pelo governo brasileiro. Além disso este projeto sósuporta a comunicação entre usuários que utilizam o próprioOmegaBox, deixando osusuários de outros dispositivos de fora, como um cliente webpor exemplo. Outro pro-blema observado no projetoEPG-Board é a facilidade que um usuário tem de alterar osmeta-dados sobre um determinado programa, podendo levar usuários maldosos a realiza-


rem qualificações absurdas, ou simplesmente apagar os meta-dados, e ao invés de facilitarpode acabar dificultando nas buscas por programas baseados nestes meta-dados.

3.7 Miso

O projetoMiso [goMiso.com 2011] é uma rede social virtual que dá uma segundaexperiência para quem assiste a televisão. Ela permite aos usuários compartilharem en-tre si o que eles assistiram, através de um sistema decheck-in, além de um sistema depontuação para estimular seu uso, possuindo um comportamento que se assemelha aoFoursquare [foursquare.com 2011]. Embora seja uma rede social para televisão, ela nãodisponibiliza vídeos on-line nem permite assistir o conteúdo, sendo inteiramente voltadopara a web. O sistema oferece um sistema de troca de mensagensentre usuários, mas nãopermite a classificação dos programas on-line, permitindo apenas uma classificação gerale atemporal, pois não existem requisitos temporais para se realizar o check-in. Além dissoesta rede social apresenta o conceito dehostsque são usuários especiais, que controlamalguns meta-dados dos programas, criam enquetes sobre o programa, além de realizaroutras atividades com mais privilégio que um usuário comum.

3.8 TA2

O principal objetivo do projetoTogether Anywhere Anytime (TA2) é tornar a comu-nicação e os relacionamentos mais fáceis entre grupos de pessoas separados no espaço,através de umframeworkque centraliza todas estas atividades. Diferente das mídias atuaisque são voltadas para o indivíduo este mecanismo de comunicação é voltada para gruposde pessoas e é caracterizado pela naturalidade, tornando a experiência imersiva mais in-teressante. Este projeto permite que os grupos possam jogar, tocar e aprender música,contar histórias, além de se comunicar. Este framework inclui tecnologias como: rende-rização de áudio e vídeo em alta definição sem perdas ou atrasos, ambientes de capturae reprodução de vídeos, análise dos dados permitindo caracterizar se o fluxo de vídeo éum monólogo ou um diálogo, modelo de composição multimídia permitindo a inserçãode conteúdo XHTML nos vídeos, gerenciamento de serviços para coordenar o uso dosdiferentes softwares e dispositivos, e finalmente a orquestração que transforma os dadosde baixo nível recebidos pela ferramenta de análise em aspectos mais significativos dainteração social.

3.9 Comparação Entre Trabalhos

A Tabela 3.1 mostra um quadro comparativo entre os trabalhosque foram aqui apre-sentados. Os trabalhos foram agrupados nas colunas, na quala última coluna aborda anossa arquiteturaTrendTV . Desta maneira, tentamos realizar uma comparação entre osprojetos e trabalhos apresentados aqui e também já expor a arquitetura neste panorama.Definimos algumas características que são comuns entre o nosso trabalho e os trabalhos

3.9. COMPARAÇÃO ENTRE TRABALHOS 29

apresentados aqui. São eles: Suporte a Multi-Dispositivos, Serviço Web, Indicação deProgramasOn-line, Chat por texto,Chat por voz, Histórico de Conversas, Suporte aoSistema Brasileiro de TV Digital, Suporte aSet-Top-Boxes, Classificação de Meta-DadosColaborativamente, Sistema de Notas, Indicação Baseada em Inferências, Indicação Ba-seada em Influência Direta, Comunidades Virtuais, Suporte a outras redes sociais e Grausde Confiança.

O Suporte a Multi-Dispositivos diz respeito aos tipos de dispositivo que o projetosuporta, comoSet-Top-Boxes, celulares, PDAS, computadores, entre outros. Como apre-sentado na tabela 3.1 os projetos que suportam multi-dispositivos foram a arquiteturaTrendTV e os projetosPTV, CollaboraTVWare , Miso, TA2.

Os serviços Web são serviços disponibilizados pelos projetos para serem acessadospor outras aplicações ou pelo usuário.

Como pode ser visto na tabela 3.1 todos os projetos que temChatpor texto, tambémindicam programason-line, e mantém o histórico das conversas. Isto acontece porque foiassumido que um chat pode funcionar como um mecanismo de indicação de programas.

Os únicos projeto que utilizaram o modelo doSBTVD foram oCollaboraTVware ea arquiteturaTrendTV , ambos desenvolvidos no Brasil.

O suporte aSet-Top-Boxesnão foi realizado pelos projetosPTV, Mass Personaliza-tion, Miso, TA2, sendo voltados inteiramente pra Web.

A classificação de Meta-Dados Colaborativamente diz respeito a alterar as informa-ções fundamentais sobre um determinado conteúdo, como o gênero, o horário de exibição,o idioma, a duração, entre outros. Os projetos que fazem essaclassificação colaborativasão oEPG-Board e o projetoMiso.

No Sistema de Notas o usuário define uma nota para um determinado programa, quegeralmente varia de 1 a 5 ou 1 a 10, permitindo uma maior precisão na classificação deum programa.

Na indicação baseada em inferências, os projetos analisam operfil de acesso do usuá-rio através de históricos e utilizam mecanismos de inferência como Redes Neurais, LógicaFuzzy, Modelos Estatísticos dentre outros.

Pela tabela 3.1 podemos perceber também que todos os projetos que possuemChattanto por texto quanto por voz causam influência direta sobreseus usuários.

Embora vários projetos possuam chats e mecanismos de comunicação, apenas 5 proje-tos apresentaram uma comunidade virtual. A propriedade Comunidade Virtual refere-seà possibilidade de se construir uma rede de amigos duradoura, assim como as comuni-dades virtuaisFacebooke Orkut , permitindo que esses laços se tornem mais fortes einfluenciem cada vez mais nas decisões de seus usuários.

Apenas o projetoMiso possui suporte e integração a outras redes sociais, permitindoque o usuário possa compartilhar suas informações com oTwitter e o Facebookporexemplo.

Assim como na sociedade, cada pessoa possui amizades com Graus de Confiança di-ferentes. Alguns são mais confiáveis e outros menos. A nossa arquitetura permite aousuário estabelecer níveis de confiança (variando de Forte,Médio a Fraco) para seus ami-gos. Nenhum dos trabalhos aqui analisados apresenta o conceito de Graus de Confiançapara a indicação de programas para o usuário além da arquiteturaTrendTV .


Propriedades PTVMassPers.

Tri-bler

Ami-goTV

Colla-bora-TV

EPG-Board

Miso TA2 TrendTV

Multi-Dispositivo

sim não não não sim não sim sim sim

Serviço Web sim sim não sim sim não sim sim simIndicaçãoOn-Line

sim sim não sim não sim sim não sim

Chat portexto

não sim não sim não sim sim não sim

Chat por voz não não não sim não não não sim nãoHistórico deConversas

não sim não não não sim sim sim sim

SBTVD não não não não sim não não não simSet-Top-Boxes

não não sim sim sim sim não não sim

Meta-DadosColaborativo

não não não não não sim sim não não

Sistema deNotas

não não não não sim não sim não sim

Inferências sim sim sim não sim não não não simInfluênciaDireta

não sim não sim não sim sim sim sim

ComunidadesVirtuais

não sim não sim não sim sim não sim

Suporta ou-tras redessociais

não não não não não não sim não não

Graus deConfiança

não não não não não não não não sim

Tabela 3.1: Comparação entre os trabalhos relacionados

Capítulo 4

Arquitetura TrendTV

Neste capítulo iremos formalizar a nossa proposta de arquitetura: OTrendTV . Essaarquitetura surgiu como uma tentativa de agilizar a busca por conteúdo interessante naTV, de maneira fácil e intuitiva, permitindo inclusive a mudança automática do canalpara um mais interessante que esteja disponível no momento,sem interferência humana,permitindo que o usuário se concentre mais na interatividade com a TV. A arquitetura deum modo geral será discutida a seguir.

4.1 Solução Proposta

Figura 4.1: Arquitetura Geral -TrendTV

Para conseguirmos solucionar o problema da grande quantidade de canais disponíveis,comunicação entre dispositivos distintos, e a mudança automática de canais, propomos

32 CAPÍTULO 4. ARQUITETURA TRENDTV

a ArquiteturaTrendTV . O cenário ideal pode ser alcançado com aplicações baseadasnessa arquitetura que alterem os canais automaticamente baseados nas influências queuns usuários realizam sobre os outros. Para facilitar a explicação dessa arquitetura iremosdividi-la em módulos e cada módulo será explicado separadamente. A figura 6.1 mostraa arquitetura do projetoTrendTV .

4.1.1 Trend4Web

O móduloTrend4Web é o módulo mais complexo dessa arquitetura e foi inteiramentedesenvolvido usando o padrão arquiteturalMVC voltado para web. Este módulo é res-ponsável por acomodar todas as estruturas lógicas de um guiaeletrônico de programaçãopersonalizável. Este módulo define as regras de negócio e representações detalhadas dasinformações que serão usadas por todos os módulos, sendo o único módulo que possui ocomponenteModele portanto acesso direto a base de dados. Assim o componenteCon-troller desse módulo, precisa formatar as informações contidas no componenteModelpara um formato universal que seja entendido por todos os outros módulos. Neste traba-lho o formato escolhido para a comunicação entre os módulos edispositivos foi oJSON(JavaScript Object Notation) por se tratar de um formato leve para intercâmbio de dadoscomputacionais, permitindo assim queweb-servicestroquem informações com outros ser-viços. O funcionamento dosweb-servicesconstruídos neste trabalho serão explicados napróxima seção.

4.1.2 Trend4Mobile

O móduloTrend4Mobile visa as plataformas móveis e permite que o usuário des-cubra quais os programas mais indicados do momento baseado em informações obtidasatravés deweb-services, que foram definidos no módulo para webTrend4Web. Este mó-dulo também possui outros serviços que serão descritos na próxima seção. Para permitira comunicação com o móduloTrend4Web, aAPI JSON deve ser utilizada. Este módulotambém possui comunicação com oSet-Top-Boxpermitindo assim a mudança automáticade canais.

4.1.3 Trend4TV

O móduloTrend4TV é um módulo paraSet-Top-Boxesque é responsável por mostrarnuma grade os canais mais indicados em um determinado momento, baseado nas escolhasdos usuários, além de outros serviços que serão descritos a seguir. As informações sobreas qualificações dos programas no momento podem ser realizadas de duas maneiras dis-tintas. Se oSet-Top-Boxespossui canal de retorno, a informação é recebidaon-lineatravésde web-servicese possui as qualificações de seus amigos. Caso contrário a informaçãoé recuperada através do ar utilizando o carrossel de dados (que consiste basicamente emum modelo de transmissão de dados que é envia as informações repetidamente em cicloscontínuos). Para tratar e utilizar as informações recebidas, aAPI JSON para a linguagemLua foi utilizada.

4.1. SOLUÇÃO PROPOSTA 33

Este módulo também possui um componente que atua como um serviço responsávelpela mudança automática de canais dentro doSet-Top-Boxes. Criamos este componentecomo um módulo para a camadaGinga Specific Service(a mesma camada que contémo móduloGinga-NCL e Ginga-J), que por sua vez foi construído tendo como base asfuncionalidades providas peloGinga Common Corecuja arquitetura foi explicada naseção 2.5.

4.1.4 Protocolo de Comunicação para a Mudança Automática de Ca-nais

Além do protocolo de comunicação padrão da arquitetura, queutiliza o modeloJSONapresentado na seção anterior, esta arquitetura contém um protocolo de comunicação pró-prio baseado emsockets UNIX para realizar a mudança de canais. Este protocolo foiescolhido em detrimento aoJSON pois o serviço residente para a mudança de canaisprecisa ser o mais simples e leve possível para não comprometer o processamento e aperformance doSet-Top-Box.

A figura 4.2 apresenta o fluxo de comunicação do protocolo de mudança automáticade canais.

Figura 4.2: Fluxo de Comunicação para a Mudança Automática deCanais

A aplicação se conecta ao serviço e recebe a mensagemTRENDTV_MSG_ACCEPT ,contendo informações sobre os canais disponíveis que já estão pré-sintonizados naqueleSet-Top-Box. Em seguida, a aplicação escolhe o canal e a seção e envia uma mensagemTRENDTV_MSG_CHANGE_CHANNEL solicitando a mudança de canal ao serviço,que retorna uma mensagem de operação realizada com sucesso,ou falha na mudança decanal no formatoTRENDTV_MSG_CONFIRMATION . Este ciclo é repetido até queo serviço receba uma mensagem contendo apenas os caracteresque identificam o fim dearquivo ou o tempo de espera por novas mensagens seja maior que o "timeout"do serviço.

34 CAPÍTULO 4. ARQUITETURA TRENDTV

4.1.5 Cálculo Para Aplicação de Pesos às Notas dos Programas

Como explicado previamente no cenário 5.5, a classificação decada programa é re-alizada em tempo real e personalizada para cada usuário, baseando-se nas indicaçõesrealizadas pelos seus amigos. Para realizar estes cálculos, antes é necessário estabeleceros pesos que os graus de confiança exercem sobre cada indicação. Para este trabalho foiescolhido arbitrariamente que o grau de confiançaForte influencia em 60% das decisões,o Médio em 30% das decisões e oFraco em 10% das decisões. Assim, a nota média decada programa para um determinada rede de amigos será:

NotaMedia= SomaDasNotas/SomaDosPesos (4.1)

Onde:

SomaDasNotas=N

∑i=0

xi ∗ki

ki = 1.6 se Nível de Confiança = Forte

ki = 1.3 se Nível de Confiança = Médio

ki = 1.1 se Nível de Confiança = Fraco

(4.2)

E:

SomaDosPesos=N

∑i=0

ki (4.3)

OndeSomaDasNotasé a soma de todas as notas de um programa para um determi-nado usuário eSomaDosPesosé a soma de todos os pesos de um programa para um dadousuário. N é o número total de votos que um programa recebeu para um dado usuário,xi representa a nota que o usuário recebeu sobre um determinadoprograma da sua redede amigos,ki é baseado noNível de Confiançada indicação para um usuário,ki = 1.6quando o nível de confiança na indicação é forte,ki = 1.3 quando o nível de confiançapara um indicação é médio eki = 1.1 quando o nível de confiança na indicação é fraco.

Capítulo 5

Cenários da Arquitetura TrendTV

Neste capítulo iremos apresentar um conjunto de cenários decasos de uso que exem-plificam o uso desta arquitetura. O caso ideal para estes cenários pode ser alcançado comaplicações que possam mudar de canal automaticamente baseadas apenas nas influênciasdos amigos do usuário através de vários dispositivos diferentes. Para ilustrar como é ocomportamento de cada serviço que irá compor a arquiteturaTrendTV foram definidos 8cenários distintos, no qual cada cenário pode possuir um ou mais casos de uso. A figura5.1 mostra um cenário geral que faz uso da arquitetura do projetoTrendTV .

Figura 5.1: Cenário geral da ArquiteturaTrendTV

36 CAPÍTULO 5. CENÁRIOS DA ARQUITETURA TRENDTV

5.1 Cadastrar Usuário

Figura 5.2: CenárioCadastrar Usuário

Como nessa arquitetura a maior parte da interação é realizadapelo telespectador, ire-mos abordar primeiramente oCadastrar Usuário. No cadastro de usuários, o usuárioinsere informações pessoais que permitem o seu reconhecimento entre os demais usuá-rios, como mais de uma pessoa pode utilizar a mesma televisão, então informações comonome de usuário e senha são fundamentais para garantir a privacidade. O usuário podeenviar essas informações através de diversos dispositivos, como computador, celular e aprópria televisão. Essas informações são enviadas atravésda web até oServidor de Usuá-rios. O servidor realiza o tratamento dessas informações e caso todas as informaçõesestejam corretas o usuário é cadastrado noRepositório de Usuários. A figura 5.2 mostrao cenárioCadastrar Usuário.

5.2 Adicionar Amigo

Figura 5.3: CenárioAdicionar Amigo

No cenário deAdicionar Amigo , o usuário pode simplesmente adicionar outro usuá-rio em sua lista de amigos através de uma busca por nome de usuário, aumentando a suarede de amigos e contatos, o usuário pode obter indicações mais atualizadas sobre um

5.3. INDICAR GRAU DE AMIZADE 37

determinado programa. Assim o usuário envia essas informações até oServidor de Usuá-rios e o servidor realiza a adição na rede de amigos noRepositório de Usuários. A figura5.3 mostra o cenárioAdicionar Amigo .

5.3 Indicar Grau de Amizade

Figura 5.4: CenárioIndicar Grau de Amizade

O cenário deIndicar Grau de Amizade permite ao usuário definir três níveis deconfiança (Forte, Médio e Fraco) entre os usuários que compõem a sua rede, atualizandoo conteúdo doRepositório de Usuários. Esses níveis de confiança causam um impactosobre a influência que um usuário pode realizar sobre outro, pois assim como acontece nasociedade, quanto maior o nível de confiança que uma pessoa tem sobre outra, maior achance de influenciá-la. A figura 5.4 mostra o cenárioIndicar Grau de Amizade.

5.4 Conversar

Figura 5.5: CenárioConversar

No cenárioConversar, o usuário pode se comunicar através de mensagens de textocom qualquer outro usuário. Para isso, o usuário precisa estar cadastrado previamenteno Repositório de Usuários, então oServiço de Chatirá Recuperar Loginpara validar o


usuário. Quando o usuário envia uma mensagem, ele pode adicionar o símbolo "@"se-guido pelousernamee a mensagem, então os usuários que possuem o seuusernamenamensagem estarão habilitados para ver a mensagem no quadro de mensagens, possuindoum comportamento semelhante à ferramenta de micro-blogging Twitter . Assim, oSer-viço de Chatprecisa realizar uma consulta noRepositório de Usuáriospara coletar essasinformações. OServiço de Chattambém guarda as conversas noHistórico de Conver-sas, para que essas conversas possam acontecer assincronamente. A figura 5.5 mostra ocenárioConversar.

5.5 Indicar Programa

Figura 5.6: CenárioIndicar Programa

O cenário deIndicar Programa , permite que usuários possam classificar um pro-grama utilizando um sistemas de notas, que variam de 0 a 5. OServiço de IndicaçõesentãoAplica Pesos de Amizade na Notarecebida, baseado em informações recebidaspeloRepositório de Usuáriose oRepositório de Notas. Todos os amigos da pessoa queenviou a indicação tem sua grade de programação atualizada dinamicamente. Os pesossão aplicados conforme o grau de confiança que um usuário tem pelo outro (Forte, Médioou Fraco).

O Serviço de Indicaçõestambém registra noRepositório de Notastodas as classifi-cações realizadas sobre um determinado programa sem aplicar os pesos, realizando umasimples soma de todas as notas. Dessa maneira, uma classificação geral baseada na opi-nião de todos os usuários é formada em tempo real.

Além disso, neste cenário os usuários ainda podem receber asclassificações realizadaspelos seus amigos. Quando um usuário realiza uma busca por indicações, oServiço deIndicaçõesbusca noServiço de Meta-Dadostodos os programas que estão sendo transmi-tidos naquele instante, e em seguida oServiço de Indicaçõesfaz uma busca noRepositóriode Notas. De posse de informações do usuário e dos programas que estãopassando na-quele instante, oRepositório de Notasretorna as notas em tempo real. A figura 5.6 mostrao cenárioIndicar Programa .

5.6. RECEBER META-DADOS 39

5.6 Receber Meta-Dados

Figura 5.7: CenárioReceber Meta-Dados

O usuário pode receber meta-dados diretamente através deweb-services. Para isto oServiço de Meta-Dadosrealiza uma requisição aoRepositório de Programase recuperaa programação que estará passando ao longo do dia, incluindoa classificação geral dosprogramas durante aquele momento, realizada pela simples média das indicações de todosos usuários.

Se o usuário faz uso do Canal de Retorno, o cenárioReceber Meta-Dadostem omesmo comportamento de receber os dados através da web. Caso ousuário possua ape-nas oSet-Top-Box, ele irá receber as informações através da Antena de Difusãoe asinformações serão enviadas através de um Carrossel de Dados.O Carrossel de Dadosrecupera as informações dos Programas periodicamente doRepositório de Programas deTV, inclusive a classificação geral e coloca na sua lista de envio. Assim, o usuário iráter acesso as classificações dos programas apenas utilizando o Set-Top-Box. A figura 5.7mostra o cenárioReceber Meta-Dados.

5.7 Enviar Meta-Dados

Figura 5.8: CenárioEnviar Meta-Dados

O cenárioEnviar Meta-Dadossimplesmente permite que a emissora possa cadastrarinformações genéricas sobre um determinado programa, comopor exemplo o gênero, o


elenco, a duração, entre outros. OServiço de Meta-Dadosrecebe essas informações eenvia para oRepositório de Programas. A figura 5.8 mostra o cenárioEnviar Meta-Dados.

5.8 Mudar Canal Automaticamente

Figura 5.9: CenárioMudar Canal Automaticamente

O cenárioMudar Canal Automaticamente irá alterar automaticamente o canal atualda TV usando um Celular ouSet-Top-Box, ambos com as tecnologiasEthernet eBlueto-oth. O celular irá receber a classificação dos programas atravésda web, e irá enviar umamensagem para oSet-Top-Boxpara mudar o canal com o programa melhor classificadono momento. OMudar Canal Automaticamente é apenas responsável por realizar amudança automática dos canais. Como omiddleware Ginga não permite as aplicaçõesmudarem os canais, esta aplicação está diretamente associada ao Sistema Operacional doSet-Top-Box, atuando como um serviço de sistema. Todas as infomações necessárias pararealizar a mudança de canal são previamente enviadas pelos módulosTrend4Mobile eTrend4TV . A figura 5.9 mostra o cenárioMudar Canal Automaticamente.

Capítulo 6

Implementação e Resultados

Para validar a arquitetura apresentada neste trabalho foram implementadas 4 aplica-ções para todos os cenários apresentados no capítulo 5, paradiversos dispositivos. Naprimeira aplicação o móduloTrend4Web foi desenvolvido contando com uma aplica-ção web e um conjunto deweb-services. A segunda aplicação desenvolveu o móduloTrend4Mobile da nossa arquitetura e ela conta com um cliente para osweb-servicesde-senvolvidos na aplicação anterior para dispositivos móveis, além de um cliente para oserviço de mudança automática de canais. A terceira aplicação possui as mesmas funcio-nalidades da segunda aplicação, mas paraSet-Top-Boxesutilizando o middleware Ginga.A quarta aplicação é simplesmente um serviço de mudança de canais localizado dentrodo Sistema Operacional doSet-Top-Box. Estas duas últimas aplicações fazem parte domóduloTrend4TV . Apresentamos neste capítulo os resultados alcançados nestas qua-tro aplicações. A figura 6.1 apresenta a estrutura da arquitetura que foi implementadautilizando as tecnologias mencionadas no capítulo 1.

6.1 Aplicação Trend4Web

A aplicação para o móduloTrend4Web consiste basicamente de uma página webcom algumas funcionalidades que serão descritas a seguir e um conjunto deweb-servicesdescritos no capítulo anterior. O sistema de autenticação,gerenciamento de usuário, con-versas, serviço de classificação e descrição dos programas ecanais foram os componentesdesenvolvidos, permitindo a avaliação dos programas disponíveis para os canais da TVpública brasileira.

O sistema de autenticação permite que apenas usuários cadastrados possam utilizar osistema. Isso adiciona mais segurança nas atividades e estápresente em todos os com-ponentes deste módulo, com exceção da consulta à classificação geral dos programas,a consulta aos canais e aos próprios programas, que estão disponíveis independente daautenticação do usuário.

No gerenciamento de usuários o telespectador pode ver e editar seu perfil, além deprocurar, adicionar ou remover outros usuários, bem como alterar o seu grau de relacio-namento com cada usuário.

O sistema de conversas permite que o telespectador envie mensagens e consulte naordem cronológica de envio as conversas que possuem o seuusernameno corpo da men-

42 CAPÍTULO 6. IMPLEMENTAÇÃO E RESULTADOS

Figura 6.1: Arquitetura Implementada -TrendTV

sagem, além de listar as mensagens que ele próprio escreveu.O serviço de classificação, permite que os usuários possam indicar a qualidade de um

determinado programa de um determinado horário, além de ordenar os programas queestão sendo exibidos no momento de acordo com a sua classificação, os mais bem clas-sificados aparecem no topo da lista, independente da quantidade de votos. E como já foiapresentado na seção anterior, este serviço de classificação possui dois comportamentosdistintos, baseado no contexto em que se encontra. A figura 6.2 apresenta um exemplo declassificação dos programas exibidos em um dado momento.

Todos os componentes que foram apresentados até agora são manipulados pelos pró-prios telespectadores. As emissoras de TV também interagemcom essa aplicação atravésdo sistema de autenticação e cadastro de programas e grade dehorários, inserindo meta-informações como por exemplo, nome dos programas, descrição e horário. Apesar derealizar o cadastro dos programas e definir sua grade de horários a emissora obviamentenão tem a permissão para indicar ou interferir na classificação dos seus programas.

Finalmente, este módulo também permite que o usuário possa obter as descrições so-bre cada programa ou canal além de outras informações específicas, bem como visualizara média geral de cada canal e programa.

6.2 Aplicação Trend4Mobile

Com osweb-servicesda aplicaçãoTrend4Web finalizados, uma aplicação para ambi-entes móveis foi desenvolvida para o móduloTrend4Mobile. Os sistemas de autentica-

6.3. APLICAÇÕES TREND4TV 43

Figura 6.2: Classificação de Programas de Acordo com as Indicações dos Usuários

ção, conversas e serviço de classificação possuem o mesmo comportamento dos compo-nentes da aplicaçãoTrend4Web e foram os componentes desenvolvidos que utilizarama tecnologia deweb-servicespara recuperar e enviar dados, desta maneira centralizandoe integrando todas as informações numa única base de dados localizada na aplicaçãoTrend4Web. A figura 6.3 mostra um exemplo de classificação de programas para a apli-caçãoTrend4Mobile desenvolvida na plataformaJavaME.

Esta aplicação também troca mensagens com um serviço localizado noSet-Top-Boxresponsável por realizar a mudança de canais. O protocolo decomunicação entre estaaplicação está sendo realizado de acordo com o protocolo descrito na seção 4.1.4. Pararealizar a mudança automática de canais, o usuário da aplicação precisa informar o inter-valo de tempo que a aplicação deve esperar até alterar o canal, como pode ser observadona figura 6.4. Quando o usuário define o intervalo de mudança automática, o sistemaexecuta umaThread embackgroundque fica alterando no tempo especificado os canais,sem a interferência do usuário.

6.3 Aplicações Trend4TV

O móduloTrend4TV é composto por duas aplicações distintas. Uma implementa umcliente para o middlewareGinga e a outra aplicação é o próprio serviço residente querealiza a mudança automática de canais. A aplicação clientepossui um sistema de auten-ticação, conversas e serviço de classificação de programas,todos com o mesmo compor-


Figura 6.3: Classificação de Programas na AplicaçãoTrend4Mobile

Figura 6.4: Mudança Automática de Canais na AplicaçãoTrend4Mobile


tamento dos componentes da aplicaçãoTrend4Web e utilizandoweb-servicespara recu-perar e enviar dados. A figura 6.5 mostra um exemplo de mudançade canais utilizando aaplicaçãoTrend4TV . A aplicação cliente também possui um mecanismo de mudança decanais com o mesmo comportamento da aplicaçãoTrend4Mobile, utilizando inclusive omesmo protocolo de comunicação.

Figura 6.5: Mudança de Canais na AplicaçãoTrend4TV

6.3.1 Melhorias na Usabilidade

Para facilitar o processo de indicação de programas na aplicaçãoTrend4TV , o usuá-rio tem apenas a opção de aprovar ou desaprovar, ao invés de atribuir uma nota para aqualidade de um programa. Quando o usuário aprova um programa, a aplicação automa-ticamente atribui a nota máxima, e quando o usuário desaprova a aplicação atribui a notamínima, desta maneira a aplicação se torna mais fácil de usarsem realizar nenhum grandeimpacto no processo de qualificação dos programas.

6.3.2 Modelagem da Base de Dados

Antes de apresentarmos as estruturas das implementações decada módulo é necessá-rio explicar a modelagem da base de dados, é ela que guarda o domínio da arquitetura epossui boa parte das lógicas de negócio, além de mostrar comofuncionam os relaciona-mentos entre cada componente da arquitetura. Esta modelagem deve também apresentarcaracterísticas semelhantes à modelagem de um guia de programação personalizado, epara tanto ela deve possuir as seguintes entidades fundamentais:


Figura 6.6: DiagramaEntidade Relacionamento

• Usuário: responsável por guardar informações sobre um determinadousuário, comodados de segurança e autenticação, além de informações pessoais. Esta entidade érepresentada no diagrama pelas tabelasuserseuser_profiles.

• Canais: armazena o nome e número do canal, a seção e uma descrição. Esta enti-dade é representada no diagrama pela tabelachannel.

• Gêneros: uma lista que contêm um conjunto de gêneros de programas pré-definidos.Esta entidade é representada no diagrama pela tabelagenres.

• Programas: guarda informações básicas sobre o programa, como nome, palavras-chave e descrição do programa. Além disso, essa entidade armazena a classificaçãogeral dos seus programas realizadas pelos usuários e faz referência as entidadesCa-naise oGêneros. Esta entidade é representada no diagrama pela tabelaprograms.

• Conversas: armazena o histórico de todos os "posts"realizadas pelos usuários e ahora de envio. Esta entidade é representada no diagrama pelatabelachat.

• Relacionamentos: referencia a EntidadeUsuáriopara criar um relacionamento en-tre os usuários que estão numa mesma tupla. Além disso esta entidade armazena ograu de amizade entre esses dois usuários. Esta entidade é representada no diagramapela tabelarelationships.

• Grade de Programação: guarda as informações temporais dos programas de TV,como horário de início e fim da exibição, e armazena também umadescrição extrae nomes especiais referentes a uma determinada exibição, além de também fazerreferência a entidadeProgramas. Esta entidade é representada no diagrama pelatabelaprograms_grid.

• Indicações dos Usuários: armazena cada classificação sobre um determinado pro-grama realizada pelos usuários em um dado momento. Assim esta tabela faz refe-rência a EntidadeUsuárioe Grade de Programação. Esta entidade é representada


no diagrama pela tabelauser_indication.

O Diagrama de Entidade-Relacionamento da figura 6.6 apresenta a modelagem dabase de dados dessa arquitetura e seus relacionamentos.

6.3.3 Protocolo de Comunicação da Arquitetura TrendTV

Para que os diversos módulos e aplicações possam trocar mensagens entre si, é neces-sária a criação ou utilização de um protocolo de comunicação. Para este trabalho foramcriadosweb-services, devido à facilidade de interoperação entre os serviços, sem os pro-blemas conhecidos de segurança/firewalls, e pela facilidade de se esconder os detalhesproprietários das infra-estruturas de suporte.

Para realizar a comunicação com osweb-servicesé necessário apenas saber aURLcorreta e fazer uma requisição usando o ProtocoloHTTP e passando oscookiesde ses-são como parâmetro. Desta maneira, os usuários poderão realizar atividades estando real-mente autenticados no sistema e garantindo a segurança dos serviços. Neste trabalho pararecuperar informações foi utilizado o métodoGET do HTTP e para enviar informaçõeso métodoPOST foi o utilizado.

A figura 6.7 mostra um exemplo de requisição doweb-servicede conversa deste tra-balho. Nesta requisição o usuário apenas está carregando asconversas.

Figura 6.7: Exemplo de comunicação HTTP comCookies

No entanto, existem críticas sobre o modelo de comunicação padrão dosweb-services.Uma dessas críticas diz respeito ao fato de que oSOAP (Simple Object Access Protocol)é menos eficiente do que os sistemas deRPC (Remote Procedure Call) existentes. Asmensagens (com os respectivos envelopes e descrição de tipos) trocadas entre as partessão descritas emformato de texto/XMLenquanto que nos sistemas clássicos deRPCsão trocadas em formato binário. Isto aumenta o tamanho da mensagem e encarece oseu envio, além do esforço computacional adicional apenas para realizar oparsingdodocumentoXML , tornando as respostas dos web-services mais lenta.

Numa tentativa de resolver esse alto custo de comunicação, oprotocoloJSON (Ja-vaScript Object Notation) foi escolhido para este trabalho, pois é um formato bem maisleve de intercâmbio de dados, além de ser fácil para humanos lerem e escreverem, e maisfácil ainda para gerar um objetoJSON e realizar oparse. JSON possui duas estruturasprincipais:

1. Uma coleção de pares nome:valor (começa com "{"e termina com"}", o par nome:valoré separador por ":"e cada par é separado por ",").


2. Uma lista de valores ordenados (começa com "["e termina com "]"e os valores sãoseparados por ",")

A figura 6.8 mostra a estrutura de uma típica mensagemJSON.

Figura 6.8: Exemplo deJSON

6.3.4 Implementação do Protocolo de Comunicação para a MudançaAutomática de Canais

Como já foi explicado na seção 4.1.4, para realizar a troca automática de canais foidefinido um protocolo para a comunicação entre o componente de mudança de canais eos clientes deste serviço, neste trabalho, implementamos as mensagens de acordo com atabela 6.1.

Na mensagemTRENDTV_MSG_ACCEPT o primeiro número representa o númerodo canal, o segundo número representa a seção do canal, os próximos 3 números represen-tamPIDs (Process IDs- números de identificação de processos do sistema operacional)e finalmente o nome do canal seguido do caractere de escape "\n",que serve para identifi-car o final da descrição de um canal. Depois que todos os canaissão descritos o caractere"$"é utilizado para determinar o fim da mensagem.

A mensagemTRENDTV_MSG_CHANGE_CHANNEL é composta simplesmentepelo número do canal, seguido de um ".", depois o número de seçãoe finalmente um ca-ractere de escape "\n", esta mensagem também pode ser simplesmente a string "EOF"quedetermina o fim da conexão com o serviço.

A mensagemTRENDTV_MSG_CONFIRMATION é apenas composta por duasstrings pré-definidas: "OK$"quando oSet-Top-Boxefetuou a operação de mudança decanal com sucesso e a mensagem "ERROR$"quando algum erro ocorre.


Mensagem ExemploTRENDTV_MSG_ACCEPT 3 1 4097 4099 4098 BAND NATAL HD\n

11 1 49 51 50 CABUGI HD\n$TRENDTV_MSG_CHANGE_CHANNEL3.1\n ou EOFTRENDTV_MSG_CONFIRMATION OK$ ou ERROR$

Tabela 6.1: Mensagens do Protocolo de Mudança Automática deCanais

6.3.5 Estrutura das Mensagens JSON

Nesta seção são apresentadas as mensagens utilizadas nessesistema, assim como umconjunto de tabelas que apresentam os componentes das mensagens JSON, além do tipode dado de cada componente.

A tabela 6.2 mostra os componentes da mensagemJSONquando um usuário faz umarequisição a umweb-servicesobre informações sobre um determinado canal. O compo-nenteclassificationapresenta a classificação geral do canal, com as indicações realizadaspor todos os usuários. O componentenumber_of_votesapresenta o número total de votosque todos os programas que este canal já recebeu. O componentenumber_of_programsmostra a quantidade de programas que este canal possui. Os campossection, channel,nameservem para identificar o número, a seção do canal e o nome do canal. Finalmenteo campodescription, contem informações genéricas sobre este canal.

Campo Tipoclassification Integernumber_of_votes Integernumber_of_programs Integersection Integerchannel Integername Stringdescription String

Tabela 6.2: MensagemJSONcom informações de umCanal

A tabela 6.3 apresenta os campos que compõem a mensagemJSONquando o usuárioconsulta informações sobre um determinado programa de TV. Ocomponenteid_programmostra o número de identificação do programa para manter a integridade da base de da-dos e identificar exclusivamente cada ocorrência de um programa. Os componentespro-gram_name, description e keywords contem, respectivamente, o nome do programa,uma descrição genérica sobre o programa e palavras chave do programa, para facilitar oprocesso de filtragem por conteúdo. Os atributosid_channelechannel_name, represen-tam respectivamente o número de identificação e o nome do canal ao qual o programapertence. Os componentesclassificatione number_of_votes, representam a classifica-ção geral do programa e o número total de indicações para esteprograma realizadas por


todos os usuários. Os componentesid_instance, instance_namee note guardam as in-formações do programa para um determinado horário, o primeiro componente define onúmero de identificação, o segundo um nome especial para o programa e o terceiro trazalgumas notas específicas sobre o programa de um determinadohorário. Os campos demensagemid_genree genre trazem o número de identificação do gênero ao qual o pro-grama pertence e o próprio nome do gênero ao qual o programa pertence.

Campo Tipoid_program Integerprogram_name Stringdescription Stringkeywords Stringid_channel Integerchannel_name Stringclassification Integernumber_of_votes Integerid_instance Integerinstance_name Stringnotes Stringid_genre Stringgenre String

Tabela 6.3: MensagemJSONcom informações de umPrograma

A tabela 6.4 contém os campos e os tipos de dados que compõem asinformações so-bre as tendências do momento sobre programas de TV, representando uma classificaçãodos programas de TV que estão sendo exibidos em um determinado momento. Apesarde possuir os mesmos campos, esta mensagemJSON apresenta dois comportamentosdiferentes, baseados no contexto em que ela é requisitada. Quando o usuário está au-tenticado no sistema, as tendências ou classificações dos programas são baseadas nasinformações enviadas apenas pela rede de amigos que o usuário possui, atribuindo pe-sos para os diferentes graus de amizade. Quando o usuário fazuma requisição a esseweb-serviceanonimamente, oweb-serviceretorna uma mensagem contendo uma médiadas classificações e indicações realizada por todos os usuários. Os atributosid_program,program, id_instance, instance_nameenotespossuem informações relativas a um pro-grama de TV que está sendo exibido no momento em que a requisição aoweb-serviceéfeita. Estas informações são, respectivamente, o número deidentificação do programa,o nome genérico do programa, o número de identificação do programa para um determi-nado horário, o nome especial para o programa em um determinado horário e finalmenteo último atributo traz notas específicas sobre o programa de um determinado horário. Osatributosid_channel, channele sectiontrazem informações sobre o canal que contém oprograma, permitindo que oSet-Top-Boxpossa alterar o canal. O primeiro atributo defineo número do canal, o segundo define o nome do canal e o terceiro atributo define a seçãodo canal na qual o programa está sendo exibido (diferentemente da TV analógica, a TV


digital permite que um canal seja subdivido em várias seçõespara aproveitar ao máximoo espectro do sinal). Finalmente, os atributosclassificationenumber_of_votesapresen-tam a classificação do programa e o número de indicações de acordo com os contextosapresentados previamente.

Campo Tipoid_program Integerprogram Stringid_instance Integerinstance_name Stringnotes Stringid_channel Integerchannel Stringsection Stringclassification Integernumber_of_votes Integer

Tabela 6.4: MensagemJSONcom informações sobre asTendências do Momento

A tabela 6.5 apresenta os campos que compõe uma mensagemJSON com informa-ções sobre as conversas epostsrealizados pelos usuários. Desta maneira, para aumentara segurança só é possível utilizar e consultar esteweb-serviceapós realizada a auten-ticação do usuário, e apenas os usuários envolvidos na conversa podem ter acesso asmesmas. Os atributosuser_id e usernamepossuem as informações relativas ao usuá-rio que está autenticado, apresentando o número de identificação e o nome do usuário,respectivamente. O atributoquerychat é uma lista de dados que contém informaçõessobre as conversas relacionadas ao usuário que está autenticado. Os atributos que com-põem esta lista sãoquerychat.id, querychat.text, querychat.time, querychat.id_userequerychat.username. O primeiro atributo representa um número de identificação de umadeterminada conversa, o segundo representa o conteúdo da conversa, o terceiro atributorepresenta a hora de envio da conversa para manter a ordem cronológica das conversas.Os dois últimos atributos representam o número de identificação e o nome do usuário queé dono de uma determinada conversa.


Campo Tipouser_id Integerusername Stringquerychat Listaquerychat.id Integerquerychat.text Stringquerychat.time Datequerychat.id_user Integerquerychat.usernameString

Tabela 6.5: MensagemJSONcom informações sobre asConversas


‘


Capítulo 7

Considerações Finais

O presente trabalho une conceitos de TV Digital Interativa eRedes Sociais Virtuaisem uma solução para o problema da sugestão e escolha de canaisno contexto da TV Digi-tal Interativa(TVDI) aplicada ao Sistema Brasileiro de TV Digital (SBTVD). Destacamoscomo principais contribuições desse trabalho: a definição de uma arquitetura(TrendTV)em camadas a ser aplicada em sistemas de TVDI na criação de redes sociais com baseemmicrobloggingde conteúdo on-line e a definição de componentes de software aseremadicionados à arquitetura dos atuais sistemas de TV Digitalexistentes, de modo a per-mitirem um maior controle da troca de canais por parte de uma aplicação. Além dessascontribuições em termos de projeto, o presente trabalho apresentou a implementação deum sistema que valida a arquitetura TrendTV aplicada ao SBTVDe aomiddlewareGinga.

Em outras palavras, propomos a arquiteturaTrendTV , uma arquitetura para avaliaçãode programas de TV baseada em redes sociais virtuais com suporte a multidispositivosno cenário do Sistema Brasileiro de TV Digital. Essa arquitetura permite ao usuário arealização de avaliações e indicações em tempo real sobre umdeterminado programa deTV, assim como a disponibilização dessas impressões para todos que fazem parte de suarede de amigos.

Ainda como contribuição, introduzimos o conceito de peso deamizade para redesdemicroblogging, pesos estes que influenciam a relevância das indicações de cada novaamizade adicionada a rede. Através dessas indicações os telespectadores podem reduziro tempo de busca por programas e canais que sejam de seu interesse ou do grupo deamigos em sua rede. Dessa forma, ajudamos os seus usuários a se capitalizarem com essamoeda social que são as conversas que giram em torno dos programas mais assistidos porum grupo de pessoas. A sugestão de canais e programas ajuda a reduzir o tempo gasto"zapeando"de um canal para outro.

Definimos novos componentes sugeridos para serem incorporados aomiddlewareGinga,permitindo um maior controle do aparelho televisivo. Com esses novos componentes,possibilitamos a criação de um novo modo de assistir programas, onde o aparelho deTV pode realizar, automaticamente, a mudança de canais com base na rede social criadapelo usuário. Definimos também um protocolo de comunicação usando diferentes inter-faces ou dispositivos, possibilitando que usuários com dispositivos ou interfaces distintasrealizem as mesmas atividades, como indicar programas e enviar mensagens, além de per-mitir o compartilhamento dessas informações entre os usuários. Vale ressaltar também a

56 CAPÍTULO 7. CONSIDERAÇÕES FINAIS

arquitetura cliente-servidor (baseada no protocoloHTTP+JSON) do sistema usado nasaplicações, que pode ser facilmente adaptada para outras aplicações (portanto, uma basepara a construção de umframeworkque suporte uma maior variedade de dispositivos).

Outra contribuição realizada a partir deste trabalho foi a produção de um artigo in-ternacional [Sena et al. 2011] para aConferência Internacional IEEE sobre AmbientesVirtuais, Interfaces Humano-Computador e Sistemas de Medição (VECIMS ’2011) queapresenta brevemente esta arquitetura, bem como os cenários dos casos de uso.

Desta maneira, neste trabalho, uma nova abordagem está sendo proposta para resolveros problemas de classificação de programas de TV de maneira a propiciar uma maiorsatisfação do usuário no momento da escolha de um canal.

Utilizando a arquitetura proposta com o propósito de validação da mesma, desenvolve-mos neste trabalho aplicações que pudessem ser usadas por usuários através de celulares,tablets, computadores eSet-Top-Boxes, tudo realizado de maneira transparente para ousuário. O resultado é um sistema que disponibiliza diferentes maneiras de conexão paraque seus usuários o acessem, visando garantir uma maior acessibilidade, principalmentepara os usuários com poucos recursos. Usuários com equipamentos de baixo desempenhoque não conseguiriam acessar o sistema através de um computador, podem optar por umcelular com recursos menos exigentes. Já os usuário que possuem apenasSet-Top-Boxes.Através deste trabalho mostramos que é possível interligardiferentes dispositivos com opropósito de classificar programas de televisão utilizandoum único ambiente comparti-lhado por todos os usuários.

Esta arquitetura possui um grande potencial para ser utilizado por todas as classessociais, inclusive a população de baixa renda, tornando-seuma importante ferramenta declassificação de programas. Isto permite o acesso a um público maior de usuários queem muitos casos não teriam acesso a uma variedade de sistemasse não dispusessem decomputadores com a configuração mínima para executá-los.

Nos experimentos e testes, mostramos o desenvolvimento de aplicações para a arqui-teturaTrendTV que possibilitam um usuário indicar programas, se comunicar e trocarde canal sem interferências. Os resultados alcançados demonstram a viabilidade do usodo modelo proposto, visando melhorar os atuaisGuias Eletrônicos de Programação.Contudo, percebemos que o processo de mudança automática de canais requer alteraçõesno middlewareGinga (mais precisamente na camadaGinga Specific Service) e portantouma versão customizada é necessária, já que a especificação do Ginga não permite queaplicações interfiram na mudança de canais. Por isso outros desenvolvimentos futuros sãonecessários, visando aumentar a portabilidade da arquitetura proposta.

7.1 Perspectivas

Este trabalho explicou os cenários e a arquitetura de um sistema de recomendaçãode programas baseado em redes sociais compatíveis com o middlewareGinga. Isto abreuma margem para vários estudos e análises. A princípio, poderíamos realizar testes destressna arquitetura para avaliar aspectos como escalabilidade,resposta do sistema erobustez. Como já foi comentado previamente o processo de mudança de canais não étrivial e utiliza uma versão customizada do middleware Ginga que não segue todas as

7.1. PERSPECTIVAS 57

especificações. Portanto estudos futuros poderiam ser realizados utilizando tecnologiade raios infravermelhos para simular o comportamento de um controle remoto de TV erealizar a mudança de canais.

O que pode ser feito para tentar aumentar ainda mais a relevância dos resultado étornar mais dinâmica e implícita a distribuição de pesos dosgraus de amizade, a partirde comparativos entre as suas escolhas e as escolhas de cada amigo da sua rede. O queocasionaria inclusive uma alteração no conceito da arquitetura, que passaria a ter graus deinfluência ao invés de graus de amizades.

Outros trabalhos futuros que podem ser realizados a partir deste trabalho é a integraçãocom outras redes sociais comoTwitter e Facebook, além de uma análise aprofundadasobre o impacto que a mudança automática de canais associadaa relevância dos resultadoscausa sobre a perspectiva dos usuários. Para realizar esta análise, podem ser criadasenquetes e entrevistas com o usuário e desta maneira será possível inferir o impacto namaneira de se assistir televisão.

58 CAPÍTULO 7. CONSIDERAÇÕES FINAIS

Referências Bibliográficas

15606-2, NBR (2007), Digital terrestrial television standard 06: Data codificationand transmission specifications for digital broadcasting,part 2 - ginga-ncl: Xmlapplication language for application coding, Documento dereferência, ABNT, SãoPaulo, SP, Brazil.URL: http://www.abnt.org.br/imagens/Normalizacao_TV_Digital/ABNTNBR15606-2_2007Ing_2008.pdf

Adrianson, L. & E. Hjelmquist (1991), ‘Group processes in face-to-face and computer-mediated communication’,Behav. Info Tech.10(4), 281–296.

Albrecht, Chris (2009), How socializing can be a boon to tv, Página na internet.URL: http://gigaom.com/video/how-socializing-can-be-a-boon-to-tv/

Alves, Luiz G. P. (2008), Collaboratvware: Uma infra-estrutura ciente de contexto parasuporte a participação colaborativa no cenário da tv digital interativa, Dissertação demestrado, Escola Politécnica da Universidade de São Paulo,São Paulo, Brasil.

Andrews, Gregory R. (2000),Foundations of Multithreaded, Parallel, and DistributedProgramming.

ARIB-B-24 (2004), Terrestrial integrated services digital broadcasting, xml-based multi-media coding scheme, Documento de referência, ARIB Standardb-24 Data Codingand Transmission Specifications for Digital Broadcasting.

Barrér, Eduardo & Paula Marin Leite (2009), ‘Metodologia de integração entre aplicaçõesweb e aplicações para tv digital’,Simpósio de Excelência em Gestão e Tecnologia.

Beck, Kent & Cynthia Andres (2004),Extreme Programming Explained: EmbraceChange, Addison-Wesley Professional.

Berners-Lee, Timothy John & et al. (1992), The world wide web project, Página nainternet.URL: http://www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html

Berscheid, E. & L. A. Peplau (1983),Close relationships, capítulo The emerging scienceof relationships, pp. 1–19.

Burbec, Steve (1987),Applications programming in smalltalk-80:how to use model-view-controller, 1a edição.

59

60 REFERÊNCIAS BIBLIOGRÁFICAS

Campbell, Janet (2010), Eclipse ide, Interface de desenvolvimento, Eclipse Foundation.URL: http://www.eclipse.org

Cerf, Vinton (1993),The Online User’s Encyclopedia, Addison-Wesley, Los Angeles,California, EUA, capítulo How the Internet Came to Be, pp. 47–75.

Change-Vision (2010), Astah* community, Ferramenta uml.URL: http://astah.change-vision.com/

Cisco (2010), Cisco vni global ip traffic forecast, Página na internet.URL: http://www.cisco.com/en/US/netsol/ns827/networking_solutions_sub_solution.html

ComScore.com (2007), Social networking goes global, Páginana internet.URL: http://www.comscore.com/Press_Events/Press_Releases/2007/07/Social_Networking_Goes_Global

Coppens, T., L. Trappeniers & M. Godon (2004), Amigotv: towards a social tv experi-ence,em‘Proceedings from the Second European Conference on Interactive Televi-sion Enhancing the experience’.

da Silva Filho, Antonio Mendes (2003), ‘Os três pilares da inclusão digital’,Revista Es-paço AcadêmicoIII .

Dall’oglio, Pablo (2007),PHP Programando com Orientação a Objetos: Inclui DesignPatterns, 1a edição, Novatec, São Paulo, Brasil.

Damasceno, Jean Ribeiro (2008), Middleware Ginga, Tese de doutorado, UFF, Niterói,RJ, Brazil.

Dolev, Shlomi (2000),Self-Stabilization.

Eckerson, Wayne W. (1995), ‘Three tier client/server architecture: Achieving scalability,performance, and efficiency in client server applications’, Open Information SystemsIII .

Fernandes, Jorge, Guido Lemos & Gledson Silveira (2004), Introdução à televisão digitalinterativa: Arquitetura, protocolos, padrões e prática,em ‘Jornada de Atualizaçãoem Informática do Congresso da Sociedade Brasileira de Computação’, SBC, Sal-vador, Bahia, Brasil, pp. 1–56.

Fink, M., M. Covell & S. Baluja (2006), Social-and interactive-television applicationsbased on real-time ambient-audio identification,em ‘Proceedings of the 4th EuroiTV conference’, pp. 138–146.

foursquare.com (2011), Foursquare, Página na internet.URL: http://www.foursquare.com/

Fowler, Martin (2002),Patterns of Enterprise Application Architecture.

REFERÊNCIAS BIBLIOGRÁFICAS 61

Freeman, Linton (2006),The Development of Social Network Analysis.

Ghosh, Sukumar (2007),Distributed Systems - An Algorithmic Approach.

Gliffy (2010), Gliffy, Página na internet.URL: http://www.gliffy.com

goMiso.com (2011), Miso - watch tv. follow shows. earn points and badges., Página nainternet.URL: http://www.gomiso.com/

Gross, Tom, Thilo Paul-Stueve & Mirko Fetter (2009),Social Interactive Television: Im-mersive Shared Experiences and Perspectives, capítulo Social TV from a Computer-Supported Cooperative Work Perspective, pp. 50–66.

Hiltz, S. R., K. Johnson & M. Turoff (1986), ‘Experiments in group decision making:communication process and outcome in face-to-face versus computerized conferen-ces’,Human Communication Research13(2), 225–252.

Hof, R. D., S. Browder & P. Elstrom (1997), ‘Internet communities’,Business Week.

Iatrino, Arianna & Sonia Modeo (2007), Epg-board a social application for the omegaboxmedia center,em ‘EuroITV’07: Proceedings of the 5th European conference onInteractive TV’, Springer-Verlag, Berlin, Heidelberg, pp.31–36.

Ierusalimschy, Roberto, Luiz Henrique Figueiredo & Waldemar Celes (2006),Lua Refe-rence Manual, PUC-Rio, Rio de Janeiro, Brasil.

ITU-T Recommendation H.761, 2009 (2009), Nested context language (ncl) and ginga-ncl for iptv services, Documento de referência, ABNT, Geneva.

Kiesler, S.B., J. Siegal & T. W. McGuire (1984), ‘Social psychological aspects ofcomputer-mediated communication’,Am. Psychol.39(10), 1123–1134.

LAViD (2006), Middleware ginga, Sistema operacional, PUC-Rio, UFPB.URL: http://www.ginga.org.br

Lynch, Nancy A. (1996),Distributed Algorithms.

Machado, Alessandro H. (1999), ‘Conceitos sobre interatividade em sistemas de radiodi-fusão’,Revista Engenharia de Televisão(47).

Melo, Júlio César Paulino & Rodrigo Moreira Araújo (2008), ‘Osmódulos ncl e ncluados middleware ginga para aplicações em tv digital interativa’, MOPA EmbeddedSystems.

Mendes, Luciano Leonel (2007), ‘Sbtvd - uma visão sobre a tv digital no brasil’,T and CAmazôniaV(12).


Montez, Carlos & Valdeci Becker (2004), Tv digital interativa: Conceitos e tecnologias,em‘WebMidia e LA-Web 2004 - Joint Conference’.

Montpetit, Marie-José (2009), ‘Your content, your networks, your devices: Socialnetworks meet your tv experience’,Computers in Entertainment7.

Moreno, Marcio Ferreira, Luiz Fernando Gomes Soares & RenatoCerqueira (2011), Umaarquitetura orientada a componentes para o ginga,em‘Proceedings of SBRC’2011’,Rio de Janeiro, Brazil, pp. 265–278.

NCL.org.br (2009), Nested context language, Página na internet.URL: http://www.ncl.org.br/pt-br/inicio

Nielsen, Jakob (2003), ‘Usability 101: Introduction to usability’, Alertbox: Current Issuesin Web Usability101.URL: http://www.useit.com/alertbox/20030825.html

Nielsen.com (2010), U.s. homes add even more tv sets in 2010,Página na internet.URL: http://blog.nielsen.com/nielsenwire/consumer/u-s-homes-add-even-more-tv-sets-in-2010/

Nielsen.com (2011), Social media and tv - who’s talking, when and what about?, Páginana internet.URL: http://blog.nielsen.com/nielsenwire/global/social-media-and-tv-whos-talking-when-and-what-about/

Oliveira, Antônio Carlos Albuquerque de & João Paulo Lopes deLacerda (2008), A TVDigital no Brasil e o Desenvolvimento de Aplicações Interativas para o MiddlewareGinga, Tese de doutorado, UFS, Aracaju, SE, Brazil.

Oracle (2010), Java programming language, Linguagem de programação, Oracle.URL: http://java.sun.com/

Reese, George (2000),Database Programming with JDBC and Java, capítulo DistributedApplication Architecture, pp. 126–145.

Rempt, Dick (2010), Social tv - making the tv experience more social, Página na internet.URL: http://www.appmarket.tv/opinion/34-writers/551-social-tv-making-the-tv-experience-more-social.html

Rheingold, Howard (1993),The Virtual Community, 1a edição.

Rice, R. & G. Love (1987), ‘Electronic emotion: socioemotional content in a computer-mediated communication network’,Human Communication Research14(1), 85–108.

Sena, Hugo T. A., Ricardo A. R. Dias, Júlio P. Melo & Aquiles M. F.Burlamaqui(2011), Trendtv: An architecture for automatic change of tvchannels based on socialnetworks with multiple device support,em ‘Proceedings of VECIMS’2011’, IEEEInternational Conference, Ottawa, Canadá, pp. 1–5.

REFERÊNCIAS BIBLIOGRÁFICAS 63

Smeaton, Alan F., N. Murphy, N. E. O’Connor, S. Marlow, H. Lee,K. McDonald, P.Browne & J. Ye (2001), The físchlár digital video system: A digital library of bro-adcast tv programmes,em‘Proceedings of the 1st ACM/IEEE-CS Joint Conferenceon Digital Libraries’, ACM Press, pp. 312–313.

Smyth, Barry & Paul Cotter (2001), ‘Personalized electronic programme guides’,Artifi-cial Intelligence Magazine22(2), 89–98.

Soares, Luiz Fernando Soares, Guido Lemos & Sérgio Colcher (1995),Redes de Compu-tadores: das LANs, MANs e WANs às Redes ATM.

Sullivan, Derry O., Barry Smyth, David C. Wilson, Kieran McDonald & Alan Smeaton(2004), ‘Improving the quality of the personalized electronic program guide’,UserModeling and User-Adapted Interaction14, 5–36.

Tanenbaum, Andrew S. & Maarten van Steen (2006),Distributed Systems: Principalsand Paradigms, 2a edição, Prentice-Hall International.

TeleMidia (2006), Nested context language, Linguagem de programação, PUC-Rio, Riode Janeiro, Brasil.URL: http://www.ncl.org.br/

Twitter (2010), Twitter.com, Página na internet.URL: http://www.twitter.com/

Upton, David (2007),CodeIgniter for Rapid PHP Application Development, Packt Pu-blishing.

Wang, J., J. Pouwelse, J. Fokker & M. J. T. Reinders (2006), Personalization of a peer-to-peer television system,em‘Proceedings of the 4th Euro iTV conference’, pp. 147–155.

Wasserman, Stanley & Katherine Faust (1994),Social Network Analysis: Methods andApplications.

Weisband, S.P, S. K. Schneider & T. Connolly (1995), ‘Computer-mediated communica-tion and social information: status salience and status difference’,Academic Mana-gement Journal38(4), 1124–1151.

Wellman, Barry, Janet Salaff, Dimitrina Dimitrova, Laura Garton, Milena Gulia & Caro-line Haythornthwaite (1996), ‘Computer networks as social networks: Colaborativework, telework and virtual community’,Annual Reviews of Sociology.


Documents

TrendTV: Uma Arquitetura para Mudança Automática de Canais ... · TrendTV, uma arquitetura em camadas que permite a formação de redes sociais entre te- lespectadores de programas