Collaborative Edition Support of Interactive Digital TV Programs Suporte à Edição Colaborativa de Documentos Interativos para TV Digital

Lucas Augusto Scotta Merlo1 PPGI UFES

Vitória, ES, Brasil scotta@inf.ufes.br

Fernando Antonio Marques Filho DI

UFES Vitória, ES, Brasil

fernando.marquesfilho@gmail.com

Roberta Lima Gomes1,2 PPGI UFES

Vitória, ES, Brasil rgomes@inf.ufes.br

Abstract - Due to the multiprogramming support and to the creation of new TV channels, the Brazilian Digital Television System will allow the strengthening of several actors such as community stations, as well as independent content producers. Expecting the establishment of a collaborative network between these actors, it is important to support the collaborative development of interactive content for Digital TV. In order to provide this support, this paper proposes a collaborative environment for the development and edition of NCL documents, NCL being the declarative language adopted by Brazilian Digital TV middleware. This paper focus on the definition of concurrency control and consistency mechanisms to be applied in such collaborative edition environment, considering the specific features related to the NCL language.

CSCW, Collaborative Editors, Ginga-NCL, Groupware, Digital TV.

Resumo — Com o suporte à multiprogramação e a previsão de criação de novos canais, a TV Digital permitirá o fortalecimento de vários atores como emissoras comunitárias, assim como produtores independentes. Prevendo-se um modelo de redes colaborativas entre esses atores, torna-se importante que o desenvolvimento de conteúdo interativo para TV Digital possa ser executado de forma colaborativa. Tendo em vista atender a essa necessidade, este artigo propõe um ambiente colaborativo para o desenvolvimento e a edição de documentos NCL, linguagem declarativa adotada pelo middleware do Sistema Brasileiro de TV Digital. O foco desta proposta é a definição de mecanismos de controle de concorrência e consistência considerando-se as características específicas da linguagem NCL.

CSCW, Editores Colaborativos, Ginga-NCL, Groupware, TV Digital.

1 Beneficiário de auxílio financeiro da CAPES –

