TrabalhodeConclusodeCurso

CinciasdaComputao

Anliseempricacomparativaentre
mtricasdemodularidadeemodificaes
emcdigoduranteaevoluodesistemas
opensource

GabrieldeSouzaRolim
gabrielsrolim@gmail.com

Orientador:
EudisleyGomesdosAnjos

Marode2014

CentrodeInformtica
UniversidadeFederaldaParaba
Gabriel de Souza Rolim

Anlisecomparativaentremtricasde
modularidadeemodificaesemcdigo
duranteaevoluodesistemasopensource
Monografia apresentada ao curso Cincias da
Computao do Centro de Informtica, da
UniversidadeFederaldaParaba,comorequisito
paraaobtenodograudeBacharelemCincias
daComputao.
Orientador:EudisleyGomesdosAnjos

Marode2014

Fichacatalogrfica:elaboradapelabibliotecadoCI.
Serimpressanoversodafolhaderostoenodeversercontada.
<Senohouverbiblioteca,deixarembranco>

CentrodeInformtica
UniversidadeFederaldaParaba

TrabalhodeConclusodeCursodeCinciasdaComputaointituladoanlisecomparativa
entre mtricas de modularidade e modificaes em cdigo durante a evoluo de
sistemas open source de autoria de Gabriel de Souza Rolim, aprovada pela banca
examinadoraconstitudapelosseguintesprofessores:

_______________________________________________________________
Prof.Dr.<NomedoProfessor>
***instituio***
_______________________________________________________________
Prof.Dr.<NomedoProfessor>
***instituio***
_______________________________________________________________
Prof.Dr.<NomedoProfessor>
***instituio***

_______________________________________________________________
ChefedoDepartamento<NomedoDepartamento>
CI/UFPB

JooPessoa,20demarode2014

CentrodeInformtica,UniversidadeFederaldaParaba,JooPessoaParaba
CEP:58.051900Telefone:(83)32167093Faz:(83)32167117

DEDICATRIA
meu orientador, Eudisley Anjos, que sem sua ajuda e pacincia nada disso seria
possvel.
Aos meus pais, Manuel Junior e Elizabete Rolim, que me acompanhou em todas
as fases do meu curso.
minha av, Maria das Neves, que sempre me deu apoio.
minha maravilhosa namorada, Suamy Rabelo, que sem o seu apoio nos
momentos mais angustiantes eu no teria terminado esse Trabalho.
meu grande amigo, Ewerton Oliveira, que desde o comeo do curso esteve
sempre comigo sofrendo nos trabalhos em grupo e sempre dando aquele toque especial nos
texto dos trabalhos.

AGRADECIMENTOS
AgradeoprimeiramenteaDeusquesempreiluminouomeucaminho,medeuforase
sabedorianessalongacaminhada.
Atodososprofessoresquemeensinaramefizeramcomqueeumetornaseotimo
profissionalquesouhoje.
Agradeoportodasaspessoasquecruzaramomeucaminhoemederamforanessa
longacaminhada.

Amenosquemodifiquemosanossamaneirade
pensar,noseremoscapazesderesolveros
problemascausadospelaformacomonos
acostumamosaveromundo.(AlbertEinstein)

RESUMO

Nestetrabalhoverificoucomoasmtricasdemodularidadesecomportamatravsdotempocomo
acrscimodefuncionalidade,correesdebugsecolaboraodedesenvolvedores.Existemvrias
pesquisasnareaqueprocuramacharpadresdemtricasdesoftwareeoaparecimentodebugs.
Nestetrabalhoforamfeitasanalisesaolongodavidadossoftwaresafimdeverificarocomportamento
das correlaes existentes entre as mtricas e os dados mencionados. Verificamos atravs de
mineraoderepositrioeanalisesestatsticasdedadosqueosdadostemumagrandecorrelaopara
aalteraodosvaloresdasmtricasdesoftware.

Palavraschave:Mtricasdemodularidade,Mineraoderepositrios,bugs,Evoluodesoftware.

ABSTRACT

Thisworkverifiedhowthemetricsofmodularitybehaveovertimewiththeadditionoffunctionality,
bugfixesanddevelopercollaboration.Thereareseveralstudiesinthearealookingtofindpatternsof
softwaremetricsandtheappearanceofbugs.Thisworkanalyzesweremadethroughoutthelifeof
softwareinordertoverifythebehaviorofcorrelationsbetweenmetricsandtheinformationcontained
herein.Lookedthroughrepositoryminingandstatisticalanalysisofdatathatthedatahasahigh
correlationtothechangingvaluesofsoftwaremetrics.
Keywords:Metricsformodularity,Miningrepositories,bugs,softwareevolution.

LISTADEFIGURAS

FIGURA 1: DIAGRAMA DE CONTROLE DE VERSO LOCAL................................................................17

FIGURA 2: DIAGRAMA DE CONTROLE DE VERSO CENTRALIZADO.....................................................18
FIGURA 3: DIAGRAMA DE CONTROLE DE VERSO DISTRIBUDO........................................................19
FIGURA 4: DIRETRIO DE TRABALHO, REA DE PREPARAO, E O DIRETRIO DO GIT..........................21
FIGURA 5: GRAFOS DE FLUXOS DE CONTROLE DE UM PROGRAMA SIMPLES.........................................26
FIGURA 6: FORMULA DO COEFICIENTE DE CORRELAO DE PEARSON...............................................27
FIGURA 7: UMA FOTOGRAFIA SUPOSTAMENTE DO PRIMEIRO BUG (UM INSETO REAL) QUE FOI DEPURADO
("DEBUGADO") EM 1947. DA O SEU USO NOS DIAS ATUAIS....................................................29
FIGURA 8: PASSOS DO SCRIPT PYTHON PARA OBTENO DOS DADOS EM CADA COMMIT.......................34
FIGURA 9: EVOLUO DA CORREO DE BUGS TOMCAT................................................................36
FIGURA 10: EVOLUO DA QUANTIDADE DE DESENVOLVEDORES TOMCAT........................................36
FIGURA 11: EVOLUO DA QUANTIDADE DE FEATURES TOMCAT.....................................................37
FIGURA 12: EVOLUO DO VALOR DA METRICA DE CICLOS DE PACOTES TOMCAT...............................37
FIGURA 13: EVOLUO DA QUANTIDADE DE FUNES TOMCAT......................................................37
FIGURA 14: EVOLUO DA COMPLEXIDADE DE FUNO DE TOMCAT................................................38
FIGURA 15: EVOLUO DA COMPLEXIDADE CICLOMTICA DO TOMCAT.............................................38
FIGURA 16: EVOLUO DA QUANTIDADE DE FEATURES POI...........................................................39
FIGURA 17: EVOLUO DA CORREO DE BUGS POI...................................................................39
FIGURA 18: EVOLUO DA QUANTIDADE DE DESENVOLVEDORES POI..............................................40
FIGURA 19: EVOLUO DO VALOR DA METRICA CICLO DE PACOTE POI............................................40
FIGURA 20: EVOLUO DA QUANTIDADE DE FUNO POI.............................................................41
FIGURA 21: EVOLUO DA COMPLEXIDADE DE FUNO POI..........................................................41
FIGURA 22: EVOLUO DA COMPLEXIDADE CICLOMTICA POI........................................................42
FIGURA 23: EVOLUO DA QUANTIDADE CORREO JMETER.........................................................42
FIGURA 24: EVOLUO DA QUANTIDADES DESENVOLVEDORES JMETER.............................................43
FIGURA 25: EVOLUO DA QUANTIDADE DE FEATURES JMETER......................................................43
FIGURA 26: EVOLUO DO VALOR DA MTRICA CICLO DE PACOTE JMETER........................................43
FIGURA 27: EVOLUO DA QUANTIDADE DE FUNES JMETER.......................................................44
FIGURA 28: EVOLUO DA COMPLEXIDADE DE FUNO JMETER......................................................44
FIGURA 29: EVOLUO DA COMPLEXIDADE CICLOMTICA JMETER....................................................45
FIGURA 30: HISTORIO DA COMPLEXIDADE CICLOMTICA DO TOMCAT................................................48
FIGURA 31: EVOLUO DA CORREO DE BUGS X METRICA DE CICLOS DE PACOTE............................49
FIGURA 32: EVOLUO DA QUANTIDADE DE FEATURES X METRICAS DE CICLOS DE PACOTE..................49
FIGURA 33: EVOLUO DA QUANTIDADE DE DESENVOLVEDORES X METRICA DE CICLOS DE PACOTE.......50

LISTADETABELAS

TABELA
TABELA
TABELA
TABELA
TABELA
TABELA
TABELA
TABELA
TABELA

