SISTEMA DE DISTRIBUIÇÃO DE PUBLICIDADE DIGITAL

Transcrição

1 FÁBIO CHIOCCHETTI GUARITA FLÁVIO MIYAMARU MARCEL MASSAKI KANEKO Prof. Orientador: ANDRÉ RIYUITI HIRAKAWA SISTEMA DE DISTRIBUIÇÃO DE PUBLICIDADE DIGITAL SÃO PAULO 2007

2 FÁBIO CHIOCCHETTI GUARITA FLÁVIO MIYAMARU MARCEL MASSAKI KANEKO SISTEMA DE DISTRIBUIÇÃO DE PUBLICIDADE DIGITAL Dissertação apresentada à Escola Politécnica da Universidade de São Paulo como trabalho de conclusão do curso de Engenharia Elétrica com Ênfase em Computação SÃO PAULO 2007

3 FÁBIO CHIOCCHETTI GUARITA FLÁVIO MIYAMARU MARCEL MASSAKI KANEKO SISTEMA DE DISTRIBUIÇÃO DE PUBLICIDADE DIGITAL Dissertação apresentada à Escola Politécnica da Universidade de São Paulo como trabalho de conclusão do curso de Engenharia Elétrica com Ênfase em Computação Área de Concentração: Engenharia da Computação Orientador: Prof. Dr. André Riyuiti Hirakawa SÃO PAULO 2007

4 RESUMO Dada a constante procura por meios mais efetivos de comunicação pelo mercado publicitário, aliada à proibição do uso de outdoors e semelhantes na cidade de São Paulo decorrente da Lei Cidade Limpa (Lei Municipal /06), o grupo identificou uma necessidade para a qual direcionar os esforços do Projeto de Formatura. Analisando as novas tendências, o grupo chegou ao conceito de Digital Signage, meio de comunicação indoor já em pleno uso no exterior, mas que ainda se encontra em fase embrionária no Brasil, com potencial imenso de crescimento. Este documento versa sobre o projeto e a implementação de uma solução de Digital Signage. Esta solução tem por objetivos principais ser de fácil utilização pelo usuário final e permitir uma maior personalização quanto às possibilidades do sistema. O documento contempla ainda todas as fases do desenvolvimento, além de uma análise dos resultados finais obtidos, propondo melhorias ao sistema desenvolvido.

5 ABSTRACT Given the publicity market s persistent search for more effective ways of communication, allied to the recently approved law (City Law /06) that banned billboard advertising in Sao Paulo, the group identified a current necessity to focus their efforts on as a graduation project. Through the study of new tendencies, the group has reached the concept of Digital Signage, an indoor way of communication widely used overseas but still found in its early stages of adoption in Brazil, where it presents a huge potential of growth. This document details the design and implementation of a Digital Signage solution. This solution presents as main objectives its ease of use by its final users, as well as a higher level of customization regarding the system s possibilities. The document also details all of the system development steps and an analysis on the final results, giving advice for further improvement on the developed system.

6 LISTA DE ILUSTRAÇÕES Figura 1 - Exemplo de sinalização digital para agências bancárias Figura 2 - Exemplo de sinalização digital como painel publicitário Figura 3 - Arquitetura em blocos Figura 4 - Arquitetura diagramada do sistema Figura 5 Modelo utilizado para simulação do sistema Figura 6 - Fluxo de sincronizar programação Figura 7 - Arquitetura dos softwares Figura 8 - Diagrama de classes A Figura 9 - Diagrama de Classes B Figura 10 - Diagrama de Classes C Figura 11 - Diagrama de Classes - Somente entidades Figura 12 - Diagrama do modelo físico de dados Figura 13- Diagrama de interfaces Figura 14 - Associação do mapa de navegação com os casos de uso Figura 15 - Wireframe do modelo geral Figura 16 - Wireframe de modelo de lista Figura 17 - Wireframe modelo inserir Figura 18 - Wireframe do modelo de detalhe Figura 19 - Wireframe modelo de edição Figura 20 - Wireframe do modelo de exclusão Figura 21 - WF-01 - Wireframe da lista de tarefas Figura 22 - WF-02 - Selecionar o Terminal Figura 23 - WF-03 - Wireframe para inserção de uma tarefa Figura 24 - WF-04 - Wireframe da agenda de tarefas Figura 25 - WF-06 Wireframe de detalhes do vídeo Figura 26 - Wireframe de inserção de template Figura 27 - Wireframe de template para o terminal com 3 posições para FlashParts (4:3) Figura 28 - Wireframe de template para o terminal com uma posição para FlashPart (16:9) Figura 29 - Caso de inclusão de tarefa em horário ocupado por um a tarefa Figura 30 - Caso de inclusão de tarefa em intervalo sobreposto a duas tarefa Figura 31 - Caso de inclusão com conflito com três ou mais tarefas Figura 32 - Formato do arquivo XML de programação Figura 33 - Código para utilizar arquivos swf como vídeos Figura 34 - Arquitetura com terminal isolado Figura 35 - Arquitetura cliente-servidor Figura 36 - Arquitetura com servidor externo, servidor local e terminais Figura 37 - Cronograma detalhado - 1o semestre

7 Figura 38 - Cronograma detalhado - 1o semestre parte Figura 39 - Cronograma detalhado - 2o semestre Figura 40 - Cronograma detalhado - 2o semestre parte Figura 41 - Modelo A para simulação Figura 42 - Modelo B para simulação Figura 43 - Modelo C para simulação

8 LISTA DE TABELAS Tabela 1 - Cronograma macro do 1o semestre Tabela 2 - Cronograma macro do 2o semestre Tabela 3 - Hardware do Terminal Tabela 4 - Hardware dos monitores Tabela 5 - Hardware do Servidor Tabela 6 - Hardware do Switch Tabela 7 - Parâmetros para codificação do ffmpeg Tabela 8 Relação das principais funções de cada tabela Tabela 9 - Lista detalhada das colunas das tabelas do banco de dados Tabela 10- Continuação da lista detalhada das colunas das tabelas do banco de dados Tabela 11 - Casos de usos relacionados a cada módulo da interface

9 SUMÁRIO 1. Introdução Proposta do Projeto Justificativa do Projeto Conceito Vantagens Desvantagens Exemplos Planejamento Especificação do Sistema Descrição Geral Perspectivas do Produto Interfaces de Usuários Interfaces de Hardware Interfaces com Software Interfaces de Comunicação Características dos Usuários Arquitetura do Sistema Funções do Sistema Requisitos Não-Funcionais Acessibilidade Confiabilidade Qualidade Flexibilidade Segurança Usabilidade Restrições Limitações de Hardware Limitações da Interface com Outras Aplicações Operações Paralelas Funções de Auditoria Limitações de Compatibilidade Funções de Controle... 31

10 Requisitos de Ambientes de Desenvolvimento Restrição Funcional Estudo de tecnologias Conversão de Vídeos FFmpeg FlashServer Limitação de Redes Casos de Uso Casos de Uso do Terminal Sincronizar Programação Armazenar dados de exibição Reproduzir vídeo Casos de uso do servidor Realizar login Consultar ajuda Casos de uso de Administração Gerenciar cadastro de usuários Gerenciar perfis de usuário Gerenciar cadastro de terminais Visualizar relatórios Casos de uso de Bibliotecas Gerenciar vídeos do Servidor Gerenciar FlashParts do servidor Gerenciar cadastro de templates Casos de uso de Programação Gerenciar Tarefa Visualizar Agenda Diagrama de Classes Modelo Físico de Dados Interfaces de Dados Interface entre Subsistema e Atores Interface entre Subsistemas Interfaces de Acesso a Dados Externos Mapa de Navegação Wireframes Modelo Geral Modelo Lista Modelo Inserir... 81

11 Modelo Detalhe Modelo Editar Modelo Excluir WF -01 Lista de Tarefas WF Selecionar Terminal WF Inserir Tarefa WF Visualizar Agenda WF -05 Detalhes do vídeo WF -06 Inserir template FlashParts Definição Potencial e Restrições FlashParts Desenvolvidos Previsão do Tempo Descrição Requisitos Funcionais Requisitos Não-Funcionais Implementação Notícias Descrição Requisitos Funcionais Requisitos Não-Funcionais Implementação Relógio Requisitos Funcionais Requisitos Não-Funcionais Implementação Desenvolvimento Metodologia de Desenvolvimento Divisão da Tela em Frames Ferramentas Utilizadas Linguagens utilizadas PHP PHP Hypertext Preprocessor ActionScript JavaScript C#.NET Plataformas

12 NET MySQL Servidor PHP Flash Player IDEs Zend Adobe Flash CS Microsoft Visual Studio Configuração inicial e prototipagem Configuração do Ambiente de Desenvolvimento Configuração do Ambiente de Execução Servidor central: Computadores Terminais: Árvore de Diretórios Computador terminal: Servidor central: Protótipo e-sign server e-sign player Classes PHP Testes com FTP Testes de Construção de XML Detalhes de Implementação e-sign server Log SQL Mudança no Banco de Dados para Upload de Vídeos Estudo de Nova Feature e Regra de Negócio Para Tarefa Terminal e-sign player Leitura do XML de Programação Exibição das Tarefas Requisição de Geração do Log Loop de Arquivos SWF Modelagem e-sign sync Memória Utilizada Testes e Avaliação

13 8.1. Screenshots e-sign server Login Modelo Lista Modelo Inserir Modelo Detalhe Modelo Editar Modelo Excluir Tarefas Agenda Vídeo Inserir Template e-sign player Observações Requisitos Não-Atendidos Versões Futuras Conclusão Referencias Bibliográficas GLOSSÁRIO APÊNDICE APÊNDICE A Vantagens financeiras do sistema de sinalização digital APÊNDICE B Modelos de arquiteturas para sinalização digital ANEXOS ANEXO A Cronograma detalhado do projeto ANEXO B Entrevista com Motivu ANEXO C Configuração do Flash Player ANEXO D Análise do impacto na rede

14 1. Introdução O presente documento apresenta e especifica o Sistema e-sign de distribuição de publicidade digital (Digital Signage). O documento é composto pelas seguintes seções: Introdução: Esta descrição inicial do documento Proposta do Projeto: Explica qual problema o sistema se propõe a resolver. Isto é, o escopo do projeto. Justificativa do Projeto: Expõe o motivo do projeto e porque é interessante o seu desenvolvimento. Conceitos: Define o conceito de sinalização digital, suas vantagens e desvantagens. Especificação do Sistema: Descrição detalhada do funcionamento do sistema. Inclui descrições do produto, interação com software, hardware e usuários, requisitos funcionais e não-funcionais, diagramas explicativos, casos de uso e wireframes. Planejamento: Descrição detalhada das etapas do projeto, com o cronograma macro das duas fases do projeto. Desenvolvimento: Descreve toda a fase de desenvolvimento do sistema, técnicas e ferramentas utilizadas, dificuldades encontradas, soluções propostas e outros detalhes técnicos. Testes e Avaliação: Descreve os resultados obtidos, as funcionalidades desenvolvidas, os requisitos não-atendidos e melhorias para versões futuras. Conclusão: Explana sobre os resultados obtidos com o estudo de caso e das funcionalidades desenvolvidas. 11

15 2. Proposta do Projeto A proposta do projeto é o desenvolvimento de um sistema de gerenciamento e exibição de conteúdo multimídia (propaganda) em displays de vídeo, com um controle centralizado e flexibilidade para instalação de novas funcionalidades. O sistema é composto por terminais de exibição, formados por monitores ou televisores, e uma central responsável pelo controle da programação dos terminais, pelo tratamento dos vídeos e imagens e pelo acesso à configuração do sistema por usuários externos à rede. O terminal recebe os dados do computador central e transmite ao monitor as informações de acordo com a programação recebida, nos horários determinados. O servidor agrega as funções de organizar a programação, inserir conteúdo (vídeos e pequenos aplicativos com conteúdos dinâmicos) no sistema e distribuir este conteúdo para os terminais. Nele, podem-se identificar quantos e quais terminais estão conectados, bem como visualizar e editar a programação de cada um deles. A edição da programação de um terminal é feita de forma simples, pela inclusão de tarefas nas quais são inseridos os vídeos de uma lista previamente armazenada no sistema. Em cada tarefa pode ser configurada a freqüência de projeção (periodicidade), quantidade de repetições, horários, entre outros. Serão gerados relatórios sobre o funcionamento do sistema, como, por exemplo, a quantidade de vezes que um vídeo foi executado ou a porcentagem de tempo dedicada a comerciais. Este software central deve apresentar todas as suas funcionalidades acessíveis pela internet. O sistema possibilita a inclusão de FlashParts (mini-aplicativos) que realizarão funções especificas como a exibição de notícias ou da cotação da bolsa de valores. A instalação e exibição de FlashParts será integrada ao sistema central. A gama de aplicações do sistema é enorme. Porém, para esta primeira versão, o foco estará na veiculação de publicidade e na possibilidade de agregar componentes. 12

16 3. Justificativa do Projeto O mercado brasileiro e mundial de publicidade digital vem em grande expansão principalmente devido à internet. Este nicho de mercado compreende a criação de websites institucionais, banners, links patrocinados, entre outros. A TV, meio de comunicação de décadas, tem um importante papel no campo publicitário, por ser um meio de grande penetração na sociedade e que pode provocar bons resultados diante de uma boa campanha veiculada. No Brasil, a publicidade em locais fechados, como shoppings, lojas de departamento e supermercados é realizada com a promoção de produtos e serviços através de cartazes impressos, vídeos promocionais e stands de degustação. Na Europa, America do Norte e Sudeste Asiático, meios de comunicação em áreas internas e externas estão convergindo para meios eletrônicos, tais como painéis digitais, televisores de plasma e LCD, totens eletrônicos, entre outros. Esta forma eletrônica de distribuir informação e publicidade foi denominada Digital Signage, uma forma de mídia para áreas livres (internas ou externas), no qual vídeos e mensagens são exibidos em telas eletrônicas e que podem ser alterados sem mudanças da estrutura física. Geralmente, tem-se como objetivo focar mensagens em locais específicos, em horários específicos. Segundo pesquisa de avaliação de mercados futuros, conduzida pela conceituada empresa DisplaySearch, o mercado mundial de Digital Signage utilizado pelo varejo espera crescer de US$1.4 bilhões em 2006 para US$2.8 bilhões em Já o de Digital Signage indoor terá o crescimento explosivo de US$704 milhões em 2006 para US$7.2 bilhões em O mercado nacional de sinalização digital está em um estágio embrionário, com apenas uma dezena de empresas com soluções neste segmento. Dentre elas, duas se destacam: Elemidia e CerejaPRN. A Elemidia iniciou seus negócios em 2003 com o foco em instalação de displays de sinalização digital em elevadores de prédios comerciais. Seu retorno financeiro é gerado através da venda de espaços publicitários. A CerejaPRN, empresa constituída no ano de 2007, com a união de uma empresa de publicidade - a Cereja Digital - com a norte-americana PRN (Premier Retail 13

17 Networks), instalou em mais de cem hipermercados brasileiros redes de sinalização digital na qual veiculam conteúdo disponibilizado pelo canal GloboSat, além de anúncios publicitários. Um fator impulsionador para a utilização de sistemas de sinalização digital é a redução dos custos dos equipamentos necessários para a implantação de um sistema completo. No inicio do ano de 2007 foi aprovada a lei que proíbe o uso de outdoors e semelhantes na cidade de São Paulo, nomeada Lei Cidade Limpa (Lei Municipal /06). Desta forma, o mercado publicitário perdeu um meio de veiculação outof-home (fora do lar) muito importante, iniciando o investimento em soluções de propaganda em locais fechados. Diante deste panorama, o grupo optou por este projeto, que engloba o estudo de caso de um sistema de sinalização digital, realizando todo o processo de planejamento, prototipagem, desenvolvimento e testes. O grande diferencial estará na possibilidade de criação independente de novas funcionalidades para o sistema, através das FlashParts, sem a necessidade de alterar as aplicações-base. 14

18 4. Conceito Sistema de sinalização digital (Digital Signage) é um meio de comunicação interno que veicula conteúdo digital (filmes, animações, informes e aplicações) em painéis eletrônicos, na sua maioria displays LCD. As principais aplicações destes sistemas são o de serviço de informação e a veiculação de propaganda. Como provedor de informações, o sistema de sinalização digital pode ser utilizado: Em aeroportos, com informações dos vôos; Em estações de trem e metrô, com tempo de espera para o próximo trem; Em salas de espera de consultórios, hospitais, salões de beleza, elevadores, e outros, provendo publicidade, previsão do tempo, notícias; Em empresas com vídeos e mensagens institucionais (premiações, metas, visão, missão, valores da empresa, aniversariantes etc.), lançamento ou divulgação de produtos e serviços, divulgação de projetos e parcerias, avisos sobre palestras, treinamentos e eventos em geral; Em shoppings, lojas de departamentos e hotéis, com localização de lojas, banheiros, área de alimentação, restaurantes, etc. Em palestras e congressos, sinalizando local e horário dos eventos, descrição dos palestrantes, etc. Como mecanismo de publicidade, eles podem ser utilizados nos pontos de venda de magazines, redes de lojas, hipermercados, fast-foods, entre outros, veiculando propagandas e informações adicionais sobre os produtos oferecidos no local, além de anúncios de promoções. Em qualquer local de grande circulação de pessoas um sistema de sinalização pode ser instalado com o papel de servir como painéis publicitários para veiculação de produtos ou marcas de diversas empresas. 15

19 4.1. Vantagens A principal vantagem de um sistema de Digital Signage é o controle centralizado e dinâmico de vários displays simultaneamente. Com o uso de softwares apropriados é possível o controle de todos os displays, independentemente da localização dos mesmos. Este é um diferencial do modelo tradicional de pôsteres que demanda o envio do material físico ou de uma equipe para a fixação do novo anúncio no local de divulgação. Outra vantagem está na agilidade da divulgação de novas informações. O administrador do sistema pode, através de um aplicativo Web, atualizar os dados apresentados em todos os terminais. Como exemplo, pode-se citar uma ferramenta de anúncios de promoções-relâmpago em um supermercado, na qual o administrador armazena o nome, o valor e a foto do produto e imediatamente o anúncio é veiculado em todos os displays. O custo em longo prazo de uma solução de sinalização digital tem um valor reduzido em relação ao modelo tradicional de sinalização publicitária através de pôsteres. Mesmo com os altos investimentos iniciais para aquisição do hardware e software, o custo de manutenção é bem inferior em relação aos pôsteres. Detalhes são discutidos no apêndice A. No caso do sistema proposto, a flexibilidade na inclusão de novas funcionalidades sem a intervenção sobre os softwares-base é um importante diferencial. Desta forma, o administrador do sistema pode criar aplicações especificas para suas necessidades, não interferindo no funcionamento do sistema como um todo Desvantagens A utilização de um sistema de sinalização digital gera preocupações quanto a manutenção e segurança dos equipamentos, que devem ser protegidos contra furtos e danos físicos. 16

