tcc-v0.6

Anlise comparativa entre mtricas de modularidade e modificaes em cdigo durante a evoluo de sistemas open source

Trabalho de Concluso de CursoCincias da Computao

Anlise emprica comparativa entre mtricas de modularidade e modificaes em cdigo durante a evoluo de sistemas open source

Gabriel de Souza [email protected]

Orientador:Eudisley Gomes dos Anjos

Maro de 2014

Centro de InformticaUniversidade Federal da ParabaGabriel de Souza Rolim

Anlise comparativa entre mtricas de modularidade e modificaes em cdigo durante a evoluo de sistemas open source

Monografia apresentada ao curso Cincias da Computao do Centro de Informtica, da Universidade Federal da Paraba, como requisito para a obteno do grau de Bacharel em Cincias da Computao.

Orientador: Eudisley Gomes dos Anjos

Maro de 2014

Ficha catalogrfica: elaborada pela biblioteca do CI.

Ser impressa no verso da folha de rosto e no dever ser contada.

Centro de InformticaUniversidade Federal da Paraba

Trabalho de Concluso de Curso de Cincias da Computao intitulado anlise comparativa 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 examinadora constituda pelos seguintes professores:

_______________________________________________________________Prof. Dr. ***instituio***



_______________________________________________________________Chefe do Departamento CI/UFPB

Joo Pessoa, 20 de maro de 2014

Centro de Informtica, Universidade Federal da Paraba, Joo Pessoa - Paraba CEP: 58.051-900 Telefone: (83) 3216-7093 Faz: (83) 3216-7117

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.

AGRADECIMENTOSAgradeo primeiramente a Deus que sempre iluminou o meu caminho, me deu foras e sabedoria nessa longa caminhada.A todos os professores que me ensinaram e fizeram com que eu me torna-se o timo profissional que sou hoje.Agradeo por todas as pessoas que cruzaram o meu caminho e me deram fora nessa longa caminhada.

A menos que modifiquemos a nossa maneira de pensar, no seremos capazes de resolver os problemas causados pela forma como nos acostumamos a ver o mundo. (Albert Einstein)

RESUMONeste trabalho verificou como as mtricas de modularidade se comportam atravs do tempo com o acrscimo de funcionalidade, correes de bugs e colaborao de desenvolvedores. Existem vrias pesquisas na rea que procuram achar padres de mtricas de software e o aparecimento de bugs. Neste trabalho foram feitas analises ao longo da vida dos softwares afim de verificar o comportamento das correlaes existentes entre as mtricas e os dados mencionados. Verificamos atravs de minerao de repositrio e analises estatsticas de dados que os dados tem uma grande correlao para a alterao dos valores das mtricas de software.

Palavras-chave: Mtricas de modularidade, Minerao de repositrios, bugs, Evoluo de software.

ABSTRACTThis work verified how the metrics of modularity behave over time with the addition of functionality, bug fixes and developer collaboration. There are several studies in the area looking to find patterns of software metrics and the appearance of bugs. This work analyzes were made throughout the life of software in order to verify the behavior of correlations between metrics and the information contained herein. Looked through repository mining and statistical analysis of data that the data has a high correlation to the changing values of software metrics.

Key-words: Metrics for modularity, Mining repositories, bugs, software evolution.

LISTA DE FIGURASFigura 1: Diagrama de controle de verso local17Figura 2: Diagrama de controle de verso centralizado18Figura 3: Diagrama de controle de verso distribudo19Figura 4: Diretrio de trabalho, rea de preparao, e o diretrio do Git.21Figura 5: Grafos de fluxos de controle de um programa simples.26Figura 6: Formula do coeficiente de correlao de Pearson.27Figura 7: Uma fotografia supostamente do primeiro bug (um inseto real) que foi depurado ("debugado") em 1947. Da o seu uso nos dias atuais.29Figura 8: Passos do script python para obteno dos dados em cada commit.34Figura 9: Evoluo da Correo de bugs Tomcat36Figura 10: Evoluo da Quantidade de Desenvolvedores Tomcat36Figura 11: Evoluo da Quantidade de features Tomcat37Figura 12: Evoluo do valor da metrica de Ciclos de Pacotes Tomcat37Figura 13: Evoluo da Quantidade de Funes Tomcat37Figura 14: Evoluo da Complexidade de Funo de Tomcat38Figura 15: Evoluo da Complexidade Ciclomtica do Tomcat38Figura 16: Evoluo da Quantidade de features POI39Figura 17: Evoluo da Correo de Bugs POI39Figura 18: Evoluo da Quantidade de Desenvolvedores POI40Figura 19: Evoluo do valor da metrica Ciclo de Pacote POI40Figura 20: Evoluo da Quantidade de Funo POI41Figura 21: Evoluo da Complexidade de Funo POI41Figura 22: Evoluo da Complexidade Ciclomtica POI42Figura 23: Evoluo da Quantidade Correo Jmeter42Figura 24: Evoluo da Quantidades Desenvolvedores Jmeter43Figura 25: Evoluo da Quantidade de Features Jmeter43Figura 26: Evoluo do valor da mtrica Ciclo de Pacote Jmeter43Figura 27: Evoluo da Quantidade de Funes Jmeter44Figura 28: Evoluo da Complexidade de Funo Jmeter44Figura 29: Evoluo da Complexidade Ciclomtica Jmeter45Figura 30: Historio da complexidade ciclomtica do Tomcat48Figura 31: Evoluo da correo de bugs x Metrica de Ciclos de Pacote49Figura 32: Evoluo da quantidade de features x Metricas de Ciclos de Pacote49Figura 33: Evoluo da quantidade de desenvolvedores x Metrica de Ciclos de Pacote50

LISTA DE TABELASTabela 1: Classificao dos valores da Correlao de Pearson28Tabela 2: Quadro comparativo entre aplicaes de anlise de mtricas de modularidade.32Tabela 3: Perodo de commits analisados por projeto.35Tabela 4: Quantidade de verses analisadas.35Tabela 5: Correlao de Pearson (BUG x Mtricas)45Tabela 6: Correlao de Pearson (Desenvolvedores x Mtricas)46Tabela 7: Correlao de Pearson (Feature x Mtricas)46Tabela 8: Quantidade de linhas48Tabela 9: ndice de Pearson49

LISTA DE ABREVIATURASSIGLA NOME COMPLETO OOOrientado a ObjetoVCSVersion Control SystemDVCSDistributed Version Control SystemOSDOpen source definitionMRminerao de repositriosAPIApplication Programming InterfaceADLLinguagem de descrio de arquiteturaRFCReponse for classesIDEIntegrated Development Environment

