UNIVERSIDADE CATÓLICA DOM BOSCOCentro de Ciências Exatas e Tecnológicas

Curso de Engenharia de Computação

Ambiente Colaborativo UtilizandoRealidade Virtual na WWW

André Luiz Miranda da Rosa

__________________________________________Prof. Alfredo Lanari de Aragão

Orientador

__________________________________________Prof. Marco A. Álvares

Coordenador do Curso de Engenharia de Computação

Monografia do Projeto de Graduação submetida como requisito parcial para a obtenção do grau de Engenheiro de Computação.

Campo Grande, MSDezembro - 2003

Ambiente Colaborativo Utilizando Realidade Virtual na WWW

André Luiz Miranda da Rosa

Composição da Banca ExaminadoraProf. Alfredo Lanari de Aragão (Orientador) Presidente - UCDB

Prof. Ricardo Ribeiro dos Santos UCDBProf. Danielle Ruchkys UCDB

Universidade Católica Dom BoscoCampo Grande, MS

Dezembro - 2003

2

Resumo

Este projeto tem como objetivo especificar e elaborar um protocolo que permita a

utilização de um Ambiente Virtual Colaborativo (AVC) através da WWW e, com isso, a

interação e colaboração em tempo real entre os usuários presentes no ambiente. Como uma

das principais características da Internet é permitir a comunicação de diferentes máquinas e

arquiteturas ao redor do mundo, tal sistema também deverá partilhar da capacidade

multiplataforma. Por isso será utilizado o modelo de Realidade Virtual (RV) Não-Imersivo,

que permite a utilização de periféricos comuns, baratos, e existentes na maioria dos

computadores atuais como monitores, teclados e mouses. Portanto, este projeto visa

especificar um protocolo para AVC na plataforma WWW, cujo objetivo é facilitar a

cooperação e interação entre pessoas envolvidas em uma mesma atividade.

Palavras-chave: Interação Homem-Computador, Realidade Virtual, Trabalho Colaborativo

Auxiliado por Computador

3

AgradecimentosPrimeiramente, agradeço a Deus por permitir que eu ainda esteja aqui, seja qual for o

seu objetivo; à meus pais, que enquanto estiveram ao meu lado me mostraram o verdadeiro

valor da educação, e com certeza - onde quer que estejam - ainda me guiam de alguma

maneira; à meus familiares, que se tornarem meus segundos pais, me incentivando a continuar

estudando e que, sem os quais, eu talvez nem estaria escrevendo esta monografia; à meus

colegas de classe que muitas vezes me ajudaram a prosseguir com o curso; e à meu orientador

que, desde o começo deste projeto, também soube me guiar mostrando o melhor caminho para

a obtenção de um resultado mais significativo.

À todos vocês,

meu sincero: Obrigado.

4

Índice1 Introdução........................................................................................................................8

2 Interação Homem-Computador e Realidade Virtual.....................................10

2.1 Considerações Iniciais.............................................................................................10

2.2 Interação Homem-Computador...............................................................................11

2.2.1 O Desafio da IHC..................................................................................12

2.2.2 As Metas da IHC...................................................................................12

2.2.3 Mudanças Tecnológicas........................................................................13

2.2.4 Projeto de IHC.......................................................................................14

2.3 Realidade Virtual.....................................................................................................15

2.3.1 Ambientes Virtuais................................................................................16

2.3.2 Ambientes Virtuais Colaborativos........................................................19

2.4 Considerações Finais...............................................................................................20

3 Trabalho Colaborativo Auxiliado por Computador.......................................23

3.1 Considerações Iniciais.............................................................................................23

3.2 Trabalho Colaborativo Auxiliado por Computador................................................24

3.2.1 Projetos de Sistemas CSCW.................................................................25

3.2.2 Tendências da Computação Colaborativa.............................................26

3.3 Multimídia...............................................................................................................28

3.3.1 Computação Colaborativa Utilizando Realidade Virtual......................30

3.4 Sistemas Distribuídos..............................................................................................33

3.4.1 Sistemas Distribuídos e Realidade Virtual............................................35

3.4.2 Características de Sistemas Distribuídos...............................................36

3.4.3 Compartilhamento de Recursos e a Internet..........................................39

3.4.4 Comunicação em Grupo........................................................................40

3.5 O Protocolo TCP/IP................................................................................................41

3.5.1 IP (Internet Protocol)............................................................................42

3.5.2 Datagramas IP.......................................................................................43

3.5.3 UDP (User Datagram Protocol)...........................................................43

5

3.5.4 TCP (Transmission Control Protocol)..................................................45

3.5.5 Máquina de Estado Finito do TCP........................................................46

3.6 Considerações Finais...............................................................................................47

4 Especificação..................................................................................................................49

4.1 Objetivos do Projeto................................................................................................49

4.2 Especificação do Protocolo.....................................................................................49

4.3 Funcionalidades do Protocolo.................................................................................50

4.4 Características de Controle do Protocolo................................................................51

4.5 Mensagens de Controle do Protocolo......................................................................54

4.6 Máquina de Estados Finitos do Protocolo...............................................................58

4.6.1 Conclusão......................................................................................................................

..61

4.6.2 Referências Bibliográfi-

cas........................................................................................63

6

Lista de Figuras

Figura 1 – Dispositivos para Realidade Virtual........................................................................17

Figura 2 – Abstrações Compartilhadas.....................................................................................27

Figura 3 - A Máquina de Estado Finito do TCP (Comer, 1999)...............................................47

Figura 4 – Diagrama de Classes do Protocolo..........................................................................52

Figura 5 – Máquina de Estados Finitos do Protocolo...............................................................58

Figura 6 – Diagrama de Seqüência...........................................................................................60

7

1.Introdução

No mundo real, muitos tipos de trabalho, lazer ou qualquer interação social envolve

grupos de pessoas com objetivos comuns interagindo umas com as outras, com vários objetos

naturais ou artificiais e com o ambiente nas quais elas estão localizadas. Entretanto, estes

tipos de trabalho envolvem algumas dificuldades como reunir seus integrantes no mesmo

momento e local e a necessidade de visualização e manipulação de grandes volumes de

informações, dependendo da área de atividade do grupo.

Para o bom desenvolvimento de um trabalho em grupo, é necessária uma grande intera-

ção entre as pessoas que o compõe. Portanto, o Trabalho Colaborativo Auxiliado por

Computador, que é um campo de pesquisa multi-disciplinar (envolvendo disciplinas como

Interação Homem-Computador, Multimídia e Sistemas Distribuídos) que utiliza ferramentas e

técnicas para suportar o trabalho de várias pessoas com objetivos específicos, possui a finali-

dade de facilitar a comunicação e a produtividade em grupo. Podem ser produzidas muitas

aplicações de sistemas colaborativos auxiliados por computador incluindo: jogos, sistemas de

suporte à decisões em grupo, salas de encontro, conferências, simulações e treinamentos re-

motos.

Ainda hoje, poucos sistemas de computador são projetados com a finalidade de tornar

mais fácil os trabalhos colaborativos e, atualmente, ainda não existe nenhum protocolo ampla-

mente utilizado para o seu controle e gerenciamento. Sendo assim, a especificação de um pro-

tocolo padrão pode ser muito útil no suporte às mais variadas aplicações colaborativas, pou-

pando assim o tempo despendido pelos projetistas com a especificação dos requisitos de co-

municação individuais de cada aplicação. Além disso, os Trabalhos Colaborativos Auxiliados

por Computador podem ser enriquecidos e se tornar mais eficientes com a utilização de uma

das melhores Interações Homem-Computador atualmente existentes, a Realidade Virtual, que

fornece uma interface mais natural e em tempo real com seus usuários através de um Ambien-

te Virtual Colaborativo.

Portanto, o projeto de um protocolo padrão que forneça todos os requisitos para contro-

lar a comunicação e administração de Trabalhos Colaborativos Auxiliados por Computador

8

utilizando Realidade Virtual, em ambientes multi-plataforma (como a Internet), pode ser con-

siderado muito promissor.

Inicialmente este Projeto de Graduação previa a implementação um protocolo para tra-

balhos colaborativos utilizando Ambientes Virtuais Colaborativos na plataforma WWW vol-

tado especificamente para uma determinada aplicação colaborativa (a UCDB Virtual, que

conteria um dos blocos da UCDB modelado tridimensionalmente e permitiria aos usuários re-

motos conhecerem as dependências da UCDB e interagiram uns com os outros).

Entretanto, como este tipo de protocolo não permitiria a construção de outras aplicações

colaborativas, o principal objetivo deste projeto se tornou a especificação e elaboração de um

protocolo padrão que forneça o gerenciamento e a comunicação necessária de um sistema co-

laborativo para o suporte às mais variadas aplicações utilizando Realidade Virtual na WWW.

Portanto, este projeto descreve detalhadamente sua especificação de requisitos funcionais,

contendo todo o fluxo de mensagens e a estrutura de controle necessária para o seu gerencia-

mento e funcionamento.

9

2.Interação Homem-Computador e

Realidade Virtual

2.1.Considerações Iniciais

Durante os últimos 30 anos, a tecnologia avançou ao ponto de quase todas as pessoas,

de alguma maneira, mantém algum tipo de contato com computadores. Nos primeiros dias da

computação, somente pessoas capacitadas tecnicamente, como engenheiros e cientistas,

conseguiam utilizá-los. Hoje em dia, o conhecimento e a experiência de diferentes tipos de

usuários são muito variados. Portanto, é importante que a interação seja simples e intuitiva

(Preece, 1994). Entretanto, desenvolver interfaces apropriadas entre usuário e computador não

é sempre fácil, como comprovam muitos sistemas de computador fracamente desenvolvidos.

A Realidade Virtual é uma interface de alto nível com o usuário que envolve simulações

em tempo real e interações direcionadas a múltiplos canais sensoriais como o visual, o

auditivo e o tátil, e portanto pode ser considerada como uma das melhores interfaces atuais

para a Interação Homem-Computador (que estuda todos os aspectos que envolvem a

utilização de computadores por seres humanos). Ela utiliza a Computação Gráfica para criar

um mundo virtual de forma realística. Além disso, este mundo sintetizado não é estático, mas

responde as entradas do usuário – gestos e comandos verbais, por exemplo. Isto define uma

característica chave da Realidade Virtual, que é a interatividade em tempo real (Burdea,

1994).

Sendo asssim, o novo protocolo será destinado ao suporte de aplicações colaborativas

utilizando Realidade Virtual devido à seu imenso potencial de enriquecimento da colaboração

ao permitir uma maior interação dos usuários com o sistema (e consequentemente com os

outros usuários), visualizações mais realísticas e manipulações de grandes volumes de dados

de forma mais natural, eficiente e entendível.

10

2.2.Interação Homem-Computador

Um dos desafios do desenvolvimento da Interação Homem-Computador (IHC) é a

utilização dos atuais avanços tecnológicos e a garantia de que eles serão utilizados para o

máximo benefício humano (Preece, 1994). Um importante fator em IHC é a segurança, visto

que alguns tipos de sistemas de computador podem colocar vidas em perigo caso não tenham

uma boa interação.

Quando os primeiros computadores apareceram no cenário comercial na década de

1950, eles eram extremamente difíceis de usar, desajeitados e algumas vezes imprevisíveis.

Preece (1994) aponta uma série de fatores que contribuíram para este fato:

i. Eram máquinas grandes e caras; tanto que eram considerados bens

“inacessíveis” para a maioria das pessoas;

ii. Eram usados somente por especialistas (cientistas e engenheiros) que estavam

familiarizados com a programação off-line utilizando-se cartões perfurados;

iii. Pouco se sabia sobre como torná-los mais fáceis de se utilizar.

Nenhuma destas condições se mantém atualmente: os computadores se tornaram muito

mais baratos, existem usuários dos mais diversos tipos e entendemos muito mais sobre como

utilizar as máquinas para suprir as necessidades e trabalhos das pessoas (Preece, 1994). A

diminuição dramática do custo de recursos computacionais foi resultante de novos avanços

tecnológicos; o mais significante foi o desenvolvimento do chip de silício. A habilidade de

não apenas miniaturizar circuitos, mas também de empacotar muitos deles em chips

individuais, pavimentou o caminho para o desenvolvimento de poderosos computadores com

alta capacidade de armazenamento.

Em menos de 30 anos, os computadores mudaram de gigantescas máquinas em imensas

salas com ar-condicionado para máquinas muito mais baratas e menores, incluindo algumas

que podem ser facilmente carregadas por crianças (como Notebooks e Palmtops). Os

computadores também se tornaram mais confiáveis e as máquinas atuais não sofrem tanto de

superaquecimento como os seus antecessores. A Computação entrou em uma nova era e se

tornou onipresente (Preece, 1994) pois praticamente todos os setores (ciência, medicina,

comércio, entretenimento, etc.) foram, de um modo ou de outro, influenciados pelos avanços

da informática a ponto de atualmente muitos deles serem bastante dependentes desta

tecnologia, como os setores de telecomunicações e as indústrias de entretenimento.

11

2.2.1.O Desafio da IHC

O desenvolvimento do chip de silício mudou o mundo a ponto de que muitas pessoas

usam ou entram em contato com os computadores de uma maneira ou de outra. Além do mais,

a velocidade das inovações não está diminuindo. O desenvolvimento de máquinas mais

rápidas e com maior capacidade (em termos de poder de processamento) continua; em adição

novas melhorias na tecnologia de hardware e software estão abrindo novas possibilidades

para as interações entre homens e computadores e para os trabalhos colaborativos, como a

utilização da Realidade Virtual como uma avançada interface de IHC. Neste caso, a

necessidade de um software de controle para um Ambiente Virtual Colaborativo é resolvida

através da especificação de um protocolo padrão.

Equipamentos especiais permitem que o usuário agarre e mova objetos virtuais em um

Ambiente Virtual (AV), ou mesmo, que se mova ao redor deste ambiente. Aplicações

Multimídia, na qual sons, gráficos dinâmicos e estáticos, vídeos e textos estão interligados de

maneira síncrona e interdependente, agora são comuns. Imagem, vídeo, som e texto podem

todos ser transmitidos com uma mínima perda de eficiência e qualidade. Informações

mantidas em banco de dados ao redor do mundo estão se tornando acessíveis às pessoas em

suas próprias casas. Estas mudanças trazem dois importantes desafios para os projetistas de

IHC, segundo Preece (1994):

i. Como se manter lado a lado com as mudanças tecnológicas;

ii. Como garantir que o seu desenvolvimento traga uma boa IHC mesmo com

potenciais funcionalidades de novas tecnologias.

2.2.2.As Metas da IHC

As metas da IHC são produzir sistemas funcionais que sejam úteis e seguros. Estas

metas podem ser resumidas como: “Desenvolver ou melhorar a segurança, utilidade,

efetividade, eficiência e usabilidade de sistemas, incluindo computadores” (Preece, 1994).