1:
2:
3:
4:
5:
6:
7:
8:
9:

CLASSIFICAO DOS VALORES DA CORRELAO DE PEARSON..........................................28

QUADRO COMPARATIVO ENTRE APLICAES DE ANLISE DE MTRICAS DE MODULARIDADE.....32
PERODO DE COMMITS ANALISADOS POR PROJETO.........................................................35
QUANTIDADE DE VERSES ANALISADAS.......................................................................35
CORRELAO DE PEARSON (BUG X MTRICAS)...........................................................45
CORRELAO DE PEARSON (DESENVOLVEDORES X MTRICAS)........................................46
CORRELAO DE PEARSON (FEATURE X MTRICAS)......................................................46
QUANTIDADE DE LINHAS.......................................................................................... 48
NDICE DE PEARSON............................................................................................... 49

LISTADEABREVIATURAS

SIGLA
OO
VCS
DVCS
OSD
MR
API
ADL
RFC
IDE

NOMECOMPLETO
OrientadoaObjeto
Version Control System
Distributed Version Control System
Open source definition
minerao de repositrios
Application Programming Interface
Linguagem de descrio de arquitetura
Reponse for classes
Integrated Development Environment

SUMRIO

INTRODUO............................................................................................

1.1

ESTRUTURADAMONOGRAFIA................................................................

TRABALHOSRELACIONADOS................................................................

REFERENCIALTERICO.........................................................................

3.1
3.1.1
3.1.2
3.1.3

CONTROLE DE VERSO...........................................................................
Controle de verso Local.............................................................................
Controle de verso centralizado..................................................................
Controle de verso distribudo.....................................................................

3.2

GIT...............................................................................................................

3.3

OPEN SOURCE SOFTWARE.....................................................................

3.4

MINERAO DE REPOSITRIOS.............................................................

3.5
3.5.1
3.5.2

MTRICAS DE MODULARIDADE..............................................................
Tamanho de Cdigo.....................................................................................
Estrutural......................................................................................................

3.6

CORRELAO DE PEARSON...................................................................

3.7
3.7.1

BUG..............................................................................................................
Tipos comuns de Bugs.................................................................................

METODOLOGIA.........................................................................................

APRESENTAOEANLISEDOSRESULTADOS.................................

5.1

EVOLUO DO TOMCAT...........................................................................

5.2

EVOLUO DO POI....................................................................................

5.3

EVOLUO JMETER..................................................................................

5.4

ESTUDO DA CORRELAO DE PEARSON DOS DADOS......................

CONCLUSESETRABALHOSFUTUROS...............................................

REFERNCIAS...........................................................................................................
ANEXOAGRFICOSEVOLUTIVOSDETODOSOSDADOS
COLETADOS...............................................................................................

INTRODUO

Inicialmente os sistemas computacionais eram desenvolvidos de forma

estrutural,semnenhumoupoucogerenciamento.Essessistemas, comopassardosanos,
tornarvamsecadavezmaisdifceisilecomplexosdesemanterse.Porisso,Eessessistemas,
aos poucos, comearam a introduzir um melhor gerenciamento melhor do projeto. ,
Pprogramas foram quebrados em mdulos, objetos, aspectos, etc. Com isso facilitou o
acrscimodenovasfeatures,modificaesemcdigo,correesdebugseassimfacilitando
tambmamanutenodessessistemas.
Emgrandesistemasnaturalqueapareamdificuldadesnoentendimentodos
problemas.Eparaissoadefiniodividirparaconquistarusadoemalgoritmosparaque
cadavezmaisosalgoritmossejammaissimplesefcildeseentender.Assimdiminuindoo
esforonamanutenodosistema.
Quantomaioronveldedivisodosmdulosdosistemamaiorseraqualidade
e a facilidade de manuteno. PortantoPensando nisso, a modularidade pode ser vistose
configura comoumimportanteatributodequalidade quedeveserlevadoemconsiderao
durante o desenvolvimento de sistemas. Para que seja avaliada, a modularidade possui
diversas mtricas de software que ajudam na determinaodo ne assim comoos outros
atributospodeseravaliadoatravsdemtricasdemodularidade.
QUANDOSEESCREVEUMTEXTO,DEVESETERCOESOENTREO
QUE EST FALANDO. POR EXEMPLO, SE VOC TERMINA AQUI FALANDO
SOBRE MTRICAS O PRXIMO PARGRAFO DEVE CONTINUAR SOBRE ISSO.
VOC PARA AQUI, FALA SOBRE OPENSOURCE, DEPOIS OUTRO PARGRAFO
SOBRE O DESENVOLVIMENTO DISTRIBUDO E DEPOIS VOLTA PARA
MTRICAS....NECESSRIOCOESOTEXTUALOUQUEMLNOENTENDEO
QUEVOCQUERDIZER.
Cadavezmaiscresceonmerodeprojetosondeoseucdigoabertopara
qualquerdesenvolvedor.Destaformaaevoluodocdigoeaqualidadedomesmoevoluem
muitorpido.EstetipodesoftwarechamadoOpenSource.
Essessistemassomantidosmuitasvezesporvriosdesenvolvedoresespalhados
pelo mundo. Utilizam para troca de informaes fruns, wiki, chats e emails. O que se
mostrameioseficientesdecomunicaoeobtenodedados.

As mtricas demodularidade ajudam a garantir uma qualidade nos sistemas.

Existemvriasmtricasdemodularidadenaliteraturaqueajudamnagarantiadopadrode
qualidade de projeto Orientados a Objeto. Elas ajudam a melhorar o entendimento das
caractersticas do sistema e desta forma ajudar no desenvolvimento de um sistema de
qualidade.
Existem tambm as medidas de software, Ddiferentemente das mtricas de
modularidade, as medidas de software calculam a quantidade de desfeitos registrados ou
corrigidosporumdeterminadoperododetempo. , Aa quantidadededesenvolvedoresque
contribuiparaoacrscimodenovasfuncionalidadesduranteumaversoeaquantidadede
novasfuncionalidadesacrescentadasnosoftware. Essas medidasnoajudamnagarantiada
qualidadedossistemas,masnosproporcionam ummelhorentendimentodas caractersticas
do software. Ento medidas de software podem ter uma relevncia para o aumento ou
diminuiodosvaloresdasmtricasdemodularidadequegarantemaqualidadedosistema.
Comaevoluodosprojetosaquantidadedecorreesdebugs,quantidadede
desenvolvedores e acrscimo de novas features pode aumentar ou diminuir ao longo do
desenvolvimentodosoftwarequesomtricasdesoftware.Comooaumentoediminuio
das mtricas desoftwareinfluenciamnasmtricasdemodularidade?Serqueelastemum
correlacionamentocomoaumentooudiminuiodosvaloresdasmtricas?Eseelasajudam
aaumentaroudiminuirosvaloresdasmtricasdemodularidadequaissuascaractersticas?
Nestetrabalhosiremosfazerumestudodasmtricasdemodularidadeemtricas
de software. Neste estudo procuramos estudas como as mtricas de modularidade
correlacionamcomasmtricasdesoftware.Eassimmostrararelevnciadessasmedidasde
software.

1.1 Estruturadamonografia
Estetrabalhoestdivididoem5captulosalmdaintroduo.Nocaptulo2
falamossobreostrabalhosrelacionadosnareaeoquemotivouodesenvolvimento
dessestrabalho.Nocaptulo3apresentamosoreferencialtericocomconceitose
definies. No captulo 4 mostramos a metodologia utilizada, como conseguimos
gerar os dados necessrios. No captulo 5 apresentamos os resultados obtidos
visualizandoatravsdegrficosetabelas.Nocaptulo6realizadoaconclusodo
trabalhoatravsdasanlisesdosgrficosetabelasobtidos.