SUMRIO1Introduo131.1Estrutura da monografia142Trabalhos Relacionados153Referencial Terico163.1Controle de verso163.1.1Controle de verso Local163.1.2Controle de verso centralizado173.1.3Controle de verso distribudo183.2GIT193.3Open Source Software213.4Minerao de Repositrios233.5Mtricas de modularidade243.5.1Tamanho de Cdigo253.5.2Estrutural253.6Correlao de Pearson263.7Bug283.7.1Tipos comuns de Bugs294Metodologia315Apresentao e anlise dos Resultados365.1Evoluo do Tomcat365.2Evoluo do POI395.3Evoluo Jmeter425.4Estudo da Correlao de Pearson dos dados456Concluses E TRABALHOS FUTUROS51Referncias52Anexo A GRficos evolutivos de todos os dados coletados.53

12

Introduo

Inicialmente os sistemas computacionais eram desenvolvidos de forma estrutural, sem nenhum ou pouco gerenciamento. Esses sistemas, com o passar dos anos, tornarvam-se cada vez mais difceisil e complexos de se manter-se. Por isso, Eesses sistemas, aos poucos, comearam a introduzir um melhor gerenciamento melhor do projeto. , Pprogramas foram quebrados em mdulos, objetos, aspectos, etc. Com isso facilitou o acrscimo de novas features, modificaes em cdigo, correes de bugs e assim facilitando tambm a manuteno desses sistemas.Comment by Eudis Anjos: H muita informaoo em um pargrafo s. Primeiro voc inicia dizendo sobre compexidade dos sistemas, depois passa a falar de mdulos e depois de bugs. Eu dividiria esse pargrafo em dois juntando com o segundo que diz a mesma coisa.Em grande sistemas natural que apaream dificuldades no entendimento dos problemas. E para isso a definio dividir para conquistar usado em algoritmos para que cada vez mais os algoritmos sejam mais simples e fcil de se entender. Assim diminuindo o esforo na manuteno do sistema.Quanto maior o nvel de diviso dos mdulos do sistema maior ser a qualidade e a facilidade de manuteno. PortantoPensando nisso, a modularidade pode ser vistose configura como um importante atributo de qualidade que deve ser levado em considerao durante o desenvolvimento de sistemas. Para que seja avaliada, a modularidade possui diversas mtricas de software que ajudam na determinao do ne assim como os outros atributos pode ser avaliado atravs de mtricas de modularidade.Comment by Eudis Anjos: Tem certeza? Ento um programa que tem 12673517356712531765351276537612 de mdulos ser mais fcil de manter do que um que s tem um mdulo? Se isso verdade coloque a referencia de quem disse isso!QUANDO SE ESCREVE UM TEXTO, DEVE-SE TER COESO ENTRE O QUE EST FALANDO. POR EXEMPLO, SE VOC TERMINA AQUI FALANDO SOBRE MTRICAS O PRXIMO PARGRAFO DEVE CONTINUAR SOBRE ISSO. VOC PARA AQUI, FALA SOBRE OPEN-SOURCE, DEPOIS OUTRO PARGRAFO SOBRE O DESENVOLVIMENTO DISTRIBUDO E DEPOIS VOLTA PARA MTRICAS.... NECESSRIO COESO TEXTUAL OU QUEM L NO ENTENDE O QUE VOC QUER DIZER. Cada vez mais cresce o nmero de projetos onde o seu cdigo aberto para qualquer desenvolvedor. Desta forma a evoluo do cdigo e a qualidade do mesmo evoluem muito rpido. Este tipo de software chamado Open Source.Esses sistemas so mantidos muitas vezes por vrios desenvolvedores espalhados pelo mundo. Utilizam para troca de informaes fruns, wiki, chats e e-mails. O que se mostra meios eficientes de comunicao e obteno de dados.As mtricas de modularidade ajudam a garantir uma qualidade nos sistemas. Existem vrias mtricas de modularidade na literatura que ajudam na garantia do padro de 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 corrigidos por um determinado perodo de tempo. , Aa quantidade de desenvolvedores que contribui para o acrscimo de novas funcionalidades durante uma verso e a quantidade de novas funcionalidades acrescentadas no software. Essas medidas no ajudam na garantia da qualidade dos sistemas, mas nos proporcionam um melhor entendimento das caractersticas do software. Ento medidas de software podem ter uma relevncia para o aumento ou diminuio dos valores das mtricas de modularidade que garantem a qualidade do sistema.Comment by Eudis Anjos: No entendiComment by Eudis Anjos: Quais medidas?????Comment by Eudis Anjos: Quais?Comment by Eudis Anjos: Ento.... voc conclui isso a partir de que? A partir de que elas proporcionam o entendimento de caractersticas? No entendi como... De verdade mesmo, no entendi o que voc quer dizer aqui.Com a evoluo dos projetos a quantidade de correes de bugs, quantidade de desenvolvedores e acrscimo de novas features pode aumentar ou diminuir ao longo do desenvolvimento do software que so mtricas de software. Como o aumento e diminuio das mtricas de software influenciam nas mtricas de modularidade? Ser que elas tem um correlacionamento com o aumento ou diminuio dos valores das mtricas? E se elas ajudam a aumentar ou diminuir os valores das mtricas de modularidade quais suas caractersticas?Comment by Eudis Anjos: O desenvolvimento do software so mtricas de software? ACHO QUE NOComment by Eudis Anjos: Como uma mtrica aumenta ou diminui?Neste trabalhos iremos fazer um estudo das mtricas de modularidade e mtricas de software. Neste estudo procuramos estudas como as mtricas de modularidade correlacionam com as mtricas de software. E assim mostrar a relevncia dessas medidas de software.Comment by Eudis Anjos: Pegar o ltimo pargrafo da introduo do artigo. Ficou perfeito e cabe muito bem aqui!Estrutura da monografia

Este trabalho est dividido em 5 captulos alm da introduo. No captulo 2 falamos sobre os trabalhos relacionados na rea e o que motivou o desenvolvimento desses trabalho. No captulo 3 apresentamos o referencial terico com conceitos e definies. No captulo 4 mostramos a metodologia utilizada, como conseguimos gerar os dados necessrios. No captulo 5 apresentamos os resultados obtidos visualizando atravs de grficos e tabelas. No captulo 6 realizado a concluso do trabalho atravs das anlises dos grficos e tabelas obtidos.

