Arquitetura Orientada a Serviços como Base para Implementação de um Algoritmo Evolucionário Paralelo

Transcrição

1 Arquitetura Orientada a Serviços como Base para Implementação de um Algoritmo Evolucionário Paralelo André de Oliveira Gomes 1, Maury Meirelles Gouvêa Jr. 2 1 Instituto de Ciências Exatas e Informática 2 Instituto Politécnico Pontifícia Universidade Católica de Minas Gerais Belo Horizonte, Brasil andreog.ti@gmail.com, maury@pucminas.br Abstract. In dynamic optimization problems, where the optimal solution varies over time, an evolutionary algorithm (EA) performs well when one or more of its parameters are adaptive. However, an EA requires a large computational effort, due to the operations that need to be performed to simulate an evolutionary process. This paper presents an alternative that reduces the processing limitation of EAs in dynamic problems using service-oriented architecture. This approach provides a large processing capacity with parallel computing. The results of the experiments were promising in both processing time and the quality of the solution. Resumo. Em problemas de otimização dinâmicos, onde a solução ótima varia com o tempo, um algoritmo evolucionário (AE) apresenta um bom desempenho quando um ou mais de seus parâmetros são adaptáveis. Entretanto, um AE demanda grande esforço computacional, devido às operações que são realizadas para simular o processo evolucionário. Este artigo apresenta uma alternativa para reduzir a limitação de processamento dos AEs em problemas dinâmicos com a utilização de uma arquitetura orientada a serviços. Essa abordagem fornece um grande poder de processamento através de computação paralela. Os resultados dos experimentos foram promissores tanto no tempo de processamento quanto na qualidade da solução. 1. Introdução A tecnologia de informação (TI) vem sendo utilizada na maioria das soluções apresentadas para os mais diferentes problemas, a fim de aumentar sua eficiência, precisão e, sobretudo, agilidade. A aplicação de sistemas de informação para resolução de problemas geralmente é muito satisfatória, principalmente em comparação com métodos alheios a TI. Para problemas complexos, vêm surgindo algoritmos cada vez mais eficientes, em qualidade e tempo de execução, principalmente devido à evolução do poder computacional. Ainda assim, certos algoritmos, como os evolucionários (EIBEN; SMITH, 2003), necessitam de um grande poder de processamento para encontrar soluções ótimas ou sub-ótimas, devido às várias operações, como mutação e cruzamento, que devem ser feitas para simular o processo evolucionário. Essas operações geram algumas restrições, como, por exemplo, o tempo para se chegar a uma

