O documento discute mineração de repositórios de software, apresentando: 1) uma introdução sobre data mining e mineração de repositórios de software; 2) exemplos de estudos que mineram históricos de versão para prever mudanças futuras e guiar alterações no código; 3) um estudo que resume recomendações de mineração de repositórios ao longo da última década.

1. Mining Software Repositories
Rafael Germano Rossi
Departamento de Ciência de Computação – IME/USP

2. Tópicos
Introdução – O que é Data Mining?
Mining Software Repositories – Fontes e Ferramentas
If Your Version System Could Talk...
Mining Version History to Guide Software Changes
The MSR Cookbook – Mining a Decade of Research
Failure is a Four-Letter Word

3. O que é Data Mining?
Termo surgiu por volta de 1990.
Também conhecido como KDD (Knowledge Discovery in Databases), ou como uma parte deste processo.
Extração de padrões e informações de um conjunto de dados, além das obtidas com simples consultas, de modo a permitir análise e tomada de decisões.

4. O que é Data Mining?
No processo de negócio “Vendas” em um supermercado, é simples obter informações como:
Quantos produtos X foram vendidos no mês?
Qual é o produto de maior venda no estado, neste ano?
Data mining procura obter análises que não são explícitas como as acima:
Ao comprar o produto X, existe algum produto Y que também é comumente comprado?
Dado o perfil do comprador ou a disposição do produto na loja, é possível aumentar a venda? Como?

5. Mining Software Repositories
Mineração de repositórios de software é a prática de Data Mining, na qual a fonte de dados são os repositórios de controle de versão.
O processo de negócio analisado é o desenvolvimento do software.
Algumas possíveis análises e ações, obtidas a partir da mineração:
Detecção e prevenção de bugs
Predição de mudanças futuras
Otimização da organização do código
Otimização da divisão de tarefas na equipe de desenvolvedores

6. Mining Software Repositories - Fontes
Marco Aurélio Gerosa (gerosa@ime.usp.br) March/2014
https://github.com/about/pre
ss
http://octoverse.github.com/
11.3 millions repositories
5.4 millions users
In 2013:
• 3 millions new users
• 152 millions pushes
• 25 millions comments
• 14 millions issue
• 7 millions pull requests
36K projects
http://en.wikipedia.org/wiki/CodePlex
30K projects
https://launchpad.net
324K projects
3.4 millions developers
http://sourceforge.net/apps/trac/sourceforge/wiki/What%20is%20Sour
ceForge.net
250K projects
http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hostin
g_facilities
93K projects
1 million users
200 projects
http://projects.apache.org/indexes/alpha.html
661K projects
29 billions of lines of codes
3 millions users
33K projects
http://www.ohloh.net/

7. Mining software repositories
Marco Aurélio Gerosa (gerosa@ime.usp.br) March/2014
Mining
http://2014.msrconf.org/
“The Mining Software Repositories (MSR) field analyzes the rich data available in
software repositories to uncover interesting and actionable information about
software systems and projects.”
Information about
a project
Information about
an ecosystem
Information about
Software
Engineering
Decision making
Software
understanding
Support
maintenance
Empirical
validation of ideas
& techniques
Collaboration and software production
Practitioner Researcher
*3C Model: Fuks, H., Raposo, A., Gerosa, M.A., Pimentel, M. & Lucena, C.J.P. (2007) “The 3C Collaboration Model” in: The Encyclopedia of E-Collaboration,
Ned Kock (org), ISBN 978-1-59904-000-4, pp. 637-644.
Communication
Cooperation Coordination
3C Model*
Discussion lists
Comments on issues
Code comments
User reports
Q&A sites
Source code Social media
and artifacts Issue trackers
Project management systems
Reputation systems
Applications
Tag cloud from MSR 2014 CFP

8. Mining Software Repositories - Ferramentas

9. If Your Version System Could Talk...
Ball et al. (ICSE – 1997)
Objetivos:
Entender o histórico do processo de desenvolvimento de um software e os efeitos de decisões de desenvolvimento na evolução deste processo.
Obter métricas e analisá-las no decorrer do tempo para identificar pontos de reestruturação de modo a reduzir o esforço necessário para manter e estender um sistema.

10. If Your Version System Could Talk...
Relação entre visões dentro do desenvolvimento de software

11. If Your Version System Could Talk...
Projeto sob estudo:
5ESS – Lucent Technologies
Sistema de switch para telefonia
Estimativa de 10 milhões de linhas de código
Base de dados relacional distribuída contendo informações sobre conexões de hardware, configuração de software e clientes
Base de dados com diversas constraints, codificadas com a linguagem PRL5 e compiladas com o compilador P5CC (C++), que mudam constantemente
Necessidade de compilação rápida e código gerado com menor acesso a disco possível

