XXIV Simpósio Brasileiro de Banco de Dados XXIII Simpósio Brasileiro de Engenharia de Software Fortaleza, 05 a 09 de Outubro de 2009
Metaheurísticas Aplicadas a Problemas Complexos da Engenharia de Software Dr. Jerffeson Teixeira de Souza GOES.UECE - Grupo de Otimização em Engenharia de Software Universidade Estadual do Ceará
Prazer em conhecer,
Jerffeson Teixeira de Souza Universidade Estadual do Cearรก Professor Adjunto http://goes.comp.uece.br/ prof.jerff@gmail.com
Nosso tempo está dividido desta forma Parte 01 Parte 02 Parte 03 Parte 04 Parte 05
Otimização em Engenharia de Software Introdução a Metaheurísticas Aplicação de Metaheurísticas em Engenharia de Software Considerações Finais Discussões (se o tempo permitir)
XXIV Simpósio Brasileiro de Banco de Dados XXIII Simpósio Brasileiro de Engenharia de Software Fortaleza, 05 a 09 de Outubro de 2009
Metaheurísticas Aplicadas a Problemas Complexos da Engenharia de Software PARTE 01 – OTIMIZAÇÃO EM ENGENHARIA DE SOFTWARE
Espere um minuto. Antes, vamos definir ...
Engenharia de Software
Otimização
Engenharia de Software
“
Disciplina da engenharia que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de especificação até a manutenção desse sistema.
Sommerville
”
Otimização βελτιστοποίησης
Otimização “Otimização consiste em encontrar uma ou mais soluções válidas para um determinado problema que correspondem a valores extremos (ou ótimos) de uma ou mais funções que valoram tais soluções.”
Tipos de Otimização Mono-objetiva Uma única função a ser otimizada Possui uma Ordenação Total Busca uma única solução (ótima)
Multi-objetiva Duas ou mais funções a serem otimizadas Possui uma Ordenação Parcial Busca um conjunto de soluções
f(x)
f(y) ou f(x)
f(y), para todo x e y
Ordenação Total Ordenação Parcial f(x)
f(y), f(x)
f(y) ou (f(x) / f(y) e f(x) / f(y)) para algum x e y
Na Otimização multi-objetiva, o conceito de Dominância substitui o conceito “melhor-pior-igual”
Dominância “Uma solução S1 domina uma solução S2 se S1 é melhor ou igual a S2 em todos os critérios, e estritamente melhor em pelo menos um deles”
EXEMPLO ILUSTRATIVO
Problema Escolher um voo entre São Paulo e Fortaleza, minimizando o custo, que deve ser no máximo de R$ 800,00, e que possua o menor tempo de voo possível.
EXEMPLO ILUSTRATIVO
Tempo de Voo (horas)
2
1
2
3,5
4
6
7
8
Custo (R$)
300,00
700,00
900,00
650,00
400,00
100,00
300,00
600,00
Voos Disponíveis
Problema Escolher um voo entre São Paulo e Fortaleza, minimizando o custo, que deve ser no máximo de R$ 800,00, e que possua o menor tempo de voo possível.
EXEMPLO ILUSTRATIVO
Tempo de Voo (horas)
2
1
2
3,5
4
6
7
8
Custo (R$)
300,00
700,00
900,00
650,00
400,00
100,00
300,00
600,00
Voos Disponíveis Solução Inválida
Problema Escolher um voo entre São Paulo e Fortaleza, minimizando o custo, que deve ser no máximo de R$ 800,00, e que possua o menor tempo de voo possível.
S1 domina S2 1.000,00 900,00 800,00 700,00 600,00 custo() (R$) 500,00 400,00 300,00 200,00 100,00 0,00
S2 S1
0
1
2
3
4
5
6
7
8
9
10
tempo_de_voo() (horas)
Objetivo: Minimizar tempo_de_voo() e custo()
S1 n達o domina S2 e S2 n達o domina S1
1.000,00 900,00 800,00 700,00 600,00 custo() (R$) 500,00 400,00 300,00 200,00 100,00 0,00
S1 S2
0
1
2
3
4
5
6
7
8
9
10
tempo_de_voo() (horas)
Objetivo: Minimizar tempo_de_voo() e custo()
1.000,00 900,00 800,00 700,00 600,00 custo() (R$) 500,00 400,00 300,00 200,00 100,00 0,00
Pior Indiferente Indiferente Melhor
0
1
2
3
4
5
6
7
8
9
10
tempo_de_voo() (horas)
Objetivo: Minimizar tempo_de_voo() e custo()
Soluções Não Dominadas
Soluções Dominadas
1.000,00 900,00 800,00 700,00 600,00 custo() (R$) 500,00 400,00 300,00 200,00 100,00 0,00 0 Frente de Pareto
1
2
3
4
5
6
7
8
9
10
tempo_de_voo() (horas)
Objetivo: Minimizar tempo_de_voo() e custo()
Funções a Minimizar/Maximizar
minimizar f m(x)
m 1,..., M Restrições
sujeito a : g j(x) 0 hk (x) 0 xi
( L)
j 1,..., J
k 1,..., K (U ) x i x i i 1,..., n
Definem as Soluções Válidas
Formulação de Um Problema da Otimização
Resolvendo Problemas Multi-objetivos
1
Métodos à priori Decisor explicita suas preferências antes do processo de busca
2
Métodos à posteriori Decisor explicita suas preferências após o processo de busca
3
Métodos Interativos Decisor explicida suas preferências durante o proceso de busca, guiando o processo iterativamente
1
Métodos à Priori
Atribui-se um peso a cada objetivo, explicitando as preferências do decisor, assim técnicas de otimização mono-objetivo podem ser utilizadas diretamente. n
f ( x)
n
wi f i ( x) i 1
wi
1
i 1
Técnicas de Resolução: Métodos Exatos, Métodos Aproximativos, Heurísticas, Metaheurísticas Mono-objetivas.
2
Métodos à Posteriori
Selecionam um conjunto de soluções não dominadas, que deverão ser analisadas posteriormente pelo decisor. Técnicas de Resolução: Metaheurísticas Multiobjetivas.
Engenharia de Software
Otimização
Otimização em Engenharia de Software
?
Por que, quando e como aplicar. Recapitulando...
Otimização em Engenharia de Software Novo ramo da Engenharia de Software dedicado a resolução automática de problemas complexos dessa área, modelados como problemas de otimização
Otimização em Engenharia de Software = Search-based Software Engineering (SBSE)
Otimização em Engenharia de Software óri
Por que ?
Por que ? Sistemas cada vez mais complexos Abordagens automáticas se tornam cada vez mais necessárias.
Escalabilidade Soluções convencionais sofrem com problemas de escalabilidade em grandes projetos. SBSE é escalável, dado o aumento no poder de processamento.
Independência Resultados são gerados a partir de análises ausentes de qualquer vício ou pré-conceitos.
Otimização em Engenharia de Software óri
Quando ?
Quando ? Problemas Complexos
1: Grande Espaço de Busca 2: Ausência de Solução Ótima Conhecida
Otimização em Engenharia de Software óri
Como ?
Aplicando Otimização em Engenharia de Software Escolha de uma Representação para as soluções do problema
Definição da Função(ões) de Avaliação e das Restrições do problema
Escolha e Aplicação de Algoritmos de Busca
Exemplos de Problemas Complexos em Engenharia de Software Planejamento de Releases Estimativa de Custos Alocação de Pessoal
Exemplos de Problemas Complexos em Engenharia de Software Otimização de Código Fonte Otimização de Projeto Geração, Seleção e Priorização de Casos de Teste
Um Pouco de
Hist贸ria
até 2001 Diversos trabalhos esparsos, especialmente em teste de software, tratam problemas de Engenharia de Software como problemas de busca.
2007 Mark Harman publica o artigo “The Current State and Future of Search Based Software Engineering”.
Maio de 2009 1st International Symposium on Search Based Software Engineering, na cidade de Windsor, UK
2008
2001
Chamada para Edição Especial do periódico IEEE Transactions on Software Engineering em Search-Based Optimization for Software Engineering.
Mark Harman e Bryan Jones introduzem o termo Search-based Software Engineering em um artigo de mesmo nome.
Agosto de 2009 Chamada para Edição Especial do periódico Software—Practice and Experience em Practical Aspects of Search-Based Software Engineering
XXIV Simpósio Brasileiro de Banco de Dados XXIII Simpósio Brasileiro de Engenharia de Software Fortaleza, 05 a 09 de Outubro de 2009
Metaheurísticas Aplicadas a Problemas Complexos da Engenharia de Software PARTE 02 - INTRODUÇÃO A METAHEURÍSTICAS
Metaheurística Combinação de duas palavras gregas: heuriskein, que significa “encontrar”, e o sufixo meta significando “além, em um nível mais alto”.
Refere-se a uma estratégia inteligente de alto nível que guia um processo de busca, explorando eficientemente um espaço de soluções a procura de soluções ótimas ou sub-ótimas.
Discutiremos as seguintes Metaheurísticas Mono-objetivas
Algoritmos Genéticos Têmpera Simulada GRASP
Multi-objetiva
NSGA II
Algoritmos GenĂŠticos
Introdução Método de busca inspirado na Teoria da
Evolução Natural de Charles Darwin Introduzido por John Holland (1975) e popularizado por um dos seus alunos, David Goldberg (1989).
•Naturalista Britânico •1859 – Livro “A Origem das Espécies”
•Conceitos Fundamentais •Evolução é natural •Seleção Natural •Sobrevivências dos mais adaptados •Propagação genética •Mutação
Charles Darwin (1809 – 1882)
procedimento ALGORITMO_GENÉTICO() cria_população_inicial(P); repita P’ ← avaliação_da_população(P); P’’ ← seleção_dos_pais (P); P’ ← recombinação_dos_pais(P’’); mutação(P’’); P ← P’’; enquanto condições de parada não for atingida fim ALGORITMO_GENÉTICO
Pseudocódigo do Algoritmo Genético
Representação Genética Um AG processa populações de cromossomos. Um cromossomo é uma estrutura de dados, geralmente vetor ou cadeia de bits (cadeia de bits é a estrutura mais tradicional, porém nem sempre a melhor), que representa uma possível solução do problema a ser otimizado. O primeiro passo para resolver um problema utilizando AGs é representar uma possível solução deste problema na forma de um cromossomo.
População Inicial Um Algoritmo Genético começa com uma população inicial de N cromossomos.
Essa população pode ser gerada de forma aleatória ou a partir de conhecimentos prévios do problema.
O tamanho da população inicial deve ser determinado de acordo com cada problema.
Seleção
Inspirado no processo de seleção natural de seres vivos.
O AG seleciona os melhores cromossomos (aqueles de alta aptidão) com maior probabilidade para gerar cromossomos filhos (que são variantes dos pais) através dos operadores de cruzamento e mutação.
Métodos de Seleção Método da Roleta • Seleciona um cromossomo com probabilidade proporcional a sua aptidão. Método de Torneio • Seleciona um cromossomo a partir de competições, normalmente envolvendo dois cromossomos.
Cruzamento (ou Crossover) Processo de combinação de dois cromossomos para a geração de dois filhos.
Garante a propagação de material genético.
Respeita uma Taxa de Cruzamento (entre 60 e 90%) determinada a priori.
Métodos de Cruzamento Cruzamento de 1 ponto
• Realiza um corte único de cada cromossomo e combina os materiais genéticos divididos. Cruzamento de 2 pontos • Realize dois cortes, e similarmente combina os materiais genéticos divididos.
Mutação Processo de alteração genética aleatório.
Permite a adição de material genético inédito.
Respeita uma Taxa de Mutação (até 5%) determinada a priori.
Calibragem dos Parâmetros Tamanho da População
Número de Populações
Taxa de Reprodução
Taxa de Mutação
Critério de Parada
Alternativas • • • •
Número de Gerações Qualidade da Solução Ausência de Evolução Tempo
TĂŞmpera Simulada
Introdução Simulação do processo de tratamento térmico de têmpera de um sólido. Aplicação a problemas de otimização, em que a pesquisa pelo mínimo de uma função objetivo corresponderá a procurar o valor mínimo de energia na matéria solidificada após tratamento térmico de têmpera.
Têmpera Real X
Têmpera Simulada Microestados
Soluções viáveis
Energia de um Microestado
Qualidade de uma solução
Perturbação de um Microestado
Transição para uma solução vizinha
Temperatura
Parâmetro de controle
Tempo de arrefecimento
Número de iterações
Microestado de energia mínima
Solução ótima global
procedimento TEMPERA_SIMULADA() s ← GerarSoluçãoInicial() T ← T0 enquanto condições de parada não for atingida faça s’ ← EscolherRandomicamente(N(s)) se (f(s ) < f(s)) então s ← s senão Aceita s’ com probabilidade e -(f(s ) - f(s))/T fim se Atualiza(T) fim enquanto Critério de Metrópolis fim TEMPERA_SIMULADA
Análise do Critério de Metrópolis e
-(f(s ) - f(s))/T
Quanto maior f(s ) - f(s), menor a probabilidade de aceitação
Quanto maior T, maior a probabilidade de aceitação
Calibragem dos Par창metros
Temperatura Inicial
Taxa de Resfriamento
Critério de Parada
Alternativas • • • •
Congelamento Número de iterações sem melhora Número de iterações (soluções visitadas) Qualidade da Solução Tempo
GRASP
Introdução Proposto por Feo e Resende (1995)
Possui duas fases 1. Construcão Encontra uma solução viável utilizando método semiguloso (utiliza fator aleatório)
2. Busca Local Procura o mínimo local a partir da solução obtida na fase Construção
procedimento GRASP() enquanto condições de parada não for atingida faça s ConstruirSolucaoGulosaRandomica() BuscaLocal(s) GuardarMelhorSolucaoEncontrada() fim enquanto fim GRASP
Fase de Construção
Fase de Busca Local
...
...
...
...
...
...
...
Melhor Solução
procedimento GRASP() enquanto condições de parada não for atingida faça s ConstruirSolucaoGulosaRandomica() BuscaLocal(s) GuardarMelhorSolucaoEncontrada() fim enquanto fim GRASP
Fase de Construção ?? de candidatos válidos IniciaComo com lista
Reduz essa lista para uma Lista Restrita de Candidatos (RLC)
Escolhe aleatoriamente um elemento na RLC
procedimento ConstruirSolucaoGulosaRandomica() Solução Inicializar o conjunto dos candidatos C E Avaliar os custos incrementais dos elementos candidatos enquanto Solução não estiver completa faça
cmin min{c(e)|e C} cmax max{c(e)|e C} LRC {e C|c(e) cmin + (cmax – cmin)} Selecionar um elemento s LRC randomicamente Solução Solução {s} Atualizar C Reavaliar os custos incrementais dos candidatos fim enquanto retorne Solução fim ConstruirSolucaoGulosaRandomica
Fase de Construção do GRASP
Análise da LRC LRC
{e
C|c(e)
cmin +
(cmax – cmin)}
varia de 0 a 1
Quando
= 1, LRC = C
Quando
= 0, LRC = {e
C|c(e)
cmin}
Fase de Busca Local Retorna melhor solução da vizinhança
GRASP Reativo Ajuste dinâmico do valor de encontradas
de acordo com as soluções
Conjunto de valores possíveis de
Probabilidade inicial de escolha de cada é igual a 1/ n, onde n é o número de valores possíveis de
NSGA-II
Introdução AG multi-objetivo desenvolvido em Deb et al. (2000)
Utiliza dois algoritmos de ordenação 1. Non-dominated Sorting Algorithm Busca por soluções próximas a Frente de Pareto
2. Crowding Distance Sorting Busca por soluções bem distribuídas no espaço
Crowding Distance Sorting
pop
F1 F2
pop
F3
filhos Rejeitado
Non-Dominated Sorting
Non-dominated Sorting Para cada solução calcula-se quantas outras soluções a dominam e quais soluções são dominadas por ela Faz-se um ciclo no qual a cada iteração são retiradas as soluções que não são dominadas e diminui-se o contador das soluções dominadas por estas que foram retiradas A cada ciclo, uma nova frente é criada com as soluções retiradas do conjunto
Crowding Distance Sorting Utiliza uma função de cálculo de distância entre soluções que estejam no mesmo front para garantir um melhor fitness àquelas que estejam em áreas menos povoadas no espaço de busca. Para cada função objetivo as soluções com valores extremos são classificadas como tendo distância infinita. As outras soluções tem sua distância recalculada de acordo com uma fórmula normalizada que utiliza a diferença de valores para esta solução e as duas mais próximas a ela.
XXIV Simpósio Brasileiro de Banco de Dados XXIII Simpósio Brasileiro de Engenharia de Software Fortaleza, 05 a 09 de Outubro de 2009
Metaheurísticas Aplicadas a Problemas Complexos da Engenharia de Software PARTE 03 - APLICAÇÃO DE METAHEURÍSTICAS EM ENGENHARIA DE SOFTWARE
Roteiro de Aplica莽玫es
Engenharia de Requisitos Problema do Pr贸ximo Release (Mono-objetivo)
Problema do Pr贸ximo Release (Multi-objetivo)
Planejamento de Releases
Roteiro de Aplicações
Alocação de Pessoal Teste de Software Priorização de Casos de Teste
!
ATENÇÃO Notações e formulação serão respeitadas integralmente
Fonte: Bagnall, A., Rayward-Smith, V., e Whittley, I. The Next Release Problem. Information and Software Technology, 43:883-890(8), 2001.
Empresas desenvolvedoras de sistemas complexos para vários clientes precisam determinar quais requisitos serão incluidos no próximo release. Demanda de vários clientes por requisitos individuais Requisitos possuem pré-requisitos
Clientes tem importâncias diferentes Requisitos possuem custo
Problema do Próximo Releases (Mono-Objetivo)
Problema
Selecionar um conjunto de requisitos que possam ser implementados dentro de um orรงamento restrito e que satisfaรงam as demandas de clientes importantes
Problema do Prรณximo Releases (Mono-Objetivo)
Formulação R é o conjunto de requisitos
Cada cliente, i, possui um conjunto de requisitos, Ri indica a importância desse clientes para a empresa
R, e um peso, wi, o qual
Associado com o conjunto R está um grafo G = (R,E), direcionado e acíclico, onde (r,r´)
E sss r é um pré-requisito de r´
Se a empresa decide satisfazer os requisitos do cliente i, ela deve também desenvolver não somente Ri, mas também, parents(Ri), onde parents(Ri) = {r
R | (r,r´)
E , r´ Ri}
Problema do Próximo Releases (Mono-Objetivo)
Formulação R*i = Ri parents(Ri ) contêm todos os requisitos que devem ser implementados para satisfazer o cliente i. Cada r possui um custo associado, cost(r)
Z+
Para um subconjunto de requisitos R´, temos que cost (R´) = ({cost(r)|r R´} Assumindo que a empresa tem n clientes, a tarefa é encontrar um subconjunto de clientes, S {1,2,3,…,n}, cujo requisitos serão satisfeitos
Problema do Próximo Releases (Mono-Objetivo)
Maximização da Importância
Maximizar
wi i S
Restrição de Custo
sujeito a cost
R
*
i
B
i S
Problema do Próximo Releases (Mono-Objetivo)
Resultados
Foram avaliados vários algoritmos (Método Exato, GRASP, Busca Local, Subida em Encosta e Têmpera Simulada) sobre problemas gerados aleatoriamente contendo entre 100 clientes e 140 tarefas e 500 clientes e 3250 tarefas.
No menor dos problemas, o Método Exato se mostrou satisfatório. Enquanto nos outros, a Têmpera Simulada encontrou as melhores soluções com baixo custo computacional, obtendo em médio resultados somente 1.5% piores que os ótimos conhecidos.
Problema do Próximo Releases (Mono-Objetivo)
Fonte: Zhang, Y., Harman, M., e Mansouri, S. A. The multi-objective next release problem. Anais do IX Annual Conference on Genetic and Evolutionary Computation. 2007.
Extensão da formulação anterior
Considera o custo como objetivo, e não como restrição
Problema do Próximo Releases (Multi-Objetivo)
Problema
Selecionar um conjunto de requisitos que possam maximizar o valor total e minimizar o custo requerido.
Problema do Pr贸ximo Releases (Multi-Objetivo)
Formulação Conjunto de clientes, C = {c1, . . .,cm} e conjunto de requisitos, R = {r1, . . .,rm} todos independentes
Cada requisito possui um certo custo, dado por Cost = {cost1, . . .,costm} Cada cliente têm uma importância, dado por Weight = {weight1, . . .,weightm} Cada cliente indica um valor para cada requisito, dado por value(ri,cj), onde value(ri,cj) > 0 se possui esse requisito, ou value(ri,cj) = 0, ao contrário.
A importância total de um requisito ri é dada por scorei=
m j=1 value(ri,cj)
A tarefa é encontrar um vetor de decisão x = {x1, . . .,xn} que o requisito foi selecionado, e 0 que não.
{0,1}, onde 1 indica
Problema do Próximo Releases (Multi-Objetivo)
Maximização da Importância n
Maximizar
scorei xi i 1
Minimização do Custo
n
Maximizar -
costi xi i 1
Problema do Próximo Releases (Multi-Objetivo)
Resultados Foram avaliados vários algoritmos (NSGA-II, Algoritmo Genético de Pareto (Pareto GA), Algoritmo Genético Mono-Objetivo, Busca Randômica) sobre dois problemas de tamanhos variados.
A metaheurística NSGA-II obteve os melhores resultados em todos os casos.
Quando maior o conjunto de teste, maior foi a diferença de desempenho entre o NSGA-II e o Pareto GA, que obteve o segundo melhor resultado nos experimentos.
Problema do Próximo Releases (Multi-Objetivo)
Fonte: Colares, F., Souza, J., Carmo, R., Pádua, C. e Mateus, G. A New Approach to the Software Release Planning. Anais do XXIII Simpósio Brasileiro de Engenharia de Software. 2009.
Extensão da formulação anterior Trata a dependência entre requisitos e risco
Planeja todos os releases, e não somente o próximo Aspectos Considerados
Planejamento de Releases
• Satisfação dos Clientes • Priorização de Requisitos (pelo risco) • Interdependência entre Requisitos • Recursos Limitados
Problema
Distribuir um conjunto de requisitos entre diversos releases com os objetivos de aumentar a satisfação dos clientes e diminuir os riscos do projeto, respeitando a quantidade de recursos disponíveis em cada release e a interdependência entre requisitos.
Planejamento de Releases
Formulação
Conjunto de Requisitos, R = {r1, r2, ..., r|R|} Conjunto de Clientes, S = {s1, s2,..., s|S|}
Conjunto de Releases, K = {k1, k2,..., k|K|} Conjunto de Recursos, P = {p1, p2, ..., p|P|}
Planejamento de Releases
Formulação Cada cliente possui um peso, Weight = {weight1, . . .,weight|S|}
Cada cliente tem uma prioridade para cada requisito, prioritys,r
Cada requisito tem um custo relativo a cada recurso, efforti
Planejamento de Releases
Formulação
Há um valor disponível para cada recurso em cada iteração, Available_resources = {available_resources1, . . .,available_resources iority|K|} Cada requisito tem um risco associado, Risk = {risk1, . . .,risk|R|}
Deseja-se calcular o vetor x = {x1, ..., r|R|}, onde cada xi varia de 1 até |K|, indicando em qual release o requisito i será implementado.
Planejamento de Releases
Maximizar
weights s S r R
Minimizar
prioritys ,r total _ prioritys
risk r xi
K
xi
Maximização da Satisfação
r R
Minimização do Risco
Sujeito a
effortr
available _ resourcesi , i | 1 i
K
r R
xi
x j , (ri
rj )
Restrição de Recursos
Restrição de Precedência
Planejamento de Releases
Resultados A metaheurística NSGA-II foi avaliada sobre um problema com 19 requisitos, 5 releases, 5 clientes e 3 recursos diferentes.
A metaheurística NSGA-II obteve melhores resultado que uma busca aleatória.
Comparado com os resultados gerados por 5 profissionais, o NSGA-II os superou significantemente.
Planejamento de Releases
Fonte: Burdett, G. e Li, R. Quantitative Approach to the Formation of Workgroups. Anais do ACM SIGCPR Conference on Supporting Teams, Groups, and Learning inside and Outside the IS Function: Reinventing IS. 1995
Alocação de pessoas para a execução de uma determinada conjunto de tarefas Considera as preferências e as habilidades de cada pessoa
Alocação de Pessoal
Problema Alocar um conjunto de pessoas a um conjunto de tarefas minimizando o custo salarial, priorizando as habilidades de cada pessoa e respeitando suas preferĂŞncias.
Alocação de Pessoal
P
N
Minimizar
Sal p Aap Dura p 1 a 1 P
S
N
R ps Aap SI s p 1 s 1 a 1 N
P
N
P
Ppa Aap a 1 p 1 N
P
Pmpa Aap a 1 p 1
P
Pp1 p 2 Aap1 Aap2 X p1 p 2 a 1 p1 1 p 2 1
Alocação de Pessoal
Formulação Duração da Atividade a, Dura Tempo de finalização da Atividade a, FTa
Número de instâncias da Habilidade s requeridas para a Atividade a, Isa Peso da performance na função objetivo,
Alocação de Pessoal
Formulação Peso das preferências na função objetiva,
Número total de Atividades, N Número total de Pessoas, P
Preferência da gerência pela Pessoa P na Atividade a, Pma Preferência da Pessoa p pela Atividade a, Ppa
Alocação de Pessoal
Formulação
A Pessoa 1 prefere trabalhar com a Pessoa 2, Pp1p2
Ranking da Pessoa p na Habilidade s, Rps Custo salarial da Pessoa p por unidade de tempo, Salp Importância da Habilidade s, SIs
Tempo de inicialização da Atividade a, STa
Alocação de Pessoal
Onde ...
Aap = 1 se a Pessoa p for alocada para a Atividade a, e 0, caso contrário
Aap1 = 1 se a Pessoa p1 for alocada para a Atividade a, e 0, caso contrário Aap2 = 1 se a Pessoa p2 for alocada para a Atividade a, e 0, caso contrário
Alocação de Pessoal
Onde ...
Das = 1 se a Atividade a demanda a habilidade s, e 0, caso contrário Xp1p2 = 1 se a Pessoa p1 é diferente da pessoa p2, e 0, caso contrário
Alocação de Pessoal
P
N
Minimizar
Sal p Aap Dura p 1 a 1 P
S
Custo Salarial
N
R ps Aap SI s p 1 s 1 a 1 N
P
N
P
Ppa Aap a 1 p 1 N
P
Pmpa Aap a 1 p 1
P
Pp1 p 2 Aap1 Aap2 X p1 p 2 a 1 p1 1 p 2 1
Alocação de Pessoal
P
N
Minimizar
Sal p Aap Dura p 1 a 1 P
S
N
R ps Aap SI s p 1 s 1 a 1
Priorização das Habilidades
N
P
N
P
Ppa Aap a 1 p 1 N
P
Pmpa Aap a 1 p 1
P
Pp1 p 2 Aap1 Aap2 X p1 p 2 a 1 p1 1 p 2 1
Alocação de Pessoal
P
N
Minimizar
Sal p Aap Dura p 1 a 1 P
S
N
R ps Aap SI s p 1 s 1 a 1 N
P
N
P
Ppa Aap a 1 p 1
Priorização das Preferências por Atividades
N
P
Pmpa Aap a 1 p 1
P
Pp1 p 2 Aap1 Aap2 X p1 p 2 a 1 p1 1 p 2 1
Alocação de Pessoal
P
N
Minimizar
Sal p Aap Dura p 1 a 1 P
S
N
R ps Aap SI s p 1 s 1 a 1 N
Priorização das Preferências por Pessoas
P
N
P
Ppa Aap a 1 p 1 N
P
Pmpa Aap a 1 p 1
P
Pp1 p 2 Aap1 Aap2 X p1 p 2 a 1 p1 1 p 2 1
Alocação de Pessoal
Resultados A metaheurística Têmpera Simulada foi avaliada sobre dados gerados aleatoriamento contendo 10, 20, 50 e 100 pessoas, onde foram selecionadas equipes de 5 ou 10 pessoas. A solução ótima foi encontrado pela Têmpera Simulada para equipes de 5 pessoas de um total de 10, 20, 50 e 100 pessoas, com baixo custo computacional. Para equipes de 10 pessoas, como as soluções ótimas não eram conhecidas, os resultados obtidos pela Têmpera Simulada não puderam ser avaliados.
Alocação de Pessoal
Fonte: Maia, C. , Carmo, R., Campos, G. e SOUZA, J. A Reactive GRASP Approach for Regression Test Case Prioritization. Anais do XL Simpósio Brasileiro de Pesquisa Operacional. 2008.
Modificações em um software pode causar problemas em outras funcionalidades Re-testar todo o software pode ser inviável
A ordenação de casos de teste permite a seleção de um subconjunto destes Um caso de teste é avaliado pela quantidade de erros que ele encontra
Calcular esse valor é impossível sem executar o caso de teste
Priorização de Casos de Teste
Métricas de cobertura (de bloco, de linhas de comando e de decisão) são utilizadas
Problema Ordenar os casos de teste de forma que somente um subconjunto de casos de teste possa ser executado, com somente pequena, ou nenhuma, perda de efetividade.
Priorização de Casos de Teste
Formulação Suíte de testes, T, com n casos de teste que cobre um conjunto B de m blocos de código Seja TBi o primeiro caso de teste na ordem T´, de T, que cobre o bloco i. A métrica APBC (Average Percentage Block Coverage) para a ordem T´ é dada por 1 – (TB1 + TB2 + ... + TBm)/nm + 1/2n As métricas APDC (Average Percentage Decision Coverage) e APSC (Average Percentage Statement Coverage) são calculadas de forma similar
Priorização de Casos de Teste
1
Casos de Teste
Entendendo a Métrica APBC
Blocos 2
3
A
X
B
X
X
X
C
X
X
X
4
5
6
7
8
9
10
X
X
X
X
X
D
X
X X
X
X
X
E
Percentual de Cobertura de Blocos
Ordenação T1: A – B – C – D – E 100 90 80 70 60 50 40 30 20 10 0
APBC = 46% 0,0
0,2
0,4
0,6
0,8
1,0
Fração do Suíte de Teste
Priorização de Casos de Teste
1
Casos de Teste
Entendendo a Métrica APBC
Blocos 2
3
A
X
B
X
X
X
C
X
X
X
4
5
6
7
8
9
10
X
X
X
X
X
D
X
X X
X
X
X
E
Percentual de Cobertura de Blocos
Ordenação T1: C – E – B – A – D 100 90 80 70 60 50 40 30 20 10 0
APBC = 82% 0,0
0,2
0,4
0,6
0,8
1,0
Fração do Suíte de Teste
Priorização de Casos de Teste
Maximizar APBC
Priorização de Casos de Teste
Resultados A metaheurística GRASP Reativo foi comparada com os métodos Guloso, Guloso Adicional e Algoritmo Genético. Foram usados 5 programas de tamanhos variados, onde foram avaliadas as métricas APBC, APDC e APSC. O algoritmo Guloso Adicional teve o melhor desempenho de todos, superando significantemente o método Guloso e Algoritmo Genético, que surpreendentemente obteve a pior performance de todos.
O GRASP Reactivo obteve o segundo melhor resultado, gerando resultados insignificantemente piores do que o Guloso Adicional. Não foram encontradas diferenças de performance nas diferentes métricas.
Priorização de Casos de Teste
XXIV Simpósio Brasileiro de Banco de Dados XXIII Simpósio Brasileiro de Engenharia de Software Fortaleza, 05 a 09 de Outubro de 2009
Metaheurísticas Aplicadas a Problemas Complexos da Engenharia de Software PARTE 04 - CONSIDERAÇÕES FINAIS
Considerações Finais
A Otimização em Engenharia de Software (Search-based Software Engineering) se apresenta como novo ramo de pesquisa da Engenharia de Software.
Tem alcançado um crescente interesse mundial (ver slide a seguir), e gerado resultados relevantes rapidamente, especialmente por combinar conhecimentos consolidados. Muito ainda precisa ser feito no sentido de popularização desses resultados fora do meio acadêmico.
Histórico de Publicações em SBSE 100 90 80 70 60 50 40 30 20 10 0
FONTE: SEBASE
Pesquisa em Otimização em Engenharia de Software Novos Problemas Geração de novas formulações para problemas da engenharia de software. Extensão de formulações existentes . Tratamento multi-objetivo para formulações monoobjetivas.
Novas Abordagens Aplicações de novos métodos de busca em problemas existentes. Estudos comparativos de técnicas de busca.
Competitividade Humana Análise da competitividade dos resultados gerados automaticamente em comparação com resultados produzidos por humanos.
Pesquisa em Otimização em Engenharia de Software Análise de Sensibilidade Avaliação da influência de variáveis na qualidade de resultados gerados e na dificuldade de resolver certos problemas.
Otimização Interativa Estratégias de incorporação do julgamento humano durante o processo de otimização.
Hibridização Combinação de métodos na geração de abordagens mais eficientes.
Oportunidades Cooperação O Grupo de Otimização em Engenharia de Software (GOES.UECE) está a disposição.
Divulgação/Aprendizado 2nd International Symposium on Search Based Software Engineering, em Setembro de 2010 na Cidade de Benevento, Itália
1o Workshop Brasileiro de Otimização em Engenharia de Software, em conjunto com o SBES´2010 (a confirmar)
Chegamos ao fim! Obrigado pelo tempo e pela atenção.
Chegamos ao fim! Obrigado pelo tempo e pela atenção.
XXIV Simpósio Brasileiro de Banco de Dados XXIII Simpósio Brasileiro de Engenharia de Software Fortaleza, 05 a 09 de Outubro de 2009
Metaheurísticas Aplicadas a Problemas Complexos da Engenharia de Software
prof.jerff@gmail.com http://goes.comp.uece.br/ Universidade Estadual do Ceará GOES.UECE - Grupo de Otimização em Engenharia de Software