2 solução adequada. Restrições desse tipo podem tornar necessária a redução das iterações realizadas pelo algoritmo, o que possivelmente prejudicará o resultado final apresentado por ele. Outra restrição do algoritmo evolucionário (AE) é a limitação de dispositivos onde ele pode ser utilizado. Isso se dá porque, como o algoritmo necessita de um grande poder de processamento para apresentar boas soluções, os componentes de hardware mais simples não conseguem executá-lo satisfatoriamente, seja por tempo para se chegar ao objetivo ou pela baixa qualidade da solução apresentada. Em ambientes dinâmicos, onde a melhor solução pode variar com o tempo, o algoritmo deve se adaptar a nova situação o mais rápido possível. Uma solução é reiniciar o processo de otimização, mas para alguns problemas esta solução pode ser muito demorada e até inviável. A adaptação do AE em ambientes dinâmicos tem sido considerada em diversos estudos (BUI et al., 2005; GREFENSTETTE, 1992; SIMÕES; COSTA, 2002). Entretanto, as abordagens que tratam ambientes dinâmicos produzem um grande esforço computacional. A proposta desse artigo é buscar a solução dos problemas de tempo e local de processamento do AE, utilizando como base para sua implementação a arquitetura orientada a serviços (SOA, do inglês Service Oriented Architecture) e alguns padrões de estruturação de código e disponibilização de funcionalidades (SORDI et al., 2006). Através da SOA, é possível garantir um processamento paralelo do algoritmo em um sistema distribuído, reduzindo o tempo de resposta e possibilitando sua utilização em locais que não possuem grandes capacidades de hardware. Com o tempo reduzido, podem-se aplicar técnicas de controle paramétrico para tornar o AE mais adaptativo a ambientes dinâmicos, o que aumenta expressivamente a qualidade das soluções neste tipo de cenário (GOUVÊA; ARAUJO, 2007). O restante deste artigo está estruturado como segue. Na Seção 2, são apresentados conceitos e definições de SOA. Na Seção 3, a SOA implementada para execução do AE paralelo é detalhada, apresentando as ferramentas utilizadas para a elaboração da arquitetura, a seleção dos serviços e as configurações necessárias para o funcionamento da arquitetura. Na Seção 4, são apresentados os experimentos realizados para validação do algoritmo proposto. Os resultados são analisados do ponto de vista do tempo e da qualidade da solução. Na Seção 5, são apresentadas as conclusões e sugestões para trabalhos futuros. 2. Arquitetura Orientada a Serviços (SOA, do inglês Service Oriented Architecture) O paradigma de utilização e desenvolvimento de software tem mudado muito nos últimos anos, principalmente com a evolução das tecnologias e com o aumento da necessidade de utilizá-las. Essa evolução tem acontecido devido a diversos fatores, como o aumento do potencial dos componentes de hardware, que possibilita a utilização de recursos mais avançados. Outro fator importante foram os estudos e propostas de mudanças na forma com que os sistemas são construídos. Essa mudança vai desde os processos de desenvolvimento, como a engenharia de software, até os processos de estruturação dos componentes do sistema, a arquitetura de software (PRESSMAN, 2006). Durante muito tempo o desenvolvimento de software seguiu o paradigma estrutural, onde existiam blocos de código responsáveis por realizar determinadas

3 tarefas. Estas estruturas se dividiam em funções e procedimentos, que executavam comandos linearmente, baseados em uma ordem de passos, e geravam resultados. Em seguida, surgiu o modelo de orientação por objetos (OO), que aproxima a forma com que as soluções de software são elaboradas da forma com que as pessoas fazem naturalmente (SEBESTA, 2005). O paradigma orientado a objetos utiliza-se largamente de conceitos como encapsulamento, alta coesão e baixo acoplamento, visando tornar as soluções mais legíveis, claras e modulares. Isso permite que haja grande reutilização dos códigos gerados e que as manutenções necessárias sejam realizadas sem maiores dificuldades (SOMMERVILLE, 2003). Para colocar em prática os conceitos supracitados, metodologias como padrões de projeto (GAMMA et al., 1995) e padrões de arquitetura de software (FOWLER, 2003) estão sendo cada vez mais utilizadas no desenvolvimento dos sistemas. Diz-se por arquitetura de software a organização fundamental de um sistema, incorporados em seus componentes, suas relações entre si e com o ambiente, e os princípios que orientam o seu desenho e evolução (ANSI/IEEE, 2000). SOA é uma arquitetura de software cujos principais componentes são serviços, disponíveis para consumo das aplicações. Os serviços são funcionalidades com objetivos bem claros e contratos bem definidos, seguindo os conceitos de encapsulamento e coesão. O importante é saber o que o serviço faz, onde ele está acessível e como fazer para utilizá-lo, sem a necessidade de saber como ou onde ele foi implementado (HUHNS; SINGH, 2005). A forma com que estes serviços são desenvolvidos independe de plataforma ou linguagem de programação, e sua utilização também mantém essa transparência. Na SOA, utiliza-se a funcionalidade disponibilizada pelo serviço, sem a preocupação de saber o que ele utiliza ou executa para prover uma resposta, desde que o resultado tenha qualidade e eficiência (TURNER et al., 2003). Os serviços são hospedados em servidores, ou provedores de serviços, responsáveis por receber uma requisição, processá-la e, se necessário for, devolver uma resposta. 3. Implementação do AE Utilizando a SOA A utilização do controle paramétrico tem como objetivo produzir um algoritmo evolucionário mais adaptável ao ambiente, apresentando soluções melhores em problemas dinâmicos (GOUVÊA; ARAUJO, 2007). Uma das formas de tratar problemas dinâmicos com AEs é criar diversas populações, cada uma delas com uma diferente estratégia de controle paramétrico (BRANKE; SCHMECK, 2003). No entanto, essa filosofia pode aumentar muito o esforço computacional, até mesmo tornando o AE inviável para determinados problemas. Com a computação paralela utilizando a SOA, cada população, com sua própria estratégia de controle paramétrico, tem seu processo evolucionário executado em um computador ou núcleo de processamento distinto, garantindo o paralelismo e viabilizando respostas praticamente simultâneas a cada ordem de execução. Além de proporcionar melhorias em desempenho, a utilização da SOA possibilita o acesso a este tipo de solução de qualquer dispositivo provido de tecnologia para chamadas remotas, como a Internet.

