METAHEURÍSTICAS ILS E ACS PARA GERAÇÃO DE CONFIGURAÇÕES OTIMIZADAS PARA SISTEMAS ORIENTADOS A

COMPONENTES

Jefferson Ferreira de Araújo Lima

Departamento de Informática - Universidade Federal da Paraíba João Pessoa, PB – Brasil jefferson@lavid.ufpb.br

Gilberto Farias de Sousa Filho Departamento de Informática - Universidade Federal da Paraíba

João Pessoa, PB – Brasil gilberto@lavid.ufpb.br

Luiz Eduardo C. Leite

Departamento de Informática - Universidade Federal da Paraíba João Pessoa, PB – Brasil gilberto@lavid.ufpb.br

Lucídio A. F. Cabral

Departamento de Estatística - Universidade Federal da Paraíba João Pessoa, PB – Brasil

lucidio@de.ufpb.br

Guido Lemos de Sousa Filho

1Departamento de Informática - Universidade Federal da Paraíba João Pessoa, PB – Brasil

guido@lavid.ufpb.br

RESUMO

É cada vez mais comum que sistemas distribuídos de larga-escala, incluindo sistemas de middleware, sejam desenvolvidos utilizando-se componentes pré-fabricados de software. Durante o desenvolvimento desses sistemas, componentes de software devem ser selecionados e interconectados através de uma linguagem de programação apropriada, visando atender a todos os requisitos do sistema, inclusive os não-funcionais. Este trabalho apresenta as metaheurísticas ILS e ACS capazes de encontrar configurações otimizadas para sistemas orientados a componentes, considerando o seu contexto de execução corrente. Os resultados obtidos indicam que uma configuração ótima ou próxima dela pode ser obtida em poucos segundos. PALAVRAS CHAVE. ILS, ACS, Otimização, Componentes

ABSTRACT

Component platforms, such as CORBA, Java Beans, .Net and DCOM have been increasingly used to develop and deploy large-scale distributed systems, including middleware. Such a systems are built by using pre-manufactured components, interconnected using an appropriated programming language, in order to reach all the systems requirements including the non-functions. This paper presents a ILS and ACS meta-heuristics capable of finding system’s configurations which are most suitable for a given execution context. The obtained results depicts that it is possible to obtain an optimum solution or a solution close to the optimum in a few seconds. KEYWORDS. ILS, ACS, Optimization, Components

1366

1. Introdução

Plataformas orientadas a componentes, tais como CORBA, Java Beans, .Net e DCOM têm sido frequentemente utilizadas para o desenvolvimento de sistemas distribuídos em larga-escala, inclusive sistemas de middleware. O processo de construção de tais sistemas normalmente é conduzido através da construção de seus módulos (componentes) separadamente, sendo estes posteriormente interligados através de seus pontos de conexão ou interfaces.

De acordo com os requisitos de um sistema, sua configuração pode ser projetada selecionando-se os componentes mais adequados para compô-la. Entretanto, diversos sistemas possuem requisitos não-funcionais que variam muito ao longo do tempo, durante a sua execução. Nesse caso, uma configuração de componentes, inicialmente projetada, pode tornar-se inadequada em determinados momentos, demandando modificações em tempo de execução. No escopo deste trabalho, o contexto de execução de um sistema é definido em termos da sua configuração atual, dos recursos disponíveis (CPU, memória, qualidade do serviço de rede, dentre outros) e das preferências dos usuários que correntemente fazem uso do sistema.

