Congresso Brasileiro de Software: Teoria e Prática Engenharia de Software e Sistemas Inteligentes...

Congresso Brasileiro de Software: Teoria e Prática 28 de setembro a 03 de outubro de 2014 – Maceió/AL

V Workshop sobre Sistemas de Software Autônomos

AutoSoft 2014

Anais

AutoSoft 2014 V Workshop sobre Sistemas de Software Autônomos

COORDENADORES DO COMITÊ DE PROGRAMA Ingrid Nunes - Universidade Federal do Rio Grande do Sul (UFRGS) Mariela Cortés - Universidade Estadual do Ceará (UECE) COORDENAÇÃO DO CBSOFT 2014 Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) REALIZAÇÃO Universidade Federal de Alagoas (UFAL) Instituto de Computação (IC/UFAL) PROMOÇÃO Sociedade Brasileira de Computação (SBC) PATROCÍNIO CAPES, CNPq, INES, Google APOIO Instituto Federal de Alagoas, Aloo Telecom, Springer, Secretaria de Estado do Turismo AL, Maceió Convention & Visitors Bureau, Centro Universitário CESMAC e Mix Cópia

Anais

Volume 02 ISSN 2178-6097

AutoSoft

2

AutoSoft 2014 5th Workshop on Autonomous Software Systems

PROGRAM CHAIR Ingrid Nunes - Universidade Federal do Rio Grande do Sul (UFRGS) Mariela Cortés - Universidade Estadual do Ceará (UECE) CBSOFT 2014 GENERAL CHAIRS Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) ORGANIZATION Universidade Federal de Alagoas (UFAL) Instituto de Computação (IC/UFAL) PROMOTION Sociedade Brasileira de Computação (SBC) SPONSORS CAPES, CNPq, INES, Google SUPPORT Instituto Federal de Alagoas, Aloo Telecom, Springer, Secretaria de Estado do Turismo - AL, Maceió Convention & Visitors Bureau, Centro Universitário CESMAC and Mix Cópia

PROCEEDINGS

Volume 02 ISSN 2178-6097

AutoSoft

3

Autorizo a reprodução parcial ou total desta obra, para fins acadêmicos, desde que citada a fonte

AutoSoft

4

Apresentação

Estes anais registram os trabalhos apresentados no quinto Workshop de Sistemas de Software Autônomos - AutoSoft, que é um evento satélite da quinta Conferência Brasileira de Software: Teoria e Prática (CBSoft), acontecendo em Maceió, Alagoas, no dia 28 de setembro de 2014.

Esta edição continua o sucesso das versões anteriores, realizadas no CBSoft 2010 (em Salvador), no CBSoft 2011 (em São Paulo), CBSoft 2012 (em Natal) e na última edição em Brasília, em 2013. No contexto da conferência CBSoft, cujo objetivo é integrar as diversas comunidades de pesquisadores e profissionais voltados a software, o âmbito do workshop AutoSoft é estender o estado da arte tanto no que se refere aos processos de engenharia quanto no desenvolvimento de aplicações no contexto de sistemas autônomos.

Sistemas autônomos contribuem cada vez mais para a criação de sistemas inteligentes capazes de dar suporte à complexidade do mundo real. A transição de componentes passivos para autônomos transforma arquiteturas de software em plataformas complexas envolvendo diversos componentes interagindo dinamicamente, engajados em complexos protocolos de interação, e se adaptando de forma a ativar medidas adequadas com base na situação corrente. Transportes, pesquisa aeroespacial, defesa e finanças são alguns dos setores que estão optando por substituir operadores humanos por arquiteturas e plataformas de implementação que objetivam prover melhorias no sistema como um todo. De fato, tais sistemas promovem o aumento do desempenho geral das aplicações, permitem operar em ambientes remotos ou perigosos e facilitam a automação e a tomada de decisão.

Para esta edição, o evento recebeu uma variedade de contribuições. As sessões técnicas contaram com a apresentação de 8 trabalhos, os quais foram avaliados por no mínimo três revisores, selecionados a partir do Comitê de Programa que inclui mais de trinta pesquisadores da academia e da indústria, do Brasil e do exterior. O workshop incluiu duas palestras internacionais convidadas, sendo uma do Professor Michael Luck, do King’s College London que proferiu a palestra intitulada From Agents to Electronic Order via Norms, e o Dr. Onn Shehory, da IBM Haifa Labs, Israel, que discorreu sobre Software Self-Healing: Improving the Quality of Complex Software Systems.

Gostaríamos de agradecer aos palestrantes convidados, Prof. Luck e Dr. Shehory pela dedicação e contribuição ao evento. Também agradecemos aos membros do Comitê de Programa, pela alta qualidade do trabalho produzido. Não podemos esquecer-nos de agradecer à organização do CBSOFT pela oportunidade de continuar contribuindo com o crescimento e divulgação de pesquisas na área de sistemas autônomos na comunidade cientifica brasileira. Finalmente, agradecemos o auxílio financeiro da CAPES determinante para a realização e o sucesso do evento. Maceió, setembro de 2014.

Ingrid Nunes Mariela Inés Cortés

Coordenadores do AutoSoft 2014 CBSoft 2014

AutoSoft

5

Foreword

This proceedings records the contributions presented at the Fifth Workshop on Autonomous Software Systems - AutoSoft, a satellite event of the Fifth Brazilian Conference on Software: Theory and Practice (CBSOFT), which took place in Maceió, Alagoas, on September 28th, 2014.

This workshop builds on the success of the previous event in this series, which took place at CBSoft 2010 (in Salvador), at CBSoft 2011 (in São Paulo), CBSoft 2012 (in Natal) and the last edition at Brasilia (2013). AutoSoft aims to bring together researchers and practitioners involved in the development of techniques and applications of Autonomous Software Systems, to discuss the latest developments, trends and innovations concerning the theory and practice of such software.

Autonomous systems represent the next great step in the fusion of computing, sensing, and software to create intelligent systems capable of interacting with the complexities of the real world. The transition from passive to autonomous components turned software architectures into complex platforms that may contain many components that dynamically interact, and engage in complex coordination protocols. Games, aerospace, robotics, defense and finance are amongst some of the sectors shifting towards replacing the human operator by architectures and implementation technologies that are intended to provide overall system improvements.

The current edition of the workshop received a range of contributions. Besides its technical sessions, with 8 presentations of selected research papers, the workshop included two invited talks. The submitted papers in these proceedings have been reviewed by three reviewers drawn from the 34 Program Committee members, selected from academia or industry. The invited speakers were Professor Michael Luck, from King’s College London, and Dr. Onn Shehory from IBM Haifa Labs, Israel. Professor Luck’s talk was entitled From Agents to Electronic Order via Norms, and Dr. Shehory discussed about Software Self-Healing: Improving the Quality of Complex Software Systems.

We would like to thank the invited speakers, Prof. Luck and Dr. Shehory, for their valuable contribution to the event. We would also like to thank all members of the AutoSoft Program Committee, for the quality of their work. We are grateful to the CBSOFT Organization for the opportunity to contribute to the advancement of the autonomous software community. Finally, we acknowledge CAPES for the financial support. Maceió, September 2014.

Ingrid Nunes Mariela Inés Cortés

AutoSoft 2014 Chairs CBSoft 2014

AutoSoft

6

Biografia dos Coordenadores Ingrid Nunes Ingrid Nunes é professora adjunta na Universidade Federal do Rio Grande do Sul (UFRGS), Porto Alegre, Brasil, e coordenadora do grupo de pesquisa Prosoft. Ela possui graduação em Bacharelado em Ciência da Computação pela Universidade Federal do Rio Grande do Sul (2006), obteve o título de Mestre em Informática pela Pontifícia Universidade Católica do Rio de Janeiro (2009), e o título de doutora em Informática pela Pontifícia Universidade Católica do Rio de Janeiro (2012). Seu doutorado foi realizado em cooperação com a King's College London (UK), onde realizou um período de doutorado sanduíche de um ano, e com a University of Waterloo (Canadá), tendo realizado três visitas de pesquisa por três meses cada vez. Ela também fez pós-doutorado na PUC-Rio no Laboratório de Engenharia de Software (LES) (2012), e tem experiência na indústria, onde ela trabalhou como desenvolvedora de software de 2005 a 2007. Ela é editora de seção da Revista de Iniciação Científica (REIC). Suas principais áreas de pesquisa são engenharia de software e inteligência artificial.

Mariela Inés Cortés Mariela Inés Cortés possui doutorado em informática na Pontifícia Universidade Católica do Rio de Janeiro (2003) com ênfase em engenharia de software. Atualmente é professora adjunta da Universidade Estadual do Ceará (UECE), onde lidera o Grupo de Engenharia de Software e Sistemas Inteligentes (GESSI). Sua pesquisa concentra-se predominantemente na aplicação de técnicas de Engenharia de Software para a construção de sistemas autônomos, com ênfase em sistemas multiagentes.

AutoSoft

7

Chairs Short Biographies

Ingrid Nunes Ingrid Nunes is a Professor Adjunto (Associate Professor) of the Instituto de Informática at the Federal University of Rio Grande do Sul (UFRGS), Porto Alegre, Brazil, and the head of the Prosoft research group. She completed her undergraduate studies in Computer Science at UFRGS (2006), obtained her Master's degree in Informatics at the Pontifical Catholic University of Rio de Janeiro (2009), and obtained her Doctor's degree in Informatics at the Pontifical Catholic University of Rio de Janeiro (2012). Her phd was in cooperation with King's College London (UK), under a sandwich Ph.D. programme of one year, and with University of Waterloo (Canada), with three three-month research visits. She was also a post-doc researcher at PUC-Rio in the Software Engineering Laboratory (LES) (2012), and has experience in the industry, where she worked as a software developer from 2005 to 2007. She is a section editor of the Scientific Initiation Magazine (REIC). Her main research areas are software engineering and artificial intelligence.

Mariela Inés Cortés Mariela Inés Cortés had her doctoral degree in Informatics at Pontifical University Catholic of Rio de Janeiro (2003), Brazil, her master degree in Computing and System at Military Engineering Institute of Rio de Janeiro (1999). Nowadays she is an Assistant Professor at Computer Science from State University of Ceará (UECE), where leads the Software Engineering and Intelligent Systems group (GESSI). Her main research interest is in software engineering techniques for autonomous software systems, particularly multiagent systems.

AutoSoft

8

Comitês Técnicos / Program Committee Comitê Diretivo / Steering Committee

Anarosa A.F. Brandão - Universidade de São Paulo (USP) Carlos Lucena - Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Jaime Simão Sichman - Universidade de São Paulo (USP) Rafael Bordini - Universidade Federal do Rio Grande do Sul (UFRGS) Ricardo Choren - Instituto Militar de Engenharia (IME) Viviane Torres da Silva - Universidade Federal Fluminense (UFF) Comitê do programa / Program Committee Ana L. C. Bazzan - Universidade Federal do Rio Grande do Sul (UFRGS) Ana Paula Lemke - Instituto Federal Rio Grande do Sul (IFRS-Campus Feliz) Anarosa Alves Franco Brandão - Universidade de São Paulo (USP) Andrea Omicini - Alma Mater Studiorum–Università di Bologna, Italy Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Carlos Lucena - Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Danny Weyns - Linnaeus University, Sweden Denis Wolf - Universidade de São Paulo (USP) Diana Francisca Adamatti - Universidade Federal do Rio Grande (FURG) Elder Cirilo - Universidade Federal de São João del-Rei (UFSJ) Felipe Meneguzzi - Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS) Guillermo Ricardo Simari - Universidad Nacional del Sur in Bahia Blanca, Argentina Gustavo Campos - Universidade Estadual do Ceará (UECE) Gustavo Giménez-Lugo - Universidade Tecnológica Federal do Paraná (UTFPR) Ingrid Nunes - Universidade Federal do Rio Grande do Sul (UFRGS) Jaime Sichman - Universidade de São Paulo (USP) Joao Leite - CENTRIA, Universidade Nova de Lisboa, Portugal Jomi Fred Hubner - Universidade Federal de Santa Catarina (UFSC) Kalinka Regina Castelo Branco - Universidade de São Paulo (USP) Luis Gustavo Nardin - Universidade de São Paulo (USP) Maira Gatti - IBM Research, Brazil Marcelo Ribeiro - IEEE Member Mariela Cortés - Universidade Estadual do Ceará (UECE) Olivier Boissier - ENS Mines Saint-Etienne, France Paulo A. L. Castro - Instituto Tecnológico de Aeronáutica (ITA) Rafael H. Bordini - Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS) Raimundo Barreto - Universidade Federal do Amazonas (UFAM) Renato Cerqueira - Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Rodrigo Paes - Universidade Federal de Alagoas (UFAL) Samhar Mahmoud - King's College London, United Kingdom Valdinei Silva - Universidade de São Paulo (USP) Valguima Victoria Viana Aguiar Odakura - Universidade Federal da Grande Dourados (UFGD)

AutoSoft

9

Wamberto Vasconcelos - University of Aberdeen, United Kingdom Zahia Guessoum - LIP6, Universit de Paris 6, France Revisores Adicionais / Additinal Reviewers

Maicon Zatelli - Universidade Federal de Santa Catarina (UFSC)

AutoSoft

10

Comitê organizador / Organizing Committee COORDENAÇÃO GERAL

Baldoino Fonseca - Universidade Federal de Alagoas (UFAL) Leandro Dias da Silva - Universidade Federal de Alagoas (UFAL) Márcio Ribeiro - Universidade Federal de Alagoas (UFAL) COMITÊ LOCAL

Adilson Santos - Centro Universitário Cesmac (CESMAC) Elvys Soares - Instituto Federal de Alagoas (IFAL) Francisco Dalton Barbosa Dias - Universidade Federal de Alagoas (UFAL) COORDENADORES DO AutoSoft 2014

Ingrid Nunes - Universidade Federal do Rio Grande do Sul (UFRGS) Mariela Cortés - Universidade Estadual do Ceará (UECE)

AutoSoft

11

Índice / Table of Contents Uma Plataforma para Agentes Normativos Baseada no Modelo Huginn

Tiago L. Schmitz, Jomi F. Hübner

13

Reengineering Network Resilience Strategies using the BDI Architecture

Ingrid Nunes, Alberto Schaeffer-Filho

25

Abordagem Baseada em Agentes para o Monitoramento e Controle do Trabalho e Gestão Integrada de Mudanças

Nécio L. Veras, Mariela I. Cortés, Anderson C. P. Queiroz, Leandro L. C. de Souza

37

Uma Abordagem para o Tratamento Racional de Normas de Obrigação em Ambientes de Tarefas Normativos

Pedro I. F. Aragão, Gustavo A. L. de Campos, Mariela I. Cortés, Francisco I. S. Cruz

49

Fragmenting O-MaSE using the Medee Framework

Felipe Cardoso Resende, Anarosa A. F. Brandão, Sara J. Casare, Jaime S. Sichman

61

JAMDER 2.0: Support to Implementation of Normative Multi-Agent Systems

Robert M. Rocha Júnior, Emmanuel S. S. Freire, Mariela I. Cortés

71

Reputation in MAS-based Simulation: an Approach Using CArtAgO Artifacts

Henrique Rodrigues, Glenda Dimuro, Graçaliz Dimuro, Diana Francisca Adamatti, Esteban Jerez

81

Adaptação de Artefatos de Software em Tempo de Execução utilizando Aspectos e Reflexão

Samuel Davi Müller de Souza, Frank José Affonso, Elisa Yumi Nakagawa

93

AutoSoft

12

Uma plataforma para agentes normativos baseada no modeloHuginn

Tiago L. Schmitz1, Jomi F. Hubner1

1Universidade Federal de Santa CatarinaC.P. 476, 88040-900 Florianopolis - SC, Brasil

[email protected], [email protected]

Resumo. Uma classe de sistemas multiagente pode ser descrita como uma so-ciedade na qual o sistema normativo orienta os agentes para atingirem os obje-tivos do sistema. Quando um agente percebe um sistema de normas, ele precisaraciocinar sobre o impacto dessas normas em seus objetivos pessoais. Conside-rando que os agentes normativos tem recursos limitados, e necessario racioci-nar tambem sobre os recursos disponıveis e se eles sao suficientes para alcancaro objetivo implicado por uma norma. O modelo Huginn trata explicitamente doraciocınio normativo com recursos finitos propondo um processo de deliberacaoque traduz as normas, desejos e recursos para um problema de otimizacao co-nhecido como problema da mochila multidimensional com multipla escolha.Este artigo propoe uma arquitetura de implementacao para o modelo Huginn.

1. IntroducaoEm sistemas multiagente abertos, nos quais os agentes podem entrar e sair do

sistema a qualquer momento, e importante que o sistema coordene as acoes dos agentespara que o sistema possa atingir seus objetivos. O sistema normativo pode ser utilizadopara esta finalidade, regulando o comportamento de um agente atraves de permissoes,proibicoes e obrigacoes.

A capacidade de compreender e interpretar os sistemas normativos e uma carac-terıstica desejavel para os agentes presentes nesse tipo de sistema. Um agente normativoprecisa resolver conflitos entre desejos (de carater individual) e normas (de carater cole-tivo). As vezes, estes agentes tem o desejo de alcancar um objetivo especıfico, mas umanorma os proıbe de atingir esse objetivo. Por exemplo, um agente deseja chegar ao topoda colina e, ao mesmo tempo, uma norma o proıbe de chegar ao topo. Este agente precisaponderar o que e melhor para ele e para o grupo.

No caso especıfico onde os agentes normativos tem recursos limitados, eles ne-cessitam raciocinar tambem sobre os recursos disponıveis. As vezes, um agente podeconcordar com a norma mas nao tem recursos suficientes para alcancar o objetivo impli-cado pela norma ou a recompensa da norma nao justifica o recurso necessario.

Dentre os modelos propostos para agentes normativos, o modelo Huginn[Schmitz and Hubner 2013], ate onde sabemos, e o unico que trata explicitamente dautilizacao de recursos finitos no raciocınio de desejos e normas. O Huggin e um modeloteorico que traduz o processo de deliberacao para um problema de otimizacao conhecidocomo problema da mochila multidimensional com multiplas escolhas. Este modelo e des-crito brevemente na secao 2. Com a finalidade de viabilizar o modelo, este artigo propoeuma arquitetura de implementacao. Para tal os objetivos deste artigo sao:

AutoSoft

13

• Identificar os elementos do Huggin e atribuir a estes uma representacao dentrodo framework JaCaMo1 [Boissier et al. 2013]. Na secao 3.1 e apresentado umaserie de artefatos, crencas e notacoes de objetivos para representar os elementosconstituintes do modelo Huginn.• Alterar a arquitetura do agente Jason2 [Bordini et al. 2007] para que este possa

identificar os elementos do Huginn e assim executar o processo de deliberacao.Na secao 3.2 sao apresentados os elementos adicionados a arquitetura de agentedo Jason e os algoritmos envolvidos.

Este e um trabalho em andamento e os resultados apresentados neste artigo dizem res-peito a concepcao pratica do modelo Huginn. Futuramente, estao previstas avaliacoescomparativas entre diferentes modelos normativos.

2. O modelo Huginn

O raciocınio normativo baseado em animo proposto em[Schmitz and Hubner 2013] e inspirado no trabalho [Thayer 1989] e permite que oagente raciocine sobre normas e desejos, considerando os recursos disponıveis. Existemtres conceitos chaves neste modelo: a energia, a tensao e o benefıcio.

No Huginn a energia do agente corresponde a quantidade de recursos que elepossui para cumprir os objetivos implicados pelas normas e desejos. A tensao do agenterepresenta o feedback negativo gerado pelo nao cumprimento de uma norma ou desejo.O benefıcio representa o feedback positivo gerado pelo cumprimento de uma norma oudesejo.

A energia do agente e um espaco d-dimensional no qual cada dimensao representaum recurso limitado. Por exemplo, se um agente tem dois recursos, pneus e combustıvel, aenergia e bidimensional e esta e utilizada para minimizar a tensao e maximizar o benefıcio(melhor animo).

O Huginn propoe modelar a energia, tensao e benefıcio como um problema deotimizacao, permitindo ao agente encontrar o melhor animo (menos tensao e mais be-nefıcios). O processo de deliberacao tem como entradas os desejos, normas e recursos etem como saıda o melhor conjunto de objetivos.

O processo de deliberacao e acionado quando os dados de entrada sofremalteracao. O primeiro gatilho e a expiracao de uma norma ou desejo. Quando o desejoou norma tem sua condicao de expiracao verdadeira, o objetivo implicado por ele nao emais relevante. A expiracao causa uma liberacao de recursos sendo necessario executar oprocesso de deliberacao para encontrar novamente o melhor animo.

O segundo gatilho e a percepcao de uma nova norma, desejo, ou recurso. Nestassituacoes, o processo de deliberacao e acionado, pois, eventualmente e possıvel produzirum novo conjunto com um animo melhor do que o atual.

A figura 1 ilustra o processo de deliberacao proposto. O hexagono representa oprocesso de deliberacao normativa, os retangulos representam conjuntos, e a caixa tra-cejada representa a definicao de energias, tensao e benefıcio. A figura 1 apresenta cinco

1http://jacamo.sourceforge.net/2http://jason.sourceforge.net/

AutoSoft

14

Objetivos(O)

Seleção de objetivos

Normas(N)

Desejos(D)

Recursos(R)

Conjunto de objetivos de melhor ânimo

(M)Expiração - normas - desejosPercepção - normas - desejos - recursos

Gatilhos

Definições de energias, tensões e

benefícios

Figura 1. Fluxograma do processo de deliberacao

conjuntos ( R, D, N , O, M ), onde R e composto por todos os tipos de recursos dis-ponıveis para o agente, D e o conjunto de todos os desejos, N e composto por todas asnormas ativas, O e o conjunto de objetivos implicadas pelos desejos e normas em D e N ,por fim, M e o conjunto de objetivos que maximiza os ganhos do agente.

Este artigo concentra-se na implementacao dos elementos destacados em cinza dafigura 1. O elemento definicao de energias, tensao e benefıcio dos objetivos implicadospor desejos e normas e abordado na secao 3.1. Os outros dois elementos, abordados nasecao 3.2, sao os gatilhos que disparam o processo de deliberacao e a selecao de objetivos.

3. Arquitetura de implementacao do modelo HuginnEste artigo apresenta uma proposta de implementacao do Huginn atraves da ex-

tensao da plataforma Jason [Bordini et al. 2007]. A escolha pelo Jason foi motivada pelasua consolidacao na area, sendo referencia constante na area academica para construcaode agentes BDI. O fato de fazer parte do framework JaCaMo foi outro fator que motivoua escolha. Inicialmente, a implementacao proposta fara uso apenas do JaCa (Jason e CAr-tAgO [Ricci et al. 2007])3. A descricao da proposta de implementacao ocorrera em duaspartes. A representacao das informacoes requeridas pelo Huginn e as alteracoes na arqui-tetura do agente para que o processo de deliberacao do Huginn seja possıvel, apresentadasrespectivamente nas secoes 3.1 e 3.2.

3.1. Expressando energias, tensoes e benefıcios

Os tres eixos que dao suporte ao processo de deliberacao do Huginn sao os dese-jos, as normas e os recursos. Nesta abordagem sera considerado que cada agente possuidois artefatos com os quais apenas o agente e capaz de interagir. Este artefatos represen-tam os recursos do agente e as normas que o agente deve obedecer. Os desejos por suavez sao de natureza interna do agente e, como tal, sao representados por crencas.

Os recursos sao considerados de uso pessoal do agente e, portanto, os agentes naocompartilham os mesmos recursos. Para representar os recursos disponıveis, cada agentepossui um artefato composto por uma propriedade observavel para cada recurso. Estapropriedade e representada em (1).

resource(resourceType, quantity) (1)

3Neste primeiro momento, nao utilizou-se o Moise porque ele segue um paradigma onde tudo e proibidoexceto o que e permitido e o Huginn segue um paradigma onde tudo e permitido menos o que e proibido.

AutoSoft

15

O artefato de normas por sua vez possui apenas propriedades observaveis referen-tes as obrigacoes e proibicoes do agente. A propriedade observavel identifica o objetivoimplicado pela norma, a condicao de expiracao, a sancao, a recompensa e o tipo da norma(p para proibicao e o para obrigacao). A assinatura dessas propriedades e representadapor (2).

norm(goal , expiration, saction, reward , normType) (2)

Os desejos definidos no Huginn sao de natureza interna do agente e, portanto,representados por: crencas que identificam o objetivo desejado, a condicao de expiracaodo desejo, a necessidade e a intensidade do desejo. A assinatura desta crenca e dada por(3).

desire(goal , expiration, necessity , intensity) (3)

Alem dos tres eixos do processo de deliberacao o Huginn especifica que os obje-tivos possuem tres tipos de propriedades: a tensao, o benefıcio e as energias necessarias.A tensao esta relacionada a sancao da norma e a necessidade do desejo. O benefıcio estarelacionado a recompensa da norma e a intensidade do desejo. Por fim as energias estaorelacionadas aos recursos necessarios para cumprir os objetivos.

Conforme descrito em Huginn [Schmitz and Hubner 2013], a tensao de um obje-tivo o e baseada na sancao caso este seja implicado por uma norma e baseada na necessi-dade quando implicado por um desejo. Esta relacao e representada em (4).

tension(o) =

