Detecting Modularity Flaws of Evolving Code:What the History can Reveal?

Leandra Mara da Silva, Francisco Dantas, Gustavo Honorato, Alessandro Garcia, Carlos LucenaDepartamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio), Brasil

{lsilva, fneto, ghonorato, afgarcia, lucena}@inf.puc-rio.br

Resumo—Anomalias de modularidade (ou code smells) podemprejudicar o reúso e a manutenibilidade do código ou aindaindicar a degradação da arquitetura de um sistema. Por isso,engenheiros de software têm se dedicado em pesquisar mecanis-mos que auxiliem na detecção dessas anomalias. Estratégias dedetecção de anomalias usualmente ignoram informações sobreo histórico das modificações de um sistema. Entretanto, estu-dos recentes relatam que tais estratégias têm se apresentadocontraproducentes. Este artigo propõe e avalia a utilização deestratégias de detecção formadas por métricas que considerampropriedades históricas do código em evolução. Além disso,também é proposta uma ferramenta capaz de dar suporte àabordagem. As estratégias são avaliadas em termos de precisãoe revocação para detectar três anomalias clássicas ao longodas 16 versões de dois sistemas. Duas importantes observaçõessão feitas: (i) a utilização de informações sobre a evolução dosmódulos pode contribuir com detecções eficazes de anomalias demodularidade; (ii) em ambos os sistemas, estratégias sensíveisà história apresentaram resultados consideravelmente superioresaos de estratégias convencionais.

Abstract—Modularity flaws can hamper the reuse and main-tainability of code or even indicating the architecture degradationof a system. Therefore, researchers have increasingly investigatednew mechanisms to assist the detection of these anomalies. Strate-gies for detection these flaws usually ignore information about thesoftware change history. However, recent studies report that thesestrategies have been considered counter-productive. This articleproposes and evaluates the use of detection strategies consistingof metrics that consider historic properties of evolving sourcecode. It also proposes tool support for history-sensitive detectionof modularity flaws. The strategies are evaluated in terms ofprecision and recall to detect three classic modularity flaws over16 versions of two systems. Several observations were made,including: (i) exploiting information about the code evolutioncan contribute to effective detection of modularity flaws; and(ii) in both systems, history-sensitive strategies presented resultssuperior to conventional strategies.

Index Terms—modularity flaws; detection strategies; history-sensitive metrics; empirical software engineering;

I. INTRODUÇÃO

Em desenvolvimento de sistemas, boas práticas de projetomodular [1][2] devem ser aplicadas visando-se maximizar oreúso e manutenibilidade de sistemas. Entretanto, na prática,nem sempre essa recomendação é respeitada. Sistemas desoftware sofrem uma série de mudanças de diferentes natu-rezas, levando à produção de uma série de versões ao longodo histórico dos mesmos. A maioria dessas mudanças sãode natureza corretiva ou envolvem incrementos e remoçõesde funcionalidades. Essas alterações inadvertidamente podem

levar à introdução de anomalias de modularidade1 impactandonegativamente o reúso e a decomposição modular do sistema[3]. De fato, tendo em vista as restrições de tempo ouinexperiência de programadores, é inevitável que anomaliasde modularidade sejam introduzidas em código na medida quenovas versões do sistema são geradas [2].

Um exemplo clássico desses problemas são as chamadasGod Classes, frequentemente caracterizadas por serem com-plexas e encapsularem muitas responsabilidades do sistema[1][4][5]. Essa anomalias são indesejáveis devido ao impactonegativo relacionado ao reúso e manutenibilidade do código.Além disso, elas comumente são indicadores de violaçõesbásicas de arquitetura. Um caso comum seria uma God Classque, dentre suas várias preocupações, possui código relativoa responsabilidades de diferentes camadas da arquitetura dosistema. Ou ainda que acumula responsabilidades de diferentesinteresses do padrão Modelo-Visão-Controle (MVC) [6]. Emcasos como estes, a detecção de anomalias em código poderia,adicionalmente, contribuir com a identificação de módulos quepotencialmente contribuiriam para a degradação da arquiteturado sistema.

Portanto, engenheiros de software têm se dedicado empesquisar mecanismos que auxiliem na detecção de anomaliasde modularidade de código. Métricas [7][8] e estratégias dedetecção [9][10] têm sido tradicionalmente exploradas nessecontexto. Um problema central das estratégias de detecçãotradicionais [9][10] é que elas apresentam eficácia limitada.Isto é, elas geralmente levam a um número significativode falsos positivos e falsos negativos [4][5][11]. Um fatorlimitante é que as métricas utilizadas nessas estratégias tendema se concentrar exclusivamente em propriedades de versõesparticulares dos módulos. Ou seja, atualmente, elas não levamem consideração o histórico de mudanças dos módulos paradetectar possíveis anomalias.

Poucos trabalhos na literatura têm investigado como in-formações básicas sobre a evolução dos módulos podem: (i)auxiliar na detecção eficaz de anomalias clássicas de modu-laridade, e (ii) contornar limitações das estratégias baseadasem análises individuais de versões de programas. Existemalgumas métricas sensíveis à história propostas recentementena literatura [4][5], mas nenhum trabalho tem explorado ocontexto de estratégias sensíveis à história para identificação

1Neste artigo, usaremos o termo anomalias de modularidade (ou, simples-mente, anomalias) como sinônimo ao termo em inglês code smells.

de anomalias. Em trabalhos mais próximos ao nosso [4][5],métricas de evolução são utilizadas apenas para classificarem prejudiciais ou inofensivos os resultados previamenteobtidos pela aplicação de estratégias convencionais [9][10].Dessa forma, esses trabalhos não possibilitam a detecçãodos módulos não detectados pela abordagem convencional.Quanto às ferramentas [12][13][14][15], também não existenenhuma que permita ao programador definir, de forma flexí-vel, diferentes configurações de estratégias. Elas também nãopermitem considerar o histórico evolutivo do código das apli-cações avaliadas. Um problema ainda maior é que não existequalquer evidência que estratégias sensíveis à história sejammais eficazes do que estratégias sensíveis à uma única versão.Tal negligência ocorre até mesmo para detecção de anomaliasclássicas de modularidade [2], tais como God Classes.

Nesse contexto, algumas contribuições desse artigo sãodestacadas. Primeiramente é apresentada uma revisão de con-ceitos relacionados a anomalias de modularidade de código eestratégias de detecção, além de discusões sobre limitações dasestratégias convencionais (Seção II). Na Seção III, é propostoum subconjunto de métricas e estratégias de detecção sensíveisà história, além de uma ferramenta de suporte à abordagem. Oartigo ainda apresenta uma avaliação sistemática (Seções IVe V) que compara, em termos de precisão e revocação [16],estratégias convencionais e sensíveis à história na detecção detrês anomalias clássicas de modularidade [2]: God Class (GC),Divergent Change (DC) e Shotgun Surgery (SS). Esta avali-ação é realizada ao longo de 16 versões de dois sistemas dedomínio diferentes. Embora, algumas limitações de trabalhosrelacionados já tenham sido discutidos nesta introdução, outrascomparações são apresentadas ao longo das seções do artigo.Conclusões e trabalhos futuros são apresentados na Seção VI.

II. DETECÇÃO DE ANOMALIAS DE MODULARIDADE

