Uma Abordagem para o Desenvolvimento de Apoio à
Percepção em Ambientes Colaborativos de
Desenvolvimento de Software
Marco Aurélio Souza Mangan
Orientadores:
Cláudia M. L. Werner, Marcos R. S. Borges
Roteiro
 Cenário, Motivação
 Problema, Proposta de Solução, Objetivos e Hipóteses
 Análise do Domínio
 Colaboração Transparente
 Arquitetura de Colaboração Transparente (ACT)
 Protótipos
 Avaliações dos Protótipos
 Conclusão
‹#› :: 40
Cenário
 Desenvolvimento Distribuído ou Globalizado de Software
 Participantes em lugares ou horários diferentes
 Equipes virtuais
 Em teoria: aumento de produtividade
 Na prática: problemas culturais, dificuldades de percepção e
comunicação
 Ambientes Colaborativos de Desenvolvimento de Software
 Ferramentas para o desenvolvimento de software + ferramentas
para colaboração
 Duas dimensões: apoio à tarefa e apoio à colaboração
 Exemplos: Palantir, Milos, Tukan, Gossip, Serendipity
‹#› :: 40
Apoio à colaboração e apoio à tarefa
Apoio à
colaboração
alto
q
CO2DE
•
REDUCE
•
BSCW
q
OdysseyShare , Serendipity
q
DARGOUML
q
TUKAN, Palantir
•
COAST
q
Odyssey
q
ARGOUML, Pose
baixo
•
JDK
baixo
Legenda:
● biblioteca ou groupware genérico
idon
•
Eclipse, Visual
SmallTalk
alto
Apoio à
tarefa
□ ferramenta ou ambiente CASE
‹#› :: 40
Motivação
 Ausência de apoio adequado à colaboração nos ambientes
de desenvolvimento tradicionais (e.x. Eclipse, Rose)
 Dificuldades na combinação de apoio à tarefa e apoio à
percepção em uma mesma ferramenta
 Reutilização de software: economia e qualidade
 Semelhanças e diferenças entre ambientes colaborativos
 Necessidade de uma abordagem alternativa ao uso de
frameworks e toolkits colaborativos
 Modelo de desenvolvimento: diversos participantes, framelets
 Arquitetura: coexistência de diversas soluções
‹#› :: 40
Roteiro
 Cenário, Motivação
 Problema, Proposta de Solução, Objetivos e Hipóteses
 Análise do Domínio
 Colaboração Transparente
 Arquitetura de Colaboração Transparente (ACT)
 Protótipos
 Avaliações dos Protótipos
 Conclusão
‹#› :: 40
Problema e Proposta de Solução
 Problema: Como construir ambientes colaborativos para o
desenvolvimento de software?
 Como oferecer apoio adequado para a tarefa e para a colaboração?
 Como permitir a composição de diferentes ambientes?
 Proposta de Solução:
 Alterações sobre ferramentas que oferecem apoio à tarefa
 Uma arquitetura de colaboração que descreve uma infra-estrutura
comum
 Mecanismos de extensão que permitem tratar de variantes
 Metodologia para desenvolver e avaliar essas extensões
‹#› :: 40
Objetivos
 Analisar os ambientes de desenvolvimento colaborativo
como uma família de aplicações
 Apresentar uma abordagem de desenvolvimento alternativa
ao uso de groupkits e frameworks colaborativos
 Determinar se existe um conjunto de características para
descrever o apoio à percepção nesses ambientes
 Realizar implementação de protótipos
 Realizar avaliações dos protótipos
‹#› :: 40
Hipóteses
 Existe um potencial para reutilização de software nesses
ambientes de desenvolvimento colaborativo?
 É possivel desenvolver o apoio à percepção em ambientes
de desenvolvimento pré-existentes?
 O apoio à percepção desenvolvido dessa forma pode ser
