universidade estadual de maringa centro de …mestrado/diss/2013/vivian.pdf · das a˘c~oes que...

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


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


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.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.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


4 Abordagem DiSEN-CollaborAR 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


5 Arquitetura e Implementacao 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


6 Estudo Experimental 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


7 Conclusoes 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


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


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.


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


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.


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


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


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


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.


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


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.

universidade estadual de maringa centro de …mestrado/diss/2013/vivian.pdf · das a˘c~oes que...

Documents