Visando promover a adaptação dos sistemas computacionais, alguns trabalhos têm sido propostos na literatura para especificar mecanismos que possibilitem a alteração dos componentes de um sistema mediante mudanças ocorridas em seus contextos de execução [Tripathi 2002; Kon 2002; Agha 2002; Venkatasubramanian 2002; Eliassen 2000; Vogt 1993]. Esses trabalhos apresentam frameworks que, quando utilizados durante a implementação dos componentes de um sistema, possibilitam que os mesmos possam ser substituídos em tempo de execução. Contudo, esses frameworks não definem como e quando os componentes devem ser substituídos, deixando essa estratégia como um ponto de flexibilização que pode ser definida e implementada pelo programador. Por ser definida pelo programador, a estratégia utilizada para promover a reconfiguração automática de um sistema em tempo de execução fica restrita ao seu domínio de conhecimento [Curtis, 1989]. O programador normalmente considera na sua estratégia apenas os componentes por ele conhecidos [Lange, 1989], especificando regras que definem que componentes específicos devem ser utilizados em determinados contextos de execução. O surgimento de novos componentes faz com que estas estratégias precisem ser alteradas para possibilitar o uso desses elementos, normalmente exigindo atividades de programação ou pelo menos de especificação de novas regras. Este trabalho apresenta um mecanismo capaz de computar configurações otimizadas para sistemas distribuídos orientados a componentes, de acordo com os seus contextos de execução. Para fazer uso dos melhores componentes existentes, o mecanismo deve ser capaz de acessar toda informação sobre os componentes armazenados em um dado repositório. Essa abordagem minimiza os problemas oriundos da falta de conhecimento do programador e dispensa a necessidade de geração de novas regras de reconfiguração sempre que novos componentes fossem inseridos no repositório. O mecanismo de otimização proposto baseia-se na utilização de metaheurísticas computacionais capazes de encontrar configurações de componentes de baixo custo. No escopo deste trabalho, o custo de uma configuração está relacionado ao somatório dos custos individuais de cada componente. O custo de cada componente por sua vez é uma medida numérica que indica o quão adequado é o componente para um dado contexto de execução do sistema. Esse custo pode ser continuamente determinado por um mecanismo de avaliação de contexto. O foco deste trabalho está na apresentação do mecanismo de otimização. Uma descrição mais detalhada do mecanismo de avaliação de contexto será feita em outros trabalhos. Este artigo está organizado em sete seções. Na seção 2 descrevemos o problema abordado neste artigo. Na seção 3, apresentamos uma formulação matemática do mesmo. Na seção 4, descrevemos a complexidade computacional do problema modelado. Na seção 5, apresentamos as metaheurísticas ILS e ACS para a solução do problema proposto, na seção 6 são apresentados os resultados computacionais obtidos com o emprego destas metaheurística na resolução de algumas instâncias geradas de forma aleatória utilizadas em [LEITE, 2007]. Finalmente, na seção 7, são feitas algumas considerações finais.

1367

2. Problema de Otimização de Sistemas Orientados a Componentes

O Problema de Otimização de Sistemas Orientados a Componentes – POSOC, que deve ser resolvido pelos algoritmos do mecanismo de otimização proposto, pode ser modelado da seguinte maneira: Considerando-se um Sistema Orientado a Componentes - SOC qualquer, esse sistema deve possuir um conjunto de interfaces de acesso, que são utilizadas para que os seus clientes possam fazer uso dos serviços providos por ele. Esses clientes podem ser usuários humanos (nesse caso as interfaces de acesso seriam as janelas do sistema, shells, etc.) ou podem ser outros sistemas (e as interfaces de acesso seriam interfaces de comunicação entre processos, interfaces de programação de aplicações, etc.). Além das interfaces de acesso, o SOC também possui algumas interfaces provedoras, que são as interfaces utilizadas pelo sistema para acessar os serviços providos por outros sistemas (APIs de sistema operacional, interfaces de comunicação entre processos, etc.). As interfaces de acesso especificam apenas quais serviços serão oferecidos pelo SOC e como eles podem ser acessados pelos seus clientes. Elas poderiam ser pensadas como sendo contratos de prestação de serviços que o SOC se compromete a prestar. No entanto, para que possam ser prestados, tais serviços precisam ter seus mecanismos de funcionamento implementados no interior do sistema. No modelo orientado a componentes de software, os componentes são responsáveis por implementar os serviços oferecidos pelas interfaces de acesso do sistema. Eles podem ser vistos como unidades funcionais básicas que podem ser interconectadas para prestação de um serviço. Ou seja, o serviço prestado por uma interface de acesso pode ser implementado por um conjunto de componentes de software interconectados.

A interconexão dos componentes, existentes em um repositório de componentes, para a construção de um sistema ocorre através das suas interfaces, que podem ser de dois tipos: as interfaces provedoras dos componentes – que são utilizadas para oferecer serviços a outros componentes do sistema; e as interfaces de acesso dos componentes – que podem ser utilizadas para acessar serviços de outros componentes. Assim sendo, um determinado componente pode fazer uso dos serviços implementados por outro componente do sistema sempre que sua interface de acesso estiver conectada na interface provedora do segundo componente. Uma representação gráfica de um repositório de componentes é feita na Figura 1.

Figura 1. Representação de um repositório com 20 componentes

A Figura 2 mostra uma configuração otimizada para o SOC. Este sistema oferece um conjunto de serviços aos seus usuários através das suas interfaces de acesso. Esses serviços são de fato implementadas pelos diversos componentes de software do sistema. Nesse sentido, as interfaces de acesso do SOC servem apenas para expor para os seus clientes as interfaces provedoras de alguns dos seus componentes, de forma a prover todas as funcionalidades do sistema. Sendo assim, toda interface de acesso do sistema deve estar conectada a uma interface

1368

provedora de algum dos seus componentes internos.

Figura 2. Representação de uma configuração otimizada para um SOC

Para que consigam implementar as suas funcionalidades, os componentes de software de

