Procedimentos para a Coleta dos Dados

Para responder as questões de pesquisa, um conjunto de dados foi coletados das LPSs MobileMedia e Health Watcher. Os passos para a coleta foram os seguintes: i) Identificar e coletar code smells; ii) Identificar relações Inter-smell; iii) Medir e remover as ocorrências de Inter-smell; e iv) Analisar o impacto de ocorrências de Inter-smell na manutenibilidade da LPS.

i) Identificar e coletar code smells: os code smells das LPSs MobileMedia e Health Watcher foram identificados utilizando as ferramenta JDeodorant e PMD, essas ferramentas foram escolhidas pela disponibilidade e pela utilização em trabalhos anteriores para detecção de code smells (PAIVA1 _{et al., 2015),(SHEN; RUAN, 2008). Atualmente 4 code smells são}

suportados pela ferramenta JDeodorant: Long Method, Feature Envy, God Class e Type Cheking (KAUR; SINGH, 2016). A ferramenta PMD foi utilizada para detectar o code smell Duplicated Code.

Foi realizado o levantamento e armazenamento do número total de code smells presentes em cada release das LPSs MobileMedia e Healt Watcher.

Figura 5 – Detecção de code smells na ferramenta JDeodorant

Fonte – Elaborado pelo Autor

A Figura 5 mostra o processo de detecção do code smell Long Method utilizando a ferramenta JDeodorant. Nesta Figura pode ser observado o critério de seleção da ferramenta para identificar esse code smell, que está dermarcado com a cor verde.

Para a identificação do code smell Duplicated Code foi utilizada a ferramenta PMD como um plugin do eclipse. A Figura 6 mostra a lista de classes com esse smell. Nesse caso foi selecionada a classe BaseController para verificação e como pode ser observado, a ferramenta seleciona o trecho de código que está duplicado.

Figura 6 – Detecção de Duplicated Code com a ferramenta PMD

Fonte – Elaborado pelo Autor

Após identificação dos code smells, deu-se o início do armazenamento dessas anomalias em planilhas. A Tabela 3 mostra o padrão ou representação utilizada para armazenamento das ocorrências individuais de code smells.

Tabela 3 – Padrão de armazenamento das ocorrências de code smell

Pacote Classe Método LM FE TC GC DC

pacote1 Classe1 metodo1() X

Após a detecção de ocorrências individuais de code smells, foi percebido que alguns code smells estavam “agrupados”, ou seja, em um primeiro caso foi encontrado que em um mesmo método existia a presença de mais de um code smell, e que em um segundo caso foi detectado a presença de outros code smells em uma God Class. A Tabela 4 mostra as duas situações na Classe2 e Classe3, respectivamente.

Tabela 4 – Padrão de armazenamento das co-ocorrências de code smell

Pacote Classe Método LM FE TC GC DC

pacote1 Classe1 metodo1() X

pacote1 Classe2 método2() X X

pacote1 Classe3 método3() X X

Desta forma, com os code smells e as co-ocorrências (Inter-smell) já detectadas, o processo para Identificação das relações Inter-smell pôde ter início.

ii) Identificar relações Inter-smell: após o procedimento de identificação de ocorrências individuais de code smell e das co-ocorrências desses code smells nas LPSs MobileMedia e Health Watcher, foram detectadas as relações Inter-smell dos 5 code smells, Duplicated Code (DC), God Class (GC), Long Method (LM), Feature Envy (FE) e Type Checking(TC). Os tipos de relacionamento são descritos na Seção 2.2.2. Para identificar as relações Inter-smells foram utilizadas as métricas definidas na Seção 2.2.3.

Figura 7 – Processo para identificar relações Inter-smell

Fonte – Elaborado pelo Autor

A Figura 7 mostra como foi o procedimento para identificação das relações Inter- smell. Esse processo foi feito totalmente de maneira manual, os cálculos e resultados obtidos foram armazenados em planilhas. Note que as co-ocorrências de code smells foram marcadas com cores para facilitar no processo de identificação, após isso, as métricas indiretas exist que é o número de ocorrências de um code smell e co-exist que é o número de co-ocorrências de um code smell(CS1) juntamente com outro code smell (CS2), foram armazenadas. Após o cálculo das métricas indiretas, foi utilizada a métrica exist − overlap(CS1,CS2) que é equivalente a métrica co-exist de um CS1 e CS2 dividido pelo exist do CS1. Como exemplo, note que o exist − overlap(TC,GC) é equivalente a 1/1 pois o co-exist(TC,GC) = 1 e o número de ocorrências de TC = 1. Perceba que o inverso também acontece, o exist − overlap(GC,TC) é equivalente a 1/1 pois o co-exist(GC,TC) = 1 e o número de ocorrências de GC = 1.

