Comparison

Segundo Law e Rothermel, as três principais técnicas de análise de impacto baseada em dependências são grafos de chamadas, particionamento estático e particionamento dinâmico [Law03].

Um grafo de chamadas é um grafo direto no qual os nodos representam funções (ou métodos) e uma aresta transitiva entre A e B significa que A pode chamar B [Ors03]. Através da definição de dependência direta entre os métodos, é possível avaliar o impacto pela manutenção de uma função específica.

O particionamento de um programa consiste em reduzir esse programa para a sua forma mínima, mantendo ainda seu comportamento inicial [Wei81]. Por exemplo, inserindo mudanças no código e aplicando particionamento, que se baseia na construção de um grafo de dependência entre diversas entidades computacionais para determinar a dependência transitiva de determinada entidade, permite-se identificar um conjunto de pontos de impacto decorrentes de determinada mudança. A ideia por traz do particionamento é justamente identificar apenas o código de interesse para determinado comportamento para, então, modificar apenas essa porção de código. Por exemplo, considere a Figura 2.2.

A Figura 2.2(a) apresenta um exemplo de código que lê um número n e computa a soma e o produto dos primeiros n números positivos. A Figura 2.2(b) representa apenas uma porção do código relacionada ao cálculo do produto, ignorando todos os demais

trechos do código que não dizem respeito a essa operação. O particionamento estático realiza a identificação do conjunto de todas as declarações transitivas relativas a determinado fluxo de controle ou de dados, considerando apenas as informações estáticas presentes no código. O particionamento estático reduz o número de análises se comparado ao grafo de chamadas, pois considera apenas os valores potencialmente afetados em algum ponto de interesse, também chamado de critério de particionamento [Tip95]. Critérios de particionamento geralmente são definidos em uma parte de um programa contendo a ocorrência, por exemplo, a linha 10, write(product), da Figura 2.2, e uma variável, por exemplo, a variável product da Figura 2.2. Neste exemplo, o critério de particionamento é (10, product) e o código resultante é representado pela Figura 2.2 (b). Neste exemplo, qualquer referência a variável sum é considerada fora do escopo da partição analisada.

Figura 2.2 – (a) Um exemplo de programa. (b) O particionamento estático do programa segundo o critério de particionamento (10, product) (proposto em [Tip95]).

Dentre os particionamentos, o estático é computado sem realizar suposições sobre as entradas de um programa enquanto o dinâmico utiliza casos de testes específicos em sua definição para determinar suas possíveis entradas [Tip95]. Neste caso, apenas as dependências que ocorrem em uma execução específica (caso de teste) devem ser levadas em consideração. Tipicamente, o critério de particionamento dinâmico é composto por três elementos: entrada do programa, ocorrência e variável. A ocorrência deve levar em consideração dados históricos, isto é, o número de vezes que esta declaração ocorreu no código.

Por exemplo, a Figura 2.3 apresenta um exemplo de programa e o critério de particionamento. Esse critério é definido por (n=2, 81, x), sendo que n=2 representa a entrada, 81 representa a primeira ocorrência da declaração e x a variável de interesse. Note que como n=2, o loop será executado duas vezes passando uma única vez pelas declarações x:= 17 e x:=18. A linha 6 na Figura 2.3 (b) está omitida, pois a variável x na primeira iteração do loop é ignorada devido à atribuição do valor 17 da segunda iteração.

Figura 2.3 – (a) Exemplo de programa. (b) Particionamento dinâmico usando o critério (n=2, 81, x) (proposto em [Tip95]).

No exemplo da Figura 2.3, o particionamento estático, cujo critério é (8, x), irá considerar todo o algoritmo, isto é, a Figura 2.3 (a), enquanto o particionamento dinâmico irá considerar apenas a partição representada pela Figura 2.3 (b).

Para o particionamento entre procedimentos, existem algumas técnicas comuns, como o Grafo de Fluxo de Controle (Figura 2.4), que representa a ordem de invocação das instruções, o Grafo de Dependência (Figura 2.5), que representa a subordinação das estruturas, e Grafo de Fluxo de Dados (Figura 2.6), que representa o uso de cada variável ao longo do programa.