12. If Your Version System Could Talk...
Relação entre visões dentro do desenvolvimento de software
Requerimento: Compilador otimizador para uma linguagem declarativa parecida com SQL
Tecnologia: C++
Desenvolvedores: Time de 6 desenvolvedores
Processo de desenvolvimento: Maioria dos componentes construídos paralelamente

13. If Your Version System Could Talk...
Compilador P5CC:
C++
Estrutura tradicional: fases léxico, parsing, checagem semântica e de tipo, otimização, geração de código
As fases léxica e de parsing produzem uma AST (Abstract Syntax Tree), sobre a qual as outras fases operam
Aproximadamente 275 classes (aprox. 120 geradas por macros), divididas nas categorias: Top: classes de alto nível, usadas de base Symtab: tabela de símbolos representando tipos da linguagem PRL5 AST: classes do tipo abstract syntax tree Optim: classes que aplicam otimização às AST Quads: classes geradoras de código

14. If Your Version System Could Talk...
Versionamento:
Cada modificação no compilador é comitada em um VCS
Foram utilizados no estudo 750 MRs (Modification Records)
Modification Record:
Conjunto de mudanças feitas no commit
Captura o fato de que as mudanças estão relacionadas
Contém informações como: descrição, data de abertura e fechamento, status, desenvolvedor responsável.
Com isso, cada mudança atômica está associada com as informações fornecidas pelo MR.

15. If Your Version System Could Talk...

16. If Your Version System Could Talk...

17. If Your Version System Could Talk...

18. If Your Version System Could Talk...
Trabalhos futuros (provavelmente passado, agora):
Análise no decorrer do tempo
Melhorar o modelo de análise (variáveis mais detalhadas, novas variáveis)
Analisar o impacto de diferentes etapas do processo nos resultados obtidos e como decisões de projeto impactam no desenvolvimento

19. Mining Version History to Guide Software Changes
 Zimmermann, Weißgerber, Diehl, & Zeller (ICSE – 2004)
Objetivos:
Sugerir e prever possíveis mudanças futuras
Mostrar acoplamento de itens indetectáveis por análise do programa
Prevenir erros por mudanças incompletas

20. Mining Version History to Guide Software Changes
 Protótipo – ROSE (Reengineering Of Software Evolution)
Ideia de sugestão, como em sites de compra: “Clientes que compraram este item também compraram ...” “Desenvolvedores que alteraram este método também alteraram ...”
Consegue prever 26% das mudanças futuras a serem feitas.
15% das funções e variáveis.
As três primeiras sugestões contém uma localização correta com probabilidade de 64%.

22. Mining Version History to Guide Software Changes

23. Mining Version History to Guide Software Changes
Ameaças à validade:
O estudo foi feito com 10761 transações de oito projetos open-source. Apesar dos projetos serem diferentes, não é possível afirmar que o histórico de versionamento represente todos os tipos de projetos de desenvolvimento de softwares.
A ordem das transações não é levada em consideração, dificultando a prevenção de erros.
A qualidade das transações não foi verificada. Portanto, transações não-desejadas também foram incluídas como possíveis sugestões.
ROSE pode distrair, se um programador experiente já sabe as mudanças futuras a serem feitas. Essa ameaça só poderia ser refutada em estudos com usuários reais, que não foram realizados.

24. The MSR Cookbook – Mining a Decade of Research
Hemmati et al. (MSR – 2013)
Survey de todos os 117 full papers publicados no MSR entre 2004 e 2012
Método utilizado é o de Data Mining
Objetivo: produzir um guia de boas práticas

25. The MSR Cookbook – Mining a Decade of Research
Foram extraídos 268 comentários feitos pelos autores dos 117 papers
Os comentários foram categorizados em quatro temas:
Aquisição e preparação de dados
Síntese
Análise
Compartilhamento e replicação
Foram identificadas recomendações em comum dentro dos temas e como evoluíram
As recomendações foram publicadas em um fórum para serem evoluídas

26. The MSR Cookbook – Mining a Decade of Research
Aquisição e preparação de dados
7 de 16 recomendações, a maioria relacionada a como e o que extrair de repositórios, códigos-fonte, listas de email, etc. e como os dados devem ser pré- processados.
Síntese
4 de 16 recomendações, sobre mineração de textos, classificação de dados, predição, etc.
Análise
4 de 16 recomendações, sobre análise estatística e avaliação dos métodos de síntese
Compartilhamento e replicação
Apenas 1 recomendação das 16, sobre como melhorar a reprodutibilidade dos estudos de MSR.