20 A segurança do sistema de gerenciamento também deverá ser apropriado para que invasores de redes digitais (hackers) não alterem a programação e o conteúdo exibido Exemplos Seguem abaixo exemplos de sinalização digital implantados em outros países. Figura 1 - Exemplo de sinalização digital para agências bancárias 1. 1 Imagem retirada do site: em Junho de

21 Figura 2 - Exemplo de sinalização digital como painel publicitário 2. 2 Imagem retirada do site: em Junho de

22 5. Planejamento O planejamento de todo o projeto foi realizado no início dos trabalho,s com o intuito de obter o software funcional. O cronograma foi dividido em duas grandes fases, a primeira para concepção, planejamento e desenvolvimento da documentação de requisitos e definição técnica; e a segunda fase destinada ao desenvolvimento do sistema, testes e elaboração final da documentação. Os cronogramas são detalhados no anexo A deste documento. Tabela 1 - Cronograma macro do 1o semestre. Março Abril Maio Junho Julho Cronograma (1º semestre) Definição do Escopo Pesquisa de Mercado Estudo de Tecnologias Especificação de Requisitos de Software Apresentações e Relatórios de Status Protótipo Preparação do Ambiente de Desenvolvimento Para o primeiro semestre foram planejadas a definição do tema do projeto e uma pesquisa de técnicas, projetos, produtos e métodos relacionados ao tema selecionado. Em seguida seria realizado o estudo de tecnologias necessárias para o desenvolvimento do sistema, como o aprendizado de linguagens, ferramentas e tecnologias. Diante da proposta do sistema, a equipe desenvolveria a especificação de requisitos funcionais e não-funcionais do sistema, além de outras ferramentas baseadas em padrões do mercado como casos de uso e diagramas de classes. Paralelamente, haveria a elaboração dos relatórios e apresentações parciais conforme solicitado pela grade da matéria de Projeto de formatura I. A partir de julho, com a primeira versão da documentação, a equipe realizaria o estudo prático das tecnologias através do desenvolvimento de um protótipo. 19

23 Tabela 2 - Cronograma macro do 2o semestre. Agosto Setembro Outubro Novembro Dezembro Cronograma (2º semestre) Desenvolvimento Testes Correções e finalização desenvolvimento Documentação do sistema Documento e Apresentação Final Para o segundo semestre foi planejado o desenvolvimento do sistema projetado na primeira fase do projeto. O desenvolvimento duraria 3 meses, na qual as funcionalidades descritas no documento de especificação seriam implementadas e testadas individualmente. Em seguida seriam realizados testes integrados e a correção de eventuais problemas detectados no software. A documentação do sistema seria atualizada e complementada com as análises realizadas após o término do desenvolvimento do sistema. 20

24 6. Especificação do Sistema Descrição de todas as funcionalidades do sistema 6.1. Descrição Geral Nesta seção serão descritos os requisitos funcionais e não- funcionais para o sistema de sinalização digital nomeado de e-sign (Eletronic Sign) Perspectivas do Produto Os softwares aqui especificados são os principais integrantes do sistema de distribuição de publicidade (conteúdo multimídia). Desta forma os softwares do servidor e do terminal compõem a principal parte do sistema, que inclui outras aplicações menores (FlashParts) agregadas a estes softwares iniciais. Os softwares instalados em computadores distintos realizarão a comunicação através de uma rede local ou internet e deverá prover acesso à suas funcionalidades de gerenciamento através da um portal online Interfaces de Usuários O produto possui duas interfaces principais com os usuários. A primeira através dos displays dos terminais que podem ser tanto televisores LCD ou de plasma quanto monitores de computadores. De modo mais amplo, o meio de saída poderá ser qualquer equipamento compatível com saída de placas de vídeo para computadores. A restrição fica quanto ao seu tamanho e formato, na qual serão compatibilizados somente os padrões 4:3 e 16:9 (widescreen). 21

25 Os displays dos terminais exibirão os vídeos publicitários pré-selecionados pelo administrador do sistema. O público-alvo destes terminais são os consumidores que estão dentro do raio de visão dos displays. A segunda interface é o sistema de gerenciamento dos terminais, aplicação web que permitirá todo o controle da programação dos terminais. Através de qualquer browser de um computador conectado à mesma rede do servidor da aplicação é possível administrar qualquer terminal conectado ao servidor Interfaces de Hardware As interfaces de hardware necessárias para o sistema são o servidor, os terminais, os componentes de rede e os monitores. Segue abaixo uma especificação razoável para o bom funcionamento do sistema: Tabela 3 - Hardware do Terminal Parâmetro Processador Memória RAM Memória de Vídeo Disco Interface de Rede Especificação Pentium 4 HT 2.0 GHz 512MB 256MB 60GB a 5400RPM 10/100 Base-TX ou Wi-Fi g Tabela 4 - Hardware dos monitores Parâmetro Resolução máxima Profundidade Freqüência mínima (para todas as resoluções) Especificação 1280x bpp 60Hz 22

26 Tabela 5 - Hardware do Servidor Parâmetro Processador Memória RAM Memória de Vídeo Disco Interface de Rede Mídia Óptica Energia Especificação Intel Core Duo 1.8GHz 1.0 GB 256MB 120GB 7200RPM 10/100/1000 Gigabit Ethernet DVD-RW No-Break, 30 minutos Tabela 6 - Hardware do Switch Parâmetro Interfaces de Rede LAN Interfaces de Rede WLAN Especificação 10/100/1000 Gigabit Ethernet Wi-Fi, G 54Mbps Interfaces com Software O sistema terá interface com outros softwares de base e apoio listados abaixo: SGBD: A princípio, o sistema trabalhará em conjunto com o gerenciador de banco de dados MySQL versão 5.0. Sistema Operacional do Servidor e do Terminal: A princípio, não existem restrições quanto o sistema a ser utilizado, porém o foco estará nos sistemas operacionais Windows e Linux. Servidor Web: Apache TomCat. Browser: Meio de visualização do sistema de controle. O sistema será compatível com Internet Explorer 7.0 ou posterior e Mozilla / Firefox 2.0. Biblioteca FFmpeg: Conversor de vídeo (vide estudo de tecnologia). Adobe Flash Player: Plataforma de interface de mídia utilizada para a exibição de conteúdo e de FlashParts. 23

27 Interfaces de Comunicação A comunicação é realizada através do protocolo TCP/IP em redes locais ou Internet. Sobre este protocolo, a comunicação será baseada em HTTP (acesso Web, AJAX requests, POSTs de arquivos) e FTP (download de arquivos) Características dos Usuários Os usuários serão, em sua maioria, pessoas ligadas ao meio publicitário. Estes usuários possuem nível de computação básico e são muito exigentes quanto à usabilidade e design do sistema. 24

28 6.2. Arquitetura do Sistema O sistema é composto por terminais responsáveis pela exibição da publicidade em displays, e por um servidor responsável pelo controle da programação dos terminais, pelo tratamento dos vídeos e imagens e ponto de acesso para usuários externos à rede. Terminais e servidor serão conectados por uma rede local (LAN ou WLAN). O terminal é composto por um computador com dois softwares instalados: o e-sign player e o e-sign sync. Além disso, um ou mais displays (monitores ou TVs) conectados na saída de vídeo do computador exibem o conteúdo do software e-sign player. O e-sign player é o aplicativo do terminal que reproduz os vídeos e FlashParts das tarefas a partir de um arquivo de programação. Já o e-sign sync é o agente do terminal que monitora o servidor, procurando pela programação mais atualizada para o terminal em que está instalado. O servidor, computador com configurações recomendadas descritas na seção anterior, possui o aplicativo web e-sign server, que realiza o gerenciamento de todo sistema. O e-sign Server é o aplicativo Web administrativo do sistema. Permite a edição de tarefas, o upload de vídeos e FlashParts, entre outras funções administrativas. Figura 3 - Arquitetura em blocos. 25

29 Administradores do Sistema Vídeo Internet Rede Local Vídeo Servidor do Portal Aplicativo Gerenciador (e Sign server) Banco de dados Arquivos dos vídeos LAN Rede cabeada Internet Rede Local WAN Rede sem fio Vídeo Terminais Aplicativos e Sign sync e Sign player Terminais Estabelecimento 1 Estabelecimento 1 Estabelecimento 1 Estabelecimento 2 Estabelecimento 2 Figura 4 - Arquitetura diagramada do sistema 6.3. Funções do Sistema A principal função do sistema é exibir vídeos e FlashParts armazenados no terminal em uma ordem e layout pré-estabelecidos. O administrador do sistema poderá controlar um repositório de vídeos que poderão ser selecionados, para exibi-los no terminal. Além disso, o administrador poderá controlar um repositório de FlashParts e templates. A programação, união de todas as tarefas definidas para o mesmo terminal, poderá ser gerenciada através de uma interface semelhante a um calendário semanal. As tarefas poderão ser recursivas, isto é, poderão ser definidas para se repetirem diariamente ou em dias da semana desejados. Cada tarefa poderá receber um template diferente, com duração variável, e quantidade ilimitada de vídeos. Os vídeos dentro de cada tarefa deverão ser ordenadas para exibição. O gerenciamento de usuários, perfis e terminais também deverá ser disponibilizado ao administrador do sistema. 26

30 Outra funcionalidade necessária para o administrador do sistema é a geração de relatórios que apresentem no servidor a quantidade de vezes que cada vídeo foi apresentado. No terminal, além da exibição de vídeos, poderão existir outros conteúdos como notícias, horário local, previsão do tempo e anúncios online, na forma de FlashParts, descritos posteriormente neste documento Requisitos Não-Funcionais Características não-funcionais requeridas no sistema Acessibilidade O terminal deverá ser configurável sem o acesso físico ao mesmo, isto é, todas as funções do terminal poderão ser realizadas de forma remota. O terminal deverá ser de prática instalação. Desta forma, um novo terminal dentro de uma rede já existente não poderá impactar o restante do sistema. Existirá uma aplicação Web hospedada em um servidor central, onde administradores dos terminais poderão acessar e editar as programações de cada um dos terminais conectados a este servidor. Alem disso, será o ponto de acesso para o envio de novos vídeos para os terminais. Existirão servidores que poderão se conectar a outros servidores. Desta forma, será possível acessar todos os terminais conectados aos respectivos servidores, centralizando-se a administração de várias sub-redes do sistema Confiabilidade O terminal deverá reinicializar-se automaticamente após queda de energia. Os vídeos publicitários não poderão parar mediante queda de conexão à rede. 27

31 O mecanismo de alteração de programação dos terminais deverá ser flexível e com boa usabilidade. Pessoas instruídas em navegação básica da internet deverão estar aptas a utilizar o sistema. Todos os equipamentos e softwares deverão ser otimizados de forma que o custo total de um projeto do sistema seja o mais baixo possível, mantendo os padrões de qualidade pré-estabelecidos Qualidade A qualidade da imagem apresentada no terminal será um diferencial do sistema. O sistema deverá garantir a exibição de vídeos com perfeição, dada uma especificação máxima de vídeo: Ex.: 1024x768 pixels, taxa de 15 fps (frames por segundo). Os softwares envolvidos deverão ter qualidade garantida por bateria de testes a ser realizado após o desenvolvimento do mesmo. A documentação envolvida no desenvolvimento e na finalização do sistema será completa e acessível. Entre os documentos estão a Especificação de Requisitos de Software, o manual de instalação e o manual do usuário Flexibilidade O sistema deverá ser flexível quanto à rede de transmissão adotada (LAN / WAN). A arquitetura de rede não deve interferir no funcionamento do sistema, desde que esteja dentro dos limites pré-estabelecidos. As informações exibidas no terminal serão flexíveis, mediante diferentes componentes que podem facilmente ser incorporados ao sistema. O layout das informações exibidas no terminal também será flexível Segurança Existirão funcionalidades administrativas do sistema que somente usuários com perfil adequado poderão acessar. 28

32 O modo de acesso dos terminais ao servidor será realizado por uma senha comum, porém distinta das demais operações de controle do sistema Usabilidade O sistema deverá apresentar uma interface homem-máquina flexível e de fácil manipulação. O e-sign server deverá prover uma interface de fácil aprendizado e que facilite a operação das funcionalidades do software. A estrutura física deverá ser de fácil instalação, com componentes de fácil aquisição e movimentação Restrições Nesta seção serão descritas as restrições aplicáveis ao sistema Limitações de Hardware Os monitores com cabeamento DVI devem estar localizados a menos de 9 metros do terminal para uma resolução de 1024 pixels de largura por 768 pixels de altura e a apenas 1 metro para uma resolução de 1600 pixels de largura por 1200 de largura 3. No caso de cabos VGA, a restrição é de 10 metros para 1024px por 768 px. Observar que, havendo repetidores ou conversores ótico-eletrônico-óticos pode-se alcançar distâncias muito maiores (centenas de metros). Quanto à memória, o Adobe Flash Player é o maior consumidor mínimo de memória. Ele exige ao menos 128MB de memória RAM para sistemas operacionais Windows, e 512MB de RAM com 128MB de memória de vídeo nos sistemas operacionais Linux. 3 Cfr. What is the maximum length of cable for a DVI and VGA? na lista de referências. 29

33 Limitações da Interface com Outras Aplicações O software FFmpeg é licenciado sob a LGPL 4, o que significa que pode ser ligado a um software proprietário preservando a licença do sistema. Para manter-se a licença do software aberta restringe-se a edição do código da biblioteca FFmpeg Operações Paralelas Nos terminais, as aplicações e-sign player e o e-sign sync estarão rodando ao mesmo tempo. Também simultaneamente estarão rodando no servidor inúmeras sessões de execução de scripts PHP e de conversão de vídeo FFmpeg Funções de Auditoria O sistema deve fornecer relatórios que relatem quantos e quais vídeos foram efetivamente exibidos e o tempo de vídeo não exibido por mau funcionamento do sistema Limitações de Compatibilidade O sistema garantirá a compatibilidade com arquivos de vídeo no padrão Flash Vídeo (FLV) e arquivos de animação Flash (SWF). 4 Cfr. Glossário 30

34 Funções de Controle Não serão abordadas funcionalidades de controle para o terminal, como exemplo, o acionamento remoto (ligar e desligar) Requisitos de Ambientes de Desenvolvimento Serão utilizadas as seguintes linguagens de programação: PHP: Camada de apresentação e negócios do e-sign server; JavaScript: Camada de apresentação do e-sign server; ActionScript: Camada de apresentação do terminal (e-sign player); C#: Camada de controle do terminal (e-sign sync). O sistema rodará completamente sobre o protocolo TCP/IP. Para a troca de arquivos entre terminal e servidor utilizar-se-á o FTP. A aplicação deve rodar 24/7, realizando-se o log de todas as falhas detectadas por monitor Restrição Funcional A exclusão de vídeos no terminal será realizada de modo manual, isto é, um usuário do sistema (por meio remoto) deverá fazer a limpeza dos vídeos que não serão reproduzidos utilizando a lista de vídeos gerada pelo e-sign server Estudo de tecnologias Esta seção apresenta os resultados do estudo sobre as diversas tecnologias cogitadas para uso no projeto. Apresenta também as justificativas de adoção ou rejeição das tecnologias. 31

35 Conversão de Vídeos FFmpeg O programa FFmpeg é um software conversor de formatos de vídeos, que possui seu código aberto licenciado pela LGPL. Ele efetua facilmente a conversão de formatos (transcodificação), redimensionamento e edição de vídeo. Para o presente projeto, duas features são utilizadas: Conversão de qualquer formato para Flash Vídeo (FLV); Downsizing 5. O conversor é acionado via linha de comando. Para converter um vídeo de um formato para outro qualquer se executa o seguinte comando: ffmpeg i [entrada] [saída] ; O formato de saída é definido pela extensão do nome de arquivo [saída]. Para reduzir o vídeo em dimensão, taxa de quadros e bitrate utiliza-se o comando abaixo com os parâmetros devidos: ffmpeg i [entrada] s [largura]x[altura] r [taxa de quadros] b [bitrate] [saída] Tabela 7 - Parâmetros para codificação do ffmpeg. Parâmetro Função -i [arquivo de entrada] Define o arquivo a ser codificado. -s [largura] [altura] Define a resolução de saída. Por padrão, assume-se os mesmos valores do arquivo de entrada. r [taxa de frames] Define a taxa de quadros. O padrão é 25 frames por segundo b [bitrate] Define o bitrate médio do vídeo. O padrão é de 200kb/s. an Retira os canais de áudio do vídeo. Para o software central, desenvolvido em PHP, acessar as funções do FFmpeg utiliza-se a função shell_exec([comando]) com os comandos acima. Para se receber 5 Vide Glossário. 32

36 um feedback da execução, basta analisar a string retornada pela função, que corresponde à saída do terminal FlashServer Para a distribuição e streaming de mídia foi cogitada a utilização do Flash Media Server. Porém, por motivos de limitação do software, dificuldades de assimilação do uso e aumento na complexidade do software, a sua utilização foi descartada Limitação de Redes Para o impacto da capacidade das redes, efetuou-se modelagem e simulação do sistema da seguinte forma: Existem essencialmente dois tipos de pacotes: o Pacotes de conteúdo (serviços): pequenos pacotes enviados de forma constante do servidor externo de conteúdo, passando pelo servidor central e seguindo para o terminal especifico. o Pacotes de vídeo (upload de vídeos): enviados de forma pontual de máquinas de clientes para o servidor. Neste caso, a máquina cliente foi modelada como única, pois a taxa de envio é baixa (porém, o tamanho dos pacotes é grande). Os pacotes de vídeo também são gerados do servidor central em direção a cada terminal, simulando o caso de sincronização. A rede de entrada do servidor (internet) possui banda limitada. A rede de saída do servidor possui banda limitada. Foram considerados somente cinco ou oito terminais. 33

37 Figura 5 Modelo utilizado para simulação do sistema. Detalhes dos testes executados estão descritos no Anexo D deste documento. Com a execução do teste considerando-se apenas os pacotes de conteúdo observase que o seu impacto sobre o sistema é muito baixo. Desta forma, foram descartados das demais simulações. Em outra execução, o foco foi alterado para os pacotes de vídeo. Pacotes maiores são injetados no sistema a uma taxa baixa. 34

38 O sistema com redes de alta vazão é pouco influenciado pelo aumento da quantidade de terminais. Isto se deve pela baixa freqüência de envio de pacotes de vídeo. Por serem ações pontuais, o número de terminais deve ser muito elevado para que ocorra um impacto significativo no sistema. É importante ressaltar que a variação da taxa de saída das redes influencia fortemente o sistema e a redução destas taxas cria gargalos no sistema. Com este estudo concluiu-se que: Os pacotes de conteúdo pouco influenciam o sistema. O sistema apresenta alta dependência das redes. O sistema tem baixa dependência em relação à quantidade de terminais Casos de Uso Nesta seção estão descritos todos os casos de uso pretendidos para o sistema Casos de Uso do Terminal Relacionados abaixo, os casos de uso relativos ao Terminal: Sincronizar Programação Atores e-sign sync, e-sign server. Pré-condição O arquivo de programação atual não está em uso. Início O caso de uso se inicia quando o agente e-sign sync dispara um timeout de sincronização de programação. Fluxo básico 1. e-sign sync requere ao e-sign server os vídeos pendentes da programação 35