TRABALHOSRELACIONADOS
Aocomearminhaspesquisasnareademtricasdemodularidadealguns
trabalhos (SCHRTER; ZIMMERMANN,2006)(NAGAPPAN,NACHIAPPANet
al.,2006),
Em(NAGAPPAN,NACHIAPPANetal.,2006) iniciadoumestudoem
cincoprogramasdaMicrosoftparaaidentificaodefalhasdeprogramasatravsdas
mtricasdesoftware.Nofoipossvelidentificarumacorrelaosignificativaentre
algumamtricademodularidadeeapresenadefalhasnosistema.
No segundo trabalho (SCHRTER; ZIMMERMANN, 2006) ele d
continuidadeaotrabalhode(NAGAPPAN,NACHIAPPANetal.,2006)trabalhando
oaparecimentodebugsantesedepoisdolanamentodaverso3.0doeclipse,no
trabalho ele correlaciona as mtricas de modularidade com a densidade de bugs
encontradoantesdedepoisdaverso.Almdissoelecorrelacionaoaparecimentode
bugscomaquantidadededesenvolvedoresantesedepoisdolanamentodaverso.
Em outro trabalho (SUBRAMANYAM; KRISHNAN, 2003) foram
analisadosprojetosdelinguagensdiferentesverificandoseexistiamcorrelaesentre
asmtricasdemodularidadeeoaparecimentodebugs.Notrabalhonofoipossvel
verificar um padro entre as linguagens do aparecimento de bugs e as mtricas
analisadas,masfoiverificadoquealgumasmtricasdemodularidadecorrelacionam
comoaparecimentodefalhasnosistema.
Nosprojetosanterioressopropostosvriosmelhoramentosdeseustrabalhos
em(SCHRTER;ZIMMERMANN,2006)propeumaanlisemaisprolongadado
projeto,analisarmaisdeumaversodosistema.Em(NAGAPPAN,NACHIAPPAN
et al., 2006) prope autilizaode mais mtricas, mais verses e com a mesma
linguagemdeprogramao.
Verificando essas limitaes nos projetos anteriores iremos analisar as
mtricas de modularidade em longo perodo de vida do software, quantidade de
verses maior que 10, entre trs projetos de uma mesma empresa, Open Source,
Orientado a Objeto e de uma mesma linguagem Java. Iremos correlacionar as
principaismtricasdemodularidadecomaquantidadedebugscorrigidasporverso,
aquantidadededesenvolvedorescolaboradosporversoeaquantidadedefeatures
adicionadasaolongododesenvolvimentodosistema.

REFERENCIALTERICO

Neste capitulo so apresentados conceitos e definies importantes para o

desenvolvimento do trabalho. Destacamse controle de verso, Git, Open Source
Software,mineraoderepositrios,mtricasdesoftware,mtricasdemodularidade,
correlaodePearsoneBug.

3.1 Controle de verso

O que controle de verso, e por que desenvolvedores acham importante a
utilizao?Controledeversoumsistemaquearmazenaasalteraesfeitasemumarquivo
ouconjuntodearquivosaolongodotempodeformaquevocconsigarecuperarverses
especificas.
Se voc um programador e deseja manter as modificaes feitas durante a
implementao do projeto, utilizar um Sistema de controle de Verso (Version Control
Systemouc)umasabiadeciso.Elepermitearecuperaodequalquerestadodearquivo
no desenvolvimento do seu projeto, recuperar o estado de um projeto inteiro, fazer
comparaesfeitasaolongodotempo,verificarasltimasmodificaesqueocasionaramo
aparecimentodealgumerro.UsarumVCSsignificaqueseaconteceualgumproblemano
projeto ou houve perde de arquivos, poder facilmente recuperalos. Alm disso, o
gerenciamentodoprojetoficamuitomaisfcil.
Existempraticamentetrsmtodosparasefazerumsistemadecontroledeverso:
controledeversoLocal,controledeversocentralizado,controledeversodistribudo.

3.1.1 ControledeversoLocal

Omtodopreferidodecontroledeversopormuitaspessoasacriaodevrias
pastascomasversesdosarquivos.aformamaissimplesdeversionamentodearquivos,
masmuitosuscetvelaerros.muitofcilesquecerondefoiguardadooarquivoougravar
umarquivoemumdiretrioerradosobrescrevendooarquivoanterior.

Figura1:Diagramadecontroledeversolocal

3.1.2 Controledeversocentralizado

Umgrandeproblemaidentificadonosprojetoseraquandovriosdesenvolvedores
desejavamtrabalharemconjuntocomoutrosdesenvolvedores,queutilizamoutrosVCS.Para
solucionarissofoicriadoumdosmtodosmaisutilizadosnosVCSocontroledeverso
centralizado.Nestemtodofoidesenvolvidoumservidorcentralizavaoarmazenamentode
todas as modificaes de arquivos feito no sistema e agora cada desenvolvedor poderia
resgatar(checkout)osarquivosdoservidor.

Figura2:Diagramadecontroledeversocentralizado

Estemtodooferecevriasvantagens,especialmentesobreomtododeversolocal.
Agoratodomundotemumconhecimentorazovelsobreoqueosoutrosdesenvolvedores
estofazendonoprojeto.Administradoresdosistemaocontroledoquecadadesenvolvedor
devefazer.
Entretantoestemtodooferecefalhar,poistudoestcentralizadonoservidorcentral.
Seesteservidorficarforadoaroutiverproblemasnosistemadearquivos,namelhordas
hiptesesosdesenvolvedoresficaramsemtrabalharpeloperodoqueoservidorficarforado
ar.Eemumproblemamaisgraveoservidorpodecorromperoseusistemadearquivoeassim
perdertodoohistricodemodificaesdoprojeto.

3.1.3 Controledeversodistribudo

E ento surge os sistemas de controle de verso distribudo. Nesses sistemas os

clientesnocopiamapenasasltimasversesdosarquivos:elessocopiascompletasdo
repositrio.Destaforma,seoservidorcentralfalhar,qualquerumdosrepositrioslocaisdos
clientes podeser copiado devoltapara o servidor e assim restaura todooprojeto. Cada
checkoutoresgatedorepositriocompletocomtodososdados.

Figura3:Diagramadecontroledeversodistribudo

Alm disso, muitos desses sistemas funcionam muito bem quando se tem vrios
repositrios remotos com os quais eles podem colaborar, permitindo que vrios
desenvolvedores trabalhem em conjunto em vrios projetos diferentes e simultaneamente.
Isso permite o estabelecimento de diferentes workflow (fluxo de trabalho) que no so
possveisemsistemascentralizado,porexemplo,usodehierarquia.

3.2 GIT
O GIT foi desenvolvido a partir da necessidade sentida no processo de
desenvolvimentodokerneldoLinux.Entre1991e2002oLinuxeradistribudoatravsde
patchearquivoscompactados.Em2002,oprojetodokerneldoLinuxcomeouautilizaro
sistemaDVCS(Distributed Version Control System)proprietriochamadoBitKeeper.

Em 2005, o relacionamento entre os desenvolvedores do Linux e a empresa que

desenvolviacomercialmenteoBitKeepersedesfez,e ostatusde isentodepagamentoda
ferramentafoirevogado.IssofezcomqueacomunidadedesenvolvedoradoKerneldoLinux
(Em particular Linus Torvalds, o criador do linux) a desenvolver sua prpria ferramenta
baseadonaexperinciaobtidaatravsdoBitKeeper.
Osobjetivosparaacriaodonovosistemaforam:

Velocidade

Designersimples

Suporterobustoaodesenvolvimentonolinear

Totalmentedistribudo

Capazdelidarcomgrandesprojetos.

Desde2005oGitevoluiueamadureceuapontodeserumsistemafcildeusare
aindaassimmatemessasqualidadesiniciais.rpido,eficientepragrandesprojetosepossui
umtimosistemadebranchingparaodesenvolvimentonolinear.
OGitclassificaosarquivosemtrsestadosfundamentais:consolidado(Commited),
modificado (modified) e preparado (staged). Dados so tidos como consolidados quando
estoarmazenadosnabasededadoslocal.Modificadoquandoumarquivosofreualteraes
masaindanofoiconsolidadonabasededados.Umarquivotidocomopreparadoquando
vocadicionaoarquivoparafazerpartedeumaconsolidao(Commited).

Figura4:Diretriodetrabalho,readepreparao,eodiretriodoGit.

OworkflowbsicodoGitpodeserdescritoassim:
1. Vocmodificaarquivosnoseudiretriodetrabalho.
2. Vocselecionaosarquivosparafazerpartedocommit.
3. Vocfazocommit,quearmazenaosarquivoscomoelesestonabasede
dadoslocal.

3.3 Open Source Software

OtermoOpenSourcedadoasistemasquepodemserlivrementeusados,alteradose
compartilhados(Modificadosouno)porqualquerum.OpenSourceSoftwaremantidopor
vriaspessoasedistribudosoblicenasqueestejamemconformidadecomadefinioOpen
Source.
O desenvolvimento de Open Source Software (OSS) normalmente muito
colaborativo e distribudo geograficamente (GODFREY; TU, 2000). Muitas empresas e
desenvolvedores individuais tem desenvolvido seus projetos inhouse como o projeto
proprietrioparafuturamenteseremliberadoscomoOpenSourceoucomumalicenaqued