comparado com o apoio existente em ambientes
desenvolvidos com uma abordagem diferente?
‹#› :: 40
Roteiro
 Cenário, Motivação
 Problema, Proposta de Solução, Objetivos e Hipóteses
 Análise do Domínio
 Colaboração Transparente
 Arquitetura de Colaboração Transparente (ACT)
 Protótipos
 Avaliações dos Protótipos
 Conclusão
‹#› :: 40
Características do domínio
 Os ambientes colaborativos estudados fazem parte de uma
família de aplicações
 As aplicações podem ser classificadas de acordo com
características específicas
 As características escolhidas tem origem no vocabulário dos
especialistas
‹#› :: 40
Diagrama de características
Legenda:
Ator
Ponto de variação
Variante
‹#› :: 40
Roteiro
 Cenário, Motivação
 Problema, Proposta de Solução, Objetivos e Hipóteses
 Análise do Domínio
 Colaboração Transparente
 Arquitetura de Colaboração Transparente (ACT)
 Protótipos
 Avaliações dos Protótipos
 Conclusão
‹#› :: 40
Colaboração Transparente
 Técnica de desenvolvimento de groupware
 Permite a modificação de ferramentas existentes para a
inclusão de apoio à colaboração, em particular, apoio à
percepção
 Colaboração Transparente (~1980)
 Colaboração Flexível (Begole, 1998)
 Colaboração Inteligente (Li e Li, 2000)
 Contribuições desta tese para a técnica de colaboração
transparente:
 eventos semânticos,
 a combinação de mecanismos de apoio à percepção e
 a possibilidade de reutilização desses mecanismos
‹#› :: 40
Roteiro
 Cenário, Motivação
 Problema, Proposta de Solução, Objetivos e Hipóteses
 Análise do Domínio
 Colaboração Transparente
 Arquitetura de Colaboração Transparente (ACT)
 Modelo de Percepção com base em Anotações
 Arquitetura
 Processo de desenvolvimento
 Protótipos
 Avaliações dos Protótipos
 Conclusão
‹#› :: 40
Modelo de Percepção com base em Anotações
 Espaço de software: ambiente virtual descrito por meio de
documentos estruturados utilizados no desenvolvimento de
software
 Modelos e código fonte
 Modelo objetivo de percepção: meta-modelo UML
 Anotações representam informações de percepção que
relacionam atividades de agentes sobre o modelo objetivo
 Outros modelos objetivos de percepção: ex.: documento,
diagrama, WIMP
‹#› :: 40
Modelo de Percepção com base em Anotações
order
reference
<<from MOF>>
ModelElement
act
Action
before
Agent
after
State
‹#› :: 40
Arquitetura de Colaboração Transparente
 Uma descrição dos principais componentes de um ambiente
colaborativo
 Ferramenta CASE (Aplicação): uma fonte de eventos
 Sensor (Coletor): um programa que coleta eventos
 Extensão (Collablet): um consumidor de eventos
‹#› :: 40
Visão geral da arquitetura
Ambiente de Execução
Interpretação
de eventos
Scriptlet
Extensões
colaborativas
Aplicação
Histórico
local
Coletor
Histórico
do grupo
Injetor
Collablet
Sistema de eventos e notificação
Controle de sessão
Catálogo
Autenticação e autorização
‹#› :: 40
Arquitetura de distribuição
 Três modelos de percepção
 WIMP: janela, botão, barra de rolagem
 Modelo: classe, pacote, relacionamento
 Documento: documento, parágrafo, linhas
 Cinco operações básicas
 Criar, recuperar, alterar, remover, visualizar
 Eventos: operações + elementos de um modelo de
percepção
 Exemplos: criar classe, alterar linha, mover janela
 Eventos são ordenados em canais de comunicação
 Dados históricos e dados on-line
‹#› :: 40
Arquitetura de distribuição
 Arquitetura de Quadro Negro (Blackboard)
 A comunicação ocorre em um único espaço compartilhado
 Notificação e consulta com base em exemplos
 Notificação de eventos implementada usando espaço de
