Supervisores: Claudio Santos Pinhanez, Carlos Humes
Autores: Igor dos Santos Montagner, Mauro Carlos Pichiliani,Marcel Kania
Colaboradores: Crhistian Noriega, Christian Danniel Paz Trillo, Daniel Baptista Dias, Eduardo Cotrin Teixeira, Igor dos Santos Montagner, José David Fernández Curado, Marcel Kania, Marcelo Dutra Os, Marcos Takechi Hirata, Mauro Carlos Pichiliani, Reginaldo do Prado, Ricardo Augusto Teixeira de Souza, Ricardo Guimarães Herrmann
Table of Contents
|
Comentário CSP - 1a. Fase
Avaliação Geral: A
Acho que houve um bom início neste capítulo, com uma boa coleta de referências e uma boa tentativa de estruturação. Acrescentei algumas idéias para a estrutura abaixo. Bom trabalho. E não se esqueçam que o foco é em modelamento e simulação de sistemas de CSCW.
Comentário CSP - 2a. Fase
Avaliação Geral: A
//O texto está bom, com um tom correto. O que está insuficiente é o uso de referências, que pode ser maior do que é feito agora. //
texto do capítulo começa aqui
1. Introdução
"Dois suspeitos, A e B, são presos pela polícia. A polícia tem provas insuficientes para os condenar, mas, separando os prisioneiros, oferece a ambos o mesmo acordo: se um dos prisioneiros, confessando, testemunhar contra o outro e esse outro permanecer em silêncio, o que confessou sai livre enquanto o cúmplice silencioso cumpre 10 anos de sentença. Se ambos ficarem em silêncio, a polícia só pode condená-los a 6 meses de cadeia cada um. Se ambos traírem o comparsa, cada um leva 5 anos de cadeia. Cada prisioneiro faz a sua decisão sem saber que decisão o outro vai tomar, e nenhum tem certeza da decisão do outro. A questão que o dilema propõe é: o que vai acontecer? Como o prisioneiro vai reagir?"
Esta situação é chamada de "Dilema do prisioneiro" e foi proposta, primeiramente por Merrill Flood e Melvin Dresher, sendo que Albert W. Tucker formalizou o problema e o batizou com este nome. Nesta situação, os prisioneiros são confrontados com uma escolha: ou colabora com o outro suspeito ou trai para obter benefício próprio. O ponto chave do dilema é que a estratégia aparentemente vencedora é sempre trair o outro suspeito, pois escolher a traição sempre diminui a pena do prisioneiro. Porém, ao analisar o conjunto de prisioneiros, a estratégia melhor é a colaboração: qualquer outra estratégia torna a soma dos tempos de prisão maior do que a em que os prisioneiros colaboram.
Este mesmo dilema é enfrentado na implantação de sistemas de TI que procurem tirar proveito da colaboração entre participantes para a realização de uma tarefa. Ao adaptar-se ao uso de uma nova ferramenta, um participante torna-se menos produtivos e tende ser resistente ao uso de uma ferramenta que o deixa mais lento, porém quando a adoção é feita por um número mínimo de participantes os benefícios superam a estranheza inicial. Nesta situação, continuar o trabalho sozinho pode manter a produtividade e evitar um trabalho que, na visão de um participante não colaborativo, desnecessário, porém ao escolher colaborar com outros participantes pode haver melhora na produtividade e na qualidade do trabalho realizado. A área de Computer Supported Cooperative/Colaborative Work, também chamada de CSCW, estuda justamente esta situação: como grupos colaboram de maneira eficiente e eficaz e como a tecnologia pode apoiar este processo de colaboração.
Neste capítulo serão abordados aspectos fundamentais de CSCW nos capítulos 2 e 5, arquiteturas para a criação de groupware (seção 4), ambientes virtuais colaborativos (seção 6), aprendizado colaborativo apoiado por computadores (seção 7), sistemas de suporta computacional para colaboração (seção 8), aspectos gerais de modelagem e simulação em CSCW (seção 9). Na seção 10 é feita uma discussão final sobre o conteúdo apresentado. O foco deste capítulo é na modelagem e simulação na área de CSCW.
2. Fundamentos de CSCW
This chapter gives a basic introduction to Computer Supported Cooperative Work (CSCW) and groupware systems. In the first part we will explain the basic terms and concepts related to CSCW. In the latter, we will present various models and taxonomies that were created in order to classify, evaluate and compare groupware systems.
2.1 Computer Supported Cooperative Work and Groupware
The advances in the field of information and communication technology in the last decades changed dramatically the way we are communicating (and is continuing in doing so), which directly influences our working environments and the way we are working. While in former times, (efficient) work required the presence of the corroborating parties at the same place, modern technology enables us to communicate via rich media with partners scattered throughout the world.
With this advances in IT Technology and changes in work life, emerged the research discipline of Computer supported Cooperative Work (CSCW). Research in CSCW deals with the two questions: 1) how do groups work and collaborate effectively and efficiently and 2) how can IT support this collaboration. The term CSCW was coined by Irene Greif and Paul Cashman in 1984, who organized a workshop dealing with these issue. As the two research questions relate to both social (work and collaboration) and technical aspects (IT support), CSCW is a interdisciplinary field, researched by disciplines like computer science, social sciences, anthropology, business science and media sciences.
While CSCW refers to the research area, the term groupware is referred to as IT systems, that support collaborative work. This term was first used by Peter and Trudy Johnson-Lenz who defined groupware as "software that supports intentional group processes" [JohnsonLenz1981].
The Cooperative Work Framework [Dix 1998] models the entities in a groupware system and their relationships. It is build by two types of entities: artifacts and participants (normally human users). Participants modify artifacts during the work process (Figure 1.1). In a groupware system, artifacts are shared among various participants. In order to direct work goals, a groupware systems must also support communication between the participants. Based on this framework the structural support functionalities of a groupware systems are:
- computer-mediated communication, i.e. direct communication between participants is supported
- meeting and decision support, i.e. common understandings are captured
- shared applications and artifacts, i.e. interaction between group members to work on shared objects is supported
Figure 1.1 Artifacts and participants in the Cooperative Work Framework. Source: [Dix 1998].
2.2 Taxonomy and Classification
As the definition of a groupware system is quite generic, many applications, each with specific characteristics and features, may be considered as a groupware system. Thus, it is necessary to identify the specific characteristics of groupware systems in order to be able to evaluate and compare different systems. For this purpose, various models and taxonomies were developed, which we will present in this chapter.
The most basic and often cited classification is the time-space-matrix, proposed by [DeSanctis1987, Johansen1988]. It classifies systems along the dimensions time and space, regarding to the aspects when and where. The time dimension differentiates whether the interaction of the users happens in real time or not. Real-time interaction is also referred to as being synchronous, i.e. users expects an “immediate” response or reaction of the involved participants. In contrast to this stands asynchronous interaction. The dimension space differentiates between systems where users are physically located at the same place and systems where users work at different places. This results in four different categories shown in Figure 1.2.
Figure 1.2 Time-space matrix with samples (fonte: http://en.wikipedia.org/wiki/File:Cscwmatrix.jpg)
[Grudin1994] uses 3 categories for each dimension in the time-space matrix. Work can either be done at the same place, at several places, where participants are aware of these places, or at several places, which participants may not know all. Interaction can either take place in real-time, where little delay between the responses is expected and where participants have a clear expectation when responses should arrive. For asynchronous interaction, he differentiates whether users have a notion about when messages should arrive (and if at all ), or not. He refers to these three kinds of classification in each dimension as to: same, different but predictable and differrent and unpredictable (Figure 1.3).
Figure 1.3 Time-space matrix (3x3). Source: [Grudin1994]
[Dennis1988] extended this classification in their Electronic Meeting System (EMS) by refining the space dimension and adding a group-size dimension. The classes in the space dimension are (Figure 1.4):
- One Group Site: all group members are working at the same location
- Multiple Individual Sites: individual members of a group work at their individual workingplace, physically separeted from the other group members
- Multiple Group Sites: Group members are split in subgroups and members of each subgroup are working at the same location
The group size dimension differentiates between groups, whose size is either smaller or larger than 7 members. Groups up to 7 members are referred to as Member Project Teams. Groups larger than 7 are referred to as Member Task Force. The value of 7 is based on various studies that showed that process losses increase dramatically with growing group size passing this limit [Shaw1971].
Figure 1.4: Time-space-group size matrix. Source: [Dennis1988]
While the above taxonomies, based on the time-space classification, work well for simple groupware systems, they might fail for more complex systems which implement several types of functionality at the same time or which are based on various (sub) groupware systems. For instance a groupware application can implement an instant messaging system and a mail application and thus would support synchronous and asynchronous interaction. Another example is a shared whiteboard system, which content is transmitted to several subgroups at different places and is edited by each group on one touch screen. Such a system would fall both into the same time-different places and same time-same place category. For this, another kind of classification schemes was developed, which focus on the functionalities of a groupware system as classification criterias.
Penichet et. al. [Penichet2007] proposed a classification where the support of each of three CSCW characteristics, namely information sharing, communication and coordination, is evaluated for an application. This results in 8 (=2³) different classes, whereas a system that doesn't support any of these characteristics is not considered to be a groupware system.
[Teufel1995] proposed a triangular framework, which classifies groupware systems by their principle functionality they are implementing. The functionalities considered in this framework are: Communication Support, Coordination Support and Cooperation Support. Figure 1.5 shows the graphical representation: Each edge in the triangular is labeled with one function. Groupware systems are positioned within this triangular, whereas the relative distance to the edges represents the degree of support of this functionality this application implements.
Figure 1.5 Functional Classification. Source: [Teufel1995]
3. Modelos de Colaboração Entre Humanos
As CSCW deals about how IT can support group collaboration, we want to discuss the characteristics of collaborating groups in work environments. The term group refers to individuals that share a common objective and join in order to resolve a specific task, i.e. their doing is goal oriented. [Schermerhorn, J., Hunt, J. & Osborn, R. (1988) Managing Organizational behavior] define a group as "a collection of people who interact with one another regularly to attain common goals". [DuBrin 2002] defines groups as "a collection of people who interact with one another, are working towards a common purpose and perceive themselves to be a group". Another term that is commonly used for group work is team work. A often cited definition for teams comes from Katzenbach who says "A team is a small group of people with complementary skills who are committed to a common purpose for which they hold themselves mutually accountable" [KatzenbachSmith1993]. In this chapter we will use group work and team work synonymously.
3.1 Motivation for team work
Enterprises regard teamwork as promising, as it requires direct communication with colleagues, which is expected to result in exchange of knowledge and experiences. As in team work, hierarchies normally are maintained flat, it is expected both to reduce the managerial functions of superiors and increase staff satisfaction, their higher identification with tasks and goals and to take more responsibility. Furthermore, team work can result in improved performance as team members are inspiring others and working in a competitive climate [working-in-germany].
[FrancisYoung1992 ???] identified six major strengths of teamwork:
- Individual weaknesses are compensated by others strengths
- Teamwork builds consensus and commitment to common objectives
- Team membership is a strong motivator
- Members can learn to work together with efficiency, effectiveness and enjoyment
- Teams can monitor and discipline other members which results in less errors and carelessness
- Teamwork skills enable people to be assimilated into new teams and to become efficient quickly
But there are also problems with teamwork. Contribution of individual members might not be valued fairly, which can have discouraging effects. Furthermore, individuals might "hide" behind the team. Conflicts within the team go at the expense of the results. Finally, creating and developing a team is time consuming [working-in-germany].
There are various forms of team work characterized by authority, duration and objective [CohenBailey1997]:
- (classic) work teams (including service and production teams) "are stable, usually full-time and well defined" and resolve tasks given by superiors
- parallel teams are characterized by "members from various work units", "have limited authority" and "only make recommendations to individuals higher up in the organizational hierarchy"
- project teams are created for a limited time in order to "create one-time outputs" such as a new product or a service
- management teams "are responsible for the overall performance of the business unit" and coordinate sub-units in production environments
It is very likely, and often intended (e.g. in project teams), that a group consists of various characters representing the following characteristics:
- they might come from various enterprises and representing the enterprises' interests
- they have different qualifications, professional background and experiences
- they are intended to have specific roles and competences within the group
- that have different responsibilities
Due to this, it is essential to develop the team carefully at the beginning, which includes aspects such as selecting the team members [Mankin1997], perform group dynamic activities in order to make the member be acquainted with each others. Bruce Tuckman was the first that developed a model of stages [stagesgroupdevelopment] [Tuckman1965], or phases, that must be passed by teams in order to be successful. This original model was refined by various authors in the following years. [FrancisYoung1992][Hersey1969]. The four stages identified by Tuckman are:
1. Forming: This is the first stage where group members get to know each other. In this phase conflicts are avoided.
2. Storming: This is the phase where group members set up for their roles within the teams, which might create conflicts due to competitive characters. Furthermore, the group is going to define how it pretends to (re)solve the upcoming task and which leadership model they will accept
3. Norming: In this phase, team members know each other. Individual team members give up their personal interests and ideas for the sake of the team goal. Ideally, all team members take responsibility for accomplishing the task
4. Performing: In this phase group members have learned both to work autonomously and interdependently. That is, to resolve the own tasks smoothly in order to provide the results to other members whose work depends on these results.
3.2 Collaboration Awareness and Context
In order to provide efficient and effective communication, collaborative applications must support a notion about "what is done", "what was done", "who did what and when" and which are the current agreements in the project. In the context of CSCW this is referred to as collaboration awareness. [Dourish92] defines it as "an understanding of the activities of others which provides a context for your own activity". Gutwin et al. [Gutwin1995] define it as "part of the synergy that allows groups to be more efficient than individuals". They differentiate various classes of awareness such as:
- Informal Awareness: User knowledge of where the team members are currently located
- Group Structural Awareness: "The knowledge of peoples roles and everybody responsibilities, position and status of peoples within a shared artifact and group process [Ellis1991]"
- Social/Conversational Awareness: "to know if people are paying attention; to know their special abilities, emotional states or interest levels"
- Workspace awareness: "The up-to-the minute knowledge a user requires of other's group member's interaction with a shared workspace in order to collaborate effectively"
Gutwin and Greenberg [Gutwin1995] developed a framework for describing Workspace Awareness. They identified a set of (basic) elements [GutwinGreenberg2001] that answer questions about the "who", "what", "where", "when" and "how" that users might ask working in a shared workspace. Further they distinguish between workspace awareness related to the past and workspace awareness related to the present and classified the elements accordingly. This framework was extended by Vertegaal [Vertegaal1997] adding the category Conversational Awareness, which provides information about "who is communicating with whom". [Mendoza-Chapa2000] used Vertegaals framework for making a comparative analysis of various groupware systems.
Table Workspace Awareness Framework, taken from [GutwinGreenberg2001], lists the identified elements:
Category | Element | Specific Question |
---|---|---|
Who | Presence | Is anyone in the workspace? |
Identity | Who is participating? Who is that? | |
Authorship | Who is doing that? | |
What | Action | What are they doing? |
Intention | What goal is that action part of? | |
Artifact | What objects are they working on? | |
Where | Location | Where are they working? |
Gaze | Where are they looking? | |
View | Where can they see? | |
Reach | Where can they reach? |
Category | Element | Specific Question |
---|---|---|
How | Action History | How did that operation happen? |
Artifact History | How did this artifact come to be in this state? | |
When | Event History | When did that event happen |
Who (past) | Presence History | Who was here and when? |
Where (past) | Location History | Where has a person been? |
What (past) | Action History | What has a person been doing? |
Prakash uses the following types of awareness in collaborative tools [Prakash]:
- Participant Context provides awareness about the participants involved in the work. In applications, this is typically realized by displaying a contact list, with personal information of each contact, displaying photo and so on. Prakash comments the problem of limited expressiveness of such contact lists, as they just indicate whether a user is online or not, but not whether he is (actively) participating and paying attention.
- View Context deals with the problem of providing a synchronized view to the users which becomes necessary when they work distributed at the same time on a document. The paradigm of synchronizing the view is also referred to as "What You See Is What I See" (WYSIWIS).
- Telepointing is related to the WYSIWIS paradigm which refers to the feature of tracking the pointing- and selection activities of an user and displaying it to the rest of the team. There are two approaches: shared single pointer and multiple pointers. Systems of the first type provide a single pointer shared by the group and which is "locked" when used by an user at a time. The second provides a solution where each user has an own telepointer. In order to differentiate the pointers and to know to which user is belongs, such solutions ideally provide Participant Context techniques, for instance by coloring each pointer of an user with a different color.
- Activity Context is the notion about which parts of a document are currently edited by users. It is necessary for efficient work and for avoiding conflicting work. When several users work at the same part of a document, synchronization techniques are required in order to decide which result should be finally included in the document. Very often, this must be done manually, which is tedious and error prone.
4. Arquiteturas para aplicações colaborativas
Se considerarmos os vários Sistemas Colaborativos comerciais ou acadêmicos poderemos observar que diferentes topologias têm sido adotadas como arquiteturas de sistemas. A escolha da arquitetura influenciará diretamente diferentes aspectos do sistema, como desempenho, tolerância a falhas, segurança, entre outros. Portanto, as escolhas de cada sistema normalmente são orientadas pelos requisitos específicos do sistema. Enquanto um sistema busca um melhor tempo de resposta para o usuário (feedback e feedthrough time), outro pode priorizar uma maior consistência das informações compartilhadas.
Esta seção apresenta algumas arquiteturas conceituais utilizadas no desenvolvimento de aplicações colaborativas seguidas pela apresentação de três grupos de arquiteturas de implementação geralmente utilizadas neste tipo de aplicação
4.1. Arquiteturas conceituais para aplicações colaborativas
Devido à complexidade inerente ao projeto de um sistema multiusuário distribuído, geralmente a especificação de um Sistema Colaborativo é realizada através de uma arquitetura conceitual. Um dos principais objetivos de uma arquitetura conceitual é definir uma organização apropriada ao software que propicie um desenvolvimento eficiente e um código modular (facilmente modificável e reutilizável). Geralmente, uma arquitetura conceitual apresenta os componentes, ou as partes do sistema, sob a forma de unidades de desenvolvimento de software como módulos ou classes. No caso específico de Sistemas Colaborativos, arquiteturas conceituais também têm sido definidas com o objetivo de abstrair diferentes aspectos de distribuição e de concorrência.
Um estilo arquitetural descreve uma família de arquiteturas de software que compartilha propriedades, como por exemplo, os componentes permitidos, as restrições e interações entre os componentes, as invariantes, o modelo computacional etc.
Estilos arquiteturais específicos para o desenvolvimento de software surgiram ao mesmo tempo em que os sistemas groupware tornaram-se populares. As arquiteturas colaborativas foram modeladas, por meio da expansão e modificação dos componentes e de sua organização.
Com o objetivo de facilitar a organização dos componentes de uma aplicação, diversos tipos de arquiteturas de software foram desenvolvidos. Esta seção apresenta algumas das principais arquiteturas de software e estilos arquiteturais utilizados no desenvolvimento de software colaborativo. É importante notar que as principais arquiteturas descritas nesta seção focam a organização dos componentes de uma aplicação em relação à interface do usuário. O estilo arquitetural MVC, em particular, surgiu da necessidade de separar os componentes da interface do usuário dos demais componentes da aplicação.
4.1.2 O estilo arquitetural MVC e MVC distribuído
Suthers [Suthers 2001] define o estilo arquitetural MVC por meio da separação das partes da aplicação: Modelo, Visão e Controle. Na definição de Suthers, Modelo é a representação interna de modelo semântico de um problema do domínio e implementa os dados da aplicação, Visão é responsável pela visualização dos dados do Modelo por meio de alguma representação visual, e Controle habilita o usuário ou o ambiente a modificar o estado do Modelo.
O Controle é responsável por traduzir as interações do usuário com o sistema em atualizações no estado do Modelo e também por notificar os componentes da Visão que o estado do modelo foi modificado, possivelmente desencadeando alguma modificação na interface do usuário.
Os componentes Controle e Visão devem se registrar como observadores do Modelo, de modo que as modificações no estado do modelo automaticamente resultem em atualizações no Controle e também da Visão. A Figura 4.1 mostra alguns dos fluxos de mensagens da arquitetura MVC da maneira que ela é implementada na maioria dos softwares.
Uma característica inerente ao estilo arquitetural MVC é o baixo acoplamento entre Visão, Controle e Modelo. Devido a este baixo acoplamento, em teoria, uma aplicação que segue o estilo arquitetural MVC pode utilizar várias implementações de Visão e Controle para um mesmo Modelo, pois as maneiras nas quais estas partes são conectadas na aplicação geralmente é flexível, a ponto de permitir que outras implementações da Visão ou Controle sejam registradas para se comunicarem com o modelo.
Figura 4.1 - Estilo arquitetural MVC. Fonte: [Suthers 2001]
A arquitetura MVC é empregada de diversas formas nas aplicações colaborativas. Suthers [Suthers 2001] apresenta algumas maneiras pelas quais as aplicações colaborativas organizaram seus componentes na arquitetura MVC, de acordo com o nível de acoplamento dos componentes. A Figura 4.2 apresenta os quatro tipos de organização do modelo MVC, de acordo com o acoplamento dos componentes sugerido por Suthers: 1) Arquitetura Centralizada; 2) Arquitetura Replicada; 3) Arquitetura Distribuída; e 4) Arquitetura Híbrida.
A Arquitetura Centralizada sugere que somente uma aplicação contenha todos os componentes do MVC. Os clientes contêm apenas cópias distribuídas da Visão e do Controle, alimentadas pelo envio dos eventos gerados na GUI para todos os clientes participantes. Neste caso, os componentes Visão, Controle e Modelo permanecem apenas em uma máquina, como a Figura 4.2.a apresenta.
Figura 4.2 - Organizações dos componentes do MVC em: a) Arquitetura Centralizada, b) Arquitetura Replicada, c) Arquitetura Distribuída e d) Arquitetura Híbrida. Fonte: traduzido de [Suthers 2001].
Na Arquitetura Replicada, todos os componentes do software são instalados e configurados em cada uma das máquinas clientes. Esta arquitetura é caracterizada pela replicação de todos os componentes da arquitetura MVC em todos os clientes. A Figura 4.2.b apresenta a Arquitetura Replicada, onde dois clientes utilizam uma aplicação colaborativa.
A arquitetura Replicada faz um uso eficiente dos recursos de rede, pois apenas os dados relacionados com os eventos do Controle são transmitidos, diferentemente da Arquitetura Centralizada onde os dados relacionados com os eventos do Controle e também da Visão são transmitidos pela rede. Apesar de ser possível utilizar as aplicações que seguem a Arquitetura Replicada, sem a presença de uma conexão constante com a rede, estas arquiteturas, em geral, são utilizadas apenas quando há uma conexão constante entre todos os componentes.
A Arquitetura Distribuída é caracterizada pela distribuição dos componentes do MVC em várias estações. Tipicamente, o Modelo é mantido em um servidor compartilhado, e cada cliente possui os componentes da Visão e do Controle, como mostrado na Figura 4.2.c.
O exemplo mais familiar do uso da Arquitetura Distribuída pode ser encontrado em aplicações de comércio eletrônico, onde o usuário utiliza um navegador que fornece os componentes Visão e Controle para que ele interaja com os dados do Modelo armazenados em um servidor. Este tipo de Arquitetura Distribuída compartilha algumas características da Arquitetura Centralizada no sentido que as especificações da Visão e do Controle são construídas, implantadas e armazenadas no servidor, para depois serem enviadas aos clientes.
Se a Arquitetura Distribuída for corretamente implementada, somente as atualizações dos eventos no Modelo precisam ser transmitidas, fazendo com que a arquitetura utilize os recursos de rede de forma eficiente. Nesta arquitetura, os usuários podem colaborar no mesmo modelo de dados enquanto utilizam diferentes representações visuais. Contudo, a falta de um Modelo local nas aplicações faz com que elas dependam de uma conexão permanente com a rede para serem executadas.
Na Arquitetura Híbrida, apresentada na Figura 4.2.d, cada cliente mantém uma cópia local dos componentes da Visão, do Controle e do Modelo. Nela, os softwares básicos podem ser executados sem depender dos demais componentes, armazenando o estado dos dados do Modelo local em um arquivo e possuindo diferentes representações visuais de cada modelo.
Para compartilhar os dados entre os usuários, um servidor remoto é responsável para armazenar uma cópia compartilhada do Modelo que deverá sincronizar as modificações locais dos modelos em um único repositório central de dados. Assim, somente o envio dos eventos do Controle pela rede são necessários para que o modelo do software armazenado no servidor remoto possa ser atualizado. Nesta arquitetura os softwares básicos devem possuir algum mecanismo não só para enviar e receber as modificações do modelo armazenado no servidor compartilhado, mas para também atualizar os componentes de Visão.
4.1.3 Arquitetura Colaborativa Genérica
Dewan [Dewan 1995] propõe uma Arquitetura Colaborativa Genérica que estrutura um groupware em um número variável de camadas que compreendem desde o nível de domínio do problema até o nível de hardware. Nesta arquitetura, apresentada na Figura 4.3, uma camada é considerada um componente de software que corresponde a um nível específico de abstração.
Uma camada de nível inferior, isto é, uma camada que está mais perto do usuário, é responsável pelo gerenciamento de objetos que interagem com os objetos na camada imediatamente superior. A camada inferior desta arquitetura representa as estações de trabalho (sistema operacional e o hardware), responsáveis pelo gerenciamento dos dispositivos de entrada e saída da aplicação. A comunicação entre as camadas é feita por meio de eventos. Neste contexto, os eventos são considerados mecanismos de alto nível que não devem ser classificados com base na simultaneidade de comunicação entre as camadas. A camada superior da arquitetura é chamada de camada semântica, pois contém objetos que representam, internamente, os objetos abstratos que o usuário do software colaborativo utiliza no contexto da sua tarefa.
DBD:
Na camada do nível mais baixo (Camada 1), próxima ao usuário, gerencia as interações entre a interface do usuário e camada superior. Ela é responsável por apresentar as abstrações da camada acima, fazendo a transformação de uma informação em uma abstração e vice-versa, por exemplo no ambiente Web transformando os dados lógicos trabalhados no sistema em uma página HTML (no caminho do output) ou transformando as informações de um Http POST nos dados lógicos do sistema (no caminho de input).
Cada camada se comunica com a outra através de eventos, podendo ser frequentemente enviado de forma assíncrona do emissor para o receptor. Estes eventos podem ser divididos em eventos de interação, originados da interação do usuário com a aplicação e eventos de colaboração, que pode ser uma cópia ou extensão de um evento de interação, sendo propagado entre as camadas ou ainda entre as ramificações (como as interações entre as Camadas 1, 2 e R).
Alguns níveis desta arquitetura podem ser compartilhados enquanto outros podem ser versionados ou replicados. Um nível compartilhado pode atender as requisições de diversos usuários (como o caso da Camada L e R + 1), enquanto os níveis versionados ou replicados são privados a cada usuário da aplicação (Camada 1, 2 e R).
A última camada, na base dessa arquitetura são as estações de trabalho (Camada 1, onde reside o hardware e o sistema operacional), que gerenciam a tela e os dispositivos de entrada anexados a estação de trabalho.
Apesar de ser considerado uma Arquitetura Colaborativa Genérica, nem todos os módulos de um software colaborativo são organizados nas camadas abstratas apresentadas na arquitetura da Figura 4.3. As camadas e os módulos de uma arquitetura colaborativa incluem componentes da aplicação, implementados para prover as funcionalidades colaborativas do software, e componentes do sistema, que suportam a infra-estrutura necessária na colaboração. Indicar a arquitetura de uma aplicação colaborativa na verdade é caracterizar a interação e os aspectos dos componentes definidos pela aplicação.
Figura 4.3 - Arquitetura Colaborativa Genérica. Fonte: traduzida de [Dewan 1995].
DBD: Uma bibliografia que apesar de pequena pode ajudar um pouco na questão da infraestrutura além do livro de Beaudouim-Lafon é [http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=805177]
4.1.4 Modelo arquitetural PAC*
PAC* [Gaëlle 1997] é uma extensão colaborativa do modelo arquitetural PAC estruturado de acordo com o estilo sugerido pela Arquitetura Colaborativa Genérica de Dewan, mas com a diferença de permitir diferentes divisões e junções. O modelo PAC foi estendido para permitir que os controladores não apenas se comuniquem com os controladores de outros agentes do software colaborativo, mas que também interajam com outros softwares que utilizam o PAC*, sejam eles colaborativos ou não. A Figura 4.4 apresenta o Modelo arquitetural PAC*.
Figura 4.4 - Modelo arquitetural PAC*. Fonte: [Gaëlle 1997].
4.1.5 Modelo arquitetural Clover
O modelo arquitetural Clover [Yann 2002] é derivado da arquitetura de Dewan. Contudo, no lugar das cinco camadas do modelo Arch, o modelo Clover contêm seis camadas. Os componentes do Núcleo Funcional (FC) foram separados em dois componentes: os componentes de Núcleo Funcional compartilhados e os componentes de Núcleo Funcional replicados. O metamodelo Clover, uma generalização do estilo arquitetural Clover, pode ser construído sobre outras arquiteturas e estilos arquiteturais como o Arch, o PAC* ou o MVC. A Figura 4.5 apresenta o metamodelo Clover.
Figura 4.5 - Modelo arquitetural Clover. Fonte: [Yann 2002].
4.2 Arquiteturas de implementação para aplicações colaborativas
Algumas pesquisas foram realizadas dentro do domínio de Sistemas Colaborativos visando descrever ou padronizar os diferentes tipos de arquiteturas de implementação. Apesar de encontrarmos diferenças de terminologias ou de categorias é pos´sivel identificar três tipos principais de modelos de distribuição: arquiteturas centralizadas, arquiteturas descentralizadas e arquiteturas híbridas. Esta classificação é baseada em um levantamento de vários Sistemas Colaborativos síncronos porém esses mesmos modelos de distribuição também podem ser aplicados para sistemas assíncronos.
Diferente da arquitetura conceitual, uma arquitetura de distribuição, ou arquitetura de implementação, está preocupada justamente em apresentar o sistema como um Sistema Distribuído em tempo de execução. Na prática, uma vez definida uma arquitetura conceitual para um Sistema Colaborativo, este sistema será implementado através de uma arquitetura de distribuição.
4.2.1 Arquiteturas centralizadas
Uma arquitetura centralizada segue a abordagem cliente-servidor. Nela, todo o processamento necessário à execução de uma aplicação colaborativa é realizado em um servidor, único nó (ou sistema computacional). Enquanto isso, em cada nó cliente é executada uma aplicação cliente simples responsável apenas pelos serviços de apresentação de interface gráfica.
Em uma arquitetura centralizada todo gerenciamento e processamento da aplicação são realizados no servidor que também executa todo o processamento de interface gráfica de cada cliente conectado ao sistema. Quando um usuário interage com a aplicação cliente os eventos de interface gráfica referentes a esta interação são gerados pelo componente de apresentação gráfica, mas não são tratados localmente. Eles são enviados ao servidor que, através de um componente de processamento gráfico, trata o evento.
Como só há uma instância do espaço compartilhado, a implementação da arquitetura centralizada torna-se muito simples. Os problemas de controle de consistência e sincronização são naturalmente eliminados já que só existe uma instância do espaço de trabalho compartilhado. A gerência da segurança também pode ser feita de forma mais controlada. Além disso, o controle de concorrência é realizado por um servidor central que pode gerenciar todos os acessos aos recursos compartilhados e eventuais conflitos.
Contudo, toda arquitetura que segue o modelo cliente-servidor sofre de problemas bem conhecidos – baixa escalabilidade e baixa tolerância a falhas.
O problema de escalabilidade está associado ao fato de o servidor ser responsável por todo processamento, com exceção da exibição das interfaces gráficas. O gerenciamento do espaço compartilhado e o processamento gráfico de cada usuário podem representar atividades computacionalmente intensivas. À medida que o número de usuários conectados aumenta, o servidor pode não conseguir tratar de forma satisfatória os eventos recebidos de todos os clientes. Além disso, em uma arquitetura cliente-servidor, o servidor torna-se um ponto único de falha.
Esta arquitetura também tem sido aplicada no desenvolvimento de sistemas colaborativos em que o cliente é uma aplicação Web. Enquanto a aplicação Web apresenta os componentes gráficos de interação, o servidor é responsável por realizar a gerência do espaço de trabalho compartilhado.
Existe ainda uma variante desta arquitetura centralizada que não define um servidor específico para realizar o processamento centralizado do Sistema Colaborativo. Uma das aplicações clientes assume o papel de servidor e centraliza todo o processamento. É comum neste tipo de arquitetura não oferecer um espaço de trabalho privado para cada usuário. O objetivo é diminuir o processamento da aplicação do usuário que tem o papel de servidor.
4.2.2 Arquiteturas descentralizadas
Em uma arquitetura completamente descentralizada, todo processamento é executado de forma distribuída. Os recursos compartilhados também se encontram replicados nos sistemas de cada usuário.
Deve existir com isso uma instância “completa” da aplicação colaborativa rodando para cada usuário do grupo de trabalho. Um dos grandes desafios para as aplicações que implementam este tipo de arquitetura é sincronizar e manter um estado distribuído consistente do espaço de trabalho compartilhado.
No modelo de arquitetura descentralizada geralmente implementa-se um canal de sincronização direto entre as cópias do espaço de trabalho. Desta forma, se uma das cópias do espaço de trabalho é alterada, o novo estado do espaço de trabalho (ou o estado de um subconjunto do mesmo) é repassado às demais cópias para que estas últimas possam replicar o novo estado. Também é possível que a sincronização seja realizada através da replicação das alterações ou ações realizadas sobre o espaço de trabalho compartilhado. Essas alterações são geralmente resultantes de interações dos usuários sobre a aplicação colaborativa.
Uma das grandes vantagens das aplicações que implementam uma arquitetura descentralizada está no feedback time. Aplicando-se um controle de concorrência otimista, o usuário pode interagir diretamente sobre uma cópia local do espaço de trabalho sem interferência de atrasos de rede.
A redundância promovida por cópias dos recursos compartilhados e a ausência de um servidor central tornam a arquitetura descentralizada mais tolerante a falhas. Da mesma forma, com a distribuição do processamento (principalmente processamento gráfico), este tipo de arquitetura promove uma maior escalabilidade. No entanto, essa mesma distribuição pode ter impacto direto no número de mensagens trocadas entre as aplicações para garantir a sincronização. O número de mensagens também dependerá do tipo de protocolo utilizado e da forma como as mensagens devem ser distribuídas. Isso pode comprometer a escalabilidade. Além de mais recursos de comunicação, o processamento distribuído e a existência de cópias dos recursos implica em uma maior utilização agregada de outros recursos computacionais, como memória e processador.
Seguramente a gerência da consistência dos dados compartilhados torna-se mais complexa do que em um sistema centralizado. Na verdade, é comum em aplicações que implementam esta arquitetura que o estado do espaço de trabalho compartilhado fique temporariamente inconsistente.
4.2.3 Arquiteturas híbridas
Arquiteturas híbridas combinam características de arquiteturas centralizadas e descentralizadas em um único sistema. Essa combinação permite que os componentes da aplicação colaborativa sejam distribuídos e se comuniquem de diferentes formas, dependendo dos requisitos da aplicação.
Uma arquitetura híbrida bastante adotada utiliza um servidor responsável pelo gerenciamento do espaço de trabalho compartilhado enquanto a aplicação cliente gerencia o espaço de trabalho privado e realiza todo o processamento gráfico. Este modelo promove uma maior escabilidade já que uma parte do processamento é transferida para os clientes. O modelo mantém ainda a simplicidade de uma arquitetura centralizada já que só existe uma instância do espaço de trabalho compartilhado.
O tempo de resposta das ações do próprio usuário pode ser crítico em determinadas classes de aplicações colaborativas, sobretudo aplicações síncronas. Técnicas como o uso de caches nos clientes permitem reduzir esse tempo. Outros modelos de arquitetura híbrida também podem ser utilizados com objetivo de melhorar o tempo de resposta. Uma solução é dividir o espaço de trabalho compartilhado: uma parte é gerenciada pelo servidor e outra parte é gerenciada pelos clientes, como em uma arquitetura descentralizada. Esta arquitetura poderia ser utilizada para implementar diferentes mecanismos de controle de concorrência. O servidor pode aplicar um mecanismo pessimista para controlar o acesso a recursos compartilhados cuja consistência seja crítica. Paralelamente, através de um mecanismo otimista os clientes gerenciam os recursos compartilhados cujo acesso deve apresentar pequenos tempos de resposta.
Uma arquitetura híbrida também pode ser bastante adequada para acomodar em um mesmo ambiente diferentes sistemas computacionais de usuário. Neste caso, para os sistemas mais restritos (por exemplo, pouca capacidade de processamento e memória) a aplicação cliente realiza apenas o processamento gráfico e o gerenciamento do espaço de trabalho privado, enquanto o acesso ao espaço compartilhado é gerenciado pelo servidor. Para sistemas com mais recursos computacionais, a aplicação cliente também gerencia o espaço compartilhado de forma distribuída juntamente com o servidor.
5. Trabalho Colaborativo com Suporte Computacional
A área de CSCW trata, essencialmente, de como grupos colaboram para realizar tarefas e como a tecnologia pode suportar esta colaboração de modo a, entre outras coisas, aumentar produtividade, reunir grupos fisicamente distantes e facilitar a criação de conhecimento compartilhado entre equipes. Por ser uma área multi disciplinar envolvendo áreas como economia, psicologia, sociologia, computação e educação, são desafios em CSCW a comunicação de ideias para pessoas de áreas diversas e a junção de informações vindas de diversas fontes com diversos backgrounds para obter informações mais abrangentes.
O foco de pesquisas e desenvolvimento em CSCW é voltado à interação entre participantes em grupos pequenos [1], porém existe também interesse em estudos no nível de projeto, principalmente em salas de reunião inteligentes. Devido a diferenças culturais, tanto o foco de pesquisas como a aceitação de sistemas de CSCW são diferentes conforme a região. Um exemplo esclarecedor é dado em [1], que cita a importância do consenso na cultura japonesa e como este fato pode fazer com que decisões não sejam tomadas em público, mas sim em conversas privadas, e, pela preferência pelo contato e interação direta, pode existir maior resistência a adoção de um software de CSCW .
5.1 Definições de Groupware
Como definido na seção 3, groupware refere-se aos sitemas de TI que suportam o trabalho colaborativo. Apesar desta definição parecer direta, existem diversos níveis de suporte e diversos tipos de trabalhos colaborativos. Deste modo, diferentes tipos de aplicações são consideradas como groupware na literatura. Grudin [1] ilustra esta diversidade de definições através dos elementos apresentados na Figura 5.1
Figura 5.1 Níveis de suporte e tipos de trabalhos colaborativos. Fonte: [1]
Nela são mostrados diversas definições do que é groupware. Na imagem, os autores apontados consideram tudo que está acima do nome deles como groupware. Começando de cima, Allen argumenta que o e-mail é um meio para aplicações groupware, mas como não é sensível a qualidade de grupo ou organizacionais não pode ser considerado groupware. Já Kraut considera o e-mail como única aplicação de sucesso, eliminando outras aplicações abaixo desta linha. Grudin e Poltrock consideraram como groupware aplicações multi usuário como bancos de dados e sistemas de controle de versão pois estas aplicações possuem casos de sucesso informativos. Por fim, Crowley argumenta que o único fator que impede a colaboração usando computadores é a falta de software que permita interação entre PCs. Deste modo, tudo acima da camada de rede e compartilhamento de arquivos é considerado groupware.
5.2 Trabalho Colaborativo em Dispositivos Móveis
Com as novas tecnologias de computação móvel, a associação entre o local de trabalho e o ato de trabalhar tornou-se mais fraca. Diferentemente do teletrabalho (ou home-office), em que o trabalhador trabalha de casa em vez de se locomover até um escritório distante, no trabalho móvel não existe definição de um local de trabalho fixo. Esta mobilidade, que algumas vezes pode ser central para certas funções, como suporte técnico a domicílio ou força de vendas, cria novos desafios na área de CSCW devido a diversas limitações encontradas nos dispositivos móveis, como tamanho de tela, duração de bateria, conectividade e localização.
CSCW móvel deve lidar com falhas de conectividade, largura de banda restrita e tamanhos diferentes de telas. Neste cenário, implementar eficientemente WYSIWIS (What you see is what I see) é um desafio. Isto significa que a criação de Awareness é complicada por diversos fatores quando lidamos com dispositivos móveis. Além dos citados acima, a entrada de informações também pode ser um impedimento, assim como a leitura de grandes quantidades de informações em telas pequenas.
Em [13] é descrito um modelo que visa lidar com os fatores citados e são descritos diversos outros sistemas que também tentam contornar as dificuldades acima descritas.
[CPT]:
Como em outras aplicações, o trabalho colaborativo sofre algumas restrições quando realizado desde dispositivos móveis por causa das limitações de memória, conectividade e poder de visualização e manipulação. Em [9] os autores propõem uma arquitetura para aplicações colaborativas móveis e distribuídas, focando no compartilhamento de conhecimento, notificação de disponibilidade de recursos, busca de especialistas e facilidade de comunicação síncrona com os colaboradores, tudo isto encima de um middleware Peer-To-Peer, uma camada de serviços de colaboração e uma camada de aplicações (Figura 5.2).
Figura 5.2 Arquitetura para aplicações móveis colaborativas. Fonte: [9].
Um exemplo de sistema colaborativo para dispositivos móveis foi apresentado em [10]. Neste trabalho, os autores apresentam um sistema para compartilhamento e edição colaborativa de slides para apresentações durante aulas ou reuniões. O iPH (Interactive Presenter for Handhelds) foi testado dentro de um ambiente acadêmico com sucesso, mas apresenta fraquezas na utilização e em aspectos de segurança na colaboração.
5.3 Avaliação de sistemas de CSCW
O artigo [2] faz diversas críticas a implementações de sistemas de CSCW existentes. Segundo este trabalho, os sistemas possuem 3 principias problemas:
- existe disparidade entre quem faz o trabalho e quem se beneficia deste trabalho;
- na fase de design, nossa intuição é ruim para aplicações multi usuário. Existe uma tendência a vermos somente os benefícios para pessoas similares a nós mesmos;
- não conseguimos aprender por experiência pois estas aplicações introduzem obstáculos para a análise e avaliação dos resultados.
Devido a aplicações de CSCW serem alvo de grande investimento, tanto financeiro como operacional, um obstáculo adicional para a avaliação destes sistemas é o "fator gerencial". Os responsáveis por tamanho investimento querem que a aplicação seja um sucesso e este fato tanto coíbe uma avaliação dos benefícios decorrentes do uso do sistema quanto força o uso de uma ferramenta que pode diminuir a produtividade da empresa. Este fato, que se encaixa no terceiro item acima, é um grande dificultador da análise objetiva de sistemas de CSCW.
O trabalho [12] cita três grandes dificuldades para a avaliação deste tipo de aplicação:
- A logística para a avaliação distribuída é complexa
- Existe um grande número de variáveis a serem analisadas, e estas variáveis são
- É necessário um foco na validação das modificações ocorridas no trabalho em grupo baseado em CSCW.
Neste trabalho também são descritos alguns frameworks de avaliação de sistemas de CSCW, classificados em três tipos: orientados a metodologia, conceituais e orientados a conceitos específicos. O primeiro tipo descreve metodologias e experimentos disponíveis para a avaliação de sistemas de CSCW, porém não provê um guia para a escolha e comparação entre estes métodos. O segundo descreve fatores de grupo que devem ser avaliados em um CSCW, porém existem poucas referência mapeando os conceitos a serem analisados com metodologias para este fim. Por último, frameworks orientados a conceitos visam avaliar conceitos específicos, como comunicação ou coordenação. Apesar de limitados, oferecem sugestões mais concretas para melhorias no conceito avaliado, porém é difícil determinar como juntar diversos métodos deste tipo para obter uma análise global do sistema. Também é citado como método de análise a etnografia, que se caracteriza pelo contato direto do avaliador com os avaliados e envolve observação direta, questionários e entrevistas com participantes para avaliar os benefícios do sistema.
6. Ambientes Virtuais Colaborativos
Esta seção aborda aspectos de Ambientes Virtuais Colaborativos relacionados aos seus principais conceitos e definições. A seção também apresenta exemplos destes ambientes e discute questões de interação junto com aspectos de modelagem e simulação proporcionadas por estes ambientes.
6.1 Definição e conceitos
O conceito de Ambiente Virtual Colaborativo, ou CVE (do inglês, Collaborative Virtual Environment) foi difundido fora do meio acadêmico principalmente devido à obras de ficção científica representadas por livros como "Neuromancer" e filmes como "Matrix" e "Avatar".
Do ponto de vista de computação, CVE é um sistema de realidade virtual distribuído que simula em tempo real um mundo real ou imaginário, onde usuários, representados por seus avatares, estão simultaneamente presentes e podem navegar e interagir com objetos e outros usuários. Essa definição está de acordo com os exemplos mais populares e bem sucedidos de CVEs que temos hoje em dia, tais como o Second Life (SL) e o World of Warcraft (WoW). Esta definição engloba ambientes de espaços compartilhados, 3D, 2.5D, 2D ou baseados em texto.
O elemento mais básico de um CVE é o mundo virtual, definido como um espaço imaginário manifestado através de um meio que pode ser gerado através de imagens ou cenários virtuais. Este ambiente é composto de uma descrição de objetos num espaço e das regras que governam esses objetos, juntamente com a execução computacional dessa descrição. O mundo virtual deve responder às ações dos avatares, seja quando eles navegam pelo mundo, mudando suas posições e pontos de vista, seja quando eles selecionam objetos, os trocam de posição, etc. Este mundo virtual deve fornecer o sentimento de imersão (“estar lá”, dentro do mundo virtual) que, em última instância, é o que os usuários esperam obter em uma experiência com CVEs. Um CVE também deve fornecer um canal de comunicação entre os usuários e informações relacionadas à localização geográfica dos mesmos no mundo virtual.
Devido às características dos CVEs eles fornecem um terreno fértil para avaliar, validar e testar diversas teorias que não são viáveis técnica e economicamente na realidade. As principais áreas de atuação de CVEs são: o entretenimento (jogos), a simulação de teorias de comportamento, simulação de teorias macro e micro-economicas, a publicidade/propaganda, o tratamento de fobias, a simulação de algoritmos distribuídos, a realização de experimentos psicológicos, educação à distância e diversas outras área de atuação.
6.2 Exemplos de CVE
Durante a década de 1990 e 2000 diversos CVEs foram criados pela comunidade acadêmica, tais como o DIVE, o MASSIVE, o Bamboo, e o ANTS, entre outros. Fora do meio acadêmico, algumas empresas também lançaram CVEs na década de 1990, na época vistos como “chats 3D”. Alguns exemplos daquela época são: Habitat, WorldsAway, AlphaWorld, Online Traveler, The Palace e Active Worlds.
Na área de jogos destaca-se o EverQuest e o mais bem sucedido jogo em rede já lançado: o World of Warcraft, mais conhecido como WoW. O WoW é um MMORPG (do inglês, Massively Multiplayer Online Role-Playing Game, ou jogo de interpretação online e massivo para múltiplos jogadores), que é o gênero de videogame que mais cresceu em importância na última década, atingindo um total estimado de 17 milhões de jogadores em 2010. Nesse tipo de jogo um número muito grande de jogadores cria seus personagens e interage simultaneamente com um mundo virtual dinâmico e persistente. Em outubro de 2010 o WOW ele possuía cerca de 12 milhões de usuários, pagando uma taxa mensal média de 14,99 dólares. A Figura 6.1 mostra um exemplo da interface do WoW onde pode-se notar diversos avatares reunidos próximos a um local do mundo virtual antes de iniciarem uma RAID, evento que requer a participação e colaboração de diversos avatares.
Figura 6.1 Avatores do jogo WoW se reunindo antes de um evento chamado RAID. Fonte: do autor.
A empresa Linden Labs desenvolveu o primeiro CVE fora da área de jogos que conseguiu atingir uma grande massa de usuários: o Second Life (SL). O Second Life é um ambiente virtual 3D que simula em alguns aspectos a vida real e social do ser humano. Dependendo do tipo de uso, o Second Life pode ser encarado como um jogo, um mero simulador, um comércio virtual, um ambiente de educação à distância ou uma rede social. O Second Life aprimorou a noção de economia no ciberespaço. Transações comerciais podem ser realizadas numa moeda virtual (os Linden dólares) que pode ser convertida em moeda real, fora do Second Life. Assim, o Second Life permite a comercialização tanto de objetos virtuais, como de produtos reais, vendidos no ambiente virtual. Após uma explosão de crescimento por volta de 2007, até a primeira metade de 2010, o Second Life se manteve estável com cerca de 500 mil usuários economicamente ativos. A figura 6.2 mostra diversos avatares do SL participando do evento promovido pela Microsoft para o lançamento virtual do produto Microsoft SQL Server 2008 dentro do SL.
Figura 6.2 Avatares do Second Life participando do lançamento virtual do produto Microsoft SQL Server 2008. Fonte: do autor.
CGC:Semelhante ao SecondLife, há o OpenSimulator, geralmente chamado de OpenSim. Trata-se de um servidor de aplicações tridimensionais que permite a criação de ambientes virtuais acessíveis a diversos usuários. Em síntese, é um framework projetado para ser extensível, multiplataforma, que suporta múltiplos usuários e protocolos de comunicação. Além disso, permite simulação física em tempo real com auxílio dos engines, como o ODE (Open Dynamics Engine); criação de conteúdo (objetos tridimensionais) em tempo real e scripts escritos usando diferentes linguagens, tais como: LSL/OSSL (Linden Scripting Language/OpenSimulator Scripting Language), C# e VB.NET [OpenSimulator 2011].
CGC:O OpenSim, escrito em linguagem de programação C#, é uma tecnologia open source, sendo que o código fonte pode ser liberado sob Licença BSD (Berkeley Software Distribution). Utiliza o libsecondlife para a comunicação entre o cliente e o servidor, tornando possível a conexão entre um servidor OpenSim e um cliente Second Life. Na Figura 6.3 é apresentado um ambiente virtual suportado pelo OpenSim, acessado por meio de um cliente Second Life.
Figura 6.3 Avatar representado no ambiente virtual OpenSim
(Figura gerada por Fábio Carmo, estudante de mestrado do Interlab - Laboratório de Tecnologias Interativas - Departamento de Engenharia da Computação e Sistemas Digitais da Escola Politécnica da USP)
CGC:O OpenSim possui dois modos de funcionamento: Standalone e Grid. No modo Standalone, um único processo é responsável pela simulação, sendo de simples configuração, mas limitado a um determinado número de usuários. No modo Grid, diversos aspectos da simulação podem ser separados entre múltiplos processos e executados em diferentes máquinas, com a capacidade de escalonamento conforme o crescimento da demanda de usuários.
O documentário "Second Skin" (http://www.secondskinfilm.com/) produzido em março de 2008 apresenta o mundo dos CVE e seus usuários na forma de um documentário premiado internacionalmente. Este documentário aborda aspectos como emoções, economia, relacionamentos, trabalho, exploração de mão de obra e diversos aspectos em mundos que não existem fisicamente mas que abrigam mais de 50 milhões de usuários globalmente. O trabalho de Spence [Spence 2008] apresenta diversos indicadores demográficos para diferentes mundos virtuais e fornece uma visão geral da utilização de CVE na época em que foi escrito.
CNG
Second Earth (http://www.technologyreview.com/Infotech/18911/) é uma proposta que surgiu naturamente da união de modelos como Second Life (ambientes virtuais) e mirror worlds (Google Earth). Assim, é criado no mundo virtual representacões 3D de entidades do mundo real (objetos físicos) e esta representacão é mantida segundo o mundo físico, e dependendo das capacidades dos dispositivos é possível alterar o mundo físico através do mundo virtual. Nesse artigo são apresentados idéias e esforços iniciais nesta linha. Recentemente, esta abordagem deu uma nova visão na pesquisa de "realidade mista" que segue esta mesma visão. O laboratorio FX Palo Alto da Fuji Xerox (http://www.fxpal.com/?p=MixedReality) tem criado um mundo virtual para o controle de uma fabrica de chocolate, este cenário ativa um ambiente distribuído colaborativo altamente imersivo onde engenheiros remotos podem interagir com engenheiros locais.
[DMT] Ogi et al. [Ogi et al. 2003] apresentam um proposta de ambientes de CSCW virtuais onde os participantes são representados de forma tridimensional e mais realista, de forma a tornar a experiência e representatividade dos participantes mais rica. Para tal, os autores implementam diferentes formas de representação dos participantes dentro dos ambientes virtuais utilizando informações de imagens capturadas dos participantes em tempo-real. Esta representação permite que os participantes interpretem gestos ou expressões faciais dos outros participantes, permitindo, por sua vez, uma forma mais rica de comunicação e interação, de forma a melhorar a colaboração como um todo.
[DMT] Prover diferentes formas de interação e comunicação entre participantes é um dos focos de Raskar et al., em seu trabalho[Raskar et al. 1998], para tornar a colaboração entre pessoas mais rica. Neste trabalho, os autores apresentam uma proposta para o escritório do futuro, onde informações virtuais são apresentadas de forma tangível (através de técnicas de realidade aumentada espacial), para que os participantes possam interagir de forma direta com estas informações, aumentando o nível de interação e sua expressividade. Participantes remotos são representados de forma tridimensional sobre paredes criando a sensação de extensão do escritório de forma virtual, aumentar o nível de comunicação entre os participantes e, por sua vez, auxiliar o trabalho como um todo. Apesar de que esta proposta não ser implementada de forma completa pelos autores, eles apresentam a implementação, ou formas de se implementar, as ideias apresentadas no artigo, dando uma visão de um possível ambiente virtual de CSCW.
6.3 Aspectos de interação
Como todos os sistemas colaborativos, CVEs apresentam desafios tanto no campo técnico como em questões humanas, tais como cognição, percepção, comportamento, entre outras. Nesta seção trataremos os desafios do lado do ser humano focando nos aspectos relacionados à identidade, interação e presença.
As noções de identidade, localização, presença, interesse dos demais usuários e andamento das atividades devem ser suportadas de forma mais natural em um CVE visando prover a base para uma interação mais rica entre os usuários. A identidade está intimamente relacionada ao avatar que deve cumprir o papel de representar a identidade, real ou fictícia, do usuário em diversos níveis de reconhecimento.
Hoje em dia os CVEs já estão bem avançados no que diz respeito à representação visual dos avatares. Os elementos de um avatar são bastante representativas das características humanas, incluindo movimentos, gestos e algumas expressões faciais. Porém, apesar do crescente realismo apresentado pelos avatares e pelos cenários virtuais, a representação da interação, particularmente da interação face a face que os CVEs querem reproduzir, ainda é um grande desafio enfrentado por esse tipo de ambiente.
A navegação nos CVEs exige um grande esforço cognitivo dos usuários, que normalmente não possuem maiores habilidades para navegar entre os ambientes 3D, voar pelo espaço, se teletransportar, ou mesmo utilizar mapas com vários níveis de zoom. São novas habilidades, em que usuários sem uma cultura prévia de jogos 3D costumam enfrentar dificuldades.
Além de garantir a identidade, a representação do avatar é essencial para promover a interação entre os usuários de um CVE, pois é ele quem fornece as principais informações de percepção (awareness) dos usuários de um CVE. A noção de espaço e a metáfora de mundo real oferecidas por CVEs trazem possibilidades de percepção que não são triviais em aplicações de desktop.
Uma informação de percepção essencial é a localização espacial do avatar, tanto no que diz respeito à sua posição quanto à orientação. A localização é importante porque geralmente a interação se restringe a avatares fisicamente próximos. A orientação é importante porque os avatares, assim como os humanos, possuem distinção entre a frente e as costas, o que é de grande importância na interação. A orientação indica se um usuário está entrando ou saindo de uma determinada área e se ele está engajado ou não em uma atividade social.
Outra informação de percepção importante que pode ser fornecida pelos avatares é a de disponibilidade do usuário. De alguma forma o avatar deve representar quando o usuário está e quando ele não está disponível para interação com outros usuários. Um caso típico é quando o avatar está no ambiente virtual, mas o usuário real não está mais em frente ao computador. Assim como acontece em outros sistemas colaborativos síncronos (chats, por exemplo), o avatar deve fornecer alguma indicação quando o usuário real não se manifesta por algum tempo, ou se coloca como “ocupado”.
Os movimentos e gestos dos avatares, juntamente com sua posição e orientação, fornecem a informação das atividades do avatar: com quem ou com que objetos ele está interagindo, o que ele está fazendo, etc. Por exemplo, no Second Life, o avatar faz um gesto parecido com a digitação, enquanto o usuário está digitando algo na área de comunicação textual. Os gestos dos avatares também podem ser usados para chamar atenção, demonstrar algum tipo de emoção, etc.
A presença em CVEs envolve tanto a presença física quanto a social, e pode ser definida como a sensação de estar presente no mundo virtual (imersão), e estar junto com outras pessoas nesse mundo. Particularmente, a presença social é de interesse para todas as atividades que envolvam algum tipo de colaboração em CVEs. Presença é um dos assuntos mais multidisciplinares envolvendo os CVEs, passando pelas áreas de comunicação, psicologia e outras interessadas em entender os processos fisiológicos e psicológicos que ocorrem em situações extremas, que não podem ser avaliadas no mundo real. O sentimento de presença é também de grande importância para a maioria das aplicações de CVEs, tais como jogos, treinamento, ensino, simulações militares, etc.
//DMT - Sugestão: como referencia para presença poderia se utilizar o artigo de Biocca ( Frank Biocca, Chad Harms, and Judee K. Burgoon. 2003. Toward a more robust theory and measure of social presence: review and suggested criteria. Presence: Teleoper. Virtual Environ. 12, 5 (October 2003), 456-480. DOI=10.1162/105474603322761270 http://dx.doi.org/10.1162/105474603322761270) ele fala justo sobre o conceito de presença social.
[DMT] Esta presença social pode ser fortemente afetada através do nível de comunicação que a ferramenta de CSCW prove aos participantes, i.e. quais tipos de informações a ferramenta permite que os participantes troquem. Hauber et al. [Hauber et al. 2005] apresentam um estudo da presença social em diferentes ambientes de colaboração, como o face-a-face, bidimensional com video stream e tridimensional com representação virtual e espacial do ambiente e dos participantes. Neste trabalho, a presença social dos participantes é analisada através de questionário para medir variáveis, como atenção geral do grupo, entendimento geral do grupo, entre outros aspectos. Através deste estudo pode se analisar que, apesar de que os dos ambientes computacionais comparados a ambientes face-a-face tenham resultados inferiores, a presença social é maior nos caso de ambientes tridimensionais comprada à ambientes bidimensionais.
[DMT] Este resultado confirma o resultado anteriormente obtido por Fussell et al. [Fussell et al. 2000], que apresenta que a utilização de objetos virtuais, áudio e vídeo dos participantes compartilhados entre si, aumenta a velocidade de atividades como reparos de equipamentos. Os autores, neste trabalho, comparam uma mesma tarefa de reparo em condições diferentes (face-a-face, somente áudio, áudio e vídeo e objetos virtuais) analisando os resultados obtidos deste s experimentos. Através dos resultados foi possível de se observar que a comunicação por vídeo e objetos virtuais trás uma melhora na base de conhecimento na conversa entre os participantes, desta forma melhorando a eficiência da tarefa em si.
6.4 Estudos de modelagem de comportamento
A modelagem de comportamento de seres humanos é uma das áreas de pesquisa que mais utilizam CVE. Há, inclusive, uma publicação específica chamada Journal of Virtual Worlds Research (http://jvwresearch.org/page/home) cujo objetivo é apresentar pesquisas acadêmicas que envolvem especificamente mundos virtuais. Dentre o acervo de trabalhos desta punblicação destaca-se o segundo número do primeiro volume que contém apenas trabalhos relacionados ao comportamento de consumidores em mundos virtuais. Destaca-se também a conferência internacional de CVE (ACM International Conference on Collaborative Virtual Environments - http://www.ai.sri.com/cve2000/) que explora diferentes aplicações e teorias relacionadas à CVEs.
Dentre os modelos analisados e verificados em CVEs podem ser citados a modelagem de consumidores em um CVE [Parl et al. 2008], modelos de ensino e aprendizado [Chodos et al 2009, Zielke et al. 2009], modelos de avatares/agentes para CVEs educacionais [Gerhard 2003]), a modelagem de multidões em CVEs [Musse, 1998],modelagem de participantes de ambientes virtuais com redes de Petri [Huang & Deng, 2000], dentre outros.
[DMT] Criação de métricas para se avaliar a cooperações entre participantes dentro de um ambiente virtual também são importantes para a modelagem de humanos dentro de CVEs. El-Nasr et al. [El-Nars et al. 2010] apresentam métricas para ambientes de jogos digitais. As métricas para cooperação entre os jogadores, levantadas pelos autores são:
- sorrir juntos;
- trabalhados juntos com uma estratégia;
- ajudas mútuas;
- criação de estratégias globais, onde cada jogador teve papeis diferentes durante o jogo;
- esperado pelo outro jogador;
- intervir para auxilio do outro jogador.
Apesar de que muitas das métricas apresentadas neste trabalho são voltadas para jogos digitais, acredita-se que essas podem ser estendidas para o uso em CVEs genéricos, tanto como a metodologia utilizada pelos autores.
6.5 Simulação em CVE
Um CVE é um candidato natural para o estudo de simulação, uma vez que suas características já incluem mundos virtuais simulados, objetos, cenários, situações e diversos outros elementos que podem ser aproveitados quando se deseja realizar uma simulação que envolva pessoas reais representadas pelos seus avatares.
Existem diversas pesquisas na área de simulação que envolvem seres humanos representados por avatares em CVE. Nota-se que como um CVE inclui diversos aspectos de realidade virtual é importante destacar as pesquisas envolvendo simulação em CVE geralmente possuem sua origem na área de realidade virtual. Alguns exemplos de pesquisa em simulação que envolvem CVE incluem: a simulação de cirurgias [Morris et al. 2004], a simulação de design arquiteturais de prédios [Rhee et al. 2003], simulação de treinamento de funcionários responsáveis pela manutenção de aeronaves [Sadasivan et al. 2005] e simulação de aquisições [Bochenek et al. 2002].
MDO
O artigo [((bibcite CSCW-WorkflowIEEE2007))] oferece uma ótima introdução a sistemas de workflow utlizados como CSCW dentro principalmente de grandes empresas.
7. Aprendizagem Colaborativa com Suporte Computacional
A área de Aprendizagem Colaborativa com Suporte Computacional (CSCL) tem como objetivo desenvolver e analisar métodos que facilitem o aprendizado colaborativo utilizando ferramentas tecnológicas e interativas [Hadwin et al 2006]. Diferentemente de CSCW, aonde o foco é o produto final da colaboração, CSCL estuda o processo de colaboração entre os participantes e como ele pode ser melhorado para auxiliar a aprendizagem de modo colaborativo. Devido ao interesse de diversas áreas do conhecimento, como educação, psicologia, ciência da computação e interação humano computador, existe grande diferença de enfoque nos trabalhos desta área. [Hadwin et al 2006] Até o momento, não existe um framework teórico unificado e estabelecido e existem diversas divergências em relação a metologia, objeto de estudo e conceitos de colaboração [Lipponen 2002, Hadwin et al 2006]. Nesta seção serão abordados os aspectos relacionados ao conceito de colaboração em CSCL, modelagem e simulação em CSCL.
7.1 Colaboração em CSCL
Não existe uma definição bem aceita entre as diversas áreas que estudam CSCL do que é colaboração. [Lipponen 2002] identificou dois grupos de definições: um grupo em que o fator comum é que a colaboração é "um tipo especial de interação" e outro em que a colaboração é "o processo de participação em comunidades de conhecimentos". Já [Hadwin et al 2006] identificou cinco dimensões em que as definições de colaboração e tarefas colaborativas variam: posição teórica, papéis dos participantes, tipo de tarefa , propósito da colaboração e atributos gerais de colaboração.
Cinco posições teóricas foram referenciadas ou caracterizavam, mesmo que fracamente, os trabalhos: construtivismo, teoria da cognição flexível, filosofia da interação e estilo de vida, teoria sócio-cultural de Vygotsky e sócio-construtivismo.
Os papéis exercidos pelos participantes variaram em vários graus, desde a colocação do aprendizado nas mão dos participantes, incluindo as decisões sobre o conteúdo e direção da colaboração, até a condição de facilitador de um professor para o aprendizado de seus alunos.
A natureza das tarefas encontradas variou bastante. Em alguns estudos a tarefa produzia um resultado individual que deveria ser juntado a outros para formar o resultado coletivo, enquanto em outras enfatizavam a co criação de um resultado coletivo. Algumas tarefas exigiam a junção de outras tarefas individuais, enquanto outras davam ênfase na cooperação durante a tarefa. Também foram encontradas tarefas que não poderiam ser resolvidas individualmente e tarefas que enfatizavam o compartilhamento de recursos para resolver um problema ou construir um conhecimento.
O propósito da colaboração foi introduzida para melhorar, no longo prazo, a retenção e transferência, promover pensamento individual e construção de conhecimento socialmente distribuído, sintetizar informação, desenvolver senso de comunidade e ativar aprendizado usando diálogo e troca de informações.
Por último, 6 diferentes atributos presentes nas definições de colaboração exploradas foram identificados e um ou mais destes atributos são enfatizados nas pesquisas:
- Cognição distribuída, ou tentativas de promover perspectivas distintas e distribuição social do conhecimento.
- Interação no formato de comunicação e interdependência;
- Participação em comunidades de construção de conhecimento;
- Construção de equipes e concenso;
- Responsabilidade e agenciamento de estudantes
- Comprometimento conjunto para um objetivo ou resultado
[RDP] Open Domain Collaborative Storytelling With Say Anything
Artigo que apresenta o software Say Anything que cria, em colaboração com o usuário, uma história… um texto construído com a participação ativa do usuário e do programa. Basicamente, o usuário diz (digita) alguma coisa para iniciar a história e o programa busca, segundo os autores, em centenas de milhares de blogs na Internet, por frases similares e completa a sentença do usuário, ou seja, o final da história é absolutamente imprevisível. O mencionado software tem sido utilizado como ferramenta educacional.
7.1.2 Fundamentos teóricos do aprendizado
A pesquisa e os sistemas de CSCL baseam-se em, basicamente, duas perspectivas teóricas para um mecanismo que proponha o aprendizado colaborativo [Lipponen 2002]. A primeira baseia-se no conflito sócio-cognitivo de Piaget. A interação entre crianças de níveis de cognição diferentes pode provocar um choque cognitivo, que induziria à criação de novos conceitos e entendimentos. Note que o aprendizado nesta interpretação é individual, não ocorre construção de conhecimento conjunto nem pensamento compartilhado. Existe uma outra interpretação da teoria de Piaget que prega que o conhecimento é co-construído nas interação quando uma pessoa passa a considerar mais o pensamento de outras pessoas. Esta habilidade passaria por cinco etapas, desde egocêntrico e indiferente até uma visão profunda e social.
A segunda perspectiva teórica é baseada na ideias de Vygotsky, que possui duas interpretações básicas. A primeira,e mais conservadora, diz que a colaboração é um facilitador do desenvolvimento cognitivo de uma pessoa. A segunda considera o aprendizado mais como processo de grupo do que individual, sendo que o conhecimento emerge a partir das interações e é mediado pelas partes que interagem, sejam elas humanas ou ferramentas.
7.2 Modelagem e simulação de sistemas de CSCL
Na área de CSCL existem modelos que focam o processo de colaboração e modelos de sistemas de CSCL, que são mais focados na criação e design de sistemas que suportem o aprendizado colaborativo. Nesta seção serão apresentados os modelos de aprendizado colaborativo identificados em [Hadwin et al 2006], o design e modelagem do sistema AulaNet, criado na PUC-RJ e usos de agentes para modelar sistemas de CSCL.
7.2.1 Modelos de aprendizagem colaborativa
[Hadwin et al] identificou 7 modelos de aprendizagem colaborativa, que variam em tamanho do grupo, espaço, tempo (assíncrono ou síncrono), produto final do trabalho e papéis na colaboração:
- Trabalho assíncrono para compor documento único, que é feito de partes individuais sem interação entre partes; (Um exemplo poderia ser um website em que cada participante faz, separadamente, uma das seções do site.)
- Trabalho assíncrono em que os participantes refletem e trocam ideias sobre seus trabalhos, modificando-os baseado nas opiniões do grupo, porém não criam um documento compartilhado; (Estudantes trabalham individualmente, mas compartilham seus resultados e modificam os próprios trabalhos baseados nas opiniões dos outros)
- Existe troca de informações e opiniões, porém não existe contribuição para a criação de um documento único compartilhado nem a modificação dos próprios resultados em decorrência da interação; (Um grupo de estudantes de medicina trabalha, individualmente, em seus casos e recebem um feedback do restante do grupo)
- Contribuições síncronas para um documento compartilhado; (A edição compartilhada de um documento no Google Docs, que permite que várias pessoas escrevem ao mesmo tempo e troquem ideias em um chat)
- Contribuições síncronas para um documento compartilhado, porém só um dos participantes tem o direito de editar o documento; (Uma situação em que o trabalho é discutido por diversas pessoas, mas existe um responsável por fazer as modificações, que são visíveis para os outros integrantes)
- Trabalho feito com a ajuda de um sistema especialista/tutor; (A interação entre um usuário e um sistema de aprendizado que orienta o usuário para criar um trabalho se encaixa neste modelo)
- Trabalho assíncrono feito em documentos individuais, porém com a possibilidade de deixar comentários e editar o trabalho de outros integrantes. (Um exemplo seria um caderno de anotações pessoal disponível entre os participantes de um grupo, que poderiam fazer anotações e comentários nos cadernos dos outros).
7.2.2 O sistema AulaNet e o modelo 3C de sistemas colaborativos
O sistema AulaNet é uma plataforma de Ensino a Distância criado no Laboratório de Engenharia de Softawer da PUC-RJ que foi desenvolvido usando o modelo de sistemas colaborativos 3C. Este modelo "(…) é baseado na idéia de que para colaborar, um grupo tem que exercer três atividades principais: comunicar-se, coordernar-se e cooperar (…)" [Fuks et al 2004]. A Figura 7.1 contém uma representação do modelo 3C.
Figura 7.1 Representação do Modelo 3C. [Fonte: [Fuks et al 2004]]
Em sistemas de aprendizagem colaborativa, a comunicação está presente nas trocas de informações e negociações de compromissos e prazos. A cooperação é a ação conjuntas dos participantes para a realização da tarefa proposta. A coordenação, por fim, faz com que a cooperação e comunicação não sejam desperdiçadas e levem o grupo a cumprir a tarefa.
O AulaNet provê serviços para a execução destas três atividades, de modo que a colaboração seja facilitada. O modo como cada serviço do AulaNet auxilia na execução dos 3C é ilutrado pela Figura 7.2.
Figura 7.2 Serviços do AulaNet de acordo com o Modelo 3C [Fonte: [Fuks et al 2004]]
Segundo o relatado em [Fuks et al 2004], "O modelo 3C ajudou a definir as atividades do curso de forma a valorizar os vários aspectos e características da comunicação, da coordenação e da cooperação de forma que as atividades se complementem e a colaboração se torne efetiva".
Para o desenvolvimento de novos softwares de CSCL, [Pimentel 2006] define um processo de desenvolvimento de groupwares baseados no modelo 3C chamado RUP-3C-Groupware. Este processo foi criado utilizando a experiência adquirida no desenvolvimento do AulaNet e do Mediated Chat.
7.2.3 Modelos multi agentes
A modelagem de sistemas baseados em agentes é comum em sistemas de CSCL, porém existem diversas variações nos objetos modelados pelos agentes. [Zhao et al 2008] divide o sistema em três camadas: aplicativo de colaboração, serviços de colaboração e camada de comunicação. As duas primeiras camadas contém uma série de agentes, cada um especializado em uma tarefa. Na camada de aplicativo de colaboração estão incluídos agentes responsáveis por estratégias de colaboração, avaliação de aprendizado e objetivos do aprendizado. Na camade de serviços de colaboração estão agentes responsáveis por gerenciamento de grupos, objetivos e recursos. A camada de comunicação provê os serviços de infraestrutura de redes e transmissão de dados.
Outra modelagem comum utilizando agentes é a representação de cada participante do sistema como um agente, que guarda as características e o papel na colaboração da pessoa que representa. Este modelo pode ser usado tanto para a formação de grupos de colaboração que procurem maximizar a colaboração ou o aprendizado, como em [De Marchi et al 2009, Khandaker and Soh 2010], quanto para auxiliar o estudante a alcançar tanto seus objetivos como os do grupo. Uma vantagem é que como cada agente está associado a um estudante, o agente pode ser adaptativo e prover recursos para suprir as necessidades de seu usuário. Sistemas deste tipo são descritos em [Soh et al 2008, Weidong et al 2006].
7.3 Simulação de colaboração em CSCL
Como sistemas de CSCL envolvem diversas variáveis que dependem tanto do sistema (tipo de interações possíveis e orientação do professor, por exemplo) quanto do aluno (potencial de aprendizado e motivação, por exemplo), controlar e testar variações nestes atributos pode ser muito complicado em uma sala de aula real. Sistemas de simulação podem ser usados para suprir esta necessidade, fazendo com que seja possível testar cenários "E SE … " que não ocorreram em alguma situação real, fazer variações nas políticas de formação de grupos e testar abordagens com um número muito grande de estudantes e/ou por uma quantidade muito grande de tempo.
Como o interesse dos estudos em CSCL é o processo de colaboração que surge a partir das atividades individuais dos participantes em um ambiente complexo, dinâmico e com muito ruído, o modelo de agentes pode ser utilizado [Kandhaker e Soh 2008, Sklar e Davies 2005] para simular as interações que ocorrem no aprendizado colaborativo. A modelagem destes agentes pode ser feita tomando como base teorias de aprendizado colaborativo e/ou individual.
[Kandhaker e Soh 2008] descreve um sistema de simulação baseado em agentes, chamado SimCoL, cujo funcionamento básico é de simular um sistema de CSCL em que um professor forma grupos e designa tarefas para os grupos completarem. Segundo os autores, a capacidade de variar os parâmetros (como atributos dos estudantes, metodologia de trabalho e formação de grupos) dá ao professor a capacidade de: 1) testar o impacto ou se um design de CSCL específico é apropriado para um certo grupo e 2) identificar como auxiliar o aprendizado colaborativo dada uma classe ou grupo de estudantes específico.
8. Serviços de Suporte Computacional à Colaboração
Em organizações de qualquer porte a necessidade de interação de um grupo de profissionais com um ou vários grupos de pessoas é sempre presente. Quando existem projetos paralelamente acompanhados por duas ou mais pessoas, o conceito de time/equipe passa a estar presente em todas as atividades desenvolvidas, e nesse momento não contar com ferramentas de trabalho em grupo pode significar perda de rendimento e desorganização das atividades em equipe.
As ferramentas de trabalho em grupo mais comuns são classificadas como groupware, pois elas oferecem recursos para colaboração interpessoal imediata através de um sistema centralizado. Neste contexto, groupware é considerado um sistema de co-envolvimento entre recurso humano e recurso computacional como ferramenta, capaz de aumentar a produtividade e funcionalidade dos processos pessoa-a-pessoa e pessoa-a-projeto [JOHNSON-LENZ 1981].
Contudo, as funcionalidades de uma ferramenta de groupware estão cada vez mais atreladas a serviços de colaboração que se propõe a aumentar a cooperação e a comunicação interpessoal. Ao contrário do foco estritamente técnico empregados nas ferramentas de groupware, serviços de colaboração apresentam fortes dimensões sociais e organizacionais.
Esta seção discutirá alguns aspectos de serviços de suporte computacional à colaboração e também apresentará alguns exemplos de serviços que se propõem a suportar as atividades e tarefas a serem realizadas de forma colaborativa.
8.1 Aspectos de serviços de suporte computacional à colaboração
Alguns aspectos da colaboração devem ser considerados no projeto de um serviço colaborativo tais como: o processo de trabalho em grupo; a captura e gestão do conhecimento coletivo; o contexto e percepção; mobilidade, ubiquidade e pervasividade.
Processo de negócio é a forma que uma empresa organiza o trabalho e os recursos (pessoas, equipamento e informação) para atingir seus objetivos. No processo de negócio deve estar prevista a colaboração, pois o sucesso da instituição dependente cada vez mais das formas de interação entre as pessoas e do compartilhamento de conhecimento.
Conhecimento é compartilhado e construído quando pessoas interagem e trabalham em grupo. No processo de conversão do conhecimento, o aprendizado individual é expandido em conhecimento coletivo, conhecimento do grupo e das organizações. Memória de Grupo combina o conhecimento individual com a busca e a consciência do conhecimento disponível no ambiente coletivo. Sistemas colaborativos criam um ambiente propício à gestão do conhecimento, pois auxiliam a criação, uso e compartilhamento de informações.
Contexto são informações sobre o grupo, os artefatos, o ambiente compartilhado e a tarefa em execução. Contexto apóia a seleção das informações relevantes para evitar o problema da sobrecarga de informação. Mecanismos de gerenciamento das informações de contexto e de visualização dessas informações são relevantes e devem constar no projeto de serviço que suporta a colaboração [SCHROEDER 2010].
Percepção está relacionada com a capacidade de um participante reconhecer e compreender as ações executadas pelos participantes do grupo. É comum o uso de mecanismos de percepção para prover informações e notificações sobre as ações do grupo, o que apóia a atividade do participante e minimiza a sensação de solidão e isolamento em interações virtuais.
Questões de privacidade, segurança e intrusão devem ser tratadas para mitigar os efeitos invasivos inerentes aos mecanismos de percepção. Mobilidade, Ubiquidade e Pervasividade são aspectos importantes para o suporte computacional da colaboração realizada localmente ou em diferentes ambientes distribuídos.
Também é importante citar que os serviços de colaboração devem levar em conta aspectos técnicos como infra-estrutura de comunicação, funcionalidade de troca de mensagens e acesso a dados compartilhados, dentre outros. Isto torna o serviço de colaboração um importante mecanismo para melhorar o intercâmbio de conhecimento tácito, pois ele facilita o compartilhamento de informações e o trabalho conjunto em projetos.
8.2 Exemplos de serviços de suporte à colaboração
O Lotus Notes foi uma das plataformas de groupware mais populares durante os início das ferramentas que suportam o trabalho em grupo. A vocação essencial do Lotus Notes como software de groupware é permitir que as pessoas colaborem de forma a adicionar valor ao negócio. O Lotus Notes oferece todos os recursos tradicionais de um sistema de groupware, suportando vários aplicativos de colaboração como correio eletrônico, grupos de discussão, centrais de suporte e outros. O Lotus Notes não é mais disponibilizado como uma ferramenta e sim como um serviço de colaboração on-line e rede social que recebeu o nome de LotusLive, disponível em: http://www.lotuslive.com/.
De forma semelhante ao Lotus Notes, o Microsoft NetMeeting se tornou uma popular aplicação para a colaboração através de vídeo conferência. Esta ferramenta de groupware permitia a criação de conferências virtuais e compartilhavainformações integrada com as ferramentas do pacote Microsoft Office, além de possuir recursos de compartilhamento de desenho como em um quadro negro virtual. O Microsoft NetMeeting se transformou em um serviço de colaboração chamado Windows Meeting Space (http://windows.microsoft.com/en-US/windows-vista/Collaborate-anywhere-using-Windows-Meeting-Space) que contém recursos para compartilhamento de agendas, calendários, apresentações, notas, desenhos, diagramas e outros elementos junto com vídeo e áudio conferência.
O SalesForce (http://www.salesforce.com/br/) é uma serviço de colaboração que visa auxiliar as equipes de venda de uma empresa através da gestão do relacionamento com clientes (CRM). Neste contexto o CRM permite a gestão das relações com todos os clientes, inclusive os potenciais, aliando processos, pessoas e tecnologias empresariais para alcançar um único objetivo: obter clientes e mantê-los satisfeitos. Trata-se de uma estratégia global que o ajuda a conhecer melhor seus clientes e seu comportamento, permitindo-lhe criar relações mais sólidas e duradouras que beneficiarão o usuário do serviço.
Com a popularização das tecnologias fornecidas pela internet na chamada web 2.0 diversas empresas começaram a fornecer serviços quer suportam a colaboração on-line. Dentre as principais áreas que envolvem colaboração podem ser citados serviços de compartilhamento de documentos, arquivos, vídeo, diagramas, apresentações, calendários, gerenciamento de projetos, versionamento de arquivos, chat, VoIP, vídeo conferência, compartilhamento de tela e muitas outras. No link http://www.mindmeister.com/pt/12213323/best-online-collaboration-tools-2011-robin-good-s-collaborative-map há um mapa conceitual contendo mais de 50 serviços on-line que podem ser utilizados para suportar a colaboração computacional.
DBD:
Em 2009, o Google lançou um serviço de suporte a colaboração chamado Google Wave. Através desta ferramenta os usuários poderiam trocar mensagens, que são armazenadas em um servidor central como uma espécie de post de um fórum de internet, onde os destinatários da mensagem poderiam editá-la em tempo real, fazendo comentários em partes das mensagens especificas da mensagem, seja com texto ou com outros recursos multimídias, como videos do YouTube.
Em 2010 o serviço foi descontinuado pela Google, porém a tecnologia foi aproveitada no Google Shared Spaces, um espaço onde um desenvolvedor pode utilizar a API do Google Wave para criar a sua própria aplicação colaborativa e publica-la.
9. Modelamento e Simulação de Sistemas de CSCW
O modelamento de sistemas de CSCW pode ser realizado de várias maneiras, porém geralmente a modelagem utilizada tem como foco auxiliar a implementação e outros detalhes práticos envolvidos no desenvolvimento do sistema de CSCW. A modelagem voltada para a simulação não é muito comum como forma de experimentação, verificação e validação de sistemas de CSCW principalmente pelo fato que estes sistemas dependem de pessoas para a realização do trabalho de forma cooperativa. Além disso, geralmente os sistemas de CSCW são avaliados através de experimentos que contam com pessoas reais utilizando o sistema em situações pré-programadas ou através da observação da utilização do sistema em um contexto real. Contudo, existem alguns exemplos de simulação de sistemas de CSCW de acordo com o tipo de aplicação e da maneira na qual as ações e comportamento das pessoas são representadas durante a interação com o sistema.
Ferramentas para a criação, acompanhamento e execução de workflows são o grupo de sistemas de CSCW mais populares para a organização e execução de tarefas que envolvem grupos de pessoas. Baseado na modelagem de um processo de expedição de cartões de crédito, Rozinat et. al [Rozinat 2008] exploram a utilização de informações de design, histórico e estado do processo para realizar simulações do workflow visando auxiliar o processo de tomada de decisão operacional. A Figura 9.1 mostra como o processo de expedição de cartões de crédito foi modelado utilizando a ferramenta YAML (Yeat Another Workflow Language http://www.yawlfoundation.org/).
Figura 9.1 Modelagem do processo de expedição de cartões de crédito na ferramenta YAML. Fonte: [Rozinat 2008].
A partir do processo modelado em YAML e dos logs gerados pela execução das tarefas deste workflow os autores montaram o modelo de simulação que se baseia em redes de petri colorida (Coloured Petri Nets - CPN). Este modelo CPN é integrado com workflow em YAML no simulador proposto pelos autores e apresentado na Figura 9.2.
Figura 9.2 Modelo de simulação do processo de expedição de cartões de crédito. Fonte: [Rozinat 2008].
As ferramentas utilizadas para a modelagem de modelos de processo de negócio (Bussiness Process Models - BPM) também são consideradas sistemas de CSCW. A disciplina de BPM possui diversas opções para simulação e Jansen-Vullers e Netjes [Jansen-Vullers 2006] apresentam um estudo onde as ferramentas de simulação de modelos de processo de negócio Protos, ARIS, FLOWer, FileNet, Arena, CPN são avaliadas de acordo com os critérios facilidade de modelagem, verificação formal e semântica, nível de detalhe, transparência, desempenho e outros. Estas ferramentas permitem a simulação a partir de modelos criados com agentes, redes de petri coloridas (CPN), Event-driven Process Chains (EPCs), cadeias de valor (value chains), organogramas, diagramas de alocação funcional e filas de trabalho (work queues).
Outro exemplo de simulação de sistemas de CSCW é a simulação de atividades de um grupo de estudantes que empregam um sistemas de colaborativo educacional (CSCL) disponível pela Web proposto por Barbero et al. [Barbero 2007]. Este sistema modela tanto os alunos como as tarefas a serem realizadas como agentes ativos. O modelo de simulação, chamado de KnowCat Simulation Model, é apresentado na Figura 9.3 como um diagrama de classes que mostra o relacionamento dos agentes e suas características.
Figura 9.3 Modelo de classes que representa um agente na simulação de grupos de estudantes que empregam um sistemas de colaborativo educacional. Fonte: [Barbero 2007]
O modelo e a simulação foram implementados na biblioteca de simulação multi-agentes Swarm (http://www.swarm.org/index.php/Main_Page). Este modelo conta com mais de 30 parâmetros e procura, entre outras métricas, avaliar a quantidade de conhecimento adquirido pelos estudantes de acordo com as personalidades dos estudantes, os seus relacionamentos de amizades, a qualidade dos documentos fornecidos pelos professores e o tempo e quantidade de tarefas atribuídas durante a simulação de um curso.
Com o objetivo de simular o efeito de diferentes políticas de sincronização em um editor de texto compartilhado Maldonado [Maldonado 2006] propõe o simulador SynchSim. Esta ferramenta utiliza a simulação de eventos discretos (Discreve Event Simulation - DES) para avaliar quatro políticas de sincronização em editores de texto colaborativos em tempo real: Strict, Relaxed, Hybrid e Totally Relaxed. Cada uma das políticas é modelada de acordo com a frequência de sincronização do trabalho entre os participantes. O simulador modela os participantes de acordo com a velocidade de leitura e o tempo de interação com o documento. A Figura 9.4 abaixo mostra a janela do simulador que permite a configuração dos parâmetros da simulação.
O autor utiliza a simulação para avaliar características de cada política como, por exemplo, a penalidade por desfazer trabalho (rollback) e o efeito do número de participantes no tempo total de execução da tarefa simulada de acordo com cada política de sincronização.
Figura 9.4 Tela de configuração dos parâmetros de simulação do SynchSim. Fonte: [Maldonado 2006].
Berkenbrock e Hirata [Berkenbrock 2007] apresentam uma simulação em um ambiente de cooperação móvel. Esta simulação tem como objetivo testar o tempo de comunicação e o consumo de energia de aparelhos móveis quanto utiliza-se uma técnica de coerência de cache adaptada para o ambiente de colaboração móvel. A simulação foi realizada utilizando a ferramenta de simulação de rede The Network Simulator NS-2 (http://www.isi.edu/nsnam/ns/) , que é simulador para eventos discretos direcionado à pesquisa em redes de computadores. O modelo de rede escolhido na simulação representa a estrutura de um cenário (redes TCP cabeadas e sem fio) onde se considera a assimetria na comunicação e consumo de energia para verificar a eficiência do algoritmo de coerência de cache. Este modelo foi implementado através da codificação do algoritmos de coerência de cache em C++ e Tcl na aplicação chamada Mobile Groupware Cache Coherence.
10. Discussão Final
Durante este capítulo foram expostos diversos aspectos de Colaboração Auxiliada por Computador(CSCW), uma área de estudo que foi batizada na década de 80, ganhou importância com a alta disponibilidade da internet para o público e enfrenta novos desafios com a chegada dos dispositivos móveis atuais, como tablets e smartphones.
Os fundamentos de CSCW são descritos na seção 2, explicitando as possíveis situações que um sistema colaborativo deve ser capaz de lidar. Na seção 3 são apresentados modelos de humanos voltados para aspectos de colaboração. Um aspecto importante para sistemas colaborativos é o de Awareness (presença, em tradução livre), que representa a sensação de proximidade que um participante tem dos outros, mesmo que a distância física entre eles seja grande.
A seção 4 apresentou as principais arquiteturas conceituais e de implementação utilizadas para a construção de aplicações colaborativas chamados de groupware. O foco desta seção foi descrever em aspectos técnicos como organizar os componentes de forma adequada para que as aplicações colaborativas atendam aos requisitos de comunicação, cooperação e colaboração.
Na seção 5 foram discutidos aspectos gerais de CSCW, focando nas diversas definições de groupware, avaliação de groupwares e nos desafios criados pela introdução do uso dispositivos móveis para colaboração. O artigo [2] merece destaque pois descreve fatores que causam falhas na adoção e no uso de softwares colaborativos.
A seção 6 abordou os conceitos e definições de Ambientes Virtuais Colaborativos CVE - Collaborative Virtual Environments). Inicialmente esta seção descreveu os principais conceitos e definições seguidos de exemplos de CVEs, como o jogo World of Warcraft (WOW) e o Second Life. A seção discutiu ainda os principais aspectos de interação, alguns estudos sobre modelagem de comportamento e de simulação nestes ambientes virtuais.
Na seção 7 foi apresentada a área de sistemas para aprendizado colaborativo. Nesta área não existe uma teoria unificada para a criação de sistemas e a multitude de esforços vindos de diversas áreas, como psicologia, pedagogia e computação, revela vocabulários e backgrounds muito diferentes. Foram descritas técnicas de modelagem e simulação de ambientes de aprendizagem colaborativa, com destaque para o sistema AulaNet, desenvolvido pela PUC-RJ
O conteúdo da seção 8 foca nos serviços de colaboração que suportem o trabalho em grupo. Esta seção discute os aspectos de processo de trabalho em grupo, captura e gestão do conhecimento coletivo, contexto, percepção, mobilidade, ubiquidade e pervasividade. Por fim, a seção também apresenta alguns exemplos de serviços de colaboração disponíveis na internet.
A modelagem e a simulação de sistemas CSCW é o conteúdo da seção 9, que discute e apresenta exemplos de como modelar um sistemas CSCW com foco na simulação. Apesar desta técnica não ser muito utilizada para testar hipóteses, validar e verificar sistemas de CSCW, a seção contém alguns exemplos de modelagem e simulação envolvendo ferramentas para o trabalho em grupo.
Com estas seções os principais temas sobre CSCW foram abordados, sendo que, sempre que possível, foi dada ênfase para os aspectos de modelagem e simulação. Em cada seção foi coberto o básico de cada assunto e são dadas referências para trabalhos e artigos importantes na área.
Referências
Beaudouim-Lafon, M. 1999 "Computer Supported Co-operative Work". John Wiley and Sons, ISBN 0-471-96736-X.
Bardram, Jakob. Desining for the Dynamics of Cooperative Work Activities. Proceeding CSCW '98 Proceedings of the 1998 ACM conference on Computer supported cooperative work, New York., 1998.
[Bochenek 2002] Grace M. Bochenek, James M. Ragusa. "Using Collaborative Virtual Environments for Simulation Based Acquisition". In Proc. of the 2002 European Simulation Interoperability Workshop, 2002
[CohenBailey1997] "What Makes Teams Work: Group Effectiveness Research from the Shop Floor to the Executive Suite", Cohen, S. G., Bailey, D. E., Journal of Management, 1997, Vol. 23, No. 3, 239-290
[Chodos 2009] David Chodos, Parisa Naeimi, Eleni Stroulia. " An integrated framework for simulation-based training on video and in a virtual world". In Journal of Virtual Worlds Research vol. 2 nro. 1, Abril 2009, pp. 3-28.
[Dennis1988] Dennis, A.R. and George, J.F. and Jessup, L.M. and Nunamaker Jr, J.F. and Vogel, D.R., “Information technology to support electronic meetings”, Journal: MIS quarterly, Pages 591-624, ISSN 0276-7783, 1988, Publisher JSTOR
[DeSanctis1987] Desanctis, G. and Gallupe, R.B., “A foundation for the study of group decision support systems”, Management science, Vol. 33, No. 5, Pages 589-609, ISSN: 0025-1909, 1987, JSTOR]
[Dix1998] Alan Dix, Janet E. Finlay, Gregory D. Abowd, Russell Beale, Human-Computer Interaction (2nd Edition), 1998
Dourish, Paul. Developing a Reflective Model of Collaborative Systems. ACM Transactions on Computer-Human Interaction, VOI 2, No. 1, March 1995 Pages 40-63.
[Ellis1991] C. A. Ellis, S. J. Gibbs and G. L. Rein, “Groupware: Some Issues and Experiences”, Communications of the ACM, 1991, Vol. 34, No. 1, pp. 38-58.
EPSTEIN, I. (1995) O dilema do prisioneiro e a ética. Estudos Avançados, vol. 9 no. 23, Jan./Apr. 1995. Instituto de Estudos Avançados, USP. ISSN 0103-4014. DOI: 10.1590/S0103-40141995000100010
[Gerhard 2009] Michael Gerhard. " A Hybrid Avatar/Agent Model for Educational CVEs". Tese de doutorado, Leeds Metropolitan University, Fevereiro 2009.
Greenberg, Saul. An Annotated Bibliography Of Computer Supported Cooperative Work. SIGCHI Bulletin July 1991, Vol. 23, nro 3.
Greif, Irene. (1988) "Computer-Supported Cooperative Work: A Book of Readings". Morgan Kaufmann, ISBN-13: 978-0934613576.
[Grudin1994] Grudin, J., “Computer-supported cooperative work: History and focus”, Journal Computer, Vol. 27, No. 5, Pages 19-26, ISSN 0018-9162, 1994, IEEE
GRUDIN, J. Why CSCW applications fail: Problems in the design and evaluation of organizational interfaces. Proceedings of the 1988 ACM conference on Computer supported cooperative work, pg 85-93, 1998
[Gutwin1995] C. Gutwin, G. Stark and S. Greenberg, “Support for Group Awareness in Educational Groupware”, Proceedings of the Conference on Computer Supported Collaborative Learning (CSCL’95), Bloomington, Indiana, USA, 1995, pp. 147- 156.
[GutwinGreenberg2001] Gutwin, C., and Greenberg, S. (2001) "A Descriptive Framework of Workspace Awareness for Real-Time Groupware", Computer Supported Cooperative Work, Kluwer Academic Press.
[Huang 2000] Jiung-Yao Huang, Lawrence Y. Deng. " The Petri Net Model for the Collaborative Virtual Environment on the Web ". In Tamkang Journal of Science and Engineering, Vol. 3, No. 4, pp. 267-281, 2000.
[Johansen1988] Johansen, R.,”Groupware: Computer support for business teams”, ISBN: 0029164915, 1988, The Free Press]
Lynch, K., Snyder, J., Vogel, D. 1990 The Arizona Analyst Information System: Supporting Collaborative Research on International Technology Trends. In Gibbs, S., Verrijn-Stuart, A. (Eds.) 1990 “Multiuser Interfaces and Applications” North-Holland, pp. 159-174.
[JohnsonLenz1981] Johnson-Lenz, P. and T. Johnson-Lenz, Consider the Groupware: Design and Group Process Impacts on Communication in the Electronic Medium, Studies of Computer-Mediated Communications Systems: A Synthesis of the Findings, Computerized Conferencing and
Communications Center, New Jersey Institute of Technology, Newark, New Jersey, 1981
[Morris 2004] Dan Morris, Christopher Sewell , Nikolas Blevins, Federico Barbagli, Kenneth Salisbury. "A Collaborative Virtual Environment for the Simulation of Temporal Bone Surgery ". In Proc. of the Medical Image Computing and Computer-Assisted Intervention - MICCAI , pp. 319-327, 2004.
[Musse 1998] Soraia R. Musse, Christian Babski, Tolga Çapin, Daniel Thalmann. "Crowd Modelling in Collaborative Virtual Environments ". In Proceeding VRST '98 Proceedings of the ACM symposium on Virtual reality software and technology, 1998.
Neale, Dennis C., Caroll, John M., Rosson, Mary B. Evaluating Computer-Supported Cooperative Work: Models and Frameworks. Proceeding CSCW '04 Proceedings of the 2004 ACM conference on Computer supported cooperative work, Chicago, Illinois , 2004.
NUNAMAKER, Jay F; DENNIS, Alan R; VALACICH, Joseph S; VOGEL, Douglas R; GEORGE, Joey F. Electronic Meeting Systems to Support Group Work: Theory;Practice at Arizona, Communication of the ACM, vol.34, n.7, p.40-61, 1991.
[OpenSimulator 2011] OpenSimulator. Disponível em: http://opensimulator.org/wiki/Main_Page. Acesso em: 10 mai. 2011.
[Park 2008] So Ra Park, Fiona Fui-Hoon Nah, David DeWester, Brenda Eschenbrenner, "Virtual World Affordances Enhancing Brand Value". In Journal of Virtual Worlds Research vol. 1 nro. 2, Novembro 2008, pp. 1-18.
[Penichet2007] Penichet, VMR and Marin, I. and Gallud, JA and Lozano, MD and Tesoriero, R., “A classification method for cscw systems”, Electronic Notes in Theoretical Computer Science, Vol. 168, Pages 237-247, ISSN 1571-0661, 2007, Elsevier
[Rhee et al. 2003] Seon-Min Rhee, Eun Cho, Hyo-Sun You, Myoung-Hee Kim. "Architectural Design and Simulation in the Heterogeneous Collaborative Virtual Environment". In Proceedings of CW'2003. pp. 120-127
[Sadasvian 2005] Sadasivan, S., Rele, R., Greenstein, J. S., Duchowski, A. T., and Gramopadhye, A. K., “Simulating On-the-Job Training using a Collaborative Virtual Environment with Head Slaved Visual Deictic Reference”, in Proceedings of HCI International, Las Vegas, NV, July 22-27, 2005.
[Shaw1971] Shaw, M.E., “Group dynamics: The psychology of small group behavior”, 1971, McGraw Hill.
[Spence 2008] Jeremiah Spence. " Demographics of Virtual Worlds ". In Journal of Virtual Worlds Research Vol. 1 nro. 2, Novembro 2008, pp. 20-65.
[Teufel1995] Teufel, S. and Sauter, C., “Computerunterstützung für die Gruppenarbeit”, 1995, Addison-Wesley
[Zielke 2009] Marjorie A. Zielke, Thomas C. Roome. "A Composite Adult Learning Model for Virtual World Residents with Disabilities A Case Study of the Virtual Ability Second Life". In Journal of Virtual Worlds Research Vol. 2 nro. 1, Abril 2009, pp. 53-87.
Whitaker, S., Terveen, L., Hill, W., Cherny, L. The dynamics of mass interactions. Proceeding CSCW '98 Proceedings of the 1998 ACM conference on Computer supported cooperative work, New York, 1998.
[http://jom.sagepub.com/content/30/6/805.short Luis L. Martins, Lucy L. Gilson, and M. Travis Maynard
Virtual Teams: What Do We Know and Where Do We Go From Here?
Journal of Management December 2004 30: 805-835, doi:10.1016/j.jm.2004.05.002]
[Hadwin et al 2006] Toward Standards for Reporting Research: A Review of the Lliterature on Computer-Supported Collaborative Learning Allyson F. Hadwin, Carmen L. Z. Gress, Jessica Page.
CGC: Tsiatsos, Th.; Konstantinidis, A.; Ioannidis, L.; Tseloudi, C. Implementing Collaborative e-Learning Techniques in Collaborative Virtual Environments: The Case of Second Life. In Proceedings of the 2009 Fourth Balkan Conference in Informatics (BCI '09). IEEE Computer Society, Washington, DC, USA, 2009, 181-186. DOI=10.1109/BCI.2009.33 http://dx.doi.org/10.1109/BCI.2009.33 Tsiatsos2009.pdf.
[Stahl et. al 2006] Stahl, G., Koschmann, T., & Suthers, D. (2006). Computer-supported collaborative learning: An historical perspective. In R. K. Sawyer (Ed.), Cambridge handbook of the learning sciences (pp. 409-426). Cambridge, UK: Cambridge University Press. cscl-historical-perspective.pdf
[Lipponen 2002] Lasse Lipponen. 2002. Exploring foundations for computer-supported collaborative learning. In Proceedings of the Conference on Computer Support for Collaborative Learning: Foundations for a CSCL Community (CSCL '02), Gerry Stahl (Ed.). International Society of the Learning Sciences 72-81. cscl-foundations.pdf
[Sklar e Davies 2005] Elizabeth Sklar and Mathew Davies (2005), Multiagent Simulation of Learning Environments, Fourth International Conference of Autonomous Agents and Multiagent Systems (AAMAS-2005)
[Khandaker e Soh 2008] Nobel Khandaker, Leen-Kiat Soh (2008), On Incorporating Learning Theories to Simulate a Computer-Supported Collaborative Learning Environment, University of Nebraska–Lincoln, Computer Science and Engineering Technical Report TR-UNL-CSE-2008-0006, (Sept. 4, 2008) cscl-simulation
[FrancisYoung1992] Francis, D. & Young, D. (1992), "Improving work groups: A practical manual for team building", Pfeiffer
[Hersey1969] Hersey, P. and Blanchard, K. H. (1969). Life cycle theory of leadership. Training and Development Journal, 23 (5), 26–34.
[Hugo et al 2004] Hugo Fuks, Marco Gerosa, Alberto Raposo, Carlos de Lucena (2004), O modelo de colaboração 3C no ambiente AulaNet, INFORMÁTICA NA EDUCAÇÃO: teoria & prática. ISSN: 1516-084X e-ISSN: 1982-1654
[Mankin1997] Mankin, D., Cohan, S. G., Bikson, T. K. "Teams and Technology: Tensions Participatory in Design", Organizational Dynamics, 1997
[Pimentel 2006] Mariano Gomes Pimentel, Orientador: Hugo Fuks (2006), RUP-3C-Groupware: um processo de desenvolvimento de groupware baseado no modelo 3C de colaboração. Tese de doutorado, Rio de Janeiro.
[De Marchi et al 2009] Ana De Marchi, Márcia Moraes, Cristiane Testa (2009), CV-Muzar Using a Multiagent System for Group Formation, World Conference on Computers in Education - WCCE , pp. 159-168, 2009
[Khandaker and Soh, 2010] Nobel Khandaker, Leen-Kiat Soh (2010) , ClassroomWiki: A Collaborative Wiki for Instructional Use with Multiagent Group Formation, Scheduled for publication in forthcoming issue of IEEE TRANSACTIONS ON LEARNING TECHNOLOGIES, TLT-2009-07-0129 Digital Object Indentifier
[Soh et al 2008] Leen-Kiat Soh, Nobel Khandaker, Hong Jiang (2008), I-MINDS: A Multiagent System for Intelligent Computer-Supported Collaborative Learning and Classroom Management, Journal International Journal of Artificial Intelligence in Education, Volume 18 Issue 2, April 2008
[Weidong et al 2006 ] Weidong Pan, Igor Hawryszkiewycz and Dongbei Xue (2006), FACILITATING COLLABORATION AMONG STUDENTS
IN E-LEARNING BY SOFTWARE AGENTS, IADIS International Conference e-Society 2006
[Zhao et al 2008] Xiaoming Zhao, Wenping Guo, Ying Chen (2008), Construction of Collaborative Learning System Based on Multi-Agent Technology, 2008 Seventh International Conference on Web-based Learning
[Rozinat 2008] Rozinat A., Wynn M., Aalst W, Hofstede, A. Fidge, C. Workflow Simulation for Operational Decision Support Using Design, Historic and State Information. In Proceedings of the 6th International Conference on Business Process Management, Springer-Verlag Berlin,p. 7-16, 2008.
[Jansen-Vullers 2006] Jansen-Vullers M., Netjes M. Business process simulation – a tool survey. In Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools, Aarhus, Denmark, October 2006.
[Barbero 2007] Barbero Á, González-Rodríguez M. S., de Lara J., Alfonseca M. Multi-agent simulation of an educational collaborative web system. In European Simulation and Modelling Conference 2007 proceedings, 2007.
[Maldonado 2006] Maldonado, M. Synchronization Policies in Collaborative Work Environments. Tese de mestrado, Estocolmo, Suécia, 2006.
[Mendoza-Chapa2000] Mendoza-Chapa, S., Romero-Salcedo, M., Oktaba, H., "Group Awareness Support in Collaborative Writing Systems", Proceedings of the 6th International Workshop on Groupware, (CRIWG’00) 0-7695-0828-6/00 $10.00 © 2000 IEEE
[Berkenbrock 2007] Berkenbrock, C. D. M., Hirata C. M. Um estudo de simulação para avaliar o tempo de comunicação e o consumo de energia em um ambiente de cooperação móvel. Em Sistemas & Gestão, Vol. 2, nro 3, p. 303-318, 2007.
[Suthers 2001] SUTHERS, Daniel D; JONES, Dan. An Architecture for Intelligent Collaborative Educational Systems. In: Proceedings of the 8th World Conference on Artificial Intelligence in Education (AIED’97), Kobe, Japão, p.55-62, 1997.
[Dewan 1995] DEWAN, Prasun. Multiuser architectures. In: Proceedings of the IFIP TC2/WG2.7 Working Conference on Engineering for Human-Computer Interaction, p.247-270, 1995.
[Gaëlle 1997] CALVARY, Gaëlle; COUTAZ Joëlle; NIGAY, Laurence. From single-user architectural design to PAC*: A generic software architecture model for CSCW. In: Proceedings of the SIGCHI Conference on Human factors in computing systems, p.242-249, 1997.
[KatzenbachSmith1993] Katzenbach, Jon R., Smith, Douglas K., "The Wisdom of Teams", Small Business Reports, Jul 1993, http://web2.uqat.ca/marsanm/Readings/ch2%20The%20wisdom%20of%20teams.pdf
[Yann 2002] LAURILLAU, Yann; NIGAY, Laurence. Clover Architecture for Groupware. In: Proceedings of the 8th ACM Conference on Computer Supported Cooperative Work (CSCW'02), New Orleans, Lousiana, E.U.A., p.236-245, 2002.
[working-in-germany] http://www.working-in-germany.com/the-teamwork-0121.html (Acesso 9 de junho 2011)
[Prakash] Prakash, A., "Group Editors", Computer Supported Cooperative Work, 1999, John Wiley & Sons Ltd
[SCHROEDER 2010] SCHROEDER, R. Being There Together: Social Interaction in Shared Virtual Environments. Oxford University Press, 2010.
[Tuckman1965] Tuckman, Bruce, "Developmental sequence in small groups". Psychological Bulletin 63 (6): 384–99. doi:10.1037/h0022100. PMID 14314073, 1965
[JOHNSON-LENZ 1981] JOHNSON-LENZ, P.; JOHNSON-LENZ, T. Groupware: coining and defining it. ACM SIGGROUP Bulletin, v. 19, n. 3, p. 58, dez. 1998.
[stagesgroupdevelopment] http://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development]
[Vertegaal1997] Vertegaal, R., Velichkowsky, B., van der Veer, G, "Catching the Eye: Management of Joint Attention in Cooperative Work", SIGCHI Bulletin (29)4. ACM SIGCHI, 1997
Artigos:
Links:
Conferência da ACM sobre Colaboração Assistida por Computador
SBSC - Simpósio Brasileiro de Sistemas Colaborativos
Journal of Computer Supported Cooperative Work
O documentário Second Skin sobre mundos virtuais
Journal of Virtual Worlds Research
Conferência da ACM sobre CVE (ACM International Conference on Collaborative Virtual Environments)
Sistemas de colaboração
Teleduc (http://www.ead.unicamp.br/~teleduc/): Um aplicativo para ensino a distância desenvolvido pela Unicamp. É utilizado por muitos dos cursos de algumas faculdades públicas, como a Unesp Rio Claro, por exemplo.
Moodle É um aplicativo livre que pode ser usado por educadores para a criação de espaços virtuais para cursos e disciplinas. O IME tem uma instalação do Moodle chamada de PACA que é extensamente usada pelas disciplinas de computação.
Wikipedia enciclopedia livre com artigos criados e mudados pela comunidade
Redmine ferrameta para gerenciar projetos , documentar issues/bugs, planejar custo e auxiliar o desenvolvimento de projetos de software
[http://www.egroupware.org/] Plataforma Web que contém diversas ferramentas para trabalho em grupo (calendário, anotações, correio eletrônico, gerenciador de tarefas, planilhas de tempo, etc).
[www.opengroupware.org ] Suíte de ferramentas para comunicação de grupos que contém gerenciador de projeto, calendários, notas, chat e diversas outras funcionalidades para suportar a comunicação entre grupos de pessoas.
Simuladores:
Jogos:
Second Life Pode ser usado para reuniões virtuais e como espaço de encontro virtual. Existe até uma página na Wiki do Second Life dedicada a este propósito. Além disto, [De Lucia et al. 08] investiga como equipes podem trabalhar mais efetivamente usando o Second Life.
Everquest Um jovo MMORPG com temática medieval/futurista
Word of Warcraft O MMORPG com temática medieval mais popular da atualidade