Figura 2.5 – Grafo de Dependência (proposto em [Tip95]).

Figura 2.6 – Grafo de Fluxo de Dados (proposto em [Tip95]).

Segundo Law e Rothermel, cada uma dessas abordagens para análise de dependência tem suas vantagens e desvantagens [Law03]:

 o fechamento de transitividade em grafos de chamadas é relativamente barato, porém pode ser altamente propenso a erro, identificando impactos onde não existem e falhando na identificação de impactos onde existem;

 o particionamento estático pode prever impactos de mudanças em um modelo mais conservador e seguro, entretanto ele foca em todos os possíveis comportamentos do programa podendo retornar um conjunto de elementos impactados muito grande ou impreciso comparado àqueles perfis operacionais esperados por um sistema e útil ao time de desenvolvimento;

 o particionamento dinâmico pode prever um impacto relativo de um programa específico ou perfil operacional, o qual pode ser útil para as tarefas de manutenção do software, sacrificando, porém a segurança na auditoria dos impactos resultantes;

 tanto o particionamento estático quanto dinâmico são relativamente caros em termos computacionais, possuindo dependência de dados, de controle e

análise de aliases. Nesta perspectiva, a análise por grafo de chamadas é mais barata;

 todas as três abordagens baseiam-se no código fonte para determinar a invocação das estruturas ou dependências estáticas no código e requerem um esforço computacional significativo para reprocessar toda a informação necessária para avaliar o impacto em entregas subsequentes do código fonte do sistema em manutenção.

O particionamento em um grafo de chamadas pode gerar estimativas inseguras sobre o conjunto de operações afetadas pelas mudanças [Arn96], gerando resultados imprecisos e superestimando os efeitos de mudanças [Ors03]. Recentemente, pesquisadores vêm considerando formas mais precisas de auditar os impactos utilizando informações capturadas durante a execução dessas mudanças.

Por exemplo, Law e Rothermel definiram uma técnica para análise de impacto que utiliza uma técnica chamada caminho completo de programas [Law03]. Esta técnica captura a dinâmica de um programa através de seus fluxos de controle e, em oposição às técnicas comuns de perfis de caminho que registram caminhos intraprocedurais e acíclicos, esta proposta captura os fluxos completos de programas incluindo ciclos e interações interprocedurais. Nesta abordagem, se um procedimento p é alterado, todos os procedimentos que são invocados após p, bem como qualquer procedimento que está na pilha de chamada aguardando o retorno deste procedimento, são incluídos no conjunto de procedimentos potencialmente impactados.

Embora técnicas baseadas no rastreamento de execução possam atingir melhores resultados do que técnicas de análise de impacto tradicionais [Law03], tais como grafo de chamadas e particionamento de programas estático e dinâmico, essas técnicas são restringidas pela qualidade dos dados que são utilizados. Como restrições, tem-se que (1) a quantidade de rastros de execução utilizados pode crescer exponencialmente, e (2) algoritmos que comprimem estes rastros a um nível computacionalmente razoável podem se tornar custosos, comprometendo o seu uso em tempo de execução na medida em que os rastros são produzidos [Ors03].

Conforme apresentado, a análise de impacto corresponde à identificação de potenciais consequências de determinada mudança ou a estimativa do trabalho necessário para completar essa mudança. No que se referem a impacto, duas perspectivas são pertinentes: (1) perspectiva de negócio, relacionada às preocupações

das partes interessadas em verificar se as regras de negócio existentes são impactadas por uma mudança, necessitando adequação; (2) perspectiva do software, relacionada com as alterações no código fonte e documentação associada. Oliveira, em [Oli10], apresenta um estudo sobre diferentes técnicas de rastreabilidade e evidencia que nenhuma das avaliadas lida diretamente com a perspectiva de negócio com razoável nível de precisão para os impactos descobertos. Para ambas as perspectivas, dois tipos de medidas são consideradas importantes para a avaliação dos impactos: precisão, para medir a exatidão ou fidelidade, e revocação, como uma medida de completude [Ols08].