Uma Estratégia para Integrar e Testar Agrupamentos de Classes Baseada em Algoritmos Multiobjetivos

Transcrição

1 Uma Estratégia para Integrar e Testar Agrupamentos de Classes Baseada em Algoritmos Multiobjetivos Wesley Klewerton Guez Assunção 1, Thelma Elita Colanzi 1 2, Aurora Trinidad Ramirez Pozo 1, Silvia Regina Vergilio 1 1 DInf, Universidade Federal do Paraná (UFPR) Curitiba, PR Brasil 2 DIN, Universidade Estadual de Maringá (UEM) Maringá, PR Brasil {wesleyk, thelmae, aurora, silvia}@inf.ufpr.br Resumo. Para realizar o teste de software orientado a objetos é necessário determinar uma ordem para integrar e testar as classes que implique em um custo mínimo associado à construção de stubs. Vários trabalhos tratam esse problema, porém nenhum deles considera uma característica presente na maioria dos sistemas, que é o agrupamento de classes (ou modularização). Considerando essa limitação, este artigo apresenta uma estratégia de integração e teste de classes que considera agrupamentos. Esta estratégia é implementada utilizando três algoritmos evolutivos multiobjetivos e diferentes medidas de acoplamento para cálculo do custo associado aos stubs. Os algoritmos são avaliados e comparados experimentalmente. O espaço de busca é analisado em comparação com a estratégia que não considera agrupamentos. Os resultados mostram que o espaço de busca fica restrito, forçando os algoritmos a explorarem novas regiões e fazendo com que soluções sub-ótimas passem a ser soluções aproximadas. Abstract. To perform the test of object-oriented software it is necessary to determine a class integration and test order associated to a minimal stubbing cost. Several works deal with this problem, however, none of them considers a characteristic of most systems: the cluster of classes (or modularization). To overcome this limitation, this paper presents a strategy to integrate and test classes that considers classes clusters. This strategy is implemented by using three multiobjective evolutionary algorithms and several coupling measures to calculate the stubbing cost. The algorithms are evaluated and compared in an experimental study. The search space is analysed in comparison with the strategy that does not consider clusters. Results show that the search space is constrained, forcing the algorithms to explore new regions, and making sub-optimal solutions to become approximate solutions. 1. Introdução O teste é uma atividade essencial dentre as de garantia de qualidade de software, geralmente realizada em etapas. Por exemplo, no teste de software orientado a objetos (OO), o teste de integração tem como objetivo testar a interação entre as classes. Nesta etapa, é comum que algumas classes necessitem de recursos de outras classes que ainda estão em desenvolvimento, o que leva à necessidade de construção de stubs, que são pseudoimplementações que simulam recursos não disponíveis para executar a classe.

2 Para reduzir o custo da construção de stubs é necessário determinar uma ordem com custo mínimo para testar e integrar as classes. Este problema é conhecido como CITO (Class Integration and Test Order Problem) [Abdurazik and Offutt 2006] e tem sido alvo de pesquisa de vários trabalhos. Estes trabalhos propõem soluções baseadas em grafos e podem ser classificados em dois tipos: os tradicionais [Kung et al. 1995, Tai and Daniels 1997, Briand et al. 2003], que usam algoritmos baseados em grafos, e os trabalhos baseados em busca, que utilizam meta-heurísticas. Dentre estes últimos, destacam-se os trabalhos que utilizam algoritmos de otimização multiobjetivo como os mais promissores. Em [Vergilio et al. 2012] três algoritmos multiobjetivos foram utilizados e comparados considerando duas medidas de acoplamento (objetivos) que representam os custos associados à construção de stubs. Neste estudo o algoritmo evolutivo, apresentou um melhor desempenho. Considerando este fato, em [Assunção et al. 2011a], uma estratégia baseada em algoritmos evolutivos multiobjetivos (MOEAs - Multi-Objective Evolutionary Algorithms) foi proposta e avaliada com quatro medidas de acoplamento. Em outro trabalho foram avaliados três diferentes MOEAs: NSGA-II, SPEA2, e PAES, sendo que este último encontrou soluções ligeiramente melhores [Assunção et al. 2011b]. Apesar de existirem vários trabalhos que propõem diferentes estratégias para integrar e testar classes, nenhum deles considera uma característica do desenvolvimento de software: o agrupamento de classes ou modularização [Card et al. 1985, Pressman 2001]. O agrupamento corresponde a várias classes, que são geralmente desenvolvidas em grupos e por isto testadas em conjunto, muitas vezes pela mesma equipe de teste. O agrupamento de classes em pacotes é amplamente utilizado para facilitar a organização, o desenvolvimento e a manutenção do software. Muitas vezes está associado ao desenvolvimento distribuído de software. Por isto é importante estabelecer uma estratégia que considere os grupos de classes que não podem ser separadas na solução (ordem) do problema CITO. O objetivo do presente trabalho é propor e avaliar uma estratégia baseada em MO- EAs que considera o agrupamento de classes. Lidar com o problema CITO considerando que grupos de classes precisam ser testados em conjunto impõe restrições ao espaço de busca e pode influenciar o desempenho dos algoritmos. Portanto, outro objetivo é comparar os três algoritmos evolutivos NSGA-II, SPEA2, e PAES, escolhidos por implementarem diferentes estratégias de evolução, e ver qual apresenta o melhor desempenho para o problema CITO com restrições. Para isto, é conduzido um experimento utilizando quatro sistemas reais, quatro medidas de acoplamento (objetivos) e quatro indicadores de qualidade para comparar os algoritmos: Cobertura, Distância Geracional, Distância Geracional Invertida e Distância Euclidiana da Solução Ideal. Este artigo está organizado como segue: na Seção 2 são descritos os MOEAs utilizados. Na Seção 3 a estratégia de teste e integração de classes que considera agrupamentos é apresentada. Os aspectos da aplicação dos MOEAs no problema são apresentados na Seção 4. A Seção 5 descreve como foi realizado o estudo experimental. A Seção 6 apresenta a análise dos resultados, comparando estratégias e algoritmos. Finalmente, na Seção 7 são apresentadas as conclusões. 2. Algoritmos Multiobjetivos Problemas multiobjetivos estão presentes na maioria das disciplinas. Para solucionar estes problemas, diferentes fatores devem ser considerados. Para estes problemas não é

