1 de 7

Modelagem Arquitetural Voltada a Sistemas de Transmisso de Contedo Multimdia Enriquecido, IDTVS - Interactive Digital TV Show
Anderson Nunes, Valnei Batista
(IFBA, Instituto Federal de Educao Cincia e Tecnologia da Bahia)

Resumo O artigo pretende abordar uma arquitetura escalvel e interopervel para disseminao de contedo multimdia rico atravs da rede. Uma proposta terica ser apresentada a cerca dos estilos e padres arquiteturais alm de componentes, capazes de tornar possvel sua implementao com um nvel aceitvel de confiabilidade.

observar, que a contribuio da soluo proposta projeta possibilidades de futuras integraes com outros sistemas. II. IDTVS - INTERACTIVE DIGITAL TV SHOW Esta seo objetiva apresentar requisitos funcionais e no-

I. INTRODUO Contedo multimdia est presente em diversos meios de comunicao de massa. Tais contedos esto presentes nas mais diversas formas: vdeos, fotos, msica e texto. Atravs da internet isso vem sendo usado como forma de difuso do conhecimento abrindo um leque de oportunidades. As instituies de ensino vm usando a mdia digital como mais um instrumento didtico objetivando disseminar contedo rico por entender ser um facilitador do aprendizado, sem, contudo abrir mo dos mtodos tradicionais de ensino. Nesse contexto a aplicao de novas metodologias de ensino vem na adoo da TV digital um meio eficaz e eficiente de propagar informao. Observando essa tendncia, foi proposta a elaborao de um projeto de sistema cuja finalidade a distribuio de contedo multimdia rico por meio de uma rede local. Assim, os usurios conectados rede sintonizaro um provedor especfico obedecendo a uma grade de programao. Os contedos distribudos podem ser: vdeos streaming, udio, textos, ou objetos IDTVS (coleo de objetos de mdia) responsvel pela adio de dados extra. Sero projetadas 3 vises arquiteturais do projeto, so elas: estrutural, concorrncia e implantao. Sero propostas ainda, possveis padres de projeto adotados, alm da indicao de componentes de mercado presentes na arquitetura e que podem ser viveis sua implementao. importante

funcionais do sistema proposto. Em atendimento aos requisitos funcionais entende-se que: O administrador do sistema deve ser capaz de transmitir vdeos, udio ou textos a seus usurios, armazenar o registro de todos os provedores de servio e usurios conectados, monitorar o

desempenho dos servios, configurar numa grade de programao as mdias sendo exibidas ou a exibir, carregar diversas verses do mesmo contedo diferenciadas por exemplo, pelo codec, indicando os pr-requisitos para a execuo. responsvel tambm, pelo envio de contedo extra, (IDTVS Object) compreendido por uma coleo de objetos de mdia que podem ser textos, imagens, udio, vdeos ou qualquer tipo de objeto complementar ao principal. Ao usurio assinante cabe a responsabilidade em sintonizar um broadcaster disponvel ou conectar-se ao provedor de contedo extra diretamente. Os requisitos no-funcionais melhor descritos nas prximas seces devero atender aos seguintes aspectos: Escalabilidade - A aplicao deve atender a demanda crescente de usurios por entender que a proposta de disseminao usurios. de conhecimento atrair muitos

2 de 7 Interoperabilidade - Face diversidade de ambientes operacionais disponveis no mercado, a proposta deve convergir para uma aplicao flexvel que possibilite a execuo da aplicao em qualquer ambiente. Disponibilidade - Torn-lo em grau de funcionar satisfatoriamente ainda que por um tempo prdeterminado, fundamental para o sucesso da soluo. III. PROJETO ARQUITETURAL A proposta arquitetural para este artigo composta de trs diagramas: Componente/Conector, Concorrncia e Implantao representados na Figura 1. No diagrama Componente/ Conector esto dispostos os principais componentes que faro parte do sistema juntamente com as interaes entre os mesmos que sero realizadas atravs de conectores especficos para cada situao. J no de Concorrncia sero mostrados os principais processos e threads em run-time do sistema. E no de Implantao mostra uma viso dos dispositivos que sero utilizados para executar esta arquitetura proposta. Os principais componentes desta arquitetura so: Event: Conector orientado ao servio de coordenao. O fluxo de mensagem iniciado a partir de um evento, que pode ser ou no respondido pelos componentes interessados [1]. Stream: Disponibiliza o servio de comunicao. capaz de realizar transferncia de grande quantidade de dados e por serem facilmente transmitidos por protocolos de rede a exemplo do TCP.[1] Arbitrator: Resolve conflitos entre processos e redireciona o fluxo de controle. O conector atende a necessidade do sistema em gerenciar concorrncia entre as transmisses.[1] Distributor: Identifica os caminhos de interao e roteamento ao longo da rede. Esse conector envia pacotes em broadcast quanto por multicast[1]. Para maiores detalhes sobre a dimenso e valor dos conectores usados neste artigo ver referncias bibliogrficas.

