IMPLEMENTAÇÃO DE UM AGENTE TAC SCM EM...

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS

CURSO DE CIÊNCIAS DA COMPUTAÇÃO – BACHARELADO

IMPLEMENTAÇÃO DE UM AGENTE TAC SCM EM

LINGUAGEM AGENTSPEAK(L)

ANDRÉ FELIPE LAUS

BLUMENAU 2007

2007/1-04

ANDRÉ FELIPE LAUS



Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciências da Computação — Bacharelado.

Prof. Jomi Fred Hübner, Doutor - Orientador

BLUMENAU 2007

2007/1-04



Por

ANDRÉ FELIPE LAUS

Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:

______________________________________________________ Presidente: Prof. Jomi Fred Hübner, Doutor – Orientador, FURB

______________________________________________________ Membro: Prof. Paulo César Rodacki Gomes, Doutor – FURB

______________________________________________________ Membro: Prof. Adilson Vahldick, Especialista – FURB

Blumenau, 11 de julho de 2007

Dedico este trabalho a todos aqueles que me ajudaram diretamente ou indiretamente na realização deste.

AGRADECIMENTOS

À Deus, pelo seu imenso amor e graça.

À minha família que sempre esteve presente.

A minha namorada Luciane pelo apoio, incentivos e compreensão.

Aos meus amigos, pelos empurrões e cobranças.

Ao meu orientador, Jomi Fred Hübner, por ter acreditado na conclusão deste trabalho.

Nunca ande pelo caminho traçado, pois ele conduz somente até onde os outros foram.

Graham Bell

RESUMO

Este trabalho apresenta uma implementação de um sistema multiagentes que se situa em um ambiente simulado chamado de Trading Agent Competition Supply Chain Management (TAC SCM). O TAC SCM consiste em competições com seis agentes concorrentes, onde cada um é responsável por gerenciar uma fábrica de montagem de computadores. O agente tem como tarefas: receber pedidos dos consumidores de computadores, fazer pedidos aos fornecedores de componentes, agendar a produção da fábrica e agendar a entrega dos pedidos. Onde o simulador faz o papel de consumidor, fornecedor, fábrica, estoque e banco. A arquitetura do agente é baseada em modelo de cognição fundamentado em três principais atitudes mentais que são as crenças, os desejos e as intenções (abreviadas por BDI, do inglês beliefs, desires e intentions). Neste trabalho é relatado a construção de uma aplicativo capaz de interagir em um ambiente competitivo. O sistema é especificado com a metodologia Prometheus e implementado em linguagem AgentSpeak(L) usando o interpretador Jason.

Palavras-chave: Sistema multiagentes. AgentSpeak(L). Jason. Prometheus.

ABSTRACT

This work presents an implementation of a multiagent system situated in a simulated environment called Trading Agent Competition Supply Chain Management (TAC SCM). TAC SCM consists of competitions with six competing agents, where each one is responsible for managing computers assembly lines. The agent has as tasks: to receive order from the consumers of computers, to ask suppliers for components, to schedule the production of the plant and to schedule the delivery of the orders. The simulator plays the role of consumer, supplier, plant, supply and bank. The architecture of the agent is based on a model cognitive with three main mental attitudes that are the beliefs, the desires and the intentions (shortened for BDI). In this work, the applicatory construction of a capable one is told to interact in a competitive environment. The system is specified with the Prometheus methodology and implemented in AgentSpeak(L) language using the Jason interpreter.

Keywords: Multi-agent system. AgentSpeak(L). Jason. Prometheus.

LISTA DE ILUSTRAÇÕES

Figura 1 – Diagrama de fases da metodologia Prometheus......................................................19

Figura 2 – Scenarios diagram..................................................................................................20

Figura 3 – Goal overview diagram...........................................................................................21

Figura 4 – System role diagram................................................................................................22

Figura 5 – Data coupling diagram...........................................................................................22

Figura 6 – Agent-role grouping diagram.................................................................................23

Figura 7 – Agent acquaintance diagram..................................................................................23

Figura 8 – System overview diagram........................................................................................24

Figura 9 – Agent overview diagram.........................................................................................25

Figura 10 – Capability overview diagram................................................................................26

Quadro 1 – Exemplos de planos AgentSpeak(L) .....................................................................27

Figura 11 – Cenário do TAC SMC...........................................................................................30

Figura 12 – Representação dos dias no TAC, onde o agente negocia com os clientes e os

fornecedores e produz e entrega dos PCs ..............................................................32

Figura 13 – Visão geral do sistema focado no agente..............................................................48

Figura 14 – Diagrama de cenários TAC SCM .........................................................................49

Figura 15 – Papéis do agente....................................................................................................50

Figura 16 – Diagrama detalhado dos papéis do agente............................................................51

Figura 17 – Camadas da aplicação ...........................................................................................54

Figura 18 – Diagrama de classes da camada de integração......................................................55

Figura 19 – Diagrama de classes da interface de comunicação (parte1)..................................56

Figura 20 - Diagrama de classes da interface de comunicação (parte2) ..................................57

Figura 21 – Classe de implementação para a comunicação entre o agente e o simulador .......58

Figura 22 – Diagrama de seqüência para adição de crenças ....................................................60

Figura 23 – Diagrama de seqüência para adição de crenças ....................................................61

Quadro 2 – Criação da arquitetura do agente ...........................................................................64

Quadro 3 - Ligando agente escrito em AgentSpeak(L) e simulador TAC SCM......................64

Quadro 4 – Método de recebimento de mensagens vindas do servidor TAC SCM.................65

Quadro 5 – Implementação do método para atender as RFQs dos consumidores ...................66

Quadro 6 – Método de execução de ações ...............................................................................67

Quadro 7 – Método de chamada da classe que representa as ações .........................................67

Quadro 8 – Procedimento de atualização da data corrente.......................................................68

Quadro 9 – Procedimento de envio de RFQs ao fornecedores.................................................69

Quadro 10 – Processo de iniciação do processo de agendamento da produção.......................70

Quadro 11 – Processo de agendamento da produção ...............................................................72

Quadro 12 – Processo atualização das crenças de ordens de pedidos do consumidor .............73

Quadro 13 – Processo de entrega de pedidos ...........................................................................74

Quadro 14 - Comando de execução do servidor TAC SCM....................................................75

Figura 24 – Página de gerenciamento do servidor TAC SCM.................................................75

Figura 25 – Formulário de cadastro de novo usuário no servidor TAC SCM..........................76

Figura 26 – Requisição de usuário e senha do TAC SCM.......................................................77

Figura 27 – Página para criação de nova simulação ou acompanhamento ..............................77

Figura 28 – Criada nova simulação ..........................................................................................78

Figura 29 – Adicionando agentes na simulação .......................................................................79

Figura 30 – Simulação rodando com agente padrão ................................................................80

Figura 31 – Monitor de simulação............................................................................................81

Figura 32 – Detalhes sobre consumidores................................................................................81

Figura 33 – Acompanhamento do agente no lado do cliente ...................................................82

LISTA DE TABELAS

Tabela 1 – Catálogo de componentes.......................................................................................31

Tabela 2 – Combinação de PCs................................................................................................31

Tabela 3 – Parâmetros usados no TAC SMC...........................................................................36

LISTA DE SIGLAS

API - Application Programming Interface

BDI – Beliefs, Desires e Intentions

JASON – Java-based AgentSpeak interpreter used with SACI for multi-agent distribution

Over the Net

PC – Personal Computer

PDT – Prometheus Design Tool

RFQs - Requests For Quotes

SMA – Sistema Multiagentes

SMC - Supply Chain Management

TAC - Trading Agent Competition

SUMÁRIO

1 INTRODUÇÃO..................................................................................................................13

1.1 OBJETIVOS DO TRABALHO ........................................................................................14

1.2 ESTRUTURA DO TRABALHO......................................................................................15

2 FUNDAMENTAÇÃO TEÓRICA....................................................................................16

2.1 SISTEMAS MULTIAGENTES........................................................................................16

2.2 ARQUITETURA BDI.......................................................................................................17

2.3 METODOLOGIA PROMETHEUS PARA DESENVOLVIMENTO DE SMA..............18

2.4 LINGUAGEM AGENTSPEAK(L)...................................................................................26

2.5 TAC SMC..........................................................................................................................28

2.5.1 Produtos e componentes..................................................................................................30

2.5.2 Agente .............................................................................................................................31

2.5.2.1 Produção .......................................................................................................................33

2.5.2.2 Envio.............................................................................................................................34

2.5.2.3 Custo de armazenagem .................................................................................................34

2.5.2.4 O banco.........................................................................................................................37

2.5.3 Fornecedores ...................................................................................................................37

2.5.3.1 Modelagem dos fornecedores .......................................................................................38

2.5.3.2 Pedidos enviados ao fornecedor ...................................................................................39

2.5.3.3 Produção diária .............................................................................................................40

2.5.3.4 Reputação do agente .....................................................................................................40

2.5.3.5 Definição de preços ......................................................................................................41

2.5.3.6 Processamento de ofertas..............................................................................................42

2.5.4 Consumidor.....................................................................................................................42

2.5.4.1 Demanda de consumidor ..............................................................................................43

2.5.4.2 Processamento das ofertas ............................................................................................43

2.5.4.3 Finalizando os pedidos .................................................................................................44

2.6 TRABALHOS CORRELATOS........................................................................................44

3 DESENVOLVIMENTO DO SISTEMA..........................................................................46

3.1 REQUISITOS DO PROBLEMA A SER TRABALHADO .............................................46

3.2 ESPECIFICAÇÃO ............................................................................................................47

3.2.1 Visão geral do sistema ....................................................................................................47

3.2.2 Cenários...........................................................................................................................48

3.2.3 Agente .............................................................................................................................50

3.2.4 Funcionalidades...............................................................................................................52

3.2.5 Interface de integração ....................................................................................................53

3.3 IMPLEMENTAÇÃO ........................................................................................................62

3.3.1 Técnicas e ferramentas utilizadas....................................................................................62

3.3.2 Implementação da camada de integração........................................................................63

3.3.3 Implementação do agente................................................................................................68

3.3.4 Operacionalidade da implementação ..............................................................................74

3.4 RESULTADOS E DISCUSSÃO ......................................................................................83

4 CONCLUSÕES..................................................................................................................85

4.1 EXTENSÕES ....................................................................................................................86

REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................87

13

1 INTRODUÇÃO

Atualmente as tecnologias e os softwares têm evoluído em ritmo acelerado, e vêm

facilitar a execução de tarefas tanto para usuários quanto para desenvolvedores. Segundo

Wooldridge (2002, p. 1-2), algumas importantes e contínuas tendências da computação são:

os sistemas distribuídos1; a interconectividade entre computadores; os sistemas inteligentes; a

delegação de tarefas aos computadores, bem como a destinação de tarefas críticas aos

sistemas computadorizados; e a programação com conceitos de alto-nível2 de abstração.

Dentre estas tendências, destaca-se a delegação, que implica em dar o controle de tarefas a

sistemas computacionais, por exemplo, delegando tarefas de contexto crítico, como o controle

de um avião.

Um novo paradigma emergente e que vem de encontro a estas tendências é a

programação orientada a agentes. Wooldridge (2002, p. 15) e Wooldridge e Jennings (1995,

p. 4-5) definem um agente como um sistema computadorizado situado em um ambiente, ou

seja, possui percepção sobre este, e que seja capaz de ações autônomas no ambiente a fim de

ir ao encontro dos objetivos pelos quais foi projetado, sendo que o agente pode se comunicar

com outros agentes que compartilham do mesmo ambiente, e esta comunicação acaba

atribuindo características sociais ao agente.

Observando as pesquisas correspondentes a este novo paradigma, é possível encontrar

diversos recursos para o desenvolvimento de agentes e algumas linhas de desenvolvimento. É

possível encontrar estas diversidades em arquiteturas para agentes, sendo uma delas a BDI. A

mesma variedade encontra-se em linguagens orientadas a agentes, como a AgentSpeak, sendo

esta baseada na arquitetura de agentes BDI. Conta-se também com algumas opções de

ferramentas para desenvolvimento de agentes, citando como exemplo o Jason, que segundo

Bordini e Hübner (2006, p. 1), interpreta a linguagem AgentSpeak. Ainda pode-se encontrar

algumas implementações de simuladores de ambientes destinados ao teste de SMA.

Um destes simuladores é descrito por Collins et al. (2005, p. 1-2), onde é simulado um

1 Segundo Tanenbaum e Steen (2002, p. 2), um sistema distribuído é uma coleção de computadores independentes que parecem com um único sistema para o usuário. 2 Conforme Wooldridge (2002, p. 1-2) é a programação que se assemelha à linguagem humana.

14

ambiente de uma organização de produtos manufaturados. Neste simulador o agente assume o

papel da gerência de uma cadeia de suprimentos. Agrega-se a este papel a necessidade de

planejamento e coordenação das atividades da organização, atividades estas que se aplicam

desde a obtenção de matérias para a fabricação até a entrega do produto. O simulador

denominado de TAC SCM contempla um cenário onde o agente deve: negociar com seus

fornecedores os componentes para fabricação dos produtos; planejar e coordenar a produção e

estocagem tanto dos produtos quanto dos componentes para a sua fabricação; e ser

responsável pela oferta dos produtos e entrega dos pedidos feitos pelos clientes. O TAC SCM

foi desenvolvido para proporcionar um ambiente de competição entre os agentes que

disputam tanto os clientes quanto os fornecedores.

O interpretador Jason, e diretamente a linguagem AgentSpeak, possui algumas

validações através de implementações de alguns sistemas simples. No intuito de somar fontes

de conhecimento e de validação para a linguagem AgentSpeak, propõe-se inserir no ambiente

TAC SCM um agente construído através do Jason, a fim de testar e averiguar se a linguagem

AgentSpeak permite este tipo de implementação e qual o comportamento dos agentes

construídos em tal linguagem em um ambiente estilo o TAC SCM.

1.1 OBJETIVOS DO TRABALHO

O objetivo deste trabalho é a exploração da linguagem AgentSpeak e das técnicas e

