Universidade Federal de Pernambuco Ps-Graduao em Cincia da Computao Centro de Informtica

ProfileTV: Um Sistema de Gerenciamento de Perfis em TVDi

Por Andrino Soares de Souza Colho

Dissertao de Mestrado

Recife, Agosto 2008

ii

iii

Universidade Federal de Pernambuco Ps-Graduao em Cincia da Computao Centro de Informtica

ProfileTV: Um Sistema de Gerenciamento de Perfis em TVDi

Este trabalho foi apresentado ps-graduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para obteno do ttulo de Mestre em Cincia da Computao.

Por Andrino Soares de Souza Colho

Dissertao de Mestrado Orientador: Carlos Andr Guimares Ferraz

iv

Recife, Agosto 2008

Coelho, Andrino S. S. ProfileTV: Um Sistema de Gerenciamento de Perfis em TVDi / Andrino S. S. Coelho. Recife, 2008. Dissertao de Mestrado Universidade Federal de Pernambuco Centro de Informtica Orientador: Ferraz, Carlos A. Guimares

vi

O isolamento s existe no isolamento. Uma vez compartilhado, ele evapora.

- Yalom, I. D.

viii

ix

Aos Meus Pais

xi

Agradecimentos

Aos meus pais, patronos e incentivadores de minha formao. A minha noiva Ddia pela motivao e apoio em todos os momentos. Aos meus compreenso. familiares e amigos, pelo suporte e

Ao meu irmo que jamais tive Jayro, pelo companheirismo, apoio, solues e amizade. Sem voc este trabalho no teria se concretizado. Ao meu orientador e, sempre amigo, Carlos Ferraz, pelos fundamentais e duradouros ensinamentos. Aos meus companheiros dos projetos de TVDi, pelas calorosas e enriquecedoras discusses. Aos meus companheiros, e acima de tudo amigos, do C.E.S.A.R., pelos conhecimentos partilhados. Aos meus mestres do CIN, em especial ao Prof. Nelson Rosa, pelo conhecimento adquirido. E a todos que contriburam, direta ou indiretamente, para a concluso deste trabalho, meus sinceros agradecimentos.

xii

xiii

Resumo

Desde o fim do sculo XX, a televiso vem sendo alvo constante de discusses. A busca incessante por melhoria na qualidade de imagem e de som levou ao surgimento de uma nova mdia mais completa, complexa e abrangente, a chamada TV Digital Interativa. Neste novo cenrio, um telespectador tem acesso a diversos contedos atravs de vrios dispositivos utilizando meios distintos. So tantas as possibilidades de interao que o usurio pode se sentir perdido em meio s configuraes dos aparelhos e dos servios, e simplesmente no usufruir de todas as benesses disponveis. A fim de evitar este problema e facilitar o uso dos aparelhos, faz-se necessrio o uso de tcnicas de HCI e Cincia de Contexto, que permitem uma captura natural das informaes relevantes de uma interao entre telespectador e o dispositivo digital interativo. Esta dissertao prope uma infra-estrutura que permita a criao de servios de personalizao com foco na interao entre telespectadores e dispositos ou servios interativos. Palavras-chave: televiso digital interativa, interao homem mquina, computao ubqua, cincia de contexto.

xiv

xv

Abstract

Since the end of the twentieth century, television has been subject of constant discussion. The incessant search for improvement in quality of picture and sound led to the emergence of a new media more complete, comprehensive and complex, called the Interactive Digital TV. In this new scenario, a viewer has access to several contents through several devices using different means. There are so many opportunities for interaction that the users feel lost in the midst of configuration of devices and services, preventing him simply enjoy all the benefits available. To avoid this problem and simplify the use of devices, it is necessary to use techniques of HCI and Context-Awareness Computing, allowing a capture natural of relevant information for each interaction between viewer and interactive digital devices. This masters dissertation proposes an infrastructure to enable the creation of customized services with a focus on the interaction between viewers and interactive devices/services of TVDi. Keywords: interactive digital television, human computer interaction, ubiquitous computing, context-awareness.

xvi

xvii

Sumrio

1. Captulo...................................................................................................1 Introduo..................................................................................................1 2. Captulo.................................................................................................11 Estado da Arte..........................................................................................11 3. Captulo.................................................................................................29 ProfileTV...................................................................................................29 4. Captulo.................................................................................................57 Implementao........................................................................................57 5. Captulo.................................................................................................94 Experimentos...........................................................................................94 6. Captulo...............................................................................................111 Concluses.............................................................................................111 Referncias............................................................................................115 7. Apndice A..........................................................................................126 Definio do Contexto............................................................................126 Apndice B.............................................................................................130 Protocolo do ProfileTV............................................................................130 B.1. Cdigos de Mensagens....................................................................130 B.2. operaes........................................................................................131 B.2.1. Atualizao...................................................................................131 B.2.2. Busca............................................................................................132 B.2.3. Sincronizao................................................................................132 8. Apndice C..........................................................................................135 Casos de Uso..........................................................................................135 C.1. Atores..............................................................................................135 C.2. Diagramas de Casos de Uso............................................................136 C.2.1. Device...........................................................................................136 C.2.2. Service..........................................................................................136 C.2.3. User..............................................................................................137 C.2.4. Third Party....................................................................................137 C.3. Realizao dos Casos de Uso...........................................................137 Apndice D.............................................................................................150 API..........................................................................................................150 D.1. Communication Package.................................................................150 D.1.1. AbstractCommunicationService....................................................150 D.1.2. AbstractCommunicationWorker....................................................151 D.1.3. CommunicationFactory.................................................................151 D.1.4. SearchWorker...............................................................................152 D.1.5. SynchronizationWorker.................................................................154 D.1.6. UpdateWorker...............................................................................156 D.2. Communication Event Package.......................................................159 xviii

D.2.1. CommunicationEvent...................................................................159 D.2.2. ICommunicationListener...............................................................160 D.3. IO Package.......................................................................................160 D.3.1. AbstractIOService.........................................................................160 D.3.2. BluetoothWorker...........................................................................160 D.3.3. IIOFactory.....................................................................................161 D.3.4. InfraredWorker.............................................................................162 D.3.5. IOFactory......................................................................................162 D.3.6. IOWorker.......................................................................................162 D.3.7. USBWorker...................................................................................163 D.3.8. WifiWorker....................................................................................163 D.4. Logging Package..............................................................................164 D.4.1. AbstractLogger.............................................................................164 D.4.2. Level.............................................................................................165 D.4.3. ProfiletvLogger.............................................................................165 D.5. Persistence Package........................................................................166 D.5.1. PersistenceRegister......................................................................166 D.6. Persistence Key Package.................................................................167 D.6.1. CompositeKey...............................................................................167 D.6.2. Key...............................................................................................167 D.6.3. SingleKey......................................................................................167 ..............................................................................................................168

xix

xx

Lista de Tabelas

Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela

1-1 - Desafios para Infra-estrutura de Personalizao em TVDi.......7 3-2 - Comparao entre solues de TVDi.....................................54 4-3 - Adaptaes dos Dados no Communication............................67 4-4 - Alguns Cdigos do protocolo ProfileTV...................................68 4-5 - Padres Arquiteturais do ProfileTV.........................................84 4-6 - Interfaces do ProfileTV...........................................................89 5-7 - Ambiente de Desenvolvimento e Testes do ProfileTV............94 B-8 Todos os Cdigos do protocolo ProfileTV.............................130 C-9 - Atores do ProfileTV ..............................................................135

xxi

xxii

Lista de Figuras

Figura 2-1 - Planejamento da ANATEL........................................................15 Figura 2-2 - Evoluo dos cenrios para formao do conceito de Computao Ubqua [45]...........................................................................16 Figura 2-3 - Tela de Configurao do MyTV...............................................20 Figura 2-4 Ciclo de adaptao do User Model.........................................22 Figura 2-5 - Informao contextual relevante para o experimento de Thawani et. al. [53]....................................................................................23 Figura 2-6 - Arquitetura proposta por Thawani et. al. [53].........................25 Figura 3-7 - Viso Geral do ProfileTV..........................................................31 Figura 3-8 - Gramtica do ProfileTV...........................................................37 Figura 3-9 - Exemplo de configurao do ProfileTV...................................38 Figura 3-10 - Relacionamento entre Agregador de Perfis e ProfileTV........42 Figura 3-11. Vises do framework 4+1...................................................44 Figura 3-12 - Camadas do ProfileTV...........................................................44 Figura 3-13 Cliente embarcado do ProfileTV...........................................45 Figura 3-14 - Componentes do ProfileTV Server........................................47 Figura 3-15 - Viso Geral do Modelo E-R do ProfileTV................................50 Figura 3-16 - Cenrios Arquiteturais Relevantes........................................51 Figura 3-17 - Exemplo do Protocolo do ProfileTV.......................................55 Figura 4-18 - Arquitetura bsica do MHP....................................................58 Figura 4-19 - Viso de Implementao do ProfileTV Embedded Client Side Middleware.................................................................................................59 Figura 4-20 - Diagrama de classes do ProfileTV Embedded Client Side Middleware Communication.......................................................................60 Figura 4-21 - Diagrama de classes do ProfileTV Embedded Client Side Middleware I/O...........................................................................................61 Figura 4-22 - Diagrama de classes do ProfileTV Embedded Client Side Middleware Logging...................................................................................62 Figura 4-23 - Adio do Profile Capture como Observer de reas do MHP.63 Figura 4-24 - Diagrama de classes do ProfileTV Embedded Client Side Middleware Persistence.............................................................................64 Figura 4-25 - Viso de Implementao do ProfileTV Server.......................65 Figura 4-26 - Excerto do struts-config.xml do ProfileTV Server..................66 Figura 4-27 - Mtodo de acesso a recursos do ProfileTV Server................70 Figura 4-28 - Diagrama de Classes do Parsing...........................................71 Figura 4-29 - Diagrama de Classes do ProfileTV Security System..............72 Figura 4-30 - Adio do elemento Role na gramtica do ProfileTV............73 Figura 4-31 - Exemplo de uso de um Role.................................................74 Figura 4-32 - Configurao do commons-logging.properties.....................75 Figura 4-33 - Configurao do log4j .properties.........................................76 Figura 4-34 - Macro diagrama de classes de Persistence..........................77 xxiii

Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura

4-35 - Assinaturas dos mtodos createProperty.............................79 4-36 Assinatura dos mtodos para criao de Profiles.................80 4-37 - Diagrama de Classes do pacote Util de Persistence.............81 4-38 - Exemplo de ndices de Category..........................................81 4-39 - Diagrama de classes de Report............................................82 4-40 - Diagrama E-R Refinado do ProfileTV Server.........................83 4-41 - Modelo MVC..........................................................................87 4-42 - Alteraes na poltica de segurana do MHP-IRT..................92 4-43 - Elementos Tombstone de traduo......................................92 5-44 - Ambiente Cliente..................................................................95 5-45 - Definio Contextual dos Servios Interativos Testados......95 5-46 - Definio do Contexto para os Experimentos.......................96 5-47 - Estatsticas das Tabelas do Banco........................................98 5-48 - Configurao de Aplicaes do MHP-IRT.............................100 5-49 - Mtodo initXlet....................................................................101 5-50 - Mtodos Inseridos na classe PanMain.................................102 5-51 - Aplicao do Pan-Americano..............................................103 5-52 - Aplicaes de Teste do ProfileTV........................................104 5-53 - Arquivo de propriedades io.properties................................105 5-54 - BlueSoleil com Dispositivo Bluetooth Encontrado...............105 B-55 - Criao de um Profile..........................................................132 B-56 - Sincronizao de Profile......................................................133 C-57 - Casos de Uso disponveis para um Device.........................136 C-58 - Casos de Uso disponveis para um Service.........................136 C-59 - Casos de Uso disponveis para um User.............................137 C-60 - Casos de Uso disponveis para um Third Party...................137

xxiv

Termos e Abreviaturas

ADO API ARIB ATSC CRUD CSV DOM DTD DVB EJB EPG ESG GRAS P HCI HQL HTML HTTP IDE IPTV IRT ISDB ISDTV JAR JDO JSF JSP LDAP MHP MOM MPEG MSO MVC OO ORM OSGI P2p PBTV D PDA

ActiveX Data Objects Abstract Programming Interface Association of Radio Industries and Businesses Advanced Television System Committee Create, Retrieve, Update e Delete Comma-separated values Document Object Model Document Type Definition Dgital Video Broadcast Enterprise Java Beans Eletronic Program Guide Eletronic Service Guide General Responsibility Assignment Software Patterns Human Computer Interaction Hibernate Query Language Hyper Text Markup Language Hyper Text Transfer Protocol Integrated Development Environment Internet Protocol Television Institut fr Rundfunktechnik Integrated Services Digital Broadcasting International System for Digital Tlevision Java Archive Java Data Objects Java Server Faces Java Server Pages Lightweight Directory Access Protocol Multimedia Home Platform Message Oriented Middleware Moving Picture Experts Group Multiple System Operator Model-View-Control Orientao a Objetos Object Relational Mapping Open Service Gateway Initiative Peer-to-peer Plano Bsico de Distribuio de Canais de Televiso Digital Personal Digital Assistent xxv

PVR RBAC RMI RPC SAX SGBD SOAP STB TVDi USB VoD W3C WS XML

Personal Video Recorder Role-Based Access Control Remote Method Invocation Remote Procedure Call Simple API for XML Sistema Gerenciador de Banco de Dados Simple Object Access Protoco Set-top Box Televiso Digital Interativa Universal Serial Bus Video on Demand World Wide Web Consortium Web Services Extensible Markup Language

xxvi

1.Captulo Introduo
Um bom comeo a metade. -Aristteles

1.1. Tema
Desde o fim do sculo XX, a televiso vem sendo alvo constante de discusses [1]. A busca incessante por melhoria na qualidade de imagem e de som levou a digitalizao, tambm adotada em outros meios de comunicao em massa como o rdio. Esta mudana, denominada de TV Digital, representa no apenas a substituio das plataformas analgicas para as digitais, mas tambm o rompimento com os moldes tradicionais de criao e manipulao de contedo. o surgimento de uma nova mdia mais completa, complexa e abrangente que sua antecessora analgica. A Televiso Digital une o tradicional udio e vdeo com

processamento computacional de dados, permitindo aos telespectadores usufrurem de comodidades como multi-programao, guia eletrnico de programas e servios interativos. O antigo usurio passivo, que apenas recebe contedo, perder gradativamente espao para os ativos, que podem interagir diretamente com a programao atravs de enquetes, votaes e jogos. Tudo isto atravs do receptor digital, sem que o telespectador precise mudar seu contexto, seu ambiente comunitrio (normalmente a sala de estar) pela interao pessoal e solitria atravs de pginas web ou ligaes telefnicas. Esta nova mdia surge no momento em que a mobilidade e a portabilidade esto revolucionando o cotidiano das pessoas. Com a confiabilidade da digitalizao do sinal possvel transmitir para dispositivos mveis, como televisores em nibus e trens. Aliando esta 1

capacidade

de

transmisso

com

poder

de

processamento

armazenamento que os atuais celulares e smartphones possuem, permitese tambm a transmisso de televiso para dispositivos portteis. Afinal, atualmente praticamente impossvel pensar a vida sem celulares, notebooks e diversos dispositivos portteis, como pen-drives, mp3 e mp4 players. Para que tudo isto funcione corretamente necessrio padronizar. Entretanto padronizao algo ainda no alcanado em termos de TV Digital, at porque existem duas vertentes, a TV Digital aberta e a fechada ou por assinatura [2]1. O mercado de TV Digital por assinatura tende a continuar sem padronizao, j que cada soluo proprietria, o que torna o modelo vertical: o emissor que adotar o modelo OpenTV [3], por exemplo, compra toda a infra-estrutura de transmisso (moduladores e transmissores) e recepo (set-top boxes e middleware) em conformidade com as normas do modelo. Alm desta caracterstica, a no padronizao utilizada como diferencial competitivo. No mercado aberto de TV Digital existem diversos esforos de padronizao, contudo o que vem acontecendo a formao de blocos (grupos de pases) que aderem um ou outro modelo, sem haver uma harmonizao global. Destes "padres" os mais conhecidos so o americano (ATSC) [4], o europeu (DVB) [5] e o japons (ISDB) [6]. Recentemente, o Brasil passou por processo decisrio de qual modelo adotar. Levou-se em considerao a adequao das normas do modelo s necessidades brasileiras de relevo fsico, transmisso direta para dispositivos pblico alvo e polticas sociais e de mercado. O modelo japons foi adotado com algumas adaptaes em seu sistema de informao de servios, modulao e transmisso para dispositivos mveis e portteis. Alm disso, trocou-se a transmisso de vdeo do mpeg2 [07] para o mpeg4 [08] e o middleware para o nacional Ginga [09] [10] [11] [12] [13] em detrimento do japons ARIB [14].

Ambas as solues, aberta ou fechada, podem ser desenvolvidas para transmisso via satlite, rdio-difuso, cabo ou IP.

A TV Digital aberta tem na gratuitidade sua maior vantagem, mas em contrapartida perde para a homloga por assinatura na acessibilidade e transparncia aos telespectadores e, normalmente, na quantidade de contedo. Independentemente, ambas sofrem cada vez mais a concorrncia da Internet, primeiramente atravs da WebTV [15] [16] [17], que no chegou a vingar e, atualmente atravs de concorridos clientes peer-to-peer. Contudo um ambiente democrtico como a Internet tambm tem suas desvantagens, onde a falta de controle e ambiente no-dedicado so os principais. Pode-se dizer que o presente da Internet, mas o futuro pertence ao IPTV [18]. Assim como as TVs por assinatura, IPTV so redes privadas, controladas, baseadas em IP e dedicadas entrega de contedo digital [19] [20]. Ainda so pouco accessveis, no Brasil nem sequer h legislao sobre a tecnologia, mas a tendncia internacional a popularizao do servio. O principal meio desta disseminao so as redes 3G [21] de telefonia celular, as quais disponibilizam, via IP, servios de vdeo sob demanda (VoD) [22] e tele-chamadas. Para as operadoras, a tecnologia de IPTV permite o lanamento de pacotes de servios como o triple ou quadplay, onde esto juntos a telefonia (fixa e mvel), o acesso Internet o contedo multimdia digital. Neste cenrio, um telespectador tem acesso a diversos contedos atravs de vrios dispositivos utilizando meios distintos. So tantas as possibilidades de interao que o usurio pode se sentir perdido em meio s configuraes dos aparelhos e dos servios, e simplesmente no usufruir de todas as benesses disponveis. A fim de evitar este problema e facilitar o uso dos aparelhos, faz-se necessrio o uso de tcnicas de Human Computer Interaction (HCI) [23], como a cincia de contexto [24]. Para tanto, preciso definir o que relevante para o usurio durante uma interao com um dispositivo/servio de TV Digital, capturar estes dados de forma transparente e no intrusiva, e, finalmente, utilizar estas informaes em prol do prprio usurio. Esta variao de meios de acesso e a diversidade de contedo disponibilizado tem sido alvo de 3

estudos

constantes

[25]

[26]

no

meio

acadmico

empresarial

internacional. Baseado neste cenrio, esta dissertao prope como tema uma infra-estrutura que permita a personalizao da interao de um telespectador com dispositivos e servios de TV Digital Interativa.

1.2. Motivao
Os cenrios descritos na seo anterior demonstram como a Televiso Digital oferece diversos servios de formatos distintos, acessveis das mais variadas formas, desde a tradicional TV por rdio-difuso at as transmisses via IP para dispositivos portteis como celulares e smartphones. Alie a este fato a existncia de bilhes de TVs (ex. no Brasil existem mais TVs que geladeiras [27] [28]) espalhadas mundialmente e do crescente nmero de celulares, e podemos assumir que a transmisso de televiso um dos mais ubquos meios de entrega de contedo informativo. Todavia, a entrega deste contedo ainda feita sem maiores preocupaes com o telespectador, desconsiderando, por exemplo, contextualizao de regionalizao, classes sociais e preferncias individuais de cada telespectador. Assim, pode-se assumir que o usurio de TV refm tanto dos interesses dos provedores de contedos como dos emissores. Alm disso, o formato imperativo e seqencial dos programas, bem como a forma pobre de interao atual, no permite ao telespectador assistir o que quer e quando quer. O mximo de controle que um telespectador dispe atualmente descobrir o que est passando em outros canais em paralelo com o programa que est assistindo (whats on) ou os prximos programas deste ou de outros canais (whats next), e, mesmo esta ao, s possvel se e somente se um Eletronic Program Guide (EPG) estiver disponvel. Estudos, como o de Turner [25], apontam melhorias que podem ser feitas no sistema de TV a fim de permitirem uma personalizao do contedo que recebem, contudo ainda so esforos pontuais, no caso, especificamente EPG. 4

Para ilustrar como este problema atual, imagine um simples cenrio onde um empresrio, viajando a negcios, desloca-se entre pases vizinhos. Ao chegar ao pas de destino e acessar a um programa televisivo dito como universal, o telespectador tem de se contentar com a formatao local do programa, ou ter o trabalho de configurar o dispositivo de recepo com suas preferncias. Aqui, nenhum dado contextual est sendo aproveitado pelo receptor a fim de configurar automaticamente o contedo recebido. Voltemos ao mesmo cenrio, mas adicionemos um receptor que provenha funcionalidade de importao das preferncias do usurio, seja atravs de um dispositivo porttil, seja atravs da comunicao com um servidor remoto. Neste caso, o sistema associa automaticamente as preferncias do usurio (ex. lngua preferida, formatao do contedo, apresentao selecionada de imagens, volume preferencial do udio, intensidade de brilho e, at mesmo, formatao das aplicaes acessveis com o contedo), modificando a apresentao do programa. O telespectador poderia usufruir de todas as suas predilees sem ter de configurar o sistema. O segundo cenrio representa um desejo do telespectador atual, que em breve representar uma necessidade e, em um futuro prximo, cotidiano. Afinal, estamos cada vez mais rodeados de dispositivos computacionais que em sua maioria nos permitem realizar as mais diversas tarefas. O problema ter de se adequar a cada um deles. A televiso, por tudo o que vem sendo apresentado, no pode ser mais um dispositivo complexo cheio de configuraes e customizaes. O telespectador quer apenas lig-la e ver os programas de que mais gosta de uma forma completamente despojada (lean back) [29]. Este cenrio trar ganhos para o telespectador, para o provedor de contedo, que saber em que focar a sua programao, e para as emissoras, que ganharo com publicidade dirigida e personalizada. Desta forma, estudar e dominar tal rea so de suma importncia na construo de um diferencial competitivo. 5

1.3. Problemas e Desafios

Os cenrios descritos nas sees anteriores apresentam situaes complexas de interao entre um telespectador e dispositivos de Televiso Digital Interativa. Estes s so possveis atravs da unio de diversas reas da computao como sistemas distribudos, interao homem-mquina e pervasividade/ubiqidade [30]2. Entretanto a adoo destas reas implica na adio de problemas inerentes a cada uma. Para prover uma infra-estrutura que permita a criao dos servios apresentados nos cenrios, faz-se necessrio a soluo de alguns destes problemas. No que diz respeito aos sistemas distribudos temos a escalabilidade como desafio principal. Afinal, a quantidade de informaes geradas em cada sesso de interao pode at ser pequena, depender do que se determinar como informao relevante, mas ao se aplicar no ambiente de TV, onde existem hoje alguns milhes de televisores, isso s no Brasil, o problema passar ser realmente crucial. Entretanto, a escalabilidade pode ser atenuada dependendo do alcance dado a soluo (i.e. transmisso aberta, por assinatura, IPTV), bem como de onde armazenar os dados relevantes (i.e. porttil, local ou servidor). Esta ltima possibilidade adiciona o problema da capacidade de armazenamento para dispositivos portteis (ex. pen-drives, celulares e smartphones) e locais (ex. set-top boxes e televisores) que normalmente reduzida. Outro problema inerente distribuio a segurana (privacidade e integridade) das informaes de cada telespectador. Se os dados permanecem com o telespectador garantimos uma maior privacidade, mas desde o momento que estes so exportados, para dispositivos portteis ou para um servidor, esta garantia sofre um grande revs. Alm disto, "espetar" um pen-drive em um receptor de TV Digital outro problema grave de segurana, pois o mesmo pode conter vrus e vrios malwares.

Pervasivo significa espalhado, inteiramente difundido, em toda a parte. um neologismo em portugus utilizado como traduo do termo em ingls Pervasive.

A necessidade de se capturar dados de forma no intrusiva para permitir a personalizao quanto a contedo e sua apresentao outro problema, este da rea de HCI. Como adquirir estes dados sem que o telespectador tenha de gastar horas configurando o sistema, ou tenha seu entretenimento interrompido por questes que, na maioria das vezes, no lhe fazem o menor sentido. Determinar quais so os dados relevantes a serem capturados em cada interao um problema de cincia de contexto, subrea da pervasividade. O problema que so diferentes servios em diferentes dispositivos com telespectadores distintos. Estereotipar ou generalizar todo o tipo de interao impraticvel. Desta forma, necessrio prover mecanismos que permitam a atualizao de uma forma dinmica do que relevante para o sistema, para o telespectador, para o dispositivo e, por fim, para o servio interativo. Dentre todos os problemas discutidos, esta dissertao enfatiza alguns durante os captulos. Estes problemas encontram-se destacados com um (*) na Tabela 1 -1.
Tabela 1-1 - Desafios para Infra-estrutura de Personalizao em TVDi
Ca te goria Proble m a Sub -proble m a Ba ixac a pa c ida dede Uso dedispositivos port te is a rma ze na me nto* Exporta o/ Importa o deda dos* Ca pturadainte ra o Tra nspa r nc ianac a pturados da dos* Usu rio/ Dispositivo/ Se rvi o De fini o do Conte xto* Ci nc iadeConte xto Ide ntific a o do usu rio Pe rsona liza o do c onte do Pe rsona liza o daa pre se nta o* Inte rfa c eHome m-M quina Re c ome nda o dec onte do re la c iona do Esc a la bilida dee m fa c ea qua ntida dedeusu rios, Custos ope ra c iona is deumainfra dispositivos ese rvi os e struturase rvidora * ofe re c idos Priva c ida dedos da dos deum Se gura n a usu rio e xporta dos pa rao se rvidor

Co m p uta o Pe rv a s iv a

HCI

Sis te m a s Dis itrib ud o s

Desafios estudados neste trabalho.

1.4. Soluo
Este trabalho apresenta o ProfileTV, um sistema cliente-servidor que prov infra-estrutura para que aplicaes de personalizao da interao de telespectadores com dispositivos e servios de Televiso Digital Interativa. O objetivo do sistema permitir a (1) definio e (2) atualizao do contexto, ou seja, das informaes relevantes a cada interao entre telespectador e servio interativo, (3) capturar estes dados de forma transparente, (4) fornecer uma API para que servios interativos possam (5) adicionar dados relevantes ao seu contexto especfico, bem como (6) buscar e (7) alterar dados pblicos do telespectador. Alm destas funcionalidades, o ProfileTV tem como objetivo secundrios a exportao e importao das preferncias do telespectador, denominadas por este trabalho de Profile, para dispositivos portteis. A construo de um sistema como o ProfileTV requer o estudo e domnio das reas discutidas na seo anterior (1.3), bem como das aplicaes e servios que executaro sobre esta infra-estrutura. O modelo de distribuio adotado, cliente-servidor, possui muitas solues clssicas conhecidas, mas nem todas podero ser aplicadas, por exemplo, as solues padres de escalabilidade s funcionam para redes de TV por assinatura, independentemente da transmisso. Apesar de relacionados, no o foco de este trabalho discutir as tcnicas de criao e atualizao de um User Modeling [31], tcnicas de inferncias, tcnicas de recomendao e adaptao de contedo. Estas tcnicas podem ser utilizadas pelos servios que venham a executar sobre o sistema, mais precisamente sobre a base de dados capturados/adquiridos.

1.5. Estrutura do Documento

O copo deste trabalho dividido em 6 (seis) captulos. Aps esta introduo o Captulo 2 (dois) apresenta o estado da arte de televiso digital e cincia de contexto, procurando relacionar as duas reas, Ainda 8

neste captulo sero apresentados os trabalhos relacionados a esta dissertao, enfatizando trabalhos que utilizariam o sistema aqui proposto, ProfileTV, como base para sua execuo. O Captulo 3 (trs) apresenta o ProfileTV segundo a tcnica descrita por Kruchten [32]. Neste captulo so apresentadas as funcionalidades, bem com uma viso lgica do sistema e de seu modelo de distribuio. O Captulo 4 (quatro) aborda o desenvolvimento de do sistema Atem-se e discute os desafios definio da dos implementao referncia. tambm na

frameworks, bibliotecas e padres arquiteturais utilizados, apresentando, sempre que possvel, uma discusso acerca do processo decisrio de cada item arquitetural utilizado. Os experimentos realizados a caracterizar a viabilidade do sistema ProfileTV so apresentados no Captulo 5 (cinco). Por fim, as concluses e os trabalhos so discutidos no Captulo 6 (seis).

10

2.Captulo Estado da Arte

"Se enxerguei mais longe foi porque me apoiei nos ombros de gigantes - Sir. Isaac Newton

Este Captulo apresenta o estado da arte das reas envolvidas nesta dissertao, bem como vrios trabalhos relacionados ao tema deste trabalho: Televiso Digital Interativa, Pervasividade e Cincia de Contexto.

2.1. Introduo
A Televiso Digital Interativa uma rea de muita pesquisa, discusses acaloradas e de vrias propostas, contudo de poucas e efetivas aes. O cenrio mundial ainda de indefinio quanto padronizao da tecnologia de transmisso aberta, porm muito determinado no mercado de cabos e televiso por assinatura, onde o padro OpenTV detm cerca de 70% [33] do mercado. Questes sobre a interatividade atravs da TV e o uso de dispositivos portteis, como extenso ou, at mesmo, substituio desta interatividade, comeam a ser levantadas [25]. O IPTV surge como um novo meio de transmisso, trazendo muito mais funcionalidades e tambm mais algumas questes, como: "por que o telespectador dever gastar uma pequena fortuna e mudar para IPTV?". Ao mesmo tempo, estamos presenciando o surgimento da "calm technology" [34], onde a computao encontra-se espalhada em diversos dispositivos, nos envolvendo e nos tornando cada vez mais dependentes. Dispositivos portteis, como celulares e smartphones, dispem de diversos servios e se tornam pontos de convergncia de mdias. A quantidade de informao disponvel tanta, que cada vez mais 11

imprescindvel a personalizao e adaptao do contedo e de seu formato. Na onda destas pesquisas envolvendo pervasividade, reas como a captura de informao contextual, interfaces naturais e cincia de contexto vieram tona. Sistemas de recomendao, baseados nestas trs reas, j so largamente utilizados em lojas virtuais como a Amazon e o Submarino, e recentes pesquisas apresentam arquiteturas, metodologias e servios relacionados TV Digital Interativa. neste cenrio turbulento, de diversas frentes de pesquisa, que se insere o ProfileTV. Sistema que procura fornecer infra-estrutura para o desenvolvimento de servios e aplicaes que permeiam todas estas reas. O objetivo que um telespectador de TV Digital Interativa munido de um dispositivo porttil poder carregar consigo dados contextuais para onde quer que v. Dados estes, adquiridos atravs de um sistema de captura, que serviro como entrada para complexos sistemas de recomendao, a fim de prover a personalizao e adaptao do contedo televisivo para o telespectador.

2.2. Televiso Digital Interativa