tuplas
 Integrado com o modelo de objetos
 Comunicação e persistência em um único sistema
 Paradigma de programação distribuída
‹#› :: 40
Arquitetura de distribuição
CASE tool
Extension
Collector
read(e?)
write(e1)
e1
Event Notification
e2[e1]
write(e2[e1])
Collector
Extension
CASE tool
‹#› :: 40
Processo de desenvolvimento
 Um guia para o desenvolvimento de extensões
 Papéis: capacidades e responsabilidades
 Desenvolvedor da ferramenta CASE
 Desenvolvedor da extensão colaborativa
 Administrador da base de eventos
 Desenvolvedor de integração
 Administrador de ambiente
 Atividades: etapas na criação de uma ambiente colaborativo
 Desenvolvimento da ferramenta CASE
 Desenvolvimento da extensão colaborativa
 Desenvolvimento da integração
 Composição de um ambiente
‹#› :: 40
Roteiro
 Cenário, Motivação
 Problema, Proposta de Solução, Objetivos e Hipóteses
 Análise do Domínio
 Colaboração Transparente
 Arquitetura de Colaboração Transparente (ACT)
 Protótipos
 Avaliações dos Protótipos
 Conclusão
‹#› :: 40
Protótipos
 Projeto e implementação de alterações:
 Coletor e Extensão colaborativa
 Coletores são reutilizados
 Uma extensão pode utilizar um novo ambiente por meio de
um coletor adequado
 O desenvolvimento dos protótipos demonstra a viabilidade
de proposta e o potencial para reutilização
‹#› :: 40
Protótipos
Shared Workspaces
Tarefa: revisão de software
Ferramenta CASE: Odyssey
Coletor: Sistema de Janelas Java
Modelo de percepção espacial
GAW
Tarefa: programação concorrente
Ferramenta CASE: Eclipse
Coletor: mecanismo de extensão
da ferramenta
Modelo de percepção com base
em documentos
‹#› :: 40
Protótipos
MAIS
Tarefa: modelagem concorrente
Ferramenta CASE: Odyssey
Coletor: mecanismo de
extensão da ferramenta
Modelo de percepção semântico
Ariane
Tarefa: gerência de software
Ferramenta CASE: Odyssey
Coletor: camada de persistência
Modelo de percepção semântico
‹#› :: 40
Roteiro
 Cenário, Motivação
 Problema, Proposta de Solução, Objetivos e Hipóteses
 Análise do Domínio
 Colaboração Transparente
 Arquitetura de Colaboração Transparente (ACT)
 Protótipos
 Avaliações dos Protótipos
 Conclusão
‹#› :: 40
Avaliações dos protótipos
 Adaptação de guias para planejamento de avaliações
 Metodologia para o planejamento das avaliações
 Passo 1: Descrição de aplicação
 Passo 2: Definição do tipo de estudo
 Passo 3: Descrição da tarefa operacional
 Passo 4: Definição de medidas
 Passo 5: Análise
‹#› :: 40
Avaliações dos protótipos
 Avaliações realizadas usando diferentes protótipos
 Shared Workspaces, Ariane, MAIS, GAW
 Diferentes perfis de participantes: alunos e profissionais
 Resultados obtidos nas avaliações
 Avaliação da operação correta do protótipo
 Avaliação da usabilidade do protótipo
 Sugestões e correções de funcionalidades
 Empacotamento do protótipo
 Relação entre o uso do protótipo e o tempo, esforço e satisfação
durante a tarefa
‹#› :: 40
Exemplo: Avaliação comparativa entre o GAW e o RH
Objeto de estudo representações gráficas e textuais para
informação de percepção.
Propósito avaliar o uso de ambas as representações.
Foco de qualidade esforço realizado e satisfação do usuário.
Perspectiva do programador em condição de distribuição.
Contexto seis desenvolvedores profissionais, divididos em
dois grupos de três desenvolvedores, que procuram
individualmente por especialistas sobre artefatos.
‹#› :: 40
Avaliação do GAW e Resource History nas questões de usabilidade
‹#› :: 40
Roteiro
 Cenário, Motivação
 Problema, Proposta de Solução, Objetivos e Hipóteses
 Análise do Domínio
 Colaboração Transparente
 Arquitetura de Colaboração Transparente (ACT)
 Protótipos
 Avaliações dos Protótipos
 Conclusão