Brasil (RH-TVD #225/2008) 2 Trabalho parcialmente financiado pelos projetos

FAPES/MCT/CNPq/ CT-INFRA #36316008/2007, FAPES/Universal #38874849, e RNP/MCT/CTIC .

I. INTRODUÇÃO

TV Digital é uma tecnologia que, além de possibilitar maiores qualidades de áudio e vídeo nas transmissões, também traz todo um novo paradigma à televisão com a adição da interatividade. No caso do Sistema Brasileiro de Televisão Digital [1], foi escolhido o middleware Ginga [1], que é resultado de projetos de pesquisa coordenados pelos laboratórios Telemídia da PUC-Rio e LAViD da UFPB. O Ginga tem a responsabilidade de fazer com que os produtores de conteúdo interativo tenham uma visão única de aparelho sem precisar se preocupar com os diversos tipos desses que podem executar esses conteúdos.

Com a implantação da TV Digital novos cenários surgem. Dependendo no nível de interatividade programada e do tipo de canal de interatividade (canal de retorno), o telespectador pode acessar diferentes tipos de aplicações e até mesmo torna-se um autor de conteúdo, compartilhando este conteúdo com outros usuários [14].

Além de permitir que a audiência participe da produção de conteúdos, com a possibilidade de se definir mais canais através do suporte à multiprogramação (transmissão de até quatro programações diferentes no mesmo canal), e com a previsão de criação de quatro novos canais Estatais, a TV Digital permitirá um fortalecimento de atores como emissoras comunitárias e regionais, assim como produtores independentes. Vários esforços vêm sendo empreendidos pelo governo no sentido de pautar os critérios que nortearão o estímulo à produção de conteúdos digitais. De acordo com [27] “isso [os esforços desprendidos pelo governo] significa estimular a produção e o desenvolvimento de projetos de conteúdos audiovisuais digitais por diferentes atores sociais, como a academia, os produtores independentes, pequenas empresas, institutos de pesquisa e desenvolvimento e terceiro setor, de forma colaborativa, livre e democrática“. Portanto, a Televisão Digital vem ao encontro de políticas públicas que buscam implantar uma infraestrutura de comunicação no país para viabilizar as chamadas redes horizontais de colaboração [15].

2009 Simpósio Brasileiro de Sistemas Colaborativos

978-0-7695-3918-8/09 $29.00 © 2009 IEEE

DOI 10.1109/SBSC.2009.23

106

Sabe-se que ferramentas para autoria prestam um grande auxílio ao desenvolvedor, pois além de reduzir o tempo de criação e desenvolvimento, torna a aplicação mais confiável e muitas vezes abstraem conceitos da linguagem facilitando o desenvolvimento. Para o modelo de TV Digital Brasileira, isto não é diferente. No caso do Ginga, uma das linguagens usadas para a produção de programas interativos é o NCL. Existem alguns editores gráficos e textuais para o suporte a autoria desse tipo de documento. Mas vale ressaltar que nenhum deles fornece suporte para que a produção seja realizada colaborativamente. Prevendo-se um modelo de redes colaborativas como o horizonte natural da TV Digital brasileira, o suporte ao desenvolvimento de conteúdo interativo deve, portanto, permitir que essa atividade seja executada de forma colaborativa. Desta forma, no contexto da TV Digital, a possibilidade de desenvolvimento colaborativo de conteúdo permitirá que um grupo de produtores (separados ou não geograficamente) trabalhe na etapa de produção e pós-produção, na criação de programas interativos de forma concorrente.

Observa-se, portanto a importância de haver ferramentas que forneçam suporte à edição colaborativa de documentos NCL, neste novo cenário que surge com a implantação do SBTVD. Tendo em vista atender a essa necessidade, este artigo propõe um ambiente colaborativo para o desenvolvimento e a edição de documentos NCL. O foco desta proposta é a definição de mecanismos específicos de controle de concorrência e consistência considerando-se as características específicas de documentos NCL.

Esse artigo está estruturado da seguinte forma. A Seção 2 apresenta os trabalhos relacionados e a contextualização sobre o tema. A Seção 3 descreve uma conceituação a respeito de NCL. A Seção 4 apresenta os mecanismos de controle de concorrência e uma proposta híbrida para a realização deste controle em um editor colaborativo síncrono de documentos NCL. A Seção 5 apresenta a arquitetura e o desenvolvimento de um editor colaborativo NCL. E finalizando, a Seção 6 conclui este artigo e apresenta algumas perspectivas de trabalhos futuros.

II. TRABALHOS RELACIONADOS

A. Editores Colaborativos Groupwares são sistemas apoiados por computador que

suportam grupos de usuários engajados numa mesma tarefa (ou objetivo) e que proveem uma interface para um ambiente compartilhado [2]. Editores colaborativos, também conhecidos como sistemas de co-autoria, representam uma classe importante desses.

Os editores colaborativos são ferramentas que apoiam o trabalho de elaboração de documentos em grupo, oferecendo principalmente, uma área comum, compartilhada pelos diversos autores, para a elaboração dos seus trabalhos, podendo ser gráficos ou textuais, além de poderem ser

síncronos ou assíncronos. Na abordagem síncrona as alterações são realizadas em tempo real e as cópias devem estar sincronizadas a todo tempo. Por outro lado na abordagem assíncrona o usuário pode possuir uma cópia desatualizada do documento compartilhado e trabalhar de forma individual, integrando posteriormente as alterações realizadas.

Além dos requisitos gerais comumente associados aos groupwares, referentes aos aspectos gerais de comunicação, coordenação, e cooperação apresentados no Modelo 3C [4] [2], editores colaborativos devem também resolver questões específicas deste tipo de sistema. Como normalmente esses sistemas permitem a edição em grupo de objetos que se encontram em um espaço compartilhado, existe uma preocupação especial com relação aos mecanismos de controle de concorrência e o gerenciamento de problemas genéricos de inconsistência: divergência, violação de causalidade e, violação de intenção [3]. Efetivamente, em [5] discute-se que a parte mais crítica nesses sistemas são os mecanismos para manter consistência dos dados compartilhados, já que devido às operações concorrentes, inconsistências podem ocorrer, e, portanto, o controle de concorrência é a chave para o correto funcionamento de sistemas de groupware. Por exemplo, suponha que dois usuários realizem duas modificações simultâneas, as quais deveriam ser executadas de forma incremental sobre um objeto compartilhado. Sem um mecanismo de controle, essas modificações poderiam ter sido executadas em ordem invertida no cliente de cada usuário, o que poderia causar visões distintas do espaço de trabalho compartilhado. Isso comprometeria diretamente a cooperação, podendo também ter implicações sobre a coordenação - se o estado atual do objeto determinasse o estado da tarefa, um usuário poderia concluir que a mesma foi finalizada, enquanto o outro poderia entender que não, tentando continuar o trabalho.

Mecanismos de controle de concorrência devem, portanto, ser aplicados tanto a editores síncronos quanto assíncronos. O uso da concorrência em editores síncronos apresenta muitos desafios, dado que o controle de concorrência deve ser aplicado em tempo de execução, com impactos diretos sobre os tempos de resposta do sistema.

Em [2] são discutidas algumas questões sobre groupware, como o merge da tecnologia de computadores e a comunicação que está sendo usada em diversos sistemas. Exploram-se problemas técnicos com relação ao projeto e ao desenvolvimento destes tipos de sistema, mostrando como groupware pode auxiliá-los. Mais detalhes podem ser encontrados em [2].

A ferramenta proposta GROVE (GRoup Outline Viewing Editor) apresenta uma implementação dos conceitos apresentados comprovando o auxílio discutido no artigo de [2]. Tal ferramenta é um editor de textos síncronos projetado para ser utilizado por um grupo de usuários para a edição de outline (tabela de conteúdo). Cada usuário pode ler e editar

107

livremente qualquer parte do documento, já que não há mecanismos de lock (mecanismo que assegura acesso exclusivo ao fragmento solicitado). Cada usuário possui uma réplica do documento. As alterações são imediatamente executadas localmente e sincronizadas com as outras cópias, através de um algoritmo automático de OT (OPeration Transformation, em que operações são realizadas para manter a integridade do texto), o dOPT (Distributed Operational Tranformation).

SASSE [20] e CALLIOPE [19] são exemplos de editores que se baseiam no uso de locks para controlar o acesso concorrente aos documentos. Locks podem ser aplicados em diferentes granularidades, onde quanto mais fina a granularidade, maior o nível de concorrência e mais complexo o mecanismo de controle. No caso do SASSE, os locks são realizados no que o usuário selecionar do texto , enquanto o CALLIOPE permite ao usuário usar ou não o lock com a granularidade do Sasse. Além das características apresentadas pelo GROVE, como controle de consistência e controle de sessão, esses dois sistemas também oferecem suporte a awareness (percepção da atividade colaborativa, como discutido em [28]): no primeiro caso são oferecidas funcionalidades como coloração textual, barra de rolagem multiusuário e dois tipos de visão; enquanto no segundo caso, além de coloração textual, possui telepointers (auxilia a saber onde os usuários estão editando) e scrollbars compartilhada. Editores colaborativos podem ser de propósito geral, como os citados anteriormente, ou para a autoria de documentos de textos aplicados a domínios específicos, como a ferramenta CoEdit [12] que permite a edição síncrona de modelos de Engenharia de Software. No trabalho de [21] é proposto um editor colaborativo síncrono para UML baseado na ferramenta de edição de diagramas UML, ArgoUML utilizando locks implícitos como controle de concorrência.

No caso da TV Digital, temos um domínio diferente quando se trata de editores compartilhados, pois, além dos requisitos comumente usados, aspectos específicos das linguagens de criação de conteúdo para TV Digital devem ser considerados, já que cada Sistema de TV Digital oferece seu próprio conjunto de formatos e linguagem. Na subseção a seguir serão apresentados alguns aspectos específicos dos editores aplicados a esse domínio, focando-se no Ginga-NCL.

B. Edição de Documentos Interativos para TV Digital O middleware brasileiro Ginga suporta tanto aplicações

declarativas como procedurais. A parte declarativa é definida pelo Ginga-NCL, que é um subsistema do Ginga para exibição de documentos NCL. Já o subsistema Ginga-J [7] deverá prover uma infraestrutura de execução e aplicações JAVA. Porém, apenas o Ginga-NCL foi formalmente especificado e disponibilizado para testes até a presente data.

Com relação à autoria e edição de documentos interativos NCL, algumas ferramentas já foram desenvolvidas e disponibilizadas. Uma das ferramentas mais importantes é o Composer [8] que se trata de um ambiente gráfico que faz uso de visões com principal objetivo de facilitar a edição de programas interativos por usuários que não sejam especialistas na linguagem NCL.

Outra ferramenta é o plugin NCL Eclipse [9] que auxilia o desenvolvedor na criação de aplicativos utilizando a IDE (Integrated Development Environment) Eclipse. Na sua versão atual 1.0.0, apesar de não possuir uma visão gráfica, possui características interessantes como: ser multi-plataforma, auto-completação contextual de código, validação do documento NCL.

GingaWay [10] é uma extensão criada para Eclipse que representa a reunião de ferramentas NCL e Lua de forma integrada em um mesmo ambiente. Gingaway utiliza como base duas extensões já existentes: o NCL Eclipse e o Lua Eclipse. Suas principais características são: editor de arquivo NCL e Lua, execução integrada de aplicações Ginga-NCL e marcadores de problemas.

Devido ao fato de o SBTVD ser recente, ainda não foram disponibilizadas ferramentas comerciais. E quanto às soluções acadêmicas apresentadas aqui, nenhuma delas oferece apoio à criação colaborativa de documentos NCL. No entanto, algumas soluções de suporte à autoria colaborativa para linguagens adotadas por outros middlewares de TV Digital podem ser encontradas na literatura.

Um exemplo de linguagem é o SMIL (Synchronized Multimedia Integration Language) [22], adotada pelo middleware LASeR [23]. Em [26] é proposto um ambiente de autoria colaborativa que usa a visualização e os serviços de autoria da ferramenta LORNAV, trabalhando no formato SMIL 2.0. Nesta ferramenta o processo global de autoria também é reforçado com a adição de moderação e serviços de áudio e vídeo-conferência multiponto-a-multiponto. Em [11] é proposto um sistema de autoria colaborativa para apresentação multimídia SMIL que, por utilizar uma interface 3D espaço-temporal, ganha muitos benefícios, como representar intuitivamente a apresentação multimídia de um ambiente sem descontinuidades. Foram implementadas algumas ideias eficientes para o controle de concorrência baseadas na percepção do usuário (awareness), múltiplas versões, granularidade fina de lock, e permissões de acesso a objetos compartilhados.

O padrão Americano e Europeu para TV digital utiliza a linguagem XHTML, sendo que já existem ferramentas para edição colaborativa XML (Syntext Serna, Topologi Collaborative Markup Editor e Captio (para dispositivos móveis)). Apesar de o NCL ser baseado no XML, a autoria colaborativa não seria adequada em editores dessa

108

linguagem, já que o NCL apresenta algumas características específicas tais como as inter-relações entre diferentes elementos (tags), necessitando assim de mecanismos de controle mais elaborados para garantir a consistência do documento compartilhado.

Para uma melhor compreensão da estrutura do NCL e suas particularidades a próxima seção ressalta os relacionamentos existentes entre os diferentes tipos de elementos.

III. ESTRUTURA DE DOCUMENTOS NCL NCL ou Nested Context Language é uma linguagem

declarativa adotada pelo middleware Ginga. É baseado em XML e, portanto, herda todas as características existentes nele como, por exemplo, o fato de possuir uma abordagem modular [6].

O XML (eXtensible Markup Language) é uma linguagem de marcação de dados que provê um formato para descrever dados estruturados. O documento XML é formado por unidades de armazenamento conhecidas como entidades [16], facilitando declarações mais precisas do conteúdo e os resultados mais significativos de busca através de múltiplas plataformas. Um documento XML é uma árvore rotulada (tags), onde temos o nó raiz, seus filhos e "sub-filhos", recursivamente. NCM, ou Nested Context Model, é o modelo que define o NCL. Apesar de o NCL não implementar todos os componentes existentes no NCM, o entendimento deste modelo é importante para a compreensão dos elementos NCL. O foco principal do NCM é a representação e o tratamento de documentos hipermídia, e como um modelo para hipermídia este deve apresentar conceitos estruturados de dados, além dos eventos e relacionamentos entre os dados e as regras e operações usados para manipular e atualizar seus elementos.

A definição de documentos no NCM é baseada nos conceitos usuais de nós (ou elementos) e elos. Nós (nodes) são fragmentos de informação, e elos (links) são usados para a definição de relacionamentos entre os nós. Os nós podem ser de conteúdo ou de composição, sendo os de composição o ponto central do NCM [27].

A. Componentes Uma característica importante para linguagens de autoria

declarativa é a capacidade de oferecer grande poder de expressão mantendo o código simples. Simplicidade, flexibilidade e poder de expressão foram alvos para a definição da linguagem NCL [18] e é exatamente por estas características que os elementos NCL são simples. No geral os elementos mais simples podem conter entre 1 a 3 linhas. Alguns elementos mais complexos possuem diversos sub-elementos a eles relacionados e, assim, possuem mais linhas de código.

B. Relacionamentos entre elementos NCL Elementos NCL podem se relacionar com outros

elementos de duas formas principais: através de agrupamento ou com outros nós usando o ID (identificador único) do nó alvo como forma de relação. Os relacionamentos por agrupamento são aqueles herdados da linguagem XML. É a relação de elementos e sub-elementos citados anteriormente. Essa forma de relação é usada no NCL para adicionar características a nós existentes.

Os relacionamentos com relação a ID são normalmente utilizados para a sincronização temporal e espacial do documento. Este tipo de relacionamento faz com que elementos que não estejam encadeados (relacionamento por agrupamento) tenham algum impacto sobre os elementos aos quais são associados, ou ainda, apresentem alguma dependência destes elementos. Desta forma, é necessário um controle mais sofisticado ao tratar esses relacionamentos a fim de garantir a consistência do documento NCL. Um exemplo desse relacionamento são os nós <media> e <descriptor>, como se pode visualizar na figura 1. Para um melhor entendimento, faz-se necessária a rápida explicação de algumas tags.

Figura 1. Exemplo de documento NCL

A tag <region> informa onde será apresentado o vídeo, a tag <descriptor> é responsável por realizar a cola entre o descritor e a região. E por usarem o mesmo <descriptor>, ambos são exibidos na mesma região da tela. A tag <connectorBase> é responsável por controlar a base de conectores que ligam dois ou mais elementos. A tag <port> indica a porta de início do vídeo. As tags <media> indicam as mídias usadas e seu respectivo descritor.

Voltando aos relacionamentos, o nó <media> através do ID do descritor que será usado “dVideo” informa quais são as características de exibição da mídia em questão, ou seja, a modificação de um <descriptor> tem impacto direto na

109

forma como o <media> será exibido. Quando o primeiro vídeo termina, outro inicia na sequência, como descrito na tag <link>.

IV. CONTROLE DE CONCORRÊNCIA PARA EDIÇÃO COLABORATIVA SÍNCRONA DE DOCUMENTOS NCL

Devido às particularidades associadas aos relacionamentos dos nós NCL, o uso de editores XML colaborativos existentes não garantiria de forma satisfatória a consistência das propriedades deste tipo de documento. O objetivo deste trabalho é, portanto, propor uma estratégia de controle de concorrência que possa ser utilizada no desenvolvimento de um editor síncrono de documentos NCL. O foco se dá em abordagens síncronas de edição visto que os relacionamentos específicos dos documentos NCL podem apresentar um maior impacto no controle da consistência neste tipo de cenário, onde aspectos de distribuição e tempos de resposta também devem ser considerados.

A. Proposta de um Mecanismo Híbrido de Controle de Concorrência Naturalmente a busca pelo melhor mecanismo de

controle de concorrência depende da semântica do sistema colaborativo [11]. Um dos principais compromissos que deve ser levado em consideração ao se criar um software de edição colaborativa é a relação entre usabilidade e consistência dos dados. Por um lado pode-se proibir o usuário de realizar modificações em partes específicas do documento, por exemplo, através da abordagem pessimista usando locks. Mas isso implicaria impedir que o usuário realize a alteração desejada. Já se a abordagem otimista for utilizada, pode-se garantir uma maior usabilidade, mas a aplicação estará mais susceptível a apresentar inconsistências no documento compartilhado.

Para o desenvolvimento de uma solução específica, como já dito anteriormente, é necessário o conhecimento das restrições inerentes à aplicação, sejam elas devido à linguagem ou estrutura do documento compartilhado, seja devido à arquitetura de distribuição do sistema de edição. Algo importante a ser frisado é a velocidade com que novos nós de um documento NCL podem ser criados, ou nós existentes podem ser editados. A edição pode se tornar ainda mais rápida se ela for suportada por ferramentas ou plugins que auxiliem neste processo (por exemplo, o auto-complete contextual da ferramenta NCL Eclipse). Outra consideração importante refere-se ao fato de o ambiente ser distribuído, o que impõe restrições críticas quanto à sincronização dos eventos, ficando este limitado aos tempos de atraso de rede.

A solução proposta neste trabalho envolve inicialmente o uso da técnica de OT, que também é usado por GROVE[2], para resolver os três problemas genéricos de inconsistência [3] [5]: divergência - cópias finais não semelhantes ao final da execução das operações; violação de causalidade -

execução fora de ordem das operações; violação de intenção - a execução de operações pode alterar a real intenção do usuário. Porém, apenas o uso do OT como sugerido não garante a resolução do contexto específico, que neste caso é a linguagem NCL, e assim é necessário o uso de um mecanismo complementar.

O uso de mecanismos de lock torna a solução mais robusta, uma vez que permite a um usuário ter acesso exclusivo a algumas partes do documento, evitando-se que alguma inconsistência seja gerada por outro usuário. Por outro lado, o uso em excesso do mecanismo de lock pode comprometer a usabilidade. Por este motivo o uso ou não dos mecanismos de lock e os níveis de granularidade devem ser cautelosamente considerados. Em particular, a questão da granularidade, quando oferecida em diferentes níveis, permite uma maior concorrência nas ações de edição, mas aumenta também o overhead de gerência do sistema [13].

Inicialmente foi discutido o uso de lock implícito, adotado pelo já citado ArgoUML [21], e, desta forma, quando um usuário começasse a edição ou criação de um novo nó este seria automaticamente bloqueado, enquanto o mesmo ocorreria para outros nós que estivessem relacionados a este através de IDs. Por exemplo, a edição do nó “video1” da figura 1 apresentada anteriormente implicaria o lock automático dos nós “dVideo” e “rgVideo”. Todavia, a edição de um elemento NCL ocorre geralmente de forma muito rápida, na qual em menos (ou muito menos) de um minuto pode-se criar um elemento NCL, ou em alguns segundos pode-se modificar um elemento existente. Desta forma o processo de obter o lock e removê-lo ocorreria em pouco tempo, gerando um grande overhead desnecessário no ambiente. Agravando este cenário tem-se a questão dos atrasos da rede que, proporcionalmente, poderiam ser impactantes durante o processo de sincronização dos eventos para implantar o lock. Com isso, o mecanismo de lock implícito foi descartado.

Apesar de o lock implícito não ser adequado para esta solução, o lock explícito (quando o usuário o solicita), similarmente ao implementado por SASSE [20] e CALLIOPE [19], representa uma opção a ser analisada. Esse tipo de lock pode aparecer de duas formas distintas: (i) reativo, onde o sistema apenas realiza o lock caso o usuário através de alguma funcionalidade do sistema explicite que deseja realizar o lock em um nó do documento; (ii) pró-ativo, um mecanismo de inteligência no ambiente faz perguntas ao usuário sempre que julgar importante a implantação do lock. Apesar da segunda solução auxiliar o usuário nas decisões de usar ou não o lock, ele teria que ficar respondendo a perguntas do ambiente enquanto edita o documento, o que poderia provocar desconforto ou até mesmo diminuir seu desempenho. Por outro, lado no lock reativo, o usuário deve ter conhecimento de quando um lock se faz necessário; e, mais ainda, quais elementos devem receber o lock – só o que está sendo editado ou também outros elementos relacionados.

110

A solução aqui proposta suporta o mecanismo de lock reativo. No entanto, a fim de livrar o usuário da responsabilidade de decidir quais elementos são implicados ao se aplicar o lock, o sistema se encarrega de aplicá-lo aos elementos relacionados ao nó selecionado. Além disso, outro fator muito importante ao se fazer uso de locks é a definição da granularidade. Nesta proposta, essa tarefa também é atribuída ao sistema, que deverá executá-la em função das características específicas do NCL. Por exemplo, muitas vezes basta que os identificadores únicos dos elementos não sejam alterados.

Aliado aos sistemas de lock podem-se usar mecanismos de awareness com o intuito de permitir que os autores do documento tenham a percepção de quem está editando qual parte do código, de forma a melhorar a coordenação do grupo como um todo, SASSE [20] e CALLIOPE [19] são ótimos exemplos de como o awareness pode auxiliar na edição colaborativa. Além disso, é importante que esses mecanismos também permitam a visualização de quais elementos estão relacionados com o que cada co-autor está trabalhando. Essa característica pode auxiliar um usuário na decisão de aplicar ou não um lock. Por exemplo, novamente considerando a figura 1, um usuário A editando o elemento media “video1” visualiza através deste mecanismo de awareness que o elemento <descriptor> “dVideo” está relacionado à <media> sendo editada e que um usuário B está neste momento editando este <descriptor>. Em resposta, o usuário A pode requisitar um lock sobre o elemento “video1” e os demais elementos relacionados. Este cenário evidencia a possibilidade da ocorrência de conflitos. Por exemplo, qual usuário terá a prioridade sobre a edição? Essas questões e mais detalhes dos algoritmos utilizados neste trabalho serão apresentados nas subseções a seguir.

B. Definição dos Algoritmos Nessa seção descreveremos os algoritmos escolhidos

para o controle de concorrência e consistência de nosso sistema. Para o controle de consistência optou-se por adotar o treeOpt [5] por ser mais próximo da solução para o problema apresentado. Já para o controle de concorrência, no nosso caso lock, foi adaptado o algoritmo Dynamic Locking Protocol – DLP [24] e proposto um gerenciador de conflitos genérico NCL.

1) treeOpt O algoritmo treeOpt (tree OPerational Transformation)