39 2. e-sign server verifica quais filmes não foram enviados ao terminal e envia uma lista para o e-sign sync. 3. e-sign sync faz o download do primeiro vídeo e o salva na pasta local de vídeos. 4. Ao completar o download, o e-sign sync informa que o download foi concluído com êxito e retira o vídeo da lista. 5. Se ainda há videos na lista, retorna ao passo e-sign sync requere ao e-sign server os FlashParts que ainda não foram transferidos para o terminal. 7. e-sign server verifica quais FlashParts não foram enviados ao terminal e envia uma lista para o e-sign sync. 8. e-sign sync faz o download do primeiro FlashPart e salva na pasta local de FlashParts. 9. Ao completar o download, o e-sign sync informa que o download foi concluído com êxito e retira o FlashPart da lista. 10. Se ainda há FlashParts na lista retorna ao passo e-sign sync requere ao e-sign server a programação atualizada. 12. e-sign server agrupa as tarefas do terminal, monta uma descrição XML da programação e envia para o terminal. 13. e-sign sync atualiza a programação armazenada no terminal. 14. O caso de uso se encerra. Pós-condição: Novo arquivo de programação pronto para leitura do programa terminal e vídeos e FlashParts devidamente atualizados. 36

40 Sincronizar programação e-sign server e-sign sync Solicita lista de novos vídeos. Envia lista de novos vídeos destinados ao terminal. Não Lista vazia? Envia arquivo solicitado. Solicita arquivo. Sim Recebe e armazena o arquivo. Existe arquivo para download? Não Sim Solicita lista de novos FlashParts Envia lista de novos vídeos destinados ao terminal. Não Lista vazia? Envia arquivo solicitado. Solicita arquivo. Sim Recebe e armazena o arquivo. Existe arquivo para download? Não Sim Solicita arquivo de nova programação. Envia arquivo solicitado. Recebe e armazena o arquivo. Finaliza processo de sincronização. Figura 6 - Fluxo de sincronizar programação. 37

41 Armazenar dados de exibição Atores e-sign player Pré-condição Não há. Início O caso de uso se inicia quando termina a exibição de um vídeo. Fluxo básico 1. e-sign player envia dados do vídeo exibido. (Identificador do vídeo, data e horário de exibição). 2. e-sign server armazena os dados. 3. O caso de uso se encerra. Pós-condição Log de vídeos exibidos atualizado Reproduzir vídeo Atores e-sign player. Pré-condição O arquivo de programação pronto para uso no terminal. Todos os arquivos (Vídeos e FlashParts) que serão reproduzidos estão disponíveis no terminal. Início O caso de uso se inicia quando o aplicativo e-sign player é iniciado no terminal. Fluxo básico 1. O e-sign player verifica se há tarefas para serem reproduzidas no horário atual. 2. Exibe na tela, em modo full-screen, o primeiro vídeo e os FlashParts no layout definido pelo template da tarefa. 3. Ao finalizar o vídeo, inclui o caso de uso Armazenar dados de exibição e segue para o próximo vídeo da lista da tarefa. 38

42 4. Ao finalizar a tarefa, segue para a próxima tarefa da programação. Fluxo de excessão 1. No passo 4 do fluxo básico, se o terminal não encontra mais tarefas em sua programação, executa novamente a última tarefa executada. 2. Retorna ao passo 1 do fluxo básico. Pós-condição O terminal continuará exibindo a programação. Detalhes técnicos Será realizado via Flash Player. Os layouts serão definidos pelos tamanhos dos frames. Obs: A programação de um terminal é atualizada pelo agente e-sign sync Casos de uso do servidor Relacionados abaixo, os casos de uso relativos ao servidor: Realizar login Atores Usuário, e-sign server Início O caso de uso se inicia quando o usuário acessa a página inicial do sistema e o sistema detecta que o usuário não está autenticado. Fluxo Básico 1. e-sign server informa ao usuário que não está autenticado. 2. e-sign apresenta formulário de login com campos de login e senha. 3. Usuário preenche os campos com suas credenciais. 4. e-sign verifica se algum cadastro de usuário coincide com o informado. 5. e-sign server autentica a sessão do usuário. 6. e-sign server redireciona usuário para a área de bibliotecas, na seção de vídeos. 7. Encerra o caso de uso. Fluxo de exceção de credenciais inválidas 39

43 No passo 4 do fluxo básico, se o sistema não encontra nenhum cadastro que corresponda ao informado pelo usuário: 1. Informa login ou senha inválidos. 2. Retorna ao passo 1 do fluxo básico Consultar ajuda Atores Usuário, e-sign server Início O caso de uso se inicia quando o usuário seleciona a opção ajuda. Fluxo Básico 1. e-sign server apresenta informações explicativas sobre a utilização do sistema. 2. O caso de uso se encerra Casos de uso de Administração Relacionados abaixo, os casos de uso relativos à administração do sistema: Gerenciar cadastro de usuários Início O caso de uso se inicia quando o usuário, na área de administração, acessa a seção de usuários. Atores Usuário, e-sign server Pré-condição Usuário logado no sistema. Fluxo básico 1. e-sign server lista os cadastros dos usuários do sistema e apresenta para cada item os dados abaixo: 40

44 ID Nome Login Celular Perfil 2. Usuário seleciona um terminal da lista 3. e-sign apresenta todas as informações do terminal selecionado e as opções: novo, editar e excluir. 4. Usuário seleciona opção novo. 5. e-sign server apresenta formulário para inserção de novo usuário com os seguintes campos: Nome alternativo Login Senha Telefone Comercial Celular Empresa Setor da Empresa Perfil do usuário 6. Usuário insere os dados e envia 7. e-sign server valida se Nome, , Login e Senha foram informados. 8. e-sign server registra o novo usuário 9. Retorna para o passo 1. Fluxo alternativo alterar cadastro de usuário No passo 4 do fluxo básico, se o usuário seleciona a opção Editar nas opções do usuário: 1. e-sign server obtém o cadastro do usuário e apresenta formulário para edição do usuário preenchido com os seguintes campos: Nome 41

45 alternativo Login Senha Telefone Comercial Celular Empresa Setor da Empresa Perfil do usuário 2. Usuário insere os dados e envia 3. e-sign server valida se nome, , login e senha foram informados. 4. e-sign server atualiza o cadastro do usuário 5. Retorna para o passo 1 do fluxo básico. Fluxo alternativo excluir cadastro de usuário No passo 4 do fluxo básico, se o Usuário seleciona a opção excluir: 1. e-sign server pede confirmação para a exclusão. 2. Usuário confirma a exclusão. 3. e-sign server exclui o cadastro do usuário selecionado. 4. Retorna para o passo 1 do fluxo básico. Fluxo alternativo No passo 2 do fluxo alternativo excluir cadastro de usuário, se o Usuário cancela a exclusão de usuário: 1. Retorna para o passo 1 do fluxo básico. Fluxo de exceção No passo 7 do fluxo básico e do fluxo alternativo de edição de usuário, se o e-sign server invalida o preenchimento dos dados: 1. e-sign server informa dados inválidos. 2. e-sign server apresenta formulário novamente ao usuário e requisita alteração dos dados. 3. Usuário insere dados 4. Retorna ao passo 8 dos respectivos fluxos. Detalhes técnicos 42

46 A senha é protegida por algoritmo de Hash MD5, sendo armazenado o MD5 da senha no servidor Gerenciar perfis de usuário Início O caso de uso se inicia quando o usuário, na área de administração, acessa a seção de perfis. Atores Usuário, e-sign server Pré-condição Usuário logado no sistema. Fluxo básico 1. e-sign server lista perfis cadastrados no sistema e apresenta, para cada item, os dados abaixo: ID Nome Descrição 2. Usuário seleciona um perfil da lista 3. e-sign apresenta as informações do perfil: Nome Descrição 4. Usuário seleciona opção novo. 5. e-sign server apresenta formulário para inserção de novo perfil com os seguintes campos: Nome Descrição 6. Usuário insere os dados e envia 7. e-sign server valida se Nome e Descrição foram informados. 8. e-sign server registra o novo perfil de usuário 9. Retorna para o passo 1. Fluxo alternativo alterar cadastro de perfil de usuário 43

47 No passo 4 do fluxo básico, se o usuário seleciona a opção Editar nas opções do perfil: 1. e-sign server obtém o cadastro do perfil e apresenta formulário para edição do perfil preenchido com os seguintes campos: Nome Descrição 2. Usuário insere os dados e envia 3. e-sign server valida se nome e descrição foram informados. 4. e-sign server atualiza o cadastro do perfil 5. Retorna para o passo 1 do fluxo básico. Fluxo alternativo excluir cadastro de perfil de usuário No passo 4 do fluxo básico, se o Usuário seleciona a opção excluir: 1. e-sign server pede confirmação para a exclusão. 2. Usuário confirma a exclusão. 3. e-sign server exclui o cadastro do perfil selecionado. 4. Retorna para o passo 1 do fluxo básico. Fluxo alternativo No passo 2 do fluxo alternativo excluir cadastro de perfil, se o Usuário cancela a exclusão de perfil: 1. Retorna para o passo 1 do fluxo básico. Fluxo de exceção No passo 7 do fluxo básico e no passo 3 do fluxo alternativo de edição de perfil, se o e-sign server invalida o preenchimento dos dados: 5. e-sign server informa dados necessários faltantes. 6. e-sign server apresenta formulário novamente ao usuário e requisita alteração dos dados. 7. Usuário insere dados 8. Retorna ao passo 8 do fluxo básico ou passo 4 do fluxo alternativo. Detalhes técnicos Não há. 44

48 Gerenciar cadastro de terminais Início O caso de uso se inicia quando o Usuário, na área de Administração, entra na seção de terminais. Atores Usuário, e-sign server Processo 1. e-sign server lista os cadastros dos terminais do sistema e apresenta para cada item os dados abaixo: ID Nome Local Empresa IP MAC 2. Usuário seleciona um terminal da lista 3. e-sign apresenta todas as informações abaixo do terminal selecionado e as opções: novo, editar e excluir: Nome Local Empresa IP MAC 4. Usuário seleciona opção novo. 5. e-sign server apresenta formulário para inserção de novo terminal com os seguintes campos: Nome Local Empresa IP MAC 45

49 6. Usuário insere os dados e envia 7. e-sign server valida se Nome, IP e MAC foram informados. 8. e-sign server registra o novo terminal. 9. Retorna para o passo 1. Fluxo alternativo alterar cadastro de terminal No passo 4 do fluxo básico, se o usuário seleciona a opção Editar nas opções do terminal: 1. e-sign server obtém o cadastro do terminal selecionado no passo 2 do fluxo básico e apresenta formulário para edição do terminal preenchido com os seguintes campos: Nome Local Empresa IP MAC 2. Usuário insere os dados e envia 3. e-sign server valida se Nome, IP e MAC foram informados. 4. e-sign server atualiza o cadastro do terminal. 5. Retorna para o passo 1 do fluxo básico. Fluxo alternativo excluir cadastro de terminal No passo 4 do fluxo básico, se o Usuário seleciona a opção excluir: 5. e-sign server pede confirmação para a exclusão. 6. Usuário confirma a exclusão. 7. e-sign server exclui o cadastro do terminal selecionado. 8. Retorna para o passo 1 do fluxo básico. Fluxo alternativo No passo 2 do fluxo alternativo excluir cadastro de terminal, se o Usuário cancela a exclusão de terminal: 1. Retorna para o passo 1 do fluxo básico. Fluxo de exceção No passo 7 do fluxo básico e do fluxo alternativo de edição de terminal, se o e-sign server invalida o preenchimento dos dados: 46

50 1. e-sign server informa dados não preenchidos e de preenchimento obrigatório. 2. e-sign server apresenta formulário novamente ao usuário e requisita alteração dos dados. 3. Usuário insere dados 4. Retorna ao passo 8 dos respectivos fluxos. Detalhes técnicos Não há Visualizar relatórios Início O caso de uso se inicia quando o usuário, na área de administração, acessa a seção de relatórios. Atores Usuário, e-sign server Pré-condição Usuário logado no sistema. Fluxo básico 1. e-sign server lista todos os itens do histórico de filmes reproduzidos, exibindo para cada item os seguintes dados: Nome do terminal Nome do video Data e Hora 2. e-sign server exibe opções Relatório geral e relatório agrupado e lista de opções de filtro por terminal populada com todos os nomes de terminais cadastrados no sistema. 3. Usuário visualiza a lista. 4. O caso de uso se encerra. Fluxo alternativo exibir relatório geral No passo 2 do fluxo básico, se o usuário seleciona a opção relatório geral: 1. Retorna ao passo 1 do fluxo básico. Fluxo alternativo exibir relatório agrupado 47

51 1. e-sign server lista todos os videos constantes do histórico de filmes reproduzidos exibindo para cada item o número de vezes que o filme foi exibido. 2. e-sign server exibe opções relatório geral e relatório agrupado e lista de opções de filtro por terminal populada com todos os nomes de terminais cadastrados no sistema. 3. Usuário visualiza a lista. 4. O caso de uso se encerra. Fluxo alternativo filtrar relatório geral por terminal No passo 3 do fluxo básico, se o Usuário seleciona um terminal da opção filtrar por terminal: 1. e-sign server lista os itens do histórico de filmes reproduzidos no terminal selecionado, exibindo para cada item os seguintes dados: Nome do terminal Nome do video Data e Hora 2. Retorna ao passo 2 do fluxo básico. Fluxo alternativo filtrar relatório agrupado por terminal No passo 3 do fluxo alternativo exibir relatório agrupado, se o Usuário seleciona um terminal da opção filtrar por terminal: 1. e-sign server lista todos os videos constantes do histórico de filmes reproduzidos, exibindo para cada item o número de vezes que o filme foi exibido no terminal selecionado. 2. Retorna ao passo 2 do fluxo alternativo exibir relatório agrupado. Detalhes técnicos Não há Casos de uso de Bibliotecas Relacionados abaixo, os casos de uso relativos ao gerenciamento de conteúdo: 48

52 Gerenciar vídeos do Servidor Início O caso de uso se inicia quando o usuário, na área de bibliotecas, acessa a seção de vídeos. Atores Usuário, e-sign server Pré-condição Usuário logado no sistema. Fluxo básico 1. e-sign server lista vídeos cadastrados no sistema e apresenta para cada item os dados abaixo: ID Nome Descrição Duração (em segundos) Resolução Nome arq. Fisico O sistema também apresenta a opção novo vídeo. 2. Usuário seleciona a opção novo vídeo 3. e-sign server apresenta formulário para inserção de novo vídeo com os seguintes campos: Nome do vídeo Descrição Produtora Duração (segundos) Altura Largura Nome do arquivo O sistema exibe a opção Enviar e Arquivo... relativa ao campo Nome do arquivo e a opção inserir. 4. Usuário insere os dados 49

53 5. Usuário seleciona opção Arquivo... e seleciona um arquivo local de vídeo. 6. Usuário seleciona opção Enviar 7. e-sign server recebe o arquivo e verifica se o arquivo enviado é um Flash (swf), ou um vídeo em formato flv, mpeg, ogg, divx ou mov. 8. Se o arquivo não é um Flash, e-sign server salva o arquivo com um nome único, realiza o downsizing do vídeo e armazena em arquivo separado, também com nome único, para preview. 9. e-sign server informa arquivo recebido com sucesso. 10. Usuário seleciona opção Inserir. 11. e-sign server valida se nome, descrição, produtora, duração, altura, largura foram informados e se um arquivo válido foi enviado. 12. e-sign server registra o novo cadastro de vídeo 13. Retorna para o passo 1. Fluxo alternativo alterar cadastro de vídeo No passo 2 do fluxo básico, se o usuário seleciona um vídeo da lista: 1. e-sign server apresenta as seguintes informações do vídeo e as opções novo, editar e excluir: Nome do vídeo Descrição Produtora Duração (segundos) Resolução (altura x largura) Nome do arquivo O sistema exibe também a reprodução do preview do vídeo selecionado. 2. Usuário seleciona opção editar. 3. e-sign server obtém o cadastro do vídeo e apresenta formulário para edição do vídeo preenchido com os seguintes campos: Nome do vídeo Descrição Produtora Duração (segundos) Altura Largura 50

54 Nome do arquivo Obs: No campo Nome de arquivo é apresentado o nome do arquivo salvo na cadastro do vídeo, porém não é permitida a edição do vídeo em si. 4. Usuário altera os dados e envia 5. e-sign server valida se nome, descrição, produtora, duração, altura, largura foram informados. 6. e-sign server atualiza o cadastro do vídeo 7. Retorna para o passo 1 do fluxo básico. Fluxo alternativo excluir cadastro de vídeo No passo 2 do fluxo básico, se o usuário seleciona um vídeo da lista: 1. e-sign server apresenta as seguintes informações do vídeo e as opções novo, editar e excluir: Nome do vídeo Descrição Produtora Duração (segundos) Resolução (altura x largura) Nome do arquivo O sistema exibe também a reprodução do preview do vídeo selecionado. 2. Usuário seleciona opção excluir. 3. e-sign server requere confirmação do usuário 4. Usuário confirma exclusão. 5. e-sign server verifica se o video está associado a uma ou mais tarefas. 6. e-sign server exclui o cadastro do vídeo. 7. Retorna para o passo 1 do fluxo básico. Fluxo de exceção vídeo inválido No passo 7 do fluxo, se o arquivo enviado não é um dos formatos aceitos: 1. e-sign server informa arquivo de vídeo inválido. 2. Retorna ao passo 1 do fluxo básico. Fluxo de exceção dados de cadastro inválidos No passo 11 do fluxo básico e no passo 5 do fluxo alternativo alterar cadastro de vídeo, se o arquivo enviado não é um dos formatos aceitos: 1. e-sign server informa arquivo de vídeo inválido. 51

55 2. Retorna ao passo 3 do fluxo básico. Fluxo de exceção dados de cadastro inválidos No passo 5 do fluxo alternativo excluir cadastro de vídeo, se o vídeo a ser excluído está presente em alguma tarefa: 1. e-sign server informa que o vídeo está associado a uma ou mais tarefas. 2. Retorna ao passo 1 do fluxo básico. Detalhes técnicos Ao ser excluído o cadastro de um vídeo no sistema, o arquivo físico não é excluído Gerenciar FlashParts do servidor Início O caso de uso se inicia quando o usuário, na área de bibliotecas, acessa a seção de FlashParts. Atores Usuário, e-sign server Pré-condição Usuário logado no sistema. Fluxo básico 1. e-sign server lista FlashParts cadastrados no sistema e apresenta para cada item os dados abaixo: ID Nome Descrição Duração (em segundos) Resolução Link Nome arq. Fisico O sistema também apresenta a opção novo FlashPart. 2. Usuário seleciona a opção novo FlashPart. 3. e-sign server apresenta formulário para inserção de novo FlashPart com os seguintes campos: 52

