CARLOS EDUARDO PANTOJA UMA METODOLOGIA PARA APOIO AO DESENVOLVIMENTO SEMI-AUTOMÁTICO DE SISTEMAS MULTI-AGENTES

(1)

MINIST´

ERIO DA DEFESA

EX´

ERCITO BRASILEIRO

DEPARTAMENTO DE CIˆ

ENCIA E TECNOLOGIA

INSTITUTO MILITAR DE ENGENHARIA

CURSO DE MESTRADO EM SISTEMAS E COMPUTAC

¸ ˜

AO

CARLOS EDUARDO PANTOJA

UMA METODOLOGIA PARA APOIO AO DESENVOLVIMENTO

SEMI-AUTOM ´

ATICO DE SISTEMAS MULTI-AGENTES

Rio de Janeiro

2012

(2)

INSTITUTO MILITAR DE ENGENHARIA

CARLOS EDUARDO PANTOJA

UMA METODOLOGIA PARA APOIO AO

DESENVOLVIMENTO SEMI-AUTOM ´

ATICO DE SISTEMAS

MULTI-AGENTES

Disserta¸cão de Mestrado apresentada ao Curso de Mestrado em Sistemas e Computa¸cão do Instituto Mili-tar de Engenharia, como requisito parcial para obten¸cão do t´ıtulo de Mestre em Sistemas e Computa¸cão.

Orientador: Ricardo Choren Noya - D.Sc.

Rio de Janeiro

2012

(3)

c2012

INSTITUTO MILITAR DE ENGENHARIA Pra¸ca General Tib´urcio, 80-Praia Vermelha Rio de Janeiro-RJ CEP 22290-270

Este exemplar ´e de propriedade do Instituto Militar de Engenharia, que poder´a inclu´ı-lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento.

´

E permitida a men¸cão, reprodu¸cão parcial ou integral e a transmissão entre bibliotecas deste trabalho, sem modifica¸cão de seu texto, em qualquer meio que esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e cita¸cões, desde que sem finalidade comercial e que seja feita a referência bibliográfica completa.

Os conceitos expressos neste trabalho s˜ao de responsabilidade do autor e do orientador.

005.12 P 198a

Pantoja, Carlos Eduardo

Uma Metodologia Para Apoio ao Desenvolvimento Semi-autom´atico de Sistemas Multi-agentes/ Carlos Ed-uardo Pantoja; orientado por Ricardo Choren Noya. – Rio de Janeiro: Instituto Militar de Engenharia, 2012.

114 p.: il.

Disserta¸c˜ao (mestrado) – Instituto Militar de Enge-nharia – Rio de Janeiro, 2012.

1. Sistemas e computa¸c˜ao. 2. Sistemas Multi-Agentes. 3. Arquitetura Orientada a Modelos. I. Noya, Ricardo Choren. II. Uma Metodologia Para Apoio ao Desenvolvimento Semi-autom´atico de Sistemas Multi-Agentes. III. Instituto Militar de Engenharia.

(4)

INSTITUTO MILITAR DE ENGENHARIA

CARLOS EDUARDO PANTOJA

UMA METODOLOGIA PARA APOIO AO

DESENVOLVIMENTO SEMI-AUTOM ´

ATICO DE SISTEMAS

MULTI-AGENTES

Disserta¸cão de Mestrado apresentada ao Curso de Mestrado em Sistemas e Com-puta¸cão do Instituto Militar de Engenharia, como requisito parcial para obten¸cão do t´ıtulo de Mestre em Sistemas e Computa¸cão.

Orientador: Ricardo Choren Noya - D.Sc.

Aprovada em 9 de Novembro de 2012 pela seguinte Banca Examinadora:

Ricardo Choren Noya - D.Sc. do IME - Presidente

Prof. Paulo Fernando Ferreira Rosa - Ph.D, do IME

Prof. Anarosa Alves Franco Brand˜ao - D.Sc. da USP

Rio de Janeiro 2012

(5)

(6)

AGRADECIMENTOS

Agrade¸co a todas as pessoas que cooperaram com o desenvolvimento desta disserta¸c˜ao de mestrado, tenha sido por meio de cr´ıticas, ideias, apoio, incentivo ou qualquer outra forma de aux´ılio.

Por fim, a todos os professores e funcionários da Se¸cão de Engenharia de Computa¸cão do Instituto Militar de Engenharia.

(7)

E aqueles que foram vistos dan¸cando foram julgados insanos por aqueles que n˜ao podiam escutar a m´usica.

(8)

SUM ´ARIO

LISTA DE ILUSTRAC¸ ˜OES . . . 10

LISTA DE ABREVIATURAS . . . 12

1 INTRODUC¸ ˜AO . . . 15

1.1 Problema . . . 20

1.2 Objetivo e Contribui¸c˜oes Esperadas . . . 21

1.3 Estrutura do Texto . . . 23

2 CONCEITOS B ´ASICOS . . . 24

2.1 Desenvolvimento Orientado a Modelos . . . 24

2.2 FAME Agent-oriented Modeling Language (FAML) . . . 25

2.3 Jason . . . 31

2.4 Moise+ . . . 34

2.5 JaCaMo . . . 36

2.6 Representa¸c˜ao de Transforma¸c˜oes . . . 36

3 A METODOLOGIA PROPOSTA . . . 38

3.1 A Modelagem do Sistema (PIM) . . . 39

3.2 Transforma¸c˜ao do Modelo de Especifica¸c˜ao para o Modelo de Projeto . . . 41

3.2.1 Modifica¸c˜oes . . . 42

3.2.2 As Transforma¸c˜oes QVT . . . 42

3.2.3 Transforma¸c˜ao Pim To Psm . . . 44

3.2.4 Transforma¸c˜ao Faml To Geaplam . . . 44

3.2.5 Transforma¸c˜ao System To System . . . 46

3.2.6 Transforma¸c˜ao Role To Role . . . 47

3.2.7 Transforma¸c˜ao SystemGoal To Goal . . . 48

3.2.8 Transforma¸c˜ao Organization To Group . . . 48

3.2.9 Transforma¸c˜ao Task To Mission . . . 49

3.2.10 Transforma¸c˜ao Environment To Environment . . . 50

3.2.11 Transforma¸c˜ao Agent To Agent . . . 51

(9)

3.2.13 Transforma¸c˜ao MentalState To Goal . . . 53

3.2.14 Transforma¸c˜ao Facet To Percept . . . 54

3.2.15 Transforma¸c˜ao Plan To Plan . . . 54

3.2.16 Transforma¸c˜ao Action To Action . . . 56

3.2.17 Transforma¸c˜ao Action To InternalAction . . . 57

3.2.18 Transforma¸c˜ao Action To ExternalAction . . . 58

3.3 Transforma¸c˜ao do Modelo de Projeto para a Plataforma de Execu¸c˜ao . . . 59

3.3.1 Template Jason To Code . . . 59

3.3.2 Template System To Mas2j . . . 60

3.3.3 Template Environment To Class . . . 62

3.3.4 Template Percept To Attribute . . . 63

3.3.5 Template Agent To Asl . . . 64

3.3.6 Template Belief To Jason . . . 65

3.3.7 Template Goal To Jason . . . 66

3.3.8 Template Plan To Jason . . . 67

3.3.9 Template Action To Jason . . . 68

3.3.10 Template InternalAction To Jason . . . 70

3.3.11 Template Organization To Xml . . . 71 3.3.12 Template Structural To Xml . . . 72 3.3.13 Template Role To Xml . . . 73 3.3.14 Template Group To Xml . . . 74 3.3.15 Template GroupRole To Xml . . . 75 3.3.16 Template Link To Xml . . . 76 3.3.17 Template Functional To Xml . . . 77 3.3.18 Template Scheme To Xml . . . 77 3.3.19 Template SchemePlan To Xml . . . 78 3.3.20 Template Mission To Xml . . . 79 3.3.21 Template Goal To Xml . . . 80 3.3.22 Template Normative To Xml . . . 80 3.3.23 Template Norm To Xml . . . 80

3.4 Transforma¸cão do Modelo de Projeto para a Plataforma de Execu¸cão UAVAS 81 3.5 Discussão . . . 82

(10)

4 PROVA DE CONCEITO . . . 84

4.1 Sistema Gold Miners . . . 84

4.1.1 A Modelagem do Sistema . . . 85

4.1.2 A Gera¸c˜ao do Sistema . . . 90

4.2 Sistema UAVAS/Tropos . . . 92

4.3 Sistema Write Paper . . . 97

5 TRABALHOS RELACIONADOS . . . 104

5.1 INGENIAS Development Kit . . . 104

5.2 Prometheus Development Toolkit . . . 105

5.3 PASSI Toolkit . . . 106

5.4 Comparativo . . . 107

6 CONCLUS ˜AO . . . 108

6.1 Contribui¸c˜oes . . . 109

6.2 Trabalhos futuros . . . 110

(11)

LISTA DE ILUSTRAC¸ ˜OES

FIG.1.1 Vis˜ao tradicionalista de um SMA. . . 15

FIG.1.2 Um agente de software. . . 16

FIG.1.3 A arquitetura PRS. . . 19

FIG.1.4 A abordagem atual das plataformas de desenvolvimento SMA. . . 21

FIG.1.5 A abordagem proposta. . . 22

FIG.2.1 A Arquitetura Orientada a Modelos (OMG, 2003). . . 25

FIG.2.2 A Arquitetura de quatro camadas da OMG (OMG, 2012a). . . 26