A Televiso Digital Interativa j realidade h muitos anos, inclusive no Brasil, atravs das operadoras de televiso a cabo e por assinatura. O que ainda est em discusso a padronizao da forma aberta de transmisso. A disputa est entre trs modelos: o americano ATSC [04], o europeu DVB [05] e o japons ISDB [06]. Na Amrica Latina, o Brasil adotou o ISDB, com algumas alteraes em sua estrutura (vide seo 2.2.1), j o Uruguai adotou o DVB em meados de 2007 e o restante dos pases ainda se encontram em estudos e/ou negociaes. A tendncia adotarem o modelo brasileiro a fim de aumentar a exportao e importao de programas entre os pases. Entretanto, a briga pela padronizao est comeando a perder terreno para outras discusses acerca de TV Digital Interativa, como o IPTV [35] [36]. Esta uma tecnologia cada vez mais forte e presente, 12

principalmente com o advento de 3G, que trouxe a alta velocidade no trfego de dados para os aparelhos celulares. Contudo, no apenas por meio de 3G que o IPTV est se popularizando. Na realidade, tudo comeou na Internet, com a chamada WebTV [15] [16] [17], que no chegou a vingar. Porm serviu como base para vrias pesquisas em IPTV que mais a frente se tornariam produtos, como o caso do Joost [37], um servio de TV pela Internet desenvolvido pelo sueco Niklas Nennstrm e o dinamarqus Janus Friis, criadores do Skype e KaZaA. O grande destaque do Joost a forma de distribuio de contedo que se d por P2P (peer-topeer) permitindo que o "sinal" chegue ao usurio de forma rpida e com boa qualidade. Outro bom exemplo de pesquisa em IPTV a parceria da Microsoft com a Alcatel-Lucent. As duas construram uma infra-estrutura fechada de IPTV e a comercializam como TV por assinatura em vrios pases da Europa. Para se ter acesso ao contedo o usurio compra um set-top box da Alcatel-Lucent, que ainda assina a infra-estrutura de cabos, modems e servidores - muitos da Cisco System. A Microsoft entra com o middleware, softwares de suporte e servidores de Vdeo sob Demanda (VoD). O grande atrativo so os Personal Video Recorders (PVR), que permitem ao usurio gravarem em seus receptores qualquer contedo acessvel. Assim como a parceria Alcatel-Lucent e Microsoft, existem outros grandes players apostando no mercado de IPTV, como AT&T, Time Warner e Disney. Na rea de televiso a cabo a evoluo marcada pelo poderio dos investimentos privados. Existem diversas solues para este mercado com um destaque para a OpenTV, que possui mais de 100 milhes de dispositivos ativados com sua tecnologia [03]. A empresa dispe de diversos produtos desde dispositivos de recepo, a engenhos de propaganda dirigida, interatividade e headend. O campo da interatividade, na televiso por assinatura, muito abrangente. Pode-se criar aplicaes em vrios tipos de linguagens, dependendo do ambiente da operadora. Essa caracterstica traz o 13

problema de porting, existente em celulares, para o mundo de TV Digital. Afinal, se um contrato for firmado com um provedor de contedo que tenha suas informaes disponibilizadas atravs de trs operadoras diferentes, utilizando solues distintas, ser necessrio portar a aplicao interativa para as trs plataformas. Desta forma, um ramo que tem aumentado consideravelmente o de ferramentas de apoio ao desenvolvimento de servios interativos, seja ela votada para designer ou desenvolvedores. A TV Digital Interativa um meio em constante ebulio, abrangente e de muitas vertentes. Novos servios surgem todos os dias. Modelos de negcios so montados e reestruturados constantemente. As pesquisas no param, principalmente na rea de convergncia de mdias. um ramo atual e de vanguarda, o que aumenta a sua relevncia como um dos temas desta dissertao.

2.2.1.

Cenrio de TV Digital Aberta Brasileiro

No Brasil a discusso sobre Televiso Digital Interativa vem desde 1999, quando foi dado incio as avaliaes tcnicas e econmicas. Desde ento aconteceram alguns marcos importantes: Em novembro de 2003 o governo criou por decreto o Sistema

Brasileiro de Televiso Digital (SBTVD) e ainda trs comits: Comit de Desenvolvimento, Grupo Gestor e Grupo Consultivo. Os trs ficaram responsveis por coordenar os estudos que indicariam o modelo que seria adotado no pas; Em junho de 2005 o Plano Bsico de Distribuio de Canais de

Televiso Digital (PBTVD) foi aprovado; Em junho de 2006 foi oficializada a adoo do modelo japons

com modificaes na codificao de vdeo, que passaria a ser o H.264/MPEG-4 AVC em vez do MPEG-2 utilizado no Japo;

14

No mesmo ano foi decidido que seria adotado o middleware

brasileiro Ginga [09] [10] [11] [12] [13]. Este ser o responsvel pela interatividade; Em 02 de dezembro de 2007 foi dado incio s transmisses

abertas do sinal digital. A primeira cidade a receber o sinal digital foi So Paulo. A Agncia Nacional de Telecomunicaes (Anatel) esteve sempre a frente nos estudos e decises sobre o formato de transmisso digital no Brasil. E definiu que a transio total do analgico para o digital deve ocorrer em no mximo 10 anos. Alm disso, definiu tambm que em no mximo 15 anos todas as transmisses digitais devem ser em altadefinio (HDTV), vide Figura 2 -1.

Figura 2-1 - Planejamento da ANATEL

Recentemente foram colocadas em consultoria pblica as normas referentes ao middleware Ginga. Este componente do SBTVD uma soluo tupiniquim baseada na norma ITU-T J200 [38], ITU-T J201 [39] e ITU-T J202 [40].

2.3. Computao Pervasiva

Segundo Weiser, estamos vivendo a era da ubiqidade, onde os computadores esto em todos os lugares, inseridos intrinsecamente ao 15

cotidiano humano [34]. Neste artigo, Weiser chama ateno para o surgimento da calm technology, baseada no conceito de que a interao homem-mquina tem de ser algo natural, intuitivo e simples, ou seja, invisvel. As idias de Weiser desencadearam vrias pesquisas relacionadas ubiqidade, como a de realidade aumentada [41], interfaces tangveis [42], wereable computers [43], edificaes cooperativas e inteligentes [44], todas discutidas em [45]. Todas focadas na interao homemmquina, entretanto dando maior nfase na forma de representao das informaes relevantes e na cincia de que estas informaes realmente existem no ambiente, ou seja, cincia de contexto.

Figura 2-2 - Evoluo dos cenrios para formao do conceito de Computao Ubqua [45]

As primeiras aplicaes cientes de contexto elegeram a mobilidade e a localizao no ambiente como foco principal. Este o caso do CyberGuide [46], no qual usurios so guiados dentro de um museu a partir de informaes adquiridas atravs de um Personal Digital Assistent (PDA). Outros exemplos desta leva de aplicaes so o HotTown [47] e o Active Badge [48]. A partir destes estudos, muitas outras pesquisas tm sido feitas (ex. aplicao de ajuda a cegos, o VEye [49]) e, por conseguinte, foram criados congressos especficos para a discusso de ubiqidade, como a International Conference of Ubiquitous Computing (Ubicomp). 16

2.3.1.
Em 91,

Cincia de Contexto Weiser [30] estabeleceu que os conceitos para Computao de forma

Ubqua/Pervasiva. Seu artigo descreve um cenrio repleto de pequenos dispositivos computacionais provem informaes ininterrupta e transparente para quaisquer pessoas que estivessem imersas no cenrio. Weiser define, tambm, trs caractersticas bsicas para ubiqidade: Interfaces naturais: a interao homem-mquina deve ser a

menos traumtica possvel. Para tanto as interfaces tm de serem reestruturadas ou simplesmente deixar de existir, ex. sistemas que reconhecem comandos de voz. Captura automtica de experincias reais: massas de

informaes armazenadas em praticamente todos os lugares. Estas informaes podem e devem ser acessadas por pessoas em trnsito. A idia prover um tipo de memria auxiliar, por exemplo, anotaes de outros visitantes em quadros de museus como os propostos no CyberGuide [46]. Cincia de contexto: tenta explicar como adquirir estas

informaes disponveis no ambiente, como se adaptar as condies locais, com inferir o desejo do usurio. Aplicaes cientes de contexto permitem que os usurios usufruam das informaes dispostas no ambiente naturalmente. Para Weiser, qualquer atividade est envolta e influenciada por um contexto. Essa mxima serve para todas as interaes homem-homem como, por exemplo: o dilogo tem seu significado alterado pelos gestos dos participantes, ou seja, o contexto que a comunicao est inserida modifica o seu significado. A interao homem-mquina mais limitada do que a tradicional homem-homem, j que as mquinas no so capazes de reconhecer o contexto no qual esto inseridas. A cincia de contexto tem como objetivo tornar mais rica esta interao entre homens e mquinas. Portanto foca 17

seus esforos na criao de um mecanismo que permita o acesso e interpretao do contexto pelas mquinas. O termo contexto tem ampla definio, sendo comum cada pesquisador ter a sua prpria definio. Para computao, h, ainda, um passo anterior que a adaptao do significado geral do termo realidade computacional. Dey [50] foi um dos primeiros a realizar esta tarefa, definindo contexto como: ... qualquer informao que pode ser utilizada para caracterizar a situao de uma entidade. Uma entidade uma pessoa, lugar, ou objeto que considerado relevante para a interao entre um usurio e uma aplicao, incluindo o usurio e a aplicao em si. Essa definio at hoje uma das mais usadas, pois insere o conceito de relevncia de informaes. Pode-se a partir desta, definir, de uma maneira bem geral que contexto toda e qualquer informao relevante interao entre homem-mquina e at mesmo entre mquinamquina. de suma importncia que desenvolvedores de aplicaes cientes de contexto entendam esta definio, para que saibam discernir entre o que contexto e o que no .

2.4. Trabalhos Relacionados

Atualmente pode-se encontrar, dentre as pesquisas de cincia de contexto, assuntos ligados a TVD, como em [51]. Neste trabalho, Goularte explicita uma forma de criao de contedo televisivo de carter personalizado e rico. Seu estudo baseado na descrio de programas apresentado pelo TV Anytime [52]. Tomando com referncia o trabalho de Goularte, Thawani et. al. [53] propuseram um ambiente para se inserir comerciais personalizados na programao de uma emissora, discutido mais detalhadamente na subseo 2.4.4. Vrios outros trabalhos relacionados com Televiso Digital Interativa e Cincia de Contexto tm surgido no meio acadmico. o caso de [54], onde apresentada uma infra-estrutura Open Service Gateway Initiative 18

(OSGI) para construo e prototipao rpida de servios multimdia baseados em contexto para TVD, alm do middleware Context-Aware Multimedia Middleware (CMM) que d suporte a filtragem, recomendao e adaptao de contedo. Existem vrias pesquisas tratando da interseo entre Televiso Digital Interativa e Computao Pervasiva/Cincia de Contexto. Nas prximas subsees so discutidas as que possuem maior relacionamento com o ProfileTV

2.4.1.

MyTV

Correia e Peres apresentam em [55] um prottipo de servio de personalizao em ambiente de TV Digital Interativa, denominado de MyTV. O servio foi desenvolvido sobre a plataforma comercial da TV Cabo, uma operadora de telecomunicaes de Portugal, tendo como principal objetivo avaliar o desejo dos usurios por servios personalizados. Em seu trabalho, Correia e Peres tambm atentam para a existncia de vrias formas de personalizao, desde as completamente manuais, onde o telespectador precisa realizar toda uma configurao inicial, at as totalmente automticas, onde no h nenhuma entrada explcita do telespectador, o sistema captura todos os dados relevantes. Entretanto, apesar de apontarem que a melhor configurao seria um meio termo entre os extremos, decidiram por utilizar no prottipo o primeiro tipo de personalizao, completamente manual. O interessante desta escolha que mesmo com a necessidade de uma configurao inicial, os usurios questionados avaliaram positivamente o servio, que nada mais era que um browser para TV. A Figura servio MyTV. 2 -3 mostra a tela de configurao do

19

Figura 2-3 - Tela de Configurao do MyTV

um trabalho introdutrio que os prprios autores definem como base para experimentos futuros. Desta forma, no h aluso direta aos problemas de armazenamento dos dados preferenciais dos usurios no set-top box, da identificao dos usurios, escalabilidade da soluo, da tcnica de personalizao adotada, nem de detalhes da infra-estrutura criada para o desenvolvimento do prottipo. A principal contribuio deste trabalho a apresentao de alguns conceitos interessantes, dos quais muitos foram utilizados nesta dissertao. Um destes a classificao dos tipos de personalizao em duas categorias distintas, apresentao e contedo. A primeira remete aos aspectos da interface grfica como cores e posio dos elementos grficos. J a segunda aponta para a gerao e entrega de contedos do interesse do usurio, ou seja, se o usurio gosta de esportes, deve receber notcias e propagandas associadas. O prottipo apresentado ainda no inclui a segunda categoria de personalizao. Outro ponto importante abordado no trabalho de Correia e Peres o uso de interfaces amigas do usurio (user friendly), que para a rea de televiso devem ser "... simples de usar, simples de aprender, simples de entender, simples para prevenir e evitar erros, simples de manter e simples de se compartilhar em grupo".

2.4.2.

Dispersing the Interactivity

Turner e Cairns apresentam em seu trabalho [25] como dispositivos portteis podem expandir as funcionalidades de um guia eletrnico de 20

programao (EPG). A grande contribuio para esta dissertao o de constatar o grau de ubiqidade que dispositivos portteis alcanaram, no caso do trabalho um Palm. O fato dos dispositivos portteis serem atualmente quase que parte do corpo de um ser humano [56] [57], permite utiliz-los como extenses de servios, que no caso do trabalho de Turner e Cairns um EPG. J para esta dissertao o dispositivo porttil atuar como uma extenso do sistema de armazenamento das preferncias do telespectador. Alm desta contribuio, o trabalho descreve vrios problemas na criao de servios interessantes para os telespectadores, discute o problema da passividade dos usurios e do jeito relaxado (lean back) a que assistem TV, em vez do jeito ereto e atento empregado na interao com um PC (forward style) [29]. No estudo de caso apresentado, chama a ateno o desejo que os usurios apresentam em acessar informaes de sua predileo ou indicadas por um usurio conhecido ou respeitado, sendo esta a caracterstica mais til apontada pelos usurios que participaram da pesquisa. Por se tratar de um estudo qualitativo, a pesquisa foi realizada apenas com 12 usurios, e com foco em usabilidade, problemas tratados no ProfileTV (ex. escalabilidade, armazenamento de dados) no foram evidenciados.

2.4.3.

A Methodology of Personalized Advertisements

Lekakos e Giaglis construram uma metodologia baseada em esteretipos para a entrega de propaganda personalizada em ambiente de TV Digital Interativa [58]. um trabalho terico que define um processo atravs de um misto de coleta de dados com usurios, minerao de dados e experincia de experts da rea. O objetivo do trabalho fornecer subsdios s agncias de publicidade a descobrirem quais propagandas surtem melhor efeito em que grupos de usurios. A relevncia deste trabalho para o ProfileTV a constatao do desejo dos usurios em receber contedo cada vez mais personalizados. O 21

estudo apresenta a insatisfao dos telespectadores com o tipo de propaganda enviada pelas transmissoras. Esses dois fatos atestam a relevncia desta dissertao. Em seu trabalho, Lekakos e Giaglis descrevem os requisitos de um sistema adaptativo s necessidades do usurio: criao e atualizao de um user model (profile) e adaptao de apresentao e contedo. A Figura 2 -4 apresenta o ciclo proposto de adaptao de contedo e atualizao do user model. O ProfileTV atua apenas na coleta dos dados e no fornecimento de funes que permitem o armazenamento de dados que o sistema no responsvel, ou no pode coletar. Todas as outras etapas, ficam a cargo de servios de inferncia (ex. collaborative e content-based filtering [31]) que no so contemplados pelo ProfileTV, estando fora do escopo desta dissertao.

Figura 2-4 Ciclo de adaptao do User Model

Lekakos e Giaglis assumem que os telespectadores escolhem o seu perfil no incio do experimento, ou seja, h a necessidade de uma configurao inicial. Isto evidencia que o problema da total transparncia (i.e. interface completamente natural e invisvel proposto por Weiser) ainda no est completamente resolvido. Para este problema, o ProfileTV apresenta uma proposta de soluo atravs do uso de dispositivos portteis, mas mesmo essa ainda possui falhas, que podem levar a uma interao explcita do usurio com o sistema.

22

2.4.4.

Context Aware Personalized Ad Insertion

Thawani et. al. baseiam-se em cincia de contexto para propor uma arquitetura para seleo e insero em tempo real de propagandas na transmisso de contedo televisivo [53]. Assumem como informaes contextuais o perfil atual e histrico de cada telespectador. Este trabalho busca solues para o mercado de publicidade e marketing, ameaados pelos servios de Personal Video Recorder (PVR) e Video on Demand (VoD), os quais permitem que os telespectadores "saltem" as propagandas indesejveis. A soluo proposta a adaptao dos comerciais baseados nas preferncias e circunstncias de cada usurio. Para alcanarem este objetivo, Thawani et. al. apresentam quais as informaes que consideram relevantes para promover a insero de comerciais. Classificam-nas em localizao (sala, cozinha ou sala de entretenimento), identificao (usurio, dispositivo, contedo e evento), atividade (atual e histrico dos usurios e dispositivos) e tempo (perodos do dia e da semana). A figura um excerto do trabalho de Thawani et. al.

Figura 2-5 - Informao contextual relevante para o experimento de Thawani et. al. [53]

A arquitetura proposta composta por quatro subsistemas, Context Derivation (Cod), Context-aware Ad Selection and Insertion (CaSI), User Identification (UId), e Bulk Ad Retrieval (BAR). Em sua descrio, os autores apresentam 3 formas para insero das propagandas, considerando a transmisso utilizada na ndia (pas onde foi realizado o

23

estudo), transmisso de contedo para um MSO e destes para a casa dos telespectadores, normalmente via cabo: Insero de propaganda na gerao do contedo; Insero de propaganda no MSO via Internet ou rede IP; Distribuio das propagandas diretamente para casa dos

telespectadores. Estas seriam armazenadas nos set-top boxes, tambm responsveis por inserir as propagandas na grade de programao. A arquitetura apresentada na Figura 2 -6 levanta algumas

consideraes acerca das duas ltimas opes, as quais os autores consideram de "the most appropriate ads". Em ambos os casos, as mudanas necessrias nas atuais infra-estruturas de transmisso e recepo sero bastante custosas. Infelizmente, o trabalho no discute como ser feita a multiplexao de contedo advindo de mdias diferentes (ex. rdio-difuso e Internet ou redes IP), nem a complexidade e custo de se embarcar em um set-top box o subsistema UId, por exemplo. A arquitetura ainda se apia em sensores para identificar a localizao dos usurios dentro da casa e em um contexto razoavelmente complexo de se capturar, manter e atualizar. Todas estas brechas evidenciam o carter de pesquisa da proposta, deixando de lado problemas reais em um ambiente comercial.

24

Figura 2-6 - Arquitetura proposta por Thawani et. al. [53]

As idias e discusses levantadas neste trabalho serviram de base para criao de alguns subcomponentes do ProfileTV, como o de captura de informao relevante, alm de alertar para os problemas de escalabilidade e armazenamento de informaes em dispositivos de baixo poder de processamento computacional, como os set-top boxes. Serviu ainda como incentivador da exportao dos dados relevantes para dispositivos portteis e da necessidade de se manter alguns dados em servidores para posterior processamento.

2.4.5.

Recommendation

Dois trabalhos similares descrevem sistemas de recomendao para televiso digital interativa [59] [60]. No primeiro, Ardissono et. al. apresentam uma forma personalizada de recomendao de programas de TV. Eles propem o Personal Program Guide (PPG), um EPG que recomenda programas do interesse de usurios previamente cadastrados no sistema. No PPG, todos os dados relevantes so capturados, armazenados e inferidos no set-top box. No foram levantados os problemas de capacidade de processamento e armazenamento de dados nestes 25

dispositivos. A implementao de referncia foi feita para PC. A deciso de excluir um servidor, que permitiria o uso de tcnicas mais aprimoradas de IA como collaborative e content based filtering [31], foi tomada por se acreditar que informaes advindas da observao direta da interao do telespectador com o dispositivo seriam perdidas. J em [60], Dai e Cohen propuseram um sistema dinmico para personalizao de recomendao para televiso digital interativa. O dinamismo foi apresentado como inovao e grande motivao do trabalho porque "... nas mquinas locais, h um nmero fixo de possveis perfis de telespectadores desatualizados...". Desta forma, Dai e Cohen colocam seu sistema de recomendao no servidor, onde mantm centralizadas as informaes de cada telespectador, redistribuindo-as apenas para os ativos. Contudo, no so discutidos os problemas de escalabilidade da soluo, nem se para transmisso de televiso por rede aberta ou por assinatura. Ponto a se ressaltar nestes trabalhos a infra-estrutura comum s propostas. Em ambas, h a necessidade de captura e armazenamento de informaes para uso posterior no sistema de recomendao, esteja no cliente ou no servidor. Prover esta infra-estrutura a proposta do ProfileTV, que alm destas caractersticas tambm d suporte a definio dinmica das informaes consideradas relevantes, ou seja, suporte a definio de contexto.

2.5. Consideraes
A Televiso Digital Interativa um assunto abrangente, com muitas vertentes como foi apresentado neste Captulo. A rea possui diversas classificaes, como modelo de negcio aberto ou fechado, ou ainda, modelo de transmisso por satlite, cabo, rdio-difuso ou via IP. Vrias pesquisas esto sendo feitas, desde melhorias nas atuais formas de transmisso, como na acessibilidade a recursos e simplicidade de uso dos servios.

26

As duas ltimas pesquisas levantam vrios problemas e desafios a serem tratados na Televiso Digital Interativa, como a personalizao de contedo, que se constitui em parte do tema desta dissertao. Por conseguinte, vrios trabalhos relacionados so apresentados e discutidos. Alguns voltados para rea de Inteligncia Artificial outros para a Pervasividade, dando uma maior nfase a Cincia de Contexto. Estes trabalhos so sempre confrontados com o ProfileTV, sistema proposto por esta dissertao e que ser apresentado no prximo captulo.

27

28

3.Captulo ProfileTV
"O nico lugar aonde o sucesso vem antes do trabalho no dicionrio. - Albert Einstein

Este captulo introduz o ProfileTV, apresentando um cenrio hipottico, onde uma personagem fictcia tem sua rotina facilitada graas ao bom uso do sistema. A partir deste cenrio so evidenciadas as funcionalidades, a arquitetura, a distribuio e os principais desafios do ProfileTV, bem como as decises de projeto e paralelos com solues relacionadas ou similares.

3.1. Introduo
O ProfileTV um sistema distribudo cliente-servidor que prov infraestrutura para desenvolvimento de servios de personalizao e recomendao de contedo de televiso. Atravs do sistema, aplicaes para TVDi tm acesso s preferncias do usurio quanto a, por exemplo: (1) disposio da aplicao na tela; (2) informaes mais acessadas; (3) tempo gasto em sua utilizao; e, alm destes, (4) preferncias de contedo televisivo e (5) configurao de aspectos tcnicos da TV ou do STB. Como sistema distribudo, o ProfileTV assemelha-se, em estrutura e acessibilidade, a sistemas de informao web, sofrendo restries e problemas similares. Alguns destes problemas so clssicos em sistemas distribudos (ex. compartilhamento de recurso, abertura/flexibilidade, balanceamento de carga, escalabilidade, tolerncia a falhas e transparncia) [61] havendo diversas solues j propostas. O ProfileTV

29

baseia-se em clusterizao com o objetivo de resolver tais problemas, vide Figura 3 -7. Nesta macro viso do sistema esto assinalados: proxy(s) de acesso (ProfileTV Proxy): responsvel (is) pela

aplicao da poltica de acesso ao sistema3, o qual pode ser efetuado atravs de dispositivos integrantes da "rede" do ProfileTV e da Internet; gerenciador de conexes (Connection Manager):

responsvel pelo balanceamento de carga; ativao de servidores de backup na queda/inacessibilidade de um servidor ativo; controle de sesso e de acesso. Este ltimo focado na autenticao de usurios, dispositivos e servios, j que atravs do par (meio de acesso, autenticao) que o sistema autoriza o acesso a determinadas operaes do sistema; servidores de aplicao e gestores de dados redundantes

(ProfileTV Cluster): responsveis pela resposta s requisies dos clientes, filtragem de informaes, armazenamento e acesso a dados.

Esta poltica diz respeito aplicao de firewall. NAT e outras polticas de rede.

30

Figura 3-7 - Viso Geral do ProfileTV

O objetivo do ProfileTV armazenar toda informao relevante4 do usurio e, da interao deste com dispositivos e servios. Estes dados podem ser armazenados em (1) dispositivos portteis (ex. celulares, smartphones, pen-drives), (2) no dispositivo onde ocorre uma interao (ex. aparelho televisor, set-top box, smartphone) e, por fim, (3) no servidor do sistema, desde que aspectos de segurana, como privacidade e integridade sejam respeitados. Os dados armazenados no servidor podem ainda ser configurados como pblicos ou privados5, permitindo, ou no, que os mesmos sejam acessados por terceiros para diversas finalidades (ex. entrega de contedo personalizado, marketing direto). Como padro, apenas os dados pblicos so enviados ao servidor atravs dos dispositivos e servios. Os dados privados so sempre mantidos localmente e/ou em dispositivos portteis do telespectador. Se por ventura, um telespectador
4 5

Determinada pelo administrador do ProfileTV. Determinados pelo administrador do ProfileTV.

31

quiser exportar estes dados para o servidor, mantendo-os como privados, precisar entrar em contato com a administrao do ProfileTV para adquirir uma conta individual, que lhe permitir esta ao bem como gerenciar alguns de seus dados pblicos (ex. gerenciar os perfis social ou profissional).

3.2. Cenrios de Uso

O ProfileTV um sistema que atende aos interesses tanto do usurio final (i.e. telespectador), como de quem prov o servio (i.e provedor de contedo). Esta afirmao pode ser claramente atestada nos cenrios descritos a seguir:

3.2.1.

Primeiro acesso

Neste cenrio, o telespectador utilizar o ProfileTV pela primeira vez. O telespectador realizar poucas configuraes de sua preferncia e assistir a programao de que mais gosta. "(1) Um telespectador, na sala de seu apartamento, liga seu aparelho de televiso digital interativo e (2) ajusta as configuraes de cor, brilho, matiz e udio. Logo em seguida, (3) sintoniza um canal de esportes, permanecendo sintonizado neste canal por toda apresentao de um programa de (4) esportes radicais, o que dura aproximadamente 2h. Ao trmino do programa, o telespectador (5) muda para um canal de variedades, pois ao consultar a hora percebeu que o jornal da noite estava para comear. O telespectador mantm-se sintonizado no telejornal, e

percebe que em determinado momento surge um cone no canto superior direito da tela. Est disponvel uma aplicao interativa com informaes adicionais sobre as matrias apresentadas. O telespectador (6) inicia a aplicao, mas a mesma se estende por todo o vdeo, impedindo-o de ver as imagens. Ele ento (7) configura a aplicao para trabalhar 32

com o vdeo em resize (i.e. o vdeo fica visvel em uma parte pequena da tela e aplicao sobrepe-se pelo restante) e navega entre as informaes disponveis, desprendendo um tempo maior nas (8) notcias culturais. Antes do trmino do jornal, o telespectador resolve (9) desligar o aparelho, pois uma das notcias que leu na aplicao, alertou-o para o horrio da pea teatral que assistir hoje e, o mesmo j se encontra um tanto atrasado..." Durante esta interao, o ProfileTV capturou vrias informaes que j estaro disponveis, para servios e dispositivos de TVDi, na prxima vez em que o telespectador acessar o sistema, deste ou outro dispositivo: (1)Antes mesmo de que o telespectador acesse transparentemente o ProfileTV, um administrador teve de configur-lo, definindo categorias6 e papis7, alm de ter adicionado dispositivos e servios; (2)O sistema captura os dados das configuraes do dispositivo. Estes dados so armazenados localmente, podendo, posteriormente, serem exportados (se e somente se o telespectador solicitar) para dispositivos portteis ou sincronizados com dados pblicos do servidor (realizado de forma transparente para o usurio final); (3)O sistema captura a sintonizao do canal, e armazena o momento em que essa ao ocorreu; (4) feito tambm um cruzamento de dados com a grade de programao, para se conhecer qual o programa est sendo visto. Se durante a visualizao deste canal comear outro programa, o sistema captura o evento e adiciona-o nos dados capturados; (5)O sistema atualiza as informaes do canal; (6)Ao ser iniciada, a aplicao procura a preferncia do usurio, entretanto, como a primeira vez de execuo neste dispositivo
6

Categorias so modelos para a criao de perfis. Sua definio ser dada mais adiante neste captulo. 7 Papis definem o tipo de acesso (autorizao) que um usurio tem do sistema. Divide-se basicamente em administradores e geral.

33

com este telespectador, nada retornado. Desta forma, a aplicao inicia em sua forma padro: full-screen com transparncia sobre o vdeo; (7)A aplicao invoca o ProfileTV para armazenar localmente a preferncia do telespectador pela apresentao da mesma com vdeo em resize; (8)A aplicao invoca o ProfileTV para armazenar toda informao relevante da interao com o telespectador; (9)O dispositivo aciona o ProfileTV, solicitando a exportao de todos os dados, pblicos e privados, para um dispositivo porttil acessvel (ex. pen-drive plugado na porta USB [62] do set-top box) e/ou a sincronizao dos dados pblicos locais com os do ProfileTV Server. Ambas as aes8 permitem que as informaes deste telespectador estejam sempre atualizadas, onde quer que ele v.

3.2.2.

N-simo Acesso

Este um cenrio evolutivo, que apresenta hipoteticamente a forma como o sistema funcionaria aps uso rotineiro: "O telespectador mantm uma rotina semanal, na qual ao chegar em casa, aps a jornada de trabalho, (1) liga seu aparelho de televiso digital, (2) j sintonizado no canal de esportes, pois este o canal de sua preferncia. Enquanto prepara o jantar ouve as notcias de esportes radicais e alternativos. Sempre que falta 15min para o incio do telejornal em outro canal o telespectador (3) avisado atravs de um sinal sonoro e um componente grfico sobre o vdeo. Normalmente, o telespectador sintoniza o telejornal e espera pelo carregamento (4) automtico da aplicao em formato (5) full-screen com resize do vdeo."

As aes de sincronizao e exportao no precisam ser feitas necessariamente no ato de desligar o dispositivo. Outras possibilidades sero discutidas no Captulo 4, que trata da implementao de referncia do ProfileTV.

34

Pode-se observar que o sistema comporta-se diferente do primeiro acesso e, mais prximo do desejo do usurio. Isso s possvel, pois muitas informaes foram capturadas e armazenadas, permitindo s aplicaes tomarem suas decises quanto preferncia do usurio: (1)O televisor digital interativo liga sempre com as configuraes (ex. brilho, cor, matiz) de preferncia do ltimo telespectador ou daquele que transferiu, atravs de algum dispositivo porttil (ex. pen-drive via USB [62], celulares via Bluetooth [63]), o perfil para o dispositivo durante seu start up; (2)O aparelho sintoniza automaticamente o canal mais assistido por este telespectador; (3)O televisor digital interativo consulta a preferncia de

programao do telespectador no ProfileTV, criando um evento no middleware para ser alertado faltando 15 (quinze) minutos para o incio do prximo programa mais visto por este telespectador; (4)Ao ser carregada, a aplicao consulta o ProfileTV e verifica que de preferncia do usurio sua execuo automtica; (5)Ao ser iniciada, a aplicao consulta novamente o ProfileTV e assume o formato de preferncia deste telespectador (i.e. fullscreen com resize de vdeo).

