Uma Estrat´egia para Integrar e Testar Agrupamentos de Classes Baseada em Algoritmos Multiobjetivos
Wesley Klewerton Guez Assunc¸˜ao1, Thelma Elita Colanzi1 2, Aurora Trinidad Ramirez Pozo1, Silvia Regina Vergilio1
1DInf, Universidade Federal do Paran´a (UFPR) – Curitiba, PR – Brasil
2DIN, Universidade Estadual de Maring´a (UEM) – Maring´a, PR – Brasil
{wesleyk, thelmae, aurora, silvia}@inf.ufpr.br
Resumo. Para realizar o teste de software orientado a objetos ´e necess´ario determinar uma ordem para integrar e testar as classes que implique em um custo m´ınimo associado `a construc¸˜ao de stubs. V´arios trabalhos tratam esse problema, por´em nenhum deles considera uma caracter´ıstica presente na mai- oria dos sistemas, que ´e o agrupamento de classes (ou modularizac¸˜ao). Con- siderando essa limitac¸˜ao, este artigo apresenta uma estrat´egia de integrac¸˜ao e teste de classes que considera agrupamentos. Esta estrat´egia ´e implemen- tada utilizando trˆes algoritmos evolutivos multiobjetivos e diferentes medidas de acoplamento para c´alculo do custo associado aos stubs. Os algoritmos s˜ao avaliados e comparados experimentalmente. O espac¸o de busca ´e analisado em comparac¸˜ao com a estrat´egia que n˜ao considera agrupamentos. Os resultados mostram que o espac¸o de busca fica restrito, forc¸ando os algoritmos a explora- rem novas regi˜oes e fazendo com que soluc¸˜oes sub-´otimas passem a ser soluc¸˜oes aproximadas.
Abstract. To perform the test of object-oriented software it is necessary to de- termine a class integration and test order associated to a minimal stubbing cost.
Several works deal with this problem, however, none of them considers a charac- teristic 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 multi- objective evolutionary algorithms and several coupling measures to calculate the stubbing cost. The algorithms are evaluated and compared in an experi- mental 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. Introduc¸˜ao
O teste ´e uma atividade essencial dentre as de garantia de qualidade de software, geral- mente realizada em etapas. Por exemplo, no teste de software orientado a objetos (OO), o teste de integrac¸˜ao tem como objetivo testar a interac¸˜ao entre as classes. Nesta etapa,
´e comum que algumas classes necessitem de recursos de outras classes que ainda est˜ao em desenvolvimento, o que leva `a necessidade de construc¸˜ao destubs, que s˜ao pseudo- implementac¸˜oes que simulam recursos n˜ao dispon´ıveis para executar a classe.
Para reduzir o custo da construc¸˜ao de stubs ´e necess´ario determinar uma ordem com custo m´ınimo para testar e integrar as classes. Este problema ´e conhecido como CITO (Class Integration and Test Order Problem) [Abdurazik and Offutt 2006] e tem sido alvo de pesquisa de v´arios trabalhos. Estes trabalhos prop˜oem soluc¸˜oes 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 ´ultimos, destacam-se os trabalhos que utilizam algoritmos de otimizac¸˜ao multiobjetivo como os mais promissores. Em [Vergilio et al. 2012] trˆes algoritmos multiobjetivos foram utiliza- dos e comparados considerando duas medidas de acoplamento (objetivos) que represen- tam os custos associados `a construc¸˜ao destubs. Neste estudo o algoritmo evolutivo, apre- sentou um melhor desempenho. Considerando este fato, em [Assunc¸˜ao et al. 2011a], uma estrat´egia 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ˆes diferentes MOEAs: NSGA-II, SPEA2, e PAES, sendo que este ´ultimo encontrou soluc¸˜oes ligeiramente melhores [Assunc¸˜ao et al. 2011b].
Apesar de existirem v´arios trabalhos que prop˜oem diferentes estrat´egias para in- tegrar e testar classes, nenhum deles considera uma caracter´ıstica do desenvolvimento de software: o agrupamento de classes ou modularizac¸˜ao [Card et al. 1985, Pressman 2001].
O agrupamento corresponde a v´arias classes, que s˜ao geralmente desenvolvidas em grupos e por isto testadas em conjunto, muitas vezes pela mesma equipe de teste. O agrupamento de classes em pacotes ´e amplamente utilizado para facilitar a organizac¸˜ao, o desenvol- vimento e a manutenc¸˜ao do software. Muitas vezes est´a associado ao desenvolvimento distribu´ıdo de software. Por isto ´e importante estabelecer uma estrat´egia que considere os grupos de classes que n˜ao podem ser separadas na soluc¸˜ao (ordem) do problema CITO.
O objetivo do presente trabalho ´e propor e avaliar uma estrat´egia 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˜oe restric¸˜oes ao espac¸o de busca e pode influenciar o desempenho dos algoritmos. Portanto, outro objetivo ´e compa- rar os trˆes algoritmos evolutivos NSGA-II, SPEA2, e PAES, escolhidos por implementa- rem diferentes estrat´egias de evoluc¸˜ao, e ver qual apresenta o melhor desempenho para o problema CITO com restric¸˜oes. Para isto, ´e conduzido um experimento utilizando quatro sistemas reais, quatro medidas de acoplamento (objetivos) e quatro indicadores de quali- dade para comparar os algoritmos: Cobertura, Distˆancia Geracional, Distˆancia Geracional Invertida e Distˆancia Euclidiana da Soluc¸˜ao Ideal.
Este artigo est´a organizado como segue: na Sec¸˜ao 2 s˜ao descritos os MOEAs utili- zados. Na Sec¸˜ao 3 a estrat´egia de teste e integrac¸˜ao de classes que considera agrupamen- tos ´e apresentada. Os aspectos da aplicac¸˜ao dos MOEAs no problema s˜ao apresentados na Sec¸˜ao 4. A Sec¸˜ao 5 descreve como foi realizado o estudo experimental. A Sec¸˜ao 6 apresenta a an´alise dos resultados, comparando estrat´egias e algoritmos. Finalmente, na Sec¸˜ao 7 s˜ao apresentadas as conclus˜oes.
2. Algoritmos Multiobjetivos
Problemas multiobjetivos est˜ao presentes na maioria das disciplinas. Para solucionar es- tes problemas, diferentes fatores devem ser considerados. Para estes problemas n˜ao ´e
poss´ıvel encontrar uma soluc¸˜ao ´unica, pois em geral os objetivos s˜ao conflitantes, ou seja, quando se melhora um objetivo se degrada outro. Ent˜ao a otimizac¸˜ao consiste em en- contrar um conjunto de soluc¸˜oes com o melhor balanceamento entre os objetivos. Para avaliar e determinar o grupo dessas soluc¸˜oes, utiliza-se o conceito de dominˆancia de Pa- reto [Pareto 1927]. O objetivo ´e descobrir soluc¸˜oes que n˜ao s˜ao dominadas. Dado um conjunto de poss´ıveis soluc¸˜oes para o problema, uma soluc¸˜ao A domina uma soluc¸˜ao B, se e somente se, A ´e melhor que B em pelo menos um dos objetivos, sem ser pior que B nos outros objetivos. O conjunto de soluc¸˜oes n˜ao-dominadas forma a fronteira de Pareto.
Muitas vezes encontrar a fronteira de Pareto real ´e NP-dif´ıcil [Knowles et al. 2006], ent˜ao o desafio ´e encontrar uma aproximac¸˜ao desta fronteira.
MOEAs s˜ao extens˜oes de algoritmos gen´eticos para problemas multiobjetivos que aplicam os conceitos de dominˆancia de Pareto para criar estrat´egias distintas para evo- luir e diversificar as soluc¸˜oes. 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 gerac¸˜ao os indiv´ıduos das populac¸˜oes pai e filha com base na relac¸˜ao de n˜ao- dominˆancia. Ele cria diversas fronteiras e, depois da ordenac¸˜ao, as soluc¸˜oes com mais baixa dominˆancia s˜ao descartadas. As fronteiras representam a estrat´egia de elitismo adotada pelo NSGA-II. Este algoritmo utiliza tamb´em um operador chamadocrowding distanceque ordena os indiv´ıduos de acordo com a sua distˆancia em relac¸˜ao aos vizinhos da fronteira, visando a garantir maior espalhamento das soluc¸˜oes. Ambas ordenac¸˜oes, de fronteiras e decrowding distance, s˜ao usadas pelo operador de selec¸˜ao.
O SPEA2 (Strength Pareto Evolutionary Algorithm) [Zitzler et al. 2001], al´em de ter sua populac¸˜ao regular, possui um arquivo externo que armazena soluc¸˜oes n˜ao- dominadas encontradas no processo evolutivo. Para cada soluc¸˜ao que est´a no arquivo e na populac¸˜ao ´e calculado um valor destrengthque tamb´em ´e usado no c´alculo dofitnessdo indiv´ıduo. O valor destrengthde uma soluc¸˜aoicorresponde a quantidade de indiv´ıduos j, do arquivo e da populac¸˜ao, dominados pori. Este valor ´e utilizado durante o processo de selec¸˜ao. No processo evolutivo, o arquivo externo ´e utilizado para complementar a nova gerac¸˜ao com soluc¸˜oes n˜ao dominadas. Como o tamanho do arquivo ´e fixo, se este tamanho for excedido, um algoritmo de agrupamento ´e utilizado a fim de reduzi-lo.
No processo evolutivo do algoritmo PAES (Pareto Archived Evolution Stra- tegy) [Knowles and Corne 2000] o conceito de populac¸˜ao ´e diferente das estrat´egias tra- dicionais, pois apenas uma soluc¸˜ao ´e mantida em cada gerac¸˜ao, e a criac¸˜ao de novos indiv´ıduos ´e feita somente atrav´es da aplicac¸˜ao do operador de mutac¸˜ao. Assim como no SPEA2, existe um arquivo externo de soluc¸˜oes que ´e populado com as soluc¸˜oes n˜ao do- minadas encontradas durante o processo. A cada gerac¸˜ao, o PAES cria uma nova soluc¸˜ao filha que ´e comparada com a soluc¸˜ao pai, se a soluc¸˜ao filha domina a soluc¸˜ao pai, a fi- lha toma o lugar da pai, e a filha ´e acrescentada ao arquivo externo; se a soluc¸˜ao filha
´e dominada pela pai ou por alguma soluc¸˜ao do arquivo externo, a filha ´e descartada; e caso nenhuma das soluc¸˜oes domine a outra, a escolha da soluc¸˜ao que vai permanecer no processo evolutivo ´e feita considerando a diversidade entre pai, filha e as soluc¸˜oes do con- junto externo. Caso o tamanho do arquivo externo exceda, ´e aplicada uma estrat´egia de diversidade sobre este conjunto de soluc¸˜oes, eliminando soluc¸˜oes similares.
3. Estrat´egia de Integrac¸˜ao e Teste de Classes Baseada em Agrupamento A estrat´egia de ordenac¸˜ao de classes proposta consiste em considerar um conjunto de agrupamentos de classes durante o estabelecimento de uma ordem de integrac¸˜ao e teste.
Um agrupamento corresponde a um conjunto de classes que s˜ao agrupadas pelo enge- nheiro de software e que devem ser desenvolvidas e testadas em conjunto.
A Figura 1 ilustra o problema de integrac¸˜ao considerando o agrupamento de clas- ses. O sistema cont´em 12 classes. O problema CITO requer uma ordem (por exemplo Or- dens A e B) para que estas classes sejam testadas com um custo m´ınimo para construc¸˜ao de stubs. Para o problema CITO que n˜ao considera agrupamentos ambas ordens s˜ao v´alidas. Mas suponha que o engenheiro de software determine que algumas classes, por exemplo por quest˜ao de um desenvolvimento distribu´ıdo, sejam agrupadas para serem de- senvolvidas e testadas por uma mesma equipe em conjunto, formando os agrupamentos A1, A2 e A3. A Ordem A ´e v´alida, pois as classes dos agrupamentos n˜ao est˜ao separadas.
Na Ordem A as classes de A1 devem ser desenvolvidas e testadas primeiramente, segui- das pelas classes de A3 e pelas classes de A2. J´a a Ordem B n˜ao ´e uma sequˆencia v´alida, pois as classes de A1 e A3 ficaram dispersas, ou seja, as classes dos agrupamentos A1 e A3 n˜ao est˜ao agrupadas como definidas.
1 3 2
4 5
6 7 8 9
10 11 12
Agrupamento de Classes
1 3 2
4 5 11 8 9 12 6 10 7
Possíveis ordens de testes Ordem A
1 2 3
4 5
6 7 10 8 12 11 9
Ordem B
A1 A2 A3
Figura 1. Exemplos da Utilizac¸ ˜ao da Estrat ´egia Baseada em Agrupamentos
4. MOEAs aplicados ao problema CITO com Agrupamentos
Para aplicar os MOEAs para resolver o problema CITO considerando os agrupamentos ´e preciso definir uma boa representac¸˜ao para o problema. E esta representac¸˜ao influencia na implementac¸˜ao de todos os est´agios dos algoritmos. Para considerar os agrupamentos de classes, foi necess´aria uma representac¸˜ao diferente das utilizadas nos trabalhos relaci- onados. Foi implementada uma classeCluster formada por dois atributos: (i)iddo tipo inteiro utilizado para identificar o agrupamento durante o cruzamento e a mutac¸˜ao, e (ii)modulesque ´e uma lista de inteiros, que armazena a ordem das classes do agrupa- mento, na qual cada inteiro representa uma classe. Um indiv´ıduo ´e formado por um vetor de objetos da classeCluster(ArrayList<Cluster>). O tamanho do vetor ´e igual a quantidade de agrupamentos e a soma de todos os tamanhos dos vetoresmodules ´e igual a quantidade de classes do sistema.
Para as func¸˜oes objetivo dos MOEAs foram usadas quatro medidas de acopla- mento, que representam o custo da construc¸˜ao destubs. Considerando-se queci ecj s˜ao duas classes acopladas, essas medidas de acoplamento s˜ao definidas como segue:
• N ´umero de atributos (A)= N´umero de atributos localmente declarados em cj quando referˆencias ou apontadores para uma instˆancia decj aparecem na lista de argumentos de alguns m´etodos deci.
• N ´umero de m´etodos (M)= N´umero de m´etodos (inclusive construtores) local- mente declarados emcj que s˜ao invocados por m´etodos deci.
• N ´umero de tipos de retorno (Rd) = Total de tipos de retorno distintos dos m´etodos localmente declarados emcj que s˜ao invocados por m´etodos deci.
• N ´umero de tipos de parˆametros (Pd) = Total de tipos de parˆametros distintos localmente declarados em m´etodos decj que s˜ao invocados por m´etodos deci. Os dados de entrada de cada MOEA s˜ao formados por matrizes, como em [Briand et al. 2002], e s˜ao: uma matriz de dependˆencia entre as classes, que define as restric¸˜oes relativas `as dependˆencias de heranc¸a que n˜ao devem ser quebradas; outras qua- tro matrizes correspondentes a cada uma das m´etricas descritas acima; e uma matriz com a definic¸˜ao dos agrupamentos. Ofitnessde cada soluc¸˜ao ´e calculado atrav´es da soma das dependˆencias quebradas entre as classes para cada uma das m´etricas, que correspondem aos objetivos. Para reduzir o custo dosstubsdeve-se minimizar todos os objetivos.
Para os operadores gen´eticos foram implementadas diferentes estrat´egias a fim de possibilitar o tratamento das restric¸˜oes dos agrupamentos. Para o cruzamento e mutac¸˜ao foram implementadas estrat´egias inter-cluster e intra-cluster. No cruzamento inter-cluster os agrupamentos s˜ao completamente trocados entre dois indiv´ıduos, j´a no cruzamentointra-cluster um mesmo agrupamento ´e selecionado de dois indiv´ıduos dife- rentes, ent˜ao ´e efetuado o cruzamento de dois pontos de corte, sendo que os outros agru- pamentos n˜ao s˜ao afetados. Na mutac¸˜aointer-cluster os agrupamentos de um indiv´ıduo s˜ao trocados completamente de posic¸˜ao dentro da ordem, j´a na mutac¸˜ao intra-cluster ´e selecionado um agrupamento do indiv´ıduo, ent˜ao duas classes s˜ao trocadas de posic¸˜ao.
5. Descric¸˜ao do Estudo Experimetal
A seguir a estrat´egia que n˜ao considera os agrupamentos ser´a referenciada pela sigla SA (Sem Agrupamentos) implementada tal como descrito em [Assunc¸˜ao et al. 2011a, Assunc¸˜ao et al. 2011b], enquanto a estrat´egia proposta que considera os agrupamentos
´e referenciada pela siglaCA(Com Agrupamentos) tal como descrito anteriormente. Os sistemas utilizados bem como a metodologia adotada s˜ao os mesmos descritos nos traba- lhos relacionados [Assunc¸˜ao et al. 2011a, Assunc¸˜ao et al. 2011b].
5.1. Sistemas Utilizados
Foram utilizados quatro sistemas desenvolvidos em Java (Tabela 1). S˜ao eles: BCEL, JBoss, JHotDraw e MyBatis. O sistema BCEL (Byte Code Engineering Library),
´e uma biblioteca utilizada para analisar, criar e manipular arquivos bin´arios da lin- guagem de programac¸˜ao Java. Neste experimento utilizou-se somente o pacote org.apache.bcel.classfileda vers˜ao 5.0. O sistema JBoss ´e um servidor de aplicac¸˜oes Java. Para o experimento utilizou-se o subsistema Management da vers˜ao 6.0.0M5. Outro sistema utilizado ´e umframework de gr´aficos bidimensionais para edi- tores de desenho estruturado chamado de JHotDraw. Para o experimento utilizou-se o pacoteorg.jhotdraw.drawda vers˜ao 7.5.1. O ´ultimo sistema selecionado foi o My- Batis, que ´e umframework de mapeamento de classes para aplicac¸˜oes OO que utilizam bancos de dados relacionais. A vers˜ao utilizada do sistema MyBatis ´e a 3.0.2.
Tabela 1. Sistemas Utilizados no Experimento
Sistema Vers˜ao LOC Classes Dispon´ıvel em Agrupamentos
BCEL 5.0 2999 45 http://archive.apache.org/dist/jakarta/bcel/old/v5.0/ 3 JBoss 6.0.0M5 8434 148 http://www.jboss.org/jbossas/downloads.html 8 JHotDraw 7.5.1 20273 197 http://sourceforge.net/projects/jhotdraw/ 13
MyBatis 3.0.2 23535 331 http://code.google.com/p/mybatis/downloads/list 24
As estrat´egias de integrac¸˜ao e teste devem ser aplicadas durante o projeto do sis- tema a ser desenvolvido, uma vez que estabelecem uma ordem para desenvolvimento e teste de classes. Por´em, ´e dif´ıcil obter documentac¸˜ao da arquitetura de sistemas com- plexos, ent˜ao para o experimento utilizou-se engenharia reversa para obter informac¸˜oes de acoplamento. A ferramenta utilizada foi um parser baseado na ferramenta AJATO1 (AspectJ and Java Assessment Tool). Esteparsertem como entrada o c´odigo fonte Java e retorna uma arvore sint´atica, usada para construir as matrizes de dependˆencia.
Para cada um dos sistemas, foi necess´ario definir os agrupamentos de classes. Para tal, utilizou-se uma regra a fim de padronizar a definic¸˜ao dos agrupamentos. O procedi- mento consiste em montar um grafo direcionado utilizando somente as dependˆencias de heranc¸a, considerando assim apenas as dependˆencias que n˜ao podem ser quebradas.
A partir deste grafo, foram separados os componentes conectados, ou seja, separa- das as classes que tˆem relac¸˜ao, formando subgrafos. A partir dos subgrafos, as classes dos subgrafos de tamanho um, formaram um agrupamento, os subgrafos de tamanho dois for- maram outro agrupamento, os subgrafos de tamanho trˆes 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 ´e apresentado na ´ultima coluna da Tabela 1.
5.2. Configurac¸˜ao de Parˆametros dos MOEAs
Os parˆametros 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 [Assunc¸˜ao et al. 2011a, Assunc¸˜ao et al. 2011b]. Os valores adotados s˜ao apresentados na Tabela 2. O n´umero de avaliac¸˜oes de fitness ´e utilizado como crit´erio de parada. Cada MOEA foi executado trinta vezes para cada sistema, para verificar o seu comportamento padr˜ao.
Tabela 2. Valores dos Par ˆametros Utilizados pelos MOEAs
Parˆametro CA SA
NSGA-II PAES SPEA2 NSGA-II PAES SPEA2
Tamanho da Populac¸˜ao 300 300 300 300 300 300
Taxa de Cruzamento 0,95 - 0,95 0,95 - 0,95
Taxa de CruzamentoInter-Cluster 1,0 - 1,0 - - -
Taxa de CruzamentoIntra-Cluster 1,0 - 1,0 - - -
Taxa de Mutac¸˜ao 0,02 1 0,02 0,02 1 0,02
Taxa de Mutac¸˜aoInter-Cluster 0,5 0,5 0,5 - - -
Taxa de Mutac¸˜aoIntra-Cluster 0,5 0,5 0,5 - - -
Tamanho do Arquivo Externo - 250 250 - 250 250
N´umero de Avaliac¸˜oes deFitness 60000 60000 60000 60000 60000 60000
1AJATO dispon´ıvel em: http://www.teccomm.les.inf.puc-rio.br/emagno/ajato/
6. Resultados e An´alises
A seguir s˜ao apresentados os resultados da aplicac¸˜ao dos MOEAs com as estrat´egias SA e CA, com objetivo de analisar a diferenc¸a com relac¸˜ao ao espac¸o de busca considerando ambas estrat´egias. Posteriormente os MOEA s˜ao comparados para verificar qual tem melhor o comportamento para solucionar o problema utilizando a estrat´egia CA.
Para as an´alises ´e necess´ario utilizar diferentes conjuntos de soluc¸˜oes encontra- das, conjuntos estes obtidos de diferentes maneiras. Os conjuntos utilizados foram: (i) P Fapprox: este conjunto ´e obtido em cada execuc¸˜ao de cada algoritmo, portanto, como cada algoritmo ´e executado trinta vezes para cada problema, ao final das execuc¸˜oes obtˆem- se trinta conjuntosP Fapprox; (ii)P Fknown: este conjunto ´e formado atrav´es da uni˜ao de todas as soluc¸˜oes dos trinta conjuntosP Fapprox, eliminando-se as soluc¸˜oes dominadas e repetidas. J´a que os algoritmos tˆem aleatoriedade em seu processo evolutivo, ent˜ao cada execuc¸˜ao pode encontrar soluc¸˜oes diferentes; (iii)P Ftrue: este conjunto ´e obtido atrav´es da uni˜ao de todas as soluc¸˜oes dos conjuntosP Fknownde todos os MOEAs utilizados no experimento, eliminando-se as soluc¸˜oes dominadas e repetidas [Zitzler et al. 2003], pois uma vez que o conjuntoP Fknowntem as melhores soluc¸˜oes de determinado MOEA, ent˜ao juntar todas estas soluc¸˜oes implica em ter todas as melhores soluc¸˜oes conhecidas.
Para comparac¸˜ao entre os MOEAs, foram utilizados quatro indicadores de qua- lidade, assim como em [Assunc¸˜ao et al. 2011b]: Cobertura (C), Distˆancia Geracional (GD), Distˆancia Geracional Invertida (IGD) e Distˆancia Euclididana da Soluc¸˜ao Ideal (ED). O indicador de qualidade C ´e usado para medir a dominˆancia entre dois conjuntos.
Este indicador ´e um valor entre 0 e 1 referente a quanto um conjunto ´e dominado por outro. O indicador GD ´e usado para calcular a distˆancia entre o conjunto P Fapprox em relac¸˜ao ao conjuntoP Ftrue. J´a o indicador IGD observa o inverso do GD, pois tem o ob- jetivo de calcular a distˆancia do conjuntoP Ftrueem relac¸˜ao ao conjuntoP Fapprox. Tanto para GD quanto para IGD deseja-se obter valores pr´oximos a 0. O indicador Distˆancia Euclidiana da Soluc¸˜ao Ideal (ED) tem como objetivo encontrar a soluc¸˜ao que mais se aproxima dos objetivos ´otimos. Este indicador consiste em determinar os melhores valo- res para cada um dos objetivos entre todas as soluc¸˜oes deP Ftrue, encontrando um ponto considerado como o custo de uma soluc¸˜ao ideal, ent˜ao calcula-se a partir deste ponto a distˆancia euclidiana em relac¸˜ao a todas as soluc¸˜oes deP Fknown.
6.1. Comparac¸˜ao entre as estrat´egias SA e CA
As estrat´egias SA e CA s˜ao duas propostas diferenciadas para solucionar o problema CITO, portanto seus resultados n˜ao podem ser comparados assumindo que deveriam ter valores similares. O objetivo deste trabalho ´e analisar o impacto no espac¸o de busca.
A Tabela 3 apresenta o n´umero de soluc¸˜oes encontradas e o tempo de execuc¸˜ao.
Na terceira e na sexta colunas ´e apresentada a cardinalidade do conjunto P Ftrue. Na quarta e na s´etima colunas s˜ao apresentadas a m´edia da quantidade de soluc¸˜oes dos con- juntosP Fapprox e, entre parˆenteses, a cardinalidade do conjunto P Fknown. Na quinta e na oitava colunas s˜ao apresentados, respectivamente, a m´edia do tempo de execuc¸˜ao, em segundos, utilizados para obter cadaP Fapprox e o desvio padr˜ao entre parˆenteses.
Atrav´es do tamanho do conjuntoP Ftrueverifica-se que para os sistemas BCEL e MyBatis o n´umero de soluc¸˜oes encontradas pela estrat´egia CA foi menor que o n´umero de soluc¸˜oes encontradas pela estrat´egia SA. J´a para os sistemas JBoss e JHotDraw o n´umero
Tabela 3. N ´umero de Soluc¸ ˜oes e Tempo de Execuc¸ ˜ao
Sistema MOEA
SA CA
# N ´umero de Tempo de # N ´umero de Tempo de P Ftrue Soluc¸˜oes Execuc¸˜ao P Ftrue Soluc¸˜oes Execuc¸˜ao
BCEL
NSGA-II 37
37,43 (37) 5,91 (0,05)
15
7,57 (11) 8,61 (0,11)
PAES 39,30 (37) 6,58 (1,25) 3,40 (8) 29,89 (22,25)
SPEA2 36,70 (37) 123,07 (18,84) 8,53 (19) 3786,79 (476,23)
JBoss
NSGA-II 1
1,00 (1) 18,73 (0,20) 2
1,97 (2) 42,50 (0,47)
PAES 1,13 (1) 10,69 (0,62) 2,87 (2) 56,15 (12,50)
SPEA2 1,00 (1) 2455,35 (612,18) 2,17 (2) 3536,01 (335,97)
JHotDraw
NSGA-II 11
8,40 (10) 29,85 (0,34)
153
45,80 (110) 71,90 (0,45)
PAES 10,47 (19) 24,29 (1,50) 85,47 (143) 51,18 (2,82)
SPEA2 9,63 (9) 922,99 (373,98) 49,17 (102) 532,83 (81,93)
MyBatis
NSGA-II 789
276,37 (941) 74,03 (0,87)
200
72,60 (103) 189,91 (0,83) PAES 243,60 (679) 104,30 (7,91) 108,43 (200) 132,37 (3,91) SPEA2 248,77 (690) 128,88 (2,65) 64,33 (144) 517,52 (67,52)
de soluc¸˜oes encontradas pela CA foi maior do que encontradas pela SA. Observa-se que para os sistemas que apresentam v´arias soluc¸˜oes, menos soluc¸˜oes s˜ao encontradas quando se considera os agrupamentos, e o contr´ario para sistemas com poucas soluc¸˜oes.
Em relac¸˜ao ao tempo de processamento (Tabela 3), observa-se que apesar do esforc¸o ser o mesmo (n´umero de avaliac¸˜oes defitness), existe grande diferenc¸a de tempo entre as estrat´egias. Em todos os sistemas, o NSGA-II e o PAES demoraram mais na estrat´egia CA. O SPEA2 na estrat´egia CA foi mais r´apido que na SA para o sistema JHot- Draw, j´a para os outros sistemas a estrat´egia CA demorou mais para executar. Dos trˆes MOEAs, o SPEA2 foi o ´unico que teve comportamento diferenciado para um sistema e tamb´em foi o que mais demorou para finalizar as execuc¸˜oes.
A Figura 2 apresenta as soluc¸˜oes no espac¸o de busca. Como s´o ´e poss´ıvel a apresentac¸˜ao de trˆes medidas no gr´afico, foram escolhidas as medidas que possibilita- ram a melhor visualizac¸˜ao das soluc¸˜oes no espac¸o de busca. No gr´afico do JHotDraw (Figura 2(a)) observa-se que as soluc¸˜oes da estrat´egia SA est˜ao pr´oximas dos objetivos m´ınimos (A=0,O=0,Rd=0,Pd=0), entretanto as restric¸˜oes dos agrupamentos n˜ao permi- tem esta soluc¸˜ao, ent˜ao os MOEAs encontram soluc¸˜oes em outras regi˜oes do espac¸o de busca, onde um maior n´umero de soluc¸˜oes ´e poss´ıvel. Para o sistema MyBatis (Fi- gura 2(b)) pode-se verificar que as soluc¸˜oes da estrat´egia SA est˜ao localizadas em uma mesma regi˜ao do gr´afico, mais pr´oximas aos objetivos m´ınimos. Entretanto na estrat´egia CA estas soluc¸˜oes n˜ao s˜ao poss´ıveis, forc¸ando os MOEAs a explorarem novas regi˜oes do espac¸o de busca. Mas neste caso as restric¸˜oes dificultam a obtenc¸˜ao de soluc¸˜oes, di- minuindo a quantidade das mesmas. Fica claro que a utilizac¸˜ao da estrat´egia CA nestes casos deixa a busca por soluc¸˜oes mais complexa, limitando o espac¸o de busca.
6.2. Comparac¸˜ao entre os MOEAs utilizando a estrat´egia CA
A Tabela 4 apresenta os valores do indicador C para os conjuntosP Fknown. A leitura da tabela ´e feita por linha/coluna, no qual o MOEA da linha domina em determinado valor o MOEA da coluna. Os valores est˜ao em um intervalo de 0 a 1, onde 0 indica que n˜ao existe dominˆancia e 1 indica que todo o conjunto ´e dominado. S´o s˜ao significantes os valores acima de 0,5, o que indica que mais de 50% do conjunto ´e dominado.
Os resultados deste indicador demonstram diferenc¸a dentre os MOEAS para dois sistemas: BCEL e MyBatis. Atrav´es da an´alise da Tabela 4 verifica-se que para o sistema
0 500 1000 1500 2000 2500 3000 3500 0
20 40 60 80 100 120 140
0 50 100 150 200 250
Parâmetro
SA CA
Atributo Retorno
Parâmetro
(a) Sistema JHotDraw
0 500 1000 1500 2000 2500 3000 20 10
40 30 60 50 80 70 100 90 120 110
50 0 100 150 200 250 300 350
Parâmetro
SA CA
Atributo Retorno
Parâmetro
(b) Sistema MyBatis Figura 2. P Ftrue’s no Espac¸o de Busca
Tabela 4. Valores do Indicador C
Sistema MOEA NSGA-II PAES SPEA2 Sistema NSGA-II PAES SPEA2
BCEL
NSGA-II - 0,75 0,578947
JHotDraw
- 0,027972 0,166667
PAES 0 - 0 0,427273 - 0,45098
SPEA2 0,181818 0,75 - 0,345455 0,020979 -
JBoss
NSGA-II - 0 0
MyBatis
- 0 0,729167
PAES 0 - 0 1 - 1
SPEA2 0 0 - 0,349515 0 -
BCEL, as soluc¸˜oes do NSGA-II dominam 75% das soluc¸˜oes do PAES e aproximadamente 60% das soluc¸˜oes do SPEA2. As soluc¸˜oes do SPEA2 tamb´em dominam 75% das soluc¸˜oes do PAES. Para o sistema MyBatis, as soluc¸˜oes do PAES dominam todas as soluc¸˜oes do NSGA-II e do SPEA2, e as soluc¸˜oes do NSGA-II dominam aproximadamente 73% das soluc¸˜oes 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 resulta- dos correspondem `a m´edia e ao desvio padr˜ao dos valores de GD e IGD obtidos na comparac¸˜ao de cada um dos trintaP Fapprox em relac¸˜ao ao conjuntoP Ftrue de cada sis- tema. Para verificar a diferenc¸a significativa entre os resultados dos MOEAs, utilizou-se o teste estat´ıstico de Friedman [G´arcia et al. 2009] utilizandoα = 0,05.
Tabela 5. M ´edia e Desvio Padr ˜ao de GD e IGD
Indicador Sistema
NSGA-II PAES SPEA2
M´edia Desvio
M´edia Desvio
M´edia Desvio
Padr˜ao Padr˜ao Padr˜ao
GD
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
IGD
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 diferenc¸a significativa entre os sistemas: BCEL, JHotDraw e MyBatis. Para o sistema BCEL, o NSGA-II e SPEA2 s˜ao melhores e n˜ao apresentam diferenc¸a entre si. Para os sistemas JHotDraw e MyBatis, o
PAES ´e melhor que o NSGA-II e o SPEA2, e estes ´ultimos n˜ao apresentam diferenc¸a. Para o indicador IGD os sistemas JHotDraw e MyBatis apresentaram diferenc¸a estat´ıstica, na qual o PAES ´e melhor que o NSGA-II e SPEA2, e estes ´ultimos n˜ao apresentam diferenc¸a.
A Tabela 6 apresenta os valores do indicador ED. Na segunda coluna s˜ao apresen- tados os custos das soluc¸˜oes ideais, obtidos considerando os menores valores de cada um dos objetivos, independentemente de estarem na mesma soluc¸˜ao, de todas as soluc¸˜oes do conjunto P Ftrue de cada sistema. Nas outras colunas s˜ao apresentados os custos (A,O,Rd,Pd) da soluc¸˜ao mais pr´oxima da ideal e os valores obtidos por cada algoritmo.
Tabela 6. Custo da Soluc¸ ˜ao Ideal e Menores ED Encontradas
Sistema Soluc¸˜ao NSGA-II PAES SPEA2
Ideal Menor Custo da Menor Custo da Menor Custo da ED Soluc¸˜ao ED Soluc¸˜ao ED Soluc¸˜ao BCEL (40,54,
24,5764 (57,59,
74,0000 (51,59,
23,4094 (45,63,
33,59) 50,60) 34,132) 52,68)
JBoss (25,17,
2,0000 (25,17,
2,0000 (25,17,
2,0000 (25,17,
4,14) 6,14) 6,14) 6,14)
JHotDraw (283,258,
63,2297 (301,274,
63,2297 (301,274,
63,2297 (301,274,
92,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 soluc¸˜ao com o menor valor de ED. Para o sistema BCEL, o SPEA2 encontrou a soluc¸˜ao com o melhor valor de ED. Para o sistema MyBatis, o PAES encontrou a soluc¸˜ao com menor valor de ED.
6.3. Discuss˜ao 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 me- lhor MOEA foi o SPEA2, seguido com pouca diferenc¸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 diferenc¸a, seguido pelo NSGA-II.
Diante desta an´alise, verifica-se que o PAES, considerando a maioria dos casos, obteve os melhores resultados para trˆes sistemas: JBoss, JHotDraw, MyBatis. Estes trˆes sistemas s˜ao os que tˆem maior n´umero de classes e maior n´umero de agrupamentos (Ta- bela 1). Portanto, em casos que se deve estabelecer ordens de integrac¸˜ao e teste para sistemas grandes e com v´arios agrupamentos, o PAES ´e a melhor opc¸˜ao 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˜ao melhores para sistemas com poucas classes e poucos agrupamentos (Tabela 1). Uma vez que o PAES foi melhor para os sistemas com maior n´umero de agrupamentos, pode- se inferir que o operador de mutac¸˜ao, o ´unico operador evolutivo aplicado pelo PAES,
´e o mais apropriado para obter melhores soluc¸˜oes. Ou seja, para sistemas com muitos agrupamentos, parece que o operador de cruzamento n˜ao apresenta boa performance.
6.4. Exemplo de Uso das Soluc¸˜oes - Selec¸˜ao de Uma Ordem
Os MOEAs encontram um conjunto de diversas soluc¸˜oes, por´em s´o uma vai ser utilizada.
Uma recomendac¸˜ao para selecionar uma ordem ´e utilizar a soluc¸˜ao com melhor ED, pois
esta est´a mais pr´oxima dos objetivos ´otimos. Como exemplo, na Tabela 7 ´e apresentada a soluc¸˜ao com menor ED obtida pelo PAES para o sistema JHotDraw.
Tabela 7. Soluc¸ ˜ao do PAES para o Sistema JHotDraw
Custo da Soluc¸˜ao Ordem das Classes
(301,274,105,197)
{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 ´e poss´ıvel observar que as classes devem ser desenvol- vidas, integradas e testadas na seguinte sequˆencia: {138, 29, 108, ...}, ..., {..., 92, 162, 80}. Utilizando esta ordem, para realizac¸˜ao do teste de integrac¸˜ao de todo o sistema ser´a necess´ario construirstubspara simular 301 atributos, 274 m´etodos, 105 tipos distintos de retornos e 197 tipos distintos de parˆametros.
Outra possibilidade de regra para selecionar uma ordem de classes ´e priorizar determinada medida de acoplamento. Por exemplo, caso o sistema em desenvolvimento apresente atributos complexos de serem constru´ıdos, ent˜ao a soluc¸˜ao com menor valor para A deve ser utilizada; ou caso o sistema apresente parˆametros dos m´etodos dif´ıceis de serem simulados, a soluc¸˜ao com menor Pd deve ser utilizada.
7. Conclus˜ao
Este trabalho tratou do problema CITO propondo uma estrat´egia que considera agrupa- mento de classes durante o estabelecimento de ordens de teste e integrac¸˜ao. O objetivo do trabalho foi avaliar o impacto no espac¸o de busca quando restric¸˜oes relativas a agrupa- mentos s˜ao consideradas, al´em de verificar qual algoritmo apresenta melhor desempenho para resolver o problema CITO com agrupamento.
Por meio da an´alise dos resultados, comparando o comportamento da estrat´egia SA em relac¸˜ao `a estrat´egia CA, ´e poss´ıvel verificar que considerar agrupamentos de classes durante a resoluc¸˜ao do problema CITO eleva a complexidade para se encontrar soluc¸˜oes, limitando o espac¸o de busca a determinadas regi˜oes.
Em relac¸˜ao ao comportamento dos MOEAs na estrat´egia CA, todos encontra- ram boas soluc¸˜oes, e com bom tradeoff entre as medidas de acoplamento. Atrav´es dos indicadores de qualidade ´e poss´ıvel observar que o PAES obteve melhores resultados, principalmente nos casos de sistemas mais complexos com um maior n´umero de classes, seguido pelo SPEA2 e NSGA-II que n˜ao apresentam diferenc¸a. Este resultado ´e similar aos reportados na literatura [Assunc¸˜ao et al. 2011b] para a estrat´egia SA.
Como trabalhos futuros pretende-se: explorar algoritmos de “clustering” para estabelecer os agrupamentos de classes; avaliar a estrat´egia CA em outros contextos, tais como software orientado a aspectos, a componentes e servic¸os; considerar restric¸˜oes reais de um contexto de desenvolvimento distribu´ıdo de software; al´em de utilizar outras meta- heur´ısticas como otimizac¸˜ao por colˆonia de formigas, por nuvem de part´ıculas, etc.
Referˆencias
Abdurazik, A. and Offutt, J. (2006). Coupling-based class integration and test order. InInternati- onal Workshop on Automation of Software Test, Shanghai, China. ACM.
Assunc¸˜ao, W. K. G., Colanzi, T. E., Pozo, A. T. R., and Vergilio, S. R. (2011a). Reduzindo o custo do teste de integrac¸˜ao com algoritmos evolutivos multiobjetivos e diferentes medidas de acoplamento. InEncontro Nacional de Inteligˆencia Artificial (ENIA’2011).
Assunc¸˜ao, W. K. G., Colanzi, T. E., Vergilio, S. R., and Pozo, A. T. R. (2011b). Estabelecendo sequˆencias de teste de integrac¸˜ao de classes: Um estudo comparativo da aplicac¸˜ao de trˆes algoritmos evolutivos multiobjetivos. InWorkshop de Teste e Tolerˆancia 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):594–607.
Card, D. N., Page, G. T., and McGarry, F. E. (1985). Criteria for software modularization. In8th International Conference on Software Engineering (ICSE’1985), pages 372–377.
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):182 –197.
G´arcia, 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):617–644.
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:149–172.
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):51–65.
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. In21st Inter. Computer Software and Applications Conference, pages 602–607.
Vergilio, S., Pozo, A., ´Arias, 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):461–475.
Zitzler, E., Laumanns, M., and Thiele, L. (2001). SPEA2: Improving the Strength Pareto Evoluti- onary 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). Perfor- mance assessment of multiobjective optimizers: An analysis and review. IEEE Transactions on Evolutionary Computation, 7:117–132.