um sistema precisam fazer uso dos serviços que normalmente são providos por outros componentes. Essa necessidade dos componentes é expressa através das suas interfaces de acesso. As interfaces de acesso de um componente especificam quais serviços devem ser providos para que ele possa funcionar corretamente. Assim sendo, toda interface de acesso de um componente deve ser conectada a uma interface provedora de outro componente ou do próprio sistema, de forma que ele possa fazer uso dos serviços necessários para o seu funcionamento. Cada interface de acesso, seja ela do sistema ou de algum componente, só pode ser conectada a uma interface provedora que ofereça os serviços que a primeira necessita. Quando isso ocorre, diz-se que a interface provedora é compatível com a interface de acesso. Dessa forma, encontrar uma configuração otimizada para um sistema orientado a componentes consiste então em encontrar um conjunto de componentes interconectados de tal maneira que: todas as interfaces de acesso do sistema estejam conectadas a uma interface provedora de algum componente que seja compatível com a primeira; e que toda interface de acesso de cada componente presente no sistema esteja conectada a uma interface provedora compatível, seja essa interface provedora de algum componente utilizado na configuração ou do próprio sistema. Considerando que existe um custo associado ao uso de cada componente – que indica o quão adequado é o componente para o contexto de execução do sistema, o custo total de um sistema, que é representado pelo somatório dos custos associados a cada componente presente no mesmo, deve ser minimizado. 3. Formulação Matemática do POSOC Em termos de modelagem matemática, o POSOC pode se definido da seguinte maneira: Índices: i, j: índice dos componentes; i, j = 1, 2, ...,m; 0 é o índice do próprio sistema k: índice das interfaces de acesso; k = 1, 2, ..., n

1369

l: índice das interfaces provedoras Parâmetros: C: conjunto de componentes disponíveis A: conjunto das interfaces de acesso do sistema e dos componentes P: conjunto das interfaces provedoras do sistema e dos componentes Vi: custo de usar o componente i Dkl: igual a 1 se a interface de acesso k depende da interface provedora l Variáveis de decisão: Xi: igual a 1 apenas se o componente i for utilizado no sistema; caso contrário é igual a 0. Yikjl: igual a 1 apenas se a interface de acesso k do componente i estiver conectada na interface provedora l do componente j; caso contrario e igual a 0. Minimizar: ∑Vi × Xi

i∈C (1) Sujeito a: (∑ ∑Yikjl × Dkl ) − Xi = 0 i∈C, l∈P (2) j∈C k∈A ((∑ ∑Yikjl × Dkl ) − NACESSO × Xj) ≤ 0 j∈C, l∈P (3) i∈C k∈A Xi ∈ {0,1} i∈C (4) Yikjl ∈ {0,1} i∈C , k∈A, j∈C , l∈P (5) X0 = 1 (6)

Nessa formulação, a função objetivo (1) visa minimizar o custo total associado a utilização dos componentes. A restrição (2) estabelece que cada interface de acesso do componente i só pode estar conectada a uma interface provedora da qual é dependente, se o componente for utilizado. A restrição (3) indica que cada interface provedora p de todo componente ativo pode estar conectada a nenhuma ou no máximo NACESSO, que representa o número de interfaces de acesso pertencentes ao conjunto A e que possam ser atendidas por P. Finalmente, as restrições (4) e (5) definem as variáveis Xi e Yikjl como binários. E, finalmente, a restrição (6) estabelece o valor inicial para o índice X0, ou seja, indica se o componente X0 será utilizado. 4. Complexidade do Problema

Caso fosse feito um relaxamento nas restrições impostas pelo POSOC de tal forma que as interfaces de acesso do sistema pudessem ser conectadas a qualquer componente de software, independentemente das interfaces provedoras que este possui e que qualquer componente de software pudesse ser conectado a qualquer interface provedora do sistema, o problema de otimização possuiria uma solução trivial. Um relaxamento um pouco mais suave seria adotar um mecanismo que privilegiasse as configurações que possuíssem apenas conexões entre interfaces compatíveis em detrimento das

1370

