SlideShare uma empresa Scribd logo
1 de 117
Baixar para ler offline
Evolução de SoftwareFerramentas, técnicas e métricas[versão 1.1] Gustavo Oliva, Mauricio Aniche, Marco Gerosa{goliva, aniche, gerosa}@ime.usp.br 
Versão atualizada do curso apresentado em: CBSoft2011 –São Paulo –SP –Brasil 
IME-USP
Instrutores 
Gustavo Oliva 
Mestre em Ciência da Computação pelo IME/USP 
Evolução e manutenção de software 
Gerência de dependências em sistemas OO 
Atuou como desenvolvedor na IBM Brasil por ~3 anos 
Mauricio Aniche 
Mestre em Ciência da Computação pelo IME/USP 
Test-DrivenDevelopmente Design de Sistemas OO 
Instrutor dos cursos de Java e Métodos Ágeis da Caelum 
2
Objetivos do Curso 
Objetivo Geral 
Discutir evolução de software e técnicas para extração e visualização de dados 
Objetivos Específicos 
Discutir ferramentas 
Discutir técnicas 
Discutir métricas 
3
Agenda 
Motivação 
Conceitos Básicos 
Temas Atuais de Pesquisa 
Métricas e Visualização 
XFlowe rEvolution 
4
Agenda 
Motivação 
Conceitos Básicos 
Temas Atuais de Pesquisa 
Métricas e Visualização 
XFlowe rEvolution 
5
O mundoreal… 
… écomplicado! 
FindBugsv1.3.0 (Novembro/2007) 
6
Todosoftware útil… 
Mudacontinuamente 
Tendea tornar-se maiscomplexo 
Tendea crescer 
7
Motivação 
8 
A evoluçãodo software é difícilde compreender 
Grande quantidadede dados históricos 
A interaçãoentre aspectostécnicose sociaisdo processode desenvolvimentode software é difícilde desvendar 
Uma análisecompreensivada evoluçãorequermecânismossofisticados, comovisualizaçõessob váriasperspectivase cálculode métricas
Evoluçãode Software 
9 
Evoluçãode software se preocupaprincipalmentecom as mudançasdo sistemaemrelaçãoa diferentesversõesoureleases do mesmo 
EmMaiode 2010, o Google Scholar reportouque, em2009, 70 publicaçõescontinham“software evolution” no título, e maisde 900 tinham“software evolution” emalgumlugardo texto
Evoluçãode Software 
10 
Sistemasde software precisamevoluir 
A sociedadealtamentedinâmicaimpõeumapressãoconstanteparamudançasemsistemasde software 
Para continuarútil, é crucial quesistemasde software possamserfacilmenteadaptáveisa mudançascontínuase flexíveiso suficienteparaadiçãode novasfuncionalidades 
Software quenãoé tolerantea modificaçõesestáfadadoaoabandonooua substituição[Mens& Demeyer2008], [Bode 2009]
EstudosemEvoluçãode Software 
11 
Estudossobreevoluçãopossuemdiversosobjetivos 
Identificaçãode boas práticasde engenhariade software baseadasnaanálisede comosistemasde sucessoe de longoprazose mantém[Bennet& Rajlich2000] 
Avaliaçãode hipótesesempíricassobrecaracterísticasda evoluçãode software [Lehman 1997] 
Padrõesde colaboraçãoentre desenvolvedores[Cataldo2008] 
Identificaçãode problemasde design e de códigoatravésda visualizaçãodo históricodo software [D‘Ambros& Lanza2010]
Agenda 
Motivação 
Conceitos Básicos 
Temas Atuais de Pesquisa 
Métricas e Visualização 
XFlowandrEvolution 
12
Software Intelligence 
As mesmas ideias de 
Business Intelligence (BI), só 
que aplicadas no domínio 
de software 
13
Mineraçãode Repositóriosde Código 
14 
Mineraçãode Repositóriosde Código(MSR) se refereà aplicaçãode técnicasde mineraçãode dados emdados históricosde projetos[Ball et al. 1996] 
Estudossobreevoluçãode software frequentementeestãoassociadosà MSR
Dados interessantes 
As técnicasde MSR podemencontrarpadrõesinteressantesemprojetosde software 
No exemploaolado, o gráficomostrao númerode bugs escritospordiada semana. Para esseprojeto, podemosverquequarta- feiraéo diaemqueessaequipeproduzmenosbugs 
15
Repositórios 
16
Repositóriosde código 
Háváriosdeles: CVS, SVN, Git, Mercurial, Bazaar 
Muitascaracterísticasemcomum 
Mas muitascaracterísticasespecíficastambém! 
17
Benefícios 
Contémtodoo históricodo projetoaolongodo tempo 
Contéminformaçõesrelevantes, como 
Data/hora 
Desenvolvedor 
Mensagemexplicandoa alteração(commit message) 
18
Dificuldades 
Muitasequipesnãocolocammensagemnoscommits 
Fazemcommits grandes, dificultandoa compreensãodo mesmo 
Dependendodo controladorde versão, extrairdados podesertrabalhoso 
CVS, porexemplo, nãodásuporteparacommits atômicos 
19
Outros repositórios 
Listasde Discussão 
Bug Trackers 
… 
20
Issue Trackers 
21
Issue Trackers 
Descriçãodo bug, severidade 
Data de criaçãodo ticket, data de fechamentodo ticket 
Desenvolvedorquefechou, desenvolvedoresqueinteragiramnadiscussão 
… 
22
Benefícios 
Uma base de dados grandesobrebugs e suascaracterísticas 
As informaçõesde data possibilitama criaçãode links entre o repositóriode códigoe o repositóriode bugs 
23
Dificuldades 
Cadaferramentaarmazena/exportadados de umamaneiradiferente 
Muitasequipesnãousam 
O link entre repositóriode códigoe repositóriode bugs é fraco 
Uma soluçãocomumé procurarporreferênciasa bugs nasmensagensdos commits 
24
Listasde Discussão 
25
Listasde Discussão 
Local ondeaconteceumagrandetrocade informaçõesrelativasaoprojeto 
Discute-se bugs, melhorias, novasfuncionalidades, etc. 
Geralmentedisponívelnaweb 
Bastanteusadoporprojetosopen-source 
26
Benefícios 
“Documentação” das discussõespodemconterdados interessantes. 
Altamenterelacionadoscom atividadesde mudançade código[Bird et al.06] 
Geralmentecontémdiscussõessobreplanosfuturos, decisõesde design 
Contéma “redesocial” de desenvolvedoresdo projeto 
27
Exemplo: Motivação 
Estudodo conteúdodas mensagensantes e depoisde umarelease; 
Depoisdo release Apache 1.3, houveumaquedano otimismo; 
Depoisdo release do Apache 2.0, houveum aumentonasocialibilidade; 
[Rigby & Hassan 07] 
28
Dificuldades 
Dados nãoestruturadosdificultama extraçãode dados 
Desenvolvedorcom múltiplose-mails 
Threads “quebradas” emváriose-mails diferentes 
29
Extraçãode dados 
30
Logs 
Controladores de versão proveem logs das modificações armazenadas 
Geralmente em texto puro 
Exemplo: gitlog 
31
Exemplodo diff 
Diffs mostrama diferençaentre umaversãoe a versãoanterior 
Útilparaidentificaras mudançasfeitas 
32
Ferramentasprontas 
SVNKit(svnkit.com) 
JGit(eclipse.org/jgit/) 
33
Modelandoosdados 
Release HistoryDatabase(RHDB) [D’Ambroset al. 2008] 
34
Analisandoosdados 
35
DependênciasLógicas 
Dependênciaslógicassãodependênciasimplícitasentre artefatosde software queevoluíramjuntos[Gall et al. 1998] 
Dependênciaslógicasocorremquandodoisartefatossãofrequentementemudadosjuntos 
Estatécnicapoderevelarlinks evolucionáriosentre quaisquertiposde artefatosquecompõemo sistema, incluindoarquivosde configuraçãoe documentação 
Dependênciaslógicassãoidentificadaspormeiode análisedos logs dos sistemasde controlede versão 
36
Requisitosde Coordenação 
Requisitosde coordenação(CRs) sãoempregadosparainferirdependênciasentre desenvolvedores[Cataldoet al.2006] 
CRs sãoinferidasa partirde doiselementos 
Dependênciaslógicasentre arquivose 
Alocaçãode tarefasparadesenvolvedores 
Exemplo#1: desenvolvedoresmudandoo mesmoconjuntode arquivos 
Exemplo#2: desenvolvedord1 devecoordenarseutrabalhocom osdesenvolvedoresd2 e d3 quandoosarquivosmodificadospord1 dependemlogicamentede arquivosmodificadospord2 e d3 
37
Prediçãode Bugs 
A mensagemdo commit podeajudara identificar“commits bugados” [Eyolfson, Tan, Lam 11]; 
Aoolhara mensagem, podemosencontrarmensagensdo tipo“bug corrigido” 
Bastaolharparatrás, e verquaiscommits introduziramas linhasqueforamremovidasno commit corrente 
Essescommits podemserconsiderados“bugados” 
Possibilitaa visualizaçãodos diase horáriosemqueosbugs sãogerados 
38
Prediçãode Mudanças 
Com base emmétricasaplicadassobredependênciaslógicas, é possívelfazerprediçõessobremudanças 
Ideiabásica: “ClientesquecompraramX, tambémcompraramY” 
A granularidadepodevariar: classes, métodos, etc. 
É possívelaindaprevinirerrosdecorrentesde mudançasincompletas 
39
Clones de código 
Com o históricoda base de códigoemmãos, é possívelprocurarporclones de código 
É possível, inclusive, descobrirquandoosclones foramcriados 
40
Complexidadede código 
O cálculoda complexidadedo código(ouqualqueroutramétrica) aolongodo tempo podepassarinformaçõesinteressantescomo: 
Classes maiscomplexas 
Classes cujacomplexidadetem aumentadoconstantemente 
41
Truck Factor 
A análisede desenvolvedorese artefatosmodificadospodempassarinformaçõesinteressantes, como: 
Artefatosquesósãomodificadosporum desenvolvedoraolongodo tempo (truck factor) 
Artefatosquesãomodificadosporváriosdesenvolvedorese a relaçãodisso com a complexidadedo códigogerado 
42
Ferramentasde métricas 
Existemvárias, como: 
JDepend/NDepend 
JavaNCSS 
Eclipse Metrics 
KalibroMetrics 
Byecycle 
iPlasma 
Neste caso, o desenvolvedor fica responsável por analisar as várias releases (ou versões) do código para chegar a conclusões acerca da evolução do sistema em questão 
43
JDepend/NDepend 
Calculamétricas, taiscomo 
Númerode classes e interfaces 
Acoplamentoaferente/eferente 
Abstração 
Instabilidade 
Distânciada linhaprincipal 
Ciclosde dependênciaentre pacotes 
Precisado códigocompiladoparaexecutar 
44
JavaNCSS 
Cálculacomplexidadeciclomáticade métodose classes 
Faza análiseemcimado própriocódigo-fonte, nãoexigindoo códigocompilado 
45
Eclipse Metrics 
Plugin do eclipse queconstantementecalculaas métricas 
Uma grandequantidadede métricasdiferentes 
Poderodarforado Eclipse 
É complicado, mas possível 
46
KalibroMetrics 
Software brasileiro 
Fácilde plugarnovasmétricas 
Jápossuimuitasmétricasimplementadas 
Nãoprecisade códigocompilado 
47
Byecycle 
Mostraas dependênciasentre osdiversospacotesdo projeto 
Plugin do Eclipse 
48
iPlasma-Avaliando Design 
Além de investigar dependências, há outros métodos mais automatizados 
Lanza e Marinescupropõem um conjunto de estratégias de detecção de problemas de design com base em composição de métricas e limiares 
49
Estratégiasde Detecção 
50
Design Disharmonies (Lanzae Marinescu–Object- Oriented Metrics in Practice) 
51
GodClass 
52
Shotgun Surgery 
53
Adotandoresultados 
54
Reengenharia 
Apósa análisedos dados, osproblemasidentificadossãotratadospormeiode técnicasde reengenharia 
Reengenharia (…) é o exame e alteração de um sistema para reconstituí-lo em uma nova forma e a subsequente implementação da nova forma [Chikofsky1990] 
No escopo de sistemas orientados a objetos, há um enorme corpo de conhecimento acerca de técnicas de reengenharia 
Padrõesde reengenharia 
Object-Oriented ReengineringPatterns[Demeyeret al. 2009] 
Refatoração 
Refactoring to Patterns [Kerievsky2004] 
Refactoring: Improving the Design of Existing Code [Fowler et al. 1999] 
55
Como implantarnaindústria? 
No PASED 2011, Ahmed Hassan comentousobreo problemado “ovoe da galinha” 
Para mostraro valor das técnicasde MSR, precisamosexecutá-lasnaindústria 
Mas paraquea indústriacomprea ideia, é precisoprimeiromostraro valor 
56
Agenda 
Motivação 
Conceitos Básicos 
Temas Atuais de Pesquisa 
Métricas e Visualização 
XFlowandrEvolution 
57
Quaisosdesafios? 
Quais os desafios no processo de MSR? 
58
DesafiosemMSR 
Exploraçãode dados não-estruturados 
E-mails, comentários, … 
Relaçãode dados entre diferentesrepositórios 
Informaçõessobrebugs e repositóriode código 
Procurardados emlugaresnãoconvencionais 
Entenderas limitações 
Poucoscommits, poucosdesenvolvedores, … 
59
DesafiosemMSR 
Lidarcom ruídosnosdados 
Melhorara qualidadedos dados nesses repositórios 
Facilitara extraçãode dados 
60
DesafiosemMSR 
Entendera necessidadedos praticantes 
Mostrarosresultadospráticos 
Avaliarprojetosquenãosejamopen-source 
Simplificaro acessoa tecnologia 
Ajudaro participantea tomardecisõessobreo projeto 
61
Agenda 
Motivação 
Conceitos Básicos 
Temas Atuais de Pesquisa 
Métricas e Visualização 
XFlowandrEvolution 
62
Visualizaçãode software 
A área de “Visualização de Software” estuda a representação visual estática ou animada da informaçãosobre um sistema de software baseado em sua estrutura, comportamento ou evolução [Diehl 2010] 
O objetivo central da visualização de software é apoiar a compreensão e análise de sistemas e algoritmos 
Pode ser encarada como uma atividade de Engenharia Reversa 
63
O queéumamétrica? 
O mapeamentode umacaracterísticaparticular de umaentidademedidaparaum valor numérico 
Porquemedir? 
Auxilianaadministraçãoda complexidade! 
64
Vantagense Desvantagens 
Vantagens 
Capacidadede quantificaraspectosde qualidade 
Possibilidadede automatizaras mediçõesde um sistema 
Desvantagens 
Númerossãoapenasnúmeros: nãoconfiecegamenteneles! 
Emgeral, capturamsomentesintomasde altagranularidade, e nãocausasde problemasde design 
Difícilparadesenvolvedoreslidaremcom elas 
Inflaçãode medições 
65
Desafios 
O quevisualizar? 
Como visualizar? 
Quantascoisasvisualizar(aomesmotempo)? 
Como associarvisualizaçãoe métricas? 
66
Um exemplosimples 
Árvorequedenotaumahierarquiade classes 
67
Visualização de Dependências 
Structure101 (classes) 
Grafos 
68
Visualização de Dependências 
Structure101 (pacotes e jars) 
Grafos 
69
Visualização de Dependências 
Lattix 
DSM (Design/dependencystructurematrix) 
Outbounddep 
Inbound dep 
Cyclic dep 
70
Visualizaçãode Dependências 
IBM SA4J 
Whatif 
Skeleton 
71
Visualização de Dependências 
EvolutionRadar 
Poderia ser qualquer outra métrica 
72
Visualização de Dependências 
73
Evolution Matrix 
74
The ClassBlueprint 
75
MetricsPyramid 
Diferentes métricas e a relação entre elas 
Cores indicam se valores estão dentro dos limites aceitáveis 
76
Legenda: MetricsPyramid 
NOP: Número de pacotes 
NOC: Número de classes 
NOM: Número de métodos 
LOC: Linhas de Código 
CYCLO: Complexidade ciclomática 
CALLS: Número de invocações de métodos distintos 
FANOUT: Número de tipos “de fora” referenciados 
ANDC: Número médio de classes que foram derivadas 
AHH: Número médio da árvore de hierarquia 
77
Métricasde referência 
78
Existemvárias! 
Quantitative Evaluation of Software Quality Metrics in Open-Source Projects(Barkmannet al.) 
79
PolymetricViews 
80
Evospaces/Codecity 
81
Evospaces/Codecity 
82
Evospaces/Codecity 
83
Evospaces/Codecity 
84
ArgoUML 
85
CodeCityaolongodo tempo 
86
Diagramasde Kiviat(radares) 
87
Gráficosde barrase linhas 
88
Agenda 
Motivação 
Conceitos Básicos 
Temas Atuais de Pesquisa 
Métricas e Visualização 
XFlowandrEvolution 
89
XFlow 
XFlowé umaferramentaextensívelquedásuportea análisesempíricasemevoluçaõde software 
Open-source (GPL) 
Baseadano protótipoTransFlow[Costa et al.2009] 
Apoiaa análiseintegradade aspectostécnicose sociaispormeiode ricasvisualizaçõese cálculode métricas 
Trataproblemasde desempenhoencontradosemtrabalhosrelacionados 
90
Princípiosde Funcionamento 
91 
Processamento de Dados 
Persistência 
Coleta de Dados 
Métricas 
Visualizações 
Parse dos logs do sistema de controle de versão 
Identificação de dependências lógicas e requisitos de coordenação 
Cálculo de métricas de projeto, commitse de arquivo 
Oferecimento das visualizações interativas
Design Rationale 
Foco no apoio à pesquisa empírica 
Extensibilidade como chave para alcançar completude 
Faça apenas uma vez 
Filtre e personalize 
92
Visualizações da XFlow 
“Overview primeiro, zoom e filtragem, e entãodetalhessob demanda” [Shneiderman1996] 
Alcançadapormeiode filtrose controles 
Cincovisualizaçõesinterativas 
Gráficode Linhas 
Scatterplot 
TreeMap 
Grafo 
Atividade 
93
Mecanismosde Interação 
94 
(a)Abas para visualizações 
(b)Painel de desenvolvedores 
(c)Barra de informações da análise 
(d)Controles específicos
CenárioIlustrativo#1 
EvoluçãoSociotécnicade Software 
Como times de desenvolvimentolidamcom a saídade desenvolvedoresprincípios? 
A saídade líderescomprometeuo projetoGIMP inteiro(hiatode 20 mesesno desenvolvimento) [Ye & Kishida2003] 
Visualizaçõesde Atividadee TreeMapforamempregadasparaanalisaro Megamek(BattleTechboard game) 
96
CenárioIlustrativo#1 
97
CenárioIlustrativo#1 
98
CenárioIlustrativo#2 
Efeitosda arquiteturasobredesenvolvedores 
Como um sistemade software cresceparaacomodarnovasfuncionalidades? 
A análiseintegradade dependênciaslógicas(focotécnico) e requisitosde coordenação(focosocial) dásuportepraestetipode análise 
A visualizaçãode grafofoiempregadaparaanalisarambos Apache LuceneejEdit(IDE) 
99
CenárioIlustrativo#2 
Apache LuceneDependencyGraphs 
jEdit 
DependencyGraphs 
100
CenárioIlustrativo#3 
Compreendendopapelde desenvolvedores 
Estudo exploratório do projeto jEdit 
Coleta: 10895 commits 
6 anos e meio de desenvolvimento 
Apenas arquivos com extensão Java 
Análise da contribuição de 3 desenvolvedores 
k_satoda, jgellenee orutherfurd 
101
102
103 
Centralidade 
Tempo 
Centralidade Máxima do Commit
104 
Centralidade 
Tempo 
Máxima centralidade “até então” 
Maior centralidade atingida até o momento (valor de referência)
105 
Commitspor mês
rEvolution 
Ferramentaquepossibilitaa geraçãode gráficossobrea evoluçãodo software 
Analisainformaçõesdo repositóriode código, comocommit messages, datas, desenvolvedores, etc. 
Executaferramentasde métricascomoJavaNCSS, JDepend, e triangulaessesvalores 
Diversasvisualizaçõesjáimplementadas 
FerramentaOpen Source quepodeserencontradaemhttp://www.github.com/mauricioaniche/rEvolution 
CriadaporMauricio Aniche 
106
rEvolution 
AtualmentesósuportaGit 
Implementaçãode SVN estáemandamento 
Permitea criaçãode novasvisualizaçõesoumediçõesde maneirafácil 
Persisteosdados emMySQL 
PorusarHibernate, tirado usuárioa necessidadede escreverINSERTs, CREATE TABLEs oucoisado tipo, aoencaixarumanova métrica 
107
Modelode Classes do rEvolution 
108
Artefatosmaismodificados 
109
Bugs porDiae Hora 
110
ArtefatosmaisModificadosxNúmerode bugs 
111
Commitspordesenvolvedor 
112
Commits porDiae Hora 
113
Linhasadicionadasaolongodo tempo 
114
Testes acumuladosaolongodo tempo 
115
Futurodo rEvolution 
Product Backlog jágrande 
Ideiasvindasinclusive de colegasda Alemanha 
Integraçãocom SVN e Mercurial 
Interface visual parafacilitarconfiguração 
Hojeo usuárioconfiguraatravésde um .properties 
Maise maisvisualizações… 
116
Obrigado! 
Mauricio Aniche 
aniche@ime.usp.br/ @mauricioaniche 
Gustavo Oliva 
goliva@ime.usp.br/ @golivax 
Marco AurélioGerosa 
gerosa@ime.usp.br 
117

