Bruno Freitas Gadelha

Uma Abordagem de Desenvolvimento de Groupware

Baseada em Linha de Produto de Software e

Modelo 3C de Colaboração

Tese de Doutorado

Tese apresentada como requisito parcial para obtenção do título de Doutor pelo Programa de Pós-Graduação em Informática da PUC-Rio

Orientador: Professor Hugo Fuks

Rio de Janeiro

Dezembro de 2011

Bruno Freitas Gadelha

Uma Abordagem de Desenvolvimento de Groupware

Baseada em Linha de Produto de Software e

Modelo 3C de Colaboração

Tese apresentada como requisito parcial para obtenção do título de Doutor pelo Programa de Pós-Graduação em Informática da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada

Prof. Hugo Fuks Orientador

Departamento de Informática - PUC-Rio

Prof. Alberto Nogueira de Castro Jr. UFAM

Prof. Mariano Pimentel UNIRIO

Prof. Carlos Jose Pereira de Lucena Departamento de Informática - PUC-Rio

Prof. Alessandro Garcia

Departamento de Informática - PUC-Rio

Prof. José Eugenio Leal Coordenador(a) Setorial do Centro Técnico Científico - PUC-Rio

Rio de Janeiro, 21 de dezembro de 2011

Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador.

Bruno Freitas Gadelha

Bruno Freitas Gadelha iniciou seu doutorado no primeiro semestre de 2008 no Departamento de Informática da Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). É mestre em Informática (2006), pela Universidade Federal do Amazonas (UFAM), Bacharel em Ciência da Computação (2003), pela mesma universidade. Atua no Laboratório de Engenharia de Software. Tem interesse em desenvolvimento de groupware, learningware, linhas de produto de software e na construção e uso de Objetos de Aprendizagem.

Ficha Catalográfica

Gadelha, Bruno Freitas

Uma abordagem de desenvolvimento de

groupware baseada em linha de produto de software e

modelo 3C de colaboração / Bruno Freitas Gadelha;

orientador: Hugo Fuks. – 2011.

101 f. : il. (color.) ; 30 cm

Tese (doutorado)–Pontifícia Universidade

Católica do Rio de Janeiro, Departamento de Informática,

2011.

Inclui bibliografia

1. Informática – Teses. 2. Groupware. 3. Linhas de

produto de software. 4. Scripts de colaboração. I. Fuks,

Hugo. II. Pontifícia Universidade Católica do Rio de

Janeiro. Departamento de Informática. III. Título.

CDD: 004

À minha mãe, pelo apoio e confiança.

Agradecimentos

Ao meu orientador Hugo Fuks pelas horas dedicadas, estímulo e trabalho árduo

que excedendo suas funções de professor orientador, agiu como um verdadeiro

educador.

Ao professor Alberto Castro pela co-orientação informal, pelo apoio tanto na vida

acadêmica quanto pessoal, pelo debate de ideias e pela demonstração de

amizade em diferentes momentos do doutorado.

Aos professores Mariano Pimentel e Marco Aurélio Gerosa pelas dicas valiosas

durante o desenvolvimento desse trabalho.

Aos amigos do Groupware@LES Thaís Castro, Kátia Canepa, Débora Cardador

e Wallace Ugulino pela amizade e companheirismo durante a caminhada no

doutorado.

Ao CNPq e à PUC-Rio, pelo auxílio concedido, sem o qual o presente trabalho

não seria possível.

À Prefeitura Municipal de Manaus pelo apoio e por apostar na melhoria da minha

formação acadêmica e consequente melhoria profissional.

Resumo

Gadelha, Bruno Freitas; Fuks, Hugo. Uma Abordagem de Desenvolvimento de Groupware Baseada em Linha de Produto de Software e Modelo 3C de Colaboração. Rio de Janeiro, 2011. 101p. Tese de Doutorado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

Nesta tese investigou-se o desenvolvimento de software no contexto de

groupware, especificamente para apoiar a aprendizagem colaborativa. O

desenvolvimento de groupware, entretanto, não é trivial. Como todo software, há

aspectos tecnológicos e sociais envolvidos no desenvolvimento. Quanto aos

aspectos tecnológicos, o desenvolvimento de artefatos de infraestrutura ocupam

grande parte do esforço destinado à implementação dessas aplicações,

sobrando pouco tempo para a implementação de soluções inovadoras para as

questões da colaboração propriamente ditas. Com respeito aos aspectos sociais,

deve-se levar em conta que o trabalho em grupo é dinâmico e a composição dos

grupos, bem como suas características, se alteram com o passar do tempo.

Assim, desenvolveu-se uma linha de produtos de software para groupware

baseado no Modelo 3C de Colaboração, onde os groupware são derivados a

partir da formalização de técnicas de aprendizagem colaborativa em scripts de

colaboração. Foi desenvolvido um protótipo, o GroupwareBuilder para interpretar

o script de colaboração e derivar o groupware para suporte específico das suas

atividades. Uma avaliação funcional e um estudo de caso foram realizados. Na

avaliação funcional, buscou-se obter uma prova de conceito do

GroupwareBuilder, na qual dois groupware foram derivados para apoiar os

scripts de colaboração “Debate Crítico” e “Buzz Groups”. O estudo de caso foi

realizado para observar como se daria a derivação de groupware para técnicas

de aprendizagem colaborativa modeladas por diferentes professores. A principal

contribuição deste trabalho é uma abordagem que possibilita a derivação e

adaptação de groupware a partir de scripts de colaboração elaborados pelos

usuários e não a partir de uma lista de requisitos funcionais, como em LPS’s

tradicionais.

Palavras-chave

Groupware; linhas de produto de software; scripts de colaboração.

Abstract

Gadelha, Bruno Freitas; Fuks, Hugo (Advisor). An Approach for Groupware Development based on Software Product Lines and the 3C Collaboration Model. Rio de Janeiro, 2011. 101p. DSc. Thesis - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

In this thesis we explore software development on the context of

groupware, specifically on supporting collaborative learning. Groupware

development is not a trivial task given that technological and social issues are

involved. Considering the technological issues, a huge amount of time is wasted

on implementing infrastructure aspects leaving little time for implementation of

innovative solutions on collaboration. Considering the social issues, we should

take into account that group work is dynamic and that group composition

changes over time. So, we developed a software product line for groupware

based on the 3C Collaboration Model. The groupware derivation process starts

with the formalization of the collaborative learning techniques in collaboration

scripts. In order to support this collaboration process we developed the

GroupwareBuilder, that reads the collaboration script and derives groupware

tailored to the tasks described on the script. We made a functional evaluation and

a case study. On the functional evaluation, we aimed on getting a proof of

concept for GroupwareBuilder by deriving groupware for supporting the “Critical

Debate” and “Buzz Groups” collaboration scripts. In order to analyze how

GroupwareBuilder derives groupware from other collaborative learning

techniques described by different teachers we made a case study. The main

contribution of this thesis is an approach that enables the derivation of groupware

and the customization of groupware in runtime from collaboration scripts written

by the users, and not from a list of software requirements as used in other SPLs

approaches.

Keywords

Groupware; Software Product Lines; Collaboration Scripts.

Sumário

1 Introdução 13

1.1. Visão Geral da Pesquisa: Problema, Solução, Hipótese e Avaliação 16

1.2. Método de pesquisa: Estudo de Caso 17

1.3. Etapas da pesquisa 19

1.4. Estrutura da tese 19

2 Fundamentação Teórica 21

2.1. Linhas de Produto de Software (LPS) 21

2.2. Aprendizagem Colaborativa com Suporte Computacional 25

2.2.1. Scripts de Colaboração 26

2.3. BPMN – Business Process Model Notation 28

2.4. Groupware e Modelo 3C de Colaboração 31

2.4.1. RUP 3C-Groupware 32

2.4.2. Groupware Workbench 34

2.5. Desenvolvimento Dirigido por Modelos 35

2.6. Programação pelo usuário final 36

2.7. Trabalhos Relacionados 37

3 Linha de Produto Dinâmica para Groupware 40

3.1. Desenvolvimento das linhas de produto de serviços 42

3.1.1. Análise de Domínio 42

3.1.2. Projeto e implementação 43

3.2. Representando as Especificações do Designer 44

3.2.1. Representando Scripts de Colaboração com BPMN 45

3.2.2. Representando Requisitos de Sistema com BPMN 47

3.3. Linha de Produto para Groupware de Suporte a Aprendizagem

Colaborativa 48

3.3.1. Desenvolvendo o Serviço de Fórum de Discussões 50

3.3.2. Desenvolvendo o Serviço de Repositório de Arquivos 55

3.4. Derivação de produtos 60

4 Avaliação 63

4.1. Avaliação funcional da solução 63

4.1.1. Debate Crítico 64

4.1.2. Buzz Groups 69

4.2. Estudo de Caso 73

4.2.1. Protocolo para a realização do estudo de caso 73

4.2.2. Resultados obtidos 76

4.3. Discussão 86

5 Conclusão 90

5.1. Contribuições e Trabalhos Futuros 92

6 Referências bibliográficas 97

0

Lista de figuras

Figura 1. Objetos de fluxo BPMN [41]. ............................................................... 29

Figura 2. Objetos de conexão BPMN [41]. ......................................................... 30

Figura 3. Swimlanes BPMN [41]. ....................................................................... 30

Figura 4. Artefatos BPMN [41]. .......................................................................... 31

Figura 5. Modelo 3C de Colaboração [42]. ......................................................... 31

Figura 6. Fluxo Analisar Domínio do RUP 3C-Groupware [25]. .......................... 33

Figura 7. Modelo de Features 3C Genérico da Linha de Produtos para

Groupware ................................................................................................. 41

Figura 8. Exemplo de Modelo de Features 3C ................................................... 43

Figura 9. Resumo da abordagem de desenvolvimento das linhas de produto

de serviços. ................................................................................................ 44

Figura 10. Exemplo de representação de script de colaboração com BPMN. .... 46

Figura 11. Especificação de um serviço usando BPMN. .................................... 47

Figura 12. Modelo de Features 3C do serviço Fórum de Discussões ................ 52

Figura 13 Fórum PL – Modelo de Componentes UML para o serviço de

Fórum de Discussão. ................................................................................. 54

Figura 14. Fórum Descriptor File (parcial). ......................................................... 55

Figura 15. Modelo de Features 3C do serviço Repositório de Arquivos. ............ 57

Figura 16. Modelo de Componentes UML do serviço de repositório de

arquivos ..................................................................................................... 59

Figura 17. Repositório Descriptor File (parcial) .................................................. 59

Figura 18. Esquema de derivação de groupware com o GroupwareBuilder. ...... 61

Figura 19. Evolução da linha de produtos. ......................................................... 62

Figura 20. Script de Colaboração para a técnica Debate Crítico. Modelado

com o Bonita Open Studio. ........................................................................ 65

Figura 21. Tela de administração do groupware. Cadastro de tarefas. .............. 66

Figura 22. Tela de atribuição dos papéis aos usuários do groupware. ............... 67

Figura 23. Tela inicial do perfil de usuário do groupware. .................................. 67

Figura 24. Tela da atividade Debate Geral. ........................................................ 68

Figura 25. Script de Colaboração para a técnica Buzz Groups. Modelado

com o Bonita Open Studio. ........................................................................ 70

Figura 26. Tela de administração do Buzz Groups. Cadastro de Tarefas. ........ 71

1

Figura 27. Tela de atribuição dos grupos (papéis) aos usuários do

Buzz Groups. ............................................................................................. 72

Figura 28. Tela inicial do perfil de usuário do Buzz Groups................................ 72

Figura 29 - Protocolo para realização do estudo de caso. ................................. 73

Figura 30. Perfil dos participantes ...................................................................... 75

Figura 31. Familiaridade com conceitos da pesquisa ......................................... 76

Figura 32. Dificuldade de representação da técnica de aprendizagem

colaborativa ................................................................................................ 78

Figura 33. Adequação do groupware ao script de colaboração. ......................... 81

2

Lista de quadros

Tabela 1. Resumo dos requisitos funcionais do Versus, AVMJ e InGrupo. 49

Tabela 2. Quadro Conceitual 3C para o serviço de Fórum de Discussão. 51

Tabela 3. Links de rastreabilidade entre ações, features e CollabElements. 55

Tabela 4. Quadro Conceitual 3C para o serviço de Repositório de Arquivos 57

Tabela 5. Links de rastreabilidade entre ações, features e CollabElements. 60

1 Introdução

Nesse capítulo é apresentada uma visão geral da pesquisa realizada

acerca da derivação de groupware em uma linha de produtos de software a partir

de scripts de colaboração. Um script de colaboração é um cenário pedagógico a

ser seguido pelos estudantes quando estão envolvidos em uma situação de

aprendizagem colaborativa [1]. Uma linha de produto de software (LPS) é “um

conjunto de sistemas de software que compartilham características (features)

comuns e gerenciáveis que satisfazem necessidades específicas de um

segmento específico de mercado ou missão e que são desenvolvidos a partir de

um conjunto comum de artefatos de forma sistemática” [2].

A preocupação com a adequação entre o processo de colaboração e o

groupware usado para apoiar a realização do trabalho em grupo é presente na

literatura, bem como a adaptação do script de colaboração para adequar-se às

limitações do meio computacional [3-5]. A relevância da especificação de

groupware para um script de colaboração é reconhecida na literatura por meio

de abordagens especificamente projetadas para o desenvolvimento de

groupware a partir de processos de colaboração [6]. O desenvolvimento de

groupware, entretanto, não é trivial. Como todo software, há aspectos

tecnológicos e sociais envolvidos no desenvolvimento [7].

Quanto aos aspectos tecnológicos, o desenvolvimento de artefatos de

infraestrutura como protocolos, sincronismo e gerenciamento de sessão ocupam

grande parte do esforço destinado à implementação dessas aplicações,

sobrando pouco tempo para a implementação de soluções inovadoras [8] para

as questões da colaboração propriamente ditas. Além disso, há muitos serviços

comuns entre essas diferentes aplicações de groupware, como fóruns de

discussão, salas de chat, repositório de arquivos, dentre outras. Como

consequência da similaridade tecnológica e funcional entre aplicativos do tipo

groupware, é possível desenvolver um núcleo comum para essas aplicações, de

modo que as diferenças entre um groupware e outro sejam notadas em função

de aspectos funcionais relacionados com o trabalho em grupo que se pretende

realizar. A demanda de desenvolvimento dos aspectos tecnológicos comuns

entre uma família de aplicações tem sido explorada pelas LPS [2].

4

14

Com respeito aos aspectos sociais, deve-se levar em conta que o

trabalho em grupo é dinâmico e a composição dos grupos, bem como suas

características, se alteram com o passar do tempo. O grupo aprende, surgem

afinidades e conflitos entre os membros, pessoas entram e saem, o que acarreta

numa mudança contínua do grupo. A dinâmica de trabalho, os serviços

selecionados e a composição do ambiente de trabalho são fundamentais para

propiciar a colaboração [9]. Estes fatores são especialmente críticos no contexto

da aprendizagem colaborativa.

A aprendizagem colaborativa é um caso particular de trabalho em grupo

no qual o objetivo comum dos membros é aprender. As atividades de

aprendizagem são projetadas para serem executadas por pares ou pequenos

grupos de trabalho [10] em função da dificuldade de coordenação em grupos

maiores. Aprendizagem colaborativa é um tópico de interesse da comunidade

educacional que tenta adaptar o modelo educacional ao desenvolvimento da

sociedade.

Na sociedade industrial, esperava-se um trabalhador que realizasse

atividades repetitivas conforme a orientação de um chefe. Não se esperava a

comunicação entre os operários. Como reflexo desse cenário, as salas de aula

refletiam essa cultura, colocando o professor na posição de chefe e todos os

alunos (operários) voltados para o professor, inibindo dessa forma qualquer

comunicação que não seja com o chefe (professor).

Em contraste com o encontrado na sociedade industrial, na atual

sociedade espera-se muito mais colaboração entre os funcionários. Por

exemplo, médicos de diferentes especialidades se reúnem numa junta médica

para decidir como tratar do caso de um paciente específico. O projeto de

veículos, geralmente envolve profissionais de diferentes formações que devem

trabalhar juntos para a conclusão de um projeto inovador. Essa mudança no

perfil de trabalhador – que não ouve somente o chefe, mas discute e colabora

com seus pares – é demandada pela sociedade atual e é refletida na educação

por meio da adoção de um modelo onde o professor não simula somente o papel

de um chefe que transfere aos estudantes (operários) o conhecimento sobre

como executar uma tarefa repetitiva. Em vez disso, o professor atua como um

coordenador, um mediador, que lidera seus alunos divididos em grupos de

trabalho para a solução de problemas complexos. É papel desse professor-

mediador induzir a comunicação, a coordenação e a cooperação entre os

membros, além de preparar projetos de aprendizagem que cubram os

conhecimentos planejados no currículo do curso. A sala de aula, novamente, é

5

15

uma simulação da empresa, mas uma empresa na qual os funcionários tem mais

autonomia, aprendem por conta própria como resolver problemas complexos e

como trabalhar em grupo para atingir seus objetivos.

É papel do professor-mediador lidar com alguns problemas comuns que

ocorrem durante as atividades da aprendizagem colaborativa, tais como:

participação desigual nas atividades, resistência ao trabalho em grupo,

comportamento incompatível com as atividades, grupos que não se dão bem,

competição excessiva pela liderança do grupo, diferenças nos níveis de

habilidade, velocidades diferentes de trabalho entre os grupos de uma turma,

ausência de estudantes (faltas) e cópia de trabalhos (plágio) [10]. O professor,

mediador da aprendizagem, deve ter a sensibilidade para perceber a ocorrência

desses problemas e tomar alguma medida de correção como: mudar a formação

dos grupos ou adotar outra técnica de aprendizagem colaborativa mais

apropriada aos estudantes.

A aprendizagem colaborativa com suporte computacional (CSCL –

Computer-supported Collaborative Learning) é um ramo das ciências da

aprendizagem que estuda como as pessoas aprendem juntas com o auxílio

computacional [11]. Como resultado de pesquisas em CSCL, diversos groupware

foram desenvolvidos para dar suporte a alguma técnica de aprendizagem

colaborativa em particular. Por exemplo, o Versus [12] dá suporte a técnica

Controvérsia Acadêmica [13], o AVMJ [14] dá suporte a técnica JigSaw [15] e o

InGrupo [16] dá suporte a técnica Investigação em Grupo [17]. Todos esses

groupware foram especificamente projetados para apoiar a aplicação de uma

técnica específica de aprendizagem colaborativa. Todo o esforço relativo ao

levantamento de requisitos funcionais e desenvolvimento dos aspectos

tecnológicos comuns foi feito para cada sistema, sem haver um

reaproveitamento do que fora produzido anteriormente.

Nessa tese, investiga-se como derivar groupware a partir da formalização

da técnica de aprendizagem colaborativa em scripts de colaboração (por

exemplo, por meio da definição de processos em uma ferramenta de

modelagem) e do uso de Linhas de Produto de Software (LPS). O uso conjunto

de representação das técnicas de aprendizagem e de LPS foi a abordagem

escolhida para ser investigada nessa pesquisa, pois privilegia a adaptação de

software (derivação de um novo groupware) à forma como o professor quer

conduzir o trabalho com sua turma (definição do script de colaboração).

Em função da argumentação apresentada, considera-se que a dificuldade

de projetar e desenvolver groupware específico para uma técnica de trabalho em

6

16

grupo é um problema relevante o suficiente para justificar a pesquisa dessa tese.

Assim como a proposta dessa tese é considerada original, uma vez que não

foram encontrados trabalhos que produzam resultados semelhantes entre os

trabalhos correlatos listados na revisão de literatura realizada na Seção 2.7. O

restante desse capítulo é organizado da seguinte maneira: na Seção 1.1, é

apresentada uma visão geral da pesquisa. As etapas realizadas na pesquisa são

descritas na Seção 1.2. O método usado para essa pesquisa é argumentado e

justificado na Seção 1.3. Por fim, a organização da escrita da tese é apresentada

na Seção 1.4.

1.1. Visão Geral da Pesquisa: Problema, Solução, Hi pótese e Avaliação

A visão geral da pesquisa é apresentada a seguir:

• Teoria: Engenharia de Software aplicada ao desenvolvimento de groupware;

• Problema: A dificuldade de se obter um groupware adequado a uma técnica

de trabalho em grupo específica;

• Questão: Como diminuir a dificuldade do usuário em obter um groupware

adequado à uma técnica de trabalho em grupo?

• Solução proposta: Uma arquitetura baseada em LPS para derivação

automática de groupware específico para uma técnica de trabalho em grupo

formalizada como script de colaboração em uma linguagem previamente

definida.

• Hipótese: Se a arquitetura proposta for usada, então será possível derivar

um groupware adequado para a técnica de trabalho em grupo formalizada

pelo usuário.

• Avaliação: Prova de conceito (avaliação funcional) para investigar o

funcionamento da arquitetura quanto aos aspectos tecnológicos e Estudo de

Caso com participantes experientes em educação para avaliar a adequação

do groupware gerado para a técnica formalizada pelos participantes. Foi

desenvolvido um protótipo chamado “GroupwareBuilder” para apoiar a

avaliação realizada nessa pesquisa. Por meio do protótipo, planeja-se que os

processos formalizados pelos participantes sejam usados para derivar

groupware. Observação não participativa, onde não há interferência do

pesquisador observador, foi realizada durante a realização das tarefas

propostas no estudo de caso com os participantes. Os dados coletados na

observação são notas textuais, vídeos e áudio, conforme a autorização dos

7

17

usuários e recursos disponíveis. Outros dados coletados são respostas dos

participantes ao questionário da pesquisa, os groupware gerados e as

técnicas de aprendizagem formalizadas.

• Falseabilidade: A hipótese será refutada se o groupware derivado por meio

da arquitetura proposta não refletir adequadamente a técnica formalizada

pelos usuários. A hipótese será confirmada se os groupware refletirem

adequadamente a técnica modelada pelos usuários. É possível que a

hipótese não seja nem confirmada e nem refutada se nenhum participante