soluções com conexões entre interfaces incompatíveis. Uma forma de alcançaar tal objetivo seria atribuir custos as conexões entre duas interfaces. Sempre que duas interfaces compatíveis estiverem conectadas em uma configuração, o custo da conexão entre elas será igual a zero. Em contrapartida, o custo associado a conexão entre duas interfaces incompatíveis deve ser bastante elevado. Através desse relaxamento nas restrições do POSOC, o problema ficaria resumido a: interconectar um conjunto de nós (interfaces provedoras e de acesso do sistema) através de nós intermediários (os componentes de software), minimizando o custo associado aos nós intermediários e as conexões entre os mesmos. Este problema já foi apresentado na literatura como sendo uma variação de um problema de Árvore de Steiner [Winter, 1997], denominado de Árvore de Steiner Estrela (ou Steiner Tree Star – STS) [Lee, 1996]. O STS consiste de m nós finais (equivalentes as interfaces provedoras e de acesso do sistema), que são interconectados através de n nós de Steiner (equivalentes aos componentes de software). Cada nó de Steiner j que é usado para conectar pelo menos um nó final ou outros nós Steiner é denominado nó de Steiner Ativo e incorrerá num custo fixo bj; cada nó final i deve ser conectado a exatamente um nó de Steiner ativo, incorrendo num custo de conexão Cij; dois nós de Steiner distintos j e k que são diretamente conectados incorrem um custo de conexão djk. O problema consiste em encontrar uma árvore de custo mínimo que englobe todos os nós destino através dos nós de Steiner selecionados [Lee, 1996]. O problema de Árvore de Steiner é NP-difícil [Lee, 1996]. Como o POSOC pode ser reduzido a um problema de Árvore de Steiner através do relaxamento nas suas restrições, pode-se afirmar que o primeiro é NP-difícil e, portanto, não possui solução em tempo polinomial. Nesse caso, a utilização de algoritmos heurísticos para obtenção de configurações próximas da ótima em um tempo razoável é uma boa abordagem. 5 Metaheurísticas

Nesta seção serão descritas as metaheurísticas ILS - Iterated Local Search e ACS - Ant Colony System para serem aplicadas ao POSOC. Estas metaheurísticas serão utilizadas para minimizar o custo da função objetivo (1).

f = ∑ fcomponente(i) , (7)

i i∈C Em (1), fcomponente é uma função calculada através de um mecanismo de avaliação de

componentes de acordo com o contexto de execução do sistema, sendo C o conjunto de componentes que compõe o sistema a ser avaliado. Este mecanismo baseia-se em descrições dos requisitos dos componentes (funcionais e não funcionais) em lógica fuzzy e na utilização de um motor de inferência para determinar o quão adequado é cada componente para o contexto de execução do sistema. Devido a sua complexidade, esse mecanismo de avaliação é apresentado em outros trabalhos [LEITE, 2006] e está fora do escopo deste. No presente trabalho deve-se considerar que cada componente está associado a um custo fixo de utilização. 5.1 Metaheurística ILS

O ILS é um método de busca local que consiste em explorar um subespaço de soluções através de pertubações sistemáticas de estruturas de vizinhanças. Ao contrário de outras metaheurísticas baseadas em busca local, o método ILS não segue uma trajetória, mas sim explora vizinhanças gradativamente mais "distantes" sem se preocupar com a melhora da solução atual (movimento de shaking ou perturbação) na tentativa escapar de ótimos locais e focaliza a busca em torno de uma nova solução se, e somente se, um movimento de melhora é realizado. Em geral, heurísticas de busca executam uma sucessão de trocas locais numa solução inicial que melhora iterativamente o valor da função objetivo ate um mínimo local ser encontrado. Ou seja, a cada iteração uma solução melhor s0 numa vizinhança N(s) da solução atual s é obtida, até que nenhuma melhoria seja encontrada.

1371

5.1.1 Um algoritmo ILS para o POSOC

A metaheurística ILS foi empregada como um procedimento de melhora intensiva de solução, sendo utilizado em conjunto com a metaheurística GRASP [LEITE, 2007] para a crição da metaheurística híbrida GILS. A solução gerada previamente pelo procedimento GRASP é passada para o ILS que procura por vizinhos progressivamente mais distantes na tentativa de sair de ótimos locais. O algoritmo procura na solução anterior por componentes que possuam custos altos e, sobre estes componentes, é executado um movimento SWAP, ou seja, o componente anterior é trocado por outro possivelmente menos custoso para solução. Caso esse movimento implique redução do custo global, a solução final é atualizada. Feito isso, a vizinhança desta nova solução ainda e intensificada na busca local, o qual tenta achar outro valor melhor nas vizinhanças da nova solução. O algoritmo termina quando o número máximo de iterações for alcançado. Na especificação do algoritmo ILS para o POSOC assumir-se-á que o conjunto C, com |C| = n, representará o conjunto de todos os componentes existentes no repositório, enquanto que o conjunto M, com |M| = m, representará o conjunto dos componentes que fazem parte da configuração montada para um SOC. Será considerada ainda a existência de duas listas: A e P, sendo A o conjunto de interfaces de acesso do sistema e dos componentes presentes em M, que ainda não foram conectadas a interfaces provedoras na solução; e P o conjunto das interfaces provedoras do sistema e dos componentes presentes em M. 5.1.1.1 Movimentos de Busca Local