Mais conteúdo relacionado

Mais procurados

Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
eros.viggiano
 
Engenharia de Software - Wikipedia
Engenharia de Software - WikipediaEngenharia de Software - Wikipedia
Engenharia de Software - Wikipedia
Robson Silva Espig
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
Adriano Tavares
 
2010 05-06 b - desenho de interfaces com o utilizador
2010 05-06 b - desenho de interfaces com o utilizador2010 05-06 b - desenho de interfaces com o utilizador
2010 05-06 b - desenho de interfaces com o utilizador
guest8a778
 
Perfil profissional%20 tecnólogo%20 análise e desenvol
Perfil profissional%20 tecnólogo%20 análise e desenvolPerfil profissional%20 tecnólogo%20 análise e desenvol
Perfil profissional%20 tecnólogo%20 análise e desenvol
Carlos Melo
 
Aula 1 2-es
Aula 1 2-esAula 1 2-es
Aula 1 2-es
cifjovo
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
elliando dias
 

Mais procurados (13)

Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
TDC 2012 - Métricas de código na arquitetura
TDC 2012 - Métricas de código na arquiteturaTDC 2012 - Métricas de código na arquitetura
TDC 2012 - Métricas de código na arquitetura
 
Princípios da engenharia de software (marcello thiry)
Princípios da engenharia de software (marcello thiry)Princípios da engenharia de software (marcello thiry)
Princípios da engenharia de software (marcello thiry)
 