conseguir modelar uma técnica de aprendizagem, pois não será possível

avaliar a adequabilidade do groupware à técnica. Nesse caso, será preciso

analisar as escolhas de projeto feitas na tese, especialmente com relação à

linguagem escolhida para representação da técnica de aprendizagem

colaborativa.

1.2.Método de pesquisa: Estudo de Caso

Estudo de caso é um método empírico considerado adequado para

investigar fenômenos num contexto específico [18]. Nessa pesquisa, o fenômeno

investigado é a dificuldade inerente ao desenvolvimento de software, que é um

trabalho artesanal, para o qual levantam-se requisitos – por meio de entrevistas,

questionários, e outros instrumentos – e realiza-se o projeto, desenvolvimento,

teste e implantação do software. O contexto dessa pesquisa é o

desenvolvimento de groupware especificamente para dar suporte à técnicas de

aprendizagem colaborativa (o contexto é definido de forma ainda mais específica

em função do perfil dos participantes, experiência com colaboração apoiada por

computador, etc.).

Estudo de caso é recomendado, especialmente, quando as fronteiras

entre fenômeno e o contexto não são evidentes. Na presente pesquisa, não são

evidentes quais são os fatores do contexto que efetivamente influenciam no

desenvolvimento de groupware (contexto) em contraste com o desenvolvimento

de software tradicional (fenômeno), embora a diferença seja reconhecida pela

grande quantidade de referências na literatura de autores atacando o problema

de desenvolver groupware específico para uma técnica de aprendizagem

colaborativa, como os citados anteriormente. Uma fronteira que se destaca entre

o desenvolvimento de groupware e software tradicional, é que o

desenvolvimento de groupware requer a análise da colaboração entre os

participantes e não somente da interação do usuário com o sistema.

8

18

Outra recomendação para uso de estudo de caso é quando a pesquisa

requer o uso de diferentes tipos de dados, como objetivo-quantitativo e,

principalmente, qualitativos. O uso de dados objetivo-quantitativos e a

investigação de hipóteses são características de um estudo de caso que se

assemelham à experimentação [19, 20]. Apesar da semelhança, o método dessa

pesquisa não é experimentação porque nem todas as variáveis estão definidas e

controladas e, dessa forma, não é possível garantir que sempre serão obtidos os

mesmos resultados entre semelhantes estudos de caso, enquanto a

reprodutibilidade é uma qualidade esperada de um experimento. Nessa

pesquisa, não se pode controlar, por exemplo, como os usuários vão abstrair a

técnica de aprendizagem colaborativa na forma de representação gráfica, como

também não se pode controlar o julgamento subjetivo dos usuários com relação

à adequação do groupware à técnica formalizada. Um item relevante que é

parcialmente controlado nesse estudo é o grau de experiência em informática e

conhecimento e interesse sobre a aprendizagem colaborativa, item para o qual

foram coletadas medidas subjetivas, na forma de resposta dos participantes às

perguntas fechadas do questionário de pesquisa. Não é possível caracterizar

todas as variáveis que precisariam estar controladas como requerido no método

experimentação.

O alto grau de controle da experimentação pressupõe o uso de um

laboratório em situações artificiais para a realização de experimentos, enquanto

na pesquisa aqui apresentada são investigadas situações reais de projetos de

aprendizagem formalizados por professores. A escolha de estudo de caso em

detrimento da experimentação é também uma escolha do realismo em

detrimento da facilidade de generalização obtida quando se tem um ambiente

controlado e artificial. Outra importante característica desse estudo que o

classifica como estudo de caso é o uso de diferentes tipos de dados: tanto

quantitativos como qualitativos. Experimentação focaliza apenas variáveis

quantitativas, enquanto estudo de caso interessa-se também por dados e

análises qualitativas tal como as declarações dos participantes sobre a

adequação do groupware à técnica modelada. Todos estes fatores – o baixo

grau de controle das variáveis, a presença de dados e análises qualitativas, e a

investigação em contextos reais – distanciam experimentação do método estudo

de caso usado na pesquisa apresentada nessa tese.

9

19

1.3.Etapas da pesquisa

As etapas dessa pesquisa são listadas a seguir:

(1) O sistema FLOCOS, um repositório de objetos de aprendizagem com o

registro da cooperação dos usuários de cada objeto de aprendizagem, foi

desenvolvido e comunicado em artigos [21]; A partir do desenvolvimento do

FLOCOS, foi possível perceber a dificuldade específica do desenvolvimento

de groupware, que é a necessidade da análise da interação entre os

participantes, ao invés de analisar somente questões de usabilidade e

interação do usuário com o sistema;

(2) Uma revisão da literatura foi realizada para investigar a dificuldade de

desenvolvimento de groupware e está registrada em seções dessa tese;

(3) Um segundo protótipo de groupware foi desenvolvido – e comunicado em um

artigo [22] – para explorar o uso de LPS na derivação de groupware baseado

no Modelo 3C, uma vez que esse modelo é usado na análise da

colaboração. Uma das contribuições dessa etapa de pesquisa foi a

adaptação do modelo de features para acomodar o Modelo 3C e,

consequentemente, características da colaboração na LPS;

(4) Na quarta etapa, a evolução da pesquisa – comunicada nos artigos [23, 24] –

foi usar o conhecimento acumulado sobre o desenvolvimento de groupware:

anexou-se o modelo RUP 3C-Groupware para desenvolvimento [25] e a

bancada de componentes para desenvolvimento de groupware (Groupware

Workbench [26]);

(5) A quinta etapa consistiu em generalizar o conhecimento adquirido nas etapas

anteriores na forma de uma arquitetura de LPS para derivação de groupware

a partir da formalização de técnicas de aprendizagem colaborativa.

1.4. Estrutura da tese

No Capítulo 2 é realizada uma revisão da literatura, onde são descritos os

conceitos que embasam o desenvolvimento da pesquisa desta tese. São

apresentados os conceitos de linhas de produtos de software, aprendizagem

colaborativa e scripts de colaboração, o Modelo 3C de Colaboração,

desenvolvimento dirigido por modelos e programação pelo usuário final. Por fim,

são apresentados os trabalhos correlatos a esta pesquisa.

No Capítulo 3 a proposta de arquitetura para a derivação de groupware em

linhas de produtos de software a partir de scripts de colaboração é apresentada.

0

20

O capítulo apresenta a abordagem de forma geral e exemplifica a abordagem

apresentando o desenvolvimento de uma linha de produtos para groupware de

suporte à aprendizagem colaborativa.

No capítulo 4, é apresentada a avaliação da proposta desta tese. Essa

avaliação é realizada em duas etapas: (1) avaliação funcional da arquitetura, que

consiste em uma prova de conceito para mostrar que a linha de produtos

desenvolvida é capaz de gerar groupware adequado à uma técnica de

aprendizagem colaborativa e, (2) estudo de caso com o objetivo de verificar

como se dá a geração de groupware a partir de scripts de colaboração definidos

por professores. Ao fim do capítulo, é apresentada uma discussão.

Por fim, no Capítulo 5 são apresentadas as conclusões e contribuições

dessa pesquisa. O capítulo descreve, ainda, possíveis desdobramentos dessa

pesquisa para diferentes comunidades científicas.

2 Fundamentação Teórica

Este capítulo apresenta os conceitos que fundamentam essa pesquisa. A

Seção 2.1 conceitua linhas de produto de software e aponta os benefícios de sua

adoção. Na Seção 2.2, é apresentado o conceito de aprendizagem colaborativa

com suporte computacional, além de conceituar scripts de colaboração e

descrever o framework para a criação de scripts usado nessa tese. Em seguida,

na Seção 2.3 são apresentados os elementos que constituem a BPMN, que foi

usada para representar os scripts de colaboração. A Seção 2.4 apresenta o

Modelo 3C de Colaboração e seus recursos para o desenvolvimento de

groupware, o RUP 3C-Groupware e o Groupware Workbench. A Seção 2.5

define o conceito de desenvolvimento dirigido por modelos usando (Model Driven

Development – MDD) na implementação do protótipo desenvolvido nesta tese. A

Seção 2.6 define End-user programming, conceito usado em conjunto com o

MDD que permite com que o usuário final do protótipo possa derivar seu próprio

groupware a partir da LPS descrita nessa tese. Por fim, na Seção 2.7 são

apresentados trabalhos relacionados a essa pesquisa.

2.1. Linhas de Produto de Software (LPS)

Uma linha de produto de software (LPS) é um conjunto de sistemas

computacionais compartilhando um conjunto de características comuns,

gerenciáveis que satisfazem as necessidades específicas de um segmento de

mercado particular (família de software) e que são desenvolvidos a partir de um

conjunto comum de artefatos de forma sistemática [2].

As LPS objetivam prover, a custos reduzidos, software customizados. A

adoção das LPS provê benefícios [27], tais como:

• Customização em massa. Consiste na produção em larga escala de

software adaptado às necessidades individuais dos usuários.

• Tempo de entrega reduzido. Apesar do tempo de entrega de produtos

derivados de LPS ser inicialmente alto, devido ao esforço inicial no

desenvolvimento dos artefatos comuns que farão parte do núcleo da LPS,

2

22

esse tempo é reduzido com o reuso desses artefatos para entrega de novos

produtos.

• Baixo custo de desenvolvimento. Da mesma maneira que o tempo de

entrega, o custo inicial do desenvolvimento de LPS é alto (investimento

inicial), porém o autor argumenta que o investimento inicial é justificado a

partir da entrega do terceiro produto da LPS aproximadamente.

• Melhoria na qualidade dos produtos. Os artefatos da LPS são revistos e

testados em diversos produtos, e precisam funcionar bem em todos eles.

Esses testes intensivos implicam em uma chance maior de detectar e corrigir

eventuais problemas, aumentando assim a qualidade de todos os produtos

da linha.

Os benefícios da adoção de LPS identificados são conseqüência do reuso

intensivo e sistemático de software. Os produtos são desenvolvidos a partir de

um conjunto de artefatos de software de forma sistemática, em contraste com o

desenvolvimento individual de software, a partir do zero, ou através do reuso de

software de forma arbitrária [2]. Destaca-se, porém, que a abordagem de LPS

pode ser confundida com outras abordagens no desenvolvimento de software [2,

28], tais como:

• Reuso fortuito de pequena granularidade. Essa abordagem trata do reuso

de pequenos pedaços de software geralmente escritos em bibliotecas de

funções, módulos, objetos ou pequenos componentes. Na abordagem de

LPS, o reuso é planejado, possibilitado e forçado, ao contrário do reuso

oportunístico. A base de artefatos inclui aqueles que possuem o maior custo

de desenvolvimento no caso de sistemas desenvolvidos isoladamente. Esses

artefatos são projetados para serem reusados em mais diversos sistemas.

• Desenvolvimento de software individual com reuso. Essa abordagem

trata do reuso oportunístico no desenvolvimento de software. No

desenvolvimento individual de software, é comum que o desenvolvedor já

tenha desenvolvido soluções semelhantes que podem ser aplicadas ao novo

software em desenvolvimento. Nesse caso, o desenvolvedor geralmente

“copia e cola”, se apropriando do conhecimento adquirido em experiências

anteriores de desenvolvimento. Como resultado tem-se sistemas totalmente

diferentes e não sistemas construídos a partir da mesma base. Em LPS, os

artefatos são projetados explicitamente para o reuso, e a linha de produtos é

tratada como um todo, não como vários produtos que são vistos e mantidos

separadamente. Cada produto é simplesmente resultado da composição e

adequação dos artefatos do núcleo da linha de produtos e de,

3

23

eventualmente, uma pequena coleção de artefatos adicionais exclusivos para

esse produto.

• Apenas desenvolvimento baseado em componentes ou se rviços.

Embora os produtos nas LPS sejam desenvolvidos através da composição

de componentes, alguns dos quais podem ser também Web Services, todos

esses componentes devem ser especificados pela arquitetura de linha de

produtos. Além disso, os componentes são montados de forma prescrita, o

que inclui embutir mecanismos de variação nos componentes para usá-los

em produtos específicos. Em uma linha de produtos, a forma genérica do

componente é desenvolvida e mantida na base de artefatos essenciais

(núcleo da linha de produtos). No caso do desenvolvimento baseado em

componentes, se houver necessidade de alguma variação no produto, isso

implica em escrever mais código, e essas variações geralmente são

mantidas separadamente. No desenvolvimento baseado em componentes

falta, também, os aspectos de gestão técnica e organizacional que são tão

importantes para o sucesso de um produto de software. Nesta pesquisa, foi

usado o desenvolvimento baseado em componentes para a implementação

dos artefatos da linha de produtos, conforme descrito no Capítulo 3.

• Apenas uma arquitetura reconfigurável. Arquiteturas de referência e

frameworks são projetados para serem reusados em múltiplos sistemas e, se

necessário, serem reconfigurados. Reusar estruturas de arquitetura de

software é apropriado visto que é uma parte essencial de qualquer sistema,

além de ter um alto custo de desenvolvimento. Uma arquitetura de LPS é

projetada para dar suporte à variação necessária para os produtos da linha

de produtos, assim torná-la reconfigurável é desejável. No entanto, a

arquitetura da LPS é apenas um artefato, embora importante, no núcleo da

linha de produtos.

• Releases e versões de produtos individuais. Uma LPS gera vários

produtos ao mesmo tempo, todos esses produtos passam por seus próprios

ciclos de lançamento e controle de versões simultaneamente. Assim, a

evolução de um único produto deve ser considerada dentro de um contexto

mais amplo, ou seja, a evolução da LPS como um todo. No contexto de

produtos individuais, uma vez que é lançada uma nova versão, as versões

anteriores perdem seu valor e são descartadas. Mas em uma LPS uma

versão anterior de um produto, que ainda é considerado com potencial de

mercado, é mantida como um membro viável da família de produtos, dado

4

24

que consiste em uma instância de artefatos do núcleo da linha de produtos,

assim como outras versões de outros produtos.

• Apenas um conjunto de normas técnicas. Muitas organizações adotam

um conjunto de normas técnicas para limitar as escolhas de seus

desenvolvedores de software no que diz respeito aos tipos e fontes dos

componentes a serem usados nos sistemas que desenvolvem. Essas

normas consistem em restrições para promover a interoperabilidade e reduzir

os custos associados à manutenção e suporte de componentes comerciais.

No entanto, essas normas são simplesmente restrições impostas às LPS.

Na engenharia de linhas de produtos de software são identificadas duas

atividades principais:

• Engenharia de domínio , que consiste na definição dos aspectos comuns e

variáveis das LPS, na realização desses aspectos em artefatos de software e

a definição dos links de rastreabilidade entre esses artefatos. Os links de

rastreabilidade facilitam o reuso sistemático e consistente dos artefatos de

software.

• Engenharia de aplicação que tem por objetivo realizar a derivação dos

produtos de software através do reuso dos artefatos produzidos na atividade

de engenharia de domínio, explorando a variabilidade definida para a LPS.

Essa pesquisa engloba essas duas atividades. A atividade de engenharia

de domínio é realizada na definição da abordagem para o desenvolvimento das

LPS de serviços descrita na Seção 3.1 desta tese. A atividade de engenharia de

aplicação é realizada através da abordagem de derivação de produtos a partir

dos scripts de colaboração que é apresentada na Seção 3.4 desta tese.

A principal atividade da engenharia de domínio consiste na identificação

dos aspectos comuns e variáveis entre os membros de uma família de software.

Essa variabilidade é descrita em termos de features que são definidas como

“uma propriedade do sistema que é relevante para algumas das partes

interessadas e é usada para capturar ou discriminar semelhanças entre os

produtos em SPL” [29].

Após identificadas, as features são então organizadas em um modelo de

features (feature modelling). Essa atividade, além de identificar as features

comuns e variáveis da LPS, captura também suas interdependências. Foi

originalmente proposta pelo método Feature Oriented Domain Analysis (FODA)

[30] e tem sido usada em várias abordagens de SPL.

O suporte à variabilidade é alcançado, tendo em conta a modularização

das features e adotando técnicas para promovê-la. O principal benefício de se

5

25

ter features modularizadas é possibilitar que uma feature seja incluída ou

removida da LPS viabilizando a derivação sistemática de produtos e,

consequentemente, reduzindo o tempo e custos do processo de derivação na

atividade de engenharia de domínio. Diferentes técnicas de desenvolvimento de

software podem ser usadas para modularizar features [31] como, por exemplo,

polimorfismo, design patterns, frameworks, componentização, compilação

condicional e programação orientada a aspectos.

De acordo com Galster [32], a variabilidade acontece em diferentes fases

no ciclo de vida do software como, por exemplo, na fase de projeto do software,

chamada variabilidade de projeto (design time variability), e em tempo de

execução, chamada variabilidade em tempo de execução (runtime variability). As

fontes para a variabilidade tanto de projeto quanto de execução são tanto

mudanças nos requisitos ou propagação de modificações em diferentes níveis

(nível de negócio ou de processo, por exemplo) quanto à necessidade de

responder a situações de erros.

As LPS tradicionais tratam da variabilidade em tempo de projeto, onde as

possíveis variações são previstas, modeladas e implementadas durante o projeto

da LPS. Para tratar da variabilidade em tempo de execução, a literatura aponta o

conceito de linhas de produtos de software dinâmicas (DSPL – Dynamic

Software Product Lines). DSPL é definida por Burégio et. al. [33] como uma

“estratégia promissora para lidar com projeto e implementação de mudanças que

devem ser realizadas em tempo de execução em aplicações de domínios

emergentes”, uma vez que produz software capaz de se adaptar a mudanças

nas necessidades dos usuários em tempo de execução.

A adaptação de software em tempo de execução é uma característica

desejável no contexto de groupware, dado que o trabalho colaborativo é

dinâmico, o que exige maior flexibilidade dos serviços para se adaptar a

mudanças nos requisitos de colaboração. Os requisitos de colaboração nessa

pesquisa são formalizados em scripts de colaboração. O uso desses scripts tem

sido explorado em pesquisas na área da aprendizagem colaborativa com suporte

computacional (CSCL – Computer-supported collaborative learning).

2.2.Aprendizagem Colaborativa com Suporte Computaci onal

A aprendizagem colaborativa refere-se a atividades de aprendizagem

explicitamente projetadas e executadas por pares ou pequenos grupos de

estudantes para atingir objetivos de aprendizagem comuns [10].

6

26

A motivação para a investigação da aprendizagem colaborativa se dá pelo

fato das pessoas aprenderem muito umas com as outras. Essa aprendizagem

acontece de diferentes maneiras: resolvendo problemas em conjunto, obtendo

informações sobre problemas já resolvidos, explicando soluções para problemas,

debatendo sobre vantagens e desvantagens de uma determinada escolha,

fazendo ou recebendo críticas, dentre outras atividades em grupo [34].

A estruturação da aprendizagem colaborativa ocorre a partir dos seguintes

princípios [34]: (1) os estudantes trabalham juntos com o objetivo comum do

aprendizado e; (2) os estudantes são responsáveis tanto pela sua própria

aprendizagem quanto pela aprendizagem dos demais. Isso implica no

estabelecimento de metas coletivas que, quanto melhor atendidas, maiores são

as possibilidades de aprendizagem de cada estudante sobre o assunto

estudado.

A aprendizagem colaborativa é praticada por educadores nos diversos

níveis escolares, do ensino fundamental à pós-graduação [34] e em diversas

situações de educação, desde a formal, nas escolas à informal, como no caso de

museus [11]. O suporte computacional para essas atividades é resultado de

avanços na área de Aprendizagem Colaborativa com Suporte Computacional

(CSCL).

Essa pesquisa contribui para a área de CSCL dado que objetiva prover um

ambiente de suporte computacional adequado a técnicas de colaboração

descritas em scripts de colaboração. Os scripts são usados na transposição das

técnicas de aprendizagem colaborativas para contextos mediados por

computador [35]. A próxima seção detalha o conceito de scripts de colaboração.

2.2.1.Scripts de Colaboração

Um script de colaboração consiste em um cenário pedagógico a ser

seguido pelos estudantes envolvidos em um ambiente de aprendizagem

colaborativa [1]. Scripts de colaboração estruturam o processo interativo entre

dois ou mais estudantes propiciando a colaboração através da especificação de

uma sequência de atividades de aprendizagem em conjunto com funções

(papéis) apropriadas para os estudantes, a fim de provocar o envolvimento em

atividades sociais e cognitivas que de outra forma não ocorreria [35, 36].

Pesquisas em scripts de colaboração [37, 1, 35] diferenciam dois tipos de

scripts:

7

27

• Micro-scripts são modelos de diálogos, geralmente modelos de

argumentação, que são embutidos no ambiente computacional e que os

estudantes devem adotar e progressivamente internalizar, por exemplo:

inícios de sentenças, perguntas ou descrições detalhadas de atividades.

• Macro-scripts são modelos pedagógicos focados na organização e

estruturação da atividade colaborativa. Eles estruturam a interação

enfatizando a sequência de atividades que devem ser realizadas pelos

estudantes.

Essa pesquisa foca nos macro-scripts para guiar o processo de derivação

de groupware pois informam em alto nível como as pessoas deverão interagir no

groupware.

Não há, até o momento dessa pesquisa, uma padronização na descrição

de cenários pedagógicos para a o uso combinado com tecnologias

computacionais. A Open University of the Netherlands (OUNL) desenvolveu uma

linguagem, a IMS Learning Desin (IMS-LD), que foi projetada para possibilitar a

descrição de diferentes práticas pedagógicas [38]. No entanto, a linguagem

carece de software de suporte, o que dificulta seu uso por pessoas com

conhecimentos limitados em computação.

A falta de padronização dos scripts de colaboração levou ao

desenvolvimento do framework genérico [35] usado nessa pesquisa para

determinar a linguagem de especificação desses scripts. Esse framework usa

um pequeno número de componentes e mecanismos que são descritos a seguir:

• Componentes. Compreendem os indivíduos que participam em um script de

colaboração, as atividades que eles realizam, os papéis que assumem, o

recurso que usam e os grupos que forma.

o Participantes . Em geral indica o número de participantes que um