4 Neste trabalho, as ferramentas utilizadas para elaboração da SOA são detalhadas a seguir. Como API de desenvolvimento, foi utilizado o Windows Communication Foundation (WCF), por possuir todas os atributos de qualidade necessários para o desenvolvimento do AE baseado em SOA. A linguagem escolhida foi o C#, pois suporta o paradigma de programação orientada a objetos e a serviços, pela riqueza de bibliotecas em diversas áreas, pela grande quantidade de contribuições da comunidade de desenvolvimento de software e, principalmente, pelo ambiente integrado de desenvolvimento (IDE, do inglês Integrated Development Environment) da Microsoft, o Visual Studio Para disponibilização dos serviços criados foi escolhido como servidor web o IIS, por ser totalmente compatível com as demais ferramentas definidas. Com a SOA, tem-se duas propostas para aumentar o poder de processamento do servidor para que o tempo de resposta a cada solicitação seja reduzido, a saber: (i) hospedando os serviços do WCF em um servidor de configurações melhores ou (ii) hospedando os serviços em vários computadores, dividindo a carga de requisições entre eles. Dessa forma os processamentos se tornam paralelos e o tempo de resposta diminui. A alternativa (i) é mais simples, mas pode ser menos viável em relação aos custos e, principalmente, ao desempenho, quando for possível paralelizar várias tarefas do AE. A alternativa (ii) resolve esses problemas, mas necessita de algumas configurações que a (i) não demanda. A primeira necessidade para distribuição de processamento em vários computadores é que cada um deles tenha capacidade de processar o que for solicitado. Para isso, é necessário que os serviços estejam hospedados em todos aqueles computadores que precisem responder às requisições. A segunda necessidade é redirecionar as requisições que chegam dos clientes aos computadores disponíveis, balanceando a carga entre eles da maneira mais eficiente possível. Assim, chega-se a uma melhoria no tempo de resposta final do algoritmo. Para realizar esta tarefa, foi escolhido o Application Request Routing (ARR) Desenvolvimento da SOA Com as ferramentas e técnicas definidas, a SOA já pode ser implementada para execução do AE. A Figura 1 mostra a forma com que a arquitetura elaborada atende às necessidades do problema. Trata-se de uma estrutura do tipo cliente-servidor, onde os clientes podem ser dispositivos variados, como celulares, computadores, laptops e tablets. Esses clientes enviam requisições de execução do algoritmo evolucionário paralelo através de uma rede, como Internet ou rede local, que são recebidas por um servidor central, que distribui as solicitações aos provedores de serviços. Os pedidos são recebidos pelos provedores de serviços, que possuem as funcionalidades que serão consumidas, e devolvem uma resposta a quem a solicitou.