Padrões Arquiteturais de Sistemas
Padrões Arquiteturais de SistemasPadrões Arquiteturais de Sistemas
Padrões Arquiteturais de Sistemas
 
Engenharia de Software - Wikipedia
Engenharia de Software - WikipediaEngenharia de Software - Wikipedia
Engenharia de Software - Wikipedia
 
DevQA: Como medir qualidade de código ?
DevQA: Como medir qualidade de código ?DevQA: Como medir qualidade de código ?
DevQA: Como medir qualidade de código ?
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
 
2010 05-06 b - desenho de interfaces com o utilizador
2010 05-06 b - desenho de interfaces com o utilizador2010 05-06 b - desenho de interfaces com o utilizador
2010 05-06 b - desenho de interfaces com o utilizador
 
Linguagem de programação C# 4 e 5
Linguagem de programação C# 4 e 5Linguagem de programação C# 4 e 5
Linguagem de programação C# 4 e 5
 
Perfil profissional%20 tecnólogo%20 análise e desenvol
Perfil profissional%20 tecnólogo%20 análise e desenvolPerfil profissional%20 tecnólogo%20 análise e desenvol
Perfil profissional%20 tecnólogo%20 análise e desenvol
 
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de software
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de softwareAplicação de Padrões de Projeto para a melhoria da manutenabilidade de software
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de software
 