[5] representa os documentos em forma de árvore, aplicando-se mecanismos de transformação operacional recursivamente sobre os diferentes níveis do documento. Com este algoritmo consegue-se atingir uma melhor eficiência, além da possibilidade de trabalhar em diferentes níveis de granularidade e obter melhorias na coerência semântica.

Baseia-se em transformação operacional e na “modelagem” do documento utilizando uma estrutura hierárquica e não linear. Desta forma, evitam-se problemas

como o alto custo para operações no histórico de alterações, já que na estruturação linear acaba-se tendo um histórico longo, o que demanda uma alta complexidade de transformação operacional. Mantendo o histórico distribuído pela árvore, quando há uma operação a ser transformada, apenas aquele caminho é varrido e não o histórico como um todo, reduzindo-se a complexidade. A complexidade afeta negativamente o tempo de resposta, que é um fator de crucial importância em sistemas de edição em tempo real [5]. No caso específico dos documentos NCL, a hierarquia está bem definida pela própria estrutura XML.

Cada site armazena uma cópia local da estrutura hierárquica do documento compartilhado. Cada nó (excluindo os nós folhas) mantém um histórico de operações de inserções e deleções associadas com os nós filhos. Cada site pode gerar operações de composição, representando inserções ou deleções de sub-árvores de um documento. Cada nó de uma sub-árvore, ao ser inserida, contém este histórico (History Buffer – HB) vazio. Ao se gerar a operação de composição, a mesma é executada no site imediatamente. A operação é então gravada no HB associando seus nós pai de inserção ou deleção. Finalmente a nova operação é enviada para todos os outros sites, e marcada no vetor de estados. Após receber uma operação remota, o site receptor irá testá-la para ver se é causally ready (quando uma operação pode alterar outra). Se a operação não é causally ready, ela será colocada na fila, caso contrário, ela será transformada e então executada.