‹#› :: 40
Conclusão
 Alternativa para o desenvolvimento de ambientes colaborativos
 A extensão de ferramentas de software pré-existentes reduz o problema
de apoio à tarefa
 As alterações são compostas de duas partes reutilizáveis: coletores e
extensões colaborativas
 Uma arquitetura descreve os componentes de uma infra-estrutura
comum
 Um processo de desenvolvimento guia os desenvolvedores de
ambientes colaborativos
 Os exemplos de alterações realizadas com os protótipos demonstram a
viabilidade da abordagem
 A avaliações dos protótipos demonstram a aplicabilidade dessas
alterações
‹#› :: 40
Contribuições desta tese
 A definição de uma abordagem para o desenvolvimento
de apoio à percepção em cenários reais de
desenvolvimento de software, envolvendo pequenas
equipes (2 a 10 pessoas)
 A proposta de uma metodologia para planejamento e
observação de cenários e estudos de caso que ofereceram
dados mais concretos sobre os efeitos do apoio à
colaboração sobre o trabalho dos participantes
 A implementação de uma arquitetura transparente que
facilita a integração e a observação dos efeitos do apoio à
colaboração nesses ambientes
‹#› :: 40
Contribuições desta tese
 Uma análise do domínio de conhecimento relativo ao
desenvolvimento distribuído de software e da família de
aplicações propostas para esse domínio, dentro do aspecto
de apoio à percepção
 A construção de protótipos com base na abordagem
proposta
 A realização de observações sobre a usabilidade dos
protótipos
‹#› :: 40
Limitações
 Família de aplicações restrita
 Esforço adicional para o desenvolvimento para reutilização
 Falta de uma avaliação sistemática do esforço de
desenvolvimento com a abordagem proposta
‹#› :: 40
Perspectivas Futuras
 maiores facilidades para o uso da abordagem
 desenvolvimento ou aplicação de ferramentas que auxiliem na
composição de ambientes com base em componentes
 criação de componentes visuais que simplifiquem a ligação entre
componentes e a configuração de ambientes a partir de uma
interface de usuário intuitiva
 Ampliação da família de aplicações atendida pela
abordagem
 Incentivo e observação da colaboração nos ambientes
modificados
‹#› :: 40
Publicações e atividades no período
 Artigos internacionais: 4/6
 MANGAN, M. A. S., BORGES, M. R. S., WERNER, C. M. L., "Increasing
Awareness in Distributed Software Development Workspaces", In:
International Workshop on Groupware, pp.84-91, Costa Rica, 2004
 MANGAN, M. A. S., BORGES, M. R. S., WERNER, C. M. L., "A Middleware
to Increase Awareness in Distributed Software Development Workspaces",
In: WebMedia & LA-Web Joint Conference, pp.62-64, Brasil, 2004.
 Artigo nacionais: 4/11
 MANGAN, M. A. S., WERNER, C. M. L., BORGES, M. R. S., "Componentes
para Colaboração Síncrona em um Ambiente de Reutilização de Software",
In: XVI Simpósio Brasileiro de Engenharia de Software, Caderno de
Ferramentas, pp.372-377, Brasil, 2002.
 Co-orientações
 Trabalhos de conclusão: 2
‹#› :: 40
Uma Abordagem para o Desenvolvimento de Apoio à
Percepção em Ambientes Colaborativos de
Desenvolvimento de Software
Marco Aurélio Souza Mangan
Orientadores:
Cláudia M. L. Werner, Marcos R. S. Borges
‹#› :: 40