script deve ter, por exemplo: três a oito participantes. Pode-se

também levar em consideração a opinião ou conhecimento em um

domínio, por exemplo participantes com opiniões divergentes.

o Atividades . Indica as atividades que os participantes devem executar

no script.

o Papéis . Refere-se a participantes específicos para os quais

atividades devem ser atribuídas e recursos devem ser alocados.

Também se pode associar participantes com privilégios, obrigações e

expectativas.

o Recursos . Compreende objetos virtuais ou físicos que podem

oferecer uma informação ou funcionalidade importante. Em geral, é

8

28

associado a participantes, mas também podem ser associados a

atividades.

o Grupos . Participantes podem ser agrupados para executar as

atividades definidas no script. Os critérios para a formação de grupos

são diversos como, por exemplo, gênero, faixa etária ou apenas

grupos aleatórios para alcançar a quantidade de participantes

necessária para as atividades.

• Mecanismos . Descrevem a natureza distribuída dos scripts através da

definição de atributos como:

o Distribuição de tarefas . Descreve como as atividades, os papéis e

recursos são distribuídos entre os participantes.

o Formação de grupos . Descreve como participantes são distribuídos

entre os grupos.

o Sequenciamento . Descreve como componentes e grupos estão

distribuídos através do tempo.

Dado que os scripts de colaboração estruturam o fluxo das atividades

colaborativas, os grupos e os papéis envolvidos nessas atividades, nessa

pesquisa propôs-se o uso do Business Process Modeling Notation (BPMN) para

descrevê-los. A próxima seção apresenta o BPMN e seus principais elementos.

2.3.BPMN – Business Process Model Notation

Business Process Modeling Notation (BPMN) [39] é uma notação para

modelar processos de negócios especificada pela Object Management Group

(OMG [40]). Foi desenvolvida para prover uma notação que pudesse ser

entendida por diferentes tipos de usuários, desde analistas de negócios, que

criam as versões inciais do processo, a desenvolvedores responsáveis pela

tecnologia de suporte a tais processos, além dos usuários responsáveis pelo

gerenciamento do processo. BPMN cria uma ligação padrão entre o projeto de

processos de negócio e a implementação desses processos.

BPMN define um diagrama de processo de negócios (Business Process

Diagram – BPD), que é baseado na técnica de fluxograma adaptada para a

criação de modelos gráficos de operações de processos de negócios. Um

modelo de processos de negócio, então, consiste numa rede de objetos gráficos

que são atividades e fluxos de controle que define a ordem de execução das

atividades [41]. Os elementos do BPD são divididos em 4 categorias:

9

29

• Objetos de fluxo. Um BPD conta com três elementos para representar os

objetos de fluxo que são:

o Evento (event). Um evento é representado por um círculo e

representa algo que “acontece” durante o andamento de um processo

de negócio. Esses eventos afetam o fluxo dos processos e

geralmente têm uma causa ou um impacto. Existem três tipos de

eventos, baseados em quando eles afetam o fluxo: início,

intermediário e fim, representados respectivamente na Figura 1(a).

o Atividade (activity). Uma atividade é representada por um retângulo

com cantos arredondados e é um termo genérico para o trabalho que

a companhia executa. Uma atividade pode ser atômica ou composta.

Os tipos de atividade são: tarefas e subprocessos. O subprocesso é

identificado por um sinal de soma “+” centralizado na parte inferior da

forma. A atividade é representada na Figura 1 (b).

o Gateway. Um gateway é representado por um losango e é usado

para controlar a divergência e convergência da sequência de fluxo.

Figura 1. Objetos de fluxo BPMN [41].

• Objetos de conexão. Os objetos de fluxo são interligados para criar a

estrutura do processo de negócio, para tanto, existem três objetos de

conexão representados pela Figura 2 e descritos abaixo:

o Fluxo de sequência (sequence flow). Um fluxo de sequência é

representado por uma seta sólida direcionada e é usada para ordenar

as atividades a serem executadas no processo.

o Fluxo de mensagem (sequence message). Um fluxo de mensagem

é representado pela seta entrecortada direcional e é usada para

mostrar o fluxo das mensagens entre dois processos participantes.

o Associação (association). Uma associação é representada por uma

seta pontilhada direcionada e é usada para associar dados, textos e

outros artefatos com objetos de fluxo. Associações são usadas para

ilustrar as entradas e saídas das atividades.

0

30

Figura 2. Objetos de conexão BPMN [41].

• Swimlanes. Diversos processos usam o conceito de swimlanes como um

mecanismo para organizar atividades em categorias visualmente separadas

para ilustrar diferentes possibilidades funcionais ou responsabilidades. As

swimlanes estão ilustradas na Figura 3. São dois tipos de estruturas:

o Pools. Uma pool representa um participante em um processo.

Também atua como um container gráfico para dividir o conjunto de

atividades de outras pools.

o Lanes. Uma lane é uma partição dentro de uma pool e ocupa a

largura inteira da pool. Lanes são usadas para organizar e categorizar

atividades.

Figura 3. Swimlanes BPMN [41].

• Artefatos. Os artefatos podem ser adicionados ao diagrama de acordo com

a necessidade do processo que está sendo modelado (Figura 4). São três os

elementos para representar artefatos:

o Objetos de dados (data objects). Objetos de dados são

mecanismos para ilustrar como o dado é requerido ou produzido

pelas atividades. Eles são conectados a atividades por associações.

o Grupo (group). Um grupo é representado por um retângulo com

cantos arredondados desenhado com linha pontilhada. O

agrupamento pode ser usado com o propósito de documentação ou

análise e não afeta o fluxo de sequência.

o Anotação (annotation). Anotações são mecanismos para prover

informação textual adicional ao leitor de um diagrama BPMN.

1

31

Figura 4. Artefatos BPMN [41].

Conforme dito anteriormente, nessa pesquisa, o BPMN foi usado como

base para definir os scripts de colaboração. Nem todos os elementos descritos

acima foram utilizados. Outros tiveram seus significados alterados para uma

maior aderência ao framework de elaboração de scripts de colaboração usado. A

Seção 3.2 detalha como os scripts de colaboração devem ser escritos com os

elementos do BPMN. Esses scripts servem de fonte para a derivação de

groupware na LPS desenvolvida que diferencia-se das demais LPS pela análise

da colaboração através do Modelo 3C de Colaboração.

2.4.Groupware e Modelo 3C de Colaboração

A colaboração nesta pesquisa é analisada de acordo com o Modelo 3C

ilustrado pela Figura 5, que considera que esta é alcançada através da interação

entre a comunicação, coordenação e cooperação.

Durante a comunicação ocorre uma troca de mensagens objetivando

futura ação comum. Coordenação trata das pessoas e suas interdependências

necessárias para o cumprimento do plano de ação acordado. Cooperação

compreende as ações tomadas pelos membros do grupo no espaço

compartilhado.

Comunicação

CoordenaçãoCooperação

gera compromissos gerenciados pela

organiza as tarefas para

demanda

comum + ação

Ação de tornar comum

co + ordem + ação

Ação de organizar em conjuntoco + operar + ação

Ação de operar em conjunto

Figura 5. Modelo 3C de Colaboração [42].

2

32

Para dar suporte à comunicação, Fuks et. al [42] afirma que o projetista

das ferramentas de comunicação define os elementos de comunicação que, por

sua vez, definem o canal de comunicação entre os interlocutores como

propósito, dinâmica, tempo e espaço. De acordo com as necessidades do grupo,

aspectos como privacidade e sobrecarga de informação são levados em

consideração.

Se o objetivo for coordenar pessoas, o foco da coordenação deve ser as

ferramentas que provêm agenda e contexto. Coordenar recursos está

relacionado ao espaço compartilhado, onde as ações acontecem. Coordenar

tarefas consiste em gerenciar interdependências entre tarefas que devem ser

executadas para atingir o objetivo do grupo. Então, o projetista deve considerar

esses diferentes aspectos da coordenação ao projetar ferramentas.

Para dar suporte à cooperação, o projetista deve configurar o espaço

compartilhado onde as ações irão acontecer. Um conjunto de ferramentas para

armazenamento e manutenção de artefatos (documentos, planilhas,

apresentações e outros) deve ser oferecido.

Apesar de parecerem independentes, os “C”s possuem um intra-

relacionamento [43]. Por exemplo, em uma ferramenta cujo propósito é a

comunicação, como no caso de um fórum de discussão, é possível verificar os

outros “C”s do modelo. Usuários em um fórum postam mensagens que estão

disponíveis a outros (cooperação) e existe uma lista de participantes

(coordenação).

2.4.1.RUP 3C-Groupware

RUP-3C-Groupware [25] consiste numa extensão e especificação do

Rational Unified Process que tem por objetivo documentar como o Modelo 3C de

Colaboração é sistematicamente usado nas diferentes etapas de um processo

de desenvolvimento de groupware. O RUP 3C-Groupware se aplica neste

trabalho na etapa de análise de domínio da linha de produto, para a classificação

dos produtos de groupware resultantes e seus elementos. Os procedimentos

para realizar a análise de domínio são documentados pelo fluxo “Analisar

Domínio” do RUP 3C-Groupware, conforme esquematizado na Figura 6.

De acordo o fluxo, cabe ao Analista de Domínio analisar diferentes

aplicações do domínio para o qual o novo groupware está sendo desenvolvido.

O analista estabelece comparações entre as aplicações para identificar e abstrair

os elementos de comunicação, coordenação e cooperação do domínio. Como

3

33

resultado desta atividade, objetiva-se construir um Quadro Conceitual 3C do

domínio, ou aperfeiçoar algum já existente. Ao analisar as aplicações do

domínio, devem-se documentar as principais funcionalidades classificando-as de

acordo com o Quadro Conceitual 3C. O analista também deve caracterizar o que

é uma aplicação típica daquele domínio, identificando o conjunto mais relevante

de elementos. Isto consistirá no núcleo da linha de produto de aplicações do

domínio, a partir do qual novas características poderão ser adicionadas aos

diferentes produtos derivados da linha de produtos.

Figura 6. Fluxo Analisar Domínio do RUP 3C-Groupwar e [25].

Alguns problemas e soluções do domínio já podem ser conhecidos e

devem estar documentados num repositório, tornando-se útil para auxiliar o

analista na seleção ou especificação de uma variação de solução já conhecida

em outras aplicações. Deve-se, ainda, contar com um Analista de Modelo 3C

que será responsável pelo uso consistente do modelo ao longo do processo de

desenvolvimento.

4

34

2.4.2.Groupware Workbench

Groupware Workbench (GW) é uma bancada baseada em componentes

para o desenvolvimento de sistemas colaborativos. A bancada oferece aos

engenheiros de software uma infraestrutura componentizada específica para o

domínio de groupware baseados no Modelo 3C de Colaboração para

instrumentar a construção e manutenção de sistemas colaborativos extensíveis e

adaptáveis. Assim, os engenheiros de software lidam com o projeto da

colaboração em um alto nível [44].

A maioria dos groupware provê um conjunto comum de serviços

colaborativos a seus usuários como fóruns de discussão, agenda, repositório de

arquivos, questionários, gerenciamento de links e relatório de atividades. Essas

características são apropriadas para o uso das técnicas de desenvolvimento

baseado em componentes e linhas de produto, dado que serviços colaborativos

são componentes de groupware e podem ser adaptados para atender alguma

necessidade específica de colaboração. Esses componentes de groupware no

GW são denominados Collablets.

A mesma análise aplicada a sistemas e seus serviços é aplicada para

serviços e suas funcionalidades, que são recorrentes. Por exemplo, diversos

serviços dentro de um ambiente reusam a categorização de mensagens e

avaliação, controle de permissões, dentre outros. Encapsular essas

funcionalidades em componentes possibilita também a outros desenvolvedores o

reuso dessas funcionalidades em seus projetos, tornando possível a evolução,

adaptação e construção de serviços variando e reconfigurando os componentes

de colaboração. Esses componentes de colaboração no GW são chamados

CollabElements. No GW, tanto Collablets quanto CollabElements são

organizados de acordo com o Modelo 3C de Colaboração.

Assim, o desenvolvimento de groupware usando o GW consiste na

composição de Collablets que implementam serviços de groupware. Esses

Collablets são resultados da união de CollabElements seguido por suas

adaptações para prover funcionalidade específica. Isso favorece um reuso de

componentes em dois níveis: na composição do sistema colaborativo

(groupware) e na composição de cada serviço colaborativo (Collablet).

5

35

2.5.Desenvolvimento Dirigido por Modelos

Desenvolvimento dirigido por modelos (Model Driven Development - MDD)

é uma abordagem descrita pela Engenharia Orientada a Modelos (Model Driven

Engineering – MDE) que trata da redução da distância entre o domínio do

problema e o domínio de implementação de software. Isso é atingido através do

uso de tecnologias de suporte a transformações sistemáticas de modelos que

representam abstrações no nível do problema para implementações de software

[45].

A principal característica do MDD é que o foco do desenvolvimento de

software está nos modelos e não na sua implementação. A maior vantagem

dessa abordagem está no fato dos modelos usarem conceitos mais relacionados

ao domínio do problema do que às tecnologias de implementação utilizadas. Em

alguns casos, como o desta tese, pode ser até mais fácil para especialistas do

domínio produzirem software do que para especialistas em tecnologia [46]. Isso

torna os modelos independentes da tecnologia computacional escolhida e da

evolução dessa tecnologia.

A seguir são apresentadas algumas motivações para a adoção do MDD

[47]:

• Aumento da produtividade . O aumento da produtividade acontece em

função da diminuição do tempo de desenvolvimento de software, sobretudo

devido à automação na geração dos artefatos de software;

• Melhoria da qualidade. Melhorias na qualidade do código gerado, dos

requisitos do sistema, no gerenciamento desses requisitos, e previsão de

bugs no sistema;

• Automação. Geração de código e outros artefatos automaticamente durante

o processo de desenvolvimento de software. Simulação e testes baseados

em modelos;

• Padronização e formalismo. Provê um framework comum para o

desenvolvimento de software que formaliza e organiza o conhecimento da

engenharia de software em um nível mais alto de abstração e estabelece um

formato comum de exportação de dados;

• Manutenção e evolução. Mantém a arquitetura intacta desde a análise até a

implementação e a evolução de sistemas legados;

• Melhoria na comunicação e compartilhamento de infor mação. Entre os

stakeholders e entre a equipe de desenvolvimento. Facilidade no

aprendizado.

6

36

Características como a facilidade no aprendizado e a automação do

processo de desenvolvimento de software foram determinantes para o uso dos

conceitos de MDD nesta pesquisa. Com a representação do script de

colaboração sob a forma de modelos desenvolvidos pelo usuário final, o

groupware é derivado conforme detalhado na Seção 3.4.

2.6.Programação pelo usuário final

Os programadores usuários-finais são usurários que não foram

formalmente treinados em programação, porém precisam programar para

cumprir suas atividades diárias. Planilhas são frequentemente citadas como o

maior sucesso da história da programação pelo usuário final (End-user

programming - EUP). Milhões de usuários escrevem fórmulas em sistemas como

o Microsoft Excel apesar de apenas poucos se considerarem programadores de

fato. Muitos nem se dão conta que estão programando [48].

A EUP tem se tornado um conceito relevante em engenharia de software

por, pelo menos, dois motivos: (i) o alto custo de construir e manter aplicações

multifuncionais, e a demanda constante dos usuários por melhoramentos e

extensões para os software, inclusive os mais bem sucedidos e; (ii) a crescente

consciência de que os usuários não são mais consumidores passivos de

software e podem exercer o papel de projetista e produtores de software [49].

A literatura cita diferentes abordagens no uso de EUP, tais como as

descritas a seguir [50]:

• Programação de preferências. Preferências são alternativas pré-definidas

pelo projetista da aplicação e usadas para suprir as necessidades de

diferentes tipos de usuários finais. Consiste em uma maneira simplificada

para o projetista adicionar alternativas à aplicação, porém, o excesso de

alternativas pode se tornar um fator complicador para os usuários.

• Programação por demonstração. Gravadores de macros são usados para

gravar as entradas dos usuários e depois repeti-las. Essas entradas

gravadas são eventos de baixo nível como um clique no mouse em uma

posição da tela, o que torna difícil reproduzir exatamente o mesmo efeito. A

programação por demonstração, também é conhecida por programação por

exemplos, consiste basicamente em um gravador de macros que ao invés de

registrar eventos de baixo nível, produz um programa geral de eventos de

nível médio ou ações de usuários.

7

37

• Programação de planilhas. Nas planilhas, ao criar fórmulas e construir

modelos na forma de funções e referências de células, os usuários finais

estão programando. As planilhas constantemente dão feedback aos usuários

finais a medida em que eles progridem na programação mesmo quando o

programa não está completo ou contém erros. Isso significa que os usuários

finais podem continuar suas atividades sem serem interrompidos para

compilar e testar os programas como na programação textual.

• Programação de scripts. Programação de scripts é quando a programação

ocorre através da adoção de uma linguagem de scripts. Uma linguagem de

script é uma linguagem pequena, geralmente com vocabulário

especificamente projetado para a aplicação e seu domínio.

Na presente pesquisa, o conceito de EUP é usado sobre a abordagem da

programação de scripts alinhada com MDD de modo a instrumentar os usuários

finais da aplicação desenvolvida nessa tese para o desenvolvimento de seus

próprios groupware. O usuário final é responsável pela criação dos scripts de

colaboração, sob a forma de modelos, que servem de ponto de partida para a

derivação de seu groupware de suporte.

A seguir são apresentados trabalhos na literatura que são relacionados à

pesquisa apresentada nessa tese.

2.7. Trabalhos Relacionados

Essa tese envolve três conceitos principais: desenvolvimento de

groupware, linhas de produtos de software e scripts de colaboração.

Com relação ao desenvolvimento de groupware, diversos trabalhos

descrevem abordagens para minimizar o esforço durante desenvolvimento. A

idéia dessas abordagens é encapsular as dificuldades técnicas da

implementação de groupware como, por exemplo, gerenciamento de sessão e

protocolos de comunicação. Dentre as motivações para o desenvolvimento

baseado em componentes, essas abordagens concentram-se na composição

(tailorability) de groupware [51, 52] e linhas de produtos [9, 53, 54]. A

composição de groupware está relacionada com a questão da montagem do

groupware pelo usuário final, porém, ainda exige conhecimentos específicos de

computação e componentização. A questão das linhas de produtos apontada

pelas abordagens citadas está relacionada ao reuso sistemático desses

componentes, que são desenvolvidos com o objetivo de serem reusados em

8

38

diversos groupware, reduzindo o investimento total do desenvolvimento e os

custos de manutenção de software.

Exemplos que ilustram essas abordagens são: (1) GroupKit [53], que provê

um toolkit que encapsula as complexidades intrínsecas do desenvolvimento de

groupware síncrono; (2) FreEvolve [51], que foi projetado para possibilitar a

customização de groupware através da composição de componentes ou a

adaptação de software existente para os usuários finais, e; (3) DreamTeam [54],

que é uma plataforma baseada em componentes de suporte a construção de

groupware síncrono.

Apesar de essas abordagens proverem técnicas que reduzem o esforço no

desenvolvimento de groupware e citarem o uso de linhas de produto de software,

elas não cobrem todo o processo de desenvolvimento das LPS. Faltam as

definições de atividades como a análise de domínio, que é responsável pela

elicitação dos requisitos comuns e variáveis (features), e da rastreabilidade

dessas features, que provê meios de derivação sistemática de groupware em

uma LPS.

Com relação às LPS, são poucos os trabalhos encontrados na literatura

que aplicam esse conceito ao desenvolvimento de groupware. Um desses

trabalhos é o apresentado por Gaspar et. al. [55] onde é descrita uma linha de

produtos de software no domínio de aplicações síncronas na Web 2.0. Essa LPS

deriva aplicações para dar suporte à colaboração síncrona, como por exemplo:

sala de aula virtual (áudio, vídeo e quadro eletrônico), um bate papo (áudio,

vídeo e texto), uma vídeo conferência (áudio e vídeo), ou outra que seja mais

adequada a uma colaboração síncrona desejada. Outro trabalho que relaciona

LPS ao desenvolvimento de groupware é o de Oliveira et. al. 2011 [56], que em

sua pesquisa usou o método FODA junto com padrões de interação para

identificar as features de compartilhamento de conteúdo em redes sociais. O

foco da sua pesquisa está na etapa de análise de domínio, onde as features

foram identificadas e implementadas com o Groupware Workbench.

Os trabalhos acima não especificam como os groupware podem ser

derivados a partir dos requisitos do usuário. Eles apresentam uma abordagem

para a identificação de features, implementam essas features e ainda apontam

como combinar essas features para atender a necessidades específicas, porém,

sem detalhar essas necessidades, como são levantadas e representadas. Tais

necessidades são representadas na pesquisa dessa tese por meios de scripts de

colaboração. Esses scripts guiam, nessa pesquisa, o processo de derivação de

groupware.

9

39

Alguns trabalhos apontam o uso de groupware para o suporte de scripts de

colaboração. Um exemplo de groupware que usa scripts de colaboração é o

ManyScripts [57], que disponibiliza três scripts para configuração por parte dos

mediadores da aprendizagem para usarem com os estudantes: o “ArgueGraph”,

que foca nas estratégias de formação de grupos guiado pela comunicação entre

os estudantes; o “ConceptGrid” que é uma implementação do JigSaw que guia o

processo da distribuição do conhecimento entre o grupo de estudantes; e o “ICE”

que consiste em um sistema de revisão por pares para exercícios. Outro

groupware que faz uso de scripts de colaboração é o WikiPlus [58], que usa um

sistema wiki para a edição e execução dos scripts. O diferencial do WikiPlus é a

possibilidade de programação de novos scripts de colaboração, porém limita a

ação dos participantes aos serviços providos pelo wiki. Outro trabalho que faz

uso de scripts de colaboração usa a linguagem IMS-LD para descrever os scripts

em um ambiente de aprendizagem usado em um contexto misto, onde atividades

virtuais são combinadas com atividades face-a-face [59]. Em seu trabalho,

