Abordagem das Simulações para Bugs de Código

Predição de Defeitos para Bugs de Código

Neste capítulo trataremos sobre a predição de bugs de código. Os bugs de código, em nosso domínio, são os bugs encontrados pela ferramenta SQ e eles retratam um possível mau fun-cionamento do sistema de acordo com as regras da ferramenta. Assim, nos apoiamos na identificação desses erros e pretendemos com isso predizê-los nas versões futuras do sis-tema.

4.1 Abordagem das Simulações para Bugs de Código 31

Uma característica encontrada no SQ consiste na identificação de classes Java que pos-suem bugs, além de também permitir a identificação da quantidade de erros dessas classes.

Assim, foi possível verificar classes que não possuem erros, que no caso são a maioria das classes do sistema. Também foi possível diferenciar as classes com apenas um bug e com diversos bugs, as quais eram minoritárias. Devido a essa disparidade na quantidade de bugs, verificou-se que para utilização dos algoritmos de classificação, era necessário atentar para a escolha de uma forma para representar os dados em cada conjunto especificado, e que quando criada, conseguisse um bom desempenho nesses conjuntos.

Figura 4.2: Resultado da execução dos algoritmos selecionados por agrupamentos A Figura 4.2 mostra na primeira coluna o agrupamento em três níveis (zero, um e maior igual a dois); na segunda, em cinco níveis (zero, um, entre dois e três, entre quatro e nove, e igual maior que 10); na terceira coluna, cinco níveis (zero, um, entre dois e cinco, entre seis e dez, maior que dez); na quarta, em quatro (zero, um, entre dois e nove, igual maior que dez); e na quinta coluna, dois níveis (zero e um). Segundo a simulação, pode-se concluir que a melhor forma de classificação apresentada foi a abordagem em dois níveis. Porém esta escolha foi descartada uma vez que se coloca em um mesmo estágio as classes que possuem apenas um erro com outra classe que possui diversos erros. Por exemplo, classes que pos-suem 30 erros. Desta forma, o segundo melhor entre os níveis testados foi eleito. Como é

possível perceber, o que apresentou o segundo melhor desempenho, para o mesmo conjunto de algoritmos e mesmo conjunto de dados, foi a abordagem (0, 1 e >=2). A principal métrica utilizada na comparação foi a MATPR.

Para a montagem da tabela demonstrada na Figura 4.2, através da validação cruzada, foi utilizada a versão (2-15-0) do sistema, a qual possui 6131 instâncias (Tabela 3.1). Esta versão foi escolhida por possuir o maior número de instâncias dentre todas as versões dispo-níveis. O atributo de classificação utilizado foi à métrica bugs. A partir da tabela foi possível identificar o agrupamento que apresentou o melhor desempenho, e assim indicar o caminho a ser seguido na pesquisa. Destarte, esta forma de agrupamento foi utilizada no restante da pesquisa ao que tange a predição dos bugs de código.

Diante disso, na Figura 4.1 em (a), tem-se a obtenção de informações do sistema acadê-mico da instituição. O dispositivo de controle de versão possibilita o acesso a todo código-fonte do projeto e também faz o controle das versões do sistema. O sistema está dividido por versões com suas respectivas tags de produção.

Já na etapa (b), devido ao uso da ferramenta SQ em cada versão, é possível a extração das diversas métricas usadas na pesquisa. É importante destacar que o SQ trouxe as informações de métricas do projeto apenas referentes as classes Java do sistema. Isto é, foram excluídas da análise do SQ as.jsp, os. jsf, os .jrxml, os javascripts, etc. As métricas utilizadas estão apresentadas na Tabela 2.1.

Uma das métricas disponíveis e que serviu como atributo para a classificação foi a mé-trica bugs. O SQ ao fazer a varredura do código identificou a quantidade de erros encon-trados nas classes analisadas. No que diz respeito as outras métricas, foi realizado um pré-processamento (c), ou seja, foi realizada uma limpeza dos dados extraídos, pois o SQ disponibiliza várias métricas e nem todas foram preenchidas pela ferramenta. Além disso, percebeu-se que em determinados conjuntos de métricas existia dependências que fizeram com que algumas métricas fossem preenchidas com o mesmo valor de outras, fazendo com que existisse repetição das métricas que são usadas como atributos na predição. Isto inter-feria no preditor devido à alta correlação entre as métricas. Então foi necessário fazer uma averiguação para a escolha do conjunto de métricas na delineação do problema.

Além das escolhas das métricas, conforme Tabela 2.1, foi necessário verificar a repetição dos dados extraídos pela ferramenta ao preencher as métricas em diferentes versões, pois devido ao curto espaço de tempo entre algumas versões do sistema, percebeu-se repetição destes dados. Com isso, fez-se necessário a técnica de remoção dessas repetições. Deter-minadas versões do sistema não sofreram grandes mudanças e com isso os mesmo erros encontrados foram propagados nas versões seguintes. Inicialmente utilizamos as sete pri-meiras versões do sistema (Tabela 3.1) para a criação da base a ser utilizada na predição.