Aula 1 2-es
Aula 1 2-esAula 1 2-es
Aula 1 2-es
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 

Destaque

Destaque (17)

O que estamos temos feito com mineração de repositório de código no IME?
O que estamos temos feito com mineração de repositório de código no IME?O que estamos temos feito com mineração de repositório de código no IME?
O que estamos temos feito com mineração de repositório de código no IME?
 
Does the Act of Refactoring Really Make Code Simpler? A Preliminary Study - W...
Does the Act of Refactoring Really Make Code Simpler? A Preliminary Study - W...Does the Act of Refactoring Really Make Code Simpler? A Preliminary Study - W...
Does the Act of Refactoring Really Make Code Simpler? A Preliminary Study - W...
 
Test-Driven Development serve pra mim?
Test-Driven Development serve pra mim?Test-Driven Development serve pra mim?
Test-Driven Development serve pra mim?
 
Como eu aprendi que testar software é importante?
Como eu aprendi que testar software é importante?Como eu aprendi que testar software é importante?
Como eu aprendi que testar software é importante?
 
TDD depois do mainstream. E agora?
TDD depois do mainstream. E agora?TDD depois do mainstream. E agora?
TDD depois do mainstream. E agora?
 
DNAD 2015 - Métricas de código, pra que te quero?
DNAD 2015 - Métricas de código, pra que te quero?DNAD 2015 - Métricas de código, pra que te quero?
DNAD 2015 - Métricas de código, pra que te quero?
 
Efeitos da Prática de Revisão de Código na Caelum: Um Estudo Preliminar em Du...
Efeitos da Prática de Revisão de Código na Caelum: Um Estudo Preliminar em Du...Efeitos da Prática de Revisão de Código na Caelum: Um Estudo Preliminar em Du...
Efeitos da Prática de Revisão de Código na Caelum: Um Estudo Preliminar em Du...
 
Proposta: Métricas e Heurísticas para Detecção de Problemas em Aplicações Web
Proposta: Métricas e Heurísticas para Detecção de Problemas em Aplicações WebProposta: Métricas e Heurísticas para Detecção de Problemas em Aplicações Web
Proposta: Métricas e Heurísticas para Detecção de Problemas em Aplicações Web
 
Você tem um xerife olhando seu código?
Você tem um xerife olhando seu código?Você tem um xerife olhando seu código?
Você tem um xerife olhando seu código?
 
Eu meço, tu medes, ele mede.. Mas medimos o quê?
Eu meço, tu medes, ele mede.. Mas medimos o quê?Eu meço, tu medes, ele mede.. Mas medimos o quê?
Eu meço, tu medes, ele mede.. Mas medimos o quê?
 