Sanagustin et. al. [59] destaca a dificuldade em dar suporte computacional a

mudanças da colaboração em tempo de execução dos scripts principalmente

quando se considera o contexto misto de aprendizagem.

A linguagem para a representação dos scripts de colaboração usada na

pesquisa apresentada nessa tese é baseada em BPMN. Alguns trabalhos já

relacionam o uso conjunto de linhas de produto de software e modelos de

processo de negócio. Porém, o enfoque desses trabalhos está na identificação e

na orquestração das chamadas dos serviços de uma arquitetura orientada a

serviços (Software-oriented Architecture - SOA). Kang et. al. [60] propõe uma

abordagem para a identificação de serviços da SOA que envolve modelos de

features e modelos de processo de negócios alcançando assim o reuso de

serviços. Outro trabalho que envolve LPS e BPMN consiste no desenvolvimento

de linhas de produtos de processos de negócios [61] com o objetivo de reusar e

integrar sistematicamente vários processos de negócio orientados a serviços.

O capítulo a seguir apresenta a abordagem de linha dinâmica de produto

para groupware. Nessa abordagem, os groupware são derivados através da

formalização da colaboração em scripts de colaboração descritos em BPMN,

sintetizando os conceitos aqui apresentados.

3 Linha de Produto Dinâmica para Groupware

Este capítulo apresenta uma arquitetura geral de uma linha de produtos

para groupware baseado no Modelo 3C de Colaboração. Essa arquitetura foi

concebida de modo a viabilizar a derivação de groupware ajustado a contextos

específicos de colaboração representados por scripts de colaboração descritos

sob a forma de modelos de processos de negócios e compreende três

elementos, a saber:

• Linhas de produtos de serviços . Cada serviço que compõe o groupware é

gerado através de uma linha de produto individual. Cada linha de produto é

capaz de derivar serviços com comportamentos distintos para atender as

especificações do designer.

• Especificações do designer. Consiste nas especificações dos requisitos

iniciais de colaboração que o groupware a ser derivado deverá atender.

Contém a descrição do contexto de colaboração (script de colaboração) bem

como a configuração dos serviços necessários ao suporte do contexto

descrito.

• Derivação automática de produtos. As especificações do designer são

interpretadas pela arquitetura e traduzidas em termos de features e suas

configurações. Cada serviço descrito nas especificações é derivado a partir

de sua respectiva linha de produtos. Estes são organizados na composição

do groupware final.

A Figura 7 apresenta um Modelo de Features 3C genérico representando

um modelo geral da linha de produtos de groupware que deve ser instanciado

para cada contexto de aplicação. Por ser um modelo genérico, o nó raiz

“Groupware” está representado por um retângulo, não indicando, portanto, o

propósito 3C do groupware em questão. As demais features são representadas

por outros símbolos indicando seus respectivos propósitos. As features

assinaladas com um círculo preenchido preto são mandatórias devendo,

portanto, estar presente em todas as implementações que instanciam esse

modelo. Elas correspondem às features com propósito de coordenação que

tratam do gerenciamento de usuários, dos papéis que eles podem exercer e dos

1

41

grupos que podem participar no groupware derivado. A “Ger. Script” é outra

feature mandatória que se refere ao gerenciamento dos scripts de colaboração e

é responsável por tratar as especificações do designer na tarefa de configuração

em tempo de execução das features de serviços. Essa feature tem como

alternativas as features que tratam as possíveis linguagens de representação de

processos colaborativos como, por exemplo, o BPMN e o IMS LD. Nesta tese

utilizou-se um subconjunto do BPMN que será explicado em detalhes na Seção

3.2. Por fim, a feature mandatória “Ger. Serviços” é responsável por gerenciar

quais serviços estarão disponíveis nos groupware derivados. Possui como

features opcionais as features dos serviços individuais. Cada serviço é

representado por sua própria linha de produtos individual (ilustradas pelos

círculos cinza) e é instanciado de diferentes maneiras para dar suporte

adequado à colaboração descrita nas especificações do designer. Além disso, os

serviços são também classificados por seu propósito de acordo com o Modelo

3C de Colaboração.

Figura 7. Modelo de Features 3C Genérico da

Linha de Produtos para Groupware

As próximas seções detalham as atividades do esquema proposto

descritas acima. Em seguida, para exemplificar a instanciação do esquema

proposto, é apresentado o desenvolvimento de uma linha de produtos de

groupware para o suporte à aprendizagem colaborativa.

2

42

3.1.Desenvolvimento das linhas de produto de serviç os

Para o desenvolvimento das linhas de produto dos serviços que irão

compor os groupware fez-se uso de atividades e modelos do contexto de

desenvolvimento tanto de groupware como de linhas de produtos de software.

Essa abordagem, além de prover meios de desenvolver artefatos reutilizáveis,

provê também meios para identificação e rastreabilidade das features das linhas

de produtos de serviços. O propósito desta abordagem é permitir a derivação

automática dos serviços de groupware. A seguir são apresentadas as etapas

que compõe a abordagem: (1) Análise de Domínio, que analisa o domínio

usando o Modelo 3C de Colaboração que guia a elicitação de requisitos e

identifica features comuns e variáveis e; (2) Projeto e Implementação, que tem

por objetivo definir uma arquitetura que dê suporte à variabilidade definida e à

derivação dos serviços de forma sistemática.

3.1.1.Análise de Domínio

Na etapa de análise de domínio, os principais conceitos e atividades do

domínio são identificados e modelados usando as técnicas adequadas. As

partes comuns e variáveis de uma família de sistemas são identificadas,

definindo o escopo da linha de produtos indicando quais produtos podem ser

derivados a partir dela. A análise de domínio nesta pesquisa diferencia-se da

análise de domínio das linhas de produto de software em geral devido à

necessidade da análise da colaboração.

A análise da colaboração é realizada de acordo com o Modelo 3C de

Colaboração, e a análise de domínio é realizada conforme especificado no RUP

3C-Groupware. Como resultados dessa análise têm-se um Quadro Conceitual

3C e a identificação da aplicação típica de domínio. Esta aplicação leva a

identificação das features mandatórias dos produtos durante a modelagem de

features.

A modelagem de features é uma atividade que consiste em analisar e

capturar as features comuns e variáveis e suas interdependências nas linhas de

produto de software. Nesta tese, as features são organizadas em um modelo

que provê, além das informações de variabilidade das features e suas restrições,

informações sobre o propósito das features de acordo com o Modelo 3C de

Colaboração. Este modelo de features estendido é aqui chamado de Modelo de

Features 3C e é ilustrado pela Figura 8.

3

43

Figura 8. Exemplo de Modelo de Features 3C

Identificadas as features que farão parte da linha de produtos, passa-se

então para a etapa de projeto e implementação.

3.1.2.Projeto e implementação

O projeto e implementação das linhas de produtos de serviços devem

resultar numa arquitetura que dê suporte à variabilidade. Isso é alcançado

levando-se em consideração a modularidade das features e a adoção de

técnicas que promova essa modularidade. O principal benefício de ter as

features modularizadas é a possibilidade de (des)plugá-las, facilitando a

derivação automática de produtos e consequentemente reduzindo tempo e custo

do processo de derivação. Diferentes técnicas de implementação podem ser

utilizadas na modularização das features como, por exemplo: polimorfismos,

padrões de projetos, frameworks, compilação condicional, componentização,

programação orientada a aspectos, dentre outros. Nesta tese é utilizada a

técnica de componentização propiciando o uso do Groupware Workbench,

mantendo assim a consistência com o Modelo 3C de Colaboração em todas as

etapas do processo de desenvolvimento das linhas de produto de serviços.

Além de modelar e implementar os artefatos reutilizáveis nas linhas de

produtos de serviços, é importante manter elos de rastreabilidade entre as

features e os elementos que as implementam. Essa informação possibilita a

escolha dos artefatos apropriados de acordo com as features selecionadas

durante o processo de derivação do serviço.

4

44

Figura 9. Resumo da abordagem de desenvolvimento da s linhas de produto

de serviços.

A Figura 9 resume a abordagem apresentada. O principal resultado da

análise de domínio é o Modelo de Features 3C. Depois, a linha de produtos de

serviços é projetada considerando a variabilidade identificada e, por

consequência, os artefatos reutilizáveis são implementados. Elos entre os

artefatos da linha de produtos asseguram a rastreabilidade das features

possibilitando um processo de derivação eficaz. Nesta tese, esses elos de

rastreabilidade são expressos em forma de tabelas, que mapeiam features para

os componentes e classes que as implementam. Além disso, essas tabelas

devem informar quais ações dos usuários do groupware se relacionam com cada

feature, de modo a possibilitar a derivação dos produtos a partir dos scripts de

colaboração.

3.2.Representando as Especificações do Designer

As especificações do designer nesta pesquisa consistem nos requisitos

para um groupware derivado de uma linha de produtos de software. Tais

especificações devem explicitar a colaboração entre os usuários do groupware,

bem como os serviços necessários ao seu suporte. Dessa forma, nesta pesquisa

utilizou-se o conceito de scripts de colaboração, conforme descrito na Seção

2.2.1, com foco nos macro-scripts para guiar o processo de derivação de

groupware, uma vez que estes descrevem de modo geral a colaboração entre os

usuários do groupware.

5

45

Dado que os scripts de colaboração estruturam fluxos de atividades

colaborativas, grupos ou papéis envolvidas nessas atividades, utilizou-se um

conjunto de elementos do BPMN para descrevê-los. A próxima seção apresenta

como o BPMN foi mapeado no framework de descrição de scripts de

colaboração apresentado na Seção 2.2.1.

3.2.1.Representando Scripts de Colaboração com BPMN

Atividades e controle de fluxo são os conceitos-chave do BPMN. Embora

tenha sido criado para orquestrar a chamada de web services, o BPMN pode ser

utilizado na descrição de processos que compreendem atividades e

sequenciamento de atividades como no caso de processos colaborativos. Para

descrever scripts de colaboração, é necessário verificar se elementos oferecidos

pelo BPMN são representativas o suficiente para satisfazer os requisitos do

framework de desenvolvimento de scripts conforme mencionado anteriormente.

A seguir é apresentado o mapeamento dos elementos do framework para a

notação BPMN.

• Componentes:

o Participantes. Esta é uma característica inerente aos processos

colaborativos. BPMN originalmente prevê que os participantes dos

processos são sistemas e serviços (web services). Na representação

dos scripts de colaboração, os participantes são as pessoas

envolvidas na colaboração. Não há, portanto, um elemento específico

para representar os participantes explicitamente.

o Atividades. Estas são representadas pelo elemento “Activity” do

BPMN.

o Grupos e papéis. Grupos são representados pelo elemento “Pool” e

os papéis são representados pelo elemento “Lane” do BPMN. Uma

lane organiza e categoriza atividades. No escopo deste trabalho,

atividades em uma lane implicam em atribuir atividades a usuários

que desempenham o papel que aquela lane representa.

o Recursos. Recursos que provêm funcionalidades são representados

por uma pool separada indicando todas os seus requisitos funcionais

sob a forma de ações, conforme será apresentado na próxima seção.

• Mecanismos.

6

46

o Distribuição de tarefas. Delegar tarefas a participantes siginifica

colocar a atividade na lane que representa o papel que o participante

executa.

o Formação de grupos. Critérios de formação de grupos não são

representados pelo BPMN, que apenas representa os próprios

grupos.

o Sequenciamento. BPMN representa o sequenciamento por uma

sequencia de fluxos (uma seta direcionada) e gateways. Sequencias

de fluxos são usados para ordenar (sequenciar) as atividades que

serão executadas no processo colaborativo. Os gateways,

representados por losangos, são usados para controlar a divergência

e convergência de uma sequencia de fluxos. Visando maior clareza e

simplicidade nos modelos, os gateways não estão sendo levados em

consideração nesta pesquisa. Havendo a necessidade de divergência

ou convergência das sequencias de fluxos, estas são representadas

através de múltiplas setas partindo de uma atividade (divergência), ou

múltiplas setas levando a uma mesma atividade (convergência).

A Figura 10 exemplifica o uso dos elementos BPMN na representação de

scripts de colaboração. Na figura, o grupo é identificado pela pool “Grp: Grupo

X”. Nesse grupo verifica-se dois papeis distintos representados pelas lanes

“Papel A” e “Papel B”. As atividades representadas pelos elementos activity são:

“Atividade A”, “Atividade A2” e “Atividade B”, onde as duas primeiras devem ser

realizadas pelos participantes do “Papel A”, e a última pelo “Papel B” no grupo

representado.

Figura 10. Exemplo de representação de script de co laboração com BPMN.

7

47

A próxima seção detalha como os recursos disponíveis para a realização

das atividades deve ser representado segundo a proposta de uso do BPMN

nessa tese.

3.2.2.Representando Requisitos de Sistema com BPMN

Para completar as especificações do designer, deve-se especificar os

serviços que darão suporte a cada atividade descrita no script de colaboração.

Para cada atividade, deve-se associar um ou mais serviços. Uma vez que cada

serviço também consiste num produto derivado de uma linha de produtos, pode

haver a necessidade da derivação de diferentes configurações para um mesmo

serviço a fim de dar suporte a diferentes necessidades ou atividades. Esta

especificação também é realizada usando o BPMN, descrevendo os requisitos

funcionais como ações que devem ser executadas pelos usuários do serviço

desejado.

A especificação de um serviço (Figura 11) começa com uma nova pool do

BPMN compreendendo todas as possíveis ações que os usuários do serviço

podem executar, representadas pelo elemento activity do BPMN. Uma pool deve

ter um nome que indica a linha de produto individual que deve ser utilizada na

derivação do serviço (Src). Além da linha de produto a ser utilizada, o nome deve

também indicar um apelido (Alias) que indica o nome do serviço no groupware

derivado. O nome da pool deve ainda ter a referência de qual(ais) atividade(s)

terão o suporte do serviço especificado (To). A Figura 11 ilustra uma

especificação de um serviço conforme a notação apresentada.

Figura 11. Especificação de um serviço usando BPMN.

8

48

Para exemplificar a instanciação do esquema apresentado foi desenvolvida

uma linha de produtos para groupware de suporte a aprendizagem colaborativa.

O desenvolvimento é descrito na próxima seção.

3.3. Linha de Produto para Groupware de Suporte a A prendizagem Colaborativa

Conforme Seção 2.2 desta tese, a aprendizagem colaborativa refere-se a

uma variedade de técnicas de aprendizagem onde os estudantes trabalham em

pequenos grupos [10]. Como exemplo dessas técnicas pode-se citar:

Controvérsia Acadêmica [13], Jigsaw [15] e Investigação em Grupo [17].

Para dar suporte a cada uma dessas técnicas, foram desenvolvidos os

seguintes groupware:

• Versus [12]. Foi projetado para dar suporte à técnica Controvérsia

Acadêmica. Faz uso do conceito de mapas conceituais [14] como ferramenta

de construção, representação e comunicação do conhecimento. A

Controvérsia Acadêmica objetiva tornar conflitos acadêmicos em atividades

construtivas. A técnica é aplicada quando, por exemplo, uma idéia,

conclusão ou opinião de um estudante é incompatível com seu par. O foco

está na conversação para o alinhamento de ideias.

• AVMJ (Ambiente Virtual para o Método Jigsaw) [14]. Foi projetado para dar

suporte à técnica Jigsaw que objetiva criar um ambiente de aprendizagem

comunitário removendo aspectos indesejáveis como competição excessiva

entre os participantes aumentando o interesse na colaboração [15]. O foco

recai sobre o compartilhamento de recursos.

• InGrupo [16]. Desenvolvido para dar suporte à técnica Investigação em

grupo [17] onde aprendizes trabalham de forma colaborativa em pequenos

grupos examinando, experimentando e tentando entender os temas centrais

de estudo. O foco deste groupware está no compartilhamento de recursos e

experiências.

Os requisitos mostrados na Tabela 1 foram classificados pelos

desenvolvedores dos groupware mencionados acima de acordo com sua

relevância na aplicação de cada método como essencial, desejável ou opcional.

Os requisitos essenciais incluem aqueles necessários para a aplicação da

técnica usando um groupware; os requisitos desejáveis são aqueles que

agregam valor ao groupware, porém sua ausência é aceitável; e, os requisitos

opcionais são aqueles que podem ser cumpridos de acordo com os recursos

9

49

disponíveis. Para construir a tabela, os requisitos funcionais que foram

classificados como essenciais em pelo menos uma das etapas de uma técnica

foram considerados como “essencial”.

Tabela 1. Resumo dos requisitos funcionais do Versu s, AVMJ e InGrupo.

Groupware

Técnica

Versus Controvérsia Acadêmica

AVMJ JigSaw

InGrupo Investigação em

Grupo

Com

unic

ação

E-mail Essencial

Fórum de discussão Essencial Essencial Essencial

Enquetes Essencial Essencial

Chat Essencial Essencial Desejável

Lista de discussão Opcional

Vídeo conferência Desejável

Recados Opcional

Coo

rden

ação

Questionários Essencial Essencial

Agenda Opcional

Composição de grupos Essencial Essencial Essencial

Relatórios Essencial

Coo

pera

ção

Repositório de arquivos Essencial Essencial Essencial

Quadro-branco Desejável Desejável Desejável

Editor de mapas conceituais

Essencial Opcional Opcional

Editor compartilhado de texto

Opcional

Editor de slides Opcional Opcional

Biblioteca Desejável

Apesar de terem sido desenvolvidos com diferentes propósitos, todos os

groupware acima objetivam dar suporte a algum método de aprendizagem

colaborativa e tem seus requisitos funcionais classificados de acordo com o

Modelo 3C de Colaboração e compartilham um conjunto significante de serviços.

A seguir é apresentado o desenvolvimento de dois serviços classificados

como “essencial” para as três técnicas de aprendizagem colaborativa

consideradas. Dois dos serviços têm o propósito de comunicação, que são fórum

de discussão e chat e um com propósito de cooperação, o repositório de

arquivos. O serviço de coordenação “Composição de grupos” considerado

essencial aos três métodos não é detalhado uma vez que este é implementado

pela feature mandatória Grupos do esquema geral de linha de produtos de

groupware ilustrado anteriormente na Figura 7.

0

50

3.3.1. Desenvolvendo o Serviço de Fórum de Discuss ões

A linha de produtos (LP) de serviços de fóruns de discussão deve ser

capaz de produzir diferentes variações de fóruns a fim de dar suporte específico

aos diferentes métodos de aprendizagem colaborativa ou a atividades

específicas desses métodos. Esta seção detalha o desenvolvimento desta linha

de produto de serviços.

3.3.1.1.Análise de Domínio

Um serviço de fórum típico consiste em uma lista de mensagens postadas

pelos participantes. Em geral, essa lista contém apenas o assunto das

mensagens, e estão organizados hierarquicamente. A partir dessa lista, é

permitido ao participante enviar uma nova mensagem ao tópico em discussão ou

responder uma mensagem enviada por outro participante.

Porém, para dar suporte aos métodos analisados, é necessário o

cumprimento de alguns requisitos adicionais conforme apresentado a seguir:

• Para dar suporte à Controvérsia Acadêmica, é necessário que a lista de

mensagens seja organizada de acordo com três categorias distintas: (1)

Concordo, onde o participante se posiciona como favorável ao tópico em

discussão; (2) Discordo, onde o participante se posiciona como desfavorável

ao tópico em discussão e (3) Depende, onde o participante pondera sobre

diferentes aspectos do tópico em discussão. Essa organização de

mensagens mantém o foco no tópico principal da discussão.

• Para dar suporte ao Jigsaw, é necessário que a organização da lista de

mensagens seja semelhante hierárquica, semelhante ao fórum típico descrito

anteriormente. Porém, deve ser possível classificar as mensagens segundo

as seguintes categorias: (1) Sugestão de proposição, onde a mensagem

indica uma proposição ao fórum; (2) Aceite da proposição, onde o

participante responde indicando que aprovou a proposição; (3) Recusa da

proposição, onde o participante responde indicando que não aprovou a

proposição; (4) Dúvida, onde o participante expressa alguma dúvida sobre o

texto, mapa conceitual ou proposição apresentados; (5) Comentário, onde o

participante faz uma observação informal que pode esclarecer algum aspecto

que está sendo discutido e; (6) Explicação, onde o participante expressa uma

opinião sobre o texto, proposição ou mapa conceitual apresentados.

1

51

• Para dar suporte à Investigação em Grupo, um fórum típico como o descrito

anteriormente é suficiente.

A Tabela 2 estrutura os elementos específicos do domínio da comunicação

assíncrona e os classifica de acordo com o Modelo 3C de Colaboração.

Tabela 2. Quadro Conceitual 3C para o serviço de Fó rum de Discussão.

Elementos 3C para análise

Versus Controvérsia Acadêmica

AVMJ JigSaw

InGrupo Investigação em

Grupo

Com

unic

ação

Linguagem Textual Textual Textual

Transmissão Após elaboração da mensagem

Após elaboração da mensagem

Após elaboração da mensagem

Tamanho e Qualidade Sem limite Sem limite Sem limite

Estruturação do discurso

Organizado por categorias

Hierárquico Hierárquico

Categorização Sim Sim Não

Coo

rden

ação

Tópico Sim Sim Sim

Sessão Sim Sim Sim

Acesso Participantes do groupware

Participantes do groupware

Participantes do groupware

Presença Sim Sim Sim

Papéis

Pró Contra

Professor Todos

Professor Aluno

Professor Aluno

Posse da palavra Imediata Imediata Imediata

Freqüência Sem limitação Sem limitação Sem limitação

Visibilidade Pública Pública Pública

Endereçamento Ao grupo A todos

Ao grupo A todos

Ao grupo A todos

Avaliação Não Não Não

Coo

pera

ção

Registro Sim Sim Sim

Configuração do espaço

Janela única exibindo mensagens

agrupadas por categorias

Janela única exibindo mensagens agrupadas

hierarquicamente, porém com categorias

identificadas

Janela única exibindo mensagens agrupadas

hierarquicamente

Mensagens preconcebidas

Não Não Não

Após identificar a aplicação típica do domínio, analisar os requisitos de

