Resultados do Método Aleatório (MA)
4.3 Características do Benchmark e de seus cenários
4.3.3 Experimentos e Resultados do Método Aleatório (MA)
Para cada instrução SQL do benchmark, serão realizados vários experimentos para gerar as BDTs através das reduções pelo MA, que são importantes componente do benchmark. Cada BDT tem sua qualidade mensurada, fornecendo importantes resultados para a criação dos principais entregáveis.
4.3 Características do Benchmark e de seus cenários 73
Por este motivo, devido à sua importância no processo de construção do bench- mark, decidiu-se realizar a execução dos experimentos em um ambiente que permita o registro de todos os parâmetros, informações e resultados em uma base de dados. A esta base, deu-se o nome de Base de Dados de Experimentos (BDE). Neste ambiente, além da BDE, existe também uma instância de banco de dados para a BDP e uma outra para a geração das BDTs, sendo todas fisicamente independentes e separadas.
O objetivo de cada experimento é a geração de um conjunto de BDTs, com uma determinada quantidade de tuplas, para testar uma única instrução SQL. A quantidade de BDTs no conjunto e a quantidade de tuplas por BDT serão determinadas como parâmetros de cada experimento. Estes parâmetros foram escolhidos considerando a importância e necessidade de:
1. Criar conjuntos de diversos tamanhos para avaliar o comportamento dos resultados em cenários diferentes em relação aos conjuntos de BDTs.
2. O tamanho da BDT (percentual de redução) deve ser significativamente menor que a BDP, até mesmo para justificar a redução de dados para diminuição do custo. 3. Como já foi visto anteriormente, são necessárias várias gerações com o MA para ter
conclusividade nos resultados.
4. Não ignorar as restrições e limitações de tempo e processamento para realização dos experimentos.
Em um primeiro momento, de forma empírica, definiu-se um padrão de parâme- tros com a quantidade de conjuntos por instrução SQL variando de 1 a 18, a quantidade de BDTs por conjunto variando de 5 a 30 e a quantidade de tuplas por BDT de 1%, 2%, 3%, 5% e 7% do tamanho da BDP. Entretando, para tornar resultados gerados conclusivos, é necessário a realização de várias medições com esta abordagem a fim de se ter, ao final, uma média de resultado com o MA. Estes parâmetros foram determinados para ambos os cenários do benchmark.
A intenção foi escolher uma configuração padrão de parâmetros para testes iniciais, e após estes testes verificar se os parâmetros são adequados para os objetivos e restrições da pesquisa. Os testes foram realizados e de modo geral os parâmetros escolhidos tiveram um comportamento interessante. A única alteração necessária em relação à proposta original foi a inclusão de mais um possível tamanho de BDT de 0,1%. A primeira configuração padrão, definida para os experimentos de cada instrução SQL, está apresentada na Tabela 4.1. Cada linha da tabela é um experimento a ser realizado para cada instrução SQL. A primeira linha por exemplo indica que serão geradas aleatoriamente 5 BDTs para a instrução SQL, e cada BDT conterá 0,1% das tuplas da BDP. Ao total, para cada instrução SQL podem ser geradas 270 BDTs pelo MA.
Quantidade de BDTs Percentual da Redução 5 0,1% 10 0,1% 30 0,1% 5 1% 10 1% 30 1% 5 2% 10 2% 30 2% 5 3% 10 3% 30 3% 5 5% 10 5% 30 5% 5 7% 10 7% 30 7%
Tabela 4.1: Primeiro Conjunto Padrão de Parâmetros dos Experi- mentos
Porém, após a execução dos experimentos baseados nos parâmetros da Tabela 4.1, identificou-se algumas instruções SQL que o escore de mutação (média e/ou maior) com o MA, em nenhuma situação, aproximou do escore de mutação da BDP. Para estas situações, decidiu-se expandir os parâmetros e avaliar o comportamento destas instruções SQL com novos experimentos. A Tabela 4.2 apresenta o segundo conjunto de parâmetros de experimentos.
Quantidade de BDTs Percentual da Redução
5 8% 10 8% 30 8% 5 9% 10 9% 30 9% 5 10% 10 10% 30 10%
Tabela 4.2: Segundo Conjunto Padrão de Parâmetros dos Experi- mentos
Considerando o primeiro e o segundo grupo de parâmetros, ao total, para cada instrução SQL, podem ser geradas até 405 BDTs de diferentes tamanhos. Para facilitar a avaliação da evolução do escore de mutação destas BDTs, os parâmetros foram definidos de forma crescente. Sendo assim, serão realizados primeiro para cada instrução SQL os experimentos que geram BDTs menores, e em seguida os experimentos com BDTs maiores. A expectativa é que a cada grupo de experimentos com BDTs maiores o escore
4.3 Características do Benchmark e de seus cenários 75
de mutação médio da instrução SQL fique mais alto.
Porém, nem todos os experimentos possíveis para uma instrução SQL necessa- riamente devem ser executados. Definiu-se alguns critérios de parada que limitarão as execuções quando resultados com o MA já obtiverem escores de mutação aceitáveis.
Por exemplo, se com a maioria das BDTs de 5% já for possível matar a mesma quantidade de mutantes da BDP, não se justifica criar BDTs maiores, consequentemente mais caras, para avaliar o seu comportamento. Esta avaliação é feita observando-se três valores: (i) média do escore de mutação; (ii) maiores escores de mutação; e (iii) o escore de mutação de um conjunto de BDTs. Nestes casos, quando um destes valores alcança ou se aproxima muito do escore da BDP, o critério de parada é atingido, sinalizando que não é mais necessário realizar novos experimentos para aquela instrução SQL.
A Figura 4.13 apresenta um gráfico onde mostra a evolução do escore de mutação de uma instrução SQL onde o escore com a BDP é igual a 0,9545. Pode-se observar no gráfico que este mesmo escore da BDP já foi alcançado em algum experimento por uma BDT de apenas 1% da BDP, porém a média do escore das BDTs ainda estava distante. Com 5% a média de escores das BDTs geradas aleatoriamente já está muito próxima do escore de mutação da BDP, sinalizando com isso que não é mais necessário avaliar BDTs maiores.
Figura 4.13: Evolução da média do escore de mutação com o Método Aleatório
Outro critério de parada é o próprio tamanho máximo da BDT que foi definido nos parâmentos, pois conforme visto anteriormente, não se justifica realizar reduções de dados gerando subconjuntos grandes. A intenção é reduzir o máximo possível para obter
os benefícios esperados. Sendo assim, não foram geradas BDTs com mais de 10% da BDP, independente dos resultados alcançados.