Ps-Graduao em Cincia da Computao

DESIGN DE COMPONENTES EDUCACIONAIS SNCRONOS

Por

ENOQUE CALVINO MELO ALVES

Dissertao de Mestrado

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao

RECIFE, AGOSTO/2005

Universidade Federal de Pernambuco Centro de Informtica Ps-Graduao em Cincia da Computao

ENOQUE CALVINO MELO ALVES

DESIGN DE COMPONENTES EDUCACIONAIS SNCRONOS"

Este trabalho foi apresentado ps-graduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para obteno do grau de mestre em Cincia da Computao.

ORIENTADOR: PROF. DR. ALEX SANDRO GOMES

RECIFE, AGOSTO/2005

Alves, Enoque Calvino Melo Design de componentes educacionais sncronos / Enoque Calvino Melo Alves. Recife : O Autor, 2005. 111 folhas : il., tab., fig. Dissertao (mestrado) Universidade Federal de Pernambuco. CIn. Cincia da Computao, 2005. Inclui bibliografia. 1. Cincia da computao Interface homemmquina. 2. Aprendizagem colaborativa apoiada por computador Groupware Requisitos de grupo. 3. Anlise de requisitos Anlise de competidores, cenrios e prototipao. I. Ttulo. 004.5 004.6 CDU (2.ed.) CDD (22.ed.) UFPE BC2005-592

DEDICATRIA

Aos meus pais.

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 como pesquisador. A quem hoje eu considero como um amigo e parceiro na minha vida acadmica. Ao meu pai, Jos 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 madrugadas interminveis 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.

SUMRIO
1. 2. INTRODUO .................................................................................................... 12 AMBIENTES EDUCACIONAIS SNCRONOS ............................................................. 14 2.1. APRENDIZADO COLABORATIVO APOIADO POR COMPUTADOR .......................... 14 Taxonomia da colaborao apoiada por computador ...................... 15 Groupware sncrono de aprendizagem............................................ 18

2.1.1. 2.1.2. 2.2. 3.

PROBLEMA ................................................................................................ 20

ARQUITETURAS DE GROUPWARE........................................................................ 21 3.1. MODELOS DE REFERNCIA ......................................................................... 22 Modelo de Patterson........................................................................ 22 Modelo de Dewan ............................................................................ 24

3.1.1. 3.1.2. 3.2.

ESTILOS ARQUITETURAIS ............................................................................ 26 MVC................................................................................................. 26

3.2.1. 3.3. 4.

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

METODOLOGIA ................................................................................................. 32 4.1. OBJETIVOS DA METODOLOGIA .................................................................... 33 Geral ................................................................................................ 33 Especficos ...................................................................................... 33

4.1.1. 4.1.2. 4.2. 4.3. 4.4. 5.

ANLISE DE COMPETIDORES ....................................................................... 33 PROTOTIPAO ......................................................................................... 34 CENRIOS................................................................................................. 35

ANLISE DE COMPETIDORES .............................................................................. 37 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. RENDEZVOUS ............................................................................................ 37 NSTP ...................................................................................................... 38 ANTS ...................................................................................................... 39 DREAMTEAM ............................................................................................. 40 GROUPKIT................................................................................................. 42 HABANERO ............................................................................................... 44 SHARE-KIT................................................................................................ 45 COMPARAO ENTRE COMPETIDORES ......................................................... 46

5.9. 5.10. 6.

REQUISITOS LEVANTADOS A PARTIR DA ANLISE DE COMPETIDORES .............. 47 CONSIDERAES FINAIS ......................................................................... 52

PROTOTIPAO ................................................................................................ 53 6.1. PROTTIPO DA PLATAFORMA DE GROUPWARE PLATTUS ................................ 53 Arquitetura de Distribuio............................................................... 53 Comunicao ................................................................................... 53 Conscincia de colaborao ............................................................ 54 Espao compartilhado ..................................................................... 55 Controle de sesso .......................................................................... 55 Definio de papis ......................................................................... 56 Percepo........................................................................................ 56 Componentes de interfaces (widgets).............................................. 56 Independncia de plataforma........................................................... 57

6.1.1. 6.1.2. 6.1.3. 6.1.4. 6.1.5. 6.1.6. 6.1.7. 6.1.8. 6.1.9. 6.2.

SERVIDOR PLATTUS ................................................................................... 57 Mensagens ...................................................................................... 59 API de comunicao cliente/servidor ............................................... 60 Exemplo de envio e recebimentos de mensagens........................... 61

6.2.1. 6.2.2. 6.2.3. 6.3.

COMPONENTE COLABORATIVO GRARD....................................................... 62 Estruturas aditivas ........................................................................... 62 Prottipo do componente Grard..................................................... 65

6.3.1. 6.3.2. 6.4. 7.

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

ANLISE DE CENRIOS ...................................................................................... 69 7.1. PRIMEIRA ITERAO .................................................................................. 69 Atores .............................................................................................. 69 Contexto .......................................................................................... 69 Ambiente (setting)............................................................................ 69 Roteiro (plot) .................................................................................... 71 Roteiro positivo ................................................................................ 77 Roteiro negativo............................................................................... 79 Requisitos levantados...................................................................... 83

7.1.1. 7.1.2. 7.1.3. 7.1.4. 7.1.5. 7.1.6. 7.1.7. 7.2.

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

7.2.1. 7.2.2. 7.2.3. 7.2.4. 7.2.5. 7.2.6. 7.2.7. 7.3. 8.

Prottipo .......................................................................................... 87 Atores .............................................................................................. 91 Contexto .......................................................................................... 91 Ambiente (setting)............................................................................ 91 Roteiro positivo ................................................................................ 92 Roteiro negativo............................................................................... 94 Requisitos levantados...................................................................... 98

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

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

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

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 de Chat........................................................................................ 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........................................... 63 Figura 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

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

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

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.

ABSTRACT
Computer Supported Collaborative Learning has become a teachinglearning 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 of solving 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.

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 tipo especfico 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

12

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 dos sistemas 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.

13

2. AMBIENTES EDUCACIONAIS SNCRONOS

