Programacao Paralela em Engenharia de Software

Welton Luiz de Oliveira Barbosa1

1

Instituto de Ci ncia e Tecnologia - Universidade Federal Fluminense (UFF) e Jardim Bela Vista 28.890-000 Rio das Ostras RJ Brasil
weltonb@id.uff.br

Abstract. This Survey has as objective make a brief presentation on parallel programming, differentiating the concurrent programming, a concept very close to parallel programming. Are also addressed some topics of software engineering and demonstrations of applying parallel programming techniques applicable in those areas presented. Resumo. Este Survey tem como objetivo fazer uma breve apresentacao sobre programacao paralela, diferenciando-a de programacao concorrente, um con ceito muito pr ximo a programacao paralela. Tamb m s o abordados alguns o e a temas da engenharia de software e demonstracoes de aplicacao de t cnicas de e programacao paralela que s o aplic veis as areas apresentadas. a a

1. Programacao de Computadores
A programacao de computadores e um termo muito conhecido por todos os prossionais que atuam na area de computacao. Entretanto, esse termo n o ca restrito apenas a esse a segmento de prossionais. A programacao de computadores e realizada por meio de uma, ou mais, linguagens de programacao, inclusive h a possibilidade de se programar a diretamente em linguagem de m quina, sendo que nesta ultima e muito mais complicado a de programar devido a in meros fatores envolvidos, tais como arquitetura de m quina, u a manipulacao direta de registradores, etc. Com o passar dos anos foram surgindo cada vez mais linguagens de programacao, a maioria delas com a promessa de melhorar o desempenho ou garantir uma maior facilidade ao programador. Normalmente a escolha da linguagem a ser utilizada est de a acordo com determinados fatores como seguranca, ambiente em que o programa ir ser a implantado, desempenho, entre outros. Dentre as linguagens de programacao, as mais conhecidas s o: C, C++, Java, Objective-C, Python, PHP, JavaScript, Ruby, C#, ASP, a .NET, etc. Conforme o tempo foi passando, houve uma demanda de softwares mais elaborados e com melhores desempenhos, j que empresas comecaram a fazer o uso de software a para manter seus neg cios e at mesmo ganharem uma vantagem competitiva em relacao o e a seus concorrentes. Dessa forma, surgiu uma depend ncia de todo o Globo para com e ` os computadores. Como a perda de tempo a espera da execucao de programas n o e a comoda e tamb m e vista como perda de dinheiro para muitos, houve a necessidade de e uma evolucao dos hardwares e com isso, automaticamente, a evolucao dos software. Para que os softwares alcancassem tal performance foi necess rio uma melhora nos algorit a mos em busca de otimizacoes. Mesmo com todas as mudancas, os algoritmos ainda n o a conseguiam fazer um bom uso de todos os recursos dos hardwares. Como solucao, foi