3 possível encontrar uma solução única, pois em geral os objetivos são conflitantes, ou seja, quando se melhora um objetivo se degrada outro. Então a otimização consiste em encontrar um conjunto de soluções com o melhor balanceamento entre os objetivos. Para avaliar e determinar o grupo dessas soluções, utiliza-se o conceito de dominância de Pareto [Pareto 1927]. O objetivo é descobrir soluções que não são dominadas. Dado um conjunto de possíveis soluções para o problema, uma solução A domina uma solução B, se e somente se, A é melhor que B em pelo menos um dos objetivos, sem ser pior que B nos outros objetivos. O conjunto de soluções não-dominadas forma a fronteira de Pareto. Muitas vezes encontrar a fronteira de Pareto real é NP-difícil [Knowles et al. 2006], então o desafio é encontrar uma aproximação desta fronteira. MOEAs são extensões de algoritmos genéticos para problemas multiobjetivos que aplicam os conceitos de dominância de Pareto para criar estratégias distintas para evoluir e diversificar as soluções. Neste trabalho foram selecionados os MOEAs NSGA- II [Deb et al. 2002], SPEA2 [Zitzler et al. 2001] e PAES [Knowles and Corne 2000]. O NSGA-II (Non-dominated Sorting Genetic Algorithm) [Deb et al. 2002] ordena em cada geração os indivíduos das populações pai e filha com base na relação de nãodominância. Ele cria diversas fronteiras e, depois da ordenação, as soluções com mais baixa dominância são descartadas. As fronteiras representam a estratégia de elitismo adotada pelo NSGA-II. Este algoritmo utiliza também um operador chamado crowding distance que ordena os indivíduos de acordo com a sua distância em relação aos vizinhos da fronteira, visando a garantir maior espalhamento das soluções. Ambas ordenações, de fronteiras e de crowding distance, são usadas pelo operador de seleção. O SPEA2 (Strength Pareto Evolutionary Algorithm) [Zitzler et al. 2001], além de ter sua população regular, possui um arquivo externo que armazena soluções nãodominadas encontradas no processo evolutivo. Para cada solução que está no arquivo e na população é calculado um valor de strength que também é usado no cálculo do fitness do indivíduo. O valor de strength de uma solução i corresponde a quantidade de indivíduos j, do arquivo e da população, dominados por i. Este valor é utilizado durante o processo de seleção. No processo evolutivo, o arquivo externo é utilizado para complementar a nova geração com soluções não dominadas. Como o tamanho do arquivo é fixo, se este tamanho for excedido, um algoritmo de agrupamento é utilizado a fim de reduzi-lo. No processo evolutivo do algoritmo PAES (Pareto Archived Evolution Strategy) [Knowles and Corne 2000] o conceito de população é diferente das estratégias tradicionais, pois apenas uma solução é mantida em cada geração, e a criação de novos indivíduos é feita somente através da aplicação do operador de mutação. Assim como no SPEA2, existe um arquivo externo de soluções que é populado com as soluções não dominadas encontradas durante o processo. A cada geração, o PAES cria uma nova solução filha que é comparada com a solução pai, se a solução filha domina a solução pai, a filha toma o lugar da pai, e a filha é acrescentada ao arquivo externo; se a solução filha é dominada pela pai ou por alguma solução do arquivo externo, a filha é descartada; e caso nenhuma das soluções domine a outra, a escolha da solução que vai permanecer no processo evolutivo é feita considerando a diversidade entre pai, filha e as soluções do conjunto externo. Caso o tamanho do arquivo externo exceda, é aplicada uma estratégia de diversidade sobre este conjunto de soluções, eliminando soluções similares.

