Uma Análise Experimental de Algoritmos
Metaheurísticos para um Problema de Caminho
mais Curto Multiobjetivo na Computação em Nuvem.
Natal - Rio Grande do Norte - Brasil 05/08/2013
Uma Análise Experimental de Algoritmos
Metaheurísticos para um Problema de Caminho
mais Curto Multiobjetivo na Computação em Nuvem.
Orientador(a):
Elizabeth Ferreira Gouvêa Goldbarg
UNIVERSIDADE FEDERAL DO RIOGRANDE DONORTE (UFRN) DEPARTAMENTO DEINFORMÁTICA E MATEMÁTICAAPLICADA (DIMAP)
Natal - Rio Grande do Norte - Brasil 05/08/2013
Orientador(a): Elizabeth Ferreira Gouvêa Goldbarg
Uma Análise Experimental de Algoritmos
Metaheurísticos para um Problema de
Caminho mais Curto Multiobjetivo na
Computação em Nuvem.
Dissertação de mestrado apresentado à Univer-sidade Federal do Rio Grande do Norte, como requisito parcial para a obtenção do grau de Mestre em Sistemas e Computação. Área de concentração: Algoritmos Experimentais
Natal - Rio Grande do Norte - Brasil 05/08/2013
À Hayala Glenda que sem dúvida nenhuma este trabalho é mais dela do que de qualquer outra pessoa. Obrigado por tudo.
À Deus por toda a energia necessária,
À Margarida Menezes por guiar tão bem o meu caminho,
Às mulheres da minha vida Iranilde, Larissa e Hayala por tudo, amo muito vocês. À Laise Cronembeger por todas as horas de conversas e conselhos,
Aos amigos,
Ao Wagner e Leonardo por todas as co-orientações,
Ao Ernesto, Romerito, Camila, Sidney, Ítalo, Simone pela amizade durante essa jornada. À professora Elizabeth por todas as orientações, conversas e conselhos.
Aos professores Thomé, Goldbarg, Thays e Iloneide por todas as sugestões fundamentais na melhoria deste trabalho.
Da janela de um arranha-céu.
Sem ter que sujar as mãos, Sem ter nada a perder, Sem o risco de pagar pelos erros que cometeu.
Coração Blindado Engenheiros do Hawaii
modelado como um Problema de Caminho Mais Curto Multiobjetivo. Uma vez que este último pertence à classe NP-difícil, mesmo para o caso onde apenas dois objetivos são considerados, não existem algoritmos exatos eficientes para o problema. É proposto, então, um algoritmo transgenético, uma vez que a técnica já tem sido aplicada com sucesso a outros problemas mul-tiobjetivo. O algoritmo proposto é comparado ao NSGA-II, um algoritmo evolucionário multi-objetivo proposto na literatura e que é reconhecido como uma boa abordagem. São utilizados testes estatísticos para avaliar os resultados produzidos pelas abordagens investigadas.
Palavras Chaves: Multiobjetivo, Caminho Mais Curto, Computação em Nuvem, Transge-nético.
This paper investigates a problem inherent to Cloud Computing which can be modeled as a Multiobjective Shortest Path Problem. Since the latter belongs to class NP-Hard, even in the case where only two objectives are considered, not exist exact algorithms efficient for the problem. It is proposed, therefore, an algorithm Transgenético, since the technique has already been successfully applied to other multiobjective problems. The proposed algorithm is compared to the NSGA-II, an multiobjective evolutionary algorithm proposed in the literature and is recognized as a good approach. Statistical tests are used to evaluate the results produced by the approaches investigated.
2.1 Ilustração do Cloud Integrator como mediador entre diferentes plataformas
de nuvem e aplicações (BATISTA et al., 2012). . . p. 19 3.1 Soluções Suportadas e Não Suportadas (RAITH; EHRGOTT, 2009) . . . p. 23 3.2 Exemplo de grafo direcionado acíclico representando um workflow com
di-ferentes opções de planos de execução (CAVALCANTE et al., 2011). . . p. 25 3.3 Workflowcom seis planos de execução. (CAVALCANTE et al., 2011). . . p. 26 3.4 Workflowsdo Cloud Integrator modelados como um problema de Caminho
Mais Curto . . . p. 27 3.5 Classificação dos Algoritmos Exatos para o Caminho Mais Curto Biobjetivo
(BSP) (SKRIVER, 2000). . . p. 28 4.1 Patamar . . . p. 35 4.2 Exemplo de execução do Plasmídeo . . . p. 36 4.3 Exemplo de execução do Transposon . . . p. 37 5.1 Exemplo de um caso de teste usado nos experimentos. . . p. 39 5.2 Mediana dos Hypervolumes para as 3 melhores configurações do Transgenético p. 45 5.3 Mediana dos Hypervolumes do Transgenético com e sem o LOGOS do
NSGA-II . . . p. 47 5.4 Vioplot para os casos de testes com 200 camadas. . . p. 48 5.5 Mediana dos Hypervolumes do Transgenético com LOGOS e do LOGOS . . p. 49 C.1 Ordenação por Não-Dominância da População do NSGA-II (DEB et al., 2000) p. 62 D.1 Exemplo de uma iteração da 3Logos . . . p. 65 A.1 Vioplot para os casos de testes com 005 camadas. . . p. 70 A.2 Vioplot para os casos de testes com 010 camadas. . . p. 70
A.4 Vioplot para os casos de testes com 020 camadas. . . p. 71 A.5 Vioplot para os casos de testes com 025 camadas. . . p. 72 A.6 Vioplot para os casos de testes com 050 camadas. . . p. 72 A.7 Vioplot para os casos de testes com 100 camadas. . . p. 73 A.8 Vioplot para os casos de testes com 200 camadas. . . p. 73
3.1 Relações de Dominância entre Soluções (KNOWLES; THIELE; ZITZLER,
2006) . . . p. 23 5.1 Configurações do NSGA-II. Sendo Con o número da configuração, P o
tama-nho da população, G o número de gerações, C a taxa de crossover e M a taxa
de mutação . . . p. 42 5.2 Teste de Mann-Whitney entre as três configurações do NSGA-II. . . p. 42 5.3 Tempo Médio de execução das configurações 77, 79 e 81 do NSGA-II por
caso de teste. Os valores em negrito indicam os menores tempos de execução
por caso de teste. . . p. 43 5.4 Configurações do Transgenético. Sendo Con o número da configuração, P o
tamanho da população e I o número de iterações. . . p. 43 5.5 Teste de Mann-Whitney entre as três configurações no Transgenético . . . p. 44 5.6 Tempo Médio de execução das configurações 6, 7 e 8 do Transgenético por
caso de teste. . . p. 45 5.7 Algoritmo de Martins com três objetivos sendo avaliados . . . p. 46 5.8 Média do tempo de execução dos algoritmos . . . p. 48 5.9 Porcentagem dos Hypervolumes calculados com base no algoritmos de
Mar-tins para o Transgenético com e sem o LOGOS e o NSGA-II nos casos de
testes com 5 a 25 camadas . . . p. 50 E.1 Os Blocos e Tratamentos do Teste de Friedman . . . p. 66
4.1 Pseudo Código do Algoritmo Transgenético Genérico . . . p. 33 4.2 Pseudo Código do Algoritmo Transgenético . . . p. 34 B.1 Algoritmo de Martins . . . p. 60 C.1 Pseudo Código do NSGA-II . . . p. 63 D.1 Pseudo Código do 2Logos . . . p. 64 D.2 Pseudo Código do 3Logos . . . p. 65
Resumo Abstract 1 Introdução p. 13 1.1 Contextualização e Motivação . . . p. 13 1.2 Objetivos e Contribuições . . . p. 14 1.3 Objeto de Estudo . . . p. 15 1.4 Procedimentos Metodológicos . . . p. 15 1.5 Organização do Trabalho . . . p. 16
2 Computação em Nuvem e Cloud Integrator p. 17
3 O Problema de Planejamento no Workflow p. 21 3.1 Caminho Mais Curto Multiobjetivo . . . p. 21 3.1.1 Conceitos básicos em Otimização Multiobjetivo . . . p. 22 3.2 Modelagem . . . p. 24 3.3 Revisão Bibliográfica . . . p. 27 4 Transgenética Computacional p. 32 4.1 Terminologia . . . p. 32 4.2 Algoritmo Transgenético . . . p. 33 5 Experimentos e Resultados p. 38 5.1 Casos de Testes . . . p. 39
5.3 Afinação de Parâmetros . . . p. 40 5.3.1 NSGA-II . . . p. 41 5.3.2 Transgenético . . . p. 41 5.4 Resultados Finais . . . p. 44 5.4.1 Resultados do Algoritmo Exato . . . p. 46 5.4.2 Transgenético com LOGOS e sem LOGOS X NSGA-II . . . p. 47 5.4.3 Teste do Transgenético com LOGOS e do LOGOS . . . p. 49 5.4.4 Exato X Heurísticos . . . p. 49
6 Conclusões p. 51
Referências Bibliográficas p. 52
Anexo A -- Hypervolume p. 58
Anexo B -- Algoritmo Exato p. 60
Anexo C -- NSGAII p. 62
Anexo D -- LOGOS p. 64
Anexo E -- Teste de Friedman p. 66
Anexo F -- Teste de Mann-Whitney p. 68
1
Introdução
Este trabalho investiga um problema inerente da Computação em Nuvem modelado como um Problema de Caminho Mais Curto Multiobjetivo. É proposto, então, um algoritmo transge-nético, uma vez que a técnica já tem sido aplicada com sucesso a outros problemas multiobje-tivo. O algoritmo proposto é comparado ao NSGA-II, um algoritmo evolucionário multiobjetivo proposto na literatura e que é reconhecido como uma boa abordagem. São utilizados testes es-tatísticos para avaliar os resultados produzidos pelas abordagens investigadas. Este capítulo in-trodutório está organizado em cinco seções que descrevem respectivamente: a contextualização e motivação, o objetivo e as contribuições, o objeto de estudo, os procedimentos metodológicos e a organização geral desta dissertação.
1.1
Contextualização e Motivação
A Computação em Nuvem revolucionou a tecnologia da informação. O seu modelo de negócio de pagar pelo uso fez com que recursos computacionais deixassem de ser produtos e virassem serviços (BUYYA et al., 2009). Com o avanço da Computação em Nuvem, novos leques de problemas e desafios apareceram. Apesar da Computação em Nuvem propiciar be-nefícios ausentes nas tecnologias atuais, como a alta escalabilidade, a mesma ainda está em ascensão e um dos principais desafios está na composição de serviços providos por plataformas distintas (CAVALCANTE, 2013). Criado pelo grupo de Sistemas Distribuídos da Universidade Federal do Rio Grande do Norte, o Cloud Integrator é uma arquitetura para gerenciar a agrega-ção dos serviços providos em plataformas diversas (CAVALCANTE et al., 2011). Cada serviço de nuvem possui vários atributos que o qualificam como, por exemplo, preço e tempo de res-posta. Dentre as várias possibilidades de utilização de provedores e serviços existentes, como escolher, dados os atributos desejados, a composição de serviços que seja a melhor possível? Uma forma de resolver tal problema se dá através de uma investigação científica criteriosa. Este trabalho propõe que tal investigação seja realizada através de técnicas de Otimização Combina-tória. Neste trabalho o problema do planejamento de execução dos serviços na nuvem, chamado
de planejamento de workflow, é modelado como um problema de caminho mais curto em grafos onde vários critérios são considerados simultaneamente.
O problema de encontrar o caminho mais curto entre dois vértices de um grafo simples considerando k objetivos pertence à classe dos problemas NP-difíceis para k > 1 conforme de-monstrado por (HANSEN, 1980). Deste modo, embora existam algoritmos polinomiais que resolvam o problema para o caso onde apenas um objetivo é considerado, o mesmo não ocorre para o caso geral. Neste caso, os pesquisadores costumam utilizar técnicas baseadas em me-taheurísticas para lidar com tais problemas. A área de meme-taheurísticas para problemas multi-objetivo têm crescido nos últimos anos com a publicação de diversos trabalhos no tema, sendo os Algoritmos Evolucionários uma das principais abordagens como pode ser observado na re-visão de (COELLO, 2001). Dentre as abordagens evolucionárias, se encontra a Transgenética Computacional, proposta por (GOUVÊA, 2001), desenvolvida pelo grupo de Algoritmos Expe-rimentais da Universidade Federal do Rio Grande do Norte. Esta técnica foi a escolhida para o desenvolvimento de algoritmos heurísticos deste trabalho por ter apresentado resultados satis-fatórios no contexto de problemas de Otimização Combinatória com múltiplos objetivos como os apresentado em (ALMEIDA; DELGADO; GOLDBARG, 2012).
1.2
Objetivos e Contribuições
O objetivo geral deste trabalho é apresentar um método heurístico baseado na metaheurís-tica Transgenémetaheurís-tica Computacional para o problema de planejamento de serviços disponibiliza-dos na nuvem em plataformas diferentes considerando múltiplos objetivos.
Os objetivos específicos deste trabalho são:
• Modelar o problema real de planejamento da composição de serviços do Cloud Integrator como um problema de caminho mais curto multiobjetivo em grafos.
• Implementar um algoritmo baseado na Transgenética Computacional para o problema de composição de serviços do Cloud Integrator, considerando múltiplos objetivos simulta-neamente.
• Analisar, experimentalmente, as técnicas desenvolvidas através de sua aplicação e com-paração com métodos propostos anteriormente, de forma a concluir sobre suas potencia-lidades.
1.3
Objeto de Estudo
O módulo de composição de serviços do Cloud Integrator com algumas adaptações pode ser modelado como um Problema de Caminho Mais Curto Multiobjetivo. O Problema do Caminho Mais Curto consiste em encontrar o menor caminho entre vértices de origem e destino em um grafo ponderado em arestas. Em sua versão multiobjetivo, o problema pertence à classe NP-difícil (HANSEN, 1980) e, portanto, serão propostos algoritmos heurísticos para o mesmo. Tais algoritmos serão comparados a outros propostos na literatura, tendo seu desempenho avaliado segundo metodologia estatística.
O foco deste trabalho é abordar o problema de composição de serviços do Cloud Integrator levando em consideração uma abordagem multiobjetivo. Isto será feito através da modelagem do problema utilizando uma generalização do problema de caminho mais curto, tal generaliza-ção consiste em utilizar múltiplas funções objetivos que representam cada objetivo que se quer otimizar.
1.4
Procedimentos Metodológicos
Este trabalho utiliza abordagem prática e reporta a realização de experimentos computa-cionais que comparam o desempenho dos algoritmos desenvolvidos e a qualidade das solu-ções encontradas. Todos os algoritmos foram implementados na linguagem de programação C+ + versão 11. Para a o experimento computacional foi criado um conjunto de casos teste de acordo com parâmetros obtidos do problema prático da aplicação em nuvens fornecidos pelo grupo de Sistemas Distribuídos da Universidade Federal do Rio Grande do Norte. Os casos de testes foram organizados em 14 grupos que serão descritos posteriormente. Para execu-ção dos experimentos, apenas uma máquina foi utilizada com processador Intel(R)X eon(R) CPU X3430@2.40GHz e com 9, 7GB de memória RAM. Foram considerados dois critérios bá-sicos de comparação, o tempo computacional utilizado para o funcionamento do algoritmo e a qualidade das soluções encontradas. Foram utilizados os testes estatísticos de Friedman (Apên-dice E) e de Mann-Whitney (Apên(Apên-dice F). Os testes estatísticos foram implementados em R, um software estatístico livre (TEAM, 2012). A metodologia dos experimentos é descrita com
maiores detalhes no capítulo 5, onde são relatados os testes.
1.5
Organização do Trabalho
Este trabalho está organizado da seguinte maneira:
O Capítulo 2 contém os conceitos introdutórios sobre a computação em nuvem e sobre o Cloud Integrator. O Capítulo 3 apresenta o problema de planejamento do workflow, sua mode-lagem por meio do caminho mais curto multiobjetivo e uma revisão bibliográfica dos métodos propostos na literatura. O Capítulo 4 apresenta o algoritmo heurístico implementado neste tra-balho, chamado de Transgenético. Os experimentos computacionais realizados e os resultados obtidos neste trabalho se encontram no Capítulo 5. O Capítulo 6 contém as considerações finais, as conclusões inferidas pelos resultados encontrados e sugestões para os trabalhos futuros.
2
Computação em Nuvem e Cloud
Integrator
Computação em Nuvem é um conceito simples que emergiu de computação distribuída, computação em grade (grid computing), computação utilitária (utility computing) e computa-ção autonômica (autonomic computing). Segundo a Wikipedia (2013) computacomputa-ção em nuvem é o uso de recursos computacionais (hardware e/ou software) providos como serviços sobre uma rede que normalmente é a internet. Buyya et al. (2009) apresentam um resumo das pesquisas realizadas na área da Computação em Nuvem, bem como algumas tendências. O artigo examina as pesquisas desenvolvidas até então, fazendo uma revisão dos principais paradigmas promisso-res para a computação em nuvem se tornar o quinto serviço básico da humanidade. Os autopromisso-res propõem uma arquitetura orientada a mercado para alocação de recursos dentro das nuvens, apresentando uma visão para a criação de intercâmbio entre nuvens e os serviços comerciais.
O paradigma da computação em nuvem pode oferecer qualquer tipo concebível de serviços, tais como recursos computacionais para aplicações de alto desempenho, serviços web, redes sociais, e serviços de telecomunicações. Por esse motivo, os serviços na computação em nuvem podem ser agrupados em, no mínimo, cinco tipos de serviços (SHAN, 2009):
• IaaS - Infrastructure as a Service ou Infraestrutura como Serviço: quando se utiliza uma porcentagem de um servidor, geralmente com configuração que seja compatível com a sua necessidade.
• PaaS - Plataform as a Service ou Plataforma como Serviço: utilizando-se apenas uma plataforma como um banco de dados, um web-service, o ambiente de execução de alguma linguagem, etc.
• DaaS - Development as a Service ou Desenvolvimento como Serviço: as ferramentas de desenvolvimento tomam forma na computação em nuvem como ferramentas comparti-lhadas, ferramentas de desenvolvimento baseados na web.
• SaaS - Software as a Service ou Software como Serviço: uso de um software em regime de utilização web (p.ex.: Google Docs).
• EaaS - Everything as a Service ou Tudo como Serviço: quando se utiliza tudo, infra estrutura, plataformas, software, suporte, etc como um Serviço.
Cada tipo de serviço é disponibilizado por um provedor. Com o grande crescimento da com-putação em nuvem, vários provedores surgiram como Amazon AWS, Microsoft Azure, Google App Engine, Google Compute Engine, Rackspace, Heroku, entre outros. Cada provedor possui sua própria camada de comunicação ou API (Application programming interface) fazendo com que as aplicações sejam específicas para cada provedor. Por conta desta diversidade é difícil desenvolver uma aplicação que execute nas diversas nuvens existentes. A literatura apresenta poucas propostas para lidar com o problema da composição de serviços no contexto da Com-putação em Nuvem, dentre eles estão os trabalhos apresentados por Zeng et al. (2009), Höing (2010) e Pandey, Karunamoorthy e Buyya (2011). Conforme Cavalcante et al. (2011) tais abor-dagens consideram o problema apenas sob o ponto de vista da funcionalidade do serviço, não levando em consideração a seleção dos serviços para a composição com base em dados de quali-dade do serviço. Além disso, eles não levam em consideração a heterogeneiquali-dade dos ambientes de Computação em Nuvem, de forma que não permitem o acesso a diferentes plataformas de um modo transparente.
Com o objetivo de criar uma camada intermediária, transparente e homogênea para integra-ção de diversos serviços existentes em diferente provedores, o Cloud Integrator foi criado.
O Cloud Integrator é uma plataforma de middleware para composição, execução e gerenci-amento de serviços providos por diferentes plataformas de Computação em Nuvem (BATISTA et al., 2011b). O mesmo integra serviços de nuvem de modo transparente e automático pro-movendo um ambiente que facilita o desenvolvimento e a execução de aplicações que estão inseridas na computação em nuvem. O Cloud Integrator é uma plataforma orientada a serviços baseada em SOA (Service-Oriented Architecture) ou Arquitetura Baseada em Serviço.
Conforme ilustrado na Figura 2.1 o Cloud Integrator realiza a mediação entre diferentes arquiteturas e serviços de nuvem, agindo como uma camada intermediária.
Na computação em nuvem o conceito de serviço é muito importante, pois serviços em nuvem vão além de simples operações, podendo ser aplicações de software, plataformas ou mesmo infraestruturas computacionais quase inteiras (BATISTA et al., 2012). No contexto do Cloud Integratorexistem dois tipos de serviços:
Figura 2.1: Ilustração do Cloud Integrator como mediador entre diferentes plataformas de nu-vem e aplicações (BATISTA et al., 2012).
i recursos como serviços (ou simplesmente recursos de nuvem), que dizem respeito a recur-sos propriamente ditos providos como serviços por plataformas de nuvem, como serviços de processamento, armazenamento, banco de dados, etc.
ii serviços de aplicação que se caracterizam como serviços de terceiros implantados em plataformas e que usam seus recursos subjacentes (máquinas virtuais, bancos de dados, serviços de armazenamento, etc.), como serviços de pagamento via cartão de crédito, aplicações de armazenamento na nuvem, etc.
Outro conceito fundamental para o entendimento do Cloud Integrator é Workflows Semân-ticos. Um workflow semântico é uma representação abstrata de um fluxo de trabalho ou exe-cução. Um Workflow é composto por uma sequência de atividades que devem ser executadas para atender algum objetivo de negócio da aplicação (BATISTA et al., 2012). Cada atividade de um workflow é especificada pelo par <tarefa, objeto> (e.g. <armazenar, arquivo>, <enviar, mensagem>, etc). Uma tarefa é uma operação implementada por um ou mais serviços. Um objeto pode ser usado para descrever as entradas, saídas ou pré-condições relacionadas a uma tarefa. Para a execução de um workflow, o Cloud Integrator realiza várias inferências usando a especificação do workflow e os serviços Web semânticos como base, para então criar a compo-sição de serviços, identificando que serviços devem ser selecionados para satisfazer o objetivo
de negócio do workflow (BATISTA et al., 2012).
Para que um workflow seja executado é preciso primeiro gerar um plano de execução, que contém um conjunto de serviços web concretos que são orquestrados através da execução dos mesmos em uma ordem particular (BATISTA et al., 2012). O número de planos de execução possíveis é influenciado pela quantidade de serviços disponíveis com a mesma funcionalidade no ambiente (em um dado momento). O problema do planejamento da execução de serviços pode ser modelado como um problema de Otimização Combinatória, especificamente como o problema do caminho mais curto multiobjetivo que será descrito e no Capítulo 3.
Além do problema tratado neste trabalho, diversas pesquisas modelaram problemas de Computação em Nuvem como problemas de otimização, grande parte delas direcionando-se a mecanismos de alocação de recursos e uma melhor utilização de energia por parte dos cen-tros de dados. Vinek, Beran e Schikuta (2011) apresentaram um Algoritmo Genético para o problema da seleção de instalações distribuídas em um ambiente heterogêneo, onde vários ser-viços web e banco de dados de grupos de pesquisa ao redor do mundo são usados para executar diversas tarefas. Um modelo de fornecimento de máquinas virtuais com consumo de ener-gia adaptativo utilizando inteligência de coletiva é apresentado por Jeyarani, Nagaveni e Ram (2011). No trabalho de Beloglazov, Abawajy e Buyya (2011), são propostas heurísticas para alocação de recursos com energia consciente para gerenciamento eficiente dos centros de dados para Computação em Nuvem. Um modelo flexível de seleção de serviços com suporte a requi-sitos dos usuários em uma arquitetura orientada a serviços é apresentado no trabalho de Zhao et al. (2011). Yan-hua, Lei e Zhi (2011) apresentam uma combinação entre um Algoritmo Gené-tico e uma Colônia de Formigas para otimização de agendamento de rotas em banco de dados em nuvem. Mazzucco e Dyachuk (2011) propõem uma otimização das receitas dos provedores de Computação em Nuvem através da alocação de servidores visando um consumo de energia eficiente.
3
O Problema de Planejamento no
Workflow
Este capítulo detalha o problema de otimização combinatória no planejamento de Workflows do Cloud Integrator que foi modelado como um Problema de Caminho Mais Curto Multiobje-tivo. O capítulo está organizado em três seções. Na primeira é descrito o Problema do Caminho Mais Curto Multiobjetivo. Para isto, alguns conceitos básicos na área são apresentados. A modelagem do problema real investigado neste trabalho como um Problema de Otimização Combinatória é descrita na seção 3.2. Finalmente, é apresentado um estado-da-arte no que se refere a algoritmos para o Problema do Caminho Mais Curto Multiobjetivo.
3.1
Caminho Mais Curto Multiobjetivo
O Caminho Mais Curto é um problema clássico com aplicação em diversas áreas do co-nhecimento, dentre elas a Computação e a Pesquisa Operacional. Sua definição consiste na otimização(minimização) dos custos associados à travessia de um grafo entre dois nós ou vér-tices, também chamado de ponto-a-ponto. O custo, na maioria das vezes, é dado pela soma dos pesos atribuídos aos vértices que fazem parte do caminho entre o vértice inicial e o destino. Vá-rios algoritmos polinomiais são encontrados na literatura (TARAPATA, 2007) para o problema em sua versão mono-objetivo, como por exemplo o algoritmo de Dijkstra (DIJKSTRA, 1959), Bellman-Ford (BELLMAN, 1958) (FORD, 1956) e Floyd-Warshall (FLOYD, 1962). Cada um desses algoritmos possui uma utilização específica, por exemplo o algoritmo de Dijkstra re-solve o problema com um vértice-fonte em grafos cujas arestas tenham pesos positivos, já o algoritmo de Bellman-Ford não possui a restrição dos pesos negativos, mas por outro lado pos-sui uma complexidade maior do que o algoritmo de Dijkstra. O algoritmo de Floyd-Warshall encontra o menor caminho entre todos os vértices do grafo e não apenas entre dois vértices.
Os algoritmos de Caminho Mais Curto são aplicados para encontrar automaticamente as direções entre localizações, tais como as instruções de como chegar em um destino. Outras
aplicações incluem pesquisas em disposição das instalações de fábricas, robótica, transporte e até planejamento de rotas militares (TARAPATA, 2007).
A abordagem multiobjetivo produz uma representação mais próxima ao problema real em muitas situações. Algumas das aplicações descritas anteriormente possuem vários objetivos a serem otimizados. Por exemplo, o Google Maps utiliza não apenas a menor distância entre a origem e destino mas também uma estimativa do tempo necessário entre origem e destino onde, dependendo das condições de tráfego e/ou o tipo da via utilizada (asfaltada ou pavimenta), esses objetivos podem ser conflitantes. Ao contrário da versão mono-objetivo, o problema pertence à classe NP-difícil em sua versão multiobjetivo (HANSEN, 1980).
Nos problemas multiobjetivo dificilmente existe uma solução que seja melhor que todas as outras possíveis para todos os objetivos avaliados. Geralmente, o que se encontra são soluções que possuem vantagens e desvantagens entre si (BEZERRA, 2011) de forma que uma solução não é preferível às outras em todos os critérios.
3.1.1
Conceitos básicos em Otimização Multiobjetivo
min/max f (x) = ( f1(x), . . . , fn(x) (3.1)
su jeito a:
gj(x) ≥ 0 j= 1, . . . , J (3.2)
hp(x) ≤ 0 p= 1, . . . , P (3.3)
lin fj≤ xi≤ lsupi i= 1, . . . , n (3.4)
Um problema multiobjetivo pode ser formulado de modo geral como descrito na formula-ção abaixo (3.1 – 3.4). Uma soluformula-ção x é um vetor de n variáveis de decisão x = (x1, . . . , xn)T .
O último conjunto de restrições, 3.4, dá os limites de cada variável. Estes limites constituem o espaço de decisão das variáveis. A região viável é definida pela união das restrições definidas em 3.2 e 3.3.
Dominância z1≺ z2 z1não é pior que z2em todos os k objetivos e é melhor em
pelo menos um objetivo
Dominância Fraca z1 z2 z1não é pior que z2em todos os k objetivos
Incomparável z1|| z2 nem z1 z2nem z2 z1
Indiferente z1~ z2 z1tem os mesmos valores que z2em todos os k objetivos Quadro 3.1: Relações de Dominância entre Soluções (KNOWLES; THIELE; ZITZLER, 2006)
O conjuntos de vetores objetivos das soluções pertencentes ao Pareto-ótimo é nomeado de Fronteira de Pareto. O que se busca encontrar nos problemas multiobjetivo é o conjunto Pareto-ótimo ou uma aproximação do mesmo. O conjunto Pareto-ótimo é o conjunto de todas as soluções que são não dominadas em relação a quaisquer outras soluções possíveis (KNOWLES; THIELE; ZITZLER, 2006).
Suportadas Não Suportadas
Figura 3.1: Soluções Suportadas e Não Suportadas (RAITH; EHRGOTT, 2009)
As soluções pertencentes ao conjunto Pareto-ótimo são também nomeadas como Soluções Eficientes e podem ser agrupadas em duas categorias; Suportadas e Não suportadas. Basi-camente as soluções suportadas são soluções eficientes que podem ser encontradas através de
ponderações dos objetivos. As demais soluções eficientes são ditas não suportadas. A Figura 3.1 ilustra os tipos das soluções no espaço objetivo. As soluções suportadas são soluções que podem ser encontradas através de escalarizações. Nas escalarizações cada objetivo é associ-ado com uma ponderação fazendo com que o problema multiobjetivo seja transformassoci-ado em um problema mono-objetivo.
Algoritmos Heurísticos ou Aproximativos para problemas multiobjetivos são justificados pela complexidade dos problemas que em geral são NP-difíceis (SERAFINI, 1987). Estes al-goritmos geralmente encontram aproximações das Fronteiras de Pareto.
A formulação do problema do Caminho mais Curto com múltiplos objetivos descrito nesta seção é uma generalização feita por Bezerra (2011) do modelo biobjetivo de fluxo em redes apresentado por Raith e Ehrgott (2009):
min z(x) = z1(x) = ∑ (i, j)∈A c1i jxi j . . . zk(x) = ∑ (i, j)∈A cki jxi j (3.5) su jeito a:
∑
(i, j)∈A xi j−∑
( j,i)∈A xji= 1 se i= s, 0 se i6= s,t −1 se i= t (3.6) xi, j∈ {0, 1}, ∀(i, j) ∈ A. (3.7) onde s e t são, respectivamente, os vértices de origem e destino, c é uma matriz de custo k-dimensional, z é o vetor objetivo composto por k funções objetivo, e xi j representa a inclusãoou não de uma aresta na solução.
3.2
Modelagem
No Cloud Integrator os planos de execução são representados por um grafo direcionado acíclico no qual cada nó intermediário representa um serviço de nuvem específico e as arestas direcionadas representam a sequência de execução dos serviços.
A Figura 3.2 exemplifica um grafo de possibilidades de planos de execução. Neste cenário os nós iniciais e finais são apenas nós auxiliares e não representam nenhum serviço.
Figura 3.2: Exemplo de grafo direcionado acíclico representando um workflow com diferentes opções de planos de execução (CAVALCANTE et al., 2011).
Um dos objetivos do Cloud Integrator é encontrar o melhor plano de execução existente dentre as várias possibilidades. Na Figura 3.3 seis diferentes planos de execução podem ser usados. Encontrar o melhor plano de execução nem sempre é possível uma vez que vários objetivos conflitantes são avaliados.
No Capítulo 2 foi explicado que os serviços possuem valores associados que discriminam a qualidade de cada serviço. Cada serviço possui seis valores ou objetivos que medem a quali-dade do serviço (BATISTA et al., 2011a). Esses valores são: custo, disponibiliquali-dade, tempo de resposta, erro, latência, tempo médio de recuperação, sendo que:
• Custo: é o custo do serviço em dólares, variando entre [0,001; 0,01];
• Disponibilidade: é o valor percentual da disponibilidade (availability) do serviço, vari-ando entre [0,98; 0,999]. Este parâmetro de QoS refere-se à razão entre o tempo em que o serviço está disponível em um determinado período de tempo;
• Tempo de resposta: é o tempo de resposta (response time) do serviço em segundos, vari-ando entre [50; 5000]. Este parâmetro de QoS refere-se ao tempo necessário para com-plementar uma requisição de serviço;
Figura 3.3: Workflow com seis planos de execução. (CAVALCANTE et al., 2011).
0,02]. Este parâmetro de QoS refere-se à razão entre o número de erros ocorridos em um determinado período de tempo;
• Latência: é a latência (latency) do serviço em milissegundos, variando entre [5;50]. Este parâmetro de QoS refere-se ao atraso entre enviar uma requisição e receber a resposta, podendo ser influenciado por diversos fatores da rede;
• MTTR: é o tempo médio para recuperação (MTTR mean time to recovery) do serviço em milissegundos, variando entre [500; 10000]. Este parâmetro de QoS denota o tempo necessário para que um serviço, uma vez em estado de falha, volte a funcionar completa-mente.
Para modelar o problema do planejamento da execução de serviços como um problema de Caminho Mais Curto, é preciso fazer algumas adaptações para o modelo tradicional de grafos. Por exemplo, os serviços são representados nos vértices de um grafo direcionado os quais estão associados a estes vértices. Os valores ou custos associados a cada serviço são transpostos para
Figura 3.4: Workflows do Cloud Integrator modelados como um problema de Caminho Mais Curto
as arestas do mesmo grafo. Neste caso as arestas representam a transição de um serviço para outro, por isso optou-se por colocar os custos nas arestas que chegam nos vértices, por esse motivo as arestas que conectam os serviços da penúltima camada com o nó final possuem os custos nulos. Os nós inicial e final não representam nenhum serviço e sim um artifício usado para transformar em um problema de caminho mais curto ponto-a-ponto. A Figura 3.4 ilustra essa adaptação, onde os custos c1, c2, ..., c6 que inicialmente estão presentes nos vértices pas-sam para as arestas, sendo SI e SF criados para indicar os vértices inicias e finais. Os custos c1, c2, ..., c6 na verdade são vetores de custos, onde cada elemento de um vetor representa um objetivo que o Cloud Integrator pode utilizar para escolher os melhores workflows possíveis. Neste trabalho apenas os três primeiros objetivos explicados anteriormente serão utilizados para encontrar as melhores soluções possíveis. A próxima seção contém uma breve revisão bibliográ-fica dos trabalhos encontrados na literatura do Problema de Caminho Mais Curto Multiobjetivo.
3.3
Revisão Bibliográfica
Esta seção apresenta uma revisão de métodos exatos e heurísticos para o problema do Cami-nho Mais Curto Multiobjetivo. A maioria dos trabalhos apresenta algoritmos para o caso onde 2 objetivos são considerados, uma vez que a generalização para 3 ou mais objetivos nem sempre é trivial. No caso dos algoritmos exatos existem, segundo Skriver (2000), basicamente, duas classes de algoritmos: rotulação de vértices e caminho/árvore, conforme mostrado na Figura 3.5. A primeira classe se divide, ainda, em algoritmos de atribuição de rótulos e de correção de rótulos. Tais algoritmos seguem a técnica de Programação Dinâmica. A segunda classe se di-vide em algoritmos de duas fases e algoritmos de enumeração ordenada das melhores soluções conforme proposto por Gabow (1977). Um dos primeiro trabalhos em algoritmos exatos para o caso multiobjetivo foi apresentado por (MARTINS, 1984). Neste trabalho são apresentados
Figura 3.5: Classificação dos Algoritmos Exatos para o Caminho Mais Curto Biobjetivo (BSP) (SKRIVER, 2000).
dois algoritmos exatos para o problema. O primeiro algoritmo apresentado é uma generalização imediata do algoritmo sistema de rotulagem de múltiplos objetivos de Hansen (1980). Com base neste algoritmo, é provado que qualquer par de caminhos não-dominados podem ser conectados por sub-caminhos não dominados. Este resultado é o suporte para o segundo algoritmo apresen-tado, que pode ser visto como uma variante do método SIMPLEX usado na Programação Linear contínua multiobjetivo. Uma vez que o primeiro algoritmo é utilizado neste trabalho para ob-ter soluções exatas para o problema investigado, o mesmo é apresentado com mais detalhes no Apêndice B. Brumbaugh-Smith e Shier (1989) apresentam um algoritmo de Programação Dinâmica segundo a abordagem de atribuição de rótulos para o problema biobjetivo. Mote, Murthy e Olson (1991) também desenvolveram um algoritmo para resolver o caso biobjetivo. Inicialmente, o algoritmo relaxa as condições de integralidade. Em seguida, o problema rela-xado é resolvido explorando as propriedades associadas com árvores de base adjacentes com um procedimento de correção de rótulos. Os resultados encontrados indicam que o algoritmo é ordens de grandeza mais rápido que a abordagem do t-ésimo Caminho Mais Curto. Ainda segundo os autores, em problemas com uma correlação positiva entre os objetivos o algoritmo paramétrico proposto é significativamente mais rápido do que a abordagem de atribuição de rótulos. Skriver (2000) propõem um melhoramento do algoritmo de Brumbaugh-Smith e Shier (1989) com correção de rótulos. Segundo os autores, após impor algumas condições de domi-nância simples, o número de iterações necessárias para encontrar todas as soluções pode ser reduzido. Experimentos foram realizados comparando o algoritmo desenvolvido com outros al-goritmos da literatura e comprovam o melhor desempenho do algoritmo desenvolvido. Granat e Guerriero (2003) apresentam um método iterativo baseado em rótulos que analisa o problema do caminho mais curto multiobjetivo utilizando a abordagem por ponto de referência. O algo-ritmo proposto encontra o ponto pertencente ao Pareto Ótimo que possui melhor aproximação com o ponto de referência especificado. Gandibleux, Beugnies e Randriamasy (2006)
apresen-contrar soluções nos problemas de Caminho Mais Curto e Árvore Geradora Mínima, ambos com múltiplos objetivos. Segundo os autores a integral de Choquet é um dos mais sofistica-dos métosofistica-dos baseasofistica-dos em preferência usasofistica-dos na Teoria da Decisão para agregar preferências em múltiplos objetivos. Inicialmente é apresentado o conceito das condições de preferências que caracterizam o favorecimento das soluções. Depois os autores apresentam diferentes al-goritmos usando limites como controle das enumerações possíveis (ranking) ou modelos de enumerações explícitas (branch and bound). Os resultados das simulações mostram a efici-ência real dos algoritmos em múltiplos casos de testes com diferentes tamanhos. Sauvanet e Néron (2010) utilizam uma versão multiobjetivo do algoritmo A* para encontrar a melhor solu-ção de compromisso entre dois objetivos do problema. Os autores aplicam sua abordagem em um contexto de roteamento para ciclismo. O método do A* é utilizado juntamente com duas melhorias propostas pelos autores que provam através de experimentos a eficiência das melho-rias em relação ao algoritmo original. Reinhardt e Pisinger (2011) propõem adicionar testes de dominância em um algoritmo de Programação Dinâmica para eliminar a verificação de cami-nhos em diversas versões do problema de caminho mais curto multiobjetivo. Tais versões são oriundas de problemas reais que utilizam mais de um critério, tais como, maximizar a chance de chegar ao destino, maximizar o número de pontos percorridos, maximizar o bônus recolhido em vértices visitados, dentre outros. Schmitt et al. (2011) realizaram um estudo experimental para o Problema do Caminho mais Curto Multiobjetivo, estendendo algoritmos aplicados a pro-blemas com dois objetivos para três objetivos. Machuca et al. (2012) aplicam técnicas exatas para resolver mapas rodoviários realistas e de grande porte com dois objetivos. O algoritmo usado foi NAMOA* com a função heurística proposta por Tung e Chew (1992). Machuca et al. (2012) realizam uma comparação entre três algoritmos exatos, incluindo NAMOA*, mostrando heurísticas que podem ser utilizadas para melhorar o desempenho dos algoritmos exatos.
Revisões de problemas e técnicas de solução exatas relacionadas ao problema do cami-nho mais curto multiobjetivo foram apresentadas por Tarapata (2007) e Raith e Ehrgott (2009). Tarapata (2007) faz uma revisão de diversas versões do problema do caminho mais curto mul-tiobjetivo, suas formulações, como os principais algoritmos exatos são classificados e suas res-pectivas complexidades. O autor ainda faz uma comparação entre a abordagem ponderada do algoritmo de Dijkstra (1959) com a solução dos modelos de Programação Matemática através do software CPLEX 7.0. Raith e Ehrgott (2009) comparam diversas abordagens exatas para resolver o problema biobjetivo.
A maioria dos algoritmos heurísticos propostos para o problema seguem duas principais abordagens metaheurísticas: Computação Evolucionária e Colônia de Formigas. Dentre as téc-nicas evolucionárias se encontram os algoritmos propostos por Mooney e Winstanley (2006), Pangilinan e Janssens (2007), Lin e Gen (2007) e S. e Ramirez-Marquez (2010). Mooney e Winstanley (2006) propõem um algoritmo evolutivo elitista com duas populações. No algo-ritmo utiliza-se codificação por caminhos (representação por vértices), cruzamento de um ponto e seleção por torneio binário. O operador de mutação usado escolhe um vértice aleatório e o substitui por outro vértice aleatório. Os experimentos mostram que o algoritmo proposto conse-gue encontrar soluções próximas a dos algoritmos exatos testados: Dijkstra e k-ésimo melhor. Pangilinan e Janssens (2007) uma adaptação do Strenght Pareto Evolutionary Algorithm, pro-posto por Zitzler et al. (1998), para o problema. Lin e Gen (2007) propuseram um algoritmo genético híbrido para o problema biobjetivo (minimizar o custo e o atraso da rede). Os autores usaram uma codificação baseada em prioridade para representar o cromossomo, um parâmetro adaptativo para controlar a exploração e a intensificação que é baseado na mudança da média da adequação da adequação a cada iteração. Os autores ainda usaram um mecanismo adaptativo de atribuição de pesos para ponderar os objetivos avaliados. S. e Ramirez-Marquez (2010) apre-sentam um algoritmo evolutivo para o problema biobjetivo (maximização do comprimento do caminho mais curto e a minimização do custo da estratégia de interdição) aplicado ao problema de redes com interdição. O algoritmo desenvolvido baseia-se na simulação de Monte Carlo para gerar potenciais caminhos, bem como no cálculo probabilístico da quantidade de vezes que uma aresta(vértice) aparece no Pareto Ótimo.
Dentre as abordagens por Colônia de Formigas foram apresentados os trabalhos de Häckel et al. (2008), Ghoseiri e Nadjari (2010), Bezerra et al. (2011) e Bezerra et al. (2013). Häckel et al. (2008) exibem um algoritmo de colônia de formiga híbrido para o problema com três objetivos. A técnica de Programação Dinâmica é utilizada para gerar valores heurísticos nas arestas do grafo. Os valores heurísticos posteriormente são utilizados pelas formigas artificiais. Ghoseiri e Nadjari (2010) apresentam um algoritmo de colônia de formigas para o problema bi-objetivo. Uma análise experimental foi realizada, a fim de validar a eficiência do algoritmo bem como a qualidade das soluções encontradas. Os casos de testes foram gerados aleatoriamente e foram classificadas como pequenas e grandes. Os resultados encontrados foram comparados com um algoritmo de correção de nós. Os autores concluem que o algoritmo desenvolvido con-segue encontrar boas soluções em um tempo menor principalmente nos casos de testes maiores. Bezerra et al. (2011) apresentam um algoritmo de colônia de formigas chamado GRACE para o problema com três objetivos. No trabalho, os autores comparam o desempenho do GRACE com um algoritmo NSGA-II e com o algoritmo de Häckel et al. (2008). Bezerra et al. (2013) analisam
4
Transgenética Computacional
A Transgenética Computacional é uma metáfora evolucionária baseada na evolução endos-simbiótica intracelular mutualista (GOLDBARG, 2012). A mesma é composta por três diretri-zes extraídas de Goldbarg (2012):
1. A evolução ocorre através de transformações genéticas no interior de uma célula hospe-deira que foi invadida ou que fagocitou outras unidades vivas.
2. A evolução da quimera formada pelo hospedeiro/endossimbiontes ocorre de forma guiada e influenciada pelo DNA do hospedeiro.
3. O processo de troca de informações genéticas necessário à evolução é realizado exclusi-vamente através de mecanismos de transferência horizontal de genes.
4.1
Terminologia
Para um bom entendimento do algoritmo os seguintes conceitos são apresentados:
Quimera: Uma quimera é o ambiente onde os Algoritmos Transgenéticos estão inseridos. A mesma é composta por dois elementos principais, Hospedeiro e Endossimbiontes. Hospedeiro: O hospedeiro é responsável por guardar as informações (DNA) obtidas a priori
ou a posteriori sobre um determinado problema.
Endossimbiontes: Os endossimbiontes são os indivíduos ou as soluções do problema que se quer resolver.
Vetores Transgenéticos: Os vetores transgenéticos são os operadores que modificam os en-dossimbiontes. Existem vários vetores transgenéticos, mas neste trabalho apenas dois serão usados(Plasmídeo e Transposon).
Transposon: Vetor transgenético responsável por realizar uma melhoria no DNA dos endos-simbiontes.
O Algoritmo Transgenético funciona da seguinte maneira. Primeiramente, uma população inicial é gerada. Depois, um banco de informações sobre o problema é inicializado através de técnicas de pré-processamento inline ou offline.. Em seguida, o algoritmo entra em um laço até que alguma condição de parada seja atingida. Dentro do laço o algoritmo seleciona membros da população criada anteriormente para aplicação dos operadores. Depois, os vetores transge-néticos são criados. De posse dos indivíduos selecionados e dos vetores transgetransge-néticos obtidos anteriormente o algoritmo agora manipula os cromossomos a fim de encontrar indivíduos me-lhores. A última etapa antes do laço acabar é atualizar o repositório de informações com as novas soluções encontradas.
O pseudo código do Algoritmo Transgenético é apresentado no Algoritmo 4.1. Algoritmo 4.1 Pseudo Código do Algoritmo Transgenético Genérico
1: Pop← InicializaPopulacao()
2: GI← InicializaIn f ormacaoGenetica
3: repita
4: TransVects← CriarVetoresTransgeneticos(GI)
5: SubPop← SelecionarCromossomos(Pop)
6: NovaSubPop← ManipularCromosomos(SubPop, TransVects)
7: Pop← AtualizarPopulacao(Pop, NovaSubPop)
8: GI← AtualizarIn f ormacaoGenetica(Pop)
9: enquanto StopCondition() != true
A Transgenética Computacional ainda está longe de ser completamente explorada e boas contribuições ainda devem surgir com o passar do tempo.
4.2
Algoritmo Transgenético
O pseudo código do algoritmo Transgenético implementado neste trabalho é representado pelo Algoritmo 4.2. Uma solução é representada por um vetor cujo tamanho é exatamente o mesmo do número de camadas do grafo k-partido. Um endossimbionte é composto exatamente por uma solução e pelo vetor objetivo respectivo da solução.
Algoritmo 4.2 Pseudo Código do Algoritmo Transgenético
1: Grafo← CarregarGra f o()
2: Pop← IniciaPopulacao()
3: GI← IniciaIn f ormacaoGenetica()
4: Patamar← IniciaPatamar()
5: repita
6: se NumeroEntrePatamar(randomNumber(), Patamar) então
7: Transposon()
8: senão
9: Plasmideo()
10: fim se
11: Patamar← AtualizaPatamar()
12: enquanto StopCondition() != true
Inicialmente o algoritmo carrega o grafo que se quer resolver com a função CarregarGra f o. Em seguida, a população de endossimbiontes e o banco de informações genéticas é iniciado pe-las funções IniciaPopulao e IniciaIn f ormaoGentica. A função IniciaPopulao inicializa os endossimbiontes com caminhos construídos aleatoriamente entre a fonte e o destino do grafo em questão e a função IniciaIn f ormaoGentica lê um arquivo de soluções encontradas a pri-ori se algum arquivo for passado como parâmetro para o algoritmo, caso contrário inicializa com soluções geradas através de ponderações obtidas com os vetores canônicos através do al-goritmo de Dijkstra. Quando três objetivos estão sendo avaliados, os vetores canônicos seriam [1;0;0],[0;1;0],[0;0;1]. O método usado para encontrar soluções a priori foi o LOGOS,que é descrito no Anexo D. Nos experimentos computacionais que serão apresentados no próximo capítulo, duas versões do Transgenético serão utilizadas, uma utilizando o LOGOS para iniciar o banco de informação genética e outra sem o LOGOS, onde o banco de informação genética é inicializado apenas com os vetores canônicos descritos anteriormente. O tamanho do banco de informação é ilimitado.
Após as etapas de inicialização, o algoritmo entra em repetição até que alguma condição de parada seja satisfeita. Dentro do bloco de repetição é feita a escolha de qual operador vai ser executado na iteração corrente (Plasmídeo ou Transposon). Essa escolha é feita através da variável patamar. O patamar inicia com o valor zero %, fazendo com que sempre seja executado o operador de Plasmídeo na primeira iteração. O valor final do patamar na última iteração é 100%, fazendo com que sempre seja executado o operador de Transposon. A Figura 4.1 ilustra os possíveis valores assumidos pelo patamar quando o número máximo de iterações é igual a dez. Ao final de cada iteração, o valor do patamar é atualizado dependendo da iteração corrente e do número de iterações totais que o algoritmo vai executar.
Figura 4.1: Patamar
operadores do Transgenético. Os serviços S1 a S6 possuem respectivamente os seguintes vetores de custos: S1[1; 1; 4], S2[2; 2; 1], S3[1; 3; 1], S4[1; 1; 1], S5[3; 2; 1], S6[2; 4; 2]
O Plasmídeo, inicialmente, pega um caminho armazenado no banco de informação gené-tica aleatoriamente. Em seguida, são gerados dois índices para delimitar quais informações genéticas deverão ser manipuladas com as informações contidas nos endossimbiontes. Cada endossimbionte recebe o pedaço da informação genética e caso a nova solução seja não domi-nada em relação às outras soluções pertencentes ao banco de informação, a mudança é mantida, caso contrário, a nova solução é descartada.
Por exemplo, a Figura 4.2 ilustra as três fases de execução do Plasmídeo (Antes, Durante e Depois). Na primeira fase, o intervalo de alteração é gerado. Na segunda fase, parte das infor-mações armazenadas no Banco de Informação são inseridas na população de endossimbiontes. Na terceira fase, as informações são persistidas no endossimbionte caso as novas soluções sejam melhores que as soluções da primeira fase.
O Transposon funciona de forma similar ao Plasmídeo, mas não utiliza nenhuma informa-ção do banco de informações genéticas. Inicialmente são gerados dois índices para delimitar o tamanho das informações que serão injetadas dentro dos endossimbiontes. Para cada indi-víduo da população de endossimbiontes é gerado um vetor de pesos aleatórios cuja soma dos elementos é um. A partir do vetor gerado anteriormente, é calculado um sub caminho usando o algoritmo de Dijkstra. Em cada elemento de uma solução é gerado um valor lógico aleató-rio, caso esse valor seja verdadeiro, a informação daquele elemento é inserida a partir do sub caminho encontrado anteriormente, caso seja falso, a informação do elemento corrente é alte-rada por um vértice aleatório pertencente á mesma camada do elemento corrente. Depois de
Figura 4.2: Exemplo de execução do Plasmídeo
todas as modificações serem realizadas, tenta-se inserir as soluções no banco de informações, caso algumas delas sejam não dominadas, as modificações são persistidas nos endossimbiontes respectivos.
Por exemplo a Figura 4.3 ilustra as três fases de execução do Transposon (Antes, Durante e Depois). Na primeira fase, o intervalo de alteração é gerado. Na segunda fase, as informações a serem inseridas na população de endossimbiontes são providas de duas fontes Dijkstra esca-larizado ou de vértices aleatórios do Grafo. Em cada execução do Transposon é escolhida uma das fontes, sendo que, caso o Dijkstra escalarizado seja escolhido, um vetor de escalarização aleatório é criado. Na terceira fase, as informações são persistidas no endossimbionte caso as novas soluções sejam melhores que as soluções da primeira fase.
Quando a condição de parada do Transgenético é satisfeita, um procedimento de pós pro-cessamento é executado salvando todas as soluções do banco de informações genéticas em um arquivo externo.
5
Experimentos e Resultados
Este capítulo apresenta detalhadamente os procedimentos realizados para a execução dos experimentos computacionais, bem como os resultados encontrados. Dos objetivos possíveis de serem explorados explicados anteriormente, somente três foram usados para os experimen-tos computacionais (custo, disponibilidade e tempo de resposta). Primeiramente, será descrito como os casos de testes foram gerados. Em seguida, é apresentada a metodologia para avaliação dos algoritmos heurísticos e como os parâmetros de cada algoritmo foram ajustados. A última seção expõe os resultados encontrados e as conclusões.
Todos os experimentos foram implementados na linguagem C++, compilados com o GCC 4.7.2 com as flags -std=c++11 -march=native -g -O3 -Os -DNDEBUG , executados em uma máquina com processador Intel(R) Xeon(R) CPU X3430 @ 2.40GHz e com 9,7GB de memó-ria RAM. O sistema operacional usado foi o GNU/LINUX com Kernel 2.6.18 x86_64 com a distribuição Scientific Linux SL 5.5 (Boron).
Para calcular o tempo de execução dos algoritmos, usa-se o comando time (localizado em /usr/bin/time) com o argumento de portabilidade (-p) ativado sendo que o tempo de leitura dos casos de testes como o tempo de escrita dos resultados não foram subtraídos do tempo total.
Os scripts de automatização de tarefas foram implementados na linguagem de programação chamada de Ruby por sua simplicidade e flexibilidade. Os gráficos gerados, bem como os testes estatísticos, foram implementados em R (TEAM, 2012), um software estatístico livre.
Ao final de todos os experimentos, foram gerados 2.1 gigabytes de dados simples com pouca formatação. O tempo computacional contabilizado para encontrar esses dados levou aproximadamente 65 dias ou 5646537.87 segundos. O número de linhas de código escritos em C++somados passam de 10 mil e foram escritas mais de 900 linhas de código em scripts para automatização das tarefas.
gratoré um grafo k-partido completo direcionado, onde todos os vértices de uma camada são ligados por todos os vértices da camada anterior, onde k é o número de camadas. Na Figura 5.1 o grafo é composto por três camadas (A, B,C), oito nós, sendo que para cada aresta que conecta dois nós possui um vetor de custo, totalizando oito vetores de custo. As arestas que ligam os vértices da ultima camada com o vértice SF possuem vetores de custo nulos. Todas as arestas possuem seis valores objetivos, mas apenas três são utilizados. Os intervalos de valores foram explicados na Seção 4.1.
Figura 5.1: Exemplo de um caso de teste usado nos experimentos.
Para a execução dos experimentos, foram gerados 42 casos de testes. Os casos de testes estão divididos em quatorze grupos, tais que, cada grupo possui três exemplares. Os grupos são definidos pela quantidade de camadas que o grafo (caso de teste) possui, podendo assumir os seguintes valores [5, 10, 15, 20, 25, 50, 75, 100, 125, 150, 175, 200, 225, 250]. A quantidade de vértices por camada é dada no intervalo de [1; 10], escolhido aleatoriamente na geração de cada camada por caso de teste. A nomenclatura dos casos de teste segue o seguinte padrão: quantidade de camadas do grafo, _ , número do exemplar. Por exemplo, o caso de teste 005_1 representa o primeiro exemplar do grupo de casos de teste com a quantidade de camadas iguais a cinco. Quando apenas a quantidade de camadas é exposta, significa que todos os exemplares do grupo estão sendo avaliados.
5.2
Metodologia para Avaliação dos Algoritmos
A abordagem usada neste trabalho é o uso de uma métrica, normalmente definida na litera-tura como Indicador de Qualidade. Os indicadores nada mais são que uma métrica que atribui um número real para um ou mais conjuntos de valores. O indicador de qualidade usado é o Hypervolume(Anexo A).
Em cada experimento os algoritmos heurísticos foram executados independentemente 25 vezes em cada caso de teste. Em seguida o Hypervolume do conjunto de soluções não domina-das geradomina-das por cada algoritmo por caso de teste é calculado. No final, se obtém 25 valores de Hypervolumepor caso de teste. Quanto maior for o valor do Hipervolume melhor é o conjunto de aproximação. Testes estatísticos (Anexos E e F) não paramétricos foram usados para veri-ficar se os dados das amostras fornecem evidências suficientes para que se possa aceitar como verdadeiras as hipóteses testadas. Com os testes estatísticos pode-se prever, com certa segu-rança, que as diferenças observadas nas amostras não são casuais. Os testes não paramétricos foram escolhidos pelo fato das amostras não serem obtidas a partir de uma distribuição normal. Em todos os testes estatísticos o nível de significância usado foi de 0,01.
5.3
Afinação de Parâmetros
Os dois algoritmos evolucionários implementados neste trabalho possuem parâmetros para serem ajustados. Ambos algoritmos são populacionais e iterativos. Dessa forma, a afinação de parâmetros será mais justa possível nos critérios populacionais e iterações. Na afinação de parâmetros apenas uma amostra do conjunto de casos de testes foi usada. A amostra é composta por um caso de teste para cada número de camadas que o grafo possui. A metodologia de afinação de parâmetros para ambos algoritmos metaheurísticos foi a seguinte:
Primeiramente, foram escolhidas faixas de valores para ambos os parâmetros a serem ajus-tados. Depois, cada possível valor de parâmetro foi combinado com os demais valores dos outros parâmetros. Realizando, assim, um desenho fatorial de experimentos. Em seguida, cada configuração é executada 25 vezes em cada caso de teste pertencente ao subgrupo escolhido para afinação dos algoritmos. Depois, foi calculado o valor do Hypervolume para todas as con-figurações dos algoritmos evolucionários executados em cada caso de teste. O teste estatístico de Mann-Whitney (Apêndice F) foi aplicado entre as configurações dois a dois para verificar se existiam diferenças entre as configurações. O teste de Mann-Whitney foi escolhido por sua característica de realizar as comparações por casos de testes, assim, pode-se inferir quem são as
significativa entre as configurações, a configuração com o menor uso dos recursos computacio-nais (tempo) é escolhida.
O algoritmo escolhido para competir com o Transgenético foi o NSGA-II conforme descrito no trabalho de Bezerra (2011) (Apêndice C) que foi inicialmente idealizado no trabalho de Srinivas e Deb (1994) e depois aprimorado em Deb et al. (2000) e Deb et al. (2002). O motivo da escolha foi o fato do NSGA-II ser amplamente usado e por ser considerado um algoritmo competitivo com relação aos demais encontrados na literatura.
5.3.1
NSGA-II
Para o NSGA-II quatro parâmetros precisam ser configurados: tamanho da população, nú-mero de gerações, taxa de crossover e taxa de mutação. Foram usados três valores possíveis para cada parâmetro: tamanho da população [100, 152, 200]; número de gerações [100, 150, 200]; taxa de crossover [25%, 50%, 100%]; taxa de mutação [1%, 5%, 10%];
No total foram testadas 81 combinações, como apresenta a Tabela 5.1.
Dentre as 81, as 3 melhores configurações foram escolhidas, sendo elas: 77,79 e 81. A Tabela 5.3 contém o tempo médio em segundos das três melhores configurações. do NSGA-IItestadas. Os valores em negrito indicam que o primeiro fator da comparação é melhor que o segundo fator. Os valores sublinhados indicam que o primeiro fator da comparação é pior que o segundo fator. Os demais valores indicam que as amostram não possuem diferenças significativas. Para podermos decidir qual a melhor das três alternativas foi usado o teste de Mann-Whitney entre as configurações 79 x 77, 79 x 81 e 77 x 81. O resultado do teste estatístico é apresentado na Tabela 5.2. Apesar da maioria dos testes indicarem que não existe diferença significativa entre as amostras (0,05 < p-valor < 0,95), pode-se perceber que em nenhum dos testes a configuração 79 (População 200, Gerações 200, Crossover 100, Mutação 1) perde. Por esse motivo essa foi a configuração escolhida.
5.3.2
Transgenético
Para o Transgenético, apenas dois parâmetros foram configurados, pois a decisão de qual operador será aplicado na iteração é definida no patamar. O tamanho do plasmídeo é encontrado
Tabela 5.1: Configurações do NSGA-II. Sendo Con o número da configuração, P o tamanho da população, G o número de gerações, C a taxa de crossover e M a taxa de mutação
Con P G C M 1 100 100 25 1 2 100 100 25 5 3 100 100 25 10 4 100 100 50 1 5 100 100 50 5 6 100 100 50 10 7 100 100 100 1 8 100 100 100 5 9 100 100 100 10 10 100 150 25 1 11 100 150 25 5 12 100 150 25 10 13 100 150 50 1 14 100 150 50 5 15 100 150 50 10 16 100 150 100 1 17 100 150 100 5 18 100 150 100 10 19 100 200 25 1 20 100 200 25 5 21 100 200 25 10 22 100 200 50 1 23 100 200 50 5 24 100 200 50 10 25 100 200 100 1 26 100 200 100 5 27 100 200 100 10 Con P G C M 28 152 100 25 1 29 152 100 25 5 30 152 100 25 10 31 152 100 50 1 32 152 100 50 5 33 152 100 50 10 34 152 100 100 1 35 152 100 100 5 36 152 100 100 10 37 152 150 25 1 38 152 150 25 5 39 152 150 25 10 40 152 150 50 1 41 152 150 50 5 42 152 150 50 10 43 152 150 100 1 44 152 150 100 5 45 152 150 100 10 46 152 200 25 1 47 152 200 25 5 48 152 200 25 10 49 152 200 50 1 50 152 200 50 5 51 152 200 50 10 52 152 200 100 1 53 152 200 100 5 54 152 200 100 10 Con P G C M 55 200 100 25 1 56 200 100 25 5 57 200 100 25 10 58 200 100 50 1 59 200 100 50 5 60 200 100 50 10 61 200 100 100 1 62 200 100 100 5 63 200 100 100 10 64 200 150 25 1 65 200 150 25 5 66 200 150 25 10 67 200 150 50 1 68 200 150 50 5 69 200 150 50 10 70 200 150 100 1 71 200 150 100 5 72 200 150 100 10 73 200 200 25 1 74 200 200 25 5 75 200 200 25 10 76 200 200 50 1 77 200 200 50 5 78 200 200 50 10 79 200 200 100 1 80 200 200 100 5 81 200 200 100 10
Tabela 5.2: Teste de Mann-Whitney entre as três configurações do NSGA-II.
Configurações 79 x 77 79 x 81 77 x 81 Caso de Teste p-valor p-valor p-valor 005-1 0,79260 0,81428 0,56939 010-1 0,26896 0,77948 0,89180 015-1 0,09437 0,77948 0,99281 020-1 0,82757 0,46170 0,11944 025-1 0,53829 0,27536 0,20370 050-1 0,14878 0,29500 0,67786 100-1 0,02144 0,02837 0,43130 200-1 0,48466 0,40129 0,46170
Tabela 5.3: Tempo Médio de execução das configurações 77, 79 e 81 do NSGA-II por caso de teste. Os valores em negrito indicam os menores tempos de execução por caso de teste.
Configurações 77 79 81 Caso de Teste tempo(s) tempo(s) tempo(s)
005-1 0,5424 0,5416 0,5408 010-1 0,5392 0,5412 0,5396 015-1 0,6276 0,628 0,6292 020-1 0,6952 0,694 0,6964 025-1 0,8024 0,8048 0,8064 050-1 1,3636 1,364 1,3596 100-1 2,6972 2,692 2,7012 200-1 6,3408 6,3372 6,2596
Tabela 5.4: Configurações do Transgenético. Sendo Con o número da configuração, P o tama-nho da população e I o número de iterações.
Con P I 1 100 100 2 100 150 3 100 200 4 150 100 5 150 150 6 150 200 7 200 100 8 200 150 9 200 200
como uma opção de parâmetro em outros trabalhos, mas neste trabalho o tamanho do plasmídeo é aleatório a cada iteração, dentro do intervalo de zero ao tamanho da solução. Foram usados três valores possíveis para cada parâmetro: tamanho da população [100, 150, 200]; número de iterações [100, 150, 200]. No total foram testadas 9 combinações, como apresenta a Tabela 5.4. A Tabela 5.6 contém o tempo médio em segundos das configurações do Transgenético. Os valores em negrito indicam os menores tempos de execução por caso de teste. Os resultados mostram que a configuração 6 possui o menor tempo médio em todos os casos de testes.
O critério da mediana do Hypervolume foi usado para avaliar o quanto uma configuração é melhor que outra. A Figura 5.2 contém a mediana dos Hypervolumes calculados por grupos de casos de testes. Na Figura 5.2a, pode-se perceber que a configuração 7 está competindo com a configurações 8 mas na Figura 5.2b, a configuração 6 é melhor que todas as outras. Para podermos decidir qual a melhor das três alternativas, foi usado o teste de Mann-Whitney entre as configurações 6 x 7, 6 x 8 e 7 x 8. O resultado dos testes estatísticos é apresentado na Tabela 5.5. Os valores em negrito indicam que o primeiro fator da comparação é melhor que o segundo fator. Os valores sublinhados indicam que a o primeiro fator da comparação é pior que o segundo fator. Os demais valores indicam que as amostras não possuem diferenças significativas. Como a maioria dos testes foram não conclusivos com as configurações ganhando e perdendo em ambas comparações, foi escolhida a configuração 6 (População 150, Iterações 200) por usar menos tempo computacional.
Tabela 5.5: Teste de Mann-Whitney entre as três configurações no Transgenético
Configurações 6 x 7 6 x 9 7 x 9 Caso de Teste p-valor p-valor p-valor
005-1 0,19647 0,99955 0,97386 010-1 0,01632 0,24834 0,65112 015-1 0,05798 0.99105 0,99841 020-1 0,06026 0,04753 0,45364 025-1 0,99586 0,98512 0,63655 050-1 0,99998 0,83408 0,00023 100-1 0,00002 0,00002 0,59957 200-1 0,11828 0,01893 0,43831
5.4
Resultados Finais
Para calcular os resultados finais, todo o conjunto de casos de teste gerados é utilizado. Inicialmente, são apresentados os resultados do algoritmo de Martins, depois é apresentada
(a) (b)
Figura 5.2: Mediana dos Hypervolumes para as 3 melhores configurações do Transgenético
Tabela 5.6: Tempo Médio de execução das configurações 6, 7 e 8 do Transgenético por caso de teste.
Configurações 6 7 8 Caso de Teste tempo(s) tempo(s) tempo(s)
005-1 0,1268 0,2328 0,1668 010-1 0,1972 0,3032 0,2336 015-1 0,1992 0,3372 0,2488 020-1 0,2408 0,4144 0,3016 025-1 0,2808 0,5228 0,3688 050-1 0,4872 0,806 0,5764 100-1 0,9024 1,4608 1,1248 200-1 2,1144 3,1104 2,5572
uma comparação entre as duas versões do algoritmo Transgenético (com e sem LOGOS) e o NSGA-II.
5.4.1
Resultados do Algoritmo Exato
Ao final da execução de um processo do algoritmo de Martins três arquivos são gerados. O primeiro deles é o conjunto de vetores objetivo não dominados, ou Fronteira de Pareto. O segundo arquivo possui os caminhos das soluções não dominadas que resolvem o problema (Pareto Ótimo), bem como outras informações como o número de iterações que o algoritmo precisou para resolver o problema (caso de teste). No terceiro arquivo são armazenados os recursos utilizados como o tempo de processamento para resolver o problema. A Tabela 5.7 contém os resultados obtidos pelo algoritmo de Martins com três objetivos sendo avaliados. As colunas representam respectivamente o caso de teste, o número de iterações necessárias para a execução do algoritmo, a cardinalidade da Fronteira de Pareto e o tempo computacional utilizado.
Tabela 5.7: Algoritmo de Martins com três objetivos sendo avaliados
Caso de Teste Número de Iterações Cardinalidade da Fronteira de Pareto Tempo(s)
005-1 551 75 0,12 005-2 357 59 0,08 005-3 343 58 0,07 010-1 4421 216 7,88 010-2 1303 73 2,27 010-3 2708 153 4,48 015-1 13257 806 80,6 015-2 14299 835 86,59 015-3 21687 1170 132,25 020-1 28735 1351 367,38 020-2 27316 1067 350,72 020-3 28940 882 371,28 025-1 163315 4446 5437,45 025-2 117169 3293 3679,73 025-3 171649 6210 5985,05
Percebe-se que o número de iterações, o número soluções encontradas e o tempo compu-tacional crescem exponencialmente tonando inviável a execução do algoritmo de Martins para casos de testes que possuem o número de camadas maior que 25.
Figura 5.3: Mediana dos Hypervolumes do Transgenético com e sem o LOGOS do NSGA-II
5.4.2
Transgenético com LOGOS e sem LOGOS X NSGA-II
A Figura 5.3 mostra a mediana dos Hypervolumes encontrados a partir das execuções inde-pendentes do Transgenético com e sem LOGOS (TransL e Trans) e do NSGA-II para os casos de testes com mais de 25 camadas.
Na Figura 5.3 pode-se observar que em todos os casos a mediana do Hypervolume do Trans-genético com LOGOS é maior do que dos outros algoritmos. O TransTrans-genético sem o LOGOS possui um comportamento semelhante ao NSGA-II, mas se destaca no caso teste com 200 ca-madas.
A Figura 5.4 exibe uma variação do gráfico boxplot chamada de vioplot. No eixo x são apresentados os algoritmos avaliados e no eixo y os valores de Hypervolume calculados. Pode-se perceber que o menor valor de Hypervolume encontrado pelo Transgenético com o LOGOS é maior que o maior valor de Hypervolume encontrado pelo Transgenético sem o LOGOS e pelo NSGA-II. No Apêndice A são apresentados os vioplot para as demais classes de grafos, onde a observação do melhor comportamento do Transgenético com LOGOS pode ser verificada.
O teste de Friedman (descrito no Anexo E) com nível de significância de 0,01 foi utilizado nestes experimentos. O teste verifica se os Hypervolumes dos conjuntos de aproximação pro-duzidos pelos algoritmos possuem diferenças significativas. Caso exista diferença significativa, um pós-teste é realizado para identificar qual o melhor algoritmo. No experimento relatado neste trabalho o p-valor obtido do teste de Friedman foi de 2, 2x10−16, indicando que existe diferença significativa entre os Hypervolumes. O pós-teste indica que existem diferenças sig-nificativas entre o Transgenético com LOGOS e as outras duas abordagens e que não existe
2.0e+19
6.0e+19
1.0e+20
1.4e+20
NSGA−II Transgenético Transgenético com LOGOS
Figura 5.4: Vioplot para os casos de testes com 200 camadas.
diferença significativa entre o Transgenético sem LOGOS e o NSGA-II.
Caso de Teste NSGA-II Transgenético com LOGOS Transgenético Normal
050 1,36 0,73 0,55 075 1,98 1,15 0,96 100 2,66 1,48 1,08 125 3,05 2,01 1,75 150 3,76 2,67 2,29 175 4,92 3,13 2,39 200 6,30 3,65 3,14 225 7,21 4,45 3,70 250 9,87 5,02 4,46
Tabela 5.8: Média do tempo de execução dos algoritmos
A Tabela 5.8 contém a média do tempo de execução em segundos de cada algoritmo agru-pado pelo tamanho do caso de teste para número de camadas acima de 25. Percebe-se que o tempo do NSGA-II é maior que do Transgenético em todos os casos de testes. O Transgenético com LOGOS possui o tempo de execução maior que o Transgenético normal, esse acréscimo é constante por caso de teste e se refere a etapa de pré-processamento realizada do LOGOS.