Na fase de busca local, as soluções vizinhas à solução obtida na fase de construção serão geradas utilizando-se o movimento de perturbação SWAP e DROP. Assim, dada uma solução viável S, tenta-se, iterativamente, melhorar o valor da função objetivo (1) de S, com movimentos que consistem em: • SWAP: corresponde a uma troca de componentes, isto é, um componente c, que está integrando a solução S, será substituído por outro componente que possua interfaces provedoras em comum com c, e que pelo menos uma dessas interfaces em comum de c esteja conectada a alguma interface de acesso em S. • DROP: corresponde a remoção de um componente c, que está integrando a solução S.

Com a remoção de um dos componentes, as interfaces de acesso que estavam ligadas nas interfaces provedoras do componente removido voltarão a integrar a lista A, havendo a necessidade da reconexão destas interfaces de acesso com outras interfaces provedoras, tornando a solução viável novamente, no caso da vizinhança DROP, se após a remoção do componente não existir na solução interfaces provedoras que atendam as interfaces de acessos que ficarem desligadas, a avaliação da solução será penalizada para que a mesma seja descartada pelo algoritmo GRASP. O algoritmo utilizado na vizinhança SWAP da Busca Local está descrito na Figura 3. Algoritmo Vizinhança-SWAP(A, P, C, s, c1) 1. S = s; // Solução atual 2. S = S - {c1}; // Remove o componente c1 3. C2 = { c∈C | c possua alguma das interfaces provedoras de c1 que estão conectadas} 4. c2 = {c∈C2 | c é o componente de melhor avaliação de C2 por g(c) } 5. S = S ∪ {c2}; 6. P = P - { provedoras(c1) } // Remove de P as interfaces provedoras de c1 7. A = A - {acesso(c1) } // Remove de A as interfaces de acesso de c1 8. A = A ∪ {acesso(c2)} // Adiciona as interfaces de acesso de c2 a A 9. P = P ∪ { provedoras(c2) } // Adiciona as interfaces provedoras de c2 a P

1372

10. tornarSolucaoViavel(A, P, C, s) 11. retorne s

Figura 3. Algoritmo da vizinhança SWAP

A função g(c), apresentada na linha 4, é uma função gulosa que é a razão entre o valor atribuído ao componente c pela função fcomponente, e o número de interfaces provedoras do componente c representado por np, somado a minFcomponente, que representa o menor valor atribuído a um componente pertencente a C, multiplicado por na, representando o número de interfaces de acesso A, sendo definida como:

g(c) = (fcomponente(c) / np) + na * minFcomponente (8) A idéia da função g(c) é garantir que componentes que tenham maior número de

serviços (interface provedoras) tenham maior chance de ser escolhido, já os que possuam maior número de dependências (interfaces de acesso) tenham menor chance de ser escolhidos.

A função tornarSolucaoViavel() que se encontra na linha 9 do algoritmo da Figura 3, é responsável por encontrar interfaces provedoras que são conectadas nas interfaces de acesso que voltaram a integrar a lista A, podendo ser utilizadas as interfaces de componentes que já estão na solução ou interfaces de novos componentes que devem ser adicionados a mesma.

Estas trocas possibilitam a formação de soluções vizinhas à solução corrente S. A vizinhança é gerada de forma determinística, onde todos os possíveis vizinhos a uma solução S serão gerados. É utilizada a estratégia do melhor vizinho (best improvement) na vizinhança, ou seja, a solução corrente S é atualizada na medida em que se encontra uma solução melhor na sua vizinhança. A Figura 4 mostra o procedimento ILS na fase de intensificação da solução inicialmente gerada pela metaheurística GRASP [Leite, 2007]. procedimento ILS(s0) 1. Seja s0 uma solução inicial 2. s ← BuscaLocal(s0) // inicializa a busca local na solução inicial 3. enquanto (a condição de parada não for satisfeita) faca 6. s' ← Pertubacao(histórico, s) 7. s" ← BuscaLocal(s') 7. s ← CriterioAceitacao(s, s", historico) 15. fim-enquanto 17. retorne s fim ILS.

Figura 4. Algoritmo ILS para o POSOC 5.2 Metaheurística ACS

O algoritmo Colônia de Formigas ou Ant Colony Systems (ACS) é inspirado no comportamento biológico natural de uma colônia de formigas, em particular, no comportamento de procura por alimento. A colônia de formigas é formada por seres simples. Um formigueiro como um todo é um sistema complexo cujo comportamento é mais inteligente do que os das formigas que o formam. É este grupo organizado de agentes que possibilita a solução de problemas complexos a partir do conhecimento compartilhado durante o espalhamento destes agentes, resultando da interação de centenas ou milhares de indivíduos que se engajam para encontrar o melhor caminho do ninho até o alimento. A comunicação indireta entre uma colônia de agentes ou formigas (ants) é baseada em trilhas (caminhos ou trajetos) de feromônio que é um tipo de informação numérica distribuída que é atualizado pelas formigas para refletir sua experiência na tentativa de resolução de um problema em particular.

1373