Aprendizagem 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 COMPUTADOR A aprendizagem colaborativa apoiada por computador (ComputerSupported 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 fundamentse 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. 14

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. Estas aplicaes 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 Johansen [JOH1992]. Segundo Johansen [JOH1992], 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 2

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

15

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

16

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

17

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 copresentes, 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 como sinnimo 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

18

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 2

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

19

2.2. PROBLEMA A manuteno do espao de trabalho compartilhado, ou seja, como manter objetos compartilhados com os quais os usurios interagem, a principal preocupao 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.

20

3. ARQUITETURAS DE GROUPWARE
Este 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.

21

Finalmente, a quarta gerao distingue-se pela incorporao de objetos distribudos (CORBA, DCOM, Enterprise Javabeans e RMI) na construo de groupware e arquitetura baseada em componentes. So representantes desta gerao 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.

22

(a)

(b)

(c)

Arquitetura com estado compartilhado

Arquitetura com estado sincronizado

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 so enviadas para todas as instncias remotas da aplicao, garantindo que a cada alterao de um componente replicado suas cpias sejam atualizadas.

23

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 alunos seriam 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.

24

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.

25

3.2. ESTILOS ARQUITETURAIS Um estilo arquitetural sugere um vocabulrio de componentes (responsveis pelo comportamento do sistema), tipos de conectores (interligando os 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 dados compartilhados. 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 ModelView-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.

26

Figura 3.3 Cenrio de interao do MVC.

A Figura 3.3 tambm mostra um fluxo tpico de interao via MVC, que comea 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 alterado f 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 clientes1 (Figura 3.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.

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

27

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.

28

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 Distribuda.

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.

29

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 mltiplas representaes, 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

30

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.

31

4. METODOLOGIA
A 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.

32

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 ao

desenvolvimento 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

33

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 as caractersticas, 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 como objetivo a explorao dos aspectos crticos dos requisitos levantados na anlise de competidores. Como a plataforma de groupware destina-se a oferecer uma infraestrutura 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.

34

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 os cenrios 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, que fazem 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

35

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 em uma 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 no cenrio 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.

36

5. ANLISE DE COMPETIDORES
Neste 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

37

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 Java, chamada PlaceHolder, est disponvel sem qualquer custo para usurios no comerciais.

38

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 outros lugares. 5.3. ANTS ANTS [GAR2001] [GAR2002] um framework colaborativo para desenvolvimento de aplicaes multiusurias. Baseado totalmente na tecnologia J2EE de Java, o ANTS utiliza o modelo de componentes JavaBeans 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.

39

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 JLE [GAR2001], MOVE [GAR2002], AORTA [ORO2004] e ITCOLE1 architecture (Figura 5.2). 5.4. DREAMTEAM O DreamTeam [ROT1998] [ROT2000] um ambiente que permite o desenvolvimento 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 de gargalo no sistema, mas apresenta um modelo muito mais complexo de gerenciamento do estado compartilhado da aplicao.

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

40

Figura 5.3 Ambiente de execuo do DreamTeam

Devido ao modelo de comunicao descentralizado o DreamTeam possui 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.

41

Figura 5.4 Plataforma DreamTeam rodando em dispositivos 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.

42

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 servidor registrar. 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.

43

5.6. HABANERO O Habanero [NCS2005] uma plataforma de apoio colaborao sncrona. Habanero tem como objetivo converter applets Java em objetos distribudos. 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 um applet Java. 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.

44

Figura 5.6 Tela do cliente 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-KIT Share-Kit [ROT1998] uma plataforma para desenvolvimento de aplicaes 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.

45

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 pela replicao 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

46

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

ANTS

Dream Team

Groupkit

Habanero

NSTP

Rendezvous

Share-Kit

Critrios Modelo de comunicao

Descen Centratralizalizado do ComManuteno Sincropartido estado nizado compartilhado lhado Conscincia de Sim Sim colaborao Controle de Sim Sim sesso Definio de No No papeis Percepo Plataforma dependente Sim No Sim No

Hbrido

Centrali- Centrazado lizado Hbrida No Sim No Sim No Compartilhado Sim Sim Sim Sim No

Centralizado Compartilhado Sim Sim Sim Sim Sim

Centralizado Sincronizado No No No No Sim

Hbrida Sim Sim Sim 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.

47

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 a manuteno 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 projetista 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.

48

[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 ambiente virtual 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

49

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 Floor controla 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 Floor liber-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 ambiente compartilhado 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

50

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 individuais so 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 que diminuam 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

51

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).

52

6. PROTOTIPAO
6.1. PROTTIPO DA PLATAFORMA DE GROUPWARE PLATTUS A 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 DISTRIBUIO Adotamos 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.

53

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 preocupao com 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 nunca chegam diretamente ao usurio. So mensagens trocadas somente entre o servidor de grupo e a API de suporte ferramentas educacionais; Mensagens de Erro: como o prprio nome j diz, mensagens de erro so usadas para reportar possveis erros ocorridos no sistema; Mensagens de Modelo: mensagens que encapsulam o modelo de dados do usurio. Cada alterao no modelo de dados requer que o modelo seja transmitido para todos a fim de atualizar suas vises; Mensagens de Chat [RQ02]: utilizadas para que os usurios possam trocar mensagens de texto; Mensagens de Aplicao: mensagens que podem ser usadas livremente pelo desenvolvedor da ferramenta educacional para trocar mensagens referentes ao domnio da aplicao. 6.1.3. CONSCINCIA DE COLABORAO A plataforma de groupware Plattus exige que a aplicao seja desenvolvida com a colaborao em mente [RQ05] e fornece uma API para prover os servios de compartilhamento do ambiente. O que permite um melhor aproveitamento dos recursos compartilhados.

54

6.1.4. ESPAO COMPARTILHADO No Plattus o modelo representa o ambiente virtual que deve ser compartilhado entre os usurios [RQ06], a viso apenas uma representao visual deste modelo e o controle o responsvel pela interao com o usurio e pela atualizao do modelo. Uma cpia da verso corrente do modelo fica armazenada no servidor bem como em cada mquina cliente, sendo o servidor responsvel por atualizar cada cliente no momento em que o modelo modificado. A cada modificao realizada no modelo pelo usurio que detm o controle, o cliente envia o modelo para o servidor, a fim de atualizar a cpia do mesmo no servidor, bem como para que o modelo possa ser enviado para todos os outros clientes. 6.1.5. CONTROLE DE SESSO O controle de acesso implementado pelo prottipo conhecido como Request-and-Wait policy [RQ07]. Neste modelo, se um usurio deseja manipular objetos no ambiente compartilhado, dever requisitar o controle do mesmo. O servidor ir gerenciar a fila de solicitaes de controle, garantindo que cada usurio ter sua vez de modificar o modelo na ordem em que tais solicitaes foram recebidas pelo servidor. Para ter acesso ao ambiente compartilhado o usurio ao entrar no sistema deve informar um login e o nome do grupo ao qual deseja conectar-se. Porm, nenhuma verificao de senha ou qualquer autenticao necessria para utilizar os servios de colaborao oferecidos pelo prottipo. O Plattus responsvel pelo gerencianmento dos grupos monitorando os usurios que entram e saem dos grupos. Cada grupo associado a uma sesso de trabalho diferente [RQ08]. Usurios que trabalham em uma determinada sesso (grupo), no visualizam o trabalho de outros usurios que estejam em sesses diferentes, mesmo que estejam utilizando a mesma aplicao colaborativa.

55

6.1.6. DEFINIO DE PAPIS O prottipo no fornece suporte para definio de papis para os usurios que participam de uma atividade compartilhada. Esta funcionalidade dever ser implementada nas prximas verses do sistema. 6.1.7. PERCEPO A plataforma Plattus apresenta informaes de percepo [RQ11] de sesso, indicando quando algum usurio entra ou sai do ambiente compartilhado. Esse o tipo de percepo mais comumente encontrado nos ambientes de colaborao sncronos. Alm das informaes de sesso, a plataforma fornece informaes sobre qual usurio tem o controle do ambiente colaborativo e quais usurios requisitaram o mesmo. 6.1.8. COMPONENTES DE INTERFACES (WIDGETS) Plattus fornece dois widgets que facilitam a criao de ferramentas colaborativas [RQ12]: A lista de usurios e o componente de chat. A lista de usurios (Figura 6.1) um componente que apresenta uma lista de usurios ativos no ambiente compartilhado. Alm da lista de usurios, o componente apresenta informaes de percepo, como quem tem o controle do ambiente compartilhado ([x]) e quais usurios requisitaram o controle ([r]).

Figura 6.1 Componente Lista de Usurios.

56

O outro componente de interface fornecido pelo Plattus uma janela de chat (Figura 6.2), que permite aos usurios que participam de uma mesma sesso colaborativa trocarem mensagens de texto [RQ02].

Figura 6.2 Componente de Chat.

6.1.9. INDEPENDNCIA DE PLATAFORMA Plattus foi desenvolvido com a linguagem Java, linguagem multiplataforma que permite a execuo de suas aplicaes em uma grande variedade de sistemas operacionais e dispositivos [RQ13]. 6.2. SERVIDOR PLATTUS O servidor Plattus o ponto central da plataforma de groupware Plattus. Ele responsvel pela comunicao e coordenao da atividade de grupo. Toda comunicao entre os clientes e o servidor padronizada pela classe adaptadora chamada WorkGroupConnection que fornece uma API de groupware que fornece mtodos de servio para comunicao entre clientes e servidor.

57

Figura 6.3 Arquitetura simplificada de comunicao

Como pode ser visto no Figura 6.3, cada cliente se conecta ao servidor somente atravs da API fornecida pela classe WorkGroupConnection. Do lado servidor cada cliente considerado membro de um grupo e para cada grupo o servidor cria um GroupManager (Gerenciador de grupo) que responsvel pela coordenao dos membros do grupo. Toda comunicao entre clientes e servidor feita atravs de mensagens. Um exemplo simples do modelo de comunicao pode ser visto na Figura 6.4 contendo trs clientes. O gerenciador de grupos encarrega-se de distribuir as mensagens. O padro de interao o seguinte: 1. Durante a inicializao, todos os clientes conectam-se ao servidor atravs da Interface fornecida pela classe

WorkGroupConnection. O gerenciador de grupo mantm o registro de todos os clientes subscritos no grupo. 2. O cliente que tem o controle chega ao ponto onde necessrio enviar uma mensagem. No caso do exemplo uma mensagem de modelo. Para isso, ele cria e publica a mensagem invocando o mtodo sendModelMessage. A mensagem colocada na fila. 3. Imediatamente, o Gerenciador de grupo envia a mensagem para os clientes atravs da chamada ao mtodo onMessage.

58

Figura 6.4 Modelo de comunicao.

6.2.1. MENSAGENS As Mensagens da plataforma Plattus tm um formato bsico simples mas altamente flexvel, que permite a trocar mensagens com aplicaes em plataformas heterogneas. Uma mensagem da plataforma Plattus composta de trs partes distintas: Cabealhos Data de recebimento (timestamp) Corpo (opcional)

Cabealhos O cabealho da mensagem pode conter vrios campos para valores que clientes podem utilizar para identificar mensagens. Os clientes esto livres 59

para adicionar ler campos ao cabealho das mensagens, porm a funo que ter cada cabealho adicionado pelos clientes ser definida e controlada pelas prprias aplicaes clientes. No futuro campos predefinidos pela plataforma sero adicionados s mensagens para controle da comunicao, como por exemplo, um identificador nico seqencial que permitir a ordenao das mensagens. Data de recebimento A data de recebimento da mensagem armazena a informao de data/hora em que a mensagem foi recebida pelo servidor de groupware. O motivo pelo qual a data/hora do servidor para evitar problemas com a diferena de data entre os diversos clientes envolvidos na comunicao. Corpo da Mensagem O corpo da mensagem contm os dados que realmente esto sendo transmitidos. A plataforma Plattus define 5 tipos diferentes de mensagens:

6.2.2. API DE COMUNICAO CLIENTE/SERVIDOR Como j foi dito antes toda a comunicao entre cliente e servidor definida pela API de groupware encapsulada na classe WorkGroupConnection. A seguir apresentamos os principais mtodos definidos pela API: Open O mtodo Open responsvel por estabelecer uma conexo entre cliente e servidor. O mtodo recebe como parmetros o a identificao da aplicao, o nome do grupo o login e a senha do usurio. SendMessage Existe um mtodo para o envio de cada tipo de mensagem suportada pela plataforma: sendModelMessage, sendChatMessage, sendApplicationMessage. Mensagens de controle e de erro so utilizadas internamente pela plataforma e no esto disponveis mtodos para envio destes tipos de mensagens pelos clientes.

60

RequestFloorControl Utilizado para solicitar o controle do modelo da aplicao. LeaveFloorControl Utilizado para abandonar o controle do modelo da aplicao. Close Fecha a conexo estabelecida com o servidor de groupware. isOpenned Retorna verdadeiro se a conexo com o servidor estiver aberta. addWorkGroupListener Adiciona um Listener para receber mensagem e eventos de forma assncrona, ou seja, sem bloqueio do cliente. 6.2.3. EXEMPLO DE ENVIO E RECEBIMENTOS DE MENSAGENS Dentro da arquitetura Plattus so necessrios alguns passos para estabelecer uma conexo e preparar para enviar e receber mensagens: 1. Obter uma WorkGroupConnection Qualquer cliente precisam obter uma WorkGroupConnection, que ser usada para estabelecer uma conexo.
WorkGroupConnection connection; connection = new WorkGroupConnection(endereco_servidor);

2. Abrir uma conexo Aps obter uma WorkGroupConnection a aplicao cliente pode usa-la para abrir uma conexo com o Servidor Plattus.
connection.open("Gerard", grupo, usuario, senha);

3. Envio de mensagens Como vimos existem 5 tipos diferentes de mensagens na arquitetura Plattus. O cliente utiliza o mtodo correspondente para enviar a mensagem correta:
connection.sendModelMessage(modelo);

61

4. Recebimento de mensagens Para receber mensagens e eventos do servidor de grupo o cliente deve implementar a interface WorkGroupListener. Apresentamos abaixo a interface WorkGroupListener que define os mtodos que devem ser implementado pelo Listener.
public interface WorkGroupListener {

public void onMessage(Message message); public void onClose(); public void onChangeGroupView(GroupView view); public void onTakeControl(); }

6.3.

COMPONENTE COLABORATIVO GRARD Para validar a plataforma Plattus e a arquitetura de colaborao, foi

desenvolvido um componente educacional, chamado Grard, que permite aos alunos interagirem na resoluo de problemas bsicos no campo conceitual das estruturas aditivas, manipulando diagramas padres, definidos por Vergnaud [VER1997], como representao dos problemas propostos. O nome Grard uma homenagem ao pesquisador Grard Vergnaud, propositor da Teoria dos Campos Conceituais [VER1997]. 6.3.1. ESTRUTURAS ADITIVAS Grard Vergnaud, propositor da Teoria dos Campos Conceituais, em seus estudos sobre as estruturas aditivas, fez uma classificao de problemas pelas dificuldades dos problemas e pelos raciocnios requeridos para resolv-los. Vergnaud [VER1997] considera o campo conceitual das estruturas aditivas formado por trs grupos bsicos de problemas, classificados segundo suas caractersticas em: composio, transformao e comparao.

62

Problema: Vnia e Gabriel colecionam chaveiros. Vnia tem 8 chaveiros e Gabriel tem 7. Quantos chaveiros eles tem?
Figura 6.5 Exemplo de diagrama e problema de composio.

Problemas de composio, apresentado na Figura 6.5, representam situaes que envolvem parte-todo. Onde o aluno, ao resolver, deve juntar uma parte com outra para obter o todo, ou subtrair uma parte do todo para obter a outra parte.

Problema: Joo tinha 8 carrinhos, ganhou mais 6 de sua me. Quantos carrinhos Joo tem agora?
Figura 6.6 Exemplo de diagrama e problema de transformao.

A classe de problemas de transformao (Figura 6.6) trata de situaes onde existe uma idia temporal envolvida. Existe um estado inicial que sofre uma transformao de perda ou ganho, chegando ao estado final com uma nova quantidade.

63

Problema: Pedro tem 6 carrinhos, Joo tem dois a mais que Pedro. Quantos carrinhos tem Joo?
Figura 6.7 Exemplo de diagrama e problema de comparao.

Os problemas de comparao, representados na Figura 6.7, implicam na comparao de duas quantidades: uma denominada referente e a outra referido. No exemplo, a quantidade de carrinhos de Joo apontada em relao a quantidade de carrinhos de Pedro. A quantidade de carrinhos de Pedro a referncia (referente), pois para obter-se a quantidade de carrinhos de Joo (referido) necessrio saber a quantidade possuda por Pedro. Dentro destes trs tipos bsicos existe ainda a possibilidade de gerar outras variaes de problemas diferentes dos problemas apresentados nos exemplos anteriores. Como pode ser visto na Figura 6.8, existem diversas variaes para os problemas e diagramas bsicos das estruturas aditivas. Como por exemplo, tomemos o diagrama de composio ( esquerda), um possvel problema para este diagrama seria: Ao redor de uma mesa esto sentadas 20 crianas, destas, 3 so meninas. Quantos meninos esto sentados ao redor da mesa?

Figura 6.8 Exemplo de variaes dos diagramas bsicos.

64

Ainda possvel a existncia de situaes problema que compem duas ou mais estruturas. Como pode ser visto na Figura 6.9, existe uma infinidade de combinaes entre as diversas estruturas, que podem gerar problemas mais complexos.

Problema: Carlos e seu irmo Andr colecionam selos. Carlos tinha 8 selos e Andr tinha 2 selos a mais que seu irmo. Seu pai chegou de viagem e deu 3 selos para Carlos e 5 selos Andr. Quantos selos Carlos e Andr tm ao todo?
Figura 6.9 Estrutura aditiva composta.

6.3.2. PROTTIPO DO COMPONENTE GRARD O Grard um software que tem o objetivo de favorecer a aprendizagem colaborativa no campo conceitual das estruturas aditivas, atravs da manipulao direta dos diagramas de Vergnaud, para resoluo conjunta de situaes-problemas. A interface do Grard (Figura 6.10) constituda de trs reas principais: uma lista de usurios ativos n, fornecida pela plataforma Plattus; um chat para a comunicao dos usurios o, tambm fornecido pela plataforma e uma rea de trabalho compartilhada p, utilizada para o desenho dos diagramas.

65

Figura 6.10 Interface do ambiente Grard.

A interface do prottipo Grard tambm apresenta uma barra de ferramentas q, que fornece atalhos para as opes contidas nos menus da aplicao. A barra de ferramentas do Grard composta dos seguintes botes:
Tabela 6.1 Botes da barra de ferramentas do Grard

Novo: Limpa a rea compartilhada e inicia um novo diagrama. Abrir: Abre um diagrama previamente salvo no sistema local de arquivo do usurio. Salvar: Salva o diagrama no sistema local de arquivo do usurio. Composio: Insere um diagrama bsico de composio. Valor: Insere no diagrama um valor absoluto.

66

Transformao: Insere um diagrama bsico de transformao. Comparao: Insere um diagrama bsico de comparao. Seleo: Seleciona um objeto no diagrama. Soluo: Resolve o diagrama. Desfazer: desfaz a ltima ao realizada no espao compartilhado. Refazer: refaz a ltima ao desfeita. Solicitar controle: Solicitar o direito de editar o diagrama. Abandonar controle: Abandonar o direito de editar o diagrama. Sair: Sair do Grard.

No Grard, somente um usurio detm o controle da aplicao em um determinado momento, ou seja, apenas aquele que tem o controle consegue criar/modificar a representao do problema. Enquanto isso, os demais usurios s conseguem assistir a interao e colaborar atravs do chat disponvel no ambiente. Qualquer usurio pode solicitar o controle da aplicao, mas este s ser passado quando o usurio que o detm abandon-lo voluntariamente. Se mais de um usurio requisitar o controle da aplicao, este ser passado na mesma ordem em que foi solicitado. possvel identificar quem detm ou requisitou o controle da aplicao atravs do sinal [r] localizado ao lado dos nomes dos usurios ativos. Uma caracterstica importante do Grard a verificao da consistncia do diagrama a cada modificao da estrutura. Essa permite desfazer/refazer qualquer modificao realizada. Inconsistncias so geradas quando valores representando termos ou o prprio resultado do problema esto incorretos. Para destac-las o sistema utiliza o recurso de cores para dar feedback ao usurio, por exemplo, qualquer erro inserido em um diagrama destacado em vermelho.

67

6.4.

CONSIDERAES FINAIS O desenvolvimento de prottipos foi til em dois aspectos. O primeiro

refere-se ao entendimento dos problemas relacionados ao desenvolvimento de sistemas colaborativos e a explorao dos aspectos crticos dos requisitos. Somente quando se tenta implementar um sistema deste tipo, por mais simples que seja, que nos deparamos com a complexidade envolvida em conceitos aparentemente muito simples como floor control e definio de papis. Um outro aspecto do uso de prottipo ter um produto concreto que pode ser utilizado para negociar com o usurio o entendimento do sistema e o levantamento de novos requisitos. Como poder ser visto no prximo captulo, o prottipo do componente Grard foi til para realizao de testes com usurios que geraram o cenrio apresentado na primeira iterao e ajudou a encontrar novos requisitos para a plataforma de groupware.

68

7. ANLISE DE CENRIOS
7.1. PRIMEIRA ITERAO A histria contada neste cenrio fictcia, mas foi baseada em trabalho de campo realizado no trabalho de mestrado de Vnia Alves [ALV2005], no qual a autora observou vrios usurios usando a ferramenta Grard. A primeira iterao reflete uma srie de situaes reais experimentadas por vrios usurios no uso da ferramenta Grard. O cenrio descreve o uso da ferramenta Grard por dois alunos hipotticos de pedagogia, Matheus e Leandra, que procuram o professor para tirar dvidas sobre a aula de estruturas aditivas. A tarefa proposta pelo professor prev a resoluo de vrias situaes problemas, mas somente a interao dos alunos para soluo do primeiro problema apresentada. 7.1.1. ATORES Os Alunos Leandra e Matheus e o professor. 7.1.2. CONTEXTO Dois alunos de pedagogia, Matheus e Leandra, procuram o professor no final da aula sobre estruturas aditivas e lhe apresentam algumas dificuldades na compreenso dos diagramas de Vergnaud [VER1997]. O Professor prope ento aos alunos uma sesso de utilizao de um prottipo de uma ferramenta colaborativa, chamada Grard, como atividade docente para tentar elucidar alguns conceitos atravs da manipulao direta dos diagramas no computador. Os alunos mostram-se inseguros para realizao da atividade, pois alegam nunca terem utilizado a referida ferramenta. O professor os acalma informando que prepararia todo o ambiente para a realizao da atividade e que realizaria uma sesso inicial para ensin-los a utilizar a ferramenta. 7.1.3. AMBIENTE (SETTING) Matheus e Leandra esto em um laboratrio que tem 12 computadores dispostos em uma grande bancada que atravessa a sala em quase toda sua extenso. Os computadores na bancada esto voltados em direes opostas 69

permitindo um melhor aproveitamento do espao do ambiente. Todos os computadores esto ligados a uma rede local, que permite tambm acesso Internet. No canto esquerdo de quem entra no laboratrio encontra-se uma impressora (Figura 7.1-A) que compartilhada por todos atravs da rede local. Na parede lateral direita de quem entra v-se um grande quadro branco (Figura 7.1-B), que utilizado pelos professores durante as aulas prticas no laboratrio. Matheus sentou-se ao computador no fundo do laboratrio (Figura 7.1-C), enquanto que Leandra preferiu o computador mais prximo porta de entrada (Figura 7.1-D), que fica do lado simetricamente oposto ao computador escolhido por Matheus. No outro computador ao fundo do laboratrio (Figura 7.1-E) foi instalado o Servidor que controla a colaborao entre os alunos.

Figura 7.1 Laboratrio de informtica.

O professor prepara todo o ambiente para realizao da tarefa, prepara e testa o sistema nos computadores, tambm instala e configura o servidor de grupo. O professor tambm transcreve no quadro a tarefa que deveria ser executada pelos alunos, juntamente com as regras que ambos deveriam seguir durante a realizao da atividade. Antes do incio da atividade, o professor apresenta aos alunos instrues de como utilizar o sistema. Durante a realizao

70

da atividade espera-se que os alunos alternem-se no controle da ferramenta para modelagem dos diagramas e que se comuniquem e negociem durante a realizao da tarefa atravs do chat da ferramenta. As regras definidas pelo professor para realizao da atividade, transcritas por ele no quadro, so: a) Vocs devem criar colaborativamente os diagramas que representam os problemas de adio e/ou subtrao propostos; b) Vocs devem ajudar-se mutuamente e interagir atravs do chat disponvel no sistema, a fim de modelar tais problemas; c) No ser permitido comunicar-se verbalmente e toda comunicao dever ser efetuada atravs da ferramenta; d) Vocs esto livres para negociar como deve se dar o processo de resoluo; e) Sempre que seu parceiro solicitar o controle da ferramenta e voc no concordar com isso, vocs devem negociar via chat e a atividade s poder ser retomada quando houver algum consenso; f) Para que uma tarefa seja considerada completa, vocs devem estar em comum acordo e devem deixar isso bem claro concordando mutuamente atravs do chat. Os problemas propostos pelo professor so os seguintes: 1) Joana tinha algumas revistas. Seu tio chegou de viagem e trouxe-lhe de presente 24 revistas para sua coleo. Joana tem agora 78 revistas. Quantas ela tinha antes? 2) Vera e Solange so feirantes. Vera vendeu 36 laranjas e vendeu 18 a mais que Solange. Quantas laranjas Solange vendeu? 7.1.4. ROTEIRO (PLOT) Antes do incio da atividade, o professor apresentou aos alunos instrues de como utilizar o sistema. Ambos acharam de fcil assimilao, pois j