FIG.2.3 O N´ıvel de Sistema (BEYDOUN et al., 2009). . . 27

FIG.2.4 O N´ıvel de Defini¸c˜ao do Agente (BEYDOUN et al., 2009). . . 28

FIG.2.5 O N´ıvel de Ambiente (BEYDOUN et al., 2009). . . 29

FIG.2.6 O N´ıvel do Agente (BEYDOUN et al., 2009). . . 31

FIG.2.7 O metamodelo JaCaMo (BOISSIER et al., 2011). . . 36

FIG.3.1 A metodologia proposta. . . 38

FIG.3.2 O metamodelo FAML adaptado (PANTOJA; CHOREN, 2012). . . 40

FIG.3.3 O metamodelo JaCaMo adaptado (PANTOJA; CHOREN, 2012). . . 43

FIG.4.1 Diagrama do agente Leader (BORDINI et al., 2007) . . . 85

FIG.4.2 Diagrama do agente Miner (BORDINI et al., 2007) . . . 86

FIG.4.3 Diagrama de atividades do sistema Gold Miners (BORDINI et al., 2007) . . . 87

FIG.4.4 Diagrama de atividades do sistema Gold Miners (BORDINI et al., 2007) . . . 87

FIG.4.5 O meta-modelo FAML instanciado para o sistema Gold Miners . . . 88

FIG.4.6 A instância do meta-modelo JaCaMo após as transforma¸cões QVT para o sistema Gold Miners . . . 89

FIG.4.7 O codifica¸c˜ao semi-autom´atica gerada para o sistema Gold Miners . . . 90

FIG.4.8 O trecho de c´odigo gerado a partir do template System To Mas2j . . . 91 FIG.4.9 O trecho de c´odigo gerado a partir do template Percepts To Attribute

91

FIG.4.10 O trecho de c´odigo gerado a partir do template Environment To Environment 91

(12)

FIG.4.11 O trecho de c´odigo gerado a partir do template Belief To Jason . . . 92

FIG.4.12 O trecho de c´odigo gerado a partir do template Plan To Jason . . . 92

FIG.4.13 O diagrama geral do sistema UAVAS. . . 93

FIG.4.14 O diagrama de metas do agente plane do sistema UAVAS. . . 94

FIG.4.15 O diagrama de atividades dos planos toDestination, photograph e getBack. . . 94

FIG.4.16 A instˆancia do modelo FAML para o sistema UAVAS. . . 95

FIG.4.17 A instância do meta-modelo JaCaMo após as transforma¸cões QVT para o sistema UAVAS. . . 96

FIG.4.18 O c´odigo gerado para o agente plane. . . 96

FIG.4.19 A estrutura do sistema Write Paper. . . 97

FIG.4.20 A estrutura do sistema Write Paper. . . 98

FIG.4.21 A instância do meta-modelo JaCaMo após algumas modifica¸cões. . . 100

FIG.4.22 O c´odigo JASON para o agente Jaime . . . 101

FIG.4.23 O c´odigo Moise para especifica¸c˜ao estrutural. . . 101

FIG.4.24 O c´odigo Moise para especifica¸c˜ao funcional. . . 102

FIG.4.25 O c´odigo Moise para especifica¸c˜ao normativa. . . 103

FIG.5.1 O ambiente gr´afico do PDT para a plataforma Eclipse. . . 104

FIG.5.2 O ambiente gr´afico do PDT para a plataforma Eclipse. . . 105

(13)

LISTA DE ABREVIATURAS

ABREVIATURAS

AAII - Australian Artificial Intelligence Institute BDI - Belief, Desire e Intention

CIM - Computer Independent Model

dMARS - Distributed Multi-agent Reasoning System EMF - Eclipse Modeling Framework

FAML - FAME Agent Modeling Language JAM - Java Agents for Meta-Learning

M2M - Model-To-Model

M2T - Model-To-Text

MDA - Model-Driven Architecture OCL - Object Constraint Language OMG - Object Management Group PIM - Plataform Independent Model PRS - Practical Reasoning System PSM - Plataform Specific Model

QVT - Query, View e Transformations RUP - Rational Unified Process

SMA - Sistemas Multi-Agentes TAO - Taming Agent Objects UML - Unified Modeling Language

(14)

RESUMO

Este trabalho apresenta uma metodologia MDA de desenvolvimento de sistemas multi-agentes que utiliza de modelos em diferentes n´ıveis de abstra¸cão, partindo da es-pecifica¸cão do sistema, e após um conjunto de regras de transforma¸cões entre modelos, chegar até a codifica¸cão da plataforma de execu¸cão JASON/Moise+.

A metodologia utiliza o FAML como modelo independente de plataforma, que é um meta-modelo que reúne os conceitos de diversas metodologias de desenvolvimento de sis-temas multi-agentes em um único modelo. Como modelo espec´ıfico de plataforma foi escolhido o modelo JaCaMo, que utiliza a linguagem de programa¸cão orientada a agentes JASON, o modelo organizacional Moise+ e o Cartago para programa¸cão de artefatos para o ambiente.

As transforma¸cões entre o modelo independente de plataforma e o modelo espec´ıfico de plataforma são apresentadas na linguagem QVT. A linguagem QVT foi escolhida por ser uma linguagem de transforma¸cão de modelos padronizadas pela OMG. As transforma¸cões entre o modelo espec´ıfico de plataforma e a codifica¸cão da plataforma de execu¸cão são apresentadas na linguagem M2T, padronizada pela OMG, que consiste em um conjunto de templates para gera¸cão de artefatos de texto.

Uma extensão da metodologia é apresentada para a gera¸cão de codifica¸cão para a plataforma UAVAS. A plataforma é utilizada para programar agentes inteligentes em JASON e AgentSpeak para Ve´ıculos Aéreos Não Tripulados. A extensão consiste em adi¸cões nas regras de transforma¸cões M2T.

Este trabalho apresenta, também, um ambiente de desenvolvimento de sistemas-multi agentes, que consiste de um conjunto de plugins para a plataforma de desenvolvimento Eclipse. Os meta-modelos FAML e JaCaMo foram constru´ıdos utilizando o Eclipse Mo-deling Framework. As transforma¸cões entre os modelo independente de plataforma e o modelo espec´ıfico de plataforma foram implementadas utilizando a ferramenta M2M e as transforma¸cões entre o modelo espec´ıfico de plataforma para o plataforma de execu¸cão foram implementadas utilizando a ferramenta Acceleo.

São apresentados três exemplos de sistemas multi-agentes. O Sistema Gold Miners que foi modelado na metodologia Prometheus, o sistema UAVAS modelado em Tropos exemplificando a codifica¸cão para VANT e o sistema Write Paper exemplificando a gera¸cão do modelo organizacional.

(15)

ABSTRACT

This work presents a MDA methodology for MAS development that uses models in different abstraction levels, going from system specification, and after a transformation set between models, get to the especific platform JASON/Moise+ codification.

The methodology uses the FAML as platform independent model, which is a meta-model that englobes the concepts of several agent-oriented methodologies for MAS devel-opment into a single model. As platform specific model, the JaCaMo model was chosen. The JaCaMo uses the agent-oriented program language named JASON, the organiza-tional model Moise+ and the artefact-oriented program language for environments named Cartago.

The transformations between platform independent model and platform specific model are presented in QVT language. The QVT was chosen because it is a transformation lan-guage for models which is standardized by OMG. The transformations between platform specific model and the execution platform are presented in M2T language, standardized by OMG, that consists in a set of templates to code generation.

A methodology extension are presented for platform UAVAS code generation. The platform is used to program intelligent agents in Jason and AgentSpeak for Unmanned Aerial Vehicles. The extension consists of additions in M2T transformations.

This work presents a MAS development environment, which is a set of Eclipse plugins. The FAML and JaCaMO metamodels were constructed using the Eclipse Modeling Frame-work. The transformations between platform independent model and platform specific model were implemented using the M2M tool and the transformations between platform specific model and execution platform were implemented using the Acceleo tool.

Three MAS examples are presented. The Gold Miners system that was modeled using Prometheus, the UAVAS system that was modeled in Tropos exemplifying the Unmanned Aerial vehicles codification and the Write Paper system exemplifying the organizational model codification.

(16)

1 INTRODUC¸ ˜AO

Os Sistemas Multi-Agentes (SMA) consistem em um grupo de agentes de software interagindo uns com os outros através de troca de mensagens na mesma rede de computa-dores (WOOLDRIDGE, 2000). Os SMA introduzem a possibilidade de agentes terem ob-jetivos comuns e conflitantes e interagem entre si através de negocia¸cões e comunica¸cões para decidirem cooperar para benef´ıcio mútuo ou competir para atingir suas metas (BEL-LIFEMINE et al., 2007).

Os SMA são desenvolvidos e projetados em termos de uma entidade autônoma de software que possa atingir seus objetivos interagindo com outros agentes através de uma linguagem de comunica¸cão ou protocolo (ZAMBONELLI et al., 2003).

Um SMA contem um quantitativo de agentes que se comunicam entre si e podem agir em determinado ambiente. Diferentes agentes possuem esferas de influência onde terão controle sobre o que será percebido do ambiente e que podem coincidir em alguns casos. Os agentes ainda podem estar agrupados em organiza¸cões com a finalidade de atingir objetivos e metas mútuas (WOOLDRIDGE, 2009). A figura 1.1 ilustra um agente tradicional de SMA.

(17)