3.3. Funcionalidades
O ProfileTV prov vrias funcionalidades para desenvolvedores tanto de aplicaes de TVDi como para componentes de software embarcados, desde que os dispositivos estejam mapeados no sistema. Estas funcionalidades esto agrupadas por prioridade: Essencial: funcionalidade sem o qual o sistema no entra em

funcionamento. Funcionalidades essenciais so imprescindveis, devendo ser desenvolvidas desde as primeiras implantaes do sistema.

35

Importante: funcionalidade sem o qual o sistema entra em

funcionamento, mas de forma no satisfatria. Funcionalidades importantes devem ser desenvolvidas o mais rpido possvel, mas, se no forem, parte do sistema poder ser implantada mesmo assim. Desejvel: funcionalidade que no compromete o

funcionamento bsico do sistema, isto , o sistema pode funcionar de forma satisfatria sem ele. Funcionalidades desejveis podem ser desenvolvidas por ltimo, ou no desenvolvidas, sem que existir comprometimento do correto funcionamento do sistema.

3.3.1.

Configurao do ProfileTV Essencial Importante Desejvel

Prioridade:

necessrio configurar o ProfileTV antes de se realizar o captura das preferncias do telespectador. Existem duas formas de realizar esta tarefa: (1) interface web do sistema e (2) uso de arquivo XML de configurao. recomendado o uso de (2), j que o sistema disponibiliza uma gramtica, no formato DTD, para descrio de categorias e propriedades, vide Figura 3 -8. A DTD facilita a criao da configurao do sistema, pois facilmente validada atravs de Integrated Development Environments (IDE, ex. Eclipse9) alm de permitir uma viso global do sistema.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
9

<!-- ProfileTV ELEMENT --> <!ELEMENT profiletv-mapping (category+)> <!ATTLIST profiletv-mapping update (TRUE|FALSE) "FALSE"> <!-- Category ELEMENT --> <!ELEMENT category (property*)> <!ATTLIST category id ID #REQUIRED> <!ATTLIST category name CDATA #REQUIRED> <!ATTLIST category parent IDREF #REQUIRED> <!-- Property ELEMENT --> <!ELEMENT property (value*)> <!ATTLIST property id ID #REQUIRED> <!ATTLIST property name CDATA #REQUIRED> <!ATTLIST property canBeNull (TRUE|FALSE) "TRUE"> <!ATTLIST property type (MULTI|SINGLE) #REQUIRED>

http://www.eclipse.org

36

17. <!ATTLIST property pattern CDATA #IMPLIED> 18. <!ATTLIST property valueType (BINARY|BOOLEAN|CURRENCY|DATE|NUMBER|TEXT) #REQUIRED> 19. <!ATTLIST property related IDREF #IMPLIED> 20. 21. <!-- Value ELEMENT --> 22. <!ELEMENT value (#PCDATA)> Figura 3-8 - Gramtica do ProfileTV

O ProfileTV todo baseado em categorias e propriedades, onde: Categoria um conjunto finito de propriedades que modela uma interao, dispositivo, servio ou usurio. e Propriedade uma caracterstica inerente a qualquer elemento de uma determinada categoria. Uma categoria pode conter tanto as caractersticas sociais de um usurio (ex. nome, idade, sexo, endereo), como as caractersticas de um aparelho de televiso interativo (ex. modelo, marca, resoluo, cor, brilho, matiz). Fazendo um paralelo com Orientao a Objetos [64], as categorias esto para o ProfileTV, como as classes de objetos esto para OO. As categorias, assim como as classes de objetos, encapsulam as caractersticas de um determinado objeto, que no caso do ProfileTV, denominado de perfil. As caractersticas de uma classe de objetos em OO so denominadas de atributos. J no ProfileTV, so denominadas de propriedades e, assim como em OO, possuem tipos (Figura 3 -8, linha 17). Este paralelo permitiu que qualquer categoria pudesse ser descrita atravs de propriedades. Alm disso, permitiu que o perfil criado a partir desta categoria possa ser manipulado quanto s suas propriedades. Outro conceito importado de OO pelo ProfileTV foi o de herana, onde, em OO, significa que uma classe de objetos pode herdar atributos e/ou funcionalidades de outras classes. No ProfileTV, como no h o conceito de funcionalidade, uma categoria herda apenas as propriedades de uma categoria pai. Alm disto, se a categoria (1) pai for filha de outra (2) categoria, a filha de (1) herda no apenas suas propriedades, mas tambm as de (2) e, assim sucessivamente.

37

Por conseguinte, ao se descrever a configurao do sistema as categorias devem ser dispostas de forma hierrquica, construindo, desta forma, uma estrutura de rvore. Um exemplo de configurao de sistema pode ser visto abaixo e um mais completo no Apndice A.

Figura 3-9 - Exemplo de configurao do ProfileTV

3.3.2.

Atualizao do ProfileTV Essencial Importante Desejvel

Prioridade:

O ProfileTV permite que a configurao do sistema seja atualizada sem que haja a necessidade da parada do sistema. Pode-se acrescentar novas propriedades s categorias ou, at mesmo, incluir-se novas categorias. O administrador do ProfileTV pode realizar esta atualizao atravs de uma das duas formas utilizadas na criao da configurao inicial, ou seja, atravs da (1) interface web do sistema ou (2) de arquivo XML. Caso opte por (2), basta passar " FALSE" no valor do atributo "update" do elemento "profiletv-mapping". Vale ressaltar que usando (2) como opo, a remoo de categorias no estar disponvel para o administrador. De fato, recomenda-se que nenhuma categoria, uma vez criada, seja removida a fim de se manter a compatibilidade com dispositivos e aplicaes legadas. Alm do mais, ao 38

se remover uma categoria deve-se redobrar a ateno, pois caso a categoria possua filhos, os mesmos tambm sero removidos do sistema, bem como os perfis associados a estas categorias.

3.3.3.

Criao/Atualizao de Perfis Essencial Importante Desejvel

Prioridade:

Os perfis so as instncias das categorias e podem estar associados a um usurio, aos pares (usurio, dispositivo) ou (usurio, aplicao) e, ainda, a trinca (usurio, dispositivo, aplicao). Desta forma, a criao/atualizao de um perfil pode ser feita de vrias formas: Dispositivo com o componente cliente do ProfileTV instalado

pode criar/atualizar perfis associados a uma categoria que descreva suas caractersticas. Ao criar/atualizar um perfil o dispositivo comunica-se com o servidor atravs do protocolo prprio do ProfileTV. S permitido a um dispositivo criar/atualizar um perfil se o mesmo fornecer um usurio previamente cadastrado no sistema. Em casos onde o primeiro acesso do usurio ao sistema feito atravs do dispositivo, o protocolo determina a seguinte seqncia de aes: (1) buscar no sistema local um usurio previamente cadastrado; caso falhe, (2) criao automtica de um usurio (login, password) para o telespectador; Aplicao com acesso API do componente cliente do

ProfileTV pode criar/atualizar perfis associados a uma categoria que descreva suas caractersticas. A aplicao pode criar/atualizar perfis associados ao par (usurio, aplicao), bem como tupla (usurio, dispositivo, aplicao). Como a aplicao usa o dispositivo para se comunicar com o servidor ProfileTV, tambm obrigada a utilizar o protocolo prprio do sistema, sofrendo as mesmas restries; Usurio com permisso de criar/atualizar perfis atravs da

interface web do sistema, desde que estes estejam desassociados 39

de dispositivos e/ou aplicaes. A restrio se faz necessria para garantir a veracidade dos dados capturados/armazenados no sistema.

3.3.4.

Importao e Exportao de Perfis Essencial Importante Desejvel

Prioridade:

Perfis podem ser "exportados para ou importados de dispositivos portteis e/ou do servidor. A forma como esta transferncia executada depende dos dispositivos envolvidos na comunicao (ex. Bluetooth, infravermelho, USB).

3.3.5.

Sincronizao de Perfis Essencial Importante Desejvel

Prioridade:

O sistema permite que qualquer alterao feita no perfil local, reflita automaticamente no perfil remoto ou, ainda, no perfil porttil. No momento da sincronizao, o dispositivo ou aplicao deve selecionar qual o tipo de sincronizao disponvel no momento, se (1) porttil ou (2) remota10, nesta ordem. A sincronizao do ProfileTV determina que apenas as

propriedades que sofreram modificao em seus valores so atualizadas e, no o perfil inteiro. Para atualizaes remotas, isso diminui o trfego de dados entre clientes e servidores.

3.3.6.

Publicao de Perfis Essencial Importante Desejvel

Prioridade:

O usurio do ProfileTV tem total controle sobre seus perfis. -lhe permitido, atravs da interface web do sistema, determinar aquilo que pblico e o que privado. O sistema permite que o usurio restrinja o acesso por perfil ou por propriedade, sendo a restrio por propriedade
10

A sincronizao remota uma funcionalidade desejvel.

40

mais relevante do que a por perfil. Desta forma, um perfil pode ser dado como pblico e possuir algumas de suas propriedades privadas. O perfil estaria visvel para terceiros, porm as propriedades dadas como privadas no. Um bom exemplo um portal interativo composto de vrios servios interativos. O tempo gasto em cada servio seria uma propriedade pblica enquanto que a preferncia de cores, vdeo em resize seriam privadas. Por padro, todo perfil mantido no sistema pblico, os dados privados so sempre mantidos localmente. Contudo, como explicado na seo 3.1, o usurio pode adquirir uma conta e transferir os dados privados para o servidor. Esta possibilidade adiciona mais um item de segurana no ProfileTV que o uso de tcnicas, como armazenamento criptografado dos dados e uso de assinatura digital. Afinal, os dados privados de um usurio podero ser armazenados em um servidor administrado por terceiros.

3.3.7.

Agregao de Perfis Essencial situaes Importante onde a experincia Desejvel de uso de um

Prioridade: Existem

muitas

dispositivo/servio integrante do ProfileTV no individual; basta lembrar que assistir televiso usualmente uma atividade coletiva. Logo, surge a necessidade de agregar perfis, de inferir o desejo de todos no ambiente. Esta uma funcionalidade que o ProfileTV, como sistema, no prov, pois est fora de seu objetivo, contudo uma funcionalidade proposta a ser embarcada em dispositivos integrante do sistema, como apresentado na Figura 3 -10.

41

Aplicao Aplicao1 1

Aplicao Aplicao2 2

...

Aplicao AplicaoN N

Agregador Agregador de de Perfis Perfis

Device Middleware (ex. MHP)

ProfileTV :: Middleware Component

Figura 3-10 - Relacionamento entre Agregador de Perfis e ProfileTV

3.3.8.

Busca de Dados Essencial Importante Desejvel

Prioridade:

O ProfileTV permite que terceiros cadastrados no ProfileTV Server possam realizar diversas pesquisas, podendo visualizar dados, como: usurios do sistema, perfis criados, perfis associados a dispositivos e/ou aplicaes. Todas estas buscas s podem ser realizadas atravs da interface web do ProfileTV, estando visveis somente os dados pblicos dos usurios. Desta forma, um usurio que no possua dados pblicos est, concomitantemente, no acessvel a terceiros, no devendo constar nos resultados das buscas realizadas.

3.3.9.

Relatrios Essencial Importante Desejvel

Prioridade:

O ProfileTV Server possui um componente responsvel pela gerao de diversos relatrios. Os relatrios esto acessveis apenas aos administradores do sistema e a alguns terceiros previamente autorizados. Pode-se extrair dos relatrios gerados dados, como: acessos por usurio, aplicaes mais acessadas, dispositivos mais utilizados e, at mesmo, quantidade de usurios por programao. Os relatrios provem, ao proprietrio do sistema, informaes relevantes para diversas tomadas de deciso, constituindo-se em um 42

componente

de

suma

importncia

dentro

do

sistema.

Deve-se

disponibilizar modelos prvios de relatrios (acordados no momento da implantao do sistema), alm de se permitir a criao de relatrios prprios (a partir da seleo de dados), tornando esta funcionalidade dinmica e extensvel.

3.4. Arquitetura
A arquitetura do ProfileTV segue o framework 4+1 [32], que define um conjunto de vises de software, como ilustrado na Figura 3 -11. Cada uma dessas vises aborda aspectos de relevncia arquitetural sob diferentes perspectivas, das quais sero apresentadas nesta dissertao: A viso lgica apresenta os elementos de projeto significantes

para a arquitetura adotada e os relacionamentos entre eles. Entre os principais elementos esto mdulos, componentes, pacotes e classes mais importantes da aplicao; A viso de implementao aborda os aspectos relativos e frameworks, orientaes e normas para o

organizao do cdigo fonte, padres arquiteturais utilizados, bibliotecas desenvolvimento do sistema. Esta viso ser apresentada no captulo 4, que tem como objetivo apresentar o como fazer o sistema; Os cenrios apresentam um subconjunto dos casos de uso

significativos do ponto de vista da arquitetura.

43

Viso Viso Lgica Lgica

Viso Viso de de Execuo Execuo Cenrios

Viso Viso de de Implementao Implementao

Viso Viso Fsica Fsica

Figura 3-11. Vises do framework 4+1

3.4.1.

Viso Lgica

O ProfileTV organizado em mdulos e componentes, que se encontram distribudos entre dispositivos integrantes do sistema. O modelo de distribuio adotado foi o cliente-servidor de 3 (trs) camadas, com dois tipos distintos de cliente, vide Figura 3 -12.

Figura 3-12 - Camadas do ProfileTV

3.4.1.1. Camada de Front-End (Clientes)

Por se tratar de um sistema heterogneo, inclusive quanto forma de acesso a seus servios remotos, os clientes do ProfileTV foram classificados em dois grupos, embarcados e web. A distino entre ambos 44

no se d apenas na forma de acesso aos servios remotos, como tambm de funcionalidades disponibilizadas localmente. O cliente embarcado um componente de software embarcado em dispositivo interativo (ex. set-top box e televiso digital com middleware, celulares, smartphones) integrante do sistema. Suas responsabilidades so: (1) capturar as preferncias do usurio, (2) prover uma API de acesso aos perfis para outros servios em execuo no dispositivo, (3) comunicarse com o servidor do sistema, (4) exportar e (5) importar perfis. considerado um fat client [61], j que realiza muitas tarefas dentro do prprio dispositivo, interagindo com o servidor apenas para busca e armazenamento, quando necessrio, de informaes. O cliente embarcado foi especificado atravs de componentes, responsveis pela realizao de cada uma das funcionalidades descritas acima, como mostra a Figura 3 -13.
I Communication Communication Controller Controller Servios Especficos Communication Communication Worker Worker I/O I/O Worker Worker II Profile Profile Capture Capture III Profile Profile Persistence Persistence IV I/O I/O Controller Controller Logging Logging V

Figura 3-13 Cliente embarcado do ProfileTV

I. Communication:

de

sua

responsabilidade

controle

(Communication Controller) e a realizao da comunicao com o servidor (Communication Worker), o marshalling e unmarshalling de objetos trafegados durante a comunicao, controle de concorrncia entre mais de uma conexo estabelecida por vez; II. Profile Capture: componente responsvel pela captura da interao para do telespectador com o dispositivo com o ou servio e ou transformao em perfil. O perfil armazenado temporariamente 11 posterior sincronizao/atualizao servidor,

O armazenamento poder ser permanente se, e somente se, o telespectador consenti-lo explicitamente.
11

45

exportao para dispositivo porttil. O perfil capturado baseado em Categoria previamente definida e armazenada no servidor; III. Profile Persistence: componente responsvel pelo

armazenamento local dos perfis e do controle do tempo de sobrevida dos dados. Cada perfil armazenado localmente possui algumas propriedades (data de criao, ltimo acesso, quantidade de acesso) que indicam se o mesmo est velho, precisando ser (1) armazenado no servidor, (2) exportado para um dispositivo porttil ou, em ltimo caso, (3) apagado do sistema 12, mediante autorizao do usurio. IV. I/O: componente responsvel pela exportao e importao de perfis para/de dispositivos portteis. Dentre as tecnologias sugeridas para uso de I/O esto Bluetooth [63], infravermelho e USB [62]; V. Logging: componente responsvel pela gerao de logging do sistema. Por se tratar de um sistema embarcado, o sistema de logging deve direcionar sua sada para uma porta serial, a fim de ser analisado por ferramentas de terceiros (ex. Hyper Terminal do Windows). O cliente web simplesmente um browser (ex. Mozilla Firefox, Internet Explorer) que permite acesso, via Internet, s funcionalidades administrativas do sistema. Atravs deste cliente, o usurio poder gerenciar seu perfil, podendo (1) publicar dados privados, (2) manter informaes pessoais, (3) exportar dados para dispositivos portteis (ex. pen-drives, celulares), bem como (4) sincronizar dados entre dispositivos portteis e o servidor. considerado um thin client [61], j que o browser apenas um visualizador de contedo, no realizando quaisquer tarefas alm da interao com um servidor do sistema. O cliente web tambm responsvel por prover (1) acesso s informaes pblicas dos telespectadores por terceiros, (2) manuteno das Categorias e Propriedades do sistema e (3) gerao de relatrios
12

Alguns perfis so parte integrante do dispositivo (ex. standard set up de uma televiso), no podendo ser apagados do sistema local. Contudo, sua exportao para dispositivo porttil ou armazenamento redundante em servidor permitida.

46

administrativos. atravs deste cliente que terceiros podem adquirir informaes relevantes sobre os usurios do sistema e, utiliz-los (os dados) como marketing direto, entrega de contedo personalizado, dentre outras possibilidades.

3.4.1.2. Camada de Negcio

Este o ncleo do ProfileTV, responsvel por prover a grande maioria das funcionalidades do sistema. um servio disponibilizado remotamente com dois tipos de acesso bem definidos, mapeados em dois tipos de clientes j vistos na seo 3.4.1.1.
Apresentao WEB
Communication Communication Worker Worker Screen Screen I Manager Manager

II

Comunicao

Administrative Administrative Protocol Protocol

ThirdParties ThirdParties Protocol Protocol

III

Negcio

Communication Communication Controller Controller

IV ProfileTV ProfileTV Manager Manager VIII

Report Report

Parsing Parsing

VI Security Security System System IX

Logging Logging

Session Session Controller Controller

Access Access Controller Controller

VII

Controlador de Dados

Persistence Persistence

Figura 3-14 - Componentes do ProfileTV Server

Atravs da camada de negcio, as solicitaes dos clientes so resolvidas e/ou repassadas para a camada gestora de dados. a camada de negcios que (1) se aplica o controle de acesso s informaes e funcionalidades do sistema, (2) gerencia-se as sesses de usurio, (3) gera-se relatrios, (4) mantm-se a configurao da rede, (5) publica-se dados privados de usurios, (6) cria-se relacionamentos entre propriedades e, (7) se exporta, importa e sincroniza perfis.

47

Assim como os clientes, o mdulo servidor foi especificado atravs de componentes, responsveis pela realizao de cada uma das funcionalidades descritas acima, como apresentado na Figura 3 -14. A seguir encontra-se a descrio de cada componente da arquitetura: I. Screen Manager: componente responsvel pela organizao da apresentao da aplicao web. de sua responsabilidade a (1) aplicao de filtros na requisio e na resposta ao cliente, (2) definio e invocao da tela a ser apresentada, (3) montagem das telas dinmicas telas que possuem layout separado da programao e, (4) invocao de funcionalidades do sistema; II. Communication: componente responsvel pelo controle de comunicao entre dispositivos/servios cliente e o servidor. Constitui-se de dois subcomponentes que atuam sempre em sinergia, Communication Controller e Communication Worker. O primeiro gerencia o pool de workers disponveis para tratar a fila de requisies. J o segundo responsvel pela implementao dos protocolos e dos servios; III. Protocol: por se tratar de um sistema distribudo com possibilidade de muitos acesos simultneos (escalabilidade), faz-se necessria a criao de protocolos de comunicao entre a camada de apresentao web e a camada de negcios. Esto representados aqui dois possveis protocolos, o Administrative Protocol (i.e. manuteno do sistema e acesso de usurios) e o Third Paties Protocol (ex. agncias de publicidade, provedores de contedo, anunciantes); IV. ProfileTV Manager: similar ao componente homlogo do cliente embedded, tendo as mesmas responsabilidades, ou seja, gerenciar o correto funcionamento do sistema, provendo acesso aos recursos e processos compartilhados; V. Parsing: componente responsvel pela interpretao da

configurao do sistema, descritos em XML;

48

VI. Security System: apesar de estar apresentado apenas na camada de negcio, permeia todas as camadas do sistema. responsvel pela aplicao da poltica de segurana, resoluo de problemas pontuais e rejuvenescimento de componentes [65]; VII. Access Control: componente destacado do sistema de

segurana, responsvel pelo gerenciamento de autenticao e autorizao de usurios no sistema. este componente que libera ou impede o acesso a determinadas funcionalidades do sistema, alm de aplicar o controle de sesso aos usurios logados; VIII. Report: componente responsvel pela gerao de relatrios a partir dos dados armazenados na camada gestora de dados. , ainda, de sua responsabilidade aplicar os cruzamentos de dados necessrios para os relatrios associados; IX. Logging: responsvel pela gerao de log das atividades do sistema. sugerido que o log seja armazenado em banco na camada gestora de dados e, que seja gerado uma verso na sada padro do sistema. Este componente deve prover nveis de log (ex. FATAL, DEBUG, INFO); X. Persistence: este o componente responsvel pela interao com a camada gestora de dados. Deve realizar mapeamento objetorelacional de forma ntegra e eficiente. neste componente que se encontra a implementao de Categorias e Propriedades e seu relacionamento com Perfis e Caractersticas.

3.4.1.3. Camada Gestora de Dados

Sistema gerenciador de dados acessvel remotamente. Sua

responsabilidade armazenar e recuperar dados de forma ntegra e segura. Deve ser aplicada redundncia a esta camada, a fim de aumentar a tolerncia a falhas do sistema. No processo de tomada de deciso de qual SGBD utilizar, levar em considerao sua capacidade de escalabilidade, quantidade mxima de conexes, confiabilidade, facilidade de programao, configurao, uso e 49

instalao. O SGBD no precisa ser objeto-relacional j que existem frameworks, como o Hibernate [66], que oferecem esta funcionalidade. Deve-se criar um banco especfico para o armazenamento de logging, j que este tem uma tendncia de crescer rapidamente dependendo da granularidade ajustada. Deve-se criar outro banco para os dados gerados pelo sistema, ou seja, categorias e propriedades, bem como usurios, perfis, dispositivos e servios. O controle de acesso e de sesso pode compartilhar o banco do sistema, desde que seja aplicada uma viso mais restrita ao mesmo. Uma viso geral da modelagem pode ser vista a seguir, na Figura 3 -15.
Session User Profile Category Role ProfileTV Relationships
Legend = zero or one

Entity is/a Action

Interagem

Features

Property

= many = one to one

Device

Service

is/a

Executa Single Property Multi Property

Figura 3-15 - Viso Geral do Modelo E-R do ProfileTV

3.4.2.

Cenrios

Esta seo descreve os cenrios de relevncia arquitetural 13 [32] do ProfileTV. O objetivo proporcionar uma viso ampla do fluxo de informao ao longo das camadas, mdulos e componentes do sistema. A Figura 3 -16 apresenta um diagrama de casos de uso

simplificado14 contemplando os cenrios, bem como os atores envolvidos

Entende-se por relevncia arquitetural os casos de uso (cenrios) que representam uma funcionalidade central e significativa do sistema, ou possuem uma cobertura arquitetura substancial, ou ainda ilustram um determinado ponto complicado da arquitetura.
13

Os diagramas de caso de uso das funcionalidades essenciais, bem como os atores do sistema podem ser encontrados no Apndice C.
14

50

no cenrio. J as responsabilidades, direitos e deveres destes atores encontram-se a seguir: O user representa um telespectador de TVDi que disponha de

dispositivos integrantes da rede do ProfileTV. No cenrio, sua responsabilidade gerenciar seus perfis dentro do sistema; O adminUser um tipo especializado de user, que tem como

principal responsabilidade dar manuteno ao sistema; O device qualquer dispositivo utilizado pelo user para interagir

com o sistema.

Figura 3-16 - Cenrios Arquiteturais Relevantes

No cenrio acima esto representados alguns agregados de operaes, determinadas de CRUD15. Todos podem ser realizados por qualquer usurio, com exceo do KeepConfiguration que s permitido aos administradores de sistema. Apesar de possurem objetivos distintos, os CRUDs possuem interaes similares com o sistema, trafegando informaes pelas 3 camadas do modelo, sendo tratadas pelos mesmos componentes:
Acrnimo da expresso inglesa Create, Retrieve, Update e Delete usada para definir quatro operaes bsicas usadas em bancos de dados relacionais (RDBMS) ou em interface para usurios para criao, consulta, atualizao e destruio de dados [121].
15

51

O cliente web renderiza a interface do sistema e captura a

interao do administrador com a aplicao. Desta interao, os administradores podem disparar solicitaes encapsuladas pelo protocolo HTTP para o servidor ProfileTV; A camada de negcio processa as solicitaes desde sua

camada de apresentao web, passando pelos mdulos ProfileTV Manager, Access Control, Parsing16, Persistence, Security System e Logging; A camada de dados invocada atravs do mdulo Persistence

da camada de negcios, sempre que algum dado precise ser (1) recuperado (ex. validao durante login no sistema), (2) criado (ex. criao de uma sesso para o usurio), (3) atualizado (ex. atualizao de uma configurao prvia) ou, (4) removido (ex. remoo de um perfil de usurio). No cenrio, os casos de usos acessveis atravs de dispositivos foram selecionados por tambm atravessarem todo o sistema, contudo, diferentemente dos casos de uso j citados, partem do cliente embedded, em vez do web. O fluxo de informaes destes casos de uso segue: O cliente embarcado utiliza o seu mdulo Communication para

interagir com o servidor ProfileTV; A camada de negcio processa as solicitaes desde sua mdulo Communication. A partir da interpretao das

camada de protocolo, atravs do componente Worker adequado de seu solicitaes (protocolo); o mdulo de ProfileTV Manager invocado e repassa as operaes para os outros mdulos do sistema: Access Control, Persistence, Security System e Logging; A camada de dados invocada atravs do mdulo Persistence,

da camada de negcios, sempre que algum dado precise ser (1) recuperado (ex. perfil do usurio durante uma sincronizao), (2) criado (ex. criao de um novo perfil para o usurio no dispositivo),
Invocado pelo ProfileTV Manager apenas na criao e atualizao de configuraes. Acessvel apenas aos administradores do sistema.
16

52

(3) atualizado (ex. atualizao de um perfil prvio). No permitida a remoo de perfis a partir do cliente embarcado.

3.5. Distribuio
Os mdulos de comunicao tm papel de destaque no ProfileTV. Isso decorre do mesmo ser um sistema distribudo baseado no modelo clienteservidor, bem como de permitir a comunicao entre sistemas heterogneos, j que o ambiente dos clientes web, embarcado e do servidor de aplicaes so completamente distintos. Esta definio aponta a importncia da distribuio, como tambm deixa claro um problema, o da heterogeneidade. Existem muitos modelos de distribuio para solucionar

heterogeneidade entre sistemas comunicantes [67]. Um de grande destaque o emprego de um middleware, sendo este o modelo definido para a distribuio do ProfileTV. Esta deciso foi guiada pela nfase do sistema em ambientes de TVDi, os quais, em sua maioria, dispem de middleware embarcado com uma pilha de comunicao bsica, normalmente o TCP/IP. Contudo, o uso de um middleware para comunicao, por si s, no resolve os problemas. preciso definir qual o tipo de middleware utilizado, j que, tendo-se em vista que os modelos (padres) de TVDi divergem quanto ao paradigma de programao (declarativo e procedural), esta deciso determinar o grau de generalizao/reuso do ProfileTV. Dentre os modelos de TVDi abertos o japons ISDB [06] e o brasileiro ISDTV [68] empregam o paradigma de declarativo, disponibilizando uma API de comunicao baseada em requisies HTTP. Os outros modelos, incluindo o ISDTV, baseiam-se em orientao a objetos e disponibilizam um ambiente de comunicao atravs de RMI, alm do j citado HTTP. No mercado fechado de TVDi, incluindo as solues para IPTV, h uma preferncia pelo paradigma procedural, j que a OpenTV detm cerca de 70% [33] deste mercado e, seu middleware procedural. Contudo, h 53

solues em Flash e PHP, que disponibilizam APIs de comunicao baseada em requisies HTTP.
Tabela 3-2 - Comparao entre solues de TVDi
Me rca do Mode lo ATSC DVB Abe rto ISDB ISDTV/ SBTVD Ope nTV Thomson Fe cha do BRT Vide on Middle w a re DASE MHP ARIB GI NGA Ope nTV SN Vide on Lingua ge m Ja va Ja va BML NCL/ LUA + J a va C Fla sh HTML + PHP + Ja vaSc ript Pa ra digm a Proc e dura l Proc e dura l De c la ra tivo De c la ra tivo + Proc e dura l Proc e dura l Proc e dura l De c la ra tivo + Proc e dura l Com unica o HTTP + RMI + Soc ke ts HTTP +RMI + Soc ke ts HTTP HTTP +RMI + Soc ke ts HTTP sobreTCP/ IP HTTP + RPC-XML HTTP + RPC-XML

Analisando este cenrio, resumido na Tabela 3 -2, conclui-se que a melhor forma de distribuir o sistema empregar um middleware que utilize requisies HTTP nas trocas de mensagens, atendendo a todos os modelos apresentados na tabela. Contudo, esta a nica concluso que se pode tirar, j que h grande variedade quanto ao paradigma de programao e linguagem adotada, impossibilitando de se determinar qual orientao de middleware (ex. RPC [69], XMLRPC [70], RMI [71], MOM [72]) utilizar. Desta forma, sugere-se que uma implementao do ProfileTV use dupla distribuio: (1) RMI, o que abrange consideravelmente o mercado aberto; e, (2) XMLRPC (SOAP) como soluo mais abrangente, j que a mesma pode ser utilizada atravs de requisies HTTP e interpretao de XMLs.

3.5.1.

Protocolo de Interao entre Cliente-Servidor

Independentemente de qual seja o tipo do middleware, necessrio determinar como ocorrer a comunicao entre cliente e servidor. O ProfileTV determina um conjunto de regras a serem seguidas durante esta comunicao:

54

O ciclo de vida de qualquer interao ser sempre via uma per

request instance [73]. Isto implica em um maior controle de concorrncia no servidor e, que toda requisio seja self-contained, ou seja, conter toda a informao necessria operao; Objetos complexos trafegados na comunicao devem ser

simplificados seguindo as normas estabelecidas pela W3C em [74]. Isto implica na criao de adaptadores [75]; Seguir o protocolo ProfileTV para as operaes de sincronizao,

atualizao e busca, Figura 3 -17.

(a) Atualizao de Perfis

(b) Sincronizao de Perfis

(c) Busca de Perfis

Figura 3-17 - Exemplo do Protocolo do ProfileTV

O detalhamento deste protocolo, bem como todos os cdigos utilizados na troca de mensagens encontram-se detalhados no Apndice B.

3.6. Consideraes
O ProfileTV um sistema distribudo complexo, que tem por objetivo servir de infra-estrutura para a elaborao e execuo de servios de personalizao baseados em perfis. Neste captulo introduziu-se o sistema, apresentando suas funcionalidades, seu modelo de distribuio, bem como suas camadas e sua arquitetura. O sistema no trata de aspectos 55