Na tentativa de encontrar o caminho mais curto para uma fonte de alimento sem a utilização de dados visuais as formigas depositam no solo certa quantidade de feromônio θ e seguem seu deslocamento baseadas nesse rastro de feromônio. Estas trilhas podem ser observadas por outras formigas e motivá-las a seguir determinado caminho, isto é, o movimento aleatório das próximas formigas será afetado com maior probabilidade de seguir a trilha com a maior quantidade de feromônio. Esta metaheurística foi escolhida para intensificar as soluções computadas pela heurística híbrida GILS, descrita na seção 5.1. O ACS tenta procurar na vizinhança soluções melhores, na tentativa de escapar de ótimos locais. O algoritmo termina quando o número máximo de iterações é atingido. 5.2.1 Fase de Refinamento O principal fator a ser considerado na configuração automática de um SOC é identificar quais componentes, a partir do contexto atual do sistema, devem ser inseridos para satisfazer as dependências do sistema em termos de serviços demandados. O algoritmo ACS inicia construindo aleatoriamente um repositório composto de um subconjunto de componentes mais adequados ao contexto de execução do sistema. Este repositório é iniciado com uma quantidade inicial de feromônio que é adicionado ao caminho relativo a solução inicial, com isso as formigas tendem a procurar probabilisticamente por soluções vizinhas a solução inicial. Quantidades pequenas de feromônio aumentam a dispersão das formigas, ou seja, aumentam a probabilidade de espalhamnto da solução inicial, em contra partida, grandes quantidades de feromônio induzem as formigas a seguir um caminho determinado, ou seja, as soluções geradas tenderão a estar na vizinhança da solução inicial. O algoritmo da Figura 5 apresenta os parâmetros passados bem como o efeito que os mesmos podem ter sobre o algoritmo procedimento ACS(T0 , Q0 , β , s) 1. s* ← s; 2. faca ΔTij ← 0; para todo arco (i, j) 3. faca Tij ← T0 ; para todo arco referente a solução 4. enquanto (condição de parada nao for satisfeita) faca 4. para (cada formiga k=1, ..., m) faca 5. c = s[0]; // seleciona o primeiro componente de solução (sistema) 6. Rk ← buscarRota(); busca uma solução a partir do componente c 7. Lk ← comprimento(Rk ) 8. se (Lk < f(s*)) entao 9. s* ← Rk 10. // Calcule a quantidade de feromônio deixado por cada formiga K 11. se (arco(i, j) ∈Rk ) entao 12. ΔTij (k) ← dij (Q/Lk ); 13. senao 14. ΔTij (k) ← 0; 15. faca ΔTij ← ΔTij + ΔTij (k) 16. Tij ← β * Tij + ΔTij 17. fim-enquanto 18. s ← s*; 19. retorne s fim ACS.

Figura 5. Algoritmo ACS para o POSOC 6. Resultados Computacionais

1374

Nesta seção, apresentamos os resultados computacionais obtidos com a heurística híbrida GILS proposta para melhorar as soluções geradas puramente pela metaheurística GRASP, bem como os resultados obtidos com a metaheurística ACS proposta para intensificar as soluções otimizadas da heurística GILS. As metaheurísticas foram implementadas utilizando a linguagem C++. Todos os experimentos computacionais foram realizados em um computador com o sistema operacional Slackware 12.0, kernel 2.6.21.5, com o processador AMD Athlon 64 X2 Dual Core TK-55, e com 1024 MB de memória DDR2. Antes de apresentarmos os resultados obtidos, mencionaremos os valores adotados para os parâmetros da meta-heurística GRASP. Estabelecemos que o número máximo de iterações, denotado por NUM_MAX_ITER, fosse igual a 100. Os valores escolhidos para α, parâmetro que representa o grau de aleatoriedade da função gulosa para a avaliação de um componente durante a fase de construção na metaheurística GRASP, pertencem ao conjunto H = {0.5, 0.6, 0.7, 0.8, 0.9, 1.0}. Devido à ausência de um conjunto de instâncias testes na literatura, foram geradas diversas instâncias de forma aleatória, segundo uma distribuição uniforme, com número de componentes N = {20, 30 , 50, 60, 80, 100, 500, 1000, 2000, 5000} e número de níveis K = {5, 10, 20}, o nível representa o tamanho do caminho, em termos de número de componentes, entre o primeiro e o último componente do sistema. Os componentes de cada instância são gerados de forma aleatória, no que diz respeito a quantidade de interfaces de acesso e provedoras. Os valores utilizados para a avaliação dos componentes foram gerados aleatoriamente no intervalo de [50, 150] para cada serviço que o mesmo fornece. 6.1 Resultados para ILS Os testes realizados pela metaheurística GRASP retornaram bons resultados, contudo para instâncias muito grandes o custo das soluções ainda difere muito, em outras palavras, não converge sempre para boas soluções. O GRASPf, como descrito em [LEITE, 2006], conseguiu resultados um pouco melhores, mas com um tempo computacional duas ou três vezes maior que o tempo gasto pela metaheurística GRASP. Com base no fato apresentado, adicionamos a metaheurística ILS na fase de refinamento do algoritmo GRASP, a fim de intensificar a busca por melhores soluções finais, permitindo uma convergência mais rápida das soluções. Para os testes realizados na Tabela 1, foram executadas as metaheurísticas GRASP e a variação GRASPf com alfa igual a 0.5, e, ao final de cada iteração dos algoritmos GRASP e GRASPf, iniciamos a metaheuristica ILS com a melhor solução encontrada até o atual momento. A coluna C representa a instância de componentes, as colunas Zavg representa a média de seis execuções das metaheurísticas, a coluna t(s) mostra o tempo médio das 6 execuções e as colunas ∆avg1 ∆avg2 mostram o ganho percentual da metaheurística GILS com relação aos resultados encontrados pelas metaheuristicas GRASP e GRASPf respectivamente.