conceitos de programação orientada a agentes na construção de um agente para o simulador

TAC SCM.

Os objetivos específicos do trabalho são:

a) analisar o potencial do interpretador Jason na implementação de agentes BDI;

b) analisar o comportamento dos agentes implementados no interpretador Jason em

um ambiente competitivo e com características sociais;

c) desenvolver um sistema que assuma o papel gerencial de uma fábrica, planejando

e coordenando as atividades da mesma.

15

1.2 ESTRUTURA DO TRABALHO

Este trabalho é distribuído em quatro capítulos. O capítulo 2 trás a fundamentação

teórica de onde a base deste trabalho foi tirada, tanto para a especificação quanto para o

desenvolvimento. Nele são apresentados os conceitos de SMA e BDI, a noção sobre

metodologia Prometheus e sobre linguagem de programação para agentes denominada de

AgentSpeak(L) e o detalhamento do simulador TAC SCM ao qual se tem um completo

relacionamento com este trabalho.

No capítulo 3 são apresentados a especificação e o desenvolvimento. A especificação

ocorre através de ferramentas, mas são apresentadas de forma textual para compreensão. O

mesmo procedimento utilizado da especificação é utilizada no subcapítulos que descreve a

implementação do sistema.

Por fim o capítulo 4 contém a conclusão do trabalho, juntamente com sugestões para

trabalhos futuros.

16

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo são explanadas teorias, conceitos e ferramentas relacionadas a este

trabalho.

2.1 SISTEMAS MULTIAGENTES

Huhns e Stephens (1999, p. 79) dizem que os agentes são inseridos em um ambiente

com o qual podem interagir, sendo este tipicamente computacional. Este ambiente pode ser

aberto ou fechado, e conter um ou mais agentes. Mas hoje a interconectividade e o trabalho

em redes de computadores acabam tornando cada vez mais raras as situações onde os agentes

trabalham sozinhos. Atualmente os agentes tendem a se comunicar com outros agentes, assim,

apresentando características de coletividade e de sociedade de agentes.

A área de sistemas multiagente ocupa-se da construção de sistemas computacionais a partir da criação de entidades de software autônomas, denominadas agentes. Os agentes interagem através de um ambiente compartilhado por outros agentes de uma sociedade, e atuam sobre esse ambiente, alterando seu estado. (BORDINI; VIEIRA, 2003, p. 9, grifo dos autores).

Conforme Ferber (1999 apud HÜBNER, BORDINI e VIEIRA 2004, p. 57), em SMA

os agentes possuem dois grandes tipos de arquitetura. A primeira seria referente a agentes

reativos, onde, um grande número de agentes interage com o ambiente em prol de uma única

meta, idéia que tem sua origem na entomologia3, como por exemplo, um formigueiro, onde se

tem as formigas como agentes reativos, o mundo como ambiente e a coleta de comida como

uma das suas metas. Este tipo de arquitetura torna os agentes simples, mapeando as

percepções do ambiente em ações sem nenhum intermédio de outro processo. Por outro lado,

na arquitetura formada por agentes cognitivos, o sistema é formado por poucos agentes, o que

os torna sistemas sofisticados e complexos computacionalmente.

Segundo Rao e Georgeff (1995 apud HÜBNER 2003, p. 5) os agentes cognitivos

3 Estudo dos insetos.

17

possuem as seguintes características, as quais o diferem dos sistemas convencionais e dos

agentes reativos: tem autonomia funcional, o que possibilita a alteração de seu funcionamento

para adaptar-se ao ambiente; estão continuamente em funcionamento; possuem a capacidade

da comunicação e de modelagem dos outros agentes inseridos no mesmo ambiente, o que

evidencia suas propriedades sociais; seu conhecimento é introspectivo, ou seja, possui

representação do conhecimento explicitamente no código; possui mecanismo de controle

deliberativo, em outras palavras, os agentes raciocinam sobre as ações que realizam; têm

memória, assim podem se recordar de ações executadas anteriormente a seu estado atual; e

normalmente as sociedades de agentes cognitivos são formadas por poucos agentes.

2.2 ARQUITETURA BDI

Uma das propostas para os agentes deliberativos4 é a base do modelo de cognição,

sendo este, formado por crenças, desejos e intenções que são as três principais atitudes

mentais (WOOLDRIDGE, 1999, p. 54-55). A arquitetura BDI está estruturada da seguinte

forma, conforme Wooldridge (1999, p. 54-60):

a) crenças: representam aquilo que o agente sabe sobre o estado do ambiente e dos

agentes naquele ambiente (inclusive sobre si mesmo);

b) desejos: representam estados do mundo que o agente quer atingir. Em tese, desejos

podem ser contraditórios, ou seja, pode-se desejar coisas que são mutuamente

exclusivas do ponto de vista de ação prática, por exemplo, um agente

representando uma criança em um ambiente como um mercado. O agente criança

deseja comprar bolachas e chocolates, mas só tem como pagar por um dos dois;

c) intenções: representam seqüências de ações específicas que um agente se

compromete a executar para atingir determinados objetivos.

4 Conforme Hübner, Bordini e Vieira (2004, p. 58), um agente é deliberativo quando, “dada uma motivação e uma representação do estado atual do ambiente em que se encontra o agente, esse tem que ser capaz de decidir, dentre os estados de ambiente possíveis de ocorrerem no futuro, quais de fato serão os objetivos a serem seguidos por ele”.

18

2.3 METODOLOGIA PROMETHEUS PARA DESENVOLVIMENTO DE SMA

Apesar da existência de várias metodologias como MaSE, Tropos, PASSI, Message e

Gaia neste trabalho só será vista uma, a Prometheus. Conforme Padgham e Winikoff (2004, p.

7), Prometheus é uma metodologia especificamente desenvolvida em resposta a necessidade

de ajuda e direcionamento no desenvolvimento e construção de sistemas de agentes. Segundo

Padgham, Thangarajah e Paul (2006, p. 4), a metodologia Prometheus é dividida em três

partes, vistas na Figura 1 e descritas da seguinte forma:

a) system specification: onde são identificadas as interações dos atores (humanos ou

software) com o sistema, e também especificadas as interfaces do sistema em

termos de ações e percepções; aqui se elaboram os objetivos, e descrita a

seqüência de passos dos cenários que serão desenvolvidos. Abrangendo algumas

pequenas funcionalidades (identificando objetivos, percepções e ações) que são

descritas e capturadas;

b) high-level (architectural) design: aqui são definidos quais tipos de agentes serão

usados no sistema sendo estes definidos através da combinação de papéis. A

estrutura total do sistema é descrita pelo system overview diagram. E os protocolos

de interação são usados para obter a dinâmica do sistema que é identificada pela

seqüência de mensagens;

c) detailed design: nesta fase há o desenvolvimento interno de cada agente, partindo

assim para as capacidades, eventos, planos e dados dos agentes.

19

Fonte: adaptado de Wooldridge (1999, p. 58).

Figura 1 – Diagrama de fases da metodologia Prometheus

De acordo com a descrição de Padgham, Thangarajah e Paul (2006, p. 4), uma

ferramenta em vem de encontro com a metodologia Prometheus é o PDT. Sendo que este é

um editor gráfico com suporte a tarefas especificas contempladas pela Metodologia

Prometheus. É destinado para projeto e o desenvolvimento de sistemas multi-agentes,

abrangendo a engenharia de software e colaborando no projeto e documentação dos vários

aspectos da especificação e desenvolvimento de um sistema orientado a agentes. As três fases

do Prometheus são tratadas dentro da ferramenta e seus respectivos diagramas, os quais são

apresentados a seguir:

a) analysis overview diagram: é um diagrama de visão geral dos requisitos do

sistema, onde se identifica os atores externos e o sistema é separado em cenários -

(pertence à fase system specification);

b) scenarios diagram: é a representação dos cenários que podem existir dentro do

sistema. Pode se descrever as etapas em cada um destes cenários (Figura 2) -

(pertence à fase system specification);

Legenda

Cenários Objetivos do sistema

Detalhamento inicial das funcionalidades

Ações, percepções

Diagrama de interação Conhecimento

do agente

Dados de acoplamento

Mensagens Dados compartilhados

Protocolos Visão geral do sistema

Detalhamento do agente

Detalhamento das capacidades

Visão geral do agente

Processos

Visão geral das capacidades

Detalhamento dos eventos

Detalhamento dos dados

Detalhamento dos planos

Esp

ecifi

caçã

o do

sis

tem

a

Arq

uite

tura

do

proj

eto

Det

alha

men

to

do p

roje

to

Passo intermediário

Verificação

Derivação

Artefato final do projeto

20

Fonte: Padgham, Thangarajah e Paul (2006, p. 30).

Figura 2 – Scenarios diagram

c) goal overview diagram: é utilizado para conceituar e desenvolver objetivos do

sistema. Aqui se identificam os objetivos a serem removidos, inseridos, fundidos

objetivos similares e criadas e/ou excluídas dependências (Figura 3) - (pertence à

fase system specification);

21


Figura 3 – Goal overview diagram

d) system role diagram: neste diagrama são agrupados objetivos, percepções e ações

em diferentes papéis (funções). Isto ajuda a modularizar o sistema. A entrada é

representada pela percepção e a saída como ação (Figura 4) - (pertence à fase

system specification);

22


Figura 4 – System role diagram

e) data coupling diagram: aqui são ligadas as funções definidas na fase anterior com

os dados que o mesmo necessita para executar suas funções. Neste diagrama é

possível adicionar ou remover papéis, dados e ligações. As ligações representam

leitura e escrita de dados (Figura 5) - (pertence à fase architectural);


Figura 5 – Data coupling diagram

23

f) agent-role grouping diagram: aqui são agrupados os papéis (funções), ou seja, são

distribuídos para cada agente uma ou mais funções que o mesmo deve exercer

(Figura 6) - (pertence à fase architectural);


Figura 6 – Agent-role grouping diagram

g) agent acquaintance diagram: neste diagrama se pode ver todos os agentes do

sistema e quais interagem entre si. Ele só possibilita a visualização e reorganização

dos objetos do diagrama, ou seja, não é possível modificar qualquer objeto (Figura

7) - (pertence à fase architectural);


Figura 7 – Agent acquaintance diagram

24

h) system overview diagram: apresenta uma visão geral de todo o sistema, mostrando

os agentes, seus relacionamentos e interações. Este é o digrama central do projeto,

é o ponto de convergência dos outros diagramas (Figura 8) - (pertence à fase

architectural);


Figura 8 – System overview diagram

i) agent overview diagram: diagrama que mostra em detalhes cada agente. Nele são

definidas as capacidades do agente, os planos e as mensagens trocadas entre os

agentes. Podem ser especificados também os dados internos. As percepções e

ações adicionadas neste diagrama são as já definidas nos diagramas anteriores


25


Figura 9 – Agent overview diagram

j) capability overview diagram: este diagrama permite especificar as capacidades

internas do agente, isto é, planos, sub-capacidades e mensagens que serão trocadas

entre agentes. Todas as percepções e ações adicionadas neste diagrama devem

estar nos diagramas agent overview, system overview and analysis overview


26


Figura 10 – Capability overview diagram

2.4 LINGUAGEM AGENTSPEAK(L)

Conforme Bordini e Vieira (2003, p. 14), Rao criou a linguagem AgentSpeak(L), que

de acordo com seu criador, Rao (1996, p. 42), é uma linguagem que visa a programação de

agentes BDI, sendo estes agentes reativos aos eventos ocorridos no ambiente onde estão

inseridos. Rao (1996, p. 43) comenta que a linguagem AgentSpeak(L) foi baseada em alguns

trabalhos anteriores como o Intelligent Resource-bounded Machine Architecture (IRMA) e o

Procedural Reasoning System (PRS), bem como, comenta sobre o Distributed Multi-Agent

Reasoning System (dMARS), sendo este um trabalho mais recente.

A linguagem é uma extensão natural e elegante de programação em lógica para a arquitetura de agentes BDI, que representa um modelo abstrato para a programação de agentes e tem sido a abordagem predominante na implementação de agentes inteligentes ou 'racionais' (WOOLDRIDGE, 2000 apud HÜBNER; BORDINI; VIEIRA, 2004, p. 61).

Conforme Bordini e Vieira (2003, p. 16-19) e Rao (1996, p. 45-47), os agentes

AgentSpeak(L) são especificados por um conjunto de crenças, que formam a base inicial de

27

crenças, juntamente com um conjunto de planos. Tem-se o átomo de crença que é um

predicado de primeira ordem, e os átomos de crença ou suas negações são denominados de

literais de crença. Uma coleção de átomos de crença é chamada de base de crenças.

Em AgentSpeak(L) os agentes possuem objetivos que se distinguem em dois tipos: os

objetivos de realização e os objetivos de teste. Ambos são predicados, bem como as crenças,

entretanto são prefixados pelos operadores ‘!’, para objetivos de realização, e ‘?’, para

objetivos de teste. Os objetivos de realização representam os estados no ambiente que o

agente deseja alcançar onde o predicado associado ao objetivo é verdadeiro. Já os objetivos de

testes tentam unificar o predicado de teste com uma crença do agente, sendo que, se conseguir

esta unificação retorna a crença resultante.

A adição e/ou remoção de crenças corresponde ao que se chama de evento ativador,

bem como a adição e/ou remoção de objetivos. Os planos fazem referência ao conjunto de

ações básicas utilizadas para atuar sobre o ambiente, sendo que as ações são atribuídas por

predicados com símbolos especiais (símbolos de ação). No Quadro 1 é apresentado um

exemplo. Os planos compõem-se por um evento ativador, seguido de um contexto (conjunção

de literais de crença) e de uma seqüência de ações, objetivos ou atualizações de crenças.

Fonte: Bordini e Vieira (2003, p. 17).

Quadro 1 – Exemplos de planos AgentSpeak(L)

Ao interpretando o Quadro 1 visualiza-se uma seqüência de passos iniciada quando o

agente identifica um conserto, se ele gostar do artista é executado o plano para comprar um

ingresso. No plano para comprar ingresso o agente verifica se o telefone não está sendo usado,