Portanto, a operação remota deve ser transformada em cima das operações anteriores, as quais estão mantidas no HB. Isto pode ser feito usando qualquer algoritmo de transformações operacionais existentes usados em documentos estruturados linearmente, como os algoritmos GOT(O) ou SOCT2.

2) Lock Explícito Esta proposta utiliza como base a ideia do mecanismo de

lock explícito denominado Dynamic Locking Protocol (DLP), proposto em [24]. Em locks explícitos, lock e unlock são requisitados pelo usuário antes e depois da operação de edição. No entanto, na abordagem do GroupKit [24] para se editar um elemento o mesmo deve ser necessariamente bloqueado.

Neste trabalho, ao contrário, o lock é opcional. Além disso, o mecanismo auxilia o usuário permitindo que o mesmo opte ou não por bloquear, não só o elemento escolhido, mas também as dependências associadas a este elemento. A última adaptação realizada sobre o DLP é a definição de um Centralizador para o controle de conflitos. O Centralizador tem um papel importante dado que os locks, nesta proposta, podem apresentar dois níveis de granularidade, partindo do nível de um elemento NCL, chegando ao nível de um atributo ID. Aumenta-se, portanto, a complexidade na gerência dos conflitos e um Centralizador neste caso viabiliza esta gerência de forma mais controlada.