Conforme (WOOLDRIDGE, 2000), agentes são componentes autônomos e cognitivos, originados da inteligência artificial, situados em um ambiente e não são receptores passivos de a¸cões executadas por outras entidades, pois possuem uma biblioteca de planos com poss´ıveis a¸cões em resposta aos est´ımulos percebidos com a finalidade de atingir seus objetivos de projeto e modificar o ambiente em que estão inseridos. O ambiente em que o agente está situado pode ser f´ısico ou de software e é percebido através de sensores. A figura 1.2 ilustra o conceito de agentes de software.

Um agente possui as seguintes propriedades: autonomia, onde os agentes operam sem a interferência direta de humanos e tem certo controle sobre suas a¸cões e estado interno; habilidade social, no qual o agente interage, por meio de troca de informa¸cões, com outros agentes através de uma linguagem de comunica¸cão; e reativos, onde os agentes percebem o ambiente e respondem a mudan¸cas que ocorrem nele (WOOLDRIDGE; JENNINGS, 2000).

FIG. 1.2: Um agente de software.

A arquitetura BDI (Belief, Desire e Intention) permite que programas de computa-dores possuam estado mental (BRATMAN, 1987). Um agente é considerado racional se escolher agir em busca dos seus interesses e baseado nas cren¸cas que possuir do mundo (WOOLDRIDGE, 1999). O BDI se refere ao uso de programas de computadores com analogias a cren¸cas (beliefs), desejos (desires) e inten¸cões (intentions). A defini¸cão de cren¸cas, desejos e inten¸cões é descrita como se segue (BORDINI et al., 2007):

(18)

• Cren¸cas s˜ao informa¸c˜oes que o agente tem sobre o mundo.

• Desejos são todas as possibilidades de estados de negócio que o agente deve querer atingir. Porém, ter um desejo não significa que o agente irá atuar sobre ele, mas este é uma potencial influência nas a¸cões do agente.

• Inten¸cões são todos os estados de negócios em que o agente decidiu trabalhar. Conforme (WOOLDRIDGE, 2009), a abordagem SMA permite a modelagem desde sistemas simples a complexos e são usados em uma variedade de aplica¸cões como indústria, gestão da informa¸cão, Internet, transporte, telecomunica¸cões, medicina e robótica.

Existem diversas ferramentas orientadas a agentes que auxiliam o desenvolvimento de um SMA. Entre elas encontram-se as metodologias e as linguagens de modelagens. As metodologias de desenvolvimento de SMA consistem em uma cole¸cão de modelos para formalizar e entender o sistema modelado antes de sua implementa¸cão. Esses mode-los come¸cam com uma tentativa de abstra¸cão até atingirem um n´ıvel mais próximo da implementa¸cão. As principais metodologias são Gaia (ZAMBONELLI et al., 2003), Tro-pos (BRESCIANI et al., 2003), Prometheus (PADGHAM; WINIKOFF, 2004), Adelfe (BERNON et al., 2003), INGENIAS (GASCUE ÑA; FERN ÁNDEZ-CABALLERO, 2007) e PASSI (COSSENTINO, 2005). Já as linguagens de modelagem mais conhecidas são Agent UML (BAUER et al., 2000) e MAS-ML (SILVA; LUCENA, 2003).

A metodologia Gaia permite que o designer desenvolva sistematicamente um sistema SMA até um n´ıvel de design que possa ser diretamente implementado e é constitu´ıda de duas categorias: abstrata e concreta. Os conceitos de papéis, permissões, responsabili-dades, protocolos, atividades fazem parte da categoria abstrata enquanto os conceitos de tipo de agentes, servi¸cos e conhecimento fazem parte da categoria concreta.

A metodologia Tropos prove um modelo conceitual para modelagem de sistemas orientados a agentes baseados nos conceitos de atores, objetivos, planos, recursos, de-pendências, capacidades e cren¸cas. Os modelos de atores e dependências são os primeiros a serem desenvolvidos , em seguida o modelo de objetivos é desenvolvido e por último o modelo de planos identifica as a¸cões para se atingir os objetivos.

A metodologia Prometheus se baseia em três fases de especifica¸cão do sistema: especi-fica¸cão do sistema, design de arquitetura e design detalhado. A primeira é responsável por identificar as funcionalidades básicas e os objetivos do sistema, a segunda identifica

(19)

os tipos de agentes e a estrutura do sistema, enquanto que a ´ultima refina as capacidades dos agentes.

A metodologia INGENIAS é baseada em cinco meta-modelos com diferentes visões e conceitos que podem descrever um SMA: Organiza¸cão, Ambiente, Tarefas/Objetivos, Agente e Intera¸cões. A utiliza¸cão de meta-modelos permite maior flexibilidade em decor-rentes altera¸cões na nota¸cão.

A linguagem de modelagem Agent UML utiliza os conceitos da Unified Modelling Language (UML) e da orienta¸cão a objetos para modelagem de SMA, adicionando suporte para concorrência e papéis. Adelfe é uma metodologia que também é baseada nas nota¸cões da orienta¸cão a objetos como a UML e o Rational Unified Process (RUP), e ainda, utiliza o Agent UML para expressar as intera¸cões entre agentes. A metodologia PASSI utiliza uma técnica passo-a-passo para desenvolvimento de SMA, através cinco modelos e é baseado nos conceitos da orienta¸cão a objetos. A linguagem de modelagem MAS-ML estende a nota¸cão da UML baseada no modelo conceitual Taming Agent Objects (TAO) (SILVA, 2003), que é dividido em conceitos estáticos e suas rela¸cões; e em conceitos dinâmicos.

Caso um modelo computacional de agentes precise ser implementado, utiliza-se o mo-delo de racioc´ınio prático fazendo o uso da delibera¸cão e o racioc´ınio fins-meio. Exis-tem diversas linguagens e plataformas que implementam o conceito de BDI como o PRS (BRATMAN, 1987), JAM (HUBER, 1999), dMARS (D’INVERNO et al., 1998), JACK (WINIKOFF, 2005), JASON (BORDINI, 2007) e JADEX (BELLIFEMINE et al., 2007). O PRS (Procedural Reasoning System) foi a primeira arquitetura de agentes a envolver explicitamente os conceitos de cren¸ca, inten¸cão e desejo, e tem provado ser a abordagem mais duradoura de desenvolvimento de agentes (BORDINI et al., 2007).

Em PRS, um agente não faz planos, ao invés disso, ele esta equipado com uma bi-blioteca de planos pré-compilados que são programados manualmente pelo programador do agente. Os planos em PRS contêm os seguintes componentes: metas (goals), contexto (context); e o corpo (body). No momento de sua inicializa¸cão, um agente PRS terá uma cole¸cão de planos, e cren¸cas iniciais sobre o ambiente. As cren¸cas são representadas como formulas atômicas da linguagem de primeira ordem e, além disso, um agente também possuirá uma meta principal (BORDINI et al., 2007). A arquitetura PRS pode ser vista na figura 1.3.

A linguagem JAM combina os conceitos do BDI e do PRS e cada agente ´e composto de cinco componentes: um modelo do mundo, uma biblioteca de planos, um interpretador,

(20)

FIG. 1.3: A arquitetura PRS.

uma estrutura de inten¸cão e um observador. A linguagem dMARS foi criada no AAII e é implementado em C++, onde cada agente é caracterizado por uma biblioteca de planos; três fun¸cões para sele¸cão da inten¸cão a ser executada, o plano a ser adotado e o evento que está sendo gerido, além fun¸cões auxiliares que são executadas durante o ciclo de vida do agente.

A plataforma JACK Intelligent Agents estende a sintaxe da linguagem Java com constru¸c˜oes espec´ıficas para agentes permitindo que os desenvolvedores definam carac-ter´ısticas do BDI e comportamentos como: agentes, capacidades, cren¸cas, vis˜oes, eventos e planos.

O JASON é um framework baseado em AgentSpeak e Java que utiliza as principais caracter´ısticas do PRS. Em JASON um agente é composto de cren¸cas, metas, planos e a¸cões e é programado utilizando o AgentSpeak. Os agentes em JASON estão inseridos em um ambiente, que estende a classe Environment, onde as percep¸cões e rea¸cões a est´ımulos do ambiente são programadas em Java (BORDINI et al., 2007).

A plataforma JADEX é um extensão BDI para a linguagem JADE (BELLIFEMINE et al., 2007) e possuem cren¸cas que podem ser qualquer objeto java armazenados em uma base de cren¸cas; metas que são descri¸cões dos estados a serem atingidos pelo agente; e planos que são procedimentos codificados em Java.

(21)

1.1 PROBLEMA

No desenvolvimento de SMA, ao se utilizar de uma metodologia existente para modelar um sistema orientado a agentes e implementa-lo usando uma linguagem de programa¸cão espec´ıfica, de forma não automática, uma série de problemas podem ser gerados relaciona-dos à engenharia de software, como o de produtos não confiáveis, a lentidão no processo de desenvolvimento dos produtos de software, a não-confiabilidade na transforma¸cão da modelagem para o código-fonte e o desenvolvimento pass´ıveis de erros humanos.

Além disso, os SMA são sistemas complexos em questão de design e implementa¸cão e a ausência de um ambiente de modelagem compromete o projeto, análise e codifica¸cão do software orientado a agentes. A realiza¸cão da modelagem de forma manual pode ser uma tarefa longa que gere retrabalho na implementa¸cão do sistema porque os desenvolvedores tem que lidar com a diferen¸ca entre os conceitos usados na especifica¸cão e na plataforma de implementa¸cão (NUNES et al., 2011).