caso não esteja, ele faz a ligação para efetuar a compra. Por último o agente escolhe o acento

através de outro plano não exposto no exemplo.

Umas das ferramentas para se construir agentes usando a linguagem AgentSpeak é o

Jason, que de acordo com Bordini e Hübner (2006, p. 1), é um interpretador da linguagem

+concert(A,V) : likes(A)

← !book_tickets(A,V).

+!book_tickets(A,V) : ¬busy(phone)

← call(V);

…;

!choose_seats(A,V).

28

AgentSpeak(L), sendo esta, uma versão da linguagem AgentSpeak, que por sua vez, é baseada

na arquitetura BDI. Apesar de existir muitas implementações de sistemas com arquitetura

BDI, a definição de AgentSpeak possui uma importante característica: sua especificação

formal com semântica operacional, o que torna mais forte o motivo para construir um

interpretador como o Jason. Por ser implementado em Java, o Jason torna-se portanto multi-

plataforma, e é disponíbilizado como Open Source sob a licença GNU LGPL.

Os recursos do Jason segundo Bordini e Hübner (2006, p. iii) são:

a) negação forte (strong negation): possibilita sistemas que consideram tanto

mundo-fechado (closed-world) quanto mundo-aberto (open-world);

b) tratamento de falhas em planos;

c) comunicação baseada em atos de fala;

d) anotações em identificadores de planos, podendo ser usadas em funções

personalizadas para a seleção de planos;

e) suporte para o desenvolvimento de ambientes;

f) por utilizar o Simple Agent Communication Infrastructure (SACI), o Jason

possibilita executar SMA distribuído em uma rede;

g) biblioteca básica de “ações internas”;

h) pode ser estendida a biblioteca de ações internas.

2.5 TAC SMC

Todos os textos contidos nesta seção, bem como suas subseções, são escritas conforme

Collins et al. (2005, p. 1-21). O simulador de ambiente SCM é disponibilizado pelo fórum

TAC. O TAC é um fórum internacional projetado para promover e incentivar pesquisas de

alta qualidade que são relacionadas com agentes (SWENDISH INSTITUTE OF COMPUTER

SCIENCI, 2006).

O ambiente SCM foi desenvolvido por uma equipe de pesquisadores da e-Supply

Chain Management Lab na Carnegie Mellon University, da Minnesota of University e do

Swendish Institute of Computer Science (SICS). O TAC SCM consiste em competições com

29

seis agentes para competir por pedidos de consumidores e obtenção de vários componentes

dos fornecedores em um determinado número de “dias” (representados por alguns segundos

no simulador SCM). É interessante ressaltar que os consumidores e os fornecedores são

simulados pelo próprio SCM.

Todos os “dias” os consumidores pedem orçamentos para os agentes e selecionam um

para atendê-los, baseando-se na data de entrega e no preço, ou seja, o melhor fornecedor no

ponto de vista do determinado consumidor. Os agentes são limitados à capacidade da sua

linha de produção e pela procura de componentes de oito fornecedores. Quatro tipos de

componentes são requeridos para a construção de um Personal Computer (PC): Central

Processing Unit (CPU), motherboards, memory e disk drives, sendo que cada componente

possui várias versões. Os consumidores fazem pedidos de PCs cada um com combinações

diferentes de componentes.

O simulador inicia quando um ou mais agentes jogadores se conectam ao servidor

TAC SCM. Fica a cargo do servidor simular os fornecedores, os consumidores, as operações

bancárias, a linha de produção e os serviços de estoque para cada agente. A simulação

continua para um número fixo de “dias” da simulação. No final do jogo o agente que tiver a

maior quantia de dinheiro no banco do simulador é declarado o vencedor. Para uma melhor

clareza do fluxo e dos cenários do TAC SCM pode-se visualizar a Figura 11.

30

Fonte: adaptado de Collins et al. (2006, p. 1).

Figura 11 – Cenário do TAC SMC

2.5.1 Produtos e componentes

Os produtos a serem confeccionados pelo agente são PCs. Cada modelo de PC é

constituído de quatro componentes: CPU, placa mãe, memória e disco rígido. São

disponibilizadas duas famílias de CPUs e de placas mãe: Pintel e IMD, onde as CPUs Pintel

trabalham com a placa mãe Pintel e a CPUs IMD com as placas mãe IMD. Estas CPUs são

disponibilizadas em duas velocidades 2.0 GHZ e 5.0 GHz. As memórias possuem duas

capacidades de 1 GB e 2 GB e os discos rígidos também possuem duas capacidades 300 GB e

500GB. Cada componente recebe um identificador representado pela coluna chamada de

componentes na Tabela 1, onde são representados todos os componentes presentes na

simulação. Desta forma tem-se um total de 10 componentes diferentes, que podem ser

combinados em 16 configurações de PCs, como mostradas na Tabela 2, onde tem-se o

Cotação e Ordens

Oferta

Ofertas

Cotação e Ordens

Agendamento da produção

Agendamento da entrega

Consumidores - Diferentes níveis e demanda variável - Exige precisão na data da entrega

Fábrica - Capacidade limitada - Competição por fornecedores e ordens

Fornecedor - Só fabrica quando possui ordem - Varia produção e preço

Agente - Automatizado - Otimizado

Cenário TAC SCM

31

identificador da configuração do PC, seus componentes, quantos ciclos de produção

necessários para a sua fabricação e a que tipo de segmento de mercado o mesmo pertence.

Tabela 1 – Catálogo de componentes

Componente Preço base Fornecedores Descrição 100 1000 Pintel CPU Pintel, 2.0 GHz 101 1500 Pintel CPU Pintel, 5.0 GHz 110 1000 IMD CPU IMD, 2.0 GHz 111 1500 IMD CPU IMD, 5.0 GHz 200 250 Basus, Macrostar Placa mãe Pintel 210 250 Basus, Macrostar Placa mãe IMD 300 100 MEC, Queenmax Memória, 1 GB 301 200 MEC, Queenmax Memória, 2 GB 400 300 Watergate, Mintor Disco rígido, 300 GB 401 400 Watergate, Mintor Disco rígido, 500 GB


Tabela 2 – Combinação de PCs

Combinação Componentes Ciclos Segmento de mercado 1 100, 200, 300, 400 4 Baixa escala 2 100, 200, 300, 401 5 Baixa escala 3 100, 200, 301, 400 5 Média escala 4 100, 200, 301, 401 6 Média escala 5 101, 200, 300, 400 5 Média escala 6 101, 200, 300, 401 6 Alta escala 7 101, 200, 301, 400 6 Alta escala 8 101, 200, 301, 401 7 Alta escala 9 110, 210, 300, 400 4 Baixa escala 10 110, 210, 300, 401 5 Baixa escala 11 110, 210, 301, 400 5 Baixa escala 12 110, 210, 301, 401 6 Média escala 13 111, 210, 300, 400 5 Média escala 14 111, 210, 300, 401 6 Média escala 15 111, 210, 301, 400 6 Alta escala 16 111, 210, 301, 401 7 Alta escala


2.5.2 Agente

Cada competidor, que coloca um agente no simulador, deve desenvolver o agente que

32

seja responsável pelas seguintes tarefas:

a) negociar com os fornecedores;

b) fazer orçamentos dos pedidos feitos pelos consumidores;

c) planejar e controlar as atividades diárias da organização (linha de montagem)

d) e ordenar o envio dos pedidos prontos aos clientes.

O agente tem que ser totalmente autônomo na execução destas quatro tarefas, sendo

que estas tarefas são diárias. A intervenção humana não é permitida durante a simulação. A

Figura 12 ilustra os eventos diários envolvidos com o funcionamento do agente.

Fonte: adaptado de Collins et al. (2006, p. 3). Figura 12 – Representação dos dias no TAC, onde o agente negocia com os clientes e os fornecedores

e produz e entrega dos PCs

No início de cada dia, cada agente recebe as seguintes informações do ambiente:

a) dos consumidores:

- pedidos de cotação (RFQs) de PCs,

- os pedidos ganhos devido as cotações feitas pelos consumidores no dia

anterior,

Dia D -1 Dia D Dia D +1

Estoque e entrega

Produção

Negociação e Planejamento

RFQ e ordens dos consumidores

Ofertas dos fornecedores

RFQ e ordens para os fornecedores

Ofertas para os consumidores

Componentes para a produção PCs para

o estoque

Componentes dos fornecedores

PCs para os consumidores

Agendamento da entrega (para D+1)

Agendamento da produção (para D+1)

Estoque e entrega

Produção







o estoque



Agendamento da entrega (para D+1)

Agendamento da produção (para D+1)

Estoque e entrega

Produção







o estoque



Agendamento da entrega

Agendamento da produção

33

- penalidades e cancelamentos de pedidos com atraso na entrega;

b) dos fornecedores:

- cotações e ofertas de componentes em resposta as RFQs enviadas pelo agente

no dia anterior,

- entrega dos suprimentos para satisfazer os pedidos já feitos. Estes suprimentos

(componentes) podem ser usados na produção um dia após a entrega;

c) do banco:

- situação da conta do agente;

d) da fábrica:

- inventário com a quantidade de componentes e PCs terminados e disponíveis.

Durante um dia o agente deve tomar as seguintes decisões:

a) enviar as ofertas aos consumidores que enviaram uma RFQ;

b) procurar obter componentes enviando RFQs aos fornecedores;

c) aceitar ofertas dos fornecedores emitindo pedidos aos fornecedores;

d) decidir como alocar os componentes que estão no inventário, obedecendo a

capacidade de produção de PCs da fábrica e emitir a programação diária da

produção da fábrica ao qual o agente é responsável;

e) depois dos PCs prontos, emitir a programação de entrega dos mesmos aos clientes

que fizeram pedido.

2.5.2.1 Produção

Cada agente é dotado de uma fábrica de PCs, todas equivalentes entre si, e que tem a

capacidade de produzir qualquer tipo de PC. Esta fábrica que o agente recebe para gerenciar

possui uma limitação diária da capacidade de produção. Junto com a fábrica o agente recebe

um estoque que tem a capacidade para armazenar tanto os componentes comprados dos

fornecedores quanto os PCs já prontos. Cada tipo de PC requer um número específico de

ciclos de processamento (ver Tabela 2), sendo que isto interfere na capacidade diária de

produção.

Todos os dias o agente tem que enviar para a sua fábrica a programação da produção.

34

A linha de produção só inicia a montagem de um PC quando os componentes do mesmo já

estão disponíveis no estoque. Os PCs são produzidos sequencialmente até que a capacidade

seja esgotada. No final de cada dia os PCs que estão prontos são enviados para o estoque e

prontos para serem enviados no dia seguinte.

2.5.2.2 Envio

O envio é feito através de um controle de entrega, sendo que, este é enviado pelo

agente. Este controle especifica os produtos e as quantidades a serem enviados no dia

seguinte, e quais clientes que a entrega se aplica. Todas as entregas serão feitas a partir do

inventário do estoque, ou seja, somente serão enviados os PCs que já estão disponíveis no

mesmo. Assim como a fabricação, a entrega dos produtos é feitas de forma seqüencial até que

todas as entregas sejam feitas ou não tiver mais PCs no estoque para que as entregas sejam

realizadas. Fazendo um cronograma a seqüência de ações ficaria da seguinte forma:

a) dia d: antes do final do dia, o agente envia uma programação da produção que será

realizada no dia d + 1 pela fábrica;

b) dia d + 1: durante todo o dia a fábrica produz os PCs que foram pedidos pelo

agente, e antes do final do dia o agente envia um controle de entrega que será feito

no dia d + 2;

c) dia d + 2: os PCs são enviados, os mesmo serão entregues ao cliente no mesmo

dia.

2.5.2.3 Custo de armazenagem

Todos os dias o agente recebe uma mensagem de sua fábrica lhe informando da

quantidade de componentes e PCs que estão armazenados no seu estoque. Os componentes

não utilizados na produção nem os PCs prontos que não foram enviados terão um custo diário

S, que é um percentual baseado no preço do componente. Este custo é definido no início do

jogo e pode variar aleatoriamente entre a escala delimitada pelas constantes Smin e Smax que

35

são valoradas na Tabela 3, este valor é passado a todos os agentes no início do jogo. O custo

de armazenagem é especificado para todo o ano (220 dias).

36

Tabela 3 – Parâmetros usados no TAC SMC

Parâmetro Símbolo Configuração padrão Tamanho da simulação E 220 dias Capacidade de produção da fábrica comandada pelo agente

2000 ciclos / dia

Capacidade normal da produção dos fornecedores Cnom 550 componentes / dia Capacidade inicial da produção dos fornecedores acC 1− Cnom ± 35%

Fator de desconto do fornecedor δ 0,5 Pagamento efetuado quando se faz um pedido ao fornecedor

10%

Relação aceitável para compra de produto com único fornecedor disponível

Apr1 0,75

Relação aceitável para compra de produto com dois fornecedores disponíveis

Apr2 0,45

Reputação inicial 2000 Taxa de recuperação da reputação 100 unidades / dia Média de RFQs de consumidores de Alta e Baixa escala de mercado

[Qmin;Qmax] 25 – 100 por dia

Média de RFQs de consumidores de média escala de mercado

[Qmin;Qmax] 30 – 120 por dia

Intervalo entre relatórios de mercado 20 dias Tendência de volume de RFQs de clientes (todos os segmentos de mercado)

[Tmin;Tmax] [0,95;1/0,95]

Escala de quantidade por RFQs de consumidores [qmin;qmax] [1;20] Prazo para responder as RFQs dos consumidores De 3 a 12 dias depois

de receber a RFQ Escala de penalidades por RFQs de consumidores [Ψmin;Ψmax] De 5% a 15% do preço

da rteserva do consumidor por dia

Preço da reserva do consumidor 75 – 125% do preço normal dos componentes do PC

Taxa anual de debito do banco [αmin, αmax] 6,0 – 12,0% Taxa anual de deposito do banco [α'min, α'max] 0.5 α Taxa anual do custo para estocagem [Smin,Smax] 25% - 50% do preço