5 Seleção dos serviços Figura 1. SOA para atender a implementação dos AEs No AE baseado em SOA, foram estabelecidas duas abordagens distintas. Na primeira, há um único serviço, denominado DoGenerations, que recebe todos os parâmetros do AE, como população, ambiente, taxas de mutação e cruzamento, e executa o processo evolucionário, no servidor. Na segunda abordagem, transformam-se os diversos mecanismos evolutivos, como cruzamento e mutação, em serviços. Assim, é necessário separá-los de tal forma que fiquem coesos e tenham baixo acoplamento, i.e., não dependam uns dos outros para que suas tarefas sejam concluídas. Na segunda abordagem, foram levantados oito mecanismos evolutivos para se tornarem serviços, a saber: O cálculo da qualidade da solução ou fitness (CalcFitness): recebe uma população e um ambiente como parâmetros, e retorna a população com os fitnesses calculados; A obtenção do melhor fitness da população (GetBestFitness): recebe uma população e retorna um valor absoluto com a melhor solução; O cálculo do fitness médio da população (GetMeanFitness): tem a mesma interface do GetBestFitness, mas retorna o valor médio das soluções; A seleção dos melhores indivíduos da população (SelectIndividuals): recebe uma população e retorna outra com os indivíduos selecionados; O cruzamento entre indivíduos (Crossover): tem a mesma interface do SelectIndividuals, mas retorna a população após o cruzamento dos indivíduos;

6 A mutação dos indivíduos (Mutation): tem a mesma interface do SelectIndividuals, mas retorna a população após a mutação dos indivíduos; A inserção de indivíduos na população (InsertIndividuals) : tem a mesma interface do SelectIndividuals, mas retornar a população após inserir os indivíduos; e A variação do ambiente que o algoritmo está sendo executado (ChangeEnvironment): recebe um ambiente e o retorna alterado. Nas duas abordagens, a sequência de operações é realizada a cada geração do algoritmo evolucionário, como mostra a Figura 2. Figura 2. Fluxo de operações do AE Nenhum dos testes com a segunda abordagem mecanismos evolutivos transformados em serviços apresentou um tempo de resposta aceitável. Isso ocorreu porque a grande quantidade de bytes da população e de outros parâmetros transferida pela rede em cada uma das chamadas, multiplicada pela quantidade de

7 gerações, tem um custo computacional muito alto, que inviabilizou a execução do algoritmo evolucionário paralelo. Na solução da segunda abordagem, em uma única geração realiza-se 10 interações entre cliente e servidor. Por exemplo, se o AE executar 1 mil gerações para chegar a solução, serão aproximadamente 10 mil trocas de informações pela rede. Optou-se, portanto, por utilizar a primeira abordagem com apenas o serviço DoGenerations. Assim, todo o processo evolucionário, Figura 2, é executado no servidor, que reduziu consideravelmente o tempo total de resposta. Com a primeira abordagem, apenas duas trocas são necessárias, a chamada do algoritmo e a resposta do servidor, tornando o processo muito mais eficiente e rápido. A desvantagem dessa abordagem é a redução da flexibilidade de alterações na ordem de execução do AE por parte do cliente Configurações Realizadas nos Servidores Como mostra a Figura 1, a SOA utilizada para implementação do AE possui dois tipos de servidores: um central, denominado servidor web, e n provedores de serviços. O servidor web é responsável por receber todos os pedidos de execução do AE e distribuílos aos provedores de serviços, que os processam e devolvem a resposta ao servidor web. Após o término do processamento de todos os provedores de serviços que foram acionados, podem ser adotadas diversas estratégias para trabalhar com as respostas que chegaram. Uma dessas estratégias é definir a melhor população e adaptar os parâmetros das demais, para que se aproximem da resposta melhor avaliada. Outra alternativa é mudar os parâmetros anteriormente configurados, para que se faça um comparativo entre as respostas anteriores e as que chegarão após a nova tentativa. Uma outra estratégia é realizar a migração de indivíduos entre as populações resultantes do processo evolucionário, trocando indivíduos de uma população para outra. O servidor web e os provedores de serviços possuem configurações distintas, para que cada um cumpra seu papel na arquitetura. Nos provedores de serviços a configuração é mais simples, por ser significativamente automatizada pela IDE do Microsoft Visual Studio Assim, basta definir no projeto que ele será executado pelo IIS e solicitar a criação do diretório virtual no servidor, através da própria IDE. Caso o computador provedor de serviços não tenha o Visual Studio instalado ou acesso aos códigos fonte do AE, basta realizar uma publicação e disponibilizá-la localmente em cada um dos provedores de serviços, efetuando a criação do diretório virtual manualmente no IIS. Nestes computadores deve estar instalado um servidor web, que irá expor os serviços disponíveis, receber as solicitações do servidor central e respondê-las. Este trabalho utiliza o IIS 6.1 para essa finalidade. Como a SOA foi elaborada utilizando a tecnologia WCF mais atualizada, nos provedores de serviços também deve estar instalada a versão 4 da Framework.NET, elaborada pela Microsoft. Com estas ferramentas instaladas, eles já estão aptos a hospedar o AE implementado e, então, receber requisições de processamento deste algoritmo. O servidor central também necessita do IIS instalado, pelos mesmos motivos apresentados para os provedores de serviços. Entretanto, ele não precisa hospedar os serviços que representam o AE, nem ter a Framework.NET 4 instalada, uma vez que ele não fará nenhum processamento das requisições de execução, somente as distribuirá para os provedores de serviços. Para realizar essa distribuição, é necessário instalar uma ferramenta de roteamento dos pedidos. Neste trabalho, o ARR é utilizado para que esse