Portanto, para auxiliar na análise e desenvolvimento de SMA, existem diversas platafor-mas de desenvolvimento que geram codifica¸cão automatizada para determinada linguagem de programa¸cão orientada a agentes a partir de uma linguagem de modelagem ou metodolo-gia espec´ıfica como Prometheus Development Toolkit (PDT) (SUN et al., 2010), INGE-NIAS Development Kit (IDK) (GOMEZ-SANZ et al., 2008) e PASSI Toolkit (PTK) (COSSENTINO; POTTS, 2002). Contudo, tais plataformas geram um atrelamento entre a linguagem de modelagem e a linguagem de programa¸cão utilizadas, limitando o desen-volvedor na escolha da metodologia e linguagem para o desenvolvimento do sistema, e ainda, algumas tecnologias não permitem o agregamento de novas funcionalidades por não utilizarem arquiteturas reutilizáveis. A figura 1.4 demonstra o funcionamento das plataformas descritas anteriormente.

A plataforma PDT gera codifica¸cão automática utilizando o Prometheus como lin-guagem de modelagem e gera codifica¸cão automática apenas para JACK apesar de per-mitir a integra¸cão com outras linguagens de modelagens. O IDK gera código em JADE utilizando a metodologia INGENIAS, que apesar de utilizar o desenvolvimento orientado a modelos, não utiliza um meta-modelo genérico para outras metodologias. Por último, a plataforma PTK gera apenas codifica¸cão em JADE utilizando a metodologia PASSI.

Para superar os problemas de geradores de código para linguagens de modelagens espec´ıficas é importante a utiliza¸cão de meta-modelos. A Arquitetura Orientada a

(22)

Mo-FIG. 1.4: A abordagem atual das plataformas de desenvolvimento SMA.

delos (Model Driven Architecture - MDA) é uma arquitetura padronizada pela OMG que permite a cria¸cão de solu¸cões de software utilizando meta-modelos que separam a especifica¸cão independente de modelo computacional da implementa¸cão em plataformas espec´ıficas (OMG, 2003).

Existem diversos meta-modelos para orienta¸cão a agentes como Islander (ESTEVA, 2002), TAO e FAML (BEYDOUN et al., 2009). O meta-modelo genérico FAME Agent-oriented Modeling Language (FAML) é uma tentativa de unificar os componentes do pro-duto de trabalho das metodologias SMA, de forma que o mesmo seja referência para o desenvolvimento da área e venha a ser utilizado para descrever qualquer SMA mod-elado, independente da metodologia de modelagem empregada e é um candidato para padroniza¸cão no desenvolvimento de SMA.

1.2 OBJETIVO E CONTRIBUIC¸ ˜OES ESPERADAS

O objetivo desse trabalho é a cria¸cão de uma metodologia para desenvolvimento de SMA que utiliza a abordagem de desenvolvimento orientado a modelos para a gera¸cão de código semi-automático para as linguagens de programa¸cão orientada a agentes JASON e o modelo organizacional Moise+ (HUBNER et al., 2002). A abordagem utiliza o FAML como o modelo independente de plataforma e o modelo baseado no JaCaMo (BOISSIER et al., 2012), formado pelas linguagens JASON e Moise+, como modelo espec´ıfico de plataforma.

A Arquitetura Orientada a Modelos é uma abordagem de desenvolvimento de soft-ware dirigida por modelos em diversos n´ıveis de abstra¸cão, onde um sistema é modelado usando um modelo independente de plataforma, no qual será transformado em um

(23)

mo-delo espec´ıfico de plataforma, dado um momo-delo de plataforma. A arquitetura também provê linguagens de transforma¸cões entre modelos como o Query-View-Transformations (QVT) da Object Management Group (OMG) para a instancia¸cão do modelo espec´ıfico de plataforma, e a linguagem de transforma¸cão de modelos em artefatos de texto Model-To-Text (M2T) da OMG, para gera¸cão de código.

A abordagem proposta permitirá a utiliza¸cão de uma linguagem de modelagem que seja aderente ao FAML, e através de um conjunto de transforma¸cões em QVT, realizar a transi¸cão da especifica¸cão para a plataforma espec´ıfica de desenvolvimento SMA. Após o modelo da plataforma espec´ıfica for instanciado, um conjunto de transforma¸cões uti-lizando o M2T realizará a transi¸cão da plataforma espec´ıfica de desenvolvimento SMA para a codifica¸cão semi-automática da plataforma JASON/Moise+. A abordagem ainda utilizará a linguagem Object Constraint Language (OCL) da OMG, para restri¸cão e val-ida¸cão dos modelos FAML e JaCaMo utilizados na transi¸cão entre a especifica¸cão e imple-menta¸cão do sistema. A abordagem tende a garantir uma maior portabilidade, qualidade, manutenibilidade e agilidade no processo de desenvolvimento de software e pode ser vista na figura 1.5.

FIG. 1.5: A abordagem proposta.

As contribui¸cões previstas neste trabalho são: (i) a cria¸cão de uma metodologia de desenvolvimento SMA, onde os meta-modelos baseados no FAML e no JaCaMo serão uti-lizados como modelos independentes e espec´ıficos de plataforma respectivamente; um con-junto de transforma¸cões entre modelos usando o QVT; um conjunto de regras utilizando o Object Constraint Language (OCL), da OMG, para a valida¸cão dos meta-modelos FAML

(24)

e JaCaMo; e um conjunto de transforma¸cões em M2T para gera¸cão de código semi-automática para JASON e Moise+; (ii) a cria¸cão de uma ferramenta para gera¸cão de código semi-automático para a linguagem de programa¸cão orientada a agentes JASON em conjunto com o Moise+. Os meta-modelos FAML e JaCaMo serão implementados pela ferramenta de meta-modelagem chamada ECORE e as transforma¸cões entre mode-los serão implementadas usando a ferramenta Model-To-Model (M2M) do Eclipse Mod-eling Framework (EMF) (FOUNDATION, 2012); as transforma¸cões para o código serão implementadas utilizando o Acceleo (OBEO, 2012). O ambiente será um conjunto de plug-ins para o ambiente de desenvolvimento Eclipse; (iii) uma extensão da metodologia proposta para gera¸cão de código semi-automática para o modelo Unmanned Aerial Vehi-cles AgentSpeak (UAVAS) (HAMA, 2012), que é um modelo que utiliza o JASON para programa¸cão de Ve´ıculos Aéreos Não-Tripulados (VANT) em simuladores e hardware.

1.3 ESTRUTURA DO TEXTO

Este trabalho está estruturado da seguinte forma: a se¸cão 2 apresentará os conceitos básicos de desenvolvimento orientado a modelos, do meta-modelo genérico FAML, das linguagens orientadas a agentes JASON e Moise+, do meta-modelo baseado no JaCaMo e as linguagens de transforma¸cões e valida¸cões QVT, M2T e OCL; a se¸cão 3 apresentará a abordagem proposta, a modelagem do modelo independente de plataforma, as trans-forma¸cões entre o modelo de especifica¸cão para o modelo de projeto, e as transforma¸cões do modelo de projeto para o modelo de execu¸cão; a se¸cão 4 apresentará duas provas de conceitos utilizando a abordagem; a se¸cão 5 apresentará os trabalhos relacionados; e por ´

(25)

2 CONCEITOS B ´ASICOS

Este cap´ıtulo apresenta os conceitos necessários ao entendimento da constru¸cão do am-biente de desenvolvimento SMA orientado a modelos. A se¸cão 2.1 apresenta os conceitos relacionados a Arquitetura Orientada a Modelos (Model Driven Architecture - MDA); a se¸cão 2.2 apresenta o meta-modelo genérico para desenvolvimento de SMA conhecido como FAML; a se¸cão 2.3 descreve as linguagens de programa¸cão SMA JASON e o modelo organizacional Moise+; a se¸cão 2.4 apresenta as linguagens de transforma¸cão de modelos Model-To-Model e Model-To-Text, além da linguagem para restri¸cão de modelo Object Constraint Language (OCL).

2.1 DESENVOLVIMENTO ORIENTADO A MODELOS

O Desenvolvimento Orientado a Modelos é uma abordagem de desenvolvimento de soft-ware que utiliza modelos para especifica¸cão das partes e conectores de um sistema e as regras de intera¸cão entre eles (OMG, 2003). A utiliza¸cão de modelos direciona o en-tendimento, design, constru¸cão, teste, opera¸cão, manuten¸cão e modifica¸cão do sistema (MELLOR, 2004).

O MDA permite aos desenvolvedores construir modelos de projeto sem o conhecimento de outros modelos de aplica¸cão, para depois, combiná-los e criar a aplica¸cão. O uso das técnicas de MDA permite que a aplica¸cão seja independente de plataforma aumentando a interoperabilidade do projeto e facilitando sua manuten¸cão. A OMG é responsável pela padroniza¸cão do MDA (OMG, 2003).

A utiliza¸cão do MDA come¸ca com os requisitos do sistema sendo modelados de forma independente de determinado modelo computacional. Esse modelo de dom´ınio é conhecido como Modelo Independente de Computa¸cão (Computation Independent Model - CIM) e será transformado para um Modelo Independente de Plataforma (Platform Independent Model - PIM), e através de um conjunto de transforma¸cões, será instanciado o Modelo Espec´ıfico de Plataforma (Platform Specific Model - PSM) (OMG, 2003).