56 Nome do FlashPart Descrição Produtora Link Altura Largura Nome do arquivo O sistema exibe a opção Enviar e Arquivo... relativa ao campo Nome do arquivo e a opção inserir. 4. Usuário insere os dados 5. Usuário seleciona opção Arquivo... e seleciona um arquivo local de vídeo. 6. Usuário seleciona opção Enviar 7. e-sign server recebe o arquivo e verifica se o arquivo enviado é um Flash (swf). 8. e-sign server salva o arquivo com um nome único. 9. e-sign server informa arquivo recebido com sucesso. 10. Usuário seleciona opção Inserir. 11. e-sign server valida se nome do FlashPart, descrição, produtora, link, altura, largura foram informados e se um arquivo válido foi enviado. 12. e-sign server registra o novo cadastro de FlashPart 13. Retorna para o passo 1. Fluxo alternativo alterar cadastro de FlashPart No passo 2 do fluxo básico, se o usuário seleciona um FlashPart da lista: 1. e-sign server apresenta as seguintes informações do FlashPart e as opções novo, editar e excluir: Nome da FlashPart Descrição Produtor Link Resolução (altura x largura) Nome do arquivo 2. Usuário seleciona opção editar. 3. e-sign server obtém o cadastro do FlashPart e apresenta formulário para edição do FlashPart preenchido com os seguintes campos: 53

57 Nome da FlashPart Descrição Produtor Link altura largura Nome do arquivo Obs: No campo Nome de arquivo é apresentado o nome do arquivo salvo na cadastro do vídeo, porém não é permitida a edição do vídeo em si. 4. Usuário altera os dados e envia 5. e-sign server valida Nome do FlashPart, Descrição, Produtor, Link, altura, largura informados. 6. e-sign server atualiza o cadastro do FlashPart. 7. Retorna para o passo 1 do fluxo básico. Fluxo alternativo excluir cadastro de FlashPart No passo 2 do fluxo básico, se o usuário seleciona um FlashPart da lista: 1. e-sign server apresenta as seguintes informações do FlashPart e as opções novo, editar e excluir: Nome da FlashPart Descrição Produtor Link Resolução (altura x largura) Nome do arquivo 2. Usuário seleciona opção excluir. 3. e-sign server requere confirmação do usuário 4. Usuário confirma exclusão. 5. e-sign server verifica se o FlashPart está associado a um frame associado a um ou mais templates associados a uma ou mais tarefas. 6. e-sign server exclui o cadastro do FlashPart. 7. Retorna para o passo 1 do fluxo básico. Fluxo alternativo exclusão cancelada 54

58 No fluxo alternativo excluir cadastro de FlashPart, se o usuário não confirma a exclusão do FlashPart: 1. Retorna ao passo 1 do fluxo básico. Fluxo de exceção arquivo de FlashPart inválido No passo 7 do fluxo básico, se o arquivo enviado não é do formato aceito: 1. e-sign server informa arquivo de FlashPart inválido. 2. Retorna ao passo 3 do fluxo básico. Fluxo de exceção dados de cadastro inválidos na inserção de novo cadastro No passo 11 do fluxo básico, se um ou mais dos seguinte dados não estiver preenchido: Nome Descrição Produtora Resolução 1. e-sign server informa dados faltantes. 2. Retorna ao passo 3 do fluxo básico. Fluxo de exceção dados de cadastro inválidos na edição de cadastro No passo 5 do fluxo alternativo alterar cadastro de FlashPart, se um ou mais dos seguinte dados não estiver preenchido: Nome Descrição Produtora Resolução 3. e-sign server informa dados faltantes. 4. Retorna ao passo 3 do fluxo alternativo alterar cadastro de FlashPart. Detalhes técnicos Ao ser excluído o cadastro de um FlashPart do sistema, o arquivo físico não é excluído. 55

59 Gerenciar cadastro de templates Início O caso de uso se inicia quando o Usuário, na área de Bibliotecas entra na seção de templates. Atores Usuário, e-sign server Processo 1. e-sign server lista os cadastros dos templates do sistema e apresenta para cada item os dados abaixo: ID Nome Descrição 2. Usuário seleciona um template da lista 3. e-sign apresenta Nome e Descrição do template e uma lista com os 4 frames que o compõe. Para cada frame, lista os dados abaixo: IDNumero Altura Largura FlashPart Exibe Video? 4. Usuário seleciona a opção Novo. 5. e-sign server apresenta formulário para inserção de novo template com os seguintes campos: Nome do Template Descrição 6. e-sign server apresenta lista de 4 linhas de campos para preenchimento de informações de frames, cada uma contendo os seguintes campos: Altura Largura Exibe Video? 56

60 FlashPart ( e-sign server popula uma lista com todos os Flashparts disponíveis para seleção ). 7. Usuário insere os dados 8. e-sign server apresenta uma visualização do layout do template dos dados informados. 9. Usuário envia dados 10. e-sign server valida se Nome e descrição do template foram informados e se altura e largura dos frame1, frame2, frame3 e frame4 foram informados. 11. e-sign server registra o novo template. 12. Retorna para o passo 1. Fluxo alternativo alterar cadastro de template No passo 4 do fluxo básico, se o usuário seleciona a opção editar nas opções do template: 1. e-sign server obtém o cadastro do template selecionado no passo 2 do fluxo básico e apresenta formulário para edição do template preenchido com os seguintes campos: Nome do Template Descrição O e-sign server apresenta lista de 4 linhas (frame1, frame2, frame3, frame4) de campos para preenchimento de informações de frames, cada uma contendo os seguintes campos devidamente populados: Altura Largura Exibe Video? FlashPart ( e-sign server popula uma lista com todas as Flashparts disponíveis para seleção ). 2. Usuário altera os dados. 3. e-sign server apresenta uma visualização do layout do template dos dados informados. 4. Usuário envia dados. 5. e-sign server valida se Nome e descrição do template foram informados e se altura e largura de frame1, frame2, frame3 e frame4 foram informados. 6. e-sign server atualiza o cadastro do terminal. 57

61 7. Retorna para o passo 1 do fluxo básico. Fluxo alternativo excluir cadastro de template No passo 4 do fluxo básico, se o Usuário seleciona a opção excluir: 1. e-sign server pede confirmação para a exclusão. 2. Usuário confirma a exclusão. 3. e-sign sever exclui o cadastro do template selecionado. 4. Retorna para o passo 1 do fluxo básico. Fluxo alternativo No passo 2 do fluxo alternativo excluir cadastro de template, se o Usuário cancela a exclusão de template: 1. Retorna para o passo 1 do fluxo básico. Fluxo de exceção No passo 10 do fluxo básico e no passo 5 do fluxo alternativo de edição de template, se e-sign server invalida o preenchimento dos dados: 1. e-sign server informa dados não preenchidos e de preenchimento obrigatório. 2. e-sign server apresenta formulário novamente ao usuário e requisita alteração dos dados. 3. Usuário insere dados 4. Retorna ao passo 11 do fluxo básico ou passo 6 do fluxo alternativo de edição de template. Detalhes técnicos Não há Casos de uso de Programação Relacionados abaixo, os casos de uso relativos ao gerenciamento de tarefas: Gerenciar Tarefa Atores Usuário, e-sign server Pré-condição 58

62 Não há. Início O caso de uso se inicia quando o usuário acessa a área de programação e entra na seção de tarefas. Fluxo básico 1. e-sign server lista todas as tarefas com data de início posterior ao momento presente. Apresenta também uma opção novo à parte, a opção filtrar por terminal populada com todos os terminais do sistema e uma opção ver anteriores. 2. Usuário seleciona a opção Novo. 3. e-sign server lista todos os terminais do sistema para seleção. 4. Usuário seleciona um terminal. 5. e-sign server apresenta formulário com os seguintes campos para preenchimento: Nome Descrição Template (lista de opções com os templates cadastrados) Data (data de início) Inicio (horário de início) Fim (horário de fim) Repetir Semanalmente / Diariamente (opções mutualmente exclusivas) Até ( data final ) Biblioteca ( lista de vídeos do sistema ) Sequência ( lista vazia ) Sistema apresenta opções adicionar, remover, subir e descer vídeo da lista. Apresenta também a opção enviar. 6. Usuário insere nome, descrição, template, data, inicio, fim (opcional) Seleciona opção repetir até. (opcional indisponível caso opção repetir até não tenha sido selecionada) Definir data final de repetição. (opcional indisponível caso opção repetir até não tenha sido selecionada) Selecionar semanalmente nos dias: 59

63 (opcional indisponível caso opção semanalmente nos dias não tenha sido selecionada) Definir os dias da semana em que tarefa sera exibida. 7. Usuário utiliza opções + (adicionar), - (remover), subir e descer para adicionar vídeos selecionados da biblioteca para a sequência, remover vídeos da sequência, subir os vídeos selecionados em sequência uma posição e descer os vídeos selecionados em sequência uma posição. 8. Usuário envia dados. 9. e-sign server valida dados (detalhes da validação no item Validação abaixo) 10. e-sign server relaciona os vídeos presentes na sequência à tarefa, armazenando a ordem dos vídeos da sequência. 11. e-sign server registra o cadastro da tarefa 12. Retorna ao passo 1 do fluxo básico. Fluxo alternativo editar tarefa No passo 2 do fluxo básico, se o usuário seleciona uma das tarefas da lista: 1. e-sign server exibe os seguintes dados da tarefa selecionada e as opções novo, editar e excluir: Nome Descrição Data Início Data Fim Hora Início Hora Fim Loop Semana Template 2. Usuário seleciona opção editar. 3. e-sign server apresenta formulário com os seguintes campos para preenchimento populados com os dados da tarefa selecionada: Nome Descrição Template (lista de opções com os templates cadastrados) Data (data de início) Inicio (horário de início) Fim (horário de fim) 60

64 Repetir Semanalmente / Diariamente (opções mutualmente exclusivas) Até ( data final ) Biblioteca ( lista de vídeos do sistema ) Sequência ( lista vazia ) Sistema apresenta opções adicionar, remover, subir e descer vídeo da lista. Apresenta também a opção enviar. 4. Usuário altera nome, descrição, template, data, inicio, fim (opcional) Seleciona opção repetir até. (opcional indisponível caso opção repetir até não tenha sido selecionada) Definir data final de repetição. (opcional indisponível caso opção repetir até não tenha sido selecionada) Selecionar semanalmente nos dias: (opcional indisponível caso opção semanalmente nos dias não tenha sido selecionada) Definir os dias da semana em que a tarefa sera exibida. 5. Usuário utiliza opções + (adicionar), - (remover), subir e descer para adicionar vídeos selecionados da biblioteca para a sequência, remover vídeos da sequência, subir os vídeos selecionados em sequência uma posição e descer os vídeos selecionados em sequência uma posição. 6. Usuário envia dados. 7. e-sign server valida dados (detalhes da validação no item Validação abaixo) 8. e-sign remove as associações da tarefa com vídeos. 9. e-sign server relaciona os vídeos presentes na sequência à tarefa, armazenando a ordem dos vídeos da sequência. 10. e-sign server atualiza o cadastro da tarefa. 11. Retorna ao passo 1 do fluxo básico. Fluxo alternativo filtrar por terminal No passo 2 do fluxo básico, se o usuário seleciona um terminal da opção filtrar pelo terminal: 1. e-sign server lista todos as tarefas associadas ao terminal selecionado. 2. Retorna ao passo 2 do fluxo básico. Fluxo alternativo ver anteriores No passo 2 do fluxo básico, se o usuário seleciona a opção ver anteriores: 61

65 1. e-sign server lista todos as tarefas, inclusive as tarefas passadas. 2. Retorna ao passo 2 do fluxo básico. Fluxo de exceção dados inválidos na inserção de nova tarefa No passo 9 do fluxo básico, se o e-sign server invalida os dados inseridos: 1. Informa dados inválidos 2. Retorna para o passo 5 do fluxo básico. Fluxo de exceção dados inválidos na inserção de nova tarefa No passo 7 do fluxo alternativo alterar tarefa, se o e-sign server invalida os dados inseridos: 1. Informa dados inválidos. 2. Retorna para o passo 3 do fluxo alternativo alterar tarefa. Detalhes técnicos As alterações serão efetivadas após a sincronização com os terminais. Caso o usuário não selecione a opção repetir até a tarefa será realizada apenas na data selecionada. Caso o usuário selecione a opção repetir até e não selecione a opção semanalmente nos dias a tarefa será repetida todos os dias entre a data da tarefa e a data final da repetição. Caso o usuário selecione as opções repetir até e o opção semanalmente nos dias a tarefa será repetida entre a data da tarefa e a data final da repetição apenas nos dias de semana informados. Validação Caso o usuário informe uma data final para repetição anterior à data da tarefa, uma mensagem é enviada informando a regra ao usuário e retorna ao formulário. Caso o usuário informe um horário final anterior ao horário inicial da tarefa, uma mensagem é enviada informando a regra ao usuário e retorna ao formulário. Caso o usuário selecione uma data final para repetição e não escolha nenhum dia da semana para a repetição, uma mensagem é enviada informando que deve selecionar ao menos um dia da semana. Caso o usuário não defina nenhuma seqüência de vídeos para a tarefa, uma mensagem é enviada ao usuário informando-o que deve selecionar ao menos um vídeo para a seqüência. 62

66 Caso o usuário não informe um nome para a tarefa, uma mensagem é enviada ao usuário informando-o que deve inserir um nome para a tarefa. Cada terminal possui somente uma tarefa para cada instante, ou seja, não são possíveis tarefas com intervalos sobrepostos. Caso exista conflito de tarefa (ou seja, caso a nova tarefa concorra em horário com alguma outra pré-existente) emitir mensagem de confirmação. E caso seja aceita a mudança, a tarefa anterior é descartada e a nova tarefa é armazenada. A inserção e edição de uma nova tarefa poderão ser realizadas com o mínimo de 30 minutos de antecedência. Caso um usuário tente inserir uma tarefa numa janela de 15 minutos é enviada a mensagem de que não é possível incluir uma tarefa a menos de 15 minutos do momento presente Visualizar Agenda Atores Usuário, e-sign server Pré-condição Não há. Início O caso de uso se inicia quando o usuário acessa a área de programação e seleciona a opção agenda. Fluxo básico 1. e-sign server lista terminais do sistema e requere a seleção de um terminal. 2. Usuário seleciona um teminal. 3. e-sign server apresenta opções novo, voltar semana, voltar dia, avançar dia, avançar semana. e-sign server apresenta uma agenda semanal com horário, apresentando a semana atual (do último domingo até o sábado), exibindo as tarefas de maneira visual nos dias e horários em que são exibidas. Para cada tarefa apresenta a opção excluir e editar. 4. Usuário seleciona opção novo. 5. Inclui caso de uso gerenciar tarefa no passo 1 do fluxo básico. 63

67 6. Retorna ao passo 3 do fluxo básico. Fluxo alternativo editar tarefa No passo 4 do fluxo básico, se o usuário seleciona a opção editar de uma tarefa: 1. Inclui o caso de uso gerenciar tarefa no passo 1 do fluxo alternativo editar tarefa. 2. Ao atingir o passo 11 do fluxo alternativo editar tarefa do caso de uso gerenciar tarefa, retorna ao passo 3 do fluxo básico. Fluxo alternativo excluir tarefa No passo 4 do fluxo básico, se o usuário seleciona a opção excluir de uma tarefa: 1. e-sign server requere confirmação para exclusão da tarefa. 2. Usuário confirma exclusão 3. e-sign server remove todas as relações da tarefa com vídeos 4. e-sign server remove o cadastro da tarefa. 5. Retorna ao passo 3 do fluxo básico. Fluxo alternativo navegar dia semana No passo 3, se o usuário seleciona a opção avançar semana, avançar dia, retroceder semana ou retroceder dia: 1. Avança uma semana, avança um dia, retrocede uma semana ou retrocede um dia da agenda. 2. Retorna ao passo 4 do fluxo básico. Detalhes técnicos Não há Diagrama de Classes Nesta seção está representada graficamente a arquitetura do e-sign server através dos diagramas de classes. O sistema do servidor está modelado em três camadas: camada de apresentação, camada de negócios e camada de acesso ao banco de dados. 64

68 A camada de apresentação é responsável pela exibição dos dados recebidos da camada de negócios para a tela do usuário. A comunicação entre as camadas de apresentação e negócios é realizada utilizando-se da técnica AJAX 6. A camada de negócios busca os dados requisitados pelo usuário na camada de apresentação através de pedidos à camada de acesso ao banco de dados e realiza o tratamento dos dados com a lógica especificada pelos casos de uso. A camada de acesso ao Banco de Dados possui a função de extrair as informações da base de dados através de consultas pré-definidas, e fornecer os dados parametrizados em instâncias das entidades. As entidades representam os objetos com seus atributos, formalizando e facilitando a parametrização dos dados. No Terminal, existe a camada de controle básico, que busca as informações necessárias no servidor, armazenando-as em arquivos XML locais. Este arquivo é utilizado pela camada de controle funcional, que utiliza os dados para gerenciar a lista de vídeos a ser exibida no display. Já a camada de apresentação do Terminal possui a responsabilidade de garantir a exibição dos vídeos no horário programado. Esta camada, em conjunto com a camada de controle funcional, formam o software e-sign player. Figura 7 - Arquitetura dos softwares. 6 Vide Glossário. 65

69 Abaixo está representado o diagrama de classes simplificado, com a definição dos métodos das camadas de acesso ao BD e de negócios, e os atributos das entidades. O padrão de nomenclatura utilizada é a seguinte: Para as entidades: E+ Nome da entidade ; Para camada de acesso ao BD: D+ Nome da entidade de referência ou nome da relação de entidades ; Para camada de negócios: B+ Nome da entidade de referência ou nome da relação de entidades ; Para camada de apresentação: A+ Nome da entidade de referência ou nome da relação de entidades. 66

70 DPerfil +delete() +update() +insert() +selectall() +selectbyid() +count() «uses» BPerfil +listarperfis() +inserirperfil() +editarperfil() +excluirperfil() «uses» «interface» APerfil «interface» AUsuario BUsuario «uses» EPerfil -IDPerfil : int -Nome : string -Descrição : string «uses» +listarusuarios() +inserirusuario() +editarusuario() +excluirusuario() +loginusuario() «uses» DTarefaVideo +setvideosparatarefa() +inseretarefavideo() +apagavideostarefa() +selectvideosbytarefa() +selecttarefasbyidvideo() «uses» DUsuario +delete() +update() +insert() +selectall() +selectbyid() +login() «uses» EUsuario -IDUsuario : int -Nome : string - string - alternativo : string -Login : string -Senha : string -TelefoneComercial : string -Celular : string -Empresa : string -Setor : string -IDPerfil : int ETarefa -IDTarefa : int -Nome : string -Descricao : string -DataInicio : date -DataFim : date -HoraInicio : datetime -HoraFim : datetime -DiasdaSemanaLoop : int -DataFimLoop : date -IDTemplate : int -nometemplate : string «interface» ATarefaLista «interface» AAgenda «uses» BTarefa +listartarefas() +inserirtarefa() +editartarefa() +excluirtarefa() +validarconflito() +validarjanelaexecucao() «uses» «uses» DTarefaTerminal +selectbyidtarefa() +selectbyidterminal() DTarefa +selectbyid() +selectall() +insert() +update() +delete() +checktimeconflict() Figura 8 - Diagrama de classes A. 67