todaaliberdadedeusodosistema.UmexemplofoioNetscapewebbrowser(ouseja,O
projetodoMozilla),ocompiladorJavaJikesdaIBMeoKiltdedesenvolvimentoJavadaSun
quehojefoicompradopelaOracle.
Quando o dono do projeto v a possibilidade de convidar outras pessoas para o
desenvolvimento do projeto ele faz com que o cdigo esteja disponvel outros
desenvolvedoreseodesenvolvimentoprossegue.Normalmentequalquerumpodecontribuir
paraodesenvolvimentodosistema,mascabeaodonodoprojetodecidirqualcontribuidor
podeounosetornapartedolanamentooficialdoprojeto.
O desenvolvimento do modelo open Source (OSD) diferente dos processos
tradicionaisdedesenvolvimentocomercialinhouseemvriosaspectosfundamentais.Em
primeirolugar,oobjetivoprincipaldeumprojetoOpensourcecriarumsistemaqueseja
tilouinteressanteparaaquelesqueestotrabalhandonisso,noparasuprirumacarncia
comercial.
Desenvolvedoressofrequentementevoluntriosnoremuneradosquecontribuem
paraoprojetocomoumhobby,emtroca,elesrecebemoreconhecimentodacomunidadee
satisfaopessoalporseusesforos.Asvezesissosignificaquegrandepartedosesforosem
umprojetoOSDconcentrasenoqueosprogramadoresachaminteressanteemfazernasua
partedotempo,aoinvsdefazeroessencial.Podeserdifcildirecionaroprojetoparao
objetivoespecificojqueodonodoprojetonotempodersobreosdesenvolvedoresque
contribuem.Estaliberdadetambmsignificanadificuldadedeconvencerosdesenvolvedores
paraexecutartarefasessenciais,taiscomotestessistemticosoureestruturaodecdigo,
quenosotoemocionantescomoaescritadeumnovocdigo.
Outras caractersticas notveis de desenvolvimento de cdigo aberto incluem
(GODFREY;TU,2000):

Agendamento:geralmentehpoucapressocomercialparamanterqualquer
prazosdifceis,enamaioriadesenvolvedoresOSDtemdayJobsqueocupa
amaiorpartedotempododesenvolvedor.Emboraissopossaimplicarem
ciclosdedesenvolvimentosmaislongos,estatambmumavantagem,pois
projetosOSDestoemgrandeparteimuneapressestimetomarket,uma
verso do sistema no lanada at que o proprietrio do sistema esteja
convencidoqueosoftwareestestvelemaduro.

Qualidadedecdigoepadrespodemvariarmuito:Comoocdigouma
contribuioficadifcilinsistirempadresparticulares,apesardequemuitos
projetostemguiasoficiaisdedesenvolvimentoemseussites.

Cdigoinstvelcomum:AlgunsprojetosOSDrefernciasuasmodificaes

aduaslinhasprincipaisdedesenvolvimento:aliberaodedesenvolvimento
que contem novas funcionalidade (feature) experimentais e uma liberao
estvelquecontmamaioriadasatualizaesecorreesdebugsdaltima
versoestvel.

Planejamentoevolutivo,testeseprevenodemanutenibilidadepodesofrer,
pois os desenvolvedores so encorajados a participar ativamente sem
necessariamenteterumacuidadosareflexoereorganizao.Aqualidadedo
cdigomantidoemgrandepartepordepuraesmassivamenteparalelas
(ouseja,vriosdesenvolvedorescadaumutilizandoocdigodooutro),em
vezdeterumsistemadeteste.

3.4 Minerao de Repositrios

Repositriosdecdigofontepossuiumriquezadeinformaesquenosuteispara
agestoeconstruodecdigofonte,mastambmcomoumregistrodetalhadodecomoo
cdigofonte tem evoludo durante o desenvolvimento. Se um pedao do cdigofonte
refatorado,aevidenciadistoserarmazenadanorepositrio.Oestadodocdigopreps
refatoraoestarpresentenorepositrio.Assimcomoascorreesdebug,modificaes
feitasparacorrigiroproblemasogravadas.AssimcomonovasAPIssoadicionadasao
cdigo,amaneiracorretadeusalasimplicitamenteexplicadasnocdigo.Odesafio,ento,
desenvolverferramentasetcnicasqueautomaticamenteextraiameuseessasinformaes.
Amineraoderepositrios(MR)temvrioscamposdeanliseparaligarosricos
dados presentes nos repositrios de software para descobrir informaes interessantes e
acionveissobreossistemasdesoftwareeprojetos.Exemplosderepositriosdesoftware:

Repositrioshistricos:Comorepositriosdecontroledecdigo,repositrios
debugsearquivosdecomunicao.

RepositriosdeTempodeexecuotaiscomoregistrodeimplantaoque
contm informaes sobre a execuo e a utilizao da aplicao em um
simplesoumltiploslocaisdeimplantao.

RepositriodecdigoscomooSourceforge.neteGoogleCodequecontm
vrioscdigosdevriasaplicaesdesenvolvidaporvriosdesenvolvedores.

Repositrios de software so comumente usados na pratica como repositrios de

armazenamento.Porexemplo,repositrioshistricosqueutilizamrastreamentodehistrias
debugsoufeatures,masnosousadoscomumenteparadeterminarotempoderesoluo
esperadaentreaaberturadeumbugearesoluodomesmo.

Pesquisadores MR visam transformar esses repositrios de armazenamento em

repositrios ativos que podem orientar os processos de deciso em projetos de software
modernos.Minerarrepositrioshistricos,tempodeexecuoecdigos,podemosdescobrir
padres e informaes uteis. Repositrios histricos captura importante dependncias
histricas(GALLetal.,1998)entreosartefatosdeprojeto,taiscomofuno,arquivosde
documentaoouarquivosdeconfigurao.Desenvolvedorespodemusaressasinformaes
parapropagaralteraesparaartefatosrelacionados,emvezdeapenasusarasdependncias
decdigoestticaoudinmicasquepodemdeixardecapturardependnciasimportantes.Por
exemplo, uma alterao no cdigo que escreve dados em um arquivo e que pode exigir
alteraesnocdigoquelosdadosdestearquivo,emboranoexistanenhumaligaoentre
osdoispedaosdecdigo.
Paraosrepositriosdetempodeexecuoelepoderiamserusadosparaidentificar
anomaliasdeexecuo,identificar,padresdeusoatravsdeimplantaesesinalizaes.
Repositrios de cdigo poderia ser usados para identificar o padro de uso correto e
dominantedasbibliotecasminerandoseuusoatravsdemuitosprojetos.

3.5 Mtricas de modularidade

Amodularidadetemvindoadesempenhasumpapelmuitoimportantenosestgios
iniciaisdodesignerdosoftware.Osengenheirosdesoftwareconsiderammodularidadecomo
umprincpiochavequandosecomparaalternativasdearquiteturaeanlisededegeneraode
arquitetura (LINDVALL et al., 2002). Na verdade, os engenheiros de software so
promovidosparaprojetasboasarquiteturas,baseandoseemumainfinidadedemecanismos
demodularidadedisponvel:
1. Linguagemdedescriodearquitetura(ADLs),taiscomooACME.
2. Oscatlogosdeestilosarquitetnicos
3. Como bem sabemos dos mais altos princpios de designer, tais como
interfacesestreitas,reduodoacoplamentodaarquiteturaeafins.
No entanto, a confiana nesse mecanismos de arquitetura no suficiente para
alcanar projetos de arquitetura verdadeiramente modulares. Alm disso, a avaliao e
melhoramentodamodularidadedeinicialdoprojetoaindamaisdesafiador.Sonecessrios
tcnicasdeavaliaoquantitativaparaavaliarecontrolarasdiferentesarquitetura.
Mtricas de software so um poderoso meio para fornecer indicadores de
modularidadedeprojetosdearquitetura(DOBRICA;NIEMELA,2002).Acomunidadede
mtricas de softwaretem constantemente usadonoes comomdulos de acoplamento e

coesoparaderivarmedidasdequalidadedaarquiteturadesoftware.
Asmtricasdesoftwarepodemserseparadasmasseguintesreas:
1. Tamanhodecdigo.
2. Estrutural

3.5.1 TamanhodeCdigo

Cdigopodeserproduzidodevriasformas.Aformamaisutilizadaorientadoa
objetoquedeixaasmtricastradicionaismaisdifceis.
Temoscomomtricastradicionais:

Nmerodelinhasdecdigo.Existeumgrandeproblemanoclculodas
linhaspoismuitosprogramasutilizamdocumentaes,comentrios,linhas
embrancoemseuscdigoseissotrabalhanestamedida.Pararesolvereste
problematemosonmerodelinhasnocomentadosnaqualsoretirados
dacontagemaoscomentrioseaslinhasembrancodocdigo.

Nmero de funes. possvel avaliar o quanto de funcionalidades um

