Introduzindo Variabilidade no Desenvolvimento de - LES PUC-Rio
Transcrição
Introduzindo Variabilidade no Desenvolvimento de - LES PUC-Rio
Introduzindo Variabilidade no Desenvolvimento de Sistemas Multi-Agentes Aluno: Guilherme Nascimento Pate Santos Orientadores: Carlos José Pereira de Lucena Ricardo Choren Noya [email protected] , [email protected] , [email protected] Agenda • Modelagem de Sistemas Multi-agentes; • O Problema; • Objetivo; – Conceitos. • Pontos de Flexibilização; • Solução Proposta; • Estudos de Caso; – Aplicação Médica; – Aplicação de Compra e Venda; – LearnAgent (TAC). • Trabalhos Relacionados; • Contribuições; • Conclusão e Trabalhos Futuros. 27/5/2007 Guilherme Pate © LES/PUC-Rio 2 Modelagem de SMaS • Modelagem de Sistemas Multi-agentes – Atualmente existem inúmeras linguagens de modelagem de sistemas multi-agentes; – Cada qual com o seu ponto forte na modelagem; • Representação do protocolo de interação; • Levantamento de requisitos. • ... 27/5/2007 Guilherme Pate © LES/PUC-Rio 3 O Problema • Agentes de Software – As linguagens de modelagem de agentes atuais não disponibilizam mecanismos para representar as variabilidades existentes nos agentes; – Normalmente os sistemas multi-agentes são desenvolvidos visando uma única aplicação; – As linguagens atuais ajudam no desenvolvimento de aplicações multi-agentes, mas não lidam com aspectos como: a representação de uma linha de produto construídas por meio de framework. Multi-Agent System Product Lines: Challenges and Benefits Joaquin Peña, Michael G. Hinchey and Antonio Ruiz-Cortés CACM vol. 49 no. 12 dezembro 2006. 27/5/2007 Guilherme Pate © LES/PUC-Rio 4 Objetivo • Objetivo – O objetivo é determinar um método que por meio de diagramas possa projetar as possíveis variabilidades de um agente de software; – O método proposto determina linhas de produto em um agente de software (construídas por meio de framework) que tenha a variabilidade característica para tanto; – Com isto o desenvolvimento de smas torna-se ainda mais flexível e modularizado; – Introduzir variabilidade em sistemas multi-agentes é uma característica possível após a definição do método proposto que para tanto utiliza de pontos de flexibilização definidos em um agente de software. 27/5/2007 Guilherme Pate © LES/PUC-Rio 5 Conceitos • Flexibilidade – A flexibilidade neste escopo pode ser definida como uma maneira de determinar uma facilidade no manejamento dos pontos de flexibilização; – Os pontos de flexibilização em um agentes são seus planos e ações; – A flexibilidade é utilizada para determinar pontos em um agente de software que tenham a aptidão de variar em aplicações distintas; – A vantagem de determinar pontos de flexibilização é observada na possibilidade de isolar os pontos de maior variabilidade de um agente do sistema multi-agente modelado. 27/5/2007 Guilherme Pate © LES/PUC-Rio 6 Conceitos • Conceitos Base – Descrição e documentação • RDL; • Hook; • Cookbook; – Modelagem • ANote; – Representação de framework • UML-F. 27/5/2007 Guilherme Pate © LES/PUC-Rio 7 Pontos de Flexibilização • Planos – Um plano flexível pode ser chamado de um plano abstrato e suas características são as seguintes: • Um plano que é composto de ações concretas e abstratas, onde as ações concretas podem ser definidas antes mesmo de ter sido definido o foco principal da aplicação e ações abstratas que podem ser determinada somente após a determinação do foco de aplicação. • Ações – Uma ação flexível pode ser chamada de uma ação abstrata e sua característica é a seguinte: • A impossibilidade de prever de que modo a ação deve ser executada, ou seja, tal ação terá apenas a sua assinatura e sua implementação ficará a cargo da aplicação (final) que será instanciada. 27/5/2007 Guilherme Pate © LES/PUC-Rio 8 Solução • O método proposto pode ser utilizado de forma isolada, porém para se ter uma visão completa do sistema foi utilizada na dissertação a linguagem ANote. – Para utilizar o método juntamente com o ANote é necessário estender alguns diagramas para obter um gancho; os diagramas do ANote estendidos são o planning view e o scenario view; • Planos – O método proposto utiliza os diagramas flexibility view, action note view e instantiation view para representar os planos abstratos e as instâncias dos planos para as futuras aplicações. • Ações – O método proposto utiliza os diagramas instantiation view e action note view. 27/5/2007 Guilherme Pate © LES/PUC-Rio 9 Solução Abstração do Plano de um Agente • A abstração de plano deve ser representada pelos seguintes diagramas. 27/5/2007 Guilherme Pate © LES/PUC-Rio 10 Solução Abstração da Ação de um Agente • A abstração das ações são representadas pelos seguintes diagramas. 27/5/2007 Guilherme Pate © LES/PUC-Rio 11 Solução instanciação de um Agente • A instanciação do plano e da ação de um agente será guiada através do seguinte diagrama – O diagrama foi feito com base nos conceitos utilizados na RDL. Instantiation View Description: Indica a ação de criação de um plano chamado “pName” no design. Retorna o plano e suas ações para mais adiante ser manipulado. Indica a ação de criação de uma ação chamada “aName” no design. Retorna a ação para mais adiante ela possa ser manipulada. Code: 27/5/2007 COOKBOOK o que se quer fazer (objetivo) RECIPE main //adding a new plan NEW_PLAN (pName); NEW_ACTION (aName); // … END_RECIPE; END_COOKBOOK Guilherme Pate © LES/PUC-Rio 12 Solução (estudo de caso I) • Agentes de Software para área médica Agente de software responsável pela dosagem Plano 1 Produto 1 Pacientes UTI/CTI 27/5/2007 Guilherme Pate © LES/PUC-Rio Plano 2 Produto 2 Pacientes Clinica Médica 13 Solução (estudo de caso I) • Agentes de Software para área médica 27/5/2007 Guilherme Pate © LES/PUC-Rio 14 Solução (estudo de caso I) • Agentes de Software para área médica Invalidar/Validar Medicamento por Dosagem 27/5/2007 Lead Agent: Dosador. Precondition: Existir um Medicamento e/ou um Princípio Ativo para validar dosagem ou calcula-la. Description: Indica a ação de criação de um plano chamado “pName” no design. Retorna o plano e suas ações para mais adiante ser manipulado. Main Action Plan: 1. Selecionar Prescrição. 2. Calcular a dosagem e ver se está de acordo com a dosagem Padrão. -> Flexibility (Plan Creation) 3. Invalidar Dosagem. Interactions: Medicamentoso. Variant Plan: Variant PreCondition: O Agente não encontra erros na dosagem. Plan Description: -> Flexibility (Plan Creation). Se a dosagem está OK 1.1 Valida o Dosagem. Guilherme Pate © LES/PUC-Rio 15 Solução (estudo de caso I) • Agentes de Software para área médica Instantiation View Description: Indica a ação de criação de um plano, que é o plano concreto “medicamentoCTI” que foi visto no design flexibility view. Retorna o plano e suas ações para mais adiante ser manipulado. PLAN_EXTENSION(Flexibility Plan, ?) cria as extensões possíveis para o plano flexível. SELECT_PLAN_EXTENSION(Flexibility Plan) retorna o plano concreto para o sistema CQPM. ADD_ASSIGN(SELECT_PLAN_EXTENSION(Flexibility Plan), Action Note View); mostra que os planos receberão as a assinaturas das ações de acordo com o que foi definido no diagrama Action Note View. Code: COOKBOOK Calcular dosagem RECIPE main //adding a new plan (medicamentoCTI) LOOP PLAN_EXTENSION(Flexibility Plan, ?) END_LOOP ADD_ASSIGN(SELECT_PLAN_EXTENSION(Flexibility Plan), Action Note View); // … END_RECIPE; END_COOKBOOK 27/5/2007 Guilherme Pate © LES/PUC-Rio 16 Solução (estudo de caso II) • Agentes de Software para compra e venda Agente responsável pela efetivação da compra Produto 1 Produto 2 Produto 3 A variação do produto é determinada pela variação na maneira de execução da ação. No exemplo, o pagamento com dinheiro ou com cheque ou com cartão. 27/5/2007 Guilherme Pate © LES/PUC-Rio 17 Solução (estudo de caso II) • Agentes de Software para compra e venda Comprar um Produto (refrigerante) Lead Agent: Efetivador. Precondition: Existir um produto para ser adiquirido. 1. Obter o valor de cada Produto. 2. Somar o valor de cada produto. 3. Pagar valor devido. -> Flexibility (Action Creation) 4. Validar pagamento. Main Action Plan: Interactions: Vendedor. Variant Plan: Variant PreCondition: O Agente encontra erros no modo de pagamento (cheque sem fundo, cartão sem limite, dinheiro a baixo do total da conta). Ou o a problema com o produto. Action Description: -> Flexibility (Action Creation) Se teve problemas com o pagamento 1.1 Invalidar o pagamento da conta. Se teve problemas com o produto 2. Efetuar a troca do produto. 27/5/2007 Guilherme Pate © LES/PUC-Rio 18 Solução (estudo de caso II) • Agentes de Software para compra e venda Instantiation View Description: ADD_CODE(Plano, ação, código) indica que determina ação num dado plano receberá a implementação descrita. Code: COOKBOOK Pagar Valor RECIPE main //adding a new action ADD_CODE(Refrigerante, pagarValorDevido, // código para implementar a compra com cheque); // … END_RECIPE; END_COOKBOOK 27/5/2007 Guilherme Pate © LES/PUC-Rio 19 Solução (estudo de caso III) • LearnAgents – O objetivo maior desse sistema é comprar pacotes de viagens para os clientes e obtendo o maior lucro possível, levando em consideração o gosto do cliente. – Na competição TAC uma das regras é que não pode haver intervenção humana, ou seja, os agentes devem trabalhar sozinhos em leilões de bens, onde os bens podem ser passagens aéreas, hospedagens em hotel e ingressos para museus, parques ou luta livre; 27/5/2007 Guilherme Pate © LES/PUC-Rio 20 Solução (estudo de caso III) • Negotiator Agent – Para cada leilão a um negociador especializado na compra de um tipo de bem é acionado pelo agente ordenador. – Hotel Negotiator Agent • Tem o objetivo de obter boas hospedagens em hotéis de acordo com o gosto do cliente. – Flight Negotiator Agent • Envia os descontos com a quantidade e preço que são encontrados no preço atual do leilão de vôos. – Ticket Negotiator Agent • Tem o objetivo de comprar bons tickets em mercados que enviam preços com descontos onde estes serão comparados com pontos de venda de descontos e a venda de bons preços que são equivalentes ao desconto máximo com um incremento extra. 27/5/2007 Guilherme Pate © LES/PUC-Rio 21 Solução (estudo de caso III) Negotiate Goods Main Agent Negotiator Agent Preconditions Message from Ordering Main Action Plan While true Collect good orders in CKB Negotiate goods in auctions End while Interaction - Variant Action Plan - • Diagrama de scenario view do ANote. Negotiate Goods 27/5/2007 Main Agent Negotiator Agent Preconditions Message from Ordering Main Action Plan While true Collect good orders in CKB Negotiate goods in auctions (PlanCreation) End while Interaction - Variant Action Plan - Guilherme Pate © LES/PUC-Rio → flexibility 22 Solução (estudo de caso III) • Diagrama flexibility view e action note view. 27/5/2007 Guilherme Pate © LES/PUC-Rio 23 Solução (estudo de caso III) • Diagrama Instantiation view. Instantiation View Description: Loop indica que o código (PLAN EXTENTION(Negotiator Agent Plan, ?)) é executado um dado numero de vezes para se obter a quantidade de extensões necessárias. Retorna cada plano com suas ações específicas e executa cada plano até que a condição seja falsa. SELECT_PLAN_EXTENSION(Plano de onde esta sendo herdadas as características) – indica que apenas o plano correto será instanciado para uma dada aplicação. ADD_ASSIGN(SELECT_PLAN_EXTENSION(NegotiatorAgent_Plan), Action Note View); mostra que os planos receberão as a assinaturas das ações de acordo com o que foi definido no diagrama Action Note View. Code: Coobook: Negociar e obter bons preços no leilão Recipe main loop PLAN EXTENTION(Negotiator Agent Plan, ?); End loop ADD_ASSIGN(SELECT_PLAN_EXTENSION(NegotiatorAgent_Plan), Action Note View); //SELECT_PLAN_EXTENSION(NegotiatorAgent_Plan); End_Recipe End_Coobook 27/5/2007 Guilherme Pate © LES/PUC-Rio 24 Trabalhos Relacionados • Modelagem – AUML; – Tropos; – ANote. 27/5/2007 Guilherme Pate © LES/PUC-Rio 25 Trabalhos Relacionados • AUML (BAUER, B.; MÜLLER, J. P.; ODELL, J.) – Na AUML a representação das interações fica a cargo do diagrama de protocolo de interação que representa a interação entre os agentes; – Um ponto negativo da AUML é o fato de não ser possível representar através dela as variabilidades que podem ocorrer no desenvolvimento de sistemas multi-agentes. BAUER, B.; MÜLLER, J. P.; ODELL, J. Agent UML: Formalism for Specifying Multiagent Interaction Springer-Verlag, Berlin, pp. 91-103, 2001 27/5/2007 Guilherme Pate © LES/PUC-Rio 26 Trabalhos Relacionados • Tropos (GIORGINI, P.; KOLP, M.; MYLOPOULOS, J.; PISTORE, M.) – Como as demais linguagens de modelagem de agente o Tropos traz a sua representação sem se preocupar com a possibilidade de uma extensão do sistema através de artefatos como um framework, onde as variabilidades são bem definidas em função da aplicação que se quer instanciar; invés disso o que vemos na metodologia Tropos é uma explosão de tarefas; – A linguagem Tropos não aborda pontos como a representação da variabilidade segundo a aplicação que se quer utilizar no projeto de agentes de software, além disso, é necessário utilizar outra linguagem de modelagem para completar seu ciclo. GIORGINI, P.; KOLP, M.; MYLOPOULOS, J.; PISTORE, M. The Tropos Methodology: An Overview, 2000. 27/5/2007 Guilherme Pate © LES/PUC-Rio 27 Trabalhos Relacionados • ANote (CHOREN, R.; LUCENA, C. J. P.) – Dentro da linguagem ANote os diagramas dinâmicos scenario view e planning view representam o comportamento do agente e o fluxo das ações de um agente de software respectivamente; – O ANote também não representa as variabilidade segundo a aplicação que se quer instanciar no projeto de agentes de software. CHOREN, R.; LUCENA, C. J. P. Modeling Multi-agent systems with ANote Springer-Verlag 2004, 2003a. 27/5/2007 Guilherme Pate © LES/PUC-Rio 28 Contribuição • Espera-se que seja possível contribuir nos seguintes pontos: – O uso da idéia de framework para agentes de software, trazendo características de reutilização; – Pontos de flexibilização; – Método proposto; – Uma instância do método com o ANote. 27/5/2007 Guilherme Pate © LES/PUC-Rio 29 Conclusão e Trabalhos Futuros • Conclusão – O método proposto possibilita modelar sistemas multi-agentes de maneira mais flexível de forma que fica claramente visível à linha de produto de tal sistema, o que possibilita o desenvolvimento e a modelagem de frameworks; – A solução visa resolver o problema de representação, através de diagramas e técnicas de descrição e documentação e por meio destes será possível representar varias instâncias para um sistema multi-agente. • Trabalhos Futuros – Modelagem completa do sistema LearnAgents; – Desenvolvimento de um script para ajudar na criação das instâncias; – Continuar os estudos em sistemas multi-agentes aplicados a área médica. 27/5/2007 Guilherme Pate © LES/PUC-Rio 30 Fim “Há um tempo em que é preciso abandonar as roupas usadas que já têm a forma do nosso corpo e esquecer os nossos caminhos que nos levam sempre aos mesmos lugares. É tempo da travessia; e se não ousarmos fazê-la, teremos ficado para sempre à margem de nós mesmos”. Fernando Pessoa Obrigado! 27/5/2007 Guilherme Pate © LES/PUC-Rio 31