UNIVERSIDADE CATÓLICA DOM BOSCO

Centro de Ciências Exatas e Tecnológicas

Curso de Engenharia de Computação

Ambiente Colaborativo Utilizando

Realidade 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, MS
Dezembro - 2003
 Ambiente Colaborativo Utilizando
Realidade Virtual na WWW

André Luiz Miranda da Rosa

Composição da Banca Examinadora

Prof. Alfredo Lanari de Aragão (Orientador) Presidente - UCDB
Prof. Ricardo Ribeiro dos Santos UCDB
Prof. Danielle Ruchkys UCDB

Universidade Católica Dom Bosco

Campo 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
Agradecimentos
Primeiramente, 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
Índice
1 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
Retorno
OK: 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
Retorno
OK: 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
 Retorno
OK: 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
Retorno
OK: 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
Retorno
OK: 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
Retorno
OK: 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