Ferramentas de Apoio à Inspeção

Segundo Lucia e outros (2007), de maneira geral, a inspeção de software é inerentemente manual, feita em papel e, além de gastar muito tempo, é uma atividade muito trabalhosa. Kothari e outros (2004) dizem que, além de consumirem tempo e serem caras, as inspeções manuais podem ser muito tediosas e tendenciosas a erros, especificamente quando a inspeção requer uma análise completa do software. Ainda assim, a inspeção formal é considerada uma importante atividade de garantia de qualidade de software, possuindo uma boa relação entre custo e eficiência para se encontrar defeitos nos artefatos de software (BREEN, 2006).

O sucesso da inspeção depende de um procedimento sistemático para sua condução (PARNAS; LAWFORD, 2003). Como conseqüência, surge a necessidade de um apoio computacional para aumentar a eficiência do processo de inspeção (LUCIA et al., 2007). Segundo Halling, Biffl e Grünbacher (2003), as ferramentas que apóiam as inspeções são planejadas para acelerar as tarefas tediosas ajudando os inspetores a concentrar esforços em tarefas que agreguem um alto valor ao produto.

O uso de ferramentas no processo de inspeção pode influenciar significativamente o custo e o desempenho dessa atividade. Vários autores comentam que essas ferramentas podem apoiar o tratamento de uma grande variedade de documentos, auxiliar na coleta de dados, além de possibilitar a colaboração de diferentes envolvidos, tanto na preparação individual, quanto nas reuniões de inspeção (GRÜNBACHER; HALLING; BIFFL, 2003; LUCIA et al., 2007; VITHARANA; RAMAMURTHY, 2003).

Um dos pontos mais controversos relacionados com o processo de inspeção se refere à fase de reunião e seu sincronismo (LUCIA et al., 2007). O foco do desenvolvimento atual de ferramentas de inspeção está em apoiar o trabalho distribuído, mudando a natureza do processo de inspeção para outra totalmente independente de tempo e lugar, provendo meios necessários para inspecionar documentos e participar de discussões de uma maneira distribuída e assíncrona (HEDBERG; LAPPALAINEN, 2005).

Conforme pode ser visto na Figura 2.8, tendo como base os tipos de reuniões do processo de inspeção, as ferramentas evoluíram das Inspeções Síncronas para as Inspeções Distribuídas, que por sua vez evoluíram para Inspeções assíncronas.

Figura 2.8 - Evolução das ferramentas para apoiar reuniões (Adaptado de HEDBERG; LAPPALAINEN, 2005)

Mendes (2006) descreve claramente os tipos de inspeções, baseadas nas reuniões de inspeção do ponto de vista da independência de tempo e lugar:

• Inspeções Síncronas são aquelas realizadas em um determinado lugar e todos os envolvidos devem estar presentes em determinada data;

• Inspeções Distribuídas são aquelas em que os participantes podem estar geograficamente distribuídos e a reunião se realiza em determinada data, por meio de uma videoconferência, por exemplo; e

• Inspeções Assíncronas são aquelas em que os envolvidos não precisam se reunir num mesmo lugar para que o processo ocorra. Isto é possível com a utilização de ferramentas que armazenam as informações e que todos os envolvidos possam atualizar as informações e consultá-las a qualquer momento. Conforme apresentado anteriormente nesse capítulo, o processo de inspeção original incluía reuniões presenciais (FAGAN, 1976) e, por isso, as primeiras ferramentas foram desenvolvidas para dar apoio a esse tipo de reunião. Todavia, o apoio para trabalho distribuído vem sendo desenvolvido nas ferramentas de inspeção, culminando com uma total liberdade de tempo e lugar (HEDBERG, 2004).

No trabalho de Hedberg (2004), as ferramentas de inspeção de software podem ser agrupadas em quatro gerações de ferramentas, baseadas na classificação de groupware e das transições tecnológicas. Essas gerações são:

• Primeiras Ferramentas (Early tools);

• Ferramentas Distribuídas (Distributed tools); • Ferramentas Assíncronas (Asynchronous tools); e • Ferramentas baseadas em WEB (Web-based tools).

Figura 2.9 - Quatro gerações de ferramentas de apoio a inspeções (Adaptada de HEDBERG, 2004)

Ferramentas de apoio para o processo de inspeção evoluíram desde os anos 90 (HEDBERG; LAPPALAINEN, 2005). A Figura 2.9 apresenta algumas ferramentas na linha do tempo de acordo com as quatro gerações citadas acima.

Tendo em vista os benefícios agregados à utilização de apoio computacional para a área de inspeção de software, segundo Hedberg (2004), muitos esforços têm sido gastos desenvolvendo novas ferramentas para inspeção de software. Muitas dessas ferramentas apóiam particularmente inspeções de código, já existindo muitas que apóiam e até mesmo realizam análise estática do código para detectar possíveis defeitos. Cada uma dessas ferramentas procura por algum tipo de vulnerabilidade de segurança, erros de código, práticas de programação pobres e violação de estilos (SPACCO; HOVEMEYER; PUGH, 2006).

Existem ferramentas que apóiam vários tipos de artefatos, ou até mesmo o processo como um todo. Entretanto, como o foco deste trabalho encontra-se na inspeção de código, são apresentadas a seguir algumas das principais ferramentas existentes para inspeção de código.

Codestriker: É uma aplicação web de código livre que apóia revisões de código on

line. Ela possui integração com sistemas de controle de versão como CVS e Subversion. A

ferramenta permite ao inspetor ver o código e, ao identificar defeitos no software, inserir comentários a respeito dos mesmos além de acompanhar o progresso da correção dos defeitos durante o processo de inspeção. Assim que um comentário é feito, o autor do código recebe a notificação por email.