Neste contexto, o termo “sistema” deriva da teoria de sistemas e não se refere apenas ao

hardware e software, mas ao ambiente completo (incluindo os Ambientes Virtuais), seja isto

uma organização de pessoas no trabalho, em casa ou empenhando atividades de lazer, que

usam ou são afetados pela tecnologia computacional em questão.

12

Usabilidade refere-se à funcionalidade de um sistema ou, em outras palavras, as coisas

que ele pode fazer. Portanto, a usabilidade se torna um conceito chave em IHC, permitindo a

construção de sistemas fáceis de se aprender e utilizar. Melhorar a efetividade (efetuar uma

operação sempre com sucesso) e a eficiência (o quanto uma operação se torna mais veloz e

mais complexa em relação a anterior) são objetivos implícitos e onipresentes. Promover a

segurança em relação a sistemas de computador é de suprema importância no

desenvolvimento de sistemas críticos de segurança. Sistemas de computador fracamente

desenvolvidos podem ser extremamente aborrecedores para os usuários. Mas ao contrário do

que muitas pessoas podem pensar, oferecer diferentes tipos de funções não é necessariamente

o melhor caminho para se promover uma boa usabilidade.

Muitos tipos de trabalhos, lazer ou quaisquer interações sociais envolvem grupos de

pessoas interagindo umas com as outras, com vários objetos naturais ou artificiais e com o

ambiente nas quais elas estão localizadas. O Trabalho Colaborativo Auxiliado por

Computador é agora um importante tópico de pesquisa e existem muitos projetos examinando

o modo com que as pessoas utilizam o e-mail, a vídeo-conferência e outras formas de

sistemas colaborativos (Preece, 1994).

2.2.3.Mudanças Tecnológicas

Para que os computadores sejam completamente aceitáveis, eles precisam ser bem

projetados. Isto não quer dizer que os sistemas devam ser desenvolvidos para acomodar todas

as pessoas, mas que eles devem suprir as necessidades e capacidades das pessoas para as

quais eles são direcionados. Em última instância, os usuários não devem ter que pensar sobre

as complexidades de como usar um computador. O modo de utilização dos computadores

deve ser o mais natural possível para que se torne uma ferramenta útil e ágil no auxílio à

execução de uma determinada tarefa e não um empecilho que atrapalha, tornando mais

complexa, a sua conclusão. Por isso, esforços têm sido feitos para tornar o uso do computador

mais flexível e agradável às necessidades das pessoas.

Donald Norman apud Preece (1994), autor de “A Psicologia das Coisas Diárias” e

“Setas de Direção são as Expressões Faciais dos Automóveis”, catalogou muitos exemplos de

coisas do dia-a-dia que não apresentam uma imagem clara e óbvia para seus usuários. Se

pensarmos na complexidade da maioria dos sistemas de computadores, veremos que o

potencial para o desenvolvimento de IHC fracas é muito alto. Entretanto, Norman identificou

13

dois princípios chaves que ajudam no desenvolvimento de IHC: Visibilidade e

Disponibilidade. Os controles devem ser visíveis, com um bom mapeamento de seus efeitos e

devem também sugerir sua funcionalidade. Isto pode servir para diminuir a complexidade

inerente a grandes projetos, que possuem uma grande quantidade de funções, e permitir uma

segurança mais eficiente em sistemas críticos que podem colocar a vida humana em perigo.

2.2.4.Projeto de IHC

Para um bom projeto de IHC, são necessárias algumas características importantes

como: um bom mapeamento dos controles e efeitos da aplicação; controles com apenas uma

função; um bom feedback; e um sistema entendível. Em geral, as relações entre as

necessidades do usuário, as ações necessárias e seus resultados devem ser sensíveis,

significantes e não-arbitrários. Entretanto, em muitos sistemas (como, por exemplo, o

videocassete), o mapeamento dos controles e seus efeitos é arbitrário. Ou seja, não há

correspondência entre as necessidades do usuário e os botões que fazem parte da interface

(muitos deles têm múltiplas funções) e há um fraco feedback, por isso o usuário geralmente

não tem certeza se o resultado desejado foi obtido com sucesso. Em geral, o sistema não é

facilmente entendível. Portanto, estas são condições contrárias a um bom projeto de IHC.

Disponibilidade é caracterizada como “um termo técnico que se refere às propriedades

dos objetos – que operações e manipulações podem ser feitas em um objeto particular”

(Norman apud Preece, 1994). Portas, por exemplo, tem a disponibilidade de serem abertas ou

fechadas, e cadeiras de suportar pessoas. A Disponibilidade abrange uma grande parte do

desenvolvimento de objetos, mas o que realmente é importante é a “Disponibilidade

Percebida”, ou seja, o que uma pessoa pensa que pode fazer com o objeto. Por exemplo, o

desenvolvimento de uma porta pode não sugerir que ela deva ser aberta puxando-a ou

empurrando-a. Infelizmente, a estética algumas vezes entra em conflito com uma boa

disponibilidade e a aparência do objeto ganha precedência sobre o seu uso. Produzir sistemas

de computador de fácil utilização significa que os projetistas devem pensar muito além das

capacidades que o sistema deve ter. Eles também devem considerar a interação que existirá

entre os usuários e o sistema. Durante a explosão tecnológica de 1970, a noção de interface

com o usuário, também conhecida como Interface Homem-Máquina (IHM), se tornou uma

preocupação geral tanto para os projetistas quanto para os pesquisadores. Norman definiu este

termo como “aqueles aspectos do sistema em que o usuário entra em contato”, o que significa

14

“uma linguagem de entrada para o usuário, uma linguagem de saída para a máquina e um

protocolo de interconexão” (Chi apud Preece, 1994).

Empresas de informática perceberam que se melhorassem de alguma forma os

aspectos físicos da interface com o usuário para seus empregados, elas poderiam melhorar

significativamente a sua produtividade. Para explorar esta nova dimensão, um clichê muito

utilizado foi chamar um sistema de “amigável”. Na prática, isto simplesmente significou um

embelezamento das telas para torná-las mais atrativas esteticamente. A maioria dos sistemas

continuava sem satisfazer as necessidades dos usuários e ainda necessitavam que o usuário se

adaptasse ao que mais se pareciam interfaces “hostis” aos usuários.

Por sua vez, pesquisas acadêmicas na área eram direcionadas a como utilizar os

computadores para enriquecer o trabalho e a vida pessoal das pessoas. Em particular, elas

focalizaram-se nas capacidades e limitações dos usuários, ou seja, entendendo o “lado

pessoal” das interações com sistemas de computador. O termo IHC foi adotado em meados da

década de 1980 como um meio descrever este novo campo de estudo. Este termo concorda

que o foco de interesse é maior do que apenas o desenvolvimento de interfaces e sim a todos

os aspectos envolvidos na interação entre usuários e computadores (Preece, 1994).

Um termo recente que caracteriza este campo segue a definição de Acmsigchi apud

Preece (1994): Interação Homem-Computador é uma disciplina direcionada ao

desenvolvimento, avaliação e implementação de sistemas de computador interativos para o

uso humano e para o estudo de todos os fenômenos que os rodeiam.

2.3.Realidade Virtual

A Realidade Virtual (RV) pode ser definida como uma técnica avançada de Interface Ho-

mem-Computador que permite ao usuário navegar e interagir em um ambiente sintético tridi-

mensional gerado por computador (Burdea, 1994). Ela classifica-se, quanto à forma de

interação, em dois tipos, segundo Machado e Waslawick apud Silveira et al. (2001): Imersiva

e Não-Imersiva. Na Realidade Virtual Imersiva são utilizados acessórios como luvas e HMDs

(Head-Mounted Displays – Capacete de Visualização) com sensores de posicionamento

tridimensionais de modo que o usuário seja completamente envolvido pelo Ambiente Virtual.

A Realidade Virtual Não-Imersiva, por sua vez, caracteriza-se pela utilização de

equipamentos interativos mais comuns e menos sofisticados. Monitores de vídeo são usados

15

para a visualização do Ambiente Virtual. Dispositivos tradicionais de entrada, como o mouse

e o teclado, servem para que o usuário possa interagir com este ambiente.

Segundo Costa (2001), vários autores como Pantelidis e Stuart acreditam que a explora-

ção da RV apresenta inúmeras vantagens de uso em relação a outras tecnologias: provê uma

interface que gera um alto nível de motivação; apresenta recursos que ilustram a compreen-

são de conceitos abstratos; permite a observação de cenas em diferentes distâncias e ângulos;

oferece oportunidade de vivência de situações de maneira individualizada; encoraja a partici-

pação ativa do usuário; permite a participação de pessoas com incapacidades físicas ou men-

tais; disponibiliza recursos para que o usuário pratique procedimentos que serão realizados

posteriormente no mundo real; propicia um ambiente motivador para a aquisição de conheci-

mentos e aprendizagem; oferece possibilidades de entretenimento e diversão; possui caracte-

rísticas que facilitam o estudo do desempenho humano e suas capacidades perceptuais e mo-

toras.

Em função do elevado potencial para o uso nas mais variadas atividades da sociedade

como pesquisa, treinamento, negócios e lazer, a RV pode ser considerada bastante promissora

(Silveira et al., 2001).

2.3.1.Ambientes Virtuais

Kalawsky apud Junior (2001) definiu Ambiente Virtual (AV) como sendo experiências

sensórias sintéticas em um ambiente diferente do ambiente físico. Com a RV é possível criar

uma interface ou um AV que permita a manipulação de objetos por computador da mesma

maneira que seriam manuseados no mundo real. Assim, o conhecimento intuitivo do usuário

a respeito do mundo físico pode ser transferido para manipular o AV (Meiguins et al., 2001).

Além disso, o AV pode ser uma réplica da realidade obedecendo todas as suas regras – as leis

da física, por exemplo; como pode ser, também, uma realidade alternativa construída para

facilitar determinadas ações e que não tem qualquer compromisso em obedecer as regras da

natureza.

Quando um AV é visitado, o participante é representado por um avatar, que é uma

manifestação visível do usuário no ambiente - Roehl apud Meiguins et al. (2001). A

utilização do avatar, com o qual o usuário possa interagir, é capaz de levá-lo a participar

melhor do AV tornando a experiência mais excitante e realista. Também aprimora a

16

capacidade de imersão do usuário no ambiente e o conduz a um melhor sentimento de

presença, ainda que não esteja utilizando um ambiente imersivo.

Os termos Ambiente Virtual e Realidade Virtual são atualmente usados para referenciar

uma variedade de estilos de interação. Os termos que são normalmente usados para referenci-

ar tais estilos devem seguir, segundo Preece (1994), três fatores em comum:

i. Senso de Presença Física Direta: Sugestões sensórias são criadas pela tecnologia

para dar ao usuário o forte senso subjetivo de “presença física” e “experiência

direta”. Estas sugestões podem ser visuais, auditivas, táteis (com o senso de to-

que ou força no corpo) ou alguma combinação entre eles.

ii. Sugestões Sensórias Tridimensionais: O sistema explora os sensos da visão, au-

dição e tato e a informação, em ao menos um destes canais, é usualmente apre-

sentada em três dimensões.

iii. Interação Natural: Tipicamente, sistemas de RV permitem que objetos criados

por computador sejam manipulados usando gestos similares àqueles que poderi-

am ser usados para manipular objetos reais: pegar, andar ao redor, jogar, etc.

De acordo com Preece (1994), uma das formas mais comuns de AVs atuais requerem

que o usuário vista uma ou mais datagloves (luvas com sensores 3D) e um par de displays

(HMD) construídos de forma especial para serem presos à cabeça. A Figura 1 mostra estes

dois tipos de dispositivos.

Figura 1 – Dispositivos para Realidade Virtual

Os displays são miniaturas de telas de TV (uma para cada olho), cada uma tipicamente

ligada a um poderoso computador de renderização de gráficos separado. Subjetivamente, uti-

17

lizando-se o HMD em um sistema deste tipo, o usuário entra em um ambiente tridimensional

e colorido que ocupa todo o seu campo de visão (algumas versões mais caras oferecem dis-

plays de alta resolução).

Tipicamente, pode-se começar a investigar o ambiente gerado por computador girando

a cabeça e fisicamente movendo-se. Com a utilização do dataglove, uma mão virtual pode ser

vista no lugar onde sua mão real deveria estar e pode imitar todos os movimentos de sua mão

verdadeira. Dependendo da precisão do software de reconhecimento de gestos pode-se, mais

ou menos confiantemente, pegar objetos virtuais e manipulá-los no AV. Em muitos sistemas,

fazendo-se o gesto de uma arma na direção que se deseja ir permite que o usuário “voe” na-

quela direção. Muitos outros estilos de RV estão disponíveis, como por exemplo, interfaces de

auditórios virtuais tridimensionais.

Uma técnica recente e relativamente barata, de acordo com Wenzel apud Preece

(1994), permite a utilização de sons virtuais localizados precisamente no AV tridimensional.

A aparente posição da fonte de som estacionária parece fixa no espaço quando o usuário se

move ao redor. Sons virtuais 3D podem ser muito efetivos, particularmente com a combina-

ção do HMD e datagloves descritos anteriormente.

Tarefas onde sons virtuais podem ser particularmente efetivos incluem a localização

de objetos móveis, uso de fontes sonoras como meio de navegação e localização no AV, a to-

mada de consciência das atividades de outras pessoas no AV e a tomada de consciência dos

eventos que acontecem no AV fora do campo de visão e atenção imediata do usuário. Sons

virtuais 3D podem por eles mesmos, por exemplo, permitir que pilotos de aviões se tornem

diretamente conscientes da aproximação de outro avião de qualquer direção numa esfera ao

redor de suas cabeças.

Um dos poucos AV que tem sido utilizados sistematicamente e avaliados por um ex-

tenso período de tempo é o projeto GROPE (utilizado para se entender as interações molecu-

lares), associado a Fred Brooks da Universidade da Carolina do Norte. Ao contrário de muitos

sistemas de RV bem-conhecidos, este sistema se foca no senso do tato, ou seja, o senso relaci-

onado ao toque. O GROPE permite aos cientistas a sensação direta em três dimensões de for-

ças elétricas simuladas envolvidas na tentativa do ajuste das moléculas em espaços vazios de

outras moléculas. O encontro das soluções para estes problemas pode ser muito importante no

projeto de novas drogas e na resposta para muitas questões da biologia molecular.

2.3.2.Ambientes Virtuais Colaborativos

18

Utilizando-se um Ambiente Virtual Colaborativo (AVC), com técnicas de Trabalho

Colaborativo Auxiliado por Computador (descritos no próximo capítulo), é possível que

usuários separados geograficamente se comuniquem e interajam um com o outro em um

ambiente compartilhado interconectado por redes de computadores. Estes AV multiusuários

podem ser classificados, segundo Kilmer apud Meiguins et al. (2001), em:

I. Centralizados: Os usuários compartilham exatamente a mesma cópia do AVC

que fica localizada no servidor, ou seja, eles recebem informações sobre o

ambiente através de um servidor central no qual o AVC está inserido;

II. Distribuídos: Os usuários compartilham o AVC através de cópias do ambiente em

suas próprias estações de trabalho, por isso não é necessária a contínua

comunicação com o servidor para o recebimento de informações sobre o AVC.

Pode ser dividido em:

i. Replicado (para pequenos ambientes): Cada usuário mantém uma

cópia exata de todo o AVC em sua estação de trabalho. Todas as

mudanças praticadas pelos usuários devem ser comunicadas aos

outros usuários através de broadcast.

ii. Particionado (para grandes ambientes): No modelo particionado,

cada estação de trabalho dos usuários se torna um servidor para o

AVC, mas fica responsável apenas por uma de suas partes. Como o

usuário pode navegar no AV, ele poderá penetrar em outras regiões,

de forma que o servidor deverá receber uma réplica da região onde

ele se encontra. Assim, cada máquina encontra-se também cuidando

de uma região fora da sua parcela, a parcela onde o usuário está

localizado no momento. Se existirem vários usuários em uma mesma

região, esse grupo de usuários receberá uma cópia dessa região, e

suas atualizações, através de multicast.

De acordo com Teixeira e Ipólito apud Meiguins et al. (2001), existem algumas técnicas

desenvolvidas para minimizar o tráfego de mensagens na rede sobre as atualizações do AV

que são as chamadas dead reckoning (no qual atualizações sobre o AVC são enviadas aos

usuários somente quando elas realmente existirem) e filtragem de dados (no qual as

atualizações sobre o AVC são enviadas somente aos usuários que realmente necessitam

visualizar tais alterações).

19

Podem ser produzidas muitas aplicações em AVCs, incluindo jogos, sistemas de

suporte à decisões em grupo, salas de encontro, conferências e treinamento remoto. Um

exemplo de projeto bastante influente na área de AVCs foi o DIVE (que provê um ambiente

de desenvolvimento geral), desenvolvido pelo Swedish Institute of Computer Science (SICS),

que resultou em um AVC disponível livremente e que foi utilizado muldialmente como base

para outros projetos (Junior, 2001).

Dado uma especificação de um AV e poder computacional suficiente, é possível a prin-

cípio visualizá-lo de qualquer ponto de vista a um nível de detalhamento quase fotográfico.

Entretanto, isto requer uma computação intensiva e pode tomar um bom tempo. Para possibi-

litar a visualização em tempo real de um AV, várias simplificações estilo cartoon são geral-

mente adotadas. Por exemplo, texturas e sombras podem ser ignoradas, polígonos podem ser

usados ao invés de curvas e o número de objetos pode ser mantido muito limitado.

Estudos tenderam a sugerir que a Latência de Visualização (tempo de atualização de

uma imagem em resposta a um movimento) é mais importante para o sentimento de presença

do usuário do que visualizações com altas resoluções e detalhes. Conseqüentemente, ele pode

aceitar uma resolução média, se este for o preço para uma rápida atualização da imagem.

Outra causa evitável da latência são os dispositivos de rastreamento tridimensionais len-

tos e sua quantidade. Devem ser utilizados no mínimo dois dispositivos de rastreamento 3D:

um para o HMD e outro para a luva. Conseqüentemente, a menos que alguns experimentos no

AV realmente necessitem das duas mãos, o sistema terá um melhor tempo de resposta usan-

do-se apenas um HMD e uma dataglove.

2.4.Considerações Finais

O papel da IHC no projeto de sistemas é melhorar a qualidade de interação entre huma-

nos e os sistemas de computador. Para tanto, é utilizado sistematicamente em conjunto o co-

nhecimento sobre as metas, capacidades e limitações humanas com o conhecimento sobre as

capacidades e limitações dos computadores. Além disso, deve-se relacionar este conhecimen-

to para entender os aspectos sociais, organizacionais e físicos do ambiente de trabalho do

usuário.

O desafio para os projetistas de sistemas, especialistas em fatores humanos e qualquer

pessoa interessada em projetar “computadores para serem utilizados por pessoas” é conhecer

como fazer a transição entre a funcionalidade (o que pode ser feito) e a usabilidade (como

20

pode ser feito), para se adequar às necessidades dos usuários em um ambiente de trabalho na-

tural. No nível físico, isto significa selecionar os dispositivos de entrada mais apropriados

para tarefas de entrada (como teclado e mouse) e igualmente os dispositivos de saída mais

apropriados para tarefas de saída (como vídeo, som, texto e gráfico). Isto também significa

decidir pelo melhor estilo de interação (como formulários, linguagem natural, Multimídia e

Realidade Virtual).

Assim como são conhecidas as características da tecnologia, também são essenciais a

compreensão da psicologia humana e as características particulares dos usuários como habili-

dades e idades. Algumas decisões também podem ser tomadas em relação ao ambiente no

qual o sistema irá ser usado em termos de atributos físicos como espaço e luz; aspectos sociais

para fazer com que as pessoas interajam ou compartilhem tarefas; e aspectos organizacionais

como hierarquias e diferentes papéis de trabalho.

Por isso, a IHC é uma área de bastante influência em qualquer tipo de trabalho envol-

vendo seres humanos e computadores e, portanto, também é essencial para um bom projeto de

sistemas colaborativos que permitem a interação e comunicação entre diferentes usuários.

A RV, e seus benefícios, esta se tornando cada vez mais conhecida, porém sistemas

imersivos ainda têm custo elevado tornando sua utilização restrita. Se um produto é

tecnicamente viável, e satisfaz uma certa necessidade do consumidor, então ele irá se

proliferar inexoravelmente. Isto aconteceu com os computadores e é possível dizer que o

mesmo se aplicará aos sistemas de RV (Burdea, 1994).

Outro aspecto é que o progresso tecnológico é “neutro”, ou seja, cabe a nós aplicar as

descobertas para o benefício da humanidade ou para a sua destruição. Exemplos são

abundantes, mas o “duplo” uso da energia atômica parece ser bastante persuasivo. Portanto,

este é um motivo para analizar nossas responsabilidades com respeito às novas tecnologias

em RV.

Muitos sistemas colaborativos são destinados a plataformas e organizações particulares.

Em contraste, a Internet oferece uma infra-estrutura globalmente acessível e independente de

plataforma. Não surpreendentemente, muitas pessoas estão olhando em sua direção como uma

plataforma potencial para um trabalho colaborativo mais rico. Entretanto, ainda não está claro

qual tipo de protocolo, topologia e tecnologia deve ser usada para permitir sua utilização.

21

3.Trabalho Colaborativo Auxiliado por

Computador

3.1.Considerações Iniciais

22

Muitos tipos de trabalho envolvem pessoas trabalhando em conjunto e, portanto, se in-

tercomunicando. As organizações, por sua natureza comercial e empreendedora, acreditam na

cooperação entre as pessoas para que alcancem os melhores resultados possíveis. Ainda hoje,

poucos sistemas de computador são projetados com a finalidade de tornar mais fácil o traba-

lho colaborativo. Portanto, o projeto de computadores e interfaces para facilitar o trabalho em

grupo é bastante promissor.

A integração de textos, imagens, animações, áudio e vídeo sincronizados e interdepen-

dentes em sistemas computacionais interativos é comumente denominada Multimídia, que

configura, na verdade, uma nova mídia. A utilização da Multimídia vem se difundido rapida-

mente e tem sido objeto de estudo de diversas pesquisas (Chaves, 1991). Um exemplo do po-

der da Multimídia é a vídeo-conferência, que pode facilitar trabalhos colaborativos permitindo

que usuários remotos possam se comunicar de forma tão natural quanto usuários locais.

O processamento distribuído fornece um maior aprofundamento para o processamento

computacional. Computadores autônomos interligados por rede são amplamente utilizados

para o processamento local, para suportar a comunicação entre usuários e para promover aces-

so a facilidades como o compartilhamento de recursos. Entretanto, não existe nenhum sistema

único principal. A interação é mais uma forma de comunicação do que uma colaboração

(Sloman, 1994). Os Sistemas Distribuídos são essencialmente uma extensão destes sistemas

de rede. Eles também podem ser compostos por um número de processadores autônomos de

propósitos gerais interconectados por rede, mas é esperado que a interação inclua algum tipo

de colaboração. Além disso, os usuários de computadores, as informações que eles necessitam

e fornecem e as próprias aplicações estão, na maioria das vezes, fisicamente distribuídas.

Portanto, os Sistemas Distribuídos podem permitir a construção de um AVC distribuído

com recursos Multimídia (em conjunto com a RV) para permitir a visualização e manipulação

de grandes quantidades de informações à seus usuários remotos - recurso chave para o desen-

volvimento de aplicações de Trabalho Colaborativo Auxiliado por Computador.

3.2.Trabalho Colaborativo Auxiliado por Computador

O Trabalho Colaborativo Auxiliado por Computador (Computer-Supported

Cooperative Work - CSCW) é um campo de pesquisa multi-disciplinar que utiliza ferramentas

e técnicas para suportar o trabalho de várias pessoas com objetivos específicos. Sua finalidade

23

é facilitar a comunicação e a produtividade em grupo. A atual infraestrutura de estações de

trabalho interconectadas, e sua disponibilidade de comunicação de áudio e vídeo, torna mais

fácil às pessoas cooperarem e atravessarem o tempo e espaço. Deste modo, a conectividade da

rede e a integração Multimídia das estações permitem que os usuários utilizem ambientes de

CSCW.

Em CSCW, é possível identificar quatro importantes características, segundo Steinmetz

(1995): o tempo, a distribuição geográfica dos usuários, a escala de usuários e o controle do

sistema. O modo de interação relacionado ao tempo pode ser: assíncrono (que ocorre em dife-

rentes momentos) ou síncrono (que ocorre no mesmo momento); a distribuição geográfica

pode ser: local, quando os usuários estão localizados no mesmo ambiente (como uma sala), ou

remota, quando eles estão em diferentes localizações (como diferentes salas ou prédios); a es-

cala de usuários refere-se à quantidade de usuários que o sistema suporta no mesmo instante;

e o controle do sistema refere-se a todas as regras utilizadas pelo sistema para controlar o

acesso ao ambiente colaborativo por mais de um usuário no mesmo instante. O controle du-

rante a colaboração pode ser dividido em:

i. Centralizado: Significa que há um administrador que controla o trabalho cola-

borativo e cada membro do grupo.

ii. Distribuído: Significa que cada membro do grupo tem o controle de suas pró-

prias tarefas em um trabalho colaborativo e existem protocolos de controle dis-

tribuídos para permitir uma colaboração consistente.

Os sistemas de comunicação em grupo também podem ser divididos em:

i. Sistemas de Colaboração Transparente: São aplicações existentes (como um

processador de texto) estendidas para a colaboração. Por exemplo, alguns novos

sistemas de edição de textos são sistemas de colaboração transparente porque

um único editor de texto foi expandido para edições simultâneas de um docu-

mento compartilhado entre vários usuários.

ii. Sistemas Exclusivos de Colaboração: São aplicações construídas exclusiva-

mente para o CSCW. Por exemplo, um sistema de conferência é um sistema ex-

clusivo de colaboração.

Na ausência de aplicações projetadas especificamente para serem usadas por várias pes-

soas no mesmo instante, sistemas de janelas compartilhadas permitem que aplicações monou-

suário, como os processadores de texto, sejam executadas em uma única estação de trabalho e

visualizadas por qualquer número de estações. Para permitir que os usuários tenham o contro-

24

le da aplicação, o sistema de janela compartilhada pode prover um mecanismo de controle de

acesso. Este mecanismo pode ser escolhido pelo grupo de usuários (Greenberg apud Preece,

1994), ou ser imposto pelo sistema.

3.2.1.Projetos de Sistemas CSCW

Como no projeto de muitos sistemas de computador, o projeto de um sistema CSCW

depende principalmente das tarefas nele envolvidas, de seus usuários e do ambiente de traba-

lho; e sua aceitação depende de alternativas competitivas, segundo Preece (1994). Por exem-

plo, se os usuários preferem ir andando de escritório em escritório ao invés de utilizar um sis-

tema para se comunicar, eles devem ver o sistema de uma forma bem menos favorável do que

aqueles que estão separados por milhares de quilômetros de distância. Além disso, este proje-

to deve levar em consideração muitas características para o seu funcionamento, como a inter-

face de IHC, a tecnologia de rede utilizada e, um dos mais importantes, o protocolo de comu-

nicação e controle que permitirá o trabalho colaborativo; além, é claro, da especificação dos

tipos de aplicações que poderão utilizar este protocolo.

As convenções humanas existentes para o trabalho em grupo permitem uma rica fonte

de idéias para projetos de interfaces CSCW. Se usuários entram em um sistema colaborativo,

eles preferem utilizar convenções e etiquetas (regras de utilização) para tornar o uso do siste-

ma suave e efetivo. Estas etiquetas devem ser ativamente introduzidas a novos usuários. As

convenções e etiquetas para a utilização de um sistema CSCW tendem a se originar de um

plano de fundo cultural.

Quando as pessoas que utilizam a mesma tecnologia vêem de diferentes contextos orga-

nizacionais e culturais, as expectativas dos usuários podem colidir. Usuários de algum sistema

CSCW podem ser de várias zonas espaciais, ou seja, diferentes estados, países ou até conti-

nentes, com fusos horários completamente diferentes. Isto pode requerer que ao menos um

grupo opere fora de suas horas de trabalho normais ou fora de seu ambiente normal de traba-

lho e com alguma improvisação (por exemplo, via telefone celular ou telefone de automóvel).

Sistemas síncronos, ou seja, em tempo real, que funcionem bem com dois usuários po-

dem ser menos efetivos com múltiplos usuários. Atrasos imprevisíveis (por exemplo, na atua-

lização de imagens de vídeo ou superfícies de desenho compartilhado) podem ser muito frus-

trantes e, portanto, um sistema de resposta rápida é o mais preferível.

25

Além disso, um crescente número de pesquisadores acredita que a comunicação espon-

tânea e informal é tão importante quanto à comunicação formal, se não for mais importante

(Preece, 1994). Por exemplo, pessoas no trabalho podem ter a chance de se encontrar casual-

mente e aproveitar para trocar informações, resolver problemas ou identificar oportunidades

de um modo não-planejado. Este tipo de comunicação acidental é agora reconhecido como

um aspecto importante do ambiente de trabalho. Portanto, o projeto de sistemas de CSCW,

utilizando RV, também deve oferecer recursos que permitam uma comunicação informal en-

tre seus participantes.

Quanto mais pessoas existirem, existirão mais oportunidades de encontros informais.

Entretanto, alguns pesquisadores estão desenvolvendo sistemas CSCW com a intenção de

