View
0
Download
0
Category
Preview:
Citation preview
UNIVERSIDADE ESTADUAL DE MARINGA
CENTRO DE TECNOLOGIA
DEPARTAMENTO DE INFORMATICAPROGRAMADE POS-GRADUACAO EMCIENCIA DA COMPUTACAO
RAFAEL LEONARDO VIVIAN
Uma abordagem para percepcao de contexto sobre artefatos de softwareno Desenvolvimento Distribuıdo de Software
Maringa
2013
RAFAEL LEONARDO VIVIAN
Uma abordagem para percepcao de contexto sobre artefatos de softwareno Desenvolvimento Distribuıdo de Software
Dissertacao apresentada ao Programa dePos-Graduacao em Ciencia da Computacaodo Departamento de Informatica, Centrode Tecnologia da Universidade Estadualde Maringa, como requisito parcial paraobtencao do tıtulo de Mestre em Ciencia daComputacao.
Orientadora: Profa. Dra. Elisa HatsueMoriya Huzita
Maringa
2013
Para Maria e Delcino,
por trinta e um anos de amor incondicional.
AGRADECIMENTOSAo Todo-Poderoso por sua energia e paz todos os dias (ou quase todos!); meu eterno
amor e carinho aos meus pais – Maria e Delcino – por toda ajuda, paciencia e incentivo
para vencer todas as dificuldades; meu irmao – Gabriel – pelo apoio e inspiracao; todo o
meu amor a Dayana pelo companheirismo e por estar ao meu lado durante as dificuldades;
Famılias Vivian, Andrade, Velasco. Nonno e nonna Vivian; Nonno Pedro e nonna Elsa
(in memorian). Tia Bere e famılia; Tio Jair e famılia. Tios e tias; primos e primas.
Profa. Dra. Elisa Hatsue Moriya Huzita (toda minha gratidao pela oportunidade,
orientacao, confianca e ensinamentos durante o perıodo da especializacao e do mestrado);
agradeco aos professores do DIN-UEM pelo apoio (Profa. Dra. Tania Fatima Calvi Tait,
Profa. Dra. Itana Maria de Souza Gimenes, Profa. Dra. Luciana Andreia Fondazzi
Martimiano, Prof. Dr. Ronaldo Augusto de Lara Goncalves; Prof. Dr. Joao Angelo
Martini; Prof. Dr. Edson Alves de Oliveira Junior; Prof. Dr. Franklin “Led Zeppelin”
Cesar Flores, Prof. Dr. Dante Alves Medeiros Filho, Prof. Dr. Wesley Romao); secretaria
do Programa de Pos-Graduacao em Ciencia da Computacao (em especial, Ines e Wagner);
Departamento de Informatica; Universidade Estadual de Maringa. Pessoal do LDDS:
Gustavo, Helio, Beto, Lucas, Guilherme, Carlos “Biluka”, Elder, Yogi. Grupo de pesquisa
DiSEN-CK: Profa. Msc. Gislaine Camila Lapasini Leal (agradeco pelas colaboracoes e
sugestoes durante a escrita dos artigos), Prof. Dr. Renato Balancieri, Prof. Dr. Edwin
Vladimir Cardoza Galdamez, Profa. Msc. Raqueline Ritter de Moura Penteado. Ana
Paula (agradeco pelas colaboracoes e sugestoes no inıcio da pesquisa). Agradeco a todos
os alunos do DIN-UEM que participaram do experimento.
Profa. Dra. Simone do Rocio Senger de Souza (pela acolhida e orientacao durante o
tempo que estive no ICMC-USP). Agradeco, tambem, a sua orientada Maria (pela ajuda
durante a analise dos dados do experimento). Agradeco a todos os alunos do ICMC-USP
que participaram do experimento.
Prof. Dr. Marco Aurelio Gerosa (IME-USP) e Profa. Dra. Tania Fatima Calvi Tait
(DIN-UEM) por fazerem parte da banca e contribuirem com este trabalho.
Capes (Coordenacao de Aperfeicoamento de Pessoal de Nıvel Superior) pelo apoio
financeiro; Projeto Procad (Projeto de Cooperacao Academica ICMC-USP, UEM e
PUC-RS).
Toda minha gratidao e respeito aos amigos e colegas do mestrado: Lurdete (obrigado
por toda ajuda e apoio!) e Rogerio (my brothas! Cafe! Cafe! Cafe!), Euclides, Marcelo,
Sidgley, Juliano, Beleti, Andre, Claudia, Everton, Thiago, Murilo, Vinicius, Andrezao.
My english teacher Lisa (thanks for review the abstract!).
A todos os amigos que fiz em Maringa durante o perıodo da especializacao e do
mestrado (04/2008 - 09/2012): principalmente Andre Dias, Eliane, Felipe de Penapolis,
Felipe de Bebedouro, Neto.
Aos meus ex-professores da especializacao: Prof. Ayslan Trevizan Possebom, Prof.
Flavio Luiz Schiavoni, Profa. Thelma Elita Colanzi.
Aos meus ex-professores da graduacao: Prof. Zeca, Profa. Sediane, Prof. Lorenzon,
Prof. Jorge, Prof. Monica.
Aos amigos das antigas em Santa Catarina: Marcos, Marcio, Ita, Rafaela, Maira,
Rudi, Marta, Luciano, Tibola, Negao, Juninho, Clarice, Sidi.
Linus Torvalds e toda a comunidade de Software Livre por todas as ferramentas que
proporcionaram a elaboracao desta dissertacao.
Meu respeito a todas as pessoas que compreendem que um curso de pos-graduacao nao
e sinonimo de desemprego, mas sim um aperfeicoamento profissional, cientıfico e pessoal.
A todos aqueles que acreditaram... e, tambem, nao acreditaram em mim durante este
longo perıodo (tudo valeu a pena!).
Inspiracao: musica (Neil Young, David Gilmour, Roger Waters, Neil Peart, Humberto
Gessinger); livros (O Estrangeiro - Albert Camus, A Revolucao dos Bichos - George
Orwell, Admiravel Mundo Novo - Aldous Huxley, Ensaio sobre a Cegueira - Jose Sara-
mago, Olhai os Lırios do Campo - Erico Verıssimo, O Exercito de um Homem So - Moacyr
Scliar); filmes (Um Sonho de Liberdade, O Fabuloso Destino de Amelie Poulain, Menina de
Ouro, Coracao Louco, A Corrente do Bem, Inteligencia Artificial, Sociedade dos Poetas
Mortos, Na Natureza Selvagem, Diarios de Motocicleta, O Escafandro e a Borboleta);
pessoas/cientistas (Miguel Nicolelis, Albert Einstein, Edsger Dijkstra, Donald Knuth).
Os que se encantam com a pratica sem a ciencia
sao como os timoneiros que entram no navio sem timao nem bussola,
nunca tendo certeza do seu destino.
— Leonardo da Vinci
Uma abordagem para percepcao de contexto sobre artefatos de softwareno Desenvolvimento Distribuıdo de Software
RESUMO
O Desenvolvimento Distribuıdo de Software trouxe vantagens competitivas, tais como
o aumento da produtividade, melhorias na qualidade do produto e a reducao de custos.
Entretanto, as distancias geografica e temporal e as diferencas socioculturais entre as equi-
pes distribuıdas, ampliaram alguns desafios e, sobretudo, acrescentaram novas exigencias
no que diz respeito a comunicacao e a coordenacao. Tal cenario tem influenciado sobre
os artefatos de software que sao produzidos e/ou modificados, pois podem ser geradas
inconsistencias e ambiguidades sobre os mesmos. Nesse sentido, ha a necessidade de
uma abordagem que ofereca informacoes aos indivıduos para que percebam o contexto
das acoes que tem ocorrido sobre os artefatos de software. Este trabalho apresenta
uma abordagem para percepcao de contexto sobre artefatos de software, tais como
codigo fonte e diagrama de classes, no desenvolvimento distribuıdo de software. O
objetivo da abordagem e oferecer apoio ao desenvolvimento de software e, assim, melhorar
a comunicacao e a coordenacao entre as equipes distribuıdas e, tambem, reduzir as
ambiguidades nos artefatos. Esta abordagem foi elaborada e fundamentada em quatro
pilares: (i) identificar as peculiaridades do desenvolvimento distribuıdo de software que
impactam sobre a producao e a modificacao dos artefatos de software; (ii) definir um
modelo conceitual, alem das estruturas e dos elementos, que compoe a abordagem para
apoiar a percepcao de contexto sobre artefatos de software; (iii) descrever e especificar os
elementos de percepcao e contexto de artefato e, tambem, um modelo de representacao
que ofereca semantica para as informacoes dos artefatos de software; e (iv) especificar
um meio para gerar automaticamente as relacoes de dependencias entre os diferentes
tipos de artefatos de software e, tambem, definir recursos visuais para a apresentacao
de informacoes contextuais sobre tais artefatos. A abordagem foi avaliada por meio de
um estudo experimental, seguindo os princıpios da Engenharia de Software Experimental,
com o apoio de um prototipo que foi desenvolvido para tal fim. Os resultados indicaram
que a abordagem proposta aumenta a percepcao de contexto sobre os artefatos de software
pelos indivıduos.
Palavras-chave: Desenvolvimento distribuıdo de software. Percepcao. Informacao
contextual. Artefatos.
An approach to context awareness on software artifacts in DistributedSoftware Development
ABSTRACT
The Distributed Software Development brought competitive advantages, such as the in-
crease of productivity, improvement of product quality and costs reduction. However,
the geographical and temporal distances added to the sociocultural differences among
distributed teams enlarged some challenges and, above all, they added new demands
in relation to the communication and the coordination. This scenery has an affect
on the software artifacts that are produced and/or modified because inconsistencies and
ambiguities may be generated about these artifacts. In this way, there is a need for an
approach that provides information to individuals to become aware about the context of
the actions that have occurred on the software artifacts. This work presents an approach
to context awareness on software artifacts such as source code and class diagram in
the distributed software development. The goal of the approach is to provide support
for software development and, so, to improve the communication and the coordination
among distributed teams and also to reduce ambiguities in the artifacts. This approach
was elaborated based on four pillars: (i) to identify the peculiarities of distributed software
development that impact on production and modification of software artifacts; (ii) to define
a conceptual model, beyond the structures and elements which compose the approach
to support context awareness on software artifacts; (iii) to describe and to specify the
awareness elements and artifact context and also a representation model which provides
semantic to the information about software artifacts; and (iv) to specify a way to generate
automatically dependency relationships among different types of software artifacts and,
also, to determine visual resources for presenting of contextual information about such
artifacts. The approach was evaluated through an experimental study, following the
principles of Experimental Software Engineering, with the support of a prototype that
was developed for this purpose. The results indicated that the proposed approach increases
the context awareness on the software artifacts by individuals.
Keywords: Distributed software development. Awareness. Contextual information.
Artifacts
LISTA DE FIGURAS
Figura 1.1 Fases do metodo de pesquisa . . . . . . . . . . . . . . . . . . . . . . 23
Figura 2.1 Nıveis de dispersao em DDS (Paasivaara, 2004) . . . . . . . . . . . 27
Figura 2.2 Tipos de contexto (Brezillon e Pomerol, 1999) . . . . . . . . . . . . 31
Figura 2.3 Visao geral do processo de experimentacao (Wohlin et al., 2000) . . 34
Figura 3.1 Visualizacao grafica da Palantır (Sarma et al., 2003) . . . . . . . . . 38
Figura 3.2 Interface com o usuario na Ariadne (de Souza et al., 2004) . . . . . 40
Figura 3.3 Interface com o usuario na Augur (Froehlich e Dourish, 2004) . . . 41
Figura 3.4 Visualizacao do grafo de rastreabilidade na ADAMS (de Lucia et
al., 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 3.5 Interface com o usuario na ProjectWatcher (Gutwin et al., 2005) . . 43
Figura 3.6 Interface com o usuario na EvolTrack (Cepeda et al., 2010) . . . . . 44
Figura 4.1 Cenario do fluxo de informacoes da DiSEN-CollaborAR . . . . . . . 54
Figura 4.2 Modelo conceitual da DiSEN-CollaborAR . . . . . . . . . . . . . . 55
Figura 4.3 Mapa conceitual – conceitos e relacionamentos focados em artefatos
de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 4.4 Mapa conceitual – conceitos e relacionamentos sobre o tipo de
artefato diagrama . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figura 4.5 Mapa conceitual – conceitos e relacionamentos sobre o tipo de
artefato codigo fonte . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 4.6 Classes da OntoDiSENv1 focadas em artefatos de software . . . . . 64
Figura 4.7 Propriedades de objetos da OntoDiSENv1 focadas em artefatos de
software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 4.8 Vinculando instancias a partir das classes da ontologia nos domınios
diagrama de classes e codigo fonte . . . . . . . . . . . . . . . . . . . 70
Figura 5.1 Visao geral da arquitetura do ACAS . . . . . . . . . . . . . . . . . 76
Figura 5.2 Diagrama de classes do pacote model . . . . . . . . . . . . . . . . . 77
Figura 5.3 Diagrama de classes do pacote event . . . . . . . . . . . . . . . . . 78
Figura 5.4 Diagrama de classes do pacote extract . . . . . . . . . . . . . . . . 79
Figura 5.5 Diagrama de classes do pacote agency . . . . . . . . . . . . . . . . 80
Figura 5.6 Diagrama de classes do pacote visualize . . . . . . . . . . . . . . 81
Figura 5.7 Exemplo de commit . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figura 5.8 Shell Script que captura informacoes sobre o codigo fonte . . . . . . 82
Figura 5.9 Shell Script que captura informacoes sobre o diagrama de classes . 83
Figura 5.10 Implementacao do parser para o codigo fonte . . . . . . . . . . . . 84
Figura 5.11 Implementacao do parser para o codigo XMI . . . . . . . . . . . . . 85
Figura 5.12 Exemplo de regra de inferencia . . . . . . . . . . . . . . . . . . . . 86
Figura 5.13 Interface do usuario no ACAS . . . . . . . . . . . . . . . . . . . . . 87
Figura 6.1 Conhecimentos dos participantes . . . . . . . . . . . . . . . . . . . 103
Figura 6.2 Tempo despendido para a realizacao das tarefas por participante e
abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Figura 6.3 Analise de outlier para a variavel Tempo Despendido . . . . . . . . 106
Figura 6.4 Analise de outlier para a variavel Numero de Artefatos . . . . . . . 107
LISTA DE TABELAS
Tabela 3.1 Comparacao entre as ferramentas . . . . . . . . . . . . . . . . . . . 48
Tabela 4.1 Elementos de percepcao focados em artefatos de software (adaptado
de Gutwin e Greenberg (2002)) . . . . . . . . . . . . . . . . . . . . 59
Tabela 4.2 Distribuicao dos elementos contextuais por elementos de percepcao 60
Tabela 4.3 Comparacao entre os trabalhos relacionados e a DiSEN-CollaborAR 73
Tabela 6.1 Classificacao das variaveis selecionadas neste estudo experimental . 96
Tabela 6.2 Alocacao dos grupos . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Tabela 6.3 Perfil dos participantes no estudo experimental . . . . . . . . . . . 101
Tabela 6.4 Grupos e sessoes do experimento . . . . . . . . . . . . . . . . . . . 102
Tabela 6.5 Dados obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Tabela 6.6 Resultados do teste de normalidade Shapiro-Wilk . . . . . . . . . . 107
Tabela 6.7 Resultados do teste de hipotese Kruskal-Wallis . . . . . . . . . . . . 108
Tabela 6.8 Resultados do teste de hipotese Kruskal-Wallis . . . . . . . . . . . . 108
LISTA DE SIGLAS E ABREVIATURASACAS: Artifact Collaborative Awareness System
ADAMS: ADvanced Artefact Management System
ADDS: Ambiente de Desenvolvimento Distribuıdo de Software
API: Application Programming Interface
CASE: Computer Aided Software Engineering
CK: Contexual Knowledge
DDS: Desenvolvimento Distribuıdo de Software
DiSEN: Distributed Software Engineering eNvironment
DiSEN-CollaborAR: DiSEN-Collaborative Awareness for aRtifacts
DiSEN-CSE: DiSEN-Context Sensitive Environment
EK: External Knowledge
ESE: Engenharia de Software Experimental
GCS: Gerencia de Configuracao de Software
GQM: Goal Question Metric
GSD: Global Software Development
IDE: Integrated Development Environment
JUNG: Java Universal Network/Graph
LabES: Laboratorio de Engenharia de Software
LDDS: Laboratorio de Desenvolvimento Distribuıdo de Software
OWL-DL: Web Ontology Language - Description Logics
PC: Proceduralized Context
RMI: Remote Method Invocation
SAX: Simple API for XML
SCV: Sistema de Controle de Versao
UML: Unified Modeling Language
XMI: XML Metadata Interchange
SUMARIO
1 Introducao 17
1.1 Consideracoes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Contextualizacao e Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Descricao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.2 Solucao Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Metodo de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5 Organizacao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 Fundamentacao Teorica 25
2.1 Consideracoes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Desenvolvimento Distribuıdo de Software . . . . . . . . . . . . . . . . . . . 25
2.3 Percepcao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Ontologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6 Engenharia de Software Experimental . . . . . . . . . . . . . . . . . . . . . 33
2.7 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3 Trabalhos Relacionados 37
3.1 Consideracoes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Palantır . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Ariadne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4 Augur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5 ADAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6 ProjectWatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.7 EvolTrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.8 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.9 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4 Abordagem DiSEN-CollaborAR 50
4.1 Consideracoes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2 Caracterısticas da Abordagem . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Visao Geral da Abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.1 Cenario de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.2 Modelo Conceitual da DiSEN-CollaborAR . . . . . . . . . . . . . . 54
4.4 Elementos de Percepcao e Contexto de Artefato . . . . . . . . . . . . . . . 58
4.5 Representacao de Contexto para Artefatos . . . . . . . . . . . . . . . . . . 61
4.6 Rastreabilidade entre Artefatos de Software . . . . . . . . . . . . . . . . . 69
4.7 Apresentacao da Rede de Artefatos de Software . . . . . . . . . . . . . . . 71
4.8 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5 Arquitetura e Implementacao 75
5.1 Consideracoes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2 Arquitetura do ACAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.1 Pacote model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.2 Pacote event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.3 Pacote extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.4 Pacote agency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.5 Pacote visualize . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3 Implementacao do ACAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.4 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6 Estudo Experimental 89
6.1 Consideracoes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2 Definicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.3 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.3.1 Definicao das Hipoteses . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.3.2 Descricao da Instrumentacao . . . . . . . . . . . . . . . . . . . . . . 93
6.3.3 Selecao do Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3.4 Selecao dos Indivıduos . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.3.5 Selecao de Variaveis . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.3.6 Projeto do Experimento . . . . . . . . . . . . . . . . . . . . . . . . 96
6.3.7 Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.4 Operacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.4.1 Preparacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.4.2 Execucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.4.3 Validacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.5 Analise e Interpretacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.5.1 Estatıstica Descritiva . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.5.2 Analise de Outliers . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.5.3 Teste de Hipoteses . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.5.4 Analise Qualitativa . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.6 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.7 Licoes Aprendidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.8 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7 Conclusoes 115
7.1 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.2 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.3 Limitacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.5 Publicacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Referencias 122
Apendice A Instrumentos do Estudo Experimental 131
A.1 Consideracoes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
17
Capıtulo
1
Introducao
1.1 Consideracoes Iniciais
Um grande numero de organizacoes tem distribuıdo seus projetos de desenvolvimento de
software em varios locais, muitas vezes ao redor do mundo. Nesse cenario, o desenvolvi-
mento de software e realizado colaborativamente por equipes distribuıdas, caracterizando
o Desenvolvimento Distribuıdo de Software (DDS). Entretanto, essa estrategia de desen-
volvimento trouxe novos desafios relacionados a comunicacao, coordenacao e cooperacao
(Cibotto et al., 2009; Herbsleb et al., 2000; Herbsleb e Moitra, 2001; Jimenez et al., 2010;
Sangwan et al., 2006) para os projetos de software, provocados pela distancia geografica e
temporal entre as equipes (Ivcek e Galinac, 2008). Segundo Herbsleb e Moitra (2001), em
ambientes distribuıdos, os canais de comunicacao e a capacidade dos desenvolvedores
trabalharem em conjunto sao reduzidos. Dessa forma, a reducao na frequencia de
comunicacao afeta diretamente a produtividade e a qualidade do desenvolvimento de
software (Jimenez et al., 2010).
Durante o desenvolvimento de um software, os membros das equipes distribuıdas
trabalham sobre varios artefatos de software, em momentos diferentes, com indivıduos
distintos, em diversos papeis e formam diferentes perspectivas de seu workspace (Omo-
ronyia et al., 2010). Quando um membro da equipe trabalha sobre um certo artefato
de software em um determinado momento, ele precisa ter, tambem, o entendimento que
os outros membros tiveram quando estavam trabalhando sobre esse mesmo artefato. As
acoes realizadas no passado sobre um artefato de software podem fornecer informacoes
18
contextuais importantes para as atividades atuais. Assim, perceber as acoes uns dos
outros pode facilitar a compreensao e diminuir as barreiras da comunicacao impostas pela
distancia geografica (Chaves, 2009).
Analisando os trabalhos apresentados no Capıtulo 3 e, com base na revisao sistematica
apresentada em Vivian et al. (2011), foi possıvel observar que, embora existam pesquisas
voltadas para a percepcao de informacoes contextuais sobre os artefatos de software que
sao produzidos e/ou modificados no desenvolvimento de software com equipes distribuıdas,
existem algumas lacunas que ainda sao desafios. Tais lacunas sao: (i) ampliar a area de
percepcao sobre os artefatos de software a partir de informacoes capturadas de mais de
uma fonte de informacao; (ii) apoiar outros tipos de artefatos de software, alem de codigo
fonte; e (iii) gerar relacoes de dependencias, automaticamente, entre os diferentes tipos
de artefatos de software e apresenta-las por meio de recursos visuais.
Os desafios de comunicacao e coordenacao gerados pelo DDS, decorrentes da distancia
geografica e temporal, demandam por uma infraestrutura que auxilie o desenvolvimento
de software e que seja adequada para equipes distribuıdas. Assim, e oportuno projetar
mecanismos que oferecam meios para aumentar a percepcao de contexto em um ADDS
(Ambiente de Desenvolvimento Distribuıdo de Software), tal como o DiSEN (Distributed
Software Engineering eNvironment) (Huzita et al., 2007).
O restante deste capıtulo esta organizado da seguinte forma. Secao 1.2 descreve a
contextualizacao e a motivacao deste trabalho. Secao 1.3 apresenta os objetivos deste
trabalho. Secao 1.4 apresenta o metodo de pesquisa utilizado para a realizacao deste
trabalho. E por fim, na Secao 1.5 e apresentada a organizacao do trabalho.
1.2 Contextualizacao e Motivacao
O DDS tem sido estudado por diversos pesquisadores e profissionais (Aversano et al.,
2004; Jimenez et al., 2009, 2010; Lanubile et al., 2010; Noll et al., 2010; Prikladnicki et al.,
2011; Sengupta et al., 2006; da Silva et al., 2010; Whitehead, 2007) e, dessa forma, varias
metodologias e ferramentas de apoio tem sido propostas e produzidas. Uma ferramenta
fundamental para apoiar o desenvolvimento de software com equipes distribuıdas e o
Sistema de Controle de Versao (SCV), que permite a contribuicao dos desenvolvedores
em um projeto por meio da coordenacao dos recursos de desenvolvimento e a mesclagem
de linhas de codigo fonte (de Alwis e Sillito, 2009). SCV populares incluem Mercurial1,
1http://mercurial.selenic.com/
19
Git2, Subversion3, entre outros. Outra ferramenta importante para os projetos de software
e a Ferramenta CASE (Computer Aided Software Engineering), que apoia a construcao,
a manipulacao e a apresentacao de modelos tais como diagramas UML (Unified Modeling
Language) (Lahtinen e Peltonen, 2005). Ferramentas CASE UML populares incluem
ArgoUML4, Astah5, MagicDraw6, entre outros.
Os diferentes tipos de artefatos de software, tais como codigo fonte e diagrama de
classes, possuem diferentes estruturas e formatos. Alem disso, ambos SCV e Ferramenta
CASE UML nao possuem mecanismos para associar os artefatos de software de tipos
diferentes de acordo com a sua estrutura interna. Por exemplo, quando um codigo fonte e
alterado, o indivıduo nao tem conhecimento sobre os artefatos, tanto o codigo fonte como
o diagrama de classes, que podem sofrer impacto ou ter relacao com a sua atividade.
Tal fato dificulta aos membros das equipes distribuıdas estarem cientes sobre o que esta
acontecendo nos artefatos de software.
Outra questao, diz respeito as circunstancias envolvidas na producao e na modificacao
dos artefatos de software. Por vezes, e importante conhecer o usuario que manipulou
um artefato, a ferramenta utilizada ou a data que o evento ocorreu. Tais circunstancias
definem a informacao de contexto para uma dada situacao. A falta de percepcao de
contexto sobre os artefatos de software pode produzir ambiguidades, alem de falhas e
incertezas, durante o desenvolvimento distribuıdo de software (Chaves, 2009).
No desenvolvimento de software com equipes distribuıdas, os membros das equipes
precisam estar cientes das atividades dos outros, o progresso das tarefas, o estado dos
artefatos, os proprietarios dos artefatos, entre outros (Steinmacher et al., 2012). A
ausencia da percepcao sobre o que esta acontecendo em outras partes do projeto leva
a equıvocos e erros, afetando o trabalho de toda a equipe (Gutwin et al., 2005). De
acordo com Gutwin et al. (2004), a percepcao e essencial para as equipes distribuıdas
coordenarem seus esforcos, adicionar codigo sem causar problemas, fazer mudancas que
afetam outras partes do codigo e evitar retrabalho.
1.2.1 Descricao do Problema
Mecanismos de percepcao sao essenciais para fornecer aos indivıduos informacoes contex-
tuais sobre as acoes que ocorrem sobre as entidades, tais como os artefatos de software
2http://git-scm.com/3http://subversion.apache.org/4http://argouml.tigris.org/5http://astah.net/6http://www.nomagic.com/
20
(Vivian et al., 2011). Ao longo dos anos, diversas ferramentas e abordagens (Cepeda et
al., 2010; Froehlich e Dourish, 2004; Gutwin et al., 2005; de Lucia et al., 2005; Sarma et
al., 2003; de Souza et al., 2004) foram propostas para apoiar a percepcao de contexto sobre
artefatos de software em projetos de desenvolvimento distribuıdo de software. Contudo,
a maioria dos trabalhos encontrados na literatura foca apenas em um tipo de artefato
de software, conforme apresentado no Capıtulo 3. Alem disso, a fonte de informacao
mais comum para a captura de informacoes sobre os artefatos de software e o Sistema de
Controle de Versao. Nesse caso, as relacoes de dependencias geradas entre os artefatos de
software correspondem apenas ao artefato do tipo codigo fonte.
As distancias geografica e temporal entre as equipes dificultam a disseminacao de
informacoes contextuais sobre a producao e/ou a modificacao dos artefatos de software.
Tal fato afeta a compreensao dos indivıduos sobre os artefatos de software resultantes de
um trabalho colaborativo. Dessa forma, a reducao de tal compreensao, impacta sobre a
producao e a modificacao dos artefatos de software, que podem apresentar ambiguidades
e, assim, provocar falhas ou incertezas durante o ciclo de vida de um projeto de software.
As falhas de coordenacao e os problemas de comunicacao entre os membros de equipes
distribuıdas podem gerar problemas de integracao de software (Cataldo et al., 2007).
Alem disso, os problemas de coordenacao podem gerar atrasos no projeto e, tambem,
piorar a qualidade e aumentar o custo do produto (Cataldo et al., 2006). Uma maneira
para detectar as falhas de coordenacao e os problemas de comunicacao pode ser por meio
do trabalho duplicado ou inconsistente sobre os artefatos de software que sao produzidos
e/ou modificados.
Logo, os indivıduos devem perceber as informacoes contextuais (e.g. quem realizou
determinada modificacao em um artefato de software, onde, como e quando as acoes
aconteceram) sobre os artefatos de software que sao produzidos e/ou modificados em um
projeto de software com equipes distribuıdas.
1.2.2 Solucao Proposta
O cenario descrito anteriormente motiva o desenvolvimento de uma infraestrutura capaz
de apoiar a disseminacao de informacoes quando se trata de artefatos de software. Desse
modo, visando apoiar a percepcao de contexto sobre artefatos de software, este trabalho
propoe uma abordagem que apresenta recursos para a captura de informacoes contextuais
a partir de repositorios compartilhados e, com base nas informacoes contextuais captura-
das e processadas, gerar relacoes de dependencias entre os artefatos de software para, em
seguida, serem visualizadas.
21
Tal abordagem e uma compilacao de algumas ferramentas de desenvolvimento de
software, alem de um prototipo que foi desenvolvido para dar apoio ao funcionamento
do mecanismo da abordagem.
Acredita-se que a abordagem proposta pode auxiliar nas atividades de desenvolvimento
de software em relacao aos artefatos de software que sao produzidos e/ou modificados
durante o desenvolvimento de software realizado por equipes distribuıdas. Dessa forma,
espera-se reduzir os problemas de comunicacao e coordenacao e, consequentemente,
melhorar a clareza das informacoes sobre o desenvolvimento do software para aumentar
a produtividade e a qualidade do produto de software desenvolvido.
1.3 Objetivos
O principal objetivo desta pesquisa foi a investigacao de uma abordagem adequada para
apoiar a percepcao de contexto sobre os artefatos de software no desenvolvimento de
software realizado por equipes distribuıdas. Como objetivos especıficos, apontam-se:
• Identificar as peculiaridades do desenvolvimento distribuıdo de software que impac-
tam sobre a producao e a modificacao dos artefatos de software;
• Definir um modelo conceitual, alem das estruturas e dos elementos, que compoe a
abordagem para apoiar a percepcao de contexto sobre artefatos de software para
equipes distribuıdas;
• Descrever e especificar os elementos de percepcao e contexto de artefato e, tambem,
um modelo de representacao que ofereca semantica para as informacoes dos artefatos
de software;
• Especificar um meio para gerar automaticamente as relacoes de dependencias entre
os diferentes tipos de artefatos de software e, tambem, definir recursos visuais para
a apresentacao de informacoes contextuais sobre tais artefatos.
1.4 Metodo de Pesquisa
Com base em da Silva e Menezes (2005), este trabalho pode ser caracterizado da seguinte
maneira: (i) quanto a natureza, e uma pesquisa aplicada, pois visa gerar conhecimentos
para a aplicacao pratica e contribuir com avancos teoricos em variaveis crıticas para
aumentar a percepcao pelos membros das equipes distribuıdas sobre o contexto dos
22
artefatos de software; (ii) quanto aos objetivos, e uma pesquisa exploratoria, pois
visa proporcionar uma aproximacao com o problema e conhecer os fatos e fenomenos
relacionados ao tema de pesquisa; e (iii) quanto aos procedimentos tecnicos, e uma
pesquisa experimental, pois a partir do objeto de estudo, neste caso a abordagem proposta,
foram selecionadas as variaveis capazes de influencia-lo e foram definidas as formas de
controle e de observacao dos efeitos que a variavel produz sobre tal objeto.
O desenvolvimento deste trabalho e composto por seis fases: Revisao Bibliografica,
Revisao Sistematica, Definicao da Abordagem, Implementacao do Prototipo, Avaliacao e
Redacao, conforme apresentado na Figura 1.1.
Na primeira fase, Revisao Bibliografica, foi realizada uma revisao inicial da literatura,
que teve como objetivo formar um referencial teorico consistente e visualizar o estado
da arte. Esta etapa envolveu estudos sobre desenvolvimento distribuıdo de software,
percepcao, contexto, ontologia e Engenharia de Software Experimental (ESE). Dessa
forma, o conhecimento de tais conceitos foi necessario para a compreensao dos aspectos
explorados neste trabalho.
A segunda fase, Revisao Sistematica, consistiu na realizacao de um processo de
avaliacao e interpretacao de todas as pesquisas disponıveis relacionadas ao assunto de
interesse, seguindo o modelo de protocolo apresentado em Kitchenham (2007). Assim,
uma revisao sistematica, apresentada em Vivian et al. (2011), foi conduzida com o
objetivo de identificar estudos que apresentavam tecnicas para capturar e apresentar
informacoes contextuais sobre os artefatos de software produzidos e/ou modificados no
desenvolvimento distribuıdo de software. Alem disso, tal revisao sistematica visou a
identificacao de informacoes e de propriedades importantes para apoiar a percepcao de
contexto sobre artefatos de software.
Na terceira fase, Definicao da Abordagem, foi possıvel analisar e definir, com base nas
etapas anteriores, os elementos necessarios para uma abordagem que oferece uma infra-
estrutura para que os membros de equipes de projeto de software, que estao distribuıdas
geograficamente, possam perceber as contribuicoes dos demais desenvolvedores sobre as
informacoes contextuais relacionadas aos artefatos de software. Apos a identificacao, os
elementos da abordagem foram descritos e especificados de acordo com as caracterısticas
incorporadas por tais elementos.
A quarta fase, Implementacao do Prototipo, consistiu na descricao da arquitetura
e na implementacao de um prototipo que apoia a abordagem proposta. Por meio da
implementacao do prototipo, verificou-se as funcionalidades da infraestrutura em prover
informacoes contextuais pertinentes aos artefatos de software. Alem disso, o prototipo
23
implementado foi utilizado no estudo experimental para apoiar a realizacao das atividades
e, consequentemente, ser possıvel a avaliacao da abordagem proposta.
Figura 1.1: Fases do metodo de pesquisa
A quinta fase, Avaliacao, consistiu na realizacao de um estudo experimental para
avaliar os benefıcios proporcionados pela abordagem proposta, com base nas seguintes
etapas: definicao, planejamento, operacao, analise e interpretacao dos dados. Por meio
de um experimento controlado em laboratorio, os dados gerados durante as atividades
foram coletados e, em seguida, analisados por meio da estatıstica experimental.
Por fim, a sexta fase, Redacao, consistiu em produzir este documento de dissertacao,
na escrita e submissao de artigos relacionados a este trabalho e na defesa da dissertacao.
24
1.5 Organizacao do Trabalho
Este capıtulo apresentou os objetivos deste trabalho, embasados nos problemas encon-
trados durante o desenvolvimento distribuıdo de software no que se refere a percepcao
de contexto sobre artefatos de software. Alem disso, foram descritos a contextualizacao,
a motivacao e o metodo de pesquisa que nortearam o desenvolvimento do mesmo. O
restante desta dissertacao esta organizado da seguinte forma:
O Capıtulo 2 apresenta os conceitos relevantes que embasaram o desenvolvimento
deste trabalho, sendo eles: desenvolvimento distribuıdo de software, percepcao, contexto,
ontologia e Engenharia de Software Experimental.
O Capıtulo 3 discute os trabalhos encontrados na literatura que forneceram subsıdios
para a elaboracao de uma abordagem para percepcao de contexto sobre artefatos de
software no desenvolvimento distribuıdo de software. Alem disso, e apresentada uma
comparacao entre as ferramentas em relacao a alguns aspectos identificados em tais
trabalhos.
O Capıtulo 4 descreve a abordagem proposta em termos de estruturas e propriedades
incorporadas pelos elementos que se constituem em pilares que sustentam as carac-
terısticas de tal abordagem.
O Capıtulo 5 descreve a arquitetura do prototipo e detalha como seus elementos
arquiteturais sao cumpridos pela implementacao para apoiar a abordagem proposta.
O Capıtulo 6 descreve o plano e o resultado de um estudo experimental para avaliar
os benefıcios proporcionados pela abordagem proposta.
O Capıtulo 7 discute as contribuicoes e limitacoes do trabalho e apresenta os trabalhos
futuros.
25
Capıtulo
2
Fundamentacao Teorica
2.1 Consideracoes Iniciais
Neste capıtulo sao apresentados os conceitos relacionados a desenvolvimento distribuıdo
de software, percepcao, contexto, ontologia e Engenharia de Software Experimental, que
constituem a fundamentacao teorica deste trabalho. O conhecimento de tais conceitos
possibilita compreender os aspectos explorados nos capıtulos subsequentes.
O restante deste capıtulo esta organizado da seguinte forma. Secao 2.2 descreve os
conceitos sobre desenvolvimento distribuıdo de software. Secao 2.3 apresenta os conceitos
sobre percepcao. Secao 2.4 apresenta os conceitos sobre contexto. Secao 2.5 apresenta os
conceitos sobre ontologia. Secao 2.6 aborda os conceitos sobre Engenharia de Software
Experimental. Finalmente, na Secao 2.7 sao apresentadas as consideracoes finais.
2.2 Desenvolvimento Distribuıdo de Software
O software tornou-se um componente vital de quase todos os negocios. O sucesso de
uma organizacao depende, cada vez mais, da adocao do software como uma vantagem
competitiva (Carmel, 1999). Em busca de tal vantagem competitiva, diversas orga-
nizacoes adotaram atividades multilocais, multiculturais e, algumas vezes, globalmente
distribuıdas, aumentando a produtividade, melhorias na qualidade do produto e a reducao
de custos (Audy e Prikladnicki, 2007; Huzita et al., 2008). Assim, a globalizacao, o
crescimento da importancia dos sistemas de informacao nas empresas e os processos de
26
terceirizacao tem proporcionado o Desenvolvimento Distribuıdo de Software (DDS) (Audy
e Prikladnicki, 2007).
O DDS pode ser definido como o desenvolvimento de software que utiliza equipes
constituıdas por indivıduos geograficamente dispersos, promovendo a colaboracao e a
cooperacao entre grupos que trabalham em conjunto. Os participantes podem estar
localizados em cidades ou paıses diferentes, distantes temporal e geograficamente (Pri-
kladnicki e Audy, 2004) e, algumas vezes, tem culturas e lınguas diferentes (Sangwan et
al., 2006). Quando a dispersao da equipe atinge dimensoes globais, o DDS e chamado
de Desenvolvimento Global de Software (GSD – Global Software Development) (Sahay,
2003).
As tarefas e os projetos cada vez mais complexos e os prazos de execucao cada
vez menores, tem incentivado as organizacoes a substituırem o esforco individual pelo
trabalho envolvendo equipes que executam atividades colaborativas. Segundo Herbsleb
e Moitra (2001), os fatores que tem contribuıdo para o crescimento do DDS sao: (i)
as vantagens da proximidade do mercado de negocios, incluindo o conhecimento de
clientes e as condicoes locais; (ii) a pressao para reduzir o “time-to-market1” utilizando as
diferencas de fuso-horario no desenvolvimento “round-the-clock 2”; e (iii) a necessidade de
um conjunto de recursos globais para o sucesso e custo competitivo, independentemente
da sua localizacao.
O desenvolvimento distribuıdo de software e caracterizado por nıveis de dispersao de
acordo com as dimensoes da distancia organizacional e da distancia geografica. Segundo
Paasivaara (2004), a distancia organizacional pode ser: (i) uma organizacao; e (ii) duas
ou mais organizacoes. E, distancia geografica pode ser: (i) mesmo local; (ii) mesmo paıs;
e (iii) diferentes paıses. A Figura 2.1 apresenta os nıveis de dispersao no desenvolvimento
distribuıdo de software.
No entanto, aliado aos benefıcios, o DDS trouxe desafios para os projetos de soft-
ware, tais como diferencas culturais e linguısticas, confianca, coordenacao e controle,
comunicacao e gestao do conhecimento, provocados pela distancia geografica e temporal
(Herbsleb e Moitra, 2001; Ivcek e Galinac, 2008). Nesse sentido, diversos trabalhos (Ci-
botto et al., 2009; Herbsleb et al., 2000; Herbsleb e Moitra, 2001; Mockus e Herbsleb, 2001;
Sangwan et al., 2006) identificam e descrevem os principais desafios no desenvolvimento
de software com equipes distribuıdas.
1Tempo de lancamento de um produto no mercado.2Desenvolvimento contınuo, aproveitando a diferenca de fuso horario entre paıses.
27
Figura 2.1: Nıveis de dispersao em DDS (Paasivaara, 2004)
Um aspecto fundamental no DDS e a comunicacao (Trindade et al., 2008), pois e
um componente essencial para a colaboracao no processo de desenvolvimento de software
(Herbsleb et al., 2000). Entretanto, em ambientes distribuıdos, os canais de comunicacao
sao reduzidos e a capacidade dos desenvolvedores trabalharem em conjunto tambem,
devido a distancia geografica e temporal entre as equipes de desenvolvimento (Herbsleb e
Moitra, 2001). Alem disso, a complexidade dos projetos de DDS dificulta a resolucao dos
problemas de comunicacao. De acordo com Eckhard (2008), tal dificuldade e causada
por tres fatores: (i) a grande quantidade de elementos heterogeneos como pessoas,
codigo fonte, hardware e software, dificultando a integracao de ferramentas; (ii) muitas
dependencias entre tais elementos; e (iii) as constantes mudancas nos ambientes de
desenvolvimento.
No desenvolvimento de software com equipes distribuıdas, os indivıduos trocam uma
grande quantidade de informacoes utilizando ferramentas e formatos diferentes, sem seguir
um padrao de comunicacao, gerando incompreensoes durante o ciclo de vida do software
(Jimenez et al., 2010). Alem disso, quando as equipes estao localizadas em paıses
diferentes, surgem outros problemas, tais como interpretacoes erradas e ambiguidades,
uma vez que os membros possuem idiomas e culturas diferentes (Soares et al., 2012). Tais
problemas causam uma reducao na frequencia de comunicacao, afetando, diretamente, a
produtividade e a qualidade do desenvolvimento (Jimenez et al., 2010). Assim, equipes
distribuıdas, em um trabalho colaborativo, necessitam de uma infraestrutura capaz de
garantir a troca eficiente de informacoes entre os envolvidos (Chaves, 2009).
28
Segundo Herbsleb (2007), os membros de equipes distribuıdas compartilham pouco
contexto e tem pouco conhecimento sobre o que os outros membros estao fazendo,
tornando o contato difıcil pela falta de informacao contextual. Perceber as acoes uns
dos outros facilita a compreensao e diminui as barreiras da comunicacao, impostas pela
distancia fısica (Chaves, 2009).
2.3 Percepcao
Na execucao de um trabalho colaborativo por um grupo de pessoas, tal como em DDS, e
importante que os indivıduos compreendam as atividades realizadas por outros indivıduos
para que isso seja relevante para a realizacao de suas proprias tarefas e, assim, otimizar o
andamento dos trabalhos. Percepcao3 e uma compreensao das atividades dos outros, que
oferece um contexto para a propria atividade do indivıduo (Dourish e Bellotti, 1992).
A percepcao corresponde ao conhecimento e compreensao das interacoes que ocorrem
em um grupo que sao relevantes para o desenvolvimento das atividades dos seus par-
ticipantes, compondo, assim, o estado mental dos usuarios (Sohlenkamp, 1998; Vieira,
2006). Para alcancar esse estado mental sao necessarias tecnicas, empregadas em um
sistema, que oferecam elementos de percepcao, conhecidas como mecanismos de percepcao
(Sohlenkamp, 1998). Assim, um mecanismo de percepcao e o meio usado para que os
membros do grupo recebam as informacoes que apoiem a sua percepcao.
A percepcao e essencial para o fluxo e a naturalidade do trabalho, auxiliando a
reduzir as sensacoes de trabalho impessoal e de distancia, comuns em ambientes virtuais
(Gerosa et al., 2001). Assim, no DDS e necessario manter os indivıduos cientes das acoes
que ocorrem com as equipes distribuıdas para assegurar o andamento das atividades
individuais e a coordenacao do trabalho como um todo. Para tal, elementos de percepcao
fornecem informacoes para o indivıduo monitorar as acoes sobre os objetos de cooperacao
ao longo do tempo em um projeto de software. Sem essa percepcao, os indivıduos nao
podem mensurar a qualidade de seu proprio trabalho relativo aos objetivos e progressos
do grupo (Dourish e Bellotti, 1992).
Segundo Gutwin e Greenberg (2002), o conceito de percepcao possui quatro carac-
terısticas: (i) percepcao e o conhecimento sobre o estado de um ambiente delimitado no
tempo e no espaco; (ii) ambientes se modificam com o tempo, entao a percepcao precisa
ser mantida de forma contınua e atualizada; (iii) pessoas interagem e exploram o ambiente,
e a manutencao da percepcao e realizada por meio dessa interacao; e (iv) a percepcao e
3Do original em ingles, awareness. Segundo Vieira et al. (2011), a traducao mais adotada no Brasil parao termo awareness e percepcao. A percepcao ocorre quando um indivıduo “percebe” algo no ambiente.
29
um objetivo secundario na atividade, o objetivo principal nao e manter a percepcao, mas
e completar alguma tarefa no ambiente.
Para ter compreensao e conhecimento sobre o que ocorre em um grupo que trabalha
colaborativamente, o indivıduo deve ter informacoes que possibilitem a sua percepcao.
Gutwin e Greenberg (2002) apresentam um conjunto de ideias que sao fundamentais para
o apoio a percepcao. Tal conjunto de ideias e composto por elementos de percepcao, os
quais correspondem a cinco questoes – quem (who), o que (what), onde (where), como
(how) e quando (when) – que devem ser respondidas para que um indivıduo compreenda
algo do qual nao tem conhecimento.
De acordo com Vieira (2006), dois fatores influenciam a percepcao: o modo de
interacao e o papel desempenhado pelo participante do grupo. Quanto ao modo de
interacao, Molli et al. (2002) afirmam que, com base no objeto de cooperacao, as interacoes
colaborativas sao classificadas em: interacao sıncrona, assıncrona ou multissıncrona. Na
interacao sıncrona os participantes trabalham ao mesmo tempo sobre um mesmo dado.
Na interacao assıncrona os participantes trabalham em tempos diferentes sobre um mesmo
dado. Ja na interacao multissıncrona os participantes tem uma copia de um dado
compartilhado e as modifica em paralelo, para entao sincroniza-las e restabelecer uma
visao comum dos dados.
Quanto ao papel desempenhado, cada participante do grupo possui atribuicoes e
responsabilidades que afetam a necessidade de percepcao dos mesmos. Conforme Vieira
(2006), ha tres nıveis hierarquicos de papeis: (i) nıvel operacional – usuarios que executam
o trabalho, desejam informacoes relacionadas as suas proprias atividades; (ii) nıvel tatico
– usuarios que coordenam as atividades, desejam informacoes com visao de alto nıvel dos
dados; e (iii) nıvel estrategico – usuarios que definem metas e objetivos para o grupo,
desejam informacoes gerais sobre os grupos e os dados historicos de interacoes.
No ambito do desenvolvimento de software com equipes distribuıdas, os membros
das equipes devem perceber o andamento das atividades realizadas pelos demais e
compreender como os resultados gerados por essas atividades podem ser conjugados com
os seus proprios, para chegarem ao resultado final mais rapidamente (Araujo et al., 1997).
Nesse caso, a ausencia de apoio a percepcao aumenta as dificuldades para a producao de
um software consistente e de qualidade, de forma eficiente (Pinheiro et al., 2001).
2.4 Contexto
A definicao de contexto tem sido objeto de estudo de pesquisadores de diversas areas
de Ciencia da Computacao (Belotti et al., 2004; Bouquet et al., 2003; Brezillon, 2003;
30
Franklin, 2003). A falta de consenso sobre os conceitos, produz diferentes visoes sobre
contexto, como defini-lo e como considera-lo em sistemas computacionais. Assim, ha
varias definicoes para esse conceito, algumas complementares, outras limitadas a area da
computacao que buscam apoiar (Vieira, 2006). Bazire e Brezillon (2005) catalogaram
mais de 150 definicoes sobre o termo contexto, originadas de diferentes domınios.
Uma definicao, amplamente referenciada, afirma que contexto e qualquer informacao
que caracteriza a situacao de uma entidade, na qual uma entidade e uma pessoa, lugar
ou objeto considerados relevantes para a interacao entre um usuario e uma aplicacao,
incluindo o proprio usuario e a aplicacao (Dey e Abowd, 2000). Na area de Sistemas
Colaborativos, Gross e Prinz (2003) definem contexto como as condicoes (circunstancias
como tempo e localizacao) interrelacionadas (algum tipo de continuidade no sentido mais
amplo) em que alguma coisa (um usuario, um grupo ou um artefato) existe (presenca) ou
ocorre (uma acao executada por um ator).
Embora existam varias definicoes de contexto, conforme Vieira (2008), os pesquisa-
dores concordam em alguns aspectos: (i) contexto existe somente quando relacionado
a outra entidade (e.g. tarefa, agente ou interacao); (ii) contexto e um conjunto de
itens (e.g. conceitos, regras e proposicoes) associados a uma entidade; e (iii) um item e
considerado parte do contexto somente se for util para apoiar a resolucao de um problema.
Com base nessas observacoes, Vieira (2008) distinguiu os termos contexto e elemento
contextual, definindo que “um elemento contextual e qualquer dado ou informacao que
permite caracterizar uma entidade em um domınio”, enquanto que “o contexto e um
conjunto de elementos contextuais instanciados que sao necessarios para apoiar a execucao
de uma tarefa”. Essas definicoes foram utilizadas no desenvolvimento deste trabalho
por representar o contexto de forma dinamica, relacionando o mesmo com os elementos
pertinentes para a interacao entre indivıduo e aplicacao.
Brezillon e Pomerol (1999) propoem um modelo que classifica o contexto de acordo
com o foco de atencao, que pode ser uma tarefa, um passo para resolver um problema
ou uma tomada de decisao. O foco de atencao corresponde a um determinado estagio
do trabalho em que um subconjunto de informacoes contextuais e mobilizado, situado,
organizado e estruturado para alcancar um resultado relevante e significativo (Gauvin et
al., 2004).
Conforme apresenta a Figura 2.2, Brezillon e Pomerol (1999) classificam o contexto em
tres partes, de acordo com o foco de atencao atual do usuario: (i) conhecimento contextual
(CK – contexual knowledge); (ii) conhecimento externo (EK – external knowledge); e
(iii) contexto procedural (PC – proceduralized context). Conhecimento contextual e o
conhecimento relevante e tem uma forte relacao com o foco. Conhecimento externo e a
31
parte do conhecimento que nao e relevante para o foco de atencao e que nao e necessario
para apoiar a tarefa. Por fim, contexto procedural e o subconjunto do conhecimento
contextual que e invocado, organizado, estruturado e situado de acordo com o foco de
atencao, e utilizado para apoiar a tarefa em execucao naquele foco.
Figura 2.2: Tipos de contexto (Brezillon e Pomerol, 1999)
Segundo Rosa et al. (2003), o contexto pode oferecer uma complexa descricao do
conhecimento compartilhado sobre circunstancias fısicas, sociais e historicas, dentro das
quais acoes ou eventos ocorrem. Assim, o uso de contexto em sistemas colaborativos
fornece apoio para a comunicacao entre os membros do grupo, diminuindo ambiguidades
e conflitos.
2.5 Ontologia
O conceito de Ontologia surgiu na Filosofia e tem sido usada no domınio da Computacao
desde o final dos anos 70, com o intuito de compartilhar conhecimento. Segundo Gruber
(1993), uma ontologia e uma especificacao formal e explıcita de uma conceitualizacao.
Para o autor, uma conceitualizacao corresponde a uma visao abstrata e simplificada de um
domınio de conhecimento que se deseja representar. Para Noy e McGuiness (2001), uma
ontologia e uma descricao formal e explıcita dos conceitos de um domınio de conhecimento,
das suas propriedades (atributos e relacionamentos) e restricoes. Para este trabalho,
foi utilizada a definicao de Gruber (1993), pois o objetivo da ontologia, neste trabalho,
consiste em representar, formal e explicitamente, os conceitos no ambiente DiSEN (Huzita
et al., 2007), oferecendo semantica a esses conceitos.
32
Uma ontologia permite uma interpretacao automatica dos conceitos e relacionamentos
de um domınio de conhecimento (Noy e McGuiness, 2001). Assim, por meio da ontologia
e possıvel representar um conhecimento, oferecendo semantica para que humanos e
maquinas possam entender. De acordo com Noy e McGuiness (2001), os principais be-
nefıcios do uso de ontologias sao: (i) compartilhamento do entendimento comum a diversas
pessoas ou agentes de software de um domınio de conhecimento; (ii) facilitar a manutencao
do conhecimento por meio de definicoes explıcitas e formais, possibilitando uma melhor
compreensao, o reuso e a sua extensao; e (iii) separar o domınio de conhecimento de uma
aplicacao especıfica, permitindo a utilizacao da mesma ontologia em diferentes aplicacoes
de um mesmo domınio.
Segundo Nunes et al. (2007), os fatores que motivam o uso de ontologias na forma-
lizacao de modelo de contexto sao:
• Compartilhar um entendimento comum sobre a estrutura da informacao, entre
pessoas e agentes computacionais;
• Permitir reutilizacao dentro do domınio de conhecimento;
• Tornar explıcitas as concepcoes acerca do domınio;
• Analisar o conhecimento do domınio;
• Permitir o compartilhamento e a reutilizacao do conhecimento do domınio;
• Permitir o uso de mecanismos de inferencia para raciocinar sobre varios contextos.
Chaves et al. (2011) apresentam uma ontologia, a OntoDiSENv1, para o domınio do
desenvolvimento distribuıdo de software, especificamente voltada para o ambiente DiSEN
(Huzita et al., 2007). Tal ontologia descreve as entidades e os elementos contextuais
que devem ser representados e disseminados pelo modelo DiSEN-CSE (DiSEN-Context
Sensitive Environment), proposto por Chaves et al. (2010). Conforme Chaves et al.
(2011), o desenvolvimento dessa ontologia foi baseada sobre os seguintes itens:
Definicao do domınio: ambiente de desenvolvimento global de software;
Definicao da aplicacao: ambiente DiSEN;
Definicao do objetivo principal: representar de forma nao ambıgua as informacoes
relacionadas ao contexto das acoes de indivıduos, locais e ferramentas de um ambiente de
desenvolvimento global de software, mais especificamente, o DiSEN;
Definicao dos usuarios: os usuarios da ontologia sao os usuarios das ferramentas do
33
ambiente DiSEN, servicos e agentes de software disponıveis no ambiente;
Definicao dos recursos: ferramenta de modelagem (Protege 4.04) e linguagem de
modelagem (OWL-DL5 – Web Ontology Language - Description Logics).
Dessa forma, Chaves et al. (2011) definiram um conjunto de conceitos e seus relaci-
onamentos e, a partir de entao, a OntoDiSENv1 foi formalizada, por meio de classes e
propriedades, utilizando a linguagem OWL-DL e a ferramenta Protege.
2.6 Engenharia de Software Experimental
Experimentacao e a base do processo cientıfico, oferecendo um modo sistematico, disci-
plinado, computavel e controlado para avaliacao da atividade humana (Travassos et al.,
2002). Os experimentos verificam as teorias, fornecendo conclusoes a partir de avaliacoes.
De acordo com Basili et al. (1994), ha quatro metodos de experimentacao na area de
Engenharia de Software:
• Metodo cientıfico: um modelo e construıdo com base na observacao do mundo real,
por exemplo, um modelo de simulacao;
• Metodo de engenharia: as solucoes atuais sao estudadas e mudancas sao propostas
e, em seguida, avaliadas;
• Metodo empırico: um modelo e proposto e avaliado por meio de estudos empıricos,
por exemplo, estudos de caso e experimentos;
• Metodo analıtico: uma teoria formal e proposta e comparada com observacoes
empıricas.
Segundo Wohlin et al. (2000), cada metodo e aplicado de acordo com a situacao.
O metodo analıtico e usado em areas formais da Engenharia Eletrica e da Ciencia
da Computacao. O metodo cientıfico e usado em areas como simulacao de redes
de telecomunicacao a fim de avaliar seu desempenho. O metodo de engenharia e,
provavelmente, o mais usado na industria. O metodo empırico tem sido usado nas Ciencias
Sociais e Psicologia, os quais possuem semelhanca com a Engenharia de Software, pois
dizem respeito ao comportamento humano.
4http://protege.stanford.edu5http://www.w3.org/TR/owl-features
34
Os experimentos realizados em Engenharia de Software tem como objetivos carac-
terizar, avaliar, prever, controlar e melhorar os produtos, processos, recursos, modelos,
teorias, entre outros (Travassos et al., 2002). Alem disso, a principal razao para usar a
experimentacao em Engenharia de Software e permitir a compreensao e a identificacao de
relacoes entre variaveis diferentes (Wohlin et al., 2000).
Os experimentos em Engenharia de Software, frequentemente, sao quasi-experimentos,
pois nem sempre e possıvel selecionar participantes por aleatoriedade (Wohlin et al., 2000).
Entretanto, quasi-experimentos sao importantes e fornecem resultados validos.
Segundo Wohlin et al. (2000), ha tres estrategias de investigacao empırica: survey,
estudo de caso e experimento. O experimento geralmente e realizado em laboratorio e
fornece um alto nıvel de controle. Alem disso, a realizacao de um experimento envolve
varias fases, tais como definicao, planejamento, operacao, analise e interpretacao ate a
apresentacao e empacotamento (Wohlin et al., 2000). Tais fases fazem parte do processo
experimental, ilustrado na Figura 2.3.
Figura 2.3: Visao geral do processo de experimentacao (Wohlin et al., 2000)
A primeira fase do processo de experimentacao e a definicao. Nessa fase, o experimento
e definido em termos de problema, objetivos e metas. Desse modo, devem ser respondidas
35
questoes relacionadas ao objeto de estudo (o que sera estudado), proposito (intencao do
estudo), foco de qualidade (aspecto de qualidade a ser estudado), perspectiva (ponto de
vista em que os resultados serao interpretados) e contexto (ambiente no qual o experimento
sera realizado).
Na fase de planejamento, a base para realizar o experimento e determinada. Assim,
nessa fase o experimento e estabelecido por meio de definicao de hipoteses, descricao da
instrumentacao, selecao do contexto, selecao dos indivıduos, selecao de variaveis, projeto
do experimento e validade dos resultados do experimento. A definicao de hipoteses indica,
formalmente, a hipotese nula e as hipoteses alternativas que, apos a analise estatıstica,
podem ser aceitas ou refutadas. A descricao da instrumentacao prepara os objetos e guias
para a implementacao pratica do experimento. A selecao do contexto inclui o ambiente
no qual o experimento sera realizado. A selecao dos indivıduos escolhe a amostra da
populacao que participa do experimento. A selecao de variaveis determina as variaveis
independentes (entrada) e variaveis dependentes (saıda). O projeto do experimento
descreve como o experimento e organizado e executado. A validade identifica o quao
validos sao os resultados do experimento.
A fase de operacao apresenta a aplicacao do experimento, por meio da preparacao,
execucao e validacao dos dados. Durante a preparacao o material para ser utilizado no
experimento e organizado, os participantes sao informados a respeito do experimento e
o consentimento de participacao e preenchido pelos participantes. Durante a execucao
ocorre a conducao do experimento, por meio das tarefas definidas no planejamento. A
validacao dos dados e necessaria para verificar se foram coletados corretamente.
A fase de analise e interpretacao recebe como entrada os dados coletados para que, em
seguida, possam ser analisados e interpretados por meio da estatıstica descritiva, analise
de outliers e teste de hipoteses. A estatıstica descritiva fornece uma visualizacao dos
dados para um entendimento e interpretacao inicial sobre os dados. A analise de outliers
considera se o conjunto de dados deve ser reduzido para remover algum dado que possa
prejudicar a analise. O teste de hipoteses e realizado com o objetivo de aceitar ou refutar
as hipoteses com base em testes estatısticos.
A fase de apresentacao e empacotamento inclui a documentacao dos resultados, por
meio de artigos para publicacao, pacotes de laboratorio ou como parte de uma base de
conhecimento.
36
2.7 Consideracoes Finais
Neste capıtulo foi apresentada uma visao geral sobre os principais conceitos envolvidos
neste trabalho. Inicialmente foram descritos os conceitos sobre desenvolvimento dis-
tribuıdo de software, enfatizando esse domınio como um trabalho colaborativo. Em
seguida, foram apresentados os conceitos sobre percepcao e contexto, como tecnicas
para apoiar sistemas colaborativos. Na sequencia, foram apresentados os conceitos
sobre ontologia, enfatizando a OntoDiSENv1 como uma ontologia para o domınio do
desenvolvimento distribuıdo de software. Por fim, foram abordados os conceitos sobre
Engenharia de Software Experimental, os quais foram utilizados para a realizacao do
estudo experimental.
No proximo capıtulo sao discutidos os trabalhos relacionados e sua relevancia para a
definicao de uma abordagem para percepcao de contexto sobre artefatos de software no
desenvolvimento distribuıdo de software.
37
Capıtulo
3
Trabalhos Relacionados
3.1 Consideracoes Iniciais
Conforme apresentado no capıtulo anterior, o desenvolvimento distribuıdo de software
possui caracterısticas de um trabalho colaborativo e, portanto, necessita de uma infraes-
trutura capaz de garantir a troca eficiente de informacoes entre os envolvidos (Chaves,
2009). Para tal, tecnicas de percepcao combinadas com informacao contextual do ambi-
ente melhoram a comunicacao entre os indivıduos envolvidos em um trabalho colaborativo
(Herbsleb et al., 2000). Dessa forma, mecanismos de percepcao sao essenciais para
fornecer, aos indivıduos, informacoes contextuais sobre as acoes que ocorrem sobre as
entidades, tais como os artefatos de software (Vivian et al., 2011).
De acordo com Jimenez et al. (2009), estudos e literatura relacionada, combinando
DDS e percepcao, tem aumentado. Assim, foi necessario identificar estudos que apre-
sentavam tecnicas para capturar e apresentar informacoes contextuais sobre artefatos de
software gerados no desenvolvimento distribuıdo de software. Alem disso, aspectos sobre
os quais os pesquisadores tem se concentrado foram identificados e, assim, permitiram a
analise e a identificacao de desafios e de subsıdios para o desenvolvimento deste trabalho.
Ao longo dos anos, ferramentas, modelos e abordagens que fornecem apoio para a
percepcao de contexto sobre artefatos de software em desenvolvimento de software tem
sido propostos. Neste capıtulo sao apresentados alguns trabalhos que forneceram subsıdios
para a elaboracao de uma abordagem para apoiar a percepcao de contexto sobre artefatos
de software no desenvolvimento distribuıdo de software.
38
O restante deste capıtulo esta organizado da seguinte forma. Secao 3.2 descreve a
ferramenta Palantır. Secao 3.3 apresenta a ferramenta Ariadne. Secao 3.4 descreve
a ferramenta Augur. Secao 3.5 apresenta a ferramenta ADAMS. Secao 3.6 descreve
a ferramenta ProjectWatcher. Secao 3.7 apresenta a abordagem EvolTrack. Secao
3.8 discute os trabalhos relacionados. Finalmente, na Secao 3.9 sao apresentadas as
consideracoes finais.
3.2 Palantır
Palantır (Sarma et al., 2003) e uma ferramenta que apoia a percepcao sobre os artefatos
pelos desenvolvedores que usam sistemas de Gerencia de Configuracao de Software (GCS).
A ferramenta informa ao desenvolvedor quem e quais artefatos foram alterados, calcula o
impacto dessas alteracoes e apresenta as informacoes graficamente. A ferramenta aborda
estrategias para coleta, distribuicao, organizacao e apresentacao das informacoes sobre o
workspace do desenvolvedor. A Figura 3.1 apresenta a visualizacao grafica da Palantır.
Figura 3.1: Visualizacao grafica da Palantır (Sarma et al., 2003)
39
Palantır coleta e gera eventos relevantes dos workspaces dos desenvolvedores. Os even-
tos sao extraıdos, organizados e mostrados ao desenvolvedor por meio de um componente
de visualizacao. Assim, a visualizacao grafica fornece uma visao geral das atividades do
workspace. Cada artefato pode ser consultado em um conjunto de janelas em cascatas
que exibe o autor e o evento. Alem disso, essas janelas podem ser ordenadas por autor,
evento ou quantidade de alteracoes. Conforme apresentado na Figura 3.1, janelas com
a barra verde representam o usuario do workspace atual, enquanto janelas com a barra
vermelha representam os demais desenvolvedores.
No entanto, apesar da Palantır acompanhar a evolucao do artefato de acordo com as
alteracoes que sao realizadas, essa ferramenta nao gera relacoes de dependencias entre
os artefatos. Assim, o desenvolvedor percebe apenas as dependencias entre o autor e o
artefato, pois a ferramenta nao possui recursos para perceber as dependencias entre os
artefatos. Alem disso, a ferramenta nao apresenta informacoes sobre a estrutura interna
do artefato, tais como classe, variaveis ou metodos e, tambem, apoia a percepcao de
contexto apenas sobre artefatos de software do tipo codigo fonte.
3.3 Ariadne
Ariadne (de Souza et al., 2004) e uma ferramenta de visualizacao que apresenta a
relacao socio-tecnica entre os artefatos, aumentado a percepcao dos desenvolvedores sobre
as dependencias sociais do seu trabalho. A ferramenta captura informacoes sobre as
dependencias entre os codigos fonte e sobre seus autores a partir de repositorios de gestao
de configuracao de software. Em seguida, a ferramenta associa as dependencias de codigo
fonte e informacoes dos autores para gerar uma rede social de desenvolvedores de software.
Essa rede social descreve as dependencias entre os desenvolvedores de software com base
nas dependencias do codigo fonte. Assim, a Ariadne permite a analise e a visualizacao
de dependencias sociais que envolvem o codigo fonte, possibilitando a coordenacao, a
localizacao de especialistas e a analise do impacto das alteracoes. A Figura 3.2 apresenta
a interface com o usuario na Ariadne.
40
Figura 3.2: Interface com o usuario na Ariadne (de Souza et al., 2004)
Conforme apresentado no grafo da Figura 3.2, os vertices na cor ciano representam os
desenvolvedores em um projeto de software e arestas dirigidas de um desenvolvedor para
outro indicam que o primeiro depende do segundo. Arestas mais espessas representam
dependencias sociais mais solidas, indicando a presenca de mais dependencias tecnicas
entre os desenvolvedores. O desenvolvedor pode selecionar, utilizando as caixas de selecao
da coluna da esquerda, os autores que deseja visualizar, e pode, tambem, selecionar o
vertice no grafo para ver as informacoes de contato do autor na coluna da direita.
No entanto, a Ariadne gera o grafo apenas com informacoes sobre um tipo de
artefato de software – codigo fonte. Alem disso, a ferramenta nao apresenta informacoes
contextuais sobre os artefatos de software, mas apenas informacoes de contato sobre o
autor do artefato.
3.4 Augur
Augur (Froehlich e Dourish, 2004) e uma ferramenta de visualizacao que apresenta
informacoes sobre a estrutura dos artefatos e suas atividades relacionadas no desenvol-
vimento distribuıdo de software. A ferramenta apresenta a evolucao dos artefatos, nesse
caso codigo fonte, de um projeto e relaciona os eventos geradores das mudancas sobre esses
artefatos, fornecendo contexto que auxilia os desenvolvedores a entenderem o processo de
41
desenvolvimento. Dessa forma, um conjunto de informacoes e associado a cada linha do
codigo fonte, tais como a atividade a que se refere, ao metodo ou classe a que se refere e
o autor da linha. A Figura 3.3 apresenta a interface com o usuario na Augur.
Figura 3.3: Interface com o usuario na Augur (Froehlich e Dourish, 2004)
Conforme apresentado na Figura 3.3, o painel central da ferramenta fornece uma
visao temporal da evolucao das linhas de codigo fonte. Nıveis de coloracao identificam o
quao recente uma determinada linha foi modificada. Ao selecionar uma linha, informacoes
associadas a mesma sao exibidas no painel esquerdo e no painel inferior. O painel esquerdo
exibe informacoes sobre o autor e o tipo de estrutura (i.e. classe, variavel, metodo,
comentario) de uma determinada linha. O painel inferior exibe informacoes adicionais
tais como check-in e outros metadados do Sistema de Controle de Versao.
No entanto, a Augur apresenta informacoes sobre apenas um tipo de artefato de
software – codigo fonte. Alem disso, apesar da ferramenta acompanhar a evolucao do
artefato de acordo com as alteracoes que sao realizadas e apresentar informacoes sobre a
estrutura do artefato, nao sao geradas relacoes de dependencias entre os artefatos.
3.5 ADAMS
ADAMS – ADvanced Artefact Management System (de Lucia et al., 2005) e uma ferra-
menta que apoia a rastreabilidade e o gerenciamento de alteracoes em artefatos durante
o desenvolvimento de software. Eventos relativos as alteracoes de um artefato e seus
42
artefatos dependentes sao propagados por meio de mensagens, aumentando a percepcao
de contexto sobre o projeto. A ferramenta permite ao desenvolvedor procurar as de-
pendencias de um determinado artefato e, de acordo com o seu interesse, selecionar os
eventos que ocorrerem e que deseja receber sobre tal artefato. Alem disso, a ferramenta
permite a visualizacao das relacoes de dependencias entre os artefatos de software por
meio de um grafo. A Figura 3.4 apresenta a visualizacao do grafo de rastreabilidade na
ADAMS.
Figura 3.4: Visualizacao do grafo de rastreabilidade na ADAMS (de Lucia et al., 2005)
A ferramenta possui recursos que apoiam a percepcao de contexto, tais como visualizar
os desenvolvedores que estao trabalhando sobre um determinado artefato e, receber
notificacoes sobre eventos que ocorrem em um artefato que impactam o seu trabalho.
Para especificar a rastreabilidade, sao considerados pares de artefatos, criando vınculos
que representam relacoes entre um artefato independente (artefato fonte) e um artefato
dependente (artefato alvo). Alem disso, ıcones sao associados aos diferentes tipos de
artefatos, proporcionando maior informacao visual sobre os mesmos.
No entanto, em relacao as informacoes contextuais, o usuario tem acesso a essas apenas
por meio de eventos de notificacoes, que sao enviadas quando ocorrem alteracoes no
artefato. Outra dificuldade diz respeito a geracao das relacoes de dependencias, pois
essas devem ser definidas manualmente pelo desenvolvedor na ferramenta.
3.6 ProjectWatcher
ProjectWatcher (Gutwin et al., 2005) e uma ferramenta que apoia a percepcao sobre as
atividades em projetos de desenvolvimento distribuıdo de software. Para tal, a ferramenta
captura informacoes sobre os artefatos do projeto e as acoes dos desenvolvedores sobre
43
tais artefatos. A ProjectWatcher analisa o codigo fonte capturado a partir de repositorio
do Sistema de Controle de Versao. Assim, a ferramenta monitora e registra as informacoes
sobre edicoes do usuario e fornece a visualizacao de quem esta ativo em um projeto, quais
artefatos estao sendo gerados e em qual parte do projeto tem sido trabalhado. A Figura
3.5 apresenta a interface com o usuario na ProjectWatcher.
Figura 3.5: Interface com o usuario na ProjectWatcher (Gutwin et al., 2005)
Conforme apresentado na Figura 3.5, a ferramenta fornece uma visualizacao das
informacoes por meio de pequenos retangulos que sao agrupados por diretorios. Dentro de
cada retangulo ha pequenas barras verticais que representam a quantidade de alteracoes
realizadas naquele artefato. Os retangulos sao coloridos de acordo com filtros, os quais
indicam, por exemplo, o autor das alteracoes mais recentes. Informacoes adicionais podem
ser obtidas mantendo o cursor sobre um retangulo, tais como o nome da classe e um grafico
de barras mais detalhado.
No entanto, a ProjectWatcher apresenta apenas informacoes sobre o artefato de
software do tipo codigo fonte. Alem disso, apesar da ferramenta acompanhar a evolucao
do artefato de acordo com as alteracoes que sao realizadas e apresentar informacoes sobre
a estrutura do artefato, nao sao geradas relacoes de dependencias entre os artefatos.
44
3.7 EvolTrack
EvolTrack (Cepeda et al., 2010) e uma abordagem que apoia a percepcao sobre a evolucao
do software durante o ciclo de desenvolvimento. A abordagem, com base na visualizacao
de software, apoia a deteccao e a comunicacao de todas as contribuicoes realizadas em um
projeto de software pelos membros das equipes distribuıdas. Assim, o desenvolvedor pode
estar ciente do estado atual do software que esta sendo desenvolvido e, pode, verificar se o
projeto esta evoluindo de acordo com as expectativas da equipe. A Figura 3.6 apresenta
a interface com o usuario na EvolTrack.
Figura 3.6: Interface com o usuario na EvolTrack (Cepeda et al., 2010)
EvolTrack extrai informacoes estruturais sobre os artefatos de software, tais como
classes e pacotes, a partir de Sistemas de Controle de Versao e workspaces de desenvolvi-
mento. As informacoes capturadas sobre os artefatos sao transformadas em representacoes
visuais baseadas em modelos UML. Assim, recursos visuais, tais como escalas de cores, sao
utilizados para visualizar metricas e a evolucao do software sobre o tempo, aumentando
a percepcao sobre o projeto. Alem disso, por meio de um mecanismo de linha do tempo,
o usuario pode visualizar todo o historico de evolucao do projeto, conforme apresentado
na Figura 3.6.
No entanto, a EvolTrack nao apresenta as relacoes de dependencias entre os diversos
artefatos de software, mas apenas as relacoes existentes entre as versoes deles. Alem disso,
45
a abordagem apresenta um conjunto restrito de informacoes contextuais sobre os artefatos
de software, tais como autor, data de criacao e versao do artefato.
3.8 Discussao
Os trabalhos apresentados anteriormente foram selecionados a partir de uma revisao
sistematica, apresentada em Vivian et al. (2011). Tal revisao sistematica identificou
artigos na literatura que abordavam a captura e a apresentacao de informacao contextual
quando artefatos de software sao produzidos e/ou modificados em DDS. Uma revisao
sistematica e um processo de avaliacao e interpretacao de todas as pesquisas disponıveis
relacionadas a uma questao de pesquisa ou assunto de interesse (Kitchenham, 2007).
Conforme descrito em Kitchenham (2007), o protocolo de revisao consiste nas seguintes
etapas: (i) questoes de pesquisa; (ii) estrategia de busca; (iii) criterios e procedimentos
de selecao; (iv) avaliacao da qualidade; e (v) extracao de dados e sıntese. Sendo assim,
com o objetivo de examinar a evidencia do estado de pesquisa em relacao a percepcao
de contexto sobre artefatos de software em DDS, as seguintes questoes de pesquisa foram
consideradas (Vivian et al., 2011):
RQ1: Quais fontes de informacao e recursos visuais tem sido utilizados para imple-
mentar, respectivamente, a captura e a apresentacao de informacao contextual sobre o
desenvolvimento de artefatos de software em DDS?
RQ2: Que tipos de artefatos de software sao abordados pelas pesquisas em relacao a
percepcao de contexto?
RQ3: Quais informacao contextual e propriedades sao importantes para percepcao de
contexto sobre artefatos de software em DDS?
A partir da busca em conferencias, workshops, periodicos e bases de dados eletronicas,
foram selecionados 32 estudos primarios. Steinmacher et al. (2012) apresentam, tambem,
uma revisao sistematica abordando a percepcao no apoio em DDS na qual outros trabalhos
e questoes podem ser identificados.
Diversos aspectos foram identificados nos trabalhos encontrados na literatura. Com
base em Vivian et al. (2011), sobre tais aspectos, pode-se citar:
• Fonte de informacao: os artefatos de software podem ser gerados em diversas
ferramentas e armazenados em diferentes repositorios. SCV, ambientes de desen-
volvimento, sistema de controle de mudancas (bug tracking system) e integracao
46
contınua sao fontes importantes, pois os artefatos de software sao gerados por meio
de tais ferramentas. Dessa forma, os artefatos de software carregam informacoes
contextuais importantes;
• Tipo de artefato: artefatos de software tem uma variedade de formatos, incluindo
codigo fonte, diagrama e documentacao;
• Tipo de informacao: informacao de contexto (e.g. historico de alteracoes,
relacionamentos entre os artefatos e estrutura do artefato), elementos de percepcao
e propriedades dos artefatos de software (e.g. rastreabilidade, filtro e busca de
informacoes) sao importantes para aumentar a percepcao dos membros de equipes
distribuıdas;
• Analise das informacoes: as informacoes contextuais capturadas podem ser
representadas e processadas para detectar padroes ou relacionamentos, ou as in-
formacoes podem ser inferidas para obter novas informacoes;
• Apresentacao das informacoes: recursos visuais (e.g. grafo, cores, linha do
tempo) podem apoiar a apresentacao de informacoes contextuais e aumentar a
percepcao dos indivıduos;
• Local de apresentacao: o mecanismo de percepcao pode ser integrado ao ambiente
de desenvolvimento (e.g. IDE Eclipse1) ou pode ser uma aplicacao independente.
Analisando-se as ferramentas apresentadas anteriormente, pode-se observar algumas
evidencias, tal como o uso de Sistema de Controle de Versao como fonte de informacao.
Tambem, observa-se uma diversidade de formas para a apresentacao das informacoes. A
Tabela 3.1 apresenta uma comparacao entre as ferramentas descritas anteriormente, em
relacao aos aspectos citados acima.
Constata-se que, a fonte de informacao mais comum para a captura de informacoes
sobre os artefatos de software e o Sistema de Controle de Versao. Entretanto, algumas
ferramentas, tais como a Palantır e a EvolTrack, complementam as informacoes do SCV
com informacoes capturadas do ambiente de desenvolvimento do usuario, tal como a IDE
Eclipse. Assim, informacoes mais detalhadas sobre as alteracoes nos artefatos de software
podem ser obtidas. Ja a ADAMS nao realiza a captura automatica de informacoes e,
assim, o desenvolvedor deve inserir manualmente as informacoes sobre os artefatos de
software.
1http://www.eclipse.org/
47
Em relacao ao tipo de artefato, com excecao da ADAMS, todas as outras ferramentas
manipulam apenas codigo fonte. A ADAMS, alem de codigo fonte, trabalha com
diagramas e documentacao. Provavelmente, isso deve-se ao fato de que, conforme
comentado na secao 3.5, na ADAMS as informacoes sobre os artefatos de software nao sao
capturadas automaticamente pela ferramenta. Cabe ao desenvolvedor realizar essa acao
manualmente. Se por um lado, em termos de programacao, e mais simples implementar
uma acao que e realizada manualmente do que quando e realizada automaticamente; por
outro lado, a realizacao manual de uma acao consome um tempo maior quando comparada
a sua execucao automatica.
O aspecto tipo de informacao apresentado pelas ferramentas e diversificado. Os
recursos utilizados sao: estrutura dos artefatos, historico de alteracoes dos artefatos,
impacto das alteracoes, relacoes de dependencias e a relacao socio-tecnica entre os
artefatos.
Em relacao a analise das informacoes capturadas, algumas ferramentas nao realizam
uma analise avancada sobre as informacoes ou qualquer tipo de processamento, tal como
e o caso da ADAMS e da ProjectWatcher. Entretanto, a Palantır verifica eventuais
conflitos sobre os artefatos, a Ariadne realiza a inferencia de redes sociais entre os autores
dos artefatos, a Augur gera relacionamentos entre as atividades e os artefatos, enquanto
a EvolTrack extrai metricas tal como o nıvel de acoplamento entre os artefatos. Porem,
uma analise mais elaborada sobre os artefatos de software poderia ser realizada. Por
exemplo, outras informacoes contextuais poderiam ser inferidas a partir das informacoes
estruturais dos artefatos e, assim, gerar vınculos de rastreabilidade entre os artefatos de
software (Vivian et al., 2011).
O aspecto apresentacao das informacoes nas ferramentas e diversificado. Os recursos
utilizados sao conjunto de janelas, grafo, linhas de codigo coloridas, retangulos coloridos
e diagrama de classes dispostos em uma linha do tempo. Deve-se ressaltar que, a
apresentacao das informacoes nas ferramentas Ariadne e ADAMS ocorre por meio de
um grafo. Esse recurso visual e interessante, pois os desenvolvedores podem identificar
os artefatos de software que sofrem impactos pelas suas alteracoes. Alem disso, os
relacionamentos estabelecidos entre os artefatos de software, e apresentados por meio de
um grafo, podem fornecer a rastreabilidade entre eles e, assim, aumentar a comunicacao e
melhorar a coordenacao entre as equipes distribuıdas (Vivian et al., 2011). Na literatura,
ha uma area muito grande de visualizacao de software (Diehl, 2007) que utiliza recursos
visuais que apoiam a percepcao do indivıduo.
48
Tabela
3.1:Com
paracao
entreas
ferram
entas
Ferramenta
Fonte
de
in-
form
acao
Tipo
de
ar-
tefato
Tipodeinform
acao
Analise
das
in-
form
acoes
Apre
senta
cao
das
inform
acoes
Localdeapre
-senta
cao
Palan
tır
SCV,
ambiente
dedesenvolvi-
mento
Cod
igofonte
Historico
dealteracoes
dos
artefatos,
impacto
das
alteracoes
Relevan
cia,
confli-
tos
Con
junto
de
janelas
emcascatasorden
adas
Aplicacao
inde-
pen
dente
Ariadne
SCV
Cod
igofonte
Relacao
socio-tecn
ica
entreos
artefatos,
au-
toriados
artefatos
Inferencia
sobre
os
autoresdoartefato
Visualizacaocom
base
emgrafo
Ambiente
dede-
senvolvim
ento
Augu
rSCV
Cod
igofonte
Estrutura
dos
artefa-
tos,
atividad
esrelaci-
onad
asao
sartefatos,
autoriadas
alteracoes,
evolucaodos
artefatos
Relacionam
entos
entre
atividad
ese
artefatos
Visualizacaocom
base
emlinhas
de
codigo,
linhas
coloridas,
visoes
com
grafi
cos
estatısticos
Aplicacao
inde-
pen
dente
ADAMS
Inseridas
manualm
ente
pelousuario
Cod
igo
fonte,
diagrama,do-
cumentacao
Relacoes
de
dep
enden
cias
entre
osartefatos,
historico
de
alteracoes
dos
artefatos
Nao
apresenta
Visualizacaocom
base
emgrafo,ıcon
esasso-
ciad
osaos
tiposdear-
tefatos
Aplicacao
inde-
pen
dente
ProjectWatcher
SCV
Cod
igofonte
Historico
dealteracoes
dos
artefatos,
autoria
das
alteracoes
Nao
apresenta
Visualizacaocom
base
emretangulos
colori-
dosagrupados
pordi-
retorios
Ambiente
dede-
senvolvim
ento
eap
licacao
inde-
pen
dente
EvolTrack
SCV,
ambiente
dedesenvolvi-
mento
Cod
igofonte
Estrutura
dos
artefa-
tos,
autoria
das
al-
teracoes
Metricas
Diagrama
de
classes
dispostoem
umalinha
dotempo,
escala
deco-
res
Ambiente
dede-
senvolvim
ento
49
Por fim, em relacao ao local de apresentacao, observa-se que esse aspecto e uniforme
nas ferramentas. Tres ferramentas – Palantır, Augur e ADAMS – utilizam uma aplicacao
independente como local de apresentacao das informacoes sobre os artefatos de software;
enquanto duas ferramentas – Ariadne e EvolTrack – utilizam o proprio ambiente de
desenvolvimento do usuario. Entretanto, a ProjectWatcher e mais flexıvel, pois utiliza
as duas formas – aplicacao independente e ambiente de desenvolvimento – como local de
apresentacao das informacoes.
3.9 Consideracoes Finais
Neste capıtulo foram apresentados os trabalhos que forneceram subsıdios para a ela-
boracao de uma abordagem para percepcao de contexto sobre artefatos de software
no desenvolvimento distribuıdo de software. As ferramentas apresentadas apoiam a
percepcao dos indivıduos sobre as informacoes contextuais dos artefatos de software.
Alem disso, diversos aspectos foram identificados nos trabalhos encontrados na literatura.
Tais aspectos sao: fonte de informacao, tipo de artefato, tipo de informacao, analise das
informacoes, apresentacao das informacoes e local de apresentacao.
Alguns pontos recorrentes sobre as ferramentas apresentadas podem ser destacados,
com o intuito de definir uma nova abordagem. Verifica-se a necessidade de ampliar a area
de percepcao sobre os artefatos de software a partir de informacoes capturadas de mais
de uma fonte de informacao. Alem disso, e importante que outros tipos de artefatos de
software possam contribuir com informacoes contextuais e, assim, tambem, ampliar a area
de percepcao sobre tais objetos de cooperacao (i.e. artefatos de software). Tambem, e
interessante a geracao de relacoes de dependencias, que sao apresentadas por meio de um
grafo, entre os diferentes tipos de artefatos de software, tal como na ADAMS. Entretanto,
a geracao de relacoes de dependencias poderia ser automatica, sem a intervencao do
usuario, para o trabalho consumir menos tempo e, assim, reduzir o esforco durante a
realizacao das atividades.
Com base nos problemas encontrados em DDS a respeito da percepcao de con-
texto sobre artefatos de software e nas observacoes sobre as ferramentas apresentadas
neste capıtulo, incluindo seus pontos positivos e negativos, foi definida a abordagem
DiSEN-CollaborAR, que e apresentada no proximo capıtulo.
50
Capıtulo
4
Abordagem DiSEN-CollaborAR
4.1 Consideracoes Iniciais
Este capıtulo apresenta a DiSEN-CollaborAR, uma abordagem para apoiar a percepcao de
contexto sobre artefatos de software. A abordagem e fundamentada em quatro estruturas,
a saber: Workspace, Repositorio Compartilhado, Mecanismo e Componente Visual. Tal
abordagem foi proposta para proporcionar uma infraestrutura para apoiar a percepcao
dos membros das equipes distribuıdas quando se trata de artefatos de software que sao
produzidos e/ou modificados durante o DDS. Com isso, espera-se reduzir os problemas
de comunicacao e coordenacao e, em consequencia, reduzir o esforco durante a realizacao
das atividades do desenvolvimento de software.
Por meio de tal infraestrutura e possıvel capturar informacoes contextuais a partir
do workspace do indivıduo e, tambem, de repositorios compartilhados. Com base nas
informacoes contextuais capturadas e processadas, sao geradas dependencias entre os
artefatos de software e a visualizacao de informacoes contextuais.
O restante deste capıtulo esta organizado da seguinte forma. Secao 4.2 discute as
caracterısticas da abordagem. Secao 4.3 descreve uma visao geral da abordagem, com-
preendendo o cenario de uso e o modelo conceitual correspondente. Secao 4.4 apresenta
os elementos de percepcao e contexto de artefato. Secao 4.5 discute a representacao
de contexto para artefatos de software. Secao 4.6 detalha a rastreabilidade entre os
artefatos de software. Secao 4.7 descreve a apresentacao da rede de artefatos de software.
Finalmente, na Secao 4.8 sao apresentadas as consideracoes finais.
51
4.2 Caracterısticas da Abordagem
A abordagem proposta possui algumas caracterısticas relacionadas aos artefatos de soft-
ware que influenciaram a sua definicao e o seu desenvolvimento. Essas caracterısticas
dizem respeito aos tipos de artefatos de software e a especificidade das ferramentas
utilizadas para a manipulacao dos mesmos.
Artefatos tomam uma variedade de formas incluindo modelos, documentos, codigo
fonte, casos de teste e executaveis (Cleland-Huang et al., 2003). Para o escopo da
abordagem proposta, diagrama de classes e codigo fonte foram definidos como os tipos de
artefatos de software que podem ser produzidos e/ou modificados durante o ciclo de vida
de um projeto de software. O diagrama de classes e o mais utilizado e e um dos mais
importantes diagramas da UML, definindo a estrutura das classes utilizadas pelo sistema,
determinando os atributos e operacoes que cada classe tem, alem de estabelecer como
as classes se relacionam e trocam informacoes entre si (Guedes, 2009). O codigo fonte e
escrito em uma determinada linguagem de programacao, sendo um artefato resultante do
processo de programacao de software, que e posteriormente compilado. Dessa forma, uma
abordagem com base em diagrama de classes e codigo fonte e interessante, pois durante
um processo de software, com base em projeto e programacao orientado a objetos, as
atividades de implementacao e, tambem, manutencao sao realizadas de acordo com a
estrutura definida nos proprios diagramas de classes.
As equipes de desenvolvimento de software realizam suas atividades por meio de
ferramentas que auxiliam durante o processo de software. Por exemplo, atividades
relacionadas a producao e modificacao de codigo fonte e diagrama de classes. Quando se
trata de DDS, esses artefatos de software, apos serem manipulados, sao armazenados em
repositorios compartilhados aos quais as equipes distribuıdas tem acesso.
Quando um membro de uma equipe distribuıda trabalha sobre um artefato de software
que e compartilhado, as informacoes contextuais sobre o mesmo devem ser capturadas, re-
presentadas, processadas e apresentadas aos demais membros. Na pratica, as ferramentas
que um indivıduo utiliza para manipular um artefato de software, tais como Sistema de
Controle de Versao e Ferramenta CASE UML, nao possuem a capacidade de identificar e
apresentar todas as informacoes contextuais sobre os artefatos de software e distribuı-las
aos demais indivıduos. Alem disso, essas ferramentas, por si so, nao oferecem apoio para
associar os diferentes tipos de artefatos de software.
De um modo geral, as equipes de desenvolvimento costumam utilizar ferramentas com
as quais ja estao familiarizadas. No entanto, quando se trata de DDS, e interessante que
os indivıduos possam obter, tambem, apoio a percepcao de contexto sobre os artefatos de
52
software que sao produzidos e/ou modificados. A abordagem para apoiar a percepcao de
contexto sobre artefatos de software, apresentada nesta dissertacao, integra ferramentas
tais como Sistema de Controle de Versao distribuıdo (e.g. Bazaar1, Git2 e Mercurial3) e
Ferramenta CASE UML (e.g. ArgoUML4, Astah5, Umbrello6 e StarUML7).
Para a definicao da abordagem proposta, foram consideradas as caracterısticas rela-
cionadas aos tipos de artefatos de software, a especificidade das ferramentas e, tambem,
os principais trabalhos encontrados na literatura, apresentados no Capıtulo 3. Com
isso, a abordagem possui caracterısticas interessantes que a potencializam para apoiar
os desenvolvedores na percepcao de contexto. Sao elas: (i) representacao semantica das
informacoes contextuais sobre os artefatos de software por meio de uma ontologia; (ii)
geracao automatica das relacoes de dependencias entre os artefatos de software com base
em uma ontologia, de acordo com a informacao estrutural e semantica encontradas nos
proprios artefatos; (iii) associacao de vınculos de rastreabilidade entre tipos diferentes
de artefatos de software – codigo fonte e diagrama de classes; e (iv) apresentacao de
informacoes contextuais sobre os artefatos de software na forma textual e por meio de
grafos que permitem a percepcao visual.
4.3 Visao Geral da Abordagem
A reducao da comunicacao acerca dos artefatos de software que sao produzidos ou
modificados em diferentes situacoes motiva o desenvolvimento de uma infraestrutura que
ofereca recursos para apoiar a disseminacao de informacoes. Os indivıduos devem perceber
as informacoes contextuais (e.g. quem realizou determinada alteracao no artefato, onde,
como e quando as acoes aconteceram) sobre os artefatos de software que sao produzidos
e/ou modificados em um projeto de software com equipes distribuıdas. Para tal, na
abordagem proposta, as informacoes contextuais capturadas de artefatos de software sao
representadas, armazenadas, processadas e apresentadas aos indivıduos.
Nesta secao e apresentada uma abordagem para apoiar a percepcao de contexto sobre
artefatos de software chamada DiSEN-CollaborAR (DiSEN-Collaborative Awareness for
aRtifacts). Essa abordagem faz parte do projeto DiSEN, um ambiente de desenvolvi-
1http://bazaar.canonical.com/2http://git-scm.com/3http://mercurial.selenic.com/4http://argouml.tigris.org/5http://astah.net/6http://uml.sourceforge.net/7http://staruml.sourceforge.net/
53
mento distribuıdo de software, cujo objetivo e fornecer uma infraestrutura para apoiar o
desenvolvimento de software com equipes geograficamente dispersas (Huzita et al., 2007).
4.3.1 Cenario de Uso
A abordagem DiSEN-CollaborAR foi concebida para facilitar a percepcao de contexto
sobre os artefatos de software durante a sua producao e/ou modificacao por equipes
distribuıdas. Dessa forma, a abordagem apresentada nesta dissertacao, oferece apoio
a compreensao e o conhecimento, pelos indivıduos, das circunstancias envolvidas em
determinada situacao. Essa situacao envolve o objeto de trabalho compartilhado, tal
como os artefatos de software, discutidos na Secao 4.2. Aqui e apresentado um exemplo
de cenario com nomes fictıcios de desenvolvedores.
Suponha um caso hipotetico em que Joao e designado para corrigir um bug em
relacao a nota fiscal de entrada de produtos quando ha devolucao. Ele lembra que Maria
tinha trabalhado em um recurso relacionado a nota fiscal de saıda de produtos. Assim,
ele decide investigar esse recurso para obter uma melhor compreensao dos artefatos de
software e das pessoas que estavam envolvidas. Por meio da DiSEN-CollaborAR, Joao
encontra um artefato de software relacionado ao recurso que Maria tinha adicionado.
O artefato gerado por Maria esta associado a outros cinco artefatos de software e,
consequentemente, a outros dois desenvolvedores. Joao percebe que a sua correcao de
bug envolveria, pelo menos, esses cinco artefatos de software. Alem disso, ele percebe
que outro desenvolvedor – Paulo, que faz parte de outra equipe de desenvolvimento –
trabalhou em quatro desses artefatos de software. Por causa do artefato de software
em comum entre Maria e Paulo, Joao percebe que esses dois desenvolvedores podem ter
interagido para a realizacao do trabalho colaborativo. Para assegurar uma visao completa
das atividades de desenvolvimento sobre o recurso, Joao decide entrar em contato com
Paulo.
Para a abordagem DiSEN-CollaborAR apoiar o desenvolvimento de software pelas
equipes distribuıdas, cujos membros interagem sobre artefatos de software compartilhados
e estao dispersos temporal e geograficamente, deve-se considerar as seguintes etapas:
coleta, tratamento e consumo de informacoes contextuais. A Figura 4.1 apresenta um
cenario do fluxo de informacoes da DiSEN-CollaborAR.
54
Figura 4.1: Cenario do fluxo de informacoes da DiSEN-CollaborAR
Na etapa de coleta (A) ocorrem as seguintes atividades: (1) em seu workspace os
membros das equipes distribuıdas realizam suas tarefas sobre um artefato de software;
(2) o artefato de software e persistido em um repositorio compartilhado. O tratamento
(B) ocorre da seguinte forma: (3) as informacoes relacionadas aos artefatos de software,
armazenados no repositorio compartilhado, sao capturadas pelo mecanismo; (4) apos
as informacoes serem processadas pelo mecanismo, as mesmas estao disponıveis para
a apresentacao. Por fim, o consumo (C) segue da seguinte forma: (5) o componente
visual apresenta as informacoes contextuais sobre os artefatos de software aos membros
das equipes distribuıdas.
4.3.2 Modelo Conceitual da DiSEN-CollaborAR
Para a percepcao de contexto sobre os artefatos de software pelas equipes distribuıdas, a
DiSEN-CollaborAR apresenta uma infraestrutura para que o indivıduo possa visualizar
as contribuicoes dos demais desenvolvedores em relacao as informacoes e as dependencias
entre os artefatos de software. Com a abordagem pode-se gerenciar as informacoes
contextuais sobre a producao e a modificacao de artefatos de software, como aquelas
descritas na Secao 4.4, e permitir que essas informacoes fluam entre as equipes distribuıdas.
Conforme apresenta a Figura 4.2, a abordagem DiSEN-CollaborAR pode ser analisada
sobre quatro estruturas, as quais sao descritas a seguir.
55
Figura 4.2: Modelo conceitual da DiSEN-CollaborAR
Workspace: essa estrutura representa o espaco de trabalho do indivıduo que faz parte
de uma equipe distribuıda, constituıda por Sistema de Controle de Versao e Ferramenta
CASE UML. O Sistema de Controle de Versao facilita a colaboracao dos desenvolvedores
em um projeto por meio da coordenacao do desenvolvimento de recursos e a mesclagem
das linhas do codigo fonte (de Alwis e Sillito, 2009). A Ferramenta CASE UML apoia
a construcao, a manipulacao e a apresentacao de modelos, tais como diagramas UML
(Lahtinen e Peltonen, 2005). Dessa forma, os membros das equipes distribuıdas realizam
acoes sobre os artefatos de software, produzindo ou modificando codigo fonte e diagrama
de classes, os quais devem ser compartilhados com os demais indivıduos da equipe. Assim,
Sistema de Controle de Versao e Ferramenta CASE UML sao fontes importantes, pois os
artefatos de software sao gerados por meio de tais ferramentas e carregam informacoes
contextuais importantes.
Repositorio Compartilhado: essa estrutura inclui os repositorios compartilhados de
artefatos de software, tais como Repositorio de Codigo e Repositorio de Modelo. No
Repositorio de Codigo e persistido o codigo fonte enviado pelo indivıduo por meio do
56
Sistema de Controle de Versao. No Repositorio de Modelo sao armazenados os diagramas
de classes que sao manipulados pelo indivıduo por meio da Ferramenta CASE UML e que
devem ser exportados no formato XMI (XMLMetadata Interchange) para esse repositorio.
Assim, essa estrutura armazena todos os artefatos de software relacionados a codigo fonte
e diagrama de classes gerados durante o ciclo de vida de um projeto. Alem disso, essa
estrutura apresenta o Repositorio de Contexto que e responsavel pelo armazenamento de
informacoes contextuais.
Mecanismo: essa estrutura abrange os elementos do modelo DiSEN-CSE (DiSEN-Context
Sensitive Environment) proposto por Chaves et al. (2010). Esse modelo visa integrar os
elementos essenciais a percepcao de contexto a fim de permitir o compartilhamento de in-
formacoes contextuais entre os diversos workspaces envolvidos no trabalho colaborativo. O
modelo DiSEN-CSE apresenta os seguintes elementos: Suporte a Captura, Representacao
do Contexto, Suporte ao Processamento e Mecanismo de Percepcao (Chaves et al., 2010).
Dessa forma, considerando uma abordagem sobre artefatos de software, essa estrutura
inclui:
• Suporte a Captura: e responsavel por reconhecer as alteracoes que ocorrem no
contexto do artefato e capturar as informacoes referentes ao seu contexto atual por
meio de eventos no Repositorio Compartilhado. Durante o ciclo de vida do projeto, as
informacoes relacionadas a producao e modificacao de artefatos de software – codigo
fonte e diagrama de classes, realizadas pelos membros das equipes distribuıdas, sao
capturadas do Repositorio de Codigo e Repositorio de Modelo;
• Representacao do Contexto: e responsavel por receber as informacoes contextuais
capturadas sobre os artefatos de software, representa-las em um modelo formal
baseado em uma ontologia – OntoDiSENv1 (Chaves et al., 2011), e relaciona-las
com as demais informacoes contextuais disponıveis no Repositorio de Contexto. A
representacao de contexto para artefatos de software e discutida na Secao 4.5;
• Suporte ao Processamento: e responsavel por inferir as informacoes contextuais
implıcitas nas informacoes capturadas sobre os artefatos de software com base nos
relacionamentos existentes entre os conjuntos de informacoes criados pela Repre-
sentacao do Contexto. O processamento das informacoes contextuais e efetuado por
meio do mecanismo proposto por Monte-Alto et al. (2012);
57
• Rastreamento: e responsavel por gerar relacoes de dependencias entre os artefatos
de software, resultando em vınculos de rastreabilidade entre eles. A rastreabilidade
entre artefatos de software e discutida na Secao 4.6;
• Mecanismo de Percepcao: e responsavel por disseminar as informacoes contextuais
sobre os artefatos de software para as diversas instancias do workspace, por meio do
metodo de exibicao definido na estrutura Componente Visual.
Componente Visual : essa estrutura representa o componente visual de percepcao
que apoia a apresentacao de informacoes contextuais para a percepcao no workspace
do indivıduo. Essa apresentacao inclui uma rede de artefatos de software com suas
informacoes contextuais e as relacoes de dependencias entre os artefatos de software em
um grafo. A apresentacao da rede de artefatos de software e discutida na Secao 4.7.
Assim, a partir das estruturas descritas anteriormente, a abordagem
DiSEN-CollaborAR apresenta as seguintes etapas de execucao, conforme apresentado na
Figura 4.2. (1) O codigo fonte e armazenado no Repositorio de Codigo e o diagrama
de classes e exportado no formato XMI e armazenado no Repositorio de Modelo. (2)
As alteracoes que ocorrem sobre os artefatos de software que estao nos repositorios sao
capturadas pelo Suporte a Captura. (3) As informacoes contextuais capturadas sao
mapeadas pela Representacao do Contexto para um modelo de representacao formal
baseado em ontologia. (4a) As informacoes contextuais representadas devem ser armaze-
nadas no Repositorio de Contexto, formando um historico de informacoes de contexto.
Alem disso, (4b) as informacoes contextuais podem ser enviadas para o Suporte ao
Processamento inferir contextos implıcitos. (5a) O Suporte ao Processamento pode enviar
as informacoes processadas para o Repositorio de Contexto ou recuperar as informacoes
que estao armazenadas no mesmo. (5b) As informacoes contextuais sao enviadas para
o Rastreamento gerar as relacoes de dependencias entre os artefatos de software. (6)
As informacoes contextuais sobre os artefatos de software sao disponibilizadas para o
Mecanismo de Percepcao. (7) As informacoes contextuais sobre os artefatos de software
sao apresentadas por meio de um grafo. Por fim, (8a e 8b) os membros das equipes
distribuıdas percebem as informacoes contextuais e as relacoes de dependencias entre os
artefatos de software.
Logo, a DiSEN-CollaborAR oferece uma infraestrutura para que os membros de
equipes de projeto de software, que estao distribuıdas geograficamente, possam perceber as
contribuicoes dos demais desenvolvedores sobre as informacoes contextuais relacionadas
a codigo fonte e diagrama de classes. Para tal, a infraestrutura oferece recursos para
58
a apresentacao visual de informacoes contextuais e a geracao de dependencias entre os
artefatos de software. As secoes seguintes (4.4 a 4.7) detalham caracterısticas incorporadas
pelos elementos Mecanismo e Componente Visual, constantes na Figura 4.2. Esse
detalhamento constitui-se em pilares que sustentam as caracterısticas da abordagem
DiSEN-CollaborAR.
4.4 Elementos de Percepcao e Contexto de Artefato
Percepcao de contexto inclui questoes tais como o contexto do workspace do artefato, sua
mudanca de estado ao longo do tempo, inclusive de outros artefatos associados a eles e
os colaboradores que trabalham sobre eles (Omoronyia et al., 2010). Assim, elementos de
percepcao e contexto de artefato sao importantes para fornecer a percepcao de contexto
sobre artefatos de software quando o desenvolvimento de software com equipes distribuıdas
e considerado.
Os elementos de percepcao de workspace identificados por Gutwin e Greenberg (2002)
foram estendidos na abordagem DiSEN-CollaborAR para apoiar a percepcao focada nas
acoes sobre os artefatos de software. Elementos de percepcao sao informacoes que os
indivıduos precisam para monitorar, aprender e entender as alteracoes que ocorrem sobre
os artefatos de software ao longo do tempo em um projeto de DDS. Conforme apresenta
a Tabela 4.1, para cada Categoria (quem, o que, onde, como e quando) ha um conjunto
de Elementos que fornecem Questoes especıficas sobre os artefatos de software. Esses
elementos carregam informacoes sobre os eventos que ocorrem sobre os artefatos de
software durante o desenvolvimento de software.
Os elementos de percepcao incluem questoes relacionadas ao presente e passado das
acoes sobre os artefatos de software. Com base nos elementos informativos, os indivıduos
podem ter um entendimento sobre as alteracoes realizadas sobre os artefatos de software.
Assim, as informacoes resultantes podem contribuir para aumentar o nıvel de percepcao
sobre os mesmos e, consequentemente, a colaboracao entre os membros das equipes
distribuıdas.
Artefato de software pode ser definido como “um pedaco de informacao produzida
ou modificada como parte do processo de engenharia de software” (Xu et al., 2010).
Na abordagem DiSEN-CollaborAR, contexto de artefato e um conjunto de informacoes,
consistindo de varios elementos contextuais que caracterizam o artefato e que apoiam
o indivıduo para a execucao de suas tarefas. O contexto de artefato e gerado a partir
das acoes que o indivıduo realiza sobre o artefato de software e das relacoes estruturais
59
do mesmo. Alem disso, as relacoes de dependencias que o artefato de software tem com
outros artefatos tambem sao importantes para a definicao do contexto de artefato.
Tabela 4.1: Elementos de percepcao focados em artefatos de software (adaptado deGutwin e Greenberg (2002))
Categoria Elemento Questao especıfica com base em artefatos de soft-ware
QuemPresenca Quem acessou este artefato?Identidade Quem e o participante que gerou ou atualizou este artefato?Autor Quem gerou ou atualizou este artefato?
O queAcao Que alteracoes foram realizadas sobre o artefato?Intencao Qual era o objetivo das alteracoes realizadas sobre o
artefato?Artefato Qual artefato foi alterado?
Onde Localizacao Onde esta o artefato?
ComoHistoricode acao
Como as acoes aconteceram sobre o artefato?
Historicodo artefato
Como o artefato foi alterado?
Quando Historicode evento
Quando o artefato foi alterado?
Conforme definido na Secao 2.4 do Capıtulo 2, contexto e formado por um conjunto
de elementos contextuais que caracterizam uma entidade. Assim, a Tabela 4.2 apresenta
o contexto de artefato, formado pelos seus Elementos Contextuais e sua respectiva
Descricao. O contexto de artefato foi classificado de acordo com os elementos de percepcao
apresentados na Tabela 4.1.
O contexto de artefato esta diretamente relacionado ao contexto do projeto de software.
Assim, a construcao do contexto de artefato recebe influencias de informacoes externas,
tais como equipe, projeto e tarefa. Quando pessoas trabalham colaborativamente como
equipe, o conhecimento sobre os elementos contextuais relacionados as interacoes e
muito relevante para alcancar um nıvel elevado de colaboracao (Rosa et al., 2003). O
conhecimento sobre as acoes realizadas sobre o artefato de software e suas caracterısticas
sao importantes para a compreensao do projeto e das tarefas que devem ser realizadas.
Dessa forma, o contexto de artefato tambem pode aumentar a colaboracao entre os
membros de equipes de projeto de software que estao distribuıdas geograficamente.
60
Tabela 4.2: Distribuicao dos elementos contextuais por elementos de percepcao
Elemento de Per-cepcao
ElementoContextual
Descricao
Presenca
IdentidadeEquipe Equipe que o participante faz parteLocalizacao Local fısico onde a equipe estaPapel Funcao que o participante desempenha na
tarefaAutor Participante Usuario que manipulou o artefatoAcao Mudanca Alteracao que foi realizada sobre a versao do
artefatoIntencao Tarefa Atividade do projeto que gerou o artefato
Artefato
Arquivo Arquivo contendo o artefato gerado pelo sis-tema
Artefato Resultado de uma tarefaDependencia Relacao de dependencia com outro artefatoFerramenta Ferramenta utilizada para a geracao do arte-
fatoTipo de arte-fato
Indica a categoria do artefato
Versao Versao do arquivo que corresponde ao arte-fato
LocalizacaoWorkspace Espaco de trabalho que contem uma copia do
artefatoHost Repositorio do artefato
Historico de acaoAtividade doprocesso
Atividade que compoe uma fase de um pro-cesso
Atividade doprojeto
Atividade que compoe uma fase de um pro-jeto
Estado da ta-refa
Define a situacao da tarefa naquele momento
Historico do artefatoEstado daversao
Define a situacao da versao naquele momento
Estado do ar-tefato
Define a situacao do artefato naquele mo-mento
Historico de evento Data Data que o artefato foi produzido ou modifi-cado
Sobre tais elementos de percepcao e elementos contextuais, foram implementados
apenas Identidade (equipe, localizacao), Autor (participante), Artefato (arquivo, de-
pendencia, ferramenta, tipo de artefato, versao) e Historico de evento (data).
61
4.5 Representacao de Contexto para Artefatos
Um aspecto fundamental na abordagem DiSEN-CollaborAR e que as informacoes con-
textuais sobre os artefatos de software, depois de capturadas, sua semantica deve ser
representada. De acordo com Chaves et al. (2011), a representacao de contexto pode
ser baseada em ontologia, pois essa apresenta expressividade, formalismo, capacidade de
inferencia e existem ferramentas de apoio disponıveis.
Conforme apresentado no Capıtulo 2, Chaves et al. (2011) definiram uma ontologia
para o domınio do desenvolvimento distribuıdo de software, especificamente voltada para
o ambiente DiSEN (Huzita et al., 2007). Entretanto, a OntoDiSENv1 nao contemplava,
ate entao, todas as classes e propriedades no domınio de contexto focado em artefatos
de software. Sendo assim, com base nos elementos de percepcao e contexto de artefato
– Secao 4.4, a OntoDiSENv1 foi estendida para o foco em artefatos de software e um
conjunto de conceitos e seus relacionamentos foram definidos, resultando em um mapa
conceitual que foi elaborado, conforme consta na Figura 4.3. Os conceitos destacados, na
Figura 4.3, foram adicionados aquele definido por Chaves et al. (2011). O mapa conceitual
foi construıdo com a ferramenta CmapTools v5.04.028.
Figura 4.3: Mapa conceitual – conceitos e relacionamentos focados em artefatos desoftware
8http://cmap.ihmc.us/
62
Conforme apresentado na Figura 4.3, esse mapa conceitual apresenta os principais
conceitos e relacionamentos da OntoDiSENv1 focados em artefatos de software. Para
o conceito TipoArtefato ha dois conceitos – Diagrama e CodigoFonte – que foram
expandidos, conforme apresentam as Figuras 4.4 e 4.5.
Figura 4.4: Mapa conceitual – conceitos e relacionamentos sobre o tipo de artefatodiagrama
Em seguida, a ontologia foi formalizada utilizando a linguagem OWL-DL e a fer-
ramenta Protege. Os conceitos e relacionamentos foram transcritos como classes e
propriedades, conforme representadas nas Figuras 4.6 e 4.7, respectivamente. As classes
e propriedades da ontologia foram definidas com a ferramenta Protege 3.4.89.
9http://protege.stanford.edu
63
Figura
4.5:Map
aconceitual
–conceitos
erelacion
amentossobre
otipodeartefato
codigofonte
64
Algumas classes possuem atributos. Em OWL, as propriedades sao divididas em
propriedades de objetos (relacionamentos) e propriedades de dados (atributos). Nas
propriedades de objetos, estabelece-se uma relacao entre duas classes, sendo uma imagem
(entidade que possui a propriedade) e um domınio (faixa de valores possıveis para a
propriedade). Nas propriedades de dados, o domınio nao e uma classe, mas um tipo de
dado, como string, char, integer, date, float, entre outros.
Figura 4.6: Classes da OntoDiSENv1 focadas em artefatos de software
A seguir, sao apresentadas as classes, seus atributos (propriedades de dados) e seus
relacionamentos (propriedades de objetos) na qual cada classe e domınio:
Artifact: resultado de uma tarefa, que pode ser usado como materia-prima para outras
tarefas. Possui como atributos as propriedades de dados name e description. E especia-
lizado em Diagram e SourceCode. E domınio das propriedades accessedByUser para indi-
car que um artefato pode ser visualizado pelos participantes do projeto, availableAtLocal
indicando que o artefato precisa estar disponıvel para acesso em algum repositorio,
65
hasFile indicando quais arquivos formam aquele artefato, isOfArtifactType que re-
presenta o grupo de artefatos ao qual pertence, isInWorkSpace para indicar em quais
workspaces o artefato foi baixado, generatedInTool para saber qual ferramenta foi usada
para gerar o artefato, belongsToTask para indicar a tarefa a qual pertence, madeBy
indicando qual participante e responsavel pelo artefato, dependsOnArtifact indicando
qual artefato depende do artefato e, por fim, hasArtifactStatus para indicar que possui
um estado. O estado de um artefato e definido pela entidade ArtifactStatus.
Figura 4.7: Propriedades de objetos da OntoDiSENv1 focadas em artefatos de software
Diagram: e especializacao de Artifact, consiste nos diagramas que podem ser produ-
zidos durante o desenvolvimento de software. E especializado em BehaviourDiagram,
InteractionDiagram e StructureDiagram. BehaviourDiagram e especializado em
ActivityDiagram, StateDiagram e UseCaseDiagram. InteractionDiagram e especiali-
zado em CommunicationDiagram, InteractivityDiagram, SequenceDiagram e
TimingDiagram. StructureDiagram e especializado em ClassDiagram,
ComponentDiagram, CompositeStructureDiagram, DeploymentDiagram,
ObjectDiagram e PackageDiagram. E domınio da propriedade isArtifactTypeOf para
indicar que e um tipo de artefato.
ClassDiagram: e especializacao de StructureDiagram, consiste nos diagramas de classes
que podem ser produzidos durante o desenvolvimento de software. E especializado em
66
Attribute, Operation e UmlClass. E domınio das propriedades hasAttribute para
indicar os atributos que pertencem ao diagrama de classes, hasOperation para indicar as
operacoes que pertencem ao diagrama de classes e, por fim, hasUmlClass para indicar o
nome da classe que pertence ao diagrama de classes.
SourceCode: e especializacao de Artifact, consiste nos codigos fontes que podem ser
produzidos durante o desenvolvimento de software. E especializado em Class, Method
e Variable. E domınio das propriedades hasClass para indicar o nome da classe que
pertence ao codigo fonte, hasMethod para indicar os metodos que pertencem ao codigo
fonte e, por fim, hasVariable para indicar as variaveis que pertencem ao codigo fonte.
File: arquivos contendo os artefatos gerados pelo sistema. Possui como atributos as pro-
priedades de dados name e description. E domınio das propriedades belongsToArtifact
indicando que cada arquivo corresponde a um determinado artefato, hasFileStatus
indicando que possui um estado e, por fim, hasVersion, indicando que todo arquivo
pode possuir n versoes. O estado do arquivo e definido pela entidade FileStatus.
Local: sao maquinas ou equipamentos de hardware que oferecem servicos ao ambiente, por
exemplo, para funcionar como repositorio de dados ou artefatos. Possui como atributo a
propriedade de dados description. E domınio das propriedades hasArtifact indicando
que um local pode constituir um repositorio de artefatos.
Participant: sao usuarios que fazem parte de um projeto. Possui como atributo a
propriedade de dados manager. E domınio das propriedades performsTask indicando
que possui uma tarefa sob sua responsabilidade, producesArtifact para indicar que
um participante pode gerar um artefato quando realiza uma tarefa, hasArtifactAccess
indicando que um participante pode acessar um conjunto de artefatos relacionados ao seu
projeto ou a sua tarefa, generatesVersion para indicar que o participante e responsavel
por uma determinada versao de artefato, playsRole indicando que um participante pode
possuir um ou mais papeis especıficos dentro de um projeto e, por fim, isMemberOf
indicando que um participante e membro de uma equipe.
Place: lugar fısico (geografico) em que algum recurso pode estar. E domınio das
propriedades hasUser indicando que um local pode possuir diversos usuarios.
67
ProcessActivity: atividade que compoe uma fase de um processo. Possui como
atributos as propriedades de dados name e description. E domınio da propriedade
hasArtifactType para indicar que uma atividade do processo deve produzir um tipo
artefato.
ProjectActivity: atividade que compoe uma fase de um projeto, geralmente baseada em
uma atividade definida em um processo. Possui como atributos as propriedades de dados
name, description, estimatedStartDate, startDate, endDate e estimatedEndDate.
E domınio da propriedade hasArtifactType para indicar que uma atividade do projeto
deve produzir um tipo artefato.
Role: papel que o participante desempenha em um determinado projeto. Possui como
atributos as propriedades de dados name e description.
Task: subdivisao das atividades do projeto (uma atividade do projeto e composta por
um conjunto de tarefas), em que cada tarefa e uma unidade atomica, que gera um
artefato especıfico. Possui como atributos as propriedades de dados name, description,
startDate, estimatedStartDate, endDate e estimatedEndDate. E domınio das pro-
priedades dependsOnTask indicando que uma tarefa pode depender de outra tarefa para
a sua realizacao, usesArtifact para indicar que uma tarefa pode utilizar artefatos de
outras tarefas para sua realizacao, performedByParticipant para indicar que uma tarefa
possui participantes responsaveis pela sua execucao, hasArtifact para indicar que uma
tarefa deve produzir um artefato e, por fim, hasTaskStatus para indicar que as tarefas
possuem estados. A entidade TaskStatus e quem define o estado da tarefa.
Team: equipe da qual o participante faz parte. Possui como atributos as propriedades de
dados name e description.
Tool: consiste nas ferramentas de software que podem ser instaladas no ambiente e
utilizadas para a geracao dos artefatos. Possui como atributos as propriedades de dados
concept, updateDate, supplier, name, platform, size e toolVersion. E domınio das
propriedades generateArtifact para indicar que um determinado artefato de software e
gerado por uma determinada ferramenta e, por fim, generatesArtifactOfType indicando
que tipo de artefato de software uma ferramenta pode gerar.
68
Version: versao dos arquivos que correspondem a um artefato, gerado em uma tarefa.
Possui como atributo a propriedade de dados description e updateDate. E domınio das
propriedades generatedByParticipant para indicar que a versao foi produzida por um
participante responsavel, hasVersionStatus indicando que as versoes possuem estados
e, por fim, hasChange indicando que a versao possui alteracao. O estado da versao e
definido pela entidade VersionStatus. A alteracao realizada na correspondente versao
do artefato e definida pela entidade Change.
Workspace: espaco de trabalho que contem os artefatos, as ferramentas e as informacoes
que os usuarios utilizam para realizar o seu trabalho. E domınio das propriedades
accessWorkspace indicando que um workspace e acessado por um usuario e, por fim,
hasArtifact para indicar que um workspace pode possuir copias dos artefatos, funcio-
nando como um repositorio local, para que os usuarios possam modificar os artefatos.
Depois de criadas as classes e propriedades de dados e objetos, cada classe foi
formalmente definida, utilizando logica descritiva (Baader et al., 2007) para inserir regras
de inferencia. Como exemplo, definiu-se que um diagrama de classes dentro de um arquivo
pode ser considerado como todos os artefatos de software que descrevem ou contem
informacoes relacionadas a classe de ontologia ClassDiagram. A classe ClassDiagram
pode ser usada para recuperar todos os artefatos de software que se relacionam a tal
diagrama de classes. Um exemplo dessa definicao, em logica descritiva, e apresentado a
seguir.
ClassDiagram ≡ (File u Artifact) u ∃isAnArtifactType.ClassDiagram
Analogamente, a classe de ontologia SourceCode pode ser definida para recuperar
todos os artefatos de software que descrevem ou contem informacoes relacionadas ao
codigo fonte. Um exemplo dessa definicao, em logica descritiva, e apresentado a seguir.
SourceCode ≡ (File u Artifact) u ∃isAnArtifactType.SourceCode
Dessa forma, o raciocinador da ontologia pode classificar os artefatos de software de
acordo com essas definicoes em logica descritiva. As regras de inferencia para a geracao
de vınculos de rastreabilidade entre os artefatos de software sao apresentadas na Secao
4.6.
A ontologia para artefatos de software permite uma representacao comum para
reduzir a lacuna conceitual causada pelo tipo de abstracao e formato encontrados em
69
diferentes tipos de artefatos de software. Esse conhecimento “modelado” e usado para
apoiar a percepcao de contexto sobre artefatos de software. Deve-se destacar que, a
ontologia, apresentada nesta secao, nao foi utilizada totalmente na implementacao do
prototipo, apresentado no Capıtulo 5. Alem disso, as classes de ontologia ClassDiagram
e SourceCode nao foram definidas de acordo com todos os conceitos apresentados nas
Figuras 4.4 e 4.5, respectivamente. Isso esta alem do escopo deste trabalho e, assim, tal
implementacao fara parte de um trabalho futuro.
4.6 Rastreabilidade entre Artefatos de Software
Conforme apresentado na Secao 4.4, dependencia e um elemento contextual que faz parte
do contexto de artefato. Para gerar relacoes de dependencias entre os artefatos de software,
e necessario criar vınculos de rastreabilidade entre os mesmos. Vınculos de rastreabilidade
fornecem apoio para os engenheiros de software compreenderem as relacoes e dependencias
entre os artefatos de software criados durante o processo de desenvolvimento de software
(Zhang et al., 2008). Assim, quando dois indivıduos estiverem trabalhando sobre duas
classes distintas, unidas por algum tipo de relacionamento, por exemplo, ha a possibilidade
das atividades desses indivıduos estarem, tambem, relacionadas, pois seus artefatos de
software estao.
Na DiSEN-CollaborAR adotou-se uma abordagem ontologica baseada sobre a recu-
peracao semantica (Zhang et al., 2008) para a definicao de vınculos de rastreabilidade
entre os artefatos de software. Assim, as relacoes entre os diversos artefatos de software
sao recuperadas utilizando a informacao estrutural e semantica encontradas nos proprios
artefatos.
A representacao de artefatos de software em uma ontologia formal permite tirar
proveito de raciocinadores de ontologia para inferir relacoes implıcitas entre os artefatos
de software, tais como codigo fonte e diagrama de classes. Por exemplo, para gerar
relacoes de dependencias entre os artefatos de software, sao estabelecidos vınculos entre
instancias individuais sobre o codigo fonte (e.g. uma classe, uma variavel ou um metodo)
e a referencia correspondente dessas instancias em um diagrama de classes (e.g. nome,
atributo ou operacao).
A Figura 4.8 ilustra a forma como os vınculos de rastreabilidade sao estabelecidos.
A parte superior mostra as classes da ontologia nos domınios diagrama de classes e
codigo fonte. Instancias dessas classes da ontologia sao mostradas na parte inferior.
Elas sao detectadas a partir das informacoes contextuais capturadas sobre os artefatos
de software. Alguns conceitos, tais como classe, variavel/atributo ou metodo/operacao,
70
sao compartilhados entre codigo fonte e diagrama de classes. Assim, os vınculos de
rastreabilidade sao gerados por meio da ontologia, com base nas classes da ontologia
e nas informacoes de instancias.
Figura 4.8: Vinculando instancias a partir das classes da ontologia nos domıniosdiagrama de classes e codigo fonte
Por exemplo, conforme apresentado na Figura 4.8, uma analise sobre um codigo fonte
e um diagrama de classes pode identificar uma instancia c1 em ambos os artefatos
de software. Isso sugere que pode ser estabelecido um vınculo, representando uma
dependencia entre tais artefatos de software.
Com base na ontologia para artefatos de software, apresentada na Secao 4.5, foram
definidas algumas regras de inferencia para a geracao de vınculos de rastreabilidade entre
os artefatos de software. Um exemplo dessa definicao, em logica descritiva, e apresentado
a seguir.
Dependencia ≡ ((File u isOfType.ClassDiagram)
t (File u isOfType.SourceCode))
u ((ClassDiagram u hasName.ClassName) u (SourceCode uhasClass.ClassName))
Dessa forma, o raciocinador da ontologia pode gerar as relacoes de dependencias entre
os artefatos de software de acordo com tal definicao em logica descritiva.
71
4.7 Apresentacao da Rede de Artefatos de Software
Os recursos visuais desempenham um papel importante, pois e fundamental apresentar as
informacoes sobre os artefatos de software, com o objetivo de aumentar a percepcao dos
indivıduos. Para tal, a abordagem utiliza uma rede de artefatos de software associados
para apresentar as informacoes contextuais. Essa apresentacao e baseada em um grafo,
com vertices representando os artefatos de software – codigo fonte e diagrama de classes
– e arestas representando as dependencias que existem entre tais artefatos de software.
O grafo e gerado a partir do processamento das relacoes de dependencias entre os
artefatos de software – Secao 4.6. Esse grafo apresenta as entidades e os relacionamentos
existentes entre os artefatos de software do mesmo tipo. Entretanto, deve-se enfatizar que
sao apresentados, tambem, os relacionamentos entre codigo fonte e diagrama de classes.
Isso deve-se ao fato de que codigo fonte e diagrama de classes compartilham alguns
conceitos, tais como classe, variavel/atributo ou metodo/operacao, conforme discutido
na Secao 4.6.
A apresentacao e atualizada de acordo com as acoes que sao realizadas sobre os
artefatos de software. Assim, quando um codigo fonte e enviado para o Repositorio
de Codigo ou um diagrama de classes e armazenado no Repositorio de Modelo por um
indivıduo, tais acoes sao refletidas na apresentacao. Assim, a rede de artefatos de software
e compartilhada entre todos os membros das equipes, permitindo a percepcao de contexto
sobre os artefatos de software.
Os vertices do grafo sao apresentados em cores diferentes (vermelho ou amarelo). Os
vertices que representam o codigo fonte sao apresentados na cor vermelha, enquanto os
vertices que representam o diagrama de classes sao apresentados na cor amarela. Dessa
forma, a aplicacao de cores diferentes pode apoiar o aumento da percepcao pelo indivıduo.
Alem do grafo, representando as dependencias entre os artefatos de software, e
importante apresentar maiores detalhes sobre os mesmos. Para tal, a apresentacao na
forma textual tambem e necessaria para a visualizacao das informacoes contextuais, tais
como aquelas da Secao 4.4. Assim, juntamente com o grafo, sao apresentadas informacoes
contextuais sobre o artefato de software que o indivıduo desejar.
Quando um codigo fonte e alterado, por exemplo, a rede de artefatos de software
deve refletir essas mudancas. Assim, o grafo apresenta a nova versao e a versao anterior
desse artefato de software. Os indivıduos das equipes utilizam o grafo para obter
informacoes sobre o que esta acontecendo durante o desenvolvimento distribuıdo de
software, acompanhando as mudancas que ocorrem sobre os artefatos de software. Isso
facilita o entendimento pelos indivıduos e, assim, pode-se perceber quais artefatos de
72
software afetam aquele artefato que o indivıduo produziu ou modificou. Dessa forma, a
rede de artefatos de software e util para perceber as relacoes de dependencia e o estado
dos artefatos de software.
4.8 Consideracoes Finais
Neste capıtulo foi apresentada a abordagem, denominada DiSEN-CollaborAR, que for-
nece informacoes sobre os artefatos de software que sao produzidos e/ou modificados
durante o desenvolvimento distribuıdo de software. Assim, os indivıduos adquirem uma
compreensao maior sobre as acoes realizadas em um projeto de software. Para tal, a
abordagem apoia a percepcao de contexto sobre os artefatos de software pelos membros
de equipes distribuıdas para reduzir os problemas de comunicacao e coordenacao. Para
atingir esse objetivo, foram definidas quatro estruturas: Workspace, Repositorio Com-
partilhado, Mecanismo e Componente Visual. Foram detalhadas algumas caracterısticas
que constituem-se em pilares que sustentam a abordagem DiSEN-CollaborAR. Tais
caracterısticas dizem respeito a: (i) elementos de percepcao, (ii) contexto de artefato, (iii)
representacao de contexto para artefatos de software, (iv) rastreabilidade entre artefatos
de software, e (v) apresentacao da rede de artefatos de software.
A abordagem DiSEN-CollaborAR combina alguns aspectos positivos das outras abor-
dagens e ferramentas de percepcao de contexto sobre artefatos de software, tal como
a captura de informacoes contextuais a partir de Sistema de Controle de Versao e de
Ferramenta CASE UML e apresentacao por meio de grafos. Entretanto, esta abordagem
tambem explora outros desafios, tal como a associacao de vınculos de rastreabilidade entre
tipos diferentes de artefatos de software – codigo fonte e diagrama de classes.
Alem disso, a abordagem DiSEN-CollaborAR explora a representacao semantica das
informacoes contextuais sobre os artefatos de software por meio de uma ontologia. Isso
permite a geracao automatica das relacoes de dependencias entre os artefatos de software
com base na ontologia, de acordo com a informacao estrutural e semantica encontradas
nos proprios artefatos.
Com base nos aspectos apresentados na Secao 3.8 do Capıtulo 3, a Tabela 4.3
apresenta uma comparacao entre as ferramentas descritas no Capıtulo 3 e a abordagem
DiSEN-CollaborAR.
73
Tabela
4.3:Com
paracao
entreos
trab
alhos
relacion
ados
eaDiSEN-C
ollaborAR
Ferramenta
Fonte
de
in-
form
acao
Tipo
de
ar-
tefato
Tipodeinform
acao
Analise
das
in-
form
acoes
Apre
senta
cao
das
inform
acoes
Localdeapre
-senta
cao
Palan
tır
SCV,
ambiente
dedesenvolvi-
mento
Cod
igofonte
Historico
dealteracoes
dos
artefatos,
impacto
das
alteracoes
Relevan
cia,
confli-
tos
Con
junto
de
janelas
emcascatasorden
adas
Aplicacao
inde-
pen
dente
Ariadne
SCV
Cod
igofonte
Relacao
socio-tecn
ica
entreos
artefatos,
au-
toriados
artefatos
Inferencia
sobre
os
autoresdoartefato
Visualizacaocom
base
emgrafo
Ambiente
dede-
senvolvim
ento
Augu
rSCV
Cod
igofonte
Estrutura
dos
artefa-
tos,
atividad
esrelaci-
onad
asao
sartefatos,
autoriadas
alteracoes,
evolucaodos
artefatos
Relacionam
entos
entre
atividad
ese
artefatos
Visualizacaocom
base
emlinhas
de
codigo,
linhas
coloridas,
visoes
com
grafi
cos
estatısticos
Aplicacao
inde-
pen
dente
ADAMS
Inseridas
manualm
ente
pelousuario
Cod
igo
fonte,
diagrama,do-
cumentacao
Relacoes
de
dep
enden
cias
entre
osartefatos,
historico
de
alteracoes
dos
artefatos
Nao
apresenta
Visualizacaocom
base
emgrafo,ıcon
esasso-
ciad
osaos
tiposdear-
tefatos
Aplicacao
inde-
pen
dente
ProjectWatcher
SCV
Cod
igofonte
Historico
dealteracoes
dos
artefatos,
autoria
das
alteracoes
Nao
apresenta
Visualizacaocom
base
emretangulos
colori-
dosagrupados
pordi-
retorios
Ambiente
dede-
senvolvim
ento
eap
licacao
inde-
pen
dente
EvolTrack
SCV,
ambiente
dedesenvolvi-
mento
Cod
igofonte
Estrutura
dos
artefa-
tos,
autoria
das
al-
teracoes
Metricas
Diagrama
de
classes
dispostoem
umalinha
dotempo,
escala
deco-
res
Ambiente
dede-
senvolvim
ento
DiSEN
CollaborAR
SCV,
ferramenta
CASE
UML
Cod
igo
fonte,
diagrama
de
classes
Estrutura
edep
enden
cias
dos
artefatos
Inferencia
para
ge-
rardep
enden
cias
Grafo,coresetexto
Aplicacao
inde-
pen
dente
74
A abordagem DiSEN-CollaborAR, no entanto, possui algumas limitacoes. O objetivo
de tal abordagem e explorar desafios especıficos para apoiar a percepcao de contexto
sobre artefatos de software em projetos com equipes distribuıdas. Certamente existem
outros desafios que podem ter um impacto importante sobre o aumento da percepcao de
contexto quando se trata de artefatos de software. Essas questoes especıficas estavam alem
do escopo do trabalho relatado aqui. Por exemplo, a percepcao de contexto, explorada
neste trabalho, complementa apenas as informacoes contextuais no escopo dos artefatos
de software gerados durante o ciclo de vida de um projeto distribuıdo. Nesse sentido,
varios autores (Gutwin et al., 2004; Kantor e Redmiles, 2001; Tran et al., 2006) tratam a
percepcao de contexto sobre o projeto e o ambiente como um todo. Alem disso, dentre os
varios artefatos de software que podem existir (Cleland-Huang et al., 2003), para o escopo
da abordagem proposta foram considerados apenas codigo fonte e diagrama de classes.
Outra limitacao desta abordagem diz respeito a rastreabilidade entre artefatos de
software. Conforme discutido na Secao 4.6, as relacoes de dependencias entre os artefatos
de software sao geradas a partir da informacao estrutural e semantica encontradas nos
proprios artefatos. Entretanto, a abordagem DiSEN-CollaborAR explora apenas classe,
variavel e metodo quando se trata de codigo fonte e, classe, atributo e operacao quando
se trata de diagrama de classes. Dessa forma, seria interessante explorar outros elementos
que fazem parte da estrutura de artefatos de software, tais como pacotes, interfaces,
componentes, comentarios, constantes e estereotipos.
O proximo capıtulo apresenta a arquitetura e a implementacao de um prototipo que
apoia a abordagem DiSEN-CollaborAR. Ressalta-se que, esta abordagem foi definida
a partir da compilacao de algumas ferramentas para desenvolvimento de software, tais
como Sistema de Controle de Versao e Ferramenta CASE UML, e do prototipo que foi
desenvolvido para fornecer apoio ao funcionamento do mecanismo.
75
Capıtulo
5
Arquitetura e Implementacao
5.1 Consideracoes Iniciais
A fim de verificar a viabilidade da abordagem DiSEN-CollaborAR, apresentada no
Capıtulo 4, um prototipo chamado ACAS (Artifact Collaborative Awareness System) foi
implementado. Neste capıtulo e descrita a arquitetura do prototipo e detalhado como
seus elementos arquiteturais sao cumpridos pela implementacao para apoiar a abordagem
DiSEN-CollaborAR.
Note que, em relacao a arquitetura do prototipo, sao descritos detalhadamente os
pacotes presentes na arquitetura e suas respectivas classes, em nıvel de fundamentacao
do funcionamento do prototipo. Ao passo que, em relacao a implementacao do prototipo,
sempre que pertinente, e apresentado um exemplo de utilizacao, para que o seu entendi-
mento seja facilitado e a sua utilidade demonstrada.
O restante deste capıtulo esta organizado da seguinte forma. Secao 5.2 descreve uma
visao geral da arquitetura do prototipo. Secao 5.3 apresenta os detalhes da implementacao
do prototipo. Finalmente, na Secao 5.4 sao apresentadas as consideracoes finais.
5.2 Arquitetura do ACAS
Conforme apresenta a Figura 5.1, a arquitetura do prototipo ACAS esta organizada
em diagrama de pacotes. O prototipo possui varias classes e interfaces, entre outros
elementos, portanto, esses itens foram organizados em grupos maiores por meio de pacotes.
76
Os pacotes agrupam elementos que estao proximos semanticamente e que tendem a se
modificar em conjunto (Booch et al., 2005). Dessa forma, o diagrama de pacotes permite
a visualizacao de grupos de elementos que podem ser manipulados como um todo ou
de uma forma que permita controlar a respectiva visibilidade e o acesso aos elementos
individuais.
Figura 5.1: Visao geral da arquitetura do ACAS
O prototipo apoia a abordagem na captura de informacoes contextuais sobre os
artefatos de software para, em seguida, representar e processar e, por fim, apresentar aos
membros das equipes distribuıdas. Os pacotes que constituem a arquitetura do prototipo
sao descritos abaixo.
77
5.2.1 Pacote model
O pacote model possui classes que constituem o modelo de artefatos, representando os
artefatos de software e seus estados. Esse pacote e constituıdo de dois subpacotes: code e
diagram. O pacote code contem a classe que representa os artefatos do tipo codigo fonte.
O pacote diagram possui as classes que representam os artefatos do tipo diagrama UML.
A Figura 5.2 apresenta os artefatos de software implementados no prototipo.
Figura 5.2: Diagrama de classes do pacote model
A classe Artifact representa um artefato de software que pode ser especializado em
outros. A classe SourceCode abstrai os conceitos do artefato codigo fonte. A classe
ClassDiagram abstrai os conceitos do artefato diagrama de classes.
5.2.2 Pacote event
Este pacote oferece scripts e servicos necessarios para a integracao com as ferramentas
Sistema de Controle de Versao e Ferramenta CASE UML. Os scripts sao responsaveis
por monitorar as acoes realizadas nas ferramentas que estao instaladas no workspace do
indivıduo. O pacote event e constituıdo de dois subpacotes: codeEvent e diagrEvent.
O pacote codeEvent contem um mecanismo chamado hook script que e executado quando
um evento, tal como commit ou push, ocorre no Sistema de Controle de Versao. O pacote
diagrEvent possui um script que e executado quando um evento, tal como salvar um
arquivo XMI, ocorre na Ferramenta CASE UML.
Alem dos scripts responsaveis por monitorar os eventos que ocorrem nas ferramentas,
este pacote apresenta algumas classes, conforme a Figura 5.3. CaptureClient e um com-
ponente executado pelo script que recebe como parametro um objeto que representa um
artefato de software. ICapturable e uma interface remota executada pelo CaptureClient
para enviar o objeto, que representa o estado de um artefato de software, por Remote
Method Invocation (RMI) para o no servidor.
78
Figura 5.3: Diagrama de classes do pacote event
As classes do pacote event estao no no workspace do indivıduo, pois e onde ocorrem
todas as atividades por parte de uma equipe de desenvolvimento de software. Assim, o
workspace e monitorado, a fim de capturar as informacoes sobre os artefatos de software
quando um evento ocorre.
5.2.3 Pacote extract
O pacote extract e constituıdo de dois subpacotes: capture e parse. O pacote capture
contem as classes que implementam o componente que recebe um objeto que representa
um artefato de software. O pacote parse apresenta subpacotes, codeParse e diagrParse,
que possuem as classes responsaveis por realizar o parser nos codigos Java e XMI.
A Figura 5.4 apresenta as classes que fazem parte deste pacote e foram implementados
no prototipo. Parse e responsavel por definir um objeto, do tipo codigo fonte ou diagrama
de classes, que vai ser manipulado por meio de um parser. CodeParse recebe o codigo
de um artefato de software do tipo codigo fonte e realiza o parser. DiagrParse recebe o
codigo XMI de um artefato de software do tipo diagrama de classes e realiza o parser.
79
Figura 5.4: Diagrama de classes do pacote extract
O pacote org.eclipse.jdt.core.dom.AST apresenta uma Application Programming
Interface (API), o Eclipse JDT Core1, que fornece apoio para manipular o codigo fonte
Java, tal como realizar o parser sobre o mesmo. O pacote org.xml.sax apresenta uma
API, o SAX2 – Simple API for XML, que fornece apoio para manipular o codigo XMI,
tal como realizar o parser sobre o mesmo.
5.2.4 Pacote agency
Esse pacote contem as classes responsaveis pelo processamento das informacoes contex-
tuais. O pacote agency e constituıdo pelos subpacotes action, agent, engine e sensor,
que estendem o framework DiSEN Agency (Monte-Alto et al., 2012). Esse framework
apoia o desenvolvimento de sistemas multi-agentes baseado em conhecimento.
A Figura 5.5 apresenta as classes que fazem parte deste pacote e foram implementados
no prototipo. A classe AgentCreator e responsavel por modificar as configuracoes
de domınio e inicializar os agentes. DataGetterAgent e responsavel por receber os
dados capturados dos artefatos de software. GetArtifactDataAction e responsavel por
1http://www.eclipse.org/jdt/core/2http://www.saxproject.org/
80
extrair fatos relativos aos artefatos. DependenceCreatorAction e responsavel por realizar
inferencias sobre a ontologia.
Figura 5.5: Diagrama de classes do pacote agency
O pacote disen-agency apresenta o framework DiSEN Agency (Monte-Alto et al.,
2012), que apoia o desenvolvimento de sistemas multi-agentes baseado em conhecimento.
O pacote semanticore apresenta um framework, chamado SemantiCore (Escobar et
al., 2006), que permite o desenvolvimento de agentes capazes de localizar, interpretar
e usar objetos de conhecimento que encapsulam os elementos requeridos para resolver
determinado problema. O pacote com.hp.hpl.jena apresenta um framework, o Apache
Jena3, que fornece apoio para a manipulacao de ontologias.
5.2.5 Pacote visualize
O pacote visualize e constituıdo pelas classes responsaveis por gerar a visualizacao das
redes de artefatos de software por meio de grafos. A Figura 5.6 apresenta as classes que
fazem parte deste pacote e foram implementados no prototipo. A classe OntologyHandler
e responsavel por recuperar as informacoes sobre os artefatos de software que estao
representadas na ontologia. Layout e responsavel por criar e configurar a janela e o
conteudo que serao exibidos. LayoutPane e responsavel por gerar o painel para visualizar
o grafo.
3http://jena.apache.org/
81
Figura 5.6: Diagrama de classes do pacote visualize
O pacote edu.uci.ics.jung apresenta um framework que fornece apoio para a mani-
pulacao de grafos. O framework JUNG4 – Java Universal Network/Graph (O’Madadhain
et al., 2003) fornece uma API para a criacao, manipulacao e visualizacao de dados
representados como grafos ou redes. A extensibilidade do JUNG permite definir indicacoes
visuais tais como o tamanho e a cor dos vertices e das arestas para transmitir informacoes
contextuais para o indivıduo. O pacote com.hp.hpl.jena apresenta um framework, o
Apache Jena, que fornece apoio para a manipulacao de ontologias.
5.3 Implementacao do ACAS
Utilizou-se a linguagem Java como plataforma de desenvolvimento do prototipo ACAS.
Com base na abordagem DiSEN-CollaborAR, discutida no Capıtulo 4, o prototipo
apresenta integracao com Mercurial5 e ArgoUML6 para Sistema de Controle de Versao
e Ferramenta CASE UML, respectivamente. Alem disso, o prototipo desenvolvido prove
apoio para os seguintes artefatos de software: (1) codigo fonte: Java; e (2) diagrama de
classes: codigo XMI. No entanto, ressalta-se que as ideias apresentadas no Capıtulo 4 nao
estao restritas a qualquer tipo de software. Sendo assim, na implementacao apresentada
aqui, adotou-se os softwares citados anteriormente.
As informacoes sobre o codigo fonte sao capturadas a partir dos eventos que ocorrem no
Mercurial no workspace do indivıduo. Quando um commit ou um push para o repositorio
e efetuado – a Figura 5.7 apresenta um exemplo de commit, um mecanismo chamado
4http://jung.sourceforge.net/5http://mercurial.selenic.com/6http://argouml.tigris.org/
82
hook script e executado. Nesse mecanismo e possıvel definir um Shell Script7 que e
executado posteriormente. Dessa forma, quando ocorre um commit, por exemplo, as
informacoes sobre tal evento sao capturadas pelo Shell Script. As informacoes capturadas
estao relacionadas, por exemplo, ao nome do arquivo, versao, autor, data, ferramenta,
entre outras. A Figura 5.8 apresenta uma breve ilustracao do Shell Script implementado.
Figura 5.7: Exemplo de commit
As informacoes sobre diagrama de classes sao capturadas a partir dos eventos que
ocorrem no ArgoUML no workspace do indivıduo. Para tal, o diagrama de classes deve
ser exportado como um arquivo XMI e armazenado em um repositorio de modelo. Tal
repositorio de modelo e monitorado por um Shell Script que captura as informacoes sobre
o codigo XMI. As informacoes capturadas estao relacionadas, por exemplo, ao nome do
arquivo, versao, autor, data, ferramenta, entre outras. A Figura 5.9 apresenta uma breve
ilustracao do Shell Script implementado.
Figura 5.8: Shell Script que captura informacoes sobre o codigo fonte
7E uma linguagem de script que e interpretada por um bash e permite a execucao de sequencias decomandos
83
Em seguida, o Shell Script passa, via parametro de entrada, uma string contendo
todas as informacoes capturadas sobre o artefato de software para um objeto de acordo
com o tipo de artefato. Esse objeto, contendo o estado do artefato, e enviado para o
servidor por meio do metodo sendObject da interface ICapturable que e invocado. A
tecnologia de comunicacao entre objetos usada e o RMI.
Figura 5.9: Shell Script que captura informacoes sobre o diagrama de classes
No servidor, entre as informacoes presentes no objeto ha o codigo Java ou o codigo
XMI, de acordo com o tipo de artefato de software. Nesse codigo e realizado o parser
para obter informacoes tais como (1) classe, variaveis e metodos para o codigo fonte em
Java, e (2) classe, atributos e operacoes para o diagrama de classes em XMI.
Para realizar o parser sobre o codigo fonte Java foi utilizada a API Eclipse JDT Core.
A Figura 5.10 apresenta uma breve ilustracao do parser implementado.
84
Figura 5.10: Implementacao do parser para o codigo fonte
Para realizar o parser sobre o codigo XMI foi utilizada a API SAX. A Figura 5.11
apresenta uma breve ilustracao do parser implementado.
Apos ser realizado o parser sobre o codigo fonte e o codigo XMI, um componente e
responsavel por inferir as dependencias entre os artefatos de software. Tal componente
estende o framework DiSEN Agency (Monte-Alto et al., 2012). O raciocınio e possıvel
por meio da ontologia definida por Chaves et al. (2011), a OntoDiSENv1, que foi
estendida no domınio focado em artefatos de software – Secao 4.5. Assim, o agente
– DependenceCreatorAgent – responsavel por gerar as dependencias dos artefatos de
software deve ter acesso a base de conhecimento definida por essa ontologia, para que ele
possa realizar seu processo de inferencia. Outro agente – DataGetterAgent – e responsavel
por receber os dados capturados dos artefatos de software e gerar fatos (sujeito, predicado,
objeto) que sao processados.
85
Figura 5.11: Implementacao do parser para o codigo XMI
Alem dos agentes descritos anteriormente, outros agentes – OntologyAgent e
AgentCreator – fazem parte desse componente, no entanto sao agentes auxiliares do
proprio framework DiSEN Agency (Monte-Alto et al., 2012). OntologyAgent e res-
ponsavel por persistir e publicar a ontologia no ambiente, sendo o unico que tem acesso
direto a base de conhecimento. AgentCreator e responsavel por modificar as configuracoes
do domınio e inicializar os agentes.
Em relacao ao DependenceCreatorAgent, esse agente estende uma classe abstrata do
DiSEN Agency chamada AbstractLogicalAgent que incorpora um componente adicio-
86
nal. Tal componente – MemoryComponent – armazena uma referencia a instancia local
da base de conhecimento e algumas propriedades auxiliares, tais como o namespace da
OntoDiSENv1 e os caminhos para os arquivos da ontologia e das regras de inferencia.
O DependenceCreatorAgent executa seu mecanismo de inferencia quando recebe uma
mensagem sinalizando que a ontologia foi atualizada. O processo de inferencia consiste
em (1) carregar o arquivo de regras de inferencia, (2) processar o arquivo e, a partir
das regras e da instancia da base de conhecimento, criar um modelo de ontologia, (3)
extrair os fatos inferidos e (4) enviar os fatos inferidos ao OntologyAgent para que sejam
persistidos.
As regras de inferencia sao codificadas em um formato definido pelo Jena, constituıda
por uma lista de premissas e uma lista de conclusoes. A Figura 5.12 apresenta um exemplo
de regra de inferencia que foi implementada para o prototipo.
Figura 5.12: Exemplo de regra de inferencia
A regra apresentada acima consiste em adicionar a ontologia o fato de que um diagrama
de classes tem dependencia com um codigo fonte ao atender os seguintes requisitos: (i)
ambos os artefatos de software tem o mesmo nome para classe, de acordo com as linhas
5 e 13; (ii) ambos diagrama de classes e codigo fonte tem o mesmo nome para atributo e
variavel, respectivamente, de acordo com as linhas 7 e 15; (iii) ambos diagrama de classes
e codigo fonte tem o mesmo nome para operacao e metodo, respectivamente, de acordo
com as linhas 9 e 17.
Em seguida, com os fatos inferidos, tal como no exemplo da Figura 5.12, e persistidos
na ontologia, uma rede de artefatos de software e apresentada por meio de um grafo para os
indivıduos. O componente responsavel pela interface com o usuario e o visualize – Secao
87
5.2.5. Assim, as informacoes contextuais sobre os artefatos de software sao recuperadas da
base de conhecimento e, em seguida, a classe LayoutPane disponibiliza essas informacoes
e gera o grafo. Para apoiar a construcao do grafo e utilizado o framework JUNG. A Figura
5.13 mostra a interface do usuario no prototipo, destacando os elementos de percepcao
definidos na Secao 4.4 do Capıtulo 4.
Figura 5.13: Interface do usuario no ACAS
Conforme apresentado na Figura 5.13, a coluna da esquerda apresenta as informacoes
contextuais sobre um artefato de software, enquanto a coluna da direita apresenta
um exemplo de grafo. As informacoes contextuais apresentadas sao tipo de artefato,
arquivo, versao, data, ferramenta, autor, equipe, localizacao, classe, variaveis/atributos e
metodos/operacoes. No grafo, as arestas representam as dependencias que existem entre
os artefatos de software e, os vertices representam os artefatos de software. Vertices na
cor amarela representam artefatos do tipo diagrama de classes. Vertices na cor vermelha
representam artefatos do tipo codigo fonte.
88
5.4 Consideracoes Finais
Neste capıtulo foram descritas a arquitetura e a implementacao do prototipo ACAS, com
base na abordagem apresentada no Capıtulo 4. Inicialmente, foi apresentada a arquitetura
do prototipo, que inclui cinco pacotes: model, event, extract, agency e visualize. Em
seguida, os elementos arquiteturais implementados foram detalhados, com o intuito de
apoiar a abordagem DiSEN-CollaborAR.
Por meio da implementacao do prototipo ACAS, verificou-se as funcionalidades da
infraestrutura em prover informacoes contextuais pertinentes aos artefatos de software.
Assim, tal infraestrutura mostra-se como uma solucao para auxiliar os indivıduos no
desenvolvimento distribuıdo de software. Alem disso, o prototipo ACAS forneceu uma
prova de conceito para a abordagem DiSEN-CollaborAR.
O prototipo implementado, no entanto, possui algumas limitacoes. Os artefatos de
software do tipo diagrama de classes devem estar no formato XMI, embora essa restricao
seja definida pela abordagem. Sobre os artefatos de software do tipo codigo fonte, o
prototipo trabalha apenas com a linguagem Java. Alem disso, a integracao do prototipo
com o Sistema de Controle de Versao ocorre, no momento, apenas com o Mercurial.
O proximo capıtulo apresenta um estudo experimental organizado em definicao, pla-
nejamento, operacao e analise dos dados. Assim, o prototipo implementado foi utilizado
no estudo experimental para apoiar a realizacao das atividades e, consequentemente, ser
possıvel a avaliacao da abordagem DiSEN-CollaborAR. O estudo experimental serviu
como uma validacao inicial da abordagem DiSEN-CollaborAR.
89
Capıtulo
6
Estudo Experimental
6.1 Consideracoes Iniciais
Este capıtulo descreve o plano e o resultado do estudo experimental para avaliar os be-
nefıcios proporcionados pelo uso da DiSEN-CollaborAR – uma abordagem para percepcao
de contexto sobre artefatos de software para equipes distribuıdas, descrita no Capıtulo 4.
Assim, foi realizado um experimento controlado em laboratorio que considera a proposicao
e a avaliacao da abordagem apresentada no que diz respeito a sua viabilidade de aplicacao
em ambientes de desenvolvimento distribuıdo de software. Ressalta-se que, o prototipo
ACAS, apresentado no capıtulo 5, foi utilizado neste estudo experimental para apoiar
a realizacao das atividades e, consequentemente, ser possıvel a avaliacao da abordagem
DiSEN-CollaborAR.
A apresentacao deste estudo experimental segue o processo proposto por Wohlin et
al. (2000) para descrever um plano de estudo experimental. O experimento foi tratado
como um processo de avaliacao da abordagem proposta e foi realizado em quatro fases:
(1) definicao, (2) planejamento, (3) operacao e (4) analise e interpretacao.
O restante deste capıtulo esta organizado da seguinte forma. Secao 6.2 apresenta a
definicao do experimento. Secao 6.3 apresenta o planejamento do experimento. Secao
6.4 descreve como a operacao foi realizada. Secao 6.5 apresenta a analise e interpretacao
detalhadas dos resultados obtidos. Finalmente, na Secao 6.6 e apresentada a discussao, na
Secao 6.7 sao relatadas as licoes aprendidas, seguida pelas consideracoes finais na Secao
90
6.8. Os instrumentos utilizados para o estudo experimental podem ser encontrados no
Apendice A.
6.2 Definicao
Esta fase fornece a direcao geral do experimento e o seu escopo. Assim, o proposito
deste estudo foi avaliar o uso da abordagem DiSEN-CollaborAR em desenvolvimento
distribuıdo de software e, desta forma, analisar o quanto tal abordagem contribui com a
percepcao de contexto sobre os artefatos de software. A fim de alcancar esse proposito,
foi analisada a adocao da DiSEN-CollaborAR em comparacao com uma abordagem ad
hoc no desenvolvimento de um Sistema de Gestao Hoteleira.
Para avaliar se abordagem apoia a percepcao de contexto sobre artefatos de software
em equipes distribuıdas, e necessario analisar as informacoes da estrutura dos artefatos de
software juntamente as informacoes do processo humano das atividades realizadas. Nesse
sentido, diversos aspectos da abordagem podem ser avaliados: (1) eficacia, (2) capacidade
de apresentacao visual, (3) desempenho e (4) usabilidade. Neste estudo experimental
foram avaliados apenas os aspectos “1” e “2”: eficacia da abordagem, pois a mesma deve
proporcionar a compreensao sobre as acoes realizadas sobre os artefatos de software; e
capacidade de apresentacao visual da abordagem, pois as informacoes relacionadas aos
artefatos de software devem ser apresentadas visualmente para facilitar a percepcao de
contexto sobre os artefatos de software. Os demais aspectos podem ser avaliados em
trabalhos futuros.
De acordo com os princıpios do GQM (Basili et al., 1994; Solingen e Berghout, 1999),
na fase de definicao do estudo experimental sao estabelecidos os objetivos (G), formuladas
as questoes (Q) e elaboradas as metricas (M). Assim, quanto ao objetivo (G), este estudo
experimental foi definido da seguinte forma:
Analisar a abordagem DiSEN-CollaborAR em comparacao com uma abordagem ad hoc.
Com o proposito de avaliar/caracterizar.
Com respeito a compreensao e o conhecimento pelos indivıduos sobre os artefatos de
software que sao produzidos ou modificados durante o desenvolvimento distribuıdo.
Do ponto de vista do engenheiro de software.
No contexto de indivıduos envolvidos com o desenvolvimento distribuıdo de software.
Esse objetivo e alcancado quando respostas podem ser dadas as seis questoes (Q)
abaixo. Para isso, metricas (M) foram associadas as questoes.
91
Q1: A adocao da abordagem DiSEN-CollaborAR aumenta a percepcao dos engenheiros
de software sobre os artefatos de software que sao produzidos ou modificados quando
comparada a abordagem ad hoc?
M1: Tempo despendido para a realizacao das tarefas e numero de artefatos identificados
corretamente.
Q2: A adocao da abordagem DiSEN-CollaborAR reduz o esforco durante atividades de
desenvolvimento de software com equipes distribuıdas quando comparada a abordagem
ad hoc?
M2: Tempo despendido para a realizacao das atividades.
Q3: A adocao da abordagem DiSEN-CollaborAR aumenta a quantidade de artefatos
identificados corretamente durante atividades de desenvolvimento de software com equipes
distribuıdas quando comparada a abordagem ad hoc?
M3: Numero de artefatos identificados corretamente.
Q4: A adocao da abordagem DiSEN-CollaborAR reduz o grau de complexidade na
realizacao das tarefas durante o desenvolvimento de software com equipes distribuıdas
quando comparada a abordagem ad hoc?
M4: Numero de indicacoes dos participantes quanto a reducao do grau de complexidade
das tarefas.
Q5: As informacoes contextuais sobre os artefatos de software apresentadas pela aborda-
gem DiSEN-CollaborAR sao suficientes para a percepcao do indivıduo?
M5: Numero de indicacoes dos participantes quanto a suficiencia das informacoes
contextuais.
Q6: A rastreabilidade entre os artefatos de software apresentada pela abordagem
DiSEN-CollaborAR e util para a percepcao de contexto?
M6: Numero de indicacoes dos participantes quanto a utilidade da rastreabilidade entre
os artefatos de software.
92
6.3 Planejamento
Esta fase descreve o plano para realizar o experimento e e composta pelos seguintes
elementos: definicao das hipoteses, descricao da instrumentacao, selecao do contexto,
selecao dos indivıduos, selecao de variaveis, projeto do experimento e validade.
6.3.1 Definicao das Hipoteses
A seguir sao apresentadas as hipoteses nula e alternativas deste estudo experimental.
Hipotese nula (H0): A adocao da abordagem DiSEN-CollaborAR nao aumenta a per-
cepcao de contexto sobre os artefatos de software pelos membros das equipes distribuıdas
quando comparada a adocao de uma abordagem ad hoc. Isso significa que:
• (H01): nao ha diferenca no esforco para realizar as atividades adotando
DiSEN-CollaborAR quando comparada a abordagem ad hoc.
• (H02): nao ha diferenca na quantidade de artefatos identificados corretamente
adotando DiSEN-CollaborAR quando comparada a abordagem ad hoc.
Sendo assim, tem-se que:
H0: (Ta = Td) ∧ (Aa = Ad), onde:
• Ta e o tempo despendido para a realizacao das atividades adotando ad hoc.
• Td e o tempo despendido para a realizacao das atividades adotando
DiSEN-CollaborAR.
• Aa e o numero de artefatos identificados corretamente adotando ad hoc.
• Ad e o numero de artefatos identificados corretamente adotando DiSEN-CollaborAR.
Hipotese alternativa (H1): A adocao do DiSEN-CollaborAR reduz o esforco durante
as atividades de desenvolvimento de software com equipes distribuıdas se comparada a
adocao de uma abordagem ad hoc.
H1: (Ta > Td)
93
Hipotese alternativa (H2): A adocao do DiSEN-CollaborAR aumenta a quantidade de
artefatos identificados corretamente durante as atividades de desenvolvimento de software
com equipes distribuıdas se comparada a adocao de uma abordagem ad hoc.
H2: (Aa < Ad)
6.3.2 Descricao da Instrumentacao
Para a realizacao deste estudo experimental, a instrumentacao contou com um cenario de
desenvolvimento distribuıdo de um Sistema de Gestao Hoteleira. Assim, para tal cenario,
as equipes adotaram a abordagem DiSEN-CollaborAR e a abordagem ad hoc. Alem disso,
o experimento apresentou os seguintes instrumentos:
• Um termo de consentimento ao estudo experimental (Doc1 no Apendice A);
• Um questionario de caracterizacao para o participante indicar sua formacao
academica, seu nıvel de experiencia com desenvolvimento de software e uso de
ferramentas de desenvolvimento distribuıdo de software (Doc2 no Apendice A);
• Um documento descrevendo o cenario do sistema a ser desenvolvido (Doc3 no
Apendice A);
• Diagrama de classes do estudo de caso usado no experimento (Doc4 no Apendice
A);
• Listas de tarefas a serem desempenhadas pelos participantes (Doc5 no Apendice A);
• Um questionario de avaliacao para a analise qualitativa (Doc6 no Apendice A).
6.3.3 Selecao do Contexto
O contexto do experimento e composto pelas condicoes em que o experimento esta sendo
executado (Travassos et al., 2002). De acordo com Wohlin et al. (2000), o contexto pode
ser caracterizado conforme quatro dimensoes:
• Processo: on-line / off-line ;
• Participantes: alunos / profissionais;
• Realidade: problema real / modelado;
94
• Generalidade: especıfico / geral.
Este estudo experimental supoe o processo off-line porque as atividades foram realiza-
das em laboratorio e em um dia pre-determinado para a sua operacao. Os participantes
que executaram o experimento foram alunos de graduacao e pos-graduacao do curso de
Ciencia da Computacao do DIN-UEM e do ICMC-USP. O estudo e modelado porque foi
utilizado um estudo de caso que foi modelado, especificamente, para o experimento, de
modo que os participantes pudessem dar continuidade ao desenvolvimento do mesmo,
por meio dos recursos oferecidos pelas abordagens ad hoc e DiSEN-CollaborAR. A
generalidade do estudo e especıfica porque os resultados do experimento sao validos para
o contexto do desenvolvimento distribuıdo de software.
Sobre o estudo de caso utilizado no experimento, os participantes foram responsaveis
pela producao e modificacao de artefatos de software relacionados a um Sistema de
Gestao Hoteleira. Um sistema desse tipo apresenta funcionalidades para agilizar as
atividades em hoteis, tais como recepcao, reservas, controle de hospedes, quartos, diarias
e pagamentos. De certa forma, esse tipo de sistema nao exige conhecimentos avancados
para o seu entendimento e desenvolvimento, exigindo apenas conhecimentos basicos sobre
projeto e implementacao orientada a objetos. As linguagens UML e Java foram adotadas,
respectivamente, para modelagem e codificacao neste estudo de caso.
6.3.4 Selecao dos Indivıduos
Como participantes para este estudo experimental foram selecionados alunos de graduacao
e pos-graduacao em Ciencia da Computacao que frequentam cursos da Universidade Esta-
dual de Maringa (DIN-UEM) e da Universidade de Sao Paulo (ICMC-USP). Assumiu-se
que esses indivıduos estavam disponıveis para o estudo e tinham conhecimento sobre
desenvolvimento de software.
Os participantes preencheram um questionario que teve como objetivo caracterizar
sua formacao do ponto de vista academico, experiencia e conhecimentos para analisar os
dados e reduzir o vies. Alem disso, os participantes foram preparados por meio de um
treinamento realizado antes da experimentacao.
6.3.5 Selecao de Variaveis
As variaveis independentes sao fatores referentes a entrada do processo de experimentacao;
as variaveis dependentes sao respostas referentes a saıda do processo de experimentacao
(Travassos et al., 2002). A seguir sao apresentadas as variaveis independentes e depen-
95
dentes deste estudo experimental.
1) Variaveis independentes:
• A abordagem DiSEN-CollaborAR;
• Uma abordagem ad hoc;
• A experiencia e os conhecimentos dos participantes;
• A caracterizacao do domınio da aplicacao (Sistema de Gestao Hoteleira).
2) Variaveis dependentes:
• O tempo despendido para a realizacao das atividades;
• O numero de artefatos identificados corretamente;
• Numero de indicacoes quanto a reducao do grau de complexidade das tarefas;
• Numero de indicacoes quanto a suficiencia das informacoes contextuais;
• Numero de indicacoes quanto a utilidade da rastreabilidade entre os artefatos de
software.
Uma caracterıstica importante sobre as variaveis e que seus valores sao coletados em
escalas (Travassos et al., 2002), tais como: (i) nominal: representam diferentes tipos
de um elemento, sem interpretacao numerica e de ordenacao entre eles; (ii) ordinal:
representam diferentes tipos de um elemento que podem ser ordenados, ainda que sem
qualquer interpretacao numerica; (iii) intervalo: podem ser ordenados e distancias entre
valores consecutivos possuem a mesma interpretacao, porem a razao entre estes valores nao
tem significado; e (iv) razao: podem ser ordenados, distancias entre valores consecutivos
possuem o mesmo significado e a razao entre valores pode ser interpretada. As escalas
determinam as operacoes que podem ser aplicadas sobre os valores das variaveis. A Tabela
6.1 apresenta a classificacao das variaveis citadas anteriormente.
96
Tabela 6.1: Classificacao das variaveis selecionadas neste estudo experimental
Tipo Variavel Escala
Variaveis independentes
Abordagem DiSEN-CollaborAR NominalAbordagem ad hoc NominalCaracterizacao e conhecimentos dosparticipantes
Nominal ou ordinal
Caracterizacao do domınio daaplicacao
Nominal ou ordinal
Variaveis dependentes
Tempo despendido para a realizacaodas atividades
Razao
Numero de artefatos identificadoscorretamente
Razao
Numero de indicacoes quanto areducao do grau de complexidadedas tarefas
Razao
Numero de indicacoes quanto a su-ficiencia das informacoes contextu-ais
Razao
Numero de indicacoes quanto a uti-lidade da rastreabilidade entre osartefatos de software
Razao
6.3.6 Projeto do Experimento
O projeto deste estudo experimental envolveu dois fatores: (1) percepcao de contexto
sobre artefatos de software e (2) domınio da aplicacao.
Este estudo experimental comparou um cenario de desenvolvimento distribuıdo de
software “com” e “sem” a adocao da abordagem DiSEN-CollaborAR. Assim, o fator
percepcao de contexto sobre artefatos de software apresentou dois tratamentos:
• Percepcao de contexto sobre artefatos de software adotando a abordagem
DiSEN-CollaborAR: os participantes adotaram a abordagem apresentada no
Capıtulo 4, composta por Sistema de Controle de Versao, Ferramenta CASE UML
e o prototipo ACAS, apresentado no Capıtulo 5.
• Percepcao de contexto sobre artefatos de software adotando uma aborda-
gem ad hoc: os participantes adotaram apenas as ferramentas Sistema de Controle
de Versao e Ferramenta CASE UML.
97
O fator domınio de aplicacao teve o seguinte cenario (Doc3 no Apendice A apresenta
informacoes detalhadas sobre o cenario):
• Desenvolvimento de um Sistema de Gestao Hoteleira: os participantes
produziram e modificaram artefatos de software relacionados as classes de um
sistema que apresenta recursos para o gerenciamento de atividades em hoteis.
A selecao dos participantes nao foi de forma aleatoria dentro no universo de candidatos,
pois tal universo era restrito. Os grupos foram constituıdos de acordo com a sua
localizacao, neste caso Maringa e Sao Carlos. Assim, este experimento consistiu em um
grupo de 8 pessoas em Maringa e um grupo de 10 pessoas em Sao Carlos, os quais foram
observados por um moderador.
O procedimento experimental apresentou duas sessoes. Primeiramente, na Sessao 1
os dois grupos realizaram as atividades adotando uma abordagem ad hoc. Em seguida,
na Sessao 2 os dois grupos realizaram as mesmas atividades, mas adotando a abordagem
DiSEN-CollaborAR. A Tabela 6.2 apresenta a distribuicao dos grupos.
Tabela 6.2: Alocacao dos grupos
Sessao Abordagem Grupo Localizacao Quantidade de Pessoas
1Ad hoc A1 Maringa 8Ad hoc B1 Sao Carlos 10
2DiSEN-CollaborAR A2 Maringa 8DiSEN-CollaborAR B2 Sao Carlos 10
Inicialmente, os indivıduos receberam o Termo de Consentimento (Doc1 no Apendice
A) e, caso concordassem em participar do experimento, respondiam o questionario
de Caracterizacao do Participante (Doc2 no Apendice A). Esse questionario contem
perguntas sobre a experiencia academica e conhecimentos, geral e especıfico, do indivıduo
em temas relacionados a este estudo. Os dados coletados desses questionarios foram
utilizados para interpretar os resultados obtidos pelos indivıduos.
Em seguida, foi apresentado o trabalho e realizado um treinamento – durante, aproxi-
madamente, 45 minutos – sobre os principais conceitos associados a percepcao de contexto
sobre artefatos de software no desenvolvimento de software com equipes distribuıdas. O
objetivo desse treinamento foi apresentar as abordagens DiSEN-CollaborAR e ad hoc
para os grupos obterem familiaridade com os recursos. Alem disso, as equipes receberam
um documento que apresentava o Cenario (Doc3 no Apendice A) caracterizando o
desenvolvimento de um Sistema de Gestao Hoteleira.
98
Durante o experimento, as equipes receberam a Lista de Tarefas (Doc5 no Apendice
A) e alguns artefatos de software para a realizacao das atividades de desenvolvimento
de software. Os indivıduos, em ambos os tratamentos – DiSEN-CollaborAR e ad hoc,
receberam diagramas e codigos fonte de algumas classes do sistema e, em seguida,
realizaram alteracoes e produziram novos artefatos de software. Os participantes re-
gistravam a hora de inıcio, em seguida realizavam as tarefas pre-determinadas e ao final
da tarefa, registravam a hora de termino na Lista de Tarefas. Alem disso, os participantes
registravam na Lista de Tarefas os artefatos produzidos e/ou modificados durante a
realizacao das atividades.
Ao final da simulacao do desenvolvimento do software, os participantes responderam
a um Questionario de Avaliacao (Doc6 no Apendice A) que apresenta um conjunto de
perguntas sobre a conducao do experimento, sobre a abordagem DiSEN-CollaborAR e
sobre a percepcao durante o desenvolvimento do software. Em ambas as abordagens, ad
hoc e DiSEN-CollaborAR, as equipes receberam o mesmo cenario e conjunto de atividades
de modelagem e de codificacao.
E importante observar que, antes da execucao real do experimento, foi realizado
um “experimento piloto” para avaliar a instrumentacao que foi utilizada neste estudo
experimental. Para tal, somente tres indivıduos – alunos de pos-graduacao do DIN-UEM
que nao tinham conhecimento das questoes de pesquisa – foram utilizados, incluindo os
mesmos instrumentos do estudo experimental. Os dados obtidos pelo experimento piloto
nao foram utilizados para complementar este estudo.
6.3.7 Validade
Uma questao fundamental com relacao aos resultados do experimento e identificar quao
validos sao eles, pois estes devem ser generalizados (Travassos et al., 2002). Segundo
Wohlin et al. (2000), ha quatro tipos de validade em um experimento: interna, externa, de
construcao e de conclusao. As ameacas de validade identificadas neste estudo experimental
sao descritas a seguir.
Validade interna: define se o relacionamento observado entre o tratamento e o resultado
e causal, sendo considerados a selecao da populacao, a maneira da divisao das classes, o
modo da aplicacao dos tratamentos e os aspectos sociais (Travassos et al., 2002). Para
a selecao dos indivıduos, este estudo experimental utilizou alunos do curso de Ciencia
da Computacao que, geralmente, costumam desenvolver software em nıvel academico.
Assim, assumiu-se que eles eram representativos para a populacao dos desenvolvedores
99
de software em DDS. Para reduzir a influencia de ameacas a validade interna, como
o fato de um grupo ter mais conhecimento e experiencia e, consequentemente, ter um
desempenho melhor, independentemente da abordagem adotada, os participantes dos
dois grupos realizaram as tarefas adotando as duas abordagens em sessoes diferentes.
No entanto, a ordem de aplicacao das abordagens pode influenciar nos resultados, pois os
participantes, apos realizarem a Sessao1, podem apresentar um aprendizado maior para
a realizacao da Sessao 2. No termo de consentimento ao estudo experimental foi incluıdo
o sigilo das informacoes relevantes sobre o experimento.
Validade externa: define as condicoes que limitam a habilidade de generalizar os
resultados do experimento para a pratica industrial, sendo considerados a interacao do
tratamento com as pessoas, o lugar e o tempo (Travassos et al., 2002). Os participantes
deste estudo, em geral, foram considerados representativos para a populacao dos desen-
volvedores de software em nıvel academico. Os dados do questionario foram analisados
para avaliar o nıvel de experiencia e conhecimento em desenvolvimento distribuıdo de
software. Alem disso, os participantes foram preparados para a experimentacao por
meio de um treinamento. Embora seja um experimento controlado em laboratorio, neste
estudo o ambiente e as variaveis foram simulados para condizer, o mais proximo possıvel,
com a pratica industrial. No entanto, a validade externa pode ser comprometida, pois
o experimento foi realizado sobre um tipo de estudo de caso e isso pode ameacar a
generalizacao dos resultados para outros estudos de caso. Outras ameacas a validade
externa sao: a adocao da linguagem de programacao Java e a localizacao geografica.
Validade de construcao: define os relacionamentos entre a teoria e a observacao,
verificando se o tratamento reflete bem a causa e o resultado reflete bem o efeito,
considerando os aspectos relevantes ao projeto do experimento e os fatores humanos
(Travassos et al., 2002). A validade de construcao foi alcancada, pois a abordagem
DiSEN-CollaborAR e o estudo de caso usado no experimento, no nıvel que foi aplicado,
nao exigiam experiencia elevada dos participantes. No entanto, a validade de construcao
poderia ser comprometida se algum participante tivesse experiencia no desenvolvimento
de sistemas desse tipo. Com a utilizacao de dois grupos de participantes, buscou-se
generalizar os resultados para um cenario real, embora os resultados nao possam ser
generalizados pois sao influenciados pelos grupos de participantes e pelo estudo escolhido.
Validade de conclusao: e relacionada a habilidade de chegar a uma conclusao correta
a respeito dos relacionamentos entre o tratamento e o resultado do experimento, conside-
100
rando a escolha do teste estatıstico, do tamanho do conjunto dos participantes, a confiabi-
lidade das medidas e a confiabilidade da implementacao dos tratamentos (Travassos et al.,
2002). A validade de conclusao e alcancada, pois a analise dos dados foi realizada por meio
de estatıstica descritiva, analise de outliers e teste de hipoteses com metodo estatıstico
nao parametrico, para apurar a conclusao do estudo. Alem disso, as metricas sao medidas
objetivas e de facil coleta, o que reduz a influencia da complexidade de entendimento de
geracao e calculo. Entretanto, a quantidade de indivıduos – 18 – que participaram do
experimento foi baixa. Alem disso, apenas 10 indivıduos com conhecimentos em DDS,
tambem, pode ser considerado um numero baixo.
6.4 Operacao
Esta fase apresenta a aplicacao do experimento e e composta pelos seguintes elementos:
preparacao, execucao e validacao.
6.4.1 Preparacao
Os sujeitos foram dezoito alunos de Ciencia da Computacao dos cursos do DIN-UEM e
do ICMC-USP, sendo: 6 estudantes de graduacao, 8 estudantes de mestrado, 1 mestre
e 3 estudantes de doutorado. Os estudantes foram informados que seria investigado o
resultado da aplicacao de uma abordagem no desenvolvimento distribuıdo de software.
Entretanto, eles nao tinham consciencia de quais aspectos seriam estudados e conheci-
mento das hipoteses declaradas. Todos os estudantes tiveram a garantia de anonimato.
Antes do experimento ser executado, todos os instrumentos do experimento estavam
prontos. Assim, toda a instrumentacao definida na Secao 6.3.2 foi fornecida aos partici-
pantes.
6.4.2 Execucao
O experimento foi conduzido em Julho de 2012 no Laboratorio de Desenvolvimento
Distribuıdo de Software (LDDS) do DIN-UEM e no Laboratorio de Engenharia de
Software (LabES) do ICMC-USP. Os participantes assinaram um termo de consentimento
que explicava sobre o objetivo geral do estudo e autorizava que o material produzido
fosse utilizado neste estudo experimental. Alem disso, os participantes preencheram um
formulario de caracterizacao para avaliar o respectivo grau de conhecimento e experiencia.
101
Todos os estudantes tinham conhecimentos em modelagem e implementacao de siste-
mas. Entretanto, apenas sete estudantes tinham experiencia em projetos industriais. Por
outro lado, sete estudantes sao membros do Grupo de Pesquisa em Engenharia de Software
Distribuıda, e suas areas de pesquisa envolvem aspectos que proporcionam know-how
teorico a eles. A Tabela 6.3 apresenta um resumo do perfil dos participantes. A escala
de mensuracao adotada e: “0” = nenhum; “1” = basico; “2” = intermediario; “3” =
avancado.
Legenda:
(a): conhecimento em DDS
(b): conhecimento em Java
(c): conhecimento em UML
(d): experiencia com Sistema de Controle de Versao
(e): experiencia com Ferramenta CASE UML
Tabela 6.3: Perfil dos participantes no estudo experimental
Grupo Participante (a) (b) (c) (d) (e)
A
A1 1 3 2 3 2A2 1 1 1 1 1A3 0 2 2 0 1A4 1 2 2 1 2A5 0 1 1 0 1A6 1 1 2 1 2A7 0 2 1 0 1A8 2 3 2 2 2
B
B1 0 1 1 1 1B2 1 2 1 1 1B3 1 2 1 1 1B4 0 3 1 1 1B5 0 3 2 1 2B6 0 2 1 1 1B7 2 1 1 3 0B8 0 2 1 2 1B9 0 1 2 0 1B10 0 1 1 0 1
Inicialmente, os participantes receberam um treinamento sobre os conceitos e as
abordagens que seriam adotadas. Os participantes foram divididos em 2 grupos (A e B) de
102
acordo com a sua localizacao (Maringa e Sao Carlos). Conforme apresenta a Tabela 6.4,
durante a Sessao 1 os grupos realizaram as atividades adotando uma abordagem ad hoc.
Em seguida, durante a Sessao 2 os grupos adotaram a abordagem DiSEN-CollaborAR.
Tabela 6.4: Grupos e sessoes do experimento
Grupo A Grupo BSessao 1 Ad hoc Ad hocSessao 2 DiSEN-CollaborAR DiSEN-CollaborAR
Durante a operacao, os participantes realizaram uma sequencia de tarefas (Doc5 no
Apendice A). Antes de iniciar as tarefas, os participantes deveriam registrar a hora de
inıcio e apos finalizar as tarefas deveriam registrar a hora de termino. Alem disso, os
participantes registravam o nome dos artefatos produzidos e/ou modificados.
6.4.3 Validacao
Os dados foram coletados a partir do questionario de caracterizacao, listas de tarefas e
questionario de avaliacao dos 18 estudantes. Esses dados nao foram considerados como
invalidos ou questionaveis. Assim, nenhum dado dos participantes foi removido. Portanto,
todos os participantes foram considerados para a analise estatıstica e interpretacao dos
resultados.
6.5 Analise e Interpretacao
Apos a operacao do experimento, os dados foram coletados e analisados seguindo os
procedimentos definidos no planejamento do estudo. Os dados foram tratados em
um ambiente computacional para analises estatısticas, chamado R1. Nesta secao sao
apresentados: estatıstica descritiva, analise de outliers, teste de hipoteses e analise
qualitativa.
6.5.1 Estatıstica Descritiva
Como primeiro passo na analise dos dados, foi utilizada a estatıstica descritiva para
visualizar os dados coletados. A Figura 6.1 apresenta o percentual de ocorrencia dos
dados, neste caso, sobre os conhecimentos dos participantes.
1http://www.r-project.org/
103
Figura 6.1: Conhecimentos dos participantes
104
O tempo despendido para a realizacao das tarefas e a quantidade de artefatos
identificados corretamente pelos participantes sao mostrados na Tabela 6.5. Alem disso,
sao apresentadas as medianas e as medias para os conjuntos de dados.
Tabela 6.5: Dados obtidos
Grupo ParticipanteAbordagem
Ad hoc DiSEN-CollaborARTempodes-pendido(minutos)
Artefatosidenti-ficados(unidades)
Tempodes-pendido(minutos)
Artefatosidenti-ficados(unidades)
A
A1 11 2 6 2A2 10 2 6 2A3 11 2 5 2A4 15 2 5 2A5 10 2 7 2A6 15 2 9 2A7 14 2 9 2A8 14 2 9 2
B
B1 20 2 7 2B2 14 2 8 2B3 15 2 8 2B4 10 0 8 2B5 8 0 6 2B6 21 2 7 2B7 7 2 6 2B8 13 2 9 2B9 14 2 9 2B10 16 2 9 2
Mediana 14.00 2.00 7.50 2.00Media 13.22 1.77 7.38 2.00
A Figura 6.2 apresenta, graficamente, a distribuicao do tempo despendido de acordo
com os participantes e as abordagens adotadas. Pode-se visualizar que, a adocao da
abordagem ad hoc consumiu um tempo maior para a realizacao das tarefas quando
comparada a adocao da abordagem DiSEN-CollaborAR.
105
Figura 6.2: Tempo despendido para a realizacao das tarefas por participante e aborda-gem
A estatıstica descritiva proporcionou uma visao geral sobre os dados obtidos, tanto em
termos do que podia-se esperar do teste de hipoteses, quanto possıveis problemas causados
por outliers, os quais sao apresentados abaixo.
6.5.2 Analise de Outliers
Para a avaliacao das variaveis quantitativas – tempo despendido para a realizacao das
atividades e numero de artefatos identificados corretamente, foi realizada a analise de
outlier. Valores extremos – ou outliers – sao valores observados que estao muito distantes
no conjunto de valores (Araujo e Travassos, 2009). Assim, e importante verificar as origens
de cada outlier, pois eles podem ser efetivamente observacoes validas e que deveriam ser
consideradas no universo de estudo.
Analise da variavel Tempo Despendido. Aplicando-se a analise de outlier, observa-se
que nenhum participante e avaliado como sendo um outlier na avaliacao do tempo
despendido para a realizacao das atividades por abordagem – Figura 6.3. Sendo assim,
nenhum participante foi excluıdo para a analise da variavel tempo despendido.
106
Figura 6.3: Analise de outlier para a variavel Tempo Despendido
Analise da variavel Numero de Artefatos. Aplicando-se a analise de outlier,
observa-se que ha um outlier na avaliacao do numero de artefatos identificados correta-
mente por abordagem – Figura 6.4. Assim, para tal figura e importante observar os valores
extremos quando se compara as duas abordagens. Para a abordagem DiSEN-CollaborAR
nao ha outliers. Entretanto, para a abordagem ad hoc, ha um outlier, 0.0. E um valor
extremo, entretanto nao foi removido para a analise a seguir, pois e uma observacao valida
que pode influenciar sobre os resultados dos testes estatısticos.
107
Figura 6.4: Analise de outlier para a variavel Numero de Artefatos
6.5.3 Teste de Hipoteses
Primeiramente, foi realizado o teste de normalidade por meio do Teste de Shapiro-Wilk.
O Teste de Shapiro-Wilk e o mais indicado para identificar normalidade em variaveis com
menos de 50 valores (Araujo e Travassos, 2009). No caso deste estudo experimental, sao
36 valores. A Tabela 6.6 apresenta os resultados do teste para as variaveis.
Tabela 6.6: Resultados do teste de normalidade Shapiro-Wilk
Variavel W p-valueTempo despendido 0.9101 0.006509 Distribuicao nao normal
(p-value < 0.05)Numero de artefatos 0.2455 0.000000000002090 Distribuicao nao normal
(p-value < 0.05)
Para a variavel tempo despendido, verificou-se que a distribuicao dos dados era nao
normal, pois o valor de p-value 0.006509 e menor que o valor indicado para distribuicao
108
normal deste metodo que e 0.05. Dessa forma, para esta variavel no teste de hipotese foi
utilizado o metodo nao parametrico Kruskal-Wallis.
Para a variavel numero de artefatos, verificou-se que a distribuicao dos dados era nao
normal, pois o valor de p-value 0.000000000002090 e menor que o valor indicado para
distribuicao normal deste metodo que e 0.05. Dessa forma, para esta variavel no teste de
hipotese foi utilizado o metodo nao parametrico Kruskal-Wallis.
A seguir sao apresentados os testes de hipotese para as variaveis tempo despendido e
numero de artefatos utilizando o metodo nao parametrico Kruskal-Wallis.
Teste de hipotese da variavel Tempo Despendido. Aplicando-se o metodo es-
tatıstico nao parametrico Kruskal-Wallis percebe-se que existe diferenca estatıstica na
adocao da abordagem DiSEN-CollaborAR se comparada a abordagem ad hoc, como pode
ser observado pelo p-value que ficou em 0.000004626, inferior ao valor 0.05 – Tabela 6.7.
Tabela 6.7: Resultados do teste de hipotese Kruskal-Wallis
Dados Graus de liberdade (df) p-valueTempo por abordagem 1 0.000004626
A hipotese nula e que o tempo por abordagem sao populacoes identicas. Aplicando o
metodo Kruskal-Wallis para comparar os dados independentes, o p-value e quase zero
(0.000004626) (i.e. p-value < 0.05). Sendo assim, ao nıvel de significancia de 0.05,
rejeitamos a hipotese nula e podemos concluir que o tempo por abordagem sao
populacoes nao identicas.
Teste de hipotese da variavel Numero de Artefatos. Aplicando-se o metodo
estatıstico nao parametrico Kruskal-Wallis percebe-se que nao existe diferenca estatıstica
na adocao da abordagem DiSEN-CollaborAR se comparada a abordagem ad hoc, como
pode ser observado pelo p-value que ficou em 0.1513, superior ao valor 0.05 – Tabela 6.8.
Tabela 6.8: Resultados do teste de hipotese Kruskal-Wallis
Dados Graus de liberdade (df) p-valueNumero de artefatos por abordagem 1 0.1513
A hipotese nula e que o numero de artefatos por abordagem sao populacoes identicas.
Aplicando o metodo Kruskal-Wallis para comparar os dados independentes, o p-value e
109
0.1513 (i.e. p-value > 0.05). Sendo assim, ao nıvel de significancia de 0.05, aceitamos
a hipotese nula e podemos concluir que o numero de artefatos por abordagem sao
populacoes identicas.
6.5.4 Analise Qualitativa
As questoes Q4, Q5 e Q6, da Secao 6.2, nao apresentam as respectivas hipoteses e, em
consequencia, nao apresentam teste de hipoteses. Isso deve-se ao fato de que, tais questoes
possuem respostas baseadas na opiniao dos participantes do experimento. Assim, essas
questoes devem ser avaliadas por meio de uma analise qualitativa sobre a abordagem
DiSEN-CollaborAR. Dessa forma, o objetivo desta analise e identificar se a adocao da
abordagem DiSEN-CollaborAR: (1) apresenta indicacoes que o grau de complexidade na
realizacao das tarefas e reduzida, (2) apresenta indicacoes que as informacoes contextuais
apresentadas sao suficientes, e (3) apresenta indicacoes que a rastreabilidade entre os
artefatos de software e util para a percepcao de contexto.
Para realizar esta analise foram consideradas as respostas dos participantes no ques-
tionario de avaliacao (Doc6 no Apendice A) entregue ao final da execucao do experimento.
Esse aspecto foi avaliado informalmente, examinando as opinioes de cada participante.
Sendo assim, essas questoes nao foram consideradas como hipoteses por estarem relaciona-
das a uma analise qualitativa. No total, foram entregues 18 formularios preenchidos com a
avaliacao qualitativa sobre a abordagem. A seguir sao apresentadas as perguntas presentes
no formulario e as respostas que retratam a adocao da abordagem DiSEN-CollaborAR.
A adocao da abordagem DiSEN-CollaborAR reduz o grau de complexidade
na realizacao das tarefas pelos participantes. Quando questionados sobre a
complexidade na realizacao das tarefas adotando a abordagem ad hoc, 11.1% consideraram
muito complexo, 22.2% consideraram complexo, 55.6% consideraram simples e 11.1%
consideraram muito simples. Quando questionados sobre a complexidade na realizacao
das tarefas adotando a abordagem DiSEN-CollaborAR, nenhum considerou muito com-
plexo, 5.5% consideraram complexo, 61.2% consideraram simples e 33.3% consideraram
muito simples. Generalizando, 94.5% consideram simples ou muito simples o grau de
complexidade na realizacao das tarefas adotando a abordagem DiSEN-CollaborAR. Dessa
forma, verifica-se que a adocao de DiSEN-CollaborAR reduz o grau de complexidade na
realizacao das tarefas pelos participantes.
110
As informacoes contextuais sobre os artefatos de software apresentadas sao
suficientes para a percepcao do indivıduo. Quando questionados se as informacoes
contextuais sobre os artefatos de software adotando a abordagem DiSEN-CollaborAR
eram suficientes, 88.9% indicaram sim e 11.1% indicaram parcialmente. Dessa forma,
verifica-se que as informacoes contextuais sobre os artefatos de software apresentadas
pela abordagem DiSEN-CollaborAR sao suficientes.
A rastreabilidade entre os artefatos de software e util para a percepcao de
contexto. Quando questionados se a rastreabilidade entre os artefatos de software
adotando a abordagem DiSEN-CollaborAR era util, 100% indicaram sim. Dessa forma,
verifica-se que, com a adocao de DiSEN-CollaborAR, a rastreabilidade entre os artefatos
de software e util para a percepcao de contexto sobre os mesmos.
6.6 Discussao
Em relacao as hipoteses, apresentadas na Secao 6.3.1, a hipotese nula (H0) foi refutada, a
hipotese alternativa (H1) foi aceita e a hipotese alternativa (H2) foi refutada. De acordo
com o teste de hipoteses – Secao 6.5.3, a adocao da abordagem DiSEN-CollaborAR reduz
o tempo despendido para a realizacao das atividades, mas nao aumenta o numero de
artefatos identificados corretamente. Mais detalhes sao apresentados a seguir.
Os resultados apresentados na Secao 6.5.3 sugerem que a abordagem DiSEN-CollaborAR
influencia diretamente no tempo despendido para a realizacao das tarefas. Assim, a adocao
de DiSEN-CollaborAR durante o experimento apresentou resultados positivos em relacao
a adocao da abordagem ad hoc. Sendo assim, a hipotese alternativa (H1) foi aceita:
Hipotese alternativa (H1): A adocao do DiSEN-CollaborAR reduz o esforco durante
as atividades de desenvolvimento de software com equipes distribuıdas se comparada a
adocao de uma abordagem ad hoc.
Os resultados apresentados na Secao 6.5.3 sugerem que a abordagem DiSEN-CollaborAR
nao influencia no numero de artefatos identificados corretamente em relacao a adocao
da abordagem ad hoc. De uma forma geral, analisando-se a Tabela 6.5, verifica-se que
adotando a abordagem DiSEN-CollaborAR a media do numero de artefatos identificados
corretamente e maior. Entretanto, estatisticamente nao ha diferenca na comparacao entre
as duas abordagens. Sendo assim, a hipotese alternativa (H2) foi refutada:
Hipotese alternativa (H2): A adocao do DiSEN-CollaborAR aumenta a quantidade de
artefatos identificados corretamente durante as atividades de desenvolvimento de software
com equipes distribuıdas se comparada a adocao de uma abordagem ad hoc.
111
A hipotese nula (H0) e uma conjuncao logica relacionada a interseccao de dois
conjuntos, neste caso o tempo despendido e o numero de artefatos. Na primeira
situacao, H01 diz que nao ha diferenca no tempo despendido para a realizacao das
atividades, independente da abordagem adotada. Na segunda situacao, H02 diz que
nao ha diferenca na quantidade de artefatos identificados corretamente, independente da
abordagem adotada. Assim, H0 so e verdadeira se ambas situacoes – H01 e H02 – forem
verdadeiras.
Conforme discutido anteriormente, a abordagem DiSEN-CollaborAR influencia dire-
tamente no tempo despendido para a realizacao das tarefas, mas nao influencia no numero
de artefatos identificados corretamente em relacao a adocao da abordagem ad hoc. Nesse
caso, H01 e falsa e H02 e verdadeira. Sendo assim, a hipotese nula (H0) foi refutada:
Hipotese nula (H0): A adocao da abordagem DiSEN-CollaborAR nao aumenta a per-
cepcao de contexto sobre os artefatos de software pelos membros das equipes distribuıdas
quando comparada a adocao de uma abordagem ad hoc.
De uma forma geral, a abordagem DiSEN-CollaborAR proporcionou um aumento
da percepcao de contexto sobre os artefatos de software durante a operacao do ex-
perimento. Embora, estatisticamente, a DiSEN-CollaborAR nao tenha aumentado o
numero de artefatos identificados corretamente durante as atividades, houve a reducao
do esforco em relacao ao tempo despendido durante a realizacao as atividades adotando
a DiSEN-CollaborAR.
Algumas sugestoes, para aperfeicoar a abordagem e o prototipo, foram realizadas pelos
participantes do experimento. Entre as sugestoes dos participantes, pode-se citar:
• Adicionar um filtro para selecionar os artefatos de software de acordo com algum
criterio;
• Atualizar o grafo automaticamente e em tempo real;
• Abrir o artefato de software a partir de um clique sobre o vertice do grafo;
• Utilizar o proprio ambiente de desenvolvimento, tal como IDE e Ferramenta CASE
UML, para apresentar as informacoes;
• Inserir um mecanismo que altere automaticamente o codigo fonte com base no
diagrama de classes associado, e vice-versa.
Algumas limitacoes quanto a tecnologia relacionada a Ontologia e restricoes de acesso
a rede interna das universidades, dificultaram que alguns recursos pudessem ser utilizados.
Por exemplo, os grupos – A e B – nao puderam realizar simultaneamente as atividades
112
em virtude das restricoes existentes sobre a Ontologia (ver Secao 7.3 do Capıtulo 7).
Dessa forma, os integrantes de um grupo nao puderam visualizar os artefatos produzidos
e/ou modificados pelo outro grupo e, tambem, realizar comunicacao direta com outros
participantes por meio do prototipo ACAS. Sendo assim, o aumento da percepcao
de contexto sobre os artefatos de software pelos participantes, verificado por meio do
experimento, apresenta apenas indıcios que a abordagem pode melhorar, tambem, a
colaboracao, a comunicacao e a coordenacao.
Este estudo experimental foi um primeiro passo para uma avaliacao mais completa
sobre a abordagem apresentada nesta dissertacao. O experimento e limitado em diversos
aspectos, conforme descrito anteriormente, restringindo a generalizacao dos resultados
obtidos. Sendo assim, a abordagem e o prototipo podem ser aperfeicoados em diversos
pontos – aqueles relacionados as limitacoes, para que estudos experimentais adicionais
possam ser realizados e, dessa forma, avaliar plenamente a abordagem proposta.
6.7 Licoes Aprendidas
Com a finalizacao deste estudo experimental, algumas informacoes podem ser usadas
como um guia para replicacoes futuras. Entretanto, alguns aspectos importantes devem
ser considerados, especialmente aqueles relacionados as limitacoes deste experimento. As
impressoes gerais obtidas a partir do experimento sao descritas abaixo.
Indivıduos. Sobre o perfil dos participantes, conforme apresentado na Tabela 6.3, de
uma forma geral, 10 nao tinham conhecimento em DDS, 5 nao tinham conhecimento
em Sistema de Controle de Versao, 1 nao tinha conhecimento em Ferramenta CASE
UML e todos tinham algum conhecimento em Java e UML. A selecao de todos os
indivıduos sem experiencia ou sem conhecimento sobre todos esses itens, poderia tornar
o experimento custoso. Nesse sentido, varios problemas foram evitados porque varios
indivıduos selecionados apresentavam alguma experiencia em alguns dos itens citados
anteriormente.
Formacao. Poucos indivıduos selecionados tinham experiencia na industria. Assim,
para tentar reduzir o problema de falta de experiencia, foram selecionados indivıduos que
tinham desenvolvido pesquisa ou participado de projetos na academia.
Projeto. Como este experimento compreendeu dois tipos de artefatos de software –
codigo fonte e diagrama de classes, foi necessario que alguns artefatos abordassem carac-
terısticas especıficas, tais como a semelhanca entre o nome da classe, variaveis e atributos,
metodos e operacoes, a fim de analisar a contribuicao da abordagem DiSEN-CollaborAR.
113
Assim, para este experimento foi elaborado e simulado um projeto especıfico para este
experimento.
Experimento Piloto. E necessario um experimento piloto antes de aplicar o experi-
mento real com os indivıduos, uma vez que problemas podem ser identificados e, assim, o
experimento precisa ser ajustado a fim de resolve-los. Por meio de um experimento piloto
foram identificados problemas na instrumentacao que poderiam tornar o experimento
inviavel, se nao fossem mitigados.
Motivacao. E difıcil manter a motivacao dos participantes, uma vez que a execucao
do experimento pode se tornar entediante. Nesse sentido, a motivacao foi baseada na
justificativa de que o DiSEN-CollaborAR e parte do projeto DiSEN (Huzita et al., 2007)
e, como um projeto academico que envolve varios pesquisadores, incluindo professores e
estudantes de graduacao e pos-graduacao, e importante valorizar a pesquisa, mesmo com
todas as limitacoes envolvidas para realiza-la.
6.8 Consideracoes Finais
Neste capıtulo foi apresentado um estudo experimental realizado para avaliar a abordagem
DiSEN-CollaborAR. O experimento foi realizado em quatro fases: (1) definicao, (2)
planejamento, (3) operacao e (4) analise e interpretacao.
Em ambientes caracterizados como DDS, a capacidade dos desenvolvedores traba-
lharem em conjunto e reduzida, afetando diretamente a produtividade e a qualidade do
desenvolvimento de software. Alem disso, os diferentes tipos de artefatos de software que
sao produzidos e/ou modificados durante o DDS, dificulta a percepcao pelos membros
das equipes distribuıdas sobre os artefatos de software, gerando ambiguidades e, em
consequencia, falhas ou incertezas durante o trabalho. Assim, a DiSEN-CollaborAR apoia
a percepcao de contexto sobre os artefatos de software, a fim de reduzir o esforco durante
a realizacao das atividades de desenvolvimento de software.
O objetivo deste estudo experimental foi avaliar os benefıcios da DiSEN-CollaborAR.
Por meio de um experimento controlado em laboratorio, os dados gerados pelas atividades
foram coletados e analisados. Alem disso, para apoiar a realizacao das atividades
e, consequentemente, ser possıvel a avaliacao da abordagem DiSEN-CollaborAR, foi
utilizado o prototipo ACAS.
Observou-se que a DiSEN-CollaborAR aumenta a percepcao de contexto sobre os
artefatos de software pelos indivıduos durante as atividades. Embora, estatisticamente,
a DiSEN-CollaborAR nao tenha aumentado o numero de artefatos identificados correta-
114
mente durante as atividades, houve a reducao do esforco durante as atividades adotando
tal abordagem.
Apesar de o estudo ser um experimento controlado, que apresentou um numero
reduzido de indivıduos (18), foram identificadas varias questoes para a melhoria da
abordagem DiSEN-CollaborAR e, consequentemente, do prototipo ACAS, especialmente
a respeito das dificuldades dos indivıduos. Assim, essas sugestoes e observacoes serao
tratadas em trabalhos futuros.
E senso comum que e necessario um experimento na industria para validar a abordagem
em um cenario real. Entretanto, isso pode ser inserido como pesquisa futura, uma
vez que deve-se encontrar uma empresa que concorde em fornecer seus dados sobre o
desenvolvimento de software para analise. Um projeto industrial e relevante, pois envolve
aspectos reais do desenvolvimento de software e, assim, seria interessante verificar o
comportamento da abordagem DiSEN-CollaborAR em tal cenario.
As licoes aprendidas apresentadas neste trabalho devem ser consideradas para evitar
que as mesmas dificuldades sejam repetidas em outros projetos. No proximo capıtulo
sao apresentadas as conclusoes, assim como as principais contribuicoes e limitacoes desta
dissertacao e sugestoes de trabalhos futuros.
115
Capıtulo
7
Conclusoes
7.1 Consideracoes Finais
As tarefas e os projetos cada vez mais complexos e os prazos de execucao cada vez
menores tem incentivado as organizacoes a substituirem o esforco individual pelo trabalho
envolvendo equipes que executam atividades colaborativas. Assim, em busca de vantagem
competitiva e cooperacao, diversas organizacoes adotaram atividades multilocais, multi-
culturais e, algumas vezes, globalmente distribuıdas, buscando aumentar a produtividade,
melhorias na qualidade do produto e a reducao de custos (Audy e Prikladnicki, 2007;
Huzita et al., 2008).
Tal estrategia de desenvolvimento – DDS – tem causado impacto nos canais de
comunicacao e na capacidade dos desenvolvedores trabalharem em conjunto em ambientes
distribuıdos (Herbsleb e Moitra, 2001). Devido a tais limitacoes, os membros das equipes
distribuıdas compartilham pouca informacao contextual e tem pouco conhecimento sobre
o que os outros indivıduos fazem em relacao ao trabalho colaborativo (Herbsleb, 2007).
Dessa forma, a comunicacao e reduzida e, consequentemente, afeta a produtividade e a
qualidade do desenvolvimento de software (Jimenez et al., 2010).
Durante o desenvolvimento de software com equipes distribuıdas, varios artefatos de
software sao produzidos e/ou modificados, envolvendo circunstancias tais como o usuario
que manipulou o artefato, a ferramenta utilizada ou a data em que o evento ocorreu.
Assim, o contexto sobre os artefatos de software devem ser percebidos pelos membros das
equipes distribuıdas, pois essa percepcao pode auxiliar o indivıduo a evitar ambiguidades
116
e, em consequencia, nao provocar falhas ou incertezas durante o seu trabalho. Alem disso,
perceber as acoes uns dos outros pode facilitar a compreensao e diminuir as barreiras da
comunicacao impostas pela distancia geografica (Chaves, 2009).
Diante de tal cenario, o objetivo deste trabalho foi apresentar uma abordagem para
percepcao de contexto sobre artefatos de software para apoiar o desenvolvimento de
software com equipes distribuıdas. A abordagem foi elaborada com o intuito de oferecer
apoio para a disseminacao de informacoes acerca dos artefatos de software e, dessa forma,
contribuir para melhorar a comunicacao e a coordenacao entre as equipes distribuıdas e
reduzir as ambiguidades nos artefatos de software.
A partir da analise dos trabalhos relacionados, apresentados no Capıtulo 3, e da rea-
lizacao de uma revisao sistematica, apresentada em Vivian et al. (2011), pode-se identificar
alguns aspectos nos trabalhos encontrados na literatura: fonte de informacao, tipo de
artefato, tipo de informacao, analise das informacoes, apresentacao das informacoes e
local de apresentacao. Entretanto, alguns pontos recorrentes sobre os trabalhos foram
destacados: (i) outras fontes para a captura de informacoes contextuais sobre os artefatos
de software, alem de SCV; (ii) outros tipos de artefatos de software para contribuir com
informacoes contextuais; e (iii) relacoes de dependencias entre os artefatos de software,
geradas automaticamente.
Com base nas lacunas identificadas foi elaborada uma abordagem para percepcao de
contexto sobre artefatos de software. A abordagem DiSEN-CollaborAR abrange uma serie
de caracterısticas que a diferencia dos trabalhos relacionados, apresentados no Capıtulo
3. Primeiramente, alem de fornecer apoio para dois tipos de artefatos de software –
codigo fonte e diagrama de classes, a abordagem explora algumas informacoes contextuais
que definem as circunstancias do momento que um artefato de software foi produzido
ou modificado. Por exemplo, informacoes contextuais como versao, data, ferramenta,
autor, equipe, localizacao, entre outras. Alem disso, sao apresentadas informacoes sobre
a estrutura do artefato de software: (1) classe, variaveis e metodos, quando se trata de
codigo fonte; e (2) nome da classe, atributos e operacoes, quando se trata de diagrama de
classes.
A abordagem fornece recursos para a captura, representacao, armazenamento, pro-
cessamento e apresentacao de informacoes contextuais sobre os artefatos de software,
fundamentada em quatro estruturas: Workspace, Repositorio Compartilhado, Mecanismo
e Componente Visual. Assim, as caracterısticas que constituem-se em pilares que sus-
tentam a abordagem DiSEN-CollaborAR sao: (i) oferecer elementos de percepcao e
contexto de artefato que aumentam o entendimento sobre os artefatos de software em
um trabalho colaborativo tal como o DDS; (ii) permitir a representacao semantica de
117
informacoes contextuais sobre os artefatos de software por meio de uma ontologia; (iii)
estabelecer relacoes de dependencias entre os artefatos de software com base na ontologia,
de acordo com a informacao estrutural e semantica encontradas nos proprios artefatos;
(iv) gerar vınculos de rastreabilidade entre os artefatos de software, tais como codigo fonte
e diagrama de classes; e (v) apresentar informacoes contextuais por meio de grafos que
permitem a percepcao visual.
Um prototipo, chamado ACAS, foi implementado com o intuito de apoiar a abordagem
DiSEN-CollaborAR. Por meio da implementacao do prototipo, verificou-se as funciona-
lidades da infraestrutura em prover informacoes contextuais pertinentes aos artefatos
de software. Foi realizado um estudo experimental em quatro fases: (1) definicao, (2)
planejamento, (3) operacao e (4) analise e interpretacao dos dados. Assim, o prototipo
implementado foi utilizado no estudo experimental para apoiar a realizacao das atividades
e, consequentemente, ser possıvel a avaliacao da abordagem DiSEN-CollaborAR. Por
meio de um experimento controlado em laboratorio, os dados foram coletados e anali-
sados. Alem disso, foram identificadas varias questoes para a melhoria da abordagem
DiSEN-CollaborAR e, consequentemente, do prototipo ACAS.
Ao final desta dissertacao conclui-se que, apesar de restrito, o estudo experimental
indicou que a DiSEN-CollaborAR aumenta a percepcao de contexto sobre os artefatos de
software pelos indivıduos durante as atividades. Embora, estatisticamente, tal abordagem
nao tenha aumentado o numero de artefatos identificados corretamente durante as
atividades, houve a reducao do esforco durante as atividades. Espera-se que no futuro
esta abordagem possa ser adotada pela industria em projetos com equipes distribuıdas e
servir como um meio para reduzir as dificuldades encontradas em DDS provocadas pelas
distancias geografica e temporal.
Neste ultimo capıtulo, na Secao 7.2 sao destacadas as principais contribuicoes, na
Secao 7.3 sao apresentadas as limitacoes deste trabalho e na Secao 7.4 sao identificados
os trabalhos futuros. Por fim, na Secao 7.5 sao citadas as publicacoes relacionadas a este
trabalho.
7.2 Contribuicoes
Como contribuicoes deste trabalho, pode-se destacar:
• Compara diferentes ferramentas, descritas na literatura, que apresentam tecnicas
para capturar e apresentar informacoes contextuais sobre os artefatos de software
118
gerados no desenvolvimento distribuıdo de software, destacando os pontos positivos,
negativos e comuns entre tais ferramentas.
• Especifica uma abordagem, denominada DiSEN-CollaborAR, que proporciona uma
infraestrutura para aumentar a percepcao dos membros das equipes distribuıdas
quando se trata de artefatos de software que sao produzidos e/ou modificados du-
rante o DDS, contribuindo para reduzir os problemas de comunicacao e coordenacao
e, assim, reduzir o esforco durante a realizacao das atividades de desenvolvimento
de software.
• Oferece solucoes para lidar com os problemas comumente encontrados nos trabalhos
descritos na literatura, destacando-se: (i) a representacao semantica das informacoes
contextuais sobre os artefatos de software por meio de uma ontologia; (ii) a geracao
automatica das relacoes de dependencias entre os artefatos de software com base
em uma ontologia, de acordo com a informacao estrutural e semantica encontradas
nos proprios artefatos; (iii) a associacao de vınculos de rastreabilidade entre tipos
diferentes de artefatos de software – codigo fonte e diagrama de classes; e (iv) a
apresentacao de informacoes contextuais sobre os artefatos de software na forma
textual e por meio de grafos que permitem a percepcao visual.
• Oferece um prototipo, chamado ACAS, que apoia a abordagem DiSEN-CollaborAR,
auxiliando os indivıduos durante o desenvolvimento distribuıdo de software.
• Apresenta uma avaliacao da abordagem DiSEN-CollaborAR a partir do prototipo
implementado, por meio de um estudo experimental controlado em laboratorio –
com base na Engenharia de Software Experimental. Os resultados obtidos no estudo
experimental serao utilizados para melhorar o prototipo e servirao como base para
uma avaliacao futura, e mais completa, sobre a abordagem.
7.3 Limitacoes
Como limitacoes deste trabalho, pode-se destacar:
• Diversos autores (Gutwin et al., 2004; Kantor e Redmiles, 2001; Tran et al., 2006)
tratam a percepcao de contexto sobre o projeto e o ambiente como um todo.
Entretanto, a percepcao de contexto, discutida neste trabalho, explora apenas
as informacoes contextuais no escopo dos artefatos de software, produzidos e/ou
modificados durante o ciclo de vida de um projeto distribuıdo.
119
• Dentre os varios artefatos de software que podem existir (Cleland-Huang et al.,
2003), para o escopo da abordagem apresentada neste trabalho, foram considerados
apenas codigo fonte e diagrama de classes, conforme justificado na Secao 4.2. Alem
disso, o prototipo ACAS oferece apoio apenas para codigo fonte em linguagem Java.
• O prototipo ACAS nao foi implementado com todas as informacoes contextuais
definidas pela abordagem DiSEN-CollaborAR. Tal fato, deve-se ao motivo de que,
alguns elementos contextuais, que formam o contexto de artefato, precisam ser
capturados a partir de outras ferramentas, alem daquelas definidas pela abordagem
– Sistema de Controle de Versao e Ferramenta CASE UML.
• Houve algumas limitacoes quanto a tecnologia relacionada a Ontologia que afetaram
no funcionamento do prototipo ACAS. No momento da implementacao do ACAS,
nao havia, ainda, um mecanismo consolidado para o controle de concorrencia a
ontologias, tal como em um Sistema Gerenciador de Banco de Dados. Tecnologias a
respeito estao em desenvolvimento, inclusive por outros trabalhos dos membros do
grupo de pesquisa em Engenharia de Software Colaborativa do DIN-UEM, para ofe-
recer apoio a tal questao. Assim, tal fato afetou no funcionamento do processamento
das informacoes contextuais no prototipo implementado, pois o mesmo utilizou um
mecanismo que estendia o framework DiSEN Agency proposto por Monte-Alto et al.
(2012), conforme apresentado no Capıtulo 5, para realizar o processo de inferencia.
Dessa forma, tal mecanismo possui limitacoes quanto ao acesso concorrente e, no
momento, nao oferece apoio total a questao citada anteriormente. Isso e um fator
importante a ser considerado em um cenario com equipes distribuıdas, uma vez
que varios indivıduos realizam atividades simultaneamente. Assim, e necessario
controlar o acesso e a atualizacao concorrente (operacoes simultaneas) a base de
conhecimento, de modo a nao gerar inconsistencias.
• O numero de participantes – 18 – no estudo experimental foi reduzido e contou ape-
nas com a participacao de estudantes de graduacao e pos-graduacao em Ciencia da
Computacao, pois foi realizado um estudo experimental controlado em laboratorio
na academia. Um estudo experimental na industria e com um numero maior de
participantes poderia validar definitivamente a abordagem em um cenario real de
projetos com equipes distribuıdas.
120
7.4 Trabalhos Futuros
Com base nas limitacoes apresentadas e para propiciar continuidade as atividades realiza-
das neste trabalho, foram identificadas algumas sugestoes de trabalhos futuros, as quais
estao alem do escopo desta dissertacao:
• Explorar outras fontes de informacao pois diversas ferramentas podem gerar ar-
tefatos durante o ciclo de desenvolvimento de software. Tais ferramentas sao:
forum de discussao, wiki, sistema de controle de modificacoes (bug tracking system),
sistema de integracao contınua e ferramentas de teste de software. Por exemplo, um
sistema de controle de modificacoes gera artefatos do tipo relatorio de defeitos que
poderiam ser relacionados a artefatos do tipo codigo fonte, aumentado a percepcao
dos desenvolvedores sobre o porque das alteracoes realizadas em um determinado
codigo fonte.
• Contemplar outros tipos de artefatos de software tais como diagrama de caso de uso,
de sequencia e de pacote, documentos de requisitos e de validacao e descricao da
arquitetura do sistema, alem de apoiar outras linguagens de programacao. Alem
disso, relacionar outros elementos que fazem parte da estrutura do artefato de
software tais como pacotes, interfaces, componentes, comentarios, constantes e
estereotipos.
• Incorporar um mecanismo de filtro de informacoes no prototipo. Devido ao grande
volume de informacoes que podem ser geradas sobre os artefatos de software,
seria importante que um indivıduo pudesse selecionar apenas as informacoes que
cumprissem algum criterio, por exemplo, os artefatos gerados ou alterados em um
determinado momento ou por um certo indivıduo.
• Implementar, especificamente, no ACAS a captura de todo o historico de alteracoes
no SCV, pois, no momento, tal prototipo captura informacoes sobre o codigo fonte
apenas quando o desenvolvedor realiza um commit no SCV.
• Identificar redes sociotecnicas a partir dos artefatos de software. Os membros das
equipes distribuıdas em um projeto de software estao conectados por meio de arte-
fatos de software inter-relacionados, formando uma rede social de desenvolvedores.
Essas redes podem revelar padroes de colaboracao e comunicacao que influenciam
a percepcao dos indivıduos. Redes sociotecnicas foram exploradas em de Souza
et al. (2004) a partir de apenas um tipo de artefato de software. Contudo, seria
121
interessante a geracao de redes sociotecnicas a partir de varios tipos de artefatos de
software.
• Realizar um estudo de caso na industria para determinar a viabilidade da abordagem
em um cenario real de um projeto com equipes distribuıdas.
• Integrar o prototipo ACAS ao ambiente DiSEN.
7.5 Publicacoes
No decorrer do mestrado foram publicados os seguintes artigos:
• VIVIAN, R.L.; HUZITA, E.H.M.; LEAL, G.C.L.; CHAVES, A.P. Context-awareness
on software artifacts in distributed software development: a systematic review. In:
Proceedings of the 17th Conference on Collaboration and Technology (CRIWG11),
Paraty, RJ, Brasil, 2011.
• VIVIAN, R.L.; HUZITA, E.H.M.; LEAL, G.C.L. Supporting distributed software
development through context awareness on software artifacts: the DiSEN-CollaborAR
approach. In: Proceedings of the 28th ACM Symposium On Applied Computing
(SAC13), Coimbra, Portugal, 2013 (to appear).
122
Referencias
de Alwis, B.; Sillito, J. Why are software projects moving from centralized
to decentralized version control systems? In: Proceedings of the ICSE Workshop on
Cooperative and Human Aspects on Software Engineering (CHASE09), IEEE Computer
Society, 2009, p. 36–39.
Araujo, M. A. P.; Travassos, G. H. A utilizacao de metodos estatısticos no
planejamento e analise de estudos experimentais em engenharia de software. Mini-curso
apresentado no VI Experimental Software Engineering Latin American Workshop (ESE-
LAW09), 2009.
Araujo, R. M.; Dias, M. S.; Borges, M. R. S. Suporte por computador ao
desenvolvimento cooperativo de software: classificacao e propostas. In: Proceedings of
the XI Simposio Brasileiro de Engenharia de Software (SBES97), 1997, p. 299–314.
Audy, J.; Prikladnicki, R. Desenvolvimento distribuıdo de software: desenvolvi-
mento de software com equipes distribuıdas. Rio de Janeiro: Editora Campus-Elsevier,
2007.
Aversano, L.; De Lucia, A.; Gaeta, M.; Ritrovato, P.; Stefanucci, S.;
Villani, M. L. Managing coordination and cooperation in distributed software
processes: the GENESIS environment. Software Process: Improvement and Practice,
v. 9, n. 4, p. 239–263, 2004.
Baader, F.; McGuinness, D. L.; Nardi, D.; Patel-Schneider, P. F. The
description logic handbook: theory, implementation, and applications. 2 ed. Cambridge
University Press, 2007.
Basili, V. R.; Caldeira, G.; Rombach, H. D. Goal question metric paradigm.
Encyclopedia of Software Engineering, v. 2, p. 527–532, 1994.
Bazire, M.; Brezillon, P. Understanding context before using it. Modeling and
Using Context, v. 3554, p. 113–192, 2005.
123
Belotti, R.; Decurtins, C.; Grossniklaus, M.; Norrie, M. C.; Palinginis, A.
Interplay of content and context. Web Engineering, v. 3140, p. 187–200, 2004.
Booch, G.; Rumbaugh, J.; Jacobson, I. UML: guia do usuario. 2 ed. Rio de
Janeiro: Editora Campus, 2005.
Bouquet, P.; Guidini, C.; Giunchiglia, F.; Blanzieri, E. Theories and uses of
context in knowledge representation and reasoning. Journal of Pragmatics, v. 35, n. 3,
p. 455–484, 2003.
Brezillon, P. Focusing on context in human-centered computing. IEEE Intelligent
Systems, v. 18, n. 3, p. 62–66, 2003.
Brezillon, P.; Pomerol, J. C. Contextual knowledge sharing and cooperation in
intelligent assistant systems. Le Travail Humain, v. 62, n. 3, p. 223–246, 1999.
Carmel, E. Global software teams: collaborating across borders and time zones. New
York: Prentice Hall, 1999.
Cataldo, M.; Wagstrom, P. A.; Herbsleb, J. D.; Carley, K. M. Identification
of coordination requirements: implications for the design of collaboration and awareness
tools. In: Proceedings of the 20th Conference on Computer Supported Cooperative Work
(CSCW06), ACM, 2006, p. 353–362.
Cataldo, M. B.; Bass, M.; Herbsleb, J. D.; Bass, L. On coordination mechanisms
in global software development. In: Proceedings of the International Conference on Global
Software Engineering (ICGSE07), IEEE Computer Society, 2007, p. 71–80.
Cepeda, R. S. V.; Magdaleno, A. M.; Murta, L. G. P.; Werner, C. M. L.
Evoltrack: improving design evolution awareness in software development. Journal of
the Brazilian Computer Society, v. 16, n. 2, p. 117–131, 2010.
Chaves, A. P. Um modelo baseado em context-awareness para um ambiente de
desenvolvimento distribuıdo de software. Dissertacao de Mestrado, Departamento de
Informatica - DIN, Universidade Estadual de Maringa - UEM, Maringa - Parana, 2009.
Chaves, A. P.; Steinmacher, I.; Leal, G. C. L.; Huzita, E. H. M.; Biasao,
A. B. OntoDiSENv1: an ontology to support global software development. CLEI
Electronic Journal, v. 14, n. 2, p. 1–12, 2011.
124
Chaves, A. P.; Steinmacher, I.; Vieira, V.; Moriya, E. H. M. A context
conceptual model for a distributed software development environment. In: Proceedings
of the International Conference on Software Engineering and Knowledge Engineering
(SEKE10), 2010, p. 437–442.
Cibotto, R. A. G.; Pagno, R. T.; Tait, T. F. C.; Huzita, E. H. M. Uma analise
da dimensao socio-cultural no desenvolvimento distribuıdo de software. In: Proceedings
of the V Workshop Um Olhar Sociotecnico sobre a Engenharia de Software (WOSES09),
2009, p. 96–107.
Cleland-Huang, J.; Chang, C. K.; Christensen, M. Event-based traceability
for managing evolutionary change. IEEE Transactions on Software Engineering, v. 29,
n. 9, p. 796–810, 2003.
Dey, A. K.; Abowd, G. D. Towards a better understanding of context and
context-awareness. In: Proceedings of the Workshop on the What, Who, Where, When,
and How of Context-Awareness (CHI00), 2000, p. 1–6.
Diehl, S. Software visualization: visualizing the structure, behaviour, and evolution of
software. New York: Springer-Verlag, 187 p., 2007.
Dourish, P.; Bellotti, V. Awareness and coordination in shared workspaces.
In: Proceedings of the ACM Conference on Computer-Supported Cooperative Work
(CSCW92), ACM, 1992, p. 107–114.
Eckhard, B. Context-aware notification in global software development. Dissertacao de
Mestrado, Institut fur Softwaretechnik und interaktive Systeme – Technischen Universitat
Wien, 2008.
Escobar, M.; Lemke, A.; Blois, M. SemantiCore 2006: permitindo o desenvol-
vimento de aplicacoes baseadas em agentes na web semantica. In: Proceedings of the
Second Workshop on Engineering for Agent-oriented Systems, 2006, p. 72–82.
Franklin, D. The representation of context: ideas from artificial intelligence. Law,
Probability and Risk, v. 2, n. 3, p. 191–199, 2003.
Froehlich, J.; Dourish, P. Unifying artifacts and activities in a visual tool for
distributed software development teams. In: Proceedings of the 26th International
Conference on Software Engineering (ICSE04), IEEE Computer Society, 2004, p. 387–396.
125
Gauvin, M.; Bourry-Brisset, A. C.; Auger, A. Context, ontology and portfolio:
key concepts for a situational awareness knowledge portal. In: Proceedings of the 37th
Hawaii International Conference on System Sciences (HICSS), IEEE Computer Society,
2004.
Gerosa, M. A.; Fuks, H.; de Lucena, C. J. P. Elementos de percepcao como forma
de facilitar a colaboracao em cursos via internet. In: Proceedings of the XII Simposio
Brasileiro de Informatica na Educacao (SBIE01), 2001, p. 115–124.
Gruber, T. R. A translation approach to portable ontology specifications. Knowledge
Acquisition, v. 5, n. 2, p. 199–220, 1993.
Guedes, G. T. A. UML 2 : uma abordagem pratica. Sao Paulo: Novatec Editora,
2009.
Gutwin, C.; Greenberg, S. A descriptive framework of workspace awareness for
real-time groupware. Computer Supported Cooperative Work, v. 11, n. 3, p. 411–446,
2002.
Gutwin, C.; Penner, R.; Schneider, K. Group awareness in distributed
software development. In: Proceedings of the ACM Conference on Computer Supported
Cooperative Work (CSCW04), ACM, 2004, p. 72–81.
Gutwin, C.; Schneider, K.; Paquette, D.; Penner, R. Supporting group awa-
reness in distributed software development. Engineering Human Computer Interaction
and Interactive Systems, p. 901–904, 2005.
Herbsleb, J. D. Global software engineering: The future of socio-technical coordina-
tion. In: Proceedings of the Future of Software Engineering (FOSE07), IEEE Computer
Society, 2007, p. 188–198.
Herbsleb, J. D.; Mockus, A.; Finholt, T. A.; Grinter, R. E. Distance,
dependencies, and delay in a global collaboration. In: Proceedings of the ACM Conference
on Computer Supported Cooperative Work (CSCW00), ACM, 2000, p. 319–328.
Herbsleb, J. D.; Moitra, D. Guest editor’s introduction: global software
development. IEEE Software, v. 18, n. 2, p. 16–20, 2001.
Huzita, E. H. M.; Silva, C. A.; Wiese, I. S.; Tait, T. F. C.; Quinaia, M.;
Schiavone, F. L. Um conjunto de solucoes para apoiar o desenvolvimento distribuıdo
126
de software. In: Proceedings of the II Workshop de Desenvolvimento Distribuıdo de
Software (WDDS08), 2008, p. 101–110.
Huzita, E. H. M.; Tait, T. F.; Colanzi, T. E.; Quinaia, M. A. Um ambiente
de desenvolvimento distribuıdo de software – DiSEN. In: Proceedings of the I Workshop
de Desenvolvimento Distribuıdo de Software (WDDS07), 2007, p. 31–38.
Ivcek, M.; Galinac, T. Aspects of quality assurance in global software development
organization. In: Proceedings of the 27th International Conference on Telecommunicati-
ons and Information of the 31th International Convention MIPRO, 2008, p. 150–155.
Jimenez, M.; Piattini, M.; A., V. Challenges and improvements in distributed
software development: a systematic review. Advances in Software Engineering, v. 2009,
n. 3, p. 1–14, 2009.
Jimenez, M.; Vizcaıno, A.; Piattini, M. Improving distributed software develop-
ment in small and medium enterprises. Open Software Engineering Journal, v. 4, n. 1,
p. 26–37, 2010.
Kantor, M.; Redmiles, D. Creating an infrastructure for ubiquitous awareness.
Eight IFIP TC, v. 13, p. 431–438, 2001.
Kitchenham, B. A. Guidelines for performing systematic literature reviews in software
engineering. Relatorio Tecnico, Keele University, UK, EBSE-2007-001, 2007.
Lahtinen, S.; Peltonen, J. Adding speech recognition support to UML tools.
Journal of Visual Languages and Computing, v. 16, n. 1, p. 85–118, 2005.
Lanubile, F.; Ebert, C.; Prikladnicki, R.; Vizcaıno, A. Collaboration tools for
global software engineering. IEEE Software, v. 27, n. 2, p. 52–55, 2010.
de Lucia, A.; Fasano, F.; Francese, R.; Oliveto, R. Traceability management
in ADAMS. In: Proceedings of the 1st International Workshop on Distributed Software
Development, 2005, p. 135–149.
Mockus, A.; Herbsleb, J. D. Challenges of global software development. In:
Proceedings of the 7th International Symposium on Software Metrics (METRICS01),
IEEE Computer Society, 2001, p. 182–184.
Molli, P.; Skaf-Molli, H.; Oster, G.; Jourdain, S. Sams: synchronous,
asynchronous, multi-synchronous environments. In: Proceedings of the 7th International
127
Conference on Computer Supported Cooperative Work in Design (CSCWD02), IEEE
Computer Society, 2002, p. 80–84.
Monte-Alto, H. H. L. C.; Biasao, A. B.; Teixeira, L. O.; Huzita, E. H. M.
Multi-agent applications in a context-aware global software development environment. In:
Proceedings of the 9th International Symposium on Distributed Computing and Artificial
Intelligence (DCAI12), Springer, 2012, p. 265–272.
Noll, J.; Beecham, S.; Richardson, I. Global software development and
collaboration: barriers and solutions. ACM Inroads, v. 1, n. 3, p. 66–78, 2010.
Noy, F. N.; McGuiness, D. L. Ontology development 101: a guide to creating your
first ontology. Relatorio Tecnico, Stanford University, KSL-01-05, Stanford Knowledge
Systems Laboratory, 2001.
Nunes, V. T.; Santoro, F. M.; Borges, M. R. S. Um modelo para gestao de
conhecimento baseado em contexto. In: Proceedings of the XXVII Simposio Brasileiro
de Sistemas Colaborativos (SBSC07), 2007, p. 1841–1854.
O’Madadhain, J.; Fisher, D.; White, D.; Boey, Y. The JUNG (java
universal network/graph) framework. Relatorio Tecnico, University of California, Irvine,
California, UCI-ICS Tech Report 03-17, 2003.
Omoronyia, I.; Ferguson, J.; Roper, M.; Wood, M. A review of awareness in
distributed collaborative software engineering. Software: Practice and Experience, v. 40,
n. 12, p. 1107–1133, 2010.
Paasivaara, M. Communication needs, practices and supporting structures in
global inter-organizational software development projects. In: Proceedings of the 3rd
International Workshop on Global Software Development (GSD04), 2004, p. 59–63.
Pinheiro, M. K.; Lima, J. V.; Borges, M. R. S. Awareness em sistemas de
groupware. In: Proceedings of the International Database Engineering and Applications
Symposium, 2001, p. 323–335.
Prikladnicki, R.; Audy, J. L. N. MuNDDos – um modelo de referencia para
desenvolvimento distribuıdo de software. In: Proceedings of the XVIII Simposio
Brasileiro de Engenharia de Software (SBES04), 2004, p. 289–304.
Prikladnicki, R.; Marczak, S.; Conte, T.; de Souza, C.; Audy, J. L. N.;
Kroll, J.; Marques, A. B.; Orsoletta, R. A. D. The evolution and impact of
128
the research in distributed software development in brazil. In: Proceedings of the 25th
Brazilian Symposium on Software Engineering (SBES11), IEEE Computer Society, 2011,
p. 126–131.
Rosa, M. G. P.; Borges, M. R. S.; Santoro, F. M. A conceptual framework for
analyzing the use of context in groupware. In: Proceedings of the 9th CRIWG Conference
on Collaboration and Technology (CRIWG03), Springer, 2003, p. 300–313.
Sahay, S. Global software alliances: the challenge of standardization. Scandinavian
Journal of Information Systems, v. 15, n. 1, p. 3–21, 2003.
Sangwan, R.; Bass, M.; Mullick, N.; Paulish, D. J.; Kazmeier, J. Global
software development handbook (auerbach series on applied software engineering series).
Boston: Auerbach Publications, 2006.
Sarma, A.; Noroozi, Z.; van der Hoek, A. Palantır: Raising awareness
among configuration management workspaces. In: Proceedings of the 25th International
Conference on Software Engineering (ICSE03), IEEE Computer Society, 2003, p. 444–454.
Sengupta, B.; Chandra, S.; Sinha, V. A research agenda for distributed
software development. In: Proceedings of the 28th Intertacional Conference on Software
Engeneering (ICSE06), ACM, 2006, p. 731–740.
da Silva, E. L.; Menezes, E. M. Metodologia da pesquisa e elaboracao de dissertacao.
Florianopolis: UFSC, 2005.
da Silva, F. Q. B.; Costa, C.; Franca, A. C. C.; Prikladinicki, R. Challenges
and solutions in distributed software development project management: a systematic
literature review. In: Proceedings of the International Conference on Global Software
Engineering (ICGSE10), IEEE Computer Society, 2010, p. 87–96.
Soares, P. H.; Huzita, E. H. M.; Tait, T. F. C. A strategy for treat with
socio-cultural aspects in software distributed development. In: Proceedings of the
14th International Conference on Enterprise Information Systems (ICEIS12), SciTePress,
2012, p. 156–159.
Sohlenkamp, M. Supporting group awareness in multi-user environment through
perceptualization. Dissertacao de Mestrado, Fachbereich Mathematik-Informatik der
Universitat – Gesamthochschule, 1998.
129
Solingen, R.; Berghout, E. The goal/question/metric method: a practical guide for
quality improvement of software development. UK: McGraw-Hill, 1999.
de Souza, C.; Dourish, P.; Redmiles, D.; Quirk, S.; Trainer, E. From technical
dependencies to social dependencies. In: Proceedings of the Workshop on Social Networks
for Design and Analysis: Using Network Information in CSCW, 2004.
Steinmacher, I.; Chaves, A. P.; Gerosa, M. A. Awareness support in distributed
software development: a systematic review and mapping of the literature. Computer
Supported Cooperative Work (CSCW), v. 21, p. 1–46, 2012.
Tran, M. H.; Raikundalia, G. K.; Yang, Y. Using an experimental study
to develop group awareness support for real-time distributed collaborative writing.
Information and Software Technology, v. 48, n. 11, p. 1006–1024, 2006.
Travassos, G. H.; Gurov, D.; do Amaral, E. A. G. Introducao a engenharia
de software experimental. Relatorio Tecnico, Programa de Engenharia de Sistemas e
Computacao COPPE - Universidade Federal do Rio de Janeiro, ES-590/02, 2002.
Trindade, D. F. G.; Tait, T. F. C.; Huzita, E. H. M. A tool for supporting the
communication in distributed software development environment. Journal of Computer
Science and Technology, v. 8, n. 2, p. 118–124, 2008.
Vieira, V. Gerenciamento de contexto em sistemas colaborativos. Qualificacao de
Doutorado, Centro de Informatica - CIn, Universidade Federal de Pernambuc - UFPE,
Recife - Pernambuco, 2006.
Vieira, V. CEManTIKA: a domain-independent framework for designing
context-sensitive system. Tese de Doutoramento, Centro de Informatica - CIn, Uni-
versidade Federal de Pernambuco - UFPE, Recife - Pernambuco, 2008.
Vieira, V.; Tedesco, P.; Salgado, A. C. Percepcao e contexto. In: Pimentel,
M.; Fucks, H., eds. Sistemas colaborativos, Rio de Janeiro: Elsevier, p. 157–172, 2011.
Vivian, R. L.; Huzita, E. H. M.; Leal, G. C. L.; Chaves, A. P.
Context-awareness on software artifacts in distributed software development: a systematic
review. In: Proceedings of the 17th CRIWG Conference on Collaboration and Technology
(CRIWG11), Springer, 2011, p. 30–44.
Whitehead, J. Collaboration in software engineering: a roadmap. Future of Software
Engineering, p. 214–225, 2007.
130
Wohlin, C.; Runeson, P.; Host, M.; Ohlsson, M.; Regnell, B.; Wesslen,
A. Experimentation in software engineering: an introduction. USA: Kluwer Academic
Publishers, 2000.
Xu, B.; LiGuo, H.; He, Z. On scoping stakeholders and artifacts in software process.
New Modeling Concepts for Todays Software Processes, v. 6195, p. 39–51, 2010.
Zhang, Y.; Witte, R.; Rilling, J.; Haarslev, V. Ontological approach for the
semantic recovery of traceability links between software artefacts. IET Software, v. 2,
n. 3, p. 185–203, 2008.
131
Apendice
A
Instrumentos do Estudo Experimental
A.1 Consideracoes Iniciais
Este apendice contem os documentos utilizados para a realizacao do estudo experimental
– Capıtulo 6 – de avaliacao da abordagem DiSEN-CollaborAR no que diz respeito a sua
viabilidade de aplicacao em ambientes de desenvolvimento distribuıdo de software. Tais
documentos sao apresentados obedecendo a seguinte ordem:
1. Termo de consentimento;
2. Questionario de caracterizacao do participante;
3. Documento apresentando o cenario;
4. Diagrama de classes do experimento;
5. Documento com lista das tarefas;
6. Questionario de avaliacao da abordagem DiSEN-CollaborAR.
132
133
134
135
136
137
138
139
140
141
142
143
144
Recommended