A Codestriker permite ao autor rejeitar ou aceitar o defeito identificado. A Figura 2.10 apresenta uma tela da ferramenta Codestriker, na qual pode ser visto o código ao fundo e a janela de inclusão de um novo comentário à direita. É possível ver também um histórico com os comentários anteriores.

A Codestriker ferramenta, além de facilitar a comunicação entre os membros da equipe por meio de emails (VITHARANA; RAMAMURTHY, 2003), possibilita que a quantidade de papel seja diminuída, uma vez que os comentários e decisões são armazenados em uma base de dados. Segundo os autores, a ferramenta oferece um excelente ambiente para realizar inspeções de código (CODESTRIKER, 2008). Codestriker foi escrito em PERL, é executado como um script CGI e usa o banco de dados MySQL.

Jlint: É uma ferramenta de inspeção automática de código Java. Apesar de não possuir interface gráfica, seu aprendizado é muito fácil. Jlint Le códigos escritos em Java e procura por defeitos comuns, como problemas de: inconsistências, fluxos de dados e sincronização. Além de sua execução ser muito rápida, Jlint gasta pouco esforço, uma vez que os defeitos são encontrados de forma automática (JLINT, 2008).

Programa:

public class Deadlock { Object a = new Object(); Object b = new Object(); public void foo() {

synchronized (a) { synchronized (b) { } }

}

public void bar() { synchronized (b) { synchronized (a) { } } } } Saída:

Deadlock.java:13: Lock Deadlock.a is requested while holding lock Deadlock.b, with other thread holding

Deadlock.java:7: Lock Deadlock.b is requested while holding lock Deadlock.a, with other thread holding Deadlock.

Figura 2.11 - Exemplo de uso da ferramenta Jlint (JLINT, 2008)

A Figura 2.11 apresenta um programa e a respectiva saída da ferramenta Jlint. É possível observar que o código apresenta problemas de sincronização, onde dois métodos tentam prender dois recursos de maneira alternada.

FindBugs: É outra ferramenta de análise estática de código que procura por defeitos em programas Java baseada em padrões de defeitos conhecidos (FINDBUGS, 2008). Alguns exemplos de padrões de defeitos detectados pelo FindBugs incluem (COLE et al., 2006):

• Estruturas de repetição recursivas infinitas. Métodos que invocam a si mesmos novamente em loops recursivos terminando em um Stack Overflow Error;

• Instruções ou ramificações que, se executadas, irão provocar um Null Pointer

Exception;

• Verificação de casts que lançam Class Cast Exception;

• Valor de retorno ignorado quando não pode ser ignorado; e

• Atributos públicos e estáticos que podem ser modificados por um código não confiável.

Tanto o FindBugs quanto o Jlint são ferramentas livres e inspecionam o bytecode Java na tentativa de encontrar padrões de defeitos. Ambas as ferramentas têm a capacidade de relatar vários tipos de padrões de defeitos; FindBugs pode detectar defeitos relacionados à interface enquanto Jlint pode detectar deadlocks (WOJCICKI; STROOPER, 2006). A Figura 2.12 mostra uma tela da ferramenta FindBugs. Na parte esquerda superior é mostrada a árvore de possíveis defeitos dentro de cada pacote. Quando um possível defeito é selecionado, seu código fonte é mostrado à direita, e sua descrição é mostrada na parte de baixo. A ferramenta FindBugs permite ainda ao inspetor escrever comentários a respeito do possível defeito.

Figura 2.12 - Tela da ferramenta FindBugs (FINDBUGS, 2008)

Coffee Grinder: É uma ferramenta para apoiar inspeções de software orientado a objetos. Coffee Grinder provê uma infra-estrutura de scripts e uma interface de controle e

grafos de dependência. Os scripts são usados para encontrar defeitos ou potencias áreas para inspeção. Os grafos de dependência permitem escrever os scripts e, de uma forma interativa, atualizá-los para cobrir um conjunto de itens de um checklist (COOPER et al., 2006). Um grafo de dependência da ferramenta Coffee Grinder pode ser visto na Figura 2.13.

Figura 2.13 - Exemplo de grafo de dependência de uma declaração condicional (COOPER et al., 2006)

Figura 2.14 - Interface da ferramenta Coffee Grinder (COOPER et al., 2006)

Na interface da ferramenta Coffee Grinder (Figura 2.14). É possível observar na figura que para a classe selecionada e para o método selecionado, é mostrado o código,

além de sua representação em grafo. Com a visualização em grafo do código, é possível identificar com mais facilidade, as dependências de cada variável dentro do método.

CIT: É uma ferramenta designada para apoiar inspeção de código. Ela permite que o Moderador crie um projeto, e a partir dele, cadastre os inspetores para formar a equipe de inspeção. Dentre as principais características da CIT estão (CHAN; JIANG; KARUNASEKERA, 2005):

• Apoio navegacional;

• Checagem dinâmica de código usando diagramas UML de projeto; • Tratamento de documentos;

• Checagem estática; e • Coleta de métricas;

Além disso, a ferramenta CIT permite ao inspetor marcar os trechos de código como possíveis defeitos. Essa marcação pode ser feita ainda com uma escala de prioridade.

Figura 2.15 - Navegadores de código e diagrama de classes da ferramenta CIT (CHAN; JIANG; KARUNASEKERA, 2005)

A Figura 2.15 apresenta uma tela da ferramenta CIT na qual pode ser observado o navegador hierárquico do código (à esquerda), o navegador do código (ao centro) e o diagrama de classes (à direita). Esses navegadores provêem um apoio navegacional padronizado de destaque do código e referências cruzadas. Ao prover essas informações, a CIT almeja apoiar o trabalho dos inspetores, tornando a inspeção mais eficaz.