71 «uses» «interface» AFlashPart BFlashPart +listarflashparts() +inserirflashpart() +editarflashpart() +excluirflashpart() «utility» Util DFlashPart +delete() +update() +insert() +selectall() +selectbyid() +count() DSincronizacao +selectvideosbyidterminal() +selectflashpartsbyidterminal() +insertterminalvideo() +insertterminalflashpart() +selecttarefasbyidterminal() +selectvideosbyidtarefa() «uses» «uses» «uses» EFlashPart -IDFlashPart : int -Nome : string -Descrição : string -Produtor : string -Resolução : string -link : string -IDArquivo : string -nomedoarquivo : string -extensao : string «uses» BSincronizacao DVideo +selectbyid() +selectall() +insert() +update() +delete() +count() «uses» EVideo -IDVideo : int -Nome do vídeo : string -Descrição : string -Produtor : string -Duração : string -Resolução : string -Path : string -IDArquivo : int -nomedoarquivo : string -nomearqfisico : string «uses» +listavideos() +listaflashparts() +atualizaterminalvideo() +atualizaterminalflashpart() +montaprogramacao() «uses» «uses» «uses» «utility» UConverteVideo BVideo «interface» AVideo +listarvideos() +inserirvideo() +editarvideo() +excluirvideo() ETarefa -IDTarefa : int -Nome : string -Descricao : string -DataInicio : date -DataFim : date -HoraInicio : datetime -HoraFim : datetime -DiasdaSemanaLoop : int -DataFimLoop : date -IDTemplate : int -nometemplate : string Figura 9 - Diagrama de Classes B. 68

72 Figura 10 - Diagrama de Classes C. 69

73 ETerminal -IDTerminal : int -Nome : string -Senha : string -Local : string -EmpresaProprietaria : string -IP_MAC : string * * * 1 EFlashPart -IDFlashPart : int -Nome : string -Descrição : string -Produtor : string -Resolução : string -link : string -IDArquivo : string -nomedoarquivo : string -extensao : string 1 1 * EFrameTemplate -IDFrameTemplate : int -NumeroFrame : string -bolframevideo : bool -Altura : int -Largura : int * * EVideo -IDVideo : int -Nome do vídeo : string -Descrição : string -Produtor : string -Duração : string -Resolução : string -Path : string -IDArquivo : int -nomedoarquivo : string -nomearqfisico : string * * ETarefaVideo -IDTarefaVideo : int -IDTarefa : int -IDVideo : int ETarefa -IDTarefa : int -Nome : string -Descricao : string -DataInicio : date -DataFim : date -HoraInicio : datetime -HoraFim : datetime -DiasdaSemanaLoop : int -DataFimLoop : date -IDTemplate : int -nometemplate : string * * 1 ETemplate -IDTemplate : int -Nome : string -Descricao : string EUsuario -IDUsuario : int -Nome : string - string - alternativo : string -Login : string -Senha : string -TelefoneComercial : string -Celular : string -Empresa : string -Setor : string -IDPerfil : int * 1 EPerfil -IDPerfil : int -Nome : string -Descrição : string Figura 11 - Diagrama de Classes - Somente entidades. 70

74 6.9. Modelo Físico de Dados Nesta seção está representado o modelo físico de dados, com as tabelas e as respectivas colunas na qual estarão armazenados todos os dados do sistema. A definição das tabelas está diretamente ligada com a definição das entidades elaborada nos diagramas de classes, bem como os relacionamentos entre estas entidades. As tabelas tblperfil, tblusuario, tbltemplate, tblframetemplate, tbltarefa, tblvideo, tblterminal e tblflashpart são diretamente relacionadas às entidades EPerfil, EUsuario, ETemplate, EFrameTemplate, ETarefa, EVideo, ETerminal e EFlashPart. As tabelas tbltarefaterminal, tblterminalflashpart, tbltarefavideo, tblterminalvideo são tabelas de relacionamento entre entidades. A tabela tblarquivo é uma tabela auxiliar para o controle de arquivos armazenados no servidor. Tabela 8 Relação das principais funções de cada tabela. Nome tabela tblperfil tblusuario tbltemplate tblframetemplate tbltarefa tblvideo tblterminal tblflashpart tbltarefaterminal tbltarefavideo tblterminalvideo Principal função da tabela Armazena os dados básicos de um Perfil. Armazena os dados básicos de um Usuário. Armazena os templates, um agrupamento de quatro frames. Armazena os dados básicos de um frame. Cada item é relacionado a apenas um template. Armazena os dados básicos de uma tarefa. Cada item é relacionado a apenas um template. Armazena os dados básicos de um vídeo. Armazena os dados básicos de um terminal. Armazena os dados básicos de um FlashPart. Define para qual terminal a tarefa é destinada. Define os vídeos que fazem parte de cada tarefa. Define se o Terminal já possui o vídeo em sua pasta local. 71

75 tblterminalflashpart tblarquivo tblrelatoriovideo Define se o Terminal já possui o FlashPart em sua pasta local. Identificador único para todos os arquivos submetidos ao servidor (vídeo e FlashParts). Armazena o histórico de exibições de cada terminal. tblflashpart tblterminal tblterminal_flashpart PK IDFlashPart PK IDTerminal NomeTerminal Local EmpresaProprietaria IP MAC PK FK1 FK2 IDTerminalFlashPart IDTerminal IDFlashPart FK1 Nome Descricao Produtor Resolucao Link IDArquivo PK FK1 FK2 PK FK1 tbltarefaterminal IDTarefaTerminal IDTarefa IDTerminal Status tbltarefa IDTarefa Nome Descricao DataInicio DataFim HoraInicio HoraFim DiasdaSemanaLoop IDTemplate PK FK1 FK2 tblterminal_video PK FK2 FK1 PK IDTerminalVideo IDVideo IDTerminal tbltarefa_video IDTarefaVideo IDTarefa IDVideo tbltemplate IDTemplate Nome Descricao PK FK1 tblvideo IDVideo NomedoVideo Descricao Produtor Duracao Resolucao IDArquivo PK PK tblframetemplate IDFrameTemplate FK1 IDTemplate NumFrame FK2 IDFlashPart bolframevideo Altura Largura tblarquivo IDArquivo nomearqfisico tipo tblusuario tblrelatoriovideo PK IDRelatVideo IDVideo IDTerminal datahora PK FK1 IDUsuario Nome Alternativo Login Senha TelefoneComercial Celular Empresa Setor IDPerfil PK tblperfil IDPerfil Nome Descricao Figura 12 - Diagrama do modelo físico de dados. 72

76 Tabela 9 - Lista detalhada das colunas das tabelas do banco de dados Nome da tabela Nome da coluna Obrigatório? Tipo da coluna tblarquivo tblflashpart tblframetemplate tblperfil tblrelatoriovideos tbltarefa tbltarefa_terminal IDARQUIVO* Não int(11) NOMEARQFISICO Não varchar(200) EXTENSAO Não varchar(5) GUID Não text IDFLASHPART* Não int(11) NOME Não varchar(200) DESCRICAO Sim varchar(200) PRODUTOR Sim varchar(200) RESOLUCAO Não varchar(200) LINK Sim varchar(200) NOMEDOARQUIVO Não varchar(100) NOMEARQFISICO Não varchar(200) IDARQUIVO Não int(11) IDFRAMETEMPLATE* Não int(11) IDTEMPLATE Não int(11) NUMFRAME Não int(11) IDFLASHPART Não int(11) BOLFRAMEVIDEO Não binary(1) ALTURA Não int(11) LARGURA Não int(11) IDPERFIL* Não int(11) NOMEPERFIL Não varchar(200) DESCRICAO Sim varchar(200) IDRELATVIDEO* Não int(10) unsigned IDTERMINAL Não int(10) unsigned IDVIDEO Não int(10) unsigned DATAHORA Não datetime IDTAREFA* Não int(11) NOME Não varchar(200) DESCRICAO Não varchar(200) DATAINICIO Não date DATAFIM Não date HORAINICIO Não time HORAFIM Não time DIASDASEMANALOOP Sim tinyint(1) IDTEMPLATE Não int(11) IDTAREFA_TERMINAL* Não int(11) IDTAREFA Não int(11) IDTERMINAL Não int(11) STATUS Não varchar(100) (*) Colunas que são chaves-primárias e possuem a função de auto-incremento. 73

77 Tabela 10- Continuação da lista detalhada das colunas das tabelas do banco de dados Nome da tabela Nome da coluna Obrigatório? Tipo da coluna tbltarefa_video tbltemplate tblterminal tblterminal_flashpart tblterminal_video tblusuario tblvideo IDTAREFAVIDEO* Não int(11) IDTAREFA Não int(11) IDVIDEO Não int(11) ORDEM Não int(11) IDTEMPLATE Não int(11) NOME Não varchar(200) DESCRICAO Sim varchar(200) IDTERMINAL* Não int(11) NOMETERMINAL Não varchar(200) LOCAL Não varchar(200) EMPRESAPROPRIETARIA Sim varchar(200) IP Não varchar(200) MAC Não varchar(20) IDTERMINAL_FLASHPART* Não int(11) IDTERMINAL Não int(11) IDFLASHPART Não int(11) IDTERMINAL_VIDEO* Não int(11) IDTERMINAL Não int(11) IDVIDEO Não int(11) IDUSUARIO* Não int(11) NOME Não varchar(200) Não varchar(200) ALTERNATIVO Não varchar(200) LOGIN Não varchar(200) SENHA Não varchar(200) TELEFONECOMERCIAL Sim varchar(50) CELULAR Sim varchar(50) EMPRESA Sim varchar(100) SETOR Sim varchar(100) IDPERFIL Não int(11) IDVIDEO* Não int(11) NOMEDOVIDEO Não varchar(200) DESCRICAO Sim varchar(200) PRODUTOR Sim varchar(200) DURACAO Sim int(11) RESOLUCAO Não varchar(100) PATH Sim varchar(200) IDARQUIVO Não int(11) (*) Colunas que são chaves-primárias e possuem a função de auto-incremento. 74

78 6.10. Interfaces de Dados As interfaces necessárias para atender ao fluxo de dados de todos os casos de uso podem ser distinguidas entre: interfaces entre subsistemas e atores; interfaces entre subsistemas; e interface de acesso a dados externos. Figura 13- Diagrama de interfaces No diagrama acima, observam-se todas as interfaces existentes entre os atores e subsistemas que serão categorizadas e explanadas nos tópicos a seguir Interface entre Subsistema e Atores São as interfaces que realizam a troca de dados entre os atores (usuários) e os subsistemas. No diagrama de interfaces constata-se que as interfaces INT-1 e INT-4 estão nesta categoria. A interface INT-1 é responsável pela exibição do sistema no display com o conteúdo digital (publicidade e anúncios), conforme descrito no caso de uso Reproduzir vídeo. 75

79 A interface INT-4 é responsável pelo acesso ao subsistema de gerenciamento que engloba grande parte das funcionalidades definidas para o e-sign server Interface entre Subsistemas São as interfaces que realizam a troca de dados entre dois subsistemas, sem a necessidade de atuação direta de outros atores. No diagrama de interfaces constata-se que as interfaces INT-2 e INT-3 estão nesta categoria. A interface INT-2 é responsável pelo envio das informações de exibição do terminal para o servidor, conforme descrito no caso de uso Armazenar dados de exibição. A interface INT-3 é responsável pelo tráfego de vídeos, FlashParts e arquivo de programação, conforme descrito nos casos de uso Sincronizar programação Interfaces de Acesso a Dados Externos São as interfaces de acesso aos dados de repositórios (banco de dados e sistema de arquivos). Pelo diagrama, as interfaces nesta categoria são: AC-1, AC-2, AC-3 e AC-4. A interface AC-1 define a leitura dos arquivos de FlashParts, vídeos e programação no terminal pelo e-sign player. A interface AC-2 define a leitura e escrita dos arquivos de FlashParts, vídeos e programação no terminal através do e-sign sync. A interface AC-3 define a leitura e escrita da base de dados do sistema gerenciador. A interface AC-4 define a leitura e escrita dos arquivos de FlashParts e vídeos no servidor. 76

80 6.11. Mapa de Navegação O mapa de navegação é uma ferramenta utilizada para definir como será a estrutura do caminho para o acesso às informações e funções do sistema. No caso do sistema e-sign, teremos um mapa de navegação para o e-sign server, na qual os usuários terão alto grau de interação para o gerenciamento do sistema. O e-sign server foi divido em três módulos, mantendo funções com as mesmas características agrupadas. Este agrupamento foi realizado com base nos casos de uso levantados anteriormente. Os módulos definidos foram: Módulo de Programação: Todas as funcionalidades referentes ao gerenciamento das tarefas. Módulo das Bibliotecas: Repositórios dos vídeos, FlashParts e templates. Módulo Administrativo: Gerenciamento de terminais, perfis, usuários e relatórios. Tabela 11 - Casos de usos relacionados a cada módulo da interface. Nome do Módulo Programação Biblioteca Administrativo Casos de usos relacionados Gerenciar tarefas Visualizar agenda Gerenciar vídeos Gerenciar FlashParts Gerenciar cadastro de templates Gerenciar terminais Gerenciar usuários Gerenciar perfis Visualizar relatórios Observa-se que alguns casos de uso não estão relacionados a nenhum módulo da interface gráfica do sistema, pois são funções realizadas entre o software de controle e o software servidor sem a necessidade de uma interface gráfica. 77

81 Lista de Tarefas Programação Gerenciar tarefas Agenda Visualizar agenda Biblioteca de Vídeos Gerenciar vídeos Bibliotecas Biblioteca de Flashparts Gerenciar FlashParts Login Realizar Login Ajuda Consultar ajuda Biblioteca de Templates Gerenciar cadastro de templates Terminais Gerenciar Terminais Usuários Administração Gerenciar Usuários Perfis Gerenciar Perifs Relatórios Visualizar Relatórios Relatorio Geral Relatorio por Vídeo Figura 14 - Associação do mapa de navegação com os casos de uso Wireframes Nesta seção serão exibidos os wireframes elaborados para o desenvolvimento do sistema. Inicialmente, serão apresentados os modelos utilizados para a interface do software do servidor, o e-sign server. Em seguida, alguns casos particulares e, por fim, alguns modelos de template que serão utilizados no terminal. 78

82 Modelo Geral A arquitetura de informação do sistema e-sign server é a seguinte: Menu principal no topo da página com a logomarca do sistema e botões para os três principais módulos do sistema. Submenu do módulo ativo, com botões de acesso para as páginas internas de cada módulo. Área de conteúdo, apresentando as informações do sistema, com as ações controladas na barra de ferramenta localizada abaixo do nome da página. Figura 15 - Wireframe do modelo geral Modelo Lista O modelo de lista é utilizado em todos os sub-módulos do sistema e-sign server para exibir as informações armazenadas na base de dados. 79

83 Ela possui em sua barra de ferramenta o botão Novo para a inclusão de um novo item (no exemplo, um novo FlashPart). Ao clicar neste botão, o sistema redireciona para uma página de inclusão semelhante ao wireframe Mod_Inserir. A lista é composta pelos nomes das colunas e pelos itens. Cada página da lista é limitada em 10 itens, limite este que pode ser alterado conforme necessidades. Ao clicar no nome do campo de uma coluna, a lista será ordenada alfabeticamente pela coluna escolhida, alternando entre ordem decrescente e crescente. O padrão da lista é ser ordenada alfabeticamente de forma crescente pelo nome do item. Um campo de cada item (geralmente o nome) estará sublinhado, possuindo a função de link para a visualização de detalhes do item. A navegação entre as páginas da lista pode ser realizada através dos links existentes para cada número de página abaixo da lista. Mod_Lista Logo Programacao Biblioteca Administração Vídeos Flash Parts Templates Biblioteca de FlashParts Segue para Mod_Inserir Novo Ordenar pelo campo Nome FlashPart1 Descrição Ut wisi enim ad minim veniam Arquivo video1.swf Link link1 Segue para Mod_Detalhe FlashPart2 FlashPart3 Ut wisi enim ad minim veniam Ut wisi enim ad minim veniam video2.swf video3.swf link2 link3 FlashPart4 Ut wisi enim ad minim veniam video4.swf link Paginação F.C.G F.M M.M.K Figura 16 - Wireframe de modelo de lista. 80

84 Modelo Inserir A página modelo para a inserção de itens possui uma barra de ferramenta com o botão Voltar, que cancela a operação e redireciona para a página de lista; o formulário para inserção de dados e o botão Salvar. Quando o usuário aciona o botão Salvar, o sistema irá realizar as validações básicas, verificando se todos os campos necessários estão preenchidos e se os dados estão no formato correto. Caso seja detectado algum problema, uma janela de alerta aparecerá no navegador do usuário com as instruções necessárias para o correto preenchimento. Para o caso de itens que necessitem de arquivos anexados, o usuário deverá selecionar através de uma janela de busca de arquivos-padrão do sistema operacional do usuário, o arquivo a ser anexado ao item. Para o envio do anexo é necessário acionar o botão Enviar para que o anexo seja salvo no e-sign server. Figura 17 - Wireframe modelo inserir. 81

85 Modelo Detalhe Neste modelo, todos os atributos do item são exibidos em formato tabular. A barra de ferramentas é composta por quatro botões: Voltar: Retorna para a página de lista; Novo: Segue para o formulário de inserção (Mod_Inserir); Editar: Segue para o formulário de edição do item selecionado; Excluir: Envia o pedido de exclusão do item. O sistema retornará um aviso de confirmação conforme Mod_Excluir. Figura 18 - Wireframe do modelo de detalhe. 82

86 Modelo Editar Neste modelo o formulário é exibido com os dados já armazenados no banco de dados e permite sua atualização mediante o clique no botão Salvar. Este botão possui validações semelhantes ao caso de inserção de itens. O botão Voltar da barra de ferramentas cancela a operação de edição e retorna a página para a tela com a lista. Figura 19 - Wireframe modelo de edição. 83

87 Modelo Excluir O modelo para páginas de exclusão apresenta uma caixa com uma questão de confirmação da operação. Caso o usuário confirme a exclusão, o sistema executará a operação e seguirá para a página de lista, caso contrario o sistema retorna para a página de detalhes do item selecionado. Figura 20 - Wireframe do modelo de exclusão. 84

88 WF -01 Lista de Tarefas A lista de tarefas possui dois filtros especiais: o filtro de terminais e o filtro de tarefas antigas. O filtro de terminais permite exibir somente as tarefas relacionadas ao terminal desejado. Por padrão, o filtro é desativado. Ou seja, todas as tarefas são exibidas independentemente do terminal associado. O filtro para tarefas antigas permite a visualização das tarefas anteriores à data atual. O padrão não exibe as tarefas antigas. Figura 21 - WF-01 - Wireframe da lista de tarefas. 85

89 WF Selecionar Terminal No fluxo de inserção de uma nova tarefa, conforme descrito no caso de uso Gerenciar tarefa, o usuário seleciona o terminal no qual deseja inserir uma nova tarefa. Ao selecionar o terminal, o sistema seguirá para a tela de nova tarefa. Figura 22 - WF-02 - Selecionar o Terminal. 86