4 3. Estratégia de Integração e Teste de Classes Baseada em Agrupamento A estratégia de ordenação de classes proposta consiste em considerar um conjunto de agrupamentos de classes durante o estabelecimento de uma ordem de integração e teste. Um agrupamento corresponde a um conjunto de classes que são agrupadas pelo engenheiro de software e que devem ser desenvolvidas e testadas em conjunto. A Figura 1 ilustra o problema de integração considerando o agrupamento de classes. O sistema contém 12 classes. O problema CITO requer uma ordem (por exemplo Ordens A e B) para que estas classes sejam testadas com um custo mínimo para construção de stubs. Para o problema CITO que não considera agrupamentos ambas ordens são válidas. Mas suponha que o engenheiro de software determine que algumas classes, por exemplo por questão de um desenvolvimento distribuído, sejam agrupadas para serem desenvolvidas e testadas por uma mesma equipe em conjunto, formando os agrupamentos A1, A2 e A3. A Ordem A é válida, pois as classes dos agrupamentos não estão separadas. Na Ordem A as classes de A1 devem ser desenvolvidas e testadas primeiramente, seguidas pelas classes de A3 e pelas classes de A2. Já a Ordem B não é uma sequência válida, pois as classes de A1 e A3 ficaram dispersas, ou seja, as classes dos agrupamentos A1 e A3 não estão agrupadas como definidas. Agrupamento de Classes A1 A2 A Possíveis ordens de testes Ordem A Ordem B Figura 1. Exemplos da Utilização da Estratégia Baseada em Agrupamentos 4. MOEAs aplicados ao problema CITO com Agrupamentos Para aplicar os MOEAs para resolver o problema CITO considerando os agrupamentos é preciso definir uma boa representação para o problema. E esta representação influencia na implementação de todos os estágios dos algoritmos. Para considerar os agrupamentos de classes, foi necessária uma representação diferente das utilizadas nos trabalhos relacionados. Foi implementada uma classe Cluster formada por dois atributos: (i) id do tipo inteiro utilizado para identificar o agrupamento durante o cruzamento e a mutação, e (ii) modules que é uma lista de inteiros, que armazena a ordem das classes do agrupamento, na qual cada inteiro representa uma classe. Um indivíduo é formado por um vetor de objetos da classe Cluster (ArrayList<Cluster>). O tamanho do vetor é igual a quantidade de agrupamentos e a soma de todos os tamanhos dos vetores modules é igual a quantidade de classes do sistema. Para as funções objetivo dos MOEAs foram usadas quatro medidas de acoplamento, que representam o custo da construção de stubs. Considerando-se que c i e c j são duas classes acopladas, essas medidas de acoplamento são definidas como segue:

5 Número de atributos (A) = Número de atributos localmente declarados em c j quando referências ou apontadores para uma instância de c j aparecem na lista de argumentos de alguns métodos de c i. Número de métodos (M) = Número de métodos (inclusive construtores) localmente declarados em c j que são invocados por métodos de c i. Número de tipos de retorno (Rd) = Total de tipos de retorno distintos dos métodos localmente declarados em c j que são invocados por métodos de c i. Número de tipos de parâmetros (Pd) = Total de tipos de parâmetros distintos localmente declarados em métodos de c j que são invocados por métodos de c i. Os dados de entrada de cada MOEA são formados por matrizes, como em [Briand et al. 2002], e são: uma matriz de dependência entre as classes, que define as restrições relativas às dependências de herança que não devem ser quebradas; outras quatro matrizes correspondentes a cada uma das métricas descritas acima; e uma matriz com a definição dos agrupamentos. O fitness de cada solução é calculado através da soma das dependências quebradas entre as classes para cada uma das métricas, que correspondem aos objetivos. Para reduzir o custo dos stubs deve-se minimizar todos os objetivos. Para os operadores genéticos foram implementadas diferentes estratégias a fim de possibilitar o tratamento das restrições dos agrupamentos. Para o cruzamento e mutação foram implementadas estratégias inter-cluster e intra-cluster. No cruzamento inter-cluster os agrupamentos são completamente trocados entre dois indivíduos, já no cruzamento intra-cluster um mesmo agrupamento é selecionado de dois indivíduos diferentes, então é efetuado o cruzamento de dois pontos de corte, sendo que os outros agrupamentos não são afetados. Na mutação inter-cluster os agrupamentos de um indivíduo são trocados completamente de posição dentro da ordem, já na mutação intra-cluster é selecionado um agrupamento do indivíduo, então duas classes são trocadas de posição. 5. Descrição do Estudo Experimetal A seguir a estratégia que não considera os agrupamentos será referenciada pela sigla SA (Sem Agrupamentos) implementada tal como descrito em [Assunção et al. 2011a, Assunção et al. 2011b], enquanto a estratégia proposta que considera os agrupamentos é referenciada pela sigla CA (Com Agrupamentos) tal como descrito anteriormente. Os sistemas utilizados bem como a metodologia adotada são os mesmos descritos nos trabalhos relacionados [Assunção et al. 2011a, Assunção et al. 2011b] Sistemas Utilizados Foram utilizados quatro sistemas desenvolvidos em Java (Tabela 1). São eles: BCEL, JBoss, JHotDraw e MyBatis. O sistema BCEL (Byte Code Engineering Library), é uma biblioteca utilizada para analisar, criar e manipular arquivos binários da linguagem de programação Java. Neste experimento utilizou-se somente o pacote org.apache.bcel.classfile da versão 5.0. O sistema JBoss é um servidor de aplicações Java. Para o experimento utilizou-se o subsistema Management da versão 6.0.0M5. Outro sistema utilizado é um framework de gráficos bidimensionais para editores de desenho estruturado chamado de JHotDraw. Para o experimento utilizou-se o pacote org.jhotdraw.draw da versão O último sistema selecionado foi o My- Batis, que é um framework de mapeamento de classes para aplicações OO que utilizam bancos de dados relacionais. A versão utilizada do sistema MyBatis é a

