• Nenhum resultado encontrado

3 Analisando Causas de Crash: Um Estudo Exploratório

4.1 Visão Geral

4.2.6 Projeto Detalhado da Ferramenta

Para implementar o plug-in para a IDE Eclipse, utilizamos uma API, disponibilizada pela própria comunidade do Eclipse, chamada Eclipse Java Development Tools (JDT). A

JDT fornece um conjunto de ferramentas necessárias para implementar plug-ins para o Eclipse utilizando o próprio Eclipse para desenvolvê-los (ECLIPSE, 2019). Com ela, podemos construir views da IDE, popups, menus, alertas diretamente no editor do código-fonte, etc.

Além da JDT, utilizamos uma biblioteca interna da organização que desenvolve o SIPAC chamada sinfo-arq-data-elasticsearch. Esta API fornece alguns mecanismos para consultas no servidor elasticsearch implantado na organização.

O projeto está organizado em 10 pacotes de classes, conforme apresentado na Figura 20.

Figura 20: Diagrama de pacotes do projeto CrashAwareDev.

Os pacotes ast contém classes que realizam a leitura do código-fonte a ser analisado e o transformam em uma árvore de sintaxe abstrata (do inglês, abstract syntax tree). A AST é uma representação onde os elementos do código Java são transformados em objetos

que podem ser mais facilmente verificados por um analisador de código. O pacote dao contém as classes responsáveis pelas consultas e persistência das informações de exceções em uma base de dados relacional. Já os pacotes view e handlers consistem nas classes que descrevem as telas da CrashAwareDev e os tratadores de eventos, respectivamente. Já em provider e search estão os artefatos utilizados para comunicação com o servidor

elasticsearch. Nos pacotes startup e verifier estão as classes associadas ao analisador

estático de código e do controle do ciclo de vida da ferramenta. Por fim, o pacote model contém as classes que representam as entidades da aplicação.

Na próxima subseção iremos detalhar um pouco mais algumas das principais classes da CrashAwareDev utilizando diagramas UML para facilitar a visualização dos relaciona- mentos. Iremos dividir o diagrama em várias partes e omitir algumas informações para facilitar o entendimento.

4.2.6.1 Principais Classes da CrashAwareDev

Utilizaremos pequenos diagramas de classes para apresentar as principais classes do projeto e seus relacionamentos. Criamos três diagramas que apresentarão os módulos de comunicação com o servidor do elasticsearch (que obtém informações do crash reporter ), o módulo das classes relacionadas às novas views da IDE e o módulo do analisador de código.

A Figura 21 apresenta as principais classes do módulo de comunicação com o servidor que executa o elasticsearch.

Figura 21: Diagrama com as classes responsáveis pela comunicação com o servidor elastic-

A classe QueryConsumer é uma implementação da classe GeradorQueryElasticsearch, presente na API sinfo-arq-data-elasticsearch. Sua função consiste basicamente em construir strings de busca no formato definido na linguagem de domínio específico (ou DSL, do inglês Domain Specific Language) de consultas do elasticsearch (ELASTIC, 2019). Já a classe QueryExecute estende outra classe daquela API e é responsável por executar as consultas necessárias. Por fim, a CrashProvider define o host do servidor e alguns parâmetros de consultas. Esta classe é a fachada de comunicação para os demais compo- nentes da CrashAwareDev que realizam consultas ao servidor elasticsearch e retorna no formato do modelo ResultConsume.

O diagrama mostrado na Figura 22 define as classes referentes às novas views cria- das pelo plug-in. Temos três novas visões – que serão detalhadas nas próximas seções – implementadas nas classes CrashView, TopCausesDialog e InfoExceptionView. As duas primeiras estendem classes da API JDT e tem como dependência a CrashProvider para realizar as consultas aos dados que serão exibidos nas visões. A terceira consulta e per- siste informações diretamente da base de dados relacional, através de métodos da classe ExceptionInfoDao.

Figura 22: Diagrama com as classes responsáveis pela renderização de interfaces de visualização no Eclipse.

Por fim, temos a Figura 23 que mostra o diagrama UML com o módulo de análise estática de código, que é responsável por analisar e alertar sobre possíveis bug patterns presentes no código-fonte.

Figura 23: Diagrama com as classes responsáveis pela análise estática de código realizada pela CrashAwareDev.

A classe StartupClass é responsável por configurar e controlar o analisador, além de criar e deletar os alertas gerados (utilizando os métodos createMarkers e deleterMarkers. Ela utiliza métodos estáticos da classe ParseAST que geram a árvore de sintaxe abstrata descritas anteriormente. É utilizando esta AST que as classes de verificação fazem a análise do código. Estas classes (nomeadas com o sufixo Verifier ) implemementam a interface

PatternVerifier e sobrescrevem o método verify() que retorna uma lista de mensagens que

serão exibidas nas linhas correspondentes do código onde os problemas foram detectados. Para adicionar novas regras de verificação, basta adicionar novas classes que implemen- tam esta interface e colocá-las no pacote br.ufrn.lets.crashawaredev.verify. Não é necessário nenhuma configuração extra, pois a classe StartupClass utiliza mecanismos da API Java Reflections (MCCLUSKEY, 1998) para instanciar e executar os métodos de verificação de cada classe deste pacote. Na parte inferior da Figura 23 temos uma classe importante chamada Activator que estende a AbstractUIPlugin da JDT e é responsável por controlar o ciclo de vida da CrashAwareDev.

4.3

Discussão

Neste capítulo apresentamos a ferramenta, em forma de plug-in da IDE Eclipse, que foi proposta neste trabalho. A ferramenta exibe recomendações diretamente no código sobre trechos com potencial para gerar falhas, com base nas causas de falhas que já ocorreram.

Apesar de poucos padrões de erros implementados até agora, ela pode ser incrementada com novos padrões bastando apenas implementar uma nova classe para cada padrão (implementando a interface PatternVerifier).

Outra meta proposta da ferramenta foi aproximar mais o programador do crash report do sistema, trazendo informações do report diretamente à sua IDE, sem a necessidade de acessar um site externo para consultar informações de falhas. A CrashAwareDev é capaz de alertar sobre classes associadas a falhas recentes e que estes erros possam ser consultados diretamente em uma view do Eclipse. A partir daí, o usuário poderá acessar o

crash report através de um link direto da IDE.

Foi implementada também uma funcionalidade colaborativa em que os programadores podem adicionar informações sobre os diferentes tipos de exceções. O propósito disto é que quaisquer informações relevantes sobre as exceções, experiências em resolução de erros e padrões de erros a serem evitados possam ser compartilhadas entre os programadores.

Apresentamos também a arquitetura da ferramenta, que foi implementada com base na ferramenta proposta no trabalho de Montenegro (MONTENEGRO, 2017), aproveitando toda a parte de controle de ciclo de vida do plug-in, conversão do código para uma AST, leitura da AST e exibição de warnings no código-fonte.

Documentos relacionados