promover oportunidades para encontros informais à distância. Por exemplo, o ambiente

RAVE, da Xerox (Boming e Travers apud Preece, 1994), permitem transmissões de áudio e

vídeo entre os trabalhadores de diferentes escritórios. A privacidade pode ser preservada pela

desabilitação de câmeras e microfones do escritório, pelos usuários, a qualquer momento.

3.2.2.Tendências da Computação Colaborativa

Aplicações que geram novas demandas na infra-estrutura colaborativa e novos tele-ser-

viços estão emergindo, como, por exemplo, a utilização dos AVCs nas mais diversas áreas de

pesquisa, como na medicina e na engenharia. Apenas conferências e aplicações compartilha-

das não são suficientes. Aplicações Multimídia em rede, como a tele-medicina, tele-serviço,

Ambiente Virtual Colaborativo e simulações distribuídas necessitam de direções sofisticadas

no nível de um subsistema de aplicação (Steinmetz, 1995), uma vez que a grande maioria dos

trabalhos desenvolvidos e publicados na literatura especializada tem se preocupado com a

parte da concepção da comunicação de suas aplicações (Perucia, Leite e Reis apud Meiguins,

2003), o que demanda um tempo considerável que poderia ser utilizado no desenvolvimento

da própria aplicação ou na determinação de seus requisitos (Meiguins, 2003).

A futura computação colaborativa irá incorporar um (possivelmente conhecido) número

de pessoas de locais geograficamente distribuídos, usando uma variedade de aplicações de di-

ferentes domínios. Com a heterogeneidade das aplicações Multimídia colaborativas, assuntos

de interoperabilidade precisam ser satisfeitos.

O processo de desenvolvimento de groupwares, ou seja, softwares especialmente proje-

tados para serem usados por mais de uma pessoa simultaneamente, precisa ser simplificado

26

em direção a componentes re-utilizáveis. O groupware deve ter uma arquitetura plug-and-

play (Steinmetz, 1995). Também, o suporte para o desenvolvimento colaborativo durante a

Engenharia de Software deve ser do mais alto nível.

As Abstrações compartilhadas e as Protocolos Padrões precisam ser desenvolvidos para

acomodar a heterogeneidade. A arquitetura Rendezvous, da Bellcore, promove uma solução

parcial para abstrações gráficas compartilhadas (Steinmetz, 1995). Ela é baseada em uma abs-

tração centralizada que coleta a informação comum a todos os usuários em um único espaço.

Cada usuário tem sua visão pessoal da informação. Há uma ponte de ligação entre cada visão

e a abstração. As ligações são responsáveis por manter a consistência entre cada visão e a abs-

tração. A Figura 2, de Steinmetz (1995), mostra a abstração compartilhada de diferentes vi-

sões pessoais em um gráfico.

Figura 2 – Abstrações Compartilhadas

O Protocolo Padrão de CSCW utilizando a RV, uma vez que ainda não foi especificado,

terá que incorporar mecanismos de comunicação que suportem a computação colaborativa,

como a utilização do protocolo TCP/IP (protocolo padrão da Internet) como nível mais baixo

e o multicast, na qual a comunicação entre um membro e seu grupo se faz pelo envio de ape-

nas uma mensagem (que será enviada automaticamente para todos os outros membros do gru-

po, caso o tipo de multicast seja um-para-muitos); ou abstrações de protocolo.

O multicast precisa promover uma comunicação eficiente de múltiplos caminhos (um-

para-muitos, muitos-para-um e muitos-para-muitos). As abstrações de protocolo, como o con-

trole de seções distribuídas, devem proteger os usuários da complexidade de coordenação

Multimídia de múltiplas partes. Muitas abstrações emergiram para descrever fluxos, conexões

e outros objetos em sistemas de comunicação. No projeto da Internet, a abstração de fluxo foi

27

especificada para descrever o objeto que é processado pelos serviços integrados na arquitetura

da Internet (Steinmetz, 1995).

3.3.Multimídia

Como uma disciplina que oferece subsídios para a construção de sistemas colaborativos

mais ricos e eficientes, como os AVC utilizando RV, a Multimídia deve ser estudada à parte.

O termo Multimídia refere-se à apresentação ou recuperação de informações que se faz, com

o auxílio do computador, de maneira multisensorial, integrada, intuitiva e interativa (Chaves,

1991). No aspecto multisensorial, mais de um sentido humano está envolvido no processo,

fato que pode exigir a utilização de meios de comunicação que, até há pouco tempo, raramen-

te eram empregados, como sons (voz humana, música, efeitos especiais), fotografias (ima-

gem estática), vídeos (imagens em movimento), animações (desenho animado), gráficos e tex-

tos (incluindo números, tabelas, etc.). Portanto, a RV, integrada com imagens (construídas a

partir da Computação Gráfica), sons, além de um rico meio de interação com o computador,

pode ser considerada pertencente à disciplina Multimídia.

No aspecto integrado, os meios de comunicação mencionados não são meramente justa-

postos, mas formam um conjunto orgânico sob a coordenação do computador. Na verdade, a

integração, hoje, é tal que não é necessário que tenhamos, ao lado do computador, um apare-

lho de televisão especial para vermos as imagens fotográficas e vídeos: elas são exibidas, em

cores e em alta resolução, na tela do monitor do próprio computador. O áudio, por sua vez,

também dispensa equipamento de amplificação mais sofisticado, podendo ser ouvido através

do alto-falante do próprio computador.

No aspecto intuitivo, existem pelo menos duas necessidades, segundo Chaves (1991):

i. Que a informação seja apresentada ou recuperada na forma mais adequada ao

seu conteúdo, usando-se, para isso, os meios de comunicação mais apropriados;

ii. Que a forma de contato entre o usuário e o material a ser apresentado ou recupe-

rado seja tão natural quanto possível, de modo a garantir a facilidade do uso, a

eficácia da apresentação ou recuperação da informação, a efetividade da sua

compreensão e a eficiência de todo o processo.

No aspecto interativo, a Multimídia não é apenas uma maneira de apresentar informa-

ções ao usuário, como se ele fosse seu mero recipiente passivo, mas sim uma forma de o

28

usuário interagir ativamente com as informações buscando-as, recuperando-as, interligando-as

e construindo com elas novas informações, como no uso da RV.

Em geral, o potencial do computador é sub-utilizado. Uma maneira mais eficiente de

sua utilização seria usar a Multimídia para permitir que o usuário se transforme de um simples

observador passivo da apresentação da informação em um participante ativo na sua busca e

recuperação, de um mero recebedor de sons, imagens e textos, em um manipulador e proces-

sador de informações, que segundo Chaves (1991), entre outras coisas:

i. Decide a seqüência em que a informação vai ser apresentada ou recuperada e o

seu próprio esquema de navegação pela informação;

ii. Determina o ritmo e a velocidade da apresentação ou recuperação da informa-

ção;

iii. Controla repetições, avanços, interrupções, sempre podendo retomar onde parou

da vez anterior;

iv. Estabelece associações e interligações entre informações diversas, mesmo que

de natureza diferente (textos, imagens e sons, por exemplo), progredindo de um

assunto ao outro, ou saltando de um meio ao outro, sem perder "o fio da meada";

v. Introduz marcações e anotações nos textos e imagens, bem como comentários ao

material lido, visto e ouvido, podendo também realizar cálculos com informa-

ções numéricas eventualmente inseridas nos textos;

vi. Define os momentos em que, se desejar, pode avaliar seu conhecimento, deter-

minando, assim, se já possui as informações de interesse.

É um conjunto de características como esse que normalmente identifica a interatividade

de uma experiência (Anderson apud Chaves, 1991). É desnecessário frisar que se pode ter

Multimídia com maior ou menor grau de interatividade. De qualquer forma, é a possibilidade

de interação com informações representadas por mídias que não são tradicionalmente interati-

vas (fotografia, vídeo, música, voz gravada) que vem atraindo as pessoas para a Multimídia. E

é o fato de que esses meios de comunicação estão agora associados ao computador que os tor-

na interativos, conforme Steinberg apud Chaves (1991).

3.3.1.Computação Colaborativa Utilizando Realidade Virtual

Na maioria das aplicações, os usuários do sistema trabalham sem interação uns com os

outros. Entretanto, a Multimídia permite o desenvolvimento de aplicações na qual os usuários

29

podem interagir uns com os outros em um mundo simulado em 2D ou 3D, através da RV. Um

exemplo comum é a vídeo-conferência e os AVC, que permitem substituir encontros físicos

por “encontros virtuais”.

Um exemplo de um sistema colaborativo de vídeo-conferência é o Auditorium da Pla-

ceware Corporation. O sistema é escrito em Java e, portanto, é portável para muitos ambien-

tes. O Auditorium é acessado via um web browser equipado com Java e um plugin de áudio.

Os usuários podem acessar o encontro virtual tanto como palestrante como parte da platéia.

Os membros da platéia vêem um console que tem um gráfico mostrando os outros membros

da platéia. O console também tem áreas de texto para a escrita de comentários para outros

membros da platéia ou para o palestrante. O console do palestrante tem facilidades de apre-

sentação e de tomadas de decisões. As facilidades de apresentação incluem suporte como a

mostra de slides e desenhos à platéia. O suporte a tomada de decisões incluem facilidades

como apurar votos da platéia ou fazer perguntas de múltipla escolha e tabular os resultados de

forma on-line.

O Auditorium é um exemplo de sistema de vídeo conferência onde os usuários acessam

servidores de vídeo que controlam a conferência. Um projeto alternativo pode ser baseado na

adaptação da vídeo-conferência ponto-a-ponto, onde cada participante envia o vídeo a todos

os outros participantes da conferência (técnica chamada de broadcast) e escuta a todos os

participantes por meio de diferentes canais. Entretanto, a crescente complexidade de se utili-

zar múltiplos canais de comunicação e um controle distribuído da conferência torna o sistema

menos escalável do que sistemas de conferência que utilizam um servidor de vídeo centraliza-

do. Um servidor pode também fornecer características adicionais, como a manutenção de um

log da conferência, o que é difícil com sistemas puramente ponto-a-ponto.

A baixa latência (tempo de execução) é uma necessidade adicional significativa de apli-

cações de vídeo-conferência. Se a latência para a entrega do vídeo é alta, diferentes membros

da platéia podem ver o vídeo em tempos significativamente diferentes, levando à confusão.

Considere, por exemplo, o caso onde o usuário B recebe a apresentação significantemente de-

pois do usuário A. Durante a apresentação, o usuário A pode fazer um comentário da apresen-

tação para o usuário B. Se a latência de entrega do vídeo para o usuário B é alta, o usuário B

poderá ver o comentário do usuário A antes de ver a parte da apresentação que o comentário

diz respeito.

Para suportar a vasta diversidade de aplicações Multimídia, os servidores Multimídia

precisam satisfazer muitas exigências. Estas exigências são impostas não somente pela aplica-

30

ção, mas também pelos objetivos do negócio, para um desenvolvimento específico e com con-

figurações arquiteturais e carga de trabalho específica. Entretanto, para compilar uma lista

completa destas exigências, nós iremos considerar as exigências do ponto de vista do projeto

de aplicações Multimídia e negócios que operam servidores Multimídia com configurações

arquiteturais definidas pelos projetistas dos servidores.

3.3.1.1.Exigências das Aplicações Multimídia

A principal característica de Aplicações Multimídia que a distingue de aplicações não-

Multimídia é que os dados Multimídia são sensíveis ao tempo. Quadros sucessivos de dados

tem que ser mostrados de acordo com as relações de tempo definidas pelo projetista da aplica-

ção (por exemplo, fluxo contínuo do segmento de mídia, visualização sincronizada de múlti-

plos segmentos de mídia).

Para esconder as necessidades do sistema subjacente em que Aplicações Multimídia são

desdobradas, como para fazer aplicações portáveis, um segundo requerimento de aplicação é a

especificação da informação em displays de dados sensíveis ao tempo usando interfaces pa-

drão.

O terceiro requerimento de aplicação é a especificação das capacidades da infra-estrutu-

ra subjacente (por exemplo, a largura-de-banda, o armazenamento e processamento das capa-

cidades dos clientes, redes e servidores), tal que as Aplicações Multimídia possam ser partici-

onadas apropriadamente. Por exemplo, o suporte a aplicações multimídia complexas pode re-

querer a recuperação simultânea de múltiplos segmentos de mídia, conseqüentemente supor-

tando a demanda por larguras-de-banda variáveis e de alto pico, e a capacidade de composi-

ção dinâmica no cliente.

Sensibilidade ao Tempo

Se a entrega de dados Multimídia não for no tempo, os usuários receberão interrupções.

Arquivos Multimídia são geralmente muito grandes para serem copiados completamente.

Como resultado, quadros sucessivos devem ser entregues de acordo com constantes de tempo.

Estas constantes são referenciadas como exigências da Qualidade de Serviço (Quality of Ser-

vice - QoS) da aplicação. Exigências de QoS satisfatórios vinculam regras de configuração

31

para escalonamento eficiente de discos, buffers de memória e outros recursos do sistema (Si-

taran, 2000).

Algumas aplicações podem requerer a entrega de múltiplos fluxos de áudio e vídeo, o

que significa que a entrega dos vários fluxos deve ser sincronizada. Portanto, aplicações cola-

borativas podem requerer baixa latência de entrega.

Interfaces Abertas

As exigências de tempo de entrega de aplicações podem variar completamente. Con-

seqüentemente, as aplicações necessitam de interfaces para especificar suas exigências parti-

culares. Um número de características é desejável nestas interfaces. Para facilitar a portabili-

dade e comunicação em rede das aplicações, as interfaces devem ser abertas e padronizadas.

Para facilitar o desenvolvimento, as interfaces devem esconder detalhes da estrutura do servi-

dor Multimídia. Por exemplo, o fato de que um vídeo particular ser replicado e possível de ser

enviado a múltiplos servidores não é relevante a muitas aplicações. O importante para servi-

dores Multimídia é suportar interfaces comuns que muitas aplicações pré-compiladas possam

ser executadas por eles (Sitaran, 2000).

Capacidades do Cliente, do Servidor e da Rede

Para algumas aplicações, os clientes precisam suportar recuperações e visualizações

contínuas do conteúdo em vídeo. As redes que conectam os clientes aos servidores precisam

suportar fluxos contínuos ou canais auxiliares para os comandos dos usuários. Servidores

multimídia suportam o fluxo do conteúdo de mídia e possivelmente individualiza os fluxos

em resposta aos clientes.

Para aplicações mais complexas, que requerem a recuperação, composição e visualiza-

ção desta composição ou de múltiplos segmentos de mídia, as desejadas capacidades dos cli-

entes podem incluir o suporte a complexas interfaces com o usuário, capacidades computacio-

nais para composição dinâmica da apresentação e complexos protocolos de recuperação de