6 Tabela 1. Sistemas Utilizados no Experimento Sistema Versão LOC Classes Disponível em Agrupamentos BCEL JBoss 6.0.0M JHotDraw MyBatis As estratégias de integração e teste devem ser aplicadas durante o projeto do sistema a ser desenvolvido, uma vez que estabelecem uma ordem para desenvolvimento e teste de classes. Porém, é difícil obter documentação da arquitetura de sistemas complexos, então para o experimento utilizou-se engenharia reversa para obter informações de acoplamento. A ferramenta utilizada foi um parser baseado na ferramenta AJATO 1 (AspectJ and Java Assessment Tool). Este parser tem como entrada o código fonte Java e retorna uma arvore sintática, usada para construir as matrizes de dependência. Para cada um dos sistemas, foi necessário definir os agrupamentos de classes. Para tal, utilizou-se uma regra a fim de padronizar a definição dos agrupamentos. O procedimento consiste em montar um grafo direcionado utilizando somente as dependências de herança, considerando assim apenas as dependências que não podem ser quebradas. A partir deste grafo, foram separados os componentes conectados, ou seja, separadas as classes que têm relação, formando subgrafos. A partir dos subgrafos, as classes dos subgrafos de tamanho um, formaram um agrupamento, os subgrafos de tamanho dois formaram outro agrupamento, os subgrafos de tamanho três formaram outro agrupamento. Os subgrafos de tamanho igual ou superior a quatro deram origem, cada um deles a um agrupamento correspondente. Esta regra foi utilizada para todos os sistemas. O total de agrupamentos para cada sistema é apresentado na última coluna da Tabela Configuração de Parâmetros dos MOEAs Os parâmetros para os MOEAs foram ajustados a fim de que cada algoritmo executasse com seu processo evolutivo específico, mas diante de um ambiente similar. A base para este ajuste foram os trabalhos que utilizam os mesmos algoritmos e os mesmos sistemas utilizados neste experimento [Assunção et al. 2011a, Assunção et al. 2011b]. Os valores adotados são apresentados na Tabela 2. O número de avaliações de fitness é utilizado como critério de parada. Cada MOEA foi executado trinta vezes para cada sistema, para verificar o seu comportamento padrão. Tabela 2. Valores dos Parâmetros Utilizados pelos MOEAs CA SA Parâmetro NSGA-II PAES SPEA2 NSGA-II PAES SPEA2 Tamanho da População Taxa de Cruzamento 0,95-0,95 0,95-0,95 Taxa de Cruzamento Inter-Cluster 1,0-1, Taxa de Cruzamento Intra-Cluster 1,0-1, Taxa de Mutação 0,02 1 0,02 0,02 1 0,02 Taxa de Mutação Inter-Cluster 0,5 0,5 0, Taxa de Mutação Intra-Cluster 0,5 0,5 0, Tamanho do Arquivo Externo Número de Avaliações de Fitness AJATO disponível em:

7 6. Resultados e Análises A seguir são apresentados os resultados da aplicação dos MOEAs com as estratégias SA e CA, com objetivo de analisar a diferença com relação ao espaço de busca considerando ambas estratégias. Posteriormente os MOEA são comparados para verificar qual tem melhor o comportamento para solucionar o problema utilizando a estratégia CA. Para as análises é necessário utilizar diferentes conjuntos de soluções encontradas, conjuntos estes obtidos de diferentes maneiras. Os conjuntos utilizados foram: (i) P F approx : este conjunto é obtido em cada execução de cada algoritmo, portanto, como cada algoritmo é executado trinta vezes para cada problema, ao final das execuções obtêmse trinta conjuntos P F approx ; (ii) P F known : este conjunto é formado através da união de todas as soluções dos trinta conjuntos P F approx, eliminando-se as soluções dominadas e repetidas. Já que os algoritmos têm aleatoriedade em seu processo evolutivo, então cada execução pode encontrar soluções diferentes; (iii) P F true : este conjunto é obtido através da união de todas as soluções dos conjuntos P F known de todos os MOEAs utilizados no experimento, eliminando-se as soluções dominadas e repetidas [Zitzler et al. 2003], pois uma vez que o conjunto P F known tem as melhores soluções de determinado MOEA, então juntar todas estas soluções implica em ter todas as melhores soluções conhecidas. Para comparação entre os MOEAs, foram utilizados quatro indicadores de qualidade, assim como em [Assunção et al. 2011b]: Cobertura (C), Distância Geracional (GD), Distância Geracional Invertida (IGD) e Distância Euclididana da Solução Ideal (ED). O indicador de qualidade C é usado para medir a dominância entre dois conjuntos. Este indicador é um valor entre 0 e 1 referente a quanto um conjunto é dominado por outro. O indicador GD é usado para calcular a distância entre o conjunto P F approx em relação ao conjunto P F true. Já o indicador IGD observa o inverso do GD, pois tem o objetivo de calcular a distância do conjunto P F true em relação ao conjunto P F approx. Tanto para GD quanto para IGD deseja-se obter valores próximos a 0. O indicador Distância Euclidiana da Solução Ideal (ED) tem como objetivo encontrar a solução que mais se aproxima dos objetivos ótimos. Este indicador consiste em determinar os melhores valores para cada um dos objetivos entre todas as soluções de P F true, encontrando um ponto considerado como o custo de uma solução ideal, então calcula-se a partir deste ponto a distância euclidiana em relação a todas as soluções de P F known Comparação entre as estratégias SA e CA As estratégias SA e CA são duas propostas diferenciadas para solucionar o problema CITO, portanto seus resultados não podem ser comparados assumindo que deveriam ter valores similares. O objetivo deste trabalho é analisar o impacto no espaço de busca. A Tabela 3 apresenta o número de soluções encontradas e o tempo de execução. Na terceira e na sexta colunas é apresentada a cardinalidade do conjunto P F true. Na quarta e na sétima colunas são apresentadas a média da quantidade de soluções dos conjuntos P F approx e, entre parênteses, a cardinalidade do conjunto P F known. Na quinta e na oitava colunas são apresentados, respectivamente, a média do tempo de execução, em segundos, utilizados para obter cada P F approx e o desvio padrão entre parênteses. Através do tamanho do conjunto P F true verifica-se que para os sistemas BCEL e MyBatis o número de soluções encontradas pela estratégia CA foi menor que o número de soluções encontradas pela estratégia SA. Já para os sistemas JBoss e JHotDraw o número

8 Sistema BCEL JBoss JHotDraw MyBatis Tabela 3. Número de Soluções e Tempo de Execução SA CA MOEA # Número de Tempo de # Número de Tempo de P F true Soluções Execução P F true Soluções Execução NSGA-II 37,43 (37) 5,91 (0,05) 7,57 (11) 8,61 (0,11) PAES 37 39,30 (37) 6,58 (1,25) 15 3,40 (8) 29,89 (22,25) SPEA2 36,70 (37) 123,07 (18,84) 8,53 (19) 3786,79 (476,23) NSGA-II 1,00 (1) 18,73 (0,20) 1,97 (2) 42,50 (0,47) PAES 1 1,13 (1) 10,69 (0,62) 2 2,87 (2) 56,15 (12,50) SPEA2 1,00 (1) 2455,35 (612,18) 2,17 (2) 3536,01 (335,97) NSGA-II 8,40 (10) 29,85 (0,34) 45,80 (110) 71,90 (0,45) PAES 11 10,47 (19) 24,29 (1,50) ,47 (143) 51,18 (2,82) SPEA2 9,63 (9) 922,99 (373,98) 49,17 (102) 532,83 (81,93) NSGA-II 276,37 (941) 74,03 (0,87) 72,60 (103) 189,91 (0,83) PAES ,60 (679) 104,30 (7,91) ,43 (200) 132,37 (3,91) SPEA2 248,77 (690) 128,88 (2,65) 64,33 (144) 517,52 (67,52) de soluções encontradas pela CA foi maior do que encontradas pela SA. Observa-se que para os sistemas que apresentam várias soluções, menos soluções são encontradas quando se considera os agrupamentos, e o contrário para sistemas com poucas soluções. Em relação ao tempo de processamento (Tabela 3), observa-se que apesar do esforço ser o mesmo (número de avaliações de fitness), existe grande diferença de tempo entre as estratégias. Em todos os sistemas, o NSGA-II e o PAES demoraram mais na estratégia CA. O SPEA2 na estratégia CA foi mais rápido que na SA para o sistema JHot- Draw, já para os outros sistemas a estratégia CA demorou mais para executar. Dos três MOEAs, o SPEA2 foi o único que teve comportamento diferenciado para um sistema e também foi o que mais demorou para finalizar as execuções. A Figura 2 apresenta as soluções no espaço de busca. Como só é possível a apresentação de três medidas no gráfico, foram escolhidas as medidas que possibilitaram a melhor visualização das soluções no espaço de busca. No gráfico do JHotDraw (Figura 2(a)) observa-se que as soluções da estratégia SA estão próximas dos objetivos mínimos (A=0,O=0,Rd=0,Pd=0), entretanto as restrições dos agrupamentos não permitem esta solução, então os MOEAs encontram soluções em outras regiões do espaço de busca, onde um maior número de soluções é possível. Para o sistema MyBatis (Figura 2(b)) pode-se verificar que as soluções da estratégia SA estão localizadas em uma mesma região do gráfico, mais próximas aos objetivos mínimos. Entretanto na estratégia CA estas soluções não são possíveis, forçando os MOEAs a explorarem novas regiões do espaço de busca. Mas neste caso as restrições dificultam a obtenção de soluções, diminuindo a quantidade das mesmas. Fica claro que a utilização da estratégia CA nestes casos deixa a busca por soluções mais complexa, limitando o espaço de busca Comparação entre os MOEAs utilizando a estratégia CA A Tabela 4 apresenta os valores do indicador C para os conjuntos P F known. A leitura da tabela é feita por linha/coluna, no qual o MOEA da linha domina em determinado valor o MOEA da coluna. Os valores estão em um intervalo de 0 a 1, onde 0 indica que não existe dominância e 1 indica que todo o conjunto é dominado. Só são significantes os valores acima de 0,5, o que indica que mais de 50% do conjunto é dominado. Os resultados deste indicador demonstram diferença dentre os MOEAS para dois sistemas: BCEL e MyBatis. Através da análise da Tabela 4 verifica-se que para o sistema