Trabalhos RelacionadosAo comear minhas pesquisas na rea de mtricas de modularidade alguns trabalhos (SCHRTER; ZIMMERMANN, 2006)(NAGAPPAN, NACHIAPPAN et al., 2006), Comment by Eudis Anjos: Faltou terminar essa frase?Em (NAGAPPAN, NACHIAPPAN et al., 2006) iniciado um estudo em cinco programas da Microsoft para a identificao de falhas de programas atravs das mtricas de software. No foi possvel identificar uma correlao significativa entre alguma mtrica de modularidade e a presena de falhas no sistema. No segundo trabalho (SCHRTER; ZIMMERMANN, 2006) ele d continuidade ao trabalho de (NAGAPPAN, NACHIAPPAN et al., 2006) trabalhando o aparecimento de bugs antes e depois do lanamento da verso 3.0 do eclipse, no trabalho ele correlaciona as mtricas de modularidade com a densidade de bugs encontrado antes de depois da verso. Alm disso ele correlaciona o aparecimento de bugs com a quantidade de desenvolvedores antes e depois do lanamento da verso. Em outro trabalho (SUBRAMANYAM; KRISHNAN, 2003) foram analisados projetos de linguagens diferentes verificando se existiam correlaes entre as mtricas de modularidade e o aparecimento de bugs. No trabalho no foi possvel verificar um padro entre as linguagens do aparecimento de bugs e as mtricas analisadas, mas foi verificado que algumas mtricas de modularidade correlacionam com o aparecimento de falhas no sistema.Nos projetos anteriores so propostos vrios melhoramentos de seus trabalhos em (SCHRTER; ZIMMERMANN, 2006) prope uma anlise mais prolongada do projeto, analisar mais de uma verso do sistema. Em (NAGAPPAN, NACHIAPPAN et al., 2006) prope a utilizao de mais mtricas, mais verses e com a mesma linguagem de programao.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 principais mtricas de modularidade com a quantidade de bugs corrigidas por verso, a quantidade de desenvolvedores colaborados por verso e a quantidade de features adicionadas ao longo do desenvolvimento do sistema.Referencial Terico

Neste capitulo so apresentados conceitos e definies importantes para o desenvolvimento do trabalho. Destacam-se controle de verso, Git, Open Source Software, minerao de repositrios, mtricas de software, mtricas de modularidade, correlao de Pearson e Bug.Controle de verso

O que controle de verso, e por que desenvolvedores acham importante a utilizao? Controle de verso um sistema que armazena as alteraes feitas em um arquivo ou conjunto de arquivos ao longo do tempo de forma que voc consiga recuperar verses 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 System ou c) uma sabia deciso. Ele permite a recuperao de qualquer estado de arquivo no desenvolvimento do seu projeto, recuperar o estado de um projeto inteiro, fazer comparaes feitas ao longo do tempo, verificar as ltimas modificaes que ocasionaram o aparecimento de algum erro. Usar um VCS significa que se aconteceu algum problema no projeto ou houve perde de arquivos, poder facilmente recupera-los. Alm disso, o gerenciamento do projeto fica muito mais fcil.Existem praticamente trs mtodos para se fazer um sistema de controle de verso: controle de verso Local, controle de verso centralizado, controle de verso distribudo.Controle de verso LocalO mtodo preferido de controle de verso por muitas pessoas a criao de vrias pastas com as verses dos arquivos. a forma mais simples de versionamento de arquivos, mas muito suscetvel a erros. muito fcil esquecer onde foi guardado o arquivo ou gravar um arquivo em um diretrio errado sobrescrevendo o arquivo anterior.

Figura 1: Diagrama de controle de verso localControle de verso centralizadoUm grande problema identificado nos projetos era quando vrios desenvolvedores desejavam trabalhar em conjunto com outros desenvolvedores, que utilizam outros VCS. Para solucionar isso foi criado um dos mtodos mais utilizados nos VCS o controle de verso centralizado. Neste mtodo foi desenvolvido um servidor centralizava o armazenamento de todas as modificaes de arquivos feito no sistema e agora cada desenvolvedor poderia resgatar (check out) os arquivos do servidor.

Figura 2: Diagrama de controle de verso centralizadoEste mtodo oferece vrias vantagens, especialmente sobre o mtodo de verso local. Agora todo mundo tem um conhecimento razovel sobre o que os outros desenvolvedores esto fazendo no projeto. Administradores do sistema o controle do que cada desenvolvedor deve fazer.Entretanto este mtodo oferece falhar, pois tudo est centralizado no servidor central. Se este servidor ficar fora do ar ou tiver problemas no sistema de arquivos, na melhor das hipteses os desenvolvedores ficaram sem trabalhar pelo perodo que o servidor ficar fora do ar. E em um problema mais grave o servidor pode corromper o seu sistema de arquivo e assim perder todo o histrico de modificaes do projeto.Controle de verso distribudoE ento surge os sistemas de controle de verso distribudo. Nesses sistemas os clientes no copiam apenas as ltimas verses dos arquivos: eles so copias completas do repositrio. Desta forma, se o servidor central falhar, qualquer um dos repositrios locais dos clientes pode ser copiado de volta para o servidor e assim restaura todo o projeto. Cada checkout o resgate do repositrio completo com todos os dados.

Figura 3: Diagrama de controle de verso distribudoAlm 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 possveis em sistemas centralizado, por exemplo, uso de hierarquia.GIT

O GIT foi desenvolvido a partir da necessidade sentida no processo de desenvolvimento do kernel do Linux. Entre 1991 e 2002 o Linux era distribudo atravs de patch e arquivos compactados. Em 2002, o projeto do kernel do Linux comeou a utilizar o sistema DVCS (Distributed Version Control System) proprietrio chamado BitKeeper.Em 2005, o relacionamento entre os desenvolvedores do Linux e a empresa que desenvolvia comercialmente o BitKeeper se desfez, e o status de isento-de-pagamento da ferramenta foi revogado. Isso fez com que a comunidade desenvolvedora do Kernel do Linux (Em particular Linus Torvalds, o criador do linux) a desenvolver sua prpria ferramenta baseado na experincia obtida atravs do BitKeeper.Os objetivos para a criao do novo sistema foram: Velocidade Designer simples Suporte robusto ao desenvolvimento no linear Totalmente distribudo Capaz de lidar com grandes projetos.Desde 2005 o Git evoluiu e amadureceu a ponto de ser um sistema fcil de usar e ainda assim matem essas qualidades iniciais. rpido, eficiente pra grandes projetos e possui um timo sistema de branching para o desenvolvimento no-linear.O Git classifica os arquivos em trs estados fundamentais: consolidado (Commited), modificado (modified) e preparado (staged). Dados so tidos como consolidados quando esto armazenados na base de dados local. Modificado quando um arquivo sofreu alteraes mas ainda no foi consolidado na base de dados. Um arquivo tido como preparado quando voc adiciona o arquivo para fazer parte de uma consolidao (Commited).

Figura 4: Diretrio de trabalho, rea de preparao, e o diretrio do Git.O workflow bsico do Git pode ser descrito assim:1. Voc modifica arquivos no seu diretrio de trabalho.2. Voc seleciona os arquivos para fazer parte do commit.3. Voc faz o commit, que armazena os arquivos como eles esto na base de dados local.

Open Source Software