90 WF Inserir Tarefa A inserção de tarefas possui um formulário mais complexo que os demais. Isto se deve pela quantidade de informações necessárias e pelas possibilidades existentes. Todos os pormenores do processo de inserção foram definidos no fluxo alternativo de inserção no caso de uso Gerenciar tarefa. Com relação à navegação e interface, a ferramenta de escolha de vídeos é diferenciada. Para a escolha de vídeos, é necessário selecionar um ou mais vídeos da lista, e em seguida clicar no botão +. Para retirar os vídeos da lista escolhida basta selecionar os vídeos na lista e clicar no botão -. A lista de vídeos escolhidos permite a repetição de itens. Além disso, a lista pode ser ordenada através dos botões up e down. Ao lado dos campos de data existe um ícone para acesso ao calendário flutuante, que permite a seleção da data desejada no formato padrão do sistema. Figura 23 - WF-03 - Wireframe para inserção de uma tarefa. 87

91 WF Visualizar Agenda O segundo modo para a visualização das tarefas de um terminal é pela interface de Agenda. O usuário primeiramente deve escolher o terminal que deseja visualizar a agenda. Esta escolha é realizada em tela semelhante ao WF-02, diferenciando apenas o link sobre o nome do terminal, que possui o redirecionamento para a visualização da agenda. A agenda possui a disposição gráfica das tarefas destinadas ao terminal selecionado que estejam na data definida. A data padrão para a exibição da agenda é a do dia atual. A navegação de dias ou semanas anteriores ou posteriores é feita pelos ícones posicionados no canto superior direito da agenda. Ao selecionar uma tarefa, o sistema exibe o formulário da tarefa para edição. Para os casos de tarefas com períodos muito pequenos (menores de 15 min), aparecerá um ícone ao lado da data da tarefa, que ao ser clicado exibirá uma janela flutuante contendo a lista completa das tarefas que não estão na agenda. Figura 24 - WF-04 - Wireframe da agenda de tarefas. 88

92 WF -05 Detalhes do vídeo Segue o modelo de detalhes com o acréscimo de um player de vídeo. Figura 25 - WF-06 Wireframe de detalhes do vídeo WF -06 Inserir template Modelo de inserção com a funcionalidade de pré-visualização do template. Figura 26 - Wireframe de inserção de template. 89

93 Exemplos de templates para o terminal. Abaixo, dois exemplos de templates para o terminal. O primeiro para telas de proporção 4:3, com 3 posições para FlashParts e uma posição para os vídeos, e um segundo template com uma posição para FlashPart e outra para vídeos. VIDEO PART FLASH PART FLASH PART FLASH PART Figura 27 - Wireframe de template para o terminal com 3 posições para FlashParts (4:3). Figura 28 - Wireframe de template para o terminal com uma posição para FlashPart (16:9). 90

94 6.13. FlashParts Um dos objetivos propostos pelo projeto é o de prover uma arquitetura flexível, que dê liberdade ao desenvolvedor não só para definir a forma como deseja dividir a tela do terminal, como também para criar seus próprios mini-aplicativos, os chamados FlashParts Definição FlashPart é o nome dado a cada um dos mini-aplicativos construídos em Flash, e que apresentam suas próprias funcionalidades. Os vídeos e animações Flash, estejam eles no formato flv ou swf, são reproduzidos em loop, dentro da janela de tempo da tarefa que estiver sendo apresentada no momento. FlashParts, por sua vez, são executados uma vez em cada tarefa. Ou seja, não pode ser definida mais de um FlashPart por frame em uma tarefa Potencial e Restrições A princípio, os FlashParts podem ser desenvolvidos explorando-se todo o potencial presente no Adobe Flash CS3, tanto no aspecto de desenvolvimento gráfico das animações, quanto na codificação por ActionScript, contanto que se respeitem as seguintes restrições: - Restrições do Terminal: todo FlashPart será adicionado ao programa principal do e-sign player como filha, herdando suas propriedades e classes. Os FlashParts desenvolvidos devem, portanto, respeitar todas as restrições observadas no Terminal. - Tamanho de exportação: o FlashPart deve ser exportado com o tamanho do palco (stage) igual ao tamanho do frame em pixels onde se deseja executá-lo. - Restrições de exportação: para evitar que certas camadas de animação vazem para cima de outros FlashParts, sobrepondo-os, recomenda-se restringir o 91

95 movimento dos objetos de cena ao interior do palco do aplicativo. Além disso, devese definir uma taxa de quadros por segundo (fps - frames per second) compatível com a definida pelo e-sign player. Uma vez adicionado como filho, o FlashPart passa a ser executado à taxa de quadros por segundo herdada do e-sign player. - Tratamento de erros: quando ocorrem eventos inesperados nos aplicativos Flash, uma mensagem de erro é aberta, sobrepondo o programa em execução. Para evitar este tipo de ocorrência, recomenda-se tratar todos os eventos que porventura possam resultar em erros em tempo de execução FlashParts Desenvolvidos A fim de se demonstrar seu potencial, alguns FlashParts foram desenvolvidos. Eles foram projetados para atender a um template que exibe vídeos de tamanho 800x600 pixels em seu frame principal, deixando o espaço restante livre para a utilização pelos FlashParts. A figura abaixo ilustra a posição dos FlashParts: Figura 1 - Representação de tela do terminal com FlashParts 92

96 Previsão do Tempo Descrição Este aplicativo tem a função de receber as últimas informações de previsão do tempo, exibindo-as de forma atraente e objetiva Requisitos Funcionais Exibir as informações de temperaturas mínima e máxima, probabilidade e quantidade de precipitação, e descrição da previsão do dia na cidade de São Paulo. Além disso, exibir informações resumidas dos quatro próximos dias, contendo apenas as máximas e mínimas esperadas para cada uma delas. Em todos os casos, mostrar também uma figura para a representação visual da descrição Requisitos Não-Funcionais Por causa da conexão a uma URL externa, é imprescindível que o terminal tenha livre acesso à internet. Para configurar o Flash Player, consultar o anexo C Implementação Este FlashPart consiste em um aplicativo simples que lê as informações de previsão do tempo de um feed RSS 7, fazendo o parsing do XML e extraindo as informações dos cinco próximos dias (o dia atual, inclusive) da cidade de São Paulo. 7 RSS: RDF Site Summary, representa uma família de formatos XML usualmente utilizados para a publicação de conteúdo freqüentemente atualizado, como portais de notícias e blogs. 93

97 Concebida para ser apresentado no quadrante superior direito do display, foi exportado no tamanho de 224x600 pixels Notícias Descrição Este FlashPart tem o objetivo de apresentar as manchetes mais recentes de notícias de forma dinâmica e atualizada Requisitos Funcionais Receber as manchetes de uma fonte e exibir as últimas dez de forma rotativa, uma a uma Requisitos Não-Funcionais O aplicativo não deve parar por não conseguir ler a fonte de notícias. Caso isso ocorra, deve ser reproduzida uma tela de descanso no lugar das manchetes. As notícias devem ser constantemente atualizadas, a fim de sempre apresentar as últimas manchetes. É importante que se desative o cache do Flash Player, para que as notícias possam ser atualizadas. Para configurar o Flash Player, consultar o anexo C Implementação Um feed RSS é lido para extrair as dez últimas notícias que são apresentadas uma de cada vez, rotativamente. Depois de apresentada a última notícia, o RSS é requisitado novamente, atualizando a lista de notícias. 94

98 Usa-se um timer para a verificação da leitura do XML de notícias. A cada tentativa de leitura, o timer é disparado. Em caso de sucesso, o timer é parado e o programa prossegue normalmente. Caso a requisição demore a retornar uma resposta, o logo do e-sign é mostrado até que se consiga ler um novo XML. Concebido para ser apresentado no quadrante inferior esquerdo do display, foi exportado no tamanho de 800x168 pixels Relógio Relógio simples, que exibe a hora correta Requisitos Funcionais Exibir a hora correta do sistema no formato HH:MM, juntamente com o logo do e- Sign Requisitos Não-Funcionais Este FlashPart deve se manter operante enquanto estiver sendo exibido Implementação A implementação, extremamente simples, trata de um aplicativo que recupera, a cada intervalo de tempo, o horário do sistema operacional em que está sendo executado, atualizando a informação no display. Concebido para ser apresentado no quadrante inferior direito do display, foi exportado no tamanho de 224x168 pixels. 95

99 7. Desenvolvimento Nesta seção serão detalhados todos os passos de implementação do sistema, explanando sobre as ferramentas, técnicas e modelos utilizados para a codificação do sistema Metodologia de Desenvolvimento O desenvolvimento teve início tão logo se concluiu o projeto do sistema. Por se tratar de um sistema composto por duas partes diferentes (o Servidor, fromado pleo e-sign server e o Terminal composto pelo e-sign sync e e-sign player), e que poderiam ser desenvolvidos de forma totalmente independente entre si, decidiu-se por realizar a implementação de ambos os módulos paralelamente, em duas frentes de trabalho. Para o estudo de viabilidade e prova de conceito das funcionalidades principais, foi definido um conjunto de funções que seriam implementadas inicialmente, como primeiro protótipo do sistema. O protótipo envolve uma quantidade restrita de funcionalidades do sistema completo. As funcionalidades selecionadas foram: Gerenciamento da biblioteca de vídeos o Inserir / Editar / Visualizar Lista / Visualizar Detalhe / Excluir lista o Upload de arquivos Controle de vídeos no terminal o Leitura de arquivo XML o Exibição de vídeos Envio de arquivos via FTP para os terminais. Tendo, então, o protótipo funcional em mãos, seria possível continuar o desenvolvimento do sistema completo, mas modularmente, agregando as demais funcionalidades esperadas do projeto. 96

100 Ao final, realizou-se a integração do sistema, a fim de se simular o funcionamento e certificar-se de que os módulos estivessem se comunicando, testando exaustivamente todos os componentes Divisão da Tela em Frames Para efeitos de programação, a tela do terminal será definida como uma área dividida em quatro partes, respeitando a figura a seguir: Frame 1 Frame 2 Frame 3 Frame 4 Figura 2 - Modelo de estrutura da tela do terminal A tela poderá, dessa forma, ter de um a quatro frames, de acordo com o template escolhido. Cada uma dessas partes poderá ter tamanho variável, dependendo do template escolhido no e-sign server, e terá suas dimensões definidas por duas variáveis: width (largura) e height (altura), ambas descritas no XML de programação. Assim, se quisermos uma tela com apenas um frame de programação, definimos o width e height do frame 1 como sendo do tamanho da tela inteira, e os atributos dos demais frames como sendo zero. Um exemplo gráfico, dado que a resolução da tela é de 800x600 pixels: Frame 1 97

101 Frame 3 Figura 3 - Exemplo de tela com dois frames Os atributos passados ao terminal são os seguintes: Frame 1: width=800 e height=450 Frame 2: width=0 e height=0 Frame 3: width=800 e height=150 Frame 4: width=0 e height=0 A posição relativa de cada um dos frames é calculada a partir do tamanho das demais Ferramentas Utilizadas Esta seção descreve brevemente as ferramentas utilizadas na implementação do sistema e-sign Linguagens utilizadas Esta seção apresenta as linguagens utilizadas para o desenvolvimento do sistema e- Sign PHP PHP Hypertext Preprocessor O PHP é uma linguagem de programação voltada para a geração de conteúdo dinâmico. Apesar de ser voltada à Web, é uma linguagem muito poderosa. Essa linguagem apresenta as seguintes características interessantes no desenvolvimento do presente sistema: 98

102 Portabilidade: há interpretadores PHP para as plataformas mais utilizadas (Linux, Windows, Unix, etc.). Facilidade de interface com a Web: o controle do servidor central é feito via Web. Usar PHP facilita a criação páginas para controle do sistema. Orientação a objetos: o PHP implementa objetos e assim, é uma solução que permite a utilização da metodologia OO ActionScript 3 O ActionScript 3 é a linguagem de programação utilizada no Adobe Flash CS3. Ele apresenta uma série de propriedades que fazem dele uma boa escolha para a implementação, que se seguem: Orientação a objetos: além de facilitar a programação, a divisão em classes e a estrutura em objetos resultam em uma maior modularidade e expansibilidade. Reconhecimento de eventos: o fácil reconhecimento de eventos auxilia no gerenciamento dos vídeos e na manutenção da programação do terminal. Portabilidade: como a idéia inicial do Flash era disponibilizar uma ferramenta para criação de animações para a Web, os programas criados nesta plataforma são extremamente portáveis, com versões do Flash Player distribuídos em todos os principais sistemas operacionais (Windows, Mac OS, Linux). XML: o ActionScript permite a leitura de arquivos XML, utilizados neste projeto para transmitir as informações sobre a programação do terminal. Mais detalhes sobre o formato utilizado serão apresentados posteriormente. Familiaridade de formatos: os formatos a serem tocados no terminal são o SWF (formato de aplicações e animações Flash) e o FLV (formato de vídeo do Flash). Como ambos são suportados nativamente pela linguagem ActionScript, não há problemas decorrentes de conversão de formatos ou implantação de plugins externos. Comunicação com outras linguagens: o ActionScript possui fácil integração com aplicações HTML e com o JavaScript. Demais linguagens a verificar. 99

103 JavaScript O JavaScript é uma linguagem de script altamente utilizada como linguagem de execução de código client-side em páginas Web. Por esse motivo seu auxílio na dinamização de interfaces Web é muito útil, nos seguintes aspectos: Diminui a necessidade de recarregamento de páginas: aliada ao XML e com alguns métodos bem definidos, essa linguagem permite o desenvolvimento de páginas AJAX 8 com apresentação dinâmica de conteúdo sem a necessidade de se baixar uma página nova completa do servidor. Permite a manipulação de objetos HTML client-side: interações do usuário com a interface podem ser processadas pelo próprio cliente, reservando ao servidor apenas as tarefas que realmente devem ser executadas em server-side. Possui larga documentação na Web, bem como numerosos exemplos, APIs e bibliotecas prontas que agilizam o desenvolvimento. Além disso, é largamente utilizada para criação de aplicações on-line de sucesso como o Google Calendar, o Writely 9, entre muitas outras. Tem como única desvantagem a falta de padronização na implementação nos browsers mais utilizados. Apesar disso, tendo em vista os benefícios de sua adoção, foi escolhida como linguagem auxiliar de interface no projeto C#.NET C# (lê-se c-sharp) é uma linguagem de programação orientada a objetos desenvolvida pela Microsoft como parte da iniciativa.net e posteriormente aprovada como um padrão pela ECMA e pela ISO. C# tem sua sintaxe orientada a objetos baseada no C++ e inclui aspectos de várias outras linguagens de 8 Vide Glossário. 9 Ambas as ferramentas são parte do pacote de serviços do Google. Com a integração, o Writely passou a ser chamado Google Docs. 100

104 programação (mais proeminentemente Delphi e Java), com uma ênfase particular em simplicidade. Uma grande vantagem do C# é a disponibilidade da IDE Microsoft Visual Studio para o desenvolvimento de projetos, o que facilita e guia o desenvolvimento de aplicações das mais diversas naturezas. C# foi escolhida como linguagem para implementação do e-sign sync pelo seu foco em simplicidade, desempenho (principalmente em memória) e pela afinidade préexistente dos desenvolvedores com ela Plataformas Nesta seção, são citadas as plataformas de desenvolvimento e de execução do sistema NET O Framework.NET é um componente de software que pode ser adicionado ou incluído com o Microsoft Windows. Ele provê um grande corpo de soluções précodificadas para necessidades recorrentes em programação e gerencia a execução de programas escritos especificamente para o framework. Dá o suporte necessário para a execução de programas escritos na linguagem C#.NET, utilizada para o desenvolvimento do e-sign sync MySQL O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem SQL (Structured Query Language - Linguagem de Consulta Estruturada) 101

105 como interface. É atualmente um dos bancos de dados mais populares, com 30% do mercado de gerenciadores de banco de dados do mundo Servidor PHP Software processador das páginas dinâmicas escritas em script PHP. Implementa a interpretação e execução de scripts PHP junto ao servidor Web, recebendo pedidos de processamento de scripts e retornando a saída que eles geram para o servidor Web. Permite a utilização de recursos do servidor, como o banco de dados, pelo usuário via Web Flash Player Plataforma de execução do e-sign player. Permite a execução de RIAs (Rich Internet Applications) no lado cliente, mais especificamente os arquivos exportados como SWF, que permitem a execução de procedimentos complexos client-side que enriquecem e alargam significativamente o horizonte de possibilidades de aplicações sobre o player. Presente nos sistemas operacionais mais populares do mercado, promove portabilidade para aplicações Flash IDEs Esta seção descreve as IDEs (Integrated Development Environment) utilizadas no projeto. 10 Dados retirados de acessado em Maio de

106 Zend Poderosa ferramenta de desenvolvimento de scripts PHP, que inclui diversas facilidades para o desenvolvedor, como: Grifo de sintaxe: destaca as palavras-chave, facilitando a visualização do código. Sugestão de código: sugere possibilidades relevantes para um termo enquanto é digitado. Ambiente de teste: permite a análise em tempo de execução com debugger Adobe Flash CS3 Ambiente de desenvolvimento de aplicações Flash com editor de interface visual (o vídeo Flash) e de código (ActionScript) Microsoft Visual Studio O Visual Studio é o IDE desenvolvido pela Microsoft para a plataforma.net, e foi utilizado no projeto como suporte ao desenvolvimento do e-sign sync na linguagem C#.NET Configuração inicial e prototipagem Nesta seção, serão detalhados os aspectos relativos à configuração de todo ambiente tecnológico para o início da prototipagem. 103

107 Configuração do Ambiente de Desenvolvimento Para o desenvolvimento do e-sign server, foi configurado um ambiente onde foi instalado o aplicativo EasyPHP , que reúne em um mesmo pacote o servidor Apache 2.2.3, o interpretador PHP 5.2.0, o banco de dados MySQL e a aplicação de administração do banco de dados PHPMyAdmin O EasyPHP é uma aplicação para plataforma Microsoft Windows que facilita a instalação e configuração dos componentes do servidor. No caso do e-sign player, a configuração se limitou à instalação do Adobe Flash CS3. O Microsoft Visual Studio 2005, por sua vez, foi instalado para o desenvolvimento do e-sign sync. A ferramenta de controle de versões utilizado pela equipe de trabalho é o SVN (SubVersion), utilizando-se o cliente TortoiseSVN 12 em conjunto com o repositório gratuito disponibilizado pelo website Assembla 13, que permite o compartilhamento e controle dos códigos-fonte e documentos entre os integrantes da equipe Configuração do Ambiente de Execução Para que os softwares desenvolvidos pudessem ser propriamente executados, os seguintes ambientes foram configurados: 11 [EasyPHP] Apache MySQL PHP PhPMyAdmin. Informações e download do software. Disponível em: < Acesso em: 26 nov TortoiseSVN. Informações e download do software. Disponível em: < Acesso em: 26 nov Workspaces for agile teams and rapid application development Assembla. Oferece ferramentas para gerenciamento de sistemas. Disponível em < Acesso em: 26 nov