Com os modelos criados (d), realizou-se a validação da predição (e) na última versão do

4.1 Abordagem das Simulações para Bugs de Código 33

SIGAA (2-19-0). Esta versão desempenhou a função da base de teste. Para isto, também foi utilizada a abordagem de remoção de dados repetidos nesta versão.

Tanto as bases de treinamento e teste criadas apresentaram problemas de desbalancea-mento. De fato, este problema é clássico neste tipo de domínio, uma vez que o número de instâncias da classe sem erros é muito maior do que as demais (com um ou mais erros). Para resolver esse problema, fizemos um undersampling (diminuição) da classe majoritária. Ou seja, na classe sem erros a qual possuía 5302 instâncias na base de treinamento e 4643 na base de testes. A ideia foi que tais números ficassem perto dos números apresentados abaixo:

• Base de treinamento: 546 instâncias com um erro e 256 instâncias com dois ou mais erros;

• Base de testes: 483 instâncias com um erro e 186 instâncias com dois ou mais erro As Tabelas de 4.1 a 4.4 mostram os resultados para 3 simulações do undersampling, o qual gerou subconjuntos de instâncias da classe sem erros. A formação de tais subconjuntos foi feita através de uma escolha aleatória, sendo o tamanho de tais subconjuntos (treinamen-to/teste) igual a 356/229 (Tabela 4.1), 401/334 (Tabela 4.2),566/505 (Tabela 4.3) e 802/669 (Tabela 4.4). Tais tabelas mostram os resultados da previsão de bugs do SQ para a versão 2-19-0 do sistema (f).

Tabela 4.1: Resultados da execução dos algoritmos de predição usando undersampling (356/229) – Bugs SQ

J48 OneR Ibk(5) RNA NB

CC 76,95% 93,76% 36,64% 89,09% 39,31%

MAE 0,1957 0,0416 0,4119 0,0866 0,4028

RMSE 0,3251 0,2039 0,5458 0,2441 0,6228

TPR 0 0,3100 1,0000 0,0260 0,9870 0,8860 TPR 1 0,9730 0,9830 0,3420 0,9250 0,2010

TPR≥2 0,8060 0,7420 0,8490 0,6830 0,2850

MPTPR 0,7690 0,9380 0,3660 0,8910 0,3930 MATPR 0,6963 0,9083 0,4056 0,8650 0,4573

CC: Instâncias Classificadas Corretamente, MAE: Erro Médio Absoluto, RMSE: Erro Quadrático Médio, TPR 0: Taxa de Verdadeiros Positivos para a Classe Sem Bugs, TPR 1: Taxa de Verdadeiros Positivos para a Classe Com Bugs, TPR≥2: Taxa de Verdadeiros Positivos para a Classe Com Dois ou Mais Bugs, MPTPR: Média Ponderada da Taxa de Verdadeiros Positivos, MATPR: Média Aritmética da Taxa de Verdadeiros Positivos

Os resultados descritos nas tabelas mostram que o algoritmo OneR foi o que apresentou o melhor desempenho, sendo que ele foi capaz de classificar corretamente mais do que 93%

das instâncias em todos as simulações realizadas. Outra conclusão é que a variabilidade da

Tabela 4.2: Resultados da execução dos algoritmos de predição usando undersampling (401/334) – Bugs SQ

J48 OneR Ibk(5) RNA NB

CC 70,69% 94,42% 34,80% 89,13% 45,36%

MAE 0,2285 0,0372 0,4035 0,0841 0,3624

RMSE 0,3520 0,1929 0,5369 0,2384 0,5914

TPR 0 0,2660 1,0000 0,1230 0,9250 0,9250 TPR 1 0,9770 0,9830 0,3250 0,9570 0,1930

TPR≥2 0,7960 0,7420 0,8120 0,6610 0,2850

MPTPR 0,7070 0,9440 0,3480 0,8910 0,4540 MATPR 0,6796 0,9083 0,4200 0,8476 0,4676

Tabela 4.3: Resultados da execução dos algoritmos de predição usando undersampling (566/505) – Bugs SQ

J48 OneR Ibk(5) RNA NB

CC 68,91% 95,23% 31,69% 92,67% 51,96%

MAE 0,2519 0,0318 0,4101 0,0644 0,3205

RMSE 0,3732 0,1783 0,5335 0,1997 0,5569

TPR 0 0,4300 1,0000 0,1110 0,9900 0,9070 TPR 1 0,9250 0,9830 0,3420 0,9880 0,2050

TPR≥2 0,7800 0,7420 0,8120 0,5970 0,2850