O CIM é uma visão independente de computa¸cão do sistema que não mostra os de-talhes da estrutura do sistema e é o modelo de dom´ınio da solu¸cão. O PIM é constru´ıdo baseado nas opera¸cões do sistema com independência de plataforma de implementa¸cão e

(26)

em seguida um modelo espec´ıfico de plataforma é escolhido para permitir a implanta¸cão do sistema. O PSM é um modelo do sistema com o ponto de vista da plataforma uti-lizada, que combina as especifica¸cões do PIM com como o sistema utiliza as tecnologias da plataforma, enquanto as regras de mapeamento provêm a especifica¸cão necessária para a transforma¸cão do PIM no PSM. A Arquitetura Orientada a Modelos pode ser vista na figura 2.1

FIG. 2.1: A Arquitetura Orientada a Modelos (OMG, 2003).

A OMG padronizou a terminologia em uma arquitetura de quatro camadas para fa-cilitar a comunica¸cão entre objetos, modelos e meta-modelos. A camada M0 contém os dados do aplicativo em suas respectivas instâncias. A camada M1 contém o aplicativo em si, com suas classes de um sistema orientado a objetos ou as defini¸cões de um banco de dados relacional. Nessa camada é onde a modelagem do sistema ou aplicativo é realizada. A camada M2 contém os meta-modelos que capturam a linguagem de modelagem. A camada M3 é o meta-modelo que descreve outro meta-modelo e as propriedades que o meta-dado pode exibir (MELLOR, 2004). A figura 2.2 mostra um exemplo utilizando a arquitetura de quatro camadas.

O Meta-Metamodelo MOF descreve uma meta-metalinguagem abstrata utilizada para descrever outras metalinguagens para diferentes dom´ınios e também descreve um repositório de metadados para suportar metadados dos metamodelos baseados no próprio Meta-Metamodelo MOF.

2.2 FAME AGENT-ORIENTED MODELING LANGUAGE (FAML)

O FAME Agent-oriented Modeling Language (FAML) é um meta-modelo genérico para desenvolvimento e especifica¸cão de SMA, baseado no (BEYDOUN, 2006), que combina diferentes linguagens de modelagem orientadas a agentes dentro do mesmo dom´ınio da

(27)

FIG. 2.2: A Arquitetura de quatro camadas da OMG (OMG, 2012a).

engenharia de software. O meta-modelo genérico foi validado passando por refinamen-tos para garantir os conceirefinamen-tos promovidos pelas mais recentes metodologias orientadas a agentes. A inten¸cão é que o FAML forne¸ca um conjunto de conceitos genéricos úteis para qualquer linguagem de modelagem. A valida¸cão foi composta por quatro passos mapeando-se diversas linguagens de modelagem orientadas a agentes e metodologias, e.g., TAO, Islander, Adelfe, PASSI, Gaia, INGENIAS e Tropos (BEYDOUN et al., 2006).

O FAML é composto por duas camadas, a de design-time, onde o conceito central é o sistema orientado a agentes, incluindo suas defini¸cões, e a de runtime, onde o conceito central é o ambiente e os agentes que ali estão situados. A divisão dessas camadas permite que os conceitos de modelagem do SMA tanto quanto os conceitos em tempo de execu¸cão sejam considerados pelo engenheiro de software no momento da especifica¸cão do sistema. O conceito de agente também possui um papel central no FAML onde algumas classes desse meta-modelo estão relacionadas ao escopo interno, enquanto outras estão rela-cionadas ao escopo externo de um agente (BEYDOUN et al., 2009). Portanto é poss´ıvel identificar quatro categorias de classes para o FAML: n´ıvel do Agente, n´ıvel de Defini¸cão

(28)

do Agente, n´ıvel do Ambiente e n´ıvel do Sistema.

O escopo externo de um agente na camada de design-time é chamado de n´ıvel de Sistema e pode ser visto na figura 2.3. Nesse n´ıvel, um sistema é o produto final de um projeto de desenvolvimento de software orientado a agente. Um sistema é composto de papéis, tarefas, organiza¸cões e rela¸cões, que um sistema orientado a agentes pode ter. Um papel é um comportamento que um agente assume em determinado momento e é responsável pela realiza¸cão de um conjunto de tarefas, que auxiliam no atingimento de determinada meta de sistema. Os papéis podem ter relacionamentos dos tipos de compa-tibilidade e dependência entre si e estão hierarquicamente estruturadas. As organiza¸cões são compostas por agentes e papéis que estes podem assumir no sistema, onde eles atuam em conjunto para atingir uma meta de sistema em comum.

FIG. 2.3: O N´ıvel de Sistema (BEYDOUN et al., 2009).

O escopo interno de um agente na camada de design-time é chamado de n´ıvel de Defini¸cão do Agente e descreve as defini¸cões e especifica¸cões do agente. A figura 2.4

(29)

apresenta as classes associadas ao n´ıvel de Defini¸c˜ao do Agente.

FIG. 2.4: O N´ıvel de Defini¸c˜ao do Agente (BEYDOUN et al., 2009).

Todos os conceitos relacionados ao design-time do FAML podem ser vistos na tabela 2.1.

TAB. 2.1: Defini¸c˜oes dos conceitos dos n´ıveis do FAML

Conceito Defini¸c˜ao

Action Specification A especifica¸c˜ao de uma a¸c˜ao

Agent Definition Especifica¸c˜ao inicial do agente ap´os ele ser criado

Facet Action Specification Especifica¸cão da defini¸cão da faceta em termos de valores e visibilidade Facet Definition Especifica¸cão da estrutura de uma faceta

Functional Requirement Requisito funcional do sistema

Interaction Protocol Especifica¸cão de padrões de comunica¸cão ocorrentes no sistema Mental State Specification Especifica¸cão das cren¸cas e metas iniciais do estado mental do agente

Message Schema Defini¸cão da estrutura e semântica das mensagens que ocorrem no sistema Non-Functional Requirement Requisito não-funcional do sistema

Ontology Modelo estrutural de determinado dom´ınio Organization Definition Defini¸c˜ao da organiza¸c˜ao

Plan Resource Specification Especifica¸c˜ao de recursos utilizados em um plano Plan Specification Especifica¸c˜ao de um plano

Policy Regras que especificam um conjunto de eventos esperados no sistema

Requirement Requisito do sistema

Resource Specification Especifica¸c˜ao de um recurso

Role Compability Compatibilidade entre os papéis representados pelo agente Role Dependency Dependência entre os papéis representados pelo agente Role Relationship Rela¸cão entre os papéis representados pelo agente

Service Um bloco de atividades que o agente pode assumir System Goal A especifica¸c˜ao do estado do ambiente em que o sistema deseja atingir

Task Uma parte de comportamento que o sistema pode realizar

O escopo externo de um agente na camada de runtime é chamado de n´ıvel de Ambiente, e descreve os agentes que estão situados no ambiente, os recursos e facetas que um agente pode usar e modificar. Este n´ıvel ainda mantem um histórico de eventos e o sistema do qual foi gerado (BEYDOUN et al., 2009).

O ambiente é o local onde estão situados os agentes, que é gerado a partir de um sistema, e utiliza as defini¸cões de ontologia, agentes, facetas, recursos, organiza¸cão e um histórico de ambiente. A ontologia é um modelo estrutural de um dom´ınio de aplica¸cão.

(30)

Uma faceta é a propriedade do ambiente em que o agente pode interagir e é inicializada a partir de uma defini¸cão de faceta, que é a especifica¸cão de sua estrutura, incluindo o seu nome, tipo de dado e modo de acesso. O histórico do ambiente é a sequência de eventos que ocorreram no ambiente desde seu in´ıcio até determinado instante e pode ser do tipo evento de faceta ou evento de mensagem. Um evento de mensagem é o evento que acontece quando uma mensagem é enviada. A classe evento de mensagem se refere a um esquema de mensagem e possui os atributos agente de origem, agentes destinatários e parâmetros. O n´ıvel de Ambiente pode ser visto na figura 2.5.

FIG. 2.5: O N´ıvel de Ambiente (BEYDOUN et al., 2009).

O escopo interno de um agente na camada de runtime é chamado de n´ıvel do Agente (BEYDOUN et al., 2009) e descreve o estado mental de um agente, seus planos e a¸cões para atingir objetivos em que esteja comprometido, papéis que um agente pode assumir, e suas comunica¸cões. Nesse n´ıvel, um agente é uma entidade racional direcionada e autônoma baseado no modelo BDI que pode possuir um estado mental, que representa papéis, que pode utilizar recursos, pode possuir obriga¸cões e que se comunica com outros agentes.

O estado mental de um agente é a composi¸cão de cren¸cas e metas que o mesmo detêm em determinado momento, onde a cren¸ca é uma afirmativa do ambiente em que o agente está inserido e que este acredita ser verdade em determinado per´ıodo de tempo. Um

(31)

re-curso é alguma coisa que possua nome, representa¸cões racionais e que possa ser adquirida, compartilhada ou produzida e a obriga¸cão são as atividades esperadas do comportamento de um agente em determinado cenário.

Uma meta é a representa¸cão de um estado do ambiente em que o agente busca atingir e realizar através de, no m´ınimo, um plano. Uma meta possui ainda dois atributos: committed e o PlanDescriptors. O primeiro atributo determina se a meta é um desejo ou uma inten¸cão, e caso o valor do atributo committed seja verdadeiro, então a meta ´