71

estavam acostumados a usar outras ferramentas com funcionalidade equivalentes. Tanto Leandra como Matheus estavam ansiosos para utilizar a ferramenta.

(a)

(b)
Figura 7.2 Telas de escolha do grupo e login.

(c)

Matheus e Leandra iniciam a atividade executando a ferramenta atravs de um atalho na rea de trabalho. Inicialmente, eles escolhem o grupo ao qual conectar. Leandra escolhe o grupo cin, conforme sugerido pelo professor, Matheus no lembra muito bem da instruo do professor e tem dvidas sobre o nome do grupo, mas aps alguns segundos lembra que o nome do grupo acordado cin (Figura 7.2a). Imediatamente aps a escolha do grupo eles escolhem um apelido (login) com o qual sero referenciados no ambiente virtual. Leandra escolheu seu prprio nome como login (Figura 7.2b) e seguindo a mesma lgica, Matheus tambm preferiu seu nome original (Figura 7.2c). Aps efetuarem o login no ambiente eles puderam visualizar a tela principal da ferramenta. Leandra Matheus

Figura 7.3 Leandra entra no ambiente

72

Na Figura 7.3: Leandra a primeira a entrar no ambiente. Ela percebe isto, pois a nica que consta na lista de usuriosn. Ela leva algum tempo para lembrar que o indicador [x] na frente de seu nome representa que ela tem o controle da ferramentao. Ento, ela percebe que todos os botes da barra de ferramentas esto habilitados, com exceo de um, que serve para solicitar o controle da ferramentap. Leandra Matheus

Figura 7.4 Matheus entra no ambiente

Na Figura 7.4: Matheus entra logo em seguida, ele v atravs da lista de usurios que Leandra j se encontra no ambienten. Ele queria ter o controle da ferramenta e lamenta o fato de ter demorado em lembrar o nome do grupo, quando lembra que o professor explicou que o primeiro a entrar no ambiente recebe automaticamente controle. Ento ele percebe que quase todos os botes esto desabilitadoso, com exceo de um que serve para solicitar o controle da ferramentap.

73

Leandra

Matheus

Figura 7.5 Leandra desenha o diagrama no ambiente.

Na Figura 7.5: Leandra resolve convidar Matheus para ler o primeiro problema, lembra da regra (c) e convida o colega atravs do chatn. Ele concordao e aps alguns minutos, que cada um reservou para ler atentamente o problema, Matheus indaga Leandra sobre o que ela achou da questop. Leandra acha que melhor do que expressar-se atravs do chat seria desenhar o diagramaq. Matheus demora-se em responder, pois queria discutir pelo chat, mas concorda. Ento Leandra comea a desenharr. Matheus assiste sua colega desenhar o diagrama que representa a situaoproblema, no ambiente compartilhados. Enquanto ela desenha, ele distrai-se clicando nos menus e procurando conhecer mais sobre a ferramenta. Mas como ele nada pode fazer, volta a observar o que a colega est fazendo.

74

Leandra

Matheus

Figura 7.6 Leandra termina de desenhar o diagrama.

Na Figura 7.6: Leandra termina de desenhar o diagrama e Matheus ao v que a colega terminou de desenhar faz comentrios atravs do chat, tentando mostrar que tem domnio do assunton. Ele tambm infere a soluo do problema e apresenta para ela atravs do chato. Leandra pega o resultado oferecido pelo colega e completa o diagramap para demonstrar que concorda com a resposta dele. Matheus v a colega editar o diagrama para adicionar a resposta sugerida por eleq.

75

Leandra