9 Parâmetro Retorno SA CA Atributo (a) Sistema JHotDraw Parâmetro Retorno SA CA Atributo (b) Sistema MyBatis 3000 Figura 2. P F true s no Espaço de Busca Tabela 4. Valores do Indicador C Sistema MOEA NSGA-II PAES SPEA2 Sistema NSGA-II PAES SPEA2 NSGA-II - 0,75 0, , , BCEL PAES 0-0 JHotDraw 0, ,45098 SPEA2 0, ,75-0, , NSGA-II , JBoss PAES 0-0 MyBatis 1-1 SPEA , BCEL, as soluções do NSGA-II dominam 75% das soluções do PAES e aproximadamente 60% das soluções do SPEA2. As soluções do SPEA2 também dominam 75% das soluções do PAES. Para o sistema MyBatis, as soluções do PAES dominam todas as soluções do NSGA-II e do SPEA2, e as soluções do NSGA-II dominam aproximadamente 73% das soluções do SPEA2. Baseado no indicador C verifica-se que o NSGA-II teve os melhores resultados, seguido pelo SPEA2 e por fim o PAES. A Tabela 5 apresenta os resultados dos indicadores GD e IGD. Estes resultados correspondem à média e ao desvio padrão dos valores de GD e IGD obtidos na comparação de cada um dos trinta P F approx em relação ao conjunto P F true de cada sistema. Para verificar a diferença significativa entre os resultados dos MOEAs, utilizou-se o teste estatístico de Friedman [Gárcia et al. 2009] utilizando α = 0, 05. Tabela 5. Média e Desvio Padrão de GD e IGD NSGA-II PAES SPEA2 Indicador Sistema Média Desvio Média Desvio Média Desvio Padrão Padrão Padrão GD IGD BCEL 0,1334 0,0349 1,9266 1,2256 0,1257 0,0387 JBoss 0,7956 1,6492 1,1045 1,9222 0,5147 1,2308 JHotDraw 0,0132 0,0039 0,0076 0,0021 0,0126 0,0026 MyBatis 0,0444 0,0125 0,0082 0,0026 0,0479 0,0160 BCEL 0,2205 0,0420 0,9239 1,2194 0,2024 0,0345 JBoss 0,6312 1,2291 0,8242 1,4220 0,4361 0,9378 JHotDraw 0,0254 0,0102 0,0135 0,0054 0,0229 0,0069 MyBatis 0,0512 0,0223 0,0104 0,0034 0,0578 0,0191 Para o indicador GD, o teste de Friedman apontou diferença significativa entre os sistemas: BCEL, JHotDraw e MyBatis. Para o sistema BCEL, o NSGA-II e SPEA2 são melhores e não apresentam diferença entre si. Para os sistemas JHotDraw e MyBatis, o