IDTVS Subscriber
View Subscriber - Tem a funo de exibir o contedo disponibilizado pelo IDTVS Broadcaster, mostrar o contedo extra enviado por um IDTVS Provider especfico, mostrar lista dos IDTVS Providers disponveis. Ordenador de Contedo Extra - Organiza a forma como contedo extra enviado pelo IDTVS Broadcaster ser

A. Componente/Conector Nesta viso busca-se mostrar a integrao entre os componentes e conectores que compem as partes do IDTVS Subscriber, IDTVS Broadcaster, IDTVS Provider. D-se o nome de IDTVS Broadcaster ao transmissor de contedo principal mais contedo extra aos usurios da rede local. J o IDTVS Provider o provedor de contedo principal mais contedo extra ao IDTVS Broadcaster que neste caso funcionar como uma espcie de subscriber deste IDTVS Provider. Alm disto ele pode fornecer contedo extra diretamente aos usurios do IDTVS Subscriber Um componente uma unidade que proporciona a realizao de um conjunto de interfaces que, por sua vez indica os servios providos ou requeridos dentro de seu ambiente. J os conectores realizam transferncia de controle e dados entre componentes. Os conectores apresentados tm as seguintes caractersticas, a saber:[1]

utilizado, sincroniza a exibio dos objetos com o contedo principal apresentado.Organiza o contedo extra enviado

pelos IDTVS Providers independentes.

IDTVS Provider
Configurao de Contedo Extra - Aplicao que configura o envio de contedo extra para os subscribers que desejam receber o contedo extra. DSCM-CC - Ser criada uma implementao da ferramenta para o desenvolvimento de canais de controle associados com fluxos MPEG-1 e MPEG-2. Trabalhar em conjunto com redes de pacotes de ltima gerao, trabalhando ao lado de

3 de 7

4 de 7

protocolos de internet tais como de RSVP , RTSP , RTP e SCP e ser usada para manipular os arquivos de contedo extra adicionados ao fluxo de contedo principal.

Serv. BD - um servio que prover acesso a um SGBD o qual armazenar dados da aplicao que gerencia o IDTVS Broadcaster.

Sistema de Configurao do Contedo - uma aplicao a qual dever implementar features como prover o contedo extra para o IDTVS Broadcaster ou diretamente para os IDTVS Subscribers, receber as imagens geradas por uma webcam e envia-la para ser disseminada pelo IDTVS

J os principais conectores desta arquitetura so:

Fluxo de contedo Multimdia - um conector do tipo Stream com a dimenses definidas em [1], funciona como um facilitador de comunicao entre o IDTVS Broadcaster e o IDTVS Subscriber. Devido a necessidade de transporte de contudo em pacotes dentro de um fluxo de dados se faz necessrio a sua entrega. IDTVS Subscriber TO IDTVS Provider- um conector do tipo procedure call com dimenses remote procedure call, funciona como um facilitador de servio utilizando a invocao de mtodos remotos do provider que recebem assinaturas de subscribers solicitando receberem contedo extra.

Broadaster como contedo principal. Alm de permitir ao operador do sistema configurar os contedos multimdias, a grade de programao do IDTVS Provider por dia e horrios especficos BDServidor - um servio que prover acesso a um SGBD o qual armazenar dados da aplicao que gerencia o IDTVS Provider. Repositrio - Ser um sistema de arquivos que armazenar as mdias a serem exibidas pelo IDTVS. Contedo Ao Vivo(Webcam) - Uma webcam que permitir a exibio de contedo ao vivo via sistema.

Registro Subscriber - um conector do tipo Data Acess com as dimenses definidas em [1], funciona permitindo que o componente do IDTVS Subscriber tenha acesso aos dados

IDTVS Broadcaster
Servidor Broadcaster - Continer que abrigar as aplicaes para e servios necessrios para a transmisso via broadcast Monitoramento dos Providers - Mostra ao operador uma viso geral do consumo de recursos da mquina (CPU, memria, rede, etc), exibe os providers sendo exibidos no momento. Aplicao Broadcaster O operador poder incluir ou

mantidos no componente de Armazenamento BD Server.

Fluxo Contudo - conector do tipo Stream com as dimenses definidas em [1], funciona como facilitador de comunicao entre o componente Repositrio e Sistema de Configurao de Contedo. Sua utilizao justificada pela necessidade do transporte dos pacotes de dados do contedo principal e extra para outros componentes. Protocolo UDP - conector do tipo Event + Distributor com as dimenses especificadas em [1]. Responsvel por transmitir dados referente lista de Providers disponveis ao IDTVS Broadcaster , assim como os contedos que sero transmitidos pelo IDTVS Broadcaster. Para isto ser utilizado o protocolo de rede UDP para realizar a comunicao entre IDTVS Provider e IDTVS Broadcaster. Estilos Arquiteturais Dentro desta arquitetura podemos identificar a utilizao de alguns estilos arquiteturais combinados para atender os

excluir um provider, configurar quem ser exibido aos subscribers , transmite o contedo via Stream.

Transmissor - Realiza a transmisso propriamente dita,