Matheus

Figura 7.7 Leandra e Matheus concluem a primeira tarefa.

Na Figura 7.7: Para completar a tarefa Leandra deixa explcito no chat que concorda com o colega e o convida para passar para o prximo probleman. Matheus concorda com sua colega e expressa isso claramente atravs do chat, mas ressalta que pretende ter o controle da ferramenta para resolver o prximo problemao. Ento, ele solicita o controle atravs da ferramentap. Leandra Matheus

Figura 7.8 Leandra passa o controle para Matheus.

76

Na Figura 7.8: Leandra recebe a mensagem do seu colegan e s neste momento percebe na lista de usurio o indicador [r] na frente do nome de Matheuso, isso indica que o colega solicitou o controle da ferramenta. Matheus aguarda que Leandra lhe passe o controlep. Leandra ento concorda em passar o controle da ferramenta para ele e pressiona o botoq que realiza esta ao. Leandra Matheus

Figura 7.9 Matheus recebe o controle do ambiente.

Na Figura 7.9: Aps passar o controle, Leandra percebe que os botes da sua barra de ferramenta ficam quase todos desabilitadosn. Matheus recebe o controle e observa que os botes da sua barra de ferramentas ficaram habilitadoso e percebe na lista de usurios o indicador [x] na frente de seu nomep, que representa que ele tem o controle da ferramenta. Ele limpa a rea compartilhadaq para remover o diagrama do problema anterior e convida sua colega para ler o prximo problemar.

7.1.5. ROTEIRO POSITIVO Matheus e Leandra iniciam a atividade executando a ferramenta atravs de um atalho na rea de trabalho. Inicialmente eles escolhem o grupo ao qual conectar. Eles sabem que devem escolher o mesmo grupo e previamente tinham

77

acordado que se conectariam ao grupo cin. Imediatamente aps a escolha do grupo eles escolhem um apelido (login) com o qual sero referenciados no ambiente virtual. Leandra escolheu seu prprio nome como login e seguindo a mesma lgica, Matheus tambm preferiu seu nome original. Aps efetuarem o login no ambiente eles puderam visualizar a tela principal da ferramenta. Leandra a primeira a entrar no ambiente. E percebe isto, pois a nica que aparece na lista de usurios. Ela lembra da instruo do professor e reconhece que o indicador [x] na frente de seu nome representa que ela tem o controle da ferramenta. Ela tambm percebe que todos os botes da barra de ferramentas esto habilitados, com exceo de um, que serve para solicitar o controle da ferramenta. Matheus entra logo em seguida, e v atravs da lista de usurios que Leandra j se encontra no ambiente. Ele j esperava que Leandra tivesse o controle da ferramenta, pois lembra que o professor explicou que o primeiro a entrar no ambiente recebe automaticamente controle. Ele tambm no estranha o fato de quase todos os botes da ferramenta estarem desabilitados, porque sabe que somente quem tem o controle da ferramenta que pode manipular a rea de trabalho compartilhada. Leandra resolve convidar Matheus para ler o primeiro problema, mas lembra da regra (c) e convida o colega atravs do chat. Ele concorda e aps alguns minutos, que cada um reservou para ler atentamente o problema, Matheus indaga Leandra sobre o que ela achou da questo. Leandra acha que melhor do que se expressar atravs do chat seria desenhar o diagrama. Matheus concorda prontamente. Ento Leandra comea a desenhar. Matheus assiste sua colega desenhar o diagrama, que representa a situao-problema, no ambiente compartilhado. Enquanto ela desenha, ele concorda com o diagrama e vai acompanhando o desenrolar da tarefa concordando com cada passo realizado por sua colega. Leandra termina de desenhar o diagrama e Matheus ao v que a colega terminou de desenhar faz comentrios atravs do chat para que ela perceba que

78

ele est totalmente de acordo. Ele tambm infere a soluo do problema e apresenta para ela atravs do chat. Leandra pega o resultado oferecido pelo colega e completa o diagrama, para demonstrar que concorda com a resposta dele. Matheus percebe que Leandra concorda quando a v editar o diagrama para colocar a resposta sugerida por ele. Para completar a tarefa, Leandra deixa explcito no chat que concorda com o colega e o convida para passar para o prximo problema. Matheus concorda com sua colega e expressa isso claramente atravs do chat. Mas ressalta que pretende ter o controle da ferramenta para resolver o prximo problema. Ento, ele solicita o controle atravs da ferramenta. Quando Leandra recebe a mensagem do seu colega, ela j havia percebido na lista de usurio o indicador [r] na frente do nome de Matheus, que indica que o colega solicitou o controle da ferramenta. Leandra ento prontamente concorda em passar o controle da ferramenta para ele e pressiona o boto que realiza esta ao. Aps passar o controle Leandra percebe que os botes da sua barra de ferramenta ficam quase todos desabilitados. Matheus recebe o controle e observa que os botes da sua barra de ferramentas ficaram habilitados e percebe na lista de usurios o indicador [x] na frente de seu nome, o qual representa que ele tem o controle da ferramenta. Ele limpa a rea compartilhada para remover o diagrama do problema anterior e convida sua colega para ler o prximo problema. 7.1.6. ROTEIRO NEGATIVO Os requisitos aparecem mais facilmente no roteiro negativo, pois o que requer uma viso crtica sobre a interao dos usurios com o sistema. No decorrer do texto quando uma referncia do tipo [RQ01] aparecer, significa que um requisito foi levantado. Todos os requisitos levantados nesta seo sero apresentados em uma tabela na prxima seo. Matheus e Leandra iniciam a atividade executando a ferramenta atravs de um atalho na rea de trabalho. Inicialmente, eles escolhem o grupo ao qual conectar. Leandra escolhe o grupo cin, conforme sugerido pelo professor, mas 79

Matheus no lembra muito bem da instruo do professor e escolhe como nome do grupo ufpe [RQ14]. Ele gostaria de saber se Leandra j est neste grupo, para ter certeza de que est fazendo a escolha certa [RQ15]. Imediatamente aps a escolha do grupo, eles escolhem um apelido (login) com o qual sero referenciados no ambiente virtual. Leandra escolheu seu prprio nome como login e seguindo a mesma lgica, Matheus tambm preferiu seu nome original [RQ16]. Matheus questiona o professor sobre a necessidade de uso de senhas para evitar que outros usem seu login. O professor informa que a verso que eles esto usando apenas um prottipo e que o normal seria o aluno autenticar-se no ambiente com seu login e senha cadastrados previamente [RQ17]. Aps efetuarem o login no ambiente eles visualizam a tela principal da ferramenta. Leandra a primeira a entrar no ambiente. E percebe isto, pois a nica que figura na lista de usurios. Ela lembra da instruo do professor e reconhece que o indicador [x] na frente de seu nome representa que ela tem o controle da ferramenta. Leandra no acha o sinal [x] intuitivo, pois se o professor no tivesse explicado, ela no saberia seu significado. Leandra tambm acha que este sinal deveria ser grfico [RQ18]. Ela tambm percebe que todos os botes da barra de ferramentas esto habilitados, com exceo de um, que serve para solicitar o controle da ferramenta. Leandra ento fica aguardando que seu colega entre no ambiente. Matheus entra logo em seguida. Ele percebe que est sozinho no ambiente e por alguns minutos espera que Leandra entre no ambiente. Como nada acontece ele chama o professor. O professor ento percebe, ao olhar para a barra de ttulo da janela, que Matheus entrou no grupo errado e pede que ele saia da ferramenta e entre novamente. No entanto, agora ele deve entrar no grupo cin [RQ19]. Matheus questiona sobre a possibilidade de poder ver os grupos criados e poder escolher em qual grupo entrar ao invs de ter que lembrar o nome do grupo [RQ14]. Matheus segue as instrues do professor e entra corretamente no grupo indicado.

80

Ao entrar no grupo correto, Matheus v atravs da lista de usurios que Leandra j se encontra no ambiente. Ele j esperava que Leandra tivesse o controle da ferramenta, pois lembra que o professor explicou que o primeiro a entrar no ambiente recebe automaticamente o controle. Ele tambm no se espanta ao ver quase todos os botes da ferramenta desabilitados, porque sabe que somente quem tem o controle da ferramenta que pode manipular a rea de trabalho compartilhada. Mas acha que poderiam ter outras opes que ele pudesse usar para ajudar na tarefa [RQ20], ele tenta usar alguns botes, mas como esto desabilitados nada acontece [RQ21]. Leandra resolve convidar Matheus para ler o primeiro problema, mas lembra da regra (c) e convida o colega atravs do chat. Ela acha que isso no seria necessrio se o problema estivesse na tela da ferramenta [RQ22] e no no quadro como o professor colocou. Matheus aceita o convite e aps alguns minutos, que cada um reservou para ler atentamente o problema, Matheus indaga Leandra sobre o que ela achou da questo. Leandra tem dificuldades de separar suas mensagens das mensagens de seu colega, pois todas tm a mesma formatao, sendo diferenciada somente pelo nome do autor no incio da frase. Acostumada com o uso de ferramentas de chat, Leandra gostaria de poder personalizar a formatao de suas mensagens para facilitar a leitura [RQ23]. Leandra acha que melhor do que se expressar atravs do chat seria desenhar o diagrama. Matheus concorda prontamente. Ento Leandra comea a desenhar. Matheus assiste sua colega desenhar o diagrama, que representa a situao-problema, no ambiente compartilhado. Ele no concorda com o diagrama que ela est construindo e tenta se comunicar com ela. Mas como Leandra est concentrada montando o diagrama, ela no percebe o que ele escreve no chat [RQ23]. Matheus tenta insistentemente chamar a ateno dela pela ferramenta, mas no encontra nenhuma outra opo a no ser o chat [RQ20]. Como ltima alternativa, Matheus resolve pedir o controle da ferramenta. Ele clica no boto para solicitar o controle e percebe na lista de usurio que aparece o indicador [r]

81

na frente do seu nome. Matheus no acha o sinal [r] intuitivo, pois se o professor no tivesse explicado, ele no saberia seu significado. Ele acha que este sinal poderia ser grfico [RQ18]. Infelizmente Leandra tambm no percebe que o colega pediu o controle [RQ24], pois est concentrada na resoluo da tarefa. No tendo alternativa, Matheus levanta-se e fala em voz alta: Leandra, eu estou falando com voc no chat. Nesse momento ele percebe que quebrou uma das regras estipuladas pelo professor e imediatamente busca-o com seu olhar. E informa ao professor que no teve alternativa, pois Leandra no respondia ao chat. Leandra informa que no estava vendo as mensagens do colega e que deveria ter alguma forma de chamar sua ateno pela ferramenta [RQ25]. Ao ver as mensagens do colega, Leandra rel o problema e reflete sobre o que estava fazendo. Ela percebe que no estava desenhando o diagrama correto. Pede desculpas ao colega por no ter visto isto antes. Informa que vai corrigir seu erro, mas que no vai lhe passar o controle, pois sabe qual o diagrama correto. Matheus concorda com Leandra e no tem mais interesse pelo controle, mas no sabe como cancelar sua requisio anterior, pergunta ao professor e ele informa que no h como fazer isso na ferramenta [RQ26]. Leandra limpa a rea compartilhada e comea a desenhar o novo diagrama. Enquanto ela desenha, Matheus concorda com o diagrama e vai acompanhando o desenrolar da tarefa concordando com cada passo realizado por sua colega. Leandra termina de desenhar o diagrama e Matheus ao ver que a colega terminou de desenhar faz comentrios atravs do chat para que ela perceba que ele est totalmente de acordo. Ele tambm infere a soluo do problema e apresenta para ela atravs do chat. Leandra pega o resultado oferecido pelo colega e completa o diagrama, para demonstrar que concorda com a resposta dele. Matheus percebe que Leandra concorda quando a v editar o diagrama para colocar a resposta sugerida por ele.

82