cada método e o framework conceitual 3C é possível capturar as features

comuns e variáveis do domínio. A Figura 12 ilustra o Modelo de Features 3C

para os serviços de fóruns de discussão informando além da variabilidade, o

propósito 3C de cada feature.

Uma questão a ser observada é que, apesar dos fóruns de discussão

serem ferramentas com propósito de comunicação, várias das features

identificadas tem por propósito a coordenação e a cooperação, refletindo os

intra-relacionamentos dessas dimensões do modelo de colaboração [43].

2

52

Após identificadas, essas features são analisadas e classificadas em três

categorias distintas: mandatórias, opcionais e alternativas. Features mandatórias

são essenciais para qualquer fórum de discussão, features opcionais são

necessárias apenas em situações específicas, e features alternativas variam de

um produto para outro.

Figura 12. Modelo de Features 3C do serviço Fórum d e Discussões

A seguir, as features que compõe a LP do serviço de fórum de discussões

são descritas:

• Tópicos. Esta é uma feature mandatória. Mensagens em um fórum derivado

dessa linha de produtos são organizadas em tópicos que estão relacionados

ao assunto da discussão.

• Mensagens. As mensagens são enviadas a um tópico específico. Esta é a

feature principal da linha de produto, mandatória, e consiste na própria

discussão. Para enriquecer cada postagem, a LP de serviço de fórum de

discussões provê features opcionais como: (1) Anexos, onde os participantes

podem adicionar arquivos (texto, imagens, vídeos, sons, etc.) como anexos a

suas mensagens para prover maior detalhamento o ilustrá-la; (2)

Categorização, onde os participantes podem escolher uma categoria em uma

lista para adicionar informação semântica às suas mensagens evidenciando

um relacionamento entre as elas e; (3) E-mail. Mensagens enviadas ao

3

53

fórum podem ser automaticamente enviadas por e-mail aos seus

participantes como em uma lista de discussões. Neste caso, o e-mail tem o

propósito apenas de notificar o participante, visto que o mesmo deverá estar

logado no fórum para responder a uma mensagem ou fazer uma nova

postagem.

• Visualização. Esta é uma feature obrigatória que trata da forma em que as

mensagens são estruturadas e apresentadas aos usuários. Esta feature

provê a estrutura de dados para dar suporte a diferentes formas de

apresentação representadas pelas features alternativas: (1) Hierárquica, que

consiste em uma estrutura que deve ser usada quando o relacionamento das

mensagens precisa ser rapidamente identificado como, por exemplo, no caso

de perguntas e respostas, sendo a estrutura mais comumente encontrada

nos fóruns disponíveis na Internet; (2) Categorias, que consiste em organizar

a visualização das mensagens por suas categorias, possibilitando manter o

foco da discussão no tópico discutido como mencionado anteriormente e (3)

Listas, que consiste em uma forma apropriada para comunicação onde a

ordem cronológica das mensagens postadas é importante, como por

exemplo, o envio de notícias.

• Busca. Esta feature opcional permite que usuários busquem mensagens em

uma discussão facilitando, assim, o acesso a mensagens passadas.

Além das features identificadas para o serviço de fórum de discussão, o

modelo de features 3C deve mostrar, também, o relacionamento entre essas

features. No modelo da Figura 12 observa-se uma seta que parte da feature de

visualização “Categoria” para a feature de mensagens “Categorização”,

indicando uma relação de dependência das features, dado que a visualização

das mensagens apenas será organizada pelas categorias se as mensagens

puderem ser categorizadas.

3.3.1.2.Projeto e Implementação

A implementação das features da linha de produtos de serviços é realizada

através do desenvolvimento de CollabElements do Groupware Workbench. Um

produto derivado desta linha consiste na composição desses CollabElements em

um Collablet. Ou seja, Collablet corresponde a um serviço que vai ser adicionado

ao groupware. Isso possibilita a adaptação e reuso desses componentes, não

apenas para uso nessa linha de produtos, mas também em qualquer outra linha

de produtos ou groupware desenvolvidos usando o GW.

4

54

A Figura 13 ilustra o Modelo de Componentes UML para o serviço de

fórum de discussão. As caixas que envolvem os componentes os agrupam de

acordo com seus propósitos. Além disso, os estereótipos <<mandatory>> e

<<optional>> indicam quais componentes fazem parte do núcleo do da LP de

serviço e quais não fazem parte. Um novo elemento que aparece nesse modelo

é o componente UserMgr. Este deve ser implementado pelo groupware que

usará Fórum Collablets derivados do Fórum PL.

Figura 13 Fórum PL – Modelo de Componentes UML para o serviço de

Fórum de Discussão.

Apesar de o Groupware Workbench possibilitar que features específicas

sejam diretamente codificadas como parte estática de um Collablet, decidiu-se

implementar features mandatórias separadamente como features independentes

da mesma forma que as opcionais. Isso possibilita o reuso dessas features

mandatórias como opcionais em outra linha de produto. Para garantir que todas

as features mandatórias estarão presentes em todos os produtos derivados do

Fórum PL, o Fórum Descriptor File, que consiste em um arquivo XML de

configuração do Collablet, é pré-configurado conforme a Figura 14. Este arquivo

de configuração será usado posteriormente na etapa de derivação de produtos

para a combinação de componentes opcionais para produtos específicos.

Finalmente, as última atividades a serem executadas nesta etapa é prover

os links de rastreabilidade entre as features do Fórum PL e os CollabElements

implementados, e associar ações que representam as funcionalidades do serviço

às features que as implementam. Cada feature é implementada por um único

CollabElements no Groupware Workbench. Como conseqüência, constrói-se

5

55

uma tabela que mapeia cada feature ao CollabElements que o implementa

(Tabela 3).

01. «TOOL» 02. «component-description» 03. «Version»1.0«Version» 04. «ComponentClass»tools.forum..ForumMgrComponent«ComponentClass» 05. 06. (...) 07. 08. <collaboration-components> 09. <collabComponent id="cooperation.topicsMgr" > 10. <collabComponent id="cooperation.postsMgr" > 11. <collabComponent id="cooperation.visualizationMgr" > 12. 13. (...) 14. 15. </collaboration-components> 16. (...) 17. «/TOOL»

Figura 14. Fórum Descriptor File (parcial).

Tabela 3. Links de rastreabilidade entre ações, fea tures e CollabElements.

Ação Feature CollabElement

Ler mensagens hierárquicas Visualização; Hierárquico

VisualizationMgr; Hierarchic

Ler mensagens por categorias Visualização;

categorias

VisualizationMgr; Categories;

CategorizationMgr;

Ler lista de mensagens Visualização;

Lista VisualizationMgr;

List

Escrever mensagens Tópicos;

Mensagens TopicsMrg; PostsMgr

Categorizar mensagens Categorização CategorizationMgr

Anexar arquivos Anexos AttachmentsMgr

Buscar mensagens Busca TopicsMrg; PostsMgr

Notificar participantes E-mail EmailSender

Como resultado, quando se necessita derivar um produto com certas

features, os componentes relacionados a elas devem ser selecionados para

fazer parte do produto. Nessa pesquisa, as ações descritas no script de

colaboração serão utilizadas para a identificação das features para a derivação

do serviço.

3.3.2. Desenvolvendo o Serviço de Repositório de Ar quivos

A linha de produtos (LP) de serviços de repositório de arquivos deve ser

capaz de produzir diferentes variações de repositórios a fim de dar suporte

específico aos diferentes métodos de aprendizagem colaborativa ou a atividades

6

56

específicas desses métodos. Esta seção detalha o desenvolvimento desta linha

de produto de serviços.

3.3.2.1. Análise de Domínio

Um serviço de repositório típico consiste em uma lista hierárquica de

arquivos e pastas de arquivos enviados pelos participantes. Em geral, essa lista

contém, além do nome dos arquivos, suas descrições e informação sobre o

participante que postou o arquivo. A lista possibilita o download do arquivo e que

novos arquivos sejam enviados ao repositório.

Porém, para dar suporte aos métodos analisados, é necessário o

cumprimento de alguns requisitos adicionais conforme apresentado a seguir:

• Para dar suporte à Controvérsia Acadêmica, os arquivos deverão possuir

diferentes níveis de acesso: (1) Público, onde todos os participantes do

groupware podem ter acesso; (2) Privado, onde apenas os participantes do

mesmo papel “Pró” ou “Contra” podem ter acesso e; (3) Compartilhado, onde

apenas os participantes de um mesmo grupo têm acesso aos arquivos.

• Para dar suporte ao Jigsaw, os arquivos também deverão ter diferentes

níveis de acesso: (1) Público, que dá acesso a todos os arquivos para todos

os participantes e; (2) Privado, onde apenas os participantes do mesmo

papel têm acesso aos arquivos postados.

• Para dar suporte à Investigação em Grupo, os arquivos deverão ter dois

níveis de acesso: (1) Público, disponível a todos os participantes e; (2)

Compartilhado, onde apenas os participantes do grupo de investigação terá

acesso.

A Tabela 4 estrutura os elementos específicos do domínio da cooperação

assíncrona e os classifica de acordo com o Modelo 3C de Colaboração.

Observa-se que, por se tratar de um serviço com propósito de cooperação, não

foram identificados elementos de comunicação além da notificação dos

participantes quando um arquivo for adicionado ao repositório.

Após identificar a aplicação típica do domínio, analisar os requisitos de

cada método e o framework conceitual 3C é possível capturar as features

comuns e variáveis do domínio. A Figura 15 ilustra o Modelo de Features 3C

para o serviço de repositório de arquivos informando além da variabilidade, o

propósito 3C de cada feature.

As features são analisadas e classificadas em três categorias distintas:

mandatórias, opcionais e alternativas. Features mandatórias são essenciais para

7

57

qualquer repositório de arquivos, features opcionais são necessárias apenas em

situações específicas, e features alternativas variam de um produto para outro.

Tabela 4. Quadro Conceitual 3C para o serviço de Re positório de

Arquivos

Elementos 3C para análise

Versus Controvérsia Acadêmica

AVMJ JigSaw

InGrupo Investigação em

Grupo

Com

unic

ação

Notificação

Não Não Não

Coo

rden

ação

Tópico Não Não Não

Sessão Não Não Não

Acesso Público Privado

Compartilhado

Público Privado

Público Compartilhado

Presença Sim Sim Sim

Papéis

Pró Contra

Professor Todos

Professor Aluno

Professor Aluno

Freqüência Sem limitação Sem limitação Sem limitação

Coo

pera

ção

Registro Sim Sim Sim

Configuração do espaço

Arquivos e pastas exibidas

hierarquicamente

Arquivos e pastas exibidas

hierarquicamente

Arquivos e pastas exibidas

hierarquicamente

Tamanho máximo de arquivo

10MB 10MB 10MB

Figura 15. Modelo de Features 3C do serviço Reposit ório de Arquivos.

8

58

A seguir, as features que compõe a LPS de repositórios de arquivos são

descritas:

• Envio de arquivos. Esta é a feature principal da linha de produto,

mandatória, e consiste no gerenciamento de envio de arquivos para o

repositório. Provê como feature opcional a “Notificação”, que trata do envio

de uma mensagem aos participantes notificando que um novo arquivo foi

postado no fórum de discussões. O envio dessa notificação acontece de

acordo com o nível de acesso definido para o arquivo, por exemplo, se um

arquivo tem acesso público, todos os participantes do groupware receberão a

notificação, senão apenas os participantes autorizados serão informados do

envio do arquivo.

• Busca. Essa feature opcional possibilita a localização de um arquivo

baseado na sua descrição.

• Acesso. Essa feature é obrigatória e é responsável pela definição dos níveis

de acesso aos arquivos enviados ao repositório. Pelo menos um dos níveis

de acesso definidos deve estar presente em um serviço de repositório

derivado dessa linha de produtos. Mais de um nível de acesso pode ser

disponibilizado.

o Público. Os arquivos enviados ao repositório com esse nível de

acesso estarão acessíveis a todos os participantes do groupware com

acesso ao serviço de repositório.

o Privado. Os arquivos enviados ao repositório com esse nível de

acesso estarão acessíveis a todos os participantes que

desempenham o mesmo papel em um groupware.

o Compartilhado. Os arquivos enviados ao repositório com esse nível

de acesso estarão acessíveis a todos os participantes que fazem

parte de um mesmo grupo definido no groupware.

• Visualização. Essa feature é obrigatória e tem for finalidade exibir a lista de

arquivos disponíveis no repositório, respeitando os níveis de acesso

definidos para cada arquivo.

3.3.2.2.Projeto e Implementação

Assim como no caso do serviço Fórum de Discussões, implementação das

features dessa linha de produtos de serviços também é realizada através do

desenvolvimento de CollabElements do Groupware Workbench. Um produto

9

59

derivado desta linha consiste na composição desses CollabElements em um

Collablet.

A Figura 16 ilustra o Modelo de Componentes UML para o serviço de

repositório de arquivos. Da mesma forma que na linha de produtos de fóruns de

discussão, nesse modelo também está presente os componentes UseMgr e

RoleMgr, que devem fazem parte do groupware onde o serviço de repositório

será instanciado.

Figura 16. Modelo de Componentes UML do serviço de repositório de

arquivos

Para garantir que todas as feature mandatórias estarão presentes em

todos os serviços derivados, o Repositório Descriptor File, que consiste em um

arquivo XML de configuração do Collablet, é pré-configurado conforme a Figura

17. Este arquivo de configuração será usado posteriormente na etapa de

derivação de produtos para a combinação de componentes opcionais para

produtos específicos.

01. «TOOL» 02. «component-description» 03. «Version»1.0«Version» 04. «ComponentClass»tools.forum..RepositoryMgrComponent«ComponentClass» 05. 06. (...) 07. 08. <collaboration-components> 09. <collabComponent id="cooperation.UploadMgr" > 10. <collabComponent id="cooperation.FileAcessMgr" > 11. <collabComponent id="cooperation.FileVisualizationMgr" > 12. 13. (...) 14. 15. </collaboration-components> 16. (...) 17. «/TOOL»

Figura 17. Repositório Descriptor File (parcial)

0

60

Finalmente, as últimas atividades a serem executadas nesta etapa são

prover os links de rastreabilidade entre as features da linha de produtos de

repositórios de arquivos e os CollabElements implementados, e associar ações

que representam as funcionalidades do serviço às features que as implementam.

Como conseqüência, constrói-se uma tabela que mapeia cada feature ao

CollabElement que o implementa (Tabela 5).

Tabela 5. Links de rastreabilidade entre ações, fea tures e CollabElements.

Ação Feature CollabElement

Enviar arquivo Envio de arquivos UploadMgr

Notificar grupo Notificação EmailSender

Buscar arquivo Busca FileSearchMgr

Ver arquivos publicos Acesso; Público

FileAcessMgr

Ver arquivos do papel Acesso; Privado

FileAcessMgr

Ver arquivos do grupo Acesso;

Compartilhado FileAcessMgr

As ações descritas no script de colaboração serão utilizadas para a

identificação das features para a derivação do serviço.

3.4.Derivação de produtos

Derivação de produto [13] na engenharia de linhas de produto de software

refere-se ao processo de construção de um produto a partir de um conjunto de

artefatos reutilizáveis. Nas linhas de produtos dos serviços descritos

anteriormente, os serviços são derivados através da composição de

CollabElements e configuração de Collablets específicos. Esses artefatos

encapsulam as dificuldades técnicas de sistemas distribuídos e multiusuários

baseados no Modelo 3C de Colaboração. O exemplo prático da derivação é

mostrado no Capítulo 4.

Um protótipo foi desenvolvido para a derivação de groupware a partir de

scripts de colaboração descritos em BPMN chamado GroupwareBuilder (GB). O

GB recebe como entrada o nome do groupware a ser criado e o arquivo XML

que representa o script de colaboração descrito conforme apresentado na Seção

3.2. Esse arquivo XML é gerado automaticamente pelo software Bonita Open

Studio usado para a modelagem dos scripts. De posse desse XML, o GB analisa

o documento, identificando os grupos, os papeis, as atividades, a ordem de

1

61

realização dessas atividades e os serviços descritos para apoiar as atividades.

Cada serviço deve ser derivado da linha de produtos de serviço correspondente.

O GB identifica então esses serviços, e a partir da tabela com os links de

rastreabilidade, o GB instancia os componentes e gera o arquivo de

configuração de cada componente de acordo com as features identificadas.

Após gerar e configurar todos os serviços descritos no script de colaboração, o

GB configura a aplicação base do GW, feita através de arquivos de

configuração. Essa aplicação base consiste em um groupware sem nenhum

serviço instanciado, e sem nenhuma atividade associada (núcleo da linha de

produtos de groupware). Após a geração e configuração desses arquivos, o

groupware está pronto para ser usado. A Figura 18 ilustra o funcionamento do

GroupwareBuilder.

Figura 18. Esquema de derivação de groupware com o

GroupwareBuilder.

O GroupwareBuilder possibilita a geração de groupware adaptado às

necessidades de colaboração de seus usuários escritas nos scripts de

colaboração. Dessa forma, o papel de derivar o groupware passa a ser do

próprio usuário diminuindo sua dependência de um desenvolvedor de software.

O usuário é capaz de criar scripts de colaboração, submeter ao GB e avaliar se o

seu groupware está adequado às suas necessidades. Caso não esteja satisfeito

2

62

com o groupware gerado, o usuário tem a possibilidade de alterar o script de

colaboração e submeter novamente ao GB até que obtenha o groupware

desejado. Se o problema da adequação do groupware desejado às

necessidades do usuário for em decorrência dos poucos serviços disponíveis, ou

do mal funcionamento de um deles, o usuário, então, solicita uma manutenção

ao desenvolvedor de software. O desenvolvedor avalia a solicitação. Se o

problema for o mal funcionamento de algum componente de software, o

problema é corrigido e o usuário deve ser notificado da correção. Caso o

problema seja a necessidade de disponibilizar uma nova funcionalidade a algum

serviço, essa nova funcionalidade deve ser implementada gerando novos

componentes de software. Isso implica em atualização da LPS, onde novas

features serão criadas, novas ações disponibilizadas e a tabela dos links de

rastreabilidade são atualizadas. Esse processo de derivação, verificação da

adequação do produto e possíveis atualizações da LPS estão representadas na

Figura 19. O processo sistematiza a manutenção e criação de componentes do

Groupware Workbench e, consequentemente, a evolução das LPS.

Figura 19. Evolução da linha de produtos.

A seguir é descrita a avaliação da proposta de derivação de groupware a

partir de scripts de colaboração apresentada nessa pesquisa.

4 Avaliação

A avaliação da solução apresentada nessa tese foi realizada em 2 etapas:

avaliação funcional da solução e um estudo de caso com professores para

avaliar a derivação de groupware a partir dos scripts de colaboração. Na primeira

avaliação, o objetivo foi obter uma prova de conceito da arquitetura proposta,

enquanto o objetivo do estudo de caso foi obter uma avaliação da proposta a

partir de professores, potenciais usuários.

4.1. Avaliação funcional da solução

A avaliação funcional da solução proposta consiste na derivação de

groupware através da linha de produtos definida na seção 3.3. Para tanto,

selecionou-se duas técnicas de aprendizagem colaborativa distintas a serem

descritas como script de colaboração, a saber: Debate Crítico (Critical Debate) e

Buzz Groups[10]. A primeira é uma variante da técnica Controvérsia Acadêmica

e tem por objetivo fazer com o que os estudantes tomem um posicionamento em

relação ao assunto estudado contrário ao seu próprio ponto de vista. A segunda

técnica tem por objetivo incentivar uma discussão com toda a turma, a partir de

discussões informais em grupos menores sobre o tema em estudo.

A escolha do Debate Crítico deu-se por ser uma variante de uma das

técnicas usadas na concepção da LPS definida na seção 3.3 e teve o objetivo de

evidenciar a possibilidade de derivação de groupware de suporte a técnicas

ligeiramente diferentes das usadas no desenvolvimento da linha de produtos. Já

a escolha do Buzz Groups teve por objetivo mostrar que a LPS também é capaz

de derivar groupware de suporte a outras técnicas de aprendizagem

colaborativa.

A seguir são apresentadas as representações em scripts de colaboração

das técnicas selecionadas para a avaliação funcional, bem como suas

implementações nos groupware derivados.

4

64

4.1.1. Debate Crítico

No Debate Crítico, o professor deve selecionar um assunto controverso,

identificar dois posicionamentos opostos e organizar os estudantes em grupos

“Pró” e “Contra” tendo em mente que o papel que cada estudante deve

desempenhar o papel contrário às suas opiniões pessoais. Após a criação dos

grupos, cada grupo deve ter um tempo para pesquisar e discutir seus

argumentos em um fórum de discussões separado. Após essa discussão, os

grupos unem-se em uma discussão única defendendo suas posições originais e

em busca de um alinhamento de idéias.

A Figura 20 ilustra o script de colaboração criado a partir da modelagem da

técnica descrita acima. A modelagem foi feita seguindo as definições

apresentadas na seção 3.2. A primeira pool “Grp: Debate Critico” representa

todos os estudantes que vão participar da aplicação da técnica. As lanes “Pro”,

“Contra” e “Turma”, representam os papéis que os estudantes assumem durante

as atividades. O papel “Pro” deve ser atribuído as estudantes que possuem

opinião contrária à questão em estudo e devem, durante a dinâmica, argumentar

a favor da questão. O papel “Contra”, em contrapartida, deve ser atribuído aos

estudantes que possuem opinião favorável à questão em estudo e devem,

durante a dinâmica, argumentar contra a questão. O papel “Turma” deve ser

atribuído a todos os estudantes na ocasião do debate geral, onde eles devem

usar os argumentos elaborados anteriormente para discutir em profundidade

buscando o alinhamento de idéias com toda a turma. As atividades

representadas são (1) “Argumentacao Contra”, (2) “Argumentacao Pro” e (3)

“Debate Geral”. Na seqüência, a figura ilustra ainda os requisitos para cada

serviço que vai dar suporte ao Debate Crítico. Foram criados 3 instâncias de

fóruns de discussão. Uma instância para dar suporte a cada atividade