proposta a quebra do ent o utilizado, paradigma sequencial, e trago a tona o paradigma a de programacao concorrente. 1.1. Programacao Concorrente e Paralela O termo concorr ncia est atrelado a independ ncia temporal, concorr ncia por recursos e a e e e at mesmo pela cooperacao entre diferentes indivduos (contribuicao). e A programacao Concorrente visa a exploracao de independ ncias temporais en e tre diferentes atividades das aplicacoes, visando explorar tal fator. Em computacao, este termo est sempre interligado ao compartilhamento de recursos tais como mem ria, disa o positivos de entrada e sada, processador(es), etc. Emprega-se tamb m este conceito para e buscar uma evolucao da aplicacao ao dividir areas independentes de tal modo que haja um melhor proveito dos recursos e uma cooperacao entre eles, com o intuito de dividir as tarefas entre eles. Com relacao ao paralelismo, h uma pequena diferenca entre ela e o conceito de a programacao paralela. Basicamente, o paralelismo e um tipo de atividade concorrente, contudo, faz o uso de recursos independentes, n o disputando estes. Para fazer uso de a ` programacao concorrente, de modo geral, continua com os mesmos passos aplicados a programacao linear, por m deve-se considerar novos itens como identicar as atividades e concorrentes, o compartilhamento de recursos e dados, al m da estrutura de colaboracao e entre as tarefas e o modo em que as atividades concorrentes ser o sincronizadas que, por a incrvel que pareca, e uma das partes mais trabalhosas e difceis a serem tratadas. Alguns dos objetivos de se utilizar a programacao paralela s o a reducao de tempo a de processamento, assim como a reducao de custos, j que para elevar ainda mais o desem a penho do hardware, atualmente, e necess rio um gasto muito elevado, devido as restricoes a dos materiais. Com isso, e mais proveitoso a utilizacao de um maior n mero de proces u sadores ecientes e mais baratos. Junto ao conceito de concorr ncia e paralelismo, surgiram algumas estruturas de e arquitetura de computadores visando obter maiores desempenhos e reducao de custo. Tais arquiteturas podem ser denominadas de in meras maneiras, entre elas, a mais conhecida u foi desenvolvida por Flynn em 1966, conhecida como taxonomia de Flynn. Neste modelo s o representados quatro (4) conjuntos diferentes de arquitetura, que s o SISD, SIMD, a a MISD e MIMD.

2. Engenharia de Software
Com o decorrer dos anos os softwares foram evoluindo e aumentando cada vez mais sua complexidade, cando praticamente invi vel ser desenvolvido por apenas um proa ` gramador. A adicao de novos programadores a equipe de desenvolvimento fez com que surgissem in meros problemas durante o ciclo de vida do sistema. Com o intuito de reu solver tais problemas surgiu uma grande area da computacao, a Engenharia de Software. [Sommerville 2001] A Engenharia de software est preocupada em desenvolver pesquisar e solucoes a para diversos temas de pesquisa, dentre eles destacamos os seguintes problemas: Requisitos de Software Ferramentas e M todos de Engenharia de Software e

Figure 1. Taxonomia de Flynn

Qualidade de Software Processos de Engenharia de Software Ger ncia de Engenharia de Software e Ger ncia de Conguracao de Software e Manutencao de software Teste de Software Construcao de Software Projeto de Software Sistemas Multi Agentes

Grande quantidade das sub areas da Engenharia de Software fazem auxlio de sistemas computacionais para proporcionarem um maior controle sobre os processos e tamb m os facilitar, assim como em diversas outras areas onde a computacao e uma fere ramenta indispens vel e at mesmo que pode inferir um diferencial para a empresa em a e relacao a seus concorrentes.