27. The MSR Cookbook – Mining a Decade of Research

28. The MSR Cookbook – Mining a Decade of Research
Processo de pesquisa
Descrição dos dados: Os comentários deveriam aparentar ser generalizáveis e ter evidências no artigo os suportando. Também foram extraídos os nomes de ferramentas usadas ou desenvolvidas.
Critério para seleção das recomendações: apenas full papers da conferência de MSR. Uma recomendação deveria aparecer em pelo menos 5 artigos.
Categorização: Card sorting, resultando em 28 categorias que foram unidas nos 4 grande temas.
Representação dos resultados: Citação com o número de comentários que rementem à recomendação.

29. The MSR Cookbook – Mining a Decade of Research
Aquisição e preparação de dados:
Código-fonte

30. The MSR Cookbook – Mining a Decade of Research
Aquisição e preparação de dados:
Issues e Patches

31. The MSR Cookbook – Mining a Decade of Research
Aquisição e preparação de dados:
Artefatos de comunicação

32. The MSR Cookbook – Mining a Decade of Research
Aquisição e preparação de dados:
Mineração de texto

33. The MSR Cookbook – Mining a Decade of Research
Aquisição e preparação de dados:
Modelando os desenvolvedores

34. The MSR Cookbook – Mining a Decade of Research
Síntese:

35. The MSR Cookbook – Mining a Decade of Research
Análise:

36. The MSR Cookbook – Mining a Decade of Research
Compartilhamento e replicação:

37. The MSR Cookbook – Mining a Decade of Research
Evolução dos artigos por tema

38. The MSR Cookbook – Mining a Decade of Research
Distribuição das recomendações

39. Failure is a Four-Letter Word – A Parody in Empirical Research –
Objetivo: IROP, um método simples, leve e de fácil implementação para prever e evitar falhas em sistemas de software usando features elementares de codificação.
Objetivo real: crítica a estudos empíricos mal elaborados e mal avaliados, mostrando o que devemos e não devemos fazer.

40. Failure is a Four-Letter Word – A Parody in Empirical Research –
Hipóteses:
H1 – IROP pode prever defeitos a partir de “ações do desenvolvedor”
H2 – Se H1 é verdadeiro, IROP pode isolar “ações do desenvolvedor” propensas a erros
H3 – IROP pode prevenir erros restringindo “ações do desenvolvedor”
Objeto de estudo:
Eclipse 2.0 e 3.0 bug dataset (17000+ arquivos)

41. Failure is a Four-Letter Word – A Parody in Empirical Research –
Variáveis independentes:
As ações do programador foram modeladas nas 256 possíveis teclas digitadas. “espaço”, “e”, “t” são as de maior ocorrência

42. Failure is a Four-Letter Word – A Parody in Empirical Research –
Variável dependente:
Se o arquivo é propenso a defeitos ou não

43. Failure is a Four-Letter Word – A Parody in Empirical Research –
Predição de defeitos pelas ações do programador
Hipótese nula: a distribuição de caracteres NÃO é suficiente para prever a propensão a erros.

44. Failure is a Four-Letter Word – A Parody in Empirical Research –
Precisão e sensibilidade máximas de 74% e 32% respectivamente
“Ação do programador” é excelente para prever defeitos!

45. Failure is a Four-Letter Word – A Parody in Empirical Research –
Ação do programador  Defeitos
Hipótese nula: não há correlação entre distribuição de caracteres e propensão a defeitos

46. Failure is a Four-Letter Word – A Parody in Empirical Research –

47. Failure is a Four-Letter Word – A Parody in Empirical Research –
Trabalhos futuros:
Automação: plug-ins para IDEs para refatorar os códigos existentes, removendo as letras
Abstração: verificar se existe. Será que os programadores inconscientemente associam as letras a termos como “failure”,”mistake”,”error”,”problem”,”bug report”? As palavras “fame” e “success” não contém as letras i,r,o,p!
Generalização: os autores estão estudando códigos-fonte russos para saber se os caracteres equivalentes ИРОП também mantém a correlação e estão muito otimistas que sim!

48. Failure is a Four-Letter Word – A Parody in Empirical Research –
Por que isso tudo está errado??
Correlações não implicam em causas
Não confunda causas e sintomas
Poucas descobertas generalizam
Cuidado com “cherry-picking” (falácia)
Cuidado com fraudes
Ameaças à validade devem ajudar a entender
Transforme descobertas em ações
Solucione causas e não sintomas
Trabalhe com dados reais

49. Don’t program on Fridays
Marco Aurélio Gerosa (gerosa@imeh.uttspp.:b/r/) www.slideshare.net/taoxiease/software-analytics-towards-software-mining- March/2014
that-matters