Instância GRASP GRASPf GILS Nível C Zavg t(s) Zavg t(s) Zavg t(s) ∆avg1 ∆avg2

10 100 1594 0.056 1468 0.100 1349 0.628 15.3 8.0 10 500 1393 0.053 1126 0.120 645 0.506 53.6 42.6 10 1000 1619 0.082 1370 0.197 703 0.638 56.5 48.6 10 2000 1564 0.081 1283 0.284 592 0.528 62.1 53.7 10 5000 1342 0.114 1055 0.745 538 0.549 59.9 49.0 20 100 4802 0.186 4592 0.247 4348 2.041 9.4 5.3 20 500 3746 0.186 3165 0.279 1965 2.017 47.5 37.9 20 1000 3632 0.183 3283 0.313 1769 1.886 51.2 46.1 20 2000 4191 0.236 3570 0.490 1642 2.058 60.4 54.0 20 5000 4041 0.297 3527 1.026 1417 2.177 64.9 59.8

Tabela 1. Analise comparativa da metaheuristica hibrida GILS

Observamos que a adição do passo de refinamento aumentou muito a qualidade das soluções finais, com ganho de ate 64% sobre o GRASP e 59% sobre o GRASPf. Com isto

1375

podemos concluir que o GILS e mais eficiente que a metaheurística GRASP. 6.2 Resultados para ACS Como visto na seção 5.2.1, a metaheurística ACS deveria utilizar um subconjunto de componentes mais adequados a composição do sistema final, ao contrário dos testes realizados com a metaheurística GILS o qual utilizava uma instância completa de componentes. Isto nos permitiu agilizar o tempo gasto para computar novas configurações otimizadas sem grandes perdas da qualidade das soluções. A Tabela 2 apresenta o estudo do comportamento da metaheuristica ACS a partir da variação do tamanho do subconjunto de componentes utilizado para gerar as novas configurações. Nesta Tabela, observamos que a variação do gap não foi tão evidente, ou seja, foram mantidas quase de forma constante para diferentes instâncias de componentes. Isto pode ser concebido devido a robustez da função que avalia os componentes para a construção dos subconjuntos de componentes. A coluna gap mostra o ganho percentual da metaheurística ACS com relação aos resultados encontrados pelas metaheuristicas GILS mostrados na Tabela 1. Instância ACS

N l C 20% gap 40% gap 60% gap 80% gap 100% gap íve10 1 2 3 3 3 3 00 1307 .54% 1300 .02% 1300 .02% 1294 .51% 1294 .51%10 500 637 0.00% 642 0.00% 638 0.00% 637 0.00% 0.00% 64010 1000 698 0.00% 681 0.00% 706 0.37% 696 0.38% 697 0.00% 10 2000 5 0.00% 5 0.00% 5 0.57% 5 0.00% 575 0.00% 81 80 83 7810 5000 535 0.06% 533 0.00% 535 0.00% 536 0.00% 534 0.00% 20 100 3823 12.07% 3804 12.51% 3823 12.06% 3824 12.03% 3838 11.72% 20 5 1906 0.00% 1928 0.45% 1927 0.22% 1930 0.51% 1945 0.01% 0020 1000 1674 0.49% 1628 2.60% 1700 0.16% 1631 0.06% 1682 0.00% 20 2 1 1 1 000 603 1.86% 594 0.77% 631 0.00% 1608 0.33% 1615 1.79% 20 5000 1329 0.00% 1292 1.45% 1341 1.11% 1294 1.56% 1359 0.00%

Tabela 2. Estudo da va anho do subc o de com

Pro uin ste oi m do râm os para que ficassem ide a lo er os e ul ol cme res c s, p o S

Os testes utilizaram a configuração inicial: feromônio inicial igual a 50, parâmetro