dados como também o armazenamento local para negociações com larguras-de-banda variá-

veis.

Semelhantemente, as redes precisam suportar complexos protocolos de recuperação de

dados (por exemplo, alocação da largura-de-banda) como também canais de comandos e da-

32

dos. As capacidades do servidor incluem, em resposta as requisições dos clientes, composição

da apresentação e fluxos de segmentos de mídia via um ou múltiplos fluxos de recuperação.

3.3.1.2.Exigências das Arquiteturas Multimídia

Servidores Multimídia de larga escala são construídos usando componentes de sistema

pré-existentes (por exemplo, dispositivos de armazenamento e processadores). As característi-

cas destes componentes já existentes (como, por exemplo, a velocidade, espaço e conectivida-

de) influenciam fortemente a estrutura de servidores Multimídia e políticas de otimização usa-

das para melhorar a performance.

É desejável usar utilitários padrões (como programas de backup) para administrar servi-

dores Multimídia. Isto pode ser alcançado se ele for esquematizado em termos de Sub-compo-

nentes Lógicos Padrões. Por exemplo, se o componente de armazenamento do servidor Multi-

mídia é esquematizado como um sistema de arquivo (promovendo uma interface de sistemas

de arquivos), ele pode ser recuperado por programas de backup padrões (Sitaran, 2000).

3.4.Sistemas Distribuídos

Um Sistema Distribuído (SD) é constituído por componentes, localizados em uma rede

de computadores, que se comunicam e coordenam suas ações apenas pela troca de mensagens

(Coulouris, 2001). Os Sistemas Distribuídos são utilizados como requisitos físicos básicos de

interligação de aplicações colaborativas e, portanto, são essenciais para o projeto e construção

das mesmas. Uma definição mais refinada, que enfatiza o aspecto da colaboração de SD, é

feita por Sloman (1994): “um SD é composto por um número de processadores autônomos

e/ou armazenadores de dados suportando processos e/ou base de dados que interagem

colaborativamente para alcançar uma meta comum. Os processos coodenam suas atividades e

trocam informações por meio da transferência de informações por rede de comunicação”.

Existe, entretanto, a necessidade de alguma forma de administração e controle geral do

sistema. A computação distribuída se torna complicada pelo fato da comunicação entre os

processos ser assunto de atrasos e falhas. Além disso, o “estado” geral do sistema é

particionado e distribuído sobre os processadores e armazenadores de dados constituintes.

Portanto, não existe uma visão global coerente. A administração do sistema deve, entretanto,

ser capaz de tomar decisões baseadas em informações parciais.

33

O compartilhamento de recursos é a principal motivação para a construção de SD. Re-

cursos podem ser administrados por servidores a acessados por clientes ou podem ser encap-

sulados como objetos e acessados por outros objetos de clientes. A Internet é um bom exem-

plo de compartilhamento de recursos.

Os SD permitem uma estrutura mais geral e modular para emparelhar a estrutura da

aplicação e as necessidades dos usuários; e assim permitem também o uso de seu potencial

para construir extensões logo que as necessidades surgem. Esta flexibilidade gera benefícios

no custo; como foi mencionado anteriormente, um dos principais benefícios é a habilidade de

suportar o compartilhamento de recursos e serviços: recursos caros podem ser acessados pela

rede e compartilhados entre os usuários do sistema.

O principal desafio é promover esses benefícios de uma maneira transparente e robusta.

A transparência refere-se à capacidade que os recursos e serviços têm de permitir que o

usuário ou o programador da aplicação não fique ciente de sua distribuição. Outros desafios,

que surgem na construção de SD, são: a heterogeneidade de seus componentes, a abertura

(que permite que novos componentes sejam adicionados ou trocados), a segurança, a escalabi-

lidade (habilidade de trabalhar bem quando o número de usuários aumenta), a tolerância à fa-

lhas, a concorrência entre componentes e a transparência. A seguir são citados três exemplos

de SD:

i. A Internet (uma grande coleção de diferentes tipos de computadores interco-

nectados mundialmente);

ii. Uma Intranet (uma porção da Internet administrada por uma organização); e

iii. A computação móvel e ubíqua (por exemplo, laptops, telefoneis móveis e dis-

positivos vestíveis).

Os potenciais benefícios oferecidos pelos SD são muitos. Alguns procuram explorar seu

potencial para melhorar a disponibilidade do sistema pelo uso de replicação e remoção de

pontos de falhas. Outros procuram um ganho de performance melhorando o tempo de resposta

do processamento local e/ou o throughput pelo uso do processamento paralelo.

3.4.1.Sistemas Distribuídos e Realidade Virtual

Para se utilizar uma simulação de RV em tempo real é necessário fazer uma distribuição

da carga de processamento, ou seja, dividir tarefas entre as várias estações-de-trabalho se co-

municando via rede (Burdea, 1994), como por exemplo, utilizar as próprias máquinas dos

34

usuários para o processamento das imagens locais de seu ponto de vista do AV, e não ficar

completamente dependente de que algum servidor central (máquina responsável pelo controle

da simulação) que lhe forneça estas imagens processadas, além de estar responsável pelo con-

trole da simulação distribuída. A distribuição em rede tem a vantagem de usar, na simulação,

os computadores existentes sem a necessidade de se adquirir novas estações-de-trabalho dedi-

cadas. Outra vantagem é a possibilidade de computadores remotos acessarem e participarem

da simulação. Isto, portanto, torna possível utilizar simulações multi-usuário, e portanto cola-

borativas, em RV.

Um problema relacionado aos SD e à RV é a necessidade da continuidade da simulação

caso a comunicação for interrompida. A simulação não deve ser completamente interrompida

se acontecer algum problema com uma das múltiplas máquinas do sistema de RV, mas deve

continuar nas outras máquinas remanescentes (Burdea, 1994). Tal problema foi enfrentado

pelo simulador do exército, chamado SIMNET, que tinha 200 servidores distribuídos mundi-

almente. A solução foi o “dead reckoning”, ou continuação local da simulação, baseada na

aproximação premeditada das ações e localizações dos outros participantes. A desvantagem,

neste caso, é a falta de precisão das posições.

Existem muitas similaridades entre os banco-de-dados “cliente-servidor” e a RV distri-

buída, sendo que os AV podem ser considerados como banco-de-dados, acessíveis em tempo

real (Pimentel e Blau apud Burdea, 1994). Ambos utilizam o conceito “cliente-servidor”. O

servidor é a máquina central que coordena a maioria das atividades da simulação. Ele tem a

responsabilidade de manter o controle de todos os objetos virtuais na simulação. Processos

clientes controlam a simulação local, a interação com ferramentas de Entrada/Saída e executa

a renderização (processo de construção de imagens) dos gráficos.

No caso onde os próprios servidores estão distribuídos, cada servidor coordena a simu-

lação (e seus clientes) em diferentes máquinas. A comunicação entre os servidores deve ser

minimizada para não sobrecarregar a rede, e para permitir uma simulação colaborativa em

tempo real. Isto significa que uma quantidade mínima de mensagens deve ser enviada (por ex-

emplo, apenas mudanças na posição ou criação/destruição de um objeto virtual).

Problemas adicionais surgem quando servidores não estão “emparelhados” em um mes-

mo poder computacional. Neste caso, o servidor mais rápido irá mandar muitas mensagens

(correspondendo às mudanças de estado da RV), e o servidor mais lento irá perder muito tem-

po lendo estas mensagens ao invés de coordenar a simulação local. Como resultado, as latên-

cias do servidor mais lento são aumentadas cada vez mais. Em um sistema de dois usuários,

35

os dois servidores podem ser configurados para reduzir o número de conjunto de dados envia-

dos pelo servidor mais rápido. Outra possibilidade para reduzir a latência na rede é simples-

mente escolher o mesmo tipo e modelo de máquinas como servidores em ambos os lados. In-

felizmente, isto não é prático em grandes sistemas multi-usuário.

Como os SD permitem a colaboração multi-usuário, eles são requisitos fundamentais

para a construção de sistemas colaborativos utilizando AVCs e, portanto, devem ser conside-

rados como base para a especificação do protocolo padrão para ambientes colaborativos utili-

zando Realidade Virtual na WWW.

3.4.2.Características de Sistemas Distribuídos

Existem algumas características que são comuns aos softwares de um SD. A seguir es-

tão indicadas algumas preocupações de sua construção:

Nomeação

A nomeação é a identificação do que é visto. Isto pode ser contrastado com endereça-

mento (que indica a localização) e roteamento (que indica como chegar na localização) (Sho-

ch apud Sloman, 1994). É necessário que os nomes sejam únicos (ou que sejam arranjados de

modo a identificar qualquer componente ou objeto unicamente), sejam capazes de serem co-

municados eficientemente, sejam independente da localização (para permitir a migração) e

devam suportar o compartilhamento.

Esquemas de nomeação local suportam o uso de nomes concisos, mas que devem ser

mapeados para algum esquema de individualização e interação global. Esquemas de nomea-

ção global obrigam a singularidade e uniformidade, mas são difíceis de se usar e manter.

A maioria dos sistemas usa uma forma hierárquica de nomeação que é dividida de modo

a promover individualização com o contexto local, mas que podem ser estendida com o con-

texto de nomes para dar uma maior individualidade global quando requerida (por exemplo,

números de telefones que podem ser estendidos pelos códigos da área e país).

Sincronização

36

A administração e controle de SD e paralelos requerem a sincronização para, em ordem,

coordenar e obrigar a exclusão mútua durante o acesso a recursos compartilhados e, geral-

mente, para preservar estados consistentes (Sloman, 1994). Existem alguns algoritmos que

forçam a exclusão mútua por sincronização das atividades relacionadas.

Em geral, os aprofundamentos centralizados são mais simples e eficientes, mas menos

robustos e mais sucessíveis a gargalos. As técnicas descentralizadas superam esses proble-

mas, mas são mais complexas.

Controle de Erros

Os SD potencialmente oferecem confiabilidade e disponibilidade. Entretanto, ser consti-

tuído por mais de uma entidade também implica na existência de uma grande probabilidade

de falhas em uma delas, tal como falhas de comunicação ou falhas na execução de um proces-

so remoto.

Técnicas de detecção de falhas geralmente empregam redundâncias como paridade, che-

cagem de dados replicados ou aprofundamentos baseados em tempo (como um timeout para

falta de resposta). A recuperação para um estado consistente pode envolver tanto uma recupe-

ração para frente (no caso da operação ser repetida ou alguma forma de ação compensatória

ser executada), ou para trás (para desfazer efeitos inaceitáveis e levar a um estado consistente

anterior).

Na prática, as estratégias variam de acordo com a freqüência e tipos de erros. Por exem-

plo, uma das mais simples estratégias é empregar operações periódicas onde tais operações

são idempotentes. Quando isto não é o caso, transações atômicas talvez devam ser emprega-

das.

Administração de Recursos

Como descrito anteriormente, recursos distribuídos e compartilhados promovem uma

das principais atrações do processamento distribuído (Sloman, 1994). Entretanto, eles devem

ser cuidadosamente administrados para prevenir interferências e garantir alocações eficientes.

Um dos objetivos de tal administração é aumentar a performance, enquanto reduz o tempo de

resposta e/ou aumenta o throughput.

37

Em muitos casos, um compromisso é necessário: a administração deve também atuar na

prevenção de deadlocks, congestionamentos e monopólio de um recurso por qualquer cliente.

O objetivo é promover alguma forma de justiça. Como antes, as técnicas variam desde sim-

ples aprofundamentos centralizados (que são mais eficientes, porém mais sucessíveis a garga-

los) a administradores de recursos descentralizados (que retém autonomia local, mas reque-

rem protocolos mais complexos).

Administração da Qualidade de Serviço

A integração do suporte a sistemas Multimídia distribuídos em arquiteturas de comuni-

cação é importante para a realização da próxima geração de padrões de sistemas abertos; isto

também é um desafio técnico significante (Sloman, 1994).

Uma observação chave é que a Qualidade de Serviço (QOS – Quality of Service) pro-

move um tema unificado, no qual funções e facilidades dos novos padrões integrados possam

ser construídas. Para futuras aplicações, especialmente aquelas altamente interativas e que

confiam na transferência da informação Multimídia, é essencial que a QOS seja um sistema

amplamente garantido, incluindo a plataforma de sistema distribuído e protocolo de transpor-

te.

O protocolo de comunicação suporta negociações QOS fim-a-fim, renegociações e indi-

cação das degradações da QOS e é necessária, portanto, uma coordenação sobre múltiplas co-

nexões relacionadas.

Controle de Congestionamento

A imprevisível flutuação na estatística dos fluxos de tráfego é a principal causa para o

congestionamento em redes de alta velocidade. Portanto, os mecanismos de controle reativos

e preventivos são importantes no projeto de redes (Raghavan, 1998).

O controle de congestionamento reativo refere-se à regulagem do fluxo de tráfego nos

pontos de acesso, quando ocorrem congestionamentos na rede. Para isto, é necessário um me-

canismo de feedback (com um tempo adequado de reação). Conseqüentemente, os mecanis-

mos de controle de congestionamento reativos podem não ser considerados atraentes para

Aplicações Multimídia.

Ao contrário, o mecanismo preventivo tenta prevenir a rede de alcançar um nível inacei-

tável de congestionamento. Este aprofundamento é mais bem utilizado em redes orientadas à

38

conexão, como redes ATM, porque a decisão de admitir uma nova conexão pode ser feita ba-

seando-se no conhecimento do estado da rota proposta pela nova conexão.

3.4.3.Compartilhamento de Recursos e a Internet

Os usuários estão tão acostumados aos benefícios do compartilhamento de recursos

que muitas vezes negligenciam seu significado (Coulouris, 2001). Diariamente compartilha-

mos recursos de hardware (como impressoras), recursos de dados (como arquivos) e recursos

com funcionalidades mais específicas (como motores de busca).

Olhando para o ponto de vista do hardware, o compartilhamento é feito para a redução

de custos. Mas a maior significância para os usuários é o compartilhamento de recursos de

alto-nível. Por exemplo, os usuários estão acostumados com o compartilhamento de dados na

forma de banco de dados compartilhados ou conjuntos de páginas Web, não com os discos e

processadores nos quais eles estão inseridos. Similarmente, os usuários pensam em termos de

recursos compartilhados, como em uma máquina de busca, sem considerar o servidor(es) que

os sustentam.

Na prática, padrões de compartilhamento de recursos variam enormemente em seus es-

copos e em quanto os usuários trabalham em conjunto. Em um extremo, uma máquina de bus-

ca promove facilidades para usuários ao redor do mundo; usuários que nunca precisaram en-

trar em contato uns com os outros diretamente. No outro, existe o CSCW, no qual um grupo

de usuários colabora diretamente compartilhando recursos (como documentos) em grupos fe-

chados. O padrão de compartilhamento e distribuição geográfica dos usuários determina quais

