bruno freitas gadelha uma abordagem de desenvolvimento de...
TRANSCRIPT
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