dos sistemas inteligentes que viro a utilizar a plataforma, bem como do desempenho da soluo proposta. O foco deste captulo foi responder o que o sistema? e, no como fazer o sistema?, que sero discutidos nos prximos captulos.

56

4.Captulo Implementao
Foi o tempo que perdi com a minha rosa que a fez to importante. - Antoine de Saint-Exupry

No modelo proposto por Kruchten [32], a viso de implementao responsvel por "descrever a organizao esttica do software em seu ambiente de desenvolvimento" . Esta viso descreve como o processo de desenvolvimento deve se desenrolar. Este captulo vai alm desta definio e procura discutir aspectos mais profundos de implementao, como a tomada de deciso entre padres e frameworks utilizados, paralelos com implementaes similares e, quando necessrio, a descrio de adaptao dos mdulos e componentes implementados para um ambiente j estabelecido. Apresenta tambm alguns refinamentos da viso lgica apresentada no Captulo 3.

4.1. Camada de Front-End

O front-end a interface do sistema com o usurio final (ex.

telespectador, usurio de dispositivos portteis, web users), sendo composto pelos dois tipos de cliente do ProfileTV, o web e o embarcado. Os clientes web so implementados por browsers (navegadores), de livre escolha do usurio. Desta forma, mesmo ciente de que haver situaes onde ser exigida a programao neste tipo de cliente, optouse, para esta dissertao, pelo no detalhamento do mesmo. Por conseguinte, esta seo detalha apenas o segundo tipo de cliente, o embarcado.

57

4.1.1.

ProfileTV Embedded Client Side Middleware

Para a implementao de referncia do cliente embarcado do ProfileTV foi utilizado uma verso para PC do middleware de televiso digital europeu, o Multimedia Home Platform (MHP) [76]. A escolha pelo MHP foi natural, j que o middleware de modelo aberto mais utilizado e difundido mundialmente [77], possui uma boa documentao on-line [78], alm de implementaes de referncia open-source [79]. Aliado a estas caractersticas completamente desenvolvido em Java, possuindo embarcadas as bibliotecas necessrias ( Java RMI) para execuo do ProfileTV. A Figura 4 -18 ilustra a arquitetura bsica da especificao do MHP [80].
Application Application Application Application Application Application Application Application

Application management/Xlet API Service Selection Conditional Access DVB UI Return Channel

Inter-Xlet Communication

DSM-CC

SI

Tuning

JMF

UI Events

AWT

HAVi

Section Filtering MPEG

pJava

Resources Resources

Figura 4-18 - Arquitetura bsica do MHP

Dentre as implementaes disponveis, optou-se pela do instituto alemo Institut fr Rundfunktechnik (IRT) [81]. A escolha pelo IRT torna a implementao de referncia do ProfileTV mais prxima da realidade, j que esta uma implementao comercial do middleware MHP. Entretanto, foram necessrias algumas configuraes no MHP-IRT para efetuar a correta adio do ProfileTV ao sistema. Estas configuraes permitiram disponibilizar a API do ProfileTV Embedded

58

Client Side Middleware para uso das aplicaes de televiso digital interativa. Estas configuraes so apresentadas na seo 4.7.1.

4.1.1.1. Viso de Implementao

O ProfileTV Embedded Client Side Middleware tem como funcionalidades capturar a interao do usurio com o dispositivo no qual est embarcado, armazenando-os localmente. tambm de sua responsabilidade prover, tanto para servios como para o prprio dispositivo, uma API para manipulao destes dados locais (ver Apndice D), alm de permitir o acesso a dados remotos armazenados no ProfileTV Server. O cliente embarcado deve sempre fazer parte da camada de servios especficos17 do middleware ao qual for adicionado, utilizando as demais camadas como suporte para suas operaes. A Figura ilustra a viso de implementao deste tipo de cliente do ProfileTV.
CoR*
Embbeded Client Legenda

4 -19

BlueCove

Controller

I/O I/O

Communication Communication

Profile Profile Capture Capture

Figura 4-19 - Viso de Implementao do ProfileTV Embedded Client Side Middleware

4.1.1.2. Communication
O componente Communication responsvel pela comunicao com o ProfileTV Server atravs de invocaes remotas de mtodos (RMI). Possui uma fbrica concreta (CommunicationFactory) que permite a criao de Workers especializados em um conjunto de operaes do protocolo ProfileTV. Estes tipos esto definidos na enumerao WorkerType, disponvel s aplicaes atravs da prpria CommunicationFactory. A Figura 4 -20 ilustra o diagrama de classes deste componente.

17

No caso do MHP, o ProfileTV Embedded Client seria uma vertical sobre o pJava (Personal Java [82]) da Figura 4 -18.

59

Observer

Servios Especficos de Middleware

J2SE 1.3

Logging Logging

Profile Profile Persistence Persistence

Pattern/Model Library

Figura 4-20 - Diagrama de classes do ProfileTV Embedded Client Side Middleware Communication

Este componente permite um mnimo de configuraes, como o endereo do ProfileTV Server e nome dos objetos distribudos invocados. Estas configuraes so feitas em arquivos de configurao lidos pela classe auxiliar CommunicationService. Uma aplicao que necessite interagir com o ProfileTV Server, dever fazer uso deste componente, recuperando um Worker especializado atravs da CommunicationFactory. Alm disso, dever se cadastrar como um Observer das aes deste Worker, podendo intervir diretamente nas tomadas de deciso do protocolo de comunicao. Vale ressaltar que este um componente obrigatrio nas

implementaes do ProfileTV Embedded Client Side Middleware.

4.1.1.3. I/O
O componente de I/O responsvel por exportar e importar Profiles para/de dispositivos portteis, como pen-drives, celulares e smartphones. Este componente prov vrios meios de transmisso para estes dados, contudo todos so opcionais, sendo obrigatrio a implementao de ao menos uma forma de transmisso de dados. Para a implementao de referncia do ProfileTV Embedded Client Side Middleware foram desenvolvidas as transmisses via USB [62] e Bluetooth [63]. A Figura 4 -21 ilustra o diagrama de classes deste componente. 60

Figura 4-21 - Diagrama de classes do ProfileTV Embedded Client Side Middleware I/O

O componente disponibiliza uma fbrica concreta para criao de Workers especializados em cada tipo de transmisso. atravs dos Workers que uma aplicao tem acesso aos mtodos exportProfile e importProfile.

4.1.1.4. Logging
O componente Logging do ProfileTV Embedded Client Side Middleware segue as definies do padro arquitetural Cadeia de Responsabilidade. Isto permite que uma aplicao customize vrios Loggers de nveis distintos e os encadeie. Ao ser invocado, o componente de Logging aplicar a mscara de logs atual na cadeia, desta forma apenas os Loggers que possuam nvel igual ou mais elevado que a mscara imprimiro a mensagem no dispositivo de sada indicado. A Figura 4 -22 ilustra o diagrama de classes deste componente.

61

Figura 4-22 - Diagrama de classes do ProfileTV Embedded Client Side Middleware Logging

Este um componente opcional na implementao do ProfileTV Embedded Client Side Middleware. Entretanto sua implementao fortemente sugerida, j que muitos dos middleware hospedeiros no disponibilizam tal funcionalidade. O MHP, por exemplo, no disponibiliza em sua API as funcionalidades de logging. Contudo, por ser baseado em um Personal Profile Java [82], espera-se que o pacote java.util.logging esteja disponvel nas implementaes comerciais.

4.1.1.5. Profile Capture

O Profile Capture um dos principais componentes do ProfileTV Embedded Client Side Middleware e tambm um dos mais dependentes do middleware hospedeiro. Sua funo monitorar todo tipo de interao que o usurio realize com o dispositivo no qual est embarcado, ou seja, atua como um grande Observer das atividades do sistema. Para implementao de referncia do ProfileTV Client Embedded, este componente utilizou as funcionalidades providas pela API do MHP a fim de se registrar como um Observer das reas Network, Service Selection e User Events, vide Figura 4 -23. Desta forma, a cada mudana nos estados destas reas o componente Profile Capture notificado por eventos. Se a informao passada no evento for relevante, esta ser armazenada localmente atravs do componente Persistence.

62

Entende-se por informao relevante, todo dado que pode ser mapeado em uma Feature que componha o Profile pr-determinado de interao de um usurio com este dispositivo (ex. tempo gasto em determinada rea de uma aplicao, brilho e contraste do dispositivo interativo). Para que isto ocorra, necessrio que os dispositivos possuam um Profile associado a uma Category no ProfileTV Server. Esta associao deve ser feita por um administrador durante a configurao inicial ou atualizao posterior do sistema (ex. adio de uma Category para o dispositivo na hierarquia de Categories do sistema).

Figura 4-23 - Adio do Profile Capture como Observer de reas do MHP

O fato de estes dados estarem armazenados localmente, garante um ganho de desempenho para o sistema, j que possibilita que as preferncias do usurio sejam recuperadas rapidamente durante o boot. O acesso ao Profile do dispositivo pelas aplicaes tambm fica mais rpido e no suscetvel aos possveis atrasos de rede. Entretanto, esta deciso inseriu um novo problema no sistema: a possibilidade de que alguns dados do ProfileTV Server possam estar desatualizados. Como proposta de soluo adicionou-se um timer para de tempos em tempos sincronizar o Profile local com o remoto. Outras solues seriam, por exemplo: (1) disparar as alteraes locais no shutdown do dispositivo, porm isso acarretaria em um processo mais demorado de desligamento, ou (2) realizar a sincronizao durante o estado de standby do aparelho, contudo muitos usurios retiram o aparelho da tomada, o que impediria a sincronizao.

63

4.1.1.6. Persistence
O componente de persistncia do ProfileTV Embedded Client Side Middleware prov s aplicaes um servio de armazenamento de Profiles. Estes Profiles so armazenados em arquivos de acesso exclusivo para este componente, garantido atravs de polticas de segurana definidas junto ao middleware hospedeiro. A Figura 4 -24 ilustra o diagrama de classes do Persistence. Este componente baseou-se em algumas premissas bsicas de SGBDs relacionais, como a definio de chaves primrias para identificao nica dos dados (Key, SingleKey e CompositeKey) e armazenamento atravs de tabelas (Hashtable). A idia que a similaridade facilita o entendimento e uso deste componente. Importante ressaltar que esta funcionalidade obrigatria. Portanto, deve ser disponibilizada independentemente de que o middleware hospedeiro provenha servio similar. O MHP, por exemplo, no oferece uma API de persistncia18, deixando a cargo dos fabricantes de set-top boxes determinarem como ser o acesso ao sistema de arquivos do dispositivo.

Figura 4-24 - Diagrama de classes do ProfileTV Embedded Client Side Middleware Persistence

18

O pacote "org.dvb.application.storage" contm classes que permitem que aplicaes inteiras sejam armazenadas, recuperadas e removidas do sistema. Contudo, no h menes ao armazenamento de arquivos.

64

4.2. Camada de Negcios

Camada intermediria do ProfileTV responsvel pela implementao do negcio do sistema. Assume o papel do servidor/mediador, resolvendo ou despachando as requisies dos clientes. Tem sua implementao realizada por instncias do mdulo ProfileTV Server, executadas em servidores de aplicao. A Figura 4 -25 ilustra viso de implementao do mdulo ProfileTV Server.
Apresentao WEB J2SE RMI JAX-RPC MVC
Screen Screen Manager Manager

ProfileTV Server Legenda J2EE 1.4 Framework Pattern/Model Library

Struts
Communication Communication Worker Worker Administrative Administrative Protocol Protocol ThirdParties ThirdParties Protocol Protocol

Comunicao

DOM4J

Visitor

Parsing Parsing

Log4J RBAC
Report Report

Negcio

Controller

Security Security System System

Communication Communication Controller Controller

MyProfile MyProfile Manager Manager

Controlador de Dados

Persistence Persistence

Hibernate

Figura 4-25 - Viso de Implementao do ProfileTV Server

4.2.1.

Screen Manager

O Screen Manager do ProfileTV Server foi construdo sobre o Struts, ficando a cargo do framework interceptar as requisies dos clientes, despach-las para processamento e redirecionar o resultado para a renderizao de uma tela especfica. Desta forma, o componente Screen Manager encapsula apenas parte do Controller, atravs da descrio do fluxo de informao, dos processadores (Action) e entidades auxiliadoras de processamento (ActionForm), alm de toda a View, atravs de pginas JSP e Servlets. O Model fica a cargo dos componentes de persistncia e 65

Observer

CoR*

J2SE 1.5

Session Session Controller Controller

Access Access Controller Controller

Jasper

CoR*

Logging Logging

controle de acesso do sistema, acessados como recursos atravs do ProfileTV Manager. A descrio do controle do fluxo de informao feita atravs de uma arquivo de configurao (struts-config.xml) passado para o Struts framework no startup do sistema19. Este arquivo contm a descrio de todos os (1) processadores ( Action) e das (2) entidades auxiliadoras de processamento (ActionForm), do mapeamento entre (1) e (2), de (3) datasources e de (4) do controladores fluxo de de configurao, Na alm de (5) de redirecionamentos informao. implementao

referncia do ProfileTV Server foram utilizados (1), (2) e (5). A Figura 4 -26 abaixo um excerto da configurao utilizada no

ProfileTV Server e ilustra o mapeamento de um processador ( LoginAction) e uma entidade auxiliadora de processamento (LoginActionForm).

Figura 4-26 - Excerto do struts-config.xml do ProfileTV Server

O LoginAction invocado pelo framework sempre que uma requisio ao caminho "/loginAction" feita. Neste momento, o objeto LoginActionForm, que contm todos os dados do formulrio ( login e password) preenchido na tela de login, passado para o LoginAction juntamente com outras informaes, como a prpria requisio do cliente e o mapeamento de aes.

19

O struts-config.xml repassado para o Controller do Struts framework, o ActionServlet.

66

 importante ressaltar na Figura

4 -26, as tags de forward

aninhadas ao LoginAction. Estas tags so responsveis por determinar o redirecionamento das chamadas, que podem ser tanto para uma tela como para outro processador. Ainda quanto ao excerto de configurao, se o login de um usurio no sistema for efetuado com sucesso, o LoginAction deve retornar para o framework uma mensagem de "ok", encapsulada em um objeto ActionForward. Para o Struts, receber um "ok" do LoginAction, significa invocar a tela "menu.jsp", para que o resultado da requisio seja renderizado e enviado para o cliente.

4.2.2.

Communication

O componente Communication responsvel por prover as interfaces de comunicao, detalhadas na seo 4.6, do ProfileTV Server. Este componente, como definido no Captulo 3, possui duas formas de distribuio: via Web Service (WS), baseado em JAX-RPC [83], e objetos distribudos, baseado em Java RMI [71]. Esta deciso imps uma restrio complexidade dos dados trafegados. O World Wide Web Consortium (W3C) define em suas normas [84] [85] [86] os tipos de dados que podem ser trafegados nas mensagens de WS, dados estes bem mais limitados que os permitidos em Java RMI. Desta forma, foi necessrio criar adaptadores (wrappers) dos dados (objetos) empregados na persistncia do ProfileTV Server. A Tabela 4 -3 mostra as adaptaes realizadas.
Tabela 4-3 - Adaptaes dos Dados no Communication
Tipo deDa dosnaPe rs is te nce Cole e s do Ja vaCo lle c tio nsFra m e w o rk Enume ra e s Ge ne ricMe tho d s Ada pta o no Com m unica tion Arra y s Consta nte s De sdobra me nto e m m todos e spe c ia liza dos Adi o depa r me tros pa rade fini o do tipo utiliza do Disc re tiza dae ma rra y s dea rra y s de Prope rtie s Disc re tiza dae ma rra y s dea rra y s de Fe a ture s

rvoredeCa te g o rie s rvoredePro file s

67

Communication

constitui-se

de

dois

subcomponentes,

Communication Controller e o Communication Worker. O subcomponente Communication Controller responsvel, no startup do sistema, pela criao do servidor de registros (RMIRegistry), da vinculao dos servios20 Java RMI no servidor de registros recm criado, alm da criao das instncias dos servios disponibilizados via WS. O Communication Controller tambm responsvel por repassar para o ProfileTV Server Manager todas as instncias de servios criadas, alm de realizar algumas configuraes na poltica de segurana do sistema. Todo o gerenciamento dos objetos distribudos fica a cargo do Java RMI e do servidor de aplicao adotado. O subcomponente Communication Worker representa os prprios objetos distribudos, sendo responsveis no apenas pelo tratamento de requisies, mas tambm pela implementao do protocolo ProfileTV Server. A Tabela X abaixo ilustra alguns cdigos embutidos no cabealho das mensagens do sistema. O Apndice B apresenta todos, bem como as operaes possveis do protocolo.
Tabela 4-4 - Alguns Cdigos do protocolo ProfileTV Cdig o Nome 111 113 121 123 130 NEW PROFILE NEW USER UPDATE PROFILE UPDATE USER SEARCH PROFILE BY USER Tipo Atualiza o Atualiza o Atualiza o Atualiza o Buscas Descrio Cria um novo Profile no Sistema Cria um novo User no Sistema Atualiza um Profile previamente cadastrado no sistema Atualiza um User previamente cadastrado no sistema Busca os Profiles associados ao User

134 102 200 400

SEARCH PROFILE BY SERVICE ON DEVICE PER USER Buscas SYNCHRONIZE PROFILE PER SERVICE ON Sincroniza DEVICE o OK UNKNOWN

Busca os Profiles do User associados a dupla (Service, Device) Sincroniza a tupla (Service, Device, User) com um Profile previamente criado Retorno correto de uma operao, Respostas normalmente uma busca Respostas Operao desconhecida

20

Os WS so publicados automaticamente na implantao do sistema no servidor de aplicao.

68

403

PROFILE NOT FOUND

Profile no existente para o User neste (Device/Service/DeviceRespostas Service)

Cada worker processa um conjunto especfico de requisies definidos em sua interface remota, e so obrigados a responder com o mesmo tipo de dado, a Message. Uma Message composta por um header, que contm o tipo da mensagem, e por um payload, contendo uma tabela (Hashtable) associativa entre classes e objetos. Este tipo padronizado de resposta foi utilizado para permitir a troca de mensagens com clientes que no possuam um modelo de comunicao atravs de objetos distribudos (ex. sockets).

4.2.3.

ProfileTV Server Manager

O ProfileTV Server Manager carregado no startup do sistema e fica responsvel por iniciar todos os componentes do ProfileTV Server. Em seu carregamento este componente registra-se como um Observer de cada componente do sistema. Esta ao o permite ouvir as operaes de relevncia sistmica, possibilitando a rpida interveno em casos de falha, alm de ser um ponto centralizado de gerao de logs. Este componente tambm a Facade [75] do ProfileTV Server, controlando todo o acesso aos recursos do sistema. Entretanto, diferentemente das tradicionais Facades, que replicam as assinaturas de todas as funcionalidades do sistema, atuando basicamente como um Proxy [75], o ProfileTV Server Manager disponibiliza apenas um mtodo, o
getProfileTVResource

(cf. Figura 4 -27 - Mtodo de acesso a recursos do

ProfileTV Server). Este mtodo tem assinatura similar aos FactoryMethods [75], possuindo um nico parmetro que determina o tipo do recurso requerido.

69

Figura 4-27 - Mtodo de acesso a recursos do ProfileTV Server

Por ser a principal porta de entrada do ProfileTV Server, este componente atua sempre junto com os dois componentes de segurana do sistema, o Security System e o Access Controller. Para o Security System serve como ltimo nvel em todas as cadeias de responsabilidade criadas e, aplica as regras de permisso do Access Controller em todas as requisies de recursos feitas por qualquer entidade.

4.2.4.

Parsing

O ProfileTV define uma gramtica (DTD) para a configurao do sistema atravs de XML, como apresentado no Captulo 3. As configuraes precisam ser primeiramente interpretadas e validadas pelo sistema, para s depois serem disponibilizadas para uso. O componente responsvel por esta funcionalidade o Parsing. O Parsing um componente simples, conforme Figura 4 -28,

construdo sobre a biblioteca DOM4J [87]. Utiliza a tcnica SAX [88] para leitura do arquivo XML e a tcnica DOM [89] para construo e interpretao da rvore de elementos. A unio das duas tcnicas possibilita uma rpida leitura do arquivo (SAX mais eficiente que DOM 70

para leitura de arquivos XML) e uma fcil navegao entre os elementos (DOM mais simples de utilizar).

Figura 4-28 - Diagrama de Classes do Parsing

O ProfileTV Parser a principal classe do componente, sendo a nica diretamente acessada por componentes externos ao Parsing. uma classe abstrata que se prope a criar parsers especializados para cada trabalho, atravs do Factory Method
type).

[75] esta

ProfileTVParser implementao de