Esta seção apresenta os conceitos fundamentais relaciona-dos a anomalias de modularidade (Seção II-A) e a estratégiasconvencionais usadas na detecção dessas anomalias (SeçãoII-B). Exemplos e limitações dessas estratégias também sãodestacadas nas Seções II-C e II-D, respectivamente.

A. Anomalias de Modularidade

Martin Fowler e Kent Beck [2] deram uma importante con-tribuição em tal contexto. Eles catalogaram diversos problemasde código denominados por eles como “code smells”. Taltermo pode ser entendido como uma metáfora normalmenteusada para descrever sintomas observados nos módulos quepossivelmente prejudicarão o reúso ou manutenibilidade dosistema. Tratam-se de sintomas frequentemente resultantes deindevida modularidade. Por isso, neste artigo, usamos o termoanomalias de modularidade (ou, simplesmente, anomalias)como sinônimo ao termo em inglês code smells.

De acordo com Fowler [2], tais anomalias podem trazerimpactos bastante negativos ao sistema e a identificação dessesproblemas indica a necessidade de melhorar a estrutura docódigo, ou refatorá-lo [2]. Alguns exemplos de anomaliascitadas por Fowler são God Class, Divergent Change, e

Shotgun Surgery, todas selecionadas no contexto desse estudo(Seção IV-B). Nesse último caso, a má modularização dosistema pode fazer com que a alteração de uma classe possaimplicar na necessidade de alterar diversas outras, em umefeito cascata. Outras estruturas prejudiciais ao código tambémtêm sido bastante discutidas na literatura [1][2].

B. Estratégias Convencionais de Detecção

Apesar do extensivo uso de métricas, quando consideradasisoladamente, elas fornecem informações de granularidademuito fina e insuficientes para o reconhecimento de anomalias[10]. Para contornar tal limitação, pesquisadores [9][10] pro-puseram as chamadas estratégias de detecção. Uma estratégiade detecção é uma condição lógica composta por métricasque detecta módulos do código em conformidade com talcondição. Por meio do uso dessas estratégias, o desenvolvedorpode localizar diretamente classes e métodos afetados poruma anomalia de modularidade particular. Isso é possível semque ele tenha que inferir o problema a partir de um extensoconjunto de valores anormais de métricas.

As detecções são realizadas a partir de dois processosdenominados filtragem e composição [9]. A filtragem reduzo conjunto inicial dos dados e dá suporte à avaliação deuma métrica, de forma isolada. Por exemplo, na detecção deanomalias presentes em classes, “LOC > 250” define umafiltro absoluto [9] para recuperar todas as classes que possuemmais de 100 linhas; “LOC, TopValues(25%)” define um filtrorelativo [9] que recupera 25% das classes com os maioresnúmeros de linhas de código. Já o processo de composiçãotem por objetivo apoiar a interpretação correlacionada dosresultados de diferentes filtros. Isso é feito através da utilizaçãode operadores de composição: “E” ou “OU”. Por exemplo,“(LOC, TopValues(25%)) E (LOC > 100)”, indica a composi-ção dos dois filtros anteriormente mencionados.

C. Exemplos de Estratégias Convencionais de Detecção

Para detectar GCs, por exemplo, alguns pesquisadoresformularam estratégias que visam capturar classes com osseguintes sintomas: (a) acessa vários dados de classes quepossuem poucas funcionalidades, (b) possui elevada complexi-dade e, por fim, (c) apresenta baixa coesão. Para quantificar ossintomas (a), (b) e (c), Marinescu utiliza as seguintes métricas:ATFD (Acesso a Dados Estrangeiros) [9], WMC (Soma dasComplexidades dos Métodos) [9] e TCC (Intensidade da Coe-são da Classe) [9], respectivamente. A partir dessas métricas,a seguinte estratégia convencional foi definida [9].

((ATFD > 1) E (WMC, TopV alues(25%))E (TCC, BottomV alues(25%)) (1)

De acordo com a estratégia da Equação 1, serão filtradas:classes que apresentam valores de ATFD maiores que 1; 25%das classes com os maiores valores de WMC; e 25% dasclasses com os menores valores de TCC. Como o operadorde composição é do tipo “E” são consideradas God Classesapenas as classes em conformidade com os três filtros.

D. Limitações das Estratégias Convencionais

Não é difícil encontrar trabalhos que relatem sobre oconsiderável número de falsos positivos e negativos geradospor estratégias convencionais de detecção [4][5][11]. Parailustrar tal limitação, avaliaremos o resultado de detecção daestratégia de Marinescu, apresentada pela Equação 1. Trata-se de uma estratégia convencional e que, sendo assim, nãoconsidera a análise do histórico das classes para realizar asdetecções. De fato, no estado da arte, estratégias de detecção[9][10] apresentam regras com tais características, agnósticasao histórico, independentemente da anomalia a ser detectada.

A Figura 1 ilustra a classe ImageAccessor como umexemplo de GC presente em uma aplicação chamada MobileMedia [17]. Tal classe possui mais de 250 linhas de códigoe foi projetada para prover as funcionalidades de persistênciade todos os objetos de domínio da aplicação. Isto viola a idéiaque uma classe deveria capturar uma e somente uma abstração.Através de análise minuciosa do código também é possívelobservar o entrelaçamento de diferentes responsabilidades naclasse. Na Figura 1, os dois diferentes tons de cinza ilustram oentrelaçamento de código relativo a operações de persistênciados objetos de negócio: ImageData e AlbumData.

Figura 1. Entrelaçamento de responsabilidades e valores de métricasconvencionais da God Class ImageAccessor

ImageAccessor apresenta os seguintes valores de métri-cas: ATFD = 2, WMC = 32 e TCC = 28 (Figura 1). Aplicandoa estratégia representada pela Expressão 1, ela não é detectadacomo GC pois não possui um dos menores valores de coesãodo sistema. O uso de filtros relativos, como o utilizado paraavaliar TCC, contribui frequentemente com a ocorrência defalsos positivos e negativos. Isso porque a avaliação de umdeterminado módulo fica muito dependente dos resultadosdas métricas dos demais módulos. Além disso, a inclusão ouremoção de outros módulos acaba interferindo diretamente noresultado do módulo avaliado. Uma outra estratégia conven-cional [10] foi testada para detectar essa mesma anomalia.Entretanto, novamente o resultado foi contraproducente.

Uma possível limitação encontrada nessas estratégias é queas propriedades de evolução do sistema não são considera-das. Por exemplo, ImageAccessor talvez não possui umdos menores valores de coesão, mas talvez fosse importanteobservar que sua coesão veio decrescendo gradativamenteao longo de sua história. Informações sensíveis à históriacomo essa poderiam fornecer algum suporte para auxiliar nas

detecções. Entretanto, embora o desenvolvimento de softwareseja cada vez mais incremental, estratégias de detecção atuaisnão consideram a evolução das características dos módulos.

III. RECURSOS DE DETECÇÃO SENSÍVEIS À HISTÓRIA

Esta seção tem por objetivo apresentar as métricas (SeçãoIII-A), estratégias de detecção sensíveis à história (SeçãoIII-B) e a ferramenta de suporte (Seção III-C) propostas nocontexto dessa pesquisa.

A. Métricas Sensíveis à História

Com o objetivo de contornar as limitações apresentadasna seção anterior e de avaliar as influências de se utilizarinformações sobre a evolução em estratégias de detecção,um conjunto de métricas sensíveis à história foi definido.Enquanto métricas convencionais ou orientadas a uma únicaversão [7][8] avaliam uma “fotografia” da versão atual docódigo, métricas sensíveis à história (SHs) [4][18] considerama avaliação das características dos módulos ao longo do seuhistórico. Dessa forma, elas são capazes de fornecer indi-cadores sobre a evolução de propriedades do código, comocomplexidade, acoplamento, coesão ou outras. Muitas são asmétricas sensíveis à história definidas no contexto de nossosestudos. Entretanto, apresentamos nessa seção apenas umsubconjunto de métricas de maior relevância nesse trabalho.

As métricas apresentadas na Tabela I podem ser utiliza-das para avaliar módulos de diferentes granularidades, sejampacotes, classes ou métodos. Em conformidade com o usoda abordagem GQM (Goal-Question-Metric) [19], a primeiracoluna da tabela apresenta a pergunta a ser respondida pelosubconjunto de métricas apresentado. Além disso, a evoluçãode diferentes propriedades de código pode ser considerada portais métricas, apesar de na segunda coluna da tabela apenasa propriedade LOC (linhas de código) ter sido usada comoexemplo. A terceira coluna da Tabela I apresenta a definiçãoformal das métricas sensíveis à história e o raciocínio utilizadona implementação de cada uma na ferramenta descrita naSeção III-C.

A maioria das métricas SHs são baseadas na extensãode métricas que consideram a medição de uma única ver-são do sistema, ou seja, métricas não sensíveis à história(NSH). Nesse caso, tais métricas SHs seguem uma mesmaregra de formação na definição de suas siglas. Essa regra écomposta por dois elementos: prefixo SH + sigla de métricaNSH. O elemento “prefixo SH” representa de que forma umapropriedade P será avaliada no contexto sensível a história.Por exemplo, a propriedade complexidade pode ser avaliada(i) contabilizando-se a quantidade de vezes que tal medidacresceu ao longo da história, (ii) verificando-se a quantidadede vezes que tal propriedade permaneceu estável, ou outrasformas similares. O segundo elemento “sigla de métrica NSH”representa a sigla da métrica convencional (ou não sensível àhistória) selecionada para avaliar essa propriedade P. Note queas cinco primeiras métricas apresentadas na Tabela I, seguemtal lei de formação pois tomam como base a evolução demétricas convencionais. Nos exemplos utilizamos a métrica

Tabela IEXEMPLOS DE MÉTRICAS SENSÍVEIS À HISTÓRIA

Pergunta GQM Exemplo de MétricaSH usando LOC1

Exemplo de formulação utilizando linhas de código (LOC)

Qual o valor de uma dada pro-priedade1 na versão anterior àversão atual de um módulo?

1) pLOC (PreviousLOC)