10 PAES é melhor que o NSGA-II e o SPEA2, e estes últimos não apresentam diferença. Para o indicador IGD os sistemas JHotDraw e MyBatis apresentaram diferença estatística, na qual o PAES é melhor que o NSGA-II e SPEA2, e estes últimos não apresentam diferença. A Tabela 6 apresenta os valores do indicador ED. Na segunda coluna são apresentados os custos das soluções ideais, obtidos considerando os menores valores de cada um dos objetivos, independentemente de estarem na mesma solução, de todas as soluções do conjunto P F true de cada sistema. Nas outras colunas são apresentados os custos (A,O,Rd,Pd) da solução mais próxima da ideal e os valores obtidos por cada algoritmo. Tabela 6. Custo da Solução Ideal e Menores ED Encontradas NSGA-II PAES SPEA2 Solução Sistema Menor Custo da Menor Custo da Menor Custo da Ideal ED Solução ED Solução ED Solução BCEL (40,54, (57,59, (51,59, (45,63, 24, , , ,59) 50,60) 34,132) 52,68) JBoss (25,17, (25,17, (25,17, (25,17, 2,0000 2,0000 2,0000 4,14) 6,14) 6,14) 6,14) JHotDraw (283,258, (301,274, (301,274, (301,274, 63, , , ,140) 105,197) 105,197) 105,197) MyBatis (259,148, 203,2855 (1709,204, 147,5263 (282,235, 221,4746 (386,267, 57,145) 81,191) 78,260) 97,276) Por meio dos resultados verifica-se que para os sistemas JBoss e JHotDraw, todos os MOEAs encontraram uma mesma solução com o menor valor de ED. Para o sistema BCEL, o SPEA2 encontrou a solução com o melhor valor de ED. Para o sistema MyBatis, o PAES encontrou a solução com menor valor de ED Discussão dos Resultados Para comparar os MOEAs utilizando todos os indicadores, considerou-se qual o melhor MOEA para cada um dos quatro indicadores de qualidade. Para o sistema BCEL, o melhor MOEA foi o SPEA2, seguido com pouca diferença pelo NSGA-II e distante dos dois o PAES. Para o sistema JBoss, todos os MOEAs apresentaram o mesmo comportamento. Para o sistema JHotDraw, o PAES foi o melhor, seguido pelo NSGA-II e SPEA2. Para o sistema MyBatis, o PAES foi o melhor com bastante diferença, seguido pelo NSGA-II. Diante desta análise, verifica-se que o PAES, considerando a maioria dos casos, obteve os melhores resultados para três sistemas: JBoss, JHotDraw, MyBatis. Estes três sistemas são os que têm maior número de classes e maior número de agrupamentos (Tabela 1). Portanto, em casos que se deve estabelecer ordens de integração e teste para sistemas grandes e com vários agrupamentos, o PAES é a melhor opção dentre os MO- EAs analisados. O SPEA2 e o NSGA-II apresentaram comportamento similar, obtendo os melhores resultados para dois sistemas: BCEL, JBoss. Tanto o SPEA2 quanto o NSGA-II são melhores para sistemas com poucas classes e poucos agrupamentos (Tabela 1). Uma vez que o PAES foi melhor para os sistemas com maior número de agrupamentos, podese inferir que o operador de mutação, o único operador evolutivo aplicado pelo PAES, é o mais apropriado para obter melhores soluções. Ou seja, para sistemas com muitos agrupamentos, parece que o operador de cruzamento não apresenta boa performance Exemplo de Uso das Soluções - Seleção de Uma Ordem Os MOEAs encontram um conjunto de diversas soluções, porém só uma vai ser utilizada. Uma recomendação para selecionar uma ordem é utilizar a solução com melhor ED, pois

11 esta está mais próxima dos objetivos ótimos. Como exemplo, na Tabela 7 é apresentada a solução com menor ED obtida pelo PAES para o sistema JHotDraw. Custo da Solução (301,274,105,197) Tabela 7. Solução do PAES para o Sistema JHotDraw Ordem das Classes {138, 29, 108, 15, 33, 154, 153}, {187, 87, 9, 196, 185, 67}, {24, 116, 93, 82, 25, 190, 49, 91, 30, 99, 170, 104, 105, 26, 115, 173, 191, 164, 121, 86, 50, 189, 46, 69, 186, 134, 38, 48, 155, 102, 100, 188, 117, 89, 23, 118, 157, 68}, {101, 96, 114, 12, 53, 180, 123, 62, 182, 16, 156, 140, 107, 103, 145, 45, 75, 144, 34, 36, 146, 11, 97, 3, 152, 158, 95, 73, 2, 122, 179, 176, 47, 28, 27, 31, 5, 165, 54, 77, 4, 57, 159, 113, 150, 52, 129, 166, 192, 83, 110, 32, 137, 135, 1, 8, 151, 65, 132, 130}, {128, 147, 124, 125, 169, 181, 61}, {131, 13, 141, 120, 194}, {58, 84, 66, 0, 7, 98, 111, 85, 79}, {10, 81, 78, 88, 195, 90, 183}, {133, 51, 14, 148, 109, 21}, {56, 6, 139, 42, 40, 39, 44, 43, 172, 41}, {136, 60, 94, 171}, {184, 76, 160, 119, 18, 64, 55, 74, 59, 35, 70, 126, 178, 175, 177, 71, 174, 167, 72}, {17, 161, 163, 20, 63, 142, 168, 19, 149, 106, 112, 193, 22, 143, 37, 127, 92, 162, 80} Por da ordem selecionada é possível observar que as classes devem ser desenvolvidas, integradas e testadas na seguinte sequência: {138, 29, 108,...},..., {..., 92, 162, 80}. Utilizando esta ordem, para realização do teste de integração de todo o sistema será necessário construir stubs para simular 301 atributos, 274 métodos, 105 tipos distintos de retornos e 197 tipos distintos de parâmetros. Outra possibilidade de regra para selecionar uma ordem de classes é priorizar determinada medida de acoplamento. Por exemplo, caso o sistema em desenvolvimento apresente atributos complexos de serem construídos, então a solução com menor valor para A deve ser utilizada; ou caso o sistema apresente parâmetros dos métodos difíceis de serem simulados, a solução com menor Pd deve ser utilizada. 7. Conclusão Este trabalho tratou do problema CITO propondo uma estratégia que considera agrupamento de classes durante o estabelecimento de ordens de teste e integração. O objetivo do trabalho foi avaliar o impacto no espaço de busca quando restrições relativas a agrupamentos são consideradas, além de verificar qual algoritmo apresenta melhor desempenho para resolver o problema CITO com agrupamento. Por meio da análise dos resultados, comparando o comportamento da estratégia SA em relação à estratégia CA, é possível verificar que considerar agrupamentos de classes durante a resolução do problema CITO eleva a complexidade para se encontrar soluções, limitando o espaço de busca a determinadas regiões. Em relação ao comportamento dos MOEAs na estratégia CA, todos encontraram boas soluções, e com bom tradeoff entre as medidas de acoplamento. Através dos indicadores de qualidade é possível observar que o PAES obteve melhores resultados, principalmente nos casos de sistemas mais complexos com um maior número de classes, seguido pelo SPEA2 e NSGA-II que não apresentam diferença. Este resultado é similar aos reportados na literatura [Assunção et al. 2011b] para a estratégia SA. Como trabalhos futuros pretende-se: explorar algoritmos de clustering para estabelecer os agrupamentos de classes; avaliar a estratégia CA em outros contextos, tais como software orientado a aspectos, a componentes e serviços; considerar restrições reais de um contexto de desenvolvimento distribuído de software; além de utilizar outras metaheurísticas como otimização por colônia de formigas, por nuvem de partículas, etc.