newInstance(ProfileTVParserType

Para

referncia do ProfileTV Server, sempre passado como argumento para este mtodo o tipo CATEGORY_PARSER. O componente ainda dispe de um tratador de erros de leitura de XML (ProfileTVParserErrorHandler), de um subcomponente de utilidades (ProfileTVParserUtil) e de uma exceo especializada. importante ressaltar que o ProfileTVParserErrorHandler o primeiro nvel na cadeia de responsabilidade para tratamento de erros no Parsing, ou seja, faz parte, tambm, do Security System.

4.2.5.

Security System Server est distribudo entre os

O Security System do ProfileTV

componentes do sistema. Suas principais responsabilidades so tratar violaes de segurana e auxiliar no tratamento de erros. Desta forma, atua sempre em conjunto com o componente Access Control e o tratamento de excees de Java. Uma das tcnicas empregadas no Security System so as cadeias de responsabilidade. Estas cadeias formam listas ligadas unidirecionais, 71

sendo formadas por elementos do tipo SecurityChainElements, uma classe abstrata que referencia o prximo elemento na cadeia e, obriga seus filhos a implementar o mtodo abstrato void execute(). Este mtodo invocado pelos outros componentes do sistema quando precisam aplicar regras de segurana durante a operao de alguma de suas funcionalidades. A Figura componente. 4 -29 mostra o diagrama de classes deste

Figura 4-29 - Diagrama de Classes do ProfileTV Security System

O System Security disponibiliza tambm Observers para a realizao de uma segurana pr-ativa. Estes so representados por classes que implementam a interface SecurityObserver e, conseqentemente, seu nico mtodo void applySecurityPermission (SecurityPermission sp). Este mtodo invocado pelo prprio Security System quando alguma regra de segurana violada ou quando algum elemento de uma cadeia de responsabilidade lana uma exceo do tipo SecurityViolationException.

4.2.6.

Access Control

O componente Access Control do ProfileTV Server composto por dois subcomponentes, o Access Controller e o Session Controller. Ambos esto 72

envolvidos com os aspectos de autenticao de usurio e autorizao de acesso a operaes dentro do sistema.

4.2.6.1. Access Controller

O ProfileTV Server poderia ter reutilizado um sistema de controle de acesso, como o MACA [90] ou o OpenLDAP [91]. Entretanto, o modelo criado no ProfileTV para a representao de perfis de usurio permitiu, com pequenas adaptaes, o reuso da base de dados e do componente Persistence como parte de um mini-sistema de controle de acesso. A primeira adaptao feita foi a adio de um novo elemento ( role) na gramtica de configurao do ProfileTV, conforme Figura 4 -30. Este novo elemento permite que os administradores definam papis ( roles) que um usurio pode assumir dentro do sistema. baseado no papel do usurio que o acesso a reas e operaes do sistema liberado ou bloqueado.
21.... 22. <!-- Role ELEMENT --> 23. <!ELEMENT role (#PCDATA)> 24. <!ATTLIST role category IDREF #REQUIRED> 25. <!-- A role, and only one role, MUST be default --> 26. <!ATTLIST role default (TRUE|FALSE) "FALSE"> Figura 4-30 - Adio do elemento Role na gramtica do ProfileTV

obrigatrio que os papis estejam associados s categorias (categories) do sistema, pois so estas, atravs de suas propriedades, que determinaro as operaes disponveis para o papel associado. O elemento role possui um atributo, denominado default, que indica qual o papel padro do sistema. Este papel ser utilizado sempre que um usurio for criado atravs de um cliente embedded. Se este processo for realizado a partir de um cliente web, fica disponvel para o administrador selecionar qual o papel que melhor se adqe ao usurio em questo. A Figura 4 -31 apresenta um exemplo de configurao de acesso, onde temos um papel (role) de "administrator", no padro (default
FALSE),

associado a uma categoria (category) ADM. As propriedades

73

(property) aninhadas a ADM passam a representar as operaes disponveis para qualquer usurio que possua um papel de administrator.

Figura 4-31 - Exemplo de uso de um Role

A segunda adaptao no sistema foi a adio de um novo atributo (denied) na classe Feature, do componente Persistence. Este atributo permite que um administrador determine
21

se um usurio tem direito de

acesso a uma operao do papel que a contm ou no. Esta adaptao aumenta a capacidade de configurao do sistema, possibilitando que usurios com o mesmo papel possuam diferentes tipos de acesso. Estas duas adaptaes possibilitaram a criao de um controle de acesso baseado em papis de usurios, o RBAC. Desta forma, qualquer ao solicitada pelos clientes web precisa passar pela autenticao e autorizao deste sistema. Isto obriga todos os mdulos disponibilizados como um recurso pelo ProfileTV Server Manager a acionar o Access Controller nas chamadas de seus mtodos pblicos.

4.2.6.2. Session Controller

O Session Controller utilizado para armazenar as sesses de um usurio no sistema. de suma importncia em sistemas que disponibilizam diversos servios, o que no o caso do ProfileTV. Foi adicionado arquitetura para fins de extensibilidade, j que um de seus conceitos permitir que usurios possam ter (1) login nico nos mais diversos servios disponveis e, que ao realizarem um log in em quaisquer dos
21

Este tipo de configurao s pode ser feito com o sistema em produo, pois necessrio que um usurio j tenha sido cadastrado no ProfileTV e que um role j tenha sido associado a este usurio.

74

servios, (2) possam acessar outros sem que precisem logar novamente conhecido como Single Sign-On [92].

4.2.7.

Logging

O componente Logging baseado no Log4J framework [93]. Portanto sua implementao restringe-se configurao dos arquivos (1) commonslogging.properties e (2) log4j.properties. Em (1) definida a classe responsvel pela gerao de logs do servidor de aplicaes e onde se encontra as configuraes desta classe, vide Figura 4 -32.

Figura 4-32 - Configurao do commons-logging.properties

Em (2) configura-se a raiz da cadeia de log22, os tipos de logs, o padro utilizado na gerao do log, o meio de armazenamento/sada. Em casos onde o log precise ser armazenado em bancos, este arquivo deve conter tambm o Driver e a URL de acesso ao banco, o login e o password, bem como o comando SQL para adio de um novo log na base de dados. O ProfileTV Server configura trs tipos de log, um para sada-padro do sistema, outro para arquivo e mais um para banco de dados, vide Figura 4 -33.

22

O Log4J, assim como outros frameworks de log, cria uma cadeia de responsabilidade entre os logs. Desta forma, podem ser empregados vrios tipos distintos de logs dentro de um mesmo sistema.

75

Figura 4-33 - Configurao do log4j .properties

O Log4J framework disponibiliza algumas possibilidades para fazer uso da configurao dentro do sistema. O ProfileTV Server adotou a tcnica que faz uso de um objeto Logger para cada classe que queira logar alguma mensagem durante sua execuo. A classe adquire uma referncia para um Logger atravs da invocao do mtodo esttico Logger
getLogger(Class clazz)

da classe Logger. De posse desta

referncia, basta que a classe invoque um dos vrios mtodos de log disponveis (ex. warn(String msg), error(String msg), info(String msg),
debug(String msg)).

4.2.8.

Persistence

Este componente abriga a representao das categorias e propriedades, perfis e caractersticas, dispositivos, servios, usurios e papis. responsvel pela interao direta com a camada de dados e pelo mapeamento Objeto-Relacional (OR), este ltimo atravs do Hibernate

76

framework [66]. Um macro-diagrama de classes apresentado na Figura 4 -34.

Figura 4-34 - Macro diagrama de classes de Persistence

Todas as entidades deste diagrama de classes, bem como seus relacionamentos foram mapeados em tabelas relacionais atravs de arquivos hbm.xml (hibernate mapping). Estes arquivos so utilizados pelo Hibernate para converter objetos em tabelas e vice-versa.

4.2.8.1. Device
Um Device representa todo e qualquer objeto com o qual o usurio venha a interagir. identificado unicamente pelo seu Serial Number. Para o ProfileTV, so considerados Devices as televises, os set-top boxes, celulares e smartphones com recepo de TV.

77

4.2.8.2. Role
Adicionado ao sistema como parte do componente Access Control. Sua principal funo definir papis que usurios podem assumir dentro do sistema. Esta entidade utilizado pelo sistema de Controle de Acesso descrito na seo 4.2.6

4.2.8.3. Service
Um Service representa todo e qualquer servio interativo que o usurio venha a utilizar. identificado unicamente pela dupla ServiceID (sid), OriginalID (oid). Para o ProfileTV, so considerados Services aplicaes de TVDi, celulares e smartphones, como: ESG (Eletronic Service Guide) e EPG (Eletronic Program Guide).

4.2.8.4. User
Um User representa qualquer usurio do sistema, independente de meio de acesso. Para o ProfileTV, um User um conjunto de caractersticas organizadas por perfis. Desta forma, os dados contidos pela entidade User so simplesmente um login e um password, que permite o acesso ao sistema. telefone. Todas as outras informaes podem ser inferidas das caractersticas associadas aos seus perfis, inclusive seu nome, endereo e

4.2.8.5. Category
As Categories servem como modelos de perfis de usurio, determinando quais so os dados relevantes que devem ser capturados em uma interao. Devem ser dispostas em uma estrutura hierrquica (rvore), a fim de permitir o reuso (herana) de dados das Categories mais genricas (pais) pelas mais especializadas (filhos). No ProfileTV, os dados das Categories so denominados de Property. Estas so criadas atravs de uma fbrica concreta (PropertyFactory) a partir da invocao de um dos dois Factory Methods [75] disponveis, conforme Figura 4 -35. 78

Dentre os argumentos que estes dois mtodos recebem, destacamse as duas enumeraes, PropertyType e o PropertyEntryType: PropertyType define os tipos23 suportados pelas Properties:

BINARY, BOOLEAN, CURRENCY, DATE, NUMBER e TEXT. Esta enumerao

tambm disponibiliza mtodos para validao de valores a partir de expresses regulares. Estes mtodos so invocados pelo sistema em atribuies, recuperaes e sincronizaes de valores. PropertyEntryType subdivide as Properties em (1)

SingleProperty e (2) MultiProperty, onde (1) representa as Properties simples, que podem comportar apenas um nico valor. J as Properties do tipo (2) comportam mltiplos valores de um mesmo tipo (ex. tempo gasto em cada rea).

Figura 4-35 - Assinaturas dos mtodos createProperty

23

O Profiletv fortemente tipado, o que determina que se uma propriedade definida como de TEXT, ser sempre TEXT durante todo o seu ciclo de vida no sistema. Qualquer tentativa de atribuio de um valor de tipo diferente resultar em erro em tempo de execuo.

79

4.2.8.6. Profile
Um Profile a instncia de uma Category e, como esta, tambm possui estrutura hierrquica. So responsveis pelo armazenamento dos dados gerados na interao de usurios com Devices ou Services. No ProfileTV, estes dados capturados so denominados de Features e, assim como os Profiles so instncias de Category, as Features so instncias de Property.

Figura 4-36 Assinatura dos mtodos para criao de Profiles

S possvel criar um Profile se ao menos uma Category est cadastrada no sistema24 e, apenas atravs da Abstract Factory [75] ProfileFactory. Esta fbrica disponibiliza dois mtodos para criao de Profiles, como ilustrado na Figura 4 -36.

4.2.8.7. Utilidades
O pacote de utilidades possui um conjunto de classes que auxiliam na (1) manipulao das entidades, no (2) acesso camada gestora de dados, no (3) mapeamento dos objetos para as tabelas relacionais e, na (4) gerao e (5) controle de ndices de categorias e propriedades. A Figura mostra o diagrama de classes deste pacote. 4 -37

24

Procedimento feito, normalmente, pelos administradores durante a configurao do sistema ou nas atualizaes de uma configurao previamente cadastrada.

80

Figura 4-37 - Diagrama de Classes do pacote Util de Persistence

A interface SequenceGenerator define um mtodo para gerao de ndices pelo sistema. Essa funcionalidade se aplica s entidades que controlam seus ndices por conta prpria, em vez de utilizar a gerao automtica da camada gestora de dados. Na implementao de referncia do ProfileTV esta interface implementada apenas pela classe CategorySequenceGenerator, responsvel pela construo hierarquizada dos ndices das categorias. Esta classe gera os ndices similarmente ao definido pelo padro TvAnytime [52], vide Figura 4 -38.

Figura 4-38 - Exemplo de ndices de Category

A classe DataAccessUtil faz uso do conceito de Thread Local [94] para recuperar conexes livres com a camada gestora de dados. tambm de sua responsabilidade validar e carregar a configurao inicial do mapeamento O-R (objeto-relacional) no sistema, bem como gerar queries de busca de dados a partir de argumentos de configurao. O componente IntEnumUserType foi reusado pelo ProfileTV. O mesmo foi desenvolvido por Benoit Xhenseval, do grupo mantenedor do Hibernate framework [66]. O IntEnumUserType capaz de mapear os 81

elementos de uma enumerao em nmeros inteiros que podem ser entendidos pela camada gestora de dados, e vice-versa.

4.2.9.

Report

O componente Report define vrios tipos de relatrios que podem ser gerados pelo sistema. Utiliza a biblioteca JasperReports [95] para criar, editar e atualizar os relatrios. Disponibiliza alguns relatrios prontos e, permite que o usurio crie seu prprio relatrio a partir de dados previamente cadastrados no sistema. O Report um componente simples, possuindo uma fbrica concreta de relatrios (ReportFactory), que cria componentes responsveis ( Report) pela gerao de relatrios propriamente ditos. A Figura 4 -39 apresenta o diagrama de classes deste componente.

Figura 4-39 - Diagrama de classes de Report

4.3. Camada Gestora de Dados

A camada gestora de dados representada por um SGBD (Sistema Gestor de Banco de Dados), que no caso do ProfileTV Server o PostgreSQL [96], verso 8.2. Este um SGBD open-source de fcil utilizao e com maior confiabilidade que o MySQL [97]. Permite replicao, podendo ser configurado para trabalhar em clusters. Uma base de dados foi criada para o sistema, denominada de ProfileTV-DB. Esta base possui 12 (doze) tabelas, que representam todas 82

as entidades do sistema e seus relacionamentos, bem como 5 (cinco) seqncias para gerao automtica de ndices. A figura abaixo apresenta o diagrama refinado de entidade-relacionamento.

Figura 4-40 - Diagrama E-R Refinado do ProfileTV Server

Note que a entidade Session apresentada no Captulo 3 no est presente no refinamento, pois o controle de sesso no foi desenvolvido na implementao de referncia do ProfileTV.

4.3.1.

Mapeamento O-R

A seo 4.2.8 explicitou que o Hibernate framework [66] o responsvel pelo mapeamento das entidades (Objetos) em tabelas relacionais, Desta forma o mesmo tambm fica responsvel pela organizao e gerao da base de dados, o que torna desnecessria a criao de um Script SQL. Entretanto, alguns relacionamentos so particularmente difceis para serem gerados pelo Hibernate, causando uma complexidade desnecessria na base de dados. O ProfileTV-DB possui alguns

relacionamentos N para M, particularmente entre as entidades User, Profile, Device e Service. O Hibernate, ento, sugere a criao de vrias mini-tabelas, replicando dados de forma desnecessria. Para solucionar este problema, foi necessrio a no declarao do relacionamento nos hbm.xml, para serem efetuados atravs da linguagem HQL (Hibernate Query Language), prpria do Hibernate.

4.4. Padres/Modelos Arquiteturais

A implementao do ProfileTV segue alguns padres/modelos

arquiteturais bem utilizados em engenharia de software. Esta prtica promove reuso de tcnicas bem sucedidas e bem documentadas, facilitando o entendimento e a manuteno do software implementado. A

83

Tabela

4 -5 apresenta os principais padres/modelos 25 empregados,

justificando o seu uso no ProfileTV.

Tabela 4-5 - Padres Arquiteturais do ProfileTV
Pa dr o Mdulo Jus tifica tiv a Os siste madelogs do Profile TV , ta nto nos c lie nte sc omo no se rvidor, utiliza m e stepa dr o afim depe rmitir c ustomiza e s pa rac a dac ompone nte . Al m dos logs, o siste madese gura n ado Pro file TV Se rv e r tra ba lhadeumaforma hie ra quiza da ,e nc a de a ndo re spons ve is e spe c ia liza dos pa ratra ta me nto dec a da ponto dase gura n a . Pa dr o GRASP [122] pa rac ontroledesiste ma s deformac e ntra liza da . Busc ao m ximo dec oe s oc om o mnimo dea c opla me nto. Utiliza do e mc onjunto c om o Ob s e rv e r pe rmitequec a damdulo re a lizese u prprio c ontrolesolic ita ndo a o c ontrolec e ntra la pe na sa c e sso are c ursos. Esteo pa dr o/ mode lo utiliza do pe lo fra m e w o rk (Struts) e mpre ga do na c onstru o daa plic a ow e b. Estepa dr o pe rmitequeos c ontrola dore s ou a m ae xe c u o do siste mae , qua ndo houve r ne c e ssida de , inte rve nha m ne steproc e sso. Fa mliademode los utiliza danaa ute ntic a o deusu rios ea utoriza o de ope ra e s pe los me smos. e mpre ga dano Profile TV c omo formadepre ve nir a c e sso n oa utoriza do s ope ra e s-c ha ve s do siste ma . Pa dr oc omume nteutiliza do pa rape rc orre r rvore s. No Profile TV e mpre ga do nainte rpre ta o dea rquivos XML a tra v s dabibliote c aJ DOM [114].

Cha in Of Em b e d d e dClie nt/ Re s pons ibility Se rv e r

Controlle r

Em b e d d e dClie nt/ Se rv e r Se rv e r Em b e d d e dClie nt/ Se rv e r Se rv e r

MVC Obs e rve r RBAC

Vis itor

Se rv e r

4.4.1.

Chain Of Responsibility

Este padro aplicado em diversas situaes, como aplicao de filtros (ex. Servlet Filters [98]), serializao de dados em middleware (ex. sinks em .NET Remoting [99] e handlers em Web Services [100]), gerao de logs e, tratamento de excees em OO (ex. Java). Neste ltimo caso, permite-se ao desenvolvedor criar excees especficas para sua aplicao e adicion-las cadeia de responsabilidade padro da tecnologia. uma tcnica de tratamento de falhas que visa garantir a correta execuo do programa. No ProfileTV, o padro comportamental Chain of Responsibility aplicado na gerao de logs nas camadas de front-end e de negcios. Em ambas, o sistema de logging permite a customizao e encadeamento de diferentes geradores de log. Esta caracterstica aumenta sensivelmente a manutenibilidade do sistema, j que cada componente pode empregar diferentes nveis de logging e diferentes meios de sada.
25

Outros padres/modelos so empregados na implementao do sistema, contudo no foram aqui explicitados por serem muito comuns na elaborao de softwares orientados a objetos, como Singleton, Facade, Factory Methods e Adapter [75].

84

Alm

de

ser

empregado

na

gerao

de

logs,

Chain

of

Responsibility determinante para a segurana no ProfileTV Server, onde cada elemento de uma cadeia de responsabilidade responsvel especificamente por determinada situao. Se o elemento invocado no conseguir tratar o problema, dever repassar para o prximo elemento da cadeia at que uma soluo seja dada ou que todos os elementos da cadeia tenham sido aplicados. O padro Chain Of Responsibility aplicado na segurana do ProfileTV Server similar ao empregado no tratamento de excees. Entretanto, para este caso, apresenta algumas adaptaes: segurana pr-ativa: um elemento da cadeia de

responsabilidade atua no tratamento de um problema sem a necessidade explcita de sua invocao. necessrio empregar o padro Observer em conjunto nesta soluo; aplicao parcial da cadeia: no h a obrigatoriedade de se

aplicar a cadeia por completo. Um elemento s deve invocar o prximo na cadeia se e somente se sua regra de tratamento falhar.

4.4.2.

Controller

Os Controllers so responsveis por lidar com eventos do sistema, realizando um caso de uso ou representando a interface de um sistema (Facade). No ProfileTV existem diversos Controllers, agindo sob estes dois aspectos. No ProfileTV Embedded Client Side Middleware , existem dois Controllers, um no subcomponente Communication e outro no I/O. Em ambos os casos, esto embutidos nas fbricas concretas que geram os Workers especializados. Estas fbricas s retornam um Worker se, e somente se, o pool do tipo de Worker solicitado no estiver vazio. Alm disso, mantm uma referncia para cada Worker gerado, o que lhes permite interceder diretamente no processo de execuo dos mesmos, podendo at termin-los se houver esta necessidade.

85

Quanto ao ProfileTV Server, este possui mdulos autnomos, onde cada um destes precisa (1) gerenciar seus componentes internos, (2) mediar requisies a componentes externos e (3) controlar o acesso aos seus componentes internos. Desta forma, cada mdulo possui um Controller [75] que desempenha basicamente estas funes, contudo dois mdulos possuem controladores com mais responsabilidades: Security System: o seu Controller tambm responsvel pela

(1) criao das cadeias de responsabilidade, (2) assumir o papel de coordenador das aes tomadas pelas cadeias e, (3) atuar sempre como o ltimo nvel de todas as cadeias criadas; Manager: este o principal Controller do ProfileTV Server, sendo responsvel pela criao de todos os mdulos e

tambm

componentes do sistema, ouvir alguns processos (ex. processos de comunicao e parsing), e despachar as requisies que o alcancem para os mdulos responsveis. No ProfileTV Server, este padro deve ser normalmente utilizado em conjunto com outros padres, como o Facade, o Singleton e o Observer [75] (ex. Security System e ProfileTV Server Manager). Esta associao empregada quando h a necessidade de que o Controller seja a nica interface do mdulo, bem como impedir a criao de mais instncias suas.

4.4.3.

Model-View-Controller (MVC)

O modelo MVC [101] tem suas razes em Smalltalk [102] [103], constituindo-se atualmente em um dos padres mais empregados na concepo de sistemas multicamadas. O MVC est presente em vrios frameworks, como o caso do Struts [104] [105], empregado no ProfileTV Server. Este padro arquitetural separa a (1) os dados (model) de sua (2) apresentao (view), o que permite o uso de mltiplas vises compartilhando um mesmo modelo de dados. Tal separao alcanada introduzindo-se um componente entre as duas camadas, o Controller. Este fica responsvel pelo controle, identificao e notificao de alteraes 86

tanto na view como no model. O funcionamento do MVC pode ser visto na Figura 4 -41.
Model Model
Notificao de Mudana Seleo de View

Requisio de Estado

Mudana de Estado

View View
Sinalizao de usurio Invocao de Mtodos Eventos

Controller Controller

Figura 4-41 - Modelo MVC

4.4.4.

Observer

O padro Observer define uma dependncia one-to-many entre objetos de forma que quando um objeto mudar seu estado, todos os seus dependentes so notificados e atualizados automaticamente [75]. Os Controllers do ProfileTV, tanto do Server como do Embedded Client, tambm so Observers, ouvintes de seus componentes dependentes.

4.4.5.

Role-Based Access Control (RBAC)

RBAC [106] uma famlia de modelos de referncia, na qual privilgios so associados a papis e estes so associados a usurios [107]. Foi apresentado por Ferraiolo e Kuhn [108] em 92, mas seus conceitos j vinham sendo estudados desde os anos 70. Este modelo arquitetural de autenticao e autorizao foi escolhido por se adaptar facilmente a arquitetura proposta do ProfileTV.

4.4.6.

Visitor

Este padro muito utilizado em operaes de interpretao de dados (ex. fase de parsing em compiladores), j que permite que operaes sejam realizadas em objetos sem que suas classes sejam alteradas. Desta forma, o componente Parsing do ProfileTV Server, ao utilizar a biblioteca 87

DOM4J [87] de manipulao de XML, aplica indiretamente este padro arquitetural sem adaptaes.

4.5. Bibliotecas e Frameworks

Similarmente como os padres e modelos, o ProfileTV emprega em sua implementao bibliotecas e frameworks bem sucedidos em vrios sistemas, com o objetivo de promover o reuso e a manutenibilidade do sistema. importante ressaltar que, excetuando a biblioteca BlueCove, todas as outras bibliotecas e frameworks descritos nesta seo so empregados no ProfileTV Server, j que, por ser um componente do middleware MHPIRT, a implementao de referncia do ProfileTV Embedded Client Side Middleware est sujeita s restries do ambiente ao qual est inserido. As bibliotecas e frameworks utilizados so: Hibernate Framework [66]: dentre outras opes (ex. ADO

.NET [109], JDO [110] e EJB [111]) para o mapeamneto ObjetoRelacional, o Hibernate foi escolhido por melhor se (1) adaptar ao sistema, alm de ser um framework (2) estvel e, com ampla (3) documentao. Log4J Framework [93]: a escolha do Log4J framework para

criao de logs no ProfileTV Server se deu pela sua (1) maturidade, (2) adaptabilidade a diversos ambientes de desenvolvimento e produo, (3) flexibilidade quanto ao I/O do log (ex. sada padro, arquivo, base de dados), (4) amplo suporte (ex. fruns, listas de discusso, tutoriais) e (5) facilidade de utilizao. Struts Framework [104] [105]: dentre outras opes (ex. JSF para o controle de apresentao web, o

[112], ASP .NET [113])

Struts foi escolhido por oferecer vrios (1) elementos prprios para controlar o fluxo de execuo, (2) adaptao s bibliotecas empregadas no sistema, (3) ampla documentao e (4) facilidade de utilizao. 88

Biblioteca

BlueCove

[114]:

nica

biblioteca

externa

implementao de referncia do middleware MHP a ser utilizada na implementao do ProfileTV Embedded Client Side Middleware. A BlueCove uma biblioteca Java para Bluetooth implementada a partir da JSR-82, que d suporte as interfaces Mac OS X, WIDCOMM, BlueSoleil (utilizada nesta implementao) e a pilha Bluetooh do Windows XP SP2. Biblioteca DOM4J [87]: em estudos comparativos com outras

bibliotecas de manuseamento de XML [115] [116], o DOM4J apresentou resultados satisfatrios, unindo bom desempenho com padronizao e implementao funcional. A concluso destes testes e sua similaridade com o JDOM [117], a credenciaram para ser utilizada no ProfileTV Server. Biblioteca JasperReports [95]: uma biblioteca open-source

para a gerao de relatrios na plataforma Java. Unida com seu complemento visual, a biblioteca open-source IReports [118], foi escolhida para ser empregada no ProfileTV Server, em detrimento a outras solues, pagas ou no (ex. Crystal Reports [119]).

4.6. Interfaces e Integraes

O ProfileTV possui vrias interfaces externas e internas ao sistema. atravs destas interfaces que os componentes internos interagem entre si e, que as requisies dos clientes alcanam o servidor para serem processadas. A Tabela 4 -6 apresenta as interfaces existentes no ProfileTV, os mdulos e componentes a que pertencem, se externas (E) ou internas (I), alm de uma breve descrio de cada.
Tabela 4-6 - Interfaces do ProfileTV

89

Inte rfa ce

Mdulo Se rv e r/ ISe a rch Se rvice Clie nt ISy nchroniza tion Se rv e r/ S e rv ice Clie nt Se rv e r/ IUpda teSe rv ice Clie nt My ProfileWS Se rv e r

Com pone nte Tipo Te cnologia Co m m unic a tio n E Ja vaRMI Wo rke r Co m m unic a tio n E Ja vaRMI Wo rke r Co m m unic a tio n E Ja vaRMI Wo rke r Co m m unic a tio n Wo rke r E

De s cri o Pe rmiteare c upe ra o dec a te goria s epe rfis.

ICom m unica tion Clie nt Lis te n e r IIOWorke r IProfile TV Ma na ge r IRe m ote Pe rs is te nce IPe rs is te nce Controlle r IAcce s s Controlle r Clie nt Se rv e r Se rv e r

Co m m unic a tio n

I/ O Pro file TV Ma na g e r Pe rs is te nc e

I I I

I mple me ntao protoc olo desinc roniza o depe rfis. Disponibilizam todos pa rac ria oe a tua liza o depe rfis. I nte rfa c equec omportatoda sa s JAX-RPC func iona lida de s da s 3a nte riore s, por m disponibiliza -a sa tra v s dese rvi ow e b. Entida de s queaimple me nte m pode m se c a da stra r pa raouvir e ve ntos oriundos da Ja va troc ademe nsa ge ns e ntreo c lie ntee se rvidor. De fineos m todos dee xporta oe Ja va importa o depe rfis. Ja va Ja va Prova c e sso a os c ompone nte s do siste ma . Vis o do c ompone ntePe rs is te nc e utiliza da pe lo mdulo Co m m unic a tio n. Vis o do c ompone ntePe rsiste nc e disponibiliza dapa ratodos mdulos/ c ompone nte s do My Pro file Se rv e r, e xc e to o mdulo Co m m unic a tio n. Disponibilizam todos pa rave rific a o de a ute ntic a o deusu rios ea utoriza o de a c e sso afunc iona lida de s.

Se rv e r

Pe rs is te nc e

Ja va

Se rv e r

Ac c e s sCo ntro l

Ja va

4.7. Dificuldades
Durante a implementao de referncia do ProfileTV surgiram alguns desafios que precisaram ser solucionados. Esta seo descreve os dois mais importantes.

4.7.1.

Adio do Embedded Client no MHP-IRT

Como tornar a API do ProfileTV Embedded Client Side Middleware disponvel s aplicaes que executem sobre o MHP-IRT? A resposta para esta questo s foi alcanada aps um estudo aprofundado da verso do middleware MHP-IRT disponvel. Foi preciso adicionar a biblioteca do ProfileTV ao processo de boot do sistema, e garantir o acesso ao sistema de arquivos do middleware e a algumas propriedades do sistema.

90

4.7.1.1. Adio ao Boot do MHP-IRT

Foi criado um Fat JAR (Java Archive) para distribuir o ProfileTV Embedded Client Side Middleware, incorporando um JAR com algumas classes do ProfileTV Server (interfaces do componente Communication e os wrappers do Persitence) e o prprio JAR do cliente. Alm disso, foi necessrio selar alguns pacotes para impedir que fossem disponibilizados s aplicaes. O prximo passo foi adicionar este JAR ao boot do MHP-IRT, que feito atravs dos arquivos mhp.bat e mhp11.bat. Esses so arquivos de programao em lote que acessam variveis de ambiente do Windows, alm do sistema de arquivos para configurar o sistema antes de executlo. Adicionou-se varivel de ambiente RICLASSPATH o caminho do ProfileTV.jar e a configurao estava pronta.

4.7.1.2. Permisses
A poltica de segurana do MHP-IRT feita atravs de arquivos RIBoot*.pol. Na verso utilizada, existem dois destes arquivos, um que garante acesso a todos os recursos do sistema e utilizado no modo Debug do middleware. O outro utilizado no modo Release e restringe o acesso de algumas reas do sistema apenas a aplicaes certificadas 26, tendo sido necessrio alter-lo, como apresentado a seguir.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
26

# Garante total acesso aos recursos do sistema para o ProfileTV.jar grant codeBase "file:%RUNTIME%lib/ProfileTV/ProfileTV.jar" { permission java.security.AllPermission; }; # Garante s aplicaes acesso a classes de pacotes do ProfileTV.jar grant codeBase "file:%RUNTIME%fileio/dsmcc/-" { permission java.lang.RuntimePermission "accessClassInPackage.ufpe.cin.profiletv.communication"; permission java.lang.RuntimePermission "accessClassInPackage.ufpe.cin.profiletv.communication.event"; permission java.lang.RuntimePermission "accessClassInPackage.ufpe.cin.profiletv.io"; permission java.lang.RuntimePermission "accessClassInPackage.ufpe.cin.profiletv.logging"; permission java.lang.RuntimePermission "accessClassInPackage.ufpe.cin.profiletv.persistence"; permission java.lang.RuntimePermission

O MHP-IRT tem uma ferramenta para certificar uma aplicao, o IrtAppSigner.

91

"accessClassInPackage.ufpe.cin.profiletv.persistence.key"; 14. }; Figura 4-42 - Alteraes na poltica de segurana do MHP-IRT

4.7.2.

Comunicao Cliente-Servidor

O problema principal foi harmonizar as duas formas distribuio (XML-RPC e Java RMI) para utilizarem a mesma infra-estrutura, sem que houvesse perca de suas vantagens. Como explicitado na seo 4.2.2, foi necessrio escolher a forma de distribuio mais restritiva para criao dos adaptadores. Alm disso, foi necessrio o desenvolvimento de um tradutor das classes do componente Persistence para seus adaptados do componente Communication e viceversa. Esta traduo pode ser ilustrada atravs dos elementos Tombstone [120] a seguir.
PO JVM CO CO JVM PO

Onde, PO = Persistence Objects e CO = Communication Objects

Figura 4-43 - Elementos Tombstone de traduo

4.8. Consideraes
Este captulo aprofundou a viso lgica apresentada no captulo 3, ilustrando com diagramas de classes, trechos de cdigo e excertos de arquivos de configurao, as funcionalidades desenvolvidas para a implementao de referncia do ProfileTV. Seguindo o modelo proposto por Kruchten [32], a viso de implementao do sistema foi apresentada e, dentro desta, foram discutidas as escolhas dos padres/modelos, bibliotecas e frameworks empregados no desenvolvimento. Alm disso, foram discutidas solues encontradas para problemas resolvidos, bem como sugeridas alternativas para problemas parcialmente resolvidos.

92

A seguir sero apresentados os experimentos realizados sobre a implementao de referncia descrita neste Captulo 4.

93

5.Captulo Experimentos
O nico lugar aonde o sucesso vem antes do trabalho no dicionrio. - Albert Einstein

Este captulo apresenta os experimentos realizados para validao do sistema proposto por esta dissertao, o ProfileTV. Os desafios levantados (definio do contexto, captura das informaes, exportao de dados, espao de armazenamento e escalabilidade) durante o desenrolar desta dissertao so discutidos atravs da demonstrao de resultados discutido e clculos de extrapolao. captulo. Os O desafio de espao de armazenamento, por estar atrelado a vrios aspectos do sistema, durante todo outros desafios, incluindo escalabilidade, so discutidos em sees separadas.

5.1. Ambiente dos Experimentos

A Tabela 5 -7 apresenta o ambiente utilizado nos experimentos realizados na implementao de referncia do ProfileTV. Logo a seguir apresentado o hardware cliente e o dispositivo porttil.
Tabela 5-7 - Ambiente de Desenvolvimento e Testes do ProfileTV
Se rv idor Inte l Core2 Duo E4500 Ha rdw a re 2.2GHz 2GB RAM Windows XP Profe ssiona l SO Se rvic ePa c k2 JRE 1.6 Tomc a t 5.5 Softw a re Struts 1.1 J2EE 1.4 SGBD Postgre SQl 8.2 Clie nte Note book STI I nte l Pe ntium Ce ntrino de 1.7Ghz Dis pos itiv o Port til Ce lula r Nokia5220 c om c a rt o mic ro SD de 256MB, e xpa nsve la t 2GB Pe n-Drivede256MB

1Gb RAM Windows XP Profe ssiona l NA Se rvic ePa c k2 MHP-I RT 1.0.3 J RE 1.4.2 (modific a da pe lo prprio MHP-IRT) NA Blue c ove2.0.2 Blue Sole il 2.7.0.8

94

(a) Notebook STI + MHP-IRT (Simula um Set-top Box)

(b) Nokia 5200 e antena Bluetooth

Figura 5-44 - Ambiente Cliente

5.2. Configurao do ProfileTV

Configurar o ProfileTV , na realidade, o desafio de definir o contexto do sistema. O administrador do sistema tem de se preocupar em levantar as informaes relevantes para cada tipo de interao que queira coletar dados. Basicamente, deve-se responder as perguntas que definem as cinco dimenses semnticas: quem, onde, o que, quando e por qu?

Figura 5-45 - Definio Contextual dos Servios Interativos Testados

95

Na implementao de referncia do ProfileTV a definio do contexto feita atravs de arquivos xml, seguindo a DTD de mapeamento profiletv-mapping. Para os testes, foram definidas algumas categorias de dispositivos, servios interativos e caractersticas pessoais de cada usurio. A Figura se no Apndice A. Uma funcionalidade essencial do sistema fornecer uma forma de entrada desta configurao no sistema. Assim, foi criada uma interface web em Struts. A Figura 5 -46-(a) abaixo apresenta o upload do contexto na base de dados e a Figura 5 -46-(b) um screenshot da base de dados aps a operao. 5 -45 acima mostra os dados a serem coletados nos servios interativos experimentados. A configurao 27 completa encontra-

(a)

(b)

Figura 5-46 - Definio do Contexto para os Experimentos

27

Esta definio de contexto foi criada baseando-se na representao contextual para sistemas de Televiso Digital Interativa apresentados por Goularte [52] em sua tese de doutorado.

96

Em relao ao desafio de espao de armazenmanto, a configurao apresentada no Apndice A criou no sistema 16 Categorias, ocupando um espao de 32KB, e 56 propriedades, ocupando um espao de 184KB. Somadas alcanam um total de 216KB. Se assumirmos que fabricantes (ex. Sony, Philips, Panasonic, Toshiba, Scientific Atlanta, RCA) de set-top boxes e televises digitais interativas queiram cadastrar no sistema em mdia 10 novos modelos ao ano e considerando cerca de 20 fabricantes, teramos um total de 200 novas Categorias filhas de Set-top Boxes e 200 novas de Televiso Digital Interativa. Assim, se para cada Categoria temos um ocupao mdia de 2KB (32KB / 16) em um ano, considerando os tais lanamentos, teramos um aumento de aproximadamente 800KB em Categorias relacionadas a dispositivos interativos. Podemos utilizar o mesmo raciocnio para servios interativos. Desta forma, se assumirmos cerca de 120 canais 28 e que cada um destes queira criar 4 (quatro) aplicaes interativas por ano29, teramos um aumento anual de aproximadamente 960KB de espao utilizado. Temos ainda de considerar as propriedades, responsveis pela granularidade do contexto desejado. Aplicando mais uma vez o raciocnio (216KB / 56 propriedades = 3.9KB/p) e extrapolando uma mdia de 10 propriedades para cada nova categoria criada 30, chegamos a aproximadamente 39KB de propriedades para cada nova Categoria criada. Nos clculos anteriores assumimos 880 novas categorias por ano, o que nos levaria a um aumento de 34.320KB de propriedades por ano. Somando-se categorias e propriedades teramos uma evoluo de 36.040KB ao ano, o que para as capacidades atuais de armazenamento de dados em servidores um valor irrelevante.
28

Esse nmero retrata a quantidade de canais provida pelas televises por assinatura. Este em particular foi retirado da SKY, atuante no Brasil desde 1996, e condizente com outras operadoras como a NET 29 Esse um valor maior do que a atual mdia brasileira, onde apenas a Rede Globo cria aplicaes interativas a uma mdia 3 ao ano (Globo News e Ana Maria Braga em 2005, Copa do Mundo em 2006, Carnaval e Pan Americano em 2007 e nenhuma at Julho de 2008) 30 Esse um nmero que extrapola em muito a quantidade mdia de dados considerados relevantes. Afinal, basta consideramos que a hierarquizao das Categorias permite o reuso de propriedades, e veremos que medida que descemos na rvore a quantidade de propriedades novas diminui.

97

Vale ressaltar que a definio de contexto no algo esttico e pode haver mudanas com o decorrer do tempo, contudo sem alterar drasticamente os clculos apresentados acima.

5.3. Criao de Perfis

Neste experimento foi executada uma rotina que cria 10000 usurios, 150 servios interativos e 40000 dispositivos, totalizando uma mdia de 4 dispositivos para cada usurio. Alm da adio de dados base tambm foram executadas operaes de busca por categorias e criao de perfis de telespectadores com foco no campo pessoal e na interao com dispositivos e servios. A Figura 5 -47 apresenta uma estatstica da base de dados aps este teste.

Figura 5-47 - Estatsticas das Tabelas do Banco

Em relao ao desafio de espao de armazenmanto, pode-se perceber que a tabela com mais acessos a de Feature, justamente pela de busca de categorias e da criao de perfis de usurios. Somando o espao em disco utilizado pelas tabelas de Feature, de FeatureValues e de Profile temos um total de 4281MB, aproximadamente 4.3GB, em 9.570.426 tuplas inseridas ou uma mdia de 0,4473KB, aproximadamente 0,5KB, por tupla. Isoladamente temos que cada tupla de Feature ocupa em mdia 0,97KB, aproximadamente 1KB, cada tupla de FeatureValues ocupa em mdia 0,055KB, aproximadamente 0,06KB, e que cada tupla de Profile ocupa em mdia 0,1KB. Baseado nestes dados podemos extrapolar o teste tomando as seguintes premissas: 98

elevar o nmero de usurios para 1 milho; manter a mdia de 4 dispositivos interativos por usurio, bem

como a mdia de 20 servios interativos anuais, dos quais 20% (4 servios) executam ao menos em 2 (dois) dos dispositivos do telespectador; assumir que cada Profile (P) tem em mdia 1,7 Feature (F) ou

aproximadamente 2 Features; assumir que cada Feature tem em mdia 1 FeatureValue (FV).

Com este novo cenrio podemos realizar o seguinte clculo: (28P x 0,1KB) + [(28P x 2F) x 1KB] + [(28P x 2F) x 1FV x 0,06KB] x 1 milho de usurios (2,8KB + 56KB + 3,36KB) x 1 milho de usurios = 62.160.000KB O resultado desta operao nos d aproximadamente 62GB de informao. Tendo-se em vista que a maior operadora de televiso por assinatura do Brasil possui pouco mais de 1,5 milho de usurios digitais interativos e, principalmente se levarmos em considerao a taxa de 4 novas aplicaes ao ano e de que os usurios troquem ou adquiram ao menos um novo aparelho interativo ao ano, este um valor plenamente aceitvel, uma vez que 62GB cabem em qualquer hard-disk dos PCs atuais, e em servidores que possuem terabytes de espao representa em mdia pouco mais de 5% do espao total disponvel.

5.4. Aplicaes de Teste

Para demosntrar a utilidade do ProfileTV, algumas aplicaes foram criadas para testes (ex. Seletor de Canais) e outras reutilizadas (ex. Campeonato Brasileiro, Portal da Globo, Pan Americano). Em todas, o foco dos testes foi a apresentao do contedo. Para que as aplicaes pudessem ser executadas, elas precisam ser adicionadas ao arquivo de configurao do MHP-IRT, vide Figura 5 -48.
# This file contains the list of built-in applications that are shown when # the MHP RI is started. These applications may reside on the local file # system or on the network (transport stream, internet, etc.). #

99

# The format is as follows (entries in brackets [] are optional): # <class name>[;<app id>[;<org id>]] = <application name>[;<service locator>[;<application locators>[;<application args>]]] # # the <app id> / <org id>, when not specified, is 1 / 1 # the <service locator>, when not specified, is dvb://0.0.0 # the <application locators>, when not specified, is <service locator> # the format for the <application locators> is plain URLs separated by spaces # the format for the <application args> is a set of strings separated by space; # if you need to enclose a space in an application argument escape it by a "\\" # all digits are hexadecimal (e.g. app id, org id, locator parts) ###### ProfileTV Tests ### Pan Americano ufpe.cin.profiletv.application.pan.PanXlet;400;9 = Pan American Games;dvb://0.0.5/TVD-PAN/bin ### Brasileiro 2007 MainXlet;401;9 = Campeonato Brasileiro;dvb://0.0.4/TVD-Brasileirao/bin ### Seletor de Canais ufpe.cin.profiletv.csel.ChannelSelector;402;9 = de Canais;dvb://0.0.4/CSel ### Ajuda br.org.cesar.aplicacaoAjuda.AjudaXlet;403;10 = Ajuda;dvb://0.0.4/bin ### CesarTVD br.org.cesar.cesartvd.CesarTVDXlet;404;10 = CESARTVD;dvb://0.0.4/bin ### SaudeCesar br.org.cesar.saudeCesar.ObesidadeXlet;405;11 = Obesidade;dvb://0.0.4/bin

ProfileTV: Rio 2007 ProfileTV: ProfileTV: Seletor ProfileTV: ProfileTV: ProfileTV:

Figura 5-48 - Configurao de Aplicaes do MHP-IRT

As modificaes realizadas em todas as aplicaes foram similares. Desta forma, a subseo a seguir explica as modificaes realizadas apenas na aplicao do Pan Americano, a fim de no tornar o texto repetitivo.

5.4.1. Pan Americano

O Pan Americano foi uma aplicao criada pelo C.E.S.A.R. durante a realizao dos jogos Pan-Americanos de 2007 no Rio de Janeiro. Esta aplicao foi ao ar em carter de testes na Rede Globo de So Paulo. Algumas poucas alteraes foram necessrias nesta aplicao para que a mesma utilizasse a API fornecida pelo ProfileTV Embedded Client Side Middleware, mantendo a caracterstica de que um middleware deve simplificar a programao de aplicaes distribudas: 100

A classe PanXlet teve em seu mtodo initXlet acrescentada uma

chamada fbrica de entrada e sada do ProfileTV, IOFactory. Atravs desta fbrica adquirida uma instncia de um Worker via USB. com este Worker que se recupera o perfil desta aplicao: Pan. A Figura 5 -49 apresenta este mtodo e extenso feita;

Figura 5-49 - Mtodo initXlet

Na classe PanMain foram acrescentados os mtodos privados

updateElapsedTime, getPreference e getPreferredArea, conforme .

Alm de algumas modificaes nos mtodos keyPressed, destroy e no construtor PanMain.

101

Figura 5-50 - Mtodos Inseridos na classe PanMain

Estas alteraes foram suficientes para fazer com o que a aplicao identificasse em qual sua o telespectador gastava mais tempo. A partir destes dados, logo na sua prxima execuo a aplicao j entrava na rea preferida. importante explicitar que para este teste no foi solicitado o perfil via Java RMI, sendo utilizado um perfil previamente exportado e armazenado em um pen-drive. O teste consistiu em executar a aplicao do Pan-Americano passando de 2 a 5 minutos em cada rea da aplicao (Notcias, Sobre o Pan, Mural, Medalhas e Agenda). Aps esta primeira execuo, saa-se da 102

aplicao e re-executava-a. A aplicao sem personalizao simplesmente abriria na tela de Notcias (cf. Figura 5 -51-(a)), que a principal telada da aplicao. J com o ProfileTV fornecedendo a infra-estrutura para personalizao, a aplicao carrega o perfil do pen-drive e identifica que a rea de preferncia do usurio o quadro de medlhas (durante a primeira execuo gastou-se 5 minutos nesta rea) e carrega diretamente nesta rea, conforme Figura 5 -51-(b).

(a)

(b)

Figura 5-51 - Aplicao do Pan-Americano

5.4.2. Demais Aplicaes

As demais aplicaes sofreram alteraes similares ao Pan-Americano, j que em sua maioria possuem contedos divididos por rea. Segue a lista de aplicaes testadas: Simulador de seleo de canais: baseada em um exemplo

fornecido pela distribuio do prprio IRT; Campeonato brasileiro de futebol: criado por um grupo de

alunos do Centro de Informtica da Universidade Federal de Pernambuco na disciplina de TV Digital. Esta aplicao utilizou a operao de busca pela categoria associada via Java-RMI, em vez da busca em pen-drive: 2.2 Pan-American Games. Assim como na aplicao do Pan Americano, os testes do Campeonato Brasileiro foram focados no tempo gasto em cada rea da aplicao. A Figura

103

5 -52-(a) apresenta a rea mais visualizada pelo telespectador, Artilheiros; Portal da Rede Globo: uma das primeiras aplicaes de testes

criadas no C.E.S.A.R. Esta aplicao foi utilizada para exportar o perfil criado para o celular em questo, Nokia 5200 (cf. Figura 5 -52(b)). A exportao foi feita atravs de Bluetooth ao se apertar o boto verde do emulador.

(a)

(b)

Figura 5-52 - Aplicaes de Teste do ProfileTV

5.5. Exportao de Perfis

Apesar de ser uma funcionalidade Importante (cf. seo 3.3) este era um dos desafios elencados para a dissrtao. Para tanto foram desenvolvidas duas formas de exportao de perfis: via USB e via Bluetooth. Em ambos os casos foram exportados os perfis relacionados s aplicaes descritas na seo 5.4. Para as operaes de exportao utilizado um arquivo de propriedade anexo ao sistema, facilitando a manuteno dos dados a serem utilizados. Neste arquivo encontram-se determinadas as portas USB do dispositivo e a extenso utilizada no arquivo gerado. Para os testes foi utilizada a extenso ptv (cf. Figura ProfileTV. Nas exportaes via USB foi utilizado um pen-drive de 256MB plugado na porta USB M: da mquina cliente. Para descobrir em qual 104 5 -53), que um acrnimo para

driver est disponvel a porta USB, utilizado um arquivo de propriedades, conforme Figura 5 -53. Este tipo de exportao simples, j que para o sistema o dispositivo porttil plugado em uma porta USB tratado como um driver de armazenamento.

Figura 5-53 - Arquivo de propriedades io.properties

Nas exportaes via Bluetooth foi utilizado uma mini-antena Bluetooth USB e um celular Nokia 5200 como dispositivo porttil. Em um ambiente real, o dispositivo interativo deve possuir embutida uma antena receptora e emissora Bluetooth. Para este teste, utilizou-se o software BlueSoleil (cf.Figura 5 -54) para efetuar a pesquisa e descoberta do dispositivo, bem como o envio do perfil. Isto foi possvel atravs da biblioteca open source BlueCove, que faz uso deste software em suas operaes.

Figura 5-54 - BlueSoleil com Dispositivo Bluetooth Encontrado

Em relao ao desafio de espao de armazenamento, em ambos os casos, os dados exportados foram muito pequenos: no celular, onde o tamanho do bloco de dados menor, o maior perfil ocupa apenas 1,5KB e o menor cerca de 0,5KB; no pen-drive estes mesmos perfis ocupam 2KB e 1KB respectivamente. Se extrapolarmos estes dados seguindo o raciocnio apresentado na seo 5.3, temos que:

105

Assumamos que perfis mais complexos ocupem 5 (cinco) vezes

mais espao que os apresentados nos testes, tem-se perfis de no mnimo 5KB e no mximo de 10KB; Consideremos que o telespectador utilize cerca de 5

dispositivos interativos ao ano: 2 celulares e 3 pares de set-top boxes com televisores digitais. Temos um total de 25KB a 50KB; Consideremos que o telespectador interaja com cerca de 50%

dos servios interativos disponibilizados pelas emissoras. Tomando como base o nmero de 4 aplicaes interativas ao ano por canal, exposto na seo 5.3., temos 2 aplicaes interativas ao ano. Devemos considerar tambm que o telespectador tem uma preferncia de programao e que provavelmente no assiste a todos os canais disponveis. Assumamos para o clculo um uso de 75% dos canais, ou seja, 90 canais. Calculando, temos 180 servios interativos ao ano, que alcanam aproximadamente 900KB no mnimo e, no mximo 1.8MB; Somando-se servios interativos mais dispositivos o espao

necessrio para armazenamento varia entre 925KB e 1.85MB ao ano, teramos em 10 anos (tempo de vida til de um televisor) uma variao entre 9.25MB e 18.5MB. Considerando que a capacidade de armazenamento porttil j atinge 32GB (ex. iPhone) nos aparelhos top de linha, e dos prprios 256MB disponvel no aparelho Nokia 5200 utilizado no teste, este intervalo plenamente aceitvel.

5.6. Escalabilidade
Discute-se nesta seo o problema de escalabilidade no contexto do ProfileTV, baseando-se nos experimentos realizados e na experincia adquirida. O ProfileTV prope que dados privados do telespectador sejam sempre guardados localmente e que todos os dados relevantes sejam armazenados em dispositivos portteis. Contudo o sistema permite 106

tambm que alguns dados (pblicos) sejam armazenados em uma estrutura servidora. Ao se armazenarem dados localmente e/ou em dispositivos

portteis, contribui-se para o controle da escalabilidade do sistema, j que esta operao diminui consideravelmente a quantidade de informao trafegada entre cliente e servidor, bem como o nmero de requisies a serem tratadas pelo sistema de retaguarda. Contudo esta reduo ataca apenas as requisies de insero, recuperao e sincronizao de perfis no sistema. Operaes de busca por categorias, dispositivos, servios e at mesmo perfis no so afetadas por esta caracterstica do sistema. Isto nos leva a ponderar onde o sistema ser empregado. Esta uma questo interessante, pois se o ProfileTV for empregado em operadoras de televiso por assinatura, muito do problema de escalabilidade estar resolvido, j que estas empresas possuem diversos servios (ex. cadastros dos assinantes, sistema de relacionamento com o cliente) que necessitam de um sistema de retaguarda escalvel. Logo, o modelo clssico (ex. mais mquinas servidoras, mais base de dados, mais espao de armazenmanto, mquinas redundantes) para resoluo deste problema pode ser empregado sem onerar os custos das empresas, pois como foi comprovada nos testes, a quantidade de dados gerados por telespectador baixo. No entanto, analisando o emprego do ProfileTV na transmisso aberta de Televiso Digital Interativa, o problema da escalabilidade volta e traz consigo o problema de como ser feito o controle e coordenao do sistema: (1) por uma nica transmissora e logo decorre a questo se as outras transmissoras aprovariam que seus dados fossem acessveis por suas rivais; (2) por todas transmissoras atravs de uma rede compartilhada e advm o problema de como prover tal rede: atravs de um rgo regulador que controlar o acesso ao sistema e tem-se outro problema de mbito poltico que est fora do escopo desta dissertao. O que se pode perceber que para se empregar o ProfileTV no mercado aberto necessitaria resolver primeiramente o problema de controle e 107

administrao do sistema ou remover a camada servidora e adaptar o cliente para que trabalhe isoladamente. O segundo cenrio tem grande impacto no ProfileTV e na gama de servios que daria suporte, j que os servios no mais disporiam de acesso ou cruzamento de dados de outros dispositivos e/ou servios que foram publicados no servidor. Alm disso, os dispositivos interativos precisariam, necessariamente, armazenar mais dados locais, armazenar um histrico maior, bem como possuir um hardware mais poderoso, em termos de processamento, a fim de permitir clculos de inferncias locais. Este hardware extra s no seria necessrio se o sistema passasse a utilizar parte da arquitetura proposta por Thawani et. al. [53], colocando em cada residncia um servidor capaz de armazenar os dados e com poder de processamento razovel. Contudo, isto encareceria por demais a soluo para que fosse empregada em pases como o Brasil. O uso de dispositivos portteis, como pde ser analisado, uma forma utilizada no sistema que atenua o problema de escalabilidade. Contudo, dependendo de onde o sistema for empregado, apenas esta caracterstica (i.e. uso de dispositivos portteis) no resolve todo o problema.

5.7. Consideraes
Este captulo apresentou os experimentos realizados sobre a

implementao de referncia do ProfileTV. Foram levantadas discusses acerca do ambiente de desenvolvimento, das funcionalidades essenciais, como a determinao e adio de contexto no sistema e criao de perfis de telespectadores, bem como sobre os desafios enfrentados na concepo do sistema, como escalabilidade e espao de armazenamento. O ProfileTV se comportou satisfatoriamente durante todos os experimentos, atendendo as necessidades bsicas das funcionalidades. A escalabilidade, que se constitui no principal desafio do sistema, foi detalhada e foram apresentadas solues para o mercado fechado de TVDi. As transmisses abertas possuem um cenrio tipicamente poltico, o 108

que implica que qualquer soluo apresentada para este desafio transforme-se em mera especulao.

109

110

6.Captulo Concluses
"O tempo o melhor autor - sempre encontra um final perfeito." - Charles Chaplin

Atender as necessidades de uma televiso cada vez mais pervasiva, alerta a mudanas contextuais e de produo incessante de informao representa um desafio para todos os servios televisivos atuais e futuros. Este trabalho props o ProfileTV, uma infra-estrutura para o desenvolvimento simplificado destes servios. O ProfileTV definiu uma arquitetura baseada no modelo distribudo de software cliente-servidor, tendo apresentado solues para os principais desafios encontrados na criao de servios de TVDi, com foco na personalizao e adaptao de contedo s preferncias de cada telespectador. Foi dada uma ateno especial a determinao das informaes relevantes a cada interao do telespectador com dispositivos ou servios interativos. Para tanto, atravs de um paralelo com o modelo de orientao a objetos, o conceito de Categoria e Propriedade foi adaptado para o sistema, o que possibilitou a criao de Perfis de interao telespectador/dispositivo, telespectador/servio e telespectador/dispositivo/servio. O ProfileTV introduziu tambm o conceito de perfil porttil, visando atender aos telespectadores de maior mobilidade. Estes podero, atravs de seus dispositivos portteis, carregar consigo o seu perfil (i.e. suas preferncias), onde quer que estejam, para onde quer que vo. Este conceito permite uma interao mais natural com o sistema, j que atenua a quantidade de entradas explcitas do usurio.

111

6.1. Contribuies
Primeiramente, este trabalho estabeleceu cenrios de utilizao de servios de personalizao em TVDi. Baseado nestes cenrios, nos estudos efetuados e na experincia adquirida, foi levantado um conjunto de funcionalidades necessrias a uma infra-estrutura de gerenciamento de perfis com foco em TVDi. Visando atender a estes requisitos, foi especificada uma arquitetura de servios e um componente de middleware de TVDi. O foco desta arquitetura foi atender a necessidade atual de locomoo dos telespectadores, alm das transmisses voltadas diretamente para dispositivos portteis. A principal contribuio de natureza arquitetural. O conjunto de funcionalidades propostas no Captulo 3 permite o desenvolvimento de dispositivos e/ou servios interativos com foco na personalizao da interao com o telespectador. A implementao de referncia do ProfileTV apresentada no Captulo 4, bem como os experimentos apresentados no Captulo 5 comprovam a viabilidade do sistema, bem como forneceram insumos de melhoria para a prpria especificao do Captulo 3. Atravs do ProfileTV pode-se: Gerenciar o contexto de cada interao do telespectador com

dispositivos e/ou servios interativos; Criar perfis contendo todas as informaes de cada interao do

telespectador; Exportar e importar perfis para/de dispositivos portteis, o que

possibilita a personalizao e adaptao de contedo em qualquer ponto aderente ao sistema; Construo de servios interativos adaptativos s preferncias do

usurio, atravs da API fornecida pelo sistema (Apndice D); Buscar categorias, perfis e dados pblicos de telespectadores, o uso de diversas tcnicas para inferncia e

possibilitando Filtering [31];

recomendao de contedo, como Collaborative e Content Based 112

Controlar o acesso e a autorizao de usurios dentro do sistema; Gerar relatrios especficos de utilizao de servios; Atender s necessidades tanto dos telespectadores, como dos

emissores e dos provedores de contedo. Outras contribuies deste trabalho foram a definio de um protocolo prprio entre cliente e servidor e as discusses acerca da aplicabilidade de padres de projeto, bibliotecas e frameworks no sistema.

6.2. Trabalhos Futuros

Este trabalho pode servir como base para trabalhos futuros. Algumas sugestes so: Generalizar a soluo para outros ambientes que no apenas o

meio de televiso; Desenvolvimento do agregador de perfis proposto no Captulo 3.

Este agregador poderia ser similar ao apresentado em [53]; Desenvolvimento da interface web do ProfileTV, visando o

gerenciamento do acesso de terceiros ao sistema; Incorporao de um sistema de inferncia e recomendao de

contedo; Propor mudanas que afetem na melhoria da escalabilidade para

transmisses de televiso aberta; Realizao de testes de desempenho sobre a arquitetura

especificada; Expor a arquitetura a outros desenvolvedores para avaliao da

facilidade de uso da mesma, e posterior refinamento.

113

114

Referncias

[1] Juc, P., Lucena, U., Ferraz, C. Desenvolvendo Aplicaes para TV Digital. III Frum de Oportunidades em Televiso Digital Interativa, Maio 2004 [2] ANATEL - Agncia Nacional de Telecomunicaes - Dados Estatsticos dos Servios de TV por Assinatura - Dezembro / 2006 [3] OpenTV. Disponvel em http://www.opentv.com, acessado em 02 de agosto de 2008 [4] Advanced Television Systems Comitee (ATSC), Disponvel em http://www.atsc.org, acessado em 02 de agosto de 2008 [5] Digital Video Broadcasting (DVB), Disponvel em http://www.dvb.org, acessado em 02 de agosto de 2008 [6] Saito, M. The ISDB-T System. ITU Seminar, Novembro de 2000 [7] Information technology Generic coding of moving pictures and associated audio information: Systems. ISO/IEC 13818-1. MPEG Meeting, Dezembro de 2000 [8] MPEG-4 Systems FDIS. ISO/IEC JTCl/SC29/WGI llN2501. MPEG meeting, Outubro de 1998 [9] ABNT NBR 15606-1:2007 - Televiso digital terrestre - Codificao de dados e especificaes de transmisso para radiodifuso digital - Parte 1: Codificao de dados [10] ABNT NBR 15606-2:2007 - Televiso digital terrestre - Codificao de dados e especificaes de transmisso para radiodifuso digital - Parte 2: Ginga-NCL para receptores fixos e mveis - Linguagem de aplicao XML para codificao de aplicaes [11] ABNT NBR 15606-3:2007 - Televiso digital terrestre - Codificao de dados e especificaes de transmisso para radiodifuso digital - Parte 3: Especificao de transmisso de dados 115

[12] Projeto de Norma ABNT 00:001.85-006/4 - Televiso digital terrestre - Codificao de dados e especificaes de transmisso para transmisso digital Parte 4: Ginga-J - Ambiente para a execuo de aplicaes procedurais [13] ABNT NBR 15606-5:2008 - Televiso digital terrestre - Codificao de dados e especificaes de transmisso para radiodifuso digital - Parte 5: Ginga-NCL para receptores portteis - Linguagem de aplicao XML para codificao de aplicaes [14] ARIB. Disponvel em http://www.arib.or.jp/english, acessado em 02 de outubro de 2008 [15] WWITV. Disponvel em http://www.wwitv.com, acessado em 13 de maio de 2007 [16] MSNTV. Disponvel em http://www.msntv.com/pc, acessado em 13 de maio de 2007 [17] Line TV. Disponvel em http://www.beelinetv.com, acessado em 13 de maio de 2007 [18] Loes, Joo. At 2010, 140 milhes de casas em todo mundo tero IPTV. Disponvel em http://wnews.uol.com.br/site/noticias/materia.php? id_secao=4&id_conteudo=5699, acessado em 13 de maio de 2007 [19] Alcatel-Lucent. Disponvel em http://www.alcatel.com, acessado em 13 de maio de 2007 [20] Microsoft TV. Disponvel em http://www.microsoft.com/tv, acessado em 13 de maio de 2007 [21] 3G. Disponvel em http://en.wikipedia.org/wiki/3G, acessado em 02 agosto de 2008 [22] Video On Demand (VoD). Disponvel em http://en.wikipedia.org/wiki/Video_on_demand, acessado em 02/08/2008 [23] Hewett, B. et. al. Curricula for Human-Computer Interaction Chapter 2: Human-Computer Interaction. ACM SIGCHI, 1992-1996. [24] Schilit, B., Adams, N. e Want., R. Context-aware computing applications. IEEE Workshop on Mobile Computing Systems and Applications (WMCSA'94), Santa Cruz, CA, US: 89-101. 116

[25] Turner, N., Cairns, P., Jones, M. Dispersing the Interactivity: Mobiles and Eletronic Programme Guides. ACM CHI, Abril de 2006 [26] Vanni, R., Martimiano, L., Moreira, E. Management of Ubiquitous Access for Better User Experience. I Workshop on Pervasive and Ubiquitous Computing - WPUC 2007. [27] Silva, D. TV Digital: O que o brasileiro tem em casa. Observatrio da Imprensa, Fevereiro de 2006 [28] Pesquisa Veja. Disponvel em http://www.cabecadecuia.com/noticias/3213/tv-esta-presente-em971-dos-lares-brasileiros-pcs-em-25.html, acessado em 02 de agosto de 2008 [29] Jones, M., Buchanan, G., Jain, P., Marsden, G. From sit-forward to Lean-back: Using a Modile Device to Vary the Place of Interactive Experience. Proceedings Mobile - HCI 2003 [30] Weiser, M. The Computer for the Twenty-First Century. Scientific American, Setembro de 1991 [31] Razmerita, L., Angehrn, A. e Nabeth, T. On the Role of User Models and User Modeling in Knowledge Management Systems, HCI 2003 [32] Kruchten, P. Architectural Blueprints - The "4+1" View Model of Software Architecture. IEEE Software, Novembro 1995, p. 42-50 [33] Research and Market. OpenTV Market Research Reports. Disponvel em http://www.researchandmarkets.com/reportinfo.asp? cat_id=7&report_id=599&p=73, acessado em 21 julho de 2007 [34] Weiser, M., Brown, J. The coming age of calm technology. Xerox PARC, Outubro de 1996. [35] IPTV. Disponvel em http://en.wikipedia.org/wiki/IPTV, acessado em 03 de agosto de 2008 [36] Murer, R. O que IPTV. SOFTV, 2007 [37] Joost. Disponvel em http://www.joost.com, acessado em 13 de maio de 2007 [38] ITU International Telecommunication Union. ITU-T Recommendation J.200: Worldwide common core Application environment for digital interactive television services. 2001. 117

[39] ITU International Telecommunication Union. ITU-T Recommendation J.201: Harmonization of declarative content format for interactive television applications. 2004. [40] ITU International Telecommunication Union. ITU-T Recommendation J.202: Harmonization of procedural content formats for interactive TV applications. 2003. [41] Mackay, W. et. al. Augmenting Reality: Adding Computational Dimensions to Paper. Communications of ACM, 1993 [42] Ishii, H. & Ullmer, B. Tangible bits: Towards seamless interfaces between people, bits and atoms. CHI - Conference on Human Factors in Computing Systems, 1997 [43] Rhodes, B., Minar, N. e Weaver, J. Wearable Computing Meets Ubiquitous Computing: Reaping the best of both worlds. [44] Moran, T. e Dourish, P. Introduction to Human-Computer Interaction on Context-Aware Computing. 2001 [45] Trinta, F. Definindo e Provendo Servios de Suporte a Jogos Multiusurio e Multiplataforma: Rumo Pervasividade. CIn/UFPE, Tese de Doutorado, Maio de 2007. [46] Long,S., Kooper, R., Abowd, G., Atkeson, C. Rapid prototyping of mobile context-aware applications: the Cyberguide case study. II Annual International Conference on Mobile Computing and Networking, November 1996. ACM Press [47] Kanter, T. HotTown, Enabling Context-Aware and Extensible Mobile Interactive Spaces. IEEE Wireless Communications, Outubro de 2002 [48] Want, R., Hopper, A., Falco, V. e Gibbons., J. The Active Badge Location System. ACM Transactions on Information Systems (TOIS), Janeiro de 1992 [49] Eduardo, C. et. al. VEye - Sistema distribudo de auxlio navegao e identificao de objetos para deficientes visuais. Disponvel em http://www.cepe.fgvsp.br/desafio/historico /Trivial_GVIntel.pdf [50] Dey, A., Abowd, G. Towards a Better Understanding of Context and Context-Awareness. I International Symposium on Handheld and 118

Ubiquitous Computing, 1999. [51] Goularte, R. Personalizao e adaptao de contedo baseadas em contexto para TV Interativa. Tese de Doutorado, USP, So Paulo, 2003. [52] TV Anytime. Disponvel em http://www.tv-anytime.org acessado em 13 de maio de 2007. [53] Thawani, A., Gopalan, S. e Sridhar, V. Context Aware Personalized Ad Insertion in an Interactive TV Environment . IV Workshop on Personalization in Future TV - Methods, Technologies, Applications for Personalized TV, Agosto de 2004 [54] Yu, Zhiwen. et. al. An OSGI-Based infraestructure for contextaware multimedia services. Publicado pela IEEE Communications Magazine, Outubro de 2006. [55] Correia, N. e Pires, M. Design of a Personalization Service for an Interactive TV Environment. Workshop on Personalization on Future TV. Workshop on Personalization on Future TV Mlaga, Espanha, Junho de 2002. [56] Scholtz, J. Ubiquitous Computing Goes Mobile. Mobile Computing and Communications Review, Volume 5, Nmero 3 - Janeiro de 2001. [57] Coelho, A., Carvalho, A., Beltro, M. e Ferraz. C. WheeTV: TV Interativa em Dispositivos Portteis. VI Frum de Oportunidades em Televiso Digital Interativa, Maio 2008 [58] Lekakos, G. e Giaglis, G. Delivering Personalized Advertisements in Digital Television: A Methodology and empirical Evaluation. Workshop on Personalization on Future TV, Mlaga, Espanha, Junho de 2002. [59] Ardissono, L. Chiarotto, A., Diffino, A. e Negro, B. Personalized Recommendation of TV Programs. VIII AI*IA Conference, Pisa, 2003 [60] Dai, W. e Cohen, R. Dynamic Personalized TV Recommendation System. UM03 - Workshop on Personalization in Future TV, Junho de 2003 [61] Coulouris, G. et. al. Distributed Systems: Concepts and Design. Pearson, 2001, 3 Edio. 119

[62] Compaq, Hewlett-Packard, Intel, Lucent, Microsoft, NEC, Philips. Universal Serial Bus Specification. Revision 2.0, Abril de 2000 [63] Specification of the Bluetooth System, Core, v1.1, Disponvel em http://www.bluetooth.com, acessado em 03 de agosto de 2008 [64] Object-Oriented Programming. Disponvel em http://en.wikipedia.org/wiki/ Object_oriented#cite_note-Kay2003-0, acessado em 03 de agosto de 2008 [65] Pfleeger, S. Software Engineering, theory and practice. Prentice Hall, 2 Edio pg. 496-502 [66] Hibernate Reference Documentation, v3.2.2. Disponvel em http://www.hibernate.org, acessado em 03 de agosto de 2008 [67] Tanenbaum, A. e Steen, M. Distributed Systems: Principles e Paradigms. Prentice Hall, Janeiro de 2002 [68] Frum do Sistema Brasileiro de TV Digital Terrestre. Disponvel em http://www.forumsbtvd.org.br, acessado em 03 de agosto de 2008 [69] Remote Procedure Call. Disponvel em http://en.wikipedia.org/wiki/ Remote_procedure_call, acessado em 03 de agosto de 2008 [70] XML-RPC. Disponvel em http://www.xmlrpc.com, acessado em 03 de agosto de 2008 [71] Java Remote Method Invocation Specification. Reviso 1.10, Java SE v 1.5.0 [72] Message Oriented Middleware. Disponvel em http://en.wikipedia.org/wiki/Message_Oriented_Middleware, acessado em 03 de agosto de 2008 [73] Volter, M., Kircher, M. e Zdun, U. Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware . Wiley Series in Software Design Patterns, 2005 pg. 93-96 [74] W3C - The World Wide Web Consortium. Disponvel em http://www.w3.org, acessado em 03 de agosto de 2008 [75] Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns: Elements of Reusable Object Oriented Software. Addison-Wesley, 1994 [76] Multimedia Home Platform (MHP). Disponvel em 120

http://www.mhp.org, acessado em 03 de agosto de 2008 [77] Morris, S., Chaigneau, A. Interactive TV Standards. Elsevier Science Ltd, Abril de 2005 [78] Interactive TV Web. Disponvel em http://www.interactivetvweb.org/, acessado em 03 de agosto de 2008 [79] XletView. Disponvel em http://sourceforge.net/projects/xletview, acessado em 03 de agosto de 2008 [80] Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.3. ETSI TS 101 812 v1.3.2, 2006-08 [81] Institut fr Rundfunktechnik. Disponvel em http://www.irt.de, acessado em 03 de agosto de 2008 [82] Personal Java. Disponvel em http://jcp.org/aboutjava/communityprocess/final/jsr062/, acessado em 03 de agosto de 2008 [83] JSR 224: Java API for XML-Based Web Services (JAX-WS) 2.0. Disponvel em http://jcp.org/en/jsr/detail?id=224, acessado em 03 de agosto de 2008 [84] Booth, D. et. al. Web Services Architecture. W3C, Fevereiro de 2004. [85] Mitra, N. e Lafon, Y. SOAP Version 1.2 Part 0: Primer (Second Edition). W3C Recommendation, Abril de 2007 [86] Gudgin, M. et. al. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). W3C Recommendation, Abril 2007 [87] DOM4J. Disponvel em http://www.dom4j.org/, acessado em 03 de agosto de 2008 [88] Simple API for XML. Disponvel em http://en.wikipedia.org/wiki/Simple_API_for_XML, acessado em 03 de agosto de 2008 [89] Document Object Model. Disponvel em http://en.wikipedia.org/wiki/Document_Object_Model, acessado em 03 de agosto de 2008 [90] Motta, G. Um modelo de autorizao contextual para o controle de acesso ao pronturio eletrnico do paciente em ambientes abertos 121

e distribudos. Escola Politcnica/USP, Tese de Doutorado, Abril de 2004 [91] Open LDAP. Disponvel em http://www.openldap.org/, acessado em 03 de agosto de 2008 [92] Single Sign-On. Disponvel em HTTP://en.wikipedia.org/wiki/Single_sign-on, acessado em 08 de agosto de 2008 [93] Goyal, V. Build Flexible Logs With Log4J. Junho de 2002 [94] Goetz, B. Threading lightly, Part 3: Sometimes it's best not to share. Exploiting ThreadLocal to enhance scalability . IBM, Outubro de 2001 [95] Jasper Report Forge. Disponvel em http://www2.jasperforge.org/plugins/project/ project_home.php?group_id=102, acessado em 03 de agosto de 2008 [96] PostgreSQL. Disponvel em http://www.postgresql.org, acessado em 03 de agosto de 2008 [97] MySQL Reference Manual. Disponvel em http://dev.mysql.com/doc/refman/5.0/en/sql-syntax.html, acessado em 03 de agosto de 2008 [98] McClanahan, C., Roh, A. e Canon, A. The Essencial of Filters, Janeiro de 2006 [99] Volter, M., Kircher, M. e Zdun, U. Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware . Wiley Series in Software Design Patterns, 2005 pg. 187-238 [100] Volter, M., Kircher, M. e Zdun, U. Remoting Patterns: Foundations of Enterprise, Internet and Realtime Distributed Object Middleware . Wiley Series in Software Design Patterns, 2005 pg. 239-292 [101] Model View Controller. Disponvel em http://Java.sun.com/blueprints/patterns/MVC.html, acessado em 03 de agosto de 2008 [102] Goldberg, A. e Robson,D. Smalltalk-80: The Language and its Implementation. Addison-Wesley, 1983. [103] Goldberg, A. e Robson,D. Smalltalk-80: The Interactive 122

Programming Environment. Addison-Wesley, 1984. [104] Cavaness, C. Programming Jakarta Struts. O'Reilly & Associates Inc, Primeira Edio, 2002. [105] The Apache Struts site. Disponvel em http://struts.apache.org/, acessado em 03 de agosto de 2008 [106] Sandhu, R., Coyne, E., Feinstein, H., Youman, C. Role-Based Access Control Models, IEEE Computer 29(2), IEEE Press, 1996, Pages 38-47 [107] Braghetto, K. Controle de Acesso Baseado em Papis. IME/USP, Maio de 2004 [108] Ferraiolo, K. e Khun, R. Role Based Access Control. NIST, National Computer Security Conference, 1992 [109] ADO .NET. Disponvel em http://en.wikipedia.org/wiki/ADO_.NET, acessado em 03 de agosto de 2008 [110] Java Data Object (JDO). Disponvel em http://en.wikipedia.org/wiki/Java_Data_Objects, acessado em 03 de agosto de 2008 [111] Kurniawan, B. Java para a Web com Servlets, Jsp e EJB. New Riders Editora, 2002 [112] JSP. Disponvel em http://java.sun.com/javaee/javaserverfaces/, acessado em 03 de agosto de 2008 [113] The Official Microsoft ASP.NET Site. Disponvel em http://www.asp.net, acessado em 03 de agosto de 2008 [114] BlueCove. Disponvel em http://www.bluecove.org, acessado em 03 de agosto de 2008 [115] Parser Compare. Disponvel em http://www.ibm.com/developerworks/library/x-injava2, acesado em 05 de junho de 2008 [116] Parser Compare. Disponvel em http://www.ibm.com/developerworks/xml/library/xinjava/index.html, acesado em 05 de junho de 2008 [117] Hunter, J. JDOM and XML Parsing. Oracle Magazine, outubro de 2002 [118] IReports. Disponvel em http://sourceforge.net/projects/ireport/, 123

acessado em 03 de agosto de 2008 [119] Crystal Reports. Disponvel em http://www.businessobjects.com/product/catalog/ crystalreports/, acessado em 03 de agosto de 2008 [120] Watt, D., Brown, D. Programming Language Processors in Java. Prentice Hall, 2000. [121] CRUD. Disponvel em http://pt.wikipedia.org/wiki/CRUD, acessado em 27 de fevereiro de 2008 [122] GRASP. Disponvel em http:// pt.wikipedia.org/wiki/GRASP, acessado em 27 de fevereiro de 2008

124

125

7.Apndice A Definio do Contexto

Este apndice apresenta a configurao utilizada no Estudo de Caso do ProfileTV. Nesta configurao so definidas categorias para (1) dispositivos digitais (ex. televises, set-top boxes), (2) servios (ex. panamericano, campeonato brasileiro), (3) dados gerais de usurios e os papis existentes no sistema, Administrator, General User e Third Party.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE profiletv-mapping PUBLIC "-//ProfileTV/ProfileTV Mapping DTD 1.0//EN" "http://localhost:8080/ProfileTVServer/dtd/profiletv-mapping-1.0.dtd"> <profiletv-mapping> <category id="ROOT" name="ProfileTVConfigurationExample" parent="ROOT" /> <category id="DD" name="Digital Devices" parent="ROOT"> <property id="DD_definition" name="Definition" canBeNull="FALSE" type="SINGLE" valueType="TEXT"> <value>Full-HD</value> </property> <property id="DD_Interactivity" name="Interactivity" canBeNull="FALSE" type="SINGLE" valueType="BOOLEAN"> <value>true</value> </property> <property id="DD_Middleware" name="Middleware" canBeNull="TRUE" type="SINGLE" valueType="TEXT"> <value>MHP</value> </property> <property id="DD_HD" name="Hard Disk" canBeNull="FALSE" type="SINGLE" valueType="BOOLEAN"> <value>false</value> </property> <property id="DD_PVR" name="Personal Video Recorder" canBeNull="FALSE" type="SINGLE" valueType="BOOLEAN"> <value>false</value> </property> <property id="DD_Description" name="Description" canBeNull="TRUE" type="SINGLE" valueType="TEXT"> <value>A generic digital device</value> </property> <property id="DD_Voltage" name="Voltage" canBeNull="FALSE" type="SINGLE" valueType="TEXT"> <value>90-120/200-240</value> </property> </category> <category id="STB" name="Set-top Box" parent="DD"> <property id="STB_HDMI" name="HDMI Out" canBeNull="FALSE"

126

type="SINGLE" valueType="NUMBER"> <value>0</value> </property> <property id="STB_DVI" name="DVI Out" canBeNull="FALSE" type="SINGLE" valueType="NUMBER"> <value>1</value> </property> </category> <category id="TVSET" name="Television Set" parent="DD"> <property id="TVSET_HDMI" name="HDMI In" canBeNull="FALSE" type="SINGLE" valueType="NUMBER"> <value>2</value> </property> <property id="TVSET_DVI" name="DVI In" canBeNull="FALSE" type="SINGLE" valueType="NUMBER"> <value>1</value> </property> <property id="TVSET_Hue" name="Hue" canBeNull="FALSE" type="SINGLE" valueType="NUMBER"> <value>50</value> </property> <property id="TVSET_Bright" name="Bright" canBeNull="FALSE" type="SINGLE" valueType="NUMBER"> <value>50</value> </property> <property id="TVSET_DC" name="Default Channel" canBeNull="FALSE" type="SINGLE" valueType="NUMBER"> <value>0</value> </property> <property id="TVSET_AM" name="Audio Mode" canBeNull="TRUE" type="SINGLE" valueType="TEXT"> <value>5-1</value> </property> <property id="TVSET_ESA" name="Default Elementary Audio Stream" canBeNull="TRUE" type="SINGLE" valueType="TEXT"> <value>original</value> </property> <property id="TVSET_Aspect" name="Screen Aspect" canBeNull="FALSE" type="SINGLE" valueType="TEXT"> <value>16:9</value> </property> </category> <category id="TVPREFERENCE" name="Programs Preference" parent="TVSET"> <property id="TVP_Channel" name="Watched Channels" canBeNull="TRUE" type="MULTI" valueType="TEXT" /> <property id="TVP_Channel_Time" name="Watched Channels Time" canBeNull="TRUE" type="MULTI" valueType="NUMBER" related="TVP_Channel" /> <property id="TVP_Program" name="Watched Programs" canBeNull="TRUE" type="SINGLE" valueType="TEXT" /> <property id="TVP_Program_Time" name="Watched Programs Time" canBeNull="TRUE" type="SINGLE" valueType="NUMBER" related="TVP_Program" /> </category> <category id="SERVICES" name="Services" parent="ROOT"> <property id="SAspect" name="Aspect" canBeNull="FALSE" type="SINGLE" valueType="TEXT" pattern="RESIZE|TRANSPARENT|FULL-SCREEN"> <value>RESIZE</value>

127

</property> <property id="SMode" name="Mode" canBeNull="FALSE" type="SINGLE" valueType="BOOLEAN" pattern="LOCAL|HALF-DUPLEX|FULL-DUPLEX"> <value>LOCAL</value> </property> <property id="SAudio" name="Audio" canBeNull="FALSE" type="SINGLE" valueType="BOOLEAN" pattern="ON|OFF"> <value>OFF</value> </property> </category> <category id="PAN" name="Pan-American Games" parent="SERVICES"> <property id="PAN-AREA" name="area" type="MULTI" valueType="TEXT" pattern="mural|medalhas|sobrePan|agenda|noticias" /> <property id="PAN-AREA-TIME" name="area time" type="MULTI" valueType="TEXT" pattern="mural|medalhas|sobrePan|agenda|noticias" related="PAN-AREA" /> <property id="PAN-Sport" name="sport" type="SINGLE" valueType="TEXT" /> </category> <category id="CCB" name="Campeonato Brasileiro" parent="SERVICES"> <property id="CCB-AREA" name="area" type="MULTI" valueType="TEXT" pattern="artilharia|tabela|campeoes|classificacao|estadio|estatisticas" /> <property id="CCB-AREA-TIME" name="area time" type="MULTI" valueType="TEXT" pattern="mural|medalhas|sobrePan|agenda|noticias" related="CCB-AREA" /> <property id="CCB-Club" name="Clube" type="MULTI" valueType="TEXT" /> </category> <category id="USER" name="User General" parent="ROOT"> <property id="UName" name="Name" canBeNull="FALSE" type="SINGLE" valueType="TEXT"> <value>Ipsum Lopsi Lorum</value> </property> <property id="UGender" name="Gender" canBeNull="FALSE" type="SINGLE" valueType="TEXT" pattern="m|f|M|F"> <value>M</value> </property> <property id="UYear" name="Birthday year" canBeNull="TRUE" type="SINGLE" valueType="DATE" pattern="yyyy"> </property> <property id="UAddress" name="Address" canBeNull="TRUE" type="SINGLE" valueType="TEXT"> </property> <property id="UZIP" name="ZIP" canBeNull="TRUE" type="SINGLE" valueType="TEXT"> </property> <property id="UPhone" name="Cel Phone" canBeNull="TRUE" type="SINGLE" valueType="TEXT" pattern="(\(\d\d\)\s?)?\d{8}"> </property> </category> <category id="USocial" name="Social" parent="USER"> <property id="USLang" name="Languages" canBeNull="TRUE" type="MULTI" valueType="TEXT" /> <property id="USBirthday" name="Birthday" canBeNull="TRUE" type="SINGLE" valueType="DATE" pattern="MM/dd" />

128

<property id="USRelationship" name="Relationship" canBeNull="TRUE" type="SINGLE" valueType="TEXT" pattern="single|committed|married|open marriage"> <value>single</value> </property> <property id="USResidencePhone" name="Residence Phone" canBeNull="TRUE" type="SINGLE" valueType="TEXT" pattern="(\(\d\d\)\s?)?\d{8}" /> <property id="USSons" name="Sons" canBeNull="TRUE" type="SINGLE" valueType="NUMBER"> <value>0</value> </property> <property id="USEthnicity" name="Ethnicity" canBeNull="TRUE" type="SINGLE" valueType="TEXT" /> <property id="USReligion" name="Religion" canBeNull="TRUE" type="SINGLE" valueType="TEXT" pattern="agnostic|atheist|budddist|crhistian|hindu" /> <property id="USSmoking" name="Smoking" canBeNull="TRUE" type="SINGLE" valueType="BOOLEAN" /> </category> <category id="SProfessional" name="Professional" parent="USER"> <property id="SPEducation" name="Education" canBeNull="TRUE" type="SINGLE" valueType="TEXT" pattern="Elementary|High School|College|Associates Degree|Bachelors Degree|Masters Degree|Ph.D.|PostDoctoral" /> <property id="SPOccupation" name="Occupation" canBeNull="TRUE" type="SINGLE" valueType="TEXT" /> <property id="SPJob" name="Job Description" canBeNull="TRUE" type="SINGLE" valueType="TEXT" /> </category> <category id="ROLE" name="Roles" parent="ROOT" /> <category id="ADM" name="Administrator Permission" parent="ROLE"> <property id="ADMCC" name="createConfiguration" type="SINGLE" valueType="TEXT" /> <property id="ADMUC" name="updateConfiguration" type="SINGLE" valueType="TEXT" /> <property id="ADMRC" name="removeConfiguration" type="SINGLE" valueType="TEXT" /> <property id="ADMGAR" name="generateAdministrativeReport" type="SINGLE" valueType="TEXT" /> </category> <category id="USERP" name="User Permission" parent="ROLE"> <property id="USERSP" name="searchProfile" type="SINGLE" valueType="TEXT" /> <property id="USERPCPP" name="createPrivateProfile" type="SINGLE" valueType="TEXT" /> <property id="USERUPP" name="updatePrivateProfile" type="SINGLE" valueType="TEXT" /> <property id="USERRPP" name="removePrivateProfile" type="SINGLE" valueType="TEXT" /> <property id="USERPP" name="publishProfile" type="SINGLE" valueType="TEXT" /> </category> <category id="THIRD" name="Third Parties Permission" parent="ROLE"> <property id="THIRDSPP" name="searchPublicProfile" type="SINGLE" valueType="TEXT" /> <property id="THIRDGR" name="generateReports" type="SINGLE" valueType="TEXT" /> </category> <role category="ADM" default="FALSE">Administrator</role>

129

<role category="USERP" default="FALSE">General User</role> <role category="THIRD" default="FALSE">Third Party</role> </profiletv-mapping>

Apndice B Protocolo do ProfileTV

Este apndice detalha o protocolo de comunicao do ProfileTV. Apresenta os cdigos utilizados na troca de mensagens durante a interao cliente-servidor, bem como as operaes que podem ser realizadas.

B.1.Cdigos de Mensagens
O protocolo do ProfileTV define alguns cdigos a serem embutidos no cabealho das mensagens do sistema. Estes cdigos tm o objetivo de indicar a operao a ser realizada, no caso de uma requisio do cliente, bem como explicitar o tipo de retorno de uma requisio, no caso de uma resposta do servidor. A Tabela B-8 apresenta todos.
Tabela B-8 Todos os Cdigos do protocolo ProfileTV Cdig o Nome 110 111 112 113 120 121 122 123 130 NEW DEVICE NEW PROFILE NEW SERVICE NEW USER UPDATE DEVICE UPDATE PROFILE UPDATE SERVICE UPDATE USER SEARCH PROFILE BY USER Tipo Atualiza o Atualiza o Atualiza o Atualiza o Atualiza o Atualiza o Atualiza o Atualiza o Buscas Descrio Cria um novo Device no Sistema Cria um novo Profile no Sistema Cria um novo Service no Sistema Cria um novo User no Sistema Atualiza um Device previamente cadastrado no sistema Atualiza um Profile previamente cadastrado no sistema Atualiza um Service previamente cadastrado no sistema Atualiza um User previamente cadastrado no sistema Busca os Profiles associados ao User

130

131 132 133

SEARCH PROFILE BY DEVICE SEARCH PROFILE BY DEVICE PER USER SEARCH PROFILE BY SERVICE PER USER SEARCH PROFILE BY SERVICE ON DEVICE PER USER SYNCHRONIZE PROFILE PER DEVICE SYNCHRONIZE PROFILE PER SERVICE SYNCHRONIZE PROFILE PER SERVICE ON DEVICE OK LISTED PROFILES SYNCHRONIZED CREATED UPDATED UNKNOWN PROBLEMS ON CREATE PROBLEMS ON UPDATE PROFILE NOT FOUND

Buscas Buscas Buscas

Busca os Profiles associados a um Device Busca os Profiles do User associados a um Device Busca os Profiles do User associados a um Service Busca os Profiles do User associados a dupla (Service, Device) Sincroniza o par (Device, User) com um Profile previamente criado Sincroniza o par (Service, User) com um Profile previamente criado Sincroniza a tupla (Service, Device, User) com um Profile previamente criado Retorno correto de uma operao, normalmente uma busca Lista os Profiles associados a pesquisa. Device/Service sincronizado com um Profile de um User Entidade (User, Profile, Device ou Service) criada com sucesso Profile atualizado Operao desconhecida Problemas na criao de uma entidade (User, Profile, Device ou Service) Problemas na atualizao de uma entidade (User, Profile, Device ou Service) Profile no existente para o User neste (Device/Service/DeviceService)

134 100 101 102 200 201 202 203 204 400 401 402 403

Buscas Sincroniza o Sincroniza o Sincroniza o Respostas Respostas Respostas Respostas Respostas Respostas Respostas Respostas Respostas

B.2.operaes
O ProfileTV oferece operaes para (1) atualizao de dados, (2) busca por perfis e (3) sincronizao entre perfis. Para cada operao h uma seqncia de mensagens que so trocadas entre os clientes e o servidor.

B.2.1.

Atualizao

As operaes de atualizao de dados so bem simples. Atravs destas operaes um cliente pode criar, remover e atualizar dados no servidor. Na maioria dos casos, uma nica interao entre clientes e servidor basta para a execuo de uma destas operaes, salvo os casos em que ocorrem erros ou fluxos alternativos. 131

Um possvel fluxo alternativo a criao de um Profile para um usurio no existente no ProfileTV Server. Neste caso, o servidor retorna uma mensagem de cdigo UNKNOWN, indicando o desconhecimento do usurio no sistema. O cliente ento solicita a criao de um usurio ao servidor, da forma mais transparente possvel para o telespectador. Com usurio criado possvel publicar o perfil deste usurio no sistema. A Figura B-55 - Criao de um Profile apresenta esta interao.

Figura B-55 - Criao de um Profile

B.2.2.

Busca

As operaes de busca so as mais simples de todas as operaes: um cliente solicita ao servidor um dado especfico ou uma lista de dados. O servidor processa a requisio, independentemente de o cliente ser identificado no sistema ou no.

B.2.3.

Sincronizao

As operaes de sincronizao so mais complexas que as de atualizao e busca, contudo ainda so bem simples. Estas operaes so funcionalidades desejveis para o ProfileTV, devido a problemas como escalabilidade e fluxo de dados na rede. A Figura B-2 apresenta uma sincronizao de um Profile associado a um dispositivo, sob uma ptica mais granular.

132

Figura B-56 - Sincronizao de Profile

133

134

8.Apndice C Casos de Uso

Este apndice especifica os casos de uso do ProfileTV, descrevendo os fluxos de eventos, entradas e sadas de cada caso de uso a ser implementado.

C.1.Atores
Tabela C-9 - Atores do ProfileTV

Ator Administrat or

Descrio Um tipo especializado de usurio com acesso apenas ao ProfileTV Server, que tem como principal responsabilidade dar manuteno ao sistema. Dispositivo utilizado pelo User para interagir de forma transparente com o sistema ProfileTV. Servio interativo, normalmente uma aplicao, que serve como outra porta de entrada para interao transparente de um User com o ProfileTV. Os Services dependem do dispositivo no qual executam. Tipo especializado de usurio com acesso apenas ao ProfileTV Server, podendo buscar dados pblicos dos usurios e gerar relatrios a partir destes. Um telespectador usurio do ProfileTV. Pode simplesmente acessar o sistema de forma transparente atravs de servios ou dispositivos interativos, bem como gerenciar seus perfis dentro do sistema, podendo vir a publicar informaes privadas que lhe interessem, atravs da interface web do ProfileTV Server.

Device Service

Third Party

User

135

C.2.Diagramas de Casos de Uso

C.2.1. Device

Figura C-57 - Casos de Uso disponveis para um Device

C.2.2.

Service

Os Services tem praticamente a mesma finalidade dos Devices dentro do ProfileTV. O que difere a ambos que os Services podem realizar a operao de KeepService enquanto que os Devices realizam a operao de KeepDevice. A Figura C-58 ilustra esta dependncia.

Figura C-58 - Casos de Uso disponveis para um Service

136

C.2.3.

User

Figura C-59 - Casos de Uso disponveis para um User

C.2.4.

Third Party

Figura C-60 - Casos de Uso disponveis para um Third Party

C.3.Realizao dos Casos de Uso

[UC001] - Manter Configurao Descri O ProfileTV permite a um administrador de sistemas realizar a o manuteno (evolutiva ou corretiva) de suas configuraes. Sendo permitido a criao, atualizao, pesquisa e remoo de configuraes. Atores Administrator

137

Priorida de

Essencial

[UC001 CRUD01] - Criar uma nova Configurao Entradas condies Sadas condies e e prps No se aplica Configurao armazenada no sistema

Fluxo de Eventos Fluxo Principal 1. Acessar o sistema atravs do cliente web; 2. Logar no sistema passando login e password como parmetros; 3. Acessar rea System Maintenance; 4. Acessar rea New Configuration; 5. Selecionar a opo ProfileTV Mapping XML no painel modal (pop up); 6. Inserir o caminho local (mquina cliente) e completo (absoluto) para o arquivo de configurao; 7. Pressionar o boto OK. Fluxo Alternativo 1 1. No passo 5 do fluxo principal, seleciona Manual Insertion; o administrador

2. O administrador preenche uma categoria por vez, como se segue: 2.1. Preencher o nome da categoria; 2.2. Selecionar pai da categoria (vazio se for um categoria raiz); 2.3. Expandir rea de propriedades; 2.4. Preencher o nome de uma propriedade; 2.5. Selecionar se a propriedade pode ou no ser multivalorada (Single ou Multi); 2.6. Selecionar um tipo para a propriedade (binary, boolean, currency, date, number, text); 2.7. Pressionar o boto Add Property to Category 2.8. Repetir passos 2.4 a 2.7 pelo propriedades que a categoria possua; 3. Repetir passo completa. Fluxo Excepcional 1 Fluxo Excepcional 2 Fluxo 2 at que a nmero de

configurao

esteja

1. No passo 2 do fluxo principal, caso usurio no esteja cadastrado no sistema, o mesmo apresentar uma mensagem de erro solicitando novos parmetros. 1. No passo 3 do fluxo principal, caso usurio no seja um administrador de sistemas esta rea no fica visvel. O usurio no poder criar configuraes. 1. No passo 6 do fluxo principal, caso o caminho no

138

Excepcional 3

corresponda ao caminho correto do arquivo no sistemas de arquivo local (cliente), o sistema apresentar uma mensagem de erro indicando que no foi possvel encontrar o arquivo. 1. No passo 6 do fluxo principal, se o arquivo estiver malformado, ou seja, no segue as regras definidas na DTD ProfileTV-Mapping, o sistema informar que a criao da configurao falhou devido a m-formao do arquivo. Caso seja possvel, a mensagem indicar a linha e coluna do arquivo onde se encontrou o erro.

Fluxo Excepcional 4

139

[UC001 CRUD02] - Remover Configurao Entradas condies Sadas condies e e prps Existir a Configurao desejada no sistema Configurao removida no sistema

Fluxo de Eventos Fluxo Principal 1. Acessar o sistema atravs do cliente web; 2. Logar no sistema passando login e password como parmetros; 3. Acessar rea System Maintenance; 4. Acessar rea Remove Configuration; 5. Selecionar na lista a configurao que deseja remover ; 6. Pressionar o boto OK. 7. Pressionar o boto Estou Ciente na tela de dilogo. Fluxo Alternativo 1 Fluxo Alternativo 2 Fluxo Excepcional 1 Fluxo Excepcional 2 Fluxo Excepcional 3 Fluxo Excepcional 4 1. No passo 6 do fluxo principal, o administrador cancela a operao. 1. No passo 7 do fluxo principal, o administrador cancela a operao. 1. No passo 2 do fluxo principal, caso usurio no esteja cadastrado no sistema, o mesmo apresentar uma mensagem de erro solicitando novos parmetros. 1. No passo 3 do fluxo principal, caso usurio no seja um administrador de sistemas esta rea no fica visvel. O usurio no poder criar configuraes. 1. No passo 5 do fluxo principal, caso a configurao que o administrador deseja remover no exista no sistema, a operao deve ser cancelada. 1. No passo 7 do fluxo principal, caso no seja possvel remover a configurao, uma tela de erro informativa deve ser apresentada ao administrador.

[UC001 CRUD03] - Listar Configuraes Entradas condies Sadas condies e e prps Existir no mnimo uma Configurao no sistema Lista contendo as configuraes do sistema

Fluxo de Eventos Fluxo Principal 1. Acessar o sistema atravs do cliente web; 2. Logar no sistema passando login e password como parmetros; 3. Acessar rea System Maintenance;

140

4. Acessar rea List Configurations; 5. Selecionar a Configurao procurada . Fluxo Excepcional 1 Fluxo Excepcional 2 Fluxo Excepcional 3 1. No passo 2 do fluxo principal, caso usurio no esteja cadastrado no sistema, o mesmo apresentar uma mensagem de erro solicitando novos parmetros. 1. No passo 3 do fluxo principal, caso usurio no seja um administrador de sistemas esta rea no fica visvel. O usurio no poder criar configuraes. 1. No passo 4 do fluxo principal, caso a lista de configuraes no seja gerada, o sistema deve retornar uma mensagem de erro informativa ao administrador.

[UC001 CRUD04] - Atualizar uma Configurao Entradas condies Sadas condies e e prps Existir a Configurao deseja da no sistema Configurao atualizada no sistema

Fluxo de Eventos Fluxo Principal 1. Acessar o sistema atravs do cliente web; 2. Logar no sistema passando login e password como parmetros; 3. Acessar rea System Maintenance; 4. Acessar rea Update Configuration; 5. Selecionar a opo ProfileTV Mapping XML no painel modal (pop up); 6. Inserir o caminho local (mquina cliente) e completo (absoluto) para o arquivo de configurao; 7. Pressionar o boto OK. Fluxo Alternativo 1 1. No passo 5 do fluxo principal, seleciona Manual Update; o administrador

2. O administrador seleciona a Configurao deseja na lista de configuraes do sistema; 3. Pressiona o boto Atualizar; 4. Atualiza individualmente Categorias e Propriedades necessrias; 5. Repetir passo 4 at que a atualizao da configurao esteja completa. Fluxo Excepcional 1 Fluxo Excepcional 2 1. No passo 2 do fluxo principal, caso usurio no esteja cadastrado no sistema, o mesmo apresentar uma mensagem de erro solicitando novos parmetros. 1. No passo 3 do fluxo principal, caso usurio no seja um administrador de sistemas esta rea no fica visvel. O usurio no poder criar configuraes.

141

Fluxo Excepcional 3

1. No passo 6 do fluxo principal, caso o caminho no corresponda ao caminho correto do arquivo no sistemas de arquivo local (cliente), o sistema apresentar uma mensagem de erro indicando que no foi possvel encontrar o arquivo. 1. No passo 6 do fluxo principal, se o arquivo estiver malformado, ou seja, no segue as regras definidas na DTD ProfileTV-Mapping, o sistema informar que a atualizao da configurao falhou devido a mformao do arquivo. Caso seja possvel, a mensagem indicar a linha e coluna do arquivo onde se encontrou o erro.

Fluxo Excepcional 4

142

[UC002] - Manter Profile Descri O ProfileTV permite a um User realizar a manuteno de seus o Profiles. Essa manuteno normalmente transparente j que a maioria dos Users atualizar seus perfis atravs da interao com um Device ou Service. Entretanto, possvel que Users avanados realizem a manuteno de seus perfis atravs de uma interface web do ProfileTV Server. Este CRUD foca-se no primeiro caso, j que o segundo uma funcionalidade desejvel para o sistema. Note que no possvel remover um Profile atravs de um cliente embarcado ( Service ou Device), o que explica o fato desta operao no constar neste CRUD. Atores Priorida de User, Device, Service Essencial

[UC002 CRUD01] - Criar um novo Profile Entradas condies Sadas condies e e prps Categoria modelo do Perfil existente no ProfileTV Server Perfil criado no dispositivo interativo

Fluxo de Eventos Fluxo Principal 1. Durante a interao do usurio com um Service ou Device, o cliente embarcado cria um UpdateWorker;

2. Invoca-se o mtodo createProfile do UpdateWorker;

3. O UpdateWorker cliente invoca o seu homnimo remoto no objeto distribudo homnimo servidor; 4. O ProfileTV Server busca a categoria solicitada na sua rea de persistncia; 5. O ProfileTV Server cria um objeto Profile baseado na categoria encontrada; 6. O ProfileTV Server traduz o objeto Profile criado para o formato entendido no cliente; 7. O UpdateWorker servidor envia uma Mensagem contendo como payload o objeto Profile traduzido e como cabealho o cdigo 203 (CREATED); 8. O UpdateWorker cliente recupera o Profile traduzido do payload da mensagem; 9. O UpdateWorker cliente repassa o Profile para cliente embarcado. Fluxo Alternativo 1 1. No passo 3 do fluxo principal, caso o Device ou Service no esteja previamente cadastrado no sistema, o cadastro ser efetuado neste momento.

2. Associa-se o Device ou Service ao User passado como 143

argumento no mtodo createProfile; 3. Prossegue com o passo 4 do fluxo principal. Fluxo Alternativo 2 1. No passo 2 do fluxo alternativo 1, caso o User no esteja previamente cadastrado no sistema, o cadastro ser efetuado neste momento. 2. Retorna ao passo 2 do fluxo alternativo 1. Fluxo Excepcional 1 1. No passo 3 do fluxo principal, caso o Device no esteja conectado rede o UpdateWorker libera uma exceo (NetworkException) que deve ser tratada pelo cliente embarcado (Service ou Device).

Fluxo Excepcional 2

1. No passo 4 do fluxo principal, caso a categoria

solicitada no for encontrada no sistema, enviada de volta uma Mensagem contendo o cdigo 400 (UNKNOWN) no cabealho e a exceo RemoteException como payload.

[UC002 CRUD02] - Buscar Profile Entradas condies Sadas condies e e prps Profile previamente cadastrado no sistema Profile solicitado recuperado no sistema local

Fluxo de Eventos Fluxo Principal 1. Durante a interao do usurio com um Service ou Device, o cliente embarcado cria um UpdateWorker;

2. Invoca-se o mtodo searchProfile do UpdateWorker;

3. O UpdateWorker cliente invoca o seu homnimo remoto no objeto distribudo homnimo servidor; 4. O ProfileTV Server busca o Profile solicitado na sua rea de persistncia; 5. O ProfileTV Server traduz o objeto Profile encontrado para o formato entendido no cliente; 6. O UpdateWorker servidor envia uma Mensagem contendo como payload o objeto Profile traduzido e como cabealho o cdigo 201 (LISTED PROFILES) ; 7. O UpdateWorker cliente recupera o Profile traduzido do payload da mensagem; 8. O UpdateWorker cliente repassa o Profile para cliente embarcado. Fluxo Alternativo 1 1. No passo 3 do fluxo principal, caso o Device ou Service no esteja previamente cadastrado no sistema, o cadastro ser efetuado neste momento.

2. Associa-se o Device ou Service ao User passado como

argumento no mtodo searchProfile; 3. Prossegue com o passo 4 do fluxo principal. Fluxo 1. No passo 3 do fluxo principal, caso o Device no esteja

144

Excepcional 1

conectado rede o UpdateWorker libera uma exceo (NetworkException) que deve ser tratada pelo cliente embarcado (Service ou Device).

Fluxo Excepcional 2

1. No passo 4 do fluxo principal, caso o Profile solicitado

no for encontrado no sistema, enviada de volta uma Mensagem contendo o cdigo 400 (UNKNOWN) no cabealho e a exceo RemoteException como payload.

[UC001 CRUD04] - Atualizar um Profile Entradas condies Sadas condies e e prps Existir o Profile desejo da no sistema Profile atualizado no sistema

Fluxo de Eventos Fluxo Principal 1. Durante a interao do usurio com um Service ou Device, o cliente embarcado cria um UpdateWorker;

2. Invoca-se o mtodo updateProfile do UpdateWorker;

3. O UpdateWorker cliente invoca o seu homnimo remoto no objeto distribudo homnimo servidor; 4. O ProfileTV Server busca o Profile solicitado na sua rea de persistncia; 5. O ProfileTV Server atualiza o Profile recuperado de sua rea de persistncia; 6. O UpdateWorker servidor envia uma Mensagem contendo o cdigo 204 (UPDATED) em seu cabealho; 7. O UpdateWorker cliente retorna TRUE para o cliente embarcado, sinalizando que o Profile foi atualizado. Fluxo Alternativo 1 1. No passo 3 do fluxo principal, caso o Device ou Service no esteja previamente cadastrado no sistema, o cadastro ser efetuado neste momento. 2. Associa-se o Device ou Service ao User passado como argumento no mtodo updateProfile; 3. Prossegue com o passo 4 do fluxo principal. Fluxo Excepcional 1 1. No passo 3 do fluxo principal, caso o Device no esteja conectado rede o UpdateWorker libera uma exceo (NetworkException) que deve ser tratada pelo cliente embarcado (Service ou Device). 1. No passo 4 do fluxo principal, caso o Profile solicitado para atualizao no for encontrado no sistema, enviada de volta uma Mensagem contendo o cdigo 400 (UNKNOWN) no cabealho e a exceo RemoteException como payload.

Fluxo Excepcional 2

145

[UC003] Exportar Profile via bluetooth Descri O ProfileTV permite que um User, Device ou Service exporte via o bluetooth um Profile para um dispositivo porttil. Atores Priorida de User, Device, Service Importante e pr Sadas e condies ps Profile previamente criado no sistema (Device) local O dispositivo porttil deve habilitar o bluetooth; Profile exportado para um dispositivo porttil

Entradas condies

Fluxo de Eventos Fluxo Principal 1. Durante a interao de um User com um Service ou Device, requisitada a exportao do Profile via bluetooth para um dispositivo porttil; 2. O sistema cria um IOWorker bluetooth (BluetoothWorker); especializado para

3. O sistema invoca o exportProfile do IOWorker;

4. O IOWorker especializado realiza um scan na rea a fim de encontrar o dispositivo para o qual enviar o Profile; 5. O IOWorker especializado exporta o Profile para o dispositivo encontrado; 6. O dispositivo deve aceitar o envio do arquivo; 7. A transferncia concluda e o IOWorker especializado termina seu trabalho. Fluxo Alternativo 1

1. No passo 3 do fluxo principal, o sistema invoca o

mtodo exportProfile exclusivo do BluetoothWorker que recebe o nome do dispositivo para o qual o Profile ser exportado;

2. O passo 4 do fluxo principal saltado; 3. Continua-se no passo 5 do fluxo principal. Fluxo Excepcional 1 Fluxo Excepcional 2 1. No passo 4 do fluxo principal, caso o sistema no encontre dispositivos para exportar o Profile, ser lanada a exceo NoDeviceExportException. 1. No passo 1 do fluxo alternativo 1, caso o sistema no encontre o dispositivo para exportar o Profile, ser lanada a exceo NoDeviceExportException.

[UC004] Exportar Profile via USB

146

Descri O ProfileTV permite que um User, Device ou Service exporte via o USB um Profile para um dispositivo porttil. Atores Priorida de User, Device, Service Importante e prps Profile previamente criado no sistema (Device) local Profile exportado para um dispositivo porttil

Entradas condies Sadas e condies

Fluxo de Eventos Fluxo Principal 1. Durante a interao de um User com um Service ou Device, requisitada a exportao do Profile via USB para um dispositivo porttil; 2. O sistema cria um IOWorker especializado para USB (USBWorker);

3. O sistema invoca o exportProfile do IOWorker;

4. O IOWorker especializado exporta o Profile para o dispositivo encontrado; 5. A transferncia concluda e o IOWorker especializado termina seu trabalho. Fluxo Alternativo 1

1. No passo 3 do fluxo principal, o sistema invoca o

mtodo exportProfile exclusivo do USBWorker que recebe a porta no qual o dispositivo est conectado; 2. Continua-se no passo 4 do fluxo principal. 1. No passo 4 do fluxo principal, caso o sistema no encontre o dispositivo porttil conectado na porta padro USB do sistema para exportar o Profile, ser lanada a exceo NoDeviceExportException. 1. No passo 1 do fluxo alternativo 1, caso o sistema no encontre o dispositivo porttil conectado na porta padro USB do sistema para exportar o Profile, ser lanada a exceo NoDeviceExportException.

Fluxo Excepcional 1

Fluxo Excepcional 2

[UC005] Importar Profile via bluetooth Descri O ProfileTV permite que um User, Device ou Service importe via o bluetooth um Profile de um dispositivo porttil para ser utilizado pelo sistema. Atores Priorida de User, Device, Service Importante e pr Profile previamente exportado e armazenado

Entradas condies

147

em um dispositivo porttil Sadas e condies ps O dispositivo porttil deve habilitar o bluetooth Profile importado para o dispositivo ( Device) local

Fluxo de Eventos Fluxo Principal 1. Durante a interao de um User com um Service ou Device, o sistema requisita a importao de um Profile via bluetooth a partir de dispositivo porttil; 2. O dispositivo porttil prepara-se para o envio do Profile; 3. O sistema cria um IOWorker bluetooth (BluetoothWorker); especializado para

4. O sistema invoca o importProfile do IOWorker;

5. O IOWorker especializado cria um host bluetooth para receber o Profile do dispositivo porttil; 6. O dispositivo porttil envia o Profile para o sistema; 7. O IOWorker especializado dispositivo porttil; recebe o Profile do

8. O IOWorker especializado armazena o Profile no dispositivo local (Device) 9. A transferncia concluda e o IOWorker especializado termina seu trabalho. Fluxo Alternativo 1 1. No passo 6 do fluxo principal, o User pode cancelar o envio do Profile para o dispositivo interativo; 2. O IOWorker especializado encerra a conexo; 3. O IOWorker especializado termina seu trabalho. Fluxo Excepcional 1 1. No passo 5 do fluxo principal, caso o envio do arquivo no se inicie em 10s o IOWorker levantar a exceo TimedOutException.

[UC004] Importar Profile via USB Descri O ProfileTV permite que um User, Device ou Service importe via o USB um Profile de um dispositivo porttil para ser utilizado pelo sistema. Atores Priorida de User, Device, Service Importante e pr Profile previamente exportado e armazenado em um dispositivo porttil O dispositivo porttil conectado ao dispositivo interativo

Entradas condies

148

Sadas e condies

ps-

Profile importado para o dispositivo ( Device) local

Fluxo de Eventos Fluxo Principal 1. Durante a interao de um User com um Service ou Device, o sistema requisita a importao de um Profile via USB a partir de dispositivo porttil; 2. O sistema cria um IOWorker especializado para USB (USBWorker);

3. O sistema invoca o importProfile do IOWorker;

4. O IOWorker especializado realiza um scan nas portas USBs do sistema, a procura do dispositivo porttil conectado; 5. O IOWorker importa o Profile do dispositivo porttil; 6. O IOWorker especializado armazena o Profile no dispositivo local (Device) 7. A transferncia concluda e o IOWorker especializado termina seu trabalho. Fluxo Alternativo 1 1. No passo 5 do fluxo principal, o User pode desconectar o dispositivo porttil; 2. O IOWorker especializado encerra a transferncia do Profile; 3. O IOWorker especializado termina seu trabalho. Fluxo Excepcional 1 1. No passo 4 do fluxo principal, caso o IOWorker no encontre o dispositivo porttil conectado na porta padro USB do sistema para importar o Profile, ser lanada a exceo NoDeviceImportException.

149

Apndice D API

Este apndice apresenta API disponibilizada pelo ProfileTV Embedded Client Side Middleware desenvolvido sobre a implementao de referncia do middleware Multimedia Home Plataform (MHP), fornecido pelo IRT.

D.1.
D.1.1.

Communication Package
AbstractCommunicationService

package ufpe.cin.profiletv.communication; /** * <p>Esta uma classe abstrata que prov servios para as classes do * pacote.</p> * <p>Esta selada dentro do jar, impedindo de ser invocada direamente por * aplicaes externas.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public abstract class AbstractCommunicationService { // CONSTANTES -----------------------------------------------------public static final String HOST = "HOST"; public static final String PORT = "PORT"; // Public Methods -------------------------------------------------/** * Mtodo auxiliar, responsvel pelo lookup dos servios. * @param service * Representa o nome do servio a ser buscado. * @return Retorna o objeto remoto solicitado. * @throws AccessException * Problemas durante o acesso ao objeto remoto. * @throws NotBoundException * O objeto remoto requisitado ainda no est vinculado ao * nome pesquisado. * @throws RemoteException * Erro geral durante a requisio do objeto remoto. */ public static Remote lookup(String service) throws AccessException, NotBoundException, RemoteException // DELEGATED METHODS ----------------------------------------------public static boolean containsKey(String service) public static String getProperty(String serice) }

150

D.1.2.

AbstractCommunicationWorker

package ufpe.cin.profiletv.communication; /** * Classe abstrata que define as funcionalidades gerais de um trabalhador * de comunicao. * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public abstract class AbstractCommunicationWorker { // Atributos ------------------------------------------------------protected Vector listeners; // Construtores ---------------------------------------------------protected AbstractCommunicationWorker() // Mtodos Pblicos -----------------------------------------------/** * Adiciona um ouvinte s funcionalides deste trabalhador. * @param listener * Um ouvinte deste trabalhador. * @return <code>true</code> se a adio fi realizada corretamente, * <code>false</code> caso contrrio. */ public boolean addListener(ICommunicationListener listener) /** * Remove um ouvinte das funcionalides deste trabalhador. * @param listener * Um ouvinte deste trabalhador. * @return <code>true</code> se a remoo foi realizada * corretamente, <code>false</code> caso contrrio. */ public boolean removeListener(ICommunicationListener listener) }