3. Requisitos de Software
As atividades de an lise concentram-se na identicacao, especicacao e descricao dos a requisitos do sistema de software. Em resumo, requisito e uma necessidade que o software deve cumprir. [Sommerville 2001] Em uma vis o alto nvel, Requisitos de Software e um conjunto de atividades dea sempenhadas por analistas cujos objetivos principais s o levantar as funcionalidades que a o sistema deve ter, especicar e descrever em mnimos detalhes cada um dos requisitos. Estes s o os requisitos funcionais. Existem tamb m, os requisitos n o funcionais, onde a e a s o especicados exig ncias que o software deve atender, al m das suas funcionalidades. a e e [Sommerville 2001] Em conjunto a esta tarefa, s o realizadas as modelagens do sistema, tais como a a descricao dos requisitos at a pr pria modelagem do sistema, em diferentes nveis de de e o talhamento. Durante esse processo, s o utilizadas ferramentas CASE, para a modelagem a do sistema. Tais programas possuem diversicadas funcoes, que podem ser realizadas independentemente umas das outras e geralmente n o s o realizadas, demandando muito a a tempo de processamento em determinadas horas e algum tempo ocioso em outra hora.

 Durante este processo, temos diferentes linhas de pesquisa atuando nesta area da Engenharia de Software, como por exemplo a Model Driven Development e o Design Rationale. 3.1. Model Driven Development (MDD) Como o pr prio nome diz, o mdd e um conceito que est sendo desenvolvido para gerar, a o a partir do modelo, criar novos modelos e at mesmo o c digo execut vel. Isto e realizado e o a em paralelo durante a construcao do modelo, onde sempre vai sendo revisado o metamod elo dos artefatos que est o sendo desenvolvidos e traduz para outro modelo com base no a anterior, tamb m, em seu metamodelo. Este e um processo arduo que demanda grande e nvel de processamento. Por m, o processo pode ser executado a cada nova alteracao no e diagrama trabalhado, pois em geral, modicacoes seguem um metamodelo e podem ser traduzidas de forma independente. Em [Marin et al. 2010] e possvel tomar conhecimento de algumas fragilidades do metamodelo da UML para fazer o uso do MDD. Neste mesmo artigo e proposto um metamodelo de qualidade para sustentar todos os princpios do model driven development de forma autom tica e criacao de modelos e c digos durante a fase de modelagem do a o sistema. 3.2. Design Rationale Resumidamente, Design Rationale e uma forma de representar todas as tomadas de decis es durante alguma etapa do processo de modelagem. No caso dos requisitos e o modelagem de software, ao fazer uso do design rationale, temos mapeadas informacoes necess rias para representar o raciocnio em torno da solucao do modelo proposto. a Uma pesquisa que envolve tal facanha e o projeto de um software, que executa em paralelo a uma ferramenta CASE, um sistema que ca supervisionando a modelagem do diagrama de classe pela ferramenta CASE e registrando as informacoes referentes as decis es (positivas e negativas) tomadas pelo analista. Um exemplo de software que o executa tal papel e o Kuaba [Medeiros 2006], onde foi proposto um metamodelo para representar todas as decis es tomadas durante a modelagem do diagrama de classes da o UML. Existe um programa KSE, que e uma extens o da ArgoUML, ferramenta de modea lagem de diagramas em UML, no qual e executado em paralelo a ArgoUML um programa observador que ca monitorando todos os passos realizados durante a modelagem de classes e esporadicamente realiza perguntas ao analista para registrar o conhecimento por tr s das decis es tomadas. Ao nal da modelagem, temos representado, todo o raciocnio a o por tr s do modelo. Tal tarefa s e possvel, devido ao paralelismo entre a ArgoUML e o a o plugin que e respons vel por transformar as acoes do modelo em uma representacao que a segue o metamodelo Kuaba.

4. Ger ncia de Conguracao de Software e

