Minicurso sobre Evolução de Software no CBSoft 2011

492 visualizações

Publicada em

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

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
492
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Minicurso sobre Evolução de Software no CBSoft 2011

  1. 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. 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. 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. 4. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowe rEvolution 4
  5. 5. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowe rEvolution 5
  6. 6. O mundoreal… … écomplicado! FindBugsv1.3.0 (Novembro/2007) 6
  7. 7. Todosoftware útil… Mudacontinuamente Tendea tornar-se maiscomplexo Tendea crescer 7
  8. 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. 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. 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. 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. 12. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowandrEvolution 12
  13. 13. Software Intelligence As mesmas ideias de Business Intelligence (BI), só que aplicadas no domínio de software 13
  14. 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. 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. 16. Repositórios 16
  17. 17. Repositóriosde código Háváriosdeles: CVS, SVN, Git, Mercurial, Bazaar Muitascaracterísticasemcomum Mas muitascaracterísticasespecíficastambém! 17
  18. 18. Benefícios Contémtodoo históricodo projetoaolongodo tempo Contéminformaçõesrelevantes, como Data/hora Desenvolvedor Mensagemexplicandoa alteração(commit message) 18
  19. 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. 20. Outros repositórios Listasde Discussão Bug Trackers … 20
  21. 21. Issue Trackers 21
  22. 22. Issue Trackers Descriçãodo bug, severidade Data de criaçãodo ticket, data de fechamentodo ticket Desenvolvedorquefechou, desenvolvedoresqueinteragiramnadiscussão … 22
  23. 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. 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. 25. Listasde Discussão 25
  26. 26. Listasde Discussão Local ondeaconteceumagrandetrocade informaçõesrelativasaoprojeto Discute-se bugs, melhorias, novasfuncionalidades, etc. Geralmentedisponívelnaweb Bastanteusadoporprojetosopen-source 26
  27. 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. 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. 29. Dificuldades Dados nãoestruturadosdificultama extraçãode dados Desenvolvedorcom múltiplose-mails Threads “quebradas” emváriose-mails diferentes 29
  30. 30. Extraçãode dados 30
  31. 31. Logs Controladores de versão proveem logs das modificações armazenadas Geralmente em texto puro Exemplo: gitlog 31
  32. 32. Exemplodo diff Diffs mostrama diferençaentre umaversãoe a versãoanterior Útilparaidentificaras mudançasfeitas 32
  33. 33. Ferramentasprontas SVNKit(svnkit.com) JGit(eclipse.org/jgit/) 33
  34. 34. Modelandoosdados Release HistoryDatabase(RHDB) [D’Ambroset al. 2008] 34
  35. 35. Analisandoosdados 35
  36. 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. 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. 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. 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. 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. 41. Complexidadede código O cálculoda complexidadedo código(ouqualqueroutramétrica) aolongodo tempo podepassarinformaçõesinteressantescomo: Classes maiscomplexas Classes cujacomplexidadetem aumentadoconstantemente 41
  42. 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. 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. 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. 45. JavaNCSS Cálculacomplexidadeciclomáticade métodose classes Faza análiseemcimado própriocódigo-fonte, nãoexigindoo códigocompilado 45
  46. 46. Eclipse Metrics Plugin do eclipse queconstantementecalculaas métricas Uma grandequantidadede métricasdiferentes Poderodarforado Eclipse É complicado, mas possível 46
  47. 47. KalibroMetrics Software brasileiro Fácilde plugarnovasmétricas Jápossuimuitasmétricasimplementadas Nãoprecisade códigocompilado 47
  48. 48. Byecycle Mostraas dependênciasentre osdiversospacotesdo projeto Plugin do Eclipse 48
  49. 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. 50. Estratégiasde Detecção 50
  51. 51. Design Disharmonies (Lanzae Marinescu–Object- Oriented Metrics in Practice) 51
  52. 52. GodClass 52
  53. 53. Shotgun Surgery 53
  54. 54. Adotandoresultados 54
  55. 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. 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. 57. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowandrEvolution 57
  58. 58. Quaisosdesafios? Quais os desafios no processo de MSR? 58
  59. 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. 60. DesafiosemMSR Lidarcom ruídosnosdados Melhorara qualidadedos dados nesses repositórios Facilitara extraçãode dados 60
  61. 61. DesafiosemMSR Entendera necessidadedos praticantes Mostrarosresultadospráticos Avaliarprojetosquenãosejamopen-source Simplificaro acessoa tecnologia Ajudaro participantea tomardecisõessobreo projeto 61
  62. 62. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowandrEvolution 62
  63. 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. 64. O queéumamétrica? O mapeamentode umacaracterísticaparticular de umaentidademedidaparaum valor numérico Porquemedir? Auxilianaadministraçãoda complexidade! 64
  65. 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. 66. Desafios O quevisualizar? Como visualizar? Quantascoisasvisualizar(aomesmotempo)? Como associarvisualizaçãoe métricas? 66
  67. 67. Um exemplosimples Árvorequedenotaumahierarquiade classes 67
  68. 68. Visualização de Dependências Structure101 (classes) Grafos 68
  69. 69. Visualização de Dependências Structure101 (pacotes e jars) Grafos 69
  70. 70. Visualização de Dependências Lattix DSM (Design/dependencystructurematrix) Outbounddep Inbound dep Cyclic dep 70
  71. 71. Visualizaçãode Dependências IBM SA4J Whatif Skeleton 71
  72. 72. Visualização de Dependências EvolutionRadar Poderia ser qualquer outra métrica 72
  73. 73. Visualização de Dependências 73
  74. 74. Evolution Matrix 74
  75. 75. The ClassBlueprint 75
  76. 76. MetricsPyramid Diferentes métricas e a relação entre elas Cores indicam se valores estão dentro dos limites aceitáveis 76
  77. 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. 78. Métricasde referência 78
  79. 79. Existemvárias! Quantitative Evaluation of Software Quality Metrics in Open-Source Projects(Barkmannet al.) 79
  80. 80. PolymetricViews 80
  81. 81. Evospaces/Codecity 81
  82. 82. Evospaces/Codecity 82
  83. 83. Evospaces/Codecity 83
  84. 84. Evospaces/Codecity 84
  85. 85. ArgoUML 85
  86. 86. CodeCityaolongodo tempo 86
  87. 87. Diagramasde Kiviat(radares) 87
  88. 88. Gráficosde barrase linhas 88
  89. 89. Agenda Motivação Conceitos Básicos Temas Atuais de Pesquisa Métricas e Visualização XFlowandrEvolution 89
  90. 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. 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. 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. 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. 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. 95. 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
  96. 96. CenárioIlustrativo#1 97
  97. 97. CenárioIlustrativo#1 98
  98. 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
  99. 99. CenárioIlustrativo#2 Apache LuceneDependencyGraphs jEdit DependencyGraphs 100
  100. 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
  101. 101. 102
  102. 102. 103 Centralidade Tempo Centralidade Máxima do Commit
  103. 103. 104 Centralidade Tempo Máxima centralidade “até então” Maior centralidade atingida até o momento (valor de referência)
  104. 104. 105 Commitspor mês
  105. 105. 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
  106. 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
  107. 107. Modelode Classes do rEvolution 108
  108. 108. Artefatosmaismodificados 109
  109. 109. Bugs porDiae Hora 110
  110. 110. ArtefatosmaisModificadosxNúmerode bugs 111
  111. 111. Commitspordesenvolvedor 112
  112. 112. Commits porDiae Hora 113
  113. 113. Linhasadicionadasaolongodo tempo 114
  114. 114. Testes acumuladosaolongodo tempo 115
  115. 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
  116. 116. Obrigado! Mauricio Aniche aniche@ime.usp.br/ @mauricioaniche Gustavo Oliva goliva@ime.usp.br/ @golivax Marco AurélioGerosa gerosa@ime.usp.br 117

×