Para completar a tarefa, Leandra deixa explcito no chat que concorda com o colega e o convida para passar para o prximo problema. Ela acha que deveria ter alguma forma de encerrar o problema na ferramenta [RQ27]. Matheus concorda com sua colega e expressa isso claramente atravs do chat, mas ressalta que pretende ter o controle da ferramenta para resolver o prximo problema. Leandra recebe a mensagem do seu colega e s neste momento percebe na lista de usurio o indicador [r] na frente do nome de Matheus. Isso indica que o colega solicitou o controle da ferramenta. Matheus aguarda que Leandra lhe passe o controle. Leandra ento concorda em passar o controle da ferramenta para ele e pressiona o boto que realiza esta ao. Aps passar o controle, Leandra percebe que os botes da sua barra de ferramenta ficam quase todos desabilitados. Matheus recebe o controle e observa que os botes da sua barra de ferramentas ficaram habilitados e percebe na lista de usurios o indicador [x] na frente de seu nome, que representa que ele tem o controle da ferramenta. Ele limpa a rea compartilhada para remover o diagrama do problema anterior e convida sua colega para ler o prximo problema. 7.1.7. REQUISITOS LEVANTADOS A partir dos cenrios descritos na seo anterior, foi possvel derivar os seguintes requisitos adicionais que deveriam estar presentes no sistema (tambm indicados no roteiro negativo atravs de indicadores, como por exemplo, [RQ14]), os requisitos sero apresentados em dois nveis, conforme influenciam as funcionalidades da ferramenta Grard ou da plataforma Plattus:
Tabela 7.1 Requisitos levantados na anlise de cenrios (primeira iterao)

Requisito Grard [RQ14]

Plattus

A ferramenta deve fornecer ao A plataforma de groupware deve usurio uma lista que apresente fornecer para as ferramentas a em quais grupos o usurio pode lista de grupos disponveis para conectar-se. conexo, juntamente com a lista

83

[RQ15]

A ferramenta deve permitir que o de usurios conectados ao grupo. usurio de Adicionalmente, a plataforma pessoas que esto conectadas ao pode prover um elemento de grupo que ele escolheu. interface (widgets) que fornea um dilogo de entrada para os usurios apresente nos ambientes, quais que o visualize a lista

grupos

usurio pode conectar-se e a lista de usurios conectados a cada grupo. [RQ16] A plataforma de groupware no deve permitir que dois usurios conectem com o mesmo login. [RQ17] A plataforma de groupware deve prover um mecanismo para autenticar de a

segurana

conexo do usurio. [RQ18] A interface da ferramenta deve A plataforma de groupware deve prover uma forma mais intuitiva apresentar no elemento de

de exibir quem est com o interface (widgets) a lista de controle da ferramenta. usurios de forma intuitiva, de preferncia com elementos

grficos, chamando a ateno do usurio para eventos como a entrada e sada de usurios e o pedido de controle da ferramenta. [RQ19] A Ferramenta deve permitir que o A plataforma de groupware deve usurio troque de grupo. permitir ao usurio trocar de grupo.

84

[RQ20]

Um usurio que no tem o controle da aplicao deve ter formas de do participar desenrolar mais da

ativamente

tarefa, por exemplo, fornecendo feedbacks aos colegas. [RQ21] Quando o usurio tentar utilizar botes desabilitados, a

ferramenta deve inform-lo que as funcionalidades no esto

acessveis porque ele no est com o controle da ferramenta. [RQ22] A interface da ferramenta deve A plataforma de groupware deve possuir uma rea para exibir o permitir a definio antecipada de enunciado dos problemas. grupos associados a uma dada ferramenta, com os respectivos dados da sesso, problemas e usurios. E enviar estes dados s ferramentas no momento que o usurio conectar-se ao grupo. [RQ23] A interface do chat deve ser mais A plataforma de groupware deve amigvel e usvel, dando mais apresentar opes de formatao e sons aos interface usurios, permitindo interajam melhor, que eles elementos no elemento de s de chat ferra-

(widgets) comuns

percebendo mentas de chats e mensagens

facilmente quando o outro est instantneas atuais. tentando se comunicar, obtendo com facilidade a ateno do outro e sabendo quem disse o que na conversa que est na tela.

85

[RQ24]

A ferramenta deve fazer o usurio A plataforma de groupware deve perceber rapidamente quando o gerar eventos especficos para seu(s) parceiro(s) pede(m) o alertar as ferramentas de que um usurio pediu o controle da

controle da ferramenta

ferramenta. A plataforma de groupware deve apresentar no elemento de

interface (widgets) a lista de usurios de forma intuitiva, de preferncia com elementos

grficos, chamando a ateno do usurio para eventos como a entrada e sada de usurios e o pedido de controle da ferramenta. [RQ25] A ferramenta deve fornecer uma A plataforma de groupware deve alternativa para que um usurio gerar eventos especficos para possa chamar a ateno de outro. alertar as ferramentas de que um usurio est tentando chamar ateno de outro. [RQ26] A interface da ferramenta deve A plataforma de groupware deve fornecer um boto para cancelar permitir uma solicitao prvia de controle o cancelamento de controle de pelos

solicitaes usurios

[RQ27]

Deve haver na ferramenta uma A plataforma de groupware deve forma explicita de informar a fornecer concluso da resoluo de um informar problema, passando para o resoluo passando seguinte. forma a de para explicita concluso um o de da

problema, problema

problema seguinte.

86

7.2. SEGUNDA ITERAO Nesta segunda iterao, buscamos refinar ainda mais os requisitos levantados na primeira iterao. Para isso, montamos um cenrio similar ao cenrio da primeira iterao, mas utilizando um sistema hipottico que implementa todos os requisitos levantados anteriormente. Com isso o cenrio estar funcionando como um prottipo de baixo custo que Carroll [CAR2000] chama de prottipos leves (soft prototype), o qual favorece a descoberta de novos requisitos e o refinamento dos requisitos j identificados. Neste cenrio, primeiramente apresentaremos uma nova e hipottica verso do sistema Grard, que no foi implementada. Neste caso o cenrio o prottipo que atende aos requisitos levantados na iterao anterior. Para atender aos requisitos em nvel do componente, significa que os requisitos associados na plataforma de groupware tambm foram atendidos. Como esse cenrio dedica uma seo para apresentar as

caractersticas do novo sistema hipottico, no vimos necessidade de apresentar um roteiro normal de uso do sistema. Neste caso, apresentaremos apenas os roteiros positivos e negativos. A seguir, apresentaremos textualmente as novas caractersticas do Grard. No decorrer do texto quando uma referncia do tipo [RQ01] aparecer, significa que um requisito levantado na iterao anterior foi atendido pelo prottipo. 7.2.1. PROTTIPO Juntamente com a nova verso do Grard, foi criada uma ferramenta para edio de problemas. Na ferramenta um professor pode criar novos problemas, ou editar problemas existentes, definindo o enunciado e desenhando o diagrama resposta para o problema. Os problemas criados so armazenados no formato XML, no prprio servidor da plataforma Plattus, no repositrio de problemas. Os problemas do repositrio podem ser utilizados por qualquer professor para definir atividades para serem resolvidas por seus alunos atravs do Grard.

87

A plataforma de groupware Plattus foi integrada a um Sistema de Gerenciamento de Cursos (LMS - Learning Management System), para autenticao dos usurios e para definio de atividades curriculares: o mdulo de autenticao de usurios acessa ao banco de dados de usurios do LMS. Somente usurios cadastrados no LMS podem utilizar o componente Grard e outros componentes da plataforma [RQ16] [RQ17]. Atravs da interface do LMS, o professor pode agendar atividades para serem realizadas por seus alunos [RQ22]. Para isso, o professor escolhe o componente, neste caso o Grard, mas futuramente outros componentes estaro disponveis para os professores. O professor define uma atividade informando a data e o horrio agendado para atividade, o tempo de durao, seleciona os alunos que participaro da tarefa, seleciona os problemas a partir do repositrio de problemas e pode definir se o floor control ser Request-and-Wait como na verso anterior do Grard ou se ser predefinido. No floor control predefinido, o professor pode definir qual participante ter o controle da ferramenta no incio e associar os participantes a cada um dos problemas escolhidos. Assim quando o problema estiver sendo resolvido pelos alunos, ter o controle da aplicao o aluno que o professor definiu na preparao da atividade. Ao executar o Grard, ser apresentada ao aluno uma caixa de dilogo chamada Rol de entrada, onde o aluno v a lista de todas as salas1 ativas [RQ14]. Ao selecionar uma sala o aluno visualiza quem j est naquela sala [RQ15]. O aluno pode entrar em uma sala j existente ou criar uma nova sala. Ao criar uma nova sala o aluno entra automaticamente nela. As salas criadas por alunos so chamadas salas temporrias, enquanto que as salas definidas pelo professor na preparao de atividades so chamadas salas persistentes. Nas salas criadas pelos alunos, os problemas so buscados do repositrio aleatoriamente e o floor control ser Request-and-Wait como na verso anterior do Grard. A cada problema resolvido o prximo problema
1

O conceito de Salas substitui o conceito de grupos da verso anterior do Grard. (ver pgina 55)

88

aleatoriamente selecionado at que todos saiam da sala, quando a sala removida do servidor. Somente podem entrar em uma sala persistente os alunos definidos pelo professor para participar da atividade. Quando um aluno est no Rol de entrada ele pode ver as atividades pr-definidas para ele e se a atividade estiver em andamento ele ser alertado para entrar na sala referente atividade. Com a possibilidade de criao de salas temporrias pelos alunos, pode ser que em um dado momento existam muitas salas ativas, neste caso o Rol de entrada dispe de uma ferramenta de pesquisa que permite ao aluno procurar por um colega e descobrir em que sala ele se encontra. Quando o aluno estiver em uma sala e quiser trocar de sala, ele pode facilmente retornar ao Rol de entrada e mudar de sala [RQ19]. Se o aluno estiver em uma sala temporria no momento agendado pelo professor para uma atividade ele ser alertado sob o fato de existir uma atividade aguardando por ele e com um simples clique ele poder sair da sala atual e entrar automaticamente na sala reservada pelo professor para atividade [RQ19]. A nova interface do Grard constituda de quatro reas principais: uma lista de usurios ativos, fornecida pela plataforma Plattus; um chat para a comunicao dos usurios, tambm fornecido pela plataforma; uma rea de trabalho compartilhada, utilizada para o desenho dos diagramas e uma rea para apresentao do enunciado do problema ativo. A lista de usurios apresenta cones grficos para fornecer aos alunos na sala o status dos usurios. Um cone de um cadeado apresentado junto ao nome do usurio que tem o controle da ferramenta [RQ18] e o cone de uma chave apresentado ao lado do nome dos usurios que requisitaram o controle da ferramenta. Dentro do cone da chave um nmero indica a posio do usurio na fila de solicitao. Sempre que um aluno solicita o controle da ferramenta um som emitido e aparece imediatamente a chave ao lado de seu nome, que fica girando por alguns segundos, ento ela estabiliza e passa a apresentar a posio do aluno na fila [RQ24].

89