mecanismos o sistema deve suportar para coordenar as ações dos usuários.

Os recursos em um SD estão fisicamente encapsulados nos computadores e podem so-

mente ser acessados, por outros computadores, através da comunicação. Para um compartilha-

mento efetivo, cada recurso deve ser administrado por um programa que oferece uma interfa-

ce de comunicação permitindo que o recurso seja acessado e atualizado confiável e consisten-

temente (Coulouris, 2001).

O termo servidor refere-se a um programa (um processo) rodando em um computador,

conectado à rede, que aceita pedidos de programas rodando em outros computadores para

executar um serviço e responder apropriadamente. Os processos requerentes são chamados de

clientes. Pedidos são enviados em mensagens do cliente ao servidor e respostas são enviadas

em mensagens do servidor para o cliente.

39

Quando um cliente envia um pedido para que uma operação seja executada, dizemos

que o cliente “invocou” uma operação no servidor. A interação completa entre um cliente e

um servidor, do ponto onde o cliente envia um pedido até o recebimento de sua resposta envi-

ada pelo servidor, é chamada de invocação remota. Um mesmo processo pode ser tanto clien-

te como servidor, uma vez que servidores podem invocar operações em outros servidores oca-

sionalmente.

Muitos SD, mas certamente não todos, podem ser construídos inteiramente na forma de

interação entre clientes e servidores. A WWW, o e-mail e as impressoras em rede se ajustam à

este modelo. Um navegador Web é um exemplo de um cliente. Ele se comunica com um ser-

vidor Web para lhe solicitar páginas.

3.4.4.Comunicação em Grupo

Em geral, a comunicação pode ser classificada, segundo (Raghavan, 1998), como:

i. Ponto-a-Ponto;

ii. Ponto-a-Muntiponto; e

iii. Muntiponto-a-Muntiponto.

Esta classificação é baseada no fato de que existem múltiplas fontes e/ou destinos e é

conhecida como unicast se for ponto-a-ponto e multicast se for ponto-a-multiponto. A troca

de mensagens entre pares de processos não é o melhor modelo de comunicação de um proces-

so a um grupo de outros processos. Uma operação multicast é mais apropriada – esta é uma

operação que envia a mesma mensagem de um processo para cada um dos membros de um

grupo de processos, usualmente de um modo transparente ao remetente. Existe um conjunto

de possibilidades no comportamento desejado de um multicast. O mais simples não fornece

nenhuma garantia sobre a entrega ou ordenação da mensagem. Mensagens multicast promo-

vem uma infraestrutura útil para a construção de SD com algumas características, segundo

Coulouris (2001):

i. Tolerância à falhas baseada em serviços replicados : Um serviço replicado con-

siste em um grupo de servidores. Os pedidos dos clientes são multicast para to-

dos os membros do grupo, cada qual executa uma operação idêntica. Mesmo que

algum dos membros falhe, os clientes podem continuar sendo servidos.

ii. Melhoria da performance utilizando-se dados replicados: Dados são replicados

para aumentar a performance de um sistema – em alguns casos, réplicas dos da-

40

dos são inseridas nos computadores dos usuários. Cada vez que os dados são al-

terados, o novo valor é enviado por multicast a todos os processos administrando

as réplicas.

iii. Propagação de eventos de notificação: O multicast para um grupo pode ser usa-

do para notificar processos quando algo ocorre. Por exemplo, um sistema de no-

tícia deve notificar usuários interassados quando uma nova mensagem foi posta-

da em um grupo de notícias específico.

3.5.O Protocolo TCP/IP

Protocolos são os padrões que especificam como os dados são apresentados ao serem

transferidos de uma máquina para outra. Eles especificam como ocorrem as transferências,

como os erros são detectados e como as confirmações são transmitidas (Comer, 1998). Segun-

do Coulouris (2001), a definição de protocolo tem duas importantes características:

i. Uma especificação da seqüência de mensagens que devem ser trocadas;

ii. Uma especificação do formato dos dados nas mensagens.

A existência de protocolos bem-conhecidos permite que componentes de software se-

parados de um SD sejam desenvolvidos independentemente e implementados em diferentes

linguagens de programação em computadores que podem ter ordem de códigos e representa-

ções de dados diferentes.

Para simplificar o projeto de protocolos e de suas implementações, os problemas de

comunicação são separados em subproblemas que podem ser resolvidos de forma indepen-

dente. A cada subproblema é atribuído um protocolo à parte.

A idéia da divisão em camadas é fundamental porque fornece uma estrutura conceitual

para o projeto do protocolo. Em um modelo dividido em camadas, cada camada trata de uma

parte do problema de comunicações e geralmente corresponde a um protocolo.

Os protocolos seguem o princípio da divisão em camadas, que determina que o

software que está implementando a camada n na máquina de destino recebe exatamente aqui-

lo que o software que está implementando a camada n na máquina de origem envia.

Na prática, o software de protocolo usa multiplexação e demultiplexação para estabe-

lecer uma distinção entre os protocolos múltiplos situados em determinada camada, tornando

o software de protocolo mais complexo do que sugere o modelo da divisão em camadas.

41

3.5.1.IP (Internet Protocol)

O serviço mais importante oferecido pelo software de interligação em redes TCP/IP é

um sistema de transmissão de pacotes sem conexão, não-confiável e sem garantia. O Internet

Protocol (IP) formalmente especifica o formato de pacotes da interligação em redes denomi-

nados datagramas e inclui informalmente as idéias de transmissão sem conexão (Comer,

1998).

O protocolo IP é usado por outros protocolos de nível superior, tais como o TCP

(Transmission Control Protocol) e o UDP (User Datagram Protocol). Ele fornece um serviço

de transferência de dados independente da implementação da camada de ligação lógica. A in-

dependência relativa às camadas inferiores, e um esquema de encaminhamento, asseguram a

comunicação através de redes heterogêneas concatenadas.

Uma transferência de dados entre dois nós usando o protocolo IP pode seguir um ca-

minho em que os dados são transportados pelas mais diversas tecnologias de nível inferior,

tais como Ethernet, Token-Ring, ATM, X.25, FDDI, etc. Este fato é totalmente transparente

para os nós finais.

O mecanismo de endereçamento é também independente dos níveis inferiores e na In-

ternet uma administração hierárquica assegura que cada nó possui um endereço universal. Na

camada IP, um endereço de destino identifica um host; nenhuma outra distinção é feita com

referência a qual usuário ou qual programa aplicativo receberá o datagrama (Comer, 1998).

3.5.2.Datagramas IP

O protocolo IP disponibiliza um serviço base de transferência de dados baseado em

datagramas. Cada datagrama é totalmente independente dos restantes (serviço não-orientado à

conexão) e trata-se de um serviço não-confiável:

i. Não há controle de erros ou fluxo (nem entre nós intermediários, nem entre nós

finais);

ii. A detecção de erros é apenas assegurada para o cabeçalho dos datagramas.

Apesar do caráter elementar do serviço de datagramas do protocolo IP, são incluídos

alguns mecanismos que o tornam especialmente adequado para comunicações à longa distân-

cia através da concatenação de infra-estruturas de comunicação heterogêneas:

42

i. Esquema de endereçamento simples e universal com facilidades para os

mecanismos de encaminhamento;

ii. Mecanismo de fragmentação e re-agrupamento que assegura uma passagem

eficiente dos datagramas IP através de infra-estruturas com tamanhos máximos

de pacote diversos;

iii. Definição de Qualidade do Serviço (QOS – Quality of Service) e Tempo de Vida

(TTL – Time to Live) dos pacotes.

iv. Notificação de alguns erros básicos via ICMP (Internet Control Message

Protocol).

3.5.3.UDP (User Datgram Protocol)

Na pilha de protocolos TCP/IP, o User Datagram Protocol, ou UDP, fornece o meca-

nismo principal utilizado pelos programas aplicativos para enviar datagramas a outros progra-

mas iguais. O UDP fornece Portas de Comunicação de Protocolo para estabelecer a distinção

entre os diversos programas executados em uma única máquina. Isto é, além dos dados envia-

dos, cada mensagem UDP contém um número de porta de destino e também um número de

porta de origem, tornando possível que o software UDP, no destino, entregue a mensagem ao

destinatário certo e possibilitando, ao destinatário, enviar uma resposta (Comer, 1998).

A definição de números de porta é fundamental para permitir mais do que um destino

em cada máquina. Em um sistema operacional multi-processado, cada processo que utiliza a

rede requisita uma porta ("abertura de porta") que lhe fica associada e todos os dados que che-

gam à máquina com essa porta de destino são encaminhados para esse processo. Tanto o UDP

como o TCP, implementam números de porta, mas elas são independentes umas das outras.

O sistema operacional garante que, em uma dada máquina, cada porta é utilizada por

apenas um processo. As portas de número inferior a 1024 são reservadas para serviços especí-

ficos e conhecidas como "portas bem conhecidas" (“Well Known Ports”).

O UDP usa o Internet Protocol (IP) implícito para transportar uma mensagem de uma

máquina a outra e, como o IP, fornece a mesma conotação não-confiável de transmissão de

datagrama sem conexão. Não usa confirmação para certificar-se de que as mensagens che-

gam, não ordena mensagens de entrada e não fornece informação para controlar a velocidade

com que as informações fluem entre as máquinas. Assim, as mensagens UDP podem se per-

43

der, ser duplicadas ou chegar com problemas. Mais ainda, os pacotes podem chegar mais rápi-

do do que podem ser processados pelo destinatário (Comer, 1998).

O cabeçalho UDP é muito reduzido, é constituído por 4 campos de 16 bits cada:

i. Porta de Origem;

ii. Porta de Destino;

iii. Comprimento do "datagrama" (Cabeçalho UDP + Dados);

iv. Checksum (Soma de Verificação) de todo o datagrama (Pseudocabeçalho IP +

Cabeçalho UDP + Dados).

Um programa aplicativo que usa UDP aceita a inteira responsabilidade para lidar com

o problema de confiabilidade, inclusive perda de mensagem, duplicação, retardo, transmissão

defeituosa e perda de conectividade. O protocolo IP não pode ser diretamente usado pelas

aplicações porque não utiliza números de porta. A funcionalidade acrescentada pelo UDP ao

IP limita-se à definição de números de Portas de Comunicação do Protocolo (identificada por

um número inteiro positivo) e Checksum sobre todo o datagrama (incluindo dados).

3.5.4.TCP (Transmission Control Protocol)

Ao contrário do protocolo UDP, o TCP representa um grande aumento de qualidade

relativo ao protocolo IP, que lhe serve de base. O objetivo do protocolo TCP é fornecer um

serviço confiável de comunicação entre aplicações, baseado no conceito de conexão. Por isso,

antes do envio e recepção de dados é necessário estabelecer a conexão. Para este efeito é ne-

cessário que duas aplicações colaborem entre si. Uma aplicação deverá estar disponível para

receber a conexão TCP e a outra aplicação deverá enviar o pedido de conexão.

O TCP utiliza o serviço não-confiável de datagramas do nível IP. Dada a enorme dife-

rença entre o tipo de serviço usado e o tipo de serviço fornecido, a implementação do TCP é

muito mais complexa do que a do UDP.

Para garantir um serviço confiável, o TCP utiliza uma técnica única e fundamental co-

nhecida como “confirmação positiva com retransmissão”. A técnica exige que um receptor

comunique-se com a origem, retornando uma mensagem de confirmação (ACK), à medida

que recebe os dados. O transmissor mantém um registro de cada pacote que envia e espera

uma confirmação antes de enviar o próximo pacote. O transmissor também inicia um tempori-

44

zador quando envia um pacote, e retransmite um pacote se esse temporizador se completar an-

tes que chegue uma confirmação (Comer, 1998).

O TCP define um serviço importante de transmissão confiável de stream (Fluxo) de

dados. Ele proporciona uma conexão full duplex entre duas máquinas, permitindo que

troquem grandes volumes de dados com eficiência.

Já que utiliza um protocolo de janela deslizante, o TCP pode usar uma rede com

eficiência. Como faz algumas suposições sobre o sistema básico de entrega, o TCP é

suficientemente flexível para operar em uma ampla variedade de sistemas de entrega. E como

oferece um controle de fluxo, permite que sistemas de velocidades amplamente variáveis se

comuniquem.

A unidade básica de transferência utilizada pelo TCP é o segmento. Os segmentos são

utilizados para transferir dados ou controlar informações (por exemplo, para permitir que o

software TCP de duas máquinas estabeleça conexões ou as interrompa). O formato do

segmento permite que uma máquina faça um piggyback de confirmação para os dados que

estão fluindo em uma direção, quando os inclui nos cabeçalhos do segmento de dados que

fluem na direção oposta.

O TCP implementa o controle de fluxo levando o receptor a informar a quantidade de

dados que espera aceitar. Ele também suporta mensagens urgentes, através de um mecanismo

de dados urgentes, e força a transmissão através de um mecanismo de push.

Portanto, considera-se uma conexão TCP como sendo um canal dedicado de comuni-

cação entre duas aplicações com as seguintes características:

i. Os dados são enviados e recebidos em stream, não existindo o conceito de

mensagem ou datagrama;

ii. Os eventuais erros de transmissão são corrigidos de forma transparente para as

aplicações;

iii. É implementado um controle de fluxo baseado no protocolo de Janela

Deslizante;

iv. Os dados chegam ao destino na mesma ordem em que foram emitidos;

v. Tal como acontecia para o UDP, são definidos números de Porta de

Comunicação de Protocolo para multiplexar o acesso ao TCP por várias

aplicações residentes na mesma máquina;

vi. Uma conexão é uma ligação privada entre duas aplicações. Uma conexão entre

duas aplicações A e B é identificada pelo conjunto (IP A, porta A; IP B, porta

45

B). Já que o TCP identifica uma conexão como um par de pontos terminais,

determinado número de portas TCP pode ser compartilhado por várias conexões

na mesma máquina (Comer, 1998).

3.5.5.Máquina de Estados Finitos do TCP

Conceitualmente, o TCP usa uma máquina de estados finitos para controlar todas as

interações. Cada extremidade de uma conexão TCP implementa uma cópia da máquina de es-

tados e a utiliza para controlar ações efetuadas quando um segmento chega. A Figura 3 apre-

senta a máquina de estado finito do TCP e as transições entre estados.

Na teoria, a máquina de estados finitos especifica completamente o modo pelo qual o

TCP de uma máquina interage com o TCP de outra. Na prática, porém, a máquina de estados

finitos não especifica totalmente as interações. Em vez disso, a máquina especifica apenas o

estado macroscópico do TCP ao passo que variáveis adicionais dão prosseguimento à

especificação dos detalhes ou do estado microscópico. E, o mais importante, como as

transições macroscópicas especificadas pela máquina de estado finito não controlam saída ou

retransmissão, tais eventos precisam ser tratados separadamente.