identificada. Os fóruns das atividades 1 e 2 possuem as mesmas características

de categorização de mensagens e organização da lista de mensagens de acordo

com essas categorias. O fórum da atividade 3 difere-se dos anteriores apenas

com relação às categorias que serão disponibilizadas, uma vez que este terá

uma categoria específica para que os estudantes postem o resumo da

discussão. A modelagem da técnica de aprendizagem colaborativa e dos

serviços de suporte completa as especificações do desiner formalizadas no

script de colaboração.

5

65

Figura 20. Script de Colaboração para a técnica Deb ate Crítico.

Modelado com o Bonita Open Studio.

Terminada a elaboração do script de colaboração, realizou-se a

exportação da modelagem BPMN para um arquivo XML a ser submetido para o

sistema de derivação prototipado para esta pesquisa, o GroupwareBuilder (GB).

6

66

A exportação para XML foi feita com o uso do mesmo software usado para a

elaboração dos modelos do script de colaboração, o Bonita Studio [62].

O XML foi, então, submetido ao GB para a derivação e configuração do

groupware. O GB analisa o documento XML e verifica quais são os grupos,

papéis, tarefas e serviços descritos no script de colaboração. Para cada serviço

identificado, o GB verifica quais são as ações que devem ser disponibilizadas,

consultando as tabelas que relacionam as ações com as features relativas às

linhas de produto de cada serviço. Cada serviço derivado corresponde a um

Collablet no Groupware Workbench (GW). O processo de derivação do

groupware ocorre como descrito na Seção 3.4.

Para efeito de testes do groupware do Debate Crítico considerou-se como

tópico de debate a questão: “Você é a favor ou contra a divisão do estado do

Pará em mais 2 novos estados?”. A questão apresentada possui dois

posicionamentos opostos que devem ser explorados pelos estudantes durante a

aplicação do método com o suporte do groupware gerado.

A sequência de figuras a seguir ilustra as telas do groupware derivado para

dar suporte ao Debate Crítico. A Figura 21 mostra uma tela do módulo de

administração do groupware, na opção de “Cadastro de Tarefas” onde é possível

cadastrar as instruções e objetivos das atividades que os alunos deverão

executar. No exemplo da figura, o objetivo da atividade “Argumentação Contra” é

fazer com que os estudantes elaborem e discutam argumentos que suportem o

posicionamento contrário à divisão do estado do Pará, conforme a questão de

debate definida.

Figura 21. Tela de administração do groupware. Cada stro de tarefas.

7

67

A Figura 22 ilustra a opção de atribuição de papéis aos usuários do

groupware, ainda no perfil de administração do groupware. Os usuários do

groupware, neste caso, são os estudantes que deverão participar dos debates.

Nesta opção, o professor seleciona os estudantes que se posicionarão

favoráveis à questão da divisão do estado do Pará, selecionando o papel

“Debate Crítico.Pro”, e os estudantes deverão se posicionar desfavoráveis à

questão debatida.

Figura 22. Tela de atribuição dos papéis aos usuári os do groupware.

A tela inicial dos usuários de groupware que será acessada pelos

estudantes é ilustrada na Figura 23. Nela é exibido o script de colaboração

definido, com as atividades e seu o período que devem ser executadas. Para um

estudante, só as atividades relacionadas aos papéis a ele atribuídos serão

acessíveis.

Figura 23. Tela inicial do perfil de usuário do gro upware.

Conforme definido na descrição do Debate Crítico, cada uma das

atividades de argumentação tem seu fórum privado, onde os estudantes

discutem e elaboram argumentos de acordo com o seu papel. E após essa

etapa, a turma inteira se une para uma discussão geral, onde os argumentos

levantados serão usados no aprofundamento da discussão. A Figura 24 mostra a

8

68

tela da atividade “Debate Geral” com o serviço “Fórum Geral”. Verifica-se a que

as mensagens do fórum são listadas de acordo com categorias pré-definidas

para a atividade.

Dado que o Debate Crítico é uma variante da Controvérsia Acadêmica, as

mensagens são organizadas nas categorias definidas por Mendonça 2003 [12]

que são: (a) Concordo: que é usada quando o estudante concorda com a

questão a ser debatida ou resposta dada; (b) Discordo: que é usada quando o

estudante tem uma opinião diferente da levantada a respeito da questão

estudada e; (c) Depende: que é usada quando o estudante quer expressar os

dois lados da questão em debate. Segundo a autora, essa organização mantém

o foco da discussão na questão de estudo, evitando assim, que haja dispersão

dos alunos em assuntos relacionados que poderiam ser aninhados em fóruns

tradicionais. No fórum da atividade “Debate Geral” consta ainda a categoria

“Resumo”, onde os estudantes podem postar as conclusões parciais do debate

ou anotações pertinentes para a elaboração do resumo final da discussão.

Figura 24. Tela da atividade Debate Geral.

A linha de produtos desenvolvida teve o Versus, groupware de suporte a

Controvérsia Acadêmica, como um dos groupware analisados na etapa de

análise de domínio dos serviços disponibilizados. Isso possibilitou a derivação

bem sucedida do groupware para o Debate Crítico, conforme descrito nessa

seção.

9

69

4.1.2. Buzz Groups

Buzz Groups consistem em grupos de quatro a seis estudantes que são

formados rapidamente e sem nenhum critério específico para responder a

questões relacionadas a um curso. Cada grupo pode responder a uma ou mais

questões; todos os grupos podem discutir as mesmas questões, ou questões

diferentes. A discussão é informal e os estudantes não precisam chegar num

consenso, devendo apenas trocar ideias acerca do tema em estudo. A técnica

do Buzz Groups serve como um aquecimento para uma discussão com toda a

turma. Uma vez formados os grupos, deve-se solicitar que os participantes dos

grupos respondam às questões levantadas pelo professor. Após essa discussão

inicial, pode-se unir a turma inteira em um único grupo para um debate em maior

profundidade.

A Figura 20Figura 25 ilustra o script de colaboração criado a partir da

modelagem da técnica descrita acima. A modelagem foi feita seguindo as

definições apresentadas na seção 3.2. A primeira pool “Grp: Buzz Groups”

representa todos os estudantes que participarão da aplicação da técnica. As

lanes “Grupo A”, “Grupo B”, “Grupo C” e “Turma”, representam os papéis que os

estudantes assumem durante as atividades. Nesse script, os grupos foram

modelados como papéis, assim, os participantes de um determinado papel

pertencem ao mesmo grupo. Vale ressaltar que esta é apenas uma das

diferentes formas de representar a técnica. Outra forma é representar cada

grupo em uma nova pool separada. Cabe ao designer da colaboração definir a

melhor forma de representar seu script de colaboração. O papel “Turma” deve

ser atribuído a todos os estudantes na ocasião do debate geral com toda a turma

sobre o tema em estudo. As atividades representadas são (1) “Discussao A”, (2)

“Discussao B”, (3) “Discussao C” e (4) “Discussao Geral”. Na sequência, a figura

ilustra ainda os requisitos para cada serviço que vai dar suporte ao Buzz Groups.

Foram criados quatro instâncias de fóruns de discussão. Uma instância para dar

suporte a cada atividade identificada.

A modelagem da técnica de aprendizagem colaborativa e dos serviços de

suporte completa as especificações do designer formalizadas no script de

colaboração.

0

70

Figura 25. Script de Colaboração para a técnica Buz z Groups.

Modelado com o Bonita Open Studio.

1

71

Terminada a elaboração do script de colaboração, realizou-se o

procedimento para a exportação da modelagem BPMN para um arquivo XML a

ser submetido para o sistema de derivação prototipado para esta pesquisa, o

GroupwareBuilder (GB). A derivação ocorre de maneira análoga à apresentada

na seção anterior.

A sequência de figuras a seguir ilustra as telas do groupware derivado para

dar suporte ao Buzz Groups. A Figura 26 mostra uma tela do módulo de

administração do groupware, na opção de “Cadastro de Tarefas” onde é possível

cadastrar as instruções e objetivos das atividades que os alunos deverão

executar. No exemplo da figura, o objetivo da atividade “Discussao Geral” é fazer

com que os estudantes discutam com toda a turma sobre o tema central de

estudo definido pelo professor.

Figura 26. Tela de administração do Buzz Groups.

Cadastro de Tarefas.

A Figura 27 ilustra a opção de atribuição de papéis aos usuários do

groupware, ainda no perfil de administração do groupware. Lembrando que

neste exemplo, como a técnica modelada não indica o uso de perfis específicos

para os usuários, os papéis foram usados para identificar os grupos conforme

mencionado anteriormente. Nesta opção, o professor seleciona os estudantes

que farão parte de cada grupo, atribuindo a ele o papel do grupo

correspondente.

2

72

Figura 27. Tela de atribuição dos grupos (papéis) a os usuários

do Buzz Groups.

A Figura 28 ilustra a tela inicial de um usuário do groupware. No caso da

figura, o usuário Bruno pertence ao “Grupo A” e ao grupo “Turma” que deve

conter todos os estudantes participantes do groupware. Assim, as únicas

atividades que aparecem clicáveis para o usuário são aquelas associadas ao

grupo ao qual ele pertence.

Figura 28. Tela inicial do perfil de usuário do Buz z Groups.

Com a geração do groupware para a técnica Buzz Groups realizada com

sucesso, encerra-se a etapa de avaliação funcional da LPS desenvolvida. A

próxima etapa na avaliação corresponde a um estudo de caso realizado para

observar como se daria a derivação de groupware para outras técnicas de

aprendizagem colaborativa modeladas por diferentes professores. A próxima

seção detalha o estudo de caso realizado.

3

73

4.2. Estudo de Caso

Um grupo de professores foi convidado para usar a arquitetura proposta. A

tarefa dada aos professores foi elaborar um script de colaboração através da

formalização de uma técnica de aprendizagem colaborativa e derivar um

groupware desse script usando o protótipo “GroupwareBuilder” fornecido pelo

pesquisador e que implementa a arquitetura proposta. Um protocolo foi definido

previamente e seguido para todo o estudo. Dados qualitativos foram coletados,

categorizados e analisados com o objetivo de avaliar a hipótese de pesquisa e

aumentar o conhecimento sobre o desenvolvimento de groupware e scripts de

colaboração. A seção de estudo de caso é organizada da seguinte maneira: a

preparação e realização do estudo de caso, com a descrição do protocolo usado,

são descritas na seção 4.2.1; Apesar de terem sido obtidos indícios que indicam

a confirmação da hipótese de pesquisa, mais estudos ainda precisam ser

realizados, conforme discutido na Seção 4.2.2, pois alguns problemas foram

identificados durante o estudo.

4.2.1.Protocolo para a realização do estudo de caso

O protocolo definido para a realização desse estudo de caso é

representado na Figura 29.

Figura 29 - Protocolo para realização do estudo de caso.

A primeira atividade do protocolo consiste na seleção das técnicas de

aprendizagem colaborativa a serem representadas em um modelo usando o

subconjunto de elementos do BPMN, conforme definido na Seção 3.2. A

atividade seguinte consiste na preparação de material explicativo sobre o uso do

subconjunto de elementos do BPMN para os participantes da pesquisa. Um

questionário de pesquisa é elaborado previamente. O passo seguinte do estudo

4

74

é selecionar os participantes. Os participantes devem ser voluntários, mas que

tenham experiência com educação. As tarefas devem ser definidas previamente,

com tempo de execução estimado e comunicado aos participantes. Durante a

execução da tarefa pelos participantes, o pesquisador assume o papel de

observador fazendo anotações e gravações em áudio e vídeo. Após a realização

das tarefas, os participantes preenchem o questionário elaborado. Por fim, a

última atividade do protocolo consiste na análise dos dados coletados pelas

observações e questionários respondidos.

As técnicas de aprendizagem colaborativas selecionadas para o estudo de

caso foram extraídas de Barkley et. al. [10]. Além da descrição das técnicas, o

autor sugere ainda como cada uma dessas técnicas deve ser aplicada com o

uso de tecnologias computacionais. Foram selecionadas as técnicas nas quais o

autor sugere o uso de fóruns de discussão ou repositório de arquivos, uma vez

que esses serviços foram disponibilizados no protótipo usado.

O questionário elaborado para essa pesquisa contou com questões

abertas e fechadas e consistiu em três partes: (1) questões relativas ao perfil do

participante; (2) questões relativas à representação das técnicas de

aprendizagem colaborativa com o subconjunto de elementos BPMN e (3)

questões relativas ao processo de derivação e adequação do groupware

derivado à técnica modelada.

A maioria dos 12 participantes do estudo de caso é do sexo feminino. O

grau de escolaridade é alto no grupo de participantes: a maioria é mestre ou está

cursando doutorado, e um dos participantes é doutor. Com relação à experiência

com informática, a maioria dos participantes declarou ser usuário avançado.

Metade dos participantes da pesquisa declarou já haver aplicado alguma técnica

de aprendizagem colaborativa. Estes dados sobre o perfil dos participantes estão

representados na Figura 30.

5

75

Figura 30. Perfil dos participantes

Nos gráficos da Figura 31 é ilustrado o grau de familiaridade dos

participantes com os conceitos relacionados à pesquisa. Ao ser perguntado

sobre a familiaridade com groupware, todos os usuários declararam já ter tido

algum contato com esse tipo de sistema. Com respeito à familiaridade com

técnicas de aprendizagem colaborativa, apenas um usuário declarou total

desconhecimento (o que não era esperado).

6

76

Figura 31. Familiaridade com conceitos da pesquisa

Foi realizada uma análise qualitativa dos dados levantados através do

questionário elaborado e das observações realizadas durante a realização das

atividades pelos participantes da pesquisa. Para analisar os comentários dos

participantes nas perguntas abertas, foi usada a técnica descrita no método

MEDS [63]. Nesta pesquisa, foram usados pseudônimos para fazer referência

aos participantes durante as descrições de citações. Alguns trechos das citações

foram aqui destacados com negrito para enfatizar a relevância para o tópico em

discussão. Os resultados dessa análise são descritos nas próximas seções.

4.2.2. Resultados obtidos

Todos os participantes conseguiram derivar o groupware apesar da

dificuldade que tiveram com a linguagem selecionada para formalizar as técnicas

de aprendizagem colaborativa. A hipótese dessa pesquisa é “Se a arquitetura

proposta for usada, então será possível derivar um Groupware adequado para a

técnica de trabalho em grupo formalizada pelo usuário”. Todos os participantes

consideraram o groupware derivado como pelo menos parcialmente adequado, o

que dá indícios da confirmação da hipótese dessa pesquisa e sugere mais

7

77

investigações para compreender os casos nos quais o groupware foi

considerado parcialmente adequado. As subseções seguintes foram definidas

em função das categorias que emergiram a partir da análise qualitativa realizada

nas respostas abertas do questionário de pesquisa enviado.

A linguagem usada tem expressividade limitada

Uma das tarefas dadas para os participantes foi a elaboração do script de

colaboração. Para elaborar o script, o participante deveria modelar com BPMN

uma técnica de aprendizagem colaborativa conforme o conteúdo explicativo

fornecido pelo pesquisador.

Durante a modelagem da técnica, os participantes sentiram a

necessidade de representar algumas situações e estruturas que não foram

contempladas. Entre as situações não contempladas, destaca-se a

necessidade de representação de atividades cíclicas, conforme destacado pela

participante Cláudia (pseudônimo) na citação a seguir:

“Na descrição do método poderia ser permitido inserir atividades

cíclicas.” (Cláudia).

As participantes Cássia, Vitória e Dalila, destacaram a ausência de

elementos para representar atividades condicionais, restrições para realização

de alguma atividade, e principalmente a falta de uma forma de representar a

ligação entre tarefas de grupos representados por diferentes Pools no diagrama

BPMN.

“Alguns casos que não consegui representar: - Linhas de

comunicação entre tarefas que se encontravam em diferentes pools. -

Conectores condicionais. - Paralelismo entre tarefas. - Loops nas tarefas."

(Cássia).

“... senti falta de mais clareza em relação às atividades paralelas,

condicionais, possíveis restrições, ordem de realização além da utilização

de setas, etc...” (Vitória).

8

78

“A linguagem utilizada só permite a definição de sequências de

etapas dentro de um mesmo ‘pool’, o que limita a representação de

processos que envolvam etapas realizadas por diferentes grupos.” (Dalila).

A expressividade limitada da linguagem usada na pesquisa resultou numa

maior dificuldade na representação das técnicas de aprendizagem colaborativas,

conforme ilustrado no gráfico da Figura 32, obtido a partir de perguntas fechadas

do questionário enviado. Observa-se que a maior parte dos participantes

classificou a representação do script com notas 3 ou 4 (0 = Muito Fácil e 5 =

Muito Difícil). Uma conclusão que se pode tirar dessa tendência de resposta

mais à direita é que os participantes consideraram difícil representar os scripts

com a linguagem sugerida.

Figura 32. Dificuldade de representação da técnica de aprendizagem

colaborativa

“A ausência de elementos de representação limita a expressividade

do professor(...)” (Ulisses).

Por fim, o participante Ulisses destacou que a limitação da expressividade

da linguagem também limita o professor, dando, dessa forma, indícios da

inadequação da linguagem para o uso com professores, como discutido na

próxima seção.

9

79

A linguagem usada é inadequada para professores se m formação em informática

Representar formalmente situações ou problemas em uma linguagem

estruturada e gráfica é uma habilidade que pessoas com formação em

informática aprendem a desenvolver, uma vez que é requerida para o exercício

da profissão. Em outras formações, no entanto, tal habilidade nem sempre é

desenvolvida ou explorada.

Nesta pesquisa, a participante Dalila – que teve experiências na

implantação de cursos à distância usando diferentes plataformas, e também já

trabalhou com professores de diferentes formações – pôde perceber que a

representação sob a forma de processos em BPMN não é uma tarefa facilmente

realizada por esses professores. Sua narrativa é apresentada a seguir:

“O software utilizado poderia ter uma interface mais amigável, que

fosse mais próxima à realidade de um educador, que não está

acostumado a pensar seu planejamento pedagógico com o um

processo . Creio que a forma de descrição do(s) processo(s) ainda está

complexa para usuários que não tenham experiência prévia com este tipo

de linguagem.” (Dalila)

Cláudia é uma participante que também possui formação em informática e

atua como tutora em cursos de educação à distância. Ao participar do estudo,

colocou-se no papel de professora apenas e comentou a necessidade de

familiarização com a proposta de representação. Seu comentário corrobora a

narrativa de Dalila na ideia de que representar práticas pedagógicas através de

processos não é uma atividade trivial, requerendo assim um esforço cognitivo

maior de educadores com formação não tecnológica.

“A dificuldade é somente no início, pois precisamos nos familiarizar

com a forma de representação proposta .” (Cláudia)

Vinícius é o único educador participante da pesquisa que não possui

formação em informática. Formado em letras e pedagogia, atua em sala de aula

ministrando disciplinas de língua portuguesa, literatura e artes. Ao ser

questionado acerca do poder de representação da linguagem de representação,

respondeu:

0

80

“No primeiro contato não ficou claro o papel de cada ícone

representativo.” (Vinícius)

Uma análise intra-participante [63] das citações do Vinícius possibilitou a

percepção do quão recorrente (e importante) é a dificuldade de usar uma

linguagem gráfica para representar o script de colaboração. A seguir, um recorte

de seus comentários relativos à linguagem gráfica usada:

“(1)No primeiro contato não ficou claro o papel de cada ícone

representativo ... (2)Após a dificuldade inicial em decodificar os ícones

não foi difícil criar o sistema.... aconteceu sem grandes problemas, (3)fora

a dificuldade inicial em me familiarizar com o programa...” (Vinícius)

Em três diferentes trechos de seu depoimento, o participante repetiu a

dificuldade em lidar com a representação gráfica do trabalho em grupo. Dessas

narrativas obtêm-se indícios de que qualquer linguagem gráfica usada é

estranha para professores sem formação em informática. Em função dessa

dificuldade em representar graficamente, faz-se necessária uma investigação do

uso dessa abordagem a partir da definição do processo em linguagem natural,

por exemplo, lista simples de tarefas, ou lista hierárquica de tarefas.

Indícios de adequação do groupware derivado

Após representada a técnica de aprendizagem colaborativa, cada

participante submeteu seu script de colaboração ao protótipo GroupwareBuilder

para a derivação do groupware específico para o script submetido. Após isso, os

participantes acessaram seus groupware a fim de verificar a adequação do

produto no suporte à técnica modelada.

Embora os participantes tenham relatado algumas dificuldades na

elaboração dos scripts de colaboração em virtude da expressividade limitada da

linguagem ou da pouca experiência em modelar práticas pedagógicas como

processos, todos conseguiram derivar e avaliar seu groupware. Nenhum dos

participantes declarou que o groupware estivesse totalmente inadequado às

suas especificações, conforme os dados apresentados na Figura 33.

1

81

Figura 33. Adequação do groupware ao script de cola boração.

Alguns participantes declararam que o groupware estava parcialmente

adequado às suas especificações, como no caso da Vitória. A participante é

experiente na aplicação de técnicas de aprendizagem colaborativas tanto sem o

suporte de tecnologia como com o suporte tecnológico. Em sua narrativa,

descrita a seguir, Vitória afirma não ter dúvidas com relação à adequação do

groupware à técnica modelada. Porém, devido à sua experiência, considera mais

produtivo implementar uma das etapas do método de forma presencial. Essa

opção se deu uma vez que entre os serviços disponibilizados no protótipo da

pesquisa não tinha um serviço para a comunicação síncrona de participantes,

como por exemplo, um Batepapo (chat). Vitória chega a dizer que, se houver um

serviço de suporte à comunicação síncrona, todos os requisitos para a aplicação

da técnica modelada seriam cumpridos a contento.

"Sem dúvida, o groupware atende o método . Mas para alcançar a

total adequação, é aconselhável que existam ferrame ntas síncronas ,

para permitir maior contato com os alunos durante as discussões. Optei

por definir uma das atividades de forma presencial , justamente por

essa dificuldade..." (Vitória).

Outros participantes declararam total adequação do groupware ao script de