D.1.3.

CommunicationFactory

package ufpe.cin.profiletv.communication; /** * Esta classe permite a criao de servios de comunicao. * uma fbrica que gera servios especializados em busca, atualizao * e sincronizao * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public class CommunicationFactory { // CONSTANTES -----------------------------------------------------/** Servio de busca */ public static String SEARCH_SERVICE = "SEARCH_SERVICE"; /** Servio de atualizao */ public static String UPDATE_SERVICE = "UPDATE_SERVICE"; /** Servio de sincronizao */ public static String SYNCHRONIZATION_SERVICE = "SYNCHRONIZATION_SERVICE"; // GETTERS & SETTERS ----------------------------------------------public static CommunicationFactory getInstance() // FactoryMethod --------------------------------------------------/**

151

* <p>Este o <i>FactoryMethod</i> desta classe.</p> * <p>Atravs deste mtodo so criados os servios de comunicao * baseados no argumento passado como parmetro.</p> * @param type * O tipo de <code>AbstractCommunicationWorker</code> solicitado. * @return * Um tipo AbstractCommunicationWorker especializado no tipo de * comunicao solicitada. */ public AbstractCommunicationWorker getWorker(String type) throws MalformedURLException, RemoteException, NotBoundException }

D.1.4.

SearchWorker