riação do

s, f

tam

ito

onjunt

os p

ponentes

sseg do com ev

os tentes qu

fe ures obt

eiam

stu d a melhor

etr da metaheurística ACS tados, sis va s res uções om os

lho usto ara OC. β

igu 0.3 um de as al ir desta configuração inicial, cada uparâmetros do f variando den dos conjunto 0 , [0.1, 0.2, 0.3, 0.4, 0.5] e [100, 150, , p am p t d est cl melhores re ltado eram consegu os para a co uração 30, 0.1 e 200, para o feromônio

icial, a const

al a e ncita

ero oi

formig igutro

a 100. A parts [10, 30, 50, 7

m dos , 90]

200su

250, 3s

00], res ectivid

ente. A ós onfig

ermino os t es, con uímos que os

ante de evaporação β e número de formigas, respectivamente. in

Figura 6 - Estudo do tempo computacional gasto por GILS e ACS

A Figura 6 mostra um estudo realizado para avaliar o tempo computacional gasto para

1376

computar os resultados da metaheuristica ACS com base no tempo gasto para computar as configurações otimizadas a partir da heuristica hibrida GILS. Para esta avaliação foram utilizados os 30, 0.1 e 200 mostrados no parágrafo anterior, em conjunto com subconjunto de componentes com 10%, 20% e 30% de componentes. Subconjuntos com tamanhos maiores iriam produzir soluções computacionalmente muito caras, por este motivo foram excluídas dos testes.

Observamos, principalmente para o subconjunto com 10% de componentes, uma redução no tempo computacional para o cálculo de uma nova configuração a partir da metaheuristica ACS. Apenas a última instância apresentou um comportamento indesejável do ponto de vista do tempo gasto para a reconfiguração. Ainda assim, na média, o crescimento do tempo e muito mais lento na metaheurística ACS, ao contrário da metaheurística híbrida GILS que cresce de maneira linear com base no tamanho das instâncias. 7 Concl

ristensen, T., Plagemann, T., Rafaelsen, H. (2000) “MULTE-ORB: Adaptative

Tree-Star forms Journal on Computing, Vol. 8, No. 3, 100-120.

randomized adaptive search procedures (GRASP)”, Encyclopedia

usões Com a hibridização das heurísitcas GRASP e ILS para a formação de GILS pudemos

obter resultados até 64% melhores que os resultados encontrados originalmente em [Leite, 2007]. A adição da metaheurística ACS permitiu aumentar ainda mais a qualidade das soluções obtidas previamente pela heurística híbrida GILS a partir de um subconjunto reduzido de componentes criados com os componentes mais adequados a construção do sistema computacional. Referências Curtis, B. (1989) “Cognitive Issues in Reusing Software Artifacts”, Software Reusability, Vol. II, ACM Press, New York, pp 169-287. Agha, G. (2002) “Adaptative Middleware”, Communications of the ACM, vol. 45, No. 6, pp 31-32. Eliassen, F., KQoS Aware Binding”, Workshop on Reflective Middleware (RM 2000), New York, USA. Kon, F., Costa, F., Blair, G., Campbell, R. (2002) “The Case for Reflective Middleware”, Communications of the ACM, 45 (6): 33-38. Lange, B., Mother, T. (1989) “Some Strategies of Reuse in an Object-oriented Programming Enviroment”, Human Factors in Computing Systems, ACM Press, pp. 69-73. Lee Y. Chiu S. Y., Ryan J. (1996) “A Branch and Cut Algorithm for the SteinerProblem”, InResende, M. (2001) “Greedyof Optimization, vol. 2, pp. 373-382, Kluwer Academic Press. Tripathi, A. (2002) “Challenges Designing Next-Generation Middleware Systems”,

cations of the ACM, 45(6):39-42. CommuniVenkatasubramanian, N. (2002) “Safe ‘Composability’ of Middleware Services”, Communications of the ACM, vol.45, no.6, pp.49-52. Vogt, M., Plattner, B., Plagemann, T., Walter, T. (1993) “A Run-time Enviroment for Da CaPo”, INET’93 - International Networking Conference, Internet Society. Winter, P., Zachariasen M. (1997) “Euclidian Steiner Minimum Trees: An Improved Exact

ol. 30, No. 3, 149-16Algorithm, Networks”, V 6. Leite, L.; Farias, G.; Souza, G.; Meira, S.; ”Uma Metaheurística GRASP para Otimização de Sistemas Orientados a Componentes de Software”, Anais do Simpósio da Sociedade Brasileira de Pesquisa Operacional, 2007 Leite, L., Lima, O., Filho, G., Meira, S. ”Uma arquitetura de serviço para a avaliação de contextos em redes de TV digital”, Centro de Informática, UFPE, LAVID, UFPB, 2006

1377