111

Com o objetivo de adaptar o DLP às particularidades do NCL e a definição de um Centralizador, foi criado o Protocolo de Gerenciamento de Conflitos Genérico NCL. Nesta proposta existem dois tipos de lock, o Lock Completo, que proíbe a alteração de qualquer atributo do elemento alvo, e o Lock por ID, que somente proíbe que o atributo ID do elemento alvo seja modificado, neste caso até mesmo por quem pediu o lock. Esta granularidade mais fina no lock deve-se ao fato de que o atributo ID define algumas relações de dependência entre elementos. Em algumas situações, ao se editar um elemento, inconsistências ocorreriam apenas se os IDs dos outros elementos com os quais ele se relaciona fossem modificados. Por exemplo, voltando à figura 1, o usuário que está editando o <link> poderia solicitar o lock para este elemento (e todas suas dependências) para garantir que ele continue referenciando elementos existentes. Ao se bloquear apenas os IDs, este último requisito é garantido ao mesmo tempo em que a colaboração não é impedida (outros usuários podem editar esses elementos apenas ficando restritos a não alterar seus IDs).

Em a) e b) é detalhado o protocolo para os dois tipos de Lock.

a) Quando um Lock Completo é solicitado: 1. O lock é requisitado ao Centralizador:

(a) Caso já exista outra solicitação pendente para este elemento, o lock é negado;