Para as salas persistentes, os nomes dos alunos definidos pelo professor para a atividade e que ainda no entraram na sala so apresentados na cor cinza. Sempre que um aluno entra ou sai da sala, emitido um som que indica a entrada ou sada de alunos. Quando o aluno entra, alm do som seu nome fica em destaque por alguns segundos permitindo aos outros perceberem quem entrou. E quando um usurio sai seu nome vai desaparecendo levemente para tambm para ajudar na percepo. Ao lado do nome de cada aluno na lista de usurios, existe tambm um cone de um sino, que pode ser utilizado para chamar a ateno do aluno. Quando se clica no sino, a tela do aluno vibra juntamente com a emisso de um som de sinos tocando, que buscam chamar sua ateno. Na lista de usurios o sino do aluno que lhe chamou a ateno pisca por alguns segundos para que o aluno perceba quem est lhe chamando a ateno [RQ25]. O chat para conversao entre os alunos agora dispe de recursos de formatao (fontes, tamanho de letra, negrito, itlico, cor, etc...). Agora, sempre no envio de uma nova mensagem um som emitido para que o usurio perceba a chegada da mensagem [RQ23]. A tela principal do Grard tem agora uma nova regio dedicada apresentao do problema que est sendo resolvido [RQ22]. Ao lado da descrio do problema existe um boto para finalizao do problema [RQ27]. Somente o aluno que tem o controle pode indicar a concluso do problema, clicando no boto, mas aps isso todos os outros alunos sero interrogados se concordam com a concluso do problema e sendo a resposta positiva o problema concludo e o prximo problema ser apresentado. Na barra de ferramentas do Grard existem novos botes. Um novo boto foi adicionado para permitir aos alunos cancelarem um pedido de controle [RQ26]. Quando pressionado o usurio abdica de uma solicitao de controle, um som emitido e a chave que se encontra em frente ao seu nome gira por alguns segundos at desaparecer levemente.

90

Um novo boto com um cone de balo de fala permite que um aluno possa fazer comentrios (feedback) diretamente na rea de trabalho

compartilhada [RQ20]. Qualquer usurio pode selecionar um objeto na rea compartilhada e apresentar comentrios. O comentrio ser visualizado na prpria rea compartilhada dentro de um balo explicativo e l permanecer por alguns segundos, podendo ser fechado pelo usurio antes do final do tempo. Ao invs de apresentar mensagens aos usurios que tentem usar botes desabilitados, nesta nova verso o Grard apresenta apenas os botes que o usurio pode usar ocultando os botes que no podem ser utilizados [RQ21]. 7.2.2. ATORES Os Alunos Leandra e Matheus e o professor. 7.2.3. CONTEXTO O professor pretende testar o novo sistema e convida os alunos Leandra e Matheus para uma nova sesso de utilizao do sistema. O professor agenda a atividade para a prxima quarta-feira s 16h, mas Leandra informa que no pode ir universidade neste dia, pois estar na casa de seus pais que moram em outra cidade. Como na casa da Leandra tem um computador com acesso Internet, eles acordam que Leandra acessar o sistema a partir dele. O professor entrega a Leandra um CD de instalao para que ela instale o Grard no computador. 7.2.4. AMBIENTE (SETTING) O professor prepara com dois dias de antecedncia a atividade a ser realizada pelos alunos, atravs do LMS. Para isso, ele escolhe o componente, neste caso o Grard. Ele define a data, o horrio de incio da atividade, e o tempo para realizao da atividade que foi de meia hora. Em seguida, o professor adiciona atividade seu prprio usurio e os dois alunos, Leandra e Matheus, e seleciona dois problemas que devero ser resolvidos pelos alunos. Finalmente, o

91

professor define o floor control como predefinido e associa o primeiro problema Leandra e o segundo problema para Matheus. Os problemas escolhidos pelo professor foram: 1) Mariana e Tlio encontraram conchinhas na praia. Mariana achou 21 e Tlio achou 16. Quantas conchinhas Mariana achou a mais que Tlio? 2) Joo tinha 63 bolas de gude. Jogando com seus colegas perdeu 31 bolas. Quantas Joo tem agora? Matheus e o professor esto no laboratrio, que tem 12 computadores dispostos em uma grande bancada que atravessa a sala em quase toda sua extenso. Os computadores na bancada esto voltados em direes opostas permitindo um melhor aproveitamento do espao do ambiente. Todos os computadores esto ligados a uma rede local, que permite tambm acesso Internet. Leandra est em sua casa, usando seu computador pessoal conectado Internet. O Grard j foi devidamente instalado por ela, atravs do CD de instalao fornecido pelo professor. 7.2.5. ROTEIRO POSITIVO Ao executar o Grard, Matheus v a tela do Rol de entrada e aps autenticar-se com o mesmo login e senha que utiliza no LMS, v a lista de todas as salas ativas. Como ainda muito cedo, Matheus entra em uma das salas criada por outro aluno e aproveita para praticar um pouco. Prximo ao horrio da atividade, Matheus recebe uma mensagem informando que esperado para uma atividade curricular, mostrando o tempo que falta para o incio da atividade e perguntando se ele deseja entrar nesta sala. Matheus gosta da funcionalidade e responde que sim. Automaticamente ele entra na referida sala. Ao entrar na sala ele percebe, na lista de usurios, que os nomes do seu professor e Leandra esto na cor cinza, informando que eles tambm so 92

esperados na sala, mas ainda no chegaram. Ele tambm percebe que mesmo sem Leandra est on-line, ao lado de seu nome existe um cadeado, tambm cinza, indicando que a mesma tem o controle da ferramenta. O problema ainda no aparece na rea de problemas, porque ainda no o horrio marcado para o incio da atividade. Matheus percebe tambm que na sua tela h poucos botes e que todos esto habilitados. O professor acompanhou as aes de Matheus para entrar no ambiente e em seguida liga outro computador e tambm executa o Grard. O professor tambm convidado a entrar na sala e prontamente aceita. O professor e Matheus conversam um pouco atravs do chat. No demora muito e Leandra tambm entra na sala. Matheus e o professor percebem que ela entrou, pois quando Leandra entra, alm do som, seu nome fica em destaque por alguns segundos permitindo aos outros perceberem que ela entrou. Tambm, tanto seu nome como o cone do cadeado deixam a cor cinza e passam a ser apresentados normalmente. O momento marcado para o incio da atividade chega e o problema apresentado para todos na regio dedicada para isso. O professor convida todos para lerem o problema e diz que est ali para acompanhar o desenrolar da tarefa e que pouco intervir na atividade. Informa tambm que as regras continuam as mesmas da interao anterior. Leandra l o problema e pergunta para Matheus pelo chat se ele j leu o problema. Matheus diz que sim e pergunta se ela concorda que o problema de comparao. Ela concorda e informa que vai desenhar o diagrama. Matheus percebe que a colega no est desenhando o diagrama corretamente e resolve utilizar o novo recurso de feedback. Matheus clica no boto de feedback e no diagrama que Leandra est desenhando. Imediatamente abre uma janela onde ele escreve seu comentrio. Quando Matheus confirma seu comentrio, em todos os computadores que participam da atividade, aparece um balo explicativo com a mensagem de

93

Matheus apontando para o diagrama. Como o olhar de Leandra est voltado para esta regio, ela v a mensagem, fecha o balo e corrige o diagrama. Matheus, ao v que a colega terminou de desenhar, faz comentrios atravs do chat. Ele tambm infere a soluo do problema e apresenta para ela atravs do chat. Leandra pega o resultado oferecido pelo colega e completa o diagrama, para demonstrar que concorda com a resposta dele. Matheus v a colega editar o diagrama para adicionar a resposta sugerida por ele. Para completar a tarefa, Leandra clica no boto ao lado da descrio do problema, que serve para finalizar a resoluo do problema. Neste momento Matheus e o professor recebem um mensagem informando que Leandra considera o problema resolvido e pedindo a confirmao da concluso do problema. Ambos concordam com o diagrama desenhado por Leandra e confirmam a concluso da soluo. Neste momento, a descrio do novo problema apresentada na tela, automaticamente a rea de trabalho compartilhada limpa e o controle da ferramenta passa para Matheus. Leandra recebe uma mensagem informando que o controle foi passado para Matheus obedecendo s regras definidas na preparao da atividade. Leandra percebe que Matheus est com o controle, pois v o cadeado ao lado de seu nome. 7.2.6. ROTEIRO NEGATIVO Os requisitos aparecem mais facilmente no roteiro negativo, pois o que requer uma viso crtica sobre a interao dos usurios com o sistema. No decorrer do texto, quando uma referncia do tipo [RQ01] aparecer, significa que um requisito foi levantado. Todos os requisitos levantados nesta seo sero apresentados em uma tabela na prxima seo. Ao executar o Grard, Matheus v a tela do Rol de entrada e aps autenticar-se com o mesmo login e senha que utiliza no LMS, v a lista de todas as salas ativas. Como ainda muito cedo, Matheus entra em uma das salas criada por outro aluno e aproveita para praticar um pouco.

94

Prximo ao horrio da atividade Matheus recebe uma mensagem informando que esperado para uma atividade curricular, mostrando o tempo que falta para o incio da atividade e perguntando se ele deseja entrar nesta sala. Matheus gosta da funcionalidade e responde que sim. Automaticamente ele entra na referida sala. Ao entrar na sala ele percebe, na lista de usurios, que os nomes do seu professor e Leandra esto na cor cinza, informando que eles tambm so esperados na sala, mas ainda no chegaram. Ele tambm percebe que mesmo sem Leandra est on-line, ao lado de seu nome existe um cadeado, tambm cinza, indicando que a mesma tem o controle da ferramenta. O problema ainda no aparece na rea de problemas, porque ainda no o horrio marcado para o incio da atividade. Matheus percebe tambm que na sua tela h poucos botes e que todos esto habilitados. Mas ele nada pode fazer, porque a atividade ainda no comeou. O professor acompanhou as aes de Matheus para entrar no ambiente e em seguida liga outro computador e tambm executa o Grard. O professor tambm convidado a entrar na sala e prontamente aceita. O professor e Matheus conversam um pouco atravs do chat. Ao conversar no chat o professor verificou que o tipo de fonte e as cores que ele havia configurado em uma sesso anterior no haviam sido gravadas e no gostou de ver que tudo voltou formatao padro. Ele gostaria que as definies feitas por ele na ferramenta pudessem permanecer mesmo entre sesses diferentes e at entre computadores diferentes, pois cada vez que utiliza o sistema, o faz em computadores diversos [RQ28]. Ento ele configura novamente a fonte e cores de sua preferncia. At a hora marcada para o incio da atividade Leandra no chega sala. Ento a plataforma automaticamente passa o controle do sistema para Matheus. Seguindo a lgica que o aluno que deveria ter o controle da ferramenta pode no vir e o andamento da tarefa poderia ser prejudicado se o sistema continuasse bloqueado aguardando este aluno.

95

Matheus est lendo o problema, quando Leandra chega. Matheus e o professor percebem que ela entrou, pois quando Leandra entra alm do som seu nome fica em destaque por alguns segundos permitindo aos outros perceberem que ela entrou. Tambm, seu nome deixa a cor cinza e passa a ser apresentado normalmente. Mas ela no recebe o controle da ferramenta. O professor gostaria de ter o direito de tirar o controle de Matheus e entregar para Leandra, mas no existe distino entre os usurios e nenhum usurio tem esse direito [RQ29]. Ento ele pede a Leandra que solicite o controle da ferramenta e a Matheus que passe o controle colega. Quando Leandra solicita o controle da ferramenta, um som emitido e no computador de todos os participantes. Aparece imediatamente a chave ao lado de seu nome, que fica girando por alguns segundo, ento ela estabiliza e passa a apresentar em seu interior o nmero 1 (um), que indica que a mesma a primeira a receber o controle quando ele for liberado. Matheus passa o controle para Leandra. Ento o professor convida todos para lerem o problema e diz que est ali para acompanhar o desenrolar da tarefa e que pouco intervir na atividade. O professor reflete que no poder participar de todas as atividades que programar. Ele gostaria de ter a possibilidade de ver o desenrolar da atividade em outro momento [RQ30]. O Professor Informa que as regras continuam as mesmas da interao anterior. Mateus pergunta ao professor porque as regras no esto no ambiente, assim poderiam ser consultadas quando necessrio [RQ31]. O professor informa que uma delas j faz parte do ambiente, que a concordncia da concluso do problema. Leandra l o problema e pergunta para Matheus pelo chat se ele j leu o problema. Matheus diz que sim e pergunta se ela concorda que o problema de comparao. Ela concorda e informa que vai desenha o diagrama. Matheus percebe que a colega no est desenhando o diagrama corretamente e resolve utilizar o novo recurso de feedback.