colaboração, como no caso de Eduardo, Ulisses e Laís. Porém, em suas

narrativas pode-se observar uma dúvida quanto à adequação de outros produtos

para outras técnicas colaborativas, dado que os participantes foram cuidadosos

ao usar em suas falas expressões com: “execução da técnica” ou “para o meu

processo”, etc.

2

82

“O groupware gerado está de acordo, isto é fornecendo todas as

funcionalidades necessárias para execução da técnica de aprendizagem”

(Eduardo).

“A linha de produto disponibilizada tinha tudo que eu precisava para

o meu processo” (Ulisses).

“GroupwareBuilder implementou as minhas especificações de

maneira correta” (Cássia).

“O groupware se adequa perfeitamente aos requisitos do método

de aprendizagem colaborativa investigação em grupo.” (Laís).

Apesar de todos os participantes declararem que o groupware derivado

implementa, de fato, todos os requisitos das técnicas modeladas, não se pode

afirmar com precisão que a abordagem usada nessa pesquisa é capaz de

derivar qualquer técnica de aprendizagem colaborativa. Os dados obtidos,

entretanto, dão indícios dessa possibilidade.

Alteração de scripts em tempo de execução

Na literatura discute-se que scripts pré-definidos limitam a emergência

espontânea de novas formas de colaboração [1, 64]. Isso não representa

propriamente um problema na abordagem proposta, uma vez que o usuário pode

alterar o groupware ou sua configuração em tempo de execução. O recurso de

alteração em tempo de execução, por sua vez, não é facilmente percebido pelos

usuários como se pode inferir por meio do relato de um participante, transcrito a

seguir:

“Eu gostaria de poder representar os processos com mais detalhes e

variações. Do jeito que eu fiz o grupo fica restrito àquela prática

descrita . Se o próprio grupo perceber durante a atividade que o método

não está muito adequado para eles não tem como modificar .” (Tânia).

É possível que um problema de usabilidade do protótipo tenha influenciado

na experiência dessa participante. Testes de usabilidade serão aplicados em

trabalhos futuros para investigar a interveniência do protótipo e para apoiar o

desenvolvimento de novas versões.

3

83

Relevância da solução proposta para CSCL

Essa tese foi desenvolvida no contexto de um grupo dedicado à pesquisa e

ao desenvolvimento de groupware. A afinidade do grupo com a área de

Sistemas Colaborativos é grande e nessa tese buscou-se uma contribuição

relevante para a área de CSCL, subárea de Sistemas Colaborativos. Os

participantes, a maior parte deles mestres e doutorandos, tem conhecimento de

Sistemas Colaborativos e participam (ou participaram) da comunidade de

sistemas colaborativos ou usam sistemas colaborativos para o trabalho. Os

relatos obtidos desse grupo de participantes dão indícios da relevância da

pesquisa dessa tese para a área, conforme o recorte inter-participantes

destacado a seguir:

“...facilitaria a vida de professores que trabalham com ambientes

virtuais de aprendizagem... O fato de ser necessária somente uma

modelagem das atividades para que as mesmas sejam inseridas em um

AVA de forma automática evitaria contratempos e montagens erradas de

ambientes” (Cláudia: considera relevante para a área de EaD e para a prototipação de

groupware)

“Com adaptações na interface, a ferramenta será bastante útil para

um professor que queira aplicar um método colaborativo...” (Vitória: considera

a proposta relevante para a área de CSCL)

“...a geração do groupware do método foi perfeita; muito adequada

para o método de aprendizagem. Se há 10 anos houvesse ferramentas

como essas disponíveis para uso, teriam enriquecido meu estudo de caso

no mestrado.” (Laís: considera relevante para prototipação em CSCL)

“Se eu tivesse essa ferramenta, com certeza utilizaria, mesmo que

atualmente esteja trabalhando com educação presencial, acho que essa

ferramenta poderia colaborar e ser utilizada para auxiliar no aprendizado

dos alunos.” (Fabiana: considera relevante para a colaboração face-a-face)

Em função dos comentários dos participantes, é possível concluir que a

proposta dessa tese foi considerada relevante para a área de CSCL.

4

84

Entrega de produtos customizados

A entrega de produtos de software customizados às necessidades

específicas dos usuários é uma das vantagens inerentes ao uso de LPS. Essa

vantagem pôde ser observada também durante a realização dessa pesquisa.

Cássia, em seu discurso, deixa claro essa vantagem no uso do protótipo

dessa pesquisa ao repetir a expressão “meu” em diferentes momentos e finalizar

destacando que o groupware derivado através do GroupwareBuilder é

personalizado para as suas definições. Além de perceber que o seu groupware é

personalizado para a técnica que representou, a participante percebeu também

que poderia ser criada uma técnica completamente nova, personalizada para as

suas necessidades, e após modelar a técnica, ter um groupware de suporte à

essa nova técnica.

“possibilitou a geração do meu método de ensino e a associação

das tarefas do método para serviços de tal forma que possa criar o meu

próprio método numa ferramenta personalizada ” (Cássia).

Diferente de Cássia, que percebeu num nível mais geral as possibilidades

de uso do protótipo, Tânia percebeu que as customizações do seu groupware

podem ser realizadas no nível da configuração dos serviços disponibilizados no

groupware. Em sua narrativa, ela destaca que podem ser criadas diferentes

instâncias de fóruns para dar suporte a diferentes situações de aprendizagem

em um curso.

“uma ferramenta como a testada pode ser utilizada para configurar

fóruns diferentes para cada situação de aprendizagem dentro de uma

disciplina” (Tânia).

As visões de Cássia e Tânia são complementares, dado que as

possibilidades de customização do protótipo desenvolvido acontecem nos dois

níveis:

1. Seleção de serviços . Nível de customização percebido por Cássia, que

consiste na seleção dos serviços que devem ser alocados para cada tarefa e

papel de usuário dentro do groupware.

2. Configuração de serviços . Nível de customização percebido por Thaís, que

consiste na seleção das características de cada serviço disponível. Trata da

5

85

variabilidade das features dos serviços. Como exemplo, para dar suporte a

uma atividade, pode ser necessária a criação de um serviço de mural de

recados e outro serviço de fórum com mensagens listadas hierarquicamente.

Os dois serviços são derivados a partir da mesma linha de produtos de

fóruns, porém são instâncias diferentes, com funcionalidades diferentes.

Essa customização dos produtos em níveis diferentes aumenta as

possibilidades de uso da abordagem, conforme detalhado na próxima seção.

Possibilidades de uso da abordagem

Alguns participantes destacaram em suas narrativas a possibilidade de uso

da abordagem de derivação de groupware a partir das descrições de scripts de

colaboração. Como exemplo, Vitória que já havia tido a experiência de

desenvolver groupware adequado a uma técnica de aprendizagem colaborativa

na ocasião de sua dissertação de mestrado e conhecia a complexidade

envolvida nesse desenvolvimento destaca que a forma de se obter groupware

específico para uma técnica de aprendizagem colaborativa apresentada nessa

pesquisa é simplificada. A participante se identificou com a pesquisa e percebeu

a possibilidade de generalizar o uso do protótipo para “vários métodos de

trabalho em grupo na web”. Observa-se que ela não se ateve apenas ao cenário

da aprendizagem colaborativa, mas sim do trabalho em grupo com suporte

computacional.

“A possibilidade de utilizar uma ferramenta para criação de

ambientes de groupware para métodos de aprendizagem cooperativa de

forma simplificada gera muitas possibilidades de uso pedagógico de

vários métodos para trabalho em grupo na web.” (Vitória)

Nina e Valéria também destacam o potencial uso da abordagem

pesquisada nesta tese em cenários diferentes do pesquisado. Diferentemente de

Nina que não detalhou os outros possíveis usos da abordagem, Valéria observou

a aplicabilidade da proposta no seu ambiente de trabalho, que é de

desenvolvimento de software. Dessa forma, a participante aponta o uso da

abordagem para a geração não apenas de groupware, mas também de outros

tipos de software que tenha seu comportamento/funcionamento registrado como

em modelos de processos de negócio com BPMN.

6

86

“A abordagem é interessante e pode ser estendida para outros

usos ...” (Nina)

“... durante o experimento percebi que pode ser aplicada em outros

contextos que não o educacional (...) Você não poderia apresentar essa

proposta lá no meu trabalho? Nós trabalhamos com BPMN e

desenvolvimento de sistemas. Esse teu trabalho aceleraria muito as

coisas...” (Valéria).

4.3. Discussão

Esse capítulo apresentou a avaliação da abordagem de desenvolvimento

de groupware baseada em linha de produtos de software descrita nessa tese.

Essa avaliação aconteceu em duas etapas: (1) avaliação funcional e (2) estudo

de caso.

A avaliação funcional teve por objetivo obter uma prova de conceito da

arquitetura desenvolvida. Ou seja, verificar se a LPS era capaz de gerar

groupware alinhado às especificações de scripts de colaboração. Para essa

verificação, selecionou-se duas técnicas de aprendizagem colaborativa distintas:

Debate Crítico e Buzz Groups.

O Debate Crítico consiste em uma variação da técnica da Controvérsia

Acadêmica que foi usada para a especificação das features da LPS. Logo, a

expectativa era de que o groupware derivado atendesse a todos os requisitos

impostos pela técnica. Para esse teste inicial, a expectativa foi atendida, porém

restava-se saber se a arquitetura também era capaz de derivar um groupware

para uma técnica diferente das três usadas na especificação da LPS. Então a

técnica Buzz Groups foi especificada como um script de colaboração e

submetida ao processo de derivação de groupware, o que aconteceu a contento.

Assim, a avaliação funcional foi encerrada com a geração de dois groupware

distintos de suporte a técnicas de aprendizagem colaborativa distintas.

A etapa seguinte teve como objetivo obter uma avaliação da arquitetura

desenvolvida a partir de professores, que são os seus potenciais usuários. Para

tanto foi realizado um estudo de caso. Nesse estudo de caso buscou-se avaliar:

(1) a linguagem de representação dos scripts de colaboração; (2) o processo de

derivação do groupware a partir dos scripts de colaboração e (3) a adequação do

groupware à técnica de aprendizagem colaborativa descrita pelos scripts.

7

87

Com respeito à linguagem de representação dos scripts de colaboração, a

maioria dos participantes do estudo de caso classificou a dificuldade da

utilização da linguagem como mediana ou difícil, de baixa expressividade e

inadequada para professores sem formação em informática. No entanto, todos

os participantes conseguiram concluir a tarefa de especificação do script de

colaboração. Isso se deve, em parte, ao fato da maioria dos participantes serem

usuários com conhecimentos avançados em computação. Apenas um dos

participantes tinha formação não tecnológica, o Vinícius. Nesse caso específico,

era esperado haver alguma dificuldade com a forma de descrever visualmente

as atividades da técnica de aprendizagem colaborativa selecionada, uma vez

que o nível de abstração necessário para a descrição da atividade sob a forma

de um processo não é uma habilidade trabalhada nas áreas de letras e

pedagogia, nas quais o Vinícius é formado, porém, isso não foi um fator

impeditivo para que ele conseguisse realizar a atividade.

Algumas decisões de projeto do subconjunto do BPMN a ser usado na

descrição dos scripts de colaboração limitou o poder de expressividade da

linguagem, conforme notado pelos participantes do estudo de caso. Uma das

limitações foi a impossibilidade de representação de atividades cíclicas. Essa

limitação deu-se por conta do protótipo implementado, e não por uma

impossibilidade da linguagem, porém, como o protótipo era o que estava sendo

avaliado, essa limitação foi sentida por alguns dos participantes do estudo de

caso. Outras decisões como a retirada dos gateways e dos artefatos do BPMN

foram tomadas para oferecer um menor número de elementos para os

professores assimilarem, além de tornar o diagrama mais limpo. Porém, os

participantes que já conheciam BPMN ou linguagem similar sentiram a falta

desses elementos.

Ainda acerca da linguagem usada na representação dos scripts, alguns

participantes destacaram a sua inadequação para professores sem formação em

informática. Os participantes alegaram que a representação de práticas

pedagógicas como processos não é uma tarefa trivial, requerendo um esforço

cognitivo maior desses professores. E isso foi observado durante a realização do

estudo de caso com o participante Vinícius, onde mesmo já tendo entendido a

linguagem, teve dificuldades em extrair o processo de atividades a partir da

descrição da técnica de aprendizagem colaborativa que deveria representar.

Mais trabalhos acerca da aceitação da linguagem por professores sem formação

tecnológica se faz necessário.

8

88

Com relação ao processo de derivação do groupware a partir dos scripts

de colaboração descritos na linguagem definida, nenhum dos participantes teve

dificuldades. Isso ocorreu porque o processo está totalmente automatizado, onde

o participante deve apenas acessar o GroupwareBuilder e fazer o upload do

arquivo XML com o script de colaboração gerado automaticamente pela

ferramenta de modelagem usada para a criação dos scripts. Depois desse

processo, o groupware era criado sem nenhuma intervenção do participante.

Após a criação do groupware, o participante deveria avaliar se o groupware

estava de acordo com a modelagem realizada.

Nenhum dos participantes do estudo de caso classificou o groupware

gerado como inadequado para a técnica de aprendizagem colaborativa que

representou. Dos doze participantes, três classificaram o groupware como

“parcialmente adequado” e nove classificaram o groupware como “totalmente

adequado” às especificações. Esse resultado fornece indícios da confirmação da

hipótese dessa tese: “Se a arquitetura proposta for usada, então será possível

derivar um groupware adequado para a técnica de trabalho em grupo

formalizada pelo usuário”. Porém, a hipótese não foi completamente confirmada

devido aos três participantes que classificaram seus groupware como

“parcialmente adequado”. Esses participantes sentiram falta de features não

identificadas previamente na etapa de desenvolvimento da LPS e de serviços de

suporte à comunicação síncrona. Esse fato evidencia a necessidade da evolução

da linha de produtos de software, conforme apresentada na seção 3.4, Figura

19. À medida que a LPS evolui, aumenta também a quantidade e a qualidade

das suas features, atendendo a uma maior variedade de necessidades

específicas de colaboração. Ainda assim, se faz necessária a continuação da

pesquisa com uma LPS mais robusta, com maior número de features atendendo

a um maior número de funcionalidades e suas respectivas variações para que se

possa refutar ou confirmar com mais precisão a hipótese elaborada.

Um aspecto importante que é uma das características principais das LPS

diz respeito à entrega de produtos customizados. Todos os participantes do

estudo de caso conseguiram observar que o groupware derivado era seu,

desenvolvido para atender à sua especificação, ao seu script de colaboração.

Isso levou alguns participantes a refletirem sobre o uso do protótipo

desenvolvido em diversos cenários, criando sua própria técnica de colaboração e

gerando o groupware específico para ela. Alguns participantes também

perceberam a possibilidade de uma especificação em um nível ainda mais fino,

9

89

onde poderiam customizar um determinado serviço de diversas formas

diferentes para atender diversas situações diferentes de colaboração.

A customização do groupware é realizada em dois níveis distintos: o nível

de serviços, onde cada groupware disponibiliza apenas os serviços necessários

à técnica de aprendizagem colaborativa descrita pelo script de colaboração; e o

nível de funcionalidades desses serviços, onde cada serviço pode ser

customizado para atender a necessidades mais específicas de uso. Isso faz com

que a derivação de groupware a partir dos scripts de colaboração possa também

ser utilizada como uma plataforma de prototipação de groupware com

refinamentos sucessivos. Isso significa, por exemplo, que um professor pode

testar diferentes maneiras de configurar o seu groupware para o suporte de

alguma prática pedagógica que queira adotar, e vai refinando a especificação do

script até que o groupware derivado tenha todas as características que deseja. O

uso recorrente vai tornar o professor proficiente na especificação das técnicas, e

consequentemente, os groupware serão cada vez mais adequados às suas

necessidades.

A seguir são apresentadas as conclusões dessa pesquisa, bem como suas

contribuições para a comunidade científica, e indicações de trabalhos futuros.

5 Conclusão

Nessa tese foi investigado o desenvolvimento de software no contexto de

groupware, especificamente para apoiar a aprendizagem colaborativa. O

desenvolvimento de um groupware, FLOCOS [21], foi o ponto de partida dessa

pesquisa. O esforço de desenvolvimento empregado para desenvolver esse

único sistema foi grande o bastante para motivar a investigação de abordagens

que maximizassem o reuso de artefatos de software para o desenvolvimento de

groupware de forma sistemática em detrimento do desenvolvimento

individualizado.

O passo seguinte nesta pesquisa foi reestruturar o sistema FLOCOS e

desenvolvê-lo novamente, porém, dessa vez o objetivo foi explorar as

possibilidades do uso das linhas de produto de software para o desenvolvimento

de groupware. Como resultado dessa exploração, o modelo de features proposto

pelo FODA foi adaptado para refletir o propósito de cada feature de acordo com

o Modelo 3C de Colaboração [22].

Dado o potencial verificado das LPS para a prototipação de groupware e

entrega de groupware ajustado a necessidades distintas, a etapa seguinte

consistiu no uso do conhecimento acumulado do grupo de pesquisa acerca do

desenvolvimento de groupware. Anexou-se, então, o RUP 3C-Groupware à fase

de análise de domínio e a bancada de componentes Groupware Workbench

(GW) à fase de implementação das LPS para groupware [23, 24].

O uso do RUP 3C-Groupware mostrou-se vantajoso dado que possibilitou

a definição da aplicação típica do domínio e, consequentemente, definição das

características variáveis que deveriam ser implementadas na LPS. O uso do

RUP 3C-Groupware em conjunto com a implementação das características com

o GW proporcionou ao projeto uma consistência com o Modelo 3C de

Colaboração desde as etapas iniciais do desenvolvimento até a codificação da

LPS e derivação do produto final.

O uso do GW no desenvolvimento da LPS foi adequado, uma vez que a

estrutura provida por ele já havia sido projetada para o reuso de componentes de

software. Além disso, o GW já provê mecanismos de composição de

CollabElements na criação de Collablets e composição de Collablets para

1

91

groupware. O conceito de linha de produtos sistematiza o processo de

desenvolvimento de groupware usando o GW, de modo a suprimir a

necessidade de se ter aspectos de gerenciamento técnicos que são importantes

por todo o ciclo de vida do software.

Resolvida a questão tecnológica no desenvolvimento de groupware que, a

partir de artefatos reusáveis, era possível entregar groupware adequado a

necessidades específicas de colaboração, observou-se a possibilidade de

delegar a atividade de geração de groupware ao usuário final. Esse usuário

conhece suas necessidades de colaboração e sabe como a tecnologia pode dar

suporte a elas.

Delegar a atividade de geração de groupware para o usuário final implica

em prover uma linguagem para que o usuário possa descrever como os

participantes do groupware deverão interagir. Assim, surgiu a necessidade do

uso dos scripts de colaboração. A linguagem usada para descrever os scripts de

colaboração nessa tese foi baseada nos elementos de BPMN. Essa escolha

deu-se por BPMN modelar fluxos de atividades através do uso de elementos

gráficos que são compreendidos por diferentes tipos de usuários. Além disso,

BPMN conta com diversos software de suporte para a modelagem. O software

de modelagem usado durante essa pesquisa foi o Bonita Open Studio [62].

Uma LPS dinâmica para groupware foi desenvolvida usando todo o

conhecimento adquirido sobre desenvolvimento de groupware baseado no

Modelo 3C de Colaboração. Para a análise da variabilidade da LPS, verificou-se

três groupware que foram projetados para o suporte a três diferentes técnicas de

aprendizagem colaborativa: o Versus, para a Controvérsia Acadêmica; o AVMJ,

para a JigSaw e o InGrupo, para a Investigação em Grupo. Um protótipo foi

desenvolvido, o GroupwareBuilder, para possibilitar a derivação de groupware da

LPS a partir de formalizações de scripts de colaboração em BPMN. Então, fez-se

necessário avaliar a derivação de groupware adequado a técnicas de

aprendizagem colaborativas a partir dos scripts de colaboração.

Uma avaliação funcional e um estudo de caso foram realizados. Na

avaliação funcional, buscou-se obter uma prova de conceito do protótipo

desenvolvido (GroupwareBuilder), na qual um groupware foi derivado para

apoiar os scripts de colaboração “Debate Crítico” e “Buzz Groups”. No estudo de

caso, o GroupwareBuilder foi usado por 12 professores para a derivação de

diferentes groupware de suporte a diferentes técnicas de aprendizagem

colaborativa. Privilegiou-se a observação não participativa e a análise qualitativa

de dados coletados com os participantes por meio de um questionário. Cada

2

92

participante formalizou seu script de colaboração e derivou um groupware a

partir do script com o uso do protótipo. Entre os 12 participantes do estudo, 9

declararam que o groupware derivado estava totalmente adequado, e somente 3

professores relataram que o groupware derivado estava parcialmente adequado

em função dos poucos serviços disponibilizados na LPS, o que dá indícios da

necessidade de evolução da LPS e motiva a continuidade dessa pesquisa.

A linguagem usada para formalização dos scripts foi considerada pouco

expressiva e inadequada para professores sem formação em computação. A

linguagem usada, entretanto, não foi fator impeditivo para a formalização dos

scripts e derivação dos groupware, pois todos conseguiram completar a tarefa

proposta no estudo.

Foi observado que a possibilidade de alteração dos scripts em tempo de

execução não foi percebida por um dos participantes. O fenômeno ocorrido pode

ter sido motivado, por exemplo, por problemas de usabilidade. Novos estudos

devem ser realizados para investigar o uso dos groupware derivados por meio

da abordagem proposta nessa pesquisa.

Os participantes perceberam a entrega de produtos customizados como

uma das vantagens da proposta dessa tese. A proposta de derivação de

groupware a partir dos scripts de colaboração foi também considerada pelos

participantes como útil para a prototipação rápida de groupware, com

possibilidade de alinhamento entre o groupware gerado e o script de

colaboração, consequentemente, apoiando também a prototipação de novos

scripts de colaboração. Por fim, os participantes comentaram sobre as

possibilidades de uso da abordagem proposta. Diversos participantes relataram