Figura 3 - A Máquina de Estado Finito do TCP (Comer, 1999).

46

3.6.Considerações Finais

Para o bom desenvolvimento de um trabalho em grupo, é necessária uma grande intera-

ção entre as pessoas que o compõe. Esta é a principal dificuldade encontrada em ambientes de

trabalho colaborativo, pois envolve complexidade de assuntos, dificuldade de reunir os inte-

grantes no mesmo instante e local e necessidade de visualização e manipulação de grandes

volumes de informações.

A maioria das aplicações Multimídia (cuja disciplina serve como base para a construção

de aplicações de RV), é destinada a monousuários. Entretanto, elas permitem o desenvolvi-

mento de aplicações multiusuários tal que eles possam se comunicar, interagir e colaborar uns

com os outros aumentando assim sua eficiência e produtividade. Portanto, a Multimídia ofere-

ce as características chaves para a construção de aplicações de CSCW em tempo real utilizan-

do AVC; juntamente com os recursos de um SD, que são computadores autônomos, com pro-

cessamentos independentes, fisicamente distribuídos e que se comunicam entre si formando

um sistema único e transparente ao usuário.

Portanto, os SD possuem grande utilidade na construção de sistemas colaborativos, pois

permite que um grupo de computadores e seus usuários trabalhem em conjunto e formem um

sistema único para a obtenção de uma meta comum, pois permitem a comunicação, interação

e colaboração entre seus usuários e o compartilhamento de seus recursos físicos e lógicos.

47

4. Especificação

4.1.Objetivos do Projeto

O principal objetivo deste projeto é especificar e elaborar um protocolo padrão que

permita a utilização de um Ambiente Virtual Colaborativo (AVC) através da WWW e, com

isso, a interação e colaboração em tempo real entre os usuários presentes no ambiente. Assim,

foi feito um estudo detalhado de toda a teoria e tecnologias envolvidas no projeto de sistemas

de Trabalho Colaborativo Auxiliado por Computador utilizando Realidade Virtual, abordando

tópicos como Interação Homem-Computador, Multimídia e Sistemas Distribuídos, conforme

descritos nos capítulos anteriores. Portanto, este protocolo terá a finalidade de facilitar o

trabalho colaborativo entre várias pessoas com objetivos específicos e, assim, tornar mais

fácil a comunicação e a produtividade em grupo, permitindo que outros projetistas de

aplicações de AVC o utilizem como base para o controle colaborativo e possam então reter

seus maiores esforços na construção das características funcionais de suas próprias aplicações,

anteriormente direcionados fortemente aos aspectos da comunicação.

Como uma das principais características da Internet é permitir a comunicação de

diferentes máquinas e arquiteturas ao redor do mundo (multiplataforma), o protocolo deve

48

levar em consideração esta característica. Por isso será utilizado o modelo de Realidade

Virtual não-imersiva utilizando a plataforma WWW, pois o mesmo permite a utilização da

RV através de diferentes sistemas operacionais e periféricos comuns, baratos, e existentes na

maioria dos computadores atuais como monitores, teclados e mouses.

4.2.Especificação do Protocolo

A maioria dos problemas atualmente relacionados à implementação de Ambientes

Virtuais Colaborativos está relacionado com suporte à comunicação (Meiguins, 2003).

Portanto, o objetivo principal deste projeto é especificar um protocolo de Trabalho

Colaborativo Auxiliado por Computador utilizando Realidade Virtual na plataforma WWW

para permitir que diversas aplicações colaborativas, que utilizem esta plataforma, possam se

beneficiar dos recursos de comunicação e controle oferecidos por este novo protocolo. Assim,

ao invés de se preocuparem com as questões de comunicação nelas envolvidas, possam

focalizar-se completamente em seu desenvolvimento e determinação de seus próprios

requisitos funcionais, aumentando assim a eficiência e complexidade de suas operações.

Para a especificação deste protocolo, foi necessário um estudo sobre o principal

protocolo de comunicação da Internet, o TCP/IP, descrito anteriormente com maiores detalhes

e no qual este novo protocolo se baseará, ou seja, utilizará seus recursos básicos de

comunicação para poder executar o controle do sistema colaborativo. Muita da variada

funcionalidade associada à pilha de protocolos TCP/IP resulta de uma variedade de serviços

de alto nível fornecidos por aplicativos. Os protocolos de alto nível que esses programas usam

são baseados em serviços básicos: entrega de datagrama não-confiável e transporte de stream

confiável. Geralmente, eles seguem o modelo cliente/servidor no qual os servidores operam

em portas de protocolos conhecidas, de modo que os clientes saibam como contatá-los.

4.3.Funcionalidades do Protocolo

As funcionalidades oferecidas pelo protocolo, em relação às aplicações em RV na

WWW que o utilizarão, incluem o controle e administração do AVC, seus objetos e seus

usuários, assim como o controle de todo o fluxo de mensagens necessário no sistema. O

49

protocolo a ser criado deve dar suporte aos mais variados tipos de aplicações (cobrindo todas

as áreas de atividades da sociedade como pesquisa, treinamento e lazer) e conter algumas

características básicas como, segundo Pinho (2002):

i. Advertência: Visualização, para um usuário, das ações executadas por seus

parceiros;

ii. Evolução: Construção de técnicas cooperativas como extensões naturais de

técnicas mono-usuário, com o objetivo de tirar proveito do conhecimento pré-

existente do usuário (ou seja, permitir a criação de aplicações colaborativas a

partir de aplicações mono-usuário);

iii. Transição: Transição de operações mono-usuário para colaborativas com uma

junção natural, sem nenhuma utilização de comandos específicos ou

descontinuidade do processo de interação;

iv. Reutilização: Facilitação da implementação de novas técnicas de interações

colaborativas, permitindo a reutilização do código existente.

O protocolo especificado se baseia no protocolo TCP/IP (que é a pilha de protocolos

mais utilizada atualmente em redes locais e se tornou a base da Internet) e pode ser

classificado como pertencente à sua Camada de Aplicação (a mais alta camada da pilha de

protocolos, que utiliza todos os protocolos das outras camadas inferiores, como o TCP/UDP e

IP).

4.4.Características de Controle do Protocolo

Para simplificar a especificação e implementação do protocolo e, ao mesmo tempo,

facilitar o controle e administração da simulação, uma topologia Centralizada (onde os

usuários compartilham exatamente a mesma cópia do AVC, que fica localizada no servidor) é

a mais adequada para este projeto pois é mais facilmente gerenciável, apesar de ser mais

suscetível a falhas e ter uma escalabilidade limitada. Esta topologia fornecerá uma

continuidade da simulação aos clientes (caso algum nó da rede falhe, com exceção do

servidor) e facilitará o controle de todos os recursos de comunicação do sistema necessários

para o bom andamento da simulação.

50

Uma maior interação entre os usuários pode ser adquirida utilizando-se uma

combinação de um sistema síncrono e em tempo real (isto permite por exemplo, ao ocorrer

uma falha de comunicação, retirar o usuário da simulação e informar automaticamente todos

os outros usuários sobre tal retirada). Este tipo de sistema também necessita fornecer repostas

rápidas, ou seja, uma rápida troca de mensagens de controle pelo protocolo (para que o senso

de continuidade da simulação não seja perdido por motivo de interrupções); e confiáveis (para

que as simulações sejam corretamente executadas). Estas características podem ser

referenciadas como exigências da QoS de cada aplicação que utilizar o protocolo criado.

Portanto, será utilizado como base o protocolo TCP, que garante uma comunicação confiável

entre qualquer par de nós de uma rede de computadores.

É necessário permitir que diferentes simulações ocorram ao mesmo tempo e que um

usuário possa participar de mais de uma simulação no mesmo momento. Isso pode ser obtido

utilizando Seções (que podem ser consideradas abstrações lógicas que diferenciam várias

simulações ocorrendo no mesmo instante) completamente independentes umas das outras, que

poderão ter diferentes administradores, AVs e usuários. Portanto, o protocolo deve fornecer

um meio de criação e exclusão de Seções no sistema (utilizando mensagens de criação e

exclusão de Seções, descritas com maiores detalhes posteriormente).

O protocolo deve utilizar fluxos de mensagens entre os clientes e o servidor, e vice-

versa, para executar a troca de informações de controle que deverão ser armazenadas em uma

Classe de Controle de Acesso (CCA) por Seção criada, permitindo, assim, que diferentes

simulações multiusuário em tempo real possam ser executadas corretamente e

concorrentemente. O acesso à essas classes deve ser protegido contra acessos simultâneos de

vários usuários, garantindo assim a sua consistência.

A CCA, para representar os usuários e os objetos do AVC, deve conter todas as

funções necessárias para a manipulação de suas propriedades. Portanto, ao receber uma

mensagem de criação de Seção, por exemplo, o servidor deve criar um novo objeto do tipo

CCA (sendo este considerado uma nova Seção), que automaticamente conterá todas as

propriedades de controle da nova Seção criada. Para o controle de todas as Seções em atual

execução no sistema, esta nova Seção deve ser referenciada em uma outra classe (única no

sistema), a Classe de Controle de Seções (CCS), permanecendo lá até a sua exclusão. Sendo

assim, a CCS conterá várias CCA (tanto quanto as Seções existentes no momento). A Figura

4 mostra o Diagrama de Classes do Protocolo:

51

Figura 4 – Diagrama de Classes do Protocolo

As CCS e as CCA deverão estar inteiramente localizadas no servidor (para evitar

inconsistências). Entretanto, cada usuário deve manter uma cópia local da CCA da seção na

qual está inserido servindo como base para a construção de sua visualização do AVC.

Portanto, as CCA do servidor, quando alteradas, deverão informar automaticamente seus

usuários para que possam atualizar suas respectivas CCA locais para poderem, assim,

construir suas respectivas visualizações. A CCA deve conter as seguintes propriedades:

i. Usuários de Seção: Informa todos os usuários da Seção, incluindo suas

características comportamentais (como sua posição e orientação) e visuais

(como seu modelo tridimensional e sua cor ou textura).

ii. Permissões: Informa o nível do usuário em relação ao sistema, definindo suas

permissões. Esse nível poderá ser utilizado por aplicações para restringir o

acesso às suas áreas de controle, que devem ser protegidas por permitem

alterações nas restrições de interação dos usuários no AVC. Os níveis podem

ser divididos em três tipos: Nível 0 (Root) – O usuário mestre do sistema (deve

ser único), que não deve ter qualquer restrição de acesso e será responsável

pela supervisão de todas as Seções. Ele pode utilizar o método espião em todas

as Seções, ou seja, ele pode visualizar as ações dos outros usuários sem ser

percebido; Nível 1 (Adminstrador) – O usuário responsável pela administração

de uma Seção, definindo todas as restrições de seu respectivo AVC e seus

usuários (não deve ter qualquer restrição de acesso às áreas de controle de seu

AVC). Também pode utilizar o método espião, mas somente em sua respectiva

Seção; e Nível 2 (Usuário) – Usuário comum do sistema, que é suscetível a

todas as restrições impostas pelo administrador do AVC no qual ele está

participando (especificadas pelo Estado Atual do Usuário, descrito

posteriormente).

52

iii. Estado Atual do Usuário: Informa a capacidade de interação do usuário com o

sistema. Será alterada pelo administrador sempre que houver necessidade. O

Estado 0 é utilizado unicamente para a visualização, sem qualquer

possibilidade de navegação ou manipulação do AVC. O Estado 1 é utilizado

unicamente para a visualização e navegação, sem qualquer possibilidade de

manipulação dos objetos do AVC ou de interação com outros usuários da

Seção. Finalmente, o Estado 2 é utilizado para a visualização, navegação,

manipulação dos objetos do AVC e interação com os usuários da Seção,

respeitando as possíveis restrições que o administrador pode impor sobre

determinados objetos ou usuários através de áreas de controle fornecidas pela

aplicação.

iv. Primitivas de Objetos: Informa todas as primitivas de objetos que poderão ser

utilizadas. Estas primitivas (com as informações sobre seu modelo

tridimensional e comportamento) servem para especificar os objetos básicos do

AVC (como planos, cubos e esferas) e todos os outros objetos mais complexos

(como os criados para aplicações específicas) que poderão ser criados ou

apagados do AVC em tempo real durante a execução da simulação.

v. Manipulação de Objetos: Informa como um objeto do sistema pode ser

manipulado (tipo de manipulação que ele permite). O objeto pode ser do Tipo

0 (manipulações básicas de translação, rotação e escala), 1 (manipulações

específicas de determinado objeto, de acordo com sua especificação na classe)

e 2 (combinação de manipulações básicas e específicas).

vi. Objetos da Seção: Informa todos os objetos da Seção, incluindo suas

características comportamentais e visuais.

Portanto, as CCA do sistema fornecem um controle de acesso aos usuários permitindo

que um administrador defina níveis de interação aos usuários como, por exemplo, permitir ou

impedir manipulações de objetos do AVC.

4.5.Mensagens de Controle do Protocolo

53

Para que vários usuários compartilhem o estado atual do AVC, ou seja, a configuração

das CCA do servidor, eles devem atualizar seus estados locais sempre que o estado do AVC

for modificado (ou seja, recebeu uma atualização). Esta atualização pode ser feita através de

trocas de mensagens com o servidor, que devem ocorrer muito freqüentemente para garantir

que o estado atual de cada usuário seja corretamente sincronizado. Além disso, como o

tráfego de mensagens de controle de um sistema síncrono é muito grande, o tráfego na rede

deve ser o menor possível para evitar congestionamentos e, conseqüentemente, perda de

informações. Entretanto, isto requer redes de alta velocidade com baixas latências, que é

contrastado com um alto custo.

Uma solução é fazer com que o protocolo envie somente atualizações do sistema para

os usuários (como atualizações das posições dos usuários e criação, destruição ou

modificação das propriedades dos objetos), e não constantemente o estado atual do sistema

como um todo. As requisições de atualização criadas pelos usuários deverão ser enviadas

primeiramente ao servidor, que as processará e enviará de volta a todos os usuários, caso a

requisição seja aceita.

Além disso, algumas aplicações também poderão utilizar algumas técnicas de

filtragem de dados para minimizar o tráfego na rede e melhorar o desempenho do sistema,

como utilizar uma média resolução gráfica de polígonos tridimensionais (para obter uma

rápida atualização das imagens e para não prejudicar a visualização) e texturas (para dar um

maior grau de realismo à cena visualizada sem utilizar polígonos muito complexos).

Para fins práticos, as mensagens de controle do sistema podem ser categorizadas, e o

método de comunicação mais ideal pode ser identificado para cada categoria como a seguir:

i. Tipo 1: Operações que não afetam outros usuários (como ler o estado de um

objeto do AVC). Para estas operações, o cliente envia diretamente a solicitação

ao servidor, que responde somente ao cliente requisitante, sem a necessidade