O termo Open Source dado a sistemas que podem ser livremente usados, alterados e compartilhados (Modificados ou no) por qualquer um. Open Source Software mantido por vrias pessoas e distribudo sob licenas que estejam em conformidade com a definio Open 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 in-house como o projeto proprietrio para futuramente serem liberados como Open Source ou com uma licena que d toda a liberdade de uso do sistema. Um exemplo foi o Netscape web browser (ou seja, O projeto do Mozilla), o compilador Java Jikes da IBM e o Kilt de desenvolvimento Java da Sun que hoje foi comprado pela Oracle.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 desenvolvedores e o desenvolvimento prossegue. Normalmente qualquer um pode contribuir para o desenvolvimento do sistema, mas cabe ao dono do projeto decidir qual contribuidor pode ou no se torna parte do lanamento oficial do projeto.O desenvolvimento do modelo open Source (OSD) diferente dos processos tradicionais de desenvolvimento comercial in-house em vrios aspectos fundamentais. Em primeiro lugar, o objetivo principal de um projeto Open source criar um sistema que seja til ou interessante para aqueles que esto trabalhando nisso, no para suprir uma carncia comercial.Desenvolvedores so frequentemente voluntrios no remunerados que contribuem para o projeto como um hobby, em troca, eles recebem o reconhecimento da comunidade e satisfao pessoal por seus esforos. As vezes isso significa que grande parte dos esforos em um projeto OSD concentra-se no que os programadores acham interessante em fazer na sua parte do tempo, ao invs de fazer o essencial. Pode ser difcil direcionar o projeto para o objetivo especifico j que o dono do projeto no tem poder sobre os desenvolvedores que contribuem. Esta liberdade tambm significa na dificuldade de convencer os desenvolvedores para executar tarefas essenciais, tais como testes sistemticos ou reestruturao de cdigo, que no so to emocionantes como a escrita de um novo cdigo.Outras caractersticas notveis de desenvolvimento de cdigo aberto incluem (GODFREY; TU, 2000): Agendamento: geralmente h pouca presso comercial para manter qualquer prazos difceis, e na maioria desenvolvedores OSD tem day Jobs que ocupa a maior parte do tempo do desenvolvedor. Embora isso possa implicar em ciclos de desenvolvimentos mais longos, esta tambm uma vantagem, pois projetos OSD esto em grande parte imune a presses time-to-market, uma verso do sistema no lanada at que o proprietrio do sistema esteja convencido que o software est estvel e maduro. Qualidade de cdigo e padres podem variar muito: Como o cdigo uma contribuio fica difcil insistir em padres particulares, apesar de que muitos projetos tem guias oficiais de desenvolvimento em seus sites. Cdigo instvel comum: Alguns projetos OSD referncia suas modificaes a duas linhas principais de desenvolvimento: a liberao de desenvolvimento que contem novas funcionalidade (feature) experimentais e uma liberao estvel que contm a maioria das atualizaes e correes de bugs da ltima verso estvel. Planejamento evolutivo, testes e preveno de manutenibilidade pode sofrer, pois os desenvolvedores so encorajados a participar ativamente sem necessariamente ter uma cuidadosa reflexo e reorganizao. A qualidade do cdigo mantido em grande parte por depuraes massivamente paralelas (ou seja, vrios desenvolvedores cada um utilizando o cdigo do outro), em vez de ter um sistema de teste.Minerao de Repositrios

Repositrios de cdigo-fonte possui um riqueza de informaes que no s uteis para a gesto e construo de cdigo-fonte, mas tambm como um registro detalhado de como o cdigo-fonte tem evoludo durante o desenvolvimento. Se um pedao do cdigo-fonte refatorado, a evidencia disto ser armazenada no repositrio. O estado do cdigo pr e ps-refatorao estar presente no repositrio. Assim como as correes de bug, modificaes feitas para corrigir o problema so gravadas. Assim como novas APIs so adicionadas ao cdigo, a maneira correta de usa-las implicitamente explicadas no cdigo. O desafio, ento, desenvolver ferramentas e tcnicas que automaticamente extraiam e use essas informaes.A minerao de repositrios (MR) tem vrios campos de anlise para ligar os ricos dados presentes nos repositrios de software para descobrir informaes interessantes e acionveis sobre os sistemas de software e projetos. Exemplos de repositrios de software: Repositrios histricos: Como repositrios de controle de cdigo, repositrios de bugs e arquivos de comunicao. Repositrios de Tempo de execuo tais como registro de implantao que contm informaes sobre a execuo e a utilizao da aplicao em um simples ou mltiplos locais de implantao. Repositrio de cdigos como o Sourceforge.net e Google Code que contm vrios cdigos de vrias aplicaes desenvolvida por vrios desenvolvedores.Repositrios de software so comumente usados na pratica como repositrios de armazenamento. Por exemplo, repositrios histricos que utilizam rastreamento de histrias de bugs ou features, mas no so usados comumente para determinar o tempo de resoluo esperada entre a abertura de um bug e a resoluo do mesmo.Pesquisadores MR visam transformar esses repositrios de armazenamento em repositrios ativos que podem orientar os processos de deciso em projetos de software modernos. Minerar repositrios histricos, tempo de execuo e cdigos, podemos descobrir padres e informaes uteis. Repositrios histricos captura importante dependncias histricas (GALL et al., 1998) entre os artefatos de projeto, tais como funo, arquivos de documentao ou arquivos de configurao. Desenvolvedores podem usar essas informaes para propagar alteraes para artefatos relacionados, em vez de apenas usar as dependncias de cdigo esttica ou dinmicas que podem deixar de capturar dependncias importantes. Por exemplo, uma alterao no cdigo que escreve dados em um arquivo e que pode exigir alteraes no cdigo que l os dados deste arquivo, embora no exista nenhuma ligao entre os dois pedaos de cdigo.Para os repositrios de tempo de execuo ele poderiam ser usados para identificar anomalias de execuo, identificar, padres de uso atravs de implantaes e sinalizaes. Repositrios de cdigo poderia ser usados para identificar o padro de uso correto e dominante das bibliotecas minerando seu uso atravs de muitos projetos.

Mtricas de modularidade