(b) Caso já exista lock neste elemento, o lock é negado;

(c) Caso exista outro usuário editando o elemento, o lock é negado;

(d) Caso contrário, o lock é aceito; i. Caso o usuário já possua lock de outro

elemento, não relacionado ao já pedido, todos os locks anteriores são liberados.

2. Quando uma confirmação de lock for recebida: (a) O lock em questão é adicionado à lista local

de locks. 3. Quando um usuário tentar editar qualquer

elemento: (a) A lista de locks locais é verificada. Caso

exista um lock no elemento, e ele pertença a outro usuário, a alteração é negada.

b) Quando um Lock por ID é solicitado: 1. O lock é requisitado ao Centralizador:

(a) Caso já exista outra solicitação pendente para este elemento, o pedido é ignorado;

(b) Caso já exista lock neste elemento, o pedido é ignorado;

(c) Caso exista outro usuário editando o elemento, o lock é aceito;

(d) Caso contrário, o lock também é aceito; 2. Quando uma confirmação de lock for recebida:

(a) O lock em questão é adicionado à lista local

de locks. 3. Quando um usuário tentar editar qualquer

elemento: (a) A lista de locks locais é verificada. Caso

exista um lock no elemento, e ele pertença a outro usuário, qualquer alteração no atributo ID é negada.

Vale ressaltar que a execução desse protocolo deve se

apoiar em mecanismos de awareness de forma a contextualizar o usuário em todos os passos citados, permitindo, por exemplo, que o mesmo saiba por que um lock solicitado não foi obtido.

Uma questão importante a ser considerada é o timeout, com intuito de evitar deadlock e permitir a colaboração. Dos diversos cenários analisados conclui-se que os seguintes procedimentos devem ser realizados: (i) Se um usuário for desconectado do sistema todos os locks por ele solicitados serão liberados. (ii) Se o usuário ficar inativo por um determinado período uma mensagem é disparada. Caso a mensagem não seja respondida, o usuário perde os locks que possui.

V. DESENVOLVIMENTO DE UM EDITOR COLABORATIVO DE NCL

Uma vez definidos os mecanismos de controle de concorrência que possam suportar de forma mais adequada à edição colaborativa de documentos NCL, este trabalho propõe o desenvolvimento de um editor colaborativo baseado nos mecanismos especificados.

A. Arquitetura Distribuída de um Editor Colaborativo Dentre as principais arquiteturas de distribuição aplicadas

a sistemas colaborativos destacam-se as abordagens cliente-servidor e P2P. Com o cliente-servidor há uma centralização do controle, o que torna a sincronização do documento e a gerência do controle de concorrência tarefas mais simples. Mas, ter um servidor requer configuração e manutenção, além de representar um “elo fraco” (se o servidor sai do ar, a aplicação torna-se indisponível). Já em uma abordagem P2P a sincronização e o controle são realizados de forma distribuída, e os nós da rede podem desempenhar funções de cliente e de servidor. Desta forma, esta última abordagem torna o sistema mais robusto (não apresenta um ponto único de falha) e mais escalável (não há gargalo para crescimento). No entanto, não havendo uma centralização do controle, a coordenação e a sincronização podem se tornar tarefas complicadas.

Desta forma, para esta proposta é sugerida uma arquitetura híbrida, na qual a sincronização e a distribuição dos eventos para a implementação do algoritmo de OT são

112