e considerada uma inten¸c˜ao, caso contrario a meta ser´a um desejo. O PlanDescriptors especifica quando os planos devem estar prontos para serem usados no momento em que a meta ocorre.

Os planos são uma cole¸cão organizada de a¸cões que podem ser executadas para atingir determinada meta de um agente. Os planos possuem dois atributos, FailureCondition e a SuccessCondition. O primeiro atributo expressa quando um plano não alcan¸cará a meta pretendida, enquanto a condi¸cão de sucesso descreve quando um plano pode ser considerado bem sucedido. Um plano é gerado a partir de uma especifica¸cão de planos e pode possuir a¸cões, que são as unidades fundamentais do comportamento de um agente. As a¸cões são divididas em dois tipos: a¸cão de faceta, que é toda a¸cão que resulta na mudan¸ca de uma faceta do ambiente; e a¸cão de mensagem, que é toda e qualquer a¸cão que resulte em envio de mensagens, e são geradas a partir da especifica¸cão da a¸cão de mensagem.

Uma mensagem é uma unidade de comunica¸cão entre agentes. A classe mensagem é uma instância de um esquema de mensagem, que contêm uma comunica¸cão e o atributo parâmetros. A comunica¸cão é uma composi¸cão de sequências de mensagens continuadas e que utiliza um protocolo de intera¸cão, que é a especifica¸cão de padrões de comunica¸cão que ocorrem um sistema. Um esquema de mensagem é a especifica¸cão da estrutura e semânticas de dado tipo de mensagem que pode ocorrer no sistema e está associada a uma performativa. A figura 2.6 apresenta as classes associadas ao n´ıvel do Agente.

Todos os conceitos relacionados ao runtime do FAML podem ser vistos na tabela 2.2. A utiliza¸cão do FAML como um modelo independente de plataforma possibilita a utiliza¸cão da abordagem orientada a modelos, pois o FAML é um metamodelo onde os conceitos de diversas linguagens de modelagens para SMA estão definidos. A utiliza¸cão do MDA, em conjunto com o FAML, permite a automatiza¸cão do processo de desenvolvi-mento de SMA, através de um conjunto de transforma¸cões partindo da especifica¸cão até

(32)

FIG. 2.6: O N´ıvel do Agente (BEYDOUN et al., 2009).

a implementa¸c˜ao efetiva do sistema.

2.3 JASON

O JASON é um framework baseado em AgentSpeak e Java para desenvolvimento de SMA criado por (BORDINI et al., 2007). A linguagem AgentSpeak, representa uma tentativa de refinar as caracter´ısticas principais do PRS em uma simples e unificada linguagem de programa¸cão e é baseada na arquitetura BDI.

Em JASON um agente pode ser implementado baseado em cren¸cas, metas, planos e a¸cões. Um agente possui uma base de cren¸cas que pode ser modificada de acordo com suas percep¸cões sobre o ambiente; planos que são sequências de a¸cões a serem executadas quando uma cren¸ca é modificada; e o agente, em JASON, também possui metas que são responsáveis pelos objetivos de projeto. A defini¸cão de um agente em JASON é dada pela cria¸cão de um arquivo com a extensão .asl.

A base de cren¸cas é uma cole¸cão de literais representados como na lógica tradicional. Um agente adquire cren¸cas através de sua percep¸cão do ambiente, através da comunica¸cão com outros agentes e pela adi¸cão de notas mentais. As cren¸cas existentes na base de

(33)

TAB. 2.2: Defini¸c˜oes dos conceitos dos n´ıveis do FAML

Action Unidade fundamental do comportamento de um agente

Agent Uma entidade altamente autˆonoma e racional

AgentGoal O estado no ambiente em que o agente deseja atingir

Belief Uma afirmativa do ambiente em que um agente acredita ser verdade em determinado per´ıodo de tempo

Communication Um conjunto de mensagens

Environment O ambiente em que o agente est´a situado

Environment History Hist´orico de eventos acontecidos desde a cria¸c˜ao do ambiente

Environment Statement Uma afirmativa sobre o ambiente

Event Alguma atividade que altera o hist´orico do ambiente

Facet Propriedade do ambiente em que o agente pode interagir

Facet Action A¸cão que resulta na modifica¸cão de uma faceta Facet Event Evento que acontece quando uma faceta é modificada

Mental State Cren¸cas e metas de um agente

Message Unidade de comunica¸c˜ao entre agentes

Message Action A¸c˜ao que resulta em uma mensagem sendo enviada Message Event Evento que acontece quando uma mensagem ´e enviada

Organization Uma cole¸cão de agentes com papéis definidos e agindo em conjunto para atingir determinado meta Plan Uma cole¸cão organizada de a¸cões a serem executadas para perseguir determinada meta Resource Alguma recurso que tenha uma representa¸cão razoável e possa ser adquirido, produzido ou compartilhado

Role Padr˜ao comportamental que o agente pode assumir em um sistema System O produto final do desenvolvimento de software orientado a agentes

cren¸cas do agente servem para lembrá-lo de alguma coisa que ele fez no passado, algo que precisa ser resumido mais a frente ou um compromisso que ele tenha assumido. As metas expressam as propriedades dos estados do ambiente em que um agente deseja tornar real. Em JASON, pode-se representar uma meta de duas formas: através de um achievement goal ou test goal. As cren¸cas e metas são duas atitudes mentais que podem ser expressas no código fonte de um agente.

Em JASON um plano é composto de três diferentes partes, o evento gatilho, o contexto e o corpo do plano. O evento gatilho é responsável pela ativa¸cão do plano. É poss´ıvel que dois ou mais planos tenham o mesmo evento gatilho, sendo a diferencia¸cão feita pelo contexto de aplica¸cão do plano. O contexto é usado para definir quando um plano deverá ser considerado aplicável, satisfazendo a determinada condi¸cão. Quando um plano não consegue ser ativado, é gerada uma falha que pode ser tratada através de planos contingenciais e quando a condi¸cão de sucesso é atingida, o plano entra em execu¸cão. O corpo do plano é um conjunto de a¸cões que o agente tem que executar para atingir a sua meta.

Os planos podem ser dos tipos de cren¸ca, verifica¸cão ou realiza¸cão. Os planos de cren¸cas são ativados quando uma cren¸ca é inserida ou removida da base de cren¸cas do agente; os planos de verifica¸cão são ativados quando o agente precisa recuperar alguma informa¸cão de sua base de cren¸cas; e por último, os planos de realiza¸cão são responsáveis por atingir um estado desejado pelo agente e são ativados quando o plano for para a base de inten¸cões do agente.

Os planos podem ser ativados de duas maneiras: por adi¸cão ou por dele¸cão. O plano de adi¸cão são ativados quando inten¸cões ou cren¸cas são adicionados ao agente durante

(34)

seu ciclo de vida, enquanto os planos de dele¸c˜ao podem ser planos contingenciais ou de remo¸c˜ao de cren¸cas de um agente.

Em JASON uma a¸cão é executada quando um plano é ativado e é representada por dois tipos: as que mudam o ambiente e são executadas fora do agente; e a¸cões internas ao agente, que podem ser fun¸cões pré-definidas, expressões aritméticas, metas e sub-metas.

As a¸cões internas são um conjunto de a¸cões pré-definidas que o agente realiza para auxiliá-lo a atingir determinado objetivo. Além das fun¸cões internas pré-definidas, é poss´ıvel a personaliza¸cão e cria¸cão de novas fun¸cões internas. Uma expressão aritmética ´

e uma a¸cão para unifica¸cão de dois termos para obten¸cão de um novo valor. Uma sub-meta é uma meta que o agente executa dentro de um plano, onde o agente espera a sua realiza¸cão e caso a mesma não seja finalizada, o plano atual não é continuado; e as a¸cões que geram uma nova meta, ou seja, o agente se compromete com outra meta e a meta atual continua em andamento.

As a¸cões externas são a¸cões que modificam o ambiente em que o agente está inserido através de métodos em Java que são implementados para representar a a¸cão do agente no ambiente. Estes métodos verificam as pré-condi¸cões, modificam as percep¸cões no ambiente e retornam um valor booleano para indicar se a¸cão foi realizada ou não no ambiente.

Em JASON a comunica¸cão é realizada através de troca de mensagens, que são enviadas com o uso de uma a¸cão interna pré-definida para comunica¸cão entre agentes utilizando os seguintes parâmetros: o destinatário; o conteúdo proposicional; e as for¸cas ilocucionárias. O destinatário é o nome dado ao agente no arquivo que define o agente e a quem a mensagem deve ser entregue. O conteúdo proposicional é um termo que pode representar um conteúdo literal, um plano, uma meta, uma cren¸ca ou uma lista das op¸cões anteriores. As for¸cas ilocucionárias são as performativas que devem ser executadas pelo agente.

As performativas em JASON são similares ao Knowledge Query and Manipulation Lan-guage (KQML) (MAYFIELD et al., 1996), que é uma linguagem designada para suportar intera¸cões entre os agentes inteligentes de software. Os agentes possuem uma caixa de mensagens onde um método chamado SocAcc pode ser sobrescrito e retorna um booleano para especificar quando um agente está ou não autorizado a enviar mensagem, ou seja, quando a mensagem deve ou não ser descartada. O KQML foi a primeira tentativa de se definir uma linguagem de comunica¸cão de alto n´ıvel baseada na teoria Speech-Act para a inteligência artificial. Em JASON as performativas KQLM que podem ser executadas são: tell; untell; achieve; unachieve; askOne; askAll; tellHow; untellHow; e askHow.

(35)

Em JASON o sistema é representado pelo arquivo de extensão .mas2j, um conjunto de arquivos de extensão asl e classes em java. O sistema ainda é responsável pela con-figura¸cão das caracter´ısticas do SMA, como por exemplo, nome e infraestrutura, que pode ser de três tipos centralised, centralised pool e jade. Em JASON um ambiente é imple-mentado estendendo a classe Environment que mantém as estruturas de dados usadas para armazenar as percep¸cões em que cada agente tem acesso, assim como as percep¸cões globais a todos agentes. Essas percep¸cões são representadas pelos atributos privados glob-alPercepts e agPercepts do tipo Literal. A arquitetura do agente, quando este deseja realizar alguma a¸cão no ambiente, invoca o método executeAction alterando o ambiente e as cren¸cas através dos métodos addPercept, removePercept e clearPercepts.

Todos os conceitos relacionados ao JASON podem ser vistos na tabela 2.3.

TAB. 2.3: Defini¸c˜oes dos conceitos do JASON

A¸cão A¸cão realizada pelo agente a fim de atingir suas metas e objetivos A¸cão Interna A¸cão pré-definida interna do JASON

A¸c˜ao Externa A¸c˜ao executada pelo agente no ambiente

Agente Arquivo de extens˜ao asl

Ambiente Conjunto de arquivos em Java que estendem a classe Environment Cren¸ca Afirmativa em que o agente acredita ser verdade Contexto Conjunto de condi¸c˜oes para ativa¸c˜ao do plano

Corpo Conjunto de a¸c˜oes de um plano

Evento Gatilho Evento de ativa¸c˜ao do plano Infraestrutura Tipo de infraestrutura do SMA

Mensagem Mensagem enviada atrav´es da a¸c˜ao interna .send

Meta Meta em que o agente busca atingir

Operador Operador da a¸c˜ao executada

Percep¸c˜ao Atributo definido na classe do ambiente

Performativa Perfomativas baseadas no KQML

Plano Plano para atingir determinada meta do agente Sistema Arquivo mas2j contendo todas os componentes do SMA Tipo de Altera¸cão Os planos podem ser de adi¸cão ou dele¸cão

Tipo de Plano Os planos podem ser de Teste, adi¸c˜ao de cren¸ca e de realiza¸c˜ao

O JASON pode ser utilizado como um PSM de SMA, onde este modelo será resultante de um o conjunto de transforma¸cões entre modelos padronizadas pela OMG. Do ponto de vista de uma abordagem MDA, é necessário para implementa¸cão de um sistema que vários n´ıveis de abstra¸cão sejam modelados através de modelos desde a especifica¸cão até a implementa¸cão. A utiliza¸cão do modelo JASON através das técnicas de MDA permite que a codifica¸cão do sistema modelado seja gerado semi-automaticamente, facilitando o trabalho de analistas e desenvolvedores de softwares.

2.4 MOISE+

O modelo Moise+ é um modelo organizacional responsável pela especifica¸cão de orga-niza¸cões em SMA e dividido em três dimensões. A primeira dimensão, a especifica¸cão estrutural, os conceitos de papéis, rela¸cões de papéis e grupos são utilizados para

(36)

cons-truir os n´ıveis estrutural individual, social e coletivo da organiza¸cão. A especifica¸cão funcional é baseada no conceito de missões, que são um conjunto de metas globais, e planos globais. A especifica¸cão deôntica sugere um relacionamento entre as especifica¸cões estrutural e funcional de forma que seja representada através de permissões e obriga¸cões de um papel (HUBNER et al., 2002).

A especifica¸cão estrutural é constru´ıda em três n´ıveis: o n´ıvel individual, que são os comportamentos que um agente se torna responsável quando assume um papel; Os relacionamentos de conhecimento, comunica¸cão e autoridade entre papéis no n´ıvel social; e a agrega¸cão de papéis em grupos no n´ıvel coletivo. A especifica¸cão funcional é um conjunto de esquemas no qual representam como um SMA atinge suas metas globais, e como estes estão decompostos em planos e distribu´ıdos em missões para os agentes. Um esquema pode ser visto através de uma árvore onde a meta global é a raiz e as folhas são as metas que o agente deve atingir para realizar a meta global. Cada missão possui uma cardinalidade que é a quantidade de agentes que devem se comprometer com ela (HUBNER et al., 2002). A especifica¸cão deôntica garante a autonomia dos agentes através do que é permitido ou obrigado dentro das organiza¸cões. As especifica¸cões descrevem as permissões de papéis e obriga¸cões para as missões (HUBNER et al., 2002).

Com a utiliza¸cão do modelo organizacional Moise+ em conjunto com o framework JASON, os conceitos de papéis, relacionamentos de papéis, tarefas, organiza¸cões e metas de sistemas podem ser constru´ıdos através de um arquivo XML, permitindo o mapeamento das regras de transforma¸cão das classes que o JASON não implementa por si só.

Todos os conceitos relacionados ao Moise+ podem ser vistos na tabela 2.4.

TAB. 2.4: Defini¸c˜oes dos conceitos do Moise+

Esquema Decomposi¸c˜ao global das metas

Grupo Organiza¸c˜ao de agentes

Link Rela¸c˜ao entre pap´eis

Miss˜ao Tarefa dos grupos

Norma Norma que o agente deve estar de acordo e obedecer no sistema Papel Papel que um agente pode assumir no sistema

O modelo Moise+ refor¸ca os conceitos organizacionais que não estão presentes na linguagem de programa¸cão a agentes JASON, permitindo que o mesmo possa contar com estruturas de papéis, tarefas e organiza¸cões a n´ıvel de sistema e ambiente. Com isso, as técnicas MDA para o desenvolvimento de SMA utilizando o JASON em conjunto com o Moise+ permitem uma abrangência maior de conceitos presentes tanto na especifica¸cão quanto na implementa¸cão.

(37)

2.5 JACAMO

O projeto JaCaMo é um plataforma para desenvolvimento de SMA que utiliza o Moise+ para defini¸cão da dimensão organizacional do agente, que são programados utilizando o JASON, e trabalham em conjunto utilizando ambientes constru´ıdos baseados em artefatos que são programados em CArtAgO (BOISSIER et al., 2011).

O JaCaMo integra as três plataformas definindo as jun¸cões entre os conceitos das diferentes dimensões de programa¸cão das tecnologias utilizadas (agente, ambiente e orga-niza¸cão), através de um meta-modelo, para obter um modelo de programa¸cão consistente e uniforme visando simplificar a combina¸cão das dimensões para programa¸cão de SMA (BOISSIER et al., 2011). O meta-modelo relacionado ao JaCaMo pode ser visto na figura 2.7.

FIG. 2.7: O metamodelo JaCaMo (BOISSIER et al., 2011).

2.6 REPRESENTAÇ ÃO DE TRANSFORMAÇ ÕES

A transforma¸cão de modelos é o processo de converter um modelo para outro de um mesmo sistema e a Arquitetura Orientada a Modelos prove especifica¸cões para as transforma¸cões de um PIM para PSM, onde o modelo da plataforma determinará o tipo do mapeamento. O mapeamento entre meta-modelos, é um exemplo de transforma¸cão onde tanto o PIM quanto o PSM são especificados como meta-modelos MOF (OMG, 2003).

(38)

O mapeamento é especificado utilizando alguma linguagem para descrever a trans-forma¸cão de um modelo para outro e, esta, deve ser em linguagem natural ou em lin-guagem de mapeamento de modelos. O MOF Query/View/Trasformation (QVT) (OMG, 2011) é uma linguagem da OMG para descrever transforma¸cões entre modelos e pode ser usada para a cria¸cão de um PSM.

A especifica¸cão define três linguagens de transforma¸cões: Relations que permite a transforma¸cão entre modelos candidatos e é especificado como um conjunto de rela¸cões que precisam ser executadas com sucesso; Operational Mappings que representa a defini¸cão unidirecional que é expressa imperativamente indicando os modelos envolvidos na trans-forma¸cão; e o Core que é um modelo que suporta valida¸cão de condi¸cões em conjunto de variáveis e trata os elementos do modelo como origem, destino e tra¸co.

O Model-To-Text (M2T) (OMG, 2008) é um especifica¸cão da OMG, que utiliza tem-plates para transformar modelos PSM em representa¸cões linearizadas de textos, como códigos e relatórios. A abordagem de utiliza¸cão de templates através do uso de opera¸cões queries, utiliza espa¸cos pré-definidos para sele¸cão e extra¸cão de informa¸cão provenientes dos meta-modelos.

As transforma¸cões M2T precisam ser repet´ıveis para que as mudan¸cas nos modelos reflitam no texto. Também devem ser rastreáveis, de forma que seja poss´ıvel determinar de que elementos do modelo de destino a por¸cão de texto foi gerada, além de manter um aspecto leg´ıvel levando em conta a identa¸cão do texto produzido.

A linguagem Object Constraint Language (OCL) é uma linguagem formal usada para descrever expressões em modelos (OMG, 2012b). Essas expressões geralmente são condi¸cões invariantes que o sistema modelado deve satisfazer ou buscas de objetos em um modelo descrito. A OCL é uma linguagem de especifica¸cão que, quando suas expressões são validadas, não alteram o estado correspondente do sistema executado, simplesmente re-tornando um valor.