E o conjunto de atividades de apoio ao desenvolvimento que permite que as mudancas sejam absorvidas de maneira controlada durante o desenvolvimento do software. Atrav s e da gerencia de conguracao se identica, controla, faz a auditoria e relata as modicacoes que invariavelmente ocorrem enquanto o software est sendo desenvolvido e depois que a

 ele e entregue ao cliente. Tamb m e por meio dela que se garante a integridade do software e por meio do controle de sua evolucao durante todo o ciclo de vida. A meta e controlar as mudancas, com o objetivo de maximizar a produtividade e minimizar os erros. Em [Viviane N. P. 2007] e possvel tomar conhecimento dos princi pais fatores a serem observados durante o processo de engenharia de software. E possvel vericar que a maior colaboracao dessa area est relacionada ao con a trole de vers o, onde e possvel se deparar com tal funcionalidade em diferentes areas a que envolve a computacao, que v o desde simples documentos de texto (MS Word, Open a Ofce) a at complexos controles de vers es de documentos de gerencia de projetos e e o c digos fonte de programas com milhares de pessoas na equipe. o O controle de vers o e um conjunto de procedimentos e ferramentas para gerenciar a diferentes vers es dos itens de conguracao criados durante o processo de Engenharia de o Software. A gerencia de conguracao permite que o cliente especique alternativas apro priadas do software que melhor se adequar o a uma plataforma ou ambiente especco. a Logo e possvel ter vers es distintas de um software, com suas variantes disponibilizadas o para atender as diferencas tecnol gicas. o Cada vers o do software e uma colecao de Itens de Conguracao de Software, a composto de c digo-fonte, documentos, dados que podem se adaptar. V rias vers es de o a o um mesmo software convivem pacicamente entre si gerando assim colecoes de Itens de Conguracao de Software (ICS) e baselines que ter o suas variantes tamb m armazenadas a e e gerenciadas pela gerencia de conguracao. As ferramentas de controle de vers o geralmente oferecem dois importantes rea cursos: Controle de acesso: apenas pessoas autorizadas tem acesso aos ICSs e podem realizar mudancas nos mesmos. Controle de sincronizacao: ajuda a garantir que as mudancas paralelas, executadas por pessoas diferentes, n o se sobreponham a V rias pessoas trabalham em paralelo e concorrentemente nos arquivos do projeto. a necess ria uma poltica para ordenar e integrar todas essas fontes de alteracoes, de modo E a a evitar que uma pessoa sobrescreva o trabalho de outra. As mais comuns neste processo s o as seguintes: a Poltica Trava-muda-Destrava C pia-modica-Resolve o Na poltica Trava-muda-Destrava e permitida apenas um desenvolvedor por vez, para alterar determinado arquivo. Esta poltica geralmente compromete o trabalho dos participantes das equipes envolvidas no projeto, por ser um m todo restritivo. Pode gerar e s rios problemas administrativos, quando n o muito bem planejado e distribudo, o acesso e a aos arquivos do projeto, causando um acesso linear aos artefatos. [Sommerville 2001] J a poltica C pia-modica-Resolve visa acabar com este travamento. E a o possvel ter acesso livremente a cada arquivo do projeto, como uma c pia. Ap s a o o utilizacao, quando o arquivo termina de ser modicado e retornado para o reposit rios, o as modicacoes s o mescladas em um unico arquivo. Este e o m todo mais abordado a e

na pr tica, sendo que na maioria dos casos as modicacoes n o s o na mesma parte do a a a arquivo. Em [Vivian ] s o fornecidas as motivacoes pela qual os sistemas de Gerencia de a Conguracao devem ser apresentar paralelismo em seus c digos, abordando os principais o conceitos a serem tratados em sistemas de GCS, sendo que projetos geralmente possuem um desenvolvimento paralelo consistindo das seguintes atividades: vers o. a 4.1. Subversion O Subversion e um sistema de controle de vers o desenhado especicamente para ser um a substituto moderno do CVS, que se considera ter algumas limitacoes. Foi desenvolvido e e mantido pela Apache Software Foundation. Esta ferramenta controla a vers o do a conte do dos arquivos, diret rios, c pias, renomeacoes e metadados. u o o Implementacao de novas funcionalidades Impacto sobre v rios elementos do sistema a M comunicacao da equipe envolvida no projeto a Correcao de Bugs Surgimento de novos bugs ap s modicacoes o A seguir, ser o apresentadas algumas ferramentas open source de controle de a

Figure 2. Imagem do programa Subversion em execucao para um projeto em PHP