A modularidade tem vindo a desempenhas um papel muito importante nos estgios iniciais do designer do software. Os engenheiros de software consideram modularidade como um princpio chave quando se compara alternativas de arquitetura e anlise de degenerao de arquitetura (LINDVALL et al., 2002). Na verdade, os engenheiros de software so promovidos para projetas boas arquiteturas, baseando-se em uma infinidade de mecanismos de modularidade disponvel:1. Linguagem de descrio de arquitetura (ADLs), tais como o ACME.2. Os catlogos de estilos arquitetnicos3. Como bem sabemos dos mais altos princpios de designer, tais como interfaces estreitas, reduo do acoplamento da arquitetura e afins.No entanto, a confiana nesse mecanismos de arquitetura no suficiente para alcanar projetos de arquitetura verdadeiramente modulares. Alm disso, a avaliao e melhoramento da modularidade de inicial do projeto ainda mais desafiador. So necessrios tcnicas de avaliao quantitativa para avaliar e controlar as diferentes arquitetura.Mtricas de software so um poderoso meio para fornecer indicadores de modularidade de projetos de arquitetura (DOBRICA; NIEMELA, 2002). A comunidade de mtricas de software tem constantemente usado noes como mdulos de acoplamento e coeso para derivar medidas de qualidade da arquitetura de software.As mtricas de software podem ser separadas mas seguintes reas:1. Tamanho de cdigo.2. EstruturalTamanho de CdigoCdigo pode ser produzido de vrias formas. A forma mais utilizada orientado a objeto que deixa as mtricas tradicionais mais difceis.Temos como mtricas tradicionais: Nmero de linhas de cdigo. Existe um grande problema no clculo das linhas pois muitos programas utilizam documentaes, comentrios, linhas em branco em seus cdigos e isso trabalha nesta medida. Para resolver este problema temos o nmero de linhas no comentados na qual so retirados da contagem aos comentrios e as linhas em branco do cdigo. Nmero de funes. possvel avaliar o quanto de funcionalidades um software pode oferecer para o usurio. Pois cada funo tem a implementao de um algoritmo que realiza um trabalho para o usurio. Nmero de Classe. Esta mtricas nos permite verificar o quanto um projeto est modularizado e menos complexo. O conceito de classe veio para melhorar o entendimento do cdigo assim melhorando a manuteno, aumentando a modularidade e diminuindo a complexidade do software. Nmero de arquivos. Com esta mtricas permitido saber o tamanho do projeto e a complexidade do mesmo. Quanto mais arquivos mais os cdigos esto distribudos e desta forma fica cada vez mais difcil localizar onde foi implementado determinada funcionalidade.EstruturalEm cdigos orientados a objeto importante que o cdigo seja cada vez mais dividido em mdulos. As mtricas estruturais iram mensurar, medir a interligao de mdulos com outros mdulos. Para uma baixa complexidade importante que os mdulos sejam coesos e no dependam de outros mdulos.As mtricas estruturais so: Complexidade de McCabe. Esta mtrica calcula atravs de gerao de grficos de fluxos a quantidade de caminhos independentes pelo cdigo. Atravs da formula:M = E N + 2 x PEm que: M Complexidade ciclomtica E Quantidade de setas N quantidade de ns P quantidade componentes conectados.

Figura 5: Grafos de fluxos de controle de um programa simples.Na figura 5.a temos um programa simples. O programa comea no n vermelho e termina no n azul. Para o grafo 5.a, E=9, N =8 e P=1, resultando numa complexidade ciclomtica de 3. Para o grafo 5.b, E = 10, N=8 e P=1, ento resultando numa complexidade ciclomtica de 4. Response for Classes (RFC). Calcula a cardinalidade das chamadas das classes (NAGAPPAN, N et al., 2006). A chamada das classes consiste em todos os mtodos locais e todos os mtodos chamados por mtodos locais. logico que quanto maior o RFC, mais complexo ser a classe e assim mais difcil ser manter a classe. Dependncia cclica de Pacotes: Esta mtrica informa a medida das dependncias de pacotes do Projeto. Quanto maior o valor desta mtricas maior o acoplamento do software.Correlao de Pearson

Tem-se uma varivel estatstica bidimensional quando, relativamente a cada elemento da populao, se observa e estuda duas caractersticas distintas. Para as variveis estatstica X e Y, a varivel estatstica bidimensional representado por (X, Y).Para a observao de como os valores dessas duas variveis evoluem criado um diagrama de disperso, ou nuvem de pontos, o conjunto dos pontos do tipo (x, y) representados num referencial, onde x e y so os valores observados das variveis X e Y, respectivamente.Quando tomamos as variveis duas a duas podemos verificar o que sucede a uma varivel X quando outra varivel Y varia. Existe correlao linear quando possvel ajustar nuvem de pontos numa reta.O coeficiente de correlao de Pearson a intensidade da associao linear existente entre as variveis pode ser quantificada atravs do chamado coeficiente de correlao linear de Pearson:

Figura 6: Formula do coeficiente de correlao de Pearson.Onde: Cxy- Covarincia ou varincia conjunta das variveis X e Y; Sx Desvio padro da varivel X; Sy Desvio padro da varivel Y;

(a) (b) (c)Figure 9: Grficos com possveis valores para X e YNa Figura 9.a temos variveis positivamente correlacionada. No limite, isto , se a correlao for perfeita como e o caso se considerarmos a correlao da varivel x consigo prpria o coeficiente de correlao ser igual a 1. Na figura 9.b as variveis esto negativamente correlacionadas. No limite, isto , se a correlao for perfeita o coeficiente de correlao ser igual a -1. Na figura 9.c as variveis so esto correlacionadas. No limite, isto , em caso de absoluta independncia o coeficiente de correlao ser igual a 0.Para os valores do Coeficiente de correlao podemos classific-los da seguinte forma:Coeficiente de correlaoCorrelao

r = 1Perfeita positiva

0.8 r < 1Forte positiva

0.5 rModerada positiva

0.1 rFraca positiva

0 < r < 0.1Intima positiva

0Nula

-0.1 < r < 0Intima negativa

-0.5 < r -0.1Fraca negativa

-0.8 < r -0.5Moderada negativa

-1 < r -0.8Forte negativa

r = -1Perfeita negativa

Tabela 1: Classificao dos valores da Correlao de PearsonBug

Um bug uma palavra inglesa que significa inseto. Este termo geralmente usado em informtica quando encontrado um erro em algum programa, ou seja, quando algum programa age de maneira inesperada ou fora do comum. Ento, bug um erro no funcionamento de um software, podendo causar comportamentos inesperados e indesejados. Geralmente eles so causados por erros do prprio cdigo-fonte, mas podem ser causados tambm por algum compilador, sistema operacional ou framework.O termo bug foi muito citado no ano de 1999 quando se esperava que acontecesse o chamado bug do milnio. Na poca, as empresas ainda usavam sistemas antigos com recursos escassos desenvolvidos nos anos 80, ento muitos programadores tratavam nos programas que utilizavam datas apenas dois dgitos, assim "1991" era tratado como "91". O grande receio dos desenvolvedores que os sistemas pudessem confundir o ano 2000 com o ano 1900, se realmente ocorresse esse erro os clientes de bancos iriam ver suas aplicaes com juros negativos e os futuros boletos de cobrana teriam 100 anos de atraso. Outro susto que sistemas militares que controlavam arsenais de guerra pudessem falhar causar acidentes. Nada passou de um grande alarde sem fundamentos j que a maior parte desses softwares j previa a virada e tinham tcnicas de compensao prprias. Logo, o bug do milnio era inofensivo.

Figura 7: Uma fotografia supostamente do primeiro bug (um inseto real) que foi depurado ("debugado") em 1947. Da o seu uso nos dias atuais.Os Bugs podem causar tanto problemas inofensivos como falhas de segurana. A principal porta de entrada para que ocorram essas falhas a utilizao de programas que se conectam a internet, clientes de e-mail e navegadores. Crackers podem ter acesso aos arquivos presentes no computador infectado, e divulgar para outras pessoas atravs da internet. Assim, deve-se tomar cuidado em programas na verso beta, ou seja, programas em desenvolvimento, sendo estes mais vulnerveis a esse tipo de ataque.Os bugs podem surgir em qualquer estgio do desenvolvimento de um software. Muitos deles so causados por erros da equipe de desenvolvimento e so resultados da falha do homem em lidar com a complexidade dos sistemas de software. Estes sistemas chegam a possuir milhares de arquivos no seu cdigo-fonte, onde cada arquivos possui centenas de linhas de cdigo.