pLOCv = LOCv−1

Qual o aumento percentual deuma propriedade da versão an-terior para a versão atual deum módulo?

2) rpiLOC (RecentPercentage Increase ofLOC)

rpiLOCv =

{0, se (LOCv < LOCv−1);LOCv − LOCv−1

LOCv−1× 100, caso contrário.

Qual o decaimento percentualde uma propridade em relaçãoao seu valor na primeira versãodo módulo?

3) rpdLOC (RecentPercentage Decrease ofLOC)

rpdLOCv =

{0, se (LOCv > LOCv−1);LOCv − LOCv−1

LOCv−1× 100, caso contrário.

Qual a variação média de umapropriedade ao longo da evo-lução de um módulo?

4) rdocLOC (RelativeDifference of OverallChange of LOC)

rdocLOCv =∑v

i=2

LOCv − LOCv−1

TLv

Qual a quantidade relativa devezes que uma determinadapropriedade cresceu ao longoda evolução de um módulo

5) rniLOC (RelativeNumber Of Increase ofLOC)

rniLOCv =∑v

i=2

Xi

TLvonde Xi =

{0, se o LOC não cresceu de vi−1 para vi

1, se o LOC cresceu de vi−1 para vi

Em quantas alterações de ver-são do sistema um determi-nado módulo se fez presente?Qual a “idade” de um determi-nado módulo no sistema?

6) TL (Time Life) TLv = (∑v

i=1Xi) − 1 onde Xi =