softwarepodeoferecerparaousurio.Poiscadafunotemaimplementao
deumalgoritmoquerealizaumtrabalhoparaousurio.

NmerodeClasse.Estamtricasnospermiteverificaroquantoumprojeto
est modularizado e menos complexo. O conceito de classe veio para
melhorar o entendimento do cdigo assim melhorando a manuteno,
aumentandoamodularidadeediminuindoacomplexidadedosoftware.

Nmerodearquivos. Comestamtricaspermitidosaberotamanhodo
projetoeacomplexidadedomesmo.Quantomaisarquivosmaisoscdigos
estodistribudosedestaformaficacadavezmaisdifcillocalizarondefoi
implementadodeterminadafuncionalidade.

3.5.2 Estrutural

Em cdigos orientados a objeto importante que o cdigo seja cada vez mais
divididoemmdulos.Asmtricasestruturaisirammensurar,medirainterligaodemdulos

com outros mdulos. Para uma baixa complexidade importante que os mdulos sejam
coesosenodependamdeoutrosmdulos.
Asmtricasestruturaisso:

Complexidade de McCabe. Esta mtrica calcula atravs de gerao de

grficos de fluxos a quantidade de caminhos independentes pelo cdigo.
Atravsdaformula:
M=EN+2xP
Emque:
o

MComplexidadeciclomtica

EQuantidadedesetas

Nquantidadedens

Pquantidadecomponentesconectados.

Figura5:Grafosdefluxosdecontroledeumprogramasimples.

Nafigura5.atemosumprogramasimples.Oprogramacomeanonvermelhoe
termina no n azul. Para o grafo 5.a, E=9, N =8 e P=1, resultando numa complexidade
ciclomticade3.Paraografo5.b,E=10,N=8eP=1,entoresultandonumacomplexidade
ciclomticade4.

Response for Classes (RFC). Calcula a cardinalidade das chamadas das

classes(NAGAPPAN,Netal.,2006).Achamadadasclassesconsisteem
todososmtodoslocaisetodososmtodoschamadospormtodoslocais.
logicoquequantomaioroRFC,maiscomplexoseraclasseeassimmais
difcilsermanteraclasse.

Dependncia cclica de Pacotes: Esta mtrica informa a medida das

dependncias depacotes do Projeto. Quantomaior o valor desta mtricas
maioroacoplamentodosoftware.

3.6 Correlao de Pearson

Temseumavarivelestatsticabidimensionalquando,relativamenteacadaelemento
dapopulao,seobservaeestudaduascaractersticasdistintas.ParaasvariveisestatsticaX
eY,avarivelestatsticabidimensionalrepresentadopor(X,Y).
Paraaobservaodecomoosvaloresdessasduasvariveisevoluemcriadoum
diagrama de disperso, ou nuvem de pontos, o conjunto dos pontos do tipo (x, y)
representadosnumreferencial,ondexeysoosvaloresobservadosdasvariveisXeY,
respectivamente.
Quandotomamosasvariveisduasaduaspodemosverificaroquesucedeauma
varivelXquandooutravarivelYvaria.Existecorrelaolinearquandopossvelajustar
nuvemdepontosnumareta.
OcoeficientedecorrelaodePearsonaintensidadedaassociaolinearexistente
entreasvariveispodeserquantificadaatravsdochamadocoeficientedecorrelaolinear
dePearson:

Figura6:FormuladocoeficientedecorrelaodePearson.

Onde:

CxyCovarinciaouvarinciaconjuntadasvariveisXeY;

SxDesviopadrodavarivelX;

SyDesviopadrodavarivelY;

(a) (b)(c)
Figure9:GrficoscompossveisvaloresparaXeY

NaFigura9.atemosvariveispositivamentecorrelacionada.Nolimite,isto,sea
correlaoforperfeitacomoeocasoseconsiderarmosacorrelaodavarivelxconsigo

prpria o coeficiente de correlao ser igual a 1. Na figura 9.b as variveis esto

negativamentecorrelacionadas.Nolimite,isto,seacorrelaoforperfeitaocoeficiente
decorrelaoseriguala1.Nafigura9.casvariveissoestocorrelacionadas.Nolimite,
isto,emcasodeabsolutaindependnciaocoeficientedecorrelaoseriguala0.
Para os valores do Coeficiente de correlao podemos classificlos da seguinte
forma:
Coeficientede

Correlao

correlao
r=1

Perfeita

0.8r<1

positiva
Forte

0.5r

positiva
Moderada

0.1r

positiva
Fraca

0<r<0.1

positiva
Intima

0
0.1<r<0

positiva
Nula
Intima

0.5<r0.1

negativa
Fraca

0.8<r0.5

negativa
Moderada

1<r0.8

negativa
Forte

r=1

negativa
Perfeita
negativa

Tabela1:ClassificaodosvaloresdaCorrelaodePearson

3.7 Bug
Umbugumapalavrainglesaquesignificainseto.Estetermogeralmenteusado
eminformticaquandoencontradoumerroemalgumprograma,ouseja,quandoalgum
programa age de maneira inesperada ou fora do comum. Ento, bug um erro no
funcionamentodeumsoftware,podendocausarcomportamentosinesperadoseindesejados.
Geralmenteelessocausadosporerrosdoprpriocdigofonte,maspodemsercausados
tambmporalgumcompilador,sistemaoperacionalouframework.

Otermobugfoimuitocitadonoanode1999quandoseesperavaqueacontecesseo
chamadobugdomilnio.Napoca,asempresasaindausavamsistemasantigoscomrecursos
escassosdesenvolvidosnosanos80,entomuitosprogramadorestratavamnosprogramas
que utilizavam datas apenas dois dgitos, assim "1991" era tratadocomo"91". O grande
receiodosdesenvolvedoresqueossistemaspudessemconfundiroano2000comoano
1900,serealmenteocorresseesseerroosclientesdebancosiriamversuasaplicaescom
jurosnegativoseosfuturosboletosdecobranateriam100anosdeatraso.Outrosustoque
sistemasmilitaresquecontrolavamarsenaisdeguerrapudessemfalharcausaracidentes.Nada
passoudeumgrandealardesemfundamentosjqueamaiorpartedessessoftwaresjprevia
aviradaetinhamtcnicasdecompensaoprprias.Logo,obugdomilnioerainofensivo.

Figura7:Umafotografiasupostamentedoprimeirobug(uminsetoreal)quefoidepurado
("debugado")em1947.Daoseuusonosdiasatuais.

OsBugs podemcausartantoproblemasinofensivoscomofalhasdesegurana.A
principalportadeentradaparaqueocorramessasfalhasautilizaodeprogramasquese
conectam a internet, clientes de email e navegadores. Crackers podem ter acesso aos
arquivos presentes no computador infectado, e divulgar para outras pessoas atravs da
internet.Assim,devesetomarcuidadoemprogramasnaversobeta,ouseja,programasem
desenvolvimento,sendoestesmaisvulnerveisaessetipodeataque.
Os bugs podem surgir em qualquer estgio do desenvolvimento de um software.
Muitosdelessocausadosporerrosdaequipededesenvolvimentoesoresultadosdafalha
dohomememlidarcomacomplexidadedossistemasdesoftware.Estessistemaschegama
possuirmilharesdearquivosnoseucdigofonte,ondecadaarquivospossuicentenasde
linhasdecdigo.

3.7.1 TiposcomunsdeBugs

Osbugspodemserclassificadosdaseguintemaneira:

Bugs Aritmticos. So bugs relacionados a operaes matemticas como

divisoporzero,estourodearmazenamentodevalordavarivel,percade
precisonumrica.

Bugs lgicos. So bugs relacionados a lgica de programao. Como a

implementaodeloopsinfinitoserecursoinfinita.

Bugssintticos.Sobugsrelacionadosalinguagemdeprogramao.Como
emalgumaslinguagensx=5iratribuirovalor5avarivelxenquantoquex
==5irchecarseovalor5.

Bugs de recurso. So Bugs relacionados a acessos de memria invlidos

comorefernciaparaponteironulo,utilizarvariveisnoinicializadas,buffer
overflow.

Bugsdeprogramasmultithread.Sobugsqueestorelacionadoadeadlock
onde um processo fica esperando outro processo liberar o recurso
compartilhadoenenhumdosdoisliberaesserecursocausandoassimuma
paradageraldosistema.

Bugs de interface. So bugs relacionado ao incorreto uso de uma API,

implementaesincorretasdeprotocolos.

Bugs de performance. So bugs relacionados a algoritmos de alta

complexidadecomputacional,acessorandmicoadiscosememria.

Bugs de Grupo de desenvolvedores. So bugs encontrados nas mudanas