realizadas segundo a abordagem P2P. Com isso, as resoluções de conflito via OT são feitas localmente por cada peer seguindo a proposta de [2]. No entanto, o controle dos mecanismos de lock deve ser realizado de forma centralizada por um dos peers da sessão (aquele que cria a seção, podendo este delegar dinamicamente as resoluções de lock para outro peer).

B. Co-NCL Após estudos realizados sobre a viabilidade de adaptação

e utilização para um editor colaborativo NCL, pensou-se no desenvolvimento da ferramenta Co-NCL a partir de um editor existente, integrando funcionalidades de colaboração baseadas nas propostas apresentadas de controle de concorrência e arquitetura.

O Composer [8], assim como seu sistema base, não foi projetado para permitir colaboração. Para evitar o trabalho e a futura manutenção de uma camada específica de comunicação, pensou-se em utilizar a IDE Eclipse, já que a mesma possibilita a agregação de plugins que se encaixam perfeitamente permitindo o reuso do ambiente em conjunto com o NCL Eclipse supracitado e outros plugins necessários para o desenvolvimento de nossa ferramenta. Além disso, caso o código-fonte do plugin esteja disponível é possível a criação de pontos para extensão e adaptação do plugin existente.

O plugin NCL Eclipse já realiza as operações para criação e edição local de documentos NCL. Porém, o mesmo não permite a colaboração. Para essa funcionalidade, no desenvolvimento do Co-NCL optou-se pela utilização do Framework ECF (Eclipse Communication Framework) [25], que abstrai a camada de comunicação e muitas características comuns à colaboração, permitindo um maior foco nos tratamentos de inconsistência e controle de concorrência. Uma das funcionalidades do ECF é o chamado DocShare [25], que implementa a colaboração em tempo real conectando usuários através do suporte prestado pela “ECF Datashare API” [25].

A figura 2 apresenta a arquitetura da ferramenta Co-NCL baseada na plataforma Eclipse. Conforme ilustrado, além dos plugins citados anteriormente, no núcleo da ferramenta encontra-se o plugin de mesmo nome, que dentre outras funcionalidades, é responsável por tratar os problemas de inconsistências e o controle de concorrência descritos nas seções 4.3.1 e 4.3.2. O plugin Co-NCL é composto de quatro módulos principais, descritos a seguir.

Figura 2. Arquitetura de desenvolvimento do Co-NCL

• NCL Inferface

NCL Interface é o módulo que trata da comunicação do Co-NCL com o plugin NCL Eclipse, sendo a parte da proposta que captura eventos de auto-completar do plugin NCL-Eclipse e faz com que as ações deste plugin sejam vistas pelo módulo de consistência. Desta forma, sempre que um evento de auto-completar acontecer a consistência recebe as operações que serão tratadas por OT, além de bloquear o evento caso algum outro usuário possua lock na área escolhida.

• Consistency Control

Módulo responsável por tratar os problemas de inconsistência e concorrência, através de OT e lock, respectivamente. Utiliza o módulo Communication Control para se comunicar com o mundo externo (internet e outros usuários). Comunica com o NCL interface para ter acesso aos dados que estão sendo editados no NCL Eclipse. Este módulo interage com o DocShare e com o ECF diretamente .

• Awareness Control

Awareness Control é o módulo que proporciona a contextualização dos usuários perante o sistema e se comunica com o Consistency Control para prover uma visão do que cada usuário está editando, os elementos que possuem lock, e quais são os elementos NCL relacionados com o elemento que está sendo editado. Pode se comunicar também com o Communication Control para trocar informações suplementares de awareness (exemplo, solicitar perfil de um usuário).

113

• Communication Control

O papel principal do Communication Control é prover funções com o intuito de facilitar a utilização do ECF, como, por exemplo, funções usadas rotineiramente pelo Consistency Control (exemplo: envio e recepção de mensagens do protocolo para obtenção de lock).

VI. CONCLUSÃO Este artigo apresentou uma proposta de um mecanismo

híbrido para o controle de concorrência e consistência na edição colaborativa de documentos NCL. Com base nesse mecanismo, foi definida a ferramenta Co-NCL, que se encontra atualmente em fase de desenvolvimento.

Como foi apresentado na seção 3, o NCL possui particularidades nos relacionamentos de seus elementos, o que levou ao estudo de quais seriam os requisitos a serem atendidos por um editor colaborativo para essa linguagem. Optou-se por se usar um mecanismo de controle de concorrência baseado em locks solicitados explicitamente pelo usuário (sendo estes opcionais), já que os tempos de edição de elementos NCL são geralmente pequenos. Com isso, a ordem dos atrasos da rede poderiam impactar na implementação de locks implícitos (de forma automática), inviabilizando a colaboração. Para tratar os problemas de inconsistências, foi adotado um algoritmo de OT (treeOpt). A proposta também se apoia em mecanismos de awareness para auxiliar os usuários tanto na resolução de conflitos como prestando informações dos elementos e seus possíveis relacionamentos.

Como trabalhos futuros estão o estudo de viabilidade para a edição assíncrona, assim como a sua adaptação para permitir a edição de documentos NCL por usuários finais (telespectadores) na plataforma Android. Tal adaptação torna-se importante para atender às perspectivas de que telespectadores virem autores de conteúdo.

REFERÊNCIAS [1] SBTVD, “Sistema Brasileiro de TV Digital”, Acesso em

Março de 2009, disponível em http://sbtvd.cpqd.com.br/

[2] C. A. Ellis, S. J. Gibbs, e G. L. Rein, “Groupware: some issues and experiences”, Communications of the ACM, v.34 n.1, p.39-58, Jan. 1991

[3] C. A. Ellis, e C. Sun, “Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements”, Proceedings of the 1998 ACM conference on Computer supported cooperative work, p.59-68, November 14-18, 1998, Seattle, Washington, United States.