package ufpe.cin.profiletv.communication; /** * <p>Esta classe representa o trabalhador especializado em buscas.</p> * @author <a href=mailto:assc@cin.ufpe.br>Andrino S. S. Colho</a> */ public class SearchWorker extends AbstractCommunicationWorker { // CONSTRUTORES -------------------------------------------------SearchWorker(String search_service) throws MalformedURLException, RemoteException, NotBoundException // Delegated Methods --------------------------------------------/** * Busca os Profiles associados a um Device. * @param deviceId * Identificao nica do dispositivo. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.ISearchService# * searchProfileByDevice(java.lang.String) */ public Message searchProfileByDevice(String deviceId) throws RemoteException /** * Busca os Profiles do User associados a um Device * @param deviceID * Identificao nica do dispositivo. * @param login * Identificao nica do usurio. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.ISearchService# * searchProfileByDevicePerUser(String, String) */ public Message searchProfileByDevicePerUser(String deviceID, String login) throws RemoteException

152

/** * Busca os Profiles do User associados dupla (Service, Device). * @param sid * O identificador nica deste servio dentro daquele provedor de * contedo. * @param oid * O identificador do provedor de contedo. * @param deviceID * Identificao nica do dispositivo. * @param login * Identificao nica do usurio. * @return Message * A mensagem contendo cdigo de <i>status</i> e um <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.ISearchService# * searchProfileByServiceOnDevicePerUser(short, long, String, String) */ public Message searchProfileByServiceOnDevicePerUser(short oid, long sid, String deviceID, String login) throws RemoteException /** * Busca os Profiles do User associados a um Service. * @param sid * O identificador nica deste servio dentro daquele provedor de * contedo. * @param oid * O identificador do provedor de contedo. * @param login * Identificao nica do usurio. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.ISearchService# * searchProfileByServicePerUser(short, long, java.lang.String) */ public Message searchProfileByServicePerUser(short oid, long sid, String login) throws RemoteException /** * Busca Profiles associados a um User. * @param login * Identificao nica do usurio. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.ISearchService# * searchProfileByUser(java.lang.String) */ public Message searchProfileByUser(String arg0) throws RemoteException

153

D.1.5.

SynchronizationWorker

package ufpe.cin.profiletv.communication; /** * Esta classe representa o trabalhador especializado em sincronizao * @author <a href=mailto:assc@cin.ufpe.br>Andrino S. S. Colho</a> */ public class SynchronizationWorker extends AbstractCommunicationWorker { // CONSTRUTORES ---------------------------------------------------SynchronizationWorker(String synchronization_service) throws MalformedURLException, RemoteException, NotBoundException // DELEGATED METHODS -----------------------------------------------------/** * Cria um perfil a partir da categoria, do usurio e do servio * associado. * @param sid * O identificador nica deste servio dentro daquele provedor de * contedo. * @param oid * O identificador do provedor de contedo. * @param login * Identificao nica do usurio. * @param categoryID * Identificao nica da categoria. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.SynchronizationService# * createProfile(short, long, java.lang.String, java.lang.String) */ public Message createProfile(short oid, long sid, String login, String categoryID) throws RemoteException /** * Cria um perfil a partir da categoria, do usurio, servio e * dispositivo associado. * @param deviceID * Identificao nica do dispositivo. * @param sid * O identificador nica deste servio dentro daquele provedor de * contedo. * @param oid * O identificador do provedor de contedo. * @param login * Identificao nica do usurio. * @param categoryID * Identificao nica da categoria. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.SynchronizationService#

154

* createProfile(String, short, long, String, String) */ public Message createProfile(String deviceID, short oid, long sid, String login, String categoryID) throws RemoteException /** * Cria um perfil a partir da categoria, do usurio e do dispositivo * associado. * @param deviceID * Identificao nica do dispositivo. * @param login * Identificao nica do usurio. * @param categoryID * Identificao nica da categoria. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.SynchronizationService# * createProfile(String, String, String) */ public Message createProfile(String deviceID, String login, String categoryID) throws RemoteException /** * Sincroniza um perfil. * @param profileID * Identificao nica do perfil. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.SynchronizationService# * synchronizeProfile(long) */ public Message synchronizeProfile(long profileID) throws RemoteException /** * Sincroniza um perfil. * @param deviceID * Identificao nica do dispositivo. * @param sid * O identificador nica deste servio dentro daquele provedor de * contedo. * @param oid * O identificador do provedor de contedo. * @param login * Identificao nica do usurio. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.SynchronizationService# * synchronizeProfile(String, short, long, String)

155

*/ public Message synchronizeProfile(String deviceID, short oid, long sid, String login) throws RemoteException /** * Atualiza um perfil local no servidor. * @param profile * O perfil local a ser atualizado no servidor. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.SynchronizationService# * updateProfile(SProfile) */ public Message updateProfile(SProfile profile) throws RemoteException }

D.1.6.

UpdateWorker

package ufpe.cin.profiletv.communication; /** * <p>Esta classe representa o trabalhador especializado em atualizao. * @author <a href=mailto:assc@cin.ufpe.br>Andrino S. S. Colho</a> */ public class UpdateWorker extends AbstractCommunicationWorker { // CONSTRUTORES --------------------------------------------------UpdateWorker(String update_service) throws MalformedURLException, RemoteException, NotBoundException /** * Cria um dispositivo no servidor. * @param device * O device a ser criado no servidor. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.IUpdateService# * createDevice(ufpe.cin.profiletv.communication.entity.SDevice) */ public Message createDevice(SDevice device) throws RemoteException /** * Cria um perfil a partir da categoria, do usurio e do servio * associado. * @param sid * O identificador nica deste servio dentro daquele provedor de * contedo. * @param oid * O identificador do provedor de contedo. * @param login * Identificao nica do usurio. * @param categoryID * Identificao nica da categoria. * @return Message

156

* A mensagem contendo cdigo de <i>status</i> e um <i>payload</i>. * * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.IUpdateService# * createProfile(short, long, java.lang.String, java.lang.String) */ public Message createProfile(short oid, long sid, String login, String categoryID) throws RemoteException /** * Cria um perfil a partir da categoria, do usurio, servio e * dispositivo associado. * @param deviceID * Identificao nica do dispositivo. * @param sid * O identificador nica deste servio dentro daquele provedor de * contedo. * @param oid * O identificador do provedor de contedo. * @param login * Identificao nica do usurio. * @param categoryID * Identificao nica da categoria. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.SynchronizationService# * createProfile(String, short, long, String, String) */ public Message createProfile(String deviceID, short oid, long sid, String login, String categoryID) throws RemoteException /** * Cria um perfil a partir da categoria, do usurio e do dispositivo * associado. * @param deviceID * Identificao nica do dispositivo. * @param login * Identificao nica do usurio. * @param categoryID * Identificao nica da categoria. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.SynchronizationService# * createProfile(String, String, String) */ public Message createProfile(String deviceID, String login, String categoryID) throws RemoteException /**

157

* Cria um servio no servidor. * @param _service * O servio a ser criado no servidor. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.IUpdateService# * createService(ufpe.cin.profiletv.communication.entity.SService) */ public Message createService(SService _service) throws RemoteException /** * Cria um usurio no servidor. * @param user * O usupario a ser criado no servidor. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.IUpdateService# * createUser(ufpe.cin.profiletv.communication.entity.SUser) */ public Message createUser(SUser user) throws RemoteException /** * Atualiza um dispositivo no servidor. * @param device * O device a ser criado no servidor. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.IUpdateService# * updateDevice(ufpe.cin.profiletv.communication.entity.SDevice) */ public Message updateDevice(SDevice arg0) throws RemoteException /** * Atualiza um perfil no servidor. * @param profile * O perfil a ser criado no servidor. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.IUpdateService# * updateProfile(ufpe.cin.profiletv.communication.entity.SProfile) */ public Message updateProfile(SProfile profile) throws RemoteException

158

/** * Atualiza um servio no servidor. * @param _service * O servio a ser criado no servidor. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.IUpdateService# * updateService(ufpe.cin.profiletv.communication.entity.SService) */ public Message updateService(SService _service) throws RemoteException /** * Atualiza um usurio no servidor. * @param user * O usupario a ser criado no servidor. * @return Message * A mensagem contendo cdigo de <i>status</i> e o <i>payload</i> * @throws RemoteException * Quando algum erro acontecer durante a invocao remota de * mtodo. * @see ufpe.cin.profiletv.communication.protocol.message.Message * @see ufpe.cin.profiletv.communication.rmi.IUpdateService# * updateUser(ufpe.cin.profiletv.communication.entity.SUser) */ public Message updateUser(SUser user) throws RemoteException

D.2.
D.2.1.

Communication Event Package

CommunicationEvent

package ufpe.cin.profiletv.communication.event; /** * <p>Esta classe representa um evento levantado pelos trabalhadores * do mdulo de comunicao.</p> * @author <a href=mailto:assc@cin.ufpe.br>Andrino S. S. Colho</a> */ public class CommunicationEvent { // Construtores -------------------------------------------------public CommunicationEvent() public CommunicationEvent(short statusMessage, Object payload) // Getters & Setters --------------------------------------------public Object getPayload() public void setPayload(Object payload) public short getStatusMessage() public void setStatusMessage(short statusMessage)

159

D.2.2.

ICommunicationListener

package ufpe.cin.profiletv.communication.event; /** * <p>Esta interface define as funcionalidades de um ouvinte dos trabalhos * de um trabalhador de comunicao especializado.</p> * @author <a href=mailto:assc@cin.ufpe.br>Andrino S. S. Colho</a> */ public interface ICommunicationListener { /** * <p>Este mtodo precisa ser implementado por todos os interessados * em receber notificaes relacionadas ao trabalho de comunicao * de um dado trbalhador.</p> * * @param event * O evento contendo informaes relacionadas. */ void receiveCommunicationEvent(CommunicationEvent event); }

D.3.
D.3.1.

IO Package
AbstractIOService

package ufpe.cin.profiletv.io; /** * <p>Esta uma classe abstrata que prov servios para as classes do pacote.</p> * <p>Esta selada dentro do jar, impedindo de ser invocada direamente por * aplicaes externas.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public abstract class AbstractIOService { // CONSTANTES ---------------------------------------------------public static final String EXTENSION = "EXTENSION"; // DELEGATED METHODS --------------------------------------------/** * @param service * @return * @see java.util.Hashtable#containsKey(java.lang.Object) */ public static boolean containsKey(String service) /** * @param serice * @return * @see java.util.Properties#getProperty(java.lang.String) */ public static String getProperty(String service)

D.3.2.

BluetoothWorker

package ufpe.cin.profiletv.io; /** * <p>Este o trabalhador de entrada e sada via Bluetooth.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */

160

public class BluetoothWorker implements IOWorker { /** * <p>Exporta um profile atravs da sada Bluetooh do dispositivo. * <p>Sugere-se que para este tipo de exportao crie-se uma thread * separada para manusear a conexo. s vezes a busca por dispositivos * conhecidos na rea demora um pouco, fazendo com que o servio ou * dispositivo interativo mantenha-se travado durante a execuo * deste mtodo. * @param profile * O perfil a ser exportado. * @param filename * O nome do arquivo a ser criado. Por conveno sugere-se * a criao de arquivos com o nome da aplicao ou dispositivo * interativo. */ public void exportProfile(SProfile profile, String filename) /** * Importa um perfil em um arquivo a partir de seu nome passado como * argumento via Bluetooh * @param filename * O nome do arquivo que contm o perfil associado. * @return O perfil existente dentro do arquivo exportado com o * nome passado como argumento. */ public SProfile importProfile(String filename)

D.3.3.

IIOFactory

package ufpe.cin.profiletv.io; /** * Esta interface determina os tipos de trabalhadores baseados nos tipos * suportados de importao/exportao. * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public interface IIOFactory { /** Define o tipo byte BLUETOOTH /** Define o tipo byte INFRA_RED /** Define o tipo byte USB /** Define o tipo byte WI_FI Bluetooth */ = 01; Infrared */ = 02; USB */ = 03; Wi-fi */ = 04;

/** * <p>Este FactoryMethod cria objetos especializados em exportao * e importao de perfis.</p> * @param type * O tipo de trabalhador especializado requerido. * @return O trabalhador solicitado. */ IOWorker createIOWorker(byte type); }

161

D.3.4.

InfraredWorker

package ufpe.cin.profiletv.io; /** * <p>Este o trabalhador de entrada e sada via porta Infrared.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public class InfraredWorker implements IOWorker { /** * @see ufpe.cin.profiletv.io.IOWorker#exportProfile(SProfile, String) */ public void exportProfile(SProfile profile, String filename) /** * @see ufpe.cin.profiletv.io.IOWorker#importProfile(String) */ public SProfile importProfile(String filename)

D.3.5.

IOFactory

package ufpe.cin.profiletv.io; /** * <p>Esta classe uma fbrica concreta para criao de trabalhadores * especializados em exportar e importar perfis.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> * @see ufpe.cin.profiletv.io.IIOFactory */ public class IOFactory implements IIOFactory { // GETTERS & SETTERS --------------------------------------------public static IOFactory getInstance() public IOWorker createIOWorker(byte type) }

D.3.6.

IOWorker

package ufpe.cin.profiletv.io; /** * <p>Esta interface determina as funes bsicas para todo trabalhador de * entrada e sada.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public interface IOWorker { /** * Exporta um profile atravs do meio de sada determinado. * @param profile * O perfil a ser exportado. * @param filename * O nome do arquivo a ser criado. Por conveno sugere-se * a criao de arquivos com o nome da aplicao ou dispositivo * interativo. */ void exportProfile(SProfile profile, String filename); /**

162

* Importa um perfil em um arquivo a partir de seu nome passado como * argumento * @param filename * O nome do arquivo que contm o perfil associado. * @return O perfil existente dentro do arquivo exportado com o * nome passado como argumento. */ SProfile importProfile(String filename);

D.3.7.

USBWorker

package ufpe.cin.profiletv.io; /** * <p>Este o trabalhador de entrada e sada via porta USB.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public class USBWorker implements IOWorker { // CONSTANTES ---------------------------------------------------/** Identifica o diretrio padro de sada. */ public static final String STANDARD_DIRECTORY = "DIRECTORY"; // CONSTRUTORES -------------------------------------------------USBWorker() // IOWorker IMPLEMENTATION --------------------------------------/** * @see ufpe.cin.profiletv.io.IOWorker# * exportProfile(SProfile, String) */ public void exportProfile(SProfile profile, String fileName) /** * @see ufpe.cin.profiletv.io.IOWorker#importProfile(String) */ public SProfile importProfile(String fileName)

D.3.8.

WifiWorker

package ufpe.cin.profiletv.io; /** * <p>Este o trabalhador de entrada e sada via porta Wi-fi.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public class WifiWorker implements IOWorker { /** * @see ufpe.cin.profiletv.io.IOWorker# * exportProfile(SProfile, String) */ public void exportProfile(SProfile profile, String filename) /** * @see ufpe.cin.profiletv.io.IOWorker#importProfile(String) */ public SProfile importProfile(String filename) }

163

D.4.
D.4.1.

Logging Package
AbstractLogger

package ufpe.cin.profiletv.logging; /** * <p>Esta classe abstrata define as funcionalidades que todo logger * precisa dispor.</p> * <p>Esta classe funciona como uma Chain of Responsibility (Cor). Assim * possvel se criar vrios logger encadeados, cada um responsvel pela * gerao de loggings especficos para cada sada desejada.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public abstract class AbstractLogger { // ATRIBUTOS ----------------------------------------------------/** Fluxo de erro */ protected PrintStream out; /** Prximo logger na cadeia */ protected AbstractLogger next; /** Classe onde gerado o Log */ protected Class clazz; // CONSTRUTORES -------------------------------------------------protected AbstractLogger(Level _level, Class clazz) // GET & SETTERS ------------------------------------------------public Level getMask() public void setMask(Level mask) public AbstractLogger getNext() public void setNext(AbstractLogger next) // PUBLIC METHODS -----------------------------------------------/** * Retorna o logger padro do Sistema. * @param clazz * A classe que o logger se vincular. * @return O logger padro do Sistema */ public static final AbstractLogger global(Class clazz) /* * Loga mensagens do tipo referido pelo nome do mtodo. * @param message */ public void debug(String message) public void info(String message) public void warn(String message) public void error(String message) public void fatal(String message) // Mtodos protegidos -------------------------------------------/** * <p>Este mtodo deve ser implementado por todo logger filho.</p> * <p> Este mtodo quem realiza o logging de uma mensagem. * @param message */ protected abstract void writeMessage(String message);

164

D.4.2.

Level

package ufpe.cin.profiletv.logging; /** * <p>Esta classe representa um nvel para o sistema de logging.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> * @see java.lang.Comparable */ public class Level implements Comparable { // CONSTANTES public static public static public static public static public static public static public static ---------------------------------------------------final Level DEBUG = new Level((byte) 01); final Level INFO = new Level((byte) 02); final Level WARN = new Level((byte) 03); final Level ERROR = new Level((byte) 04); final Level FATAL = new Level((byte) 05); final Level ALL = new Level((byte) 06); final Level OFF = new Level((byte) 00);

// CONSTRUTORES -------------------------------------------------/** * Cria um nvel */ public Level(byte _level) // GETTERS & SETTERS --------------------------------------------protected byte getLevel() protected void setLevel(byte level) // Comparable IMPLEMENTATION ------------------------------------/** * Compara apenas objetos do tipo Level. * Utilizado na identificao do nvel do log e de quias mensagens * podero ser logadas no sistema a partir do nvel vigente. * @param _level * O Level a ser comparada com este level * @return * Um inteiro indicando se este level mais alto ou mais baixo * que level passado como argumento. * @see java.lang.Comparable#compareTo(Object) */ public int compareTo(Object _level) }

D.4.3.

ProfiletvLogger

package ufpe.cin.profiletv.logging; /** * <p>Esta classe abstrata define as funcionalidades que todo logger * precisa dispor.</p> * <p>Um exemplo de logging de Debug: * <ul> * <li> Thu Jul 31 23:52:36 GMT-03:00 2008 (DEBUG): Gerando Perfis * </ul> * <p>Esta classe funciona como uma Chain of Responsibility (Cor). Assim * possvel se criar vrios logger encadeados, cada um responsvel pela * gerao de loggings especficos para cada sada desejada.</p> * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public class ProfiletvLogger extends AbstractLogger {

165

// Construtores -------------------------------------------------public ProfiletvLogger(Class clazz) // Mtodos pblicos ---------------------------------------------/** * @see ufpe.cin.profiletv.logging.AbstractLogger# * writeMessage(String) */ public void writeMessage(String message)

D.5.
D.5.1.

Persistence Package
PersistenceRegister

package ufpe.cin.profiletv.persistence; /** * Esta classe representa o controlador de acesso ao sistema de * armazenamento persistente de informao. * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public class PersistenceRegister { // GETTERS & SETTERS --------------------------------------------public static final PersistenceRegister getInstance() // PUBLIC METHODS -----------------------------------------------/** * Permite que um determinado objeto seja armazenado */ public void putProfile(SProfile object, Key key) /** * Permite que um determinado objeto seja armazenado */ public SProfile getProfile(Key key) /** * Armazena o determinado objeto */ public boolean storeProfile() /** * @see java.util.Map#remove(java.lang.Object) */ public Object removeProfile(Key key) /** * @see java.util.Map#values() */ public Collection deviceValues() /** * @see java.util.Map#values() */ public Collection serviceValues() // DELEGATED METHODS --------------------------------------------/** * @see java.util.Map#containsKey(java.lang.Object) */

166

public boolean containsKey(Key key) /** * @see java.util.Map#containsValue(java.lang.Object) */ public boolean containsValue(SProfile profile) /** * @see java.util.Map#isEmpty() */ public boolean isEmpty() }

D.6.
D.6.1.

Persistence Key Package

CompositeKey

package ufpe.cin.profiletv.persistence.key; /** * Representa uma chave primria composta. * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public class CompositeKey extends SingleKey { // Construtores -------------------------------------------------public CompositeKey(Object[] _key) // GETTERS & SETTERS --------------------------------------------public Object[] getKeys() public void setKeys(Object[] key) // OVERRIDES SingleKey ------------------------------------------public Object getKey(byte offset) public void setKey(byte offset, Object key) }

D.6.2.

Key

package ufpe.cin.profiletv.persistence.key; /** * Utilizada apenas como marcador. * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public interface Key extends Serializable

D.6.3.

SingleKey

package ufpe.cin.profiletv.persistence.key; /** * Representa uma chave primria simples. * @author <a href="mailto:assc@cin.ufpe.br">Andrino S. S. Colho</a> */ public class SingleKey implements Key { // CONSTRUTORES -------------------------------------------------public SingleKey(Object _key) // GETTERS & SETTERS ---------------------------------------------

167

public Object getKey() public void setKey(Object key)

168