108 Servidor central: Apache TomCat: instalado com usuário próprio; MySQL: instalado e com usuário configurado com permissões plenas sobre o BD. Inclusas as tabelas da especificação de banco de dados; PHP: instalado como módulo Apache com a extensão FTP e com execução de comandos shell_exec, exec e operador ` (crase) habilitados; FFmpeg: instalado na pasta FFmpeg, dentro da pasta padrão do Apache. Este caminho deve ser adicionado à variável PATH do sistema; Servidor de FTP para envio de arquivos aos terminais. Sistema operacional: configurado de modo a levantar o ambiente descrito de execução no boot do sistema, sem necessidade de interação humana Computadores Terminais: Sistema operacional: configurado de modo a levantar o ambiente de execução no boot do sistema sem necessidade de interação humana; Sistema de arquivos: cada terminal terá uma pasta esign na raíz de seu sistema de arquivos cuja subpasta tem o nome do terminal. Caso haja mais de um terminal rodando no mesmo computador haverá mais pastas, cada uma com o nome individual do terminal associado; Flash Player 9.0: simplesmente instalado o standalone player (não é necessário o plugin para browser) Árvore de Diretórios Para o funcionamento do sistema, espera-se que as seguintes configurações de diretórios sejam criadas: 105

109 Computador terminal: Pasta do terminal: [raiz]/esignterm/[nome do terminal]. Os vídeos serão depositados na subpasta [raiz]/esignterm/[nome do terminal]/vídeos. Os FlashParts se localizarão na subpasta: [raiz]/esignterm/[nome do terminal]/fparts. As instalações de softwares agregados (Apache, MySQL, etc.) são efetuadas cada uma nas respectivas pastas padrão. Cada usuário FTP terá permissão de escrita na pasta do respectivo terminal. A programação será guardada em [raiz]/esignterm/[nome do terminal]/prog Servidor central: Pasta do servidor: [raiz]/esignserv. O conteúdo da biblioteca será depositado em [raiz]/esignserv/lib. Os vídeos disponíveis serão guardados em [raiz]/esignterm/[nome do terminal]/lib/videos. Os FlashParts disponíveis serão guardados em [raiz]/esignterm/[nome do terminal]/lib/fparts. Obs: [raiz] é a pasta raiz do sistema ou seja, / em sistemas POSIX e c:\ no sistema Windows Protótipo Os aspectos mais importantes do desenvolvimento do protótipo serão relatados a seguir. 106

110 e-sign server Foi desenvolvido com sucesso o protótipo para controle de arquivos de vídeos, com o armazenamento das informações em banco de dados e o arquivo em diretório pertinente. «interface» APreviewVideo DVideo BPreviewVideo +selectbyid() +selectall() +insert() +update() +delete() «interface» AVideo «utility» UConverteVideo BVideo +selecionarvideo(entrada IDPerfil : int) +selecionartodosvideos() +inserirvideo() +editarvideo() +excluirvideo() «uses» EVideo -IDVideo : int -Nome do vídeo : string -Descrição : string -Produtor : string -Duração : string -Resolução : string -Path : string -nomedoarquivo : string -nomearqfisico : string -IDArquivo : int Figure 4 - Diagrama de classes 107

111 Figure 5 - Diagrama dos arquivos do Protótipo e-sign player A prototipagem do Terminal envolveu a implementação de suas principais funcionalidades: Ler e extrair as informações da programação de vídeos do arquivo XML; Configurar as partes do terminal, lendo os atributos de largura e altura de cada umas delas do arquivo XML; Para cada parte da tela do terminal, executar a respectiva lista de vídeos (em formatos FLV ou SWF). Todas estas funcionalidades foram implementadas em linguagem ActionScript 3.0, e são executadas no Flash Player 9. Por ser uma linguagem orientada a objetos, foi realizada uma modelagem com as seguintes classes: Programação: Responsável por ler o arquivo XML de programação, e guardar informações de horários de começo e fim de programação, e as instâncias das telas. Tela: Responsável por guardar informações de cada uma das partes (frames) que compõem a interface do terminal, tais como tamanho da tela e lista de vídeos que nela serão exibidas. Estas duas classes foram agrupadas em um pacote, chamado terminal. 108

112 O protótipo é executado em uma resolução de tela fixa de 1024x768 pixels. Durante a prototipagem do Terminal, não foram levadas em consideração quaisquer funcionalidades de controle, segurança e confiabilidade. O arquivo XML definido na fase de protótipo possui uma estrutura que segue o do exemplo abaixo: <programacao> <prog> <inicio> </inicio> <fim> </fim> <tela1> <width>512</width> <height>384</height> <video>comercial_1.flv</video> <video>comercial_2.flv</video> <video>comercial_3.flv</video> <video>comercial_4.flv </video> </tela1> <tela2> <width>512</width> <height>384</height> <video>informacoes.swf</video> </tela2> <tela3> <width>512</width> <height>384</height> <video>noticias.swf</video> </tela3> <tela4> <width>512</width> <height>384</height> <video>previsaodotempo.swf</video> </tela4> </prog> </programacao> Ao interpretar o XML, o e-sign player deverá renderizar e mostrar uma interface com a divisão de telas nos tamanhos descritos, tocando em loop os vídeos listados em 109

113 cada uma delas. Cada nó <prog> especifica uma programação, ou seja, uma configuração, que deverá ser mostrada no período de tempo que vai de <inicio> até <fim>. O XML acima resultaria na seguinte configuração: Figure 6 - Exemplo de montagem de tela do terminal Classes PHP Durante a fase de prototipagem, planejava-se realizar as transferências de arquivos a partir de um cliente FTP instalado no Servidor, que acessava os servidores disponíveis em cada um dos terminais. Esta topologia foi posteriormente alterada. Porém, algumas tecnologias foram estudadas Testes com FTP 110

114 Teste com a funcionalidade de envio de FTP. Foi gerada uma classe chamada PS_FTPClass, no PHP, que contém todos os métodos necessários para a conexão FTP entre terminal e servidor. Os testes foram realizados sobre um servidor FTP Filezilla Server configurado localmente. Para utilizar os métodos relativos ao FTP, é necessário construir uma instância de conexão, passando como parâmetros os dados do servidor e usuário FTP. Uma vez estabelecida a conexão, passa a ser possível utilizar os demais métodos da classe, a partir desta instância Testes de Construção de XML A classe XMLClass, desenvolvida em PHP, é responsável pela construção de um arquivo XML estruturado para prover a programação de um terminal. O protótipo apresenta a funcionalidade de construção da estrutura do XML. Porém, ainda resta implementar o recebimento dos parâmetros pelo método. A classe contém apenas uma construtora, que receberia como parâmetros as arrays contendo os dados de programação a serem passados ao Terminal, e constrói o arquivo XML respectivo. Assim, para que se crie o XML requerido, necessita-se apenas que se instancie um novo objeto com os parâmetros desejados Detalhes de Implementação Nesta seção, serão apresentados os detalhes mais importantes da implementação do sistema, bem como observações realizadas durante o desenvolvimento e-sign server Algumas funcionalidades e regras de negócio foram acrescentadas ou modificadas durante o percurso do projeto. 111

115 Log SQL Para facilitar o desenvolvimento e o diagnóstico de erros, foi criada uma função de log para as funções SQL, ou seja, qualquer query do banco de dados é armazenado em um arquivo txt Mudança no Banco de Dados para Upload de Vídeos Durante o desenvolvimento, constatou-se que a mudança da arquitetura do banco de dados facilitaria o gerenciamento de arquivos. Desta forma, foi criada uma tabela para armazenamento dos dados de arquivos, onde cada item receberia um identificador único. Todo arquivo enviado para o servidor é renomeado com o identificador único como o nome do arquivo Estudo de Nova Feature e Regra de Negócio Para Tarefa Na parte de inclusão de novas tarefas foi estudada a proposta para inclusão como feature de uma nova política de acomodação das tarefas preexistentes quando conflitantes com a nova tarefa. 1. Caso exista o conflito de horários de tarefas em uma inserção ou edição, o sistema informará o conflito e dará 3 opções: 1.1) Excluir as tarefas em conflito: Caso as tarefas em conflito atendam à regra 3, as tarefas são excluídas e a nova tarefa é criada. 1.2) Quebrar as tarefas em conflito: Caso as tarefas em conflito atendam a regra 3, as tarefas em conflito serão quebradas da seguinte forma: A) Caso a intervalo de execução da nova tarefa esteja inserida no tempo de execução de uma tarefa, a antiga tarefa será dividida em duas partes e a nova tarefa será incluída. - Tarefa antiga: 14:00 às 15:00 - Nova tarefa: 14:15 às 14:30 112

116 - Tarefa antiga quebrada em: 14:00 as 14:15 e 14:30 às 15:00 Figura 29 - Caso de inclusão de tarefa em horário ocupado por um a tarefa. B) Caso o intervalo da nova tarefa faça intersecção com duas tarefas já existentes, haverá a quebra das duas tarefas e a inclusão da nova tarefa: - Tarefas antigas: A) 14:00 às 15:00 B) 15:00 às 16:00; - Nova tarefa: 14:30 às 15:30; - Tarefas antigas divididas em: A) 14:00 às 14:30 B) 15:30 às 16:00 Figura 30 - Caso de inclusão de tarefa em intervalo sobreposto a duas tarefa. Obs.: Este caso vale para novas tarefas que fazem intersecção com somente uma tarefa antiga. C) A nova tarefa faz intersecção com duas tarefas e engloba o intervalo de uma ou mais tarefas. Neste caso as tarefas, com todo seu intervalo comprometido, serão excluídas. - Tarefas antigas: A) 14:00 às 14:45 B) 14:45 às 15:15 C) 15:15 às 16:00 - Nova tarefa: 14:30 às 15:30; - Exclusão da tarefa B. Divisão das tarefas A e C: A) 14:00 às 14:30 C) 15:15 às 16:00 113

117 Figura 31 - Caso de inclusão com conflito com três ou mais tarefas. 1.3) Cancelar a operação de inclusão ou edição. Resultado: A feature foi rejeitada para a primeira versão devido à necessidade de funções complexas ainda não implementadas no sistema e também ao comprometimento da simplicidade do sistema: Análise de tipo de conflito entre a nova tarefa e as tarefas preexistentes com tratamento diferenciado para cada caso(dia). Clonagem de tarefas. Dificuldade de informar efetivamente ao usuário quais alterações serão feitas para acomodação e de criar tarefa apenas onde o usuário autorizar. Foi adicionada ao planejamento de próximas versões Terminal Esta seção compreende a implementação do Terminal, dividido nos módulos e-sign player e e-sign sync e-sign player O módulo de interface do Terminal compreende a parte implementada em Flash, e tem como objetivos principais a leitura do arquivo XML que contém a programação daquele terminal e, a partir dele, a exibição dos vídeos e FlashParts nos horários e formatos por ele especificados. Algumas das observações mais importantes realizadas durante a implementação são as que se seguem: 114

118 Leitura do XML de Programação O arquivo XML contendo a programação do terminal é montado pelo e-sign server, reunindo as informações da agenda definidas para aquele terminal. Quando é feita a sincronização dos arquivos, o arquivo XML é transferido via FTP para o terminal juntamente com os vídeos nele listados. O arquivo XML consolidado possui o formato da figura abaixo. <programacao> <config> <IDTerminal>4</IDTerminal> <URLServidor> classes/brelatorio.php?funcao=insere</urlservidor> </config> <prog id= 12 > <inicio> </inicio> <fim> </fim> <tela1> <width>800</width> <height>600</height> <video>video-1.flv</video> <video>video-2.flv</video> </tela1> <tela2> <width>224</width> <height>600</height> <video>previsao.swf</video> </tela2> <tela3> <width>800</width> <height>168</height> <video>noticias.swf</video> </tela3> <tela4> <width>224</width> <height>168</height> <video>relogio.swf</video> </tela4> </prog> </programacao> Figura 32 - Formato do arquivo XML de programação. 115

119 A tag <config> traz os parâmetros necessários ao e-sign player para que este possa se comunicar com o servidor, a fim de se gerar o log. Esta funcionalidade será descrita no tópico Requisição de Geração do Log. A tag <prog> representa cada uma das tarefas que o e-sign player deve exibir. Deve existir um nó <prog> para cada tarefa diferente. Ou seja, o arquivo XML deve conter tantos nós <prog> quanto forem as tarefas definidas para aquele terminal. Cada nó <prog> contém as informações relativas a uma tarefa, listados a seguir: <inicio> : representa a data e horário de início da tarefa, no formato AAAA-MM-DDhh-mm-ss. <fim> : representa a data e horário de fim da tarefa, no formato AAAA-MM-DD-hhmm-ss. <tela1>, <tela2>, <tela3> e <tela4>: representam cada uma das divisões da tela do terminal, e contém as dimensões de cada uma delas (<width> e <height>), dependendo do template escolhido. Em cada uma delas, é definida uma lista dos vídeos (<video>) que será exibida em loop dentro do intervalo de tempo definido para a tarefa. Figura 7 - Representação de montagem da tela do terminal 116

120 Os nós <prog> do XML não precisam necessariamente estar em ordem temporal (ordenados por <inicio>) Exibição das Tarefas Quando iniciado, o e-sign player realiza a leitura do XML, colocando em uma fila todas as tarefas a serem executadas. Ao executar uma tarefa, o e-sign player dimensiona as Telas de acordo com os tamanhos determinados pelo template, executando os vídeos ou os FlashParts correspondentes a cada uma delas. A lista de vídeos é tocada em loop até que a tarefa termine. Dado o fim da tarefa, a próxima só deve começar a ser exibida no momento em que o vídeo sendo tocado no momento chegar ao seu fim. Ou seja, nenhum vídeo deve ser interrompido durante sua exibição. Além disso, o e-sign player deve verificar, a cada intervalo de tempo, se o arquivo XML foi alterado. Em caso positivo, descarta-se toda a fila de tarefas atual, construindo-se uma nova a partir do novo XML. A nova programação deve começar a ser exibida tão logo quanto for possível Requisição de Geração do Log Com o fim de gerar estatísticas de exibição dos vídeos em cada terminal, o e-sign player tem também a função de fazer requisições a uma URL do e-sign server, enviando como parâmetros o ID do terminal e o ID do vídeo que está sendo exibido no momento Loop de Arquivos SWF Flash Videos (arquivos flv) são relativamente simples de serem controlados em tempo de execução, uma vez que dispõem de uma série de eventos que indicam, por exemplo, o final do stream de vídeo. 117

121 Arquivos swf, por outro lado, podem não ser somente animações, como também podem conter aplicativos (FlashParts) e, assim, devem rodar por tempo indeterminado. Para viabilizar o loop de animações Flash em formato swf, foram analisadas as seguintes opções: a definição de um tempo fixo para as animações em swf, e a criação de um evento para sinalizar o final do vídeo. A definição de um tempo fixo consistiria apenas em se estipular uma duração fixa para a reprodução de cada animação, ficando a cargo de um timer lançar um evento para a troca de vídeo. Este método, apesar de simples de implementar, tira a flexibilidade das animações swf, uma vez que estas teriam que ter durações de tempo muito restritas. A criação de um evento, por outro lado, consistiria em definir algum tipo de evento (ou flag global) que seria disparada pelo swf reproduzido no momento, sinalizando o final do vídeo. Este evento seria recebido pelo e-sign player, que agiria avançando para o próximo vídeo da lista. Todas as animações no formato swf teriam, portanto, que disparar esse evento ao final de sua execução para que se pudesse realizar o loop de vídeos, ocasionando a inserção de código padronizado na sua criação. Nos arquivos swf utilizados neste projeto, foram inseridas, no último frame das animações, as seguintes linhas para possibilitar o loop: import terminal.glo; //importa a classe Glo try { Glo.tarefaAtual.tocarVideos(); } catch (e) { trace(e.message); } stop(); Figura 33 - Código para utilizar arquivos swf como vídeos. Deve-se, além disso, configurar o CLASSPATH de publicação do projeto, adicionando o diretório que contém a pasta /Terminal, onde estão contidas as classes do e-sign player Modelagem 118

122 A modelagem do e-sign player é relativamente simples, de acordo com o modelo de classes da figura a seguir: Figura 8 - Diagrama de classes: e-sign player Dado que a migração do ActionScript 2 para o ActionScript 3 eliminou a propriedade _global, para referência a variáveis globais, foi criada a classe Glo. Esta classe nada mais é do que uma agregadora de variáveis e métodos de utilização global. Por isso, é criada apenas uma instância desta classe durante a execução do programa. A variável strprog é um array que guarda instâncias da classe Programação. Esta classe é uma abstração dos nós <prog> do XML. Portanto, ela tem como objetivo manter informações de tempo de início e fim de cada uma das tarefas, assim como instanciar quatro objetos Tela, definindo suas posições no stage relativamente aos seus tamanhos. A classe Tela realiza o controle dos vídeos e FlashParts que devem ser tocados na parte correspondente da tela. 119

123 e-sign sync Inicialmente, este aplicativo seria integrado ao e-sign player, porém, devido restrições da linguagem de programação ActionScript, que não possui suporte a escrita de arquivos no diretório de arquivos locais, foi necessário o desenvolvimento deste aplicativo em outra plataforma, no caso, o C#. O aplicativo executa os processos descritos no caso de uso Sincronizar programação, realizando toda a comunicação com o servidor conforme o fluxo descrito anteriormente. Para a transmissão dos arquivos de vídeos e FlashParts, um canal FTP é aberto para transferência dos arquivos, que são armazenados em uma pasta local. Para realizar a distinção de terminais existe um arquivo de configuração que fornece todas as informações necessárias para o e-sign sync. Os principais parâmetros do arquivo de configuração são: O intervalo entre atualizações que define a periodicidade das atualizações dos arquivos de vídeo, FlashPart e programação. Identificador do terminal que diferencia cada terminal. Com este identificador é possível distinguir quais tarefas farão parte do terminal. URL do servidor que define o endereço do software Web e-sign server, para onde o Terminal fará as requisições e as transferências de arquivos Memória Utilizada Durante o desenvolvimento houve a preocupação quanto à eficiência deste módulo. Constatou-se, durante testes unitários, que a memória utilizada pelo aplicativo crescia gradualmente. Isto poderia acarretar problemas de desempenho do terminal. Para solucionar tal problema, encontrou-se o conceito do garbage collector (ou coletor de lixo), também conhecido por sua sigla GC, que é um processo usado no gerenciamento da memória nos sistemas computacionais. Com este recurso, é possível recuperar a zona de memória que um programa não utiliza mais. 120

124 8. Testes e Avaliação A cada iteração da etapa de implementação, realizaram-se testes unitários para verificar o funcionamento de cada um dos casos de uso descritos para o sistema. O objetivo era garantir que o Servidor e o Terminal funcionassem aceitavelmente antes de serem realizados os testes integrados. Para o teste integrado do sistema, simulou-se uma rede LAN contendo um Servidor e dois Terminais, caso em que não foram detectados maiores problemas Screenshots Visualmente, verifica-se que o sistema implementado segue a rigor o modelo planejado e detalhado pelos wireframes. As screenshots a seguir demonstram a interface tanto do Servidor (e-sign server), quanto do Terminal (e-sign player) e-sign server As screenshots correspondentes às principais telas da interface Web do e-sign server estão detalhadas a seguir Login Ao acessar o e-sign server, o usuário é recebido por uma tela de autenticação de usuário, onde é requisitado a inserir login e senha. 121

125 Figura 9 Screenshot: Autenticação de usuário Modelo Lista Após a autenticação, o usuário é levado à Biblioteca de Vídeos do Servidor. Observar que todas as páginas do sistema, excluindo-se a página inicial de autenticação, apresentam o cabeçalho com o menu principal (parte superior da tela). Este cabeçalho, além do logo do e-sign, contém os botões com links para as áreas de gerenciamento de tarefas (Programação), gerenciamento de bibliotecas (Bibliotecas), e funções administrativas (Administração), além dos botões de Ajuda e de Logout. Notar que este modelo de página serve de base para todas as áreas onde se deseja mostrar uma lista. 122

126 Modelo Inserir Figure 10 - Screenshot: Lista de vídeos As telas de inserção funcionam como descritas na seção Wireframes. Figura 11 - Screenshot: Inserção de FlashPart 123

127 Modelo Detalhe A figura abaixo representa o modelo de apresentação de detalhes de um FlashPart no sistema. As outras telas de inserção seguem o mesmo modelo. Não houve mudanças significativas entre o que foi projetado e o implementado. Figure 12 - Screenshot: Inserção de FlashPart Modelo Editar O modelo de edição de propriedades (ilustrada abaixo, a página de edição de um FlashPart) permite a alteração dos atributos do item selecionado (video, FlashPart ou template). 124

128 Figura 13 - Screenshot: Edição de FlashPart Modelo Excluir Quando requisitada a exclusão de algum item, seja ele video, FlashPart, ou template, uma tela de confirmação é apresentada. Esta tela provoca o escurecimento de todo o conteúdo visível da janela, apresentando uma janela com o pedido de confirmação de exclusão. Se a exclusão for confirmada (clicar em Sim ), o usuário é redirecionado à página onde são listados todos os itens daquela categoria. Se o usuário desistir da exclusão (clicar em Não ), ele simplesmente retorna à tela de visualização dos detalhes daquele mesmo item. O arquivo só pode ser efetivamente excluído se não pertencer a nenhuma tarefa registrada no servidor. Notar também que a exclusão de um arquivo é realizada apenas no cadastro do banco de dados. O arquivo físico permanece em disco. 125

129 Figura 14 - Screenshot: Exclusão de FlashPart Tarefas As tarefas já adicionadas ao sistema podem ser conferidas na tela de visualização de tarefas. Para a inclusão de novas tarefas, basta clicar no botão Novo. Isto direcionará o usuário à lista de terminais cadastrados no servidor, onde deve-se escolher qual terá sua programação alterada. Escolhido o terminal, abre-se a página de inserção de nova tarefa, onde são definidos os vídeos a serem exibidos, e em qual template. 126

130 Figure 15 - Screenshot: Lista de Tarefas Figure 16 - Screenshot: Lista de terminais 127

131 Figure 17: Inserção de nova tarefa Agenda Devido à quantidade de informações que devem ser exibidas simultaneamente, a agenda foi concebida para ser melhor visualizada em uma resolução de tela de pelo menos 1024x768 pixels. Assim, pode-se ter uma visão das tarefas programadas para a semana inteira, como em um calendário. As linhas da tabela, representando as horas, estão mais largas do que o inicialmente projetado, para melhor representar tarefas com duração de tempo pequenas, como aquelas que duram 15 minutos, por exemplo. 128

132 Figure 18 - Screenshot: Agenda de tarefas Vídeo Na exibição dos detalhes de um vídeo, foi criado um pequeno componente Flash responsável pela visualização em baixa resolução do item em questão. Este componente, de implementação simples, é baseado no FLVPlayback, nativo do Flash, e que provê um objeto de fácil configuração para a reprodução de vídeos em FLV. Por padrão, este reprodutor de vídeos realiza o streaming de um arquivo de vídeo remoto, iniciando a reprodução uma vez que seja possível. Além disso, ele oferece botões de controle simples, como o play/pause e a barra de progresso de reprodução (seek bar), e um controle de volume. 129

133 Figure 19 - Screenshot: Detalhes do vídeo Inserir Template Figure 20 - Screenshot: Inserção de template 130

134 Na página de inserção de template, há um preview que tem por objetivo mostrar ao usuário como será a montagem da tela do terminal a partir dos tamanhos especificados para cada frame. Aqui é especificado se determinado frame exibirá vídeos (marca-se a opção Exibe Video? ) ou se ele ficará responsável pela reprodução de um FlashPart, caso em que se escolhe, na combo box correspondente, um dentre os já cadastrados previamente e-sign player Figure 21 - Exemplo de tela do e-sign player A figura acima ilustra um exemplo de montagem de tela pelo e-sign player, considerando a seguinte configuração: - Frame 1: Tela principal, onde serão exibidos os vídeos. - Frame 2: FlashPart Previsão do Tempo. - Frame 3: FlashPart Notícias. - Frame 4: FlashPart Relógio. 131

135 8.2. Observações Os testes mostraram que é possível executar duas ou mais instâncias do e-sign player, em um mesmo terminal. Assim, é possível que um só terminal possa exibir várias programações diferentes e simultâneas, desde que seja configurada apropriadamente. Esta configuração envolve a criação de diretórios diferentes para cada instância que se deseja executar, cada um contendo os seus respectivos arquivos XML de programação, vídeos a serem exibidos e uma cópia do e-sign player Requisitos Não-Atendidos Os requisitos funcionais listados a seguir não puderam ser parcial ou totalmente atendidos nesta versão do sistema. - Criar grupos de terminais. - A funcionalidade de preview foi implementada apenas para a biblioteca de vídeos, onde se pode visualizar uma versão em baixa resolução dos vídeos escolhidos. Dada a complexidade, o preview de tarefas não foi implementado. - O sistema de keep-alive do Terminal, pela qual ele informa periodicamente ao Servidor que está functional, não foi implementado. Parte dessa funcionalidade, porém, pode ser verificada pela geração de log de reprodução de vídeos. Da mesma forma, alguns dos requisitos não-funcionais inicialmente pretendidos para o sistema não puderam ser implementados. São eles: - Acessibilidade: conexão entre servidores, permitindo o controle dos terminais ligados a redes diferentes; - Confiabilidade: reinicialização automática do software após queda de energia; - Segurança: criação de perfis e grupos de usuários diferentes. 132

136 8.4. Versões Futuras Durante o percurso do projeto, foram identificados requisitos que, por qualquer que seja o motivo, não puderam ser atendidos, além de funcionalidades não antevistas, mas que poderiam ser agregadas ao projeto em versões futuras. As funcionalidades que podem ser adicionadas em versões futuras do sistema estão listadas abaixo: Funcionalidade de exclusão automática de vídeos armazenados no terminal e que não mais serão utilizados. Isso resultaria em uma otimização do uso da memória de armazenamento do terminal, exigindo, assim, menos espaço livre. Servidores poderão estar conectados entre si, isto é, os servidores poderão se comunicar para controlar terminais associados aos servidores adjacentes. Equipamentos periféricos poderão ser acoplados no terminal e serem reconhecidos pelo software. As aplicações de periféricos são muitas. Por exemplo, pode-se ter uma impressora acoplada ao terminal, que permitiria a distribuição de cupons de desconto ou bilhetes informativos. Sistema de detecção de falhas no Terminal. O e-sign sync deve idealmente rodar como um serviço, sendo inicializado automaticamente pelo sistema operacional. Assim, no caso de queda de energia ou qualquer outra falha que force a reinicialização do terminal, garante-se que o sistema voltará a funcionar. Instaladores de fácil configuração. O instalador do Software para o Servidor ficaria responsável pela configuração do ambiente e população do banco de dados, através de interface Web. Já o instalador do Terminal teria o objetivo de criar o serviço do módulo de controle, assim como os diretórios para o armazenamento de vídeos. Download de FlashParts. A página de gerenciamento de FlashParts pode fazer referência a um repositório de onde novos FlashParts podem ser baixadas para uso. Aceitação de maior variedade de formatos de arquivos, como arquivos de apresentação (ex: PowerPoint) ou de imagem (ex: bitmap, JPEG, GIF). Utilização de uma maior quantidade de funcionalidades oferecidas pelo FFmpeg que necessitam de um estudo mais aprofundado para sua utilização. Por 133

137 exemplo: a criação de screenshots de frames dos vídeos e a definição de parâmetros de codificação avançadas. 134

138 9. Conclusão O desenvolvimento deste Projeto de Formatura permitiu que se fizesse o uso integrado de uma série de ferramentas e metodologias aprendidas com o foco na criação de um sistema complexo, composto por diversas partes, bastante diferentes entre si. Visto que a implementação do sistema completo implicaria no projeto de três componentes independentes (os chamados e-sign server, e-sign player e e-sign sync), fez-se necessária a especificação prévia detalhada de todas as interfaces entre estes módulos. Este cuidado foi de extrema importância, uma vez que se desejava o mínimo de conflitos na integração do sistema. A divisão do projeto nos módulos independentes trouxe também a vantagem da paralelização dos trabalhos, uma vez que facilitou sua divisão entre os componentes do grupo e permitiu que cada um melhor se concentrasse em seu ambiente de desenvolvimento. Estas medidas levaram ao atendimento de todas as funcionalidades tidas como primárias durante o planejamento. Como descrito nas seções anteriores, alguns dos requisitos listados não puderam ser atendidos, mas nenhum que interferisse significativamente no funcionamento do sistema esperado no planejamento. De fato, o grupo identificou o tempo como maior limitador dos trabalhos, uma vez que as concessões feitas foram em decorrência da necessidade de se adequar ao cronograma do projeto. A implementação utilizando a metodologia de orientação a objetos tem como uma de suas vantagens a maior facilidade de expansão do sistema. Assim, abre-se um leque muito maior de possibilidades quanto ao desenvolvimento de versões futuras baseando-se no sistema implementado neste Projeto de Formatura. Infelizmente, a principal característica do sistema, que é a possibilidade de se criar os próprios FlashParts para a montagem da própria programação no terminal, não pôde ter todo o seu potencial demonstrado. O desenvolvimento de cada FlashPart envolvia um projeto individual à parte que consumia tempos de implementação variados, dependendo de sua complexidade. Como o foco estava no desenvolvimento do sistema-base do e-sign, não foi dada prioridade à criação de 135

139 FlashParts de grande complexidade, limitando-se a aplicações mais simples, como o de exibição de notícias a partir da leitura de um feed RSS. Uma análise do potencial que o Flash provê, entretanto, sinaliza que é possível criar as mais diversas aplicações, envolvendo interatividade com o público, inclusive. Assim, permite-se, por exemplo, que sejam criados FlashParts que façam o uso de webcams ou microfones, para citar alguns exemplos. Considerando-se, portanto, o sistema de fato desenvolvido em contraste com o que foi inicialmente projetado, em conjunto com as suas possibilidades de continuidade, o resultado foi satisfatório no atendimento às necessidades inicialmente levantadas. Conclui-se então que o objetivo de projetar e implementar um sistema de digital signage com gerenciamento e exibição de conteúdo multimídia (propaganda) em displays de vídeo, com controle centralizado e flexibilidade para instalação de novas funcionalidades foi atingido com êxito. 136

140 10. Referencias Bibliográficas BOOCH, G.;RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usuário; São Paulo: Editora Campus, 2000, 14ª reimpressão. Project Management Institute. PMBOK: A guide to the project management body of knowledge, 3rd edition, NewTown Square PA, Estados Unidos, PMI institute. FOROUZAN, Behrouz A. Comunicação de dados e redes de computadores, 3ª edição. Porto Alegre: Bookman PRESSMAN, Roger S. Engenharia de Software, 5ª edição. São Paulo: McGraw- Hill, ROSE, Bill; WILLIAMS, Diane. The OnSpot Digital Advertising Concept in Simon Mall, New York NY: Arbitron, 2004 < Acesso em jun ELEMIDIA, Midia Kit Elemidia, [S.I.] < Acessado em jun SPIEGEL, José Roberto, Mídia digital: Um novo conceito de comunicação no ponto-de-venda. Mundo Marketing, < Acessado em jun SCALA, Retail Digital Signage Models, Platt Retail Institute [S.I.]. < Acessado em jun. 2007; 137

141 ADOBE, Adobe Flash CS3 Professional. < >. Acesso em 15 de maio de PHP PROJECT. PHP Manual. Disponível em < >. Acesso em: jun. de SCALA. What is the maximum length of cable for a DVI and VGA? Disponível em < Acesso em: junho de FFMPEG PROJECT, FFmpeg Documentation. Disponível em < Acesso em: jun. de WIRESPRING TECHNOLOGIES. An introduction to digital signage. Disponível em < Acesso em jul. de PROTOTYPE PROJECT. API Documentation. Disponível em < Acesso em set. de Documentação da API prototype.js. BABAILIICA, Reorder multiple <select> fields in a web page, The Code Project. Versão 1.3, de 7 de novembro de Disponível em < ect= >. Acesso em agosto de KRUSE, Matt. Matt Kruse s Toolbox. Disponível em < Acessado em set Documentação da api de renderização de calendários DHTML calendarpopup.js. CEREJAPRN. Tecnologia IPTV. Disponível em < Acessado em jun. de

142 SOLHEIM, Shelley. The Two Sides of Digital Signage. Disponível em < Acessado em jun. de DEUROMEDIA. Digital Signage. Disponível em < Acessado em jun. de DATAFOLHA. Lembrança de propaganda em monitores de elevadores. Disponível em < Acesso em jun. de Pesquisa DataFolha sobre a efetividade do igital-signage em elevadores. 139

143 11. GLOSSÁRIO AJAX: AJAX (acrônimo em língua inglesa de Asynchronous Javascript And XML) é o uso sistemático de tecnologias providas por navegadores, como Javascript e XML, para tornar páginas mais interativas com o usuário, utilizando-se de solicitações assíncronas de informações. Bitrate: Número de bits por segundo processados num instante na reprodução de um vídeo. Display: Dispositivo de interface visual com o usuário. Um monitor. Downsizing: Downsizing é o processo de diminuir o tamanho, resolução ou bitrate de um vídeo. e-sign player: Aplicativo do terminal que reproduz os vídeos e FlashParts das tarefas a partir de um arquivo de programação e-sign sync: Agente do terminal que monitora o servidor procurando pela programação mais atualizada para o terminal em que está instalado. e-sign server: Aplicativo administrativo do sistema. Permite a edição de tarefas, o upload de vídeos e FlashParts entre outras funções administrativas. FlashParts: Mini-aplicativos desenvolvidos sobre a plataforma Flash que exibem algum tipo de informação e podem ser adicionados como parte do template de uma tarefa. LGPL: A GNU Lesser General Public License (antes conhecida como GNU Library General Public License) é uma licença de software livre que permite aos softwares licensiados ser ligados a programas que não sejam GPL ou LGPL, que podem ser software livre ou Software proprietário. Terminal: Conjunto de dispositivos e softwares que implementam a exibição de vídeos. Um terminal é composto por: CPU Um ou mais displays e-sign player (uma instância para cada display) e-sign sync (uma instância para cada display) 140

144 Tarefa: Uma tarefa define um layout e uma sequência de vídeos para um terminal. A tarefa tem horário de início e fim e pode ser repetida diariamente num período ou semanalmente, em dias específicos da semana. Programação: Conjunto de tarefas de um terminal. O arquivo de programação é um documento XML que especifica a programação, ou seja, a sequência de tarefas, de um determinado terminal. Tela de espera: Tela do terminal em que se apresenta o logo e-sign. Esta tela é apresentada quando não há conteúdo para apresentação nos terminais. Template: Elemento que define um layout para uma tarefa: as dimensões de cada divisão e se o seu conteúdo será vídeo ou uma flashpart. Usuário: Entidade com acesso ao servidor, devidamente cadastrado e autenticado no sistema. XML: extensible Markup Language 141

145 12. APÊNDICE APÊNDICE A Vantagens financeiras do sistema de sinalização digital O retorno de investimento é maior em relação ao modelo tradicional de pôsteres. O custo por pôster (A2) pode ser calculado em média por R$ 100,00 incluindo impressão e fixação no ponto publicitário. O custo de um sistema completo de sinalização digital, incluindo todos os softwares e servidores, gira em torno de R$ ,00 pelo projeto e R$ 5.000,00 por terminal (TV + Computador) com taxa de manutenção de aproximadamente R$ 30,00 por terminal. Simulando um sistema com 2 anos de vida útil, com atualizações semanais de 20 pontos de veiculação já é possível verificar uma redução de mais de R$10.000,00 dos custos com a utilização da sinalização digital. Pôster Custo por ponto de veiculação R$ 100,00 Total R$ ,00 Sinalização digital Custo do projeto R$ ,00 Custo dos equipamentos por terminal R$ 5.000,00 Taxa de manutenção por ponto de veiculação R$ 30,00 Total R$ ,00 Uma outra simulação, realizada para o caso de um sistema com 3 anos de vida útil, com atualização semanal de 100 displays encontra-se uma redução de 63% dos custos. 142

146 Pôster Custo por ponto de veiculação R$ 100,00 Total R$ ,00 Sinalização digital Custo do projeto R$ ,00 Custo dos equipamentos por terminal R$ 5.000,00 Taxa de manutenção por ponto de veiculação R$ 30,00 Total R$ ,00 143

147 APÊNDICE B Modelos de arquiteturas para sinalização digital As arquiteturas de sistemas de sinalização digital encontradas no mercado mundial são muito semelhantes, com pequenas variações quanto ao nível de controle do sistema. Para o gerenciamento de apenas um display, existem softwares que realizam as funções de controle de agendamento dos vídeos a serem exibidos. Eles são instalados em computadores ligados diretamente ao televisor e monitor. Software de controle do terminal Figura 34 - Arquitetura com terminal isolado. A arquitetura mais encontrada é composta pelos displays e pelo servidor gerenciador do conteúdo. O terminal é composto pelo monitor ou televisor conectado diretamente a um hardware de recepção do conteúdo. Existem hardwares específicos para a tarefa de recepção e controle de cada terminal, porém a grande maioria das soluções utiliza desktops comuns. O servidor é um computador com capacidade de processar, armazenar e distribuir o conteúdo para os terminais. A distribuição pode ser feita através dos principais meios de comunicação de dados que comportem uma taxa de transmissão elevada, como transmissão via satélite, redes locais a cabo, redes locais sem fio e internet. A redução dos custos da internet banda larga e de hardwares de rede sem fio estão facilitando a utilização destas tecnologias nas soluções de sinalização digital. 144

148 Figura 35 - Arquitetura cliente-servidor Para situações envolvendo muitos terminais, com configurações e restrições de acesso à rede, existe uma arquitetura na qual cada conjunto de terminais é controlado por um servidor local, enquanto servidores externos realizam o controle de todos os terminais através dos servidores locais. Figura 36 - Arquitetura com servidor externo, servidor local e terminais. 145