[4] M. Pimentel, M. A. Gerosa, D. Filippo, A. Raposo, H. Fuks, e C. J. P. Lucena, “Modelo 3C de Colaboração para o desenvolvimento de Sistemas Colaborativos”, III Simpósio Brasileiro de Sistemas Colaborativos, p. 58-67, 2006.

[5] C. L. Ignat, “Maintaining Consistency in Collaboration over Hierarchical Documents”, Tese apresentada ao "Swiss Federal Institute Of Technology Zurich", Switzerland, Julho de 2006.

[6] R. M. R. Costa, M. F. Moreno, R. Rodrigues, e L. F. G. Soares, “Live Editing of Hypermedia Documents”, Proceedings of the 2006 ACM symposium on Document engineering, Amsterdam, The Netherlands. Outubro de 2006.

[7] G. L. de Souza Filho, L. E. C. Leite, e C. E. C. F. Batista, “Ginga-J: The Procedural Middleware for the Brazilian Digital TV System”, Journal of the Brazilian Computer Society, 13(1):47--57, Março de 2007.

[8] R. L. Guimarães, “Composer: um ambiente de autoria de documentos NCL para TV digital interativa”, Dissertação de mestrado apresentada Programa de Pós-graduação em Informática da PUC-Rio, 2007.

[9] R. G. Azevedo, “NCL Eclipse: editor textual para desenvolvimento de programas Hipermídia Interativos em NCL”, Monografia apresentada ao Curso de Ciência da Computação da Universidade Federal do Maranhão (UFMA), 2008.

[10] M. F. H. B. Filho, “Gingaway – Uma ferramenta para criação de aplicações gingancl interativas para TV digital”. Monografia apresentada ao Centro de Informática da Universidade Federal de Pernambuco, 2008.

[11] M. Y. Sung, e D. H. Lee, “A Collaborative Authoring System for Multimedia Presentation”, Proceedings of the IEEE International Conference on Communications (Paris, France), IEEE Computer Society, pp. 1396—1400, Junho de 2004.

[12] C. Carneiro, R. Q. Reis, e P. B. Menezes, “Especificação Formal de uma Ferramenta de Trabalho Colaborativo através da Composição de Objetos Náutilus”, XIII Simpósio Brasileiro de Engenharia de Software, Outubro de 1999.

[13] W. G. Phillips, “Architectures for Synchronous Groupware”, Technical Report 1999-425, Department of Computing and Information Science - Queen’s University, 1999.

[14] I. A. L. Gatis, “Um Middleware para Construção de Aplicações de TV Digital Distribuídas baseadas no Modelo P2P”, Dissertação de mestrado apresentada ao programa de pós-graduação em Ciência da Computação da Universidade Federal de Pernambuco, 2006.

[15] N. Pretto, A educação e as novas tecnologias digitais, Revista Fonte Prodemge, Número 08 - Dezembro de 2008.

[16] XML, “Extensible Markup Language 1.0 W3C Recommendation”, 1998. Acesso em Março de 2009, disponível em http://www.w3.org/XML/

[17] L. F. G. Soares e R. F. Rodrigues, “Nested Context Model 3.0 -- Part 1: NCM Core”, Monografias em Ciência da Computação, Departamento de Informática da Pontifícia Universidade Católica do Rio de Janeiro, 2005.

[18] L. F. G. Soares, M. J. Antonacci, R. F. Rodrigues, e D. C. Muchaluat-Saade, NCL: “Uma Linguagem Declarativa para Especificação de Documentos Hipermídia na Web”, VI Simpósio Brasileiro de Sistemas Multimídia e Hipermídia - SBMídia2000, p. 79-95, 2000.

[19] A. Mitchell, “Communication and Shared Understanding in Collaborative Writing”, Tese apresentada à University of Toronto, Department of Computer Science, 1996.

[20] R. M. Baecker, D. Nastos, I. R. Posner, e K. L. Mawby, “The User-centred Iterative Design of Collaborative Writing Software”, Proceedings of the INTERCHI '93 conference on Human factors in computing systems, Amsterdam, The Netherlands, p.399-405, Maio de 1993.

[21] M. C. Pichiliani, Geração de Locks na Edição Colaborativa de Diagramas da UML, relatório técnico disponível em www.comp.ita.br/~pichilia/LockUML.pdf, 2005.

[22] SMIL, Synchronized Multimedia Integration Language, Acesso em Março de 2009, disponível em http://www.w3.org/AudioVideo/#Authoring

114

[23] LASeR. Acesso em Março de 2009, disponível em: http://www.mpeglaser.org/html/techSection_technicalOverview.htm

[24] C. Chen, X, Xu, J. Bu, e Y. Li, “Distributed Dynamic-Locking in Real-Time Collaborative Editing Systems”, Lecture Notes in Computer Science, Volume 3198/2004, 2004. Proceedings of 10th International Conference on Groupware, Springer-Verlag . p.271-279, Setembro de 2004.

[25] ECF, “Eclipse Communication Framework”, Acesso em Março de 2009, disponível em http://www.eclipse.org/ecf,

[26] A. Saddik, A. M. Rahman, M.A. Hossain, “Authoring Multimedia Objects in Collaborative Ambient Intelligent

Virtual Environment”, Proceedings of the fourth IEEE International Workshop on Haptic Virtual Environments and their Applications (HAVE2005)”, pp. 159- 164, 2005.

[27] C. Castro, “Uso de plataformas tecnológicas para inclusão digital – o caso da TV digital e da produção de conteúdos”, Revista Ibitic - Inclusão Social, Brasília, v. 3, n. 1, p. 70-74, 2008.

[28] M.A. Gerosa, M.G Pimentel, H. Fuks, C.J.P. Lucena, “Development of Groupware Based on the 3C Collaboration Model and Component Technology” em 12th International Workshop, CRIWG 2006, Medina del Campo, Spain, Setembro, p 302-309, 2006.

115