MPTPR 0,6890 0,9520 0,3170 0,9270 0,5200 MATPR 0,7116 0,9083 0,4216 0,8583 0,4656

acurácia é insignificante (93,76%; 94,42% 95,23%; 95,81%) quando aumentamos o número de instâncias na classe majoritária, mas foi percebido que tal acurácia tende a aumentar com o aumento de tais instâncias. Tal fato indica que o sistema tem maior facilidade de acertar a classificação das instâncias da classe sem erro.

Outro fato que chama a atenção é o valor da Taxa de Verdadeiros Positivos (0,742) para a classe com dois ou mais bugs (TPR≥2). Tal fato ocorreu em todas as 3 simulações, na qual a percentagem de instâncias de treinamento desta classe era sempre menor. Ou seja, esse

4.1 Abordagem das Simulações para Bugs de Código 35

Tabela 4.4: Resultados da execução dos algoritmos de predição usando undersampling (802/669) – Bugs SQ

J48 OneR Ibk(5) RNA NB

CC 79,52% 95,81% 38,49% 94,17% 55,98%

MAE 0,2058 0,0279 0,4055 0,0517 0,2933

RMSE 0,3092 0,1670 0,5247 0,1796 0,5331

TPR 0 0,7890 1,0000 0,2880 1,0000 0,9100 TPR 1 0,8340 0,9830 0,3620 0,9590 0,1800

TPR≥2 0,7150 0,7420 0,7900 0,6880 0,2850

MPTPR 0,7950 0,9580 0,3850 0,9420 0,5600 MATPR 0,7793 0,9083 0,4800 0,8823 0,4583

número menor influiu no aprendizado do sistema para esta classe em específico. A Figura 4.3 apresenta a Matriz de Confusão (Confusion Matrix) para os resultados da Tabela 4.4 do algoritmo OneR.

Figura 4.3: Matriz de confusão do OneR, na Tabela 4.3

Esta matriz é lida da seguinte forma. A diagonal principal mostra os acertos para cada uma das classes. Ou seja, 138 instâncias da classe “c”, que representa instâncias com dois ou mais erros, foram corretamente classificadas em tal classe, enquanto 48 foram erroneamente classificadas como sendo da classe b (classes com um erro). Desta forma, o sistema mostra que é difícil diferenciar a quantidade de erros de uma classe entre um ou mais. Note também que nenhuma instância erroneamente classificada foi indicada como da classe sem erros (zero). Isso mostra que se o sistema fosse binário, indicando apenas se a classe possui ou não erros, ele teria uma acurácia aparentemente de 100% nesta simulação.

Outra tentativa foi refazer a predição, mas desta vez utilizando a base completa para criar os modelos. Ou seja, não foi realizado nenhum tipo de balanceamento de modo que temos uma majoração da classe com ausência de bugs (Figura 4.4). Na base de treinamento dos

modelos foram colocadas as sete primeiras versões (2-12-0 até 2-18-0) do sistema retirando apenas os dados duplicados. A base de teste foi criada conforme os dados foram extraídos pelo SQ da última versão apenas (2-19-0). Desta base também foram retiradas as possí-veis duplicações. A quantidade de instâncias encontradas foi 6104 para criação dos modelos (base de treinamento) e 5154 para a base de teste. Os gráficos abaixo (Figura 4.4) mos-tram a distribuição das instâncias nas classes, em cada uma das bases, e destaca o grau de desbalanceamento das mesmas.

Figura 4.4: Distribuição das instâncias nas três classes do domínio, mostrando o alto nível de desbalanceamento

O resultado da execução é apresentado na Tabela 4.5. Como pode ser observado, o uso de toda a base com dados desbalanceados não influencia na acurácia do algoritmo OneR. Pelo contrário, tal acurácia foi aumentada em todos os algoritmos, ficando acima dos 98% no algoritmo OneR. A literatura (SIEBRA; MELLO, 2015) mostra que trabalhos que possuem este nível de acurácia com dados desbalanceados possuem uma baixa taxa de verdadeiros positivos para as classes minoritárias. Porém, isso não é observado no nosso modelo, onde TPR1 tem um valor de 0,981 e TPR≥2 é mantido em 0,742.

A análise da Matriz de Confusão também comprova este fato. Podemos observar (Fi-gura 4.5) que das 186 instâncias da classe com dois ou mais erros, 48 foram classificadas como sendo da classe com um erro; enquanto apenas 8 instâncias que são da classe com um erro foram erroneamente classificadas na classe de dois ou mais erros. Ou seja, mesmo a base estando desbalanceada, o nosso modelo foi capaz de aprender e classificar as instâncias

No documento USO DE PREDIÇÃO DE DEFEITOS APLICADA AO PROCESSO DE IDENTIFICAÇÃO E RECOMENDAÇÃO (páginas 44-51)