A OCL também pode ser utilizada para especificar um estado de mudan¸ca de um sistema através de pós-condi¸cões e, por não ser uma linguagem de programa¸cão, não é poss´ıvel escrever lógicas de controle ou invocar processos através da linguagem. A OCL permite restringir os modelos de forma a garantir a consistência da modelagem do sistema (OMG, 2012b).

(39)

3 A METODOLOGIA PROPOSTA

Este cap´ıtulo apresenta a metodologia de desenvolvimento de SMA proposta por (PANTOJA; CHOREN, 2012) que utiliza a Arquitetura Orientada a Modelos e divide o desenvolvimento de um SMA em diferentes n´ıveis de abstra¸cão, partindo de um mo-delo de especifica¸cão para uma plataforma espec´ıfica de desenvolvimento através de um conjunto de transforma¸cões. A figura 3.1 ilustra os n´ıveis de abstra¸cão propostos na metodologia.

FIG. 3.1: A metodologia proposta.

Na se¸cão 3.1, será apresentada a modelagem do sistema do n´ıvel independente de plataforma utilizando o FAML; na se¸cão 3.2 serão apresentadas as transforma¸cões entre o modelo de especifica¸cão do sistema para o modelo de projeto utilizando a linguagem M2M e as regras de valida¸cão do modelo de especifica¸cão usando a OCL; na se¸cão 3.3

(40)

serão apresentadas as transforma¸cões do modelo de projeto para a plataforma espec´ıfica utilizando a linguagem M2T e as regras de valida¸cão do modelo de projeto usando a OCL.

3.1 A MODELAGEM DO SISTEMA (PIM)

O n´ıvel de design independente de plataforma descreve uma aplica¸cão de SMA das pers-pectivas tanto do n´ıvel interno (agente) quanto do n´ıvel externo (organiza¸cão). O modelo de destino consiste da implementa¸cão de conceitos do FAML, derivados do modelo de especifica¸cão, onde um meta-modelo composto dos n´ıveis de ambiente, agente, sistema e defini¸cão do agente, baseado no FAML, foi constru´ıdo. O FAML, meta-modelo uti-lizado como modelo independente de plataforma na metodologia, permite a utiliza¸cão de diferentes linguagens de modelagem orientadas a agentes, adicionando flexibilidade a especifica¸cão e, consequentemente, ao desenvolvimento do SMA. No entanto, para que a modelagem adequada seja feita, um conjunto de conceitos devem ser instanciados para que a metodologia funcione. Os conceitos de modelo, sistema, ambiente e agentes, devem estar presentes na modelagem.

A classe FamlMM, figura 3.2, é responsável pela instância do modelo e é composto do sistema modelado que é representado pela classe System. Além disso, a classe System apresenta atributos relacionados ao comportamento do sistema, como o caminho de origem das classes do ambiente e seus agentes. Um sistema também é composto dos objetos da classe Requirements, Policy, Role e Organization e gera o ambiente modelado que é representado pela classe Environment.

A classe Role representa os papéis que um agente pode assumir no sistema modelado e a classe Organization é um conjunto de papéis estruturados hierarquicamente. Cada papel modelado é responsável por um objetivo de sistema que é representado pela classe AgentGoal e colabora em tarefas que são tarefas espec´ıficas para atingir as metas do agente. A tarefa é representada pela classe Task. Os papéis possuem rela¸cões entre si que indicam se essa rela¸cão é de compatibilidade ou dependência e são representados pelas classes RoleRelationship, RoleCompability e RoleDependency. Esta parte do modelo de especifica¸cão do sistema é responsável pela modelagem organizacional do SMA.

O ambiente é composto dos objetos das classes Facet, Resource, EnvironmentHistory, Ontology e Agent que representam os conceitos de Facetas, Recursos, Histórico do Ambi-ente e Ontologia. As facetas e os recursos podem ser modificados ou usados pelo agAmbi-ente que estiver atuando sobre o ambiente enquanto o histórico do ambiente registra os eventos

(41)

FIG. 3.2: O metamodelo FAML adaptado (PANTOJA; CHOREN, 2012).

de mensagens e facetas, representados pela classe Event, que ocorreram no ambiente. Um agente é composto de um estado mental, tem obriga¸cões e assumem papéis no

(42)

sistema a fim de atingir o estado desejado no ambiente. Os conceitos de estado mental e obriga¸cão são representados pelas classes MentalState e Obligation. O estado mental de um agente é composto de metas e cren¸cas que um agente pode ter em determinado per´ıodo de tempo na inicializa¸cão e execu¸cão do sistema enquanto a classe Obligation é responsável pelas especifica¸cões das obriga¸cões dos agentes. As cren¸cas são representadas pela classe Belief e são afirmativas que o agente acredita ser verdade. Já as metas são representadas pela classe AgentGoal, que é responsável pelas metas que um agente deseja atingir. Se um agente estiver comprometido com a meta, então essa será classificada como uma Inten¸cão, caso contrário a meta será considerada um desejo.

Um plano é representado pela classe Plan, que é composta de a¸cões e persegue uma meta que deverá ser atingida ao final de sua execu¸cão. O plano possui condi¸cões de sucesso e falhas para determinar o momento para in´ıcio de sua execu¸cão. As a¸cões são representadas pela classe Action, que podem ser de dois tipos: mensagem e faceta. A a¸cão de faceta é representada pela classe FacetAction e é responsável pela modifica¸cão das facetas encontradas no ambiente, enquanto a a¸cão de mensagem é representada pela classe MessageAction, que resulta em uma mensagem que é parte da comunica¸cão entre um agente emissor e outro receptor. As classes envolvidas na troca de mensagens são a Message e Communication.

3.2 TRANSFORMAÇ ÃO DO MODELO DE ESPECIFICAÇ ÃO PARA O MODELO DE PROJETO

As transforma¸cões QVT, representadas por t1 na figura 3.1, recebem como entrada o mo-delo FAML instanciado e retornam o momo-delo JaCaMo (BOISSIER et al., 2011) instanciado de acordo com o modelo de especifica¸cão do SMA. O meta-modelo JaCaMo adaptado, utilizado como modelo espec´ıfico de plataforma na metodologia, reúne os conceitos tanto da dimensão da programa¸cão do agente quanto da programa¸cão organizacional, utilizando o Jason e Moise+.

A metodologia proposta neste trabalho utiliza a dimensão organizacional, através do modelo organizacional Moise+, e a dimensão do agente, através da linguagem de pro-grama¸cão orientada a agentes Jason. A dimensão ambiental utiliza a programa¸cão em Java padrão do Jason para a codifica¸cão dos ambientes onde os agentes estarão inseridos. Portanto, algumas modifica¸cões foram realizadas no meta-modelo JaCaMo para adaptá-lo a metodologia.

(43)

3.2.1 MODIFICAC¸ ˜OES

As modifica¸cões realizadas no meta-modelo adaptado deste trabalho consistem na simpli-fica¸cão da dimensão ambiental e da extensão da dimensão organizacional do meta-modelo inicial do JaCaMo. Na dimensão ambiental do JaCaMo foi necessário simplificar o mo-delo, já que a metodologia proposta utiliza apenas as classes java para implementa¸cão do ambiente do agente, não fazendo o uso de artefatos. A simplifica¸cão consistiu em manter a classe Environment, para representar o ambiente, e a classe Percept pra representa¸cão das percep¸cões. Desta forma, não se faz necessário a utiliza¸cão do CArtAgO.

Na dimensão organizacional uma extensão de relacionamentos entre as classes são in-seridas de forma que a codifica¸cão do arquivo organizacional do Moise+ seja estruturado levando em considera¸cão as especifica¸cões funcionais, estruturais e normativas. A classe Link foi adicionada ao meta-modelo para representar as rela¸cões entre grupos e papéis da especifica¸cão de grupos do modelo estrutural. Um auto-relacionamento nomeado super-type foi adicionado a classe Role de forma que a hierarquia de papéis possa ser represen-tada. Um auto-relacionamento, nomeado de monitoringScheme foi adicionado na classe Scheme de forma que possa ser identificado o esquema de monitora¸cão de cada esquema. Outro auto-relacionamento nomeado subGoal foi adicionado a classe Goal com o objetivo de identificar a hierarquia de metas da especifica¸cão funcional. O meta-modelo proposto da metodologia pode ser visto na figura 3.3.

3.2.2 AS TRANSFORMAC¸ ˜OES QVT

A transforma¸c˜ao t1, entre o Design Independente de Plataforma e o Design Espec´ıfico de Plataforma, consiste de um conjunto de mapeamentos de conceitos observados entre o meta-modelo gen´erico FAML para modelagem de SMA e o meta-modelo espec´ıfico de plataforma de desenvolvimento JaCaMo.

Alguns conceitos são mapeados diretamente do modelo independente de plataforma para o modelo espec´ıfico de plataforma. Os conceitos diretos são: Action, Agent, Be-lief, Environment, Plan, Role e System. As especifica¸cões de cada conceito são mapeados como atributos para o modelo de destino. Os conceitos de defini¸cão são:Action Speci-fication,Agent Definition,Facet Action Specification,Resource Specification,Plan Resource Specification,Organization Definition ePlan Specification. Os conceitos Task e Organiza-tion são mapeados para os conceitos Mission e Group respectivamente.

(44)

FIG. 3.3: O metamodelo JaCaMo adaptado (PANTOJA; CHOREN, 2012).

Os conceitos Agent Goal e System Goal são mapeados para o conceito Goal do modelo de destino pois na plataforma espec´ıfica não existe a diferencia¸cão entre os objetivos de