espontaneamente que consideram a proposta dessa tese relevante para a área

de CSCL.

A conclusão dessa pesquisa é que a abordagem proposta é boa e

relevante para a área de CSCL, porém enseja a realização de mais

investigações sobre como representar adequadamente scripts de colaboração

para o contexto de aprendizagem colaborativa.

5.1. Contribuições e Trabalhos Futuros

A principal contribuição deste trabalho é uma abordagem que possibilita a

derivação e adaptação de groupware a partir de scripts de colaboração

elaborados pelos usuários em vez de partir de uma lista de requisitos funcionais

como em LPS’s tradicionais. A consequência disso é a instrumentação do

3

93

usuário, e não do desenvolvedor, para a obtenção de groupware e uma maior

independência do usuário em relação ao desenvolvedor de software.

O usuário prototipa groupware e pensa em novas funcionalidades e

composições dessas funcionalidades em novos groupware a partir do registro de

seus scripts. Apesar da maior independência do usuário, não é possível abrir

mão do desenvolvedor. É o desenvolvedor quem usa, cria e modifica os

componentes, e evolui a LPS.

Outra contribuição dessa pesquisa consiste na linguagem definida para

representação de scripts de colaboração. Essa linguagem consistiu numa

simplificação da notação BPMN que teve dois objetivos: (1) oferecer uma

linguagem visual de fácil aprendizado para professores com pouca proficiência

em computação e (2) atender os requisitos do framework de desenvolvimento de

scripts de colaboração apresentado. Alguns elementos de BPMN, como

gateways e artefatos, não foram utilizados para simplificar a linguagem.

Comunicação entre diferentes pools também não foram utilizadas, mas por uma

limitação da ferramenta de modelagem selecionada. Essa simplificação na

linguagem alcançou os objetivos esperados dado que todos os participantes do

estudo de caso conseguiram representar seus scripts de colaboração e gerar

seus respectivos groupware. Porém a simplificação também limitou o poder de

expressividade da linguagem original, o que foi sentido pelos participantes com

maior proficiência em linguagens visuais similares ao BPMN.

No que diz respeito ao desenvolvimento da linha de produtos de

groupware, outra contribuição desse trabalho consiste na abordagem do uso do

modelo 3C de colaboração em todas as etapas do desenvolvimento. Na etapa

de análise de domínio, o uso do RUP 3C-Groupware ajudou tanto na

identificação de features dos serviços 3C, como na definição de parâmetros a

serem implementados nessas features. Ainda na etapa de análise de domínio,

com o objetivo de manter a consistência com o modelo 3C de colaboração, fez-

se uma adaptação da notação do modelo de features segundo FODA agregando

informação sobre o propósito 3C de cada feature. Essa adaptação é outra

contribuição dessa pesquisa. Na etapa de projeto, nos diagramas de

componentes, os componentes são agrupados de acordo com o seu propósito

3C. Na etapa de implementação, toda essa classificação de acordo com o

modelo 3C de colaboração concretiza-se nos componentes do Groupware

Workbench.

Outra contribuição dessa pesquisa é a sistematização da evolução da

bancada Groupware Workbench. À medida que a linha de produtos vai sendo

4

94

usada na derivação de diferentes groupware, os usuários podem sentir a

necessidade da criação de novas funcionalidades que as features atuais da LPS

não contemplam, ou simplesmente a correção ou atualização de funcionalidades

já existentes. Dessa forma, o groupware derivado não vai atender

adequadamente às especificações do script de colaboração. Uma vez detectado

que a LPS não satisfaz mais as necessidades dos usuários, deve-se acionar os

desenvolvedores da LPS, que deverão analisar o problema e verificar possíveis

evoluções ou manutenção das features da LPS. A manutenção das features ou a

criação de novas features impactam diretamente os componentes que são

modificados ou adicionados. Esse processo da evolução da LPS foi ilustrado na

Figura 19.

Outra contribuição consiste na implementação da LPS de groupware de

suporte a aprendizagem colaborativa, e do GroupwareBuilder, ferramenta de

derivação de groupware a partir dos scripts de colaboração. Essas

implementações tiveram por objetivo demonstrar a factibilidade e avaliar a

abordagem apresentada nessa tese.

A avaliação da abordagem apresentada nessa tese foi realizada, conforme

detalhado no capítulo 4, por uma avaliação funcional e um estudo de caso. Os

resultados do estudo de caso motivam a continuidade da pesquisa. Possíveis

trabalhos futuros são listados a seguir:

• Investigação das linguagens de representação de scripts de colaboração.

Dado que a linguagem proposta nessa tese foi considerada inadequada ao

uso por professores sem formação em informática, sugere-se realizar

estudos com outras formas de representação de scripts mais próximas a sua

realidade, baseadas em linguagem natural, por exemplo;

• Investigação sobre o uso dos groupware gerados a partir da LPS, o que pode

aumentar o conhecimento sobre como construir LPS para a derivação de

groupware;

• A investigação sobre como representar adequadamente a assimetria entre

papéis de colaboradores usuários do groupware derivado. No protótipo

gerado para essa pesquisa, os serviços derivados eram igualmente

acessíveis a todos os papéis de colaboradores. Em alguns tipos de técnica

de colaboração pode-se esperar, por exemplo, que “entrevistado” e

“entrevistador” tenham privilégio de acesso assimétrico ao sistema (por

exemplo, entrevistado somente responde perguntas e entrevistadores

somente fazem perguntas);

5

95

• Investigação acerca do uso de agentes de software para auxiliar o professor

na tarefa de coordenar as atividades do groupware através da identificação

da ocorrência de problemas de colaboração já documentados na literatura.

Como consequência disso, os agentes sugerem ao professor as

modificações necessárias no groupware para corrigir os problemas

verificados. Além disso, os agentes efetuariam tais modificações de forma

autônoma, sem a necessidade da intervenção do professor.

A partir desta pesquisa, a comunidade de linhas de produto tem suporte

para investigar a generalização dos resultados obtidos, através de pesquisas

sobre o uso da arquitetura proposta em contextos diferentes da aprendizagem

colaborativa. O estudo de caso revelou indícios da adequação do uso da

arquitetura proposta para a derivação de produtos de software através da

representação dos processos da camada de negócios, criando assim uma

plataforma de prototipação acessível a diferentes stakeholders.

Para a comunidade de educação, a contribuição dessa pesquisa é

possibilitar aos educadores experimentar novas técnicas de aprendizagem

mediada por tecnologias em uma plataforma de prototipação de groupware

personalizado.

6

96

“PO#&%!, agora sim posso colocar meus alunos para trabalhar em grupo!”

(exclamação feita pelo participante “Vinícius”, professor de língua portuguesa, literatura e artes,

após participar do estudo de caso)

6 Referências bibliográficas

[1] DILLEMBOURG, P. Over-scripting CSCL, The risk of blending collaborative learning with instructional design. In Paul A. Kirschner (Ed.), Three worlds of CSCL (pp. 61-91). Heerlen, Open Universiteit Nederland, 2002.

[2] CLEMENTS P.; NORTHROP, L. Software Product Lines: Practices and Patterns. Addison-Wesley, Boston, MA, USA, 2002.

[3] PIMENTEL, M. ComunicaTEC: Tecnologias de Comunicação para Educação e Colaboração. In: SBSI 2006, 2006, Curitiba, PR. III Simpósio Brasileiro de Sistemas de Informação. Curitiba, PR : SBC, 2006.

[4] BRIGGS, R.O.; DE VREEDE, G. J., Nunamaker, J.F., Jr. Tobey, D. (2001). ThinkLets: achieving predictable, repeatable patterns of group interaction with group support systems (GSS). In: Proceedings of the 34th Hawaii International Conference on System Sciences, USA, Hawaii: 2001.

[5] KOLFSHOTEN, G. L.; BRIGGS, R. O.; DE VREEDE, G. J.; Jacobs, P. H. M.; APPELMAN, J. H. A conceptual foundation of the thinkLet concept for Collaboration Engineering. In: International Journal of Human-Computer Studies. vol. 64. Issue 7, 2006. pp.611–621. ISSN: 1071-5819.

[6] UGULINO, W.; NUNES, R.R.; OLIVEIRA, C.L.P.; PIMENTEL, M.; SANTORO, F.M. Dos processos de colaboração para as ferramentas: a abordagem de desenvolvimento do projeto CommunicaTEC. Proceedings of XIV Brazilian Symposium on Multimedia and the Web: II Workshop of Business Process Management, 2008. ISBN: 857669199-X. 8p.

[7] FARIAS, C.R.G.; PIRES, L.F.; VAN SINDEREN, M.; Centre for Telematics & Inf. Technol., Twente Univ., Enschede A Component-Based Groupware Development Methodology. Proceedings of Enterprise Distributed Object Computing Conference, 2000.

[8] GREENBERG, S. Multimedia Tools and Applications. Volume 32 , Issue 2. February, 2007. ISBN 1380-7501, pp. 139 – 159.

[9] GEROSA, M.A. Desenvolvimento de Groupware Componentizado com Base no Modelo 3C de Colaboração. Tese de Doutorado, Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio), 16 de março de 2006.

[10] BARKLEY, E. F.; CROSS, K. P.; MAJOR, C. H. Collaborative Learning Techniques: a handbook for college faculty. Jossey Bass, 2005.

[11] STAHL, G.; KOSCHMANN, T.; SUTHERS, D. Computer-supported collaborative learning: An historical perspective. In R. K. Sawyer (Ed.), Cambridge handbook of the learning sciences. Cambridge, UK: Cambridge University Press, 2006. pp. 409-426.

[12] MENDONÇA, A. Controvérsia Acadêmica com Mapas Conceituais: Requisitos para Mediação via Ambientes Telemáticos. Programa de Pós-Graduação em Engenharia Elétrica. Centro de Tecnologia e Geociências.

8

98

Universidade Federal de Pernambuco. Dissertação de Mestrado: Julho de 2003.

[13] JOHNSON, D. W.; JOHNSON, R. T. Structuring Academic Controversy. In: Sharan, Shlomo. Handbook of Cooperative Learning Methods. Praeger Publishers. London, 1994.

[14] PEREIRA, V. Um Ambiente para Apoio ao Método JigSaw de Aprendizagem Cooperativa. Programa de Pós-Graduação em Engenharia Elétrica. Centro de Tecnologia e Geociências. Universidade Federal de Pernambuco. Dissertação de Mestrado: Setembro de 2003.

[15] ARONSON, E. Jigsaw Classroom. Disponível em: http://www.jigsaw.org/. Acesso em: Junho de 2010.

[16] SILVA, L. Um Ambiente Telemático para Mediar a Investigação em Grupo com Uso de Mapas Conceituais. Programa de Pós-Graduação em Engenharia Elétrica. Centro de Tecnologia e Geociências. Universidade Federal de Pernambuco. Dissertação de Mestrado: Março de 2004.

[17] SHARAN, Y.; SHARAN, S. Expanding Cooperative Learning through Group Investigation. New York: Teachers College Press, 1992.

[18] YIN, R. K. Estudo de Caso: planejamento e métodos. Tradução de Daniel Grassi. 3a ed. ISBN: 85-363-0462-6. Porto Alegre: Bookman, 2005.

[19] WAINER, J. Métodos de pesquisa quantitativa e qualitativa para a ciência da computação. In: Tomasz Kowaltowski; Karin Breitman. (Org.). Atualização em informática 2007. : Sociedade Brasiliera de Computação e Editora PUC Rio, v., p. 221-262.

[20] MARCZYK, G.; DEMATTEO, D.; FESTINGER, D.. Essentials of Research Design and Methodology. John Wiley and Sons, 2005.

[21] GADELHA, B.; GOMES, S.; FUKS, H.; CASTRO, A. FLOCOS: Sistema Colaborativo à Construção de Objetos de Aprendizagem Funcionais. Anais do V Simpósio Brasileiro de Sistemas Colaborativos - SBSC 2008. 27 a 29 Outubro 2008, Vila Velha, ES. ISBN: 978-0-7695-3500-5/08, Ed. IEEE-CS, pp. 215-223

[22] GADELHA, B.; NUNES, I.; FUKS, H.; LUCENA, C.J.P. An Approach for Developing Groupware Product Lines (GPL) based on the 3C Collaboration Model. CRIWG 2009, 15th Collaboration Researchers International Workshop on Groupware, Portugal, 13-17, september 2009. Lecture Notes on Computer Science LNCS 5784, Springer-Verlag, ISSN 0302-9743, pp. 328-343.

[23] GADELHA, B.; CIRILO, E.; GEROSA, M.A.; CASTRO, A.; FUKS, H.; LUCENA, C.J.P. Uma Abordagem para o Desenvolvimento de Linhas de Produto de Groupware Baseados em Componentes Utilizando o Groupware Workbench. SBSC 2010, VII Simpósio Brasileiro de Sistemas Colaborativos, Belo Horizonte, Outubro 2010, pp. 32-38.

[24] GADELHA, B.; CIRILO, E.; GEROSA, M.A.; CASTRO, A.; FUKS, H.; LUCENA, C.J.P. An Approach for Developing Component-based Groupware Product Lines using Groupware Workbench. SPLC 2010, 14th International Software Product Line Conference, South Korea, September 2010. Software Product Lines: Going Beyond, LNCS 6287, Springer-Verlag, ISSN 0302-9743, pp. 446-450.

[25] PIMENTEL, M. RUP-3C-Groupware: um processo de desenvolvimento de groupware baseado no Modelo 3C de Colaboração. Tese de Doutorado,

9

99

Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio), 22 de março de 2006.

[26] GEROSA, M.A.; FUKS, H. A component based workbench for groupware prototyping. 1st Workshop on Software Reuse Efforts (WSRE), 2nd Rise Summer School, 27-28 de outubro de 2008, Recife.

[27] POHL, K.; BOCKLE, G.; VAN DER LINDEN, F. J.. Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Verlag, New York,USA, 2005.

[28] A Framework for Software Product Line Practice, Version 5.0. What Software Product Lines Are Not. Disponível em http://www.sei.cmu.edu/productlines/frame_report/pl_is_not.htm. Consultado em dez 2011.

[29] CZARNECKI, K.; EISENECKER, U. W. Generative programming: methods, tools, and applications. USA: Addison-Wesley, 2000.

[30] KANG, K.; COHEN, S.; HESS, J.; NOVAK, W. Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-021, SEI, Carnegie-Mellon University, 1990.

[31] ALVES. Implementing Software Product Line Adoption Strategies. PhD thesis, UFPE, Brazil, 2007.

[32] GALSTER, M. Enhancing Runtime Variability in Software Product Lines through Service Orientation. Proceedings of the 14th International Software Product Line Conference, Coreia do Sul, 2010, pp 47-51.

[33] BURÉGIO, V. A.; MEIRA, S. L.; AMEIRA, E.S. Characterizing Dynamic Software Product Lines – A Preliminary Mapping Study. Proceedings of the 14th International Software Product Line Conference, Coreia do Sul, 2010, pp 53-60.

[34] CASTRO, A.; MENEZES, C. Aprendizagem Colaborativa com Suporte Computacional. Sistemas Colaborativos, cap.9 , pp. 135-155. Rio de Janeiro - RJ: Elsevier-Campus-SBC, 2011. ISBN 978-85-352-4669-8.

[35] KOBBE, L.; WEINBERGER, A.; DILLENBOURG, P.; HARRER, A.; HMLINEN, R.; HKKINEN, P.; FISCHER, F. Specifying computer-supported collabora- tion scripts. International Journal of Computer-Supported Collaborative Learning. Volume 2, Numbers 2-3, 2007, pp 211-224.

[36] KOLLAR, I.; FISCHER, F.; HESSE, F.W. Collaboration scripts - a conceptual analysis. Educational Psychology Review, 18(2), 2006, pp159-185.

[37] HONEGGER, B. D.; NOTARI, M. P. Over-computing CSCL Macro scripts? Gaining flexibility by using WikiPlus instead of specialized tools for authoring macro scripts. Computer Supported Collaborative Learn- ing Practices. Proceedings of the 9th CSCL International Conference.Rhodes, Greece, 2009.

[38] IMS Global Learning Consortium. Learning Design Specification. Disponível em: http://www.imsglobal.org/learningdesign/. Acessado em novembro, 2011.

[39] OMG. Business Process Model and Notation (BPMN) version 2.0. Janeiro, 2011. Disponível em: http://www.omg.org/spec/BPMN/2.0. Acessado em novembro, 2011.

[40] OMG. Object Management Group. Disponível em: http://www.omg.org/, acessado em dezembro, 2011.

00

100

[41] WHITE, S. A. Introduction to BPMN. IBM Corporation. Maio, 2004.Disponível em http://www.bpmn.org/Documents/ , acessado em dezembro, 2011.

[42] FUKS, H.; RAPOSO, A.; GEROSA, M.A.; PIMENTEL, M.; LUCENA, C.J.P. The 3C Collaboration Model. The Encyclopedia of E-Collaboration, Ned Kock (org), 2007, pp. 637-644.

[43] FUKS, H.; RAPOSO, A.; GEROSA, M.A.; PIMENTEL, M.; FILIPPO, D.; LUCENA, C.J.P. Inter- and Intra-Relationships between Communication Coordination and Cooperation in the Scope of the 3C Collaboration Model. CSCWD - Proc. of 12th International Conference on CSCW in Design, April 16-18, 2008, Xi'an, China.

[44] GEROSA, M.A.; FUKS, H. A component based workbench for groupware prototyping. 1st Workshop on Software Reuse Efforts (WSRE), 2nd Rise Summer School, Recife, 27-28 de outubro de 2008.

[45] SESÉ, M. A. Model Driven Product Line Engineering: Core Asset and Process Implications. Tese de doutorado. University of the Basque Country, San Sebastián, Espanha, 2011. pp 11-25.

[46] SELIC, Bran. The Pragmatics of Model-Driven Development. IEEE SOFTWARE. Setembro/Outubro, 2003. pp 19-25.

[47] MOHAGHEGHI, P.; DEHLEN, V. Where Is the Proof? - A Review of Experiences from Applying MDE in Industry. In 4th European Conference on Model Driven Architecture - Foundations and Applications (ECMDA-FA 2008), Berlin, Germany, volume 5095 of LNCS, pages 432–443. Springer, 2008.

[48] BOLIN, M. End-User Programming for the Web. Department of Electrical Engineering and Computer Science. MIT - Massachusetts Institute of Technology. Dissertação de Mestrado, Maio de 2005.

[49] DE SOUZA, C.S.; BARBOSA, S.D.J.; SILVA, S. R. P. (2001) Semiotic Engineering Principles for Evaluating End-User Programming Environments. Interacting with Computers, Amsterdam, v. 13(4), pp. 467-495, 2001.

[50] DAO, A. T. N; BOG, P. H. Programming Technologies. End-user Programming. Aalborg University. Junho de 2010.

[51] WON, M.; STIEMERLING, O.; WULF, V. Component-Based Approaches to Tailorable Systems, End User Development, Kluwer, 2005, pp. 1-27.

[52] SLAGTER, R.J.; BIEMANS, M.C.M. Component Groupware: A Basis for Tailorable Solutions that Can Evolve with the Supported Task, in ISA 2000, Wollongong, Australia.

[53] ROSEMAN, M.; GREENBERG, S. Building real time groupware with GroupKit, a groupware toolkit. ACM Transactions on Computer-Human Interaction, 3, 1, 1996, pp. 66-106.

[54] ROTH, J.; UNGER, C. Developing synchronous collaborative applications with TeamComponents. In Designing Cooperative Systems: the Use of Theories and Models, COOP’00, 2000, pp. 353-368.

[55] GASPAR,T. C.; PRADO, A. F.; TEIXEIRA, C. A. C. Linha de Produtos de Software para Colaboração Síncrona na Web 2.0. Anais do XV Simpósio Brasileiro de Sistemas Multimídia e Web. Fortaleza, Brasil. Outubro, 2009.

[56] OLIVEIRA, L. S.; GEROSA, M. A. Collaborative Features in Content Sharing Web 2.0 Social Networks: A Domain Engineering Based on the 3C

01

101

Collaboration Model. Proceedings of XVII International Conference, Criwg 2011. Paraty, Brasil. Springer, pp 142-157.

[57] DILLENBOURG, P.; HONG F. Website ManyScripts. Disponível em: http://manyscripts.epfl.ch, acessado em dezembro, 2011.

[58] HONEGGER, B. D.; Notari, M. P. Over-computing CSCL Macro scripts? Gaining flexibility by using WikiPlus instead of specialized tools for authoring macro scripts. Computer Supported Collaborative Learning Practices. Anais da 9a Conferência Internacional CSCL.Rhodes, Grécia, 2009.

[59] SANAGUSTIN, M. P; Leo, D. H; Blat, J. Towards supporting orchestrated Computer Supported Collaborative Learning scenarios. IEEE Multidisciplinary Engineering Education Magazine, vol 4, n 3. Setembro, 2009.

[60] KANG D; BAIK, D.K. Bridging Software Product Lines and Service-Oriented Architectures for Service Identification using BPM and FM. Proceedings of 9th International Conference on Computer and Information Science (ICIS).Yamagata, Japão. Agosto, 2010. pp 755 - 759.

[61] ASADI, M.; MOHABBATI, B.; KAVIANI, N.; GASEVIC, D.; BOSKOVIC, M.; HATALA, M. Model-Driven Development of Families od Service-Oriented Architectures. Proceedings of the First International Workshop on Feature-Oriented Software Development. Denver, USA. 2009. pp 95-102.

[62] BONITASOFT. Bonitasoft - Open Source Workflow & BPM software. Disponível em: http://www.bonitasoft.com/, acessado em dezembro, 2011.

[63] NICOLACI-DA-COSTA, A. M. O Campo da Pesquisa Qualitativa e o Método da Explicitação do Discurso Subjacente (MEDS). In: Psicologia: Reflexão e Crítica. vol.20 no.1. ISSN: 0102-7972. RS, Porto Alegre: 2007.

[64] CASTRO, T. Sistematização da Aprendizagem de Programação em Grupo. Tese de Doutorado, Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio), 2011