Tipos comuns de BugsOs bugs podem ser classificados da seguinte maneira: Bugs Aritmticos. So bugs relacionados a operaes matemticas como diviso por zero, estouro de armazenamento de valor da varivel, perca de preciso numrica. Bugs lgicos. So bugs relacionados a lgica de programao. Como a implementao de loops infinitos e recurso infinita. Bugs sintticos. So bugs relacionados a linguagem de programao. Como em algumas linguagens x=5 ir atribuir o valor 5 a varivel x enquanto que x == 5 ir checar se o valor 5. Bugs de recurso. So Bugs relacionados a acessos de memria invlidos como referncia para ponteiro nulo, utilizar variveis no inicializadas, buffer overflow. Bugs de programas multi-thread. So bugs que esto relacionado a deadlock onde um processo fica esperando outro processo liberar o recurso compartilhado e nenhum dos dois libera esse recurso causando assim uma parada geral do sistema. Bugs de interface. So bugs relacionado ao incorreto uso de uma API, implementaes incorretas de protocolos. Bugs de performance. So bugs relacionados a algoritmos de alta complexidade computacional, acesso randmico a discos e memria. Bugs de Grupo de desenvolvedores. So bugs encontrados nas mudanas feitas por programadores como atualizaes inapropriada no cdigo como a alterao do nome de uma funo utilizada em vrias parte do sistema e por outros programadores. Diferenas entre a documentao e o estado atual do software.MetodologiaNeste trabalho ser realizado uma anlise estatsticas atravs do uso do coeficiente de Pearson entre as mtricas de modularidade e as medidas de quantidade de bugs corrigidos, quantidade de funcionalidades adicionadas e a quantidade de desenvolvedores.Como foi explicado no capitulo 3.1 os sistema de versionamento de software guardam todo tipo de informao especifica do software. Informaes muito valiosas que atravs da minerao de repositrio podem ser analisadas e assim retirar padres dessas analises.Para o nosso estudo procuramos projetos Open Source, escritos em Java, com sistema de versionamento de cdigo de preferncia o GIT, tivessem um mecanismos de compilao automtica via linha de comando, tivessem um repositrios de Bug como por exemplo o bugzilla e fossem projetos de sucesso.Verificando o site oficial do bugzilla(http://www.bugzilla.org/) foi possvel identificar os principais projetos que utilizavam o bugzilla como repositrios de Bug e que eram Open Source. Os principais Projetos apresentados no site oficial do bugzilla so: Mozilla: https://bugzilla.mozilla.org/ Linux Kernel: http://bugzilla.kernel.org/ Gnome: http://bugzilla.gnome.org/ KDE: http://bugs.kde.org/ Apache Project: http://issues.apache.org/bugzilla/ Open Office: http://www.openoffice.org/issues/query.cgi Eclipse: http://bugs.eclipse.org/bugs/Aps a anlise desses projetos verificando a possibilidade de compilao automtica, utilizao de repositrios de versionamento Git selecionamos projetos da Apache Project. Os softwares selecionados deveriam ser de grande sucesso, ter mais que 10 mil commits e que esto em pleno desenvolvimento. Os Softwares selecionados foram:1. Tomcat. uma implementao open source de java Servlet e JavaServer Pages Technologies.2. POI. O apache POI tem a misso de criar e manter APIs java para a manipulao de vrios arquivos de formatos baseado no the Office Open XML standards (OOXML) e componentes Microsofts OLE 2.3. Jmeter. uma aplicao java feita para fazer teste funcionais e calcular medidas de performance.Com os projetos selecionados foram feitos os check out dos repositrios GIT de cada projeto: POI: https://github.com/apache/poi Jmeter: https://github.com/apache/jmeter Tomcat: https://github.com/apache/tomcatPara fazer o download do repositrios git muito simples basta instalar o Git em sua mquina, na internet muito fcil de encontrar tutoriais que explicam a instalao do Git para vrias plataformas, e utilizar o comando:git clone link_do_repositorio_gitPor exemplo para baixar o repositrios dos projetos acima os comandos so: Tomcat git clone https://github.com/apache/tomcat.git Jmeter git clone https://github.com/apache/jmeter.git POI git clone https://github.com/apache/poi.gitComo o intuito deste trabalho analisar as mtricas de modularidade foi necessrio selecionar um software de anlise de mtricas de modularidade dos sistemas. Ento pesquisamos na internet vrios programas que fazem analise de mtricas, so eles:

MetricMinerSonarEclipse MetricsKalibro e AnalizoMezuroEvoltrackArchViewCodeCityOceano

Aplicao webXX-X----X

Interface de consulta aos dados mineradosX--------

Clculo de mtricas de cdigoXXXXX-XX

Processamento de cdigo em texto puro (no compilado)XX-XX----

Interface grfica de visualizao dos dados-X---XXXX

Processamento de repositrios GITX---X----

Tabela 2: Quadro comparativo entre aplicaes de anlise de mtricas de modularidade.Dentre os projetos o MetricMiner e o mesuro tem processamento de repositrios GIT, mas no possuem interface grfica o que dificulta a visualizao dos dados. O Sonar e outros 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 mtricas de tamanho do software. O eclipseMetrics apenas utilizado atravs do eclipse e para este trabalho necessrio que o programa no necessite de uma IDE, pois queremos gerar os dados automaticamente. E com uma IDE isso fica invivel e trabalhoso.Portanto dentre todos os softwares de analises de mtricas de modularidade o SonarQube foi o escolhido para ser utilizado neste projeto. O SonarQube uma plataforma aberta de gerenciamento de qualidade de cdigo. Cobrindo os 7 eixos da qualidade de software:1. Arquitetura e design2. Comentrios3. Regras de Cdigo4. Potencialidade de bugs5. Complexidade6. Testes Unitrio7. Duplicidades.Faz anlise de mais de 20 linguagens de programao entre elas: Java C# C/C++ PL/SQL COBOL PythonSonarQube baseado em uma aplicao web. Regras, alertas, excluses, configuraes e etc. pode ser configurados online. Sonar tambm integra com os principais sistemas de gerenciamento de dados como: MySQL, PostgreSQL, Oracle entre outros.Para comear a trabalhar com o sonar preciso fazer o download de 2 projetos: SonarQube (verso 3.7.4) SonarRunner (verso 2.3)Primeiramente rodamos o SonarQube atravs de um script que est no prprio projeto do Sonar. Para iniciar o servidor bastar rodar:./sonar.sh consoleO sonarRunner o programa que vai fazer a anlise do cdigo e enviar os dados para o SonarQube armazenar na base de dados. Neste configuramos o SonarQube para trabalhar com o PostgresSQL 9.1, para isso basta procurar o arquivo de configuraes do SonarQube e configura-lo para trabalhar com o conector pgsql. Para o sonarRunner fazer a anlise dos projetos preciso configurar um arquivo chamado sonar-projetct.properties segue um exemplo do que se deve ser colocado neste arquivo:

# Required metadatasonar.projectKey=jmetersonar.projectName=jmetersonar.projectVersion=3.7 # Comma-separated paths to directories with sources (required)sonar.sources=src/core# Languagesonar.language=java# Enconding of the source filessonar.sourceEnconding=UTF-8sonar.binaries=build/core

O Comando sonar.language informa qual linguagem ser analisada, sonar.sources informa caminho para o diretrio onde est o cdigo a ser analisado e sonar.binaries informa onde esto os arquivos compilado dos sistema. Feito isso basta chamar no mesmo diretrio onde foi criado este arquivo o comando para execuo do sonarRunner.Como o SonarQube no interage com repositrios GIT e no faz compilaes automatizadas dos cdigos foi necessrio a criao de um script em python para fazer o processo de modificao das verses do cdigo por comando GIT, compilar os projetos para gerar os binrios necessrios ao sonar para conseguir analisar algumas mtricas estruturais do cdigo. Os passos utilizados para a obteno dos dados foram:

Figura 8: Passos do script python para obteno dos dados em cada commit.Como cada projeto selecionado existem mais de 10.000 commits e o programa foi executado em um perodo de 48 horas, para uma maior abrangncia de verses possveis nessas 48 horas foram feitos pulos de 6 commits. Foram analisado para cada projeto os seguintes perodos de commit:

ProjetoPerodo

Jmeter7/10/2010 12/10/2012

POI8/5/2008 9/2/2014

Tomcat21/11/2010 9/2/2014

Tabela 3: Perodo de commits analisados por projeto.Nestes perodos foram possveis analisar as seguintes quantidades de verso:

ProjetoQuantidade de verses

Jmeter22

POI41

Tomcat18

Tabela 4: Quantidade de verses analisadas.O Script python alm de fazer os processos citados anteriormente ele obtm do repositrios informaes sociais, das mensagens do commit retira informaes se o commit foi de uma correo de bug ou uma features. Nesta identificao foi utilizado nas mensagens um expresso regular para localizar a ocorrncia da palavra bug nos commits e tudo o que no tinha a palavra bug foi considerado como adio de funcionalidade ou feature.Todos esses dados foram tratados e colocado em um repositrio de dados. Ento foram feitas consultas para retirada dos dados e colocados em tabelas do Excel.O ltimo programa utilizado neste projeto foi o IBM SPSS. Com o IBM SPSS foram utilizado os dados das tabelas em Excel para fazer o clculo da correlao de Pearson. O software se mostrou muito prtico e rpido para fazer o correlacionamento dos dados.Apresentao e anlise dos ResultadosA seguir apresentado os grficos da evoluo dos dados mais significantes de mtrica, quantidade de feature, correo de bug e quantidade de desenvolvedores dos projetos.Evoluo do Tomcat

Figura 9: Evoluo da Correo de bugs Tomcat

Figura 10: Evoluo da Quantidade de Desenvolvedores Tomcat

Figura 11: Evoluo da Quantidade de features Tomcat

Figura 12: Evoluo do valor da metrica de Ciclos de Pacotes Tomcat

Figura 13: Evoluo da Quantidade de Funes Tomcat

Figura 14: Evoluo da Complexidade de Funo de Tomcat

Figura 15: Evoluo da Complexidade Ciclomtica do TomcatEvoluo do POI

Figura 16: Evoluo da Quantidade de features POI

Figura 17: Evoluo da Correo de Bugs POI

Figura 18: Evoluo da Quantidade de Desenvolvedores POI

Figura 19: Evoluo do valor da metrica Ciclo de Pacote POI

Figura 20: Evoluo da Quantidade de Funo POI

Figura 21: Evoluo da Complexidade de Funo POI

Figura 22: Evoluo da Complexidade Ciclomtica POIEvoluo Jmeter

Figura 23: Evoluo da Quantidade Correo Jmeter

Figura 24: Evoluo da Quantidades Desenvolvedores Jmeter

Figura 25: Evoluo da Quantidade de Features Jmeter

Figura 26: Evoluo do valor da mtrica Ciclo de Pacote Jmeter

Figura 27: Evoluo da Quantidade de Funes Jmeter

Figura 28: Evoluo da Complexidade de Funo Jmeter

Figura 29: Evoluo da Complexidade Ciclomtica JmeterTodos os dados gerados se encontram no apndice A deste trabalho.

Estudo da Correlao de Pearson dos dados

A seguir esto 3 tabelas com os valores da correlao de Pearson. Correlao de Pearson BUG x Mtricas

Mtrica\ProjetoJmeterPOITomcat

RFC0,9060,6470,587

Pacote0,6880,8950,901

Linhas0,9610,9390,615

Complexidade de funo0,6870,0210,901

Arquivos0,9820,5990,826

Complexidade0,9530,9810,97

Classes0,9530,890,933

Ciclo de Pacote0,9770,139-0,978

NCLOC0,9730,7990,657

Funo0,9910,9190,221

Complexidade de Arquivo0,5260,781-0,34

Complexidade de Classe-0,4440,789-0,324

Accessors0,7740,560,922

Tabela 5: Correlao de Pearson (BUG x Mtricas)Correlao de Pearson Desenvolvedor x Mtricas


RFC0,910,7160,557

Pacote0,7910,7950,84

Linhas0,9310,9390,534

Complexidade de funo0,6940,0840,84

Arquivos0,950,6820,834


Classes0,9710,8810,855


NCLOC0,9420,9450,594

Funo0,9460,918-0,015



Accessors0,8990,7550,849

Tabela 6: Correlao de Pearson (Desenvolvedores x Mtricas)Correlao de Pearson Feature x Mtricas


RFC0,9760,7630,57

Pacote0,7660,8830,954

Linhas0,9690,9440,507

Complexidade de funo0,719-0,0110,954

Arquivos0,9730,6150,846


Classes0,9880,8920,887


NCLOC0,940,9620,546

Funo0,9640,9740,223



Accessors0,8450,760,86

Tabela 7: Correlao de Pearson (Feature x Mtricas)As tabelas mostram os valores da correlao de Pearson relacionando Feature, Bug, Desenvolvedores e as principais Mtricas. Para uma melhor visualizao do dados foram marcados em vermelho as correlaes de maior ndice, seja negativo ou positivo, das 3 tabelas entre as mtricas.Verifica-se que a correlao foi forte positiva para 54,70% (62/117) das correlaes e fortemente negativa para 2,56% (3/117) das correlaes, verifica-se correlao moderada positiva para 29,91% (35/117) dos casos, verifica-se correlao fraca positiva para 3,41% (4/117) dos casos e fraca negativa para 7,69% (9/117) dos casos.Quando comparado Bugs e mtricas tem-se que 43,58% (17/39) dos maiores ndices de correlao esto relacionados a correo de Bugs. Para a comparao Desenvolvedores e Mtricas tem-se que 15,38% (6/39) dos maiores ndices de correlao esto relacionados a quantidade de desenvolvedores. Para a comparao Feature x Mtricas tem-se que 46,15% (18/39) dos maiores ndice de correlao esto relacionados ao acrscimo de Features.Como de se esperar o acrscimo de features (43,58%) tem uma maior correlao com o aumento ou diminuio das mtricas de um software seguindo pela correo de bugs (46,15%) e por ltimo a quantidade de desenvolvedores (15,38%).Quando analisado os dados isolados para o Jmeter tem-se que 38,46 % (5/13) dos maiores ndices de correlao quando comparado as mtricas com a quantidade de bugs corrigidos. Analisando as correlaes comparando as mtricas com a quantidade de desenvolvedores tem-se que 23,07% (3/13) dos maiores ndices. Analisando as correlaes comparando as mtricas com a quantidade de feature tem-se que 46,15% (6/13) dos maiores ndices de correlao. Quando comparado com os valores globais de correlao v-se que o Jmeter acompanha a tendncia de que o acrscimo de features tem uma forte influncia no aumento ou diminuio das mtricas.Quando analisado os dados isolados para o POI tem-se que 38,46% (5/13) dos maiores ndices de correlao esto relacionados a quantidade de bugs corrigidos. Analisando as correlaes comparando as mtricas com a quantidade desenvolvedores tem-se que 15,38 % (2/13) dos maiores ndices de Pearson esto relacionados a quantidade de desenvolvedores. Analisando o ndice de Pearson comparando as mtricas com a quantidade de features tem-se que 53,84% (7/13) dos ndices. Quando comparado com os valores globais de correlao v-se que o POI tambm acompanha a tendncia de que o acrscimo de features tem uma forte influncia no aumento ou diminuio das mtricas.Quando analisado os dados isolados para o Tomcat tem-se que (7/13) dos maiores ndices de correlao esto relacionados a quantidade de bugs corrigidos. Analisando as correlaes comparando as mtricas com a quantidade de desenvolvedores tem-se que 7,69% (1/13) dos maiores ndices de Pearson. Analisando o ndice de Pearson comparando as mtricas com a quantidade de features tem-se que 38,46% (5/13) dos maiores ndices esto relacionado ao aumento da quantidade features. Quando comparamos com os valores globais v-se que o Tomcat foge um pouco do padro de que features tem uma forte influncia no aumento ou diminuio das mtricas.Para explicar essa diferena que foi apresentado para o Tomcat ser verificado a quantidade de linhas por projetos:

Quantidade mxima de Linhas de Cdigo

ProjetoQuantidade de Linhas de cdigo

Tomcat338223

POI163550

Jmeter59764

Tabela 8: Quantidade de linhasPode-se verificar que o tomcat tem um maior nmero de linhas entre os projetos chegando a ter mais que 2x o nmero de linhas do POI e quase 6 vezes mais o nmero de linhas que o Jmeter. Como a quantidade de linhas no tomcat maior faz com que o cdigo seja mais complexo o que podemos verificar no seguinte grfico mostrando a evoluo da complexidade ciclomtica de McCabe:

Figura 30: Historio da complexidade ciclomtica do TomcatCom isso a correo mais complicada no Tomcat levando a ter um peso maior na correlao dos bugs com as mtricas.Um dado interessante que foi mostrado nas tabelas de correlao est relacionado os ndices de Pearson negativos:

Tomcat

Mtrica\ProjetoCiclo de Pacote

Pearson BUG x Mtricas -0,978

Pearson Desenvolvedor x Mtricas -0,997

Pearson Feature x Mtricas-0,982

Tabela 9: ndice de PearsonEsta tabela mostram que para o projeto tomcat o aumento da correo de bugs, o aumento da quantidade de desenvolvedores e o aumento da quantidade de features no projeto do tomcat apresentou uma correlao negativa. A qual pode ser vista nos grficos:

Figura 31: Evoluo da correo de bugs x Metrica de Ciclos de Pacote

Figura 32: Evoluo da quantidade de features x Metricas de Ciclos de Pacote

Figura 33: Evoluo da quantidade de desenvolvedores x Metrica de Ciclos de PacoteEsses 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 consequentimente a dependencias de pacotes.

Concluses E TRABALHOS FUTUROSComo foi visto nos correlacionamento e grficos os dados dos softwares modificam muito ao longo de sua vida. Verificou-se que a correlao das variaes da quantidade de features teve um peso significativo no aumento das mtricas obtendo uma correlao forte para 43,58% dos casos.Um dado muito interessante obtido nesse estudo foi que na mudana de verso do tomcat de 7.x para 8.x houve uma diminuio na dependncia cclica de pacotes o que significa uma diminuio do acoplamento do projeto. Pode-se verificar que houve um esforo enorme no desenvolvimento da verso 7.x para 8.x do tomcat onde verificamos que a quantidade de desenvolvedores, correo de bugs e acrscimo de features aumentaram muito causando um aumento de todas as mtricas menos da dependncia cclica de pacotes.Neste trabalho pode-se verificar que a correo de bugs no sistema um dado importante no aumento das mtricas do sistemas.Um dos pontos negativos e que deve ser feito em trabalhos futuros a anlise de todas as verses e commits de todos os sistemas. A anlise de mais projetos open source como foi visto os 3 projetos obtiveram o mesmo padro nas correlaes e dados, mas devemos variar projetos de outras empresas j que os 3 projetos escolhidos fazem parte da organizao Apache.

RefernciasDOBRICA, L.; NIEMELA, E. A survey on software architecture analysis methods. IEEE Transactions on Software Engineering, v. 28, n. 7, 2002.GALL, H.; HAJEK, K.; JAZAYERI, M. Detection of logical coupling based on product release history. Proceedings. International Conference on Software Maintenance (Cat. No. 98CB36272), 1998.GODFREY, M. W.; TU, Q. Evolution in open source software: a case study. Proceedings International Conference on Software Maintenance ICSM-94, p. 131142, 2000. IEEE Comput. Soc. Press. Disponvel em: . .LINDVALL, M.; TESORIERO, R.; COSTA, P. Avoiding architectural degeneration: an evaluation process for software architecture. Proceedings Eighth IEEE Symposium on Software Metrics, 2002.NAGAPPAN, N.; BALL, T.; ZELLER, A. Mining metrics to predict component failures. Proceedings of the 28th international conference on Software engineering. Anais... , ICSE 06.. p.452461, 2006. ACM. Disponvel em: . .NAGAPPAN, N.; BALL, T.; ZELLER, A. Object-Oriented Metrics Which Predict Maintainability. of the 28th international conference on , 2006. Disponvel em: . Acesso em: 12/3/2014.SCHRTER, A.; ZIMMERMANN, T. If your bug database could talk. Proceedings of the 5th , p. 35, 2006. Disponvel em: . .SUBRAMANYAM, R.; KRISHNAN, M. S. Empirical analysis of CK metrics for object-oriented design complexity: implications for software defects. IEEE Transactions on Software Engineering, v. 29, n. 4, p. 297310, 2003. Disponvel em: . .

Anexo A GRficos evolutivos de todos os dados coletados.

tcc-v0.6

Documents