normal do componente Prazo para compromissos do fornecedor Tshort 20 dias Redução diária na capacidade disponível do fornecedor para compromissos a longo prazo

z 0,5%

Redução exponencial de alocação m 3,0 Fonte: adaptado de Collins et al. (2006, p. 17).

37

2.5.2.4 O banco

Cada agente tem uma conta no banco central, e inicia o jogo sem nenhum dinheiro

nesta conta. O dinheiro é adicionado a conta quando um cliente pede o envio de um produto.

O dinheiro é deduzido da conta quando o agente recebe os componentes de um fornecedor ou

quando o agente não entrega os produtos o que acarreta em penalidades. O agente poderá ficar

com seu saldo negativo durante a simulação.

Quando o agente está com o saldo negativo, a conta do agente é atualizada com base

no seguinte cálculo (os símbolos α e E podem ser visto na Tabela 3):

bd+1 = (1 + Εα

) bd + créditosd – débitosd

Onde bd é o saldo do dia, α é a taxa anual de empréstimos e Ε é a duração da simulação

em dias, dias da simulação, não dias reais. Geralmente a taxa é α = 10%.

Quando o agente tem o seu saldo positivo o cálculo usado é o seguinte:

bd+1 = (1 + Ε

'α) bd + créditosd – débitosd

Geralmente a taxa é α' = 5%. Os valores de α e α' são fornecidos ao agente no início da

simulação (ver Tabela 3). Diariamente, o banco notifica os agentes sobre o seu saldo atual.

2.5.3 Fornecedores

A simulação possui 8 fornecedores. Cada tipo de componente possui dois

fornecedores. Os fornecedores de CPUs são especializados em uma das duas famílias, ou seja,

o fornecedor que produz CPUs da marca Pintel só fabrica Pintel e o que fabrica IMD só

fabrica esta marca. Os demais produtores produzem todas as variedades dos componentes as

quais são destinados a fabricarem. A lista de fornecedores e seus respectivos componentes

podem ser vistos na Tabela 1.

38

2.5.3.1 Modelagem dos fornecedores

As tarefas as quais o fornecedor é responsável são listadas abaixo:

a) controlar a capacidade de produção para atender aos pedidos;

b) fazer ofertas aos agentes baseado na capacidade futura projetada;

c) enviar componentes para satisfazer os pedidos proeminentes.

Os fornecedores operam seguindo as seguintes regras:

a) possuem um rendimento maximizado;

b) os fornecedores possuem um formulário de gestão de riscos, sendo que, através

deste formulário podem reservar uma parcela de sua capacidade de produção

futura para negócios que possam surgir futuramente, dando a preferência a agentes

que tem um histórico de aceitação de suas ofertas;

c) os fornecedores só fabricam os produtos depois de receberem uma ordem de

pedido;

d) se a produção de componentes de um único pedido levar vários dias, o pedido

ganha prioridade. Este ganho de prioridade não acarreta em nenhum custo;

e) somente as ordens completas são enviadas, salvo que no último dia da simulação

as ordens parciais serão enviadas a um inventário da exaustão;

f) toda a capacidade excedente do dia atual é utilizada para atender a demanda de

pedidos futuros. Entretanto, as ordens finalizadas antes do seu prazo de entrega só

serão entregues no dia estipulado;

g) a capacidade de produção diária é definida randomicamente;

h) as vendas novas são feitas baseadas em uma previsão da capacidade futura;

i) se um pedido não puder ser atendido no dia especificado, este pedido terá

prioridade em relação aos outros pedidos do dia em que será feito. Isto acarreta em

atrasos na produção;

j) cada fornecedor sabe das interações que fez com cada cliente (agente), assim ele

dará preferência aos agentes que tem melhor aceitação de suas ofertas.

39

2.5.3.2 Pedidos enviados ao fornecedor

Para cada dia os agentes poderão enviar cinco RFQs (cotações) para cada produto

oferecido por um fornecedor, totalizando dez RFQs por fornecedor. Cada RFQ r para uma

quantidade especifica qr de um tipo de componente em particular c que será entregue em uma

data futura ir + 1 dias, mas somente se a cotação do preço não for maior do que o preço pr por

unidade. Se pr = 0, isto é tratado como inconsistente e uma oferta será gerada com o devido

preço. Se qr = 0, o preço será cotado na devida data, mas nenhuma ordem será feita. RFQs

que tem datas que ultrapassam o final da simulação, ou que tem datas que passam o limite de

dois dias (emitidos hoje, mas terão que ser ofertadas em menos de dois dias), serão

desconsideradas. Uma vez que o fornecedor calculou os preços, uma oferta é gerada para cada

RFQ recebida. Nesta oferta são colocadas possíveis reduções de quantidades qr (devido ao

preço de reserva), sendo que, o preço unitário não é maior que o pr tabelado. Se o preço de

uma unidade não for encontrada a quantidade será zero (qr = 0).

Os fornecedores guardam todas as RFQs feitas durante todo o dia, e no final deste

mesmo dia são calculadas as ofertas para que sua produção seja maximizada. No outro dia os

fornecedores enviam as ofertas para cada RFQ, contendo o preço, a quantidade ajustada e a

data de entrega. Caso o fornecedor não for capaz de disponibilizar a quantidade pedida na

data especificada, ele poderá enviar duas ofertas juntas para atender ao pedido, isto ocorre em

duas situações:

a) uma oferta parcial é gerada quando o fornecedor conseguir entregar parcialmente

os componentes na data especificada na RFQ. Note que a oferta parcial não é uma

redução de quantidade do pedido devido ao preço de reserva;

b) uma oferta completa, onde a quantidade é a pedida, mas, possui um prazo de

entrega maior, sendo que esta não pode ultrapassar o final da simulação.

As ofertas são enviadas no dia seguinte ao processamento em resposta as RFQs, onde

os agentes optam por aceitá-las ou não. Caso o agente tentar aceitar uma proposta parcial e

também uma completa, o fornecedor só irá aceitar a que chegar primeiro. Claro que isto só

ocorre quando o fornecedor envia duas ofertas para a mesma RFQ, mas se o agente tentar

aceitar as duas, o fornecedor aceitará apenas a primeira que ele receber. As ofertas feitas pelo

40

fornecedor são válidas somente para o mesmo dia. Quando o agente aceitar a oferta o mesmo

deve emitir uma ordem de fabricação para o respectivo fornecedor.

2.5.3.3 Produção diária

Cada fornecedor possui uma linha de produção pronta e com alguma capacidade, isto

para cada tipo de fornecedor. Para cada componente produzido Cnom denota capacidade

nominal. A capacidade nominal é a capacidade média de produção do fornecedor, sendo que,

ela é usada com o propósito de planejamento. A capacidade de produção real acdC de um

componente é calculada para o dia d (dia atual) e segue a fórmula definida abaixo:

acdC = max(1, ac

dC 1− + random(-0.05, +0.05)Cnom + 0.01 (Cnom - acdC 1− ))

,onde acdC 1− geralmente é Cnom ±35%. No início do dia cada fornecedor calcula ac

dC para sua

produção. Este cálculo estipula a capacidade limite do dia. No caso da capacidade calculada

for menor que a capacidade normal (acdC < Cnom), algumas ordens podem não ser atendidas no

dia que foi especificado.

2.5.3.4 Reputação do agente

Os fornecedores calculam a reputação dos agentes e desta forma oferecem preços e

prioridades aos agente que tem melhor reputação. Os fornecedores mantêm históricos de

interações que tem com cada agente. A reputação ζa é iniciada com 1 para cada agente a. O

cálculo é simples e feito da seguinte forma:

aζ = a

a

Ofertasquantidade

Comprasquantidade

,sendo que a quantidadeComprasa é a soma de todas as ofertas aceitas pelo agente a e

quantidadeOfertasa é a quantidade de propostas feitas pelo fornecedor ao agente a.

41

2.5.3.5 Definição de preços

O preço dos componentes a serem oferecidos ao agente pelos fornecedores, em

resposta as RFQs, são computados através de uma projeção futura da capacidade de produção,

dada pela fórmula:

−=

′

acd

lvaidbase

cidC

CPP

ιδ ,

, 1

,onde:

- idP , é o preço da oferta no dia d para uma RFQ que tem sua data determinada

para d + i + 1;

- δ é o percentual de desconto, padronizado como 50%;

- basecP é o preço base para um componente de um tipo c;

- acdC a capacidade atual no dia d do fornecedor;

- lavidC ′, é capacidade disponível no dia d, aplicado ao inventário de demanda I.

O cálculo de lavidC ′, é separado em dois fatores:

postid

priorid

lavid CCC ,,, +=′

,onde prioridC , é a capacidade do dia i anterior e calculado da seguinte forma:

∑ ∑+= +=

−+−=

i

dj

i

dj

cmjd

rfqjd

acd

priorid CICiCC

1 1,,, ,0min

e postidC , é negativo, sendo que seu objetivo é reservar capacidade do dia posterior i para não

atrasar na entrega dos pedidos, ou seja, 0, ≤postidC .

( )( )

−+−−−= ∑ ∑

+= ++=+Ε++∈

k

dj

k

idj

cmjd

postid

rfqjd

acd

idk

postid CICCidkC

1 1,,

1, ,0min,0min

L

,onde postidI + é o levantamento de capacidade de produção disponível após o cálculo post

idC , . Com

isto é possível disponibilizar uma parcela da produção para negócios futuros.

42

−= ∑

+=+

i

dj

cmjd

postid CII

1,,0max

Nas fórmulas anteriores, rfqjdC , representa a quantidade total de ofertas a serem enviadas

no dia 1++ jd .

2.5.3.6 Processamento de ofertas

O fornecedor gera uma oferta de acordo com as RFQs dos agentes e visando a

maximização de sua produção conforme a capacidade prevista. Os agentes são tratados de

forma justa, mas aqueles com melhor reputação têm prioridade. Esta prioridade é uma forma

de estimar quais são ofertas que tem mais chance de virar pedidos. Uma primeira

aproximação, baseada no conjunto de RFQs Rc de um componente c, tenta a maximização da

produção pela função objetiva:

ridRcr

r Pq ,∑∈

′

Onde q'r <= qr é a quantidade ofertada para a RFQ r, e ir é o momento inicial da

produção para a RFQ r. Os valores q'r são limitados a constante de capacidade e a constante

do preço estipulado.

( )∑+=

≥−Ε+∈∀k

dj

emjd

exjd CCdk

1,, 0,1L

Dada a função objetivo, a função do preço e as constantes, o fornecedor monta o

conjunto de ofertas que maximizam a sua produção.

2.5.4 Consumidor

Os consumidores fazem as requisições de diferentes tipos de PCs. Cada pedido tem

uma quantidade que varia de acordo com [qmin;qmax] (definidos na Tabela 3) e uma data

determinando a entrega. Os agentes devem fazer ofertas dentro do que foi estipulado na

requisição (quantidade e data) para que o consumidor considere a oferta.

43

2.5.4.1 Demanda de consumidor

A demanda é expressa pelas RFQs, e cada uma, especifica o tipo de produto, a

quantidade q, a data de prazo, o preço oferecido p e a penalidade x. Para cada RFQ do

consumidor, o tipo é selecionado randomicamente a partir dos tipos definidos (ver Tabela 2),

q é um intervalo definido por [qmin;qmax] e a data no intervalo entre [duemin;duemax]. O

consumidor também especifica um preço máximo por unidade que está disposto a pagar. Este

preço p também é escolhido randomicamente (Tabela 3). Os consumidores não consideram

ofertas com preços maiores que p. E ainda é definida a penalidade que o agente sofrerá caso

tenha atraso em sua entrega, restringido pelo intervalo [Ψmin;Ψmax].

Os pedidos dos consumidores são classificados em três segmentos: escala alta, média e

baixa. Para cada um destes, no início de cada dia d, é definida a quantidade de RFQs N dos

consumidores.

( )dQpoissonN =

,onde dQ é a média de RFQs de consumidores do dia d emitido para cada segmento de

mercado. dQ é definido através de τ e este é atualizado aleatoriamente:

( )( )ddd QQQQ τmin,max,min max1 =+

( )( )( )01.0,01.0,min,max maxmin1 −+=+ randomdd ττττ

2.5.4.2 Processamento das ofertas

Ao receber uma RFQ o agente pode responder para o consumidor que fez a RFQ com

uma oferta que contêm: o preço, a quantidade e data de entrega.

O consumidor só considera as propostas que obedecem aos seguintes critérios:

a) a oferta cobre a quantidade requisitada na RFQ;

b) a data da entrega é compatível com a data especificada;

c) o preço oferecido deve ser menor ou igual ao definido no RFQ.

As ofertas que passam por este critérios são selecionadas pelo consumidor, e é enviada

44

uma ordem de pedido ao agente da oferta ganhadora, com a mesma sendo selecionada pelo

critério de menor preço. No caso de um empate entre duas ofertas é feita uma escolha

aleatória. O agente que tem sua oferta aceita receberá a ordem de produção no dia seguinte.

Diariamente os agentes são informados sobre o preço mínimo e o máximo [Pmin;Pmax] do

dia anterior para cada tipo de PC.

2.5.4.3 Finalizando os pedidos

Os pedidos são encerrados quando os mesmos são entregues aos consumidores. O

pedido é enviado no dia d e entregue ao consumidor no dia d + 1, sendo assim, o pedido deve

ser enviado um dia antes do estipulado para a entrega para evitar penalidades por atraso. O

pagamento é depositado diretamente na conta do agente, sendo feito no mesmo dia da entrega

ou no mais tardar no dia seguinte à entrega.

As penalidades são alteradas diariamente de acordo com o atraso na entrega. Estas

penalidades são valores que são retirados diretamente da conta do agente com o passar dos

dias. As penalidades são aplicadas até o quinto dia de atraso, e após isto, o pedido é cancelado

e as penalidades suspensas. Após o término da simulação, os pedidos que não podem mais

serem entregues geram penalidades até o quinto dia.

Os agentes são diariamente avisados das penalidades por entregas atrasadas e sobre os

cancelamentos de pedidos pelos clientes devido à falta de entrega.

2.6 TRABALHOS CORRELATOS

No que diz respeito a conceitos, técnicas e ferramentas pode-se citar o trabalho

descrito em Appio (2004), que define um SMA que age em um jogo estilo PacMan, onde os

agentes representam os fantasmas que tem o objetivo de dificultar a vitória do personagem

come-come que é controlado pelo usuário. O autor desenvolveu o ambiente na linguagem

Java assim como a interface com o usuário. Foi utilizada a ferramenta Jason para o

45

desenvolvimento dos agentes dos personagens fantasmas, seguindo a arquitetura BDI e

baseando-se na linguagem AgentSpeak(L). Segundo Appio (2004, p. 29), o objetivo dos

agentes fantasmas é “criar e executar estratégias de armadilhas para pegar o come-come.”

Em uma variação, Dalcastagne (2006) detalha um SMA atuante em um sistema de

livraria virtual, também usando a mesma linha de desenvolvimento do descrito no parágrafo

anterior, como o acréscimo da utilização da metodologia Prometheus. Conforme Dalcastagne

(2006, p. 50-51) o sistema é composto por quatro agentes:

a) agent sales assistant, que negocia com o cliente de maneira análoga ao assistente

real de uma loja qualquer;

b) agent delivery manager, que organiza todos os aspectos relacionados à entrega do

produto ao cliente;

c) agent customer relations, que é responsável por todas as transações off-line com o

cliente;

d) agent stock manager, que é responsável pelo estoque de livro da loja.

As interfaces do sistema são executadas em ambiente web e têm o propósito de

interação entre usuário e os agentes. O objetivo do autor era o desenvolvimento de um sistema

comercial com a utilização do paradigma de agentes.

Abrangendo o contexto do TAC SCM, há a implementação de um agente descrito por

Galindo, Ayala e Lópes (2006), Denominado de Tiancalli. É um projeto mexicano existente a

dois anos. Onde se define um agente implementado com mecanismos de real-time

(atualização imediata da visão que o agente tem sobre o ambiente simulado) e case-event (o

agente é separado em subsistemas, onde cada um deles atende determinada situação que é

disparada por um evento). Dentro do projeto são definidas estratégias para a competição

havendo todo um estudo para melhorá-las ao longo do tempo. Segundo Galindo, Ayala e

Lopes (2006, p. 3), o agente Tiancalli06 apresenta três subsistemas, um sistema destinado a

compra de componentes, outro para a seleção de clientes e um último para cuidar da parte da

fabricação e estoque.

46

3 DESENVOLVIMENTO DO SISTEMA

As próximas seções descrevem a especificação e a implementação do agente para

interagir com o simulador TAC SCM e a interface de comunicação entre o agente e o

simulador.

3.1 REQUISITOS DO PROBLEMA A SER TRABALHADO

O agente SCM deverá apresentar os seguintes requisitos gerais:

a) negociar com os fornecedores do ambiente TAC SCM (requisito funcional - RF);

b) fazer orçamentos dos pedidos dos consumidores do ambiente TAC SCM (RF);

c) planejar e controlar as atividades diárias da organização TAC SCM (RF);

d) enviar os pedidos prontos aos clientes do ambiente TAC SCM (RF);

e) ser compatível com a Application Programming Interface (API) do ambiente de

simulação TAC SCM (requisito não-funcional – RNF);

f) ser programado em AgentSpeak(L), sendo o Jason a ferramenta a ser utilizada

(RNF);

g) deverá ser baseado na arquitetura BDI (RNF);

h) deverá ser autônomo nas suas ações (RNF).

47

3.2 ESPECIFICAÇÃO

Nesta seção são apresentadas as funcionalidades, cenários e detalhes do agente e da

interface de comunicação.

3.2.1 Visão geral do sistema

A Figura 13 mostra uma visão geral do sistema focando a figura do agente a ser

implementado. Neste diagrama pode-se visualizar todas as interações entre o simulador e o

agente. O agente tem suas metas (menor preço, menor prazo, etc), bases de conhecimento

(parâmetros do jogo) em linguagem AgentSpeak(L) e as mensagens enviadas e/ou recebidas

por uma camada intermediária, o significado destas metas e mensagens já foram vistos na

seção 2.5.2. No caso dos agentes consumidor, fornecedor, linha de produção, estoque e banco,

o próprio simulador se encarrega de atingir as metas e receber e/ou enviar mensagens.

48

Figura 13 – Visão geral do sistema focado no agente

3.2.2 Cenários

Na seqüência são apresentados os cenários que representam as funcionalidades do

agente. Os cenários foram montados de acordo com o que foi descrito na documentação do

simulador TAC SCM (Figura 14).

49

Figura 14 – Diagrama de cenários TAC SCM

Os cenários apresentados na Figura 14 são explicados nos itens a seguir:

a) cenário de pedido de cotação e montagem de proposta: este é o cenário de partida

para todos os outros cenários. O agente recebe dos consumidores a requisição para

cotação, monta a proposta e a envia para o consumidor;

b) cenário ordem de pedido: neste momento o consumidor já recebeu a proposta de

todos os agentes e selecionou o agente que vai atender a sua demanda, então o

consumidor envia uma ordem de produção para o agente. A partir do recebimento

da ordem o agente verifica todos os requisitos para a produção;

c) cenário de envio de RFQ aos fornecedores: o agente verificou no cenário anterior

que não tem componentes suficientes para atender as ordens que chegaram, então

ele faz requisição de proposta dos fornecedores e espera estes retornarem;

d) cenário de recebimento da proposta e requisição de pedido: o agente recebe as

propostas dos fornecedores e escolhe a que atende suas especificações. Após as

propostas selecionadas, o agente faz os pedidos dos componentes ao respectivo

fornecedor;

e) cenário de recebimento de componentes e programação da produção: os

componentes anteriormente pedidos aos fornecedores são entregues, o agente

inicia o levantamento das ordens que ainda não foram atendidas e as agendam para

50

serem produzidas;

f) cenário programação de entrega de produtos: após produzidos os produtos devem

ser entregues, novamente o agente faz o levantamento das ordens que estavam em

produção e que podem ser atendidas.

3.2.3 Agente

Seguindo o detalhamento do simulador TAC SMC (página 28), as funções que o

agente tem são: negociar com o consumidor, negociar com o fornecedor, gerenciar a produção

e gerenciar a entrega. A Figura 15 mostra o diagrama que atribui ao agente as funcionalidades,

vistas em detalhes na Figura 16. As funcionalidades vistas na Figura 16 serão devidamente

detalhadas na seção 3.2.4.

Figura 15 – Papéis do agente

51

Figura 16 – Diagrama detalhado dos papéis do agente

As mensagens recebidas pelo agente são:

a) RFQ do consumidor: o agente recebe uma RFQ, um pedido para cotação, vindo do

consumidor. Estas RFQs são geradas aleatoriamente pelo próprio simulador. Nesta

RFQ vem todos os dados para a montagem da proposta, como tipo de PC,

quantidade, data de entrega, preço que o consumidor prefere pagar. Esta

mensagem dá início ao processo que resulta na ação de envio de proposta;

b) ordem de pedido: também enviada pelo consumidor as ordem dão início ao

processo de pedidos por componente e posteriormente ao agendamento da

produção;

c) ofertas: são ofertas feitas pelos fornecedores após o agente ter feito uma RQF ao

mesmo, a partir desta mensagem o agente escolhe a oferta que lhe atende e gera

novas ações para enviar a ordem de produção para o fornecedor;

d) entregas de componentes: quando um fornecedor entrega os componentes que

foram pedidos pelo agente, isto faz com que o agente possa revisar a produção a

fim de atender as ordens dos consumidores que ainda não estão escalados para

serem produzidos;

e) itens prontos para a entrega; o agente percebe que a fábrica terminou a confecção

de um produto, assim dando início ao processamento de entrega.

52

As mensagens enviadas pelo agente são:

a) enviar proposta para o cliente: após receber as RFQs dos consumidores o agente

processa qual a disponibilidade, o custo e a data a qual ele dispõe para que o

pedido, que possa vir a ser feito seja atendido, todas as propostas são montadas e

após enviadas para os consumidores;

b) requisitar cotação ao fornecedor: ao receber a ordem de um pedido vinda do

consumidor o agente deve levantar seu estoque, ver o que está destinado a ser

usado na produção e requisitar uma cotação para os componentes faltantes. Isto é

feito através de uma RFQ mandada ao fornecedor;

c) faz pedido ao fornecedor: o fornecedor faz sua oferta e o agente verifica qual das

ofertas atende sua demanda. Após selecionada a melhor oferta o agente efetiva a

ordem de pedido para o fornecedor;

d) agendamento de produção: a cada entrega de componentes pelo fornecedor o

agente inicia o levantamento do que deve ser produzido primeiro, e assim agenda a

confecção dos PCs que atenderam as ordens de pedidos que tem sua data de

entrega mais próxima da data atual;

e) agendamento de entrega de produtos: quando a fábrica termina de produzir um PC

e o envia para o estoque, o agente começa a preparar o agendamento da entrega.

3.2.4 Funcionalidades

As funcionalidades implementadas neste trabalho são as relacionadas ao que está

descrito na subseção sobre agentes na seção sobre TAC SMC (página 28). Estas

funcionalidades são:

a) fazer orçamentos para pedidos feitos pelos consumidores: o simulador gera as

RFQs dos clientes e o mesmo envia ao agente. Este por sua fez identifica estas

RFQs e responde enviando, ao consumidor, um orçamento;

b) receber pedidos dos consumidores: após receber o orçamento, o consumidor, que é

representado pelo simulador, escolhe para qual agente enviar a ordem de pedido. O

53

agente recebe a ordem e faz toda a verificação para o início da produção do

mesmo;

c) negociar com os fornecedores: com o recebimento diário das ordens de serviços, o

agente precisa fazer constantes pedidos de componentes aos fornecedores;

d) planejar e controlar as atividades diárias da organização (linha de montagem): para

atender os pedidos dos consumidores o agente deve planejar a produção diária a

fim de deixar pronto cada pedido na data estipulada para que possam ser entregues

conforme a solicitação do consumidor;

e) ordenar o envio dos pedidos prontos aos clientes: quem faz a entrega do produto é

o próprio simulador, porém quem deve estipular quais pedidos serão enviados em

determinado dia é o agente.

3.2.5 Interface de integração

Como ambiente foi utilizado o simulador disponibilizado pelo fórum TAC e que é

denominado de TAC SCM pelo próprio. A simulação em si é separada em duas partes:

a) servidor: onde são representados os consumidores, os fornecedores, as fábricas

destinadas aos agentes competidores e os estoques. É a este servidor que o agente

deve se conectar para participar da simulação;

b) cliente: é a API que o agente deve conhecer para poder participar das simulações.

É através dela que o agente interage com o simulador, recebendo e enviando

informações.

Para fazer com que o agente tivesse capacidade de interagir com o ambiente foi

necessário implementar uma nova camada, possibilitando que o agente implementado em

Jason pudesse se comunicar com o ambiente simulado. A Figura 17 ilustra a estrutura que a

aplicação possui.

54

Figura 17 – Camadas da aplicação

A Figura 18 apresenta o diagrama de classes completo da camada de interação, sendo

que através dela pode-se ter uma visão geral da estrutura da camada a ser detalhada neste

capítulo. Na Figura 19, na Figura 20 e na Figura 21 pode-se ver as mesmas classes mais

detalhadamente, mostrando os atributos e métodos que cada classe contêm.

Agente (AgentSpeak(L))

Servidor TAC SCM

Camada de integração

API cliente TAC SCM

55

furb::TacScmJAgent

tacscm::TACSCMEv ent

tacscm::TACSCMProxyAgentFactory

SCMAgent

tacscm::TACSCMProxyAgentImpl

«interface»

tacscm::TACSCMProxyAgent

AgArchRunnable

jason::TacScmAgentArch

act::TacScmActionExecutiv eImpl

act::addDeliv eryProduct

act::addOfferClient

act::addOrderSuppliers

act::addProductionProduct

act::addRFQSuppliers

act::sendOfferClient

act::sendOrdersSuppliers

act::sendRFQsSuppliers

act::sendSchedules

«interface»

act::TacScmAction

«interface»

act::TacScmActionExecutive

Inicia

#agentArch

#proxyAgent

#agentFactorySingleton

#tacScmSingleton

Figura 18 – Diagrama de classes da camada de integração

56

Figura 19 – Diagrama de classes da interface de comunicação (parte1)

57

Figura 20 - Diagrama de classes da interface de comunicação (parte2)

58

Figura 21 – Classe de implementação para a comunicação entre o agente e o simulador

Na Figura 19 está presente a classe TacScmAgentArch que é a implementação da

arquitetura necessária para integrar o Jason com o ambiente TAC SCM, ou seja, ela estende

uma outra classe clamada de AgArch que faz parte da API do Jason. É esta classe que repassa

as crenças, percepções e eventos para o agente e executa, quando acionadas, as ações do

mesmo. O repasse de mensagens ao agente se dá na transformação das mesmas em crenças ou

eventos do agente programado em AgentSpeak(L). Mais explicações serão dadas ao longo do

texto.

59

A classe TACSCMProxyAgentFactory (Figura 19) é a classe que fica responsável por

iniciar o agente, conectá-lo ao simulador TAC SCM e ligar o agente com a classe que

representa a arquitetura, neste caso representada pela classe TacScmAgentArch . O que a

TACSCMProxyAgentFactory faz é criar uma instância da classe TACSCMProxyAgentImpl e

atribuí-la como classe representante do agente tanto para a TacScmAgentArch quanto para o

simulador.

Nas figuras Figura 19 e Figura 20 a classe TACSCMProxyAgentImpl aparece sem

métodos e atributos por motivos visuais, mas na Figura 21 é possível ver seus detalhes. Esta

classe é a responsável por interligar o agente com o simulador. Por ela são passadas todas as

mensagens do simulador que são convertidas em crenças, percepções e eventos, e também

nela se converte as ações do agente em mensagens para o simulador.

As figuras Figura 22 e Figura 23 mostram as interações entre as classes principais e a

integração que a camada faz na sua execução. Como já foi visto, é classe

TACSCMProxyAgentImpl que faz o papel de integração, e que pode ser visualizada de melhor

forma nas figuras Figura 22 e Figura 23. Observa-se que somente esta classe se comunica

com o simulador e vice-versa. As mensagens recebidas por esta classe são transformadas em

crenças ou eventos.

Os eventos são acumulados pela TACSCMProxyAgentImpl em uma lista e o agente de

tempos em tempos verifica se há novas percepções. O agente faz esta requisição através da

classe TacScmAgentArch , sendo que a mesma busca a lista de eventos da

TACSCMProxyAgentImpl e as repassa para o agente, representados no diagrama da Figura 23.

Já a adição de crenças ocorre de forma imediata. A classe TACSCMProxyAgentImpl

acrescenta uma crença ao agente (método addBelief ) através da TacScmAgentArch que por

sua vez a converte devidamente e a adiciona as crenças do agente. Esta seqüência pode ser

vista na Figura 22. Apesar de não ser ilustrado no diagrama de seqüência, existe ainda a

retirada de uma crença, sendo que, a retirada segue os mesmos procedimentos da adição.

60

Figura 22 – Diagrama de seqüência para adição de crenças

Simulador

TacScmAgentArchTACSCMProxyAgentImpl

Agente implementado emAgentSpeak

envia mensagem de informação

addBelief(...)

addBelief(...)

addBel(...)

61

Figura 23 – Diagrama de seqüência para adição de crenças

Simulador

TacScmAgentArch TACSCMProxyAgentImplClasses de ação

Agente implementado emAgentSpeak

TacScmActionExecutiveImpl

Perceive

getEvents

decide

act(...)executeAction(...)

action= getAction(...)

execute(...)metodo referente a ação

envia mensagens ao simulador

62

As descrições feitas nos próximos parágrafos podem ser acompanhadas na Figura 23.

Toda a seqüência é representada pelo último bloco de interação. A linha que foi chamada de

“Classes de ação” na Figura 23 representam de forma genérica todas as classes que

implementam a interface TacScmAction . Elas podem ser vistas através da Figura 18 e da

Figura 20. Além das classes, os métodos chamados da TACSCMProxyAgentImpl por estas

classe também foram generalizados.

Quando o agente dispara uma ação a classe TacScmAgentArch é responsável por

iniciar o processo que executará efetivamente esta ação no ambiente. Dentro desta, mais

especificamente no método act , é disparado o método executeAction da classe

TacScmActionExecutiveImpl (Figura 20). E esta é responsável por chamar a devida classe

que executará a ação que o agente requisitou.

Cada ação do agente é representada por uma classe que implementa a interface

TacScmAction . Todas as classes deste tipo possuem somente um método chamado de

execute . Por sua vez estas classes representantes das ações, repassam os dados interpretados

aos devidos métodos da classe TACSCMProxyAgentImpl (Figura 21), sendo que estes métodos

montam ou enviam uma mensagem.

3.3 IMPLEMENTAÇÃO

Na presente seção são contemplados os detalhes sobre ferramentas, técnicas,

implementação do agente e a operacionalidade.

3.3.1 Técnicas e ferramentas utilizadas

As ferramentas utilizadas no desenvolvimento deste trabalho foram o Jason e o

Eclipse.

O agente foi desenvolvido utilizando a ferramenta Jason, que é um interpretador

63

multi-plataforma para a linguagem AgentSpeak(L), disponível sob a licença General

PublicLicense (GPL) / Library General Public License (LGPL). E a integração com o

ambiente foi desenvolvida através do Eclipse.

3.3.2 Implementação da camada de integração

A implementação começo pela camada de integração entre a API de cliente que o TAC

SCM disponibiliza para a implementação de agentes e o agente implementado em

AgentSpeak(L). Esta camada foi desenvolvida em linguagem de programação Java, sendo que

a implementação das duas APIs (Jason e TAC SCM) são nesta mesma linguagem.

Através do interpretador Jason um projeto é iniciado com a extensão “.mas2j”, onde

são configurados a infra-estrutura do SMA e quais agente são relacionados a este projeto em

questão. No entanto foi necessário criar toda a estrutura utilizando Java ao invés de usar este

recurso, pois há a necessidade de relacionar o agente, programado em AgentSpeak(L), e o

simulador, programado em Java, sendo que isto não seria possível pelo método convencional.

No Quadro 2 é mostrado o código que substitui o projeto do Jason. O parâmetro

asSource passado para o método construtor da classe TacScmAgentArch é caminho do

arquivo que contêm a arquitetura do agente, ou seja, o código em AgentSpeak(L) de extensão

“.asl”. A ligação entre o agente e o simulador é feita dentro do método

createTACSCMProxyAgent , pertencente a classe TACSCMProxyAgentFactory , sendo este

chamado no método apresentado na linha 26 do Quadro 2.

64

Quadro 2 – Criação da arquitetura do agente

A linha que faz a ligação do agente com o simulador é apresentado no Quadro 3. O

método de ligação entre o agente e simulador recebe respectivamente como parâmetros um

objeto com alguns argumentos (como o nível de detalhamento que aparecerá no console), o

nome ou IP do servidor, a porta, o nome e a senha para conectar a simulação e o nome da

classe que representa o agente, incluindo o pacote.

Quadro 3 - Ligando agente escrito em AgentSpeak(L) e simulador TAC SCM

Como comentado nas seções anteriores a classe TACSCMProxyAgentImpl é a que

representa o agente no simulador. O caminho desta classe é passado como último parâmetro

no comando do Quadro 3 (linha 2). Esta classe recebe todas as mensagens que o simulador

manda. Para que uma classe converse com o simulador TAC SCM é necessário que ela