Após calcular o exist − overlap(CS1,CS2), as relações Inter-smell já podem ser identificadas a partir das seguintes regras:

• Mutual Support (A ↔ B) : se exist − overlap(A,B) ≈ exist − overlap(B,A) • Rejection (A 6⇒ B) : se co − exist(A,B) ≈ 0

• Inclusion (A ⇒ B) : se exist − overlap(A,B) ≈ 1

A relação Rejection é a mais fácil de ser identificada, como exemplo, na Figura 7 o code smellDC não possui nenhuma ocorrência individual, portanto nesse exemplo, ele também não terá co-ocorrências com outros code smells, e nesse caso, assume-se que o co-exist de (DC,GC) = 0, (DC,LM) = 0, (DC,TC) = 0 e (DC,FE) = 0.

iii) Medir e remover as ocorrências de Inter-smell: nesse procedimento foi mensurada a qualidade interna do código de cada classe das LPSs MobileMedia e Health Watchercontendo as relações Inter-smell, apenas essas classes tiveram as métricas coletadas. Para o processo de medição foi utilizada a ferramenta ckjm que implementa as métricas já conhecidas na literatura e que são descritas na Seção 2.3.

Figura 8 – Processo de medição e refatoração de Inter-smell

Fonte – Elaborado pelo Autor

A Figura 8 mostra o processo de medição e refatoração neste trabalho. Primeiramente foi utilizada a ferramenta ckjm para a medição das métricas descritas na seção 2.3, nessa primeira parte foram medidas todas as classes com co-ocorrências de code smells nas oito releases de MobileMedia e nas três releases de Health Watcher. Ou seja, a medição antes do processo de refatoração.

A Tabela 5 mostra como foram armazenadas as métricas de cada classe com co- ocorrências de code smells.

Tabela 5 – Exemplo de armazenamento das métricas

Pacote Classe WMC DIT NOC CBO RFC LCOM

pacote1 Classe1 20 1 0 21 142 0

pacote1 Classe2 2 0 0 14 24 1

pacote1 Classe3 6 1 0 7 25 0

Após esse processo inicial de medição, deu-se início ao processo de refatoração das co-ocorrências, ou seja, todas as classes e métodos que possuíam co-ocorrências foram refatoradas de modo que apenas um code smell individual continuasse. Na Tabela 6 pode ser observado um exemplo hipotético de co-ocorrências de code smells antes do processo de refatoração.

Tabela 6 – Co-ocorrências de code smells antes da refatoração

Pacote Classe Método LM FE TC GC DC

pacote1 Classe1 metodo1() X X

pacote1 Classe2 método2() X X

pacote1 Classe3 método3() X X

O resultado do processo de refatoração das co-ocorrências pode ser visualizado na Tabela 7.

Tabela 7 – Resultado após o processo de refatoração

Pacote Classe Método LM FE TC GC DC

pacote1 Classe1 metodo1() X

pacote1 Classe2 método2() X

pacote1 Classe3 método3() X

Como pode ser visualizado na Tabela 7, foi eliminado pelo menos um code smell para descaracterizar a co-ocorrência. Não existiu critério na escolha do code smell a ser removido, o objetivo neste passo era apenas descaracterizar a co-ocorrência na classe ou no método.

Como pode ser observado na Figura 8, após a refatoração das co-ocorrências, a etapa de medição foi realizada novamente nas classes que tiveram co-ocorrências removidas seguindo o mesmo padrão da Tabela 5.

iv) Analisar o impacto de ocorrências de Inter-smell na manutenibilidade da LPS: a Figura 9 mostra o processo de comparação após o processo de refatoração. Todas as releasesforam comparadas, por exemplo, a release 1 original de MobileMedia foi comparada com a release 1 refatorada de MobileMedia e esse processo continuou para as sete releases

restantes de MobileMedia. O processo foi igual para Health Watcher, as três releases originais foram comparadas com as três refatoradas.

Figura 9 – Processo de Comparação da releases das LPSs

Fonte – Elaborado pelo Autor

A comparação foi realizada através dos resultados das métricas de qualidade, e foi feita a comparação apenas nas classes que tinham co-ocorrências de code smells. Para avaliar a manutenibilidade das LPSs a partir dos valores das métricas, este trabalho utiliza a mesma abordagem de Tarwani e Chug (2016), na qual os autores utilizam o somatório de todas as métricas para medir e comparar a manutenibilidade, quanto menor o valor do somatório, maior a manutenibilidade. Assim, este trabalho conseguiu avaliar se a presença dessas co-ocorrências ou Inter-smellprejudicaram a qualidade e a manutenibilidade do código dessas duas LPSs orientada a objetos.