E possvel fazer a utilizacao de Clientes/fachadas em ambiente gr co de usu rio a a (GUI): RapidSVN (fachada multi-plataformas em ambiente gr co de utilizador escrita a ` em C++ e recorrendo a biblioteca wxWidgets); eSvn (cliente baseado na biblioteca Qt); JSVN (cliente Java swing); SmartSVN (Cliente SubVersion para Linux, Windows e MAC); TortoiseSVN Windows shell (i.e. Explorer) extension; svnX (Mac OS X GUI front-end to svn); AnkhSVN Windows ( uma extens o (addon) do Visual Studio .NET e a Permite que as acoes mais comuns sejam executadas diretamente da IDE).

O subversion tem alternativa para os seguintes ambientes: Subversion for NetBeans - Plugin de integracao do Subversion no NetBeans; subclipse - projecto de integracao do Subversion no Eclipse; SVNKit (antigo JavaSVN) - biblioteca de cliente Subversion em Java; Subversion for Mac OS X.

5. Sistemas Multi Agentes

Segundo [Russel and Norvig 2004], um agente e tudo o que pode ser considerado capaz de perceber seu ambiente por meio de sensores e de agir sobre esse ambiente por interm dio de atuadores. e O comportamento do agente, segundo [Russel and Norvig 2004], e modelado abstratamente como uma funcao de agente - uma tabela que representa domnio e imagem de uma funcao onde, para cada elemento pertencente ao domnio, existe um correspondente na imagem. Ou seja, para cada entrada predenida (captada por meio de sensores), existe uma sada prevista (atuadores). Concretamente, o comportamento do agente e modelado como um programa de agente. Sistemas Multiagentes (SMA) s o aqueles em que v rios agentes trabalham em a a conjunto. [Carvalho 2009] Como pode ser visto acima, a pr pria denicao deixou claro a utilizacao de paro alelismo em Sistemas Multi Agentes. Um Sistema Multi-Agente e um sistema computacional em que dois ou mais agentes interagem ou trabalham em conjunto de forma a desempenhar determinadas tarefas ou satisfazer um conjunto de objetivos. [Wooldridge 2002] A investigacao cientca e a implementacao pr tica de Sistemas Multi-Agente est focalizada na construcao de stan a a dards, princpios e modelos que permitam a criacao de pequenas e grandes sociedades de agentes semiaut nomos, capazes de interagir convenientemente de forma a atingirem os o seus objetivos [Lesser, 1999]. Um dos pontos essenciais para permitir a construcao da sociedades de agentes, consiste em conseguir gerir as interacoes e as depend ncias das atividades dos difer e entes agentes no contexto do Sistema Multiagente, por exemplo, coordenar esses agentes. [da Silva 2005] Desta forma, a coordenacao desempenha um papel essencial nos SMA porque estes sistemas s o inerentemente distribudos. Ali s, o tema designado generia a camente por coordenacao constitui um dos maiores domnios cientcos da inform tica a e ci ncias da computacao. Trabalhos cientcos abrangidos por este domnio frequentee mente incluem aspectos conceituais e metodol gicos, mas tamb m implementacionais, o e de forma a conseguirem expressar e implementar aplicacoes inform ticas distribudas. a [Zambonelli et al. 2003] 5.1. Ferramentas 5.1.1. FIPA-OS FIPA (Foundation for Intelligent Physical Agents) e uma organizacao cujo objetivo e pro mover a tecnologia baseada em agentes, por meio da especicacao de padr es, e a inter o operabilidade desses padr es com outras tecnologias (FIPA, 2005). A organizacao padr o o a para agentes e para Sistemas Multi-Agentes foi aceita ocialmente pela IEEE (Institute of

Electrical and Electronics Engineers), como seu d cimo primeiro comit , em 8 de junho e e de 2005. Para atingir o seu objetivo, a FIPA prop e uma plataforma abstrata que descreve o os elementos que s o necess rios para a implementacao de um SMA. A partir dessa a a descricao, podem-se explorar os relacionamentos existentes entre os diversos elementos, ` identicando caractersticas comuns a implementacao de um ambiente em conformidade com a especicacao. Dessa forma, a plataforma abstrata prov um mecanismo que asse e gure a interoperabilidade entre implementacoes distintas. No modelo de refer ncia apresentado na Figura 3 (FIPA, 2001b), observa-se a e exist ncia de seis componentes Agent Platform, Message Transport System, Agent Mane agement System, Directory Facilitator, Agent e Software que juntos propiciam as funcionalidades requeridas. Essa plataforma de refer ncia n o implica conguracao fsica. e a Os detalhes da implementacao s o responsabilidades dos desenvolvedores. a

Figure 3. Arquitetura de referencia denida pela FIPA

A plataforma de agentes representa o ambiente fsico onde os agentes residem. Ela e formada por um conjunto de m quinas, sistemas operacionais, software de suporte a a agentes, os componentes Directory Facilitator, Agent Management System e Message Transport System e os demais agentes. O projeto interno da plataforma n o e alvo da a padronizacao da FIPA, a responsabilidade de denir tais detalhes e atribuda aos desen volvedores do ambiente. E importante ressaltar que o conceito de plataforma de agentes n o implica que a todos os agentes pertencentes a uma mesma plataforma estejam sicamente localizados na mesma m quina. A mesma plataforma pode estar espalhada em m quinas diferentes, a a contendo sistemas operacionais diferentes. 5.1.2. JADE (Java Agent Development Framework) JADE (BELLIFEMINE, POGGI e RIMASSA, 1999) e um framework de desenvolvimento de SMA, totalmente desenvolvido na linguagem de programacao Java, que est a em conformidade com a especicacao FIPA. Desta forma, seu objetivo tamb m e simpli e car o desenvolvimento de aplicacoes baseadas em agentes, ocultando detalhes que s o a independentes da aplicacao e permitindo que o desenvolvedor se concentre na l gica dos o agentes da aplicacao.

 Uma importante caracterstica em um agente e a sua autonomia. Em JADE essa caracterstica e expressa pela capacidade do agente controlar completamente a sua thread de execucao. Conforme descrito por BELLIFEMINE, POGGI e RIMASSA (1999), JADE prov um conjunto de funcionalidades que auxiliam os desenvolvedores na construcao de e aplicacoes. Dentre estas se podem destacar: Plataforma de agentes distribuda que pode ser dividida em v rias m quinas. Essa a a plataforma est em conformidade com o modelo de refer ncia proposto pela FIPA. a e Interface gr ca com o usu rio que permite a ger ncia da plataforma e dos a a e agentes. Mecanismos de transporte para a troca de mensagens entre os agentes. Disponibilidade dos agentes AMS, DF e ACC. Todos esses agentes s o instanciaa dos automaticamente pela plataforma. A Figura 4 ilustra arquitetura interna do JADE (BELLIFEMINE et al., 2005). Em cada host e executado apenas uma unica m quina virtual java (JVM, Java Virtual Maa chine). Cada JVM e um cont iner b sico que prov um ambiente completo para execucao e a e dos agentes de forma concorrente.

Figure 4. Plataforma distribuda de agentes JADE

A especicacao da FIPA n o dene a organizacao interna para o agente, esta a denicao e delegada para o desenvolvedor do ambiente. Portanto, o ambiente JADE dene sua pr pria organizacao. Ela e composta de cinco componentes: comportamentos ativos o (active agent behaviours), escalonador dos comportamentos (scheduler of behaviours), la privativa de mensagens (private inbox of ACL messages), recursos dependentes da aplicacao (application dependent agent resources) e o gerenciador do ciclo de vida (life cycle manager). Em JADE, toda tarefa, acao ou intencao desempenhada pelo agente e implemen tada pelos comportamentos. Um agente JADE deve possuir pelo menos um behaviour. Eles s o executados de maneira concorrente, o que permite que o agente desempenhe a tarefas distintas. O escalonador dos comportamentos e o respons vel por denir a ordem de a execucao dos comportamentos associados aos agentes. Cada agente possui uma la pri vativa de mensagens onde elas s o postadas pelo JADE de forma transparente. Sempre a que uma mensagem e colocada na la de um determinado agente, esse e noticado pelo

 JADE. Contudo, a decis o de consumir uma dada mensagem, quando e qual, e inteiraa mente denida pelo desenvolvedor do agente (CAIRE, 2003). Os recursos dependentes da aplicacao s o representados pelos protocolos de a interacao e comportamentos gen ricos que devem ser customizados para as necessidades e das aplicacoes especcas. O gerenciador do ciclo de vida e o controlador dos estados observ veis do agente. a 5.1.3. Outras Ferramentas Existe ainda, in meras outras ferramentas que envolvem sistemas multi agentes, seja na u area de desenvolvimentos desses sistemas, construcao de arquitetura para sistemas multi agentes, entre outras areas. A seguir s o listados outras ferramentas para auxlio de dea senvolvimento de sistemas multi agentes: Cougaar (Cognitive Agent Architecture): Foi desenvolvido na linguagem Java e e o DARPA, destinado a disponibilizar uma origin rio de um projeto de investigaca a plataforma opensource exvel para o desenvolvimento de aplicacoes baseadas em uma plataforma de desenvolvimento de aplicacoes agentes de diferentes tipos. E baseadas em agentes. Cormas: e uma proposta de abordagem para modelagem de companheiro, onde e baseada em um framework de simulacao baseado em agentes. Este frame work e livre e pode ser baixado sem a necessidade de registro. E baseado em programacao orientada a objeto SmallTalk. Espacializada, a plataforma se con centra em quest es relacionadas com a gest o dos recursos naturais e com a o a negociacao entre atores. Aglet: Sistema para desenvolvimento de agentes moveis desenvolvido pela IBM na plataforma Java Mobile. Aglets e um agente Java capaz de se mover de um host para outro de forma autom tica e espont nea. a a SeSAm (Shell for Simulated Agent Systems) e um ambiente para simulacao de sistemas multiagente reativos. Seu foco e providenciar uma ferramenta que facilita a construcao de modelos complexos, que inclui interdepend ncias din micas ou e a comportamento emergente. Jason e um interpretador para uma vers o estendida do AgentSpeak. Ele implea menta a sem ntica operacional de da linguagem e fornece uma plataforma para a o desenvolvimento de sistemas multiagente, com muitas funcionalidades person aliz veis pelo usu rio. Jason e uma ferramenta Opensource disponvel e e disa a tribuda sob a GNU LGPL. SemanticAgent e uma implementacao do SAM (Semantic Agent Model), fornece um quadro para o MAS (Multi Agent System) de programacao utilizando tecnolo gias de Web Sem ntica. Os agentes s o programados como m quina de estado a a a nita estendida.

References
Carvalho, C. L. d. A. (2009). Desenvolvimento de agentes com jade. da Silva, I. G. L. (2005). Projeto e implementaAAo de sistemas multiagentes: O caso tropos. Masters thesis, Universidade Federal de Pernambuco.

Furlaneto, R. and Grahl, E. A. Ferramenta de apoio a gerencia de conguracao de soft ware. Marin, B., Giachetti, G., Pastor, O., and Abran, A. (2010). A quality model for conceptual models of mdd environments. Hindawi Publishing Corporation, Advances in Software Engineering. Medeiros, A. P. (2006). Kuaba: Uma Abordagem para Representacao de Design Ratio nale para o Reuso de Designs baseados em Modelo. PhD thesis, Pontca Universidade Cat lica do Rio de Janeiro. o Russel, S. and Norvig, P. (2004). Intelig ncia Articial. Elsevier Editora. e Sommerville, I. (2001). Software Engineering, Ed.6. Addison Wesley. Vivian, R. L. Ger ncia de conguracao de software introducao. Universidade Estadual e de Maring - Departamento de Inform tica - Ci ncia da Computacao - Processo de a a e Engenharia de Software II. Viviane N. P., d. O. (2007). Requisitos de ferramentas de gerenciamento de conguracao. Weiss, G. (2002). Agent orientation in software engineering. Knowledge Engineering Review, 16(4):349373. Wooldridge, M. (2002). Introduction to multi-agent systems. Jonh Wiley and Sons, New York. Zambonelli, F., Jennings, N. R., and Wooldridge, M. (2003). Developing multiagent systems: the gaia methodology. ACM Trans on Software Engineering and Methodology, 12(3):317/370.