Curso sobre evolução de software dado pelo nosso grupo de pesquisa do IME-USP no CBSoft 2011, em São Paulo.

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

16. Repositórios
16

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

21. Issue Trackers
21

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

25. Listasde Discussão
25

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

30. Extraçãode dados
30

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

33. Ferramentasprontas
SVNKit(svnkit.com)
JGit(eclipse.org/jgit/)
33

34. Modelandoosdados
Release HistoryDatabase(RHDB) [D’Ambroset al. 2008]
34

35. Analisandoosdados
35

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

50. Estratégiasde Detecção
50

51. Design Disharmonies (Lanzae Marinescu–Object- Oriented Metrics in Practice)
51

52. GodClass
52

53. Shotgun Surgery
53

54. Adotandoresultados
54

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

67. Um exemplosimples
Árvorequedenotaumahierarquiade classes
67

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

73. Visualização de Dependências
73

74. Evolution Matrix
74

75. The ClassBlueprint
75

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

78. Métricasde referência
78

79. Existemvárias!
Quantitative Evaluation of Software Quality Metrics in Open-Source Projects(Barkmannet al.)
79

80. PolymetricViews
80

81. Evospaces/Codecity
81

82. Evospaces/Codecity
82

83. Evospaces/Codecity
83

84. Evospaces/Codecity
84

85. ArgoUML
85

86. CodeCityaolongodo tempo
86

87. Diagramasde Kiviat(radares)
87

88. Gráficosde barrase linhas
88

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

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

97. CenárioIlustrativo#1
97

98. CenárioIlustrativo#1
98

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

100. CenárioIlustrativo#2
Apache LuceneDependencyGraphs
jEdit
DependencyGraphs
100

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)

105. 105
Commitspor mês

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

109. Artefatosmaismodificados
109

110. Bugs porDiae Hora
110

111. ArtefatosmaisModificadosxNúmerode bugs
111

112. Commitspordesenvolvedor
112

113. Commits porDiae Hora
113

114. Linhasadicionadasaolongodo tempo
114

115. Testes acumuladosaolongodo tempo
115

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