feitasporprogramadorescomoatualizaesinapropriadanocdigocomoa
alteraodonomedeumafunoutilizadaemvriaspartedosistemaepor
outrosprogramadores.Diferenasentreadocumentaoeoestadoatualdo
software.

METODOLOGIA
Nestetrabalhoserrealizadoumaanliseestatsticasatravsdousodocoeficientede

Pearsonentreasmtricasdemodularidadeeasmedidasdequantidadedebugscorrigidos,
quantidadedefuncionalidadesadicionadaseaquantidadededesenvolvedores.
Comofoiexplicadonocapitulo3.1ossistemadeversionamentodesoftware
guardamtodotipodeinformaoespecificadosoftware.Informaesmuitovaliosas
queatravsdamineraoderepositriopodemseranalisadaseassimretirarpadres
dessasanalises.
ParaonossoestudoprocuramosprojetosOpenSource,escritosemJava,com
sistemadeversionamentodecdigodeprefernciaoGIT,tivessemummecanismos
decompilaoautomticavialinhadecomando,tivessemumrepositriosdeBug
comoporexemploobugzillaefossemprojetosdesucesso.
Verificandoositeoficialdo bugzilla(http://www.bugzilla.org/) foipossvel
identificarosprincipaisprojetosqueutilizavamobugzillacomorepositriosdeBug
e que eram Open Source. Os principais Projetos apresentados no site oficial do
bugzillaso:

Mozilla:https://bugzilla.mozilla.org/

LinuxKernel:http://bugzilla.kernel.org/

Gnome:http://bugzilla.gnome.org/

KDE:http://bugs.kde.org/

ApacheProject:http://issues.apache.org/bugzilla/

OpenOffice:http://www.openoffice.org/issues/query.cgi

Eclipse:http://bugs.eclipse.org/bugs/

Apsaanlisedessesprojetosverificandoapossibilidadedecompilaoautomtica,
utilizaoderepositriosdeversionamentoGitselecionamosprojetosdaApacheProject.Os
softwaresselecionadosdeveriamserdegrandesucesso,termaisque10milcommitseque
estoemplenodesenvolvimento.OsSoftwaresselecionadosforam:
1. Tomcat. uma implementao open source de java Servlet e JavaServer
PagesTechnologies.
2. POI. O apache POI tem a misso de criar e manter APIs java para a

manipulaodevriosarquivosdeformatosbaseadonotheOfficeOpen
XMLstandards(OOXML)ecomponentesMicrosoftsOLE2.
3. Jmeter. uma aplicao java feita para fazer teste funcionais e calcular
medidasdeperformance.
ComosprojetosselecionadosforamfeitososcheckoutdosrepositriosGITdecada
projeto:

POI:https://github.com/apache/poi

Jmeter:https://github.com/apache/jmeter

Tomcat:https://github.com/apache/tomcat

ParafazerodownloaddorepositriosgitmuitosimplesbastainstalaroGitemsua
mquina,nainternetmuitofcildeencontrartutoriaisqueexplicamainstalaodoGitpara
vriasplataformas,eutilizarocomando:
git clone link_do_repositorio_git
Porexemploparabaixarorepositriosdosprojetosacimaoscomandosso:

Tomcat
o

git clone https://github.com/apache/tomcat.git

Jmeter
o

git clone https://github.com/apache/jmeter.git

git clone https://github.com/apache/poi.git

POI

Comoointuitodestetrabalhoanalisarasmtricasdemodularidadefoinecessrio
selecionar um software de anlise de mtricas de modularidade dos sistemas. Ento

ArchView

CodeCity

dadosminerados
Clculodemtricasdecdigo
Processamento de cdigo em

X
X

X
X

X
X

X
X

textopuro(nocompilado)
Interface grfica de

visualizaodosdados
Processamento

de

Oceano

Evoltrack

KalibroeAnalizo

EclipseMetrics

X
X

Sonar

Aplicaoweb
Interface de consulta aos

MetricMiner

Mezuro

pesquisamosnainternetvriosprogramasquefazemanalisedemtricas,soeles:

repositriosGIT

Tabela2:Quadrocomparativoentreaplicaesdeanlisedemtricasdemodularidade.

DentreosprojetosoMetricMinereomesurotemprocessamentoderepositriosGIT,
masnopossueminterfacegrficaoquedificultaavisualizaodosdados.OSonareoutros
trs sistemas possuem visualizao por interface grfica, mas apenas o sonar faz
processamento de cdigo em texto puro (sem compilao), o que ajuda na obteno de
mtricasdetamanhodosoftware.OeclipseMetricsapenas utilizadoatravsdoeclipsee
paraestetrabalhonecessrioqueoprogramanonecessitedeumaIDE,poisqueremos
gerarosdadosautomaticamente.EcomumaIDEissoficainviveletrabalhoso.
Portanto dentre todos os softwares de analises de mtricas de modularidade o
SonarQubefoioescolhidoparaserutilizadonesteprojeto.OSonarQubeumaplataforma
aberta de gerenciamento de qualidade de cdigo. Cobrindo os 7 eixos da qualidade de
software:
1. Arquiteturaedesign
2. Comentrios
3. RegrasdeCdigo
4. Potencialidadedebugs
5. Complexidade
6. TestesUnitrio
7. Duplicidades.
Fazanlisedemaisde20linguagensdeprogramaoentreelas:

Java

C#

C/C++

PL/SQL

COBOL

Python

SonarQube baseado em uma aplicao web. Regras, alertas, excluses,

configuraeseetc.podeserconfiguradosonline.Sonartambmintegracomosprincipais
sistemasdegerenciamentodedadoscomo:MySQL,PostgreSQL,Oracleentreoutros.
Paracomearatrabalharcomosonarprecisofazerodownloadde2projetos:

SonarQube(verso3.7.4)

SonarRunner(verso2.3)

PrimeiramenterodamosoSonarQubeatravsdeumscriptqueestnoprprioprojeto

doSonar.Parainiciaroservidorbastarrodar:
./sonar.sh console
OsonarRunneroprogramaquevaifazeraanlisedocdigoeenviarosdadospara
oSonarQubearmazenarnabasededados.NesteconfiguramosoSonarQubeparatrabalhar
comoPostgresSQL9.1,paraissobastaprocuraroarquivodeconfiguraesdoSonarQubee
configuraloparatrabalharcomoconectorpgsql.ParaosonarRunnerfazeraanlisedos
projetos preciso configurar um arquivo chamado sonarprojetct.properties segue um
exemplodoquesedevesercolocadonestearquivo:
# Required metadata
sonar.projectKey=jmeter
sonar.projectName=jmeter
sonar.projectVersion=3.7
# Comma-separated paths to directories with sources (required)
sonar.sources=src/core
# Language
sonar.language=java
# Enconding of the source files
sonar.sourceEnconding=UTF-8
sonar.binaries=build/core

OComandosonar.languageinformaquallinguagemseranalisada,sonar.sources
informa caminho para o diretrio onde est o cdigo a ser analisado e sonar.binaries
informaondeestoosarquivoscompiladodossistema.Feitoissobastachamarnomesmo
diretrioondefoicriadoestearquivoocomandoparaexecuodosonarRunner.
Como o SonarQube no interage com repositrios GIT e no faz compilaes
automatizadas dos cdigos foi necessrio a criaode um script empythonpara fazer o
processodemodificaodasversesdocdigoporcomandoGIT,compilarosprojetospara
gerarosbinriosnecessriosaosonarparaconseguiranalisaralgumasmtricasestruturaisdo
cdigo.Ospassosutilizadosparaaobtenodosdadosforam:

GIT

Compilar
Limpar
possiveis
modifica
es
alterar
commit

Sonar

Executar
programa
ant.
Gerar
arquivo de
configura
o do
sonar.

Analisar
metricas
Armazena
dados no
banco de
dados

Figura8:Passosdoscriptpythonparaobtenodosdadosemcadacommit.

Comocadaprojetoselecionadoexistemmaisde10.000commitseoprogramafoi
executadoemumperodode48horas,paraumamaiorabrangnciadeversespossveis
nessas 48 horas foram feitos pulos de 6 commits. Foram analisado para cada projeto os
seguintesperodosdecommit:

Projeto
Perodo
Jmeter
7/10/2010 12/10/2012
POI
8/5/2008 9/2/2014
Tomcat
21/11/2010 9/2/2014
Tabela3:Perododecommitsanalisadosporprojeto.

Nestesperodosforampossveisanalisarasseguintesquantidadesdeverso:

Projeto
Quantidade de verses
Jmeter
22
POI
41
Tomcat
18
Tabela4:Quantidadedeversesanalisadas.

O Script python alm de fazer os processos citados anteriormente ele obtm do

repositriosinformaessociais,dasmensagensdocommitretirainformaesseocommit
foideumacorreodebugouumafeatures.Nestaidentificaofoiutilizadonasmensagens
umexpressoregularparalocalizaraocorrnciadapalavrabugnoscommitsetudooque
notinhaapalavrabugfoiconsideradocomoadiodefuncionalidadeoufeature.
Todos esses dados foram tratados e colocadoem um repositrio de dados. Ento
foramfeitasconsultaspararetiradadosdadosecolocadosemtabelasdoExcel.
OltimoprogramautilizadonesteprojetofoioIBMSPSS.ComoIBMSPSSforam

utilizadoosdadosdastabelasemExcelparafazeroclculodacorrelaodePearson.O
softwaresemostroumuitoprticoerpidoparafazerocorrelacionamentodosdados.

APRESENTAOEANLISEDOSRESULTADOS
Aseguirapresentadoosgrficosdaevoluodosdadosmaissignificantes
demtrica,quantidadedefeature,correodebugequantidadededesenvolvedores
dosprojetos.

5.1 Evoluo do Tomcat

Correo de Bugs Tomcat

Figura9:EvoluodaCorreodebugsTomcat

Quantidade de Desenvolvedores Tomcat

Figura10:EvoluodaQuantidadedeDesenvolvedoresTomcat

Quantidade de features Tomcat

Figura11:EvoluodaQuantidadedefeaturesTomcat

Ciclos de Pacote Tomcat

Figura12:EvoluodovalordametricadeCiclosdePacotesTomcat

Quantidade de Funes Tomcat

Figura13:EvoluodaQuantidadedeFunesTomcat

Complexidade de Funo Tomcat

Figura14:EvoluodaComplexidadedeFunodeTomcat

Complexidade Ciclomtica Tomcat

Figura15:EvoluodaComplexidadeCiclomticadoTomcat

5.2 Evoluo do POI

Quantidade de Features POI

Figura16:EvoluodaQuantidadedefeaturesPOI

Correo de Bugs POI

Figura17:EvoluodaCorreodeBugsPOI

Quantidade de Desenvolvedores POI

Figura18:EvoluodaQuantidadedeDesenvolvedoresPOI

Ciclo de Pacote POI

Figura19:EvoluodovalordametricaCiclodePacotePOI

Quantidade de Funo POI

Figura20:EvoluodaQuantidadedeFunoPOI

Complexidade de Funo POI

Figura21:EvoluodaComplexidadedeFunoPOI

Complexidade Ciclomtica POI

Figura22:EvoluodaComplexidadeCiclomticaPOI

5.3 Evoluo Jmeter

Quantidade Correo Bug Jmeter

Figura23:EvoluodaQuantidadeCorreoJmeter

Quantidades Desenvolvedores Jmeter

Figura24:EvoluodaQuantidadesDesenvolvedoresJmeter

Quantidade de Features Jmeter

Figura25:EvoluodaQuantidadedeFeaturesJmeter

Ciclo de Pacote Jmeter

Figura26:EvoluodovalordamtricaCiclodePacoteJmeter

Quantidade de Funes Jmeter

Figura27:EvoluodaQuantidadedeFunesJmeter

Complexidade de Funo Jmeter

Figura28:EvoluodaComplexidadedeFunoJmeter

Complexidade Ciclomtica Jmeter

Figura29:EvoluodaComplexidadeCiclomticaJmeter

TodososdadosgeradosseencontramnoapndiceAdestetrabalho.

5.4 Estudo da Correlao de Pearson dos dados

Aseguiresto3tabelascomosvaloresdacorrelaodePearson.

Mtrica\Projeto
RFC
Pacote
Linhas
Complexidade de
funo
Arquivos
Complexidade
Classes
Ciclo de Pacote
NCLOC
Funo
Complexidade de
Arquivo
Complexidade de
Classe
Accessors

Correlao de Pearson BUG

x Mtricas
Jmeter
POI
Tomcat
0,906
0,647
0,587
0,688
0,895
0,901
0,961
0,939
0,615
0,687
0,021
0,901
0,982
0,953
0,953
0,977
0,973
0,991
0,526

0,599
0,981
0,89
0,139
0,799
0,919
0,781

0,826
0,97
0,933
-0,978
0,657
0,221
-0,34

-0,444

0,789

-0,324

0,774

0,56

0,922

Tabela5:CorrelaodePearson(BUGxMtricas)

Mtrica\Projeto
RFC
Pacote
Linhas
Complexidade de
funo
Arquivos
Complexidade
Classes
Ciclo de Pacote
NCLOC
Funo
Complexidade de
Arquivo
Complexidade de
Classe
Accessors

Correlao de Pearson
Desenvolvedor x Mtricas
Jmeter
POI
Tomcat
0,91
0,716
0,557
0,791
0,795
0,84
0,931
0,939
0,534
0,694
0,084
0,84
0,95
0,962
0,971
0,949
0,942
0,946
0,832

0,682
0,928
0,881
0,421
0,945
0,918
0,656

0,834
0,853
0,855
-0,997
0,594
-0,015
-0,463

-0,259

0,677

-0,298

0,899

0,755

0,849

Tabela6:CorrelaodePearson(DesenvolvedoresxMtricas)

Mtrica\Projeto
RFC
Pacote
Linhas
Complexidade de
funo
Arquivos
Complexidade
Classes
Ciclo de Pacote
NCLOC
Funo
Complexidade de
Arquivo
Complexidade de
Classe
Accessors

Correlao de Pearson
Feature x Mtricas
Jmeter
POI
Tomcat
0,976
0,763
0,57
0,766
0,883
0,954
0,969
0,944
0,507
0,719
-0,011
0,954
0,973
0,967
0,988
0,985
0,94
0,964
0,712

0,615
0,977
0,892
0,094
0,962
0,974
0,76

0,846
0,987
0,887
-0,982
0,546
0,223
-0,286

-0,378

0,767

-0,205

0,845

0,76

0,86

Tabela7:CorrelaodePearson(FeaturexMtricas)

AstabelasmostramosvaloresdacorrelaodePearsonrelacionandoFeature,
Bug, Desenvolvedores e as principais Mtricas. Para uma melhor visualizao do

dadosforammarcadosemvermelhoascorrelaesdemaiorndice,sejanegativoou
positivo,das3tabelasentreasmtricas.
Verificase que a correlao foi forte positiva para 54,70% (62/117) das
correlaes e fortemente negativa para 2,56% (3/117) das correlaes, verificase
correlaomoderadapositivapara29,91%(35/117)doscasos,verificasecorrelao
fracapositivapara3,41%(4/117)doscasosefracanegativapara7,69%(9/117)dos
casos.
QuandocomparadoBugsemtricastemseque43,58%(17/39)dosmaiores
ndices de correlao esto relacionados a correo de Bugs. Para a comparao
Desenvolvedores e Mtricas temse que 15,38% (6/39) dos maiores ndices de
correlaoestorelacionadosaquantidadededesenvolvedores.Paraacomparao
FeaturexMtricastemseque46,15%(18/39)dosmaioresndicedecorrelaoesto
relacionadosaoacrscimodeFeatures.
Como de se esperar o acrscimo de features (43,58%) tem uma maior
correlaocomoaumentooudiminuiodasmtricasdeumsoftwareseguindopela
correodebugs(46,15%)eporltimoaquantidadededesenvolvedores(15,38%).
QuandoanalisadoosdadosisoladosparaoJmetertemseque38,46%(5/13)
dosmaioresndicesdecorrelaoquandocomparadoasmtricascomaquantidade
de bugs corrigidos. Analisando as correlaes comparando as mtricas com a
quantidade de desenvolvedores temse que 23,07% (3/13) dos maiores ndices.
Analisandoascorrelaescomparandoasmtricascomaquantidadedefeaturetem
seque46,15%(6/13)dosmaioresndicesdecorrelao.Quandocomparadocomos
valoresglobaisdecorrelaovsequeoJmeteracompanhaatendnciadequeo
acrscimo de features tem uma forte influncia no aumento ou diminuio das
mtricas.
QuandoanalisadoosdadosisoladosparaoPOItemseque38,46%(5/13)dos
maiores ndicesdecorrelaoestorelacionadosaquantidadedebugscorrigidos.
Analisando as correlaes comparando as mtricas com a quantidade
desenvolvedorestemseque15,38%(2/13)dosmaiores ndicesdePearsonesto
relacionados a quantidade de desenvolvedores. Analisando o ndice de Pearson
comparandoasmtricascomaquantidadedefeaturestemseque53,84%(7/13)dos
ndices.QuandocomparadocomosvaloresglobaisdecorrelaovsequeoPOI

tambm acompanha a tendncia de que o acrscimo de features tem uma forte

influncianoaumentooudiminuiodasmtricas.
QuandoanalisadoosdadosisoladosparaoTomcattemseque(7/13)dos
maiores ndicesdecorrelaoestorelacionadosaquantidadedebugscorrigidos.
Analisando as correlaes comparando as mtricas com a quantidade de
desenvolvedores temse que 7,69% (1/13) dos maiores ndices de Pearson.
AnalisandoondicedePearsoncomparandoasmtricascomaquantidadedefeatures
temse que 38,46% (5/13) dos maiores ndices esto relacionado ao aumento da
quantidadefeatures.QuandocomparamoscomosvaloresglobaisvsequeoTomcat
fogeumpoucodopadrodequefeaturestemumaforteinfluncianoaumentoou
diminuiodasmtricas.
Para explicar essa diferena que foi apresentado para o Tomcat ser
verificadoaquantidadedelinhasporprojetos:

Projeto
Tomcat
POI
Jmeter

Quantidade mxima
de Linhas de Cdigo
Quantidade de Linhas
de cdigo
338223
163550
59764
Tabela8:Quantidadedelinhas

Podese verificar que o tomcat tem um maior nmero de linhas entre os

projetoschegandoatermaisque2xonmerodelinhasdoPOIequase6vezesmais
onmerodelinhasqueoJmeter.Comoaquantidadedelinhasnotomcatmaiorfaz
comqueocdigosejamaiscomplexooquepodemosverificarnoseguintegrfico
mostrandoaevoluodacomplexidadeciclomticadeMcCabe:

Complexidade Ciclomtica Tomcat

Figura30:HistoriodacomplexidadeciclomticadoTomcat

ComissoacorreomaiscomplicadanoTomcatlevandoaterumpeso
maiornacorrelaodosbugscomasmtricas.
Umdadointeressantequefoimostradonastabelasdecorrelaoest
relacionadoosndicesdePearsonnegativos:

Mtrica\Projeto
Pearson BUG x
Mtricas
Pearson
Desenvolvedor x
Mtricas
Pearson Feature x
Mtricas

Tomcat
Ciclo de Pacote
-0,978
-0,997
-0,982

Tabela9:ndicedePearson

Estatabelamostramqueparaoprojetotomcatoaumentodacorreode
bugs,oaumentodaquantidadededesenvolvedoreseoaumentodaquantidadede
featuresnoprojetodotomcatapresentouumacorrelaonegativa.Aqualpodeser
vistanosgrficos:

BUG x Ciclo de Pacotes Tomcat

Correcao de bugs

Ciclo de pacotes

Figura31:EvoluodacorreodebugsxMetricadeCiclosdePacote

Feature X Ciclo de Pacote Tomcat

Quantidade de Features

Ciclo de pacotes

Figura32:EvoluodaquantidadedefeaturesxMetricasdeCiclosdePacote

Desenvolvedores x Ciclo de Pacote Tomcat

Quantidade de desenvolvedores
Ciclo de Pacotes

Figura33:EvoluodaquantidadededesenvolvedoresxMetricadeCiclosdePacote

Esses graficos mostra que a troca de verses de 7.20 para 8.0 houve um
esforo muito grande dos desenvolvedores para diminuir a modularidade e
consequentimenteadependenciasdepacotes.

CONCLUSESETRABALHOSFUTUROS
Como foi visto nos correlacionamento e grficos os dados dos softwares
modificammuitoaolongodesuavida.Verificousequeacorrelaodasvariaesda
quantidadedefeaturesteveumpesosignificativonoaumentodasmtricasobtendo
umacorrelaofortepara43,58%doscasos.
Um dado muito interessante obtido nesse estudo foi que na mudana de
versodotomcatde7.xpara8.xhouveumadiminuionadependnciacclicade
pacotesoquesignificaumadiminuiodoacoplamentodoprojeto.Podeseverificar
quehouveumesforoenormenodesenvolvimentodaverso7.xpara8.xdotomcat
ondeverificamosqueaquantidadededesenvolvedores,correodebugseacrscimo
defeaturesaumentarammuitocausandoumaumentodetodasasmtricasmenosda
dependnciacclicadepacotes.
Nestetrabalhopodeseverificarqueacorreodebugsnosistemaumdado
importantenoaumentodasmtricasdosistemas.
Umdospontosnegativosequedeveserfeitoemtrabalhosfuturosaanlise
detodasasversesecommitsdetodosossistemas.Aanlisedemaisprojetosopen
sourcecomofoivistoos3projetosobtiveramomesmopadronascorrelaese
dados, mas devemos variar projetos de outras empresas j que os 3 projetos
escolhidosfazempartedaorganizaoApache.

REFERNCIAS
DOBRICA,L.;NIEMELA,E.Asurveyonsoftwarearchitectureanalysismethods.IEEE
TransactionsonSoftwareEngineering,v.28,n.7,2002.
GALL,H.;HAJEK,K.;JAZAYERI,M.Detectionoflogicalcouplingbasedonproduct
releasehistory.Proceedings.InternationalConferenceonSoftwareMaintenance(Cat.
No.98CB36272),1998.
GODFREY,M.W.;TU,Q.Evolutioninopensourcesoftware:acasestudy.Proceedings
InternationalConferenceonSoftwareMaintenanceICSM94,p.131142,2000.IEEE
Comput.Soc.Press.Disponvelem:<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?
arnumber=883030>..
LINDVALL,M.;TESORIERO,R.;COSTA,P.Avoidingarchitecturaldegeneration:an
evaluationprocessforsoftwarearchitecture.ProceedingsEighthIEEESymposiumon
SoftwareMetrics,2002.
NAGAPPAN,N.;BALL,T.;ZELLER,A.Miningmetricstopredictcomponentfailures.
Proceedingsofthe28thinternationalconferenceonSoftwareengineering.Anais...,ICSE
06..p.452461,2006.ACM.Disponvelem:
<http://doi.acm.org/10.1145/1134285.1134349>..
NAGAPPAN,N.;BALL,T.;ZELLER,A.ObjectOrientedMetricsWhichPredict
Maintainability.ofthe28thinternationalconferenceon,2006.Disponvelem:
<http://eprints.cs.vt.edu/archive/00000347/01/TR9305.pdf>.Acessoem:12/3/2014.
SCHRTER,A.;ZIMMERMANN,T.Ifyourbugdatabasecouldtalk.Proceedingsofthe
5th,p.35,2006.Disponvelem:<http://home.segal.uvic.ca/~pubs/pdf/14/schroeter
isese2006b.pdf>..
SUBRAMANYAM,R.;KRISHNAN,M.S.EmpiricalanalysisofCKmetricsforobject
orienteddesigncomplexity:implicationsforsoftwaredefects.IEEETransactionson
SoftwareEngineering,v.29,n.4,p.297310,2003.Disponvelem:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1191795>..

ANEXOAGRFICOSEVOLUTIVOSDETODOSOSDADOS
COLETADOS.

RFC Tomcat

Quantidade de pacotes tomcat

Ciclos de Pacote Tomcat

NCLOC Tomcat

Quantidade de Linhas Tomcat

Quantidade de Funes Tomcat

Complexidade de Funo Tomcat

Quantidade de arquivos Tomcat

Media da complexidade de arquivos Tomcat

Complexidade Ciclomtica Tomcat

Quantidade de classe Tomcat

Media da complexidade de classe Tomcat

Accessors Tomcat

Quantidade de Desenvolvedores Tomcat

Correo de Bugs Tomcat

RFC Jmeter

Qauntidade de pacotes Jmeter

Ciclo de Pacote Jmeter

NCLOC Jmeter

Quantidade de linhas Jmeter

Quantidade de Funes Jmeter

Complexidade de Funo Jmeter

Quantidade de arquivos

Mdia da complexidade por arquivo Jmeter

Complexidade Ciclomtica Jmeter

Quantidade de classes Jmeter

Media da complexidade por classe Jmeter

Accessors Jmeter
390
380
370
360
350
340
330
320
310

Quantidades Desenvolvedores Jmeter

Quantidade de Features Jmeter

Quantidade de bugs jmeter

RFC POI

Quantidade de pacotes POI

Ciclo de Pacote POI

NCLOC POI

Quantidade de linhas POI

Quantidade de Funo POI

Media da Complexidade de Funo POI

Quantidade de arquivos POI

Media da Complexida de arquivo POI

Complexidade Ciclomtica POI

Quantidade de classes POI

Media da complexidade por classe POI

Accessores POI

Quantidade de Desenvolvedores POI

Correo de Bugs POI

Correo de Bugs POI

Quantidade de Features POI