96

Matheus clica no boto de feedback, clica no diagrama que Leandra est desenhando. Imediatamente abre uma janela onde ele escreve seu comentrio. Quando Matheus confirma seu comentrio, em todos os

computadores que participam da atividade, aparece um balo explicativo com a mensagem de Matheus apontando para o diagrama. Infelizmente, neste momento a me de Leandra a chama e leandra deixa o quarto, no vendo o feedback do colega [RQ32]. Matheus acha estranho, pois no v nenhuma reao de sua colega ao seu comentrio. Ele acha que ela est refletindo sobre o que ele escreveu. O tempo definido para o balo escoa e ele desaparece lentamente. E Matheus acha estranho que sua colega no atende aos seus apelos. Matheus pergunta ao professor se existe a possibilidade de enviar feedback sonoro, pois seu comentrio foi bastante longo e talvez fosse melhor entendido se fosse falado ao invs de escrito [RQ33]. Pergunta tambm sobre a possibilidade do uso de voz e vdeo na comunicao [RQ34], alm do chat. O professor informa que no existe essa possibilidade, mas que so idias interessantes. O professor gostaria de enviar uma mensagem de chat para Leandra fazendo algumas colocaes, mas no gostaria que Matheus visse [RQ35]. Ele sabe que qualquer mensagem enviada no chat vista por todos. Ento ele resolve aguardar mais um pouco, se nada acontecer ele vai ter que fazer o comentrio publicamente. Leandra chega, mas como o feedback j desapareceu, ela no sabe nada sobre os comentrios de seu colega [RQ36]. Matheus resolve chamar sua ateno e clica no cone do sino ao lado de seu nome na lista de usurios. A tela de Leandra vibra juntamente com a emisso do som de sinos tocando, que buscam chamar sua ateno. Na lista de usurios o sino ao lado no nome de Matheus pisca por alguns e Leandra v que Matheus quer falar com ela. Ela pergunta, pelo chat, o que ele quer. Ele pergunta por que ela ignorou seus comentrios. Leandra informa que no estava na frente do

97

computador e no viu nenhum comentrio. Matheus refaz seu comentrio. Quando Matheus confirma seu comentrio, em todos os computadores que participam da atividade, aparece um balo explicativo com a mensagem de Matheus apontando para o diagrama. Como o olhar de Leandra est voltado para esta regio, ela v a mensagem, fecha o balo e corrige o diagrama. Leandra termina de desenhar o diagrama e Matheus ao v que a colega terminou de desenhar faz comentrios atravs do chat. Ele tambm infere a soluo do problema e apresenta para ela atravs do chat. Leandra pega o resultado oferecido pelo colega e completa o diagrama, para demonstrar que concorda com a resposta dele. Matheus v a colega editar o diagrama para adicionar a resposta sugerida por ele. Para completar a tarefa Leandra clica no boto ao lado da descrio do problema, que serve para finalizar a resoluo do problema. Neste momento Matheus e o professor recebem uma mensagem informando que Leandra considera o problema resolvido e pedindo a confirmao da concluso do problema. Ambos concordam com o diagrama desenhado por Leandra e confirmam a concluso da soluo. Neste momento, a descrio do novo problema apresentada na tela, automaticamente a rea de trabalho compartilhada limpa e o controle da ferramenta passa para Matheus. Leandra recebe uma mensagem informando que o controle foi passado para Matheus obedecendo s regras definidas na preparao da atividade. Leandra percebe que Matheus est com o controle, pois v o cadeado ao lado de seu nome. 7.2.7. REQUISITOS LEVANTADOS A partir dos cenrios descritos na seo anterior, foi possvel derivar os seguintes requisitos adicionais que deveriam estar presentes no sistema (tambm indicados no roteiro negativo atravs de indicadores, como por exemplo, [RQ28]). Quando um novo indicador aparecer na descrio do requisito (por exemplo, o indicador [RQ37] apresentado no texto explicativo do requisito [RQ28]), significa

98

que um novo requisito surgiu derivado do requisito que est sendo apresentado e que o mesmo ser apresentado mais abaixo na tabela. Como na seo anterior, os requisitos sero apresentados em dois nveis, conforme influenciam as funcionalidades da ferramenta Grard ou da plataforma Plattus:
Tabela 7.2 Requisitos levantados com a anlise de cenrios (segunda iterao)

Requisito Grard [RQ28]

Plattus

A ferramenta deve armazenar as A plataforma de groupware deve preferncias de configuraes prover um repositrio persistente

dos usurios, no somente do centralizado de perfis de usurios. chat, mas quaisquer servios O perfil ser composto de

configurveis usurio. devem

oferecidas

ao pginas. Cada pgina armazena

Estas persistir

preferncias os dados de preferncias do mesmo entre usurio em uma determinada

sesses diferentes e at entre ferramenta. Cada ferramenta s computadores diferentes. poder ler e gravar informaes da pgina reservada para ela [RQ37]. [RQ29] Diferentes devem ter tipos de usurios A plataforma de groupware deve diferen- permitir a definio de papis

privilgios

ciados nas aes que podem para os usurios que participam realizar na ferramenta. de uma atividade compartilhada.1

Principalmente o professor ou um Ao definir uma atividade o tutor que podem ser responsveis professor pode definir os papis pela coordenao das atividades. que sero assumidos pelos usurios na execuo da mesma. Exemplos de papis so: Aluno,

Este requisito foi levantado na anlise de competidores, mas no foi implementado no prottipo. Veja o requisito [RQ10] levantado na anlise de competidores na pgina 51.

99

professor, nador, etc.

moderador,

coorde-

O papel assumido pelo usurio ser enviado ferramenta no momento de conexo do usurio, cabendo a ferramenta decidir

quais as aes e privilgios esto associados a cada papel. [RQ30] Todos os passos de atividade realizada em uma sala persistente devem servidor ser armazenados para no

posterior

visualizao [RQ38]. [RQ31] Todas as informaes importan- Na definio de uma atividade a tes para execuo das tarefas plataforma de groupware deve devem est disponveis na interface ou permitir o armazenamento, alm da do XML que define a atividade, de tipos de arquivos da

incorporadas

ferramenta. Este o caso das diversos regras que devem ser seguidas associados para realizao da atividade. As informaes podem atividade.

execuo

ser Esses arquivos sero enviados

providas em diversos formatos para ferramenta juntamente com como texto, vdeos, animaes, o XML da atividade. Cabe a etc. ferramenta conhecer os formatos dos arquivos e a forma de

apresentao dos mesmos aos usurios.

100

[RQ32]

A ferramenta deve prover aos A plataforma de groupware deve usurios uma forma de definir prover vrios e status de

status de disponibilidade, como disponibilidade

privacidade.

por exemplo, online ou ausente. Permitindo aos usurios informar Que permita aos outros usurios aos outros sua disposio ou identificar sua disponibilidade possibilidade para colaborar em um dado momento.

durante a realizao da tarefa. [RQ33]

A ferramenta pode prover aos A plataforma de groupware deve usurios fornecer a possibilidade de prover tambm comunicao no

feedbacks

sonoros. textual como som e vdeo.

Neste caso, ao invs de bales explicativos, um cone de um auto-falante ao lado do objeto no ambiente compartilhado pode

representar o feedback. Neste caso bastar ao usurio clicar no cone para ouvir o comentrio. [RQ34] A ferramenta deve prover aos usurios a possibilidade do uso de voz e vdeo na comunicao. [RQ35] A ferramenta deve prover aos A plataforma de groupware deve usurios a possibilidade de de prover aos usurios a

comunicarem-se privativa.

forma possibilidade de comunicarem-se de forma privativa.

[RQ36]

A ferramenta deve manter as mensagens de feedback na tela at que o usurio indique que recebeu (leu ou ouviu).

101

[RQ37]

Para garantir a implementao do S

podero de

conectar-se groupware

os

requisito [RQ28], toda ferramenta plataforma

ao conectar-se com a plataforma componentes que tenham um de groupware deve fornecer seu identificador IC (Identificador de IC (Identificador de Componente) Componente) vlido no servidor e a verso da ferramenta. de groupware. A partir do IC a plataforma pgina pode selecionar pertencente a

correta

ferramenta no perfil do usurio e fornecer o acesso aos dados nela contidos. [RQ38] Em salas persistentes da o

desenvolvedor

ferramenta

poder fornecer um visualizador que permita assistir o desenrolar da atividade realizada na sala pelo professor em outro

momento. 7.3. CONSIDERAES FINAIS A tcnica de cenrios muito flexvel, podendo ser adaptada pelos projetistas de acordo com seus interesses especficos. Nossa metodologia baseou-se no desenvolvimento de cenrios caricaturados de uma situao de uso da ferramenta Grard. O uso de cenrios de forma iterativa, ou seja, quando o cenrio seguinte incorpora ao sistema as funcionalidades descritas pelos requisitos do cenrio anterior, permite a utilizao de cenrios como prottipos leve (soft prototype [CAR2000]), trazendo baixo custo e maior rapidez no processo de desenvolvimento do sistema.

102

Foi interessante notar que um requisito levantado na anlise de competidores e que no foi implementado no prottipo, reapareceu na anlise de cenrios. O requisito [RQ10] indicava a necessidade de definio de diferentes papis para diferenciar as possibilidades aes dos usurios na execuo de tarefas. Esse requisito no foi implementado no prottipo por uma questo de simplificao da prototipao, porm, a anlise dos cenrios reforou a necessidade deste requisito em sistemas colaborativos educacionais, quando o reapresenta no requisito [RQ29], levantado na anlise do segundo cenrio. Neste trabalho, realizamos apenas duas iteraes com cenrios, mas isso pode ser repetido vrias vezes, pois cada nova iterao refina-se os requisitos levantados no cenrio anterior e levantam-se novos requisitos. Alm disso, cenrios facilitam a comunicao entre desenvolvedores e usurios, pois fornecem uma linguagem mais natural, baseada em uma histria de utilizao do futuro sistema.

103

8. CONCLUSES E TRABALHOS FUTUROS

Componentes sncronos de aprendizagem so sistemas que visam apoiar o aprendizado colaborativo fornecendo um conjunto de objetos

compartilhados, estes formam o espao compartilhado que representa o ambiente virtual para interao entre os alunos. Desenvolver um sistema deste tipo foi um desafio que buscou nas necessidades e expectativas dos usurios as respostas para qual arquitetura e quais servios deveriam ser oferecidos para resolver os principais problemas dos sistemas colaborativos: comunicao, conscincia de colaborao, manuteno do espao compartilhado, controle de acesso ao espao compartilhado, definio de papeis e percepo (awareness). Porm entender e traduzir as necessidades dos usurios para arqutipos de software no foi uma tarefa fcil. Uma caracterstica importante do uso da anlise de competidores foi que durante esta fase, nossa preocupao estava mais voltada para as estruturas arquiteturais e solues de software utilizadas em cada produto. De uma forma quase que inconsciente os usurios pareciam algo distante que deveriam adaptarse as solues j bem estabelecidas no mercado. As primeiras preocupaes com as futuras reaes dos usurios s comearam a aparecer na fase de desenvolvimento dos prottipos, mas foi durante a anlise dos cenrios que estas preocupaes se tornaram mais evidentes. Pois quem constri um cenrio assume o papel do usurio, passa a defend-lo e no mais ao sistema uma caracterstica natural dos

desenvolvedores tornando-se mais crtico em relao ao funcionamento do sistema, principalmente nos cenrios negativos. Percebemos que o cenrio negativo permitiu-nos derivar, de forma muito natural, todos os requisitos identificados. Acreditamos, portanto, que o cenrio positivo torna-se dispensvel para tal propsito, sendo mais interessante na identificao e destaque dos pontos fortes do sistema, o que faz parte de nossos planos futuros. 104