MetricMiner: Supporting Researchers in Mining Software Repositories - SCAM 2013
MetricMiner: Supporting Researchers in Mining Software Repositories - SCAM 2013MetricMiner: Supporting Researchers in Mining Software Repositories - SCAM 2013
MetricMiner: Supporting Researchers in Mining Software Repositories - SCAM 2013
 
MTD2014 - Are The Methods In Your DAOs in the Right Place? A Preliminary Study
MTD2014 - Are The Methods In Your DAOs in the Right Place? A Preliminary StudyMTD2014 - Are The Methods In Your DAOs in the Right Place? A Preliminary Study
MTD2014 - Are The Methods In Your DAOs in the Right Place? A Preliminary Study
 
Code coverage for MSR Researches [Work in Progress]
Code coverage for MSR Researches [Work in Progress]Code coverage for MSR Researches [Work in Progress]
Code coverage for MSR Researches [Work in Progress]
 
SATT: Tailoring Code Metric Thresholds for Different Software Architectures (...
SATT: Tailoring Code Metric Thresholds for Different Software Architectures (...SATT: Tailoring Code Metric Thresholds for Different Software Architectures (...
SATT: Tailoring Code Metric Thresholds for Different Software Architectures (...
 
A Validated Set of Smells for MVC Architectures - ICSME 2016
A Validated Set of Smells for MVC Architectures - ICSME 2016A Validated Set of Smells for MVC Architectures - ICSME 2016
A Validated Set of Smells for MVC Architectures - ICSME 2016
 
Code quality in MVC systems - BENEVOL 2016
Code quality in MVC systems - BENEVOL 2016Code quality in MVC systems - BENEVOL 2016
Code quality in MVC systems - BENEVOL 2016
 
A Collaborative Approach to Teach Software Architecture - SIGCSE 2017
A Collaborative Approach to Teach Software Architecture - SIGCSE 2017A Collaborative Approach to Teach Software Architecture - SIGCSE 2017
A Collaborative Approach to Teach Software Architecture - SIGCSE 2017
 

Semelhante a Minicurso sobre Evolução de Software no CBSoft 2011

Implantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLImplantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SL
Annkatlover
 
Apresentação: Utilização de Metodologias Ágeis para Adaptação de um Processo ...
Apresentação: Utilização de Metodologias Ágeis para Adaptação de um Processo ...Apresentação: Utilização de Metodologias Ágeis para Adaptação de um Processo ...
Apresentação: Utilização de Metodologias Ágeis para Adaptação de um Processo ...
Felipe Nascimento
 

Semelhante a Minicurso sobre Evolução de Software no CBSoft 2011 (20)

Fundamentos Engenharia de Software.pptx
Fundamentos Engenharia de Software.pptxFundamentos Engenharia de Software.pptx
Fundamentos Engenharia de Software.pptx
 
Tendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de SoftwareTendências e Dicas para o Desenvolvimento de Software
Tendências e Dicas para o Desenvolvimento de Software
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Implantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLImplantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SL
 
Mining software repositories
Mining software repositoriesMining software repositories
Mining software repositories
 
Escalando apps com React e Type Script e SOLID
Escalando apps com React e Type Script e SOLIDEscalando apps com React e Type Script e SOLID
Escalando apps com React e Type Script e SOLID
 
Sql01 final
Sql01 finalSql01 final
Sql01 final
 
Estratégias de Estruturação de Código-fonte e Controlo de Versão
Estratégias de Estruturação de Código-fonte e Controlo de VersãoEstratégias de Estruturação de Código-fonte e Controlo de Versão
Estratégias de Estruturação de Código-fonte e Controlo de Versão
 
Reutilização
ReutilizaçãoReutilização
Reutilização
 
Resumo capítulo 1 livro Engenharia de Software Moderna
Resumo capítulo 1 livro Engenharia de Software ModernaResumo capítulo 1 livro Engenharia de Software Moderna
Resumo capítulo 1 livro Engenharia de Software Moderna
 
Academia do Arquiteto Globalcode
Academia do Arquiteto GlobalcodeAcademia do Arquiteto Globalcode
Academia do Arquiteto Globalcode
 
Design Patterns - Com Java
Design Patterns  - Com JavaDesign Patterns  - Com Java
Design Patterns - Com Java
 
Apresentação: Utilização de Metodologias Ágeis para Adaptação de um Processo ...
Apresentação: Utilização de Metodologias Ágeis para Adaptação de um Processo ...Apresentação: Utilização de Metodologias Ágeis para Adaptação de um Processo ...
Apresentação: Utilização de Metodologias Ágeis para Adaptação de um Processo ...
 
Padrões de projeto
Padrões de projetoPadrões de projeto
Padrões de projeto
 
Introdução a informática: do Windows ao Excel
Introdução a informática: do Windows ao ExcelIntrodução a informática: do Windows ao Excel
Introdução a informática: do Windows ao Excel
 
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhDDisciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
Disciplina Gerencia de Projetos - Prof. Rogerio P C do Nascimento, PhD
 
Arquitetura web para sistemas de negócio
Arquitetura web para sistemas de negócioArquitetura web para sistemas de negócio
Arquitetura web para sistemas de negócio
 
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
 
Aula4-modelagem e uml
Aula4-modelagem e umlAula4-modelagem e uml
Aula4-modelagem e uml
 

Mais de Maurício Aniche

Mais de Maurício Aniche (13)

Can ML help software developers? (TEQnation 2022)
Can ML help software developers? (TEQnation 2022)Can ML help software developers? (TEQnation 2022)
Can ML help software developers? (TEQnation 2022)
 
Tracing Back Log Data to its Log Statement: From Research to Practice
Tracing Back Log Data to its Log Statement: From Research to PracticeTracing Back Log Data to its Log Statement: From Research to Practice
Tracing Back Log Data to its Log Statement: From Research to Practice
 
Pragmatic software testing education - SIGCSE 2019
Pragmatic software testing education - SIGCSE 2019Pragmatic software testing education - SIGCSE 2019
Pragmatic software testing education - SIGCSE 2019
 
Test Automation Day 2018
Test Automation Day 2018Test Automation Day 2018
Test Automation Day 2018
 
Software Testing with Caipirinhas and Stroopwafels
Software Testing with Caipirinhas and StroopwafelsSoftware Testing with Caipirinhas and Stroopwafels
Software Testing with Caipirinhas and Stroopwafels
 
Code smells in MVC applications (Dutch Spring meetup)
Code smells in MVC applications (Dutch Spring meetup)Code smells in MVC applications (Dutch Spring meetup)
Code smells in MVC applications (Dutch Spring meetup)
 
[TDC 2014] Métricas de código, pra que te quero?
[TDC 2014] Métricas de código, pra que te quero?[TDC 2014] Métricas de código, pra que te quero?
[TDC 2014] Métricas de código, pra que te quero?
 
Métricas de código, pra que te quero?
Métricas de código, pra que te quero?Métricas de código, pra que te quero?
Métricas de código, pra que te quero?
 
Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...
Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...
Defesa de mestrado: Como a prática de TDD influencia no projeto de classes em...
 
O que é código bonito?
O que é código bonito?O que é código bonito?
O que é código bonito?
 
Métodos Ágeis de Desenvolvimento de Software: Uma introdução
Métodos Ágeis de Desenvolvimento de Software: Uma introduçãoMétodos Ágeis de Desenvolvimento de Software: Uma introdução
Métodos Ágeis de Desenvolvimento de Software: Uma introdução
 
The relationship between test and production code quality (@ SIG)
The relationship between test and production code quality (@ SIG)The relationship between test and production code quality (@ SIG)
The relationship between test and production code quality (@ SIG)
 
What Do the Asserts in a Unit Test Tell Us About Code Quality? (CSMR2013)
What Do the Asserts in a Unit Test Tell Us About Code Quality? (CSMR2013)What Do the Asserts in a Unit Test Tell Us About Code Quality? (CSMR2013)
What Do the Asserts in a Unit Test Tell Us About Code Quality? (CSMR2013)
 

Último

Último (9)

ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo Pagliusi
 
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
 
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdfAula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
Aula 01 - Introducao a Processamento de Frutos e Hortalicas.pdf
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
 
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
 
Convergência TO e TI nas Usinas - Setor Sucroenergético
Convergência TO e TI nas Usinas - Setor SucroenergéticoConvergência TO e TI nas Usinas - Setor Sucroenergético
Convergência TO e TI nas Usinas - Setor Sucroenergético
 

Minicurso sobre Evolução de Software no CBSoft 2011

  • 1. Evolução de SoftwareFerramentas, técnicas e métricas[versão 1.1] Gustavo Oliva, Mauricio Aniche, Marco Gerosa{goliva, aniche, gerosa}@ime.usp.br Versão atualizada do curso apresentado em: CBSoft2011 –São Paulo –SP –Brasil IME-USP
  • 2. Instrutores Gustavo Oliva Mestre em Ciência da Computação pelo IME/USP Evolução e manutenção de software Gerência de dependências em sistemas OO Atuou como desenvolvedor na IBM Brasil por ~3 anos Mauricio Aniche Mestre em Ciência da Computação pelo IME/USP Test-DrivenDevelopmente Design de Sistemas OO Instrutor dos cursos de Java e Métodos Ágeis da Caelum 2
  • 3. Objetivos do Curso Objetivo Geral Discutir evolução de software e técnicas para extração e visualização de dados Objetivos Específicos Discutir ferramentas Discutir técnicas Discutir métricas 3
  • 4. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowe rEvolution 4
  • 5. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowe rEvolution 5
  • 6. O mundoreal… … écomplicado! FindBugsv1.3.0 (Novembro/2007) 6
  • 7. Todosoftware útil… Mudacontinuamente Tendea tornar-se maiscomplexo Tendea crescer 7
  • 8. Motivação 8 A evoluçãodo software é difícilde compreender Grande quantidadede dados históricos A interaçãoentre aspectostécnicose sociaisdo processode desenvolvimentode software é difícilde desvendar Uma análisecompreensivada evoluçãorequermecânismossofisticados, comovisualizaçõessob váriasperspectivase cálculode métricas
  • 9. Evoluçãode Software 9 Evoluçãode software se preocupaprincipalmentecom as mudançasdo sistemaemrelaçãoa diferentesversõesoureleases do mesmo EmMaiode 2010, o Google Scholar reportouque, em2009, 70 publicaçõescontinham“software evolution” no título, e maisde 900 tinham“software evolution” emalgumlugardo texto
  • 10. Evoluçãode Software 10 Sistemasde software precisamevoluir A sociedadealtamentedinâmicaimpõeumapressãoconstanteparamudançasemsistemasde software Para continuarútil, é crucial quesistemasde software possamserfacilmenteadaptáveisa mudançascontínuase flexíveiso suficienteparaadiçãode novasfuncionalidades Software quenãoé tolerantea modificaçõesestáfadadoaoabandonooua substituição[Mens& Demeyer2008], [Bode 2009]
  • 11. EstudosemEvoluçãode Software 11 Estudossobreevoluçãopossuemdiversosobjetivos Identificaçãode boas práticasde engenhariade software baseadasnaanálisede comosistemasde sucessoe de longoprazose mantém[Bennet& Rajlich2000] Avaliaçãode hipótesesempíricassobrecaracterísticasda evoluçãode software [Lehman 1997] Padrõesde colaboraçãoentre desenvolvedores[Cataldo2008] Identificaçãode problemasde design e de códigoatravésda visualizaçãodo históricodo software [D‘Ambros& Lanza2010]
  • 12. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowandrEvolution 12
  • 13. Software Intelligence As mesmas ideias de Business Intelligence (BI), só que aplicadas no domínio de software 13
  • 14. Mineraçãode Repositóriosde Código 14 Mineraçãode Repositóriosde Código(MSR) se refereà aplicaçãode técnicasde mineraçãode dados emdados históricosde projetos[Ball et al. 1996] Estudossobreevoluçãode software frequentementeestãoassociadosà MSR
  • 15. Dados interessantes As técnicasde MSR podemencontrarpadrõesinteressantesemprojetosde software No exemploaolado, o gráficomostrao númerode bugs escritospordiada semana. Para esseprojeto, podemosverquequarta- feiraéo diaemqueessaequipeproduzmenosbugs 15
  • 17. Repositóriosde código Háváriosdeles: CVS, SVN, Git, Mercurial, Bazaar Muitascaracterísticasemcomum Mas muitascaracterísticasespecíficastambém! 17
  • 18. Benefícios Contémtodoo históricodo projetoaolongodo tempo Contéminformaçõesrelevantes, como Data/hora Desenvolvedor Mensagemexplicandoa alteração(commit message) 18
  • 19. Dificuldades Muitasequipesnãocolocammensagemnoscommits Fazemcommits grandes, dificultandoa compreensãodo mesmo Dependendodo controladorde versão, extrairdados podesertrabalhoso CVS, porexemplo, nãodásuporteparacommits atômicos 19
  • 20. Outros repositórios Listasde Discussão Bug Trackers … 20
  • 22. Issue Trackers Descriçãodo bug, severidade Data de criaçãodo ticket, data de fechamentodo ticket Desenvolvedorquefechou, desenvolvedoresqueinteragiramnadiscussão … 22
  • 23. Benefícios Uma base de dados grandesobrebugs e suascaracterísticas As informaçõesde data possibilitama criaçãode links entre o repositóriode códigoe o repositóriode bugs 23
  • 24. Dificuldades Cadaferramentaarmazena/exportadados de umamaneiradiferente Muitasequipesnãousam O link entre repositóriode códigoe repositóriode bugs é fraco Uma soluçãocomumé procurarporreferênciasa bugs nasmensagensdos commits 24
  • 26. Listasde Discussão Local ondeaconteceumagrandetrocade informaçõesrelativasaoprojeto Discute-se bugs, melhorias, novasfuncionalidades, etc. Geralmentedisponívelnaweb Bastanteusadoporprojetosopen-source 26
  • 27. Benefícios “Documentação” das discussõespodemconterdados interessantes. Altamenterelacionadoscom atividadesde mudançade código[Bird et al.06] Geralmentecontémdiscussõessobreplanosfuturos, decisõesde design Contéma “redesocial” de desenvolvedoresdo projeto 27
  • 28. Exemplo: Motivação Estudodo conteúdodas mensagensantes e depoisde umarelease; Depoisdo release Apache 1.3, houveumaquedano otimismo; Depoisdo release do Apache 2.0, houveum aumentonasocialibilidade; [Rigby & Hassan 07] 28
  • 29. Dificuldades Dados nãoestruturadosdificultama extraçãode dados Desenvolvedorcom múltiplose-mails Threads “quebradas” emváriose-mails diferentes 29
  • 31. Logs Controladores de versão proveem logs das modificações armazenadas Geralmente em texto puro Exemplo: gitlog 31
  • 32. Exemplodo diff Diffs mostrama diferençaentre umaversãoe a versãoanterior Útilparaidentificaras mudançasfeitas 32
  • 36. DependênciasLógicas Dependênciaslógicassãodependênciasimplícitasentre artefatosde software queevoluíramjuntos[Gall et al. 1998] Dependênciaslógicasocorremquandodoisartefatossãofrequentementemudadosjuntos Estatécnicapoderevelarlinks evolucionáriosentre quaisquertiposde artefatosquecompõemo sistema, incluindoarquivosde configuraçãoe documentação Dependênciaslógicassãoidentificadaspormeiode análisedos logs dos sistemasde controlede versão 36
  • 37. Requisitosde Coordenação Requisitosde coordenação(CRs) sãoempregadosparainferirdependênciasentre desenvolvedores[Cataldoet al.2006] CRs sãoinferidasa partirde doiselementos Dependênciaslógicasentre arquivose Alocaçãode tarefasparadesenvolvedores Exemplo#1: desenvolvedoresmudandoo mesmoconjuntode arquivos Exemplo#2: desenvolvedord1 devecoordenarseutrabalhocom osdesenvolvedoresd2 e d3 quandoosarquivosmodificadospord1 dependemlogicamentede arquivosmodificadospord2 e d3 37
  • 38. Prediçãode Bugs A mensagemdo commit podeajudara identificar“commits bugados” [Eyolfson, Tan, Lam 11]; Aoolhara mensagem, podemosencontrarmensagensdo tipo“bug corrigido” Bastaolharparatrás, e verquaiscommits introduziramas linhasqueforamremovidasno commit corrente Essescommits podemserconsiderados“bugados” Possibilitaa visualizaçãodos diase horáriosemqueosbugs sãogerados 38
  • 39. Prediçãode Mudanças Com base emmétricasaplicadassobredependênciaslógicas, é possívelfazerprediçõessobremudanças Ideiabásica: “ClientesquecompraramX, tambémcompraramY” A granularidadepodevariar: classes, métodos, etc. É possívelaindaprevinirerrosdecorrentesde mudançasincompletas 39
  • 40. Clones de código Com o históricoda base de códigoemmãos, é possívelprocurarporclones de código É possível, inclusive, descobrirquandoosclones foramcriados 40
  • 41. Complexidadede código O cálculoda complexidadedo código(ouqualqueroutramétrica) aolongodo tempo podepassarinformaçõesinteressantescomo: Classes maiscomplexas Classes cujacomplexidadetem aumentadoconstantemente 41
  • 42. Truck Factor A análisede desenvolvedorese artefatosmodificadospodempassarinformaçõesinteressantes, como: Artefatosquesósãomodificadosporum desenvolvedoraolongodo tempo (truck factor) Artefatosquesãomodificadosporváriosdesenvolvedorese a relaçãodisso com a complexidadedo códigogerado 42
  • 43. Ferramentasde métricas Existemvárias, como: JDepend/NDepend JavaNCSS Eclipse Metrics KalibroMetrics Byecycle iPlasma Neste caso, o desenvolvedor fica responsável por analisar as várias releases (ou versões) do código para chegar a conclusões acerca da evolução do sistema em questão 43
  • 44. JDepend/NDepend Calculamétricas, taiscomo Númerode classes e interfaces Acoplamentoaferente/eferente Abstração Instabilidade Distânciada linhaprincipal Ciclosde dependênciaentre pacotes Precisado códigocompiladoparaexecutar 44
  • 45. JavaNCSS Cálculacomplexidadeciclomáticade métodose classes Faza análiseemcimado própriocódigo-fonte, nãoexigindoo códigocompilado 45
  • 46. Eclipse Metrics Plugin do eclipse queconstantementecalculaas métricas Uma grandequantidadede métricasdiferentes Poderodarforado Eclipse É complicado, mas possível 46
  • 47. KalibroMetrics Software brasileiro Fácilde plugarnovasmétricas Jápossuimuitasmétricasimplementadas Nãoprecisade códigocompilado 47
  • 48. Byecycle Mostraas dependênciasentre osdiversospacotesdo projeto Plugin do Eclipse 48
  • 49. iPlasma-Avaliando Design Além de investigar dependências, há outros métodos mais automatizados Lanza e Marinescupropõem um conjunto de estratégias de detecção de problemas de design com base em composição de métricas e limiares 49
  • 51. Design Disharmonies (Lanzae Marinescu–Object- Oriented Metrics in Practice) 51
  • 55. Reengenharia Apósa análisedos dados, osproblemasidentificadossãotratadospormeiode técnicasde reengenharia Reengenharia (…) é o exame e alteração de um sistema para reconstituí-lo em uma nova forma e a subsequente implementação da nova forma [Chikofsky1990] No escopo de sistemas orientados a objetos, há um enorme corpo de conhecimento acerca de técnicas de reengenharia Padrõesde reengenharia Object-Oriented ReengineringPatterns[Demeyeret al. 2009] Refatoração Refactoring to Patterns [Kerievsky2004] Refactoring: Improving the Design of Existing Code [Fowler et al. 1999] 55
  • 56. Como implantarnaindústria? No PASED 2011, Ahmed Hassan comentousobreo problemado “ovoe da galinha” Para mostraro valor das técnicasde MSR, precisamosexecutá-lasnaindústria Mas paraquea indústriacomprea ideia, é precisoprimeiromostraro valor 56
  • 57. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowandrEvolution 57
  • 58. Quaisosdesafios? Quais os desafios no processo de MSR? 58
  • 59. DesafiosemMSR Exploraçãode dados não-estruturados E-mails, comentários, … Relaçãode dados entre diferentesrepositórios Informaçõessobrebugs e repositóriode código Procurardados emlugaresnãoconvencionais Entenderas limitações Poucoscommits, poucosdesenvolvedores, … 59
  • 60. DesafiosemMSR Lidarcom ruídosnosdados Melhorara qualidadedos dados nesses repositórios Facilitara extraçãode dados 60
  • 61. DesafiosemMSR Entendera necessidadedos praticantes Mostrarosresultadospráticos Avaliarprojetosquenãosejamopen-source Simplificaro acessoa tecnologia Ajudaro participantea tomardecisõessobreo projeto 61
  • 62. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowandrEvolution 62
  • 63. Visualizaçãode software A área de “Visualização de Software” estuda a representação visual estática ou animada da informaçãosobre um sistema de software baseado em sua estrutura, comportamento ou evolução [Diehl 2010] O objetivo central da visualização de software é apoiar a compreensão e análise de sistemas e algoritmos Pode ser encarada como uma atividade de Engenharia Reversa 63
  • 64. O queéumamétrica? O mapeamentode umacaracterísticaparticular de umaentidademedidaparaum valor numérico Porquemedir? Auxilianaadministraçãoda complexidade! 64
  • 65. Vantagense Desvantagens Vantagens Capacidadede quantificaraspectosde qualidade Possibilidadede automatizaras mediçõesde um sistema Desvantagens Númerossãoapenasnúmeros: nãoconfiecegamenteneles! Emgeral, capturamsomentesintomasde altagranularidade, e nãocausasde problemasde design Difícilparadesenvolvedoreslidaremcom elas Inflaçãode medições 65
  • 66. Desafios O quevisualizar? Como visualizar? Quantascoisasvisualizar(aomesmotempo)? Como associarvisualizaçãoe métricas? 66
  • 68. Visualização de Dependências Structure101 (classes) Grafos 68
  • 69. Visualização de Dependências Structure101 (pacotes e jars) Grafos 69
  • 70. Visualização de Dependências Lattix DSM (Design/dependencystructurematrix) Outbounddep Inbound dep Cyclic dep 70
  • 71. Visualizaçãode Dependências IBM SA4J Whatif Skeleton 71
  • 72. Visualização de Dependências EvolutionRadar Poderia ser qualquer outra métrica 72
  • 76. MetricsPyramid Diferentes métricas e a relação entre elas Cores indicam se valores estão dentro dos limites aceitáveis 76
  • 77. Legenda: MetricsPyramid NOP: Número de pacotes NOC: Número de classes NOM: Número de métodos LOC: Linhas de Código CYCLO: Complexidade ciclomática CALLS: Número de invocações de métodos distintos FANOUT: Número de tipos “de fora” referenciados ANDC: Número médio de classes que foram derivadas AHH: Número médio da árvore de hierarquia 77
  • 79. Existemvárias! Quantitative Evaluation of Software Quality Metrics in Open-Source Projects(Barkmannet al.) 79
  • 89. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowandrEvolution 89
  • 90. XFlow XFlowé umaferramentaextensívelquedásuportea análisesempíricasemevoluçaõde software Open-source (GPL) Baseadano protótipoTransFlow[Costa et al.2009] Apoiaa análiseintegradade aspectostécnicose sociaispormeiode ricasvisualizaçõese cálculode métricas Trataproblemasde desempenhoencontradosemtrabalhosrelacionados 90
  • 91. Princípiosde Funcionamento 91 Processamento de Dados Persistência Coleta de Dados Métricas Visualizações Parse dos logs do sistema de controle de versão Identificação de dependências lógicas e requisitos de coordenação Cálculo de métricas de projeto, commitse de arquivo Oferecimento das visualizações interativas
  • 92. Design Rationale Foco no apoio à pesquisa empírica Extensibilidade como chave para alcançar completude Faça apenas uma vez Filtre e personalize 92
  • 93. Visualizações da XFlow “Overview primeiro, zoom e filtragem, e entãodetalhessob demanda” [Shneiderman1996] Alcançadapormeiode filtrose controles Cincovisualizaçõesinterativas Gráficode Linhas Scatterplot TreeMap Grafo Atividade 93
  • 94. Mecanismosde Interação 94 (a)Abas para visualizações (b)Painel de desenvolvedores (c)Barra de informações da análise (d)Controles específicos
  • 95.
  • 96. CenárioIlustrativo#1 EvoluçãoSociotécnicade Software Como times de desenvolvimentolidamcom a saídade desenvolvedoresprincípios? A saídade líderescomprometeuo projetoGIMP inteiro(hiatode 20 mesesno desenvolvimento) [Ye & Kishida2003] Visualizaçõesde Atividadee TreeMapforamempregadasparaanalisaro Megamek(BattleTechboard game) 96
  • 99. CenárioIlustrativo#2 Efeitosda arquiteturasobredesenvolvedores Como um sistemade software cresceparaacomodarnovasfuncionalidades? A análiseintegradade dependênciaslógicas(focotécnico) e requisitosde coordenação(focosocial) dásuportepraestetipode análise A visualizaçãode grafofoiempregadaparaanalisarambos Apache LuceneejEdit(IDE) 99
  • 101. CenárioIlustrativo#3 Compreendendopapelde desenvolvedores Estudo exploratório do projeto jEdit Coleta: 10895 commits 6 anos e meio de desenvolvimento Apenas arquivos com extensão Java Análise da contribuição de 3 desenvolvedores k_satoda, jgellenee orutherfurd 101
  • 102. 102
  • 103. 103 Centralidade Tempo Centralidade Máxima do Commit
  • 104. 104 Centralidade Tempo Máxima centralidade “até então” Maior centralidade atingida até o momento (valor de referência)
  • 106. rEvolution Ferramentaquepossibilitaa geraçãode gráficossobrea evoluçãodo software Analisainformaçõesdo repositóriode código, comocommit messages, datas, desenvolvedores, etc. Executaferramentasde métricascomoJavaNCSS, JDepend, e triangulaessesvalores Diversasvisualizaçõesjáimplementadas FerramentaOpen Source quepodeserencontradaemhttp://www.github.com/mauricioaniche/rEvolution CriadaporMauricio Aniche 106
  • 107. rEvolution AtualmentesósuportaGit Implementaçãode SVN estáemandamento Permitea criaçãode novasvisualizaçõesoumediçõesde maneirafácil Persisteosdados emMySQL PorusarHibernate, tirado usuárioa necessidadede escreverINSERTs, CREATE TABLEs oucoisado tipo, aoencaixarumanova métrica 107
  • 108. Modelode Classes do rEvolution 108
  • 116. Futurodo rEvolution Product Backlog jágrande Ideiasvindasinclusive de colegasda Alemanha Integraçãocom SVN e Mercurial Interface visual parafacilitarconfiguração Hojeo usuárioconfiguraatravésde um .properties Maise maisvisualizações… 116
  • 117. Obrigado! Mauricio Aniche aniche@ime.usp.br/ @mauricioaniche Gustavo Oliva goliva@ime.usp.br/ @golivax Marco AurélioGerosa gerosa@ime.usp.br 117