12 Referências Abdurazik, A. and Offutt, J. (2006). Coupling-based class integration and test order. In International Workshop on Automation of Software Test, Shanghai, China. ACM. Assunção, W. K. G., Colanzi, T. E., Pozo, A. T. R., and Vergilio, S. R. (2011a). Reduzindo o custo do teste de integração com algoritmos evolutivos multiobjetivos e diferentes medidas de acoplamento. In Encontro Nacional de Inteligência Artificial (ENIA 2011). Assunção, W. K. G., Colanzi, T. E., Vergilio, S. R., and Pozo, A. T. R. (2011b). Estabelecendo sequências de teste de integração de classes: Um estudo comparativo da aplicação de três algoritmos evolutivos multiobjetivos. In Workshop de Teste e Tolerância a Falhas (WTF 2011). Briand, L. C., Feng, J., and Labiche, Y. (2002). Experimenting with genetic algorithms and coupling measures to devise optimal integration test orders. Technical report. Briand, L. C., Labiche, Y., and Wang, Y. (2003). An investigation of graph-based class integration test order strategies. IEEE Transactions on Software Engineering, 29(7): Card, D. N., Page, G. T., and McGarry, F. E. (1985). Criteria for software modularization. In 8th International Conference on Software Engineering (ICSE 1985), pages Deb, K., Pratap, A., Agarwal, S., and Meyarivan, T. (2002). A fast and elitist multiobjective genetic algorithm: NSGA-II. IEEE Trans. on Evolutionary Computation, 6(2): Gárcia, S., Molina, D., Lozano, M., and Herrera, F. (2009). A study on the use of non-parametric tests for analyzing the evolutionary algorithms behaviour: a case study on the CEC 2005 Special Session on Real Parameter Optimization. Journal of Heuristics, 15(6): Knowles, J., Thiele, L., and Zitzler, E. (2006). A tutorial on the performance assessment of stochastic multiobjective optimizers. Technical report, Computer Engineering and Networks Laboratory (TIK), ETH Zurich, Switzerland. Revised version. Knowles, J. D. and Corne, D. W. (2000). Approximating the nondominated front using the pareto archived evolution strategy. Evolutionary Computation, 8: Kung, D. C., Gao, J., Hsia, P., Lin, J., and Toyoshima, Y. (1995). Class firewall, test order and regression testing of object-oriented programs. J. of Object-Oriented Program, 8(2): Pareto, V. (1927). Manuel D Economie Politique. Ams Press, Paris. Pressman, R. S. (2001). Software Engineering : A Practitioner s Approach. McGraw Hill, NY. Tai, K.-C. and Daniels, F. J. (1997). Test order for inter-class integration testing of object-oriented software. In 21st Inter. Computer Software and Applications Conference, pages Vergilio, S., Pozo, A., Árias, J., Cabral, R., and Nobre, T. (2012). Multi-objective optimization algorithms applied to the class integration and test order problem. International Journal on Software Tools for Technology Transfer, 14(4): Zitzler, E., Laumanns, M., and Thiele, L. (2001). SPEA2: Improving the Strength Pareto Evolutionary Algorithm. Technical Report 103, Gloriastrasse 35, CH-8092 Zurich, Switzerland. Zitzler, E., Thiele, L., Laumanns, M., Fonseca, C. M., and da Fonseca, V. G. (2003). Performance assessment of multiobjective optimizers: An analysis and review. IEEE Transactions on Evolutionary Computation, 7: