, -. # +! $/ #0 21' 3!" # 4 * # 4

Transcrição

1 1

2 2

3 ! "!"$ % &'' ( ) * ) +!$' $ - Introduzir agentes como uma extensão de objectos. - Promover o uso de representações standard e ferramentas que suportem análise, especificação e o design de software de agentes. 3

4 ,-. +! $/ '3!" 4 * 4

5 $ % &" ' Representação de objecto e agente. -Os objectos necessitam de controlo externo para executarem os seus métodos. -Os agentes executam acções que são guiadas por objectivos e condições (estado interno). Os agentes conhecem as condições e os efeitos pretendidos com as suas acções e então assumem a responsabilidade pelos seus actos. São ainda próactivos. -Os sistemas multi-agente geralmente reflectem uma comunidade social de membros interdependentes que agem individualmente. -Figura: -Nos agentes, a comunicação é baseada em actos de comunicação (CA). 5

6 ) * +! ) 9! 9! : 9! ;7 * %- 8 ( 6

7 , 7

8 . < ) '=: '7!> 0!1 ) % 5!< ) '=! * - -Restrições parâmetros de troca de mensagens como a ordem ou o tipo de acordo com a relação entre os agentes ou a intenção da comunicação. 8

9 0 Protocolo FIPA Contract Net. / - Contract Net: - Um dos protocolos de cooperação mais conhecidos inspirado no mundo dos negócios. - Pretende resolver o connection problem encontrar um agente apropriado para uma certa tarefa. - Figura: - Intervenientes: Initiator ou Manager (o agente que tem o problema a resolver) e Participant ou Contractor (o agente que irá resolver o problema ou parte dele). - Passos: 1. O Initiator solicita pedidos de propostas a outros agentes emitindo um call for proposal (cfp), que especifica a tarefa e as condições que o agente impõe na execução da tarefa. As setas denotam uma comunicação assíncrona. 2. Os agentes que recebem o pedido de propostas, Participants, respondem: - recusando fazer uma proposta; - indicando que não percebeu a mensagem; - ou efectuando uma proposta. Notas: - O losango indica uma decisão que pode resultar em zero ou mais comunicações. Neste caso, x representa do uma decisão do tipo ou-exclusivo. - A proposta do Participant inclui as pré-condições que este definiu para a tarefa, tais como o preço, altura em que a tarefa será executada, etc. - O cfp inclui um deadline, ao fim do qual as respostas devem ser recebidas pelo Initiator, de modo a que este não fique à espera indefinidamente caso o Participant falhe uma resposta. 3. O Initiator avalia as propostas e escolhe o(s) agente(s) que irá(ão) desempenhar a tarefa (pode não escolher qualquer agente). Os agentes cujas propostas foram aceites recebem uma mensagem de confirmação e os outros de rejeição. 4. Quando o Participant recebe a confirmação da proposta, informa o Initiator da execução da proposta, que pode cancelar a execução da proposta a qualquer instante. - Notas Adicionais: - O protocolo é tratado como uma entidade, i.e., uma agregação conceptual de sequências de interacção (package canto superior esquerdo). - O protocolo pode ser tratado como um padrão que pode ser aplicado a problemas de domínios semelhantes (templates que podem ser instanciados canto superior direito). 9

10 . 2 Protocolo de interacção com vários níveis de detalhe. 1 -Limitações: -Faltam detalhes para a especificação anterior (básica para um protocolo contract-net) ficar completa: -Procedimento usado para produzir mensagens - Quando o Initator envia a mensagem cfp não é especificado no diagrama o procedimento que este agente usa para produzir a mensagem nem o que o Participant usa para produzir a resposta. -Figura: -O processo que gera a mensagem CA-1 pode ser suficientemente complexo para que seja especificado com mais detalhe usando uma diagrama de actividade. O agente que recebe CA-1 tem um processo que prepara a resposta. Neste exemplo, o processo é especificado através de um diagrama de sequência, apesar de ser possível usar qualquer outro tipo de linguagem de modelação. Em UML pode optar-se por: diagrama de interacção, diagrama de actividade ou de estado. -O nível de detalhe pode ser cada vez maior até que o problema tenha sido especificado adequadamente para desenvolver ou gerar código. Neste caso, tem-se 2 níveis de detalhe. Cada nível representa actividade inter-agente ou intra-agente. 10

11 % < );:? '=-- 1 );:A Nível 2: -Os diagramas de sequência e os de colaboração contém a mesma informação. A representação gráfica do diagrama de sequência dá ênfase à sequência cronológica das comunicações, enquanto que os diagramas de colaboração enfatisam as associações entre agentes. -Os diagramas de actividade e os de estado capturam o fluxo de processamento na comunidade de agentes. 11

12 3 4" !< ) 4 ) 4 '= Protocolo Purchasing (Broker x Retailer) Protocolo Supplying (Retailer x Wholesaler) 1 -APIs - fornecem soluções reutilizáveis que podem ser aplicadas em vários sistemas multi-agente. -Técnicas de UML mais usadas - packages e templates. -Figura (2 packages): -Notação: canto superior esquerdo. -Protocolo Purchasing (compra) expressa um protocolo simples entre um Broker (corretor/negociador) e um Retailer (retalhista/vende aos consumidores). -O Broker faz um pedido a um Retailer que responde com uma proposta. -Para certos produtos, o Retailer pode enviar um pedido a um Wholesaler (fornecedor) para saber a disponibilidade e preço. Com base na informação retornada, o Retailer pode fornecer uma proposta mais precisa. -Nota: Tudo isto podia ter sido incluído num único protocolo Purchasing. No entanto, alguns departamentos podiam não necessitar do protocolo adicional que envolve o Wholesaler. Deste modo, podem então definir-se 2 pacotes: quando um certo cenário requer o protocolo Supplying pode ser usado com um package distinto e separado. 12

13 3 4" &B TEMPLATE Protocolo (Buyer x Seller) 1 -Um padrão, para ser um componente reutilizável, deve suportar adaptação/personalização. -Um package AIP serve como um template, que é um modelo parametrizado. -Figuras: -Notação: Tracejado indica que o package é um template. -Template é dividido em 3 categorias (linhas): -parâmetros relacionados com o tipo/papel do agente; -restrições; -actos de comunicação. -Protocolo FIPA Contract Net aplicado a um cenário particular que envolve agentes compradores e vendedores: -Agentes Initiator e Participant tornaram-se Buyer e Seller; -O acto de comunicação cfp tornou-se seller-rfp; -Formas de recusa por parte do vendedor: Refuse-1 e Refuse-2. -Forneceu-se ainda um deadline para a resposta do vendedor. 13

14 3 4" 8. 9 : ;1 < 5*< ) '=6 < ) *25;C.;5D,5< > ) 01> ) 7$% AND OR EXCLUSIVE-OR 1 -Figura: -Sintaxe: -Agentes individuais (papéis) ou conjuntos de agentes (classes). -Miguel/Cliente - Agente individual (Miguel é uma instância de um agente que desempenha o papel de Cliente). Miguel/Cliente:Pessoa (Miguel é uma pessoa, independentemente do papel que assume, pode ser expresso através de Miguel:Pessoa). -Em OO: object-name/role:class. -Actos de comunicação: Substituem as mensagens do estilo OO. -Comunicação concorrente: -Threads concorrentes não são usuais em OO: a) AND - todas as threads são enviadas concorrentemente; b) OR - inclui uma caixa de decisão (losango) que decide quantos CAs (zero ou mais) serão enviados; se é enviado mais do que 1 então a comunicação é concorrente; c) EXCLUSIVE-OR - apenas um acto de comunicação é enviado. 14

15 3 4" 8. 9 : ;< 5* < )!B7'0101> $7!& => ) '!$! > )! 1 -Figura: -Fig. a) - barras de activação paralela; -Fig. b) - barras de activação na sequência umas das outras. -Barras de activação verticais - agente receptor está a processar as várias threads de comunicação concorrentemente. -Por exemplo, em (a) CA-3 está a ser tratado pelo agente quando este assume o papel designado por role-1. 15

16 3 4" 8. 9 : ;< 7 Interacção entre agentes com múltiplos papéis. 1 ( -Figura: -Os diagramas de sequência têm 2 dimensões: -Vertical representa a ordenação do tempo. -Horizontal papéis diferentes ou agentes que desempenham papéis específicos. 16

17 3 4" 8. % 5*< ) Interacção entre agentes com múltiplos papéis. 1, 17

18 3 4" 8 9 : " ' % 9!< 9 2,95 5IJ;?E$ * 9 2,95 F,GH '' '=( ) '! '- ' 1-18

19 3 4" 8. " Electronic Commerce Network (ECN). 5**:$ K*' 1 / -Diagramas de actividade expressam operações e os eventos que as desencadeiam. -Figura: -Protocolo de processamento de compras de acções entre vários agentes. -Um Cliente (Customer) faz um pedido de compra. Este processo resulta num evento que leva a que o Negociador (Broker) faça o pedido, que é depois aceite por um agente ECN. -O agente ECN só pode associar uma encomenda com uma cotação quando ambas são aceites. -Após a associação, o Market Maker e o Broker são notificados de que a negociação está completa. 19

20 3 4" 8.,' Estados e transições válidas num protocolo de negociação. ' + -Figura: -Representação gráfica: -Estados rectângulos com os cantos arredondados; -Transições arcos directos entre os estados. -Se um certo pedido está num estado Requested, um agente fornecedor pode iniciar essa negociação, resultando numa transição para Commited. -O estado Requested tem ainda outras 2 acções possíveis (para além do commit): o fornecedor pode recusar e o cliente pode voltar atrás. O fornecedor pode ainda recusar a encomenda no estado Proposed. -Tipicamente, o diagrama de estados e os estados não estão implementados directamente como agentes. No entanto, um agente pode incluir as restrições nas transições entre estados, assegurando que as restrições do protocolo de interacção geral são satisfeitas. Em alternativa, as restrições também podem estar incorporadas nos papéis de fornecedor e cliente. 20

21 3 4" 8. " Comportamento de um agente Order para o processamento de encomendas. 1 -Figura: -Diagrama de Sequência o processo do agente é desencadeado a partir de um CA Place Order e termina quando a encomenda é completada. -Diagrama de Actividade expressa o processamento interno do Order Processor, que aceita, faz o assembly, envia e fecha a encomenda. -O diagrama indica que, após a encomenda passar por Assembled Order, as acções Prepare/send Invoice são disparadas concorrentemente. -Apenas quando o pagamento é aceite e a encomenda é enviada, o processo Close Order pode ser invocado. 21

22 3 4" 8. Comportamento de um agente Order para o processamento de encomendas. -Figura: -Estados internos e transições para um agente Order Processor. 22

23 *!!7< )! > ) > )!7-8!- 23

24 = : L <$<D""" FF-MN-M-O. +!!/!" /P-@QQ? FF-MN-M-O. +!!/ M-R8-FF-O5*! P-@QQQ M-R8-FF-O, P-@QQQ 24