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ça
Automática de Canais de TV Baseada em Redes
Sociais Virtuais com Graus de Amizade e
Suporte 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
TrendTV: Uma Arquitetura para Mudança
Automática de Canais de TV Baseada em Redes
Sociais Virtuais com Graus de Amizade e
Suporte a Múltiplos Dispositivos no Cenário da
TV Digital Brasileira
Hugo Tácito Azevedo de Sena
Orientador: Prof. Dr. Aquiles Medeiros Filgueira Burlamaqui
Dissertação de Mestrado apresentada ao
Programa de Pós-Graduação em Engenha-
ria Elétrica da UFRN (área de concentração:
Engenharia de Computação) como parte dos
requisitos para obtenção do título de Mestre
em Ciências.
Número de ordem PPgEE: M343
Natal, 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 canais de TV baseada
em redes sociais virtuais com graus de amizade e suporte a múltiplos dispositivos
no 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 Grande do Norte. Cen-
tro de Tecnologia. Programa de Pós-Graduação em Engenharia Elé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 do
Rio Grande do Norte. III. Título.
RN/UF/BCZM CDU 621.397
TrendTV: Uma Arquitetura para Mudança
Automática de Canais de TV Baseada em Redes
Sociais Virtuais com Graus de Amizade e
Suporte a Múltiplos Dispositivos no Cenário da
TV Digital Brasileira
Hugo Tácito Azevedo de Sena
Dissertação de Mestrado aprovada em 13 de fevereiro de 2012 pela banca examinadora
composta 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 pela
orientaçã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údo
interessante de maneira intuitiva e eficiente. Os guias eletrônicos de programação per-
sonalizada (pEPG) surgem como uma resposta para esse complexo desafio. Propomos a
TrendTV, 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údo
on-line. Associado a um pEPG, esta rede social permite que um telespectador realize
filtragens de conteúdo sobre um determinado assunto a partir das indicações feitas por
outros telespectadores de sua rede. Isto permite que o telespectador crie sua própria
indicação para um determinado conteúdo no momento em que ele é exibido, ou ainda
analisar a importância de um determinado programa on-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ários
dispositivos diferentes(TVs,Smartfones, Tablets ou PCs). Além disso, essa arquitetura
define um mecanismo para realizar a mudança automática de canais baseado no melhor
programa 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 programas
de TV, bem como uma aplicação que permite mudar automaticamente para o melhor canal
do 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 emerged from 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 answer
to this complex challenge. We propose TrendTV a layered architecture that allows the
formation of social networks among viewers of Interactive Digital TV based on online
microblogging. Associated with a pEPG, this social network allows the viewer to per-
form content filtering on a particular subject from the indications made by other viewers
of his network. Allowing the viewer to create his own indications for a particular content
when it is displayed, or to analyze the importance of a particular program online, based
on these indications. This allows any user to perform filtering on content and generate
or exchange information with other users in a flexible and transparent way, using several
different devices (TVs, Smartphones, Tablets or PCs). Moreover, this architecture defines
a mechanism to perform the automatic exchange of channels based on the best program
that is showing at the moment, suggesting new components to be added to the middleware
of the Brazilian Digital TV System (Ginga). The result is a constructed and dynamic da-
tabase containing the classification of several TV programs as well as an application to
automatically switch to the best channel of the moment.
Keywords: Digital TV, Virtual Social Networks, Electronic Program Guides, TV
Shows Classification.
Sumário
Sumário i
Lista de Figuras iii
Lista de Tabelas v
1 Introdução 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Estrutura deste trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Embasamento Teórico 7
2.1 Interação Humano-computador . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Sistemas Distribuídos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Arquitetura Cliente Servidor . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Arquitetura Multi-Camadas . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Comunicação em Grupos . . . . . . . . . . . . . . . . . . . . . . 9
2.2.4 Paradigma MVC . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Redes Sociais Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Interações Sociais . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Métricas nas Redes Sociais . . . . . . . . . . . . . . . . . . . . . 13
2.4 Televisão Digital e Interatividade . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1 TV Social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Interatividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Arquitetura Geral da TV Digital . . . . . . . . . . . . . . . . . . 17
2.5 Middleware Ginga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Ginga Common Core . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Ginga-NCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.3 Ginga-J . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Trabalhos Relacionados 23
3.1 PTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Mass Personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Tribler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
i
3.4 AmigoTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 CollaboraTVware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 EPG-Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Miso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8 TA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.9 Comparação Entre Trabalhos . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Arquitetura TrendTV 31
4.1 Solução Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1 Trend4Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2 Trend4Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.3 Trend4TV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.4 Protocolo de Comunicação para a Mudança Automática de Canais 33
4.1.5 Cálculo Para Aplicação de Pesos às Notas dos Programas . . . . . 34
5 Cenários da Arquitetura TrendTV 35
5.1 Cadastrar Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Adicionar Amigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Indicar Grau de Amizade . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4 Conversar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.5 Indicar Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6 Receber Meta-Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.7 Enviar Meta-Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.8 Mudar Canal Automaticamente . . . . . . . . . . . . . . . . . . . . . . . 40
6 Implementação e Resultados 41
6.1 Aplicação Trend4Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2 Aplicação Trend4Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3 Aplicações Trend4TV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.3.1 Melhorias na Usabilidade . . . . . . . . . . . . . . . . . . . . . 45
6.3.2 Modelagem da Base de Dados . . . . . . . . . . . . . . . . . . . 45
6.3.3 Protocolo de Comunicação da Arquitetura TrendTV . . . . . . . 47
6.3.4 Implementação do Protocolo de Comunicação para a Mudança
Automática de Canais . . . . . . . . . . . . . . . . . . . . . . . 48
6.3.5 Estrutura das Mensagens JSON . . . . . . . . . . . . . . . . . . 49
7 Considerações Finais 55
7.1 Perspectivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Referências Bibliográficas 58
Lista de Figuras
1.1 Primeira página Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Exemplo de CSSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Exemplo de Aplicação da DTV . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Arquitetura Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Arquitetura Multi-Camadas . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Modelos de Comunicação em Grupos . . . . . . . . . . . . . . . . . . . 10
2.4 Fluxo de Execução do Paradigma MVC . . . . . . . . . . . . . . . . . . 11
2.5 Exemplo de Comunidade em Redes Sociais Virtuais . . . . . . . . . . . . 12
2.6 Exemplo de Grafo de Rede Social . . . . . . . . . . . . . . . . . . . . . 13
2.7 Arquitetura Geral da TV Digital . . . . . . . . . . . . . . . . . . . . . . 17
2.8 Arquitetura do middleware Ginga . . . . . . . . . . . . . . . . . . . . . 18
2.9 Camada Ginga Common Core . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Arquitetura do Projeto PTV . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Arquitetura do Projeto Mass Personalization . . . . . . . . . . . . . . . 24
3.3 Arquitetura do Projeto Tribler . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Modelo de Funcionamento do AmigoTV . . . . . . . . . . . . . . . . . 26
3.5 Diagrama de Casos de Uso do CollaboraTVware . . . . . . . . . . . . . 27
4.1 Arquitetura Geral - TrendTV . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Fluxo de Comunicação para a Mudança Automática de Canais . . . . . . 33
5.1 Cenário geral da Arquitetura TrendTV . . . . . . . . . . . . . . . . . . . 35
5.2 Cenário Cadastrar Usuário . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Cenário Adicionar Amigo . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4 Cenário Indicar Grau de Amizade . . . . . . . . . . . . . . . . . . . . 37
5.5 Cenário Conversar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6 Cenário Indicar Programa . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.7 Cenário Receber Meta-Dados . . . . . . . . . . . . . . . . . . . . . . . 39
5.8 Cenário Enviar Meta-Dados . . . . . . . . . . . . . . . . . . . . . . . . 39
5.9 Cenário Mudar Canal Automaticamente . . . . . . . . . . . . . . . . . 40
6.1 Arquitetura Implementada - TrendTV . . . . . . . . . . . . . . . . . . . 42
6.2 Classificação de Programas de Acordo com as Indicações dos Usuários . 43
6.3 Classificação de Programas na Aplicação Trend4Mobile . . . . . . . . . 44
6.4 Mudança Automática de Canais na Aplicação Trend4Mobile . . . . . . . 44
6.5 Mudança de Canais na Aplicação Trend4TV . . . . . . . . . . . . . . . 45
iii
6.6 Diagrama Entidade Relacionamento . . . . . . . . . . . . . . . . . . . 46
6.7 Exemplo de comunicação HTTP com Cookies . . . . . . . . . . . . . . . 47
6.8 Exemplo de JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . 49
6.2 Mensagem JSON com informações de um Canal . . . . . . . . . . . . . 49
6.3 Mensagem JSON com informações de um Programa . . . . . . . . . . . 50
6.4 Mensagem JSON com informações sobre as Tendências do Momento . 51
6.5 Mensagem JSON com informações sobre as Conversas . . . . . . . . . 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 lidarem
de maneira mais fácil com os computadores, o campo Interação Humano-Computador
(IHC) foi criado, provendo interfaces e softwares mais fáceis de usar para o usuário co-
mum.
Na década de 1960, houve uma revolução quando as pessoas começaram a enviar
mensagens de máquina para máquina, utilizando uma rede criada pelo Departamento de
Defesa dos Estados Unidos, a ARPANET, 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 do BBS (Bouletim Board System)
na década de 80 permitiu a interligação entre computadores usando a linha telefônica
e uma central de comunicação, denominada host. Estes hosts começaram a se associar
uns com os outros através da rede mundial de computadores (World Wide Web) usando
a comunicação entre redes distintas (Internet). Esse termo se tornou tão difundido que
alguns chamam simplesmente de Net ou Web. A primeira página da web pode ser vista
na 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 que
ter 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ícil mensurar a sua quantidade
de usuários.
Com o surgimento da internet começou a surgir nas pessoas a necessidade de criarem
relacionamentos virtuais de maneira mais dinâmica e para suprir essa necessidades foram
criadas as CSSN (Computer Supported Social Networks) [Wellman et al. 1996]. Assim
estas redes se tornaram uma base importante para uma série de interações humanas, como:
trabalho colaborativo, trabalho a distância, comunidades virtuais, além de agregar mais
um 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 para pessoa. Um exemplo de
rede social pode ser observado na Figura 1.2 [Twitter 2010] :
As redes sociais virtuais são diferentes de outras formas de comunicação mediada
por computador pois elas permitem manter os laços sociais estabelecidos no mundo off-
line. Portanto, são considerados sites de redes sociais: os fotologs (Flicker e Picasa
2 CAPÍTULO 1. INTRODUÇÃO
Figura 1.1: Primeira página Web
Figura 1.2: Exemplo de CSSN
3Web), weblogs(Wordpress e Blogger), microblogs (Twitter e Jaiku), além dos sites de
relacionamento.
A televisão, por sua vez, é um dos maiores meios de comunicação em massa e uma
grande 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 as
pessoas um sentimento de pertencer a uma comunidade global.
O modelo de transmissão original da televisão, e o mais utilizado até hoje, envolve a
transmissão de som e imagens em movimento por ondas de radio-frequência (RF), que
sã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 programas primetime (horário nobre)
para suas emissoras próprias ou afiliadas veicularem entre 19:00 e 23:00. Fora do horário
nobre, 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ção
para TV Digital pode ser observado na figura 1.3:
Figura 1.3: Exemplo de Aplicação da DTV
Como parte de uma pesquisa de programas em serviços de TV personalizados, estão
sendo desenvolvidas técnicas de recomendação e personalização que são interessantes ao
domínio da TV [Smyth & Cotter 2001][Smeaton et al. 2001].
Partindo-se do pressuposto que a televisão digital possui interatividade e uma grande
quantidade 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 um
determinado programa em tempo real, que servirá como um guia para um conteúdo mais
relevante com as necessidades de seus telespectadores. Utilizando-se dessa arquitetura o
usuário poderá saber a opinião dos amigos que compõem a sua rede social sobre algum
4 CAPÍTULO 1. INTRODUÇÃO
programa que esteja passando na TV no momento e assim obter uma maior satisfação na
hora 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 algum
programa que esteja passando naquele instante. A partir da opinião de seus amigos o
usuário pode mudar para o canal mais interessante ou ainda permitir que o sistema realize
a mudança automática de canais, baseado nestas informações. O usuário poderá também
se guiar pelos comentários de todos os usuários dessa aplicação para saber de maneira
geral 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 de
interaçã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 se
comunicar. Devido à possibilidade de muitos canais oferecerem conteúdos interessan-
tes, fica difícil para o telespectador escolher o canal que possui o melhor programa do
momento. Desta maneira, usuários iniciantes tendem a querer assistir muitos canais ao
mesmo tempo, e acabam por mudar constantemente de canal. Ao invés disso o usuário
deveria 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 ferramenta
maior a satisfação do usuário.
Outro fator de motivação deste trabalho foi o fato de que estudos indicam que as redes
sociais (tanto reais como virtuais) possuem uma grande influência sobre as escolhas que
uma 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 bastante
interessante.
Além da necessidade que os humanos tem de se comunicar, das facilidades que as
redes sociais virtuais trouxeram, somado ao fato de a TV ser um meio de comunicação em
massa, 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 gerar
assuntos para conversas posteriormente, tanto no ambiente real 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, saber como procurar conteúdo
interessante 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 [Smeaton
et al. 2001] compreendem parte de uma resposta para esse complexo desafio, e juntos
eles 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 para
aprender mais sobre as preferências do usuário de maneira a oferecer conteúdo relevante
a seus usuários.
Embora esses dois sistemas de filtragem de conteúdo sejam eficientes, eles apenas
indicam a seus usuários os programas que foram classificados de acordo com suas carac-
terísticas mais gerais, não oferecendo a troca de opiniões pessoais entre seus usuários em
tempo real, o que torna a sua classificação menos dinâmica e desatualizada. Além disso,
esses sistemas de filtragem podem apresentar os problema de cold-start (novos usuários
não conseguem recomendações por parte do sistema) e first-rater (novos conteúdos não
podem 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ões
pessoais em tempo real com outros usuários, tornando a classificação dos programas de
TV mais dinâmica e atualizada, além de evitar os problemas de filtragem que foram cita-
dos anteriormente.
A Internet surgiu para interconectar diversos ambientes distintos, permitindo aos seus
usuários navegarem por ela e utilizarem a grande diversidade de recursos que ela disponi-
biliza. O crescimento vertiginoso da internet [Cisco 2010] e a evolução dos protocolos de
comunicação associada ao barateamento da banda-larga permitem agora que não apenas
usuários, mas também dispositivos possam realizar comunicação e troca de mensagens de
maneira 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 assim
uma maneira de realizar a troca de mensagens entre esses dispositivos sem a interferência
humana, 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 as
informaçõ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 paradigma MVC (Model-View-Controller) para
isolarmos 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 TV
em tempo real utilizando o conceito de redes sociais, para facilitar o processo de
decisão de um usuário baseado na influência de amigos que participam da sua rede
social.
* O primeiro objetivo secundário deste trabalho é realizar um comparativo entre as
indicações realizadas por todos os usuários, e as indicações baseadas por sua rede
social, realizando um comparativo com as estratégias de classificação já existentes.
6 CAPÍTULO 1. INTRODUÇÃO
* 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ática
de canais, baseado nas indicações realizadas por seus usuários em tempo real.
1.4 Metodologia
Para modelar a arquitetura TrendTV foi utilizada a ferramenta UML Astah* Commu-
nity [Change-Vision 2010], bem como a ferramenta de construção de diagramas online
Gliffy [Gliffy 2010].
Para realizar o desenvolvimento da aplicação, foi utilizada a abordagem de desenvol-
vimento de software incremental, usando a metodologia ágil associada a XP (eXtreme
Programming) [Beck & Andres 2004], que é ideal para pequenas equipes de desenvol-
vimento com requisitos em constante mudança. Para validar a arquitetura, cada um dos
módulo foi implementado.
As linguagens de programação que foram utilizadas para o desenvolvimento da apli-
cação para a TV foram as linguagens NCL [TeleMidia 2006], Lua [Ierusalimschy et al.
2006] ou Java [Oracle 2010], utilizando o middleware Ginga [LAViD 2006] ou o emu-
lador Ginga-J [LAViD 2006] para a execução das aplicações. A interface de desenvolvi-
mento dessas aplicações foi o ambiente de programação Eclipse [Campbell 2010].
A linguagem utilizada para o desenvolvimento da aplicação via Web foi a linguagem
PHP, 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 o framework
CodeIgniter, que permite desenvolver rapidamente aplicações web robustas e com baixa
configuração [Upton 2007].
Para que haja troca de informações entre os usuários da aplicação, a aplicação fará uso
da internet, pois além de receber, o usuário irá enviar informações. Assim, para executar
essa 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 fortes
de 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 e
estruturas que compõem esta arquitetura.
O contexto em que essa arquitetura está inserida e quando e como ela pode ser usada
está 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 resultados
obtidos 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 4
tó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ão
abordados 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 abrangem
a ciência da computação, ciência comportamental, design, artes, além de outros campos
de 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 quanto
software, e este é o principal foco de estudo, embora valha a pena ressaltar também que
outro 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ência
política, dentre outras.
A usabilidade é uma área de estudo do Design, que trata sobre a facilidade com que
uma 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 com
que uma determinada aplicação interage com um usuário.[Nielsen 2003]
A inclusão digital surgiu para democratizar o acesso aos recursos digitais como o
computador e a Internet, permitindo a inserção da população em geral na sociedade
da informação, que antes era restrita apenas às camadas mais favorecidas da sociedade.
[da Silva Filho 2003]
2.2 Sistemas Distribuídos
Um sistema distribuído nada mais é que uma referência à computação descentralizada
e paralela que ocorre através da conexão entre dois ou mais computadores em uma rede,
objetivando realizar uma mesma tarefa. De acordo com Andrew Tanenbaum [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 realizado
por todas as máquinas envolvidas para processar colaborativamente uma determinada
tarefa de forma coerente e transparente, fazendo com que o usuário tenha a impressão
que apenas um único e centralizado computador estivesse executando a tarefa [Andrews
2000][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, os
sistemas distribuídos se utilizam da comunicação inter-processos, e geralmente consistem
de diferentes computadores distribuídos geograficamente se comunicando através de uma
rede [Lynch 1996]. Embora hoje em dia este seja um conceito impreciso pois podemos
ter um sistema distribuído dentro de um mesmo computador interagindo seus processos
atravé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, para que seja possível a troca
de mensagem entre esses diferentes processos. O modelo de comunicação utilizado nesse
trabalho é 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 divide
as tarefas entre os provedores de serviço, chamados de servidores e os consumidores de
serviços, chamados de clientes [Reese 2000].
A figura 2.1 mostra a troca de mensagens da arquitetura cliente-servidor. Nesta figura
podemos perceber que vários clientes de um determinado serviço realizam requisições a
um servidor, e em seguida o servidor envia as respostas a essa requisições realizadas pelos
clientes.
Serviços que utilizam este tipo de arquitetura são os mais comuns dentre os sistemas
distribuídos. Alguns exemplos de serviços são os protocolos HTTP, FTP, DNS, bancos
de 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 uma
grande 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 dados sã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ções
flexíveis e reusáveis, proporcionando um baixo-acoplamento e evitando que a aplicação
seja inteiramente reconstruída caso algum erro grave aconteça.
A figura 2.2 mostra a troca de mensagens de uma arquitetura multi-camadas, onde
a 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ém
os modelos de dados das aplicações. A camada de persistência realiza uma requisição a
base de dados sobre as informações obtidas através das camadas superiores e finalmente
as 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 na
comunicaçã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 pode
variar desde uma simples troca de mensagens entre dois processos até a troca de dados
entre 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, definindo
os modelos de comunicação entre grupos de processos e para que juntos forneçam um
determinado serviço. Os três agrupamentos de comunicação mais comuns são [Soares
et al. 1995]:
10 CAPÍTULO 2. EMBASAMENTO TEÓRICO
• Modelo Broadcast: a mensagem é transmitida para todos os processos, indepen-
dente se a mensagem interessa ou não. Quem realiza a filtragem são os processos
interessados naquela mensagem.
• Modelo Multicast: a mensagem é enviada apenas para os componentes de um grupo
em particular.
• Modelo Unicast: a troca de mensagens é realizada ponto-a-ponto, onde o emissor
envia 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 paradigma MVC é uma arquitetura ou padrão arquitetural de software utilizado na
engenharia de software para isolar a lógica de negócio da lógica de apresentação, através
de três componentes distintos de forma que as modificações em um componente não
causem impacto nos demais, dessa maneira aumentamos a coesão de cada componente
e diminuímos o acoplamento, permitindo o desenvolvimento, teste e manutenção isolado
destes. Embora o MVC seja um padrão arquitetural, neste capítulo escolhemos tratá-lo
como um paradigma, pois este foi o termo utilizado para defini-lo num dos primeiros
artigos sobre o MVC [Burbec 1987].
Quem primeiro descreveu o paradigma MVC foi o pesquisador da Xerox Trygve Re-
enskaug em 1979, enquanto desenvolvia a interface do Smalltalk-80. Neste paradigma,
as interações do usuário, a modelagem do mundo externo, e as lógicas do negócio estão
explicitamente isoladas e cada uma delas é controlada por um componente de software
distinto. 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 de
dados, 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és
dos periféricos de entrada e se encarrega de transmitir estas informações ao View ou ao
Model, caso seja necessário. Ele também é responsável pela validação e filtragem da
entrada de dados.
Finalmente, o modelo (Model) administra o comportamento e os dados de domínio
da aplicação, responde aos eventuais pedidos de informação sobre o seu estado atual
2.3. REDES SOCIAIS VIRTUAIS 11
Figura 2.4: Fluxo de Execução do Paradigma MVC
(geralmente requisitados pelo visão), e transmite instruções sobre eventuais mudanças de
estado (geralmente requisitadas pelo controller).
A figura 2.4 demonstra o fluxo de execução do MVC:
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 de
negó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ém
da interface também é necessário refazer também os componentes de controle para cada
dispositivo. Além de refazer os componentes de controle e de visão, os diferentes dispo-
sitivos precisam se comunicar de maneira transparente e por isso, utilizar apenas o MVC
não servirá para solucionar o nosso problema, já que esse padrão arquitetural não trata de
protocolos de comunicação.
2.3 Redes Sociais Virtuais
As redes sociais virtuais são estruturas sociais compostas por indivíduos, que estão
ligados 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 maioria
das vezes a própria internet), partilhando dados e informações das mais variadas maneiras
12 CAPÍTULO 2. EMBASAMENTO TEÓRICO
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 pessoas
com a mesma afinidade por um determinado assunto possam criar comunidades virtuais
e 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 figura
2.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 em
uma 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 um
todo.
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 causa dessa interdependência, se
algo afeta um membro do relacionamento os outros membros também sofrem algum tipo
de 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 das Computer-
Supported Social Networks.
A partir daí, pesquisas em IHC começaram a ser realizadas sobre como grupos de
pessoas são mediados por sistemas de computadores. Muitos desses estudos examinaram
como a presença social limitada (em comparação ao contato em pessoa) 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 para
tarefas 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][Weisband
et al. 1995]. A presença social limitada também encorajou as pessoas a se comunica-
rem com mais liberdade e criatividade do que em pessoa, algumas vezes até cometendo
excessos 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, formando
dessa maneira grafos [Freeman 2006], que permitem diversos tipos de métricas. A figura
2.6 exemplifica um grafo de uma rede social utilizando a métrica Centrality.
Figura 2.6: Exemplo de Grafo de Rede Social
Algumas métricas freqüentemente utilizadas para analisar o comportamento de redes
sociais são: Centralization, Centrality, Closeness, Degree, Bridge, Reach, dentre muitas
outras [Wasserman & Faust 1994].
• Centralization: uma rede centralizada terá muitos de seus relacionamentos em torno
de um ou poucos nós, enquanto uma rede descentralizada é aquela em que há pouca
variaçã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 como
Closeness e Degree são todas medidas de Centrality.
• Closeness: o grau de amizade de um indivíduo em relação a todos os outros indiví-
duos próximos na rede social (direta e indiretamente). Isto reflete na habilidade de
14 CAPÍTULO 2. EMBASAMENTO TEÓRICO
acessar informações mais relevantes e importantes entre os membros da rede. Desta
maneira, a métrica Closeness é 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íduo
tem em sua rede. Esta é a métrica mais usada pelas redes sociais virtuais.
• Bridge: um relacionamento é dito Bridge, quando ele conecta dois grupos distin-
tos dentro de um grafo e caso este relacionamento seja apagado, isto irá causar a
separação destes grupos em dois grafos distintos.
• Reach: esta métrica calcula o grau que qualquer membro de uma rede pode alcançar
outro 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 de
sinal digital, em contraste com o sinal analógico utilizado pelas TVs analógicas. Mui-
tos países estão substituindo a transmissão analógica pela transmissão digital pois esta
permite 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 a EDTV
(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), cujos
aparelhos receptores possuem 408 linhas, com 704 pontos em cada uma. A HDTV, cuja
imagem possui formato 16:9, é recebida em aparelhos com 1080 linhas de definição e
1920 pontos. Entre esses dois sistemas existe a EDTV, TV de média definição, que
possibilita a utilização de aparelhos com 720 linhas de 1280 pontos. Dependendo da
largura de banda disponível para a transmissão, é possível mesclar essas modalidades
de TV digital, uma vez que a qualidade da imagem no receptor é proporcional à banda
utilizada pela transmissão [Montez & Becker 2004].
A TVD tem diversas vantagens sobre a TV analógica, a mais significativa é que os
canais 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 mais
canais digitais utilizando o mesmo espaço ou prover serviços de TV de alta-definição, ou
ainda prover serviços não televisivos como transmitir multimídia ou realizar interativi-
dade. A TVD também permite serviços especiais tais como multiplexação (mais de um
programa no mesmo canal), guias eletrônicos de programação e suporte a nacionalização
(dublagens ou legendas). A venda de serviços também poderá ser mais uma fonte de lucro
para 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 continuar
assistindo 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 é possivel
assistir 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 estudo
do comportamento social relacionado à televisão, além de redes e dispositivos. Segundo
Marie-Jose Montpetit a TV social "não é apenas sobre pessoas serem sociais; é também
sobre dispositivos e até redes sendo sociais."[Montpetit 2009]. Sistemas de TV Sociais
dispõe de facilidades para o telespectador assistir à televisão enquanto realiza interações
sociais, podendo integrar por exemplo sistemas de recomendação e classificação de pro-
gramas, chat de texto, comunicação por voz, navegação na web ou 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 para
a família, assim como à cinqüenta anos atrás. Mas devido ao seu barateamento, estudos
mostram que mais da metade das residências americanas possuem três ou mais aparelhos
de TV com mais de 250 canais [Nielsen.com 2010], tornando a TV uma experiência
individual. 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ão
assistem à 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 realizados
pelo Grupo Nielsen, demonstram que cerca de metade da população online comenta sobre
assuntos relacionados à televisão, além de que entre 10 e 17% das tendências online do
momento falam sobre programas de TV [Nielsen.com 2011]. Futebol, Copa do Mundo,
Olimpíadas, Novelas, Seriados são todos programas de TV que demonstram que a TV
sempre 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. Por
exemplo, os telespectadores poderiam realizar uma seleção dos pré-candidatos a entrar
num programa de reality-show, através de dispositivos como tablets, smartphones ou a
própria televisão utilizando a web, ao invés de simplesmente escolher quem irá vencer o
programa. Desta maneira, os telespectadores teriam a experiência de fazer parte do início
do ciclo de produção de um programa, causando impacto inclusive sobre o valor desta
mí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óximo
não haverá distinção entre o conteúdo web e o conteúdo para TV, pois as aplicações web
e mobile irão se associar à TV para interagirem com formatos e conteúdos.
Como esta tecnologia irá evoluir ainda não está claro, pois existem muito desafios, que
envolvem tanto problemas relacionados à tecnologia (como padrões, plataformas), como
problemas associados à adequação de conteúdo, monetização e propriedade intelectual
[Rempt 2010].
16 CAPÍTULO 2. EMBASAMENTO TEÓRICO
2.4.2 Interatividade
A interatividade na TV surgiu junto com os sistemas de TVD e permite a interação
entre o telespectador e o aparelho de TV. Ela pode ser entendida de várias maneiras de
acordo com o sistema de TVD que está sendo utilizado. A interação pode ocorrer simples-
mente entre o Set-Top-Box (STB) e o usuário, para mudar o canal ou visualizar o EPG.
Os middlewares para TVD mais modernos, como é o caso do Ginga, também permitem
a interação entre o telespectador e a emissora através de canais de retorno e aplicações
criadas pela própria emissora [Machado 1999].
O canal de retorno permite a comunicação bidirecional entre o telespectador, as apli-
cações interativas e o provedor de conteúdo, que no caso da TVD pode ser a própria
emissora 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 a home-banking. [Machado 1999]
cita os diferentes tipos de interação na tabela 2.1:
Classe de Interatividade Meio
Interação Forte: transmissão
bidirecional, simétrica
Redes de Comunicação de Dados e
Sistema de Radiodifusão
Interação Forte: transmissão assimétrica
bidirecional, de retorno solicitada pelo
usuário
Sistema de Radiodifusão
Interação Média: transmissão
assimétrica bidirecional, de retorno
solicitada pela emissora
Sistema de Radiodifusão
Interação Fraca: transmissão
assimétrica bidirecional, de retorno
off-line
Sistema de Radiodifusão
Interação sem canal de retorno:
transmissão unidirecional, sendo o
terminal 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 possui taxas de transmissão se-
melhantes nos canais de retorno e de ida, trafegando dados normalmente, esse modelo
geralmente é 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ão
compartilha o canal de retorno entre diversos usuários (usando multiplexadores das redes
de celulares, como por exemplo TDMA, FDMA ou CDMA). A interação média é usada
na forma de "coleta"através de algumas opções dadas aos usuários. Na interação fraca, o
usuá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 é transmitido
pela emissora, já com a aplicação e os dados armazenados na memória. O telespectador
interage, 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 ideia
central da arquitetura em camadas é cada uma oferecer serviços para a camada superior e
usar os serviços oferecidos pela inferior [Oliveira & Lacerda 2008]. A figura 2.7 apresenta
cada 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ção responde pela captura e formatação dos sinais de áudio e
vídeo, bem como pela execução dos aplicativos multimídias desenvolvidos. As aplicações
comportadas vão desde jogos e internet até aplicações governamentais e de comércio
eletrô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 proporcionam
a sua integração com aplicações desenvolvidas em diversas linguagens de programação e
interfaces de baixo nível que permitem a sua independência em relação ao dispositivo.
A Camada de Codificação e Decodificação remove 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 este
fluxo chegar no receptor [Oliveira & Lacerda 2008].
A Camada de Transmissão e Recepção leva as informações digitais da emissora
até 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 uma
demodulação na recepção [Mendes 2007].
18 CAPÍTULO 2. EMBASAMENTO TEÓRICO
2.5 Middleware Ginga
O middleware brasileiro (o sistema que irá funcionar nos Set-Top Boxes fornecendo
as funções previstas nas normas regulamentadoras do SBTVD) Ginga é resultado de
uma ação conjunta entre a Universidade Federal da Paraíba (UFPB), criadora do módulo
responsável pela interpretação de código Java (Ginga-J) nos STBs que incorporam as
especificações Globally Executable MHP (GEM, que atualmente não faz mais parte da
especificação do Ginga), e a Pontifícia Universidade Católica do Rio de Janeiro (PUC-
Rio), responsável pelo desenvolvimento da linguagem de marcação NCL e a linguagem
de script Lua e da especificação de seu motor de apresentação (Ginga-NCL) [Moreno
et al. 2011][Melo & Araújo 2008].
O Ginga é uma camada de software intermediária, situada entre o sistema operacional
e 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 suporte
ao desenvolvimento de aplicações. O sistema é composto por três módulos ou camadas
principais (Ginga-CC, Ginga-NCL e Ginga-J), permitindo que aplicações sejam desen-
volvidas usando modelos de programação diferentes. A figura 2.8 mostra a arquitetura do
Middleware Ginga.
O middleware Ginga surgiu como uma tecnologia que leva ao cidadão todos os meios
para 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 e
livre de royalties, possibilitando que qualquer programador produza conteúdo interativo,
impulsionando a programação de TVs comunitárias, por exemplo. Quando o Ginga foi
desenvolvido, o Brasil foi o primeiro pais a possuir uma solução em software livre pra TV
Digital.
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 middleware Ginga que oferece
o suporte básico tanto para os ambientes procedurais quanto declarativos e é responsável
por permitir a utilização de imagens (PNG, JPG e GIF), sons (MP3, WAV e MIDI) e
vídeo (MPEG4). Ele também fornece métodos para o controle e obtenção dos fluxos
de transmissão (ISDB-TB) e do Canal de Retorno, módulo responsável por controlar o
acesso à camada de rede. A figura 2.9 mostra a estrutura desta camada e seus componentes
que 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 de
interação (ou canal de retorno). Além disso, ele deve gerenciar o canal de retorno
de 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ário
exato [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 em que o usuário
assiste 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 no
sistema, verificando, baixando e atualizando o middleware sempre que necessário,
20 CAPÍTULO 2. EMBASAMENTO TEÓRICO
para correção de possíveis erros encontrados em versões anteriores. Isto deve ser
feito 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 mesma
forma que é definida no padrão ARIB [ARIB-B-24 2004]
* Iniciador de Aplicações: carregar, configura, inicializa e executa aplicações dos
ambientes 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 processo
que 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 de
notificar os componentes sobre qualquer evento que tenha sido recebido.
* Filtro de Seções: uma vez sintonizado, o middleware deve ser capaz de acessar
partes específicas do fluxo de transporte. Para isso, o Filtro de Seção pode procurar
no fluxo a parte exata que as APIs necessitam para suas execuções, deixando passar
apenas 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 enviados
neste canal.
* Adaptador do A/V Principal: permite que as aplicações consigam enxergar o
fluxo 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 é uma
modelo 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 formas
de apresentação de conteúdo, suporte a múltiplos dispositivos, dentre outros. Para alguns
casos, como por exemplo a geração dinâmica de conteúdo, NCL provê o suporte de sua
linguagem 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 desde
a 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. O
módulo é composto por, dentre outros, uma máquina virtual Java desenvolvida especial-
mente para funcionar em sistemas embarcados com baixo poder de processamento [Melo
& Araújo 2008].
22 CAPÍTULO 2. EMBASAMENTO TEÓRICO
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 a
encontrar programas com mais rapidez. Contudo, hoje em dia, com a grande quantidade
de emissoras e programas de TV, se torna difícil descobrir com facilidade um programa
de televisão que seja interessante mesmo com o auxílio da grade de programação. Para
diminuir 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 ou
recomendaçã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 os
usuários. No contexto da TV Digital Brasileira, é necessário ainda 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ções
e 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 projeto PTV [Smyth & Cotter 2001].
Um sistema multidispositivo (celulares e PDAs), baseado em perfis de usuário e inteligên-
cia artificial. Mas apesar de ser considerado um guia de programação personalizável, este
sistema 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ódulo Profiler
do sistema, ele guarda os programas mais assistidos do usuário e traça um perfil. A partir
de uma base de dados contendo programas cadastrados e o perfil do usuário, o módulo
Recommender constrói uma lista com todos os programas recomendados. Finalmente, o
módulo Guide Compiler gera um guia de programação online personalizável a partir da
lista gerada pelo módulo Recommender e uma base de dados com grade de programação
do momento. A figura 3.1 mostra a arquitetura do Projeto PTV.
24 CAPÍTULO 3. TRABALHOS RELACIONADOS
Figura 3.1: Arquitetura do Projeto PTV
3.2 Mass Personalization
Figura 3.2: Arquitetura do Projeto Mass Personalization
Como a televisão é uma experiência social e o processo de decisão se baseia em grande
parte 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 projeto Mass Perso-
nalization [Fink et al. 2006]. Este é um framework que combina televisão com uma
experiência personalizada baseada na web. Ela unifica quatro aplicações distintas: taxas
de popularidade on-line, serviços de bibliotecas de mídias virtuais, comunidades sociais
ad-hoc (que é um chat com os usuários que estão assistindo o mesmo programa de TV) e
camadas de conteúdo personalizado (que é uma camada extra com informações relacio-
nadas a um programa de TV). Como neste trabalho, o Mass Personalization oferece um
sistema de classificação de programas de TV, mas são serviços apenas 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 precisa
dividir sua atenção entre a televisão e o computador. A figura 3.2 mostra a arquitetura do
Projeto Mass Personalization.
3.3 Tribler
Figura 3.3: Arquitetura do Projeto Tribler
O projeto Tribler [Wang et al. 2006] também descreve uma rede social para a TV, na
qual a troca de mensagens é baseada na arquitetura de rede peer-to-peer. Ele apresenta um
esquema de relacionamento, chamado de BuddyCast, que constrói uma rede social para a
troca de interesses entre os perfis de usuários. Essas informações do perfil de usuário são
construídas baseadas em classificações dos conteúdos pelos usuários ou por análises do
histórico das mudanças de canal realizadas pelo usuário. Essas classificações e históricos
são usadas então para sugerir conteúdo personalizado ao usuário. No trabalho que nós
apresentamos, o comportamento do usuário é usado como um sistema de classificação
comunicando a comunidade de amigos desse usuário às suas preferências, já que nossas
escolhas são em sua grande maioria determinadas pelas influências de outras pessoas que
26 CAPÍTULO 3. TRABALHOS RELACIONADOS
fazem parte da sua rede social. A figura 3.3 mostra a troca de mensagens do sistema
Tribler.
3.4 AmigoTV
Figura 3.4: Modelo de Funcionamento do AmigoTV
A importância na comunicação no contexto da TV também foi abordado pelo projeto
AmigoTV [Coppens et al. 2004]. Este projeto permite comunicação utilizando a própria
voz, através da televisão. Especificamente, os usuários podem falar com seus amigos
que estão identificado através do uso de avatares. Este projeto utiliza uma abordagem
inovadora pois ele suporta a comunicação em tempo real. Nós preferimos a comunicação
textual, pois ela continuará a ser exibida na tela caso o usuário não esteja na frente da TV
no momento que a mensagem é enviada. A figura 3.4 mostra o modelo de funcionamento
do protótipo de arquitetura AmigoTV.
3.5 CollaboraTVware
O projeto CollaboraTVware [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 inteiramente
no comportamento dos perfis de usuário e utilizando técnicas de inferências para reali-
zar as recomendações. Dessa maneira, trata-se de um projeto bastante parecido com os
Guias Eletrônicos de Programação Personalizáveis que foram discutidos anteriormente.
A figura 3.5 mostra o diagrama de casos de uso do projeto CollaboraTVware.
3.6 EPG-Board
O projeto EPG-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. Eles
descrevem um sistema voltado para centros de mídia (media centers), desenvolvendo um
EPG 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 do CollaboraTVware
e um sistema de etiquetagem (tagging). Eles utilizam o OmegaBox1, um sistema para
centros 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 programa
de 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 com
outros usuários on-line mas de maneira assíncrona e funciona da mesma maneira que no
nosso 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ível classificar apenas como
bom 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 em
consideração a força dos laços de confiança dos usuários, que possuem pesos diferentes
quanto à influência que realizam.
No sistema de etiquetagem apresentado pelo projeto EPG-Board, qualquer usuário
pode 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. No
nosso trabalho, os metadados sobre um determinado programa são manipulados apenas
por usuários credenciados (como as próprias emissoras por exemplo).
O projeto EPG-Board especifica também os elevados requisitos de hardware para
o funcionamento do OmegaBox, tornando-o muito custoso e portanto proibitivo para o
contexto 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óprio OmegaBox, deixando os
usuários de outros dispositivos de fora, como um cliente web por exemplo. Outro pro-
blema observado no projeto EPG-Board é a facilidade que um usuário tem de alterar os
meta-dados sobre um determinado programa, podendo levar usuários maldosos a realiza-
28 CAPÍTULO 3. TRABALHOS RELACIONADOS
rem qualificações absurdas, ou simplesmente apagar os meta-dados, e ao invés de facilitar
pode acabar dificultando nas buscas por programas baseados nestes meta-dados.
3.7 Miso
O projeto Miso [goMiso.com 2011] é uma rede social virtual que dá uma segunda
experiê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 de check-in, além de um sistema de
pontuação para estimular seu uso, possuindo um comportamento que se assemelha ao
Foursquare [foursquare.com 2011]. Embora seja uma rede social para televisão, ela não
disponibiliza vídeos on-line nem permite assistir o conteúdo, sendo inteiramente voltado
para a web. O sistema oferece um sistema de troca de mensagens entre usuários, mas não
permite a classificação dos programas on-line, permitindo apenas uma classificação geral
e atemporal, pois não existem requisitos temporais para se realizar o check-in. Além disso
esta rede social apresenta o conceito de hosts que são usuários especiais, que controlam
alguns meta-dados dos programas, criam enquetes sobre o programa, além de realizar
outras atividades com mais privilégio que um usuário comum.
3.8 TA2
O principal objetivo do projeto Together 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 um framework que centraliza todas estas atividades. Diferente das mídias atuais
que são voltadas para o indivíduo este mecanismo de comunicação é voltada para grupos
de 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 captura
e 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ção
de conteúdo XHTML nos vídeos, gerenciamento de serviços para coordenar o uso dos
diferentes softwares e dispositivos, e finalmente a orquestração que transforma os dados
de baixo nível recebidos pela ferramenta de análise em aspectos mais significativos da
interação social.
3.9 Comparação Entre Trabalhos
A Tabela 3.1 mostra um quadro comparativo entre os trabalhos que foram aqui apre-
sentados. Os trabalhos foram agrupados nas colunas, na qual a última coluna aborda a
nossa arquitetura TrendTV. Desta maneira, tentamos realizar uma comparação entre os
projetos 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 de
Programas On-line, Chat por texto, Chat por voz, Histórico de Conversas, Suporte ao
Sistema Brasileiro de TV Digital, Suporte a Set-Top-Boxes, Classificação de Meta-Dados
Colaborativamente, 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 Graus
de Confiança.
O Suporte a Multi-Dispositivos diz respeito aos tipos de dispositivo que o projeto
suporta, como Set-Top-Boxes, celulares, PDAS, computadores, entre outros. Como apre-
sentado na tabela 3.1 os projetos que suportam multi-dispositivos foram a arquitetura
TrendTV e os projetos PTV, CollaboraTVWare, Miso, TA2.
Os serviços Web são serviços disponibilizados pelos projetos para serem acessados
por outras aplicações ou pelo usuário.
Como pode ser visto na tabela 3.1 todos os projetos que tem Chat por texto, também
indicam programas on-line, e mantém o histórico das conversas. Isto acontece porque foi
assumido que um chat pode funcionar como um mecanismo de indicação de programas.
Os únicos projeto que utilizaram o modelo do SBTVD foram o CollaboraTVware e
a arquitetura TrendTV, ambos desenvolvidos no Brasil.
O suporte a Set-Top-Boxes não foi realizado pelos projetos PTV, 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 essa classificação colaborativa
são o EPG-Board e o projeto Miso.
No Sistema de Notas o usuário define uma nota para um determinado programa, que
geralmente varia de 1 a 5 ou 1 a 10, permitindo uma maior precisão na classificação de
um programa.
Na indicação baseada em inferências, os projetos analisam o perfil de acesso do usuá-
rio através de históricos e utilizam mecanismos de inferência como Redes Neurais, Lógica
Fuzzy, Modelos Estatísticos dentre outros.
Pela tabela 3.1 podemos perceber também que todos os projetos que possuem Chat
tanto por texto quanto por voz causam influência direta sobre seus 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 virtuais Facebook e Orkut, permitindo que esses laços se tornem mais fortes e
influenciem cada vez mais nas decisões de seus usuários.
Apenas o projeto Miso possui suporte e integração a outras redes sociais, permitindo
que o usuário possa compartilhar suas informações com o Twitter e o Facebook por
exemplo.
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 ao
usuá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ça
para a indicação de programas para o usuário além da arquitetura TrendTV.
30 CAPÍTULO 3. TRABALHOS RELACIONADOS
Propriedades PTV MassPers.
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 sim
Indicação
On-Line
sim sim não sim não sim sim não sim
Chat por
texto
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ão
Histórico de
Conversas
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 sim
Set-Top-
Boxes
não não sim sim sim sim não não sim
Meta-Dados
Colaborativo
não não não não não sim sim não não
Sistema de
Notas
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 sim
Influência
Direta
não sim não sim não sim sim sim sim
Comunidades
Virtuais
não sim não sim não sim sim não sim
Suporta ou-
tras redes
sociais
não não não não não não sim não não
Graus de
Confianç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: O TrendTV. Essa
arquitetura surgiu como uma tentativa de agilizar a busca por conteúdo interessante na
TV, de maneira fácil e intuitiva, permitindo inclusive a mudança automática do canal
para 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 de
um 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 Arquitetura TrendTV. O cenário ideal pode ser alcançado com aplicações baseadas
nessa arquitetura que alterem os canais automaticamente baseados nas influências que
uns usuários realizam sobre os outros. Para facilitar a explicação dessa arquitetura iremos
dividi-la em módulos e cada módulo será explicado separadamente. A figura 6.1 mostra
a arquitetura do projeto TrendTV.
4.1.1 Trend4Web
O módulo Trend4Web é o módulo mais complexo dessa arquitetura e foi inteiramente
desenvolvido usando o padrão arquitetural MVC voltado para web. Este módulo é res-
ponsável por acomodar todas as estruturas lógicas de um guia eletrônico de programação
personalizável. Este módulo define as regras de negócio e representações detalhadas das
informações que serão usadas por todos os módulos, sendo o único módulo que possui o
componente Model e portanto acesso direto a base de dados. Assim o componente Con-
troller desse módulo, precisa formatar as informações contidas no componente Model
para 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 e dispositivos foi o JSON
(JavaScript Object Notation) por se tratar de um formato leve para intercâmbio de dados
computacionais, permitindo assim que web-services troquem informações com outros ser-
viços. O funcionamento dos web-services construídos neste trabalho serão explicados na
próxima seção.
4.1.2 Trend4Mobile
O módulo Trend4Mobile visa as plataformas móveis e permite que o usuário des-
cubra quais os programas mais indicados do momento baseado em informações obtidas
através de web-services, que foram definidos no módulo para web Trend4Web. Este mó-
dulo também possui outros serviços que serão descritos na próxima seção. Para permitir
a comunicação com o módulo Trend4Web, a API JSON deve ser utilizada. Este módulo
também possui comunicação com o Set-Top-Box permitindo assim a mudança automática
de canais.
4.1.3 Trend4TV
O módulo Trend4TV é um módulo para Set-Top-Boxes que é responsável por mostrar
numa grade os canais mais indicados em um determinado momento, baseado nas escolhas
dos usuários, além de outros serviços que serão descritos a seguir. As informações sobre
as qualificações dos programas no momento podem ser realizadas de duas maneiras dis-
tintas. Se o Set-Top-Boxes possui canal de retorno, a informação é recebida on-line através
de web-services e 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 em
um modelo de transmissão de dados que é envia as informações repetidamente em ciclos
contínuos). Para tratar e utilizar as informações recebidas, a API JSON para a linguagem
Lua foi utilizada.
4.1. SOLUÇÃO PROPOSTA 33
Este módulo também possui um componente que atua como um serviço responsável
pela mudança automática de canais dentro do Set-Top-Boxes. Criamos este componente
como um módulo para a camada Ginga Specific Service (a mesma camada que contém
o módulo Ginga-NCL e Ginga-J), que por sua vez foi construído tendo como base as
funcionalidades providas pelo Ginga Common Core cuja arquitetura foi explicada na
seçã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, que utiliza o modelo JSON
apresentado na seção anterior, esta arquitetura contém um protocolo de comunicação pró-
prio baseado em sockets UNIX para realizar a mudança de canais. Este protocolo foi
escolhido em detrimento ao JSON pois o serviço residente para a mudança de canais
precisa ser o mais simples e leve possível para não comprometer o processamento e a
performance do Set-Top-Box.
A figura 4.2 apresenta o fluxo de comunicação do protocolo de mudança automática
de canais.
Figura 4.2: Fluxo de Comunicação para a Mudança Automática de Canais
A aplicação se conecta ao serviço e recebe a mensagem TRENDTV_MSG_ACCEPT,
contendo informações sobre os canais disponíveis que já estão pré-sintonizados naquele
Set-Top-Box. Em seguida, a aplicação escolhe o canal e a seção e envia uma mensagem
TRENDTV_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 de
canal no formato TRENDTV_MSG_CONFIRMATION. Este ciclo é repetido até que
o serviço receba uma mensagem contendo apenas os caracteres que identificam o fim de
arquivo 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 de cada programa é re-
alizada em tempo real e personalizada para cada usuário, baseando-se nas indicações
realizadas pelos seus amigos. Para realizar estes cálculos, antes é necessário estabelecer
os pesos que os graus de confiança exercem sobre cada indicação. Para este trabalho foi
escolhido arbitrariamente que o grau de confiança Forte influencia em 60% das decisões,
o Médio em 30% das decisões e o Fraco em 10% das decisões. Assim, a nota média de
cada 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)
Onde SomaDasNotas é a soma de todas as notas de um programa para um determi-
nado usuário e SomaDosPesos é a soma de todos os pesos de um programa para um dado
usuá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 determinado programa da sua rede
de amigos, ki é baseado no Nível de Confiança da indicação para um usuário, ki = 1.6
quando o nível de confiança na indicação é forte, ki = 1.3 quando o nível de confiança
para um indicação é médio e ki = 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 de casos de uso que exem-
plificam o uso desta arquitetura. O caso ideal para estes cenários pode ser alcançado com
aplicações que possam mudar de canal automaticamente baseadas apenas nas influências
dos amigos do usuário através de vários dispositivos diferentes. Para ilustrar como é o
comportamento de cada serviço que irá compor a arquitetura TrendTV foram definidos 8
cenários distintos, no qual cada cenário pode possuir um ou mais casos de uso. A figura
5.1 mostra um cenário geral que faz uso da arquitetura do projeto TrendTV.
Figura 5.1: Cenário geral da Arquitetura TrendTV
36 CAPÍTULO 5. CENÁRIOS DA ARQUITETURA TRENDTV
5.1 Cadastrar Usuário
Figura 5.2: Cenário Cadastrar Usuário
Como nessa arquitetura a maior parte da interação é realizada pelo telespectador, ire-
mos abordar primeiramente o Cadastrar Usuário. No cadastro de usuários, o usuário
insere 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 como
nome de usuário e senha são fundamentais para garantir a privacidade. O usuário pode
enviar essas informações através de diversos dispositivos, como computador, celular e a
própria televisão. Essas informações são enviadas através da web até o Servidor de Usuá-
rios. O servidor realiza o tratamento dessas informações e caso todas as informações
estejam corretas o usuário é cadastrado no Repositório de Usuários. A figura 5.2 mostra
o cenário Cadastrar Usuário.
5.2 Adicionar Amigo
Figura 5.3: Cenário Adicionar Amigo
No cenário de Adicionar 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 sua
rede 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é o Servidor de Usuá-
rios e o servidor realiza a adição na rede de amigos no Repositório de Usuários. A figura
5.3 mostra o cenário Adicionar Amigo.
5.3 Indicar Grau de Amizade
Figura 5.4: Cenário Indicar Grau de Amizade
O cenário de Indicar Grau de Amizade permite ao usuário definir três níveis de
confiança (Forte, Médio e Fraco) entre os usuários que compõem a sua rede, atualizando
o conteúdo do Repositório de Usuários. Esses níveis de confiança causam um impacto
sobre a influência que um usuário pode realizar sobre outro, pois assim como acontece na
sociedade, quanto maior o nível de confiança que uma pessoa tem sobre outra, maior a
chance de influenciá-la. A figura 5.4 mostra o cenário Indicar Grau de Amizade.
5.4 Conversar
Figura 5.5: Cenário Conversar
No cenário Conversar, o usuário pode se comunicar através de mensagens de texto
com qualquer outro usuário. Para isso, o usuário precisa estar cadastrado previamente
no Repositório de Usuários, então o Serviço de Chat irá Recuperar Login para validar o
38 CAPÍTULO 5. CENÁRIOS DA ARQUITETURA TRENDTV
usuário. Quando o usuário envia uma mensagem, ele pode adicionar o símbolo "@"se-
guido pelo username e a mensagem, então os usuários que possuem o seu username na
mensagem estarão habilitados para ver a mensagem no quadro de mensagens, possuindo
um comportamento semelhante à ferramenta de micro-blogging Twitter. Assim, o Ser-
viço de Chat precisa realizar uma consulta no Repositório de Usuários para coletar essas
informações. O Serviço de Chat também guarda as conversas no Histórico de Conver-
sas, para que essas conversas possam acontecer assincronamente. A figura 5.5 mostra o
cenário Conversar.
5.5 Indicar Programa
Figura 5.6: Cenário Indicar Programa
O cenário de Indicar Programa, permite que usuários possam classificar um pro-
grama utilizando um sistemas de notas, que variam de 0 a 5. O Serviço de Indicações
então Aplica Pesos de Amizade na Nota recebida, baseado em informações recebidas
pelo Repositório de Usuários e o Repositório de Notas. Todos os amigos da pessoa que
enviou a indicação tem sua grade de programação atualizada dinamicamente. Os pesos
são aplicados conforme o grau de confiança que um usuário tem pelo outro (Forte, Médio
ou Fraco).
O Serviço de Indicações também registra no Repositório de Notas todas as classifi-
cações realizadas sobre um determinado programa sem aplicar os pesos, realizando uma
simples 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 as classificações realizadas
pelos seus amigos. Quando um usuário realiza uma busca por indicações, o Serviço de
Indicações busca no Serviço de Meta-Dados todos os programas que estão sendo transmi-
tidos naquele instante, e em seguida o Serviço de Indicações faz uma busca no Repositório
de Notas. De posse de informações do usuário e dos programas que estão passando na-
quele instante, o Repositório de Notas retorna as notas em tempo real. A figura 5.6 mostra
o cenário Indicar Programa.
5.6. RECEBER META-DADOS 39
5.6 Receber Meta-Dados
Figura 5.7: Cenário Receber Meta-Dados
O usuário pode receber meta-dados diretamente através de web-services. Para isto o
Serviço de Meta-Dados realiza uma requisição ao Repositório de Programas e recupera
a programação que estará passando ao longo do dia, incluindo a classificação geral dos
programas durante aquele momento, realizada pela simples média das indicações de todos
os usuários.
Se o usuário faz uso do Canal de Retorno, o cenário Receber Meta-Dados tem o
mesmo comportamento de receber os dados através da web. Caso o usuário possua ape-
nas o Set-Top-Box, ele irá receber as informações através da Antena de Difusão e as
informações serão enviadas através de um Carrossel de Dados. O Carrossel de Dados
recupera as informações dos Programas periodicamente do Repositório de Programas de
TV, 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.7
mostra o cenário Receber Meta-Dados.
5.7 Enviar Meta-Dados
Figura 5.8: Cenário Enviar Meta-Dados
O cenário Enviar Meta-Dados simplesmente permite que a emissora possa cadastrar
informações genéricas sobre um determinado programa, como por exemplo o gênero, o
40 CAPÍTULO 5. CENÁRIOS DA ARQUITETURA TRENDTV
elenco, a duração, entre outros. O Serviço de Meta-Dados recebe essas informações e
envia para o Repositório de Programas. A figura 5.8 mostra o cenário Enviar Meta-
Dados.
5.8 Mudar Canal Automaticamente
Figura 5.9: Cenário Mudar Canal Automaticamente
O cenário Mudar Canal Automaticamente irá alterar automaticamente o canal atual
da TV usando um Celular ou Set-Top-Box, ambos com as tecnologias Ethernet e Blueto-
oth. O celular irá receber a classificação dos programas através da web, e irá enviar uma
mensagem para o Set-Top-Box para mudar o canal com o programa melhor classificado
no momento. O Mudar Canal Automaticamente é apenas responsável por realizar a
mudança automática dos canais. Como o middleware Ginga não permite as aplicações
mudarem os canais, esta aplicação está diretamente associada ao Sistema Operacional do
Set-Top-Box, atuando como um serviço de sistema. Todas as infomações necessárias para
realizar a mudança de canal são previamente enviadas pelos módulos Trend4Mobile e
Trend4TV. A figura 5.9 mostra o cenário Mudar 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, para diversos dispositivos. Na
primeira aplicação o módulo Trend4Web foi desenvolvido contando com uma aplica-
ção web e um conjunto de web-services. A segunda aplicação desenvolveu o módulo
Trend4Mobile da nossa arquitetura e ela conta com um cliente para os web-services de-
senvolvidos na aplicação anterior para dispositivos móveis, além de um cliente para o
serviço de mudança automática de canais. A terceira aplicação possui as mesmas funcio-
nalidades da segunda aplicação, mas para Set-Top-Boxes utilizando o middleware Ginga.
A quarta aplicação é simplesmente um serviço de mudança de canais localizado dentro
do Sistema Operacional do Set-Top-Box. Estas duas últimas aplicações fazem parte do
módulo Trend4TV. Apresentamos neste capítulo os resultados alcançados nestas qua-
tro aplicações. A figura 6.1 apresenta a estrutura da arquitetura que foi implementada
utilizando as tecnologias mencionadas no capítulo 1.
6.1 Aplicação Trend4Web
A aplicação para o módulo Trend4Web consiste basicamente de uma página web
com algumas funcionalidades que serão descritas a seguir e um conjunto de web-services
descritos 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 e canais foram os componentes
desenvolvidos, permitindo a avaliação dos programas disponíveis para os canais da TV
pública brasileira.
O sistema de autenticação permite que apenas usuários cadastrados possam utilizar o
sistema. 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 da
autenticação do usuário.
No gerenciamento de usuários o telespectador pode ver e editar seu perfil, além de
procurar, 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 na
ordem cronológica de envio as conversas que possuem o seu username no 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 que
estã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á foi
apresentado na seção anterior, este serviço de classificação possui dois comportamentos
distintos, baseado no contexto em que se encontra. A figura 6.2 apresenta um exemplo de
classificaçã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 interagem com essa aplicação através
do sistema de autenticação e cadastro de programas e grade de horários, inserindo meta-
informações como por exemplo, nome dos programas, descrição e horário. Apesar de
realizar o cadastro dos programas e definir sua grade de horários a emissora obviamente
nã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 visualizar
a média geral de cada canal e programa.
6.2 Aplicação Trend4Mobile
Com os web-services da aplicação Trend4Web finalizados, uma aplicação para ambi-
entes móveis foi desenvolvida para o módulo Trend4Mobile. 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ção Trend4Web e foram os componentes desenvolvidos que utilizaram
a tecnologia de web-services para recuperar e enviar dados, desta maneira centralizando
e integrando todas as informações numa única base de dados localizada na aplicação
Trend4Web. A figura 6.3 mostra um exemplo de classificação de programas para a apli-
cação Trend4Mobile desenvolvida na plataforma JavaME.
Esta aplicação também troca mensagens com um serviço localizado no Set-Top-Box
responsável por realizar a mudança de canais. O protocolo de comunicação entre esta
aplicação está sendo realizado de acordo com o protocolo descrito na seção 4.1.4. Para
realizar 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 observado
na figura 6.4. Quando o usuário define o intervalo de mudança automática, o sistema
executa uma Thread em background que fica alterando no tempo especificado os canais,
sem a interferência do usuário.
6.3 Aplicações Trend4TV
O módulo Trend4TV é composto por duas aplicações distintas. Uma implementa um
cliente para o middleware Ginga e a outra aplicação é o próprio serviço residente que
realiza a mudança automática de canais. A aplicação cliente possui um sistema de auten-
ticação, conversas e serviço de classificação de programas, todos com o mesmo compor-
44 CAPÍTULO 6. IMPLEMENTAÇÃO E RESULTADOS
Figura 6.3: Classificação de Programas na Aplicação Trend4Mobile
Figura 6.4: Mudança Automática de Canais na Aplicação Trend4Mobile
6.3. APLICAÇÕES TREND4TV 45
tamento dos componentes da aplicação Trend4Web e utilizando web-services para recu-
perar e enviar dados. A figura 6.5 mostra um exemplo de mudança de canais utilizando a
aplicação Trend4TV. A aplicação cliente também possui um mecanismo de mudança de
canais com o mesmo comportamento da aplicação Trend4Mobile, utilizando inclusive o
mesmo protocolo de comunicação.
Figura 6.5: Mudança de Canais na Aplicação Trend4TV
6.3.1 Melhorias na Usabilidade
Para facilitar o processo de indicação de programas na aplicação Trend4TV, o usuá-
rio tem apenas a opção de aprovar ou desaprovar, ao invés de atribuir uma nota para a
qualidade 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 nota
mínima, desta maneira a aplicação se torna mais fácil de usar sem realizar nenhum grande
impacto no processo de qualificação dos programas.
6.3.2 Modelagem da Base de Dados
Antes de apresentarmos as estruturas das implementações de cada módulo é necessá-
rio explicar a modelagem da base de dados, é ela que guarda o domínio da arquitetura e
possui boa parte das lógicas de negócio, além de mostrar como funcionam os relaciona-
mentos entre cada componente da arquitetura. Esta modelagem deve também apresentar
características semelhantes à modelagem de um guia de programação personalizado, e
para tanto ela deve possuir as seguintes entidades fundamentais:
46 CAPÍTULO 6. IMPLEMENTAÇÃO E RESULTADOS
Figura 6.6: Diagrama Entidade Relacionamento
• Usuário: responsável por guardar informações sobre um determinado usuário, como
dados de segurança e autenticação, além de informações pessoais. Esta entidade é
representada no diagrama pelas tabelas users e user_profiles.
• Canais: armazena o nome e número do canal, a seção e uma descrição. Esta enti-
dade é representada no diagrama pela tabela channel.
• Gêneros: uma lista que contêm um conjunto de gêneros de programas pré-definidos.
Esta entidade é representada no diagrama pela tabela genres.
• 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ção
geral dos seus programas realizadas pelos usuários e faz referência as entidades Ca-
nais e o Gêneros. Esta entidade é representada no diagrama pela tabela programs.
• Conversas: armazena o histórico de todos os "posts"realizadas pelos usuários e a
hora de envio. Esta entidade é representada no diagrama pela tabela chat.
• Relacionamentos: referencia a Entidade Usuário para criar um relacionamento en-
tre os usuários que estão numa mesma tupla. Além disso esta entidade armazena o
grau de amizade entre esses dois usuários. Esta entidade é representada no diagrama
pela tabela relationships.
• 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 uma descrição extra
e nomes especiais referentes a uma determinada exibição, além de também fazer
referência a entidade Programas. Esta entidade é representada no diagrama pela
tabela programs_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 Entidade Usuário e Grade de Programação. Esta entidade é representada
6.3. APLICAÇÕES TREND4TV 47
no diagrama pela tabela user_indication.
O Diagrama de Entidade-Relacionamento da figura 6.6 apresenta a modelagem da
base 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 foram
criados web-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 detalhes
proprietários das infra-estruturas de suporte.
Para realizar a comunicação com os web-services é necessário apenas saber a URL
correta e fazer uma requisição usando o Protocolo HTTP e passando os cookies de 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 para
recuperar informações foi utilizado o método GET do HTTP e para enviar informações
o método POST foi o utilizado.
A figura 6.7 mostra um exemplo de requisição do web-service de conversa deste tra-
balho. Nesta requisição o usuário apenas está carregando as conversas.
Figura 6.7: Exemplo de comunicação HTTP com Cookies
No entanto, existem críticas sobre o modelo de comunicação padrão dos web-services.
Uma dessas críticas diz respeito ao fato de que o SOAP (Simple Object Access Protocol)
é menos eficiente do que os sistemas de RPC (Remote Procedure Call) existentes. As
mensagens (com os respectivos envelopes e descrição de tipos) trocadas entre as partes
são descritas em formato de texto/XML enquanto que nos sistemas clássicos de RPC
são trocadas em formato binário. Isto aumenta o tamanho da mensagem e encarece o
seu envio, além do esforço computacional adicional apenas para realizar o parsing do
documento XML, tornando as respostas dos web-services mais lenta.
Numa tentativa de resolver esse alto custo de comunicação, o protocolo JSON (Ja-
vaScript Object Notation) foi escolhido para este trabalho, pois é um formato bem mais
leve de intercâmbio de dados, além de ser fácil para humanos lerem e escreverem, e mais
fácil ainda para gerar um objeto JSON e realizar o parse. JSON possui duas estruturas
principais:
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 ",").
48 CAPÍTULO 6. IMPLEMENTAÇÃO E RESULTADOS
2. Uma lista de valores ordenados (começa com "["e termina com "]"e os valores são
separados por ",")
A figura 6.8 mostra a estrutura de uma típica mensagem JSON.
Figura 6.8: Exemplo de JSON
6.3.4 Implementação do Protocolo de Comunicação para a Mudança
Automática de Canais
Como já foi explicado na seção 4.1.4, para realizar a troca automática de canais foi
definido um protocolo para a comunicação entre o componente de mudança de canais e
os clientes deste serviço, neste trabalho, implementamos as mensagens de acordo com a
tabela 6.1.
Na mensagem TRENDTV_MSG_ACCEPT o primeiro número representa o número
do canal, o segundo número representa a seção do canal, os próximos 3 números represen-
tam PIDs (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 canais são descritos o caractere
"$"é utilizado para determinar o fim da mensagem.
A mensagem TRENDTV_MSG_CHANGE_CHANNEL é composta simplesmente
pelo número do canal, seguido de um ".", depois o número de seção e finalmente um ca-
ractere de escape "\n", esta mensagem também pode ser simplesmente a string "EOF"que
determina o fim da conexão com o serviço.
A mensagem TRENDTV_MSG_CONFIRMATION é apenas composta por duas
strings pré-definidas: "OK$"quando o Set-Top-Box efetuou a operação de mudança de
canal com sucesso e a mensagem "ERROR$"quando algum erro ocorre.
6.3. APLICAÇÕES TREND4TV 49
Mensagem Exemplo
TRENDTV_MSG_ACCEPT 3 1 4097 4099 4098 BAND NATAL HD\n
11 1 49 51 50 CABUGI HD\n$
TRENDTV_MSG_CHANGE_CHANNEL 3.1\n ou EOF
TRENDTV_MSG_CONFIRMATION OK$ ou ERROR$
Tabela 6.1: Mensagens do Protocolo de Mudança Automática de Canais
6.3.5 Estrutura das Mensagens JSON
Nesta seção são apresentadas as mensagens utilizadas nesse sistema, assim como um
conjunto de tabelas que apresentam os componentes das mensagens JSON, além do tipo
de dado de cada componente.
A tabela 6.2 mostra os componentes da mensagem JSON quando um usuário faz uma
requisição a um web-service sobre informações sobre um determinado canal. O compo-
nente classification apresenta a classificação geral do canal, com as indicações realizadas
por todos os usuários. O componente number_of_votes apresenta o número total de votos
que todos os programas que este canal já recebeu. O componente number_of_programs
mostra a quantidade de programas que este canal possui. Os campos section, channel,
name servem para identificar o número, a seção do canal e o nome do canal. Finalmente
o campo description, contem informações genéricas sobre este canal.
Campo Tipo
classification Integer
number_of_votes Integer
number_of_programs Integer
section Integer
channel Integer
name String
description String
Tabela 6.2: Mensagem JSON com informações de um Canal
A tabela 6.3 apresenta os campos que compõem a mensagem JSON quando o usuário
consulta informações sobre um determinado programa de TV. O componente id_program
mostra 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 componentes pro-
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 o
processo de filtragem por conteúdo. Os atributos id_channel e channel_name, represen-
tam respectivamente o número de identificação e o nome do canal ao qual o programa
pertence. Os componentes classification e number_of_votes, representam a classifica-
ção geral do programa e o número total de indicações para este programa realizadas por
50 CAPÍTULO 6. IMPLEMENTAÇÃO E RESULTADOS
todos os usuários. Os componentes id_instance, instance_name e note guardam as in-
formações do programa para um determinado horário, o primeiro componente define o
número de identificação, o segundo um nome especial para o programa e o terceiro traz
algumas notas específicas sobre o programa de um determinado horário. Os campos de
mensagem id_genre e 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 Tipo
id_program Integer
program_name String
description String
keywords String
id_channel Integer
channel_name String
classification Integer
number_of_votes Integer
id_instance Integer
instance_name String
notes String
id_genre String
genre String
Tabela 6.3: Mensagem JSON com informações de um Programa
A tabela 6.4 contém os campos e os tipos de dados que compõem as informações so-
bre as tendências do momento sobre programas de TV, representando uma classificação
dos programas de TV que estão sendo exibidos em um determinado momento. Apesar
de possuir os mesmos campos, esta mensagem JSON apresenta dois comportamentos
diferentes, 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 nas
informaçõ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 faz uma requisição a esse
web-service anonimamente, o web-service retorna uma mensagem contendo uma média
das classificações e indicações realizada por todos os usuários. Os atributos id_program,
program, id_instance, instance_name e notes possuem informações relativas a um pro-
grama de TV que está sendo exibido no momento em que a requisição ao web-service é
feita. Estas informações são, respectivamente, o número de identificaçã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 finalmente
o último atributo traz notas específicas sobre o programa de um determinado horário. Os
atributos id_channel, channel e section trazem informações sobre o canal que contém o
programa, permitindo que o Set-Top-Box possa alterar o canal. O primeiro atributo define
o número do canal, o segundo define o nome do canal e o terceiro atributo define a seção
do canal na qual o programa está sendo exibido (diferentemente da TV analógica, a TV
6.3. APLICAÇÕES TREND4TV 51
digital permite que um canal seja subdivido em várias seções para aproveitar ao máximo
o espectro do sinal). Finalmente, os atributos classification e number_of_votes apresen-
tam a classificação do programa e o número de indicações de acordo com os contextos
apresentados previamente.
Campo Tipo
id_program Integer
program String
id_instance Integer
instance_name String
notes String
id_channel Integer
channel String
section String
classification Integer
number_of_votes Integer
Tabela 6.4: Mensagem JSON com informações sobre as Tendências do Momento
A tabela 6.5 apresenta os campos que compõe uma mensagem JSON com informa-
ções sobre as conversas e posts realizados pelos usuários. Desta maneira, para aumentar
a segurança só é possível utilizar e consultar este web-service após realizada a auten-
ticação do usuário, e apenas os usuários envolvidos na conversa podem ter acesso as
mesmas. Os atributos user_id e username possuem 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 atributo querychat é uma lista de dados que contém informações
sobre as conversas relacionadas ao usuário que está autenticado. Os atributos que com-
põem esta lista são querychat.id, querychat.text, querychat.time, querychat.id_user e
querychat.username. O primeiro atributo representa um número de identificação de uma
determinada conversa, o segundo representa o conteúdo da conversa, o terceiro atributo
representa 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.
52 CAPÍTULO 6. IMPLEMENTAÇÃO E RESULTADOS
Campo Tipo
user_id Integer
username String
querychat Lista
querychat.id Integer
querychat.text String
querychat.time Date
querychat.id_user Integer
querychat.username String
Tabela 6.5: Mensagem JSON com informações sobre as Conversas
6.3. APLICAÇÕES TREND4TV 53
‘
54 CAPÍTULO 6. IMPLEMENTAÇÃO E RESULTADOS
Capítulo 7
Considerações Finais
O presente trabalho une conceitos de TV Digital Interativa e Redes Sociais Virtuais
em uma solução para o problema da sugestão e escolha de canais no contexto da TV Digi-
tal Interativa(TVDI) aplicada ao Sistema Brasileiro de TV Digital (SBTVD). Destacamos
como 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 base
em microblogging de conteúdo on-line e a definição de componentes de software a serem
adicionados à arquitetura dos atuais sistemas de TV Digital existentes, de modo a per-
mitirem um maior controle da troca de canais por parte de uma aplicação. Além dessas
contribuições em termos de projeto, o presente trabalho apresentou a implementação de
um sistema que valida a arquitetura TrendTV aplicada ao SBTVD e ao middleware Ginga.
Em outras palavras, propomos a arquitetura TrendTV, uma arquitetura para avaliação
de programas de TV baseada em redes sociais virtuais com suporte a multidispositivos
no cenário do Sistema Brasileiro de TV Digital. Essa arquitetura permite ao usuário a
realização de avaliações e indicações em tempo real sobre um determinado programa de
TV, assim como a disponibilização dessas impressões para todos que fazem parte de sua
rede de amigos.
Ainda como contribuição, introduzimos o conceito de peso de amizade para redes
de microblogging, pesos estes que influenciam a relevância das indicações de cada nova
amizade adicionada a rede. Através dessas indicações os telespectadores podem reduzir
o tempo de busca por programas e canais que sejam de seu interesse ou do grupo de
amigos em sua rede. Dessa forma, ajudamos os seus usuários a se capitalizarem com essa
moeda social que são as conversas que giram em torno dos programas mais assistidos por
um 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 ao middleware Ginga,
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 de
TV pode realizar, automaticamente, a mudança de canais com base na rede social criada
pelo usuário. Definimos também um protocolo de comunicação usando diferentes inter-
faces ou dispositivos, possibilitando que usuários com dispositivos ou interfaces distintas
realizem 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 protocolo HTTP+JSON) do sistema usado nas
aplicações, que pode ser facilmente adaptada para outras aplicações (portanto, uma base
para a construção de um framework que 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 a Conferência Internacional IEEE sobre Ambientes
Virtuais, Interfaces Humano-Computador e Sistemas de Medição (VECIMS’2011) que
apresenta brevemente esta arquitetura, bem como os cenários dos casos de uso.
Desta maneira, neste trabalho, uma nova abordagem está sendo proposta para resolver
os problemas de classificação de programas de TV de maneira a propiciar uma maior
satisfaçã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 e Set-Top-Boxes, tudo realizado de maneira transparente para o
usuário. O resultado é um sistema que disponibiliza diferentes maneiras de conexão para
que seus usuários o acessem, visando garantir uma maior acessibilidade, principalmente
para os usuários com poucos recursos. Usuários com equipamentos de baixo desempenho
que não conseguiriam acessar o sistema através de um computador, podem optar por um
celular com recursos menos exigentes. Já os usuário que possuem apenas Set-Top-Boxes.
Através deste trabalho mostramos que é possível interligar diferentes dispositivos com o
propósito de classificar programas de televisão utilizando um único ambiente comparti-
lhado por todos os usuários.
Esta arquitetura possui um grande potencial para ser utilizado por todas as classes
sociais, inclusive a população de baixa renda, tornando-se uma importante ferramenta de
classificação de programas. Isto permite o acesso a um público maior de usuários que
em muitos casos não teriam acesso a uma variedade de sistemas se não dispusessem de
computadores com a configuração mínima para executá-los.
Nos experimentos e testes, mostramos o desenvolvimento de aplicações para a arqui-
tetura TrendTV que possibilitam um usuário indicar programas, se comunicar e trocar
de canal sem interferências. Os resultados alcançados demonstram a viabilidade do uso
do modelo proposto, visando melhorar os atuais Guias Eletrônicos de Programação.
Contudo, percebemos que o processo de mudança automática de canais requer alterações
no middleware Ginga (mais precisamente na camada Ginga Specific Service) e portanto
uma versão customizada é necessária, já que a especificação do Ginga não permite que
aplicações interfiram na mudança de canais. Por isso outros desenvolvimentos futuros são
necessá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ção
de programas baseado em redes sociais compatíveis com o middleware Ginga. Isto abre
uma margem para vários estudos e análises. A princípio, poderíamos realizar testes de
stress na arquitetura para avaliar aspectos como escalabilidade, resposta do sistema e
robustez. 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 tecnologia
de raios infravermelhos para simular o comportamento de um controle remoto de TV e
realizar 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 dos graus de amizade, a partir
de comparativos entre as suas escolhas e as escolhas de cada amigo da sua rede. O que
ocasionaria inclusive uma alteração no conceito da arquitetura, que passaria a ter graus de
influência ao invés de graus de amizades.
Outros trabalhos futuros que podem ser realizados a partir deste trabalho é a integração
com outras redes sociais como Twitter e Facebook, além de uma análise aprofundada
sobre o impacto que a mudança automática de canais associada a relevância dos resultados
causa sobre a perspectiva dos usuários. Para realizar esta análise, podem ser criadas
enquetes e entrevistas com o usuário e desta maneira será possível inferir o impacto na
maneira 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 codification
and transmission specifications for digital broadcasting, part 2 - ginga-ncl: Xml
application language for application coding, Documento de referência, ABNT, São
Paulo, 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 para
suporte a participação colaborativa no cenário da tv digital interativa, Dissertação de
mestrado, Escola Politécnica da Universidade de São Paulo, São Paulo, Brasil.
Andrews, Gregory R. (2000), Foundations of Multithreaded, Parallel, and Distributed
Programming.
ARIB-B-24 (2004), Terrestrial integrated services digital broadcasting, xml-based multi-
media coding scheme, Documento de referência, ARIB Standard b-24 Data Coding
and Transmission Specifications for Digital Broadcasting.
Barrér, Eduardo & Paula Marin Leite (2009), ‘Metodologia de integração entre aplicações
web e aplicações para tv digital’, Simpósio de Excelência em Gestão e Tecnologia .
Beck, Kent & Cynthia Andres (2004), Extreme Programming Explained: Embrace
Change, Addison-Wesley Professional.
Berners-Lee, Timothy John & et al. (1992), The world wide web project, Página na
internet.
URL: http://www.w3.org/History/19921103-hypertext/
hypertext/WWW/TheProject.html
Berscheid, E. & L. A. Peplau (1983), Close relationships, capítulo The emerging science
of 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ágina na 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êmico III.
Dall’oglio, Pablo (2007), PHP Programando com Orientação a Objetos: Inclui Design
Patterns, 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 Systems
III.
Fernandes, Jorge, Guido Lemos & Gledson Silveira (2004), Introdução à televisão digital
interativa: Arquitetura, protocolos, padrões e prática, em ‘Jornada de Atualização
em 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 applications
based on real-time ambient-audio identification, em ‘Proceedings of the 4th Euro
iTV 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 na
internet.
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 Research 13(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 omegabox
media center, em ‘EuroITV’07: Proceedings of the 5th European conference on
Interactive 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 of
computer-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), ‘Os módulos ncl e nclua
dos middleware ginga para aplicações em tv digital interativa’, MOPA Embedded
Systems .
Mendes, Luciano Leonel (2007), ‘Sbtvd - uma visão sobre a tv digital no brasil’, T and C
Amazônia V(12).
62 REFERÊNCIAS BIBLIOGRÁFICAS
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: Social
networks meet your tv experience’, Computers in Entertainment 7.
Moreno, Marcio Ferreira, Luiz Fernando Gomes Soares & Renato Cerqueira (2011), Uma
arquitetura 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 Issues
in Web Usability 101.
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ágina
na 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 de Lacerda (2008), A TV
Digital no Brasil e o Desenvolvimento de Aplicações Interativas para o Middleware
Ginga, 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 Distributed
Application 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 Research 14(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 tv channels based on social
networks with multiple device support, em ‘Proceedings of VECIMS’2011’, IEEE
International 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 Conference
on Digital Libraries’, ACM Press, pp. 312–313.
Smyth, Barry & Paul Cotter (2001), ‘Personalized electronic programme guides’, Artifi-
cial Intelligence Magazine 22(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’, User
Modeling and User-Adapted Interaction 14, 5–36.
Tanenbaum, Andrew S. & Maarten van Steen (2006), Distributed Systems: Principals
and Paradigms, 2a edição, Prentice-Hall International.
TeleMidia (2006), Nested context language, Linguagem de programação, PUC-Rio, Rio
de 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 and
Applications.
Weisband, S.P, S. K. Schneider & T. Connolly (1995), ‘Computer-mediated communica-
tion and social information: status salience and status difference’, Academic Mana-
gement Journal 38(4), 1124–1151.
Wellman, Barry, Janet Salaff, Dimitrina Dimitrova, Laura Garton, Milena Gulia & Caro-
line Haythornthwaite (1996), ‘Computer networks as social networks: Colaborative
work, telework and virtual community’, Annual Reviews of Sociology .
64 REFERÊNCIAS BIBLIOGRÁFICAS