enviando o fluxo de contedo disponibilizado pelo provider selecionado para os subscribers. Recursos SO - Servio que retorna informaes do Sistema Operacional referente a CPU, Memria, Rede etc.

5 de 7

requisitos no funcionais exigidos pelo sistema e j mostrados na seo II deste artigo. O estilo arquitetural Publish-Subscriber pode ser observado quando um subscriber solicita uma lista de providers para que ele possa assinar os seus servios e receber contedo extra do mesmo, temos claramente uma relao que exemplifica a utilizao do mesmo. Podemos perceber tambm esta presena quando um IDTVS Broadcaster funciona como um subscriber e tambm passa receber um contedo principal com contedo extra de um provider especfico. J o estilo cliente-servidor tambm pode ser observado quando analisamos a relao entre a o IDTVS Subscriber e o IDTVS Provider quando o primeiro solicita a lista de Providers disponveis, ou at mesmo quando na etapa onde o Operador da aplicao do lado Broadcaster solicita a incluso de um IDTVS Provider . Um outro estilo arquitetural que pode ser observado o Event-Based na relao do IDTVS Broadcaster com IDTVS Subscriber onde o primeiro envia para uma rede local o contedo que est sendo exibido e o mesmo capturado pelos subscribes que esto sintonizados. B. Concorrncia C. Implantao

6 de 7 PostgreSQL

- Banco de dados gratuito de ampla

documentao ser utilizado no componente {Quais ????}. IV. PROJETO DETALHADO A. Padres de Projeto Para a viabilizao do projeto prope-se o emprego de tcnicas e princpios da P.O.O - Programao Orientada a Objetos. Para os principais componentes subscribers, Providers e Broadcaster ser adotada o padro M.V.C, (Model, View, Controller) pois o modelo isola a "lgica" (A lgica da aplicao) da interface do usurio (Inserir e exibir dados), permitindo desenvolver, editar e testar separadamente cada parte.[2]. A camada model ser implementada no componente {Quais ????} A camada controller {Quais ????} e por fim a view {Quais ????}. Em funo da grande extenso da aplicao muito provvel que venha sofrer inmeras adaptaes; desta forma, busca-se na adoo de padres de projeto reduzir os riscos de implementao. Nesse contexto, todo o projeto foi concebido em princpios de O.O como por exemplo, o princpio do Aberto-Fechado (Open-Closed Principle) e nas tcnicas de padro de projeto da classe interface conforme indicado nos componentes {Quais ????}.Aqui indica-se o padro Facade pois descreve como representar subsistemas inteiros como um nico objeto [3]. J no componente {Quais ????} usa o Bridge pois desacopla uma abstrao de sua implementao para que os dois possam variar independentemente [3]. importante deixar claro que nada impede a adoo de novos padres complementares no desenvolvimento do sistema, mas, o que deve ser seguido a observncia aos princpios que norteiam projetos O.O. B. Componentes A seguir sero descritos os principais componentes que integraram o projeto. RMI (Remote Method Invocation) Utilizada no componente {Quais ????} com esse componente possvel que um objeto ativo em uma mquina virtual Java possa interagir com objetos de outras mquinas virtuais Java, independentemente da localizao dessas mquinas virtuais. [4]. REFERNCIAS
[1] R. N. Taylor, N. Medvidovic, E. M. Dashofy. Software Architecture: Foundations, Theory, and Practice. Wiley, 2009.

JSF (Java Server Faces) - Framework que simplifica o desenvolvimento de interfaces web. As GUIs tambm devero usar primefaces. Por exemplo, {Quais ????}. Spring Implementado no broadcaster esse

framework permitir configurao atravs de XML os {Quais ????}. Maven Ferramenta de auxilio ao projeto no que diz respeito ao seu gerenciamento. Assim, possvel a configurao de ambiente de desenvolvimento

padronizado seguindo boas prticas. {Quais ????}. Vlcj Framework base para envio e recebimento de pacotes streamings na rede. Hibernate Usado para mapear objetos relacionais no servidor Broadcaster visando diminuir a

complexidade no desenvolvimento de consultas e atualizao em bando de dados. JRE 7 (Java Runtime Environment)- Usado para execuo de aplicaes desenvolvidas em Java permitindo operacionais.
V. CONCLUSO

seu

uso

em

diversos

sistemas

O projeto pretende desenvolver uma soluo capaz de transmitir e receber contedo rico atravs da rede local. Nesse sentido, no desenvolvimento da soluo, foram exploradas tcnicas conhecidas de mercado e que

demonstram ser capazes de torn-lo flexvel e por assim vivel. Muito embora deva-se pontuar que, para o sucesso de sua implantao altura de suas expectativas de fundamental importncia uma infra-estrutura de rede adequada, bem como estruturar uma equipe de

desenvolvimento acompanhada de um bom modelo de construo de software para atender a requisitos de prazo.

7 de 7
[2] http://pt.wikipedia.org/wiki/MVC. Em 10/05/2012, 10:20h. [3] Erich Gamma et al. Design Patterns: Elements of Reusable Object-oriented Software. Addison-Wesley, 1995 [4] http://pt.wikipedia.org/wiki/RMI