Respondendo as Questões do Estudo

Instrumentamos a CrashAwareDev para coletar as seguintes informações durante sua execução:

∙ Usuário realizou uma busca por classe, no consultador de falhas, e qual foi o termo utilizado.

∙ Usuário clicou na opção de abrir os dados de uma falha no crash report externo à IDE.

∙ Usuário utilizou a funcionalidade de visualizar principais tipos de exceções.

∙ Quantidade de alertas exibidos a cada classe compilada. Os alertas foram contabili- zados por tipo de bug pattern ou pelo alerta de que a classe está relacionada a um

crash recente.

O primeiro passo da análise dos logs foi simplificar os dados, pois a ferramenta era executada automaticamente a cada compilação de uma classe e isto gerava logs replicados para uma mesma classe. Em seguida, analisamos os logs manualmente e os resultados que serão apresentados tópicos a seguir.

Q1: Qual o grau de utilização da CrashAwareDev?

Os resultados das métricas M1 a M4 estão listados na tabela

Métrica Quantidade

M1: Quantidade de classes alteradas 105

M2: Quantidade de classes com algum alerta 61

M3: Quantidade de alertas por cada bug pattern

BP01 - Validar obj após findByPrimaryKey() 47 BP02 - Validar argumentos de métodos utilitários 15

BP03 - Validar obj passado via request 16

BP04 - Implementação de get/set de atributos privados N/A

M4: Alertas de classes associada a crash 17

Tabela 7: Métricas coletadas para responder a questão Q1.

Durante o período de execução, coletamos nos logs a informação de que 105 classes distintas foram alteradas. Percebemos que em alguns casos foram registradas alterações de várias classes em um período muito curto de tempo (em alguns milissegundos). Estes casos foram desconsiderados em nossa análise, pois se tratam de merges automáticos de classes e, por isso, o Eclipse recompila novamente o projeto.

A cada compilação, o módulo analisador de bug patterns realizava uma verificação nas classes alteradas em busca dos padrões sintetizados na Tabela 5. Além disso, a ferramenta também analisava estas classes verificando possíveis crashes recentes em que ela estaria envolvida. Ambas as análises poderiam gerar alertas no corpo do código-fonte. Das 105 classes alteradas, 61 apresentaram alguma mensagem de alerta (58% do total).

Foram exibidos um total de 78 alertas de bug patterns. Eles foram distribuídos entre os seguintes padrões:

alerta diz respeito à consultas de objetos na base de dados e referenciados sem verificar se o valor é válido.

∙ BP02: Alertas de getParameter() não validado ocorreram 15 vezes. Este alerta é semelhante ao anterior, porém o objeto é recuperado da request da sessão.

∙ BP03: Alertas de argumentos de métodos não validados exibidos 16 vezes. Este alerta é exibido quando argumentos de classes utilitárias não são verificados se são válidos.

∙ BP04: Alertas de atributos sem métodos get/set, foram desconsiderados nesta avaliação. Ao início do estudo, foi observado que o número de falsos positivos deste padrão era muito elevado. Alguns participantes pediram para desabilitar o alerta, então não consideramos esta verificação.

Observamos também que foram exibidos 17 alertas de classes envolvidas em crashes recentes. Conforme explicado na seção 4.2.2, a ferramenta verifica nos stack traces de falhas recentes se a classe sob análise aparece no trace.

Q2: Qual o impacto dos alertas exibidos durante o desenvolvimento?

Para identificar o impacto dos alertas durante o estudo de caso, analisamos detalha- damente os logs gerados para identificar alguma redução no número de alertas de uma classe, o que significaria uma correção de algum problema alertado. A maioria dos alertas exibidos são de problemas que já existiam no código. Por este motivo, observamos que nenhum desenvolvedor resolveu nenhum problema existente. Porém, houve um caso em que identificamos um possível alerta gerado em um novo bug pattern inserido e que o desenvolvedor corrigiu após a exibição do alerta. Foi possível detectar isso analisando uma sequência de logs em uma determinada classe. No trecho do log extraído abaixo podemos observar que a classe não havia alertas, depois foi inserido um e no terceiro log o alerta não é mais contabilizado.

!ENTRY CrashAwareDev 2019-01-10 11:32:23.712 Changed class: ProcessadorAssinaDocumentos

Total of messages findByPk: 0

!ENTRY CrashAwareDev 2019-01-10 11:34:10.223 Changed class: ProcessadorAssinaDocumentos

!ENTRY CrashAwareDev 2019-01-10 11:38:59.604 Changed class: ProcessadorAssinaDocumentos

Total of messages findByPk: 0

Concluímos que o único problema inserido durante a utilização da ferramenta emitiu um alerta relevante ao desenvolvedor, porém os alertas de problemas já existentes foram desconsiderados. Não podemos afirmar que os problemas desconsiderados não foram relevantes, pois não investigamos os motivos pelo qual os participantes não corrigiram os problemas alertados.

Q3: Como os participantes utilizaram a ferramenta?

Foram realizadas 4 consultas na funcionalidade de consultar crashes, apresentada na seção 4.2.3. Ao analisar os nomes das classes pesquisadas, observamos que todas elas estão entre aquelas 17 que tiveram um alerta. Isto nos leva a crer que, ao observar que havia uma sinalização na assinatura da classe, o desenvolvedor utilizou a consulta para ver informações do erro. Porém, em apenas 2 deles o desenvolvedor utilizou o link para visualizar os detalhes do erro no relatório de falhas.

Por fim, não tivemos nenhum registro de utilização das funcionalidades de Exibição de Principais Exceções Não Capturadas (seção 4.2.5) e Exibir Informações de Tipos de Exceções (seção 4.2.4). A primeira acreditamos ser uma função mais útil para os gerentes de projeto, pois poderiam tomar algum tipo de decisão para evitar determinados tipos de erros. Já a segunda está diretamente relacionada à consulta de crashes, pois é acessada após uma consulta. Só foram realizadas 4 consultas e não necessariamente o desenvolvedor precisou de ver as informações da exceção. Além disso, por ser uma funcionalidade colaborativa, os dados devem ser alimentados a longo prazo e não avaliamos a CrashAwareDev por tempo suficiente para formar uma base com estes dados.

A Tabela 8 formaliza o resultado desta questão.

Funcionalidade Quantidade

Consulta de crashes integrada 4

Visualizar detalhes do crash 2

Consulta principais tipos de exceções 0 Consulta informações de exceções 0

Tabela 8: Detalhamento da métrica M6.

Por se tratar de uma questão com métricas subjetivas, foi elaborado um questionário para tentar respondê-la. Mostraremos os resultados deste survey na próxima seção.