Proposta de Benchmark
4.1.3 Técnicas de Busca e Ambientes de Avaliação
Dependendo da complexidade da instância do problema, podem estar envolvidos aspectos combinatórios que vão gerar grandes espaços de busca com poucos pontos de boas soluções. No contexto do presente trabalho, seriam poucas BDTs que consigam matar todos ou a maioria dos mutantes SQL.
Este cenário vai exigir o uso de alguma abordagem que explore de forma inteligente o espaço de busca a fim de realizar a seleção/redução dos dados na formação de BDTs adequadas. Neste caso, uma das alternativas seria o uso de técnicas de busca4.
4Técnicas de Busca são metaheurísticas que visam encontrar uma boa solução, eventualmente a ótima,
para problemas onde o uso de métodos exatos se torna restrito. A técnica funciona através de algum processo que converge rapidamente para soluções interessantes dentro de um espaço de busca.
4.1 Contextualização 59
Como exemplos de técnicas de busca, pode-se citar as metaheurística de busca local, onde a exploração do espaço de soluções é feita por meio de movimentos, os quais são aplicados a cada passo sobre a solução corrente, gerando outra solução promissora na sua vizinhança. Outro tipo de técnica são as metaheurísticas de busca populacional, que consiste em manter um conjunto de boas soluções e combiná-las de forma a tentar produzir soluções ainda melhores.
Entretanto, independente de qual técnica de busca seja adaptada e/ou construída para resolver o problema da redução de dados, todas deverão inevitavelmente utilizar um ambiente que possibilite a aplicação da técnica afim de atestar o seu funcionamento e avaliar seu desempenho na geração de BDTs de qualidade.
Espera-se que este ambiente tenha no mínimo:
1. Uma Base de Dados com grande volume para ser a BDP de onde os dados serão selecionados para formar as BDTs;
2. Um conjunto de instruções SQL para usar como objeto alvo de onde serão investi- gados os defeitos;
3. O conjunto de mutantes de cada instrução SQL para permitir o uso da Análise de Mutantes como critério de avaliação de qualidade das BDTs;
4. Cálculo do escore de mutação para cada instrução SQL usando a BDP como base de teste.
A técnica de busca deve atuar neste ambiente explorando o espaço de busca realizando reduções na BDP para gerar as BDTs. Com cada BDT aplica-se a análise de mutantes na instrução SQL sendo testada, verificando quais mutantes a BDT consegue matar. Basicamente, o resultado (escore de mutação) vai indicar a qualidade da base reduzida (BDT). Quanto mais próximo do escore de mutação da BDP, melhor o poder de detecção de defeitos da BDT e mais adequada ela está. A Figura 4.4 apresenta um esquema básico de um ambiente onde seria possível avaliar o desempenho de uma técnica de busca através da avaliação das BDTs geradas.
Ainda sobre a Figura 4.4, o Passo 1 representa a exploração do espaço de busca e a seleção de tuplas da BDP, o Passo 2 é a criação da BDT a partir dos dados selecionados e o Passo 3 representa a aplicação da técnica de Análise de Mutantes para verificar a qualidade da BDT. O Passo 4 mostra que este ciclo pode acontecer várias vezes, gerando diversas BDTs. Ao final, além de verificar individualmente a adequação de cada BDT através do escore de mutação, é possível também verificar a média do escore de mutação de todas as BDTs geradas.
Figura 4.4: Um Ambiente mínimo para avaliar o desempenho de uma técnica de busca no contexto de redução de bases de dados
A Figura 4.5 apresenta o resultado de um exemplo hipotético, onde alguma técnica de busca (por exemplo, um Algoritmo Genético) em um ambiente semelhante ao apresentado na Figura 4.4, criou para uma instância de problema cinco BDTs. Ao final, cada BDT gerada apresenta um valor de escore de mutação que pode ser comparado com o escore de mutação da BDP. Neste exemplo, a média do escore de mutação das 5 BDTs foi de 0,65, ficando bem abaixo do escore da BDP. Porém, a BDT4 alcançou um escore de 0,83, conseguindo uma qualidade de detecção de defeitos semelhante à BDP, que é a principal referência de comparação.
Além do valor do escore de mutação da BDP para cada instrução SQL, seria também desejável compor o ambiente de avaliação com uma relação de valores de escore de mutação obtidos a partir de BDTs geradas aleatoriamente, ou seja, através de um Método Aleatório (MA). Considerando que o método aleatório tem o menor custo computacional [33], espera-se então que outros métodos mais caros, como as técnica de busca, tenham melhores resultados, e isso pode ser verificado comparando os escores alcançados com a técnica de busca com os escores do MA.
Porém, é necessário realizar várias medições com o método aleatório para ter conclusividade nos resultados, por este motivo é necessário gerar para cada instância de problema diversas BDTs aleatórias. Com este conjunto de BDTs, é possível ter uma média do escore de mutação através do MA.
Na Figura 4.6 é apresentado novamente o mesmo resultado ilustrado na Figura 4.5, porém acrescido de mais um valor para referência, que é a média do escore de
4.1 Contextualização 61
Figura 4.5: Exemplo de avaliação de desempenho de BDTs gera- das
mutação alcançado por supostas BDTs geradas pelo MA. É possível observar agora que a técnica de busca teve a competência de gerar de BDTs com uma média de escore de mutação bem acima do MA, sinalizando com isso uma certa propensão a ter bons resultados.
Figura 4.6: Exemplo de avaliação de desempenho de BDTs gera- das comparando com Método Aleatório
As BDTs e resultados apresentados nos exemplos anteriores, foram suposta- mente geradas e avaliadas dentro de um ambiente específico para esta finalidade. Todavia, existem alguns problemas que devem ser considerados em relação aos diferentes ambien- tes, que podem ser usados na avaliação do desempenho de técnicas de busca para redução.
Dentre eles, vale destacar como os mais relevantes no contexto desta pesquisa:
1. Demanda de tempo e esforço para a construção de um ambiente adequado, tanto no que diz respeito a BDP, às instruções SQL, aos mutantes e às gerações de BDTs através de métodos aleatórios;
2. Uso de um ambiente sem instâncias do problema desafiadoras o suficiente para ava- liar e exercitar de forma criteriosa a técnica de busca. Com um ambiente desfavo- rável, corre-se o risco de avaliar erroneamente uma técnica, podendo até fazer com que a mesma tenha tendência a obter somente bons resultados;
3. Falta de um ambiente padronizado, inviabilizando comparações e avaliações de desempenho entre técnicas de busca que usaram ambientes distintos.
Problemas semelhantes aos citados foram enfrentados na pesquisa realizada por Monção et al. [34]. Durante o desenvolvimento deste trabalho, procurou-se na literatura algum ambiente adequado a este contexto, onde fosse possível aplicar a técnica de busca desenvolvida, neste caso, um Algoritimo Genético (AG). Na Seção 3.3.2 foram apresentados maiores detalhes sobre as características e condução desta pesquisa.
A principal necessidade era realmente utilizar o AG em um ambiente que permitisse exercitar a técnica e avaliar o seu desempenho para redução de dados. Na época, não foram encontrados trabalhos e pesquisas com características que atendessem à necessidade da pesquisa [34]. Diante disso, um grande esforço para a criação de um ambiente foi empregado, e somente depois foi possível dar início efetivo aos trabalhos para construção do AG. Além disso, devido à falta de um ambiente padronizado, não foi possível comparar os resultados obtidos com resultados de outras abordagens.
Esta ausência de referências foi um dos principais motivadores para a realização da pesquisa desta dissertação, que resultaria na construção do ambiente adequado à necessidade presente na época.
4.2
Objetivos e Composição do Benchmark
Considerando os problemas e motivações citados na seção anterior, o principal objetivo da pesquisa consiste na construção e disponibilização de um benchmark, que funcione como um ambiente de referência, contribuindo para fornecer todos os elemen- tos necessários para apoiar a avaliação de desempenho de qualquer técnica de busca, no contexto de redução de bases de dados para testes de instruções SQL.
O ambiente deste benchmark se propõe a ser padronizado, possuindo instâncias do problema invariáveis e bem definidas. Espera-se também que ele tenha uma estrutura
4.2 Objetivos e Composição do Benchmark 63
com grande volume de dados, formado por uma ou mais BDPs, e um conjunto de instruções SQL com seus respectivos mutantes. Além disso, para cada instância do problema do benchmark, serão realizados diversos experimentos que visam conduzir reduções aleatórias da BDP, afim de gerar conjuntos de BDTs de diferentes tamanhos. A qualidade de cada BDT, e consequentemente de cada conjunto, será calculada e avaliada utilizando a Análise de Mutantes SQL.
O segundo objetivo, a partir da realização dos experimentos, consiste na geração de informações que indiquem a complexidade de cada instrução SQL do benchmark, permitindo assim interpretações que levem à elaboração de entregáveis, sendo eles, planilhas de resultados, gráficos e principalmente tabelas de ranqueamento em diferentes perspectivas. Servindo não só como importantes instrumentos de referências para as técnicas de busca mas também ajudando a analisar e responder importantes questões como por exemplo:
1. Quais são as situações que geram instruções SQL mais difíceis no contexto de Análise de Mutantes SQL?
2. Quais características influenciam na complexidade das instâncias do problema? 3. Quais propriedades de uma base de teste pode influenciar na sua capacidade de matar
mutantes?
Além disso, espera-se que as informações e resultados gerados na presente pesquisa forneçam relevantes insumos e parâmetros para outros pesquisadores da área de Análise de Mutantes SQL, sendo este então um outro importante objetivo que se deseja alcançar com a criação do benchmark.
Composição
A proposta é construir e disponibilizar um benchmark que seja formado por dois cenários, como apresentado na Figura 4.7. No primeiro cenário serão utilizados dados gerados especificamente para compor o benchmark. No segundo cenário serão usados dados extraídos da BDP de uma aplicação real.
Em ambos os cenários, a composição padrão será constituída pelos seguintes componentes: (i) Banco de Dados de Produção; (ii) Instruções SQL e Mutantes; e (iii) Resultados do Método Aleatório. A Figura 4.8 ilustra uma abstração simples da composição de cada cenário do benchmark.
Figura 4.7: Representação gráfica da composição do Benchmark
Figura 4.8: Representação gráfica da composição de cada cenário do Benchmark
Para cada componente serão gerados entregáveis que vão permitir o entendi- mento e utilização do benchmark dentro do que ele se propõe. O conjunto de todos estes entregáveis foi definido e organizado para fisicamente formar o benchmark. A listagem detalhada dos entregáveis está disponibilizada no Apêndice B.