-
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
4/114
DEDICATRIA
Aos meus pais.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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/
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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).
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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.
-
7/29/2019 Alves, E. C. M., Design de componentes educacionais sncronos, Dissertao (mestrado) Universidade Federal d
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