O prottipo da plataforma de groupware Plattus foi construdo com um toolkit, oferecendo seus servios ao programador atravs de uma API, que no a melhor alternativa quando se est trabalhando com uma linguagem orientada a objetos como Java. Como trabalho futuro pretende-se evoluir a plataforma para um framework, mais adequada ao estilo de programao que adotamos. Atualmente encontra-se em desenvolvimento um novo componente baseado na plataforma Plattus. Este objetiva a disponibilizao de um ambiente colaborativo sncrono, que possibilite a realizao de experimentos de Fsica colaborativamente. Este trabalho est sendo desenvolvido por uma colega de mestrado, Maria Cludia Barbosa Costa, e faz parte de um projeto de extenso coordenado pela CECINE Coordenadoria do Ensino de Cincias do Nordeste, coordenado pelo Professor Hlio Teixeira Coelho. Esse projeto visa realizar cursos de extenso, cada um com 40 h de durao, nas reas de Introduo Astronomia, Introduo Fsica, Introduo Qumica, Introduo Biologia, Introduo Filosofia, e Introduo Matemtica, em regime semi-presencial de ensino, em cinco cidades do estado de Pernambuco. Estas cidades representam plos principais de influncia scio-econmicas e culturais do estado de Pernambuco. Para cada curso espera-se um publico total de cem (100) pessoas por cidade. Para todas as cidades e todos os cursos, deveremos ter 3000 participantes no total. Esses cursos visam promover a formao inicial e continuada de estudantes do ensino mdio, superior e ps-graduao orientandoos na compreenso de conceitos fundamentais da rea.

105

REFERNCIAS BIBLIOGRFICAS
[ABD1997] Abdel-Wahab, H.; Kvande, B.; Kim, O.; Favreau, J. P. (1997). An Internet Collaborative Environment for Sharing Java Applications. Proceedings of the 6th IEEE Workshop on Future Trends of Distributed Computing Systems (FTDCS '97), p. 112-117. [ALV2004] Alves, E. C.; Gomes, A.; Braga, M. (2004). Componentes de Aprendizagem Sncronos. XV Simpsio Brasileiro de Informtica na Educao SBIE, p. 533-540. [ALV2005] Alves, S. V. L. (2005). Percepo em sistemas colaborativos sncronos de aprendizagem. Universidade Federal de Pernambuco. Relatrio tcnico. [BD2000] Bdker, S. (2000). Scenarios - setting the stage for reflection and action in user-centered design. Interacting with computers, v. 13, n. 1, p. 61-77. [BOR2000] Borchers, J. (2000). A Pattern Approach to Interaction Design. Proceedings of the International Conference on Designing Interactive Systems, ACM Press, p. 369378. [BOY1993] Boyd, J. (1993). Floor control policies in multi-user applications. INTERACT '93 and CHI '93 conference companion on Human Factors in Computing Systems, p. 107-108. [BRI1995] Bricker, L.; Tanimoto S.; Rothenberg, A.; Hutama, D.; Wong, T. (1995). Multiplayer Activities Which Develop Mathematical Coordination. Proceedings CSCL95, ACM Press, p. 32-39. [BRO1987] Brooks, F. P. (1987). No silver bullet: Essence and accidents of Software Engineering. IEEE Computer, v. 20, n. 4, p. 10-19. [CAR1998] Carroll, J. M.; Rosson, M.; Chin, G.; Koenemann, J. (1998). Requirements

106

Development in Scenario-Based Design. IEEE Transactions on Software Engineering, v. 24, n. 12, p. 1156-1170. [CAR2000] Carroll, J. M. (2000). Five Reasons for Scenario-Based Design. Interacting with Computers, v. 13, n. 1, p. 43-60. [DAY1997] Day, M. (1997). What Synchronous Groupware Needs: Notification Services. Proceedings of the 6th Workshop on Hot Topics in Operating Systems, p. 118-122. [DIL1996] Dillenbourg, P.; Baker, M; Blaye, A; OMalley, C. (1996). The evolution of research on collaborative learning. In: E. Spada & P. Reiman (Eds) Learning in Humans and Machine: Towards an interdisciplinary learning science, p. 189-211. [DOU1992] Dourish, P.; Belloti, V. (1992). Awareness and Coordination in Shared Workspaces. In: Proceedings of The Conference on Computer Supported Cooperative Work - CSCW'92October 1992, ACM Press, p. 107-114. [ELL1991] Ellis, C.; Gibbs, S.; Rein, G. (1991). Groupware: Some issues and experiences. Communications of the ACM, v. 34, n. 1, p. 38-58. [FER2003] Ferre, X. (2003). Integration of Usability Techniques into the Software Development Process. Proceedings of the International Conference on Software Engineering, p. 28-35. [GAM1994] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley: Massachusetts. [GAR2001] Lopez, G. P.; Skarmeta, A. G.; Rallo, R. (2001). ANTS: A new Collaborative Learning Framework. Proceedings of the European Conference on Computer-Supported Collaborative Learning, p. 22-24.

107

[GAR2002]

Lopez, P. G; Skarmeta, A. G.; Pinyol, O. M.; Gavald, C. P.; Rallo, R. (2002). MOVE: component groupware foundations for collaborative virtual environments. Proceedings of the 4th international conference on Collaborative virtual environments, ACM Press, ISBN 1-58113489-4.

[GRE1994]

Greenberg, S.; Marwood, D. (1994). Real time groupware as a distributed system: concurrency control and its effect on the interface. Proceedings of the 1994 ACM Conference on Computer Supported Cooperative Work, p. 207-217.

[GUE2001]

Guerrero, L.; Fuller, D. (2001). A Pattern System for the Development of Collaborative Applications. Information and Software Technology, v. 43, n. 7, p. 457-467.

[GUT1995]

Gutwin, C.; Stark, G.; Greenberg, S. (1995). Support for Workspace Awareness in Educational Groupware. Proceedings of Computer Supported Collaborative Learning, ACM Press, p. 147-156.

[HIL1988]

Hiltz, S. R. (1988). Collaborative learning in a virtual classroom: Hightlights of findings. Proceedings of the CSCW, p. 282-290.

[HSI1994]

Hsia, P.; Samuel, J.; Gao, J.; Kung, D.; Toyoshima, Y.; Chen, C. (1994). Formal Approach to Scenario Analysis. IEEE Software, v. 11, n. 2, p. 33-41.

[JOH1992]

Johansen, R. (1992). An introduction to computer augmented teamwork. In: Computer augmented teamwork: A guided tour.

[KOS1992]

Koschmann, T. (1992). Computer support of collaborative learning. ACM SIGCUE Outlook, v. 21, n. 3, p. 1-3.

[KOS1993]

Koschmann, T.; Newman, D.; Woodruff, E.; Pea, R.; Rowley, P. (1993). Technology and pedagogy for collaborative problem solving as a

108

context for learning. Report on a CSCW92 workshop, SIGCHI Bulletin, v. 25, n. 4, p. 57-60. [KRA1988] Krasner, G. E.; Pope, S. T. (1988). A cookbook for using the Model-ViewController user interface paradigm in Smalltalk. Journal of Object Oriented Programming, v. 1, n. 3, p. 26-49. [KUM1996] Kumar, V. S. (1996). Computer-Supported Collaborative Learning: Issues for Research. Disponvel em:

<http://www.cs.usask.ca/grads/vsk719/academic/890/project2/project2.html>. Acesso em: 15 Mar. 2005. [LIP2002] Lipponen, L. (2002). Exploring foundations for computer-supported collaborative learning. Proceedings of the Computer-supported Collaborative Learning, p. 72-81 [LIS1998] Li, S. F.; Hopper, A. (1998). A Framework to Integrate Synchronous and Asynchronous Collaboration. Proceedings of the 7th Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, p. 96-103. [MAN1997] McManus, M. M. (1997). Computer Supported Collaborative Learning. In: SIGGROUP Bulletin, v. 18, n. 1, p. 7-9. [MEN2002] Mendes, A. (2002). Arquitetura de software: Desenvolvimento orientado para arquitetura. Rio de Janeiro: Campos, 2002. ISBN 85-352-1013-X [MEZ2002] Menezes, G. G. (2002). O paradigma CSCL e a Avaliao discente mediada pelas NTICS: Reflexes atravs do conceito de contradies da teoria da Atividade. Dissertao de Mestrado - Programa de PsGraduao em Tecnologia, CEFET-PR, Curitiba-PR. [NCS2005] NCSA Habanero. Disponvel em:

<http://www.isrl.uiuc.edu/isaac/Habanero/>. Acesso em: 04 Jul. 2005.

109

[ORO2004]

Orozco, P. M.; Asensio, J. I.; Garcia, P.; Pairot, C.; Dimitriadis, Y. A. (2004). A decoupled architecture for action-oriented coordination and awareness management. Proceedings of the X International Workshop on Groupware (CRIWG04), p. 246-261.

[PAD2003]

Pdua, W. (2003). Engenharia de Software: Fundamentos, Mtodos e Padres. 2. ed. Rio de Janeiro: LTC.

[PAL1994]

Palmer, J.; Fields, N. (1994). Guest editor's introduction: Computer supported cooperative work. IEEE Computer, v. 27, n. 5, p. 15-17.

[PAT1990]

Patterson, J.; Hill, R.; Roholl, S.; Meeks, S. (1990). Rendezvous: An Architecture for Synchronous Multi-User Applications. Proceedings of ACM Conference on Computer-Supported Cooperative Work, p. 317328.

[PAT1991]

Patterson, J. F. (1991). Comparing the Programming Demands of Singleuser and Multi-user Applications. Proceedings of the 4th ACM SIGRAPH Conference on User Interface Software and Technology, p. 79-86.

[PAT1995]

Patterson, J. F. (1995). A taxonomy of architectures for synchronous groupware applications. ACM SIGOIS Bulletin Special Issue: Papers of the CSCW94 Workshops, v. 15, n. 3, p. 27-29.

[PAT1996]

Patterson, J. F.; Day, M.; Kucan, J. (1996). Notification Servers for Synchronous Groupware. Conference on Computer Supported Cooperative Work, p. 122-129.

[PHI1999]

Phillips, W. G. (1999). Architectures for Synchronous Groupware. Technical Report 1999-425, Queens University, Kingston, Ontario, Canada. Disponvel em: <http://symbiosis.rmc.ca/pub/arch-for-syncgroupware-tr1999-425.html>. Acesso em: 10 Mai. 2005.

110

[RIE1992]

Riel, M. (1992). Cooperative learning through telecommunications. ACM SIGCUE Outlook, v. 21, n. 3, p. 14-17.

[ROB1998]

Robinson, M.; Pekkola, S.; Snowdon, D. (1998). Cats Cradle: Working with other people in overlapping real and virtual worlds through tangled strands of visual and other media. Proceedings of the 4th International Workshop on Groupware - CRIWG 98, p. 3-20.

[ROS1996]

Roseman, M.; Greenberg, S. (1996). Building Real Time Groupware with GroupKit, A Groupware Toolkit. March. ACM Transactions on Computer Human Interaction, ACM Press, v. 3, n. 1, p. 66-106.

[ROT1998]

Roth, J. (1998). CSCW Internet Tools and Environments for Distance Education. Contribution to VirtUE - a Virtual University for Europe. Disponvel em: <http://dreamteam.fernuni-

hagen.de/paper/platfrms.pdf>. Acesso em: 20 Jun. 2005. [ROT2000] Roth, J.; Unger, C. (2000). Developing synchronous collaborative applications with TeamComponents. Proceedings of the 4th

International Conference on the Design of Cooperative Systems, p. 2326. [SUT2001] Suthers, D. (2001). Architectures for Computer Supported Collaborative Learning. Proceedings of the IEEE International Conference on Advanced Learning Technologies (ICALT2001), p. 25-28. [VER1997] Vergnaud, G. (1997). The nature of mathematical concepts. In: T. Nunes e P. Bryant (Eds.), Learning and teaching mathematics: An international Perspective, Psychology Press, Hove, p. 5-28.

111