8 objetivo seja atendido. Ao instalar o ARR, criam-se opções no IIS para que sejam listados os servidores para os quais as requisições serão distribuídas, para que se defina a estratégia para tal distribuição, além de diversas configurações e métodos de acompanhamento dos servidores. Para este artigo, foram configurados dois servidores provedores de serviços e um servidor central, que balanceava a carga entre eles. O algoritmo de distribuição utilizado no ARR trabalha enviando a próxima requisição ao servidor livre que recebeu a menor quantidade de pedidos. Como os provedores de serviços possuíam configurações semelhantes e, consequentemente, tempos de respostas parecidos, essa estratégia demonstrou grande eficiência em relação às demais Utilização da SOA no Lado do Cliente Após a execução dos passos já citados, os usuários que irão utilizar os AEs baseados nessa arquitetura, denominados clientes, já podem realizar chamadas ou consumo aos serviços disponibilizados pelo sistema distribuído responsável por representar o AE. Para isto, os clientes necessitam apenas de conhecer seu EndPoint, i.e., seu endereço, definições de como acessá-lo (protocolos, métodos de segurança, etc.) e seu contrato (quais funcionalidades estão expostas por ele). O EndPoint dos serviços disponíveis pode ser descoberto através da IDE, quando se executa o WCF, ou através do servidor web, quando se procura o serviço hospedado. Com o EndPoint conhecido, existem diversas formas de consumi-los. Por se tratar de WCF, eles podem ser acessados por diversos protocolos e consumidos por sistemas das mais variadas linguagens. Para este artigo, foi desenvolvido um programa cliente sem interface gráfica, em C#, que realiza chamadas assíncronas ao serviço criado para representar o AE (DoGenerations). O local onde o serviço estava localizado foi adicionado como referência web da aplicação cliente e, a partir deste momento, existiam classes que, se instanciadas, permitiam acessar os serviços através de chamadas de seus métodos. Como o método DoGenerations recebe alguns parâmetros, como a população que passará pelo processo evolucionário, o ambiente onde o AE será executado, as taxas de cruzamento e mutação, o número de gerações, dentre outros, o programa cliente foi preparado para construir estes parâmetros e utilizar as técnicas de controle para tornar o AE mais adaptativo, variando as taxas supracitadas e a pressão de seleção do ambiente. Neste trabalho, o servidor central, os provedores de serviços e o cliente estavam em uma rede Ethernet, mas nada impede que cada um destes elementos esteja geograficamente distante dos outros. Por exemplo, podem-se configurar os servidores em um local e, de outro lugar, o cliente consumir os serviços disponibilizados através de um protocolo HTTP, desde que o dispositivo tenha acesso para isso. Outro exemplo é a configuração de um servidor web que divide as requisições aos provedores de serviços que estão espalhados em diversos pontos do país ou do mundo, e um celular, localizado em outra posição geográfica e com acesso à internet, faz o consumo dos serviços, através da URL fornecida pelo servidor central por um EndPoint. 4. Estudo Experimental Para validar o AE paralelo com SOA, proposto neste trabalho, foi realizado um experimento com três abordagens, a saber, o AE padrão (AEP), uma população sem controle de parâmetros em um computador; um AE com multipopulações (AEMP) em

