alves, e. c. m., design de componentes educacionais síncronos, dissertação (mestrado) –...

7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d

1/114

Ps-Graduao em Cincia da Comput ao

DESIGN DE COMPONENTES EDUCACIONAI SSNCRONOS

Po r

E N O QU E C A L V I N O M E L O A L V E S Disserta o de Mestrado

Universidade Federal de [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, AGOSTO/2005


2/114

Universidade Federal de Pernambuco

Centro de InformticaPs-Graduao em Cincia da Computao

ENOQUE CALVINOMELOALVES

DESIGN DE COMPONENTES EDUCACIONAIS SNCRONOS"

Este trabalho foi apresentado ps-graduaoem Cincia da Computao do Centro deInformtica da Universidade Federal dePernambuco como requisito parcial paraobteno do grau de mestre em Cincia daComputao.

ORIENTADOR: PROF. DR.ALEX SANDRO GOMES

RECIFE, AGOSTO/2005


3/114

Alves, Enoque Calvino MeloDesign de componentes educacionais sncronos /

Enoque Calvino Melo Alves. Recife : O Autor, 2005.111 folhas : il., tab., fig.

Dissertao (mestrado) Universidade Federalde Pernambuco. CIn. Cincia da Computao, 2005.

Inclui bibliografia.

1. Cincia da computao Interface homem-mquina. 2. Aprendizagem colaborativa apoiada porcomputador Groupware Requisitos de grupo. 3.Anlise de requisi tos Anlise de competidores,cenrios e prototipao. I. Ttulo.

004.5 CDU (2.ed.) UFPE004.6 CDD (22.ed.) BC2005-592


4/114

DEDICATRIA

Aos meus pais.


5/114

AGRADECIMENTOS

um momento de grande alegria para mim a concluso deste trabalho

e com esta mesma alegria e satisfao que aproveito para agradecer as

pessoas que contriburam para este grande momento. Sem essas pessoas jamais

teria chegado at aqui. Alguns contriburam de forma mais direta para este

trabalho, enquanto outros foram importantes para que eu tenha chegado at aqui.

Ao meu orientador, Professor Alex Sandro Gomes, pelo apoio na

definio do trabalho, orientao e estmulo na minha formao comopesquisador. A quem hoje eu considero como um amigo e parceiro na minha vida

acadmica.

Ao meu pai, J os Alves Sobrinho, que sentou em uma carteira escolar

pela primeira vez na vida aos 22 anos de idade. Homem de firme propsito e fiel

aos seus ideais, um grande educador, que abdicou de muitos de seus sonhos

para dar aos filhos uma educao de qualidade.

A minha me, Odete Melo Alves, pelas noites e madrugadasinterminveis em que ficava acordada me ensinando a matemtica, que mesmo

sob meus protestos e choros, ensinou-me o valor da perseverana.

A Vnia Alves, minha esposa, por suportar o meu primeiro ano de

mestrado ausente, e nos anos seguintes, por se tornar minha colaboradora vindo

para o mestrado, escolhendo um tema relacionado com o meu e tornando esta

longa trajetria muito mais suave.

Ao meu colega e amigo Maurcio Braga, por desenvolver a ferramenta

Grard. A minha grande amiga Taciana Falco pela sua colaborao e incentivo

na elaborao do primeiro cenrio.


6/114

SUMRIO

1. INTRODUO.................................................................................................... 12

2. AMBIENTES EDUCACIONAIS SNCRONOS ............................................................. 14

2.1. APRENDIZADO COLABORATIVO APOIADO POR COMPUTADOR .......................... 14

2.1.1. Taxonomia da colaborao apoiada por computador......................15

2.1.2. Groupware sncrono de aprendizagem............................................ 18

2.2. PROBLEMA................................................................................................20

3. ARQUITETURAS DE GROUPWARE........................................................................ 21

3.1. MODELOS DE REFERNCIA .........................................................................22

3.1.1. Modelo de Patterson........................................................................ 22

3.1.2. Modelo de Dewan............................................................................ 24

3.2. ESTILOS ARQUITETURAIS............................................................................26

3.2.1. MVC.................................................................................................26

3.3. CONSIDERAES FINAIS............................................................................. 30

4. METODOLOGIA ................................................................................................. 32

4.1. OBJ ETIVOS DA METODOLOGIA ....................................................................334.1.1. Geral................................................................................................33

4.1.2. Especficos ...................................................................................... 33

4.2. ANLISE DE COMPETIDORES .......................................................................33

4.3. PROTOTIPAO ......................................................................................... 34

4.4. CENRIOS.................................................................................................35

5. ANLISE DE COMPETIDORES.............................................................................. 37

5.1. RENDEZVOUS............................................................................................37

5.2. NSTP ......................................................................................................38

5.3. ANTS ......................................................................................................39

5.4. DREAMTEAM.............................................................................................40

5.5. GROUPKIT.................................................................................................42

5.6. HABANERO ...............................................................................................44

5.7. SHARE-KIT................................................................................................45

5.8. COMPARAO ENTRE COMPETIDORES ......................................................... 46


7/114

5.9. REQUISITOS LEVANTADOS A PARTIR DA ANLISE DE COMPETIDORES ..............47

5.10. CONSIDERAES FINAIS .........................................................................52

6. PROTOTIPAO ................................................................................................ 53

6.1. PROTTIPO DA PLATAFORMA DE GROUPWAREPLATTUS................................ 53

6.1.1. Arquitetura de Distribuio............................................................... 53

6.1.2. Comunicao................................................................................... 53

6.1.3. Conscincia de colaborao............................................................54

6.1.4. Espao compartilhado .....................................................................55

6.1.5. Controle de sesso..........................................................................55

6.1.6. Definio de papis .........................................................................566.1.7. Percepo........................................................................................56

6.1.8. Componentes de interfaces (widgets).............................................. 56

6.1.9. Independncia de plataforma........................................................... 57

6.2. SERVIDOR PLATTUS................................................................................... 57

6.2.1. Mensagens ...................................................................................... 59

6.2.2. API de comunicao cliente/servidor............................................... 60

6.2.3. Exemplo de envio e recebimentos de mensagens........................... 61

6.3. COMPONENTE COLABORATIVO GRARD....................................................... 62

6.3.1. Estruturas aditivas ...........................................................................62

6.3.2. Prottipo do componente Grard..................................................... 65

6.4. CONSIDERAES FINAIS............................................................................. 68

7. ANLISE DE CENRIOS...................................................................................... 69

7.1. PRIMEIRA ITERAO .................................................................................. 69

7.1.1. Atores ..............................................................................................69

7.1.2. Contexto ..........................................................................................697.1.3. Ambiente (setting)............................................................................ 69

7.1.4. Roteiro (plot).................................................................................... 71

7.1.5. Roteiro positivo................................................................................ 77

7.1.6. Roteiro negativo............................................................................... 79

7.1.7. Requisitos levantados......................................................................83

7.2. SEGUNDA ITERAO .................................................................................. 87


8/114

7.2.1. Prottipo ..........................................................................................87

7.2.2. Atores ..............................................................................................91

7.2.3. Contexto ..........................................................................................91

7.2.4. Ambiente (setting)............................................................................ 91

7.2.5. Roteiro positivo................................................................................ 92

7.2.6. Roteiro negativo............................................................................... 94

7.2.7. Requisitos levantados......................................................................98

7.3. CONSIDERAES FINAIS...........................................................................102

8. CONCLUSES E TRABALHOS FUTUROS ............................................................. 104

REFERNCIAS BIBLIOGRFICAS .............................................................................. 106


9/114

LISTA DE FIGURAS

Figura 2.1 Taxonomia da colaborao apoiada por computador.......................................16

Figura 3.1 Exemplos da taxonomia de Petterson..............................................................23

Figura 3.2 Arquitetura genrica de Dewan........................................................................25

Figura 3.3 Cenrio de interao do MVC..........................................................................27

Figura 3.4 Arquitetura Centralizada..................................................................................28

Figura 3.5 Arquitetura Replicada. .....................................................................................28

Figura 3.6 Arquitetura Distribuda. ...................................................................................29

Figura 3.7 Arquitetura Hbrida..........................................................................................30

Figura 4.1 Alocao de tcnicas de usabilidade aplicadas anlise.................................32

Figura 4.2 Fluxo de aplicao das tcnicas selecionadas..................................................33

Figura 5.1 CardTable: uma aplicao desenvolvida com Rendezvous.............................37

Figura 5.2 MapTool: Ferramenta desenvolvida com ITCOLE architecture. ....................40

Figura 5.3 Ambiente de execuo do DreamTeam...........................................................41

Figura 5.4 Plataforma DreamTeam rodando em dispositivos Palm..................................42

Figura 5.5 Aplicaes desenvolvidas com Groupkit.........................................................43

Figura 5.6 Tela do cliente Habanero.................................................................................45

Figura 5.7 Aplicao cliente do Share-Kit........................................................................46

Figura 6.1 Componente Lista de Usurios.....................................................................56

Figura 6.2 Componente deChat........................................................................................57

Figura 6.3 Arquitetura simplificada de comunicao........................................................58

Figura 6.4 Modelo de comunicao..................................................................................59

Figura 6.5 Exemplo de diagrama e problema de composio...........................................63Figura 6.6 Exemplo de diagrama e problema de transformao.......................................63

Figura 6.7 Exemplo de diagrama e problema de comparao...........................................64

Figura 6.8 Exemplo de variaes dos diagramas bsicos..................................................64

Figura 6.9 Estrutura aditiva composta...............................................................................65

Figura 6.10 Interface do ambiente Grard.........................................................................66

Figura 7.1 Laboratrio de informtica...............................................................................70


10/114

Figura 7.2 Telas de escolha do grupo e login....................................................................72

Figura 7.3 Leandra entra no ambiente...............................................................................72

Figura 7.4 Matheus entra no ambiente..............................................................................73

Figura 7.5 Leandra desenha o diagrama no ambiente.......................................................74

Figura 7.6 Leandra termina de desenhar o diagrama.........................................................75

Figura 7.7 Leandra e Matheus concluem a primeira tarefa...............................................76

Figura 7.8 Leandra passa o controle para Matheus...........................................................76

Figura 7.9 Matheus recebe o controle do ambiente...........................................................77


11/114

LISTA DE TABELAS

Tabela 5.1 Comparao entre competidores......................................................................47

Tabela 6.1 Botes da barra de ferramentas do Grard......................................................66

Tabela 7.1 Requisitos levantados na anlise de cenrios (primeira iterao) ...................83

Tabela 7.2 Requisitos levantados com a anlise de cenrios (segunda iterao)..............99


12/114

RESUMO

Aprendizado Colaborativo Apoiado por Computador tem se firmado

como um paradigma de ensino. Neste articulam-se diferentes conceitos de

aprendizagem e interao em grupo. Os ambientes colaborativos sncronos visam

facilitar a construo de conhecimento e o desenvolvimento de competncias

entre participantes de um grupo.

Componentes sncronos de aprendizagem (tambm chamados de

sistemas de groupware) podem ser caracterizados por prover um conjunto de

objetos virtuais compartilhados. Estes so manipulveis por ferramentas e

constituem-se num espao compartilhado de interao entre usurios.

O problema que estamos focando consiste levantar, a partir da

interao entre usurios, requisitos que colaborem com a definio de uma

arquitetura de componentes colaborativos sncronos que resolva problemas de

comunicao, conscincia de colaborao, manuteno do espao compartilhado,

controle de acesso ao espao compartilhado, definio de papis e percepo

(awareness).

Este trabalho utilizou tcnicas de design para usabilidade com o intuito

de resolver problemas relativos interao mediada por componentes sncronos

de aprendizagem, propondo um conjunto de requisitos para construo de novos

sistemas que favoream a interao em grupo atravs de anlises centradas nas

necessidades dos usurios.


13/114

ABSTRACT

Computer Supported Collaborative Learning has become a teaching-

learning paradigm. It deals with different concepts of learning and group

interaction. Synchronous collaborative environments aim at facilitating the

construction of knowledge and the development of skills among the participants of

a group.

Synchronous learning components (also called groupware) can be

characterized as providers of a set of shared virtual objects. Those objects can be

manipulated through tools and form a shared space for user interaction.

The problem on which we are focusing is eliciting, from user interaction,

requirements that help to define an architecture of synchronous collaborative

components, which would solve problems in communication, collaboration

consciousness, maintainability of the shared space, shared space access control,

role definition and awareness.

This work made use of usability design techniques with the goal ofsolving problems related to interaction mediated by synchronous learning

components, proposing a set of requirements to be applied to the construction of

new systems which would favour group interaction through user needs-centered

analysis.


14/114

12

1. INTRODUO

O aprendizado mediado por computador pode apresentar um ambiente,

no qual os alunos interagem uns com os outros, colaborando para solucionar um

dado problema. A principal promessa do aprendizado colaborativo suportado por

computador, segundo Kumar [KUM1996], permitir que os alunos aprendam em

um ambiente relativamente realista, cognitivamente motivacional e socialmente

rico.

Atravs de um componente sncrono de aprendizagem, um tipoespecfico de groupware sncrono, estudantes geograficamente dispersos,

conectados via uma rede de computadores, podem colaborar em tempo real

atravs de um espao de trabalho compartilhado (shared workspace) [GUT1995].

A manuteno do espao de trabalho compartilhado, ou seja, como

manter objetos compartilhados com os quais os usurios interagem, tem sido a

principal preocupao durante o design de sistemas de groupware [PHI1999].

Mas, com a evoluo destes sistemas, as preocupaes esto movendo-se do

nvel arquitetural (comunicao) para um nvel mais prximo ao usurio (interao)

[GUE2001].

Este trabalho utilizou tcnicas de design para usabilidade, em particular

uma anlise de competidores e a tcnica de anlise de cenrios, com o objetivo

de, a partir da anlise da interao entre usurios, levantar requisitos de

groupware que colaborem com a definio de uma arquitetura de uma plataforma

de apoio a aplicaes colaborativas educacionais sncronas.

Observaram-se os principais problemas existentes no desenvolvimento

de arquiteturas de groupware e props-se um conjunto de requisitos para

construo de novos sistemas que favoream a interao em grupo apoiados na

anlise centrada no usurio.

No prximo captulo, apresentamos uma reviso da literatura dos

conceitos de aprendizado colaborativo apoiado por computador, destacando as


15/114

13

formas de colaborao, focando na colaborao sncrona e apresentando

componentes sncronos de aprendizagem, que so um tipo especfico de

groupware. Este captulo conclui com uma anlise do principal problema dossistemas de groupware e aponta para o problema tratado neste trabalho.

O terceiro captulo continua a reviso da literatura, destacando as

principais abordagens utilizadas no desenvolvimento de groupware e que foram

importantes para a implementao do prottipo desenvolvido neste trabalho.

O quarto captulo apresenta a metodologia utilizada no trabalho, cada

uma das tcnicas aplicadas no desenvolvimento deste trabalho: anlise de

competidores, prototipao e anlise de cenrios.

Nos trs captulos seguintes apresentam-se os resultados da anlise de

competidores (Captulo 5), detalhes do prottipo da plataforma de groupware

Plattus e do componente sncrono de aprendizagem Grard (Captulo 6) e os

resultados empricos da anlise dos cenrios de utilizao do software Grard

(Captulo 7).

Finalmente, o oitavo captulo apresenta as concluses evidenciadas a

partir dos resultados obtidos e descritos nos trs captulos anteriores. Este

captulo apresenta tambm os trabalhos futuros relacionados com os resultados

deste trabalho.


16/114

14

2. AMBIENTES EDUCACIONAIS SNCRONOSAprendizagem colaborativa envolve situaes que contemplam um

grupo de alunos trabalhando conjuntamente em um ambiente educacional, tanto

em tarefas comuns ou atravs do uso de ferramentas computadorizadas, como

por exemplo, um jogo eletrnico ou um componente sncrono de aprendizagem.

Aprendizagem colaborativa uma idia antiga na educao que tem

recebido ateno significativa nas duas ltimas dcadas. Porm, ao invs de

refletir a idia inicial onde a cognio era vista como um produto individual, o

contexto das interaes sociais era visto apenas como pano de fundo das

atividades individuais, o foco tem mudado para anlise do grupo como objeto de

estudo [DIL1996].

Hiltz [HIL1988] descreve que o processo de aprendizado colaborativo

enfatiza a participao ativa, a interao entre os alunos, discusso e construo

do conhecimento que emerge a partir de compartilhamento de idias e

informao.

2.1. APRENDIZADO COLABORATIVO APOIADO POR COMPUTADORA aprendizagem colaborativa apoiada por computador (Computer-

Supported Collaborative Learning - CSCL) a rea de pesquisa que estuda o uso

da tecnologia computacional no suporte s atividades da aprendizagem

colaborativa [MAN1997]. considerada uma rea multidisciplinar que fundament-

se na aplicao de conhecimentos derivados de diferentes campos de pesquisa,

tais como a cincia da computao, a sociologia, antropologia, psicologia,

pedagogia, cincias cognitivas, comunicao, entre outros [MEZ2002].

Riel [RIE1992] diz que embora os benefcios de um ambiente de

aprendizagem colaborativa tenham sido estabelecidos, a transformao das salas

de aulas tradicionais em organizaes sociais que permitam aprendizagem

colaborativa tem provado ser uma tarefa complexa. Adicionar o computador em

uma tarefa no reduz sua complexidade. Esta rea de pesquisa, entretanto, est

tentando expandir as fronteiras da aprendizagem colaborativa atravs da

utilizao de computadores.


17/114

15

CSCL enquadra-se como subrea de Computer Supported Cooperative

Work1 (CSCW), a qual por sua vez considerada uma subrea de HCI2. Na rea

CSCW inclui-se a investigao das chamadas aplicaes de groupware3. Estasaplicaes colaborativas visam dar suporte interaes de grupos, enquanto que

a rea de CSCL mais voltada ao estudo deste tipo de aplicao abordando

apenas com um domnio educacional [KOS1992].

2.1.1. TAXONOMIA DA COLABORAO APOIADA POR COMPUTADOR

Classificar de forma genrica como a colaborao pode acontecer

mediada pelo computador uma tarefa difcil devido diversidade de aplicaes e

domnios deste tipo de tecnologia. Entretanto, uma categorizao bastante aceita

na literatura de CSCW e CSCL usa as dimenses espao/tempo apresentadas por

Ellis et al. [ELL1991] e tambm por J ohansen [J OH1992].

Segundo J ohansen [J OH1992], a colaborao apoiada por computador

acontece em diferentes modos de interaes. A combinao das dimenses de

tempo e espao estabelece quatro tipos de colaborao com caractersticas bem

distintas. As interaes podem ocorrer ao mesmo tempo (sncronas) ou em

diferentes momentos (assncronas). Os usurios podem encontrar-se no mesmo

local (prximos) ou em lugares diferentes (dispersos). A Figura 2.1 mostra as

diferentes alternativas para colaborao mediada por computador.

1 Em Portugus: Trabalho cooperativo apioado por computador2 Do Ingls, Human-Computer Interaction, Interao Homem-Mquina foi adotada em meados dos anos 80para descrever o campo emergente de estudo que foca em todos os aspectos da interao entre usurios ecomputadores.


18/114

16

Figura 2.1 Taxonomia da colaborao apoiada por computador.

Mesmo tempo/mesmo espao refere-se a situaes em que a sala de

aula tradicional provida com computadores para os alunos. Neste modo de

interao o ambiente da sala de aula tradicional melhorado com o uso de

sistemas de grupos.

Mesmo tempo/espaos diferentes refere-se a situaes nas quais as

interaes ocorrem de forma sncrona, mas os usurios encontram-se separados

geograficamente. A comunicao ocorre atravs de vdeo, udio ou mesmo de

forma textual, por exemplo, atravs de um chat. Neste caso, a sala de aula no

representa mais um lugar fsico, mas sim, o conjunto de alunos que interagem

atravs do sistema de grupo. A comunicao e o compartilhamento de informao

so essenciais para manter o contexto compartilhado entre os usurios.

Tempo diferente/mesmo espao refere-se a situaes nas quais, dada

a sua natureza prpria, restringem consideravelmente a interao entre os seus

utilizadores [ROB1998]. Neste caso, por exemplo, o professor poderia definir uma

atividade colaborativa onde os alunos usariam apenas um determinado

computador para criar um texto colaborativamente. Porm, os alunos usariam o

computador em momentos diferentes, mas sempre no mesmo computador e

deixariam no prprio documento os comentrios para os demais colegas. Este


19/114

17

exemplo mostra que esta uma forma de interao bastante difcil de ser

encontrada.

Tempo diferente/espaos diferentes refere-se a situaes onde as

interaes e as atividades so realizadas individualmente, servindo o sistema de

mediador, permitindo a troca de informao e a coordenao de atividades. O

correio eletrnico (e-mail) e os sistemas de listas de discusso constituem

exemplos deste tipo de sistemas.

Este trabalho concentra-se na colaborao sncrona apoiada por

computador, ou seja, quelas que ocorrem ao mesmo tempo. Koschmann et al.

[KOS1993] divide as aplicaes que apiam a colaborao sncrona em dois

grupos: aplicaes desenvolvidas para uso em sala de aula e aquelas

desenvolvidas para comunicao entre salas de aulas via redes de longa

distncias (por exemplo, a Internet). Palmer [PAL1994] tambm apresenta uma

classificao equivalente, que ele chama de colaborao co-presencial e

distribuda.

Colaborao co-presencial caracteriza-se pela presena fsica dos

participantes no mesmo local, por exemplo, em um laboratrio onde os

computadores estejam conectados em rede, mas a qualquer momento os alunos

podem se comunicar face-a-face.

Colaborao distribuda ocorre quando vrias pessoas trabalham em

computadores separados, conectados por uma rede, e utilizando software

especialmente projetado para utilizar conexes de rede.

Segundo Bricker [BRI1995], a colaborao co-presencial prefervel

colaborao distribuda. Mas, essa afirmao depende do paradigma instrucional

que estiver sendo utilizado. Dentro do paradigma de educao distncia a

colaborao distribuda torna-se muito mais valiosa.

Dentre as formas de colaborao apresentadas, este trabalho

concentra-se nas colaboraes sncronas educacionais, co-presenciais ou

distribudas, apoiadas por sistemas colaborativos conhecidos como sistemas de


20/114

18

groupware. Na prxima seo apresentamos o conceito e caractersticas deste

tipo de sistema.

2.1.2. GROUPWARE SNCRONO DE APRENDIZAGEM

O conceito de groupware mais aceito foi definido por Ellis et al.

[ELL1991]. Ellis et al. definem groupware como sistemas baseados em

computador que suportam grupos de pessoas engajadas em uma tarefa comum e

que provem interface para um ambiente compartilhado. Este conceito bastante

genrico, pois considera um groupware qualquer sistema computacional que

oferea algum suporte para o trabalho em grupo, no importando se o sistema foi

construdo com essa finalidade.

A partir desta definio, groupware pode ser tanto sncrono como

assncrono, onde a comunicao o principal aspecto deste tipo de sistema. Uma

indicao disso que no mesmo artigo considera-se email como um exemplo de

groupware.

Nosso estudo focaliza nos sistemas de groupware sncronos que se

propem ao apoio de atividades educacionais. Ns chamamos estes sistemas de

componentes sncronos de apredizagem, e utilizamos a definio de Gutwin

[GUT1995] para definir este tipo de sistemas.

Componente sncrono de aprendizagem pode ser caracterizado por

prover um ambiente que permite estudantes geograficamente dispersos ou co-

presentes, conectados via uma rede de computadores, colaborarem em tempo

real atravs de um espao de trabalho compartilhado.

No presente trabalho estaremos utilizando o termo groupware comosinnimo de componentes sncronos de aprendizagem e por conseqncia

atendendo a este conceito mais restrito que apresentamos.

fcil perceber, a partir das diversas definies de groupware

encontradas na literatura, que um aspecto chave dos sistemas de groupware a

manuteno do espao de trabalho compartilhado. Em aplicaes monousurias a

principal preocupao da interface do usurio apresentar na tela, de forma mais


21/114

19

realista possvel, o produto das aes do usurio. Esta estratgia conhecida

como WYSIWYG (What You See Is What You Get1).

Em sistemas de groupware a interface do espao de trabalho

compartilhada com diversos usurios e existe a necessidade de manter o

acoplamento entre o espao de trabalho compartilhado e as interfaces dos

usurios. As estratgias de acoplamento de interfaces derivam semanticamente

da estratgia monousuria, mas so muitas vezes limitadas pela estratgia de

manuteno do espao compartilhado escolhida pelos projetistas do groupware.

As principais estratgias de acoplamento de interface utilizadas por

sistemas de groupware so:

WYSIWIS (What You See Is What I See2) Tambm conhecida como

WYSIWIS estrita, apresenta a todos os usurios exatamente a mesma viso. Ideal

para colaboraes onde as atividades so altamente acopladas, como treinamento

pessoal, demonstrao do uso de um determinado software, ou certos tipos de

atividades de tutoria. No recomendado para atividades fracamente acopladas,

porque todos vem o mesmo cursor e a posio de rolagem da tela a mesma

para todos.

WYSIWIS relaxada No exige que a viso seja exatamente a mesma

para todos os usurios. Os usurios podem rolar livremente a tela de forma

independente e realizar suas prprias operaes como editar ou mover objetos,

at que uma alterao no espao compartilhado resulte na atualizao da

interface.

WYMIWIM (What You Model Is What I Model3) - No exige que a

interface seja exatamente a mesma para todos os usurios. Permite o uso de

mltiplas representaes, por exemplo, um aluno pode est vendo uma tabela,

enquanto outro est vendo um grfico, que representam os mesmos dados no

espao compartilhado.

1 Em Portugus: O que voc v o que voc tem.2 Em Portugus: O que voc v o que eu vejo.3 Em Portugus: O que voc modela o que eu modelo.


22/114

20

2.2. PROBLEMA

A manuteno do espao de trabalho compartilhado, ou seja, como

manter objetos compartilhados com os quais os usurios interagem, a principalpreocupao dos sistemas de groupware, mas no a nica. Com a evoluo

destes sistemas, as preocupaes esto movendo-se do nvel arquitetural para

um nvel mais prximo ao usurio.

O problema que estamos focando consiste em levantar, a partir da

interao entre usurios, requisitos de groupware que colaborem com a definio

de uma arquitetura de uma plataforma de apoio a aplicaes colaborativas

educacionais sncronas.

No prximo captulo, apresentamos uma reviso das principais

abordagens de arquiteturas de groupware. Elas procuram simplificar o

desenvolvimento de sistemas de groupware atravs da proposta e codificao de

estruturas apropriadas ao domnio do problema.


23/114

21

3. ARQUITETURAS DE GROUPWAREEste captulo continua a apresentao da reviso da literatura iniciada

no captulo anterior, porm focaliza nas principais abordagens utilizadas no

desenvolvimento de groupware e que foram importantes para a implementao

deste trabalho. Iniciaremos com a apresentao das geraes de sistemas de

groupware e seguimos com os principais modelos de referncia e estilos

arquiteturais empregados no desenvolvimento deste tipo de sistema.

O desenvolvimento de groupware uma tarefa complexa porque

envolve aspectos que no aparecem no desenvolvimento de sistemas

monousurios. Nas ltimas dcadas, autores tm trabalhado para melhorar a

eficcia deste tipo de sistema. Segundo Guerrero & Fuller [GUE2001], isso gerou

quatro geraes de aplicaes:

A primeira gerao caracterizada pelo desenvolvimento dos primeiros

sistemas colaborativos. Estes sistemas eram monolticos, construdos em um

nico bloco lgico, no separando preocupaes em camadas ou componentes

diferentes. A linguagem C era predominante nesta gerao. Estes sistemas

preocupavam-se basicamente apenas com a comunicao entre os processos do

sistema. Um exemplo de sistema desta gerao o Share-Kit [ROT1998].

A segunda gerao marcada pelo amadurecimento das ferramentas

de apoio ao desenvolvimento de groupware. Representantes desta gerao so o

GroupKit [ROS1996] e o Habanero [NCS2005]. Esta gerao caracteriza-se pelo

surgimento de toolkits e extenses de linguagens que fornecem ao programador

mecanismos que facilitam o desenvolvimento deste tipo de sistema.

A terceira gerao caracteriza-se pela popularizao das linguagens

orientadas a objeto e ao surgimento de frameworks que encapsulam as

funcionalidades de colaborao, como por exemplo, o NSTP (Notification Service

Transfer Protocol) [PAT1996] [DAY1997]. Uma das vantagem em relao s

geraes anteriores o reuso de cdigo garantido pelo paradigma de orientao a

objetos.


24/114

22

Finalmente, a quarta gerao distingue-se pela incorporao de objetos

distribudos (CORBA, DCOM, Enterprise J avabeans e RMI) na construo de

groupware e arquitetura baseada em componentes. So representantes destagerao o ANTS [GAR2001, GAR2002] e o DreamTeam [ROT1998, ROT2000].

As dificuldades intrnsecas do desenvolvimento de groupware levaram a

uma vasta gama de abordagens de desenvolvimento. Estas arquiteturas podem

ser mapeadas conceitualmente a partir dos modelos de referncia e estilos

arquiteturais propostos para os sistemas de groupware.

3.1. MODELOS DE REFERNCIA

Os modelos de referncia tentam descrever a estrutura de um sistema

de groupware completo em um nvel abstrato. Modelos de referncia podem ser

vistos tanto como prescritivos como descritivos [PHI1999]. Do ponto de vista

prescritivo eles expressam uma perspectiva filosfica de como os sistemas de

groupware podem ser construdos, enquanto que na viso descritiva eles podem

prover um framework cannico, com o qual se pode discutir sobre a estrutura de

sistemas de groupware existentes.

Nesta seo, apresentamos dois modelos que so relevantes para este

trabalho: os modelos de Patterson e de Dewan.

3.1.1. MODELO DE PATTERSON

O primeiro modelo de referncia desenvolvido especificamente para

sistemas de groupware apareceu na taxonomia proposta por Patterson [PAT1995],

motivado pela observao de que o principal desafio das aplicaes de grupo

sncronas a manuteno do ambiente compartilhado. O modelo de Patterson

divide o estado da aplicao em quatro nveis: o primeiro o display state, que

implementado no hardware de vdeo que controla a tela do monitor do usurio; o

segundo o view state, a representao visual lgica da estrutura de dados

interna da aplicao; o terceiro o model state, a estrutura de dados interna que

representa o ambiente compartilhado e o quarto o file state, a representao

persistente do modelo.


25/114

23

(a)

Arquitetura com estado

compartilhado

(b)

Arquitetura com estado

sincronizado

(c)

Arquitetura Hbrida

Figura 3.1 Exemplos da taxonomia de Petterson

A taxonomia de Patterson, ilustrada na Figura 3.1, prope trs classes

de arquitetura de groupware: aquelas baseadas no compartilhamento do estado,

aquelas baseadas na replicao do estado com sincronizao1 e as hbridas, que

incluem as duas abordagens anteriores. O benefcio chave do compartilhamento

do estado da aplicao a simplicidade, enquanto que o benefcio da replicao

do estado o melhoramento do desempenho e a capacidade de desligar e ligar a

sincronizao.

Na Figura 3.1(a) apresentada a arquitetura de um sistema de

groupware baseado no compartilhamento do modelo. Essa permite aos usurios

ter diferentes vises dos dados da estrutura interna do modelo. O uso de

diferentes componentes de vises, permite os mesmos dados sejam apresentados

a usurios diferentes de formas diferentes. Por exemplo, algum pode est vendo

os dados em forma de tabela, enquanto outro os v em forma de grfico.

A Figura 3.1(b) mostra a arquitetura de um sistema compartilhado

usando a arquitetura sincronizada. Os elementos sincronizados devem conter

exatamente a mesma informao e so replicados por desempenho. Neste

exemplo os usurios devem ter exatamente a mesma viso em suas telas. Isto

1 A sincronizao freqentemente garantida com a troca de mensagens de sincronismo. Estas mensagens soenviadas para todas as instncias remotas da aplicao, garantindo que a cada alterao de um componentereplicado suas cpias sejam atualizadas.


26/114

24

est relacionado com o modelo de acoplamento WYSIWIS estrito. Patterson

sugere que onde as vises so sincronizadas, torna-se tambm necessrio

sincronizar separadamente os modelos.

O exemplo na Figura 3.1(c) o de uma arquitetura hbrida, onde o

modelo compartilhado e as vises podem ser sincronizadas. Esta arquitetura

prov um mecanismo simples para garantir a consistncia do estado do modelo e

permitir que a sincronia de vises possa ser ativada e desativada pelo prprio

usurio. Isso permite, por exemplo, que um professor em uma apresentao

distncia possa ativar ou desativar a sincronizao das vises. A sincronizao

das vises, neste caso, resulta na situao onde as telas de todos os alunosseriam exatamente iguais (estariam sincronizadas) tela do professor, garantindo

o acompanhamento da apresentao.

A taxonomia de Patterson oferece uma representao simples das

arquiteturas possveis para sistemas de groupware e abstrai como alguns

aspectos computacionais so alcanados, como por exemplo, concorrncia e

distribuio. Mas, a idia a simplificao do modelo, mantendo-se no nvel

conceitual favorecendo um melhor entendimento deste tipo de aplicao.

3.1.2. MODELO DE DEWAN

Este modelo foi definido a partir da arquitetura genrica de Dewan, que

pode ser vista como uma generalizao da taxonomia de Patterson [ROT2000]. A

arquitetura de Dewan (Figura 3.2) dividida em camadas, mas no define a

responsabilidade de cada uma e nem determina o nmero mximo de camadas. O

fluxo de dados modelado atravs de eventos, que podem ser transferidos entre

camadas horizontalmente ou verticalmente.


27/114

25

Figura 3.2 Arquitetura genrica de Dewan.

Os objetos prximos ao usurio (camadas inferiores) so chamados de

objetos de interao (interatores) das abstraes da camada superior. Um objeto

no meio da hierarquia ser tanto um objeto de interao quanto uma abstrao.

Um objeto de interao cria uma apresentao de sua abstrao, a qual pode

incluir transformaes da abstrao e informaes adicionais. A comunicao

entre os objetos no modelo acontece via eventos e pode ser sncrona ou

assncrona.

O modelo de Dewan, similarmente ao modelo anterior, oferece uma

representao simples das arquiteturas possveis para sistemas de groupware.

Mas apresenta um conceito muito mais aceito pelos especialistas em Rede de

Computadores, que a organizao e separao de funcionalidades em mltiplas

camadas. Onde as camadas mais prximas ao usurio apresentam um maior nvel

de interao.

Como dito anteriormente, os modelos de referncia esto em um nvel

abstrato, servindo mais para descrever e classificar sistemas de groupware que

para constru-los. A seguir apresentaremos estilos arquiteturais que propem

modelos mais concretos de componentes, topologia e conectores, que podem ser

utilizados para o desenvolvimento de novos sistemas de groupware.


28/114

26

3.2. ESTILOS ARQUITETURAIS

Um estilo arquitetural sugere um vocabulrio de componentes

(responsveis pelo comportamento do sistema), tipos de conectores (interligandoos componentes), uma topologia de interconexo (possibilitando vrios tipos de

interao e compartilhamento de informaes entre esses componentes) e uma

estratgia de controle de fluxo [MEN2002].

Phillips [PHI1999] declara que a questo chave que os

desenvolvedores devem considerar, quando selecionam um estilo arquitetural

para aplicaes de groupware, como construir sistemas que permitam vrios

usurios interagirem concorrentemente uns com os outros e com os dadoscompartilhados.

A maioria dos estilos arquiteturais encontrados em sistemas de

groupware segue uma filosofia onde os dados da aplicao (o modelo) so

mantidos separados do cdigo da interface (a viso). O estilo arquitetural Model-

View-Controler(MVC) baseado nesta filosofia e o mais comumente usado no

desenvolvimento de sistemas de groupware [PHI1999]. O prottipo desenvolvido

neste trabalho tambm vai seguir a filosofia MVC.

3.2.1. MVC

O estilo arquitetural MVC (Modelo / Viso / Controlador) foi introduzido

com a linguagem Smalltalk [KRA1988] para prover uma separao eficaz entre a

interface do usurio e a semntica da aplicao.

Nesta seo apresentaremos o MVC como foi definido no Smalltalk-80.

O MVC descrito tambm por Gamma et al. [GAM1994] como um exemplo de

utilizao do padro de projeto Observer. A estrutura do MVC est ilustrada na

Figura 3.3. A estrutura bsica do MVC consiste de um modelo (model), que

representa os dados da aplicao; um controlador (controller), que interpreta as

entrada do usurio; e uma viso (view) que representa a sada.


29/114

27

Figura 3.3 Cenrio de interao do MVC.

A Figura 3.3 tambm mostra um fluxo tpico de interao via MVC, quecomea com a entrada do usurio c, o qual interpretada pelo controlador e

resulta na atualizao do modelo d. O modelo envia um evento de notificao

para a viso e o controlador e informando que algum aspecto de seu estado foi

alterado. A viso consulta o modelo para determinar o que foi alteradof e recebe

os detalhes g que utiliza para atualizar a tela h. O controlador pode tambm

reagir notificao alterando seu modo de interao.

Quando aplicado ao desenvolvimento de groupware, o MVC resolve o

principal desafio das aplicaes colaborativas sncronas: a manuteno do

ambiente compartilhado, atravs da distribuio de seus componentes. A seguir

analisamos as arquiteturas de distribuio dos componentes do modelo MVC

apresentada por Suthers [SUT2001].

3.2.1.1. Centralizada

Esta arquitetura de distribuio prov somente uma aplicao completa

e distribui cpias da GUI (view e controler) entre as mquinas clientes

1

(Figura3.4). O modelo, a viso e o controlador da aplicao situam-se em um servidor.

Este tipo de arquitetura apresenta conseqentemente acoplamento do tipo

WYSIWIS estrito.

1 Mquinas clientes so computadores que participam da colaborao, assumindo o papel de cliente naarquitetura cliente/servidor.


30/114

28

Figura 3.4 Arquitetura Centralizada.

Como vantagem, esta arquitetura pode ser usada para compartilhar

aplicaes que no foram desenvolvidas com esta caracterstica, atravs da

captura e difuso dos eventos do sistema de janelas entre as mquinas clientes.

Como restrio, apenas uma pessoa pode usar o mouse e o teclado em um

determinado momento. mais indicada para treinamento pessoal, como a

demonstrao do uso de um determinado software.

3.2.1.2. Replicada

Esta arquitetura de distribuio (Figura 3.5) caracterizada por ter

todos os trs componentes MVC modelo, viso e controle replicados em todas

as mquinas clientes, ou seja, a aplicao completa executada em cada cliente

e provido algum tipo de sincronizao entre elas.

(a) (b)

Figura 3.5 Arquitetura Replicada.


31/114

29

Como vantagem, melhora a utilizao dos recursos de rede, pois

transmite apenas dados relacionados com os eventos dos controladores. Tambm

cada cliente pode ser utilizado isoladamente sem colaborao.

A sincronizao baseada em eventos do controlador (Figura 3.5a) pode

no ser adequada para muitos tipos de sistemas de groupware educacionais,

porque esta arquitetura est naturalmente associada ao tipo de acoplamento

WYSIWIS estrito.

J a sincronizao baseada nos modelos (Figura 3.5b) permite

acoplamento do tipo algum tipo de WYSIWIS relaxado, o que no obriga que

todos os alunos estejam na mesma posio e vejam a mesma coisa.

3.2.1.3. Distribuda

Esta arquitetura caracterizada pela distribuio dos componentes

MVC entre diversos computadores (Figura 3.6). O modelo mantido em um

servidor e compartilhado com todos os clientes, os quais possuem seus prprios

controladores e vises.

Figura 3.6 Arquitetura Distribu da.

A arquitetura distribuda requer que somente eventos de atualizao do

modelo sejam enviados pela rede, tornando o uso dos recursos de rede mais

eficiente. O acoplamento acontece no nvel do modelo, podendo suportar

WYMIWIM. Assim os usurios podem colaborar sobre o mesmo modelo, mas

utilizando vises completamente diferentes.


32/114

30

Este tipo de arquitetura de distribuio tem a desvantagem de apenas

poder ser utilizada em rede, no podendo ser executada em modo monousurio.

Do ponto de vista educacional esta arquitetura permite o uso de mltiplasrepresentaes, por exemplo, um aluno pode estar vendo uma tabela, enquanto

outro est vendo um grfico, que representam os mesmos dados.

3.2.1.4. Hbrida

Nesta arquitetura so integradas caractersticas das arquiteturas

replicada e distribuda (Figura 3.7), capturando o melhor dos dois mundos,

gerando um modelo hbrido onde as aplicaes podem ser utilizadas em modo

monousurio e em modo colaborativo.

Figura 3.7 Arquitetura Hbrida.

As aplicaes podem executar em modo monousurio utilizando seu

prprio modelo e salvando seu estado em um arquivo local, ou podem conectar-se

com o servidor que prov armazenamento persistente favorecendo atualizao

WYMIWIM entre os clientes ativos.

Do ponto de vista educacional, aplicaes construdas com este modelo

permitem que os alunos possam utilizar as ferramentas individualmente para

praticar antes de conectar com outros colegas e trabalhar colaborativamente.

3.3. CONSIDERAES FINAIS

Adotaremos a arquitetura hbrida, que apresenta caractersticas

unificadas das arquiteturas replicada e distribuda, capturando o melhor dos dois


33/114

31

mundos, gerando um modelo hbrido onde as aplicaes podem ser utilizadas

tanto em modo monousurio como em modo colaborativo.

A manuteno do espao compartilhado do prottipo seguir a

arquitetura com estado compartilhado, permitindo o acoplamento do tipo

WYSIWIS relaxado. Este acoplamento acontece no nvel do modelo, assim os

usurios podem colaborar sobre o mesmo modelo, mas utilizando vises

completamente diferentes.

No prximo captulo apresentamos a metodologia utilizada no

desenvolvimento deste trabalho, que utilizou tcnicas de design de usabilidade

para resolver problemas relativos interao em componentes sncronos de

aprendizagem.


34/114

32

4. METODOLOGIAA anlise de requisitos uma das mais importantes fases do

desenvolvimento de software e muito tem se escrito sobre tcnicas para garantir o

levantamento eficaz de requisitos. exemplo disso, Ferre [FER2003] (Figura 4.1)

apresenta um mapeamento entre diversas tcnicas de usabilidade e suas

aplicaes nas atividades de anlise de requisitos.

Figura 4.1 Alocao de tcnicas de usabilidade aplicadas anlise.

Dentre as diversas tcnicas disponveis para colaborar com a anlise

de requisitos, escolhemos trs para compor nossa metodologia.

A Figura 4.2 apresenta como cada uma das tcnicas selecionadas foi

aplicada na metodologia. Na primeira fase foi aplicada a metodologia de anlise

de competidores com o objetivo de levantar os requisitos bsicos dos sistemas de

groupware j existentes. Uma vez levantados os requisito bsicos, estes foram

implementados em um prottipo que posteriormente foi utilizado na construo de

cenrios que ajudaram a levantar novos requisitos para o sistema.


35/114

33

Figura 4.2 Fluxo de aplicao das tcnicas selecionadas.

A seguir, apresentamos em detalhes como cada uma das tcnicas foi

aplicada no desenvolvimento deste trabalho.

4.1. OBJETIVOS DA METODOLOGIA

4.1.1. GERAL

Levantar requisitos que favorecem a interao em grupo a serem

incorporados em uma plataforma de groupware, visando o apoio aodesenvolvimento de componentes educacionais sncronos.

4.1.2. ESPECFICOS

Entender e levantar os requisitos da interao sncrona que so

tratados em plataformas contemporneas.

Implementar um prottipo de uma plataforma de groupware, que

incorpore os requisitos elicitados;

Especificar requisitos a partir da gerao de cenrios de uso, baseados

em resultados de experimentos com usurios.

4.2. ANLISE DE COMPETIDORES

A anlise de competidores uma tcnica de HCI que consiste em

examinar produtos existentes para coletar guidelines, princpios e boas prticas de


36/114

34

design para construo de um novo sistema [BOR2000]. A anlise de

competidores til para:

Identificar as melhores prticas;

Levantar requisitos;

Avaliar os pontos fortes e fracos de nossos competidores;

Reutilizar experincias de design; e

Colaborar com a especificao funcional de novos sistemas.

Atravs do exame dos produtos competidores, podemos identificar ascaractersticas, funcionalidades e elementos de projeto e servios oferecidos pelos

competidores aos seus usurios. Uma vez identificados, esses elementos podem

ser reaplicados em novos produtos ou podem ser evitados se a experincia do

competidor for negativa.

A anlise de competidores foi utilizada neste trabalho para ajudar a

entender e levantar os requisitos da interao sncrona que esto incorporados

nas plataformas de groupware sncronos encontradas na literatura com o objetivo

de incorporar as boas prticas de design e evitar os problemas j identificados por

estas plataformas.

4.3. PROTOTIPAO

A elaborao de prottipos intermedirios uma tcnica muito comum

na literatura, principalmente usado na fase de levantamento de requisitos

[PAD2003]. Prottipos aumentam a eficcia das atividades de levantamento de

requisitos e a qualidade dos requisitos resultantes. Essa tcnica teve comoobjetivo a explorao dos aspectos crticos dos requisitos levantados na anlise

de competidores.

Como a plataforma de groupware destina-se a oferecer uma infra-

estrutura de colaborao, fez-se necessria a concepo de uma ferramenta

colaborativa que utilizasse servios oferecidos pela plataforma e fornecesse

servios perceptveis e usveis pelo usurio final.


37/114

35

4.4. CENRIOS

A anlise de cenrio uma metodologia que colabora para elicitao de

requisitos de um sistema. Anlise de cenrio o processo de compreenso,anlise e descrio do comportamento do sistema durante uma forma particular

esperada de uso do sistema [HSI1994]. Sua descrio vvida da atividade humana

promove reflexo focada sobre a utilidade e usabilidade de uma interveno de

projeto visionria [CAR1998]. O cenrio pode funcionar como um prottipo leve

[CAR2000], pois se constitui numa viso concreta e no apenas uma lista de

requisitos do sistema, que pode ser apresentado ao usurio, expondo o projeto a

sugestes e crticas.Para facilitar o surgimento dos requisitos, foram construdos cenrios

caricaturados positivos e negativos (plus and minus scenarios [BD2000]). Isto

favoreceu o surgimento de novas demandas para a futura aplicao. O uso de

cenrios caricaturados ajuda a capturar melhor as vantagens e problemas do

sistema proposto.

Neste trabalho apresentamos como requisitos podem ser desenvolvidos

a partir da metodologia de anlise de cenrios e mais especificamente como oscenrios caricaturados podem ajudar a refinar nossa viso inicial do sistema,

destacando os pontos positivos e negativos de nossa soluo.

Aplicamos a metodologia de cenrios de forma iterativa neste trabalho,

Os cenrios criados abordam a colaborao entre alunos para realizao de tarefa

compartilhada apoiada por uma ferramenta sncrona colaborativa construda sobre

nossa plataforma de groupware, Plattus.

Usamos cenrios a partir de um conjunto de objetivos de alto nvel, quefazem sentido para o usurio, atravs da manipulao da interface da ferramenta,

mas que nos ajudaram a levantar requisitos que devem ser embutidos dentro da

plataforma de groupware e que apoiaro a construo de novas ferramentas

colaborativas.

Na primeira iterao os cenrios, apesar de fictcios, basearam-se no

trabalho de mestrado de Vnia Alves [ALV2005], no qual a autora observou vrios


38/114

36

usurios usando a ferramenta Grard, construda a partir do prottipo da

plataforma Plattus. Assim, a primeira iterao reflete uma srie de situaes reais

experimentadas por vrios usurios, no uso da ferramenta Grard, compiladas emuma nica histria hipottica.

A segunda iterao utiliza uma histria totalmente fictcia, retratando um

cenrio futuro, pois ao invs de implementar um novo prottipo real para fazer

testes de usabilidade, o novo cenrio funciona com um prottipo leve (soft

prototype [CAR2000]), onde o cenrio apresenta um novo sistema, j

incrementado com novas funcionalidades que buscam suprir os requisitos

levantados na primeira iterao. Os elementos do futuro sistema aparecem nocenrio embutidos nas interaes do usurio. A partir deste novo cenrio, baseado

no novo sistema retratado por ele, um novo conjunto de requisito foi levantado,

apresentando necessidade de novas funcionalidades ou refinando os requisitos

levantados na iterao anterior.


39/114

37

5. ANLISE DE COMPETIDORESNeste captulo, apresentaremos os resultados da anlise de

competidores que teve como objetivo identificar as caractersticas, funcionalidades

e elementos de projeto e servios oferecidos pelos produtos competidores.

5.1. RENDEZVOUS

Rendezvous [PAT1990] [PAT1991] uma arquitetura para criao de

aplicaes sncronas multiusurias. Ela composta de duas partes distintas, uma

arquitetura de execuo (runtime) para o gerenciamento de sesses multiusurias

e a arquitetura de acionamento (start-up) para gerenciamento de conexo inicial

dos usurios (login).

Figura 5.1 CardTable: uma aplicao desenvolvida com Rendezvous

O modelo de comunicao do Rendezvous centralizado no servidor

chamado RESERV, que intermedia toda a comunicao. Os clientes utilizam


40/114

38

terminais virtuais que se comunicam com um processo centralizado que controla a

aplicao.

A manuteno do estado compartilhado no Rendezvous garantida

atravs de restries (constraints) que garantem a atualizao de objetos em trs

dimenses: compartilhamento de objetos bsicos (underlying objects),

compartilhamento de vises (views) e compartilhamento de acesso.

Uma famosa aplicao construda pelo Rendezvous foi a CardTable

(Figura 5.1). CardTable uma aplicao multiusuria que permite vrios usurios

dispersos geograficamente interagirem simultaneamente com uma mesa de cartas

virtual. A CardTable no um jogo especfico de cartas e sim uma simulao de

um ambiente fsico provido quando vrios jogadores sentam ao redor de uma

mesa para jogar cartas, as regras do jogo devem ser definidas pelos jogadores.

5.2. NSTP

NSTP (Notification Service Transfer Protocol) [PAT1996] [DAY1997]

um protocolo desenvolvido com a preocupao da manuteno da consistncia

entre aplicaes compartilhadas. NSTP prov um servio centralizado para

construo de sistemas de groupware sncronos. Neste protocolo, os clientes

trocam mensagens com o servidor de notificaes (Notification Server), que tem o

propsito de compartilhar o estado da aplicao entre um conjunto de clientes que

trabalham juntos.

NSTP tem quatro tipos de objetos: lugares (places), coisas (things),

fachadas (facades) e o prprio servidor de notificao. Place representa o espao

que compartilhado pelos clientes da aplicao. Things so os objetos dentro do

espao compartilhado que podem ser manipulados pelos clientes e Facades so

vises pblicas do espao compartilhado.

O protocolo do NSTP define ama arquitetura de colaborao e o

conjunto de regras que rege a comunicao entre os clientes. O NSTP foi

implementado em Java e C++. A implementao em J ava, chamada PlaceHolder,

est disponvel sem qualquer custo para usurios no comerciais.


41/114

39

Um conceito interessante do NSTP que ele prev browsers que

permitem aos usurios navegarem atravs das fachadas dos lugares (places) e a

possibilidade de existirem objetos dentro dos ambientes que so links para outroslugares.

5.3. ANTS

ANTS [GAR2001] [GAR2002] um framework colaborativo para

desenvolvimento de aplicaes multiusurias. Baseado totalmente na tecnologia

J 2EE de J ava, o ANTS utiliza o modelo de componentes J avaBeans para

simplificar o desenvolvimento de aplicaes colaborativas.

O modelo de comunicao do ANTS centralizado, baseado em um

servio de mensagens. A camada de comunicao funciona como uma camada

de adaptao para diferentes servios de middleware. O canal de comunicao,

chamado de Collaboration BUS, destina-se a propagao do estado compartilhado

entre as aplicaes e ao monitoramento de eventos pelo componente de

percepo (awareness).

O ANTS apresenta um modelo bem elaborado de captura de

informaes de percepo sobre as aes dos usurios. O componente de

percepo, chamado de AWS, baseado no modelo sensor/mediador/atuador.

Sensores podem ser associados a determinados eventos (mensagens) e o

mediador liga um sensor a um ou mais atuadores. Assim que ocorre um evento o

mediador dispara todos os atuadores ligados ao sensor. Os atuadores podem, por

exemplo, armazenar os dados em banco de dados, mandar um email ou enviar

mensagens para os usurios. Isso permite um sistema bastante extensvel e

flexvel para provimento e armazenamento de informaes de percepo.


42/114

40

Figura 5.2 MapTool: Ferramenta desenvolvida com ITCOLE architecture.

A arquitetura bem projetada do ANTS permitiu que alguns projetos

fossem construdos a partir de sua estrutura como o J LE [GAR2001], MOVE

[GAR2002], AORTA [ORO2004] e ITCOLE1architecture (Figura 5.2).

5.4. DREAMTEAM

O DreamTeam [ROT1998] [ROT2000] um ambiente que permite odesenvolvimento de aplicaes cooperativas como se fossem aplicaes

monousurias, sem a preocupao com detalhes de rede. O ambiente composto

de trs componentes: um ambiente de desenvolvimento, um ambiente de

execuo (Figura 5.3) e um ambiente de simulao.

DreamTeam baseia-se em uma arquitetura de comunicao

descentralizada, onde no h necessidade de um servidor para gerenciar a

comunicao entre os usurios. Isto traz uma vantagem de no se ter um ponto degargalo no sistema, mas apresenta um modelo muito mais complexo de

gerenciamento do estado compartilhado da aplicao.

1 http://ants.dif.um.es/cscl/


43/114

41

Figura 5.3 Ambiente de execuo do DreamTeam

Devido ao modelo de comunicao descentralizado o DreamTeampossui tambm um gerenciamento de sesso dos usurios descentralizado. A

sesso gerenciada pelo computador do usurio que cria a sesso e os outros

usurios podem associar-se sesso. Quando o usurio responsvel pela criao

da sesso sai, os outros usurios continuam engajados na sesso, mas nenhum

novo membro pode entrar.


44/114

42

Figura 5.4 Plataforma DreamTeam rodando em dispositi vos Palm.

Dos ambientes pesquisados, o DreamTeam o nico que oferece um

ambiente de simulao que permite testar os efeitos da rede no desempenho das

aplicaes compartilhadas. O ambiente simula atrasos de rede, falhas de

comunicao, etc., permitindo ao desenvolvedor testar o uso dos aplicativos

compartilhados em situaes adversas [ROT2000].

O DreamTeam tambm o nico dos competidores analisados que

apresenta uma verso do ambiente que compatvel com dispositivos portteis(Figura 5.4).

5.5. GROUPKIT

Groupkit [ROS1996] um pacote (toolkit) para desenvolvimento de

aplicaes distribudas, desenvolvido na linguagem TCL-TK. O Groupkit oferece

servios padronizados para groupware, como gerenciamento de sesso,

comunicao e interface de usurio distribuda.

Groupkit usado para construir aplicaes colaborativas sncronas

(Figura 5.5), tais como ferramentas de desenho, editores de texto compartilhados,

sistemas de reunies, que podem ser utilizados por vrios usurios

simultaneamente.


45/114

43

Figura 5.5 Aplicaes desenvolvidas com Groupkit .

O modelo de comunicao utilizado pelo Groupkit para manuteno do

estado compartilhado das aplicaes clientes descentralizado. Porm, durante a

fase inicial de conexo, conhecida como rendezvous, na qual o usurio entra no

ambiente, o modelo de comunicao centralizado.

Um servidor chamado registrar responsvel em fazer a autenticao

dos usurios. Uma vez que o usurio esteja conectado e autenticado, toda a

comunicao ocorre diretamente entre os clientes, sem a interveno do servidorregistrar.

O Groupkit oferece alguns elementos de interface (widgets) que visam

dar suporte conscincia de grupo (awareness), como: Teleponteiros, Viso

Miniaturas, Viso Radar e Barra de rolagem multiusurio. As aplicaes so

desenvolvidas integrando esses elementos na aplicao compartilhada, sem a

preocupao com aspectos de distribuio, como por exemplo, comunicao.


46/114

44

5.6. HABANERO

O Habanero [NCS2005] uma plataforma de apoio colaborao

sncrona. Habanero tem como objetivo converter applets J ava em objetosdistribudos. Isso no feito automaticamente, necessrio alterar o cdigo fonte

do applet.

Qualquer applet existente pode ser convertido em uma aplicao

compartilhada dentro do ambiente Habanero, atravs de pequenas alteraes no

cdigo fonte. Este processo chamado de Habanerizao de umapplet J ava.

O ambiente colaborativo inclui um servidor de sesso e um cliente

(Figura 5.6) que disponibiliza ao usurio uma variedade de aplicaes (Hablets). A

interface do cliente permite listar, criar, associar-se e interagir com sesses no

servidor do Habanero [NCS2005].

O modelo de comunicao centralizado. Baseado no modelo

Cliente/Servidor (C/S). necessrio que o servidor esteja executando e disponvel

na rede para que as aplicaes clientes possam se comunicar.

Os usurios podem criar um perfil (user profile) que pode conter

informaes pessoais, incluindo foto. Apesar disto a conscincia de grupo

(awareness), limita-se basicamente ao controle de sesso.


47/114

45

Figura 5.6 Tela do cl iente Habanero.

A idia bsica do Habanero a distribuio (broadcast) das aes dos

usurios para cada um dos participantes da sesso, o que caracteriza a

arquitetura sincronizada, na qual a manuteno do estado compartilhado

alcanada sincronizando os ambientes atravs da replicao de eventos.

O Habanero oferece um conjunto de ferramentas, como por exemplo,

quadro branco compartilhado, chat e uma ferramenta para visualizao de

estruturas de molculas.

5.7. SHARE-K IT

Share-Kit [ROT1998] uma plataforma para desenvolvimento deaplicaes compartilhadas. Desenvolvido na linguagem C e baseado no ambiente

Unix, Share-Kit utiliza o modelo de comunicao centralizado, na qual um servidor

deve estar rodando e seu endereo na rede dever ser conhecido das aplicaes

clientes.


48/114

46

As aplicaes clientes (Figura 5.7) so executadas diretamente a partir

da linha de comando passando-se o endereo do servidor atravs de parmetros.

Share-Kit no possui gerenciamento de usurios e nem o conceito de sesso.

O foco do Share-kit a aplicao compartilhada e no os usurios, no

h comunicao direta entre usurios, somente o uso da aplicao compartilhada,

essa era uma caracterstica muito comum na primeira gerao de sistemas de

groupware.

O fato de no ter o conceito de sesso resulta em apenas um espao

virtual compartilhado, todos que executam a aplicao no mesmo momento esto

no mesmo espao virtual, e no tem como escolher com quem trabalhar ou

trabalhar separadamente em outra atividade.

Figura 5.7 Aplicao cliente do Share-Kit.

Share-Kit mantm o estado compartilhado das aplicaes pelareplicao de eventos atravs da transmisso simultnea para vrias estaes de

trabalho de chamadas remotas de procedimentos (Multicast-RPC).

5.8. COMPARAO ENTRE COMPETIDORES

A Tabela 5.1 apresenta uma comparao entre os produtos

competidores analisados. A maioria dos artigos que serviram de fonte de

informao sobre os competidores no apresentaram detalhes de implementao


49/114

47

dos sistemas e nem se apresentam de forma homognea. Logo, algumas

informaes s puderam ser inferidas a partir das caractersticas de cada

competidor.

Tabela 5.1 Comparao entre competidores

Ambientes

Critrios

ANTS DreamTeam

Groupkit Habanero NSTP Rendezvous Share-K it

Modelo decomunicao

Centra-lizado

Descentraliza-

doHbrido

Centrali-zado

Centra-lizado

Centrali-zado

Centrali-zado

Manutenodo estadocompartilhado

Com-parti-lhado

Sincro-nizado

Hbrida HbridaCom-parti-lhado

Comparti-lhado

Sincro-nizado

Conscincia decolaborao

Sim Sim Sim No Sim Sim No

Controle desesso

Sim Sim Sim Sim Sim Sim No

Definio depapeis

No No Sim No Sim Sim No

Percepo Sim Sim Sim Sim Sim Sim No

Plataformadependente No No Sim No No Sim Sim

5.9. REQUISITOS LEVANTADOS A PARTIR DA ANLISE DE COMPETIDORES

A partir das informaes coletadas na anlise de competidores,

pudemos identificar e levantar os requisitos da interao sncrona que esto

incorporados nas plataformas de groupware sncronos encontrados e j

identificados por estas plataformas. A seguir, apresentamos a lista de requisitos

derivados da anlise de competidores:

[RQ01] A plataforma de groupware deve fornecer servio de comunicao

entre as aplicaes compartilhadas

Comunicao o requisito bsico dos sistemas colaborativos, sem a

capacidade de comunicao no pode haver colaborao. Como pde ser visto,

as aplicaes de groupware dependem essencialmente da comunicao para

manter o controle do estado do ambiente distribudo.


50/114

48

No nvel de aplicao, a comunicao assume seu papel funcional

(comunicao entre processos) visando oferecer suporte para a comunicao

entre as diversas instncias da aplicao de grupo, tendo como principal objetivo amanuteno do ambiente virtual.

[RQ02] A plataforma de groupware deve fornecer servio de comunicao

entre os usurios das aplicaes compartilhadas

A plataforma de grupo deve oferecer suporte comunicao entre dois

ou mais participantes humanos do ambiente compartilhado. Este tipo de

comunicao pode incluir texto, voz, imagens, vdeos, gestos e outras formas de

comunicao no verbal.

[RQ03] O pro jetista da plataforma de groupware deve escolher o modelo que

ser usado para fornecer comunicao entre as aplicaes colaborativas

No modelo centralizado, exemplo do modelo cliente/servidor clssico,

adotado pela maioria dos competidores analisados. Neste modelo quando se

incrementa o nmero de clientes participantes do ambiente virtual, o servidor

torna-se o gargalo da comunicao, j que toda a comunicao entre os

participantes distribuda pelo servidor.

O modelo descentralizado conhecido como ponto-a-ponto, adotado pelo

DreamTeam, pode superar esta limitao, mas em contrapartida aumenta a

complexidade da aplicao. Neste modelo, os participantes trocam informaes

entre si, sem um servidor intermedirio. No h necessidade que todos os pontos

estejam conectados diretamente entre si. No entanto, existe a necessidade de

conexes indiretas e que todos os participantes devem ter conhecimento de quem

est conectado ao ambiente virtual.

Algumas solues intermedirias baseiam-se em modelos hbridos,

derivados dos dois modelos anteriores, como o caso do GroupKit que introduziu

um Servidor, chamado Registrar, que fornece percepo de presena entre as

aplicaes clientes. Cada cliente toma cincia da presena dos demais atravs do

Registrar, porm a comunicao entre os clientes realizada diretamente.


51/114

49

[RQ04] A plataforma de groupware deve ser capaz de recuperar-se de falhas

de comunicao (tolerncia falhas)

Sistemas de grupo so caracteristicamente sistemas distribudos e

conseqentemente susceptveis falhas de comunicao. Isto implica que a

plataforma deve ter mecanismos que permitam recuperar-se de atrasos da rede,

falhas de comunicao, entre outros. Essa caracterstica pode, por exemplo,

garantir que um usurio que tenha uma pane em sua rede e perca a comunicao

com o servidor, possa voltar a participar da atividade colaborativa, to logo seja

restabelecida a comunicao.

[RQ05] Sistemas colaborativos devem ser conscientes de sua colaborao

Sistemas colaborativos devem ser construdos com a inteno explcita

de serem usados colaborativamente. Algumas plataformas para desenvolvimento

de sistemas colaborativos, a exemplo do Habanero, podem compartilhar

aplicaes monousurias, mas isso limita a interao entre os usurios porque as

aplicaes no foram construdas para serem colaborativas.

[RQ06] A plataforma de groupware deve fornecer um ambiente virtual

compartilhado (shared workspace)

O Ambiente virtual deve ser compartilhado por todos os usurios do

grupo e isso exige que qualquer ao realizada por um dos usurios seja refletida

para todos os outros. Neste caso, a estrutura de comunicao utilizada pela

prpria aplicao de grupo, sem a interferncia do usurio, para manter a

sincronia da viso compartilhada do ambiente.

[RQ07] A plataforma de groupware deve coordenar o acesso ao ambientevirtual compartilhado

O acesso concorrente necessita de polticas que resolvam conflitos de

acesso ao mesmo objeto no ambiente compartilhado. O Rendezvous atacou o

problema a partir de uma viso de escalonamento, baseada na literatura de

sistemas operacionais. Porm Greenberg e Marwood [GRE1994] afirmam que no

existe um esquema de controle de concorrncia que atenda todos os tipos de


52/114

50

aplicaes de groupware, simplesmente porque o usurio parte ativa do

processo.

Polticas de acesso ao ambiente compartilhado so conhecidas na

literatura como Floor Policies [ABD1997] [BOY1993] [GUE2001]. O Floorcontrola

a habilidade do usurio de interagir com objetos compartilhados no ambiente.

Alguns exemplos de polticas de acesso encontradas na literatura so:

Request-and-Get policy: Permite que o usurio receba o direito de

interagir com objetos no ambiente compartilhado imediatamente aps solicitar o

Floor.

Request-and-Wait policy: Permite ao usurio requerer o Floor, mas

apenas recebe direito de interagir quando o usurio que mantm o Floorliber-lo.

No-Floor policy: Permite que qualquer participante interaja com o

ambiente compartilhado. Ideal para aplicaes simples, como Whiteboard.

[RQ08] A plataforma de groupware deve prover gerenciamento de sesso

Uma sesso em uma plataforma de groupware ser necessariamente

sncrona e tipicamente inicia-se com a entrada do primeiro usurio no ambientecompartilhado at a sada do ltimo usurio do mesmo ambiente.

necessrio o gerenciamento das sesses dos usurios na plataforma,

gerenciando grupos de trabalho e monitorando usurios que entram e saem dos

grupos. Cada sesso representa um grupo de trabalho diferente. Usurios que

trabalham em uma determinada sesso (grupo), no devem visualizar o trabalho

de outros usurios que estejam em sesses diferentes, mesmo que estejam

utilizando a mesma aplicao colaborativa.

[RQ09] A plataforma de groupware deve fornecer segurana de acesso a

sesses

A plataforma de grupo deve fornecer um mecanismo de autenticao

dos usurios, manter uma lista de sesses ativas e a lista de usurios associados

a estas sesses. Opcionalmente podem ser criados perfis de usurios, que


53/114

51

definem quais aplicaes o usurio pode executar e em que tipos de sesses, ou

mesmo a que sesses, os mesmos podem associar-se.

[RQ10] A plataforma de groupware deve permitir a definio de papis para

os usurios que participam de uma atividade compartilhada

Muitas aplicaes colaborativas exigem que os usurios desempenhem

diferentes papis durante a colaborao com diferentes direitos de acesso aos

objetos no ambiente compartilhado. Certas operaes como excluir podem ser

restritas somente a certos tipos de usurios.

As aplicaes educacionais, principalmente, necessitam diferenciar, por

exemplo, entre professores, tutores e alunos, pois so usurios que certamente

tero funes e privilgios diferenciados na atividade colaborativa.

[RQ11] A plataforma de groupware deve prover aos usurios informaes de

percepo teis para a colaborao e coordenao da atividade colaborativa

Percepo a compreenso que um indivduo deve ter sobre as

atividades dos outros, a qual ir prover um contexto para as suas prprias

atividades. Esse contexto utilizado para garantir que as contribuies individuaisso relevantes para as atividades do grupo como um todo, e para avaliar as aes

individuais com respeito a metas e progresso do grupo [DOU1992].

As informaes de percepo so fornecidas aos usurios finais dos

sistemas de groupware atravs de mecanismos de percepo. Os mecanismos de

percepo correspondem, portanto, s tcnicas utilizadas por um sistema para

fornecer informaes destinadas percepo.

[RQ12] A plataforma de groupware pode prover widgets colaborativos quediminuam o esforo de desenvolvimento de novas aplicaes colaborativas

Widgets so elementos de interface projetados para apoiar o

desenvolvimento rpido de aplicaes. Estes elementos empregam algum tipo de

representao grfica e so usualmente integrados prpria janela da aplicao

colaborativa. O Groupkit [ROS1996], por exemplo, fornece uma coleo de


54/114

52

widgets de percepo como Teleponteiros, Viso Miniaturas, Viso Radar e Barra

de rolagem multiusurio.

[RQ13] De preferncia a plataforma de groupware deve multi -plataforma

Com a popularizao dos sistemas operacionais livres e o grande

avano tecnolgico de novos dispositivos, como palms e celulares, o ambiente de

execuo dos sistemas compartilhados tende a ser cada vez mais heterogneo.

Plataformas de grupo devem optar por linguagem multiplataforma que permitam a

execuo de suas aplicaes em uma grande variedade de sistemas operacionais

e dispositivos sem a necessidade de recompilao.

5.10. CONSIDERAES FINAIS

A anlise dos produtos existentes na literatura permite o

reaproveitamento de requisitos. A anlise de competidores favoreceu o

reaproveitamento de requisitos, que puderam ser aplicados no desenvolvimento

dos prottipos que sero apresentados no prximo captulo.

A anlise de competidores til para: identificar as melhores prticas;

levantar requisitos; avaliar os pontos fortes e fracos de nossos competidores;reutilizar experincia de design e colaborar com a especificao funcional de

novos sistemas.

No prximo captulo apresentamos os resultados da prototipao de

uma plataforma de groupware (Plattus) e um componente sncrono de

aprendizagem (Grard).


55/114

53

6. PROTOTIPAO

6.1. PROTTIPO DA PLATAFORMA DE GROUPWAREPLATTUSA plataforma de groupware visa oferecer suporte construo de

ferramentas de apoio a atividades colaborativas em ambientes virtuais de ensino

na Web, fornecendo a infra-estrutura de comunicao e coordenao da atividade

de grupo.

Com a plataforma possvel criar diferentes aplicaes educacionais

que podero ser compartilhadas por um grupo de alunos, permitindo que o

significado de conceitos abordados em sala de aula sejam progressivamente

construdos mediante a ao colaborativa dos participantes de uma atividade

sobre uma mesma interface compartilhada.

Nesta seo, apresentaremos os detalhes de implementao do

prottipo da plataforma de groupware. No decorrer do texto quando uma

referncia do tipo [RQxx] aparecer, significa que um requisito levantado na anlise

de competidores foi atendido pelo prottipo.

6.1.1. ARQUITETURA DE DISTRIBUIOAdotamos a arquitetura de distribuio hbrida, que apresenta

caractersticas unificadas das arquiteturas replicada e distribuda. A manuteno

do espao compartilhado baseada no componente modelo da arquitetura MVC,

permitindo o acoplamento do tipo WYSIWIS relaxado, o que no obriga que todos

os alunos estejam na mesma posio e vejam a mesma coisa. Este acoplamento

acontece no nvel do modelo, assim os usurios podem colaborar sobre o mesmo

modelo, mas utilizando vises completamente diferentes.

6.1.2. COMUNICAO

A plataforma de groupware composta de duas partes distintas: O

Servidor de grupo, que responsvel pela comunicao e coordenao da

atividade de grupo e a API de groupware que fornece todas as funcionalidades

para conexo e comunicao entre as ferramentas colaborativas e o Servidor de

grupo.


56/114

54

A API de groupware funciona como uma camada intermediria entre as

ferramentas colaborativas e a rede, padronizando a comunicao e permitindo

separar a preocupao com os objetivos especficos da aplicao da preocupaocom os requisitos comuns aos programas colaborativos.

Toda a comunicao [RQ01] baseada em mensagens que so

enviadas entre as ferramentas colaborativas educacionais. A comunicao entre

as aplicaes colaborativas se d de forma centralizada [RQ03]. Todas as

mensagens so enviadas pelos clientes para o servidor, o qual se encarrega de

repassar para os demais usurios conectados. O prottipo suporta cinco tipos de

mensagens:

Mensagens de Controle: mensagens usadas pela plataforma de

groupware sncrona e que

alves, e. c. m., design de componentes educacionais síncronos, dissertação (mestrado) –...

Documents