de envio da informações para os demais usuários.

ii. Tipo 2: Operações que requerem uma sincronização rigorosa entre todos os

clientes (como acender uma luz no AVC). Para estas operações, o cliente

requisitante primeiro envia sua requisição para o servidor, que a processa

verificando sua validação: se a requisição for válida, é feita a atualização de

sua CCA, e o servidor envia a mensagem de atualização via broadcast a todos

os clientes, que então atualizam suas respectivas visualizações do AVC; se a

54

requisição for inválida, é retornada uma mensagem de erro somente para o

cliente requisitante, sem qualquer envio de mensagens para os demais usuários.

Seguindo este princípio, as mensagens podem ser divididas em vários tipos, como

mostrado a seguir: (OBS: Estas mensagens, pela utilização do conceito de classe, são

implementadas como funções e, portanto, estão especificadas como “Nome da Função

(Cabeçalho, Mensagem)”, sendo “Nome da Função” um dos tipos de mensagens à seguir)

i. Mensagens de Seção (Cliente para Servidor): Mensagens do Tipo 1; São

usadas para permitir a criação ou exclusão de Seções no servidor. O usuário

que criar uma Seção será automaticamente designado administrador da

respectiva Seção criada e o único que poderá excluí-la, além do usuário Root

(Mestre do sistema). A seguir, é mostrado um exemplo deste tipo de

mensagem:

Seção ( n )Criar: n = 1, Excluir: n = 0

RetornoOK: ID_S: ID da Seção

ERRO: Mensagem de Erro

ii. Mensagens de Log (Cliente para Servidor): Mensagens do Tipo 2; São usadas

para requerer a entrada ou saída de um usuário a uma Seção existente. A

seguir, é mostrado um exemplo deste tipo de mensagem:

Log ( ID_S, IP do Usuário, n )Entrar: n = 1, Sair: n = 0

RetornoOK: ID_U: ID do Usuário

ERRO: Mensagem de Erro

iii. Mensagens de Objetos (Cliente para Servidor): Mensagens do Tipo 2; São

usadas para requerer a criação ou exclusão de objetos do AVC. A seguir, é

mostrado um exemplo deste tipo de mensagem:

Objeto ( ID_S, ID_U, Primitiva , n )Criar: n = 1, Excluir: n = 0

55

RetornoOK: ID_O: ID do Objeto

ERRO: Mensagem de Erro

iv. Mensagens de Manipulação (Cliente para Servidor): Mensagens do Tipo 1 ou

2; São usadas para requerer navegação (mensagens do Tipo 2) ou manipulação

(mensagens do Tipo 1) de objetos do AVC. A seguir, é mostrado um exemplo

deste tipo de mensagem:

Manipulação ( ID_S, ID_U, m, ID_O)Navegação: m = 0, Manipulação: m = 1

RetornoOK: Mensagem de OK

ERRO: Mensagem de Erro

v. Mensagens de Atualização (Cliente para Servidor): Mensagens do Tipo 2; São

usadas para atualizar ou cancelar a atualização das propriedades de um objeto

do AVC. A seguir, é mostrado um exemplo deste tipo de mensagem:

Atualização ( ID_S, ID_U, ID_O, n ) Atualizar: n = 1, Cancelar: n = 0

RetornoOK: Mensagem de OK

ERRO: Mensagem de Erro

vi. Mensagens de Notificação (Servidor para Cliente): Geradas por mensagens do

Tipo 2; São usadas pelo servidor para informar a todos os usuários de uma

determinada Seção sobre atualizações de usuários ou objetos de seu AVC. A

seguir, é mostrado um exemplo deste tipo de mensagem:

Notificação ( ID , n )ID do Usuário: n = 0, ID do Objeto: n = 1

RetornoOK: Mensagem de OK

ERRO: Mensagem de Erro

56

vii. Mensagens de Texto (Cliente para Servidor ou Servidor para Cliente):

Mensagens do 2; São usadas para permitir a conversação entre os participantes

de uma Seção. A seguir, é mostrado um exemplo deste tipo de mensagem:

Texto ( ID_S, ID_U Remetente, ID_U Destino, “Texto” )Retorno

OK: Mensagem de OK

ERRO: Mensagem de Erro

4.6.Máquina de Estados Finitos do Protocolo

Assim como o TCP, este novo protocolo também utiliza uma máquina de estados fini-

tos para controlar todos os seus estados. A Figura 5 apresenta a máquina de estados finitos do

protocolo, suas transições entre estados e suas ações executadas por essas transições:

Figura 5 – Máquina de Estados Finitos do Protocolo.

57

A máquina começa pelo estado Inicia, onde ocorre a inicialização do servidor e a

instanciação da classe CCS. Logo em seguida é passada para o estado Escuta, na qual o

servidor fica permanentemente esperando por requisições (Mensagens de Controle). Ao

receber uma mensagem, a mesma é identificada como mensagem do Tipo 1 ou 2. No caso de

uma mensagem do tipo 1, a máquina passa para o estado Recebe onde a mensagem é

analisada e se for uma Mensagem de Seção, passa para o estado Fin Sec, onde executa a

criação ou exclusão de uma seção no sistema, e retorna para o estado Escuta; se for uma

mensagem de Manipulação passa para o estado Fin Man, onde é feita a atualização da

respectiva CCA da Seção, e retorna para o estado Escuta.

No caso de uma mensagem do tipo 2, a máquina passa para o estado Envia onde a

mensagem é analisada. Se for uma Mensagem de Log, a máquina passa para o estado Fin

Log, onde executa a inserção ou exclusão de um usuário em uma Seção e a atualização de sua

respectiva CCA. Logo em seguida retorna para o estado Escuta enviando uma Mensagem de

Notificação para todos os usuários da Seção (ao se criar uma nova Seção, a máquina passa

automaticamente para o estado Fin Log, para a inserção do usuário como Administrador na

Seção criada). Se a máquina receber uma Mensagem de Objeto, ela passa para o estado Fin

Obj, onde executa a inserção ou exclusão de um objeto em uma Seção e a atualização de sua

respectiva CCA, e retorna para o estado Escuta, enviando uma Mensagem de Notificação para

todos os usuários da Seção. Ao receber uma Mensagem de Atualização, a máquina passa para

o estado Fin Atu, onde atualiza a respectiva CCA e retorna para o estado Escuta, enviando

uma Mensagem de Notificação para todos os usuários da respectiva Seção. Ao receber uma

Mensagem de Texto, a máquina passa para o estado Fin Tex, envia uma Mensagem de Texto

para todos os usuários da Seção e retorna para o estado Escuta.

A seguir, na Figura 6, é mostrado um Diagrama de Seqüência que ilustra

comportamento dinâmico do sistema através do tempo e que pode ser utilizado para uma

melhor compreensão do tratamento das Mensagens de Controle pelo sistema:

58

59

Figura 6 – Diagrama de Seqüência.

60

5.Conclusão

Este projeto permitirá uma maior utilização das capacidades da informática e de redes

de computadores, como a Internet, na resolução de problemas, pois o mesmo facilitará a

execução de trabalhos colaborativos em tempo real utilizando todas as vantagens que a

Realidade Virtual pode oferecer em relação aos outros sistemas interativos.

Permitirá que um grupo de pessoas, que antes necessitariam se encontrar no mundo real

para realizar determinadas atividades, se encontrem em um Ambiente Virtual Colaborativo e

realizem estas atividades da mesma maneira que as realizavam anteriormente, ou até melhor e

mais rápido pois compartilharão de vários recursos computacionais existentes no momento.

Com isso, espero que este projeto se torne uma alternativa útil e amigável para os

trabalhos colaborativos atualmente executados somente no mundo real, ou que já haviam

sendo executados de forma virtual, mas que podem ter uma grande melhora em seu

desempenho a partir da utilização da Realidade Virtual.

A Realidade Virtual, assim como o próprio computador no início de sua existência, vem

crescendo consideravelmente e permitindo, assim, a disseminação de um modo de Interação

Homem-Computador mais rico e eficaz para muitos tipos de aplicações. Mas a mesma esbarra

na principal barreira que toda nova tecnologia deve superar para se tornar popular: o alto

custo inicial.

Com o tempo, a RV e seus dispositivos imersivos se tornarão mais baratos e, portanto,

serão acessíveis a uma parcela muito maior de usuários; além de alguns pesquisadores e

profissionais especializados que já fazem uso e se beneficiam desta atual tecnologia. Portanto,

ela se tornará mais comum e se fixará como uma das melhores e mais bem elaboradas

ferramentas de IHC, pois permitirá um modo mais amigável e eficaz de controle do que os

dispositivos utilizados atualmente pela maioria dos usuários de computadores.

A colaboração entre pessoas é extremamente importante para a obtenção de qualquer

meta comum. Qualquer recurso que facilite sua execução é facilmente aceito, se for bem

desenvolvido. Como a RV facilita a IHC, ela também pode oferecer o mesmo potencial para

Trabalhos Colaborativos Auxiliados por Computador, que também tendem a se tornar cada

vez mais populares, pois englobam muitos recursos que facilitam a execução de trabalhos em

grupo.

61

Algumas das dificuldades encontradas durante a especificação deste protocolo foram: a

multidisciplinaridade inerente a este tipo de projeto, que engloba conhecimentos de áreas dis-

tintas (e algumas vezes ainda pouco exploradas – atualmente - na região do Centro-Oeste,

como a Realidade Virtual) que cooperam mutuamente formando um sistema mais complexo;

a definição dos requisitos e funcionalidades gerais que o protocolo deve fornecer para supor-

tar uma ampla variedade de tipos de aplicações colaborativas; e a estrutura de dados utilizada

pelo protocolo (neste caso, a Programação Orientada a Objetos utilizando Classes) para o con-

trole e gerenciamento do sistema, que permite uma maior eficiência, robustez e expansibilida-

de ao protocolo fornecendo requisitos para a inserção de novos módulos de controle (criação

de novas classes de controle, caso haja necessidade), novos objetos e respectivos comporta-

mentos para que possam ser utilizados em qualquer tipo de aplicação colaborativa utilizando

RV na WWW.

Com a especificação do protocolo, o próximo passo será a sua real implementação (uti-

lizando uma linguagem de programação orientada à objetos, como o Java – que possui um

grande suporte à comunicação em rede) e a criação de uma aplicação colaborativa utilizando

RV para a demonstração e validação do mesmo. Além disso, novos características de controle

Multimídia poderão ser inseridas no protocolo, como a utilização de vídeo e voz em tempo

real, permitindo uma melhor comunicação entre seus usuários e melhorando ainda mais suas

interações.

62

6.Referências Bibliográficas

(Burdea, 1994) BURDEA, G.; COIFFET, P. “Virtual Reality Technology”. Wiley-

Interscience. 1994.

(Chaves, 1991) Chaves, E. O. C. “Multimídia: Conceituação, Aplicações e Tecnologia”.

People Computação Ltda. 1991.

(Comer, 1998) COMER, Douglas E. "Interligação em Rede com TCP/IP - Volume I -

Princípios, Protocolos e Arquiteturas", 1998, Editora Campos.

(Comer, 1999) COMER, Douglas E.; STEVENS, David L. "Interligação em Rede com

TCP/IP - Volume II - Projeto, Implementação e Detalhes Internos". 1999. Editora

Campos.

(Costa, 2001) COSTA, R.M.E.M., CARVALHO, L.A.V. “Uma Estrutura de Classificação

para Estudo e Desenvolvimento de Ambientes Virtuais Voltados para a Reabilitação”

Rosatelli, Marta Costa; Wazlawick, Raul Sidnei; Kirner, Tereza Gonçalves (eds.) In: 4º

SBC Symposium on Virtual Reality, Florianópolis, Santa Catarina, pp. 302-313, 2001.

(Coulouris, 2001) COULOURIS, G. , DOLLIMORE, J. , KINDBERG, T. , "Distributed

Systems - Concepts and Design, Third Edition", 2001, Addisson-Wesley Publishing

Company.

(Junior, 2001) JUNIOR, O. R. “Ambientes Virtuais Cooperativos LRVCHAT3D, Um Estudo

de Caso” Rosatelli, Marta Costa; Wazlawick, Raul Sidnei; Kirner, Tereza Gonçalves

(eds.) In: 4º SBC Symposium on Virtual Reality, Florianópolis, Santa Catarina, pp. 1-11,

2001.

(Meiguins, 2003) MEIGUINS, B. S., GUEDES, L. A., “Arquitetura para Suporte à

Comunicação de Aplicações de Realidade Virtual Colaborativas”. Vidal, Creto Augusto;

Kirner, Cláudio (eds.) In: 6º SBC Symposium on Virtual Reality, Riberão Preto, São

Paulo, pp. 467-474, 2003

(Meiguins et al., 2001) MEIGUINS, B. S.; CARVALHO, S. R.; NETO, E. P. B.; NETO, N.

P. C.; MARTINS, S. L. O. ; ALVES, S. L.; MEIGUINS, B. S.; GUEDES, L. Afonso.

“Um Ambiente de Realidade Virtual Multi-Usuário Aplicado ao Setor de Turismo”.

63

Rosatelli, Marta Costa; Wazlawick, Raul Sidnei; Kirner, Tereza Gonçalves (eds.) In: 4º

SBC Symposium on Virtual Reality, Florianópolis, Santa Catarina, pp. 67-78, 2001.

(Pinho, 2002) PINHO, M. S., BOWMAN, D. A., FREITAS, C. M. D. S. “Cooperative Object

Manipulation in Immersive Virtual Environments: Framework and Techniques”,

VRST2002, 2002.

(Preece, 1994) PREECE, J. “Human-Computer Interaction”. Addison-Wesley. 1994.

(Raghavan, 1998) RAGHAVAN, S. V., TRIPATHI, S. K. "Networked Multimedia Systems -

Concepts, Architecture, and Design.". Prentice Hall. 1998.

(Silveira et al., 2001) SILVEIRA, A. P. B.; SILVEIRA, S. R.; GELLER, M.; PASSERINO,

L. M.; TAROUCO, L. M. R. “Construção de um Ambiente Interativo Utilizando VRML

e ASP/VBSCRIPT”. Rosatelli, Marta Costa; Wazlawick, Raul Sidnei; Kirner, Tereza

Gonçalves (eds.) In: 4º SBC Symposium on Virtual Reality, Florianópolis, Santa

Catarina, pp. 160-170, 2001.

(Sitaran, 2000) SITARAN, D.; DAN, A."Multimedia Servers - Application, Environments

and Design". Morgan Kaufmann Publishers. 2000.

(Sloman, 1994) SLOMAN, M. "Network and Distributed Systems Manegement", 1994,

Addison-Wesley Publishing Company.

(Steinmetz, 1995) STEINMETZ, R.; NAHRSTEDT, K. "Multimedia: Computing,

Communications and Applications". Prentice Hall, 1995.

64