9 um computador; e o método proposto, AE paralelo com SOA (AESOA). Foram consideradas três métricas para análise de desempenho: a média do melhor fitness da população durante o processo evolucionário, o desvio padrão dessa média e o tempo de execução. Para cada abordagem, foram realizadas cinco execuções para que fossem extraídos resultados médios das métricas de desempenho. O experimento realizado utilizou o problema da mochila, de otimização combinatória (SMITH; GOLDBERG, 1992). Nesse problema, o objetivo é maximizar a quantidade de objetos transportados em uma mochila considerando o valor e o peso de cada objeto. Assim, tem-se como objetivo Max n i1 v i x i (1) n s. a. w x C (2) i1 i sendo x i o número de unidades do i-ésimo objeto, v i e w i o valor e o peso desse objeto, respectivamente, e C o peso máximo suportado pela mochila. Para as abordagens dos AEs com multipopulações, foram utilizadas 11 populações com parâmetros evolutivos diferentes, a saber, as taxas de mutação e cruzamento e a pressão de seleção. As populações foram criadas com 120 indivíduos (N = 120), cada um com 10 genes (n = 10), taxa de seleção de pais igual a 0.5, taxa de reprodução igual a 0.5, seleções pelo método do torneio, com pressão de seleção igual a G / N, sendo G o tamanho do grupo do torneio. Os parâmetros evolutivos das 11 populações foram: a) Taxas de mutação de { 0.5, 0.1, 0.05 }; b) Taxas de cruzamento de { 0.5, 0.6, 0.7, 0.8 }; c) Pressões de seleção de { 0.02, 0.1, 0.2, 0.3 }. Em todos os experimentos, as populações evoluíram gerações, com variações aleatórias do peso máximo da mochila, C, a cada 100 gerações. O AESOA foi executado em três computadores, sendo que o primeiro foi utilizado pelas abordagens sem paralelismo: i Provedora de serviços 1: Intel Core i5 M GHz, 4GB RAM, com Windows 7 Home Premium 32 bits; Provedora de serviços 2: Intel Core i3 M GHz, 4GB RAM, com Windows 7 Ultimate 32 bits; Servidor de balanceamento: Intel Core i5 M GHz, 1.5GB RAM, com Windows 7 Professional 32 bits Resultados dos Experimentos Os resultados dos experimentos permitiram comparar a qualidade da solução e o tempo de execução das três abordagens. A primeira análise, qualidade da solução, mostrou que o método proposto, AESOA, foi mais eficiente, como mostra a Figura 3.

10 Na Figura 3, observa-se que um AE com multipopulações com diferentes parâmetros evolutivos tem desempenho muito superior em ambientes dinâmicos, quando comparado ao AEP. Nos modelos AEMP e AESOA, os fitnesses médios foram significativamente melhores que o do AEP. Também é possível observar que o AESOA apresentou melhor desempenho, pois teve maior fitness na maior parte do processo evolucionário, i.e., mais estável por crescer mais rapidamente após a mudança do ambiente. Figura 3. Comparativo do fitness entre as execuções do AE A Tabela 1 apresenta os resultados das três abordagens de AE testadas nos experimentos. Observa-se que a média do melhor fitness (MF) da população do AEP foi menor que dos AE com multipopulações em todas as execuções, assim como o desvio padrão (DP) muito mais alto, o que indica um MF mais disperso. Nota-se também que o AESOA teve solução pior que o AEMP em apenas uma execução, consequentemente tendo uma média melhor. O desvio padrão do método proposto também foi menor, o que indica menos dispersão das soluções em relação à média. A segunda análise, que compara os tempos de execução das três abordagens, apresentou uma vantagem ainda mais expressiva para a arquitetura proposta por este trabalho, como mostra a Figura 4. Como foram utilizadas dois computadores para dividir o processamento das populações, o ganho em tempo de resposta do AESOA em relação ao AEMP foi de aproximadamente 42,64%, i.e., um tempo quase duas vezes menor para se chegar a soluções ainda melhores. Espera-se que utilizando N computadores a redução no tempo de processamento do AESOA em comparação a um AE com multipopulações não-paralelo seja aproximadamente N vezes menor, desconsiderando os recursos de rede necessários para que este resultado seja obtido.