1 public TacScmAgentArch(String asSource) throws JasonException { 2 super(); 3 this. actionExecutive = new TacScmActionExecutiveImpl(); 4 // configurando o agente Jason 5 try { 6 Settings settings = new Settings(); 7 8 ClassParameters bbPars = new ClassParameters(); 9 bbPars. className = 10 DefaultBeliefBase. class.getCanonicalName(); 11 12 this.initAg(Agent. class.getCanonicalName(), bbPars, 13 asSource, settings); 14 // definindo arquitetura do agente 15 this.setArchInfraTier( new CentralisedAgArch()); 16 } catch (JasonException e) { 17 logger.log(Level. SEVERE, "Init error" , e); 18 } 19 try { 20 TACSCMProxyAgentFactory proxyAgentFactory = 21 TACSCMProxyAgentFactory. getTACSCMProxyAgentFactory(); 22 URL config = 23 TacScmAgentArch. class.getResource( "/br/furb/agent.conf" ); 24 25 proxyAgent = 26 proxyAgentFactory.createTACSCMProxyAgent( this, config); 27 } catch (URISyntaxException e) { 28 throw new JasonException(e.getMessage()); 29 } 30 }

1 SimClient client = new SimClient(configManager, host, port, 2 name, password, agentImpl);

65

estenda a classe Agent da API cliente. No caso desta implementação foi estendida uma classe

que estende a classe Agent , chamada SCMAgent, sendo escolhida por ter um nível de

abstração mais alto.

O simulador envia mensagens para a classe que representa o agente, sendo que esta

teria o papel de desempacotar as mesmas, sendo que a classe SCMAgent faz este papel. Ao

chegar uma nova mensagem esta classe identifica seu tipo, extrai os dados correspondentes e

chama um método de acordo com o tipo já identificado. Um exemplo seria no caso das RFQs

do consumidor, o método com a assinatura mostrada no Quadro 4, recebe todas as mensagens

vindas do servidor TAC SCM. Dentro deste mesmo método é retirado o conteúdo da

mensagem (linha 2 do Quadro 4), e o restante do código retira os dados necessários para o

processamento da RFQ e chama o método handleCustomerRFQs que é um método abstrato e

que deve ser implementado pela classe que estender a SCMAgent, que neste caso seria

implementado na TACSCMProxyAgentImpl .

Quadro 4 – Método de recebimento de mensagens vindas do servidor TAC SCM

No caso das RFQs dos consumidores a classe TACSCMProxyAgentImpl tem como

implementação do método chamado pela classe pai (SCMAgent) o código apresentado no

Quadro 5. Neste caso os atributos do parâmetro (objeto representante da RFQ) são

transformados para que a RFQ em questão seja adicionada como crença do agente

(addBelief ).

1 protected void messageReceived(Message message) { 2 Transportable content = message.getContent();

3 M 4 } else if (content instanceof RFQBundle) { 5 RFQBundle rfqBundle = (RFQBundle) content; 6 7 this. customerAddress = message.getSender(); 8 //Any offers from the previous day are no longer va lid 9 this. customerOfferBundle = null; 10 this. currentCustomerRFQs = rfqBundle; 11 // In TAC SCM only customers send RFQs to manufactu rers 12 handleCustomerRFQs(rfqBundle); 13 14 } else if (content instanceof OrderBundle) {

15 M 16 }

66

Quadro 5 – Implementação do método para atender as RFQs dos consumidores

Além de receber as mensagens vindas do simulador e transformá-las em objetos

entendíveis pelo agente, a camada de comunicação executa as ações do agente, ou seja, estas

ações que o agente dispara são transformadas em mensagens que serão enviadas ao simulador.

Estas ações são responsáveis por modificar o ambiente simulado. A classe TacScmAgentArch ,

que representa a arquitetura do agente, sendo esta acionada sempre que o agente executa uma

ação. O método act (Quadro 6) é chamado, que por sua vez chama um método genérico

(executeAction ).

1 protected void handleCustomerRFQs(RFQBundle rfqBundle) { 2 String str; 3 for ( int i = 0; i < rfqBundle.size(); i++) { 4 // identificador unico da rfq 5 str = rfqBundle.getRFQID(i)+ "," ; 6 // index da RFQ 7 str+= i+ "," ; 8 // tipo de PC 9 str+= rfqBundle.getProductID(i)+ "," ; 10 //quantidade pedida 11 str+= rfqBundle.getQuantity(i)+ "," ; 12 //preço ao qual o consumidor quer pagar 13 str+= rfqBundle.getReservePricePerUnit(i )+ "," ; 14 // o valor da penalidade por atrazo 15 str+= rfqBundle.getPenalty(i)+ "," ; 16 //data para entrega 17 str+= rfqBundle.getDueDate(i)+ "," ; 18 // data de validade para responder a RFQ 19 str+= rfqBundle.getValidDate(); 20 21 this. agentArch .addBelief( "client_rfq(" +str+ ")" ); 22 } 23 24 //Atualizando as crenças do agente sobre o estoque 25 this.updateCurrentInventory(); 26 }

67

Quadro 6 – Método de execução de ações

Dentro do método executeAction é chamado o método apresentado no Quadro 7, que

localiza a classe que corresponde a ação requisitada. Cada ação possui uma classe específica.

Esta classe faz o processamento e chama o método correspondente na classe

TACSCMProxyAgentImpl que manda a devida mensagem ao simulador.

Quadro 7 – Método de chamada da classe que representa as ações

1 public void act(ActionExec action,List<ActionExec> feedback){ 2 ActionExec acExec = getTS().getC().getAction() ; 3 if (acExec == null) { 4 return; 5 } 6 Term acTerm = acExec.getActionTerm(); 7 logger.fine( "doing: " +acTerm); 8 boolean actionResult; 9 try { 10 actionResult = actionExecutive .executeAction( this,acExec); 11 logger.fine( "done: '" +acTerm+ "' ->" +actionResult); 12 } catch (JasonException e) { 13 actionResult = false; 14 e.printStackTrace(); 15 } 16 acExec.setResult(actionResult); 17 getTS().getC().getFeedbackActions().add(acExec ); 18 }

1 public TacScmAction<TacScmAgentArch> 2 getAction(String actionName) throws JasonException { 3 TacScmAction<TacScmAgentArch> action = 4 actions .get(actionName); 5 if(action == null) { 6 try { 7 Class actionClass = 8 Class. forName( "br.furb.tacscm.jason.act." +actionName); 9 if(TacScmAction. class.isAssignableFrom(actionClass)) { 10 action = (TacScmAction<TacScmAgentArch>) 11 actionClass.newInstance(); 12 actions .put(actionName, action); 13 } else 14 throw new JasonException( "Incompatible action type for '" 15 +actionName+ "'" );

16 M 21 } 22 } 23 return action; 24 }

68

3.3.3 Implementação do agente

O agente foi implementado em linguagem AgentSpeak(L). Suas crenças iniciais são as

informações passadas pelo simulador quando o agente se junta a uma simulação e a mesma é

iniciada. Estas crenças são informações sobre parâmetros do simulador (Tabela 3), o catálogo

dos componentes (Tabela 1) e as configurações dos PCs (Tabela 2).

O agente possui parte do código que o faz reativo e parte que o faz cognitivo. O agente

é reativo referente às atualizações mais básicas das crenças como a atualização da data, assim

o agente pode reagir sem precisar “pensar” sobre a nova percepção. O Quadro 10 mostra o

que o agente faz ao iniciar um novo dia. O comando da linha 2 atualiza sua crença sobre o dia

atual, na linha 2 é executada uma ação que envia o agendamento da produção e das entregas

de PCs do dia seguinte e por fim zera a crença sobre a quantidade de ciclos de produção (linha

4). O último comando é a crença que serve para controlar a quantidade de PCs a serem

produzidos no próximo dia.

Quadro 8 – Procedimento de atualização da data corrente

As RFQs percebidas pelo agente são respondidas com as seguintes configurações: o

preço é o maior entre o definido pelo consumidor e o preço base do tipo de computador, e a

data de entrega é a estipulada pelo consumidor. As ordens dos consumidores disparam a

rotina de compra dos produtos. Toda a rotina feita apelo agente é mostrada no Quadro 9. O

evento lackingComponent é acionado pela camada de integração, sendo este evento que

inicia o processo. Todo o procedimento se resume a montar as RFQs, adicioná-las às

mensagens e enviar as mensagens com as RFQs adicionadas aos devidos fornecedores. Tanto

a adição das RFQs nas mensagens quanto o envio destas mensagens são feitas diretamente

pela interface de integração.

1 +updateCurrentDate(D) 2 <- -+currentDate(D); 3 sendSchedules; 4 -+cyclesProduction(0).

69

Quadro 9 – Procedimento de envio de RFQs ao fornecedores

A compra dos produtos é feita em dois passos: o primeiro passo é o envio de pedido de

cotação aos produtores; o segundo passo é o recebimento de ofertas dos produtores e o envio

de pedido. Em seguida os produtores fabricam os componentes e a partir da entrega deste o

agente dá início ao agendamento da produção.

Os planos para a verificação do agendamento da produção são iniciados assim que a

simulação começa. Todo novo processo de verificação de produção se inicia através da adição

de uma crença, a newProduction . Quando esta crença é adicionada o plano

startProduction é disparado conforme mostrado no Quadro 10.

Os dois planos de iniciação de produção, mostrados no Quadro 10, esperam por um

novo dia começar e o mesmo zerar os ciclos de produção agendados até o momento

(cyclesProduction(0) ). Isto ocorre com o comando .wait("+cyclesProduction(0)") ;

ele suspende o plano até que uma nova crença exatamente como a do parâmetro passado seja

adicionada. Em um primeiro momento o agente não terá recebido nenhuma ordem de pedido

dos consumidores então o segundo plano será o escolhido.

1 +lackingComponent(ProductID,Quantity) 2 <- .findall(rfqSupplier(ProductID,Quantity,Supp lier) 3 ,componentCatalog(ProductID,_,_,Supplier) 4 ,L); 5 -lackingComponent(ProductID,Quantity); 6 !!addRFQSupplier(L). 7 8 +!addRFQSupplier([]) 9 <- !sendRFQSupplier. 10 11 +!addRFQSupplier([rfqSupplier(ProductID,Quantity ,Supplier)|LD]) 12 : currentDate(D) 13 & (currentInventory(ProductID,QtdInv) 14 | not currentInventory(ProductID,_)) 15 & QtdInv < Quantity 16 <- addRFQSuppliers(ProductID,Quantity,Supplier, 0,D+2); 17 !addRFQSupplier(LD). 18 19 +!addRFQSupplier(LD). 20 21 // se não houver mais nenhuma rfq para adiciona r envia 22 // requisição de quotação aos fornecedores 23 +!sendRFQSupplier 24 : not lackingComponent(_,_) 25 <- sendRFQsSuppliers.

70

Os testes de um plano são feitos entre os indicadores “:” e “<-”. Estes testes é que

definem se o plano é relevante ou não ao contexto do agente. No caso do segundo plano o

teste é feito para verificar se não há ordem (linha 15 do Quadro 10). Não se esquecendo que o

plano selecionado segue a ordem em que estão, ou seja, se tiver dois planos que se aplicam ao

contexto aquele que estiver mais acima no código é o selecionado.

O segundo plano do Quadro 10 só aguarda o ciclo de agendamento de produção ser

zerado para que possa tentar reiniciar o processo para verificar os possíveis agendamentos

para o próximo dia. Para reinicializar o processo é adicionando a crença newProduction .

Quadro 10 – Processo de iniciação do processo de agendamento da produção

O primeiro plano do Quadro 10 (startProduction ) é executado quando o agente já

recebeu uma ordem de algum consumidor. Após a crença de ciclo de agendamento de

produção for zerada, o plano reúne todas as ordens que estão destinadas a serem produzidas e

as ordena por data de entrega. Por fim, o plano chama o plano setOrderInProduction que se

encarregará de agendar a produção e disponibilizará as ordens para a entrega quando a

produção das mesmas estiverem completas, sendo que este plano recebe como parâmetro a

lista de ordens de pedidos ordenadas pelo plano startProduction .

O Quadro 11 mostra o conjunto de opções para o plano setOrderInProduction . A

segunda e a terceira opção necessitam saber quantos ciclos já foram agendados, a capacidade

de produção total da fábrica, os detalhes sobre a configuração do tipo PC a ser produzido

(componentes e quantos ciclos consome) e a quantidade de componentes presentes no estoque

1 +newProduction <- -newProduction; !!startProduc tion. 2 3 +!startProduction 4 : clientOrder(D,Or,Of,RI,PI,Q,UP,"P",QP) 5 <- .wait("+cyclesProduction(0)"); 6 .findall(clientOrder(DueDate,OrderId,OfferId,RfqI d,ProdId, 7 Qtd,UnitPrice,"P",QtdPartial) 8 ,clientOrder(DueDate,OrderId,OfferId, RfqId,ProdId, 9 Qtd,UnitPrice,"P",QtdPartial) 10 ,L); 11 .sort(L,LO); 12 !!setOrderInProduction(LO). 13 14 +!startProduction 15 : not clientOrder(D,Or,Of,RI,PI,Q,UP,"P",QP) 16 & secondsPerDay(S) 17 <- .wait("+cyclesProduction(0)"); 18 +newProduction.

71

do próximo dia. Com base nestas informações é possível o plano definir se a ordem vai ser

produzida por completo ou parcialmente.

A segunda opção deste plano (Quadro 11) verifica se a quantidade de ciclos agendados

até o momento somados aos ciclos que a ordem precisa para ser produzida, não ultrapassa a

capacidade máxima de produção e se existe componentes suficientes para atender por

completo a ordem. Caso todos estes testes derem positivos, o agente adiciona o produto ao

agendamento da produção do dia seguinte passando como parâmetros o tipo de PC e a

quantidade pedida na ordem, sendo que esta adição é feita via ação. Após adicionar os PCs ao

agendamento, o agente prossegue com o processamento atualizando as suas crenças. Primeiro

atualiza a crença que controla quantos ciclos a produção do próximo dia vai ter e depois

atualiza as crenças sobre as ordens de pedidos através do plano

updateClientOrderProduction , que será explicado mais a frente. E finaliza usando uma

chamada recursiva, assim continua a percorrer a lista de ordens de pedidos.

A terceira opção do plano setOrderInProduction é responsável pela produção

parcial de uma ordem. Neste caso o plano não vai testar se a quantidade de componentes do

próximo dia no estoque é suficiente para atender toda a ordem e sim tenta agendar o máximo

que é possível produzir, ou seja, o plano verifica qual dos componentes necessários para a

produção tem a menor quantidade no estoque. O corpo de execução deste plano é o mesmo do

anterior tendo somente como diferença o plano que é chamado para atualizar as crenças sobre

as ordens de pedido que ao invés de chamar o plano updateClientOrderProduction é

chamado o plano updatePartialClientOrderProduction que não libera a ordem para ser

entregue e sim atualiza a quantidade que resta para ser produzida.

O último plano é para dar continuidade a recursividade quando os outros planos não

forem aplicáveis. E o primeiro plano é para que ao final do processamento da lista, volte a

verificar o agendamento da produção.

72

Quadro 11 – Processo de agendamento da produção

No Quadro 12 são apresentados os dois planos que atualizam as crenças das ordens. O

primeiro plano updateClientOrderProduction é chamado quando a ordem é totalmente

produzida, ou seja a ordem está pronta para a entrega. O segundo plano

updatePartialClientOrderProduction é acionado quando a ordem foi parcialmente

agendada para ser produzida, sendo que neste caso a ordem ainda não pode ser liberada para a

entrega pois não tem a quantidade suficiente de PCs para atender a entrega.

1 +!setOrderInProduction([]) <- +newProduction. 2 3 +!setOrderInProduction([clientOrder(DueDate,Orde rId,OfferId, 4 RfqId,ProdId,Qtd,UnitPrice,Status,QtdPartial )|LO]) 5 : cyclesProduction(QtdCycles) 6 & pcConfig(ProdId,CPU,MB,Me,HD,BasePrice,ProdCycl es,Desc) 7 & factoryCapacity(Capacity) 8 & Capacity > (QtdCycles+(ProdCycles*QtdPartial) ) 9 & inventoryForNextDay(CPU,QtdCPU) & QtdCPU > = QtdPartial 10 & inventoryForNextDay(MB,QtdMB) & QtdMB >= Qtd Partial 11 & inventoryForNextDay(Me,QtdMe) & QtdMe >= Qtd Partial 12 & inventoryForNextDay(HD,QtdHD) & QtdHD >= Qtd Partial 13 <- addProductionProduct(ProdId,Qtd); 14 -+cyclesProduction(QtdCycles+(ProdCycles*Qt dPartial)); 15 !updateClientOrderProduction(DueDate, OrderId, Offe rId, 16 RfqId, ProdId, Qtd, UnitPrice, "P", QtdPa rtial); 17 !!setOrderInProduction(LO). 18 19 +!setOrderInProduction([clientOrder(DueDate,Orde rId,OfferId, 20 RfqId,ProdId,Qtd,UnitPrice,Status,QtdPartial )|LO]) 21 : cyclesProduction(QtdCycles) 22 & factoryCapacity(Capacity) 23 & pcConfig(ProdId,CPU,MB,Me,HD,BasePrice,ProdC ycles,Desc) 24 & inventoryForNextDay(CPU,QtdCPU) 25 & inventoryForNextDay(MB,QtdMB) 26 & inventoryForNextDay(Me,QtdMe) 27 & inventoryForNextDay(HD,QtdHD) 28 & .min([[QtdCPU,CPU],[QtdMB,MB],[QtdMe,Me],[Qt dHD,HD]] 29 ,[QtdPos,MinProd]) 30 & Capacity > (QtdCycles+(ProdCycles*QtdPos)) 31 <-!updatePartialClientOrderProduction(DueDate,Or derId, 32 OfferId, RfqId, ProdId, Qtd,UnitPrice, Status, 33 QtdPartial, QtdPartial-QtdPos); 34 addProductionProduct(ProdId,QtdPos); 35 -+cyclesProduction(QtdCycles+(ProdCycles*Qtd Pos)); 36 !!setOrderInProduction(LO). 37 38 +!setOrderInProduction([clientOrder(DueDate,Orde rId, 39 OfferId,RfqId,ProdId,Qtd,UnitPrice,Status,QtdPar tial)|LO]) 40 <- !!setOrderInProduction(LO).

73

Quadro 12 – Processo atualização das crenças de ordens de pedidos do consumidor

No Quadro 13 são mostrados todos os planos que representam a entrega das ordens já

produzidas pelo processo anterior. O processo de entrega é ativado pela adição de um PC ao

estoque. Assim como os componentes, cada PC possui um identificador que vai de 1 até 16

conforme Tabela 2. Assim quando qualquer produto é adicionado ao estoque, a percepção de

currentInventory é ativada, mas só quando for um produto que representa os PCs é que o

processo de entrega é iniciado (primeira parte do Quadro 13).

Após formada uma lista com as ordens que vão ser entregues a mesma é passada para

o plano setOrderInDelivery que vai adicionar cada ordem que será enviada ao estoque e

este se encarregará de fazer as entregas aos consumidores. Após adicionar as ordens a

mensagem que será enviada no início do próximo dia através da ação sendSchedules

(conforme mostrado no Quadro 8). A ação sendSchedules envia os PCs que serão

produzidos, assim como os que serão entregues.

1 +!updateClientOrderProduction(DueDate,OrderId,Off erId,RfqId, 2 ProdId,Qtd,UnitPrice,Status,QtdPartial) 3 :clientOrder(DueDate,OrderId,OfferId,RfqId,ProdId ,Qtd, 4 UnitPrice,"P",QtdPartial) 5 <- -clientOrder(DueDate,OrderId,OfferId,RfqId,Pro dId,Qtd, 6 UnitPrice,"P",QtdPartial); 7 +clientOrder(DueDate,OrderId,OfferId,RfqId,P rodId, 8 Qtd,UnitPrice,"D",QtdPartial). 9 +!updateClientOrderProduction(DueDate, OrderId, O fferId, RfqId, 10 ProdId, Qtd, UnitPrice, Status, QtdPartial). 11 +!updatePartialClientOrderProduction(DueDate, Or derId, 12 OfferId, RfqId, ProdId, Qtd, 13 UnitPrice, Status, QtdPartial, NewQtd) :clientOrder(DueDate,OrderId,OfferId,RfqId,ProdId,Q td,UnitPr

74

Quadro 13 – Processo de entrega de pedidos

3.3.4 Operacionalidade da implementação

Começando pelo lado do servidor, têm-se alguns passos para a inicialização de uma

nova simulação. Após baixar o simulador do site do TAC, o primeiro passo é rodar o servidor

executando o comando apresentado no Quadro 14.

1 +currentInventory(ProdId,QtdInventory) 2 : (ProdId >= 1 & ProdId <= 16) 3 & QtdInventory > 0 4 & currentDate(D) 5 <-.findall(clientOrder(D+3,OrderId,OfferId,RfqId, 6 ProdId,Qtd,UnitPrice,"D",QtdPartial) 7 ,clientOrder(D+3,OrderId,OfferId,Rfq Id, 8 ProdId,Qtd,UnitPrice,"D",QtdPartial) 9 ,L); 10 .sort(L,LO); 11 !!setOrderInDelivery(LO). 12 13 +!setOrderInDelivery([]). 14 15 +!setOrderInDelivery([clientOrder(DueDate,OrderI d,OfferId, 16 RfqId,ProdId,Qtd,UnitPrice,Status,QtdPartia l)|LO]) 17 : currentInventory(ProdId,QtdInventory) 18 & QtdInventory >= Qtd 19 <- addDeliveryProduct(OrderId); 20 !updateClientOrderDelivery(DueDate, OrderId, OfferId, 21 RfqId, ProdId, Qtd, UnitPrice, Status, QtdPa rtial); 22 !!setOrderInDelivery(LO). 23 24 +!setOrderInDelivery([clientOrder(DueDate,OrderI d,OfferId, 25 RfqId,ProdId,Qtd,UnitPrice,Status,QtdPartia l)|LO]) 26 <- !!setOrderInDelivery(LO). 27 28 +!updateClientOrderDelivery(DueDate,OrderId,Offe rId, 29 RfqId,ProdId,Qtd,UnitPrice,Status,Qtd Partial) 30 :clientOrder(DueDate,OrderId,OfferId,RfqId,ProdI d, 31 Qtd,UnitPrice,"D",QtdPartial) 32 <- -clientOrder(DueDate,OrderId,OfferId,RfqId, 33 ProdId,Qtd,UnitPrice,"D",QtdPartial).

75

Quadro 14 - Comando de execução do servidor TAC SCM

Neste momento o servidor já está ativo e acessível para execução de novas tarefas.

Para acessar o servidor, basta digitar o endereço http://localhost:8080 em um navegador. A

página para gerenciamento do servidor deve ser mostrada como na Figura 24.

Figura 24 – Página de gerenciamento do servidor TAC SCM

Para que o agente possa participar das simulações deste servidor é necessário fazer o

cadastro de usuário. Este usuário é utilizado posteriormente pelo agente para autenticar sua

conexão na simulação corrente. Para efetuar o cadastro de um novo usuário basta clicar no

link denominado de Register new user. Esta ação resultará na apresentação do formulário

mostrado na Figura 25.

java -jar scmserver.jar

76

Figura 25 – Formulário de cadastro de novo usuário no servidor TAC SCM

Com o novo usuário cadastrado podem-se criar novas simulações e visualizar a

simulação que está correndo no momento. Para que estas ações sejam possíveis é necessário

clicar no link chamado de Coming games (watch,create). Ao clicá-lo é pedido um usuário e

senha, que é o mesmo cadastrado anteriormente (ver Figura 26). Logo em seqüência a página

mostrada na Figura 27 é apresentada.

77

Figura 26 – Requisição de usuário e senha do TAC SCM

Figura 27 – Página para criação de nova simulação ou acompanhamento

Para criar uma nova simulação basta clicar no botão Create Game, e em seguida é

78

mostrada a página representada pela Figura 28. Com a simulação criada é preciso agora

adicionar um agente para que o cliente possa se conectar a simulação. Isto é feito através do

botão Join. Adicionado o agente a página vista na Figura 29 é mostrada. Este último passo

pode ser feito até que o limite de participantes se esgote, que por padrão é seis.

Figura 28 – Criada nova simulação

79

Figura 29 – Adicionando agentes na simulação

A simulação só irá iniciar quando o número máximo de participantes for atingido. O

simulador possui em seu pacote um agente padrão, sendo que, se o número máximo de

participantes não for preenchido em um dado tempo, o simulador preenche as conexões

faltantes com o agente padrão. Tanto o tempo de espera para iniciar uma simulação, quanto o

número máximo de participantes e a classe que representa o agente padrão são configuráveis

através de um arquivo que o servidor usa para obter os parâmetros de sua execução. A Figura

30 mostra uma simulação com uma conexão para o agente implementado e mais cinco

conexões para o agente padrão.

80

Figura 30 – Simulação rodando com agente padrão

Até agora foi mostrado como criar uma simulação. O link Launch Game Viewer abre

uma página contendo um applet que mostra os acontecimentos da simulação que está rodando

no momento (Figura 31). Este monitor da simulação permite ver detalhes sobre os

personagens como mostrado na Figura 32. Basta dar um duplo clique sobre a imagem do

personagem que se quer ver detalhadamente.

81

Figura 31 – Monitor de simulação

Figura 32 – Detalhes sobre consumidores

82

Para o agente se conectar na simulação é utilizada a API do cliente e esta possui uma

interface para monitorar o agente sem precisar olhar diretamente no monitor da simulação

(ver Figura 33). Esta interface é instanciada quando se coloca o agente em execução.

Figura 33 – Acompanhamento do agente no lado do cliente

A execução do agente implementado neste trabalho se dá através do método main na

classe TacScmJAgent . Dentro deste método é criada a instância da classe

TacScmAgentArch e assim seguindo toda a especificação feita na seção 3.2.5. A partir do

momento em que o agente se conecta ao servidor de simulação a interface da Figura 33 é

instanciada pela API.

A Figura 33 representa o status do agente: fábrica, estoque, banco e mensagens. A

janela é dividida em seis partes ou quadrados. O quadrado superior esquerdo é uma mera

apresentação de uma imagem representando o agente. O quadrado superior direito são as

mensagens trocadas entre o agente e o simulador (RFQs, pedidos, entregas e penalidades). Os

83

quadrados do meio são gráficos de evolução do banco e da capacidade da produção. E os

quadrados da parte inferior representam as quantidades de produtos (componentes ou PCs)

que estão atualmente no estoque.

3.4 RESULTADOS E DISCUSSÃO

No que diz respeito à linguagem AgentSpeak(L) é uma linguagem que tem um nível de

abstração elevado o que facilita a implementação de agentes. O Jason como interpretador é de

grande ajuda na programação de agentes. Seus utilitários auxiliam plenamente o

desenvolvedor de projetos SMA. Como exemplo o fato de gerar códigos básicos para ações

internas e a modificação automática do arquivo do projeto ao gerar algo novo como no caso

de agentes. Outro ponto de grande valia na utilização do Jason é sua constante manutenção.

Durante a implementação houve varias liberações de versões.

Na parte de especificação a metodologia Prometheus foi de grande valia para a

visualização do sistema como o todo e em seus detalhes, possibilitando a identificação de

separações de atividades sendo que evidência a arquitetura que o agente deverá ter em seu

formato final. O PDT ajuda no momento de colocar a metodologia Prometheus em prática,

mas a ferramenta nem sempre é intuitiva. A metodologia é muito bem detalhada na

bibliografia escrita por Padgham e Winikoff (2004), mas a ferramenta PDT tem uma carência

de detalhamento nos tutoriais.

O simulador TAC SCM ao formar um ambiente tão complexo quanto é, propiciou uma

evolução considerável na experiência de programação na linguagem AgentSpeak(L) e na

visualização dos conceitos. A integração que teve que acontecer entre agente e simulador traz

uma visão aberta das possibilidades que este tipo de aplicativo pode ter.

Um dos maiores problemas encontrado foi o pouco detalhamento das implementação

das APIs, tanto do Jason como do simulador. Isto dificultou a integração entre as mesmas. A

implementação da interface de comunicação, além de não estar prevista, tomou mais tempo

do que o estimado. Isto foi devido à demora a encontrar o que se precisa e a quantidade de

testes que tem que ser feitos para se certificar de que é mesmo o resultado esperado.

84

Com relação ao desempenho do agente, o mesmo não possui estratégias de nível

satisfatório. Mesmo competindo com os agentes padrões do simulador ele não consegue uma

boa colocação ao final da simulação. Existe a necessidade de revisar para melhorar as

estratégias lhe dando maior competitividade.

85

4 CONCLUSÕES

Este trabalho apresentou duas contribuições para o desenvolvimento em competições

TAC SCM. A primeira é a possibilidade para mais desenvolvedores da área de agentes e da

linguagem AgentSpeak(L) para aprofundarem seus estudos. Até o término deste não havia

disponível nenhuma interface que fizesse o papel de comunicar o simulador TAC SCM com

os agentes programados no interpretador Jason. A segunda é a especificação do TAC SCM

em português e na metodologia Prometheus, dando assim, espaço para desenvolvedores de

outras metodologias e outras linguagens.

No desenvolvimento deste trabalho, notou-se uma adequação conceitual e arquitetural

entre a noção de agente adotada no interpretador Jason e simulador TAC SCM, simplificando

dessa forma a integração, que se deu apenas no nível de implementação. Isto se deve pelo fato

de que o paradigma de agentes ser bem aderente a arquitetura que o TAC SCM possui, isto é,

o ambiente e o agente precisam apenas trocar mensagens para interagir entre si. O

interpretador Jason foi de grande valia para a programação do agente. Sem o Jason a

implementação do mesmo seria mais dificultosa. A metodologia Prometheus juntamente com

a ferramenta PDT ajudou para a visualização de contexto e de comunicação entre o agente e o

simulador.

O agente implementado serve como ponto inicial para o desenvolvimento de um

agente mais completo e complexo para o TAC SCM. No entanto o atual estado do mesmo não

possibilita que este tenha um desempenho bom na simulação. Ainda existem falhas de

estratégias para que o agente seja um competidor mais relevante na simulação.

86

4.1 EXTENSÕES

Por ser um simulador complexo a implementação deste trabalho não esgotou

completamente as possibilidades para o simulador TAC SCM, sendo que este trabalho ainda

pode se estender de diversas formas. Uma destas formas é melhorando a camada de

integração entre o simulador e o agente, dentre as informações as quais o simulador

disponibiliza pode haver mais recursos disponibilizados pela API do cliente da simulação

TAC SCM. Um destes recursos são as ordens canceladas, atualmente o agente não recebe tal

informação.

Outra extensão seria o melhoramento das estratégias usadas pelo agente para competir

na simulação. Todos os planos necessitam de uma reorganização, como por exemplo, a

compra de componentes. Os componentes requisitados pelo agente não atendem a demanda

da produção. A fábrica pode produzir mais, se tiver componentes disponíveis para que os

computadores possam ser montados.

A especificação e implementação do simulador pode abrir campo para novas idéias de

simuladores (ambientes) de competição ou interação entre agentes. Idéias para integrar

simuladores ao ambiente do mundo real seria um exemplo. Os jogos, com certeza, tem sua

área de exploração. Introduzir agentes que representem personagens de um jogo seria uma

ótima área de pesquisa.

87

REFERÊNCIAS BIBLIOGRÁFICAS

APPIO, Alisson R. Sistema multiagentes utilizando a linguagem AgentSpeak(L) para criar estratégias de armadilha e cooperação em um jogo tipo PacMan. 2004. 49 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

BORDINI, Rafael H.; HÜBNER, Jomi F. Jason: a java-based interpreter for an extended version of AgentSpeak. [S.l.]: [s.n.], 2006. Disponível em: <http://jason.sourceforge.net/Jason.pdf>. Acesso em: 7 nov. 2006.

BORDINI, Rafael H.; VIEIRA, Renata. Linguagem de programação orientada a agentes: uma introdução baseada em AgentSpeak(L). Informática Teórica e Aplicada, Porto Alegre, v. 10, n. 1, p. 7-38, ago. 2003. Disponível em: <http://www.inf.ufrgs.br/~revista/docs/rita10/rita_v10_n1_p7a38.pdf>. Acesso em: 10 set. 2006.

COLLINS, John et al. The supply chain management game for the 2007 trading agent competition. Pittsburgh: School of Computer Science Carnegie Mellon University. Nov. 2005. Disponível em: <http://www.sics.se/tac/tac07scmspec.pdf>. Acesso em: 9 abr. 2007.

DALCASTAGNE, Daniel. Implementação de uma livraria virtual utilizando agentes BDI através da linguagem AgentSpeak(L). 2006. 75 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

FERBER, Jacques. Multi-agent system: an introduction to distributed artificial intelligence. Londres: Addison Wesley, 1999.

GALINDO, Daniel M.; AYALA, Darnes V.; LÓPES, Fabiola L. Tiancalli06: an agent for the supply chain management game 2006. In: IBERAGENTS 2006, 2006,Ribeirão Preto, SP.

HÜBNER, Jomi F. Um modelo de reorganização de sistemas multiagentes. 2003. 246 f. Tese (Doutorado em Engenharia Elétrica) - Escola Politécnica de Universidade de São Paulo, São Paulo.

HÜBNER, Jomi F.; BORDINI, Rafael H.; VIEIRA, Renata. Introdução ao desenvolvimento de sistemas multiagentes com Jason. In: ESCOLA DE INFORMÁTICA DA SOCIEDADE BRASILEIRA DE COMPUTAÇÂO, 12., 2004, Guarapuava. Anais... Guarapuava: UNICENTRO, 2004. p. 51-89. Disponível em: <http://www.inf.furb.br/~jomi/pubs/2004/Hubner-eriPR2004.pdf>. Acesso em: 08 set. 2006.

88

HUHNS, Michael N.; STEPHENS, Larry M. Multiagent systems and societies of agents. In: WEISS, Gerhard. Multiagent systems: a modern approach to distributed artificial intelligence. Cambridge: MIT, 1999. p. 79-120.

PADGHAM, Lin; WINIKOFF, Michael. Developing intelligent agent systems: a practical guide. Melbourne: John Wiley & Sons, 2004.

PADGHAM, Lin; THANGARAJAH, John; PAUL, Paresh. Prometheus Design Tool: user manual. [S.l.]: [s.n.], 2006. Disponível em: < http://www.cs.rmit.edu.au/agents/pdt/docs/PDT-Manual.pdf>. Acesso em: 3 abr. 2007.

RAO, Anand S. AgentSpeak(L): BDI agents speak out in a logical computable language. In: WORKSHOP ON MODELLING AUTONOMOUS AGENTS IN A MULTI-AGENT WORLD (MAAMAW’96), 7., 1996, Eindhoven, The Netherslands. Anais… London: Springer-Verlag, 1996. p. 42-55.

SWENDISH INSTITUTE OF COMPUTER SCIENCI. Trading agent competition: about TAC. [S.l.], 2006. Disponível em:<http://www.sics.se/tac/page.php?id=2>. Acesso em: 9 set. 2006.

TANENBAUM, Andrew S.; STEEN, Maarten van. Distributed systems: principle and paradigms. New Jersey: Prentice Hall, 2002.

WOOLDRIDGE, Michael. Intelligent agents. In: WEISS, Gerhard. Multiagent systems: a modern approach to distributed artificial intelligence. Cambridge: MIT, 1999. p. 27-77.

______. An introduction to multiagent systems. Chichester: John Wiley & Sons, 2002.

WOOLDRIDGE, Michael; JENNINGS, Nicholas R. Intelligent agents: theory and practice. [S.l.], 1995. Disponível em: <http://www.csc.liv.ac.uk/~mjw/pubs/ker95.pdf>. Acesso em: 07 set. 2006.

IMPLEMENTAÇÃO DE UM AGENTE TAC SCM EM...

Documents

Transcript of IMPLEMENTAÇÃO DE UM AGENTE TAC SCM EM...