Soluções Práticas para Manutenção de Software

Durante todo seu ciclo de vida, sistemas de software são sujeitos a diversas transformações de manutenção, a exemplo de adição de funcionalidades, remoção de bugs, migração para uma nova arquitetura, e atualização de bibliotecas das quais o sistema depende. Neste minicurso, apresentarei um panorama de ferramentas de auxílio a tarefas de manutenção de software, especialmente a especificação de transformações customizadas pelo desenvolvedor e a recomendação para correção automática de violações de design.

Link pro vídeo YouTube: https://www.youtube.com/watch?v=RgHL5CvPDGE

Transcript

1. Soluções Práticas para Manutenção de Software Gustavo Santos
2. Objetivo Geral ‒ Ferramentas como parte da pesquisa ‒ Foco em Manutenção de Software ‒ Também aplicável no dia-a-dia
3. Graduação Prof. Dalton Serey 2006 2010 2012 2014 2017 Formação
4. Graduação Prof. Dalton Serey 2006 2010 2012 2014 2017 Mestrado Prof. Marco Tulio Valente Formação
5. Graduação Prof. Dalton Serey 2006 2010 2012 2014 2017 Mestrado Prof. Marco Tulio Valente Doutorado Prof. Nicolas Anquetil Formação
6. Graduação Prof. Dalton Serey 2006 2010 2012 2014 2017 Mestrado Prof. Marco Tulio Valente Doutorado Prof. Nicolas Anquetil Pós-doutorado Prof. Fabio Kon Formação
7. Manutenção de Software ‒ IEEE Standard Glossary: processo de realizar mudanças num sistema de software após sua entrega
8. Manutenção de Software ‒ IEEE Standard Glossary: processo de realizar mudanças num sistema de software após sua entrega Correção de Falhas Melhoria de Performance Adaptação para Novo Ambiente
9. Manutenção Preventiva ‒ ISO/IEC 14764 ‒ Manutenção com objetivo de prevenir problemas
10. Manutenção Preventiva ‒ ISO/IEC 14764 ‒ Manutenção com objetivo de prevenir problemas Violações de Design Melhorias na Modularidade Atualização da Documentação
11. Manutenção na Prática ‒ Atividades se misturam entre si ‒ Realizar manutenção entre outras atividades ‒ Custo e esforço (de dois terços a 90%) [1] [1] Leveraging legacy system dollars for e-business. IT Professional. 2000
12. Complexidade ‒ Estabilidade da equipe ‒ Práticas de desenvolvimento questionáveis ‒ Competência da equipe
13. Consequências e Desafios ‒ Degradação da qualidade de código [2] ‒ Baixa conformidade arquitetural [3] ‒ Extra complexidade para futuras mudanças ‒ Manutenção preventiva deixada pra depois [4] [2] David Parnas. Software aging. ICSE, 1994. [3] Foundations for the study of software architecture. Software Engineering Notes. 1992. [4] When and why your code starts to smell bad. ICSE, 2015.
14. Solução Proposta Violações Código Fonte Regras de Qualidade Modelo de Qualidade checking tool
15. Solução Proposta Violações recomm. tool Recomendação (refactoring) Pré-requisitos
16. Solução Proposta Violações recomm. tool Recomendação (refactoring) Pré-requisitos
17. Exemplos de Ferramentas ‒ Restrições arquiteturais “módulo A não pode depender de módulo B” ‒ Regras de qualidade de código “variáveis temporárias devem ser acessadas”
18. Exemplos de Ferramentas ‒ Restrições arquiteturais “módulo A não pode depender de módulo B” ‒ Regras de qualidade de código “variáveis temporárias devem ser acessadas” Vamos aprender a: - Definir essas regras - Propor transformações de correção
19. Exemplos de Ferramentas ‒ Restrições arquiteturais “módulo A não pode depender de módulo B” ‒ Regras de qualidade de código “variáveis temporárias devem ser acessadas” Vamos aprender a: - Definir essas regras - Propor transformações de correção
20. Exemplos de Ferramentas ‒ Restrições arquiteturais “módulo A não pode depender de módulo B” ‒ Regras de qualidade de código “variáveis temporárias devem ser acessadas” Vamos aprender a: - Definir essas regras - Propor transformações de correção
21. Parte I — dcl-check e dcl-fix
22. dcl-check [5] ‒ Especificação de regras de dependência ‒ Plug-in pro Eclipse ‒ Exibição de warnings ‒ Sugestão de refactoring [5] A dependency constraint language to manage object-oriented software architectures. Software: Practice and Experience. 2009
23. Exemplos de regras ‒ only moduleA can-depend moduleB ‒ moduleA can-depend-only moduleB ‒ moduleA cannot-depend moduleB ‒ moduleA must-depend moduleB depend: implement, extend, create, declare, access, throw, useannotation…
24. Instalação ‒ Eclipse Neon (ou anteriores) ‒ Install New Software… ‒ http://aserg.labsoft.dcc.ufmg.br/dclsuite/ update/
25. Projeto demo: RefDiff ‒ Descobrir aplicação de refactoring em commits ‒ Repo: https://github.com/aserg-ufmg/RefDiff ‒ Executar ./gradlew eclipse
26. Regras Utilizadas — Solução ‒ only lsclipse.rules.* can-implement lsclipse.rules.Rule ‒ lsclipse.rules.* cannot-create lsclipse.rules.Rule+ ‒ only lsclipse.rules.RuleFactory can-create lsclipse.rules.Rule+ ‒ only refdiff.core.rm2.model.refactoring.* can-extend refdiff.core.rm2.model.refactoring.SDRefactor ing
27. Conclusões ‒ Linguagem simples ‒ Promover comunicação ‒ Integração total com o ambiente
28. Parte II — NextQA
29. QualityAssistant ‒ Especificação de regras de qualidade ‒ API para definição de regras específicas de domínio ‒ Exibição de warnings ‒ Sugestão de refactoring (NextQA)
30. Instalação ‒ curl https://get.pharo.org/61+vm | bash ‒ Abrir Playground ‒ Executar: Gofer it smalltalkhubUser: 'NextQA' project: 'NextQA'; configurationOf: 'NextQA'; loadVersion: #development
31. Regra demo: Variáveis Temporárias ‒ Checar se variável está declarada e não tem acesso ‒ Sugestão para remover esta variável automaticamente
32. Passo 1 Nova Regra ‒ Novo pacote ‒ Nova classe estendendo ReAbstractRule ‒ Métodos group, name, e rationale ‒ Métodos estáticos checksMethod e uniqueIdentifierName
33. Passo 2 Inspeção ‒ Método basicCheck: retornando true ‒ ReRuleManager reset ‒ Halt now (checkpoint) ‒ Alternativa com check:forCritiquesDo:
34. Passo 2 — Solução basicCheck: aMethod | theMethod accesses eresTemp | theMethod := aMethod methodNode. accesses := theMethod allAccesses collect: #name. ^ theMethod allTemporaryVariables anySatisfy: [ :tempVar | (accesses count: [ :var | tempVar = var ]) <= 1]
35. Passo 3 Display ‒ critiqueFor: (checkpoint) ‒ Identificar a variável no código ‒ Identificar o nome da variável na notificação
36. Passo 3 — Solução I check: aMethod forCritiquesDo: aBlock | ast accesses eresTemp | ast := aMethod methodNode. accesses := ast allAccesses collect: #name. ast temporaries detect: [ :tempVar | (accesses count: [ :var | tempVar name = var ]) <= 1] ifFound: [ :tempVar | aBlock cull: (self critiqueFor: tempVar) ] ifNone: [ nil ]
37. Passo 3 — Solução II critiqueFor: aTempVar | critique | critique := (ReTrivialCritique withAnchor: (ReIntervalSourceAnchor entity: aTempVar methodNode interval: aTempVar sourceInterval) by: self) tinyHint: aTempVar name. ^ critique
38. Passo 4 Sugestão ‒ Recomendar transformação para remover a violação ‒ Remover a variável temporária do método
39. Passo 4 — Solução critique := RBTransformationCritique […] critique refactoring: (RBRemoveTemporaryVariableTransformation variable: aTempVar name inMethod: aMethod selector inClass: aMethod methodClass). ^ critique
40. Conclusões ‒ Interface genérica ‒ Incentivo a regras específicas de domínio ‒ Biblioteca de transformações para especificação de sugestões ‒ Integração no ambiente de desenvolvimento
41. Obrigado http://gustavojss.github.io/ Manutenção de Software do ponto de vista prático Soluções integradas ao ambiente de desenvolvimento Extensíveis para regras de domínio específico