11 Tabela 1. Comparativo entre as três abordagens de AE Exec. AEP AEMP AESOA MF DP MF DP MF DP 1 122,56 49,10 209,19 14,87 205,08 13, ,54 92,96 200,72 14,86 205,08 13, ,52 68,00 203,08 13,27 206,37 14, ,56 71,98 202,75 14,04 203,46 12, ,97 76,18 204,04 14,69 208,15 14,03 Média 127,83 71,64 203,96 14,34 205,63 13,69 5. Conclusões Figura 4. Tempo de execução do AE entre os métodos AESOA e AEMP Este trabalho apresentou um algoritmo evolucionário paralelo, com multipopulações, utilizando a arquitetura SOA. Foram demonstradas formas de se utilizar a computação paralela e distribuída para tornar o AE mais eficiente e rápido em ambientes dinâmicos, com multipopulações com diferentes estratégias. Nos experimentos que validaram o método proposto, os resultados alcançados foram satisfatórios, tanto do ponto de vista de tempo de processamento quanto de desempenho. Em tempo de execução, concluiu-se que o AE com SOA é aproximadamente N vezes mais rápido que o modelo clássico, onde N é a quantidade de servidores disponíveis para distribuição da carga. Com a computação paralela e distribuída, diversas alternativas podem ser investigadas para que as soluções apresentadas pelo AE sejam ainda mais satisfatórias. Uma dessas alternativas é implementar migração entre as populações do AE paralelo.

12 Outra alternativa é implementar o controle de diversidade do AE paralelo, centralizando esse tarefa em um servidor e trocando informações entre os demais. 6. Referências Bibliográficas BUI, L. T.; BRANKE, J.; ABBASS, H. Multi-objective optimization for dynamic environments. In: Proceedings of the Congress on Evolutionary Computation. Edinburgh: IEEE press, BRANKE, J.; SCHMECK, H. Designing Evolutionary Algorithms for Dynamic Optimization Problems. In: Advances in Evolutionary Computing: Theory and Applications. New York: Springer , EIBEN, A. E.; SMITH, J. E. Introduction to Evolutionary Computing. Natural Computing Series. Springer, FOWLER, Martin. Patterns of Enterprise Application Architecture. Boston: Addison-Wesley, GOUVÊA JR., M. M., ARAUJO, A. F. R. Diversity-Based Model Reference for Genetic Algorithms in Dynamic Environment, 2007 IEEE Congress on Evolutionary Computation (CEC 07). Sep , GREFENSTETTE, J. J. Genetic algorithms for changing environments. In:. Parallel Problem Solving from Nature. [S.l.]: North-Holland, v. 2, p PRESSMAN, R. S., Engenheria de Software (6a edição). São Paulo, Editora McGrawHill, SEBESTA, Robert W. Conceitos de linguagens de programação. 5. ed. Bookman, Porto Alegre, SMITH, R. E.; GOLDBERG, D. E. Diploidy and dominance in artificial genetic search. Complex Systems, v. 6, n. 3, p , SIMÕES, A.; COSTA, E. Using genetic algorithms to deal with dynamic environments: a comparative study of several approaches based on promoting diversity. In: ALII, W. B. L. et (Ed.). Proceedings of the Genetic and Evolutionary Computation Conference (GECCO 2002). New York, USA: Morgan Kaufmann Publishers, SOMMERVILLE, I. Engenharia de Software. 6ª. Edição. São Paulo: Addison Wesley, 2003 SORDI, José Osvaldo de; MARINHO, Bernadete de Lourdes; NAGY, Marcio. Benefícios da Arquitetura de Software Orientada a Serviços para as Empresas: Análise da Experiência do ABN AMRO Brasil. Revista de Gestão da Tecnologia e Sistemas de Informação, Vol. 3, No. 1, 2006, p TURNER, M.; BUDGEN, D.; BRERETON, P. Turning Software into a Service. IEEE Computer, Outubro 2003.