Are domain-specific detection strategies for code anomalies reusable? An industry multi-project study Reuso de Estratégias Sensíveis a Domínio para Detecção de Anomalias de Código: Um Estudo de Múltiplos Casos Alexandre Leite Silva, Alessandro Garcia, Elder José Reioli, Carlos José Pereira de Lucena Opus Group, Laboratório de Engenharia de Software Pontifícia Universidade Católica do Rio de Janeiro (PUC - Rio) Rio de Janeiro/RJ, Brasil {aleite, afgarcia, ecirilo, lucena}@inf.puc-rio.br Resumo— Para promover a longevidade de sistemas de software, estratégias de detecção são reutilizadas para identificar anomalias relacionadas a problemas de manutenção, tais como classes grandes, métodos longos ou mudanças espalhadas. Uma estratégia de detecção é uma heurística composta por métricas de software e limiares, combinados por operadores lógicos, cujo objetivo é detectar um tipo de anomalia. Estratégias pré- definidas são usualmente aplicadas globalmente no programa na tentativa de revelar onde se encontram os problemas críticos de manutenção. A eficiência de uma estratégia de detecção está relacionada ao seu reuso, dado o conjunto de projetos de uma organização. Caso haja necessidade de definir limiares e métricas para cada projeto, o uso das estratégias consumirá muito tempo e será negligenciado. Estudos recentes sugerem que o reuso das estratégias convencionais de detecção não é usualmente possível se aplicadas de forma universal a programas de diferentes domínios. Dessa forma, conduzimos um estudo exploratório em vários projetos de um domínio comum para avaliar o reuso de estratégias de detecção. Também avaliamos o reuso de estratégias conhecidas, com calibragem inicial de limiares a partir do conhecimento e análise de especialistas do domínio. O estudo revelou que, mesmo que o reuso de estratégias aumente quando definidas e aplicadas para um domínio específico, em alguns casos o reuso é limitado pela variação das características dos elementos identificados por uma estratégia de detecção. No entanto, o estudo também revelou que o reuso pode ser significativamente melhorado quando as estratégias consideram peculiaridades dos interesses recorrentes no domínio ao invés de serem aplicadas no programa como um todo. Abstract— To prevent the quality decay, detection strategies are reused to identify symptoms of maintainability problems in the entire program. A detection strategy is a heuristic composed by the following elements: software metrics, thresholds, and logical operators combining them. The adoption of detection strategies is largely dependent on their reuse across the portfolio of the organizations software projects. If developers need to define or tailor those strategy elements to each project, their use will become time-consuming and neglected. Nevertheless, there is no evidence about efficient reuse of detection strategies across multiple software projects. Therefore, we conduct an industry multi-project study to evaluate the reusability of detection strategies in a critical domain. We assessed the degree of accurate reuse of previously-proposed detection strategies based on the judgment of domain specialists. The study revealed that even though the reuse of strategies in a specific domain should be encouraged, their accuracy is still limited when holistically applied to all the modules of a program. However, the accuracy and reuse were both significantly improved when the metrics, thresholds and logical operators were tailored to each recurring concern of the domain. Palavras-chave— anomalias;detecção;reuso;acurácia I. INTRODUÇÃO Na medida em que sistemas de software são alterados, mudanças não planejadas podem introduzir problemas estruturais no código fonte. Estes problemas representam sintomas de manutenibilidade pobre do programa e, portanto, podem dificultar as atividades subsequentes de manutenção e evolução do programa [1]. Tais problemas são chamados de anomalias de código ou popularmente de bad smells [1]. Segundo estudos empíricos, módulos de programas com anomalias recorrentes, tais como métodos longos [1] e mudanças espalhadas [1], estão usualmente relacionados com introdução de falhas [17][25][26] e sintomas de degeneração de projeto [17][20][27]. Quando tais anomalias não são identificadas e removidas, é frequente a ocorrência de degradação parcial ou total do sistema [21]. À medida que um sistema cresce, identificar anomalias de código manualmente fica ainda mais difícil ou impeditivo. A automação do processo de detecção de anomalias em programas é usualmente suportada através de métricas [2][11]. Cada métrica quantifica um atributo de elementos do código fonte, tais como acoplamento [23], coesão [24] e complexidade ciclomática [22]. A partir das métricas é possível identificar uma relação entre os valores de atributos e um sintoma de problema no código. Através dessa relação é possível definir uma estratégia de detecção para apoiar a descoberta de anomalias automaticamente [1][2]. Uma estratégia de detecção é uma condição composta por métricas e limiares, combinados através de operadores lógicos. Através desta condição é possível filtrar um conjunto específico de elementos do 2013 27th Brazilian Symposium on Software Engineering /13 $31.00 © 2013 IEEE DOI 10.1109/SBES.2013.9 79