{sanction(o) se o provem de uma normanecessity(o) se o provem de um desejo (4)

Em Huginn [Schmitz and Hubner 2013], o benefıcio de um objetivo e baseado narecompensa caso este seja implicado por uma norma e baseado na intensidade quandoimplicado por um desejo. Esta relacao e representada em (5).

benefit(o) =

{reward(o) se o provem de uma normaintensity(o) se o provem de um desejo (5)

No Huginn, a definicao da energia necessaria para atender um objetivo e dadapor uma funcao definida pelo projetista do agente. A energia requerida para atingir umobjetivo depende do estado atual do agente. Por exemplo, se o agente tem o objetivo deir para a posicao 7 e o mesmo se encontra na posicao 1 o custo energetico e maior do quese o agente estiver na posicao 5.

Este artigo, em sua proposta de implementacao, traduz as normas e desejos co-nhecidos pelo agente em objetivos. Para permitir que o desenvolvedor possa facilmentepersonalizar o agente de acordo com a sua vontade, optou-se por deixar explıcito para odesenvolvedor a traducao das normas e desejos em objetivos.

O plano 1 apresenta um plano generico para traducao de normas em objetivos.Este plano e apresentado na linguagem Jason e representa que para toda percepcao denorma, sera calculada a quantidade de energia requerida para atingir o objetivo, represen-tado nas linhas 3 a 5, e criado um objetivo GOAL com as seguintes anotacoes:

AutoSoft

16

1 +norm(GOAL, EXPIRATION, SANCTION, REWARD, NORMTYPE): true2 <-3 ?energyRequired(GOAL,r1,Q1);4 ...5 ?energyRequired(GOAL,rn,Qn);6 !GOAL[ cexp(EXPIRATION), tension(SANCTION),7 benefit (REWARD), typesource(NORMTYPE),8 resource(r1,Q1), ..., resource(rn,Qn)].

Plano 1. Plano generico para traducao de normas em objetivos

1 +norm(gather(stone), stones(5), 0.5, 0.4, o): true2 <-3 !gather(stone)[ cexp(stones(5)), tension(0.5),4 benefit (0.4), typesource(o),5 resource(pickaxe,1)].

Plano 2. Exemplo de percepcao de norma

• a condicao de expiracao (cexp) contendo a expiracao da norma (EXPIRATION);• a tensao (tension) contendo o valor da sancao (SANCTION);• o benefıcio (benefit) contendo o valor da recompensa (REWARD);• a origem (typesource) contendo o tipo da norma (NORMTYPE);• os recursos necessarios (resource) e as respectivas quantidades

((r1,Q1)..(rn,Qn)) para se obter o objetivo.

O plano 2 exemplifica um caso especıfico de como as normas sao traduzidas emobjetivos. Neste plano o agente tem uma obrigacao de obter pedras ate que o mesmo pos-sua 5 pedras. Caso nao a cumpra ele sofre uma sancao 0.5. Por outro lado cumprindo-ao agente ganha uma recompensa de 0.4. Como e previsto no Huginn, a norma e inter-pretada como um objetivo com as seguintes propriedades: condicao de expiracao de 5pedras, tensao de 0.5, benefıcio de 0.4, recursos necessarios 1 picareta e origem do obje-tivo e uma norma do tipo obrigacao. A definicao do recurso neste caso foi direta, mas odesenvolvedor do agente pode construir um conjunto de regras para definir quanto recursosera necessario. Da mesma maneira o desenvolvedor pode adicionar a esta traducao umconjunto de regras para reforcar ou dissuadir as normas atraves da definicao da tensao edo objetivo. Neste exemplo optamos pelo padrao proposto pelo Huginn.

Os desejos sao traduzidos de forma similar as normas. O plano 3 apresenta umplano generico para traducao de desejos em objetivos. Este plano representa que, paratoda percepcao de desejo, sera calculada a quantidade de energia requerida para atingiro objetivo, representado nas linhas 3 a 5, e criado um objetivo GOAL com as seguintesanotacoes:

• a condicao de expiracao (cexp) contendo a expiracao da norma (EXPIRATION);• a tensao (tension) contendo o valor da sancao (NECESSITY);• o benefıcio (benefit) contendo o valor da recompensa (INTENSITY);• a origem (typesource) informando que e um desejo (d);• os recursos necessarios (resource) e as respectivas quantidades

((r1,Q1)..(rn,Qn)) para se obter o objetivo.

AutoSoft

17

1 +desire(GOAL, EXPIRATION, NECESSITY, INTENSITY): true2 <-3 ?energyRequired(GOAL,r1,Q1);4 ...5 ?energyRequired(GOAL,rn,Qn);6 !GOAL[ cexp(EXPIRATION), tension(NECESSITY),7 benefit (INTENSITY), typesource(d),8 resource(r1,Q1), ..., resource(rn,Qn)].

Plano 3. Plano generico para traducao de desejos em objetivos

1 +desire(cook(meat), not satisfied, 0.8, 0.3): true2 <-3 !cook(meat)[cexp(not satisfied), tension(0.8)4 benefit (0.3), typesource(d),5 resource (meat,50), resource(coat,10)].

Plano 4. Exemplo de percepcao de desejo

Os desejos sao traduzidos de forma similar as normas. O plano (4) e um casoespecıfico de como os desejos sao traduzidos em objetivos. Neste trecho o agente temum desejo de cozinhar carne ate que esteja satisfeito. A intensidade deste desejo e 0.3e a necessidade e 0.8. Como e previsto no Huginn, o desejo e interpretado como umobjetivo com as seguintes propriedades: condicao de expiracao nao satisfeito, tensao de0.8, benefıcio de 0.3, recursos necessarios 50 kg de carne e 10 kg de carvao e origem doobjetivo um desejo. Assim como no exemplo anterior a definicao do recurso foi direta,contudo para cumprir este objetivo serao necessarios dois tipos de recursos a carne eo carvao. Assim como no caso das normas, o desenvolvedor pode criar um conjuntode regras para definir benefıcios, energias e tensoes. No trecho de codigo em questaooptamos pelo padrao proposto em[Schmitz and Hubner 2013].

Outra caracterıstica do modelo Huginn e o tratamento de objetivos que nao po-dem ser atingidos ao mesmo tempo. O modelo nao especifica como estes conflitos entreobjetivos sao detectados. Considerando como premissa que existem diversos trabalhosque tratam da deteccao de conflitos [Joseph et al. 2010, Thagard 2002], esta propostade implementacao nao ira determinar um mecanismo especıfico para detectar conflitos.A proposta formaliza o conflito como uma crenca que relaciona dois objetivos. Umexemplo e o conflito entre o objetivo cozinhar carne (cook(meat)) e nao cozinhar carne(∼ cook(meat)), representado no trecho de codigo (6).

conflict(cook(meat),∼ cook(meat)). (6)

A figura 2 resume os itens abordados nesta secao, na qual tratamos:

• a representacao dos tres eixos do Huginn: os desejos, as normas e os recursos;• a traducao das normas e desejos em objetivos, passando pela identificacao da

tensao, do benefıcio e das energias;• a representacao de conflitos.

Estes itens serao utilizados na arquitetura apresentada na secao 3.2 para compor efetiva-mente o raciocınio normativo.

AutoSoft

18

oplink op

Recursos

oplink op

Normas

Agente

conflict(cook(meat), ~cook(meat)). +norm(gather(stone), stones(5), 0.5, 0.4, o) : true <- !gather(stone)[ cexp(stones(5)),tension(0.5),

benefit(0.4),typesource(o), resource (pickaxe,1)].

+desire(cook(meat), not satisfied, 0.8, 0.3) : true <-

!cook(meat)[ cexp(not satisfied), tension(0.8), benefit(0.3), typesource(d),

resource(meat,50), resource(coat,10)].

Figura 2. Exemplo de codificacao de um agente normativo

3.2. Extensao da arquitetura de agente do JasonA implementacao proposta neste artigo estende a arquitetura de agente da plata-

forma Jason [Bordini et al. 2007]. A arquitetura estendida do Jason e representada nafigura 3. O funcionamento do Huginn e baseado em eventos que quando ocorridos dis-param o processo de deliberacao normativa. Os eventos podem ser capturados na funcaoselectEvent (SE) da arquitetura do Jason, destacado no losango 5 da figura 3. Esteseventos podem conter a adicao e remocao de crencas e objetivos.

SI

EventsExternal Event

Selected

SE

Beliefs toAdd and

Delete

RelevantPlans

New PlanPush

IntentionUpdated

OS

ApplicablePlans

MeansIntended

EventsExternal

PlanLibrary

Events

InternalEvents

3

checkMail

Intentions

ExecuteIntention

...NewNew

9

BeliefBase

NewIntention

Percepts

act

SelectedIntention

Intentions

Action

Percepts1 2

BUF

10

Events

ContextCheck

EventUnify

BRF

Beliefs

Agent

sendMsg

Beliefs

8

Messages

Plans

perceive

7

5

6

Actions

Beliefs

Suspended Intentions(Actions and Msgs)

...

.send

SocAcc4

Messages MessagesSM

Goals

Figura 3. Arquitetura de agente na plataforma do Huggin

Na funcao selectEvent proposta, os eventos recebido como entrada sao filtra-dos de forma a nao ultrapassar os recursos disponıveis obtendo o melhor benefıcio. Paraque isso ocorra, os eventos relacionados aos objetivos sao armazenados em uma estru-tura paralela representando o conjunto de objetivos O. Este conjunto e representado na

AutoSoft

19

figura 3 pelo retangulo em destaque. Para cada objetivo sao armazenadas as seguintesinformacoes: descricao do objetivo; origem (desejo, obrigacao ou proibicao); condicaode expiracao; lista de recursos necessarios para cumprir o objetivo; benefıcio; tensao;evento referente ao objetivo; comprometimento do agente(Verdadeiro para objetivo ativo,falso para objetivo inativo). Com base no conjunto de objetivos e proposto que a funcaoselectEvent siga o algoritmo 1, onde fo e o objetivo representado pelo evento f , of e oevento que representa o objetivo o e fr e o evento que representa a adicao ou subtracao dorecurso r.

Algoritmo 1: Funcao selectEventInput: Fila de Eventos Fi

Output: Fila de Eventos filtradas pelos objetivos ativos Fm

1 newDeliberation=false;2 Fm = Fi;3 for each (f ∈ Fi) do4 if fo /∈ O then5 O := O ∪ {fo};6 newDeliberation=true;

7 if fr e adicao de recursos then8 newDeliberation=true;

9 for each (o ∈ O) do10 if condicao de expiracao de o e verdadeira then11 O := O\{o};12 newDeliberation=true;

13 if newDeliberation then14 M := deliberation(O) ;15 for each (f ∈ Fm) do16 if fo /∈M then17 Fm = Fm\{fo};

18 for each (o ∈M ) do19 if of /∈ Fm then20 Fm := Fm ∪ {of};

21 return Fm

Para descrever em detalhes o processo de selecao proposto o mesmo foi divididoem duas partes: eventos que disparam a selecao de objetivos e a selecao dos objetivos.

Dois tipos de eventos disparam o processo de deliberacao do Huginn: a percepcaoe a expiracao. Para identifica-los e percorrida a fila de eventos recebida como parametroda funcao selectEvent. Caso alguma das situacoes a seguir ocorra o processo dedeliberacao sera disparado.

• Percepcao de um novo desejo ou norma. Para tal, existira um evento contendoum objetivo que provem de um desejo ou norma. Um novo objetivo e percebidoquando o objetivo presente no evento nao esta presente no conjunto O. Neste

AutoSoft

20

caso o novo objetivo e adicionado ao conjunto O e sera executado o processo dedeliberacao. Esta situacao e representada nas linhas 4 a 6 do algoritmo 1.• Percepcao de adicao de recurso. Esta situacao corresponde a encontrar um evento

de adicao de crenca que aumente a quantidade de recurso disponıvel. Para tanto oprocesso consulta a base de crencas do agente para comparar se o valor adicionadoe maior que o existente. Caso o recurso nao esteja presente na base de crencasa simples adicao da crenca dispara o processo de deliberacao. Esta situacao erepresentada nas linhas 7 e 8 do algoritmo 1.• Expiracao de um objetivo. Esta situacao ocorre quando um evento possui um

objetivo com a condicao de expiracao satisfeita. Para identificar esta condicaoo processo verifica na base de crencas se a condicao de expiracao e verdadeira.Neste caso o objetivo expirado e removido do conjunto O e e executado o processode deliberacao. Esta situacao e representada nas linhas 9 a 12 do algoritmo 1.

Quando uma destas tres situacoes ocorre o processo de deliberacao normativa (li-nha 14 do algoritmo 1) e executado, selecionando os objetivos que oferecem o melhoranimo. Apos selecionado os objetivos, os eventos que contem objetivos que nao foramselecionados sao removidos da lista de eventos (linhas 15 a 17 do algoritmo 1) e os obje-tivos selecionados que nao possuem evento na lista tem seu evento adicionado a mesma(linhas 18 a 20 do algoritmo 1).

O processo de deliberacao normativa traduz os objetivos, conflitos e recursosem um problema da mochila multidimensional com multipla escolha, como descrito em[Schmitz and Hubner 2013] e representado em (7). Nesta traducao os objetivos sao repre-sentados por variaveis de decisao binarias (mo) que indicam a sua ativacao; os conflitossao representados por conjuntos (c) dos quais no maximo um objetivo pode ser sele-cionado por conjunto; os recursos sao mapeados em restricoes; a tensao e o benefıciocompoem o coeficiente da variavel de decisao na funcao de maximizacao.

Maximize∑c∈C

∑o∈c

(mo(benefit(o) + tension(o))) (7)

Sujeito :∑c∈C

∑o∈c

(moenergyreq(o, r)) ≤ resourceAvailable(r), r ∈ R∑o∈c

mo ≤ 1, c ∈ C

O problema de otimizacao descrito pode ser caracterizado como uma subclassedo MIP (mixed integer programming) conhecida como programacao inteira binaria. Osproblemas do tipo MIP sao problemas de programacao linear, nos quais algumas variaveisde decisao sao inteiras. Para encontrar a solucao deste problema inicialmente foi utilizadoo solver GLPK. O GLPK4 (GNU Linear Programming Kit) e um conjunto de rotinasescritas na linguagem de programacao C e organizadas na forma de uma biblioteca. Aintencao dessa biblioteca e resolver problemas de programacao linear (LP) e programacaointeira mista (MIP).

4http://www.gnu.org/software/glpk/

AutoSoft

21

Ao utilizar o GLPK garantimos que o processo encontre sempre a solucao otima,neste caso o conjunto de objetivos que gera o melhor animo. O fato da arquitetura pro-posta ser baseada no Jason traz algumas complicacoes. A primeira complicacao e que oGLPK e desenvolvido em C e a plataforma Jason em Java. E possıvel comunicar as duasferramentas atraves de um JNI (Java Native Interface), contudo e exigido que cada com-putador no qual a plataforma seja instalada tambem contenha o GLPK e uma compilacaoespecifica a classe de interface JNI. Estes dois fatores criam um problema de distribuicaopois dificultam a sua instalacao. Outra desvantagem e que em alguns casos o processo dedeliberacao pode ser um pouco demorado (200 ms).

Como alternativa o presente artigo propoe uma heurıstica baseada em um algo-ritmo guloso proposto em [Kellerer et al. 2004], que possui um tempo de resposta melhor,mas uma qualidade de solucao inferior ao GLPK. O algoritmo proposto utiliza o conceitode eficiencia representada pela divisao do coeficiente da variavel de decisao (benefıcio+ tensao) pelos custos de restricao (recursos necessarios). No algoritmos propostos aeficiencia de um objetivo o e dada por (8). Onde R e o conjunto dos recursos. As funcoesbenefit(o), tension(o) e energyreq(o, r) retornam respectivamente o benefıcio, a tensaoe o recurso r necessario para cumprir o objetivo.

efficiency(o) =∑r∈R

benefit(o) + tension(o)

energyreq(o, r)(8)

O algoritmo 2 apresenta a funcao selecao de objetivos que implementa adeliberacao normativa. Esta funcao tem como entrada o conjunto objetivos O. O al-goritmo ordena o conjunto O por ordem decrescente de eficiencia (linha 1 do algoritmo2). Na etapa seguinte, percorre o conjunto ordenado adicionando ao conjunto M aquelesobjetivos que nao ultrapassam a quantidade disponıvel de recursos e nao tenham conflitocom os objetivos ja presentes nesse conjunto (linhas 3 a 7 do algoritmo 2). O recurso ne-cessario para atingir cada objetivo e reservado quando este e adicionado a M , para tantoa quantidade necessaria e deduzida do recurso disponıvel (resourceAvaliable(r)).

Algoritmo 2: Algoritmo de deliberacao normativaInput: Conjunto de objetivos OOutput: Conjunto de objetivos selecionados M

1 ordena por eficiencia o conjunto O;2 M := ∅;3 for each (o ∈ O) do4 if ∀r ∈ R energyreq(r, o) ≤ resourceAvailable(r)∧

∀m ∈M¬conflict(o,m) then5 M := M ∪ {o};6 for each (r ∈ R) do7 resourceAvailable(r) = resourceAvailable(r)−energyreq(r, o)

8 return M

Como podemos perceber a execucao deste algoritmo e rapida, pois sua comple-xidade e O(n log n + nm), onde n = |O| e m = |R|. Outro ponto a favor e a facil

AutoSoft

22

distribuicao pois diferente do GLPK nao e necessaria a instalacao de nenhum softwareauxiliar onde a plataforma sera instalada. O principal ponto negativo da abordagem enao garantir o resultado otimo, contudo em testes preliminares os valores obtidos saoproximos ao otimo. Em media 15% abaixo do otimo para um conjunto de teste de 100000problemas com 100 objetivos gerados aleatoriamente.

4. Trabalhos relacionadosExistem diversos trabalhos sobre programacao normativa e plataformas para de-

senvolvimento de sistemas multiagente normativos. Destes trabalhos alguns permitem aoagente deliberar sobre o cumprimento de normas. Varios destes trabalhos sao teoricosdentre eles podemos citar o BOID [Broersen et al. 2001] que e um dos precursores doassunto. O BOID estende o conceito de BDI [Rao and Georgeff 1995] declarando expli-citamente as obrigacoes e criando um sistema de preferencias para selecionar as normasou desejos mais relevantes, todavia o mesmo nao apresenta nenhuma implementacao. Ou-tros modelos de agente normativo que possuem implementacao sao o Normative KPG[Sadri et al. 2006] e o N-2APL[Alechina et al. 2012].

O Normative KPG estende o modelo KPG (knowledge-goal-plan) adicionandonocoes sobre obrigacoes, proibicoes e papeis. O modelo considera relevante todas asnormas que afetam o papel desempenhado por ele, portanto em caso de conflito comobjetivos pessoais a norma sempre prevalece. Logo, o agente nao e capaz de descumpriruma norma.

O N-2APL e uma linguagem de programacao baseada no paradigma BDI quesuporta agentes capazes de raciocinar sobre as normas. A N-2APL adiciona a 2APL[Dastani 2008] o suporte a conceitos normativos como obrigacoes, proibicoes, sancoes,prazos e duracoes. A deliberacao ocorre com a utilizacao de um algoritmo de escalona-mento e leva em consideracao os prazos e duracoes, alem do criterio de prioridade.

A arquitetura de implementacao apresentada neste trabalho apresenta similarida-des com outras arquiteturas N-BDI. O diferencial desta arquitetura e que ela implementa oHuginn que trabalha com recursos limitados para deliberar sobre desejo e normas. Sendoque os recursos limitados nao sao considerados nos trabalhos relacionados.

5. Consideracoes finaisO presente trabalho apresenta uma arquitetura de implementacao para o modelo

Huginn [Schmitz and Hubner 2013]. Para desenvolver esta arquitetura foi necessario:• Identificar os elementos do Huggin e atribuir a estes uma representacao dentro

do ambiente JaCaMo [Boissier et al. 2013]. Neste artigo foi apresentado o usode artefatos para representar os recursos limitados o agente. Alem de crencase notacoes de objetivos para representar os elementos constituintes dos desejos,normas.• Alterar a arquitetura do agente Jason para que este possa identificar os elementos

do Huginn e assim executar o processo de deliberacao. Neste artigo foi apresen-tado os processos que sao alterados para que a arquitetura de agente do Jason sejacapaz de fazer uma deliberacao normativa como preve o Huginn.

Este e um trabalho em desenvolvimento e podemos identificar alguns trabalhosfuturos. O primeiro e a conclusao da implementacao desta arquitetura para que os futuros

AutoSoft

23

usuarios possam fazer testes e verificar a capacidade de raciocınio do agente. O segundo erelacionar os gastos de recursos aos planos assumidos. No atual estagio da arquitetura osgastos estao relacionados aos objetivos. Logo, nao e possıvel raciocinar sobre um objetivoque e resolvido por planos distintos e, por conseguinte, diferentes custos.

ReferenciasAlechina, N., Dastani, M., and Logan, B. (2012). Programming norm-aware agents. In

Conitzer, V., Winikoff, M., Padgham, L., and van der Hoek, W., editors, Proceedingsof the 11th International Conference on Autonomous Agents and Multiagent Systems(AAMAS 2012), Valencia, Spain.

Boissier, O., Bordini, R. H., Hubner, J. F., Ricci, A., and Santi, A. (2013). Multi-agentoriented programming with jacamo. Science of Computer Programming, 78(6):747–761.

Bordini, R. H., Hubner, J. F., and Wooldridge, M. (2007). Programming Multi-AgentSystems in AgentSpeak using Jason (Wiley Series in Agent Technology). Wiley-Interscience.

Broersen, J., Dastani, M., Hulstijn, J., Huang, Z., and van der Torre, L. (2001). TheBOID architecture: conflicts between beliefs, obligations, intentions and desires. InProceedings of the fifth international conference on Autonomous agents, AGENTS’01, pages 9–16, New York, NY, USA. ACM.

Dastani, M. (2008). 2APL: a practical agent programming language. Autonomous Agentsand Multi-Agent Systems, 16(3):214–248.

Joseph, S., Sierra, C., Schorlemmer, W. M., and Dellunde, P. (2010). Deductive coherenceand norm adoption. Logic Journal of the IGPL, 18(1):118–156.

Kellerer, H., Pferschy, U., and Pisinger, D. (2004). Knapsack Problems. Springer.

Rao, A. S. and Georgeff, M. P. (1995). Bdi agents: From theory to practice. In InProceedings of the First International Conference on Multi-Agent Systems (ICMAS-95, pages 312–319.

Ricci, A., Viroli, M., and Omicini, A. (2007). Cartago: A framework for prototypingartifact-based environments in mas. In Proceedings of the 3rd International Confe-rence on Environments for Multi-agent Systems III, E4MAS’06, pages 67–86, Berlin,Heidelberg. Springer-Verlag.

Sadri, F., Stathis, K., and Toni, F. (2006). Normative kgp agents. Computational &Mathematical Organization Theory, 12(2-3):101–126.

Schmitz, T. L. and Hubner, J. F. (2013). Raciocınio normativo organizacional para agen-tes: Uma abordagem anımica. In IV Workshop sobre Sistemas de Software Autonomos- AutoSoft 2013, pages 59–68.

Thagard, P. (2002). Coherence in thought and action. A Bradford book. M I T PRESS(MA).

Thayer, R. E. (1989). The biopsychology of mood and arousal. Oxford University Press,1st edition.

AutoSoft

24

Reengineering Network Resilience Strategies usinga BDI Architecture

Ingrid Nunes and Alberto Schaeffer-Filho

1Instituto de InformaticaUniversidade Federal do Rio Grande do Sul (UFRGS)

Porto Alegre, Brazil

{ingridnunes,alberto}@inf.ufrgs.br

Abstract. Network resilience is a challenging task. It requires constantly mon-itoring network devices to guarantee quality of service and to address potentialchallenges to network operation, such as malicious attacks, equipment failuresor device misconfiguration. Although many approaches that provide automatedsupport to this task rely on autonomous and pro-active software components,they do not exploit domain-neutral agent-based techniques, which can arguablyprovide flexible solutions to handle situations unpredicted at design time. Inthis paper we present an investigation in which we show how a pattern-basedapproach that addresses a distributed denial-of-service (DDoS) attack usingpolicy-driven Self-Managed Cells (SMCs) can be reengineered using a BDI ar-chitecture and a logic-based language. Based on the new proposed design, wederive lessons learned, which discuss similarities, strengths and weaknesses ofeach approach. One of the main contributions of this study is to explore thesynergy between network resilience and multi-agent system research areas.

1. IntroductionComputer networks are becoming increasingly critical in supporting software appli-cations related to business, leisure and daily life in general. Thus it is fundamen-tal to support reliable network services. This is the main concern of network re-silience [Sterbenz et al. 2010, Smith et al. 2011], which involves constantly monitoringnetwork devices to guarantee quality of service and to address potential challenges to net-work operation, such as malicious attacks, equipment failures or device misconfiguration.

Due to its complex nature, network resilience combines ideas from sev-eral research areas, such as autonomic computing [Lupu et al. 2008] and machinelearning [Nguyen and Armitage 2008]. Approaches that provide automated sup-port to this task typically rely on autonomous and pro-active software compo-nents [Nguengang et al. 2006], which are related to the definition of a (software)agent [Jennings 2001]. Although some of these approaches refer to these componentsas agents, they do not exploit domain-neutral agent-based techniques, which can arguablyprovide flexible solutions to handle situations unpredicted at design time.

In this paper, we discuss how network resilience strate-gies [Schaeffer-Filho et al. 2012] can be reengineered using a widely used agentarchitecture, namely the BDI architecture [Rao and Georgeff 1995]. Initially, re-silience strategies are described in terms of management patterns to address specificnetwork challenges that are implemented using policy-driven Self-Managed Cells

AutoSoft

25

(SMCs) [Lupu et al. 2008]. In particular, we focus on a pattern for a Distributed Denialof Service (DDoS) attack. As result of this investigation, we propose a new agent-basedsolution to address this challenge, structured with BDI agents — composed of beliefs,goals and plans — using a logic-based language. We also detail domain-specific stepsof the BDI reasoning cycle, such as belief revision and goal generation. Based on thenew proposed design, we derive lessons learned, which discuss similarities, strengths andweaknesses of each approach.

Our main contribution is thus the investigation of a new design solution for pro-viding network resilience, using agents and a BDI architecture. Our aims are: (i) to betterunderstand the synergy between the network resilience and multi-agent system researchareas; (ii) to show the applicability of an existing agent-based approach to a real-worldproblem; and (iii) to provide a flexible alternative solution to network resilience.

This paper is organised as follows. Section 2 provides background on network re-silience and the pattern-based approach in which this work is based on. Section 3 presentshow the current approach can be reengineered using a BDI architecture, detailing individ-ual agent components and how they are used to form a multi-agent system. Section 4discusses lessons learned derived from our investigation. Finally, related work is outlinedin Section 5 and the concluding remarks are presented in Section 6.

2. BackgroundThis section describes the background work on network management and network re-silience, and discusses how previous work advocated means of composing and federatingresilience mechanisms into management patterns.

2.1. Network Management and Resilience Strategies

Central to a resilience strategy is the management and reconfiguration of detection andremediation mechanisms, which operate as autonomous components in the network in-frastructure. On the one hand, detection mechanisms such as link monitors, anomalydetection systems and traffic classifiers permit the identification and categorisation ofanomalies and attacks to the network. On the other hand, remediation mechanisms suchas rate limiters, load balancers and firewalls can be used in the subsequent mitigation ofthese challenges. In previous work [Schaeffer-Filho et al. 2012], we have investigatedhow to flexibly organise network mechanisms providing detection and remediation func-tionality in order to combat specific types of network attacks, such as Distributed Denialof Service (DDoS) and worm propagations.

The various mechanisms can be deployed and activated on different parts of thenetwork topology. Therefore, the functions of monitoring, anomaly detection, rate limit-ing and so on could be carried, for example, at the edge of the subnetwork under attack.We assume that mechanism configuration and adaptation can be expressed in terms ofevent-triggered condition-action (ECA) policies [Sloman and Lupu 2002]. Policies allowthe specification of how a component must react in response to specific types of events, ina declarative manner. These mechanisms can be configured and federated into resiliencestrategies to address a specific type of challenge or attack, as the one depicted in Fig-ure 1. This strategy consists of a number of stages, detailed next, which are triggered bydeclarative policies according to the conditions monitored in the network.

AutoSoft

26

:Link Monitor

:AnomalyDetection

:FlowExporter :Classifier :Rate

Limiter

notify_load(name, rate, link)

classify(flow)

limit(flow, rate)

limit(link, rate)

start(link)

notify_detection(IPAddress) limit(IPAddress, rate)

setThreshold(t)

notify_load(name, rate, link)

notify_detection(IPAddress)

notify_classification(label, flow)

start(IPAddress, samplingRate, length)

notify_new_record(flow)

Figure 1. DDoS resilience strategy using a number of mechanisms that mustoperate autonomously in the network [Schaeffer-Filho et al. 2012].

1. Policies configured in the Link Monitor should monitor the incoming traffic rate onthe ingress link and raise an alarm (notify load) in case the traffic volume observedexceeds a given threshold.

2. On receiving this event, an initial rate limiting of the link can be performed bythe Rate Limiter. Policies are used to filter a percentage of all incoming traffic inorder to protect downstream servers.

3. In addition to the preventive rate limiting started at this point, the Anomaly Detec-tion component can further start processing packets to identify the destination IPaddress of the victim.

4. As a result, it raises an event (notify detection) when one destination IP addressaccounts for 60% of all packets. This additional evidence permits the reconfigu-ration of the Rate Limiter to drop 70% of the traffic destined for the victim only.Legitimate traffic that is not destined for the victim is now allowed to go through.

5. If the attack is sustained for a longer period, the Classifier and Flow Exportermechanisms are started. Classifier attempts to identify the specific attack flows.Classification events are generated (notify classification), and rate limiting is con-fined just to the attack flow, and legitimate traffic is allowed to continue.

2.2. A Pattern-based Approach for Network ResiliencePrevious work has introduced the Self-Managed Cell (SMC) [Lupu et al. 2008] as aparadigm for structuring the management aspects of ubiquitous and network applications.An SMC typically consists of a set of autonomous hardware and software componentswith management and adaptation strategies specified as easily modifiable policies. Forexample, SMCs may represent autonomous components supporting resilience function-ality, e.g., link monitoring, anomaly detection and traffic shaping. These components

AutoSoft

27

must autonomously react to conditions monitored in the network, such as increased traf-fic load or suspicious network packets. In essence, an SMC provides an implementationof a MAPE-K loop [IBM 2005]. In the SMC model, ECA policies are used to specifyadaptation rules that determine the reconfiguration actions to be performed in responseto changes in the context, component failures, new components joining the system, orapplication-specific alarms.

In order to assemble and federate SMCs into large-scale applications we rely onthe notion of management patterns [Schaeffer-Filho et al. 2014]. A management patternis a configuration, including policies to be deployed and properties to be satisfied, be-tween a set of SMC types. For example, a management pattern for addressing a DDoSattack will contain the policies and configurations necessary for a set of mechanism typessuch as the ones listed above. SMC types are specified in the pattern using the notion ofroles [Lupu et al. 2008], which are placeholders for actual instances that will be manuallyassigned during runtime by a human expert. The use of patterns supports the constructionof SMC interactions in a methodical manner, by reusing simpler abstractions as designelements of a more complex interaction. The exchange of policies, events and interfacesdefine the task-allocation, communication and structural aspects, respectively, of a cross-SMC interaction. Ultimately, management patterns can capture best practices and theexperience of network operators into reusable policy configurations, which can be auto-matically deployed in the network when a challenge manifests.

3. Providing Network Resilience with BDI agentsPrevious work [Schaeffer-Filho et al. 2012] has shown using simulations that the pro-posed pattern to handle DDoS attacks can be effective. Nevertheless, such an approachtogether with ECA policies focuses on establishing actions that should be performed giventhe occurrence of an event, without capturing the reasoning why a certain set of actions arethe more adequate to be performed. The BDI agent architecture [Rao and Georgeff 1995]— adopted in this work — captures it in goals: the BDI architecture decouples whatshould be done from how it should be done. Consequently, it is possible to perform ahigher-level reasoning that first chooses goals to be achieved, and then selects which ac-tions are more adequate to achieve them according to the current context.

In this section, we show how the previous solution proposed to provide networkresilience can be modelled using agent components following a BDI architecture andusing a logic-based language, similar to the AgentSpeak(L) language [Rao 1996]. Wefirst present, in Section 3.1, individual BDI agent components, such as goals and plans,and then show, in Section 3.2, how such components are used to form a multi-agentsystem able to respond to DDoS attacks.

3.1. Individual BDI Agent ComponentsBDI agents are software components structured with three main finer-grained compo-nents, namely beliefs, goals and plans. Such agents are provided with a reasoning cycle,including the following customisable steps: (i) belief revision: based on perceived events,agents update their current beliefs; (ii) goal generation: agents generate goals that theywant to achieve, considering their current state; (iii) goal deliberation: agents choose,among their current goals, which they are committed to achieve; and (iv) plan selec-tion: agents select a plan to achieve each goal they are committed to achieve. Given this

AutoSoft

28

internal structure of each individual agent, next we present details on the finer-grainedcomponents that are part of our multi-agent solution to prevent DDoS attacks.

3.1.1. Belief Revision

Different network devices (which can be regarded as agents) are connected by links,where network traffic flows. Under normal conditions, only part of the link bandwidthis used, and the link usage should always be below a given threshold. Such links are partof the environment in which agents are located, and agents perceive events that occur in it.Therefore, agents perceive how much of the link capacity is being used, i.e. usage(link),and have a belief — overUsage(link) — that is updated according to the perceived linkusage, as shown in Equations 1 and 2. Such equations are rules, in which the expressionin the right-hand side of the symbol −→ takes place when the expression in the left-handside is true.

greater(usage(link), threshold) −→ belief(overUsage(link)) (1)lesseq(usage(link), threshold) −→ belief(¬overUsage(link)) (2)

When the link bandwidth is being used above the established threshold, there aretwo possibilities: this is due to either regular users that, for a certain reason, are deviatingfrom the usual behaviour, or a malicious attack. Therefore, when agents perceive that thelink bandwidth is being used above the threshold, they do not know if this is associatedwith a regular usage or not, i.e. they believe that∼ regularUsage(link). This absence ofknowledge is shown in Equation 3, where∼means that regularUsage(link) is unknown.

overUsage(link) −→ belief(∼ regularUsage(link)) (3)

3.1.2. Goal Generation and Deliberation

The belief revision step updates beliefs according to perceived external events. Given thecurrent agent state, which is composed of its current beliefs, agents may have differentgoals. A goal is associated with a state of affairs that an agent would like to achieve. Wewill now analyse goals generated by agents according to certain beliefs.

If an agent believes that overUsage(link), there are two goals to be achieved.Firstly, although the agent is not sure whether an attack is indeed occurring, it needsto prevent a possible attack, i.e., it generates a goal attackPrevented(link). Secondly,because the agent does not know if overUsage(link) is due to regular users, it needs tofind this out, by generating a goal ?regularUsage(link). “?” indicates that the target stateof affairs should either contain regularUsage(link) or ¬regularUsage(link). Thesetwo generated goals are shown below.

belief(overUsage(link)) −→goal(attackPrevented(link)) ∧ goal(?regularUsage(link))

(4)

Another situation that may occur is that an agent, somehow, may have de-tected that one of the IP addresses that use a link has an anomalous behaviour, i.e.

AutoSoft

29

anomalous(ip). Similarly to the generated goals above, the agent must restrict the accessof anomalous IPs to the link and find out whether this anomalous behaviour is benign ormalicious, and therefore two goals are generated: restricted(ip) and ?benign(ip).

belief(anomalous(ip)) −→ goal(restricted(ip)) ∧ goal(?benign(ip)) (5)

An agent may also become aware that a certain IP flow is likely to be associatedwith an attack, that is, it is a threat to the network — threat(flow). When this happens,the agent should respond to the threat, by generating a goal threatResponded(flow).

belief(threat(flow)) −→ goal(threatResponded(flow)) (6)

Finally, ideally, links should always be fully operational and accessible from any-where (i.e. by any IP address). Therefore, if a link is not fully operational, agents have agoal to make them fully operational, or if an IP address is restricted, agents have a goal tomake them unrestricted. This is shown in Equations 7 and 8, which generate these goals.Note these goals are generated solely when it is safe to do so.

belief(¬fullyOperational(link)) ∧ belief(regularUsage(link)) −→goal(fullyOperational(link))

(7)

belief(restricted(ip)) ∧ belief(¬anomalous(ip)) −→ goal(¬restricted(ip)) (8)

Given these goal generation rules, agents may have many goals to achieve. How-ever, according to the current context, agents may be committed to achieve only someof the goals, for instance those with higher priority, to later achieve others. This isperformed in the goal deliberation step. In our scenario, agents should prevent an at-tack, before learning about a certain information. Therefore goals that will lead to (pal-liative) actions to prevent and respond to attacks have the highest priority, which are:attackPrevented(link), restricted(ip), threatResponded(flow). Goals that restorefull operation, fullyOperational(link) and ¬restricted(ip), also have higher prioritythan the informational goals ?regularUsage(link) and ?benign(ip).

3.1.3. Plan Selection

We showed how agents reason about what should be done, without concerning with howit should be done. Now, we will focus on the latter, by detailing the plans to achieve goals.All plans, which are shown in Table 1 and will be described next, are used to achieve thepresented goals and consequently to respond to a DDoS attack. Each plan has a name(with an acronym that will be used later to refer to it), a goal that it can achieve, thecontext that state the conditions in which the plan is applicable, and a set of actions thatare executed to achieve the goal associated with the plan.

In order to describe plans, we will consider an initial scenario in which a specificflow is attacking a server in a network, and there is a single network switch (i.e., an agent)that provides access to this server through a single link. Consequently, after perceivingevents, the agent believes that overUsage(link) and ∼ regularUsage(link), and conse-quently has the goals attackPrevented(link) and ?regularUsage(link). So, the agent

AutoSoft

30

Table 1. Plans for responding to a DDoS attack.Plan: LimitLinkRate (LLR) Plan: AnalyseLinkStatistics (ALS)Goal: attackPrevented(link) Goal: ?regularUsage(link)Context: overUsage(link) Context: -Actions: Actions:limit(link, rate) // Analyse link and detect outliersbelief(¬fullyOperational(link)) ∀ip.(outlier(ip)) −→ belief(anomalous(ip)) ∧ belief(∼ benign(ip))belief(attackPrevented(link)) ∃ip.(anomalous(ip)) −→ belief(¬regularUsage(link))

@ip.(anomalous(ip)) −→ belief(regularUsage(link))Plan: RestoreLinkRate (RLR) Plan: LimitIPRate (LIPR)Goal: fullyOperational(link) Goal: restricted(ip)Context: regularUsage(link) Context: anomalous(ip)Actions: Actions:unlimit(link) limit(ip, rate)belief(fullyOperational(link)) belief(ipRateLimited(ip))belief(∼ attackPrevented(link)) belief(restricted(ip))

@ip′.(anomalous(ip′) ∧ ¬restricted(ip′)) −→ regularUsage(link)Plan: RecordFlow (RF) Plan: AnalyseIPFlows (AIPF)Goal: flowRecord(ip) Goal: ?benign(ip)Context: - Context: anomalous(ip)Actions: Actions:recordFlow(ip) goal(?flowRecord(ip))belief(flowRecord(ip)) // Classify flow record using machine learning

∀flow.(malicious(flow)) −→ belief(threat(flow))∃flow.(threat(flow) ∧ srcIP (flow) = ip) −→ belief(¬benign(ip))@flow.(threat(flow) ∧ srcIP (flow) = ip) −→ belief(benign(ip))

Plan: RestoreIPRate (RIPR) Plan: LimitFlowRate (LFR)Goal: ¬restricted(ip) Goal: threatResponded(flow)Context: benign(ip)∧ Context: threat(flow)

ipRateLimited(ip) Actions:Actions: limit(flow, rate)permit(ip) belief(flowRateLimited(flow))belief(¬ipRateLimited(ip)) belief(threatResponded(flow))belief(¬restricted(ip)) belief(∼ threat(flow))belief(∼ anomalous(ip)) @f.(threat(f) ∧ srcIP (flow) = srcIP (f)) −→ belief(benign(ip))

executes first the LLR plan to achieve attackPrevented(link), causing the link to be par-tially operational (¬fullyOperational(link)). Then, the ALS plan is executed to achieve?regularUsage(link) and performs statistical analysis of the link usage, concluding thatthere is an IP address with an anomalous behaviour (anomalous(ip)), which may be be-nign or malicious (∼ benign(ip)). Because now the agent believes that anomalous(ip),it also believes ¬regularUsage(link). Given that the agent knows that there is an IPaddress with anomalous behaviour, it generates goals to restrict it (restricted(ip)) andto know whether it is benign (?benign(ip)). So the LIPR plan is executed to achievethe former, and the AIPF to achieve the latter. Restricting the only IP address that isanomalous causes the agent to believe that regularUsage(link) and, as a consequence, itgenerates the goal of becoming fully operational again. As this goal has a higher prioritythan that of the ?benign(ip) goal, the RLR plan is executed, restoring the link rate. Toachieve ?benign(ip), the AIPF is executed. This plan uses a flow record, which is a beliefthat the agent does not currently have. So the AIPF plan adds a new goal to the agent,which executes the RF plan to obtain this information. Then, the AIPF plan continues itsexecution, by using a machine learning algorithm to classify flows (e.g., K-means, NaıveBayes, SVM), and concludes that a particular flow is a threat (threat(flow)), and thus theIP address is malicious (¬benign(ip)). Because there is a threat, the agent must achievethe goal threatResponded(flow), and executes the LFR plan to do so. As the maliciousflow is now limited, the IP address is considered benign and can be unrestricted. Theagent generates the goal ¬restricted(ip), and executes the RIPR plan to achieve it. In the

AutoSoft

31

Table 2. Example of belief base updates given a DDoS attack.Belief Start LLR ALS LIPR RLR AIPF(1) RF AIPF(2) LFR RIPRoverUsage(link) p p ¬1 ¬ ¬ ¬ ¬ ¬ ¬ ¬regularUsage(link) ∼ ∼ ¬ p p p p p p pfullyOperational(link) ¬ ¬ ¬ p p p p p pattackPrevented(link) p p p ∼ ∼ ∼ ∼ ∼ panomalous(ip) p p p p p p p ∼restricted(ip) p p p p p p ¬ipRateLimited(ip) p p p p p p ¬benign(ip) ∼ ∼ ∼ ∼ ∼ ¬ p pflowRecord(ip) p p p pthreat(flow) p ∼ ∼flowRateLimited(flow) p pthreatResponded(flow) p p1Updated due to belief revision.

end, the agent is fully operational and the malicious flow is limited.

This evolution of agent beliefs over time due to the execution of plans is sum-marised in Table 2. As mentioned before, we assume that the agent has as initial beliefsthe knowledge that the link is being overused, and does not know whether this is due toregular users. Then, each column represents the current agent beliefs after the executionof the plan that is indicated in the column title: (i) p: belief is true; (ii) ¬: belief is false;and (iii) ∼: it is unknown whether the belief is true. Grey cells indicate belief changes.

Two further observations can be made with respect to these plans. First, plansare independent from each other, and there is no action that invokes any of the plans.Current agent beliefs and goals are the factors that lead to plan execution. Therefore,Table 2 shows just an example of a sequence in which plans are executed. Second, thereare beliefs — ipRateLimited(ip) and flowRateLimited(flow) — that are currently notexplicitly used in our proposed design. They are used to distinguish the intervention made(such as limiting an IP address) from an ultimate goal (such as restricting an IP address).There may be different possible interventions (i.e. plans) to achieve a certain ultimategoal and, if we provided these alternative plans, agents may choose the best according toa certain scenario, or use them in case a plan fails.

3.2. Multi-agent Architecture

In previous sections, we showed components that are used to compose a BDI agent, andillustrated a scenario in which we have a single agent with all these presented components.Although this single agent provides the whole solution to respond to DDoS attacks, dueto hardware restrictions, it is more adequate to distribute responsibilities among differentnetwork devices. For example, running traffic classification algorithms requires signifi-cant RAM memory and a powerful processor, and it is thus convenient to have a dedicatedmachine to perform this task.

We will consider a network configuration that is composed of the following de-vices: (i) application servers: responsible for running applications; (ii) IP load balancers:responsible for distributing user requests among different replicated application servers;(iii) routers: responsible for forwarding network packets to their proper destination; (iv)firewall: responsible for blocking or not the flow of network traffic; and (v) classifiers:responsible for analysing flows and classifying them as malicious or benign. As can beseen in Table 1, there are some plans that involve some primitive actions, such as limiting

AutoSoft

32

Figure 2. Configuration of network devices with Initial beliefs and plans.

traffic. Therefore, these plans must be added only to agents (i.e., network devices) thatare able to perform such actions. We show an example of network topology, together withthe distribution of plans of Table 1 among agents in Figure 2.

As no agent has all plans, they are not able to achieve all goals. Agents must, thus,collaborate to respond to attacks. Due to space restrictions, we limit ourselves to a broaddescription of how agents collaborate to do so. When an agent is unable to achieve a goal(i.e., it has no plan to achieve it), it will request other agents of the network to achievethem. Other agents reply to this request by answering whether they can achieve the re-quested goal and an associated cost. This cost can be associated with the current agentavailability in terms memory or processor, or physical location, when a significant amountof data will be exchanged between agents. Such costs allow the agent that made the re-quest to decide to which agent it will delegate the goal. This process can be performedusing the FIPA Contract Net Interaction Protocol1, for example.

4. DiscussionThis paper proposes reengineering an existing solution that addresses DDoS attacks.Therefore, our agent-based design is expected to achieve similar performance than theoriginal solution in standard scenarios. As said in the introduction, our main goal withthis new design is to investigate, in the form of an exploratory study, the use of a BDIarchitecture to provide network resilience, and its impact in the design. We thus in thissection provide a qualitative discussion of major issues that were identified.

1http://www.fipa.org/specs/fipa00029/

AutoSoft

33

Table 3. Comparison of adopted terms.BDI Agent-based approach SMC-based approach

External Event EventGoal

Plan Context ConditionPlan Action

Organisation Management PatternRoles Roles

Interaction Protocols Interface

Table 4. Strengths (+) and weaknesses (-) of each approach.BDI Agent-based Approach SMC-based Approach(-) It is harder to understand its behaviour, becausethere are different factors that influence it (currentbeliefs, generated goals, etc.).

(+) It has a more predictable behaviour, because itis easier to analyse the chain of events generatedby each ECA policy, thus facilitating testing.

(+) It has a flexible behaviour, because of the dif-ferent factors that influence agent behaviour, thusallowing agents to handle situations unpredictedat design time.

(-) It is able to handle only situations predicted atdesign time.

(+) As it captures motivational state, an agent maytry different plans until it achieves a goal.

(-) It does not capture motivational state, thereforetrying different alternatives to solve an issue mustbe implemented manually.

(+) It isolates concerns: (i) informational state andhow it is updated based on perceived events; (ii)motivational state; (iii) actions to achieve goals.

(-) All these concerns are tangled in ECA policies.

(+) Plugging a new device in the network does notrequire human intervention to make it collaboratewith other devices.

(-) When a new device is added to the network, anexpert should manually re-assign roles to devices.

Terminology. Both the pattern-based approach used as reference in this work and theBDI architecture consider autonomous software components as building blocks. Never-theless, such software components (SMCs and BDI agents) are structured with differentfiner-grained components. With respect to this, we identified several similarities amongthese components, as detailed in Table 3. As can be seen, most of the concepts exist inboth approaches. The key difference is the goal concept, which specifies a motivationalstate. This makes SMCs reactive, while agents are pro-active. Some agent concepts —organisation, roles, and interaction protocols — are not explored in this paper, but thereare agent approaches that address agent organisations [Zambonelli et al. 2001].

Strengths and Weaknesses. Although many concepts used in the BDI architecture canbe mapped to those in the SMC-based approach, the BDI reasoning cycle and the use ofthe goal abstraction make the two designs significantly different. We identified strengths(+) and weaknesses (-) of each of these approaches, which are summarised in Table 4.

One of the weaknesses of using the BDI-based approach is the difficulty in testingthe system (in fact, this is a challenge of multi-agent system development), because agentbehaviour depends on many different factors and it is hard to perform a limited number oftests to guarantee that the network will behave adequately in all scenarios. However, be-cause of the adoption of a logic-based language, it is possible to prove desired properties.This is left out of the scope of this paper.

AutoSoft

34

Open Issues. Based on an existing pattern for responding to a possible DDoS attack,we proposed a design solution based on BDI agents. Although it provided a flexible im-plementation of the proposed pattern, there are many issues left unaddressed. Firstly, asdiscussed above, guaranteeing safety is not trivial, because testing all possible scenariosis unfeasible. Secondly, the proposed solution should consider that malicious users maylearn how threats are contained, thus exploiting the resilience strategy for their own bene-fit. The proposed solution must be robust enough to prevent this. Finally, there should befurther investigation on how different resilience mechanisms would interact using a BDIagent approach. For example, if an agent concluded that there is a benign peak of networkusage (e.g., as in a flash crowd), actions to handle this should also be implemented.

5. Related WorkSeveral approaches use autonomous software components to provide network resilience.However, agent-based designs [Nguengang et al. 2006] only decompose a proposed so-lution into software components, each with a specified goal. Thus, they typically do notemploy any particular technique proposed in the context of autonomous agents and multi-agent systems.

Furthermore, a sentient object [Gregory et al. 2002] resembles an SMC in thatboth are intended to model a set of interacting hardware and software components,and provide an infrastructure to support large-scale distributed and networked sys-tems composed of autonomous components. However, sentient objects rely on staticrules, so they are less flexible than SMCs. Also, sentient objects follow a struc-ture that cannot be dynamically assembled using more general patterns of interac-tion [Schaeffer-Filho et al. 2012]. Netlets [Martin et al. 2011] and autonomic functionalblocks (AFBs) [Sifalakis et al. 2011] have been proposed with the aim of supporting newarchitectures for the Future Internet. Both are inspired by component-based software de-velopment approaches. They promote the composition of network protocols by usingbuilding blocks during design-time. Components are collected within a design repositoryfor further reuse. However, both Netlets and AFBs components are aimed at the specifi-cation of network stack protocol functionality and do not cater for the general federationand coordination of autonomous components operating in the network.

6. ConclusionIn this paper, we presented the first step towards an agent-based approach for networkresilience. It exploits the synergy between the network resilience and multi-agent systemresearch areas. Our approach involves the reengineering of a previously proposed patternusing Self-Mananged Cells (SMCs) to address distributed denial-of-service attacks usingagents following a BDI architecture and a logic-based language. The proposed designnot only specifies agent beliefs, goals, and plans, but also how beliefs are updated basedon perceived external events and how goals are generated. We showed how these BDIagent components are used to instantiate agents (or network devices) in a network, sothat such agents can collaborate to respond to attacks. Based on our design, we discussedlessons learned from it. Although there are many similar concepts between SMCs andBDI agents, BDI agents have a motivational state, which makes them pro-active (whileSMCs are reactive). Moreover, BDI agents are able to reason about what should be done,not only about how it should be done. These, and other discussed factors, make agent

AutoSoft

35

behaviour more flexible. This work has left many issues unaddressed, such as provingsafety properties of our solution, which will be addressed in future work.

ReferencesGregory, A. F., Biegel, G., Clarke, S., and Cahill, V. (2002). Towards a sentient object model. In In

Workshop on Engineering Context-Aware Object Oriented Systems and Environments (ECOOSE’2002).

IBM (2005). An architectural blueprint for autonomic computing. third edition. Technical report, IBM.

Jennings, N. R. (2001). An agent-based approach for building complex software systems. Commun. ACM,44(4):35–41.

Lupu, E., Dulay, N., Sloman, M., Sventek, J., Heeps, S., Strowes, S., Twidle, K., Keoh, S.-L., and Schaeffer-Filho, A. (2008). AMUSE: autonomic management of ubiquitous systems for e-health. Concurrencyand Computation: Practice and Experience, John Wiley, 20(3):277–295.

Martin, D., Volker, L., and Zitterbart, M. (2011). A flexible framework for future internet design, assess-ment, and operation. Computer Networks, 55(4):910–918.

Nguengang, G., Hugues, L., and Gaiti, D. (2006). A multi agent system approach for self resource reg-ulation in ip networks. In Proceedings of the First IFIP TC6 International Conference on AutonomicNetworking, AN’06, pages 64–75. Springer-Verlag.

Nguyen, T. and Armitage, G. (2008). A Survey of Techniques for Internet Traffic Classification usingMachine Learning. IEEE Communications Surveys & Tutorials, 10(4):56–76.

Rao, A. S. (1996). Agentspeak(l): Bdi agents speak out in a logical computable language. In Proceedings ofthe 7th European Workshop on Modelling Autonomous Agents in a Multi-agent World : Agents BreakingAway: Agents Breaking Away, MAAMAW ’96, pages 42–55. Springer-Verlag.

Rao, A. S. and Georgeff, M. P. (1995). BDI-agents: from theory to practice. In Proceedings of the FirstIntl. Conference on Multiagent Systems, San Francisco.

Schaeffer-Filho, A., Lupu, E., and Sloman, M. (2014). Federating policy-driven autonomous systems: Inter-action specification and management patterns (in press). Journal of Network and Systems Management.DOI: 10.1007/s10922-014-9317-5.

Schaeffer-Filho, A., Smith, P., Mauthe, A., Hutchison, D., Yu, Y., and Fry, M. (2012). A framework forthe design and evaluation of network resilience management. In Proceedings of the 13th IEEE/IFIPNetwork Operations and Management Symposium (NOMS 2012), pages 401–408, Maui, Hawaii, USA.IEEE Computer Society.

Sifalakis, M., Louca, A., Bouabene, G., Fry, M., Mauthe, A., and Hutchison, D. (2011). Functional com-position in future networks. Computer Networks, 55(4):987–998.

Sloman, M. and Lupu, E. (2002). Security and management policy specification. IEEE Network, 16(2):10–19.

Smith, P., Hutchison, D., Sterbenz, J., Scholler, M., Fessi, A., Karaliopoulos, M., Lac, C., and Plattner, B.(2011). Network resilience: a systematic approach. Communications Magazine, IEEE, 49(7):88–97.

Sterbenz, J. P. G., Hutchison, D., Cetinkaya, E. K., Jabbar, A., Rohrer, J. P., Scholler, M., and Smith,P. (2010). Resilience and survivability in communication networks: Strategies, principles, and surveyof disciplines. Computer Networks: Special Issue on Resilient and Survivable Networks (COMNET),54(8):1245–1265.

Zambonelli, F., Jennings, N. R., and Wooldridge, M. (2001). Organizational abstractions for the analy-sis and design of multi-agent system. In First International Workshop, AOSE 2000 on Agent-orientedSoftware Engineering, pages 235–251. Springer-Verlag.

AutoSoft

36

Abordagem baseada em Agentes para o Monitoramento eControle do Trabalho e Gestao Integrada de Mudancas

Necio L. Veras1, Mariela I. Cortes2,Anderson C. P. Queiroz 2, Leandro L. C. de Souza3

1Instituto Federal de Educacao, Ciencia e Tecnologia do Ceara (IFCE)Rodovia CE-075, s/n - Aeroporto – Tiangua - Ceara

2Universidade Estadual do Ceara (UECE) - Fortaleza, CE - Brasil

3Instituto Federal de Educacao do Maranhao (IFMA) - Imperatriz, MA – Brasil



Abstract. The activities of monitoring and control are crucial to regulate thework progress of the project in order to attend the goals defined in the mana-gement plan. However, changes are inevitable and may arise in some momentduring the development, influencing in the performance of the initial planningand impact in the project success. This paper presents an agent-based approachfor the monitoring and control of projects. The approach includes the supportfor automated management of changes so that provides an integrated and con-solidated vision of the project progress and to help managers in decision-makingduring the execution of the tasks.

Resumo. As atividades de monitoramento e controle sao cruciais para regular oprogresso dos trabalhos do projeto de forma a atender os objetivos definidos noplano de gerenciamento. Entretanto, mudancas sao inevitaveis e podem surgira qualquer momento durante o desenvolvimento influenciando na execucao doplano originalmente tracado e colocando em risco o sucesso do projeto. Esteartigo apresenta uma abordagem baseada na tecnologia de agentes inteligentespara o monitoramento e controle de projetos. A abordagem contempla o suportea gestao automatizada das solicitacoes de mudancas de forma a fornecer umavisao integradora e consistente do andamento do projeto e auxiliar gestores natomada de decisao durante a execucao dos trabalhos.

1. IntroducaoA construcao de software de computador e um empreendimento complexo, particular-mente quando envolve muitas pessoas trabalhando durante um perıodo de tempo relativa-mente longo. Em virtude disso uma forma de gerir essa complexidade esta na elaboracaode um planejamento efetivo dos diversos aspectos relacionados ao projeto, tais como: es-copo, custo e tempo, a partir do qual possa ser realizado o monitoramento e controle dasatividades de projeto [Sommerville et al. 2009].

Mudancas sao inevitaveis e a demanda pode surgir a qualquer momento[Sommerville et al. 2009], inclusive durante o desenvolvimento. Comumente, essas

AutoSoft

37

solicitacoes ocorrem devido a mudancas no negocio ou pela carencia de uma completaespecificacao dos requisitos. Esta situacao pode colocar em risco o plano de projetotracado na fase de planejamento e pode levar ao insucesso do projeto. Uma solicitacaode mudanca pode surgir tambem como uma solucao a desvios detectados entre o planeja-mento e a execucao, a partir da analise realizada durante o monitoramento dos trabalhosde projeto.

Neste cenario de desenvolvimento altamente dinamico fica evidente a dependenciaentre os processos de monitoramento e controle dos trabalhos, onde acoes de con-trole derivam normalmente em solicitacoes de mudancas [Pmbok 2008]. Por outrolado, mudancas aprovadas devem ser incorporadas na linha de base [Pmbok 2008], cujaatualizacao deve ser levada em conta no processo de monitoramento. Em geral, as ati-vidades de monitorar e controlar custo, prazo e mudancas demandam um grande volumede informacoes e a utilizacao de ferramentas de suporte se torna indispensavel. Assim, oefetivo controle para o sucesso de projetos requer de metodos e tecnicas que possibilitemo acompanhamento e analise contınuo dos trabalhos do projeto de forma integrada e proa-tiva monitorando os diversos fatores que podem influenciar no cumprimento dos objetivosdo projeto, assim como tambem auxiliar gestores na tomada de decisao. O presente tra-balho propoe uma abordagem proativa e automatizada, baseada na uniao e atuacao de tresagentes inteligentes, para dar apoio ao processo de monitoramento e controle das ativida-des do projeto em relacao a tempo e custo de forma integrada com a gestao de mudancas.

Para tanto, o artigo esta estruturado como segue. A Secao 2 apresenta o referen-cial teorico fornecendo um overview sobre os processos de monitoramento e controle dodesempenho e o controle de mudancas. A Secao 3 discute os trabalhos relacionados. Aabordagem proposta para o suporte proativo destes processos e a descricao dos agentesenvolvidos na solucao e apresentada na Secao 4. A Secao 5 ilustra um estudo de casoonde uma simulacao com dois cenarios e apresentada. Por ultimo, conclusoes e trabalhosfuturos sao descritos na Secao 6.

2. Referencial Teorico

2.1. Processo de Monitoramento e Controle

Os processos de monitoramento e controle sao responsaveis por acompanhar, revisare regular o progresso e o desempenho do projeto, identificar todas as areas nas quaisserao necessarias mudancas no plano de execucao do projeto e recomendar sua aplicacao[Pmbok 2008]. O desempenho do projeto deve ser monitorado e medido regularmentee desvios sao ajustados evitando que os objetivos do projeto sejam colocados em risco[Possi and Borges 2006]. O trabalho do projeto e monitorado e controlado a partir doacompanhamento das areas-chave: escopo, custo e tempo.

O monitoramento consiste em uma analise contınua da aderencia do projeto aosplanos, realizada em intervalos predeterminados e um projeto e mantido sob controlea partir da determinacao de acoes corretivas ou preventivas, ou o replanejamento comobjetivo de resolver questoes de desempenho em relacao aos eventuais desvios detectados[Abran and Bourque 2004].

O guia PMBoK sugere algumas tecnicas e metodos para monitorar e controlar asatividades do projeto, entre elas: a Tecnica do Valor Agregado (TVA) e o Metodo do

AutoSoft

38

Caminho Crıtico (CPM). A TVA e uma tecnica de gerenciamento utilizada, que com-para as informacoes planejadas (linhas de base) e realizadas de escopo, custo e tempopara medir o desempenho das atividades do projeto e, a partir dos indicadores obtidos,estabelecer uma tendencia ate seu termino [Institute 2005]. O metodo do caminho crıtico[Partovi and Burton 1993] e utilizado para determinar o caminho da rede de atividades in-terligadas onde o tempo mais longo e o tempo total operacional que determina a duracaodo projeto.

2.2. Processo de Realizar o Controle Integrado de Mudancas

A ocorrencia de mudancas durante a execucao do trabalho em relacao ao que foi plane-jado para o projeto e bastante comum e esperada [Pmbok 2008]. Normalmente mudancasestao diretamente relacionadas aos aspectos de escopo, cronograma e custo estabeleci-dos na etapa do planejamento do projeto. Grande parte das mudancas e oriunda de fatoresexternos, entretanto erros de dimensionamento na especificacao do escopo original nas es-timativas de orcamentacao e de prazos de realizacao, somados a avaliacao objetiva de quedeterminada mudanca podera agregar valor ao produto, tambem podem gerar mudancas[Possi and Borges 2006].

Neste contexto, um dos fatores crıticos para o sucesso dos projetos e umaconducao estruturada do processo de solicitacao das mudancas, onde a utilizacao de umprocedimento formal previamente definido e documentado e uma importante ferramentade controle. A necessidade de mudancas pode ser identificada por qualquer parte interes-sada envolvida no projeto, as quais devem ser registradas, descrevendo o tipo da mudancae os impactos causados, caso seja aprovada. Vale ressaltar que as mudancas requeremrevisoes nos documentos gerados no planejamento do projeto, caso haja aprovacao damudanca [Pmbok 2008].

3. Trabalhos Relacionados

Varios trabalhos propoem o uso de agentes inteligentes para o gerenciamento de diferen-tes aspectos no desenvolvimento de projetos. Nesta secao sao apresentados trabalhos depesquisa que utilizam agentes como abordagem para gerenciar o monitoramento e con-trole do andamento de projetos.

Em [Chang and Sethi 2009] e apresentada a ferramenta Software Project Associ-ate (SPA), que consiste em um sistema multiagente baseado em metricas do projeto, taiscomo produtividade e esforco. O objetivo da ferramenta e acompanhar o andamento doprojeto de software para garantir a conformidade com o planejamento de metas para arealizacao das atividades, alertando gerentes quando nao sao atingidas, porem nenhumasolucao para a correcao dos desvios e sugerida pela ferramenta.

O modelo Software Project Management supported by Software Agents (SPMSA)[Nienaber 2008] consiste em um framework generico, baseado em agentes de software,projetado para suportar varios aspectos do gerenciamento do projeto de software emum ambiente distribuıdo. O SPMSA preve na sua estrutura um agente de monitora-mento, porem se limita no acompanhamento de tarefas e fases do projeto, sem levar emconsideracao o aspecto de custo. E previsto a notificacao dos stakeholders, no entantonenhum tipo de correcao de desvios em relacao a linha de base do projeto e apresentada.

AutoSoft

39

Por ultimo, o Parametric Project Monitoring and Control (PPMC) con-siste de um modelo de estimativa proprietario fundamentado na tecnica do GVA[Galorath and Galorath 2006], cujo objetivo e estender o escopo da estimativa de projetosde desenvolvimento de software estabelecendo uma iteracao na conducao das atividadesde gerenciamento. Esse modelo trabalha apenas com acoes preventivas e com isso, naogarante que todos os desvios possam ser inibidos. Cabe ressaltar que nenhuma das fer-ramentas de gestao citadas contempla na sua solucao aspectos relacionados a gestao demudancas, o que pode levar a uma analise incompleta e parcial do andamento do projetodurante a sua evolucao.

O presente trabalho diferencia-se dos demais pois consegue, por meio de umaabordagem baseada na uniao e atuacao de tres agentes, auxiliar no monitoramento e con-trole das atividades do projeto em relacao a custo e tempo, sugerindo acoes preventi-vas e/ou corretivas durante a deteccao de desvios na linha de base gerada no planeja-mento. Adicionalmente, a abordagem contempla mecanismos para a gestao integradade mudancas onde e possıvel prever impactos na linha de base no momento de umasolicitacao de mudancas e, com isso, emitir alertas ao gerente.

4. Abordagem Proposta

A abordagem proposta objetiva apoiar o gerente no processo de monitoramento e con-trole contınuo das atividades de projeto de forma integrada com a gestao das mudancas.A solucao e baseada na tecnologia de agentes, prevendo, observando e mensurando o tra-balho do projeto de forma a sugerir solucoes ao gerente. As solucoes propostas podemauxiliar o gerente no processo de tomada de decisao em relacao as mudancas requeri-das para o controle do projeto. A solucao envolve a uniao de tres agentes inteligentescapazes de colaborarem entre si e com o gerente do projeto usando ambientes compar-tilhados baseados em artefatos [Ricci et al. 2009]. A Figura 1 visa ilustrar a interacaoentre os agentes e o gerente de projeto e, para tanto, usou-se uma notacao livre que mos-tra as direcoes e os contextos das trocas de mensagens entre os elementos envolvidos naproposta.

Figura 1. Interacao entre os agentes envolvidos e o gerente.

Os agentes detectam alteracoes no ambiente de projeto no qual estao inseridos,raciocinam sobre essas alteracoes e agem de forma proativa, selecionando uma acao queenvia uma mensagem de alerta ou sugere acoes de forma a reduzir os efeitos negativosde possıveis desvios detectados [Jennings 2000] (relativos a custo e tempo) durante a

AutoSoft

40

execucao de um projeto. A partir da avaliacao do gerente, uma acao sugerida pode se tor-nar uma solicitacao de mudanca, cuja evolucao ao longo do tempo em relacao ao impactoda mesma sera atualizado e monitorado pelo agente responsavel.

O compartilhamento e troca de informacoes entre os agentes e o gerente consistede uma atividade dinamica e constante que envolve as (i) informacoes relativas ao pla-nejamento inicial e trabalho efetivamente realizado, cedidas pelo gerente de projeto, (ii)analise da situacao corrente em relacao a desejada, diagnosticada pelo agente monitor, (iii)informacoes de solicitacoes de mudancas registradas pelo gerente e demais interessadosno projeto, (iv) analise da situacao das solicitacoes de mudanca pelo agente de mudanca,e (v) o tratamento de desvios, realizado pelo agente de controle (ACon).

4.1. O Agente de Mudancas (AMud)

O agente AMud [Mascarenhas et al. 2014] e o responsavel pelo monitoramento dassolicitacoes de mudancas registradas no ambiente de solicitacao de mudancas, determi-nando e monitorando a prioridade (calculada atraves da tecnica de matriz GUT - gravi-dade, urgencia e tendencia - [Baldissera and Nunes 2006]) da mudanca no projeto. Naabordagem proposta, a gravidade representa o impacto da mudanca referente ao custo(IC) e ao tempo (IT). A urgencia (U) representa o tempo disponıvel para a implantacaoda mudanca. A prioridade e obtida atraves da relacao entre estas tres variaveis associadasa mudanca, sendo representada pela formula: Prioridade(P ) = IC × IT × U . A par-tir da avaliacao da prioridade da mudanca solicitada o agente informa o gerente sobre aviabilidade da incorporacao da mudanca nos trabalhos do projeto.

Para tanto, o AMud foi projetado como um agente reativo simples com estadointerno cujas regras de condicao-acao determinam o estado no qual o agente ira emitiravisos aos interessados no projeto. A Tabela 1 descreve as informacoes sobre o funcio-namento do agente. Mais detalhes sobre os indicadores usados e a concepcao do agentepodem ser percebidos em [Mascarenhas et al. 2014].

4.2. O Agente de Monitoramento (AMon)

O funcionamento do agente AMon [Souza et al. 2013] pressupoe a existencia de um planoinicial. Em sua estrutura, a funcao ver representa os sensores do agente que percebe asinformacoes a respeito dos valores das variaveis associadas as atividades do projeto emapeia estas informacoes em sextupla (T, duracaoAtividade, custoAtividade, planejada-Completa, realCompleta, custoRealAtiv).

O agente tambem mantem internamente informacoes relacionadas com a evolucaodo ambiente e das atividades do projeto, denominado estado interno. Esse estado e igual-mente representado pela sextupla (VP, VA, IDP, VDP, IDC, VC), cujos valores identificamou nao uma insatisfacao entre o estado corrente de uma atividade em andamento no pro-jeto e seu estado desejado, com base no GVA. VP representa o valor planejado, VA o valoragregado, IDP o ındice de desempenho de prazo, VDP a variacao de prazo, IDC o ındicede desempenho de custo e VC a variacao de custo. Os valores dessas variaveis compoemas informacoes correntes no estado interno e permitem que a funcao acao do agente deter-mine a situacao real do trabalho do projeto quanto ao orcamento e cronograma. Para isso,sao incorporados um conjunto de regras condicao-acao implementadas para determinar oquao a frente ou atras do cronograma e/ou orcamento o projeto se encontra. A partir dos

AutoSoft

41

Tabela 1. Estado interno, Acoes e Percepcoes do AMud.

Estado Interno AMud impacto no tempo (IT), impacto no custo (IC), urgencia (U)

e prioridade (P) da mudanca

Percepcoes do Ambiente de Projetos projeto (P), instante (K) e atividades(A)

Acoes AMud 1. se (IC = 5) entao

(regras condicao-acao) faca (mensagem(‘Impacto no custo e muito alto.

Procure o Sponsor do projeto para negociar os custos’))

2. se (IC = 4) entao

faca (mensagem(‘Impacto no custo e alto.

Procure o Sponsor do projeto para negociar os custos’))

3. se (IT = 5) entao

faca (mensagem(‘Impacto no tempo e muito alto.

Verique a possibilidade de paralelizar atividades’))

4. se (IT = 4) entao

faca (mensagem(‘Impacto no tempo e alto.

Verique a possibilidade de paralelizar atividades’))

5. se (U = 5) entao

faca (mensagem(‘A urgencia da mudanca e muito alta,

em breve se tornara obsoleta.’))

6. se (U = 4) entao

faca (mensagem(‘A urgencia da mudanca e alta,

em breve se tornara obsoleta.’))

Percepcoes do Ambiente tipo de mudanca

de Solicitacao de Mudancas (acrescimo/decrescimo no custo ou tempo),

atividade, valor da alteracao e estado da solicitacao

(solicitada, aprovada ou rejeitada)

indicadores obtidos, o AMon alerta o gerente sobre a situacao atual do projeto quanto aocronograma, orcamento, e eventuais desvios detectados.

O mecanismo de selecao de acao do AMon foi concebido para indicar comosolucao do problema de monitoramento em uma determinada interacao. Assim, todasas mensagens sao oriundas das regras cujos antecedentes descrevem condicoes avalia-das em cada interacao que o agente mantem com o ambiente de projeto. Na Tabela 2 epossıvel visualizar as informacoes relacionadas associadas ao AMon.

4.3. O Agente de Controle (ACon)

A partir das informacoes advindas do AMon, o ACon [Souza et al. 2014] reage de acordocom o grau de variacao entre o planejamento e o desempenho, sugerindo acoes correti-vas/preventivas para minimizar o efeito dos desvios detectados. O agente ACon consideraem seu funcionamento um plano inicial a partir do qual sao identificados alguns atributosdas atividades: identificacao (idAtividade), duracao (duracaoAtividade) e o custo (custo-Atividade), atividades predecessoras e sucessoras, mantendo em seu estado interno todo odiagrama de rede de atividades e o caminho crıtico [Souza 2013]. A medida que novas es-timativas sao geradas um novo caminho crıtico e calculado e seu estado interno atualizadocom base nos tempos das atividades contempladas no plano inicial.

AutoSoft

42

Tabela 2. Estado interno, Acoes e Percepcoes do AMon.

Estado Interno AMon VP, VA, IDP, VDP, IDC, VC

Acoes AMon 1. se (IDP = 1.0) entao

(regras condicao-acao) faca (mensagem(‘Atividade esta dentro do cronograma’))

senao se (IDP > 1) entao faca

(mensagem (‘Atividade esta adiantada do cronograma’))

senao faca (mensagem (‘Atividade esta atrasada no cronograma’))

2. se (V DP = 0.0) entao

faca (mensagem(‘Atividade esta dentro do cronograma’))

senao se (V DP > 0) entao faca

(mensagem (‘Atividade esta VDP reais a frente do cronograma’))

senao faca (mensagem (‘Atividade esta VDP reais atras do cronograma’))

3. se (IDC = 1.0) entao

faca (mensagem(‘Atividade esta dentro do orcamento’))

senao se (IDC > 1) entao faca

(mensagem (‘Atividade esta abaixo do orcamento’))

senao faca (mensagem (‘Atividade esta acima do orcamento’))

4. se (V C = 0.0) entao

faca (mensagem(‘Atividade esta dentro do orcamento’))

senao se (V C > 0) entao faca

(mensagem (‘Atividade esta VC reais abaixo do orcamento’))

senao faca (mensagem (‘Atividade esta VC reais acima do orcamento’))

Percepcoes do Ambiente idAtividade, duracaoAtividade, custoAtividade,

Tes, Tef, Tlf, Tls, R e

atividades predecessoras e sucessoras da atividade corrente

O estado interno contem dados sobre as atividades do projeto com base naformulacao do valor agregado. O agente armazena: ETcusto (representa a estimativa notermino relacionado a custo), EPTcusto (a estimativa para terminar relacionado a custo),VAFcusto (a variacao do custo na conclusao da atividade), PercVAFcusto (o percentualdessa variacao), IDPT (o ındice de desempenho para terminar a atividade), ETtempo (aestimativa no termino relacionado a tempo), EPTtempo (a estimativa para terminar relaci-onado a tempo), VAFtempo (a variacao ao final da atividade) e PercVAFtempo (o percen-tual dessa variacao) [Souza et al. 2014]. Estes valores permitem ao agente estimar custoe tempo ao final do desenvolvimento das atividades considerando o desempenho atual,alem de informar a variacao ao termino das atividades em relacao as novas estimativas.

O agente considera as atividades em andamento e as alternativas para o tratamentode desvios negativos detectados e, dentre as alternativas descritas em [Souza 2013], tem-se: compressao (hora-extra), paralelizacao, compensacao de orcamento em cronograma,compensacao de custo entre atividades e compensacao de tempo entre atividades. A Ta-bela 3 mostra os elementos usados pelo agente para a selecao de suas acoes.

O subconjunto das acoes do agente de (1) a (4) contem regras cujas condicoesno antecedente sao estabelecidas considerando apenas as informacoes correntes so-bre a execucao de atividades individuais, enquanto que as acoes determinam as

AutoSoft

43

Tabela 3. Estado interno, Acoes e Percepcoes do ACon.

Estado Interno ACon ETcusto, EPTcusto, VAFcusto, PercVAFcusto, IDPT,ETtempo, EPTtempo, VAFtempo, PercVAFtempo

Acoes ACon 1. se (IDP > 1.0 && V DP > 0.0

(regras condicao-acao) && IDC < 1.0 && V C < 0.0) entao faca Acao 01

2. se (IDP < 1.0 && V DP < 0.0 &&

IDC > 1.0 && V C > 0.0) entao faca Acao 02

3. se (IDP < 1.0 && V DP < 0.0 &&

IDC < 1.0 && V C < 0.0) entao faca Acao 03

4. se (IDP = 1.0 && V DP = 0.0 &&

IDC < 1.0 && V C < 0.0) entao faca Acao 04

5. se (V AFcustoProjeto > 0 &&

V AFtempoProjeto < 0) entao faca Acao 05

6. se (V AFcustoProjeto < 0 &&

V AFtempoProjeto > 0) entao faca Acao 06




V AFtempoProjeto = 0) entao faca Acao 08

9. se (V AFcustoProjeto = 0 &&


Percepcoes do Ambiente idAtividade, duracaoAtividade, custoAtividade,

Tes, Tef, Tlf, Tls, R e

atividades predecessoras e sucessoras da atividade corrente

correcoes/prevencoes propostas para atividades individuais e os efeitos destas acoes, ob-tidos a partir de simulacoes realizadas pelo agente no estado interno. A condicao naprimeira regra, por exemplo, permite detectar situacoes do tipo: adiantada no cronogramae acima do orcamento na execucao de uma atividade. Neste caso, e sugerido como acaopreventiva aumentar o desempenho em um valor X para concluir dentro do orcamentoprevisto para a atividade. Como acao corretiva, sugere-se uma compensacao de custosentre as duas atividades sucessoras (fora do caminho crıtico) com maior folga. A partirda correcao desse desvio, novas estimativas de custos sao calculadas pelo ACon.

Ja no subconjunto de (5) a (9) as condicoes nas regras consideram as informacoesde todas as atividades em execucao. Este novo subconjunto de regras condicao-acaoconsidera a correcao e prevencao de desvios quando tratados sobre todas as atividadescorrentes em execucao. A condicao na regra (6), por exemplo, permite detectar situacoesem que ocorrem desvios negativos de recursos (orcamento, por exemplo) e um atraso notempo total do projeto [Souza 2013].

5. Experimentos a partir da integracao dos agentes AMud, AMon e AConOs ambientes de execucao dos agentes utilizados no presente trabalho objetivam simularum ambiente real de projeto. O artefato Ambiente de Projetos contempla um projetocujas atividades possuem as mesmas configuracoes existentes em [Souza et al. 2014]. Jao Ambiente de Solicitacao de Mudancas (ambos na Figura 1), visa imitar um mecanismo

AutoSoft

44

de registro de solicitacoes para mudancas relacionadas as atividades do projeto, tais como,acrescimo/decrescimo no custo ou no tempo, como em [Mascarenhas et al. 2014].

Para a realizacao da simulacao foi criado um agente adicional que assume a funcaodo Gerente. O agente Gerente recebe mensagens oriundas dos tres agentes da abordageme, entre elas, alertas e sugestoes para aplicar correcoes mediante a deteccao de desviosna linha de base. Os agentes foram desenvolvidos em AgentSpeak (linguagem projetadae inspirada para programacao de agentes com arquitetura BDI), mais especificamente,em uma versao estendida da linguagem AgentSpeak, que fornece recursos para o de-senvolvimento de sistemas multiagentes, chamada Jason [Bordini and Hubner 2005]. Osambientes foram criados usando a tecnologia Cartago (Common ARtifact infrastructurefor AGent Open environments) [Ricci et al. 2009], um framework e infraestrutura paraprogramacao e execucao de ambientes baseados em artefatos. A partir das configuracoesambientais e do agente Gerente fez-se um recorte nos cenarios simulados e nos resultadoselencados, os quais seguem nos subtopicos seguintes.

5.1. Cenario I: Mudancas e eventos em atividades separadasNeste cenario, o modelo de evolucao do Ambiente de Projetos foi programado para evo-luir idealmente ate o quarto momento. Entre o quinto e o setimo momento a atividade“A” e acelerada para que seja possıvel terminar antes do prazo planejado (adiantado nocronograma), no entanto, consumindo mais recursos do que havia sido estabelecido noplanejamento (acima do orcamento). Ao final do setimo momento, a atividade e finali-zada com uma economia de tempo de tres momentos, mas com um acrescimo de setentaunidades de moeda no custo estimado. Apos isso, o ambiente volta a evoluir idealmente.

Figura 2. Recorte dos logs dos agentes AMon e ACon no Cenario I.Em um intervalo de momentos distintos, especificamente entre os instantes trinta

AutoSoft

45

e oito e quarenta e cinco, a atividade ”E”sofre um atraso em sua execucao de maneiraa terminar apos o planejado (atrasado no cronograma), no entanto, consumindo menosrecursos do que o planejado (abaixo do orcamento). Dessa forma, a atividade finalizano momento cinquenta e um, configurando um atraso de oito unidades de tempo, poremcom uma economia de aproximadamente cem unidades de moeda. A Figura 2 mostra osmomentos finais da atividade “E” contido nos logs dos agentes AMon e ACon.

Ainda no mesmo cenario, o agente Gerente registra as solicitacoes de mudancasenviadas pelo ACon no Ambiente de Solicitacao de Mudancas. Para efeitos de simulacao,o agente Gerente solicita as mudancas sugeridas pelo ACon por meio das acoes corretivas,pois com elas o Gerente pode controlar o plano inicial do projeto. O agente AMud percebeas novas solicitacoes, calcula os impactos em relacao ao custo e tempo e informa o gerentesobre a urgencia da mudanca e sua prioridade ao longo da evolucao do projeto. Na Figura3 e possıvel perceber as solicitacoes do agente Gerente no instante cinquenta e as acoesdo agente AMud nos momentos seguintes ate que as solicitacoes tornem-se obsoletas.

Figura 3. Solicitacoes do Gerente e mensagens enviadas pelo AMud.

Figura 4. Recorte nos conteudos dos logs de AMon e ACon no sexto momento.

AutoSoft

46

5.2. Cenario II: Mudancas e eventos em atividades conjuntasNo cenario atual, o modelo de evolucao do Ambiente de Projetos tambem foi programadopara evoluir idealmente ate o quarto momento, no entanto, o cenario provocara eventosinesperados em diferentes atividades para momentos coincidentes. Entre o quinto e osetimo momento, a atividade “A” e acelerada para que seja possıvel terminar antes doprazo planejado (adiantado no cronograma), entretanto, consumindo mais recursos doque havia sido almejado (acima do orcamento). Assim como no Cenario I, ao final dosetimo momento, a atividade e finalizada com uma economia de tempo de tres momentos,mas com um acrescimo de setenta unidades de moeda no custo estimado.

Entre o setimo e o decimo quinto momento, a atividade “B” e programada paraconsumir menos recursos do que o planejado (abaixo do orcamento), entretanto, sofrendoum atraso em sua execucao (atrasado no cronograma), finalizando apenas no momentodezoito. A situacao configura um atraso de nove unidades de tempo, porem com umaeconomia de aproximadamente trinta e oito unidades de moeda. Logo em seguida, oambiente volta a evoluir normalmente. A Figura 4 mostra o momento em que ocorremeventos paralelos nas atividades “A” e “B” por meio de um recorte no conteudo dos logsdos agentes AMon e ACon, exatamente no instante seis do projeto.6. Consideracoes finaisA atividade de monitoramento e controle do trabalho e crıtica para o sucesso do projeto.No entanto, o grande volume de informacoes envolvidas em um ambiente dinamico eem constante mudanca, onde as interacoes entre os processos participantes nem sempresao visıveis, tornam as atividades altamente complexas. No presente artigo foi apresen-tada uma abordagem que une tres agentes inteligentes capazes de automatizar o moni-toramento e controle de diversos aspectos do projeto de forma integrada com a gestaode mudancas com base em [Pmbok 2008]. Esta abordagem permite, de forma conti-nua e proativa: (a) monitorar o desempenho dos trabalhos e detectar eventuais desvios(AMon), a partir dos quais acoes preventivas e corretivas sao sugeridas com base naanalise da situacao corrente e na geracao de novas estimativas (ACon), (b) monitoraras solicitacoes de mudanca requisitadas e atualizar a evolucao do seu estado no decorrerdo tempo (AMud), possibilitando a manutencao das linhas de base do projeto consisten-tes, (c) manter o gerente informado do andamento dos trabalhos (AMon) e do estado dassolicitacoes de mudanca registradas (AMud).

Os resultados nas simulacoes mostram a capacidade da abordagem em oferecersugestoes as partes interessadas do projeto sobre acoes que podem ser tomadas para umcontrole mais efetivo do projeto. Sugere-se ainda como trabalhos futuros: (i) aprimo-ramento das regras nos agentes de forma a atender um numero maior de situacoes; (ii)incorporacao nas regras do agente de controle de aspectos relacionados a margem de erro,ja que desvios pouco aparentes estao sendo tratados de maneira geral; e (iii) inclusao decontrole de influencia de fatores geradores de mudancas, abordando principalmente o ge-renciamento de riscos. Vale comunicar que os resultados gerados durante as execucoesdos agentes apresentados neste trabalho estao disponıveis e podem ser acessados peloendereco: http://186.225.40.148/professor/necio/project monitoring logs/.ReferenciasAbran, A. and Bourque, P. (2004). SWEBOK: Guide to the software engineering Body of

Knowledge. IEEE Computer Society.

AutoSoft

47

Baldissera, T. A. and Nunes, R. C. (2006). Impacto na implementacao da norma nbriso/iec 17799 para a gestao da seguranca da informacao em colegios: um estudo decaso. ENCONTRO NACIONAL DE ENGENHARIA DA PRODUCAO, 27.

Bordini, R. H. and Hubner, J. F. (2005). A java-based agentspeak interpreter used withsaci for multi-agent distribution over the net. in http://jason.sourceforge.net.

Chang, C. W. W. and Sethi, I. (2009). A metric-based multi-agent system for softwareproject management. In Eigth IEEE/ACIS International Conference on Computer andInformation Science.

Galorath, D. D. and Galorath, J. (2006). Achieving software development success-usingbest practice planning, estimation, tracking and control. In proceedings of the Proc.Software Measurement European Forum.

Institute, P. M. (2005). Practice standart for earned value management. USA: ProjectManagement Institute, Inc.

Jennings, N. R. (2000). On agent-based software engineering. Elsevier.

Mascarenhas, E. R., Veras, N. L., Souza, L. L. C., and Cortes, M. I. (2014). Abordagembaseada em um agente para apoio a gestao integrada de mudancas em projetos. InAnais do X Simposio Brasileiro de Sistemas de Informacao (SBSI).

Nienaber, R. C. (2008). A model for enhancing software project management using soft-ware agent technology. PhD thesis, University of South Africa.

Partovi, F. Y. and Burton, J. (1993). Timing of monitoring and control of cpm projects.Engineering Management, IEEE Transactions on, 40(1):68–75.

Pmbok, P. M. I. (2008). A guide to the project management body of knowledge: Pmbok R©guide. Project Management Institute.

Possi, M. and Borges, E. (2006). Gerenciamento de projetos: Guia do profissional, abor-dagem geral e definicao de escopo. Rio de Janeiro, RJ: Ecthos/CREA/RJ, 1.

Ricci, A., Piunti, M., Viroli, M., and Omicini, A. (2009). Environment programming incartago. In Multi-Agent Programming:, pages 259–288. Springer.

Sommerville, I., Melnikoff, S. S. S., Arakaki, R., and de Andrade Barbosa, E. (2009).Engenharia de software. Addison Wesley Sao Paulo.

Souza, L. L. C. (2013). Suporte ao monitoramento e controle de processos de software– uma abordagem inteligente com base na teoria do valor agregado. Master’s thesis,Mestrado Academico em Ciencia da Computacao (MACC), Universidade Estadual doCeara.

Souza, L. L. C., Campos, G. A. L., Cortes, M. I., and Queiroz, A. C. P. (2013). Auxiliandonas decisoes gerenciais de projetos de software com agentes inteligentes. In Anais doXII Simposio Brasileiro de Qualidade de Software (SBQS).

Souza, L. L. C., Queiroz, A. C. P., Campos, G. A. L., Cortes, M. I., Veras, N. L.,Goncalvez, E. J. T., and Oliveira, M. A. (2014). Controle inteligente no desenvol-vimento de projetos de software. In Anais do X Simposio Brasileiro de Sistemas deInformacao (SBSI).

AutoSoft

48

UMA ABORDAGEM PARA O TRATAMENTO

RACIONAL DE NORMAS DE OBRIGAÇÃO EM

AMBIENTES DE TAREFAS NORMATIVOS

Pedro I. F. Aragão, Gustavo A. L. de Campos, Mariela I. Cortés,

Francisco I. S. Cruz

Departamento de Computação – Universidade Estadual do Ceará (UECE)

Av. Dr. Silas Munguba, 1700 – 60740-000 – Fortaleza – CE – Brasil

{gustavo, mariela}@larces.uece.br, {aragao.pedro.ivo,

israel.santos.cr}@gmail.com

Abstract: When dealing with simple reactive agents in the presence of norms,

we may incur in obligation norms that make the agent perform unnecessary and

irrational actions in their task environment. Considering environments with

limited resources, improve the agent performance is critical. This article

proposes an approach to the appropriate treatment of obligation norms in order

to avoid the performing of unnecessary and irrational actions.

Resumo: Quando tratamos de organizações de agentes reativos simples na

presença de normas, podemos incorrer em normas que obriguem o agente a

executar ações desnecessárias e irracionais em seu ambiente de tarefa.

Considerando ambientes com recursos escassos, é importante que o

desempenho de cada agente seja otimizado. O presente artigo propõe uma

abordagem para o tratamento adequado de normas que obrigam agentes

reativos simples normativos a executar ações desnecessárias e irracionais.

1. INTRODUÇÃO

Um agente é uma entidade capaz de perceber o ambiente através de sensores e agir

nesse ambiente por meio de atuadores [Russell e; Norvig, 2004]. Os agentes podem ser

classificados a partir das características de sua arquitetura interna como, por exemplo, a

capacidade de armazenar o histórico de ações e de adquirir conhecimento. Um sistema

multiagente (SMA) consiste de um conjunto de agentes cooperando ou disputando entre

si, inseridos em um mesmo ambiente. Abordagens orientadas a agentes estão se

tornando frequentes no desenvolvimento de sistemas de diversos tipos [Silva, 2003]. Os

sistemas multiagente normativos caracterizam-se pela inserção de proposições

normativas envolvendo os conceitos deônticos de obrigação, proibição e permissão,

para restringir as ações dos agentes [Figueiredo; Silva, 2010].

Em sistemas multiagentes normativos, organizações de diversos tipos regulam o

comportamento autônomo dos agentes participantes definindo conjuntos de normas para

serem cumpridas pelos agentes. Estas normas restringem e orientam o comportamento

dos agentes para a realização de objetivos não triviais de uma organização em

ambientes de tarefas complexos. Em geral, os agentes autônomos percebem as normas

enviadas pela organização e decidem por cumprir umas e violar outras, conforme seus

AutoSoft

49

objetivos no ambiente, que podem não ser os mesmos que os da organização [Modgil et

al., 2009]. Por sua vez, dependendo de como foi concebido, o sistema de normas

vigente na organização pode restringir algumas violações e/ou conceber mecanismos de

regulação adequados.

Visando alcançar objetivos estratégicos, uma organização de agentes racionais

deve ser capaz de conceber mecanismos de regulação que sejam adequados a

penalizar/recompensar aqueles agentes que violarem/cumprirem as normas, naqueles

momentos de interação em que ocorre a unificação das condições no ambiente de

tarefas com as condições de ativação das normas vigentes na organização. No nível de

agente individual, foram propostas adaptações nos processos decisórios dos agentes

racionais visando adequar os mesmos para a realização de tarefas na presença de

normas. Campos et al. (2012) desenvolveram uma abordagem para o caso dos agentes

reativos simples baseados em regras condição-ação. A abordagem consiste em um

primeiro refinamento na estrutura do programa de agente reativo simples [Russell e;

Norvig, 2004], adaptando-o a perceber e raciocinar com normas enviadas pela

organização em tempo de execução de tarefas em ambientes dinâmicos.

O programa de agente reativo simples refinado apresentou o desempenho

esperado na maioria dos testes realizados, pois foi capaz de perceber normas em seu

ambiente de tarefa, de reconhecer e raciocinar adequadamente com os conceitos

deônticos, e de selecionar as ações que cumpriram com as normas vigentes e que

obtiveram desempenho racional, conforme uma medida de avaliação pré-estabelecida.

Entretanto, percebeu-se que o bom desempenho dos agentes é influenciado pela

definição de um conjunto de normas adequadas, principalmente quando obrigados a

executar ações sob determinadas condições ambientais, os agentes podem executar

ações desnecessárias e irracionais, consumindo recursos disponíveis para os agentes e,

consequentemente, prejudicando o desempenho do agente na organização.

Considerando esta motivação, este artigo descreve um novo refinamento na estrutura do

programa de agente reativo simples visando capacitá-lo à seleção de ações racionais em

ambientes de tarefas dinâmicos regidos por normas.

A abordagem proposta envolve a definição, na organização, de um esquema

automático de transformação entre os conceitos deônticos, fundamentado em um

conjunto de equivalências e implicações lógicas entre proposições. Os primeiros

resultados de um estudo comparativo, envolvendo agentes programados de acordo com

o primeiro e o segundo refinamento, mostraram que a abordagem é factível e melhora o

desempenho dos agentes.

O artigo foi estruturado em seis sessões. A Seção 2 apresenta o agente reativo

simples normativo simples. A Seção 3 aborda o problema das ações obrigatórias

desnecessárias e a formação das normas. Na Seção 4 é apresentada a solução proposta

para o problema. A Seção 5 apresenta, através de um caso de estudo, como a solução

proposta neste artigo pode ser utilizada. Finalmente, a Seção 6 apresenta as conclusões,

limitações e trabalhos futuros.

AutoSoft

50

2. O AGENTE REATIVO SIMPLES NORMATIVO

Em ambientes observáveis, o desempenho do agente reativo simples baseado em regras

condição-ação costuma ser satisfatório, dependendo do conjunto de regras condição-

ação ser suficiente para a seleção de ações racionais. Em ambientes dinâmicos, estes

agentes costumam responder mais rapidamente às mudanças nas condições do ambiente

de tarefa que outros tipos de agente, por exemplo, aqueles agentes programados de

acordo com as estruturas dos programas reativos com estado interno, e orientação por

objetivo e utilidade. Influenciado pelo trabalho do Meneguzzi et al. (2009) que propôs

adaptações na arquitetura BDI, habilitando o agente a reconhecer normas, Campos et al.

(2012) propuseram um refinamento na estrutura do programa de agente reativo simples

descrito por Russell e Norvig (2004), visando capacitar o programa a reconhecer

normas enviadas por uma organização em tempo de execução de tarefas em um

ambiente dinâmico, a raciocinar com as mesmas, e a selecionar ações permitidas, ou

seja, que cumpram com as normas enviadas, e sejam racionais.

Para evitar que o agente reativo simples normativo viole as normas definidas

pela organização, Campos et al. (2012) propuseram a adição de subconjuntos de regras

condição-ação no conjunto de regras condição-ação que define as ações que são

possíveis para um agente reativo. Desta forma foram definidos três diferentes grupos de

regras condição-ação associados aos conceitos deônticos:

Grupo de Obrigação: composto de regras relacionadas com as ações que

devem ser executadas pelo agente.

Grupo de Proibição: composto de regras relacionadas com as ações que

não podem ser executadas pelo agente.

Grupo de Permissão: especifica as regras relacionadas com as ações

possíveis que podem ser executadas pelo agente.

A Figura 1 apresenta um diagrama esquematizando o agente reativo simples

normativo. Esta abordagem considera que se uma ação é obrigada, então o agente deve

executá-la somente se não for proibida.

Figura 1. Diagrama esquematizado do agente reflexivo simples normativo

Caso a ação seja proibida, então o agente deve executar outra ação possível.

Caso não existam ações obrigatórias ou proibidas, então o agente deve executar alguma

ação que seja possível e racional, como qualquer agente racional o faria.

Assim, mais especificadamente, a função ação do programa de agente reativo

simples normativo foi especificada de maneira a evitar conflitos entre regras de

AutoSoft

51

diferentes grupos. Esta função foi concebida considerando fundamentalmente uma

sequência de quatro passos principais:

(P1) primeiramente, faz-se uma busca por regras que pertencem ao grupo de

regras obrigatórias, para achar aquelas ações que devem ser feitas e não são proibidas;

(P2) se existir alguma ação proibida, então a função inibe a regra de obrigação e

busca por regras de proibição para achar aquelas ações que não são proibidas e podem

ser realizadas de acordo com as condições do ambiente;

(P3) se não existe uma regra proibida, a função seleciona a ação que deve ser

feita como indicado pela norma de obrigação;

(P4) finalmente, no caso onde não existe uma regra de obrigação (nem de

proibição), a função busca por regras no grupo de permissão que corresponda a alguma

ação que pode ser feita de acordo com o estado do ambiente.

A estratégia para selecionar ações considera que o comportamento racional é

alcançado quando o agente maximiza a sua recompensa, que são consequência de (a)

selecionar uma ação obrigada que não seja proibida, (b) não selecionar uma ação

proibida e (c) selecionar uma ação permitida e adequada com o estado do ambiente, que

maximize o desempenho do agente. A medida de avaliação recompensa o agente reativo

simples pelo cumprimento das normas que são definidas pela organização.

No trabalho de Cruz (2013), o agente proposto acima foi implementado

utilizando framework Jamder 2.0 [Rocha Jr. et al., 2013]. A Figura 2 apresenta o

algoritmo da função agente reativo simples normativo.

Figura 2: Função agente reativo simples normativo

Para simplificar o problema e com o objetivo de trabalhar apenas com as normas

que geram comportamentos desnecessários e irracionais, o módulo de tratamento entre

conflitos de normas especificado no final do primeiro passo foi retirado da função

agente. Caso existam mais de uma ação retornada pelo módulo de obrigação, o agente

irá executar a primeira ação retornada. A função agente acima executa o que foi

proposto na Seção 2.

AutoSoft

52

3. EFICIÊNCIA DO AGENTE REATIVO SIMPLES NORMATIVO

Na arquitetura normativa apresentada na seção anterior, o comportamento do agente é

governado por normas, o que pode melhorar ou piorar o desempenho do agente

dependendo das obrigações que lhe são impostas pela organização. Nestes casos como,

por exemplo, em que existem ações obrigatórias (não proibidas), pode ser que o agente

execute ações desnecessárias e irracionais, visto que a lógica de tomada de decisão no

programa de agente reativo simples refinado não distingue entre ações obrigatórias que

melhoram ou que pioram o desempenho do agente, em função de algum tipo de recurso

que poderá estar sendo consumido desnecessariamente com a execução da ação.

Como domínio de aplicação da ideia, vale considerar aqueles ambientes de

tarefa semelhantes aos dos agentes aspiradores de pó. Devido a este tipo de ambiente ser

dinâmico, periodicamente a organização define novas normas visando regular o

comportamento dos seus agentes. Neste contexto, a medida de avaliação de desempenho

estabelecida pela organização recompensa seus agentes pelo cumprimento das normas

durante a execução de ações no ambiente de tarefas. Especificadamente no caso do

aspirador de pó, a organização recompensa o agente quando ele executa a ação de

“aspirar” em um local que contém sujeira.

Nos casos em que o recurso energia disponível para a execução de tarefas é

escasso, a medida de avaliação pode penalizar proporcionalmente as ações que são

possíveis para o agente de acordo com o consumo decorrente da execução de cada ação

possível. Entretanto, pode ocorrer de um agente desperdiçar energia se alguma norma

mal definida estiver obrigando-o a aspirar durante um período de tempo uma

determinada sala que está limpa [Campos et al., 2012].

Já que o cumprimento das normas da organização é recompensado pela medida

de avaliação, seria irracional o agente descumpri-las. Assim, a maneira como o

programa de agente reativo simples foi refinado não permite que os agentes violem as

normas que vão sendo definidas e enviadas pela organização e, consequentemente, pode

ocorrer de um agente executar ações desnecessárias e irracionais devido à presença de

normas de obrigação mal definidas enviadas pela organização, ou seja, normas de

obrigação de execução de uma ação em que:

(1) o cumprimento conduz o agente ao comportamento irracional, em função de

existir uma ação possível alternativa que é melhor que a ação obrigada de ser

executada; e

(2) o descumprimento indiretamente conduz o agente ao comportamento

irracional, em função do agente deixar de receber a recompensa pelo

cumprimento da norma.

Neste trabalho, as ações resultantes de normas de obrigação mal definidas foram

denominadas desnecessárias e irracionais, pois, em geral, a não execução destas ações é

melhor em termos da medida de avaliação de desempenho estabelecida para o agente

pela organização em que participa.

AutoSoft

53

Segundo Kollingbaum et al. (2007) um conflito entre duas normas ocorre

quando uma ação está, simultaneamente, sob a influência de duas normas diferentes e

ambas estão ativas. Enquanto que o problema das ações desnecessárias e irracionais,

definida neste trabalho, ocorre quando uma norma de obrigação mal definida está

vincula a uma ação.

4. A ABORDAGEM PARA O TRATAMENTO RACIONAL DE NORMAS

DE OBRIGAÇÃO

Segundo Meyer e Wieringa (1991), a lógica deôntica em um sistema multiagente é

usada para restringir o comportamento dos agentes na forma de obrigação (o que o

agente deve fazer), na forma de permissão (o que o agente pode fazer) e na forma de

proibição (o que o agente não pode fazer). Seja O um operador de obrigação empregado

para declarar regras cujos consequentes são ações obrigadas, P um operador de

permissão para declarar regras cujos consequentes são ações permitidas e F um

operador de proibição para declarar regras cujos consequentes são ações proibidas. Por

exemplo, se existir uma regra p cujo consequente seja a ação a, então as declarações

simbólicas O p, P p e F p significam, respectivamente, que o agente é obrigado a

executar a, é permitido executar a e é proibido executar a.

De acordo com G. H. von Wright (1951), P p ↔ ¬O ¬p. Logo, ¬P p ↔ O ¬p.

Mas, ¬P p ↔ F p. Assim, F p ↔ O ¬p e, consequentemente, obtemos a seguinte

equivalência entre proposições normativas envolvendo os conceitos deônticos obrigação

e proibição O p ↔ F ¬p. Logo, no contexto do agente reativo simples normativo, o

agente é obrigado a executar uma ação a se e somente se o agente for proibido de não

executar a ação a, ou seja, está proibido de executar qualquer ação diferente de a, pois

x, x ≠ y : F ¬y → (F x ^ ¬F y) . Por exemplo, no contexto do agente reativo simples

normativo, obrigar o agente a executar a ação “aspirar” em um local durante algum

período de tempo é equivale a proibi-lo a “não aspirar” o local no período determinado,

ou seja, proibi-lo de executar qualquer outra ação diferente da ação “aspirar” no local e

no período indicado e não proibi-lo de executar a ação “aspirar”.

Assim, utilizando como base estas equivalentes lógicas apresentadas, foi

concebida uma abordagem para o tratamento das normas obrigatórias. A

responsabilidade pelo tratamento de normas de obrigação é feita pela organização.

Considerando as relações entre os conceitos deônticos de obrigação e de proibição, a

abordagem considera que a organização deve definir apenas normas em termos de

proibições e não proibições, como no caso acima, em que proibir o agente de executar a

ação “não aspirar” é equivalente a proibir as execuções de ações diferentes de “aspirar”.

Como consequência, se a ação não proibida “aspirar” for racional, isto é, se o local do

ambiente contiver sujeira, o programa refinado selecionará esta ação; caso contrário, ou

seja, o local estiver limpo, simplesmente não selecionará ações (não agirá), pois as

outras ações possíveis ao aspirador estarão proibidas.

No contexto do programa de agente, as regras condição-ação do agente reativo

simples normativo as regras foram reagrupadas em apenas dois grupos, ou seja:

Grupo de Proibição: especifica as regras relacionadas com as ações que

não podem ser executadas pelo agente.

Grupo de Não Proibição: especifica as regras relacionadas com as ações

que podem ser executadas pelo agente.

AutoSoft

54

A Figura 3 apresenta o diagrama esquematizando a nova abordagem do agente

reativo simples refinado para receber normas definidas por uma organização.

Implicitamente, esta nova abordagem considera que o novo agente reativo simples

normativo executa apenas aquelas ações que não são proibidas, mas que são racionais,

da mesma maneira que um agente racional o faria.

Figura 3. Diagrama esquematizado da nova abordagem

A nova função ação executa apenas dois passos, adaptados da sequência anterior

composta de quatro passos:

(P1) primeiramente, a função ação busca por regras que pertencem ao grupo de

regras proibidas, visando encontrar aquelas ações que não podem ser executadas; e

(P2) posteriormente, a função busca por regras no grupo de não proibidas

visando encontrar alguma ação possível para o agente conforme as condições do

ambiente de tarefa.

A Figura 4 apresenta o novo algoritmo da função agente reativo simples refinado

em relação ao algoritmo descrito na Figura 2, que fundamenta a nova abordagem.

Figura 4: Função agente reativo normativo da nova abordagem

Nesta nova abordagem, o agente não faz distinção entre regras de obrigação e

regras de permissão, inserindo-as no grupo de regras proibidas ou no grupo de não

proibidas. Desta forma, o agente reativo simples não sofrerá do problema das ações

desnecessárias e irracionais ocasionadas pelas normas de obrigação, pois com a

transformação, a execução destas ações é evita, ao mesmo tempo em que as ações

possíveis restantes, diferentes das ações desnecessárias, são proibidas, o que pode levar

o agente à não execução de ações durante o período de ativação das normas de

obrigação geradas pelo mecanismo regulador.

O papel da organização é externar para os agentes apenas normas que são

proibições e não proibições. A abordagem proposta considera que o processo de

AutoSoft

55

transformação e de imposição das normas resultantes deve ser realizado pela

organização interessada. De acordo com TAO+ [Freire et al., 2012], ilustrado na Figura

5, os agentes de um sistema multiagente normativo recebem as normas da organização

em que estão vinculados através do papel de agente.

Figura 5. Relacionamento papel do agente normativo agente normativo no TAO+

Considerando esta premissa, a Figura 6 descreve o algoritmo que deve ser

incorporado pela organização visando automatizar o processo de conversão de normas

de obrigação em suas equivalentes proibitivas.

Figura 6: Conversão das normas de obrigação em normas de proibição

Executando o processo descrito no Algoritmo 3 é possível externar a solução

para o papel do agente reativo simples normativo, deixando íntegra a arquitetura do

agente, inclusive, sem a necessidade de estender a arquitetura para comportar uma

memória que possibilite ao agente realizar o processo de transformação.

AutoSoft

56

5. ESTUDO DE CASO

Esta seção apresenta algumas simulações realizadas considerando um ambiente de

tarefa semelhante a uma das versões do mundo do aspirador de pó simplificado [Russell

e; Norvig, 2004]. As simulações visaram comparar o desempenho dos programas de

agentes descrito nos algoritmos das figuras 2 e 4, concretizados usando a linguagem de

programação Java. A Figura 7 ilustra o estado inicial do ambiente nas simulações.

Figura 7. Situação inicial da simulação

Neste mundo simplificado existem apenas duas salas A (roomA) e B (roomB),

que podem conter sujeira (Sujo) ou não (Limpo). Os agentes têm percepção local, ou

seja, percebem a sala em que está e o estado da sala. Os agentes não conhecem a

configuração inicial do ambiente. Em qualquer momento, os agentes podem executar

uma de três ações possíveis: aspirar (suck), mover para a esquerda (left), mover para a

direita (right). Os agentes podem decidir por não executar qualquer ação entre aquelas

que são possíveis (no_op). Conforme o estado inicial na figura acima indica, as duas

salas estão inicialmente sujas e os agentes começam na sala A.

A medida de avaliação de desempenho estabelecida para os agentes: (1)

recompensa com um ponto a mais quando o agente limpa uma sala; (2) penaliza com

um ponto a menos quando o agente movimenta-se entre salas; (3) recompensa com três

pontos a mais quando o agente cumpre uma norma; (4) penaliza com um ponto a menos

quando um quando o agente executa uma ação desnecessária e irracional. Três normas

foram estabelecidas para os agentes: (N1) “Obrigado aspirar sala A das 10:00 às 12:00”;

(N2) “Proibido mover-se para a esquerda das 13:00 às 15:00”; e (N3) “Proibido mover-

se para a direita das 13:00 às 15:00”.

A Tabela 1 apresenta dez episódios registrados na história do agente aspirador

de pó no ambiente de tarefa, programado de acordo com o Algoritmo 1, ou seja,

considerando o primeiro refinamento.

Tabela 1. Desempenho do Algoritmo 1

Estado Ação Pontos Acumulado

Onde está? Estado roomA Estado roomB 1 roomA Sujo Sujo suck 1 1 2 roomA Limpo Sujo right -1 0 3 roomB Limpo Sujo suck 1 1 4 roomB Limpo Limpo left -1 0 5 roomA Limpo Limpo suck 3 - 1 2 6 roomA Limpo Limpo suck 3 - 1 4 7 roomA Limpo Limpo right -1 3 8 roomB Limpo Limpo no_op 3 6 9 roomB Limpo Limpo no_op 3 9

10 roomB Limpo Limpo left -1 8

AutoSoft

57

Do primeiro ao quarto episódio, o Algoritmo 1 comportou-se racionalmente,

obtendo o valor máximo possível de desempenho. Entretanto, o mesmo não acontece no

quinto e no sexto episódios. Nestes episódios o agente foi recompensado com três

pontos pelo cumprimento da norma de obrigação N1, mas também foi penalizado com

um ponto a menos por ter aspirado em uma sala que estava limpa, consumindo

desnecessariamente a energia disponível. Por sua vez, com a ativação das normas de

proibição N2 e N3 nos últimos episódios, novamente o Algoritmo 1 apresentou um

comportamento racional, obtendo o valor máximo de pontos possíveis por ter cumprido

com as proibições descritas em N2 e N3.

Quanto ao registro do aspirador de pó programado de acordo com o Algoritmo 2

no mesmo ambiente de tarefa, o segundo refinamento propõe que a organização evite a

declaração de normas envolvendo o conceito deôntico de obrigação, transformando-as

em normas envolvendo os conceitos deônticos de proibição e permissão (não

proibição). Assim, a norma de obrigação N1 deve ser transformada pela organização em

novas normas equivalentes envolvendo o conceito deôntico de proibição, conforme o

Algoritmo 3. A transformação da norma N1, que envolve o conceito deôntico de

obrigação e, consequentemente, deve ser transformada pela organização em uma ou

mais normas equivalentes envolvendo o conceito deôntico de proibição, pode ser

melhor compreendida ressaltando-se duas etapas principais do processo de

transformação, ou seja:

(E1) considerando N1, empregando-se a equivalência O p ↔ F ¬p, obter como

equivalente lógica a norma (N1’) “Proibido não aspirar sala A das 10:00 às 12:00”; e

(E2) considerando N1’, empregando-se a implicação x, x ≠ y : F ¬y → (F x ^

¬ F y), obter como consequente lógico as normas: (N1.1) “Proibido ir para esquerda da

sala A das 10:00 às 12:00”, (N1.2) “Proibido ir para direita da sala A das 10:00 às

12:00”, e (N1.3) “Proibido não operar na sala A das 10:00 às 12:00”.

A Tabela 2 apresenta os dez episódios registrados na história do agente com o

Algoritmo 2. Vale ressaltar, além do grupo de regras de proibição relacionadas às

normas N2 e N3, esta etapa das simulações considerou também as outras regras de

proibição, relacionadas com as três normas de proibição obtidas com a transformação da

norma N1 nas normas N1.1, N1.2 e N1.3.

Tabela 2. Desempenho do Algoritmo 2

Estado Ação Pontos Acumulado

Onde está? Estado roomA Estado roomB 1 roomA Sujo Sujo suck 1 1 2 roomA Limpo Sujo right -1 0 3 roomB Limpo Sujo suck 1 1 4 roomB Limpo Limpo left -1 0 5 roomA Limpo Limpo no_op 3 3 6 roomA Limpo Limpo no_op 3 6 7 roomA Limpo Limpo right -1 5 8 roomB Limpo Limpo no_op 3 8 9 roomB Limpo Limpo no_op 3 11

10 roomB Limpo Limpo left -1 10

AutoSoft

58

Semelhante ao que aconteceu com o agente que incorporou o Algoritmo 1, o

agente que incorporou o Algoritmo 2 comportou-se racionalmente do primeiro ao

quinto episódio, obtendo o valor de desempenho igual ao obtido pelo primeiro agente.

Da mesma maneira, com a ativação das normas N2 e N3, no oitavo e nono episódios, o

segundo agente obteve a mesma pontuação que o primeiro. O mesmo aconteceu no

último episódio da história. Entretanto, o mesmo padrão de comportamento não se

manteve no quinto e no sexto episódio. Nestes episódios o agente foi recompensado

com três pontos pelo cumprimento da norma N1, mas, ao não executar ações nestes

episódios (no_op), evitou duas penalizações sofridas pelo primeiro agente, que estava

obrigado pela norma N1 a aspirar uma sala limpa.

Vale ressaltar que as normas N1.1, N1.2 e N1.3 estavam ativas durante a

ocorrência destes episódios e o agente simplesmente preferiu não operar, pois a única

ação suck era desnecessária e irracional, visto que o agente seria penalizado se a

executasse. Além de economizar energia, é importante notar que ao final da simulação,

no décimo episódio, o programa agente que empregou o Algoritmo 2, obteve melhor

desempenho que o agente que empregou o Algoritmo 1, mas isso se deve ao processo

de transformação empregado pelo Algoritmo 3, pois aplicando o Algoritmo 3 antes de

passar as normas para o primeiro refinamento, o resultado será o mesmo alcançado pelo

programa agente do segundo refinamento. Isto se deve pelo fato da norma de obrigação

N1 estar mal definida, pois caso a norma N1 fosse “Obrigado aspirar a sala A das 10:00

às 12:00, caso ela esteja suja” o agente da primeira arquitetura não executaria as ações

desnecessárias e irracionais.

6. CONCLUSÕES E TRABALHOS FUTUROS

O presente trabalho propõe uma solução para evitar a execução de ações desnecessárias

e irracionais geradas por normas mal definidas. Para isso, é feito o tratamento

automatizado das normas de obrigação em suas equivalentes lógicas de proibição pela

organização à qual os agentes reativos simples normativos pertencem. Com a

automatização e encapsulamento das transformações das normas de obrigação nas suas

equivalentes proibitivas, a conversão normativa torna-se mais uma opção para se

trabalhar com agentes normativos, podendo ou não ser executada dependendo da

quantidade de recursos disponíveis no ambiente de trabalho e dos objetivos da

organização.

Como trabalho futuro, faz-se necessário uma forma de automatizar o mecanismo

regulador para perceber quando algumas normas podem estar mal definidas, pois como

o mecanismo regulador irá atuar em relação a tais normas, os critérios para sancionar

usados pelo regulador podem prejudicar o desempenho de agentes de um sistema

multiagente normativo.

REFERÊNCIAS

Campos, G. A.; Freire, E. S. S.; Cortés, M. I. Norm-based behavior modification in

reflex agents. In: 14th International Conference on Artificial Intelligence (ICAI), Las

Vegas, Nevada, USA, Proceedings of the 14th International Conference on artificial

Intelligence, 2012.

AutoSoft

59

Cruz, F. I. S, Modificação do comportamento da arquitetura de agentes reativo

simples baseado em normas – Uma implementação em JAMDER 2.0. Trabalho de

Conclusão de Curso (TCC), Universidade Estadual do Ceará, Ceará, Fortaleza, 2013.

Emmanuel S. S. Freire, Mariela I. Cortés, Enyo J. T. Gonçalves, Yrleyjânder S. Lopes,

Extending the Framework TAO with Norms for MultiAgent Systems. Workshop-

Escola de Sistemas de Agentes, seus Ambientes e Aplicações 2012 (WESSAC),

Florianópolis, 2012.

Figueiredo, K. Modeling and Validation Norms in Multi-Agents Systems.

Dissertação (Mestrado em Computação). Universidade Federal Fluminense, Rio de

Janeiro, Niterói, 2011.

Gomes, N. G. Um panorama da lógica deôntica. Em: Kriterion: Revista de Filosofia,

Volume 49, Número 117, 2008, p. 9-38.

Martin J. Kollingbaum; Wamberto W. Vasconcelos; Andrés García-Camino; Tim

Norman Conflict Resolution in Norm-Regulated Environments Via Unification and

constraints. Em: 5th International Workshop, DALT 2007, Honolulu, HI, USA, May

14, 2007, Revised Selected and Invited Papers, p. 158–174.

Meneguzzi, F.; Luck, M. Norm-based behaviour modification in BDI agents. Em:

8th International Foundation for Autonomous Agents and Multiagent Systems,

Budapeste, Hungria, Proceedings of The 8th International Conference on Autonomous

Agents and Multiagent Systems Volume 1, 2009, p. 177–184.

Meyer, J. J.; Wieringa, R. J. Deontic logic in computer science: normative system

specification, John Wiley and Sons, Vrije Universiteit, Amsterdam, The Netherlands,

1991.

Modgil, S.; Faci, N.; Meneguzzi, F.; Oren, N.; Miles, S.; Luck, M. A framework for

monitoring agent-based normative systems. Em: 8th International Conference on

Autonomous Agents and Multiagent Systems, Budapeste, Hungria, Proceedings of the

8th International Foundation for Autonomous Agents and Multiagent Systems. Volume

1, 2009, p. 153–160.

Silva, V. T. da. Uma linguagem de modelagem para sistemas multi-agentes baseada

em um framework conceitual para agentes e objetos. Tese de doutorado. Rio de

Janeiro: PUC, Departamento de Informática, 2004.

Rocha Jr., R. M.; Freire, E. S. S.; Cortés, M. I. Estendendo o Framework JAMDER

para Suporte à Implementação de Sistemas Multi-Agente Normativos. Em: IX

Simpósio Brasileiro de Sistemas de Informação (SBSI), 2013, João Pessoa, Brasil.

Anais do IX Simpósio Brasileiro de Sistemas de Informação (SBSI). Volume 1, 2013, p.

839-850.

Russell, S.; Norvig, P. Inteligência Artificial: uma abordagem moderna. 2ª Ed. São

Paulo: Prentice-Hall, 2004.

Wright, G. H. von. Deontic Logic System. Em: Mind: New Series, Volume 60,

Número 237, 1951, p. 1–15.

AutoSoft

60

Fragmenting O-MaSE using the Medee Framework Felipe Cardoso Resende, Anarosa A. F. Brandão,

Sara J. Casare, Jaime S. Sichman

Escola Politécnica – Universidade de São Paulo (USP).

{felipe.resende, anarosa.brandao, jaime.sichman}@usp.br, [email protected],

Abstract: Multiagent system (MAS) is a promising approach for dealing with the complex problems that are emerging in the last years. However it needs a controlled way to be conducted so that it can be largely used in the software industry. The use of Situational Method Engineering (SME) for building MAS methods has gained support in the community and may be capable of solving this issue. To prove this point of view, it is necessary to apply it in practical examples. In this work, we fragment the O-MaSE (Organization-Based Multiagent Software Engineering) using the Medee Method Framework and store these fragments in the Medee Method Repository, that can be used to provide more practical examples of the use of SME to build MAS methods.

1.Introduction Multiagent Systems (MAS) is an approach being developed to solve complex problems that are emerging in the last years. The intelligent agent, which is its central notion, encapsulates the capabilities required to fulfill these problem’s requirement. However it is not yet being widely used in the software industry as it needs a controlled way to conduct its development [Brandão et al., 2013] and does not support large scale development [DeLoach, 2009].

Situational Method Engineering (SME) is an emerging field with many ideas and concepts to support process engineers and process users [M. Kuhrmann et al., 2014], and has gained support in the agent-oriented software engineering community, promoting flexibility in MAS methods and processes [Low et al., 2009; Molesini et al., 2009; Cossentino et al., 2007]. It is a sub-area of Method Engineering that deals with the composition of specific methods to each situation from a set of existing method fragments.

In order to verify the feasibility of using SME, it is necessary more empirical evidence of its practical use. Therefore, in this work the O-MaSE (Organization-Based Multiagent Software Engineering) [DeLoach and García-Ojeda, 2010] method is fragmented using the Medee Method Framework [Casare et al., 2013] and the fragments are stored in the Medee Method Repository for being reused to build Situational Methods, providing more SME practical examples. There are two related works that used Medee to fragment MAS methods, [Yassuda et al., 2014] and [Almeida et al., 2014].

AutoSoft

61

The Medee Method Framework is a situational approach which allows the development of organization-centered MAS in a disciplined way. It offer a method repository (Medee Method Repository) that covers different development phases, such as requirements, analysis, design, implementation, as well as the main components of a MAS application, like agents, environments, interactions, and organizations. It also offer the Medee Delivery Process, which specify in a step-by-step manner the whole process from the Medee method fragments elaboration to the deployment of the Medee situational method to Web servers in order to be used during the project execution.

To support the fragmentation, the Eclipse Process Framework1 (EPF) Composer is used to build and publish the method fragments.

In the following, an overview of O-MaSE is presented in Section 2, an introduction to the Medee Method Framework is presented in Section 3, the fragmentation process in Section 4. Finally, Section 5 presents our conclusions.

2. O-MaSE Method

The O-MaSE method started in 2005 [DeLoach, 2006] as an extension of MaSE [DeLoach et al., 2001] by including a flexible organization model. Such an extension allows the MAS to organize and reorganize at runtime [DeLoach et al., 2008], and provides mechanism for modeling environment interactions. Also, it integrates a set of concrete technologies aimed at facilitating industrial acceptance through situational method engineering. To achieve this, it is defined in terms of a meta-model, a set of method fragments, and a set of method construction guidelines. Specifically, it is a customizable agent-oriented method supported by plug-ins to an industrial strength development environment.

The O-MaSE meta-model defines a set of analysis, design, and implementation concepts and a set of constraints between them. Its associate method fragments define a set of work products, a set of activities that produce work products, and the performers of those activities. The method construction guidelines define how method fragments may be combined to create O-MaSE compliant methods. To help the creation of O-MaSE compliant methods, there is a development environment, the agentTool III2 (aT³), which provides editors, verification tools, and code generators.

3. Medee Method Framework The Medee Method Framework allows the composition of methods on demand according to a particular MAS project situation by combining the advantages from both Agent-Oriented Software Engineering (AOSE) methods and Agent Organization models. This framework provides a repository called Medee Method Repository, which is populated with method fragments. This repository is organized in three layers which are associated with three phases of the Medee Delivery Process and will be explained in the following sub-section.

Medee was built upon SPEM (Software and System Process Engineering Meta-model) [OMG, 2008], a standard for describing processes and methods. It can provide 1 http://www.eclipse.org/epf/ acessed on 25 June 2014 2 http://agenttool.cis.ksu.edu/ acessed on 25 June 2014

AutoSoft

62

necessary concepts for modeling, documenting, presenting, managing, and enacting development process. SPEM defines three key concepts, tasks, roles and work products, which are the base for the activities, which compose the method being described. A task represents a small piece of work, described step-by-step, which is performed by roles and results in work products.

To help in the process of describing methods using SPEM, the EPF Composer is a tool that implements SPEM elements and allows its creation and the creation of complete situational methods based on these elements. The Medee Framework was itself built using the EPF Composer and it is also used to fragment the methods to populate the Medee Repository. 3.1 Medee Method Repository The first layer is the Medee Elements layer. This layer is populated with the SPEM elements captured from the MAS development approaches (tasks, roles, work products, categories, guidance).

The second layer is the Medee Fragments layer. This layer contains the method fragments extended from the SPEM elements from the first layer. The extension is required to achieve standardization and coherence required by the MAS method fragment definition.

The third layer is the Medee Methods layer. This layer stores two kinds of methods, Medee Situational Methods and Medee AOSE Methods. The former are composed according to a given project situation, encompassing fragments usually sourced from several MAS development approaches. The latter consist of AOSE methods that have been reengineered in terms of Medee method fragments. To build these methods, the method engineer uses the fragments stored in the second layer.

3.2 Medee Delivery Process The Medee Delivery Process defines three phases for fragmenting and composing MAS methods. In the first phase, the Method Element Capture Phase, the MAS development approach is analyzed, modeled and the knowledge captured from it is stored as a collection of SPEM elements in the Medee Element layer. For instance, O-MaSE fragments captured in this work were stored in this layer.

In the second phase, the Method Fragment Elaboration Phase, the SPEM elements captured in the previous phase are extended to achieve a standardization required to allow them to be grouped with method fragments obtained from different MAS development approaches. The fragments generated in this phase are stored in the Medee Fragments layer. The fragments’ names start with MMF for standardization and they must be categorized considering the Semiotic Taxonomy[Casare et al, 2013] MMF stands for Medee Method Fragment. The Semiotic Taxonomy provides a set of criteria to categorize MAS Method Fragments taking into account their meaning, usage, structure and so on.

In the third phase, the Situational Method Composition Phase, the fragments generated in the previous phase are used to build a new MAS development approach, combining method fragments from different methodologies, or are used to reengineer the original methodology in terms of MAS method fragments.

AutoSoft

63

4. Fragmenting O-MaSE Method The next two sections describe the process of fragmenting the O-MaSE method using the EPF Composer and the Medee Delivery Process.

4.1 First layer – Capturing SPEM elements The first step consisted of analyzing the O-MaSE method and understanding how it works and how it could be described using SPEM elements, such as tasks, work products, guidance and roles.

The next step was to outline and refine the SPEM elements using the EPF. It resulted in the definition of sixty six (67) method elements: fifteen tasks, twelve roles, twenty five guidance (twelve concepts and thirteen examples) and fifteen work products. During this process of outlining and refining method elements, they were linked between them (e.g assigning works products to tasks) to maintain consistency with the original method.

After establishing the relationships between the elements, it was possible to group the tasks in activities, the activities in iterations and the latter in phases in order to build the complete method, named as O-MaSE Method As Is. A screenshot of it is given at Fig. 1.

Figure 1. A piece of O-MaSE As Is

4.2 Second layer – Elaborating Fragments In this layer the method elements captured in the first layer were standardized before being used to elaborate Medee fragments.

AutoSoft

64

The work product standardization consisted in the creation of a new work product that extends the original one, classifying it according to produced MAS component (such as agent, organization, interaction, environment) and assigning it to a Medee Work Product Slot (MPS), which groups related work products.

The task standardization consisted in the creation of a new task that extends the original one, assigning to them a MAS basic development role (such as MAS Designer, MAS Developer, MAS Tester and System Analyst). In the extended task, the original inputs were replaced in order to allow the use of any work product which belongs to the corresponding MAS component already stored in the Medee Framework.

The next step was the definition of the Medee Fragments in several layers: Activities, Iterations and Phases. The activities and the tasks that compose these activities were already defined on O-MaSE, so it was only necessary to standardize these activities. This process consisted of creating fragments designed according to the following name pattern: MMF <verb> <object> with O-MaSE, followed by the creation of the activity named as <verb> <object> with O-MaSE and the inclusion of the activities’ tasks. After that, they were categorized using the MAS Semiotic Taxonomy and their activity diagrams were created.

In the MMF Gather Requirements with O-MaSE Activity, presented at Figure 2, the system analyst uses traditional methods to identify the system requirements. O-MaSE does not provide a specific approach to this task because the traditional ones are sufficient to complete this task. The MPV System Requirement is generated at the end of this activity. Classifying this fragment according to de Semiotic Taxonomy, it belongs to the Requirement Discipline Category that is a sub-category of the Fragment Discipline Category in the Semantic Level category of the Semiotic Taxonomy.

Figure 2. MMF Gather Requirements with O-MaSE

In the MMF Analyze Problem with O-MaSE Activity, the system analyst uses information about the system requirements and the organization to model the system goals and the system domain. This fragment belongs to the Analysis Discipline Category. A screenshot of the fragment is presented at Figure 3.

In the MMF Analyze Solution with O-MaSE Activity, the system analyst use information about the organization and the system requirements to model the organization and the organization’s roles. This fragment belongs to the Analysis Discipline Category and to the Organization Component Category. A screenshot of the fragment is presented at Figure 4.

AutoSoft

65

Figure 3. MMF Analyze Problem with O-MaSE

Figure 4. MMF Analyze Solution with O-MaSE

The MMF Design Architecture with O-MaSE Activity is responsible for defining the agent classes and sub-organizations that will populate the organization (MPV Agent Class Model), the way that agents and organizations will interact (MPV Protocol Model) and the constraints applied to the system. Therefore, this fragment has outputs related to agents, interactions and the organization. It belongs to the Design Discipline Category. A screenshot of it is presented at Figure 5.

AutoSoft

66

Figure 5. MMF Design Architecture with O-MaSE

The MMF Design Low Level with O-MaSE has three tasks: MTV Model Plans, MTV Model Capabilities and MTV Model Actions. In the first task the MAS Designer uses simple finite state machines to model how agents can achieve the system goals. In the second task he defines the agents’ capabilities based on the information about the agent types, the environment and the organization roles. In the last one the way agents may act to perform plans and achieve goals is defined based on the agent capabilities and on the environment. This fragment can be classified as belonging to the Design Discipline Category and Agent Component Category. This fragment is presented at Figure 6.

Figure 6. MMF Design Low Level with O-MaSE

AutoSoft

67

The last activity fragment is the MMF Code Generation with O-MaSE and it consists of only one task, the MTV Generate Code. In this task the MAS Developer produce the code that implement the models based on the design models generated so far. This fragment belongs to the Implementation Activity Category. A screenshot of it is given in Figure 7.

Figure 7. MMF Code Generation with O-MaSE

As O-MaSE does not suggest a project lifecycle, project phases are defined by the developers in order to meet their needs to solve the current situation. So, in order to create fragments for the whole process, we assumed we are following an iterative approach specified in [DeLoach and García-Ojeda, 2010].

The process for creating the Phases Fragments was analogous. Then the iterations that belonged to them were assigned.

Finally, the MMF O-MaSE Base Method consists of a Process method fragment that involves the previously described fragments (see Figure 8). Such a fragment represents the whole development process proposed by O-MaSE in terms of activity and phase fragments.

5. Conclusion This work resulted in the fragmentation of the O-MaSE method involving sixty six (67) method elements (fifteen tasks, twelve roles, twenty five guidance and fifteen work products) and sixteen (16) method fragments (six activity fragments, six iteration fragments, three phase fragments and one process fragment).These fragments will be stored in de Medee Method Repository3 so that it can be used to build Situational Methods.

The use of the Medee Delivery Process seems to be a good approach for fragmenting MAS methods as it produces standardized fragments that can be used together independently of the fragment’s origin.

3 http://medee.poli.usp.br/

AutoSoft

68

Figure 8. O-MaSE Base Method

Acknowledges Felipe Resende is partially supported by CNPq, grant #147828/2013-9, Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq).

References Almeida, T.L.; Casare, S. and Brandão, Anarosa .A.F.. Fragmenting ADELFE using the

Medee Framework In: Anais do VIII Workshop-Escola de Sistemas de Agentes, seus Ambientes e apliCações - WESAAC 2014. Porto Alegre: PUC-RS, 2014. v. 1. p. 215-220.

Brandão, Anarosa A.F. ; Casare, S. J. ; FRANCA, D. I.. Towards automating method fragament selection for MAS. In IV Workshop sobre Sistemas de Software Autônomos - AutoSoft 2013, v. 1, p. 32-40, 2013.

AutoSoft

69

Casare, S. J. ; Brandão, Anarosa A.F. ; Guessoum, Z. ; Sichman, J.S. . Medee Method Framework: a Situational Approach for Organization-Centered MAS. Autonomous Agents and Multi-Agent Systems (Dordrecht. Online), v. tbd, p. 1-44, 2013. (http://dx.doi.org/10.1007/s10458-013-9228-y).

Cossentino, M., Gaglio, S., Garro, A. and Seidita, V. (2007) ‘Method fragments for agent design methodologies: from standardisation to research’, International Journal of Agent-Oriented Software Engineering, Vol. 1, No. 1, pp.91–121.

DeLoach, S.A., Wood, M.F. and Sparkman, C.A. (2001) ‘Multiagent systems engineering’, The International Journal of Software Engineering and Knowledge Engineering, Vol. 11, No. 3, pp.231–258.

DeLoach, S.A. (2006) ‘Multiagent systems engineering of organization-based multiagent systems’, in Garcia, A., Choren, R., Lucena, L., Giorgini, P., Holvoet, T. and Romanovsky, A. (Eds.): Software Engineering for Multi-Agent Systems IV, LNCS Vol. 3914, pp.109–125, Springer, Berlin.

DeLoach, S.A., Oyenan, W. and Matson, E.T. (2008) ‘A capabilities based model for artificial organizations’, Journal of Autonomous Agents and Multiagent Systems, Vol. 16, No. 1, pp.13–56.

DeLoach, S. 2009. Moving multiagent systems from research to practice. In: International Journal of Agent-Oriented Software Engineering, v. 3, n. 4, p.378-382.

DeLoach, S.A. and García-Ojeda, J.C. (2010) ‘O-MaSE: a customisable approach to designing and building complex, adaptive multi-agent systems’, Int. J. Agent-Oriented Software Engineering, Vol. 4, No. 3, pp.244–280.

Low, G., Beydoun, G., Henderson-Sellers, B. and Gonzalez-Perez, C. (2009) ‘Towards method engineering for multi-agent systems: a validation of a generic MAS meta-model’, in Ghose, A., Governatori, G. and Sadananda, R. (Eds.): Agent Computing and Multi-Agent Systems: 10th Pacific Rim international Conference on Multi-Agent Systems, PRIMA 2007, 21–23 November 2007, Bangkok, Thailand, LNAI Vol. 5044, Springer, Berlin.

Molesini, A., Denti, E., Nardini, E. and Omicini, A. (2009) ‘Situated process engineering for integrating processes from methodologies to infrastructures’, Proceedings of the 2009 ACM Symposium on Applied Computing (Honolulu, Hawaii), ACM, New York, pp.699–706.

M. Kuhrmann, D. Mendez Fernandez, M. Tiessler ‘A Mapping Study in the Feasibility of Method Engineering’ In: Journal of Software: Evolution and Process, Wiley, 2014

OMG (2008) ‘Software and systems process engineering meta-model specification v2.0’, Object Management Group, available at http://www.omg.org/spec/SPEM/2.0/PDF (accessed on 25 June 2014).

Yassuda, D. S. ; Casare, S. J. ; Brandao, Anarosa A. F. . Fragmenting Prometheus: new choices for developing multiagent systems. In: Anais do VIII Workshop-Escola de Sistemas de Agentes, seus Ambientes e apliCações - WESAAC 2014. Porto Alegre: PUC-RS, 2014. v. 1. p. 137-142.

AutoSoft

70

JAMDER 2.0: Support to Implementation of Normative

Multi-Agent Systems

Robert M. Rocha Júnior, Emmanuel S. S. Freire and Mariela I. Cortés

Science Computer Department - State University of Ceará (UECE)

Fortaleza – CE – Brazil

{robstermarinho, savio.essf}@gmail.com, [email protected]

Abstract. In complex systems development is evident a significant difficulty

resulting by semantic gap, which is characterized by semantic distinction between

two generated descriptions and their representations. This difference has a

negative impact on the developer productivity and probably, the quality of the

generated code. This work aims to bring near the concepts of modeling and

implementation, especially for normative multi-agent systems, through the

extension of JAMDER framework, by including the norm concepts and their

properties. The main benefit of the proposed mapping is to reduce the semantic

gap between the modeling project and its implementation. To illustrate the result

of this approach a case study that involves a normative multi-agent system to

paper submission is presented.

1. Introduction

The agent-centered systems have been widely used by the scientific community for

development of computational complex systems [Casillo, 2008]. However,

implementation of these systems requires an engineering effort in order to provide

adequate support for different development activities.

According Russell and Norvig (2004), a software agent is an entity able to perceive

its environment through sensors and acting on this environment by actuators. For many

agents cooperating or disputing between themselves, inserted in the same environment and

sharing information, we call it multi-agent system (MAS). Within the context, a MAS may

be governed by norms which regulate the behavior of the entities included in this system.

That increases the complexity to development this kind of systems [Freire et al., 2012].

A significant factor to the difficulty in developing complex systems is the conceptual

and semantic difference between the phase of project design or problem domain, which

represents the documentation over a set of models, and phase of implementation/solution which

aims the system coding. Therefore, a set of methods and appropriate tools is necessary in order

to support the development activities, which aim to reduce the semantic gap between these two

levels of abstraction: modeling and code artifacts.

Considering as requirement the existence of a metamodel that covers the entities

members of a normative MAS, the modeling language NorMAS-ML (Normative Multi-

Agent System Modeling Language) [Freire et al., 2012] supports the modeling of agent,

agent role, object role, object, organization and environment, as well as the static elements

that compose a Norm. Diagrams of language can be generated through the MAS-ML tool

[Freire, Rocha Júnior and Cortés, 2012].

AutoSoft

71

In the implementation context, JAMDER framework (JADE to MAS-ML 2.0

Resource Development) [Lopes et al., 2012] is an extension of JADE framework (Java

Agent Development) [Jade, 2013] which has the following features: (i) it has a platform

in Java language, (ii) it supports distributed systems, (iii) it is freeware and (iv) it allows

the implementation of the MAS typical elements. However JAMDER does not allow

the implementation of all normative elements.

The goal of this paper is the extension of JAMDER framework in order to provide

the appropriate infrastructure for the implementation of normative multi-agent systems

according to the definitions included in NorMAS-ML. This paper is organized as follows:

Section 2 presents some related work. Section 3 corresponds to the theoretical reference,

where is presented the language NorMAS-ML and the JAMDER framework. Then, in

Section 4, we describe the extension of JAMDER framework proposed to implement

MASs with norms. A case study related to the extension is presented in Section 5 and

finally, conclusions and future work are described in Section 6.

2. Related Work

A set of frameworks and platforms has been developed to support the development of

MASs. In general, these mechanisms are associated with a programming language for

composing entities and provide an environment for their execution. Following are some

of the most used frameworks for implementing MAS.

JACK [Jack, 2013] is a framework in Java for development of MASs. This

framework provides high performance, and an easy way to be extended to support BDI

agents (Belief-Desire-Intention) and specific requirements of applications. The language

used by JACK is built from Java language and can be used in the development of BDI

agents and their behavior [Nunes, 2007]. However, JACK does not support the modeling of

normative concepts and its IDE (Integrated Development Environment) is not freeware.

JAM [Huber, 2012] was developed based on a series of theories and frameworks for

agents based on BDI agents. It allows the implementation of agents that have plans and

goals. However, JAM does not have development tool, does not allow implementation of

agent role, organization and the normative concepts.

JADE [Jade, 2013] is a framework implemented in Java language that simplifies the

development of MASs through middleware that complies with the FIPA specifications

(Foundations of Intelligent Physical Agents) and with a set of graphical tools that support

debugging [Nunes, 2007]. This framework allows the implementation of typical elements

that compose MASs. However, it does not have support for normative concepts.

How JADE did not support the implementation of different agent architectures,

Lopes et al. (2012) proposed its extension, called JAMDER. This extension was based on

modeling language MAS-ML 2.0 [Gonçalves, 2009]. Thus, JAMDER besides supporting

the modeling of the typical elements of MASs, it has support to the different types of agent.

However, JAMDER has limited support for normative concepts. This makes it possible to

implement agents that have their behavior regulated by rules included in agent roles,

organizations and suborganizations.

Normative Jason [Santos, 2012] is an extension of framework Jason [Jason, 2013]

based on AgentSpeak Normative language (language extension AgentSpeak). This

AutoSoft

72

framework provides the implementation of normative agents which are able to understand,

to follow or to violate the norms contained in the environment. However, the language is

defined on first-order logic, the focus of norms is the behavior of agents and not the other

entities that compose normative MAS, and does not have support to exchange roles

between agents.

Based on the analysis presented and considering the need of a framework that

enables the implementation of norms together with the entities stipulated in an MAS,

JAMDER is highlighted because (i) It has a platform on JAVA language, (ii) It has support

to distributed system, (iii) It complies with the FIPA patterns, (iv) It supports the MAS

typical entities and (iv) It has graphical interface and plugins for IDEs.

3. Background

3.1. NorMAS-ML

NorMAS-ML (Normative Multi-Agent System Modeling Language) [Freire et al., 2012]

is an extension of modeling language MAS-ML [Silva, 2004] that incorporates the

concepts of norms such that entities in MAS could be modeled considering the

following normative static elements defined by Figueiredo and Silva (2010): (i) deontic

concepts (obligations, permissions and prohibitions), (ii) involved entities whose

behavior can be regulated by the norms, (iii) actions, (iv) activation constraints for

norms, (v) sanctions involving rewards and punishments at the fulfillment and violation

of a norm, and (vi) the context that determines the application area of norm. Thus, the

language provides to represent norms that regulate the behavior of both entities as its

structural properties. For example, the actions to be performed by an agent.

The extension process made possible the inclusion of the normative elements in

abstract and concrete syntaxes of MAS-ML. In abstract syntax, were defined new

metaclasses and stereotypes. In the concrete syntax, graphical representations of the entities

Organization and Agent Role were changed because of the norm concept incorporation.

Additionally, it was defined graphical elements to represent the new metaclasses and

relationships included in the abstract syntax. NorMAS-ML introduces a new static diagram

for modeling norms and its properties and reuses all diagrams defined in MAS-ML.

For modeling the norms diagram, Freire, Rocha Júnior and Cortés (2012) developed

the MAS-ML tool, which is a plug-in of the Eclipse platform. This implies that users can

work with MASs modeling while making use of the resources offered by Eclipse platform.

With this tool it is possible to model all static diagrams defined in NorMAS-ML.

3.2. JAMDER

JAMDER (JADE MAS-ML to 2.0 Resource Development) [Lopes et al., 2012] is an

extension of JADE framework [Jade, 2013] that incorporates new classes to implement

specific information present on modeling of attributes and methods. JAMDER uses all

the resources from JADE platform to incorporate the new agent types defined in MAS-

ML 2.0 [Gonçalves, 2009].

In this context, this framework includes the mapping to identify which elements

of the conceptual metamodel of MAS-ML 2.0 corresponds to first-class entities in the

implementation platform. Consequently, three-level hierarchy of agents modeling was

AutoSoft

73

defined in JAMDER, which are: agents with plan, reflexive agents (simple reactive and

responsive knowledge-based) and cognitive agents (goal-based and utility-based).

Besides the concept of agent, were defined representations of other entities that

compose MASs. Thus, the specific representations for implementing agent role,

organization, environment, object and object role were included in JAMDER.

4. Extension of JAMDER Framework

This section presents the extension of JAMDER framework based on normative

concepts presented in NorMAS-ML. The extension was called JAMDER 2.0 (Figure 1).

4.1. Inclusion of normative elements

The extension process was characterized by the mapping between concepts of modeling

and implementation in order to identify which elements of the conceptual metamodel

relating to NorMAS-ML entities were present in JAMDER. Thus, we identified the

need to create classes to represent the normative concepts. The Figure 1 shows the class

diagram representing the normative concepts included in JAMDER. Below, we explain

with each normative concept was included in JAMDER.

Norm. In NorMAS-ML, a norm is used to restrict the behavior of agents,

organizations and sub-organizations during a period of time, and defines sanctions when a

norm is violated or fulfilled [Figueiredo and Silva, 2010]. The class jamder.norms.Norm

was created to represent the norm entity. The constructor of this class defines the following

arguments in order: (i) the identifier, (ii) the norm type, (iii) the restricted entity, (iv) the

context, (v) the action, (vi) and the list of activation constraints.

Some main properties as normType define the deontic concept of the norm

through an enumeration with boolean type and the following status: PERMISSION,

PROHIBITION and OBLIGATION. Additionally, the norm has attributes that define

the involved or restricted entities: restrictOrganization, restrictAgentClass,

restrictEnvironmentClass, restrictAgentRoleClas; and attributes that define the context

or application domain: contextOrganizationClass, contextEnvironmentClass.

Furthermore, it defines the attribute action on the action linked with it.

NormResource. A norm is set to restrict the behavior of a given resource [Freire et

al., 2012]. In NorMAS-ML, a resource may be linked to: structural features (goals, beliefs,

attributes), (ii) behavioral features (methods, actions, plans and protocols), (iii) an entity

(object, agent, organization, agent role or the environment), (iv) a relationship or (v) a

message. For each of these cases, the resource is represented by the class

jamder.norms.NormResource with the following properties detailed below:

• property: it sets resource as an attribute, a goal, a belief or a relationship. This

entity is an instance of the class jamder.structural.Property from JAMDER;

• method, action, plan, protocol: these attributes are used when defining

resource as one of the behavioral features, respectively, a method, an action, a

plan or a protocol. Each one of them are instances of classes from JAMDER in

the package: package jamder.behavioral;

• object, agent, environment, agentRole: these attributes were created to define

a resource like an entity.

• message – it defines the resource as message type.

AutoSoft

74

A resource has only one parameter on the constructor that will fill one of the

listed attributes represented thus resource type.

Figure 1. The class diagram representing the normative concepts in JAMDER.

NormAction. According Freire et al. (2012), a norm is created to restrict the

execution of entities or the access to system resources, through a set of actions linked

with it, which control these resources. These actions are detailed into two types in

NorMAS-ML: AtomicAction and CompositeAction.

The AtomicAction metaclass aims to map directly the system operations (delete,

update, read, create, and execute) and the CompositeAction metaclass aims to map

operations of system entities and keeps the hierarchy of both AtomicActions such as

CompositeActions. Actions were represented by main class jamder.norms.NormAction.

The entity normResource represents an attribute in this main class which sets the

resource controlled by action. The constructor of NormAction gets this resource as

parameter. Additionally, this class has a list of norms which the action is related and

two sub-classes: jamder.norms.AtomicAction and jamder.norms.CompositeAction,

which represent the action type.

NormConstraint. In NorMAS-ML, the NormConstraint metaclass is responsible

for defining the restricted period.

In NorMAS-ML, the NormConstraint metaclass is responsible for setting the

period of norm restriction, along with their specializations: (i) Before, indicates that a

norm is active before the execution of an action and/or realization from a specified date,

(ii) After indicates that a norm is active after the execution of an action and/or

realization from a specified date, (iii) Between, indicates that a norm is active between

the execution of two specific actions and/or the realization between two specified dates,

(iv) If, activates the norm according to the comparison between two operands or by

date. An operand can be a goal, a belief, an attribute or a value.

The class jamder.norms.NormConstraint was created to represent the activation

constraints with their respective sub-classes that include each type of constraint:

jamder.norms.Before, jamder.norms.After, jamder.norms.Between and jam-

der.norms.IfConditional. It is directly linked to class jamder.norms.Date responsible for

AutoSoft

75

setting a date. The classes jamder.norms.Before and jamder.norms.After allow setting an

action or a date to activate the constraint. The class jamder.norms.Between differs from

previous because it allows setting two actions or two dates.

Finally the class jamder.norms.IfConditional has the attributes firstProperty and

secondProperty, which are instances of the class jamder.structural.property defining two

operands, and the attribute operator, which defines the operator. To include operators

the class jamder.norms.Operator was created as an enumeration boolean type that

defines the following operators LESSTHAN, GREATERTHAN, EQUALTO,

LESSOREQUALTO, GREATEROREQUALTO. Consequently, the class

jamder.norms.IfConditional allows setting an activation constraint that has an operator

and a date or that has two operands and one operator.

4.2. Changes of JAMDER classes

Some JAMDER classes were modified to include the properties defined in the language

NormMAS-ML. We describe these changes as follows:

• The list of norms contextNorms was added in the classes

jamder.Environment and jamder.Organization. It represents norms whose

environment or organization is defined as context.

• The list of norms restrictNorms was added in the classes

jamder.Environment, jamder.Organization, jamder.agents.GenericAgent and

jamder.roles.AgentRole. It represents norms whose instances of class is an

restricted entity.

• The concepts of right and duty are used in JAMDER to define the actions that

could and should be executed by agents. However, these concepts were

eliminated in NorMAS-ML because they are considered semantically equivalent

to the deontic concepts of permission and obligation in norms. Therefore, it was

necessary to remove the concepts of right and duty from class

jamder.roles.AgentRole.

• The axioms are characterized as a set of laws and rules that agents and sub-

organizations must comply with when linked to a particular organization [Silva,

2004] However, these concepts were eliminated in NorMAS-ML because an

organization or sub-organization can be associated with a norm or a set of norms

that restrict the behavior of agents or sub-organizations that play roles in this

organization or sub-organization. Therefore, the list of axioms was removed

from class jamder.Organization.

• Finally, the following classes representing instances of duty, right, and axiom,

respectively, jamder.behavioural.Duty, jamder.behavioural.Right and

jamder.structural.Axiom were removed along with the class

jamder.behavioural.DutyRightProperty.

With these changes in some JAMDER classes and the creation of new classes

(defined in the previous subsection), the JAMDER 2.0 framework allows the modeling

properties and relationships of entities within a normative multi-agent system. The

complete code of JAMDER 2.0 is found at: https://sites.google.com/site/

uecegessi/estudo-de-caso/jamder-2-0.

AutoSoft

76

5. Case Study

To illustrate the use of the JAMDER 2.0 framework, we used the Conference

Management Systems. This case study has been used by Freire, Rocha Junior and

Cortés (2012) to illustrate the modeling through the norm diagram in MAS-ML tool.

This case study discusses the creation of a normative MAS responsible for managing

submissions of papers, which are identified actors and their roles, organization,

environment and norms, by modeling on MAS-ML tool using the NorMAS-ML

language. After the classes in JAMDER 2.0 will be generated to represent these entities.

The conference management systems are used to select the papers to be published

in a scientific event. For this, authors should submit their papers before a given date

(deadline), from which the reviewers (at least three) initiate the review process. After the

end of review period, the organizers must disclose the results. Authors can: (i) submit your

papers (full or short) until the date of submission, (ii) view the status of your paper, (iii)

view review of the evaluators. Evaluators may: (i) submit papers, (ii) evaluate the papers

that were listed by event organizers. The organizers may (i) extend the period for

submission of papers, (ii) choose the evaluators, (iii) disclose the results of the review.

In the environment Conference Management, we can identify the main organization

Conference and the agent type: user agent that can play the roles: author, speaker,

organizer, conference chair, website manager and reviewer. These roles are defined by

main organization along with object role submitted. The instances of this role are played by

instances of the class Paper that has two subclasses ShortPaper and FullPaper.

5.1. Norms for System

For Conference Management System1, the following norms are defined:

N1: The organizers are prohibited from submit papers.

N2: Reviewers are allowed to submit papers.

N3: The reviewers are prohibited from reviewing their own papers.

N4 (Punishment for violation of N3): The reviewers that violate N3 should

have their role canceled.

N5 (Punishment for violation of N3): The president of the conference is

obliged to drop paper.

Figure 2 shows the modeling of the norms N3, N4 e N5 through the norm

diagram in MAS-ML tool.

5.2. Representing Norms using JAMDER 2.0

In JAMDER 2.0, each one of norms has a simple class structure that contains only the

constructor. The parameters that will be part of the constructor will all instantiated inside

the environment class ConferenceManagement. Figure 3 shows the code for norms system

N3, N4 and N5.

1 The case study is being presented partially due the limitation of number of pages. However, the full version can be

found at: https://sites.google.com/site/uecegessi/estudo-de-caso/jamder-2-0.

AutoSoft

77

Figure 2. Modeling of norms N3, N4 and N5 presented through the norm diagram.

Figure 3. Representing norms N3, N4 and N5 by using JAMDER 2.0.

To represent the environment ConferenceManagement, it is necessary identify

the features that compose each one of norms. These features will be instantiated into the

environment class even before instantiating an entity norm.

N3 norm determines that reviewers (involved entities) from Conference

organization (context) are prohibited (deontic concept) to review (action) your own

articles (activation constraint). Furthermore, N3 norm applies two punishments

(sanction) which are norms N4 and N5. If any reviewer violating N3, norm N4 obliges

(deontic concept) that the reviewer (involved entity) from Conference organization

(context) has canceled the paper (action) and N5 states that the Conference Chair

(involved entity) from Conference organization (context) is obliged (deontic concept) to

import java.util.Hashtable;

import jamder.Organization;

import jamder.norms.*;

import jamder.roles.AgentRole;

public class N3 extends Norm{

public N3 ( String name, NormType normType, AgentRole restrictAgentRoleClass, Organization

contextOrganizationClass, NomAction action, Hashtable<String, NormConstraint> normConstraint,

Hashtble<String, Norm> sactionPunishment){

super(name, normType, restrictAgentRoleClass, contextOrganizationClass, action, normConstraint);

}

}


public N4 (String name, NormType normType, AgentRole rstrictAgentRoleClass, Organization

contextOrganizationClass, NormAction action,Hashtable<String, NormConstraint> normConstraint ){

super(name, normType, restrictAgentRoleClass,

contetOganizationClass, action, normConstraint);

}

}


public N5 (String name, NormType normType, AgentRole rstrictAgentRoleClass, Organization

contextOrganizationClass, NormAction action,Hashtable<String, NormConstraint> normConstraint ){

super(name, normType, restrictAgentRoleClass,

contextOrganizationClass, action, normConstraint);

}

}

AutoSoft

78

discard the article (action). Figure 4 shows the partial code for the environment

ConferenceManagement with norms N3, N4 and N5.

Figure 4. Representing the environment Conference Management using JAMDER 2.0.

6. Conclusion and Future Work

The decrease in gap between semantic representations in design phase and

implementation contributes to increase developer productivity and consistency between

design the entities and its respective code. Additionally, the existence of a mapping

between entities at modeling level and implementation ensures consistency and

traceability between artifacts.

This paper presented the extension of JAMDER framework through a mapping

between modeling and implementation that considers mainly the norms and their

properties, because of limitation in representing normative concepts defined by

modeling language NorMAS-ML. The set of classes associated to JAMDER, here

proposed, received the name JAMDER 2.0, which includes the typical entities of a

normative MAS and their properties.

import jamder.Environment;

import jamder.Organization;

import jamder.norms.*;

import jamder.roles.AgentRole;

import jamder.roles.ProactiveAgentRole;

import jamder.structural.Property;

import java.util.Hashtable;

public class ConferenceManagement extends Environment {

public ConferenceManagement(String name, String host, String port){

super(name, host, port);

//Organization

Organization Conference = new Conference ("Conference", this, null);

addOrganization("Conference", Conference);

//AgentRole Played by Organization

ProactiveAgentRole Organizer = new Organizer("Organizer", Conference, UserAgent);

AgentRole Reviewer = new Reviewer("Reviewer", Conference, UserAgent);

AgentRole ConferenceChair = newConferenceChair("ConferenceChair", Conference, UserAgent);

addAgent("UserAgent", UserAgent);

//Objects

Object Paper = new Paper("Paper");

addObject("Paper", Paper);

//Norma N4

NormResource resourceN4 = new NormResource(Reviewer);

NormAction actionN4 = new AtomicAction(AtomicActionType.AtomicCancel, resourceN4);

Norm N4 = new N4("N4",NormType.OBLIGATION, Reviewer, Conference, actionN4, null);

//Norma N5

NormResource resourceN5 = new NormResource(Paper);

NormAction actionN5 = newAtomicAction(AtomicActionType.AtomicDelete, resourceN5);

Norm N5 = new N5("N5",NormType.OBLIGATION, ConferenceChair, Conference, null, null);

//Norma N3

NormResource resourceN3 = new NormResource(Reviewer.getAction("reviewPaper"));

NormAction actionN3 = new AtomicAction(AtomicActionType.AtomicExecute, resourceN3);

Property first_property = new Property();

Property second_property = new Property();

first_property.setName(Paper.getAuthor());

second_property.setName(Reviewer.getName());

IfConditional constraintN3 = new IfConditional(Operator.EQUALTO, first_property, second_property);

Hashtable<String, NormConstraint> constraintsN3 = new Hashtable<String, NormConstraint>();

constraintsN3.put("contraintN3", constraintN3);

Hashtable<String, Norm> sanctionsPunishmentN3 = new Hashtable<String, Norm>();

sanctionsPunishmentN3.put("N4", N4);

sanctionsPunishmentN3.put("N5", N5);

Norm N3 = new N3("N3", NormType.PROHIBITION, Reviewer, Conference, actionN3, constraintsN3,

sanctionsPunishmentN3);

Conference.addContextNorm("N3", N3);

Reviewer.addRestrictNorm("N3", N3);

}

}

AutoSoft

79

Finally, a case study based on a Conference Management System has been used

to illustrate the use of JAMDER 2.0 framework, demonstrating its applicability and

adequacy for developing normative MASs. As future work, it is relevant to consider the

automatic code generation from the diagram norms of MAS-ML tool, based on

JAMDER 2.0 framework.

References

Casillo, B. H.: Agentes auxiliando ambientes de engenharia de software centrado em

processos. Master Thesis. São José dos Campos: INPE. (2008)

Figueiredo, K. e Silva, V. T.: NormML: a modeling language to model norms. In: 1st

Workshop on Autonomous Software Systems. Salvador, Brazil. (2010)

Freire, E. S. S. ; Cortés, M. I. ; Goncalves, E. J. T. ; Lopes, Y. S.: A Modeling Language for

Normative Multi-Agent Systems. In: 13th International Workshop on Agent-Oriented

Software Engineering (AOSE@AAMAS), 2012, Valencia (Spain). Proceedings of the

13th International Workshop on Agent-Oriented Software Engineering. (2012)

Freire, E. S. S.; Rocha Jr., R. M. ; Cortés, M. I.: Um Ambiente de Modelagem para

Sistemas Multi-Agente Normativos. In: III Workshop on Autonomous Sotware Systems

(Autosoft@CBSoft), 2012, Natal. Proceedings of III Workshop on Autonomous Sotware

Systems. (2012)

Gonçalves, E. J. T.: Modelagem de arquiteturas internas de agentes de software utilizando a

linguagem MAS-ML 2.0. Master Thesis. Universidade Estadual do Ceará. Centro de

Ciência e Tecnologia. Fortaleza. (2009)

Huber, M. J.: JAM Agent. Available at: http://www.marcush.net/IRS (2013)

JACK Agent Language. Available at: http://www.agentsoftware.com.au/products/jack/ (2013)

Java Agent Development Framework. Available at: http://jade.tilab.com/ (2013)

Java-based interpreter for an extended version of AgentSpeak. Available at:

http://jason.sourceforge.net/ (2013)

Lopes, Y. S.; Goncalves, E. J. T.; Cortés, M. I.; Freire, E. S. S.: A MDA Approach Using

MAS-ML 2.0 and JAMDER. In: 13th International Workshop on Agent-Oriented

Software Engineering (AOSE@AAMAS), 2012, Valencia (Spain). Proceedings of the

13th International Workshop on Agent-Oriented Software Engineering (2012)

Nunes, I. O. Implementação do Modelo e da Arquitetura BDI. Pontifícia Universidade

Católica do Rio de Janeiro. Departamento de Informática. Rio de Janeiro (2007)

Russell, S. e Norvig, P.: Inteligência Artificial: uma Abordagem Moderna, 2ª ed. Prentice-

Hall: São Paulo. (2004)

Santos Neto, B. F.: Uma abordagem deontica para o desenvolvimento de agentes

normativos autônomos. Tese de doutorado. Rio de Janeiro: PUC, Departamento de

Informática (2012)

Silva, V. T.: Uma linguagem de modelagem para sistemas multi-agentes baseada em um

framework conceitual para agentes e objetos”, Tese de doutorado. Rio de Janeiro: PUC,

Departamento de Informática (2004)

AutoSoft

80

Reputation in multiagent systems-based simulation: Anapproach using CArtAgO artifacts

Henrique Donancio N. Rodrigues1, Glenda Dimuro2,Gracaliz P. Dimuro1, Diana F. Adamatti1, Esteban de Manuel Jerez2

1Universidade Federal do Rio Grande - FURG

2Depto de Expresion Grafica Arquitectonica, Universidad de Sevilla, Sevilla, Espanha

{henriquedonancio,gracaliz,dianaada}@gmail.com

Abstract. This paper presents the modeling a multi-agent and simulation of thereputation aspects in normative political social organization of the Urban Veg-etable Garden of San Jeronimo, located in Seville, Spain, using the platformJaCaMo. For that, we adapt the MSPP (Modeling and Simulation of PublicPolicies) framework to accomplish internal normative policy of the Urban Veg-etable Garden organization, using normative and reputation CArtAgO artifacts.

1. IntroductionThis project has the purpose to develop simulation tools to ana-

lyze/evaluate/experiment some processes to assist in fostering social participationin collective practices in urban organic agriculture, in particular, the social project ofthe San Jeronimo Urban Vegetable Garden, located in Seville, Spain, coordinated bythe association Ecologistas en Accion (EA). Currently, the beneficiaries of this projectare retired gardeners, local school students and associations for scientific experiments[Dimuro and Jerez 2011, Dimuro 2010, Dimuro and Jerez 2010].

In previous works, several aspects of the modeling of the social organizationof the garden, modeling of the routines of the roles of this organization, special mod-els of agents, modeling of normative policy, among other aspects, were introduced(see [Santos et al. 2014a, Santos et al. 2014b, Santos et al. 2013, Rodrigues et al. 2013a,Santos et al. 2012a, Santos et al. 2012c]).

This paper presents the adaptation of some reputation models for simulating thereputation aspect when considering the internal normative policy of the social orga-nization of San Jeronimo Urban Vegetable Garden (SJVG), using the JaCaMo frame-work, in particular the Jason platform[Bordini et al. 2007], together with the CArtAgO[Ricci et al. 2014] framework, and an adaptation of the MSPP (Modeling and Simulationof Public Policies) [Santos and Costa 2012, Santos et al. 2012b] framework.

The paper is organized as follows. Section 2 presents some basis aspects of Ja-CaMo framework, which is adopted in this work. Section 3 discusses the MSSP frame-work, and in Section 4 we briefly present some reputation models. In Section 5 we presentthe modeling of the normative policy of SJVG Social Organization. Section 6 introducesthe modeling of the reputation. Section 7 is the Conclusion.

2. Multiagent systems and the JaCaMo platformAgents, according to [Bordini et al. 2007], are able to sense the environment ex-

tensively or partially and take actions that can modify it. They are endowed with certain

AutoSoft

81

autonomy to these actions, in contrast to procedural programs, besides communicate andorganize themselves, what one might call a social ability.

The BDI architecture (Beliefs, Desires and Intentions) is characterized by the cog-nitive aspect. Beliefs represent the information the agent has about other agents and theenvironment; desires express goals that the agent intends to achieve; and the intentionsare goals that the agent is committed to achieve.

In the literature, there are various works motivating the using of BDI agents forimplementing/simulating social aspects (e.g., values, trust, reputation) and for agent-based social simulation. See, e.g., the discussions presented in [Caballero et al. 2011,Criado et al. , Farias et al. 2010, Long and Esterline 2000, Farias et al. 2013].

The SJVG (San Jeronimo Urban Vegetable Garden) project adopts the JaCaMoplatform [Boissier et al. 2013, Bordini and Hubner 2014], which is a framework for pro-gramming Multiagent Systems and consists of three tools: Jason, CArtAgO and Moise+.Jason [Bordini et al. 2007] is an interpreter of language AgentSpeak(L), based on the BDIarchitecture. In Jason, cognitive agents can communicate, add beliefs and activate plansdynamically.

CArtAgO framework (Common ARTifact infrastructure for AGents Open envi-ronments) [Ricci et al. 2014] is based on Agents and Artifacts (A & A) to model anddesign Multiagent Systems. With this tool one can create structured artifacts in openspaces where agents can come together in order to work in conjunction. Artifacts are re-sources and tools, built dynamically, manipulated and used by agents to support/performtheir individual and collective activities.

The main elements in CArtAgO are the observable properties, operations and sig-nals. Observable properties are a representation of resources of the environment (e.g.,physical objects, like a “hose”). The operations are implemented to provide an interfacefor a resource to be used by the agents, for example, “the agent uses a hose”. Finally, thesignals allow us to program the resources to notify agents about a situation, which mayuse such signals for decision making (e.g., sending a signal at the end of the month).

The MOISE+ organizational model [Hubner 2003] is a tool in order to modelthe organization of a MAS. Consist in the specification of three dimensions: structural,where roles are defined and linked inheritance and groups; functional, where a set forglobal plans and missions are established so that the goals are achieved; and normativedimension, which is responsible for defining what role has obligation or permission toperform each task.

3. The MSPP frameworkThe framework MSPP (Modeling and Simulation of Public Policies)

[Santos and Costa 2012, Santos et al. 2012b], used in this work, adopts the conceptualbasis of public policy, the approach defined in [Hill 2004, Easton 1965], which, in gen-eral terms, addresses the concept of public policy as a set of actions to find solutions tothe problems of a society, guiding practices and protecting rights in order to meet thedemands and ensuring the collective rights.

The framework for insertion of public policies is materialized in the form of ar-tifacts in CArtAgO model. Two types of normative artifacts are defined: NormObrig

AutoSoft

82

and NormPrb, which model obligation and prohibition norms, respectively, structured asfollows [Santos and Costa 2012]:

Norm (ID; Addressee, Action; Condition; Exception; Sanction; Periodicity). (1)

ID: the identifier of the norm;

Addressee: specifies the role to which norm it applies;

Action: specify an action to be performed by the agent who takes the role to whichthe norm is addressed;

Condition: Specifies a contextual condition for the application of the norm;

Exception: specifies a condition in which the norm does not apply;

Sanction: specifies the penalty to be imposed in case of violation of the norm.

Periodicity: Specifies the event (monthly, weekly or a specific action) for the ac-complish / verification of the norm;

The artifacts are divided into two categories because the structures of obligationand prohibition norms may be different. For example, obligation norms can have period-icity while prohibition norms cannot. In this sense, the MSPP framework presents a goodalternative, presenting a malleable structure for the norms.

The framework also has pre-inserted agents to execute/verify such norms:

• the government agent, which responsible for issuing the norms;• the social agents, which are subjected to the norms while seeking to achieve their

own goals; and• the government agents (detectors/effectors agents), which are responsible for de-

tecting the compliance with the rules as well as characteristics of the environmentand resources, imposing sanctions on possible actions that characterize norm vio-lations, and regulating the resources available in the environment.

With the framework MSPP is possible to build a dynamic environment where therules can be removed, altered, or added at any time.

4. Reputation modelsReputation models can be divided into two groups: centralized reputation models,

where information in relation to an agent generally is obtained from a single source; anddecentralized models, where the evaluation depends on the interaction between the agentsinvolved in the process.

The centralized model of reputation is commonly used in online e-commerce sys-tems, where all information about the reputation is managed centrally. An example isthe SPORAS model [Zacharia 2000]. In SPORAS model, new users receive a minimumvalue of reputation, building their reputation during their activities in the system. Thismight discourage the entry of new users, but it prevents users with a bad reputation leavethe system and come back with a better reputation than the last.

The decentralized model of reputation gives each agent the power to make theirown evaluation on the reputation of other agents, without relying on a central unit. Some

AutoSoft

83

examples of works adopting this model are: Jurca and Faltings [Jurca and Faltings 2002],Regret [Sabater 2003, Sabater and Sierra 2001] and TRAVOS [Teacy et al. 2005]. Regretmodel [Sabater 2003, Sabater and Sierra 2001] is a completely decentralized mechanism,where each agent classifies another in the end of each interaction, and these classificationshave weights according to the time. Regret also divides the evaluation into two dimen-sions, where the Individual Dimension examines only the direct interactions between theinvolved agents, and the Social Dimension, which on some occasions it is possible to ob-tain information about the target agent based on reviews of other agents in the society.TRAVOS [Teacy et al. 2005] adopts a binary classification (1 for successful interaction,and 0 for failure). After interacting with the target agent itself, the evaluator compares thereport of witnesses with its own observations.

In the present study we adopted the model proposed in [Hubner et al. 2009],where the “Reputation Artifact” works as centralized unit that guards the performanceor competence of the agent, visible to other agents. This model was chosen because thecompetence measures can be quantified in a binary form (0 or +1).

The model proposed by Hubner et al. proved to be suitable for this first approachbecause if an agent behaves according to the established rules, the agent will have a goodreputation, while those who does not give contributions, quickly will be deleted by theother agents.

We understood that a hybrid model, such as Regret or [da Silva et al. 2009] wouldbe more adequate for our purpose. Observe that, in the “Individual Dimension”, theagents may have expectations regarding interaction with other agents, and thus a gradedevaluation for the social exchanges rather than a binary form, also based on linguisticvariables and terms, would be more realistic, e.g., a service can be good, very good orvery bad.

In our future works, we expect to insert the Individual Dimension regarding non-economic exchanges between agents. As the work in the ONG is communitarian, anagent can ask helping from others, and this exchange generates values of satisfaction of aservice, as well as credit and debit values among agents [Farias et al. 2013].

5. Modeling the normative policy of SJVG Social OrganizationThe San Jeronimo Urban Vegetable Garden (SJVG) is a social project coordinated

by the Ecologistas en Accion (EA) association, located in Seville, Spain. All the produc-tion is ecological and just for self consumption. However, the participants may exchangeproducts and services, and the social production and management of this organization isregulated by an internal normative policy, which is also discussed and maintained by theSJVG community (vegetable gardeners, auxiliary gardeners, technicians, etc.) in generalmeetings.

The objective of the normative policy is to provide rules for the properfunctioning of the garden organization, establishing obligations and restrictions onthe use of available resources in the environment, guaranteing rights, stimulatinginteractions, exchanges, and so providing equilibrium conditions. For an exten-sive discussion of the SJVG Project and the simulation tools already developed,see [Santos et al. 2014a, Santos et al. 2014b, Santos et al. 2013, Santos et al. 2012a,Santos et al. 2012c, Rodrigues et al. 2013a, Rodrigues et al. 2013b, Farias et al. 2013].

AutoSoft

84

ID Type Action Result/SanctionN16 Prohibition Use hose for watering Serious and cumulative faultN28 Permission Request assistance from a specialized technician Receiving assistanceN29 Prohibition Working in more than one parcel Not serious faultN31 Rights Owning barrel for water -N35 Obligation Organize irrigation turns Serious and cumulative fault

Table 1. Part of the Table of Norms

The gardeners, once included in the project, have the right to use a parcel (an areadesignated for the cultivation and management) for a period of two years (renewable),provided they comply with norms and rules established by the normative policy.

The normative policy is composed by a set of forty norms. It includes four differ-ent types of norms, namely:

• rights norms, which allow gardeners to execute a particular action once it doesnot infringe other norms, that is, right norms give the social agents full powerto exercise that action, without any restrictions provided it does not conflict withother norms;• permission norms, which require the gardener to have permission before executing

a certain action;• obligation norms, which establish the actions the gardeners are obliged to execute;• prohibition norms, which restrict actions that gardeners cannot execute.

Table 1 shows a sample of such norms.

Permission norms are a particular case, because these norms grant the right toperform an action, if previously requested in accordance with the interests of the ONG.For example, we have the permission norm “to plant trees with the largest two-year cycle”.This particular case must be examined by the ONG, since the social agents can stay intothe project by exactly two years (extendable), i.e., the agent may leave the project andabandon its tree.

Santos et al. [Santos et al. 2012b] introduced the Moise+ model of the SJVGsocial organization, identifying the different SJVG organization roles. Among them, weidentified some that fit in the roles of social and governmental agents, and also the publicpolicy issuer agent, as required by the MSSP framework:

• the social agents are those playing the role of gardener, responsible for the culti-vation of their parcels (space for cultivation);• the policy issuer agent is the one playing the role of the EA (Ecologistas en Accion

Association) as a whole, and• there are various governmental agents, such as the ones playing the roles of techni-

cian and secretariat, and, in this paper, all were treated in a single agent responsiblefor the administration (Admin).

Whenever a social agent performs an action specified in the garden regulationas prohibited, or if it fails to comply obligations, then, if the sanction is a serious andcumulative fault (repeated at least three times), the agent is subjected to the assembly todecide its permanency or expulsion from the project. However, if the sanction providedis not serious nor of cumulative type, then the agent is penalized, but an assembly is not

AutoSoft

85

called. Observe that, when an assembly is convened, all other social agents must vote foror against the permanency of the violator agent, based on their values and beliefs aboutthe reputation of the violator agent.

In [Rodrigues et al. 2013], we discussed the adaptation of the framework to thecase study of San Jeronimo Urban Vegetable Garden. We then adapted the MSSP rulestructure of rules given in (1) as follows:

Norm (ID; Type of norm; Action; Sanction; Parameter of extension the sanction)

where:

• Type of norm defines the type of this norm, that is, whether it is a norm of prohi-bition, rights, permission or obligation;• Parameter of extension the sanction specifies if the sanction for the violation of

norms is cumulative or not.

Among the modifications made to adapt the structure of the MSSP rule (given in(1)) to our project, we have omitted the parameters Addressee, since only the gardenersassume the roles of social agents and the norms apply to everyone; Condition, because allconditions are satisfied within the bounds of the modeling; Periodicity, since the structureof the the so-called “Calendar Artifact” introduced in [Rodrigues et al. 2013] is capable tocontrol this aspect; and Exception, since we have not identified a condition under whichthe rules do not apply.

Figure 1 shows the cycle of actions of the simulation of the normative structure ofthe SJVG social organization. The policy issuer agent EA creates artifacts at the beginningof a new simulation, and then it sends signals to the other agents to notify that theseartifacts were created. The social agents then seek the Normative Artifacts and add beliefsregarding the norms, e.g., “+prohibited(sellProducts)”. The social agents also subscribein the “Communication Artifact” and execute focus operation on the artifact “Calendar”for the artifact to inform them about the new actions that should be performed accordingto the SJVG organizational routines [Santos et al. 2014a]. Finally, the social agents inserttheir registers in the “Reputation Artifact”, so reputations can be evaluated by the SJVGcommunity.

The “Communication Artifact” was proposed in [Rodrigues et al. 2013b]. In gen-eral this approach provides a kind of communication beyond the level of the agents, to beimplemented in CArtAgO model artifacts. In this work, the structure was used as follows:

• inform(ID, Receiver, Message)• request(ID, Receiver, Message)

This proposal modularize the communication between the agents in informs (theagent tells something) and requests (the agent makes a request). One advantage to thisapproach is the use of ID’s. In this way, the agent that receives a new message can treatit according to its identification, i.e., trigger plans for a specific event, as in the followingexamples:

• inform(monthlyPayment, admin, payment).• request(participation, admin, renew).

Already “Reputation Artifact” is based on the [Hubner et al. 2009] proposedmodel, using CArtAgO artifacts.

AutoSoft

86

Figure 1. Cycle of actions

Whenever a social agent executes a prohibited action, the name of this infratoragent is registered in the artifact “Penalty Registration” (which represents an abstractionof a notebook). If the agent commits serious and cumulative faults, in the recidivism ofthree times, one assembly is convened to decide its permanency in the project. Then, theother agents, based on the reputation of the infrator agent, manifest themselves in favoror not of its acquittal. If half or more of the agents decide that the infrator agent shouldnot remain in the project, then it has to quit its permanency in the garden.

If the agent is forgiven by the assembly, his record is cleared in the artifact“Penalty Registration”. In future work it is intended that the agents take into accountthe amount of times the agent was subjected to assembly.

6. Modeling Agent ReputationIn this work, reputation is considered as the information that an agent group has

on an individual agent, related to the evaluation of the results obtained by this individ-ual agent within the organization. In particular, the JSVG agent society considers theobedience to the normative policy rules.

This information is stored in the “Reputation Artifact”, a centralized unit for stor-ing information relating to the performance of social agents to the detriment of the nor-mative policy.

The Reputation Artifact is based in CArtAgO model artifact. This artifact is han-dled exclusively by the Admin agent (detector/effector agent), storing the agent’s partici-pation in the group (number of meetings and lectures it attended), obedience (amount offulfilled obligations) and results.

On the other hand, each individual agent has a belief about its respective

AutoSoft

87

Figure 2. A case example: Agent subjected to assembly.

value of the degree of importance attached to those aspects that are shared among thegroup. The individual evaluation performed by each individual agent, adapted from[Hubner et al. 2009], is given by:

γp(α) + δo(α) + εr(α)

γ + δ + ε, (2)

where factors γ, δ and ε define the importance of agents’ participation p(α), obedienceo(α) and results r(α), for an agent α, respectively.

We have adapted the model proposed by [Hubner et al. 2009], in order to obtainmore individual assessments. In our proposal, the factors γ, δ and ε are independent foreach social agent and the agents can take values from 1 to 10, so defining the degree ofrelevance that the agent determines for the factor multiplied by the attribute. In this way,the minimum value given to a particular agent reputation is 0 and the maximum value is1.

Those values are then used by agents in the assembly, to determine the perma-nency (or not) of a certain infrator agent in the SJVG project. In the voting process, eachagent determines a minimum acceptable value to vote for the permanency of the agent.If the value is less than this minimum value, then the agent votes against the permanencyinfrator agent in the project (figure 2).

In the beginning of a new simulation, each agent is responsible for entering itsregister in the “Reputation Artifact”, which then defines an “observable property” (belief)to the agents, for the analysis of the participation, obedience and results values of eachagent.

When an agent subscribes into the “Reputation Artifact”, as in the SPORAS

AutoSoft

88

Figure 3. Simulation of the normative policy

model, the attribute values are the minimum possible for evaluation of the reputation(in this work, we adopt the value 0 for the three attributes). If “n” obligations are assignedto a gardener agent and it has fulfilled all of them, then the obedience attribute is maxi-mum, that is, taking “n” as the number of obligations and “p” as the amount of completedobligations, then obedience is given by “n” divided by “p”, which, in this case, is equalto 1. When an agent performs an action, the number of participation, obedience or resultsreceive an increase (+1). If the agent fails to perform an obligation for example, not to adecrease in their values.

Whenever a new event related the norms happens, the reputation value is changedand the agents’ belief bases are updated. If any agent is subjected to the assembly, thesevalues are fetched on the beliefs base of the agent, each one multiplied by its importancefactor.

Figure 3 shows an example of a simulation. The agent pedro has the cri-terium to consider the action “sell products” (this action is represented by the parametervenderProdutos), which is an action that corresponds to an infraction of the normsof the project regulation. However, agent pedro still decides to execute such action (lines4 and 11). When the agent agent “pedro” commits this offense for the third time (line11), the Admin agent calls an assembly to decide its permanency (line 17) in the SJVGproject. The Voters are all the social agents that are participants of the project, except theagent that will be voted. The value of the composition given by 2 is sent by the agent(lines 16, 19 and 21) 1 and its decision obeys the minimum value it set for the agent toremain. Table 2 shows the degree of importance assigned to each criterion that composesthe evaluation of agent reputation for this case.

When the evaluating aspects (results, obligations and participation of the agentin the project) are processed, the Reputation Artifact acts as a measure of competenceof this agent. As in the Regret model, this analysis can be understood as the Social

1The agent being judged receive the calling for the assembly, but does not complete this plan.

AutoSoft

89

Agent γ δ εcicero 5 8 10genaro 7 2 8lucas 3 10 8pedro 9 1 4

Table 2. Importance Factors

Dimension of SJVG project. It is understood that a new dimension (Single Dimension)can also be created through a new Reputation Artifact, including ratings resulting fromdirect interactions between agents.

7. Conclusion and Further WorksIn our previous work, we discuss the advantages of the use of the framework

MSPP in contrast of the Moise+ model, in the particular case of the SJVG social or-ganization modeling [Santos et al. 2014b, Rodrigues et al. 2013a], since the frameworkMSPP contemplates the periodicity of actions, and is adequate to model the structure ofthe norms and their applications. Then, in [Rodrigues et al. 2013a], we introduced a pro-posal for the modeling and simulation of the normative policy of the Urban VegetableGarden of San Jeronimo social organization.

In the present paper, we present an approach to consider the agents’ reputationand its influence in the collective decision about the permanency (or not) of an agent inthe project, taking into account the agent’s results, obligations and participation in theproject, weighted by the importance that each other agent gives independently to theseaspects.

In future works, we intend to assign weights in the actions of agents, similar tothe Regret model, [Sabater 2003, Sabater and Sierra 2001] for recent actions that havemore relevance for the evaluation, thus considering a temporal analysis. We will alsoadopt a classification of direct interactions between social agents, similar to TRAVOSmodel [Teacy et al. 2005], but with broader values, using tools such as fuzzy logic(see,e.g. [Farias et al. 2010]).

7.0.1. Acknowledgment

This work was supported by CNPq (Proc. 481283/2013-7, 306970/2013-9) andProjeto RS-SOC (FAPERGS Proc. 10/0049-7).

ReferencesBoissier, O., Bordini, R. H., Hubner, J. F., Ricci, A., and Santi, A. (2013). Multi-agent

oriented programming with JaCaMo. Science of Computer Programming, 78(6):747 –761.

Bordini, R. H. and Hubner, J. F. (2014). Jacamo project. http://jacamo.sourceforge.net/.

Bordini, R. H., Hubner, J. F., and Wooldridge, M. (2007). Programming Multi-AgentSystems in AgentSpeak using Jason. Wiley, New Jersey.

AutoSoft

90

Caballero, A., BotAa, J., and Gomez-Skarmeta, A. (2011). Using cognitive agents insocial simulations. Engineering Applications of Artificial Intelligence, 24(7):1098 –1109. Infrastructures and Tools for Multiagent Systems.

Criado, N., Argente, E., Noriega, P., and Botti, V. Human-inspired model for norm com-pliance decision making. Information Sciences. Statistics with Imperfect Data.

da Silva, V. T., Hermoso, R., and Centeno, R. (2009). A Hybrid Reputation Model Basedon the Use of Organizations. Springer.

Dimuro, G. (2010). Sistemas urbanos: el estado de la cuestion y los ecosistemas comolaboratorio. Arquitextos, 124:11.

Dimuro, G. and Jerez, E. M. (2010). Comunidades en transicion: Hacia otras practicassostenibles en los ecosistemas urbanos. Cidades Comunidades e Territorios, 20-21:87–95.

Dimuro, G. and Jerez, E. M. (2011). La comunidad como escala de trabajo en los ecosis-temas urbanos. Revista Ciencia y Tecnologıa, 10:101–116.

Easton, D. (1965). A Framework for Political Analysis. Prentice-Hall.

Farias, G. P., Dimuro, G., Dimuro, G., and Jerez, E. D. M. (2013). Exchanges of servicesbased on Piaget’s theory of social exchanges using a BDI-fuzzy agent model.

Farias, G. P., Dimuro, G. P., and Costa, A. C. R. (2010). BDI agents with fuzzy perceptionfor simulating decision making in environments with imperfect information.

Hill, M. (2004). The Public Policy Process. Pearson Longman, 4 edition.

Hubner, J. F. (2003). Um Modelo de Reorganizacao de Sistemas Multiagentes. PhDthesis, Universidade de Sao Paulo, Sao Paulo.

Hubner, J. F., Vercouter, L., and Boissier, O. (2009). Instrumenting Multi-Agent Organi-sations with Artifacts to Support Reputation Processes. Springer.

Jurca, R. and Faltings, B. (2002). Towards incentive-compatible reputation management.In Trust, Reputation, and Security: Theories and Practice, pages 138–147.

Long, S. A. and Esterline, A. C. (2000). Fuzzy BDI architecture for social agents. In Pal,N. R., Kasabov, N., Mudi, R. K., Pal, S., and Parui, S. K., editors, Proceedings IEEESoutheastcon 2000, pages 68–74, Los Alamitos. IEEE.

Ricci, A., Santi, A., and Piunti, M. (2014). CArtAgO (common atifact infrastructure foragents open environments).

Rodrigues, H. D. N., Santos, F. C. P., Dimuro, G., Adamatti, D. F., Jerez, E. M., andDimuro, G. P. (2013a). A mas for the simulation of normative policies of the urbanvegetable garden of san jeronimo, seville, spain.

Rodrigues, T. F., Costa, A. C. R., and Dimuro, G. P. (2013b). A communication infras-tructure based on artifacts for the JaCaMo Platform.

Sabater, J. (2003). Trust and Reputation for Agent Societies. PhD thesis, UniversitatAutonoma de Barcelona, Barcelona.

AutoSoft

91

Sabater, J. and Sierra, C. (2001). Reputation model for gregarious societies. In Proceed-ings of the Fourth Workshop on deception Fraud and Trust in Agent Societies, pages61–70.

Santos, F., Rodrigues, T., Donancio, H., Santos, I., Adamatti, D. F., Dimuro, G. P.,Dimuro, G., and Jerez, E. D. M. (2014a). Towards a multi-agent-based tool for theanalysis of the social production and management processes in a urban ecosystem: anapproach based on the integration of organizational, regulatory, communication andphysical artifacts in the JaCaMo framework. In Adamatti, D., Dimuro, G. P., andCoelho, H., editors, Interdisciplinary Applications of Agent-Based Social Simulationand Modeling, pages 287–311. IGI Global.

Santos, F. C. P., Rodrigues, H. D. N., Rodrigues, T. F., Dimuro, G., Adamatti, D. F.,Dimuro, G. P., and Jerez, E. M. (2013). Integrating cartago artifacts for the simula-tion of the social production and management of urban ecosystems: the case of sanjeronimo vegetable garden of seville, spain.

Santos, F. C. P., Rodrigues, T. F. Rodrigues, H. D. N., Dimuro, G., Adamatti, D. F.,Dimuro, G. P., and Jerez, E. M. (2014b). Analyzing the problem of the modeling ofperiodic normalized behaviors in multiagent-based simulation of social systems: Thecase of the san jeronimo vegetable garden of seville, spain. In Advances in SocialSimulation, pages 61–72.

Santos, F. C. P., Rodrigues, T. F., Dimuro, G., Adamatti, D. F., Dimuro, G. P., Costa,A. C. R., and Jerez, E. M. (2012a). Modelando organizacao social de um sma parasimulacao dos processos de producao e gestao social de um ecossistema urbano: ocaso da horta san jeronimo da cidade de sevilla, espanha. pages 93–104. UFSC.

Santos, I. and Costa, A. C. R. (2012). Toward a framework for simulating agent-basedmodels of public policy processes on the jason-cartago platform. In Proceedings ofthe Second International Workshop on Agent-based Modeling for Policy Engineeringin 20th European Conference on Artificial Intelligence (ECAI)- AMPLE 2012, Mont-pellier. Montpellier University.

Santos, I., Mota, F. P., Costa, A. C. R., and Dimuro, G. P. (2012b). Um framework parasimulacao de polıticas publicas aplicado ao caso da piracema, sob o olhar da teoria dosjogos. Porto Alegre. SBC.

Santos, I., Rodrigues, T. F., Dimuro, G. P., Costa, A. C. R., Dimuro, G., and Manuel, E.(2012c). Towards the modeling of the social organization of an experiment of socialmanagement of urban vegetable gardens. pages 98–101.

Teacy, W. T. L., Patel, J., Jennings, N. R., and Luck, M. (2005). Coping with inaccuratereputation sources: experimental analysis of a probabilistic trust model. In Proceed-ings of the 4th International Joint Conference on Autonomous Agents and MultiagentSystems (AAMAS 2005), pages 997–1004.

Zacharia, G. M. P. (2000). Trust management through reputation mechanisms. AppliedArtificial Intelligence Journal.

AutoSoft

92

Adaptação de Artefatos de Software em Tempo de Execuçãoutilizando Aspectos e Reflexão

Samuel Davi Müller de Souza1, Frank José Affonso1, Elisa Yumi Nakagawa2

1 Departamento de Estatística Matemática Aplicada e Computação (DEMAC)Universidade Estadual Paulista (UNESP)

Rio Claro – SP – Brazil

2Departamento de Sistemas de Computação (SSC)Universidade de São Paulo (USP)

São Carlos – SP – Brazil

[email protected], [email protected], [email protected]

Abstract. The development of Self-adaptive System (SaS) is a complex task,since this type of software deals constantly with structural and/or behavioralchanges at runtime. In parallel, Reference Architectures (RAs) capture the ar-chitecture essence of a collection of similar systems, facilitating the design ofconcrete architectures for new systems, new versions or extensions of similarproducts. Based on this scenario, the main contribution of this paper is to pre-sent the implementation of the adaptation module of a RA based on aspect andreflection for SaS [Affonso and Nakagawa, 2013]. The main purpose of this mo-dule is to support the adaptation of SaS automatically. To show the viability ofthis module (RA), a case study is presented. As result, it has been observed thatour RA has presented good perspective to efficiently contribute to the SaS area.

Resumo. O desenvolvimento de Software autoadaptativo (Saa) é uma atividadecomplexa, pois este tipo de software lida constantemente com mudanças estru-turais e comportamentais em tempo de execução. Em paralelo, Arquiteturas deReferência (AR) capturam a essência das arquiteturas de sistemas semelhantes,facilitando o projeto de arquiteturas concretas de novos sistemas, novas versõesou extensões de produtos similares. Baseado neste contexto, este artigo apre-senta a implementação do módulo de adaptação de uma AR para Saa [Affonsoand Nakagawa, 2013]. O propósito deste módulo é viabilizar a adaptação deSaa de maneira automática. Para mostrar a aplicabilidade deste módulo (AR),um estudo de caso foi conduzido e os resultados permitem-nos acreditar queeste trabalho tem boas perspectivas para contribuir com a área de Saa.

1. IntroduçãoNa sociedade moderna os sistemas de software têm ocupado um papel importante, atu-ando em diversos segmentos, tais como: instituições públicas e privadas, aeroportos, sis-temas de comunicação, entre outros. Esses sistemas devem ser preparados para operarem funções normais ou adversas, mantendo seu estado de execução. As condições ad-versas fazem com que esses sistemas tenham que se ajustar/adaptar em relação às novascondições de execução, sejam elas por novas necessidades de seus usuários ou por mu-danças ocorridas no ambiente de execução. Sistemas de software que permitem obter

AutoSoft

93

informações sobre si mesmo como forma de melhorar seu desempenho, introduzir novascapacidades (estruturais e/ou comportamentais), ou ainda, resolver seus problemas esco-lhendo o melhor procedimento são conhecidos como sistemas autoadaptativos1 [Maes,1987], [Coulson et al., 2004], [Vinoski, 2005], [Morin et al., 2009].

A adaptação de software, quando executada manualmente, torna-se uma atividadeonerosa (tempo, esforço e dinheiro) e propensa a erros (injeção involuntária de incerte-zas pelos desenvolvedores). Como forma de contornar essas adversidades, abordagensautomatizadas têm sido adotadas, pois representam uma solução factível para maximizara velocidade de implementação de Saa e, ao mesmo tempo, minimizar o envolvimentodos desenvolvedores na atividade de adaptação [Vinoski, 2005], [Andersson et al., 2009],[Salehie and Tahvildari, 2009], [Affonso and Rodrigues, 2012].

Em outra perspectiva, Arquiteturas de Referência (AR) referem-se a um tipo espe-cial de arquitetura de software que se tornou um elemento importante para a reutilizaçãosistemática de conhecimento arquitetural. O principal objetivo de tais arquiteturas é fa-cilitar e guiar [Nakagawa et al., 2012]: (i) a concepção de arquiteturas concretas paranovos sistemas; (ii) as extensões dos sistemas de domínios vizinhos de uma AR; (iii) aevolução dos sistemas que foram derivados da AR; e (iv) a melhoria na padronização einteroperabilidade entre sistemas. No entanto, apesar da relevância deste assunto para odesenvolvimento de Saa, existe uma carência de AR que suportem o desenvolvimento detais sistemas. Portanto, Saa têm sido desenvolvidos sem a preocupação com reutilizaçãodo conhecimento previamente adquirido e experiências, tais como: melhores práticas,diretrizes de desenvolvimento e estilos arquiteturais para a Saa.

Baseado nesse cenário, este trabalho visa apresentar a implementação do módulode adaptação da AR para Saa (AR-Saa) [Affonso and Nakagawa, 2013]. Essa arquiteturaé baseada em aspectos e reflexão, que são importantes recursos para: (i) segmentação deinteresses, e (ii) inspeção e modificação de artefatos de software em tempo de execução.Basicamente, essa AR permite sistematizar o desenvolvimento de artefatos de softwaree conduzir, por meio de processos automatizados, a adaptação de tais artefatos. Comoforma de mostrar a viabilidade dessa arquitetura, um estudo de caso foi conduzido e osresultados permitem-nos visualizar boas perspectivas de contribuição para o desenvolvi-mento de Saa.

Este artigo está organizado da seguinte maneira: na Seção 2 são apresentadosconceitos, definições e os trabalhos relacionados; na Seção 3 é apresentada uma brevedescrição da AR-Saa e os detalhes de implementação do módulo de adaptação; na Seção4 é apresentado um estudo de caso; finalmente, as conclusões e perspectivas de trabalhosfuturos são apresentadas na Seção 5.

2. Conceitos, Definições e Trabalhos Relacionados

Esta seção apresenta os conceitos, definições e trabalhos relacionados que contribuírampara o desenvolvimento deste artigo.

1 O termo sistemas autoadaptativos é utilizado em diferentes áreas/domínios. Neste artigo ele irá se con-centrar apenas ao domínio de software. Portanto, será referenciado deste ponto em diante como Softwareautoadaptativo (Saa).

AutoSoft

94

2.1. Conceitos e DefiniçõesReflexão computacional, ou simplesmente a reflexão, pode ser definida como qualqueratividade executada por um sistema de software sobre si mesmo. O principal objetivoé obter informações sobre seu estado atual como forma de melhorar seu desempenho,introduzir novas capacidades (estruturais ou comportamentais), ou ainda, resolver seusproblemas escolhendo o procedimento mais adequado [Maes, 1987], [Vinoski, 2005],[Andersson et al., 2009], [Erradi et al., 1992].

A Programação Orientada a Aspectos (POA) é um paradigma de programaçãoque permite separar e organizar o código fonte de acordo com a sua importância para aaplicação (separation of concerns), evitando o espalhamento e, consequentemente, otimi-zando a manutenibilidade do sistema [Kiczales et al., 1997], [Kiczales et al., 2001]. Aseguir, alguns dos principais usos de reflexão e aspectos para a adaptação de software sãoexemplificados.

Reflexão. Borde et al. [2009] propuseram uma técnica baseada em reflexão para aadaptação de componentes de software em estrutura e comportamento. As funcionalida-des originais são preservadas e outras (novos requisitos) são adicionadas, constituindo umnovo componente de software. A reflexão também tem sido usada com sucesso na adapta-ção da arquitetura de software. Shi et al. [2006] e Peng et al. [2008] criaram arquiteturasde software reflexivas em dois níveis: (i) meta, que possui componentes arquiteturais,informações que descrevem a topologia da arquitetura e conectores. Esse nível é o localonde são “idealizadas” e aplicadas as mudanças nos sistemas de software; (ii) base, quepode ser considerado como arquitetura de software tradicional.

Aspectos. Tanter et al. [2008] propuseram uma ferramenta, baseada em reflexãoe aspectos, chamada Reflex. Esta ferramenta permite que sejam realizadas modificaçõesestruturais e comportamentais nos artefatos de software. Já Janik and Zielinski [2010]desenvolveram uma técnica para adaptar os requisitos não-funcionais, preservando o ní-vel funcional. Os autores propuseram uma extensão POA chamada POA Adaptável, querepresenta um conjunto de aspectos não-funcionais adaptáveis que são integrados ao soft-ware em tempo de execução. Assim, observa-se que já existem iniciativas importantes douso de reflexão e aspectos para o desenvolvimento de sistemas de software.

2.2. Trabalhos RelacionadosEm relação aos trabalhos relacionados, AR e modelos de referência para Saa têm sidoencontrados na literatura. Liu et al. [2008] propuseram uma AR para sistema orientadosa serviços baseada no mecanismo de auto-organização (self-organizing). O principal ob-jetivo dessa arquitetura é apoiar a construção de componentes auto-organizáveis sem aparticipação dos seres humanos. Para isso, esses componentes são capazes de monitorare controlar suas modificações de maneira transparente, ou seja, sem a percepção dos seusinteressados.

Weyns et al. [2010a] propuseram um modelo de referência, baseado em reflexão,chamado FORMS (FOrmal Reference Model for Self-adaptation). Como forma de mos-trar a aplicabilidade desse modelo, os autores instanciaram em dois domínios: (i) com-posição de sistemas autônomos usando o modelo MAPE-K [Kephart and Chess, 2003];e (ii) veículos não tripulados. Paralelamente, um modelo de referência baseado nos me-canismos de autocura (self-healing) e auto-otimização (self-optimizing) foi proposto por

AutoSoft

95

Weyns et al. [2010b]. Este modelo suporta o desenvolvimento de Saa em uma abordagemdescentralizada. Na tentativa de validar tal modelo, os autores apresentaram dois exem-plos: (i) câmeras inteligentes para monitoramento de congestionamento de transito; e (ii)melhoria de qualidade de serviços via reimplantação de componentes.

Kramer and Magee [2007] apresentaram uma abordagem arquitetural para siste-mas autogerenciáveis (self-* ou autonomic systems). Os autores propuseram um modeloarquitetural com características reflexivas organizado em dois níveis: meta e base. Asmodificações realizadas no nível base (aplicação) são realizadas através de um plano deação (criado no nível meta), que determina quais modificações podem ser implementadasno nível base.

Os trabalhos relacionados apresentados nesta seção mostram importantes evidên-cias sobre o uso de AR e modelos de referência para Saa. Portanto, pode-se dizer queesforços em tentar estabelecer AR para tais sistemas é uma alternativa interessante, in-cluindo arquiteturas que exploram reflexão e aspectos para o desenvolvimento de Saa.

3. Adaptação de Artefatos de Software em Tempo de ExecuçãoEsta seção apresenta uma breve descrição da AR-Saa. Em seguida, é apresentada umadescrição do módulo de adaptação de artefatos de software em tempo de execução dessaarquitetura.

3.1. Arquitetura de Referência

De acordo com Affonso and Nakagawa [2013] e Affonso et al. [2013], a AR-Saa (Figura1) é composta por um núcleo de adaptação (linha pontilhada) e quatro módulos com-plementares: desenvolvimento, plano de ação, regras de adaptação, e infraestrutura. Aseguir, uma breve descrição dessa arquitetura é apresentada.

Figura 1. Arquitetura de referência para Saa [Affonso and Nakagawa, 2013]

Desenvolvimento. Este módulo fornece um conjunto de diretrizes para o desen-volvimento de artefatos de software, que atuam nas seguintes fases: análise de requisitos,projeto, implementação e evolução (adaptação). Resumidamente, os artefatos de softwaresão desenvolvidos contendo apenas atributos, construtores e métodos getters e setters.

AutoSoft

96

Além disso, tais artefatos são organizados em estilos arquiteturais em camadas2. Por fim,este módulo é apoiado pelo módulo de anotações (núcleo de adaptação) para definição donível de adaptação de cada artefato.

Plano de Ação. Este módulo auxilia na atividade de adaptação de artefatos desoftware controlando o comportamento dinâmico, os motivos individuais, e o estado deexecução em relação ao ambiente de execução. Para isso, a AR-Saa adotou o loop decontrole MAPE-K (Monitor, Analyze, Plan, Execute, and Knowledge) como uma soluçãopara gerenciar a adaptação em tempo de execução [Salehie and Tahvildari, 2009], [IBM,2005], [Dobson et al., 2006].

Regras de Adaptação. Este módulo é responsável por extrair automaticamenteas regras de adaptação para cada artefato de software. Em resumo, quando um artefatoé desenvolvido e inserido no ambiente de execução, um metamodelo é instanciado pelomódulo de reflexão. A partir desse metamodelo, um mecanismo automático chamadoFábrica de Regras extrai as informações que descrevem tais artefatos (estrutura,comportamento, nível de adaptação suportado) e cria as regras no formato do frameworkDROOLS3. Finalmente, essas regras são armazenadas em repositórios (base de regras) ereutilizadas em futuras adaptações.

Infraestrutura. Este módulo fornece suporte para adaptação dos artefatos desoftware em tempo de execução, dispondo de um conjunto de mecanismos que atuam emdiversos contextos. Dentre eles, três mecanismos se destacam: (i) Compilação dinâmica ecarregamento dinâmico: permite compilar e substituir um artefato de software em tempode execução sem a necessidade de reiniciar a aplicação ou reimplantar seus componentes;(ii) Diagnóstico de problemas: permite identificar e comunicar problemas que ocorremquando uma atividade de adaptação está sendo executada; e (iii) Autocura: permite cor-rigir problemas em tempo de execução quando uma atividade de adaptação está sendorealizada.

Núcleo de adaptação. Esta é a principal estrutura da AR-Saa, pois é composta porum conjunto de módulos que são os responsáveis por gerenciar a adaptação dos artefatosde software em tempo de execução. Este núcleo está organizado em seis módulos: (i)pesquisa, (ii) anotação, (iii) estado, (iv) código fonte, (v) reflexão, e (vi) adaptação. Aseguir, uma breve descrição de cada módulo é apresentada.

Pesquisa. Este módulo auxilia na busca de artefatos de software no ambientede execução. Basicamente, este módulo possui dois métodos de pesquisa: (1) semân-tico: quando são fornecidas informações (estruturais e/ou comportamentais) dos arte-fatos de software para se compor um modelo de relacionamento semântico (Artefato-Artefato, Artefato-Atributo, Artefato-Método, ou Artefato-Atributo-Método); ou (2) téc-nico: quando informações que descrevem os artefatos de software (artefato, atributo oumétodo) no formato do metamodelo (módulo de reflexão) são fornecidas. Esse metamo-delo é convertido como parâmetro de entrada para pesquisa no repositório de regras.

2 O estilo em camadas visa auxiliar na separação de interesses e aumentar a flexibilidade e facilidade demanutenção do software do sistema. Além disso, facilita a utilização de suporte automatizado na adaptaçãode artefatos [Peng et al., 2008], [Shi et al., 2006]. As diretrizes da AR-Saa orientam o desenvolvimento deartefatos segundo o padrão arquitetural MVC (Model-View-Controller) [Buschmann et al., 1996]

3 http://drools.jboss.org

AutoSoft

97

Anotação. Este módulo auxilia os engenheiros de software na definição do nívelde adaptação dos artefatos de software na fase de desenvolvimento. Assim, pode-se dizerque tais artefatos são desenvolvidos em uma modalidade de adaptação controlada, pois asmodificações (estruturais e/ou comportamentais) podem ser aplicadas apenas em locaisestabelecidos, ou seja, onde foram definidas anotações.

Estado. Este módulo tem por objetivo preservar o estado de execução vigente dosartefatos software. Quando um artefato é selecionado para ser adaptado, as informaçõescontidas em seu estado atual devem ser preservadas. Em seguida, o artefato é modificadoe suas informações são reinseridas para que a sua execução não seja interrompida.

Código fonte. Este módulo tem por objetivo gerar o código fonte dos novos ar-tefatos de software (adaptados) com base no metamodelo instanciado pelo módulo dereflexão. Para executar esta operação, o engenheiro de software deve fornecer um modelode artefato de software com base em um estilo arquitetural em camadas.

Reflexão. Este módulo está organizado em dois submódulos. O primeiro temcomo objetivo auxiliar na “desmontagem” e “montagem” dos artefatos de software.Quando o processo de desmontagem é iniciado, informações estruturais e comportamen-tais são recuperadas pelo módulo de reflexão e inseridas em um metamodelo4 (segundosubmódulo). A Figura 2 mostra esse metamodelo.

Figura 2. Metamodelo de artefatos de software

Adaptação. Este módulo pode ser considerado como “orquestrador” da AR-Saa,pois coordena todas as atividades dos demais módulos. Basicamente, atua como um sis-tema supervisor de atividades dos artefatos de software no ambiente de execução, moni-torando suas chamadas para outros artefatos e requisições de outros artefatos. Para que

4 Este metamodelo permite a adaptação de sistemas de software orientados a objetos ou que fazem usoda estrutura de classes como unidades de sistemas de software.

AutoSoft

98

um artefato seja adaptado em tempo de execução, este módulo implementa um processocom uma sequência de passos bem definida, que será apresentada em maiores detalhes naSeção 3.2.

3.2. O Módulo de Adaptação de Artefatos de Software

A proposta de adaptação deste módulo é baseada no loop de controle MAPE-K, comomostra a Figura 3. Os artefatos de software são monitorados no ambiente de execuçãoe parâmetros sobre as modificações (novas necessidades dos usuários ou mudanças noambiente) são coletados pelos sensores. Esses parâmetros são “transformados” em sin-tomas para identificar as mudanças ocorridas (classificação do problema). Em seguida,com base nesses sintomas, um ou mais tratamentos são recomendados. Esses tratamentossão ranqueados conforme critérios de suporte e confiança (classificador probabilístico).Como forma de minimizar os efeitos colaterais que uma atividade de adaptação podegerar, testes para validar as possíveis mudanças (tratamentos) devem ser realizados. Fi-nalmente, uma lista de soluções é exibida e a escolha do tratamento é realizada com basenos critérios de confiança e ausência de efeitos colaterais.

Figura 3. Loop de controle utilizado na AR-Saa

Conforme apresentado neste artigo (Seção 2), a adaptação de software é uma ati-vidade complexa (composta por várias etapas) que deve ser realizada com suporte au-tomatizado. Assim, esta seção apresenta a implementação do módulo de adaptação deartefatos de software em tempo de execução da AR-Saa. Tal módulo permite que adap-tação de software seja conduzida de maneira automática (ou seja, sem a participação deseres humanos) em uma sequência de passos bem definida. Para isso, dois recursos com-putacionais importantes foram utilizados: (i) aspectos: permitem interceptar chamadas(protocolo de comunicação) entre o sistema supervisor (Figura 4) e o artefato de softwaresupervisionado. Além disso, permitem reduzir a transversalidade de interesses entre osistema supervisor e o artefato de software supervisionado; e (ii) reflexão: permite reali-zar a descoberta de informações dos artefatos e modificá-los (estrutura e comportamento)em tempo de execução. Assim, com a implementação de tal módulo espera-se que: (a)os artefatos de software sejam modificados de maneira transparente sem a percepção deseus usuários; (ii) incertezas injetadas involuntariamente pelos desenvolvedores sejam re-duzidas ou extintas; e, (iii) a complexidade de implementação seja reduzida. A Figura 4mostra o processo de adaptação de artefatos de software.

AutoSoft

99

Figura 4. Processo de adaptação de artefatos de software em tempo de execução

O modelo de adaptação proposto (Figura 4) está organizado em dois níveis: (i)base, representa o ambiente de execução onde são hospedados os artefatos de software;e (ii) meta, representa o ambiente de adaptação onde ocorrem as mudanças nos artefatosde software. Dessa forma, quando um artefato é desenvolvido e inserido no ambiente deexecução (nível base), um sistema supervisor é a ele acoplado como forma de monitorara comunicação com outros artefatos e adaptar sua estrutura e/ou comportamento quandonecessário. Para que um artefato de software possa ser monitorado é necessário “injetar”um atributo desse artefato como membro do sistema supervisor (passo 1). O modo deinterceptação dinâmica (monitoramento do sistema supervisor) tem suporte da POA [AS-PECTJ, 2014] (passo 2). Operacionalmente, esse sistema supervisor permite monitorarum artefato nas seguintes situações: (i) quando uma chamada ou execução de um mé-todo for realizada; (ii) quando houver o tratamento de exceções; (iii) quando um artefatofor inicializado. Assim, quando houver necessidade de mudança, em uma das situaçõesmencionadas, o processo de adaptar um artefato de software é conduzido por meio de umaspecto em três etapas:

1. Antes da execução do método (before - passo 3). O artefato de software é des-montado pelo módulo de reflexão e suas informações estruturais e/ou compor-tamentais são inseridas em um metamodelo. Além disso, as informações nelecontidas são recuperadas para futura restauração (passo 5);

2. Durante a execução do método (around - passo 4). As mudanças estruturais e oucomportamentais são inseridas no metamodelo obtido no passo 3. Tais mudançasrepresentam uma solução para a necessidade de adaptação que foi detectada pelossensores (Figura 3). A partir do novo metamodelo, o código fonte do artefato égerado pelo módulo de código fonte da AR-Saa; e

3. Depois de sua execução (after - passo 5). O módulo de infraestrutura, maisespecificamente o compilador, compila o código fonte gerado no passo 4 e criauma nova instancia do novo artefato. Em seguida, são inseridas as informaçõesrecuperadas do artefato de software no passo 3. Finalmente, o artefato é devolvidoao ambiente de execução (nível base) pelo sistema supervisor (passo 6).

AutoSoft

100

4. Estudo de Caso

Antes de iniciar a apresentação deste estudo de caso, quatro considerações devem serressaltadas: (i) a AR-Saa foi instanciada para a linguagem de programação Java5 e, pormotivos de espaço, os detalhes de implementação não serão apresentados neste artigo;(ii) alguns passos serão omitidos, sendo destacados apenas os essenciais para mostrar ofuncionamento do módulo de adaptação apresentado na Seção 3.2; (iii) a adaptação dosartefatos de software será conduzida pelo engenheiro de software, pois nosso objetivoé mostrar o funcionamento do módulo de adaptação. A autoadaptação é apoiada poreste módulo e outros módulos da AR-Saa, os quais não serão abordados neste artigo;e, (iv) conforme apresentado na descrição da AR e do módulo de adaptação, dois tiposde adaptação são suportados: estrutural e comportamental. Neste artigo, por motivos deespaço, apenas a adaptação estrutural será apresentada como mostra a Figura 5.

Figura 5. Artefato de software cliente

Para mostrar a aplicabilidade do módulo de adaptação, dois tipos de modifica-ção foram considerados: (1) Associação de novas funcionalidades, que corresponde àadição de novas informações (artefatos) a um artefato de software pelos relacionamen-tos de agregação, composição, ou associação; e (2) Extensão de novas funcionalidades,que corresponde à adição de novas informações (artefatos) a um artefato de software pelorelacionamento de herança. As transições (a)->(b) e (b)->(c) da Figura 5 representam,respectivamente os tipos de adaptação 1 e 2. A seguir é apresentada uma breve descriçãode cada um deles.

5 http://www.oracle.com/br/technologies/java/overview/index.html

AutoSoft

101

Tipo 1: (a)->(b). O artefato de software Cliente (Diagrama UML6 - parte(a)), foi inicialmente desenvolvido para atuar em um sistema local de uma livraria. Paramostrar o primeiro tipo de adaptação foi considerada a necessidade de modificar esseartefato para que possa atuar em um sistema web com autenticação. Assim, após localizartal artefato no ambiente de execução (nível base), o engenheiro de software insere asinformações desejadas (nível meta) para que o novo artefato seja gerado (Diagrama UML- parte (b)). Finamente, o artefato de software é devolvido ao nível base para ser utilizadonovamente.

O trecho de código fonte (a->b) mostra os principais comandos para a criaçãodo artefato Acesso e sua associação com o artefato Pessoa. Inicialmente, linhas 1 a4, é criado o atributo usuario com modificador de acesso, tipo de dados e nome. Oatributo senha foi criado de maneira similar. Nas linhas 7 a 9 é apresentada a cria-ção do artefato Acesso e a associação dos atributos usuario e senha a tal artefato.Finalmente, na linha 10, o novo artefato Acesso é associado ao artefato Pessoa. Oprimeiro parâmetro (cls) representa o artefato que está sendo criado (Acesso). O se-gundo parâmetro ("Pessoa") indica o nome do artefato no metamodelo que será asso-ciado ao novo artefato (primeiro parâmetro). Os dois últimos parâmetros (ONE-to-ONEe AG-UN-2) indicam, respectivamente, a cardinalidade e o tipo de associação entre os ar-tefatos. Nesta associação tem-se um relacionamento de composição com navegabilidadeunidirecional (Pessoa para Acesso). O modelo UML (b) mostra o novo artefato desoftware Cliente que pode atuar em um sistema web com autenticação.

Tipo 2: (b)->(c). Para mostrar o segundo tipo de adaptação será considerada anecessidade de modificar o artefato de software Cliente (Diagrama UML - parte (b))para atuar como Estudante em um sistema de gestão escolar (Diagrama UML - parte(c)). Para isso, o engenheiro de software faz a especificação do artefato desejado ao mó-dulo de pesquisa da AR-Saa, que tenta localizar tal artefato no ambiente de execução.Quando localizado, artefato e especificação do engenheiro de software são encaminhadosao módulo de adaptação para realizar as operações necessárias. Dessa forma, as infor-mações especificadas são nele inseridas no formato de extensão de novas funcionalidadespelo relacionamento de herança.

O trecho de código fonte (b->c) mostra os principais comandos para a criação doartefato Estudante e sua associação com o artefato Cliente. A criação do artefatoEstudante e atributos é realizada de maneira similar ao caso anterior (Tipo 1). A linha7 mostra o relacionamento entre os artefatos de software (Pessoa e Estudante). Oprimeiro parâmetro (cls) representa o artefato que está sendo criado. O segundo parâme-tro ("Cliente") indica o nome do artefato no metamodelo que será associada ao novoartefato (primeiro parâmetro). Os dois últimos parâmetros (NONE e EXTENDS) mostrama ausência de cardinalidade no relacionamento e o tipo de relacionamento (herança) entreos artefatos, respectivamente. O modelo UML (c) mostra o artefato Estudante.

5. Conclusão e Trabalhos FuturosEste artigo apresentou uma breve descrição da AR-Saa e a implementação do módulo deadaptação de artefatos de software. Baseado nessa arquitetura, os artefatos de softwaresão desenvolvidos, monitorados e adaptados em tempo de execução. Além disso, vale

6 UML: Unified Modeling Language

AutoSoft

102

ressaltar que a adaptação de tais artefatos é conduzida por suporte automatizado, sem aparticipação de seres humanos. Baseado neste cenário, as principais contribuições são:(i) paralelamente com duas áreas AR e Saa, pois uma AR foi elaborada para apoiar odesenvolvimento de tais sistemas. Devido à complexidade de tais sistemas, o uso de ARtem emergido como uma boa alternativa de desenvolvimento; (ii) com o desenvolvimentode Saa, pois a proposta de adaptação permite que mudanças estruturais e/ou comporta-mentais sejam realizadas de maneira organizada e modularizada, evitando que os desen-volvedores tenham que injetar/espalhar “código indesejados” pelos artefatos de software.Ainda na mesma linha de apoio, o uso de aspectos como mecanismo de interceptação per-mite criar chamadas dinâmicas entre os níveis base e meta; (iii) com a área de automaçãode software, uma vez que a AR-Saa apresenta um processo de adaptação em uma sequên-cia de passos bem definida, sem a participação de seres humanos, como uma “linha demontagem”; (iv) finalmente, acredita-se que a AR-Saa pode ser utilizada paralelamente aoutros processos de desenvolvimento de software utilizados por empresas, uma vez quetanto a AR-Saa quanto esses processos parecem ser complementares.

Como trabalhos futuros, algumas atividades são pretendidas: (i) conduzir maisestudos de casos como forma de avaliar a AR-Saa e, consequentemente, o módulo deadaptação apresentado neste artigo; (ii) instanciar a AR-Saa em outras linguagens deprogramação que suportem POA; e (iii) utilizar a AR-Saa na indústria como forma deavaliar seu comportamento quando utilizada em ambiente de desenvolvimento e execuçãode larga escala. Portanto, projeta-se um cenário positivo de pesquisa, que visa tornar aAR-Saa uma contribuição efetiva para a comunidade de desenvolvimento de software.

Agradecimentos

Este trabalho teve apoio financeiro da PROPe/UNESP (Pró-Reitoria de Pesquisa daUNESP) e da FAPESP (Fundação de Amparo à Pesquisa do Estado de São Paulo).

Referências

Affonso, F. J., Carneiro, M. C. V. S., Rodrigues, E. L. L., and Nakagawa, E. Y. (2013).Adaptive software development supported by an automated process: a reference model.Salesian Journal on Information Systems, 12:8 – 20.

Affonso, F. J. and Nakagawa, E. Y. (2013). A reference architecture based on reflection forself-adaptive software. In Software Components, Architectures and Reuse (SBCARS),2013 Seventh Brazilian Symposium on, pages 129–138. [In press].

Affonso, F. J. and Rodrigues, E. L. L. (2012). A proposal of reference architecture for thereconfigurable software development. In SEKE 2012, pages 668–671.

Andersson, J., de Lemos, R., Malek, S., and Weyns, D. (2009). Reflecting on self-adaptivesoftware systems. In SEAMS/ICSE 2009, pages 38 –47.

ASPECTJ (2014). Eclipse - AspectJ. [On-line], World Wide Web. In https://eclipse.org/aspectj/ (Access in 18/06/2014).

Borde, E., Haïk, G., and Pautet, L. (2009). Mode-based reconfiguration of critical soft-ware component architectures. In DATE 2009, DATE ’09, pages 1160–1165, 3001Leuven, Belgium, Belgium. European Design and Automation Association.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and Stal, M. (1996). Pattern-Oriented Software Architecture: a system of patterns, volume 1. John Wiley and Sons.

AutoSoft

103

Coulson, G., Blair, G., and Grace, P. (2004). On the performance of reflective systemssoftware. In PCCC 2004, pages 763 – 769.

Dobson, S., Denazis, S., Fernández, A., Gaïti, D., Gelenbe, E., Massacci, F., Nixon, P.,Saffre, F., Schmidt, N., and Zambonelli, F. (2006). A survey of autonomic communi-cations. ACM Trans. Auton. Adapt. Syst., 1(2):223–259.

Erradi, M., Bochmann, G., and Hamid, I. (1992). Dynamic modifications of object-oriented specifications. In CompEuro ’92, pages 654–659.

IBM (2005). An architectural blueprint for autonomic computing. On-line. White Paper,Third Edition. Avaliable: http://www-03.ibm.com/autonomic/pdfs/AC Blueprint WhitePaper V7.pdf, 2008.

Janik, A. and Zielinski, K. (2010). Aaop-based dynamically reconfigurable monitoringsystem. Inf. Softw. Technol., 52(4):380–396.

Kephart, J. and Chess, D. (2003). The vision of autonomic computing. Computer,36(1):41–50.

Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., and Griswold, W. G. (2001).An overview of aspectj. In Proceedings of the 15th European Conference on Object-Oriented Programming, ECOOP ’01, pages 327–353. Springer-Verlag.

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C. V., Loingtier, J.-M., andIrwin, J. (1997). Aspect-oriented programming. In ECOOP ’97, pages 220–242.

Kramer, J. and Magee, J. (2007). Self-managed systems: an architectural challenge. InFOSE 2007, pages 259 –268.

Liu, L., Thanheiser, S., and Schmeck, H. (2008). A reference architecture for self-organizing service-oriented computing. In Brinkschulte, U., Ungerer, T., Hochberger,C., and Spallek, R., editors, ARCS 2008, volume 4934 of Lecture Notes in ComputerScience, pages 205–219. Springer Berlin / Heidelberg.

Maes, P. (1987). Concepts and experiments in computational reflection. In OOPSLA1987, OOPSLA ’87, pages 147–155, New York, NY, USA. ACM.

Morin, B., Barais, O., Jezequel, J.-M., Fleurey, F., and Solberg, A. (2009). [email protected] to support dynamic adaptation. Computer, 42(10):44–51.

Nakagawa, E. Y., Oquendo, F., and Becker, M. (2012). RAModel: A reference model ofreference architectures. In ECSA/WICSA 2012, pages 297–301, Helsinki, Finland.

Peng, Y., Shi, Y., Xiang-Yang, J., Jun-Feng, Y., Ju-Bo, L., and Wen-Jie, Y. (2008). Areflective information model for reusing software architecture. In CCCM/ISECS 2008,volume 1, pages 270 –275.

Salehie, M. and Tahvildari, L. (2009). Self-adaptive software: Landscape and researchchallenges. ACM Trans. Auton. Adapt. Syst., 4(2):1–42.

Shi, Y., ZaoQing, L., JunLi, W., and FuDi, W. (2006). A reflection mechanism for reusingsoftware architecture. In QSIC 2006, pages 235 –243.

Tanter, E., Toledo, R., Pothier, G., and Noyé, J. (2008). Flexible metaprogramming andaop in java. Sci. Comput. Program., 72(1-2):22–30.

Vinoski, S. (2005). A time for reflection [software reflection]. Internet Computing, IEEE,9(1):86 – 89.

Weyns, D., Malek, S., and Andersson, J. (2010a). Forms: a formal reference model forself-adaptation. In ICAC 2010, ICAC ’10, pages 205–214, New York, NY, USA. ACM.

Weyns, D., Malek, S., and Andersson, J. (2010b). On decentralized self-adaptation: les-sons from the trenches and challenges for the future. In SEAMS/ICSE 2010, SEAMS’10, pages 84–93, New York, NY, USA. ACM.

AutoSoft

104

Congresso Brasileiro de Software: Teoria e Prática Engenharia de Software e Sistemas Inteligentes...

Documents

Transcript of Congresso Brasileiro de Software: Teoria e Prática Engenharia de Software e Sistemas Inteligentes...