{0, se o módulo está presente na versão i;1, se o módulo não está presente na versão i

1Linhas de Código (LOC) foi utilizada na tabela como um exemplo de propriedade a ser inspecionada ao longo da evolução. Tais métricas sensíveis àhistória podem ser aplicadas para avaliar a evolução de qualquer outra propriedade, como coesão, acoplamento, etc.

LOC. Já a sexta métrica da tabela, a TL (ou tempo devida), não segue o padrão mencionado, pois trata-se de umamétrica sensível à história independente de qualquer métricaconvencional.

B. Estratégias de Detecção Sensíveis à História

Nesse trabalho chamamos de estratégias sensíveis à história,estratégias de detecção que levam em consideração a evoluçãodas propriedades dos módulos para “diagnosticar” anomaliasde modularidade. Dessa forma, estratégias sensíveis à históriadevem possuir, necessariamente, métricas sensíveis à história(Seção III-A) em sua composição. A estratégia sensível a umaúnica versão, a qual chamamos de estratégias convencionais,pode perder informações essenciais sobre os sintomas dosmódulos ao longo do histórico dos sistemas. Por exemplo,crescimento em linhas de código, número de alterações e assimpor diante. Alguns pesquisadores [5][20] acreditam que avaliaranomalias de modularidade considerando o passado dos mó-dulos possa contribuir para melhorar a eficácia das detecçõesatuais. Por exemplo uma classe que é frequentemente alteradaou que possui tamanho e complexidade crescentes não poderiaindicar que ela possui algum problema de modularidade? Ouainda, a constatação de classes estáveis que sofrem poucasvariações de suas propriedades, não poderia indicar um projetobem modularizado?

Destacamos que diversas estratégias SHs poderiam serconfiguradas e testadas no sentido de melhorar a eficáciarelacionada à detecção de anomalias. Entretanto, até o mo-mento, não existiam ferramentas para dar suporte à aplicação

ED-SH1 - God Class:SE complexidade é grande ou tamanho e complexidade já eram grandesem passado recente e tais propriedades continuam crescendo ENTÃOPOSSÍVEL God Class

((WMC > η) OU ((pLOC > α) E (pWMC > β) E (2)(rpiLOC > γ) E (rpiWMC > δ)))

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ED-SH2 - Divergent Change:SE a classe depende de muitas outras classes de muitos distintos pacotese além disso é grande e, ao longo da história, a dependência a outrospacotes foi crescente ENTÃO POSSÍVEL Divergent Change

((DD > α) E (NOED > β) E (3)((LOC > γ) OU (rniNOED > δ)))

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ED-SH3 - Shotgun SurgerySE alterações na classe potencialmente afetam muitos métodos e muitasoutras classes e muitas são as classes que herdam direta ou indiretamentedessa classe ENTÃO POSSÍVEL Shotgun Surgery

((CM > η E ChC > θ) OU (rniNOCC > ε)) (4)

e teste de estratégias que considerassem a evolução do código.A ferramenta a ser apresentada na Seção III-C é capaz dedar suporte a essas diferentes possibilidades de configuraçõesde estratégias. Com base nas métricas SHs apresentadas naSeção III-A, podemos propor três estratégias a serem testadasna detecção das anomalias citadas na Seção II-A. Essasestratégias são representadas pelas Equações 2, 3 e 4. Oslimites associados às métricas foram representados por letrasgregas pois estudos empíricos ainda precisam ser realizadospara que se possam determinar tais valores. Além disso, a

escolha desses valores depende também das características dosistema a ser avaliado. Como usualmente ocorre, caberá aodesenvolvedor ou avaliador de código especificar quais valoresserão utilizados para parametrizar as estratégias.

C. A Ferramenta Hist-Inspect

A ferramenta Hist-Inspect visa contornar limitações obser-vadas nas ferramentas de suporte a estratégias de detecção.Percebe-se que, embora algumas ferramentas [12][13][14][15]tenham sido propostas para suportar estratégias de detecção,nenhuma delas dá suporte a métricas ou estratégias de detecçãosensíveis à história. Além disso, a maior parte não permite queo usuário do sistema possa adicionar ou alterar estratégias.Naquelas em que alguma configuração é possível, o usuárionão possui tanta flexibilidade para criar estratégias quanto lhepoderia ser dada com especificações através de linguagensespecíficas de domínio (DSLs) [21]. Nesse contexto, atravésdas ferramentas de detecção atuais, torna-se impossível avaliaros efeitos da utilização de informações sensíveis à história nadetecção de anomalias de modularidade.

Em ferramentas clássicas como o Together [12] e a inCode[13], os algoritmos de detecção são definidos em âmbitode código por desenvolvedores, ao invés de poderem serespecificados em alto nível por especialistas no domínio dedetecção e avaliação de código. Outras ferramentas como aiPlasma [14] e a inFusion [15] até disponibilizam a inclusão ealteração de estratégias em alto nível, porém com algumaslimitações, como: (i) as novas estratégias não podem sersalvas para utilizações futuras, e (ii) as customizações sãolimitadas pelo uso de elementos e operações disponíveis emuma interface de configuração. Por exemplo, não se consegueespecificar uma estratégia que contenha a expressão m1/m2

ou a expressão m1 > m2, onde m1 e m2 representammétricas. Resumidamente, apresentamos, a seguir algumascaracterísticas da Hist-Inspect.

Utilização de Repositório de Métricas Convencionais(RMCs): como descrito na Seção III-A, as métricas sensíveisà história, em sua grande maioria, são calculadas avaliando-sea evolução de propriedades capturadas por métricas convencio-nais. Na versão atual da ferramenta, os resultados das métricasconvencionais são obtidos de arquivos XML de entrada. Àprincípio, optamos por utilizar os resultados gerados pelaTogether [12], por se tratar de uma ferramenta bem conhecidae aceita, tanto na indústria quanto na academia. Para cadaversão do sistema a ser avaliado é recebido como entrada umarquivo de extensão .mtbl2. Esse arquivo é chamado por nós de“Repositório de Métricas Convencionais vx” ou “RMC vx”,onde x representa a versão do sistema em que as métricasconvencionais foram aplicadas.

Métricas, Gráficos e Estratégias Sensíveis à História:métricas, gráficos e estratégias de detecção sensíveis à históriapodem suportar a avaliação de módulos em níveis distintos degranularidade (métodos, classes ou pacotes). Isso é possível

2Extenção do arquivo gerado pelo Together com métricas convencionais.

pois a evolução é avaliada com base em métricas convencio-nais disponibilizadas pelos RMCs e diferentes granularidadesdessas métricas são disponibilizadas nesses repositórios. Aferramenta também é capaz de suportar a especificação eaplicação tanto de estratégias sensíveis à história quanto a deestratégias convencionais. Tal recurso traz grande contribuiçãoa pesquisas que avaliam a eficácia de diferentes estratégias.

Especificação de Estratégias através de DSL Interna:a ferramenta proposta utiliza uma linguagem específica dedomínio (DSL) [21] para possibitar a especificação decla-rativa de estratégias de detecção. Isso permite ao progra-mador definir, de forma flexível, estratégias com diferentesconfigurações de métricas, valores limites e operadores decomposição. Trata-se de uma DSL interna [22] através da qualpudemos reutilizar todos os elementos sintáticos e também ointerpretador da linguagem base utilizada, o JavaScript. Taisreutilizações trouxeram como principal vantagem a rápidaimplementação da funcionalidade associada nos desobrigandoda necessidade de especificar, por exemplo, uma gramática(BNF) ou outros elementos necessários para a definição delinguagens. A Equação 5 mostra um exemplo de especificaçãousando a DSL.

(CM > 7 && ChC > 7) || (rniNOCC > 0) (5)

Note que especificar uma estratégia de detecção na Hist-Inspect é praticamente equivalente à definição formal de altonível (Equação 4). As métricas utilizadas são entendidas comosimples variáveis pelo interpretador de JavaScript. Quanto aoselementos de especificação, todos os recursos da limguagembase, como operadores lógicos (OU e E, representados res-pectivamente como “||” e “&&”) e operadores matemáticos(como “==”, “>”, “<”, “≥”), dentre outros, são automatica-mente disponibilizadas para serem utilizados. As estratégias,atualmente, são fornecidas através de um arquivo de entradadenominado Catálogo de Regras. As figuras 2 e 3 apresentamrespectivamente uma tela de apresentação de métricas SHse um relatório HTML com detecções de anomalias na Hist-Inspect. Por restrições de espaço, outras telas e outros detalhesda ferramenta são disponibilizados no sítio dessa pesquisa[23].

Figura 2. Apresentação de métricas sensíveis à história.

Figura 3. Relatório HTML com resultado de detecções.

IV. AVALIAÇÃO: PROCEDIMENTOS

Essa seção descreve os procedimentos de avaliação deestratégias sensíveis à história na detecção de anomalias demodularidade. A partir desta avaliação exploratória não énosso objetivo generalizar os resultados obtidos, mas apenasavaliar a eficácia das estratégias em versões diversas dedois sistemas. Os critérios de seleção desses sistemas bemcomo algumas de suas características são apresentadas naSeção IV-A. As anomalias selecionadas para esse estudo sãodestacadas na Seção IV-B. A Seção IV-C apresenta o processode obtenção das anomalias reais nos sistemas selecionados.Na Seção IV-D, destacamos os pressupostos dessa avaliaçãoatravés das hipóteses a serem testadas, bem como as medidasutilizadas para avaliação do conceito de eficácia (Seção IV-E).Todos os artefatos desta avaliação estão disponíveis em [23].

A. Critérios de Seleção dos Sistemas

A elaboração de oráculos ou de listas de referência (SeçãoIV-C) confiáveis é altamente dependende da disponibilizaçãode desenvolvedores ou projetistas que conheçam o códigodas aplicações alvo. Percebemos que a maioria das pesquisas[24][20] que avaliam a detecção de um elevado número desistemas e de versões se rende a tomar as detecções deestratégias convencionais como verdadeiras. Entretanto, taispesquisas possibilitam muito fortemente a propagação de errosdevido aos falsos positivos e negativos detectados. Para evitartal risco, optamos por utilizar um número reduzido de sistemase de versões, mas ter a vantagem de ter como referênciaanomalias detectadas manualmente por especialistas.

Com base nos critérios discutidos acima, selecionamos doissistemas de pequeno e médio porte: Mobile Media (MM) [17]e Health Watcher (HW) [25]. O primeiro, trata-se da imple-mentação de uma linha de produtos [26] para manipulação defotos, músicas e vídeos em aparelhos celulares. O segundo éum sistema de informação de tecnologia Web cuja principalfuncionalidade é o registro de queixas relacionadas à qualidadede serviços de estabelecimentos públicos. A seleção desses

sistemas foi uma decisão estratégica baseada principalmentenas semelhanças e diferenças existentes entre eles e que foramconsideradas igualmente importantes para essa avaliação. Taissemelhanças e diferenças são descritas a seguir.

Semelhanças importantes:1) Para ambos os sistemas seria possível acessar projetistas

que poderiam identificar manualmente e/ou confirmar asanomalias reais das aplicações. Isso tornaria possível aavaliação confiável dos resultados em relação a opiniãodesses especialistas.

2) Ambos os sistemas foram desenvolvidos com a preocu-pação de atender requisitos de modularidade de código.Tal característica torna a detecção de anomalias nessessistemas longe de ser trivial. Esta particularidade foiconsiderada interessante pois poderia contribuir paraexplorarmos o apoio a detecções não óbvias e quefrequentemente passariam despercebidas por equipes dedesenvolvimento ou por estratégias convencionais.

Diferenças importantes:1) Tais aplicações pertencem a diferentes domínios, além

de utilizarem diferentes tecnologias de implementação.Tal fato contribui para que a possível obtenção deresultados comuns entre as aplicações não seja induzidapela utilização de sistemas de elevada similaridade, demesmo domínio ou mesma tecnologia.

2) Esses sistemas apresentam cenários de evolução bastantediferenciados. No MM, cada versão se diferencia da an-terior pela adição de novas funcionalidades. Enquanto noHW, as diferenças relativas às evoluções são geralmenteresultantes de sucessivas reestruturações.

Nesse estudo, foram consideradas 6 versões do MobileMedia (v2-v7) e 10 versões do Health Watcher (v1-v10). ATabela II apresenta, de forma resumida, algumas característicasquantitativas dessas aplicações. Nela, é possível observar que,apesar de termos um maior número de versões no HealthWatcher, ele possui um crescimento médio do número declasses (NOC) menor que o observado no Mobile Media. Alémdisso, o crescimento médio em linhas de código (LOC) do MMé muito mais expressivo que o do HW (238.75 contra 22.98)– o que faz com que consideremos o primeiro sistema maisinstável que o segundo. Tal comportamento provavelmente éinfluenciado pela especificidade de evolução de cada aplicação.Confirmando a informação sobre a modularidade das aplica-ções (item 2 de Semelhanças Importantes), a última linha databela destaca médias de anomalias consideravelmente baixaspara ambos os sistemas.B. Anomalias Selecionadas

As anomalias a serem detectadas no contexto dessa ava-liação são: God Class (GC), Shotgun Surgery (SS) e Di-vergent Change [1][2]. GC foi escolhida pois, segundo al-gumas pesquisas, classes com tal problema costumam serbastante instáveis e propensas a erros. Dessa forma, acredita-se que análises sensíveis à história possam contribuir comtais detecções [4]. Além disso, essa anomalia possui umaestratégia convencional para sua detecção - o que contribui

Tabela IIPRINCIPAIS CARACTERÍSTICAS DAS APLICAÇÕES DO ESTUDO

Mobile Media Health WatcherTipo de Aplicação Linha de Produto Sistema WebLing. de Programação Java JavaNº de Versões Disponíveis 8 10Nº de Versões Selecionadas 6 10LOC1 em v1 760 5295LOC em vn 2670 7593Cresc. Médio de LOC 1910/8 = 238.75 2298/10 = 22.98NOC2 em v1 16 88NOC em vn 51 135Cresc. Médio de NOC 45/8 = 5.6 47/10 = 4.7Média de GC3 (v1 à v7) 15/7 = 2.5 32/10 = 3.2

1LOC: Número de linhas de código, desconsiderando brancos e comentários;2NOC: Número de Classes; 3GC: God Classes

com possíveis comparações com estratégias da literatura. JáSS e DC foram escolhidas, pois diversas pesquisas sobremecanismos de avaliação de modularidade contemplam taisanomalias. Essas pesquisas consideram para tal detecção tantorecursos visuais [27] quanto estratégias formadas por outrostipos de métricas, por exemplo sensíveis a interesses [11].Tal fato possibilita comparações futuras com essas outrasabordagens de detecção. Além disso, no caso da anomaliaDC, não existe na literatura nenhuma estratégia convencionalpara apoiar tal detecção. Tal fato nos possibilita verificar seestratégias SHs podem trazer tal contribuição.

C. Listas de Referência ou Oráculos

Para obtenção das anomalias reais dos sistemas (SeçãoIV-A) foi solicitada a contribuição de dois especialistas decada um dos sistemas. Com a apresentação das definiçõesdas anomalias, solicitamos que eles: (i) apresentassem umalista das entidades que eles julgavam infectadas pela anomalia,e (ii) destacassem a confiabilidade de cada detecção. Essecritério seria utilizado caso fosse necessária alguma reuniãode consenso. É sabido que, devido a subjetividade encontradanas definições das anomalias, a conclusão sobre a existên-cia ou não de uma anomalia pode, frequentemente, gerarcontrovérsias. Como cada sistema foi avaliado por mais deum especialista, de forma não surpreendente, as entidadesdetectadas por um não foram exatamente as consideradas pelooutro. Para contornar tal situação, foi realizado uma reuniãoentre os mesmos para que cada um explicasse seu ponto devista e então se chegasse a uma consenso. O resultado dasdiscussões foi considerado como a opinião de um terceiroespecialista, indicando uma decisão comum. Dessa forma, ape-nas as entidades selecionadas por pelo menos dois especialistasé que passaram a fazer parte do oráculo considerado oficial.

D. Hipóteses

Nesse trabalho, definimos duas hipóteses relacionadas aeficácia de estratégias sensíveis à história. O método adotadopara avaliação da eficácia é apresentado na Seção IV-E. Paracada hipótese Hx definida é apresentada separadamente ahipótese nula (Hx-0) e a alternativa (Hx-1), onde x representao respectivo número da hipótese. A primeira hipótese objetivaavaliar estratégias SHs de forma isolada, sem comparar seus

resultados com os de estratégias convencionais. Já a segundahipótese direciona uma avaliação relativa, guiada principal-mente pela comparação dos resultados de estratégias sensíveisà história com os de estratégias convencionais. Essas hipótesessão definidas a seguir.

Hipótese 1 (H1)• H1-0: Estratégias sensíveis à história podem contribuir

com detecções eficazes de anomalias de modularidade.• H1-1: Estratégias sensíveis à história não podem contri-

buir com detecções eficazes de anomalias de modulari-dade.

Hipótese 2 (H2)• H2-0: Estratégias sensíveis à história apresentam melhor

eficácia que estratégias convencionais.• H2-1: Estratégias sensíveis à história não apresentam

melhor eficácia que estratégias convencionais.

E. Dados para Avaliação de Eficácia das Estratégias

A avaliação da eficácia no estudo foi suportada pela análisedas medidas de revocação e precisão. Além disso, outrasvariáveis a serem disponibilizadas para análises dos dados são:(i) número de acertos ou verdadeiros positivos, (ii) númerode falsos positivos e (iii) número de falsos negativos. Umacerto (VP) ocorre quando a estratégia avaliada identifica umaentidade que também está presente na lista de referência.Um falso positivo (FP) ocorre quando a entidade detectadanão se encontra na lista de detecção previamente elaborada.Um falso negativo (FN) ocorre quando uma entidade estána lista de referência mas não conseguiu ser detectada pelaestratégia avaliada. É a partir dessas variáveis que as medidasde revocação e precisão são calculadas. A revocação representao percentual de acertos em relação as entidades presentesna lista de referência. Enquanto que a precisão representa opercentual de acertos em relação as entidades detectadas. Oscálculos são realizados de acordo com as seguintes fórmulas:

Revocação =VP

VP + FNPrecisão =

VPVP + FP

F. Estratégias e Valores Limites Considerados

Para possibilitar discussões sobre as hipótese H1 e H2 asestratégias SHs apresentadas na Seção III-B foram aplicadasnos sistemas selecionados (Seção IV-A) e avaliadas em ter-mos de precisão e revocação (IV-E). De forma independente,também foram aplicadas as estratégias convencionais definidaspor Marinescu [10] para detectar as mesmas anomalias. Paraaplicação das estratégias de Marinescu foram utilizados trêsmecanismos de forma que um pudesse validar o resultado dosoutros. Esses mecanismos foram: (1) utilização da ferramentaproposta Hist-Inspect (Seção III-C); (2) aplicação manualdas estratégias a partir dos resultados de métricas geradospela ferramenta Together [12]; e (3) utilização da ferramentaiPlasma [14], proposta pelo grupo de pesquisa de Marinescu.

Cada estratégia sensível à história foi aplicada nos sistemasselecionados em dois casos. No caso1, as estratégias foramaplicada em cada versão, sem considerar o mapeamento de his-tórico das classes que sofreram refatorações de tipo “rename”.

Ou seja, uma classe renomeada passava a ser consideradauma nova classe, perdendo parte da sua história. No caso2,as mesmas estratégias foram reaplicadas assumindo que asentidades renomeadas ainda permeneciam com seus nomesoriginais. Refatorações desse tipo foram observadas apenas naversão 7 do MM e na versão 2 no HW. Nosso interesse emtestar o caso2 era o de avaliar os efeitos da abordagem sensívelà história caso ela fosse estendida de forma a conseguirdetectar a ocorrência de refatorações desse tipo. Para isso, asclasses renomeadas foram acessadas e refatoradas para querecebesses seus nomes originais. Os limites utilizados nasestratégias sensíveis à história foram testados de acordo comsugestões dos especialistas desses sistemas.

V. APRESENTAÇÃO DOS RESULTADOS E DISCUSSÕES

Nessa seção, apresentaremos os resultados de avaliaçãodas estratégias em duas etapas. Primeiro, reportaremos asmedidas definidas na Seção IV-E resultantes da aplicação dasestratégias sensíveis à história. Em seguida, reportaremos osresultados médios de precisão e revocação relativos à aplicaçãodas estratégias SHs e convencionais. As medidas de precisão erevocação versão a versão das estratégias SHs serão apresenta-das apenas para o primeiro sistema. Por limitações de espaço,no segundo sistema discutiremos apenas as médias de precisãoe revocação referentes à detecção de GCs. Entretanto, demaisdados da avaliação em tal sistema também estão disponíveisem [23]. Em todas as tabelas à seguir as medidas de precisãoe revocação foram apresentadas em sua forma percentual.Quando houve a impossibilidade de efetuar o cálculo de umadessas medidas devido a divisões por zero, um traço foiutilizado para simbolizar a situação.

A. Primeiro Sistema: Mobile Media

Eficácia de Detecções Sensíveis à História (H1): a TabelaIII apresenta os dados de avaliação referentes à detecção detodas as anomalias consideradas, em todas as versões doMobile Media. Como pode ser observado nessa tabela, emtodas as versões avaliadas a menor precisão e revocação aolongo das versões foi de 50%. Tanto na detecção de GCsquanto na detecção de DCs foi possível detectar 100% dasanomalias em pelo menos duas versões distintas. Tal resultadoocorreu em v5 e v6 no caso da detecção de GCs e de v2 à v4 nocaso de DCs. Outra observação é que nessas mesmas versões,em que o número de acertos de GCs e DCs foi máximo,também não houve a detecção de nenhum falso positivo, o quetambém repercurtiu em precisão de 100%. Pudemos constatarque apenas na versão 7 caso1 (Seção IV-F) referente à detecçãode GCs não foi possível identificar uma anomalia sequer.Entretanto, existe uma justificativa razoável para tal fato.

Tal resultado em v7 pode ser discutido analisando-se com-parativamente os resultados da estratégia pra GC nos casos 1 e2, esse último entre parênteses. O caso 2 considera a aplicaçãoda estratégia como se a avaliação fosse capaz de identificarrefatorações do tipo “rename”. Em v7, por ser a última versãoe por apresentar o maior histórico dentre as versões, eraesperado que fosse obtido um dos melhores percentuais de

Tabela IIIDETECÇÃO SENSÍVEL À HISTÓRIA NO MOBILE MEDIA

God Class (GC)v2 v3 v4 v5 v6 v71

Acertos 1 1 1 1 2 0 (1)Falsos Positivos 0 0 0 0 0 0 (0)Falsos Negativos 1 1 1 0 0 2 (1)Revocação 50% 50% 50% 100% 100% 0% (50%)Precisão 100% 100% 100% 100% 100% - (100%)

Divergent Change (DC)v2 v3 v4 v5 v6 v71

Acertos 2 2 2 2 2 2 (2)Falsos Positivos 0 0 0 0 1 2 (1)Falsos Negativos 0 0 0 1 1 2 (2)Revocação 100% 100% 100% 67% 67% 50% (50%)Precisão 100% 100% 100% 100% 67% 50% (67%)

Shotgun Surgery (SS)v21 v31 v41 v5 v6 v72

Acertos n/a n/a n/a 2 2 3 (4)Falsos Positivos 0 0 0 1 1 3 (4)Falsos Negativos 0 0 0 1 1 1 (0)Revocação n/a n/a n/a 67% 67% 75%(100%)Precisão n/a n/a n/a 67% 67% 50% (50%)

1n/a (não aplicável): não existem anomalias do tipo SS a serem detectadasnessas versões. 2Em v7, os resultados entre parênteses são referentes àaplicação da estratégia no caso2 (Seção IV-F).

acerto. Entretanto, surpreendentemente, nessa versão obteve-seo pior resultado como pode ser observado. A justificativa paratal fato é que as classes detectadas corretamente em versõesanteriores sofreram renomeação em v7. Ao considerarmoso caso2, pudemos observar que uma dentre as duas GCsexistentes em v7 passou a ser detectada. Tal fato possibilitoua obtenção de 100% de precisão na detecção de GCs emtodas as versões. A estratégia SH só não conseguiu detectar aoutra anomalia existente pois essa apresentou uma redução decomplexidade de aproximadamente 100 linhas de código. Issofez com que a estratégia SH tivesse considerado a eliminaçãoda anomalia detectada na versão anterior. Esse fato foi o únicoque impossibilitou a obtenção de uma revocação de 100%, oque já tinha sido obtido na precisão.

Elevados valores de precisão e revocação também puderamser observadas nas detecções de DC e SS. Outras observaçõesimportantes de serem feitas é que no caso de DC ainda nemexiste na literatura relacionada uma estratégia convencionalproposta para tal detectar tal anomalia. Contudo, a estratégiasensível à história avaliada para DC apresentou-se bastanteeficiente. Como relatado anteriormente, foram obtidos valoresde 100% de precisão e revocação na metade das versõesavaliadas (v2-v4). Além disso, no que diz respeito à detecçãode SS, segundo inspeção manual nem haveria a necessidade deavaliar a estratégia correspondente nas versões iniciais do MM,pois não existia tal anomalia nessas versões. Dessa forma,não seria possível avaliar o número de entidades detectadascomo anômalas corretamente nem de efetuar os cálculos deprecisão e revocação. Apesar disso, a estratégia foi aplicada e,de fato, ela não considerou a detecção de nenhuma anomaliadesse tipo entre v2 e v4, passando a identificá-la apenas apartir da versão em que se era esperado iniciar a aplicação dasestratégias. Nesses casos, de v3 à v7, também foi observado

que, considerando a possibilidade de mapear o histórico deentidades renomeadas (caso 2, entre parênteses), foi possívela detecção de 100% das anomalias desse tipo. No caso em queo mapeamento de renomeações não foi considerado tambémfoi possível obter uma revocação satisfatória de 75%.

Se nos basearmos apenas nos resultados obtidos na avalia-ção com o Mobile Media podemos dizer que são apresentadasevidências iniciais que suportam a hipótese nula de H1 (H1-0). Ou seja: “Estratégias sensíveis à história podem contribuircom detecções eficazes de anomalias de modularidade”. Todosesses dados nos trazem fortes indícios de que estratégias sen-síveis à história poderiam ser mais exploradas na identificaçãode anomalias de código.

Estratégias Sensíveis à História vs. Estratégias Conven-cionais (H2): a Tabela IV apresenta os valores médios deprecisão e revocação da aplicação das estratégias convenci-onais e sensíveis à história nas versões do Mobile Media.Como podemos observar, não há possibilidade de efetuaruma avaliação comparativa sobre os resultados de detecçãoda anomalia DC. Isso ocorre pois, como já mencionamos naSeção IV-B, não foi proposto nem em estudos mais antigos[9] nem em mais recentes [10] uma estratégia convencionalpara detectar tal anomalia. Já nos casos de GC e SS, algumasobservações podem ser feitas. Na avaliação do Mobile Media,claramente a estratégia convencional não apresentou-se efetivapara detectar GCs. Analisando separadamente as versões,cujos dados não foram apresentados por restrições de espaço,percebemos que tal estratégia detectou 50% das anomaliasem apenas duas das seis versões consideradas. Em todas asdemais não houve nenhum acerto. Nesse caso, como mostra aTabela IV, os valores médios de precisão e revocação foraminferiores a 40%. A revocação apresentou o valor médio de16.6% enquanto a precisão média o valor de 33%.

Tabela IVMÉDIAS DOS RESULTADOS DAS ESTRATÉGIAS NO MOBILE MEDIA

Estrat. Sensíveis à História Estrat. ConvencionaisGod Classes (GC)

Avg. Revocação 66.6% 16.6%Avg. Precisão 100% 33%

Divergent Change (DC)Avg. Revocação 80.6% n/a1

Avg. Precisão 89% n/a1

Shotgun Surgery (SS)Avg. Revocação 78% 38.6%Avg. Precisão 61.3% 46.6%

1Não existe na literatura estratégias convencionais para detectar DC.

Em contrapartida, utilizando uma estratégia com informa-ções sensíveis à história obteve-se uma média de revocaçãosatisfatória de 66%, com uma precisão média de 100%.Mesmo no caso da anomalia SS, foi possível uma revocaçãomédia de 78% resultante de estratégia sensível à históriacontra 38.6% resultante de estratégia convencional. Na análisede precisão ainda assim a estratégia sensível à história sesobressai à convencional com uma valor médio de 61.3%contra o valor de 46.6%. Dessa forma, de acordo com os dadosdo Mobile Media, também é possível dispor de evidências quesuportam H2-1. Ou seja, é possível que estratégias SHs sejammais eficazes que estratéias sensíveis à histórica na detecção

de anomalias de modularidade. Estratégias SHs apresentarammelhores resultados em todas as anomalias selecionadas, nãoapenas nos resultados médios de precisão e revocação mastambém em cada versão, de forma individual.

B. Segundo Sistema: Health Watcher

Eficácia de Detecções Sensíveis à História (H1): a TabelaV apresenta os dados de avaliação referentes à detecção daanomalia GC, em todas as versões do Health Watcher. Comomencionamos, por questões de espaço, disponibilizamos osdados das demais anomalias no sítio desta pesquisa [23].Enquanto no Mobile Media as estratégias sensíveis à histó-ria apresentaram-se bastante eficazes em todas as anomaliasavaliadas, no Health Watcher elas não apresentaram-se tãoeficazes. Como pode ser observado nessa tabela, a estratégiaSH possibilitou apenas a detecção de anomalias em 3 das 10versões avaliadas. Nessas versões, v4, v7 e v9, todos os valoresde revocação foram abaixo de 50%. Um ponto positivo é quenessas três versões a precisão foi de 100%. Outro avaliaçãopositiva é que, execeto em v7, em todas as demais versões,apesar de não terem ocorridos acertos ou verdadeiros positivos,também não foram detectados nenhum falso positivo. Apesardisso, o resultado não foi considerado satisfatório, devido aobaixos valores de precisão e revocação.

Como mencionamos na Seção IV-A, algumas diferençasexistentes entre o Mobile Media e Health Watcher foramconsideradas importantes para essa avaliação, justamente paraevitar replicações forçadas de bons ou maus resultados. Ouainda para não haver o favorecimento de uma ou de outra abor-dagem. Era consideralvelmente importante para essa pesquisaavaliar a eficácia das estratégias em diferentes contextos deevolução. Evidências como as apresentadas através do estudocom o Health Watcher nos fazem suspeitar que provavelmenteem sistemas com evolução pouco expressiva, isto é, em queas versões são geradas principalmente à partir de refatorações,as estratégias sensíveis à história podem não apresentar bonsresultados. De fato, os excelentes resultados de detecçõessensíveis à história observados no primeiro sistema não foramigualmente constatados no segundo.

Estratégias Sensíveis à História vs. Estratégias Convenci-onais (H2): Apesar da estratégia sensível à história não ter seapresentado muito eficaz na avaliação com o HW, pudemosobservar que, ainda assim, tal estratégia apresentou-se maiseficaz que a estratégia convencional. A Tabela IV apresenta osvalores médios de precisão e revocação dessas estratégias nasversões do Health Watcher. Enquanto a estratégia SH detectoufalso positivo apenas em v10, com a aplicação da estratégiaconvencional falsos positivos foram detectados em todas asversões. Além disso, a estratégia convencional não conseguiuobter nenhum acerto em nenhuma das 10 versões avaliadas,enquanto a estratégia SH possibilitou acertos em v4, v7 e v9.Nesse caso, apesar do resultado não satisfatório da estratégiaSH, pudemos observar uma revocação média de 10% e umaprecisão média de 33%. Enquanto a estratégia convencionalapresentou médias de 0% de precisão e de revocação, comomostra a Tabela IV. Tal fato, faz com que nesse sistema

Tabela VDETECÇÃO SENSÍVEL À HISTÓRIA NO HEALTH WATCHER

God Class (GC)v1 v2 v3 v4 v5 v6 v7 v8 v9 v10

Acertos 0 0 0 1 0 0 1 0 1 0Falsos Positivos 0 0 0 0 0 0 0 0 0 1Falsos Negativos 4 4 4 3 3 3 2 3 2 3Revocação 0% 0% 0% 25% 0% 0% 33% 0% 33% 0%Precisão - - - 100% - - 100% - 100% 0%

também seja suportada a hipótese nula de H2. Ou seja,estratégias sensíveis à história podem ser mais eficazes queestratégias convencionais.

Tabela VIMÉDIAS DOS RESULTADOS DAS ESTRATÉGIAS NO HEALTH WATCHER

Estrat. Sensíveis à História Estrat. ConvencionaisGod Classes (GC)

Avg. Revocação 10% 0%Avg. Precisão 33% 0%

VI. CONCLUSÕES E TRABALHOS FUTUROS

Nesse trabalho refinamos o conceito original de estratégiasde detecção para que tal mecanismo considerasse o uso de mé-tricas relacionadas à evolução de propriedades do código. Talabordagem foi chamada de Estratégias de Detecção Sensíveisà História e para sua composição foram definidas métricassensíveis à história. Além disso, para viabilizar a utilizaçãoda abordagem foi desenvolvida uma ferramenta capaz de darsuporte às avaliações de código. Um estudo foi realizado paraavaliar as estratégias no contexto de uma linha de produto ede um sistema web, ambos desenvolvidos com a necessidadede se priorizar requisitos de modularidade.

As estratégias possibilitaram a detecção de anomalias clás-sicas como God Class, Divergent Change e Shotgun Surgerycom elevada precisão e revocação no primeiro sistema ava-liado. No segundo sistema, em que o histórico de evoluçãoera menos expressivo, as estratégias não se apresentaram tãoeficazes, mas ainda geraram resultados mais significativos queos obtidos por estratégias convencionais. Para possibilitar umconhecimento maior sobre os benefícios e restrições de estra-tégias de detecção desse tipo outros estudos são necessários.Esses podem compreender sistemas com um maior númerode versões e ainda a utilização direta de informações deferramentas de gerência de configuração. As análises geradasnesse trabalho fornecem insumos que motivam estudos que as-sociem informações do histórico de evolução do código com adetecção de anomalias. Tais estudos podem trazer importantescontribuições a sistemas caracterizados pela necessidade de sepriorizar modularidade e manutenibilidade.

REFERÊNCIAS

[1] A. J. Riel, Object-Oriented Design Heuristics. Boston, MA, USA:Addison-Wesley Longman Publishing Co., Inc., 1996.

[2] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring:Improving the Design of Existing Code. Addison-Wesley, Reading,MA, USA, 1999.

[3] J. Buckley, T. Mens, M. Zenger, A. Rashid, and G. Kniesel, “Towards ataxonomy of software change: Research articles,” J. Softw. Maint. Evol.,vol. 17, no. 5, pp. 309–332, 2005.

[4] D. Ratiu, S. Ducasse, T. Gîrba, and R. Marinescu, “Using history infor-mation to improve design flaws detection,” in CSMR ’04: Proceedings ofthe Eighth Euromicro Working Conference on Software Maintenance andReengineering (CSMR’04). Washington, DC, USA: IEEE ComputerSociety, 2004, p. 223.

[5] D. Ratiu, S. Ducasse, T. Girba, and R. Marinescu, “Evolution-enricheddetection of god classes,” in In Proceedings of the 2ndWorkshop onComputer Aided Verification of Information Systems (CAVIS), 2004, pp.3–7.

[6] W. Pree and H. Sikora, “Design patterns for object-oriented softwaredevelopment (tutorial),” in ICSE ’97: Proceedings of the 19th internati-onal conference on Software engineering. New York, NY, USA: ACM,1997, pp. 663–664.

[7] S. R. Chidamber and C. F. Kemerer, “A metrics suite for object orienteddesign,” IEEE Trans. Softw. Eng., vol. 20, no. 6, pp. 476–493, 1994.

[8] B. Henderson-Sellers, Object-oriented metrics: measures of complexity.Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 1996.

[9] R. Marinescu, “Detection strategies: Metrics-based rules for detectingdesign flaws,” in ICSM ’04: Proceedings of the 20th IEEE InternationalConference on Software Maintenance. Washington, DC, USA: IEEEComputer Society, 2004, pp. 350–359.

[10] M. Lanza, R. Marinescu, and S. Ducasse, Object-Oriented Metrics inPractice. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2006.

[11] E. Figueiredo, C. Sant’Anna, A. Garcia, and C. Lucena, “Applying andevaluating concern-sensitive design heuristics,” in SBES ’09: Procee-dings of the 2009 XXIII Brazilian Symposium on Software Engineering.Washington, DC, USA: IEEE Computer Society, 2009, pp. 83–93.

[12] Together. [Online]. Available:http://www.borland.com/br/products/together/

[13] incode. [Online]. Available: http://loose.upt.ro/incode/pmwiki.php/[14] iplasma. [Online]. Available: http://loose.upt.ro/iplasma/[15] infusion. [Online]. Available: http://www.intooitus.com/inFusion.html[16] C. J. van Rijsbergen, “Getting into information retrieval,” pp. 1–20,

2001.[17] E. Figueiredo, N. Cacho, C. Sant’Anna, M. Monteiro, U. Kulesza,

A. Garcia, S. Soares, F. Ferrari, S. Khan, F. Castor Filho, and F. Dantas,“Evolving software product lines with aspects: an empirical study ondesign stability,” in ICSE ’08. New York, NY, USA: ACM, 2008, pp.261–270.

[18] T. Girba, S. Ducasse, and M. Lanza, “Yesterday’s weather: Guiding earlyreverse engineering efforts by summarizing the evolution of changes,”in ICSM ’04. Washington, DC, USA: IEEE Computer Society, 2004,pp. 40–49.

[19] V. R. Basili, G. Caldiera, and H. D. Rombach, “The goal question metricapproach,” in Encyclopedia of Software Engineering. Wiley, 1994.

[20] S. Olbrich, D. S. Cruzes, V. Basili, and N. Zazworka, “The evolutionand impact of code smells: A case study of two open source systems,”in ESEM ’09: Proceedings of the 2009 3rd International Symposium onEmpirical Software Engineering and Measurement. Washington, DC,USA: IEEE Computer Society, 2009, pp. 390–400.

[21] A. van Deursen, P. Klint, and J. Visser, “Domain-specific languages: anannotated bibliography,” SIGPLAN Not., vol. 35, no. 6, pp. 26–36, 2000.

[22] P. Hudak, “Building domain-specific embedded languages,” ACM Com-put. Surv., p. 196.

[23] Hist-inspect. [Online]. Available: http://www.inf.puc-rio.br/l̃silva[24] R. Shatnawi and W. Li, “An investigation of bad smells in object-oriented

design,” in ITNG ’06: Proceedings of the Third International Conferenceon Information Technology: New Generations. Washington, DC, USA:IEEE Computer Society, 2006, pp. 161–165.

[25] P. Greenwood, T. Bartolomei, E. Figueiredo, A. Garcia, N. Cacho,C. Sant’Anna, P. Borba, Uirakulesza, and A. Rashid, “On the impactof aspectual decompositions on design stability: An empirical study,” inECOOP 2007, ser. LNCS. Springer-Verlag, 2007, pp. 176–200.

[26] M. Saleh and H. Gomaa, “Separation of concerns in software productline engineering,” in MACS 05. New York, NY, USA: ACM, 2005, pp.1–5.

[27] G. Carneiro, C. Sant’Anna, A. F. Garcia, C. v. F. G. Chavez, and M. G.Mendonça, “On the use of software visualization to support concernmodularization analysis,” in ACoM 09, Florida, USA, 2009.