CBSOFT2010 AutoSoft Anais

http://cbsoft.dcc.ufba.
br
A N A I S
F
o
t
o
:

M
a
W
F
o
t
o
:

M
a
W
AutoSoft 2010
First Workshop on
Autonomous Software Systems

Volume 10 ISSN 2178-6097

AUTOSOFT 2010
I Workshop on Autonomous Software Systems

27 de Setembro de 2010
Salvador Bahia Brasil

ANAIS

Comit Organizador e Editores do AUTOSOFT
Anarosa Alves Franco Brando Carlos Jos Pereira de Lucena
Jaime Simo Sichman Mariela Ins Corts Rafael Bordini
Ricardo Choren Viviane Torres da Silva

Coordenador Geral do CBSOFT
Manoel Gomes de Mendona Neto

Coordenador de Workshops do CBSOFT
Mrcio Delamaro

Realizao
Poli/USP Escola Politcnica / Universidade de So Paulo
PUC-Rio Pontifcia Universidade Catlica do Rio de Janeiro
UECE Universidade Estadual do Cear
UFRGS Universidade Federal do Rio Grande do Sul
IME Instituto Militar de Engenharia
UFF Universidade Federal Fluminense

Promoo
SBC Sociedade Brasileira de Computao

ii


iii
Volume 10 ISSN 2178-6097

AUTOSOFT 2010
1st Workshop on Autonomous Software Systems

September 27
th
, 2010
Salvador, Bahia, Brazil

PROCEEDINGS

AUTOSOFT Organizing Committee and Editors
Anarosa Alves Franco Brando Carlos Jos Pereira de Lucena
Jaime Simo Sichman Mariela Ins Corts Rafael Bordini
Ricardo Choren Viviane Torres da Silva

CBSOFT General Chair
Manoel Gomes de Mendona Neto

CBSOFT Workshop Chair
Mrcio Delamaro

Organizers
Poli/USP Politechnique School / University of So Paulo
PUC-Rio Pontifical Catholic University of Rio de Janeiro
UECE State University of Cear
UFRGS Federal University of Rio Grande do Sul
IME Military Institute of Engineering
UFF Fluminense Federal University

Promoted by
SBC Brazilian Computing Society

iv

Sistema de Bibliotecas - UFBA

Congresso Brasileiro de Software: Teoria e Prtica (2010 : Salvador, BA).
Anais [do] Congresso Brasileiro de Software : Teoria e Prtica, Salvador, BA, 27 de
setembro a 01 de outubro de 2010 / organizao UFBA, LES, DCC ; coordenador geral
Manoel Gomes de Mendona Neto. - Salvador : SBC, 2010.
12 v.

Inclui 10 eventos satlites.
Contedo: v. 10 - AutoSoft - Workshop on Autonomous Software Systems
( 1. : 2010 : Salvador, BA).

1. Software - Brasil - Congressos. I. Workshop on Autonomous Softrware Systems
(1. : 2010 : Salvador, BA). II. Universidade Federal da Bahia. Instituto de Matemtica.
Departamento de Cincia da Computao. III. Laboratrio de Engenharia de Software.
IV. Mendona Neto, Manoel Gomes de. V. Sociedade Brasileira de Computao. VI.
Ttulo.

CDD - 005


v
Apresentao do AutoSoft

O primeiro Workshop de Sistemas de Software Autnomo, AUTOSOFT, um evento
satlite da primeira Conferencia Brasileira de Software: Teoria e Prtica (CBSoft),
acontecendo em Salvador, Bahia, no dia 27 de setembro de 2010.

O AUTOSOFT representa uma nova e melhorada edio do Workshop on Software
Engineering for Agent-oriented Systems (SEAS), que aconteceu com sucesso ao longo
de cinco edies vinculadas ao SBES (2005 2009). No contexto do CBSoft, cujo
objetivo integrar as diversas comunidades de pesquisadores e profissionais voltados a
software, o mbito do evento foi ampliado de forma a atender a esta proposta, focando
nos aspectos tericos e prticos do desenvolvimento de software autnomo.

Sistemas autnomos contribuem cada vez mais para a criao de sistemas inteligentes
capazes de dar suporte complexidade do mundo real. A transio de componentes
passivos para autnomos transforma arquiteturas de software em plataformas complexas
envolvendo diversos componentes interagindo dinamicamente, engajados em
complexos protocolos de interao. Transportes, pesquisa aeroespacial, defesa e
finanas so alguns dos setores que esto optando por substituir operadores humanos
por arquiteturas e plataformas de implementao que objetivam prover melhorias no
sistema como um todo.

O AUTOSOFT apresenta um programa tcnico de qualidade, com 10 trabalhos, a serem
apresentados em quatro sesses. Estes artigos foram cuidadosamente selecionados por
um comit de programa composto por 28 pesquisadores de destaque nacional e
internacional. O processo de avaliao garantiu que cada artigo tivesse trs avaliaes.
As avaliaes foram feitas de forma independente pelos avaliadores e depois discutida
de forma annima entre eles. Com base nessas avaliaes, o Comit Organizador do
AUTOSOFT fez a avaliao final e a escolha dos trabalhos aqui apresentados.

Agradecemos, por fim, aos membros do Comit de Programa, e demais revisores de
artigos, pela pontualidade e alta qualidade do trabalho produzido. Gostaramos de
agradecer tambm organizao do CBSOFT pela oportunidade de continuar
contribuindo com o crescimento e divulgao de pesquisas na rea de sistemas
autnomos na comunidade cientifica brasileira, e a CAPES, pelo auxlio financeiro
concedido ao evento. Fazemos votos que o AUTOSOFT produza timas discusses
cientficas e traga excelentes oportunidades de relacionamento a todos dentro da nossa
comunidade cientfica.

Salvador, Setembro de 2010.

Comit Organizador do AUTOSOFT 2010
vi

Message from the Organizing Committee

The First Workshop on Autonomous Software Systems, AUTOSOFT, is a satellite
event of the First Brazilian Conference on Software: Theory and Practice (CBSOFT),
which will take place in Salvador, Bahia, on September 27th, 2010.

AUTOSOFT is an evolution of the traditional Workshop on Software Engineering for
Agent-oriented Systems (SEAS) series, which had five editions (2005-2009) at the
Brazilian Symposium on Software Engineering (SBES). Thus, AUTOSOFT intends not
to be a brand new event, but rather an improvement of an event that already existed.
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. Transportation,
aerospace, 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.

We also have a strong technical program with 10 research papers to be presented in four
sessions. All papers where reviewed by three members of a program committee of 28
researchers, representing all regions of the country and many countries abroad. The
reviews were done independently and organization committee selected the accepted
papers after a thoroughly discussion.

We would like to conclude by thanking all members of the AUTOSOFT Program
Committee, and other paper reviewers, for the timeliness and quality of their work. We
would also like to thank the CBSOFT Organization for the opportunity to evolve the
SEAS event into a broader scope, contributing to the advancement of the autonomous
software community; and CAPES, for the financial support. We are sure AUTOSOFT
will produce many exciting discussions and bring forth excellent interaction
opportunities.

Salvador, September 2010.

AUTOSOFT 2010 Organizing Committee


vii
Comit Organizador Organizing Committee Bio

Anarosa Alves Franco Brando is PhD in Informatics at PUC-Rio,
Brazil and MsC in Mathematics at University of So Paulo, Brazil,
where she had her undergraduate studies in Mathematics. Her
research interests are related to Software Engineering and Knowledge
Engineering applied to the multiagent systems domain. Currently, she
is assistant professor at Department of Computer and Digital Systems
Engineering from Politechnique School of University of So Paulo. She is part of the
Intelligent Techniques Laboratory, where she researches about reputation, ontologies,
organizational models and method engineering applied to the MAS domain. She was
part of the SEAS 2008 organizing committee.

Carlos Jos Pereira de Lucena is a full professor at the Informatics
Department of PUC-Rio. He completed his undergraduate studies in
Economics and Mathematics in 1965 at PUC-Rio. Later, he received
his Masters degree from the University of Waterloo (1969), Canada,
and his PhD from the University of California in Los Angeles (1974).
Carlos is the author of over 450 refereed papers and 19 books in the
area of formal methods in software engineering, his primary area of
research. He has also been a member of the program committees of more than 30
national and international conferences. Until 2009, he has supervised 34 PhD theses and
91 MSc dissertations. He has received, among others, the Alvaro Alberto Award in
Informatics in 1987 (Ministry of Science and Technology), twice the National Award in
Informatics (1988 and 1991) and the Great Cross of the National Order of the Scientific
Merit in 1996. Carlos is a full member of the Brazilian Academy of Sciences and also
fellow of TWAS Academy of Sciences for the Developing World, since Nov. 2008.

Jaime Simo Sichman is an associated professor at University of
So Paulo, from where he has obtained both his B.E. and M.E.
degrees. He was one of the first students to obtain a European label to
his PhD degree, developed at the Institut National Polytechnique de
Grenoble (INPG), France, since part of his research was carried out at
the Istituto di Psicologia del CNR, Rome, Italy. His main research
focus is multi-agent systems, more particularly social reasoning,
organizational reasoning, multi-agent-based simulation, reputation and trust, and
interoperability in agent systems. He has advised/co-advised 10 MsC and 8 PhD
students and has published more than 160 papers in national and international
conferences and journals. He is member of the editorial board of the Journal of
Artificial Societies and Social Simulation (JASSS), Mediterranean Journal of Artificial
Intelligence, Computacin y Sistemas, and the Knowledge Engineering Review. He has
organized several workshops and international conferences and workshops; in particular
he was the SBIA/IBERAMIA General Chair (2000), Program Co-Chair (2006), and
AAMAS Tutorial Chair (2007) and Program Co-Chair (2009).
viii

Mariela Ins Corts is associate professor at the Computing Science
Department of the State University of Cear (UECE). She had a
Doctoral degree in Informatics at the Pontifical Catholic University of
Rio de Janeiro PUC (2003) and a Master degree in Computing
Systems (1999) at the Military Engineering Institute of Rio de Janeiro
IME, Brazil. Her alma mater is the National University of La Plata
(UNLP, Argentina) where she fulfilled her graduate studies in
Computing Science (1996). She nowadays leads the Software
Engineering and Intelligent Systems group (GESSI), and undertakes research into
agent-oriented development and intelligent systems, including modeling, programming
and platforms.

Rafael Bordini is an associate professor at the Institute of
Informatics, Federal University of Rio Grande do Sul (INF-UFRGS).
He obtained a PhD in Computer Science from University College
London in 1999, then was a visiting professor at INF-UFRGS until
2002 when he moved to the University of Liverpool as a post-doc
research fellow. In 2004 he joined Durham University as a Lecturer in
Computer Science, a position he held until 2009 when he moved back
to INF-UFRGS. His main research interests are in programming
languages and verification techniques for autonomous software systems, particularly
multi-agent systems. He has published over 70 papers in journals, book chapters,
conferences, and workshops, and has co-edited 5 books as well as co-authored a book
on the Jason multi-agent development platform published by Wiley. He has been PC or
senior PC member for a number of events. He was member of the organizing committee
of two AAMAS editions, and has organized MALLOW-2007 as well as various
editions of the ProMAS workshop. He is a member of the IFAAMAS board of
directors, member of the EURAMAS board of directors, member of the EPSRC (UK)
Peer Review College 2006-2009 as well as the new College starting in 2010, member of
the Steering Committee of ProMAS and chair of the Steering Committee of MALLOW.

Ricardo Choren is an associate professor at the Computer
Engineering Department of the Military Institute of Engineering. His
main research interests are on the following topics and their
integration: agent-oriented development, autonomic software, mining
and semantics. Ricardo obtained his doctoral degree in Informatics at
PUC-Rio, in 2003. He has advised/co-advised 13 MSc and 2 PhD
students and has published more than 60 papers in national and
international conferences and journals. Ricardo is a member of the ACM and the
Brazilian Computer Society, and has also been a member and chair of several scientific
program committees.

ix

Viviane Torres da Silva is a professor at the Computer Institute
Department of the Fluminense Federal University. She obtained a
DSc in Informatics from PUC-Rio in 2004, then, from 2006 until
2008 she was a visiting professor at Universidade Complutense de
Madrid when she moved to PUC-Rio as a research fellow. Then in
2009 she joined the Fluminense Federal University. Her main
research interests are in software agents and multi-agent systems,
including modeling languages, agent platforms and norms. She has been PC member in
many editions of Agents and AI conferences, including AAMAS, ICAART, SBIA,
SBES, COIN and AOSE. Currently she is a Steering Committee member of the COIN
Workshop.

x

Comit de Programa - Program Committee

Ana Bazzan, UFRGS, Brazil
Ana Cristina Bicharra, UFF, Brazil
Angelo Perkusich, UFCG, Brazil
Anna Helena Reali Costa, USP, Brazil
Antonio Carlos da Rocha Costa, FURG, Brazil
Diana Adamatti, FURG, Brazil
Guillermo Simari, U. Nac. del Sur, Argentina
Gustavo Gimenez Lugo, UTFPR, Brazil
Joo Leite, Nova U. de Lisboa, Portugal
Jomi Fred Hubner, UFSC, Brazil
Jos Neira, University Zaragoza, Spain
Luciano dos Reis Coutinho, UFMA, Brazil
Marc Esteva, IIIA, Spain
Marcelo Blois, PUC-RS, Brazil
Mehdi Dastani, U. of Utrecht, Netherlands
Michael Luck, King's College London, UK
Olivier Boissier, EMSE, France
Paulo Andr Lima de Castro, ITA, Brazil
Paulo Rosa, IME-RJ, Brazil
Reinaldo Bianchi, FEI, Brazil
Renata S.S. Guizzardi, UFES, Brazil
Rodrigo Paes, UFAL, Brazil
Silvia Botelho, FURG, Brazil
Valdinei Freire Silva, USP, Brazil
Valguima Odakura, UFGD, Brazil
Virginia Dignum, TU Delft, Netherlands
Wamberto Vasconcelos, U. Aberdeen, UK
Zahia Guessoum, LIP6, France

xi
ndice Table of Contents

Agent-Oriented Software Engineering

Modelagem de Organizaes de Agentes Inteligentes:
uma Extenso da MAS-ML Tool ............................................................................ 1
Enyo J. T. Gonalves, Kleinner Farias, Mariela I. Corts, Viviane Torres da Silva,
Robson G. F. Feitosa

NormML: A Modeling Language to Model Norms 11
Karen Figueiredo, Viviane Torres da Silva

A Semiotic Taxonomy to Support Multiagent Systems Situational Development .. 21
Sara Casare, Anarosa A. F. Brando, Jaime S. Sichman

Infrastructures and Tools for Autonomous Systems

Supporting the Development of Personal Assistance Software 31
Ingrid Nunes, Simone D. J. Barbosa, Carlos J. P. de Lucena

Usando Objetos de Conhecimento para Compartilhar Conhecimento na
Plataforma Jason ...................................................................................................... 41
Ana Paula Lemke, Pier Cludio M. Nicotti, Marcelo Blois Ribeiro, Rafael H. Bordini

Programming in Multi-agent Systems

A Quantitative Study about the Hidden Risk of Using Time-Scheduler Mechanisms to
Control Execution Flow in JADE-Based MAS ... 51
Pier-Giovanni Taranti, Ricardo Choren, Carlos J. P. Lucena

Definindo Logicamente Componentes Subsumption .............................................. 61
Gustavo L. Campos, Mariela I. Corts, Enyo J. T. Gonalves

Algoritmo Gentico Aplicado a um Agente para a Seleo de Leiles do
Tipo CDA do TAC .................................................................................................. 71
Robson G. F. Feitosa, Rafael A. F. do Carmo, Paulo de T. G. Oliveira, Enyo J. T.
Gonalves, Gustavo A. L. de Campos, Jerffeson T. de Souza

Applications of Autonomous Software Systems

Adaptao de Agentes de Software ao Contexto com o uso de Aspectos ............... 81
Ana Paula Lemke, Marcelo Blois Ribeiro

ALIEM: Ferramenta de Recomendao para Alinhamento de Esquemas ............ 91
Guylerme V. S. Figueiredo, Andrew Diniz da Costa, Carlos J. P. Lucena, Marco
Antnio Casanova

xii

Modelagem de Organizaes de Agentes Inteligentes:
uma Extenso da MAS-ML Tool
Enyo J. T. Gonalves
1, 2
, Kleinner Farias
3
, Mariela I. Corts
2

Viviane Torres da Silva
4
, Robson G. F. Feitosa
2

1
Universidade Federal do Cear, Quixad-CE Brasil
2
Universidade Estadual do Cear, Fortaleza - CE Brasil
3
Pontifcia Universidade Catlica do Rio de Janeiro, Rio de janeiro - RJ Brasil
4
Universidade Federal Fluminense, Niteri - RJ Brasil
enyotavares@uece.br,kfarias@inf.puc-rio.br, mariela@larces.uece.br,
viviane.silva@ic.uff.br, robsonf@gmail.com
Resumo. particularmente desafiante para os projetistas de software criar e
validar manualmente diagramas de organizaes de agentes inteligentes, ao
mesmo tempo em que importantes questes de qualidade, tais como
compreensibilidade e consistncia, sejam garantidas. Este artigo ataca esta
problemtica atravs da adio do diagrama de organizao ferramenta
MAS-ML tool, em conformidade com MAS-ML 2.0. Adicionalmente, o diagrama
de classes da ferramenta adaptado nova verso da linguagem de modelagem.
1. Introduo
A indstria de software e a academia tm cada vez mais desenvolvido pesquisas e
fornecido tecnologias no intuito de atender demanda da construo de sistemas de
software cada vez mais complexos. Neste cenrio, Sistemas Multi-Agentes (SMAs)
surgem como uma abordagem promissora na tentativa de melhor gerenciar esta
complexidade. De acordo com [Jennings 2000], SMAs podem ser entendidos como
sociedades de agentes em que entidades autnomas e heterogneas podem trabalhar de
forma conjunta para fins similares ou totalmente distintos. SMAs tm se tornado um
poderoso paradigma de engenharia de software [Mubarak 2008] e tm sido utilizados com
sucesso para o desenvolvimento de diferentes tipos de sistemas de software, tanto na
academia quanto na indstria [Lind 2001] [Wooldridge 2001].
Diante deste cenrio, linguagens de modelagem para SMAs desempenham um
papel central dentro do processo de desenvolvimento. Em especial neste artigo, damos
nfase MAS-ML (Multi-Agent System Modeling Language) [Silva et al. 2004]. A
escolha da linguagem MAS-ML foi motivada pelo (1) seu reconhecimento diante da
necessidade de modelar SMAs em projetos reais [C. Nunes et al. 2009] [I. Nunes et al.
2009], e (2) por apresentar as definies necessrias para modelar os conceitos e
abstraes apresentadas no paradigma de SMAs. Porm, algumas limitaes da
linguagem foram observadas na modelagem de agentes com arquiteturas internas
diversas. Sendo assim, a linguagem MAS-ML foi evoluda para suprir estas deficincias,
originando a MAS-ML 2.0 [Gonalves et al. 2009] [Gonalves et al. 2010].
O presente artigo apresenta uma evoluo da ferramenta MAS-ML tool [Farias et
al. 2009] relacionada : (i) adequao do diagrama de classes (j presente na ferramenta)
MAS-ML 2.0; e (ii) adio do diagrama de organizao MAS-ML tool em
conformidade com MAS-ML 2.0. O artigo organizado como segue: Na Seo 2
apresentado o referencial terico em relao MAS-ML tool e MAS-ML 2.0. Na Seo
1
3, a evoluo da ferramenta apresentada. Na Seo 4, um estudo de caso ilustrado. Na
Seo 5, os trabalhos relacionados so confrontados com as contribuies deste artigo. E
por fim, na Seo 6, so apresentadas as concluses e os trabalhos futuros.
2. Referencial Terico
Nesta seo apresentado o referencial terico em relao aos conceitos de MAS-ML
tool e da linguagem de modelagem MAS-ML em sua verso 2.0.
2.1. Background: MAS-ML tool
A ferramenta MAS-ML tool foi desenvolvida como um plug-in da plataforma Eclipse
[Eclipse 2009]. Isso implica que os usurios podem trabalhar com modelagem de SMAs
ao mesmo tempo em que fazem uso dos recursos oferecidos pela plataforma Eclipse.
Dado que muitas plataformas de agentes so implementadas em Java, tais como Jade
[Bellifemine, Caire, e Greenwood 2007], Jadex [Pokahr, Braubach e Lamersdorf 2003],
Jason [Bordini, Wooldridge e Hbner 2007], o uso da plataforma Eclipse tambm facilita
uma possvel gerao de cdigo dentro do mesmo ambiente de desenvolvimento.
O desenvolvimento da ferramenta seguiu uma abordagem dirigida por modelos,
onde o modelo central o prprio metamodelo da linguagem MAS-ML, na sua verso
inicial. Os componentes principais da MAS-ML tool so os seguintes:
(A) Package Explorer - Tem como funcionalidade central permitir a organizao dos
arquivos em uma estrutura de rvore, facilitando o gerenciamento e manipulao;
(B) Modeling View - Permite aos desenvolvedores visualizar e editar os modelos de
forma interativa;
(C) Nodes Palette - Os construtores que podem fazer parte dos diagramas encontram-
se na nodes palette, cujas instncias so visualizadas na modeling view.
(D) Relationship Palette - Os relacionamentos que podem ser estabelecidos entre os
construtores presentes na nodes palette so disponibilizados na relationship palette.
(E) Properties View - Permite manipular com preciso as propriedades dos modelos.
(F) Problems View - Apresenta eventuais inconsistncias no modelo. Esta
funcionalidade particularmente importante para viabilizar o uso da modelagem de
SMAs dentro do contexto do desenvolvimento dirigido por modelos.
(G) Outline View - Uma vez que um modelo tenha sido criado, a visualizao da
distribuio dos elementos presentes no mesmo realizada atravs da outline view.
2.2. MAS-ML 2.0
MAS-ML 2.0 [Gonalves et al. 2009] [Gonalves et al. 2010] uma extenso da
linguagem de modelagem MAS-ML visando adequ-la a modelagem de: (i) arquiteturas
internas de agentes reativos simples; (ii) agentes reativos baseados em conhecimento; e
(iii) agentes baseados em objetivo com planejamento e agentes baseados em utilidade.
Em termos prticos, a extenso da linguagem envolveu a evoluo do
metamodelo da MAS-ML com o objetivo de inserir novas meta-classes e especificar
como os relacionamentos, previamente definidos, interagem com as mesmas. A citada
extenso envolveu a criao de duas meta-classes: AgentPerceptionFunction, que
representa as percepes do agente; e AgentPlanningStrategy, que representa o
planejamento do agente. Ambas especializam a meta-classe BehavioralFeature da
UML. Alm das duas meta-classes, foram criados quatro esteretipos: formulate-goal-
2
function, para representar a funo de formulao de objetivo; formulate-problem-
function, para representar a funo de formulao de problema; next-function, para
representar a funo prximo; e utility-function, para representar a funo utilidade
[Gonalves et al. 2009] [Gonalves et al. 2010].
A partir dos novos elementos no metamodelo, a representao do agente nos
diagramas de MAS-ML ganhou quatro variantes grficas, onde cada uma representa
cada uma das arquiteturas internas citadas anteriormente. Conseqentemente, o
elemento papel de agente passou a ter trs representaes: (i) a representao inicial de
MAS-ML foi mantida; (ii) uma representao sem objetivos, associada a agentes
reativos baseados em conhecimento; e (iii) uma representao sem objetivos nem
crenas, associada a agentes reativos simples.
Em relao aos diagramas, o metamodelo de MAS-ML na sua concepo
original [Silva et al. 2004] contempla os diagramas de Classes, Organizao, Papis,
Seqncia e Atividades. MAS-ML 2.0 manteve as representaes existentes, no entanto,
esses diagramas foram alterados adequando o metamodelo original da linguagem para a
modelagem das diferentes arquiteturas internas de agentes.
3. Evoluo da MAS-ML tool
A verso da ferramenta utilizada como base para o presente trabalho disponibiliza
exclusivamente o diagrama de classes em conformidade com a verso original de MAS-
ML. Considerando a evoluo da linguagem de modelagem torna-se necessria a evoluo
da ferramenta de apoio de forma a propiciar a correta gerao do diagrama de classes em
consistncia com a nova especificao da linguagem. Adicionalmente, a ferramenta
enriquecida incorporando apoio criao do diagrama de organizao MAS-ML 2.0.
A evoluo da ferramenta segue a abordagem dirigida por modelos que foi
utilizada originalmente para seu desenvolvimento. Neste caso, o metamodelo da
linguagem MAS-ML 2.0 usado como guia para as alteraes no metamodelo da
ferramenta [Farias et al. 2009], o qual utilizado como base da implementao. O
desenvolvimento da ferramenta se baseou em uma abordagem generativa utilizando o
GMF [GMF 2009] e pode ser resumido em 6 etapas descritas como segue:
1. Extenso do Modelo de Domnio. Ao partir da especificao original do
metamodelo usando o EMOF
1
(Essencial Meta-Object Facility), os esteretipos
apresentados na seo anterior foram adicionados ActionClass atravs de uma
semntica chamada ActionSemantics. Esta semntica representa as opes 0- sem
esteretipo, 1- next-function, 2- utility-function, 3- formulate-problem-function e
4- formulate-goal-function.
2. Extenso do Modelo Grfico. O Modelo Grfico contm as definies das
entidades e suas propriedades, e dos relacionamentos com base no metamodelo da
linguagem. No contexto da evoluo, as novas meta-classes apresentadas na seo
anterior foram adicionadas na Definio do Modelo Grfico da ferramenta,
criando os relacionamentos necessarios. As multiplicidades dos relacionamentos
entre as entidades goal, belief e plan e a entidade AgentClass foram alteradas de 1
para 1..* para 1 para 0..*. As entidades perception e planning possuem um
relacionamento com multiplicidade 1 para 0..*.

1
O EMOF parte integrante do plug-in EMF (Eclipse Metamodel Framework) que consiste em um framework
de modelagem e de gerao de cdigo para construir aplicaes baseadas em modelos [EMF 2009]
3
3. Extenso do Modelo de Ferramenta. Esta etapa especifica quais elementos
fazem parte da paleta da ferramenta. Para isso, essa etapa recebe como entrada o
modelo de domnio e o modelo grfico determinados anteriormente.
Adicionalmente, para o diagrama de classes foram criados novos elementos na
paleta da ferramenta para criar percepes e planejamento. Na representao do
modelo de ferramenta do diagrama de Organizao, foram adicionados os
elementos Perception, Planning, AgentRoleClass, ObjectRoleClass, Duty, Right e
Protocol e os relacionamentos inhabit, ownership e play.
4. Extenso da Definio do Modelo Grfico. Esta etapa est relacionada com a
representao dos elementos no respectivo diagrama. O modelo Grfico, que
tem como entrada o modelo de domnio, utilizado na combinao para gerar o
modelo de mapeamento. Para esta etapa, foram criados compartimentos para a
representao das percepes e do planejamento, alm da representao dos ns
(nodes) provenientes da etapa anterior.
Na representao do diagrama de Organizao, na definio do modelo grfico,
foram adicionados os elementos Planning, Perception, AgentRoleClass,
ObjectRoleClass, Duty, Right e Protocol, compartimentos para Planning,
Perception, Duty, Right e Protocol e os relacionamentos inhabit, ownership e play.
5. Extenso do Modelo de Mapeamento. Este modelo criado a partir de um
mapeamento entre os modelos: modelo de domnio, modelo grfico, e o modelo de
ferramenta. O mapeamento gerado pode ser usado como entrada em um processo de
transformao no intuito de criar um modelo especfico de plataforma. Novas
regras de validao foram implementadas (exemplos no Quadro 1) atravs de
restries em OCL (Object Constraint Language) a partir da multiplicidade das
meta-classes presentes na Definio do Modelo Grfico da ferramenta.
Quadro 1 Regras de validao dos modelos.
Regra Propsito e Definio em OCL

Regra 1
Se o agente possui plano, ento ele possui objetivo, crena e ao.
self.ownedPlan->isEmpty() = false implies self.ownedGoal->isEmpty() = false
and self.ownedBelief->isEmpty() = false and self.owendAction->isEmpty() =
false and self.ownedPlan->isEmpty() = false

Regra 2
Se o agente possui plano, ento no possui percepo.
self.ownedPlan->isEmpty() = false implies self.ownedPerception->isEmpty() =
true and self.ownedPlan->isEmpty() = false
6. Gerao da Ferramenta. Finalmente, seguindo a abordagem generativa
[Czarnecki e Eisenecker 2000], e feita a gerao do cdigo da ferramenta a partir
do modelo especfico de plataforma estendido na etapa anterior.
No diagrama de classes, o agente passou a ter dois compartimentos extras para
abrigar as percepes do agente e o planejamento, onde uma ao pode ter um esteretipo
associado para representar a funo prximo, formulao de objetivo, formulao de
problema e utilidade. A representao do agente apresentada na Figura 1, e o diagrama de
classes do SMA para o TAC-SCM
2
[Sadeh et al. 2003] apresentado na Figura 4. Ambos
diagramas foram gerados a partir da ferramenta MAS-ML tool aps a extenso.

2
O TAC-SCM (Trading Agent Competion - Supply Chain Management) um ambiente que possibilita a
realizao de leiles simultneos, para testar tcnicas, algoritmos e heursticas em agentes de negociao.
4

Figura 1. Nova representao do agente na ferramenta MAS-ML tool.
A estrutura criada para o diagrama de classes foi aproveitada para a criao do
diagrama de organizao, pois grande parte das entidades comum aos dois diagramas.
Os papis de agente foram representados de acordo com a extenso proposta por
Gonalves et al. (2010), ilustrada na Figura 2 a partir da ferramenta MAS-ML tool.

Figura 2. Representao do papel de agente na ferramenta MAS-ML tool.
Os relacionamentos posse e exerce definidos em MAS-ML, os quais fazem parte
do diagrama de organizao, foram adicionados. O relacionamento habita teve sua
semntica alterada para permitir que agentes, papis de agente e organizaes possam ser
considerados. Na Figura 3, o diagrama de Organizao para TAC-SCM.

Figura 3. Validao na ferramenta MAS-ML tool.
Os modelos gerados a partir da ferramenta podem ser validados aplicando as
restries OCL implementadas, as quais podem ser acessadas atravs do menu edit e da
5
opo validate. Caso alguma regra seja violada, o elemento que apresenta problema
assinalado e o detalhamento dos problemas apresentado atravs do recurso problems
do eclipse. A Figura 5 apresenta o recurso de validao no Eclipse, o elemento Teste do
diagrama que apresenta problemas detectados pela validao e o respectivo relatrio.
A extenso do diagrama de classes da ferramenta MAS-ML tool envolveu: a
criao de duas novas metaclasses, a alterao da multiplicidade de alguns
relacionamentos, criao de novos compartimentos, bem como a representao das
novas entidades na paleta e criao de novas restries OCL.
Apoio gerao do diagrama de Organizao foi incorporado na ferramenta em
consistncia com as alteraes implementadas para o diagrama de classes. Foi necessrio
remover a representao dos relacionamentos associao, dependncia, generalizao,
agregao e composio, pois segundo Silva (2004) os relacionamentos presentes neste
diagrama so posse (ownership), exerce (play) e habita (inhabit). O relacionamento
inhabit foi mantido e os relacionamentos ownership e play foram adicionados na
representao deste diagrama. Os papis de agente e de objeto, que no eram modelados
no diagrama de classes, foram adicionados. Vale ressaltar que os elementos adicionados
j estavam presentes no modelo de domnio e no modelo grfico, porm no eram
utilizados na representao inicial.
4. Estudo de caso
Nesta seo apresentada a modelagem de um SMA para TAC-SCM (Trading Agent
Competition - Supply Chain Management) utilizando MAS-ML tool. Inicialmente o TAC-
SCM ser descrito e em seguida a modelagem ser apresentada.
4.1. TAC-SCM
Cadeias de Suprimento so ambientes altamente dinmicos, estocsticos e estratgicos
[Arunachalam 2004]. O TAC SCM foi projetado para capturar os desafios presentes em
um ambiente integrado de aquisio de matria-prima, produo de bens e oferta para
clientes. O jogo descreve o cenrio de uma cadeia de suprimentos para a montagem de
computadores pessoais, consistindo de uma fbrica de computadores, fornecedores que
provem componentes para a montagem destes computadores e clientes que demandam
computadores prontos [Sadeh et al. 2003].
O jogo consiste em uma seqncia de dias simulados ou rodadas em que os
agentes precisam realizar tarefas para gerenciar a cadeia de suprimento. Os agentes tm
uma conta no banco com saldo inicial igual a zero. A cada dia, clientes lanam pedidos
de oramentos e selecionam os oramentos submetidos com base na data de entrega e
no preo de oferta. Os agentes so limitados pela capacidade de produo de suas linhas
de montagem e tm que obter componentes de um conjunto de fornecedores. A
demanda de clientes vem na forma de pedidos de oramento para diferentes tipos de
computadores pessoais. O jogo comea quando um ou mais agentes se conectam ao
jogo. O jogo simula fornecedores e clientes, prov banco, produo e servio de
estocagem de mercadoria para agentes individuais. Ao final, o agente com maior soma
em dinheiro no banco declarado vencedor [Collins et al. 2006].
4.2. Modelagem do SMA para TAC-SCM com MAS-ML tool
Um nico SMA pode conter agentes com diferentes arquiteturas internas. Nesse
contexto Weiss (1999) descreve que possvel balancear o comportamento dos agentes
de um SMA em relao a pr-atividade e reatividade. Levamos em considerao na
6
escolha da arquitetura interna de cada agente que devemos escolher a arquitetura do
agente em relao funo que ele ir desempenhar no SMA. Consequentemente o
SMA envolve os seguintes agentes (Figura 4):
AgenteVendedor um agente reativo simples para ofertar computadores aos
clientes e receber o pagamento.
AgenteComprador um agente reativo baseado em conhecimento para decidir
quando realizar novos lances, o valor do lance e o realizar pagamento.
AgenteGerente um agente baseado em utilidade [Russell e Norvig 2004], que
dever encontrar uma melhor maneira de alocao dos recursos, frente a demanda
corrente, para maximizar o lucro e maximizar as vendas.
AgenteProduo um agente baseado em objetivo guiado por planejamento
[Russell e Norvig 2004]. Este agente responsvel por gerenciar o estoque e montar os
computadores frente demanda.
AgenteEntrega um agente baseado em objetivo guiado por plano. Este agente
responsvel por entregar os produtos do estoque aos clientes.

Figura 4. Diagrama de classes para TAC-SCM.
Na Figura 5 os agentes e seus relacionamentos descritos so representados atravs
do diagrama de Organizao criado atravs da nova verso de MAS-ML tool.
5. Trabalhos Relacionados
Considerando um escopo amplo em relao s ferramentas de apoio para a modelagem de
SMAs, a ferramenta Prometheus Design Tool (PDT) e AgentTool [AgentTool 2010]
podem ser citadas. A ferramenta PDT foi idealizada com o objetivo de dar suporte
metodologia Prometheus [Padgham, Thangarajah e Winikoff 2008], enquanto que
AgentTool est associada metodologia de desenvolvimento de SMAs O-MaSe
(Organization-based Multiagent Systems Engineering) [Garcia-Ojeda, DeLoach e Robby
2009]. Uma questo essencial que as ferramentas diferem-se na linguagem de
modelagem por elas suportadas, assim, as vantagens e limitaes dessas linguagens so
propagadas para as ferramentas que as implementam.

7

Figura 5. Diagrama de Organizao para o estudo de caso do TAC-SCM.
8
VisualAgent [De Maria et al. 2005] um ambiente de desenvolvimento de software
que visa auxiliar desenvolvedores na especificao, projeto e implementao de SMAs.
Ela tambm prope uma abordagem dirigida por modelo para o desenvolvimento de
SMAs fazendo uso do ASF (Agent Society Framework) [Silva, Corts e Lucena 2004], o
que representa um ponto relevante da abordagem. Similarmente, MAS-ML tool [Farias et
al. 2009] um ambiente de modelagem especfico de domnio que atende modelagem
de MAS de acordo com a especificao do metamodelo de MAS-ML. Adicionalmente,
MAS-ML tool fornece mecanismos para realizar verificao de regras de boa forma dos
modelos em relao ao metamodelo da MAS-ML. A ausncia desta funcionalidade em
VisualAgent pode comprometer a qualidade dos modelos e cdigo gerados. Alm disso, a
falta de documentao e acesso ao cdigo fonte dificulta sua evoluo.
6. Concluses e Trabalhos Futuros
Este artigo apresenta a evoluo de uma ferramenta, que consiste em uma prova
conceitual da linguagem de modelagem MAS-ML em sua verso 2.0, a qual adiciona
recursos para modelar agentes racionais de maneira adequada, propiciando um melhor
nvel de abstrao para representar caractersticas internas de SMAs. Partindo do
princpio que modelagem uma atividade essencial dentro do processo de
desenvolvimento de software, a existencia de ferramentas de apoio esta atividade se
torna de fundamental importncia. No presente trabalho apresentada a evoluo de um
ambiente de modelagem para SMAs com foco no diagrama de classes e organizaes da
MAS-ML 2.0. Com o ambiente possvel, dentre outras atividades, realizar a
modelagem, validar os modelos criados e realizar sua persistncia.
Como trabalhos futuros alguns melhoramentos podem ser realizados em relao
representao grfica dos construtores. Adicionalmente, o suporte para a modelagem dos
demais diagramas estticos da MAS-ML 2.0, bem como os diagramas dinmicos que no
foram contemplados neste trabalho sugerido.
Referncias
agentTool, http://agenttool.cis.ksu.edu/, acessado em 15 de Junho de 2010.
Arunachalam, R, (2004). The 2003 supply chain management trading agent
competition. In: Third International Joint Conference on Autonomous Agents &
Multi Agent Systems. p. 113120.
Bellifemine, F. L.; Caire, G.; Greenwood, D. (2007) Developing Multi-Agent Systems
with JADE. [S.l.]: Wiley (Wiley Series in Agent Technology).
Bordini, R.; Wooldridge, M.; Hbner, J. (2007). Programming Multi-Agent Systems in
AgentSpeak using Jason, John Wiley & Sons.
Collins, J.; Arunachalam, R.; Sadeh, N.; Eriksson, J.; Finne, N.; Janson, S., (2006). The
Supply Chain Management Game for the 2007 Trading Agent Competition.
Available in http://www.sics.se/tac/tac07scmspec.pdf.
Czarnecki, K.; Eisenecker, U. (2000). Generative Programming - Methods, Tools, and
Applications, Adison-Wesley, June 2000.
De Maria, B. A.; Silva, V. T.; Lucena, C.J.P.; Choren, R. (2005). VisualAgent: A
Software Development Environment for Multi-Agent Systems. Proceedings of the
19 Simpsio Brasileiro de Engenharia de Software, Tool Track, Brazil.
Eclipse Platform (2009). www.eclipse.org, acessado em 15 de Julho de 2009.
9
Farias, K.; Nunes, I.; Silva, V. T. da; Lucena, C. J. P. de (2009). MAS-ML Tool: Um
Ambiente de Modelagem de Sistemas Multi-Agentes. Fifth Workshop on Software
Engineering for Agent-oriented Systems (SEAS@SBES 09), Brazil.
Garcia-Ojeda, J.; DeLoach, S.; Robby (2009). agentTool Process Editor: Supporting the
Design of Tailored Agent-based Processes, In: 24th Annual ACM Symposium on
Applied Computing, Honolulu, Hawaii, USA, pp. 8 - 12, March 2009.
GMF (2009). www.eclipse.org/modeling/gmf/, Acessado em 15 de Julho de 2009.
Gonalves, E. J. T.; Campos, G. L.; Corts, M. I.; Silva, V. T. da (2009). Modelagem de
Agentes Reativos utilizando MAS-ML. Fifth Workshop on Software Engineering for
Agent-oriented Systems (SEAS@SBES 09), Brazil.
Gonalves, E. J. T.; Corts, M. I.; Campos, G. L.; Silva, V. T. (2010). Extending MAS-
ML Tt Model Proactive and Reactive Sotware Agents. 12th International Conference
on Enterprise Information System (ICEIS 2010), Funchal, Portugal.
Jennings, N.; Wooldrige, M. (2000), Agent-Oriented Software Engineering, In
Bradshaw, J. (Ed.) Handbook of Agent Technology, AAAI/MIT Press.
Lind, J. (2001), Issues in agent-oriented software engineering, In: Ciancarini P. e Wooldride
M., Agent-Oriented Software Engineering, LNCS 1957, Germany, Springer, p.45-58.
Mubarak, H. (2008), Developing Flexible Software Using Agent-Oriented Software
Engineering, IEEE Software, Sep/Oct, IEEE Computer Society, pp. 12-15.
Nunes, C.; Kulesza, U.; Sant'Anna, C.; Nunes, I.; Garcia, A.; Lucena, C. (2009),
Assessment of the Design Modularity and Stability of Multi-Agent System Product
Lines, Journal of Universal Computer Science.
Nunes, I.; Nunes, C.; Kulesza, U.; Lucena, C. (2009) Developing and Evolving a Multi-
Agent System Product Line: An Exploratory Study. In Agent-Oriented Software
Engineering IX: Springer-Verlag, v. 5386, p. 228-242.
Padgham, L.; Thangarajah, J.; Winikoff, M. (2008) Prometheus Design Tool, in 23th
AAAI Conference on Artificial Intelligence, Chicago, EUA, pp.1882-1883.
Pokahr, A.; Braubach, L.; Lamersdorf, W. (2003). Jadex: Implementing a BDI-
Infrastructure for JADE Agents. EXP - In Search of Innovation (Special Issue on
JADE), vol. 3, no. 3 , Telecom Italia Lab, Turin, Italy, S. 76-85.
Sadeh, N.; Arunachalam, R.; Erikson, J.; Finne, N.; Janson, S., (2003). A supply-chain
trading competition. AI Magazine, v. 24, n. 1, p. 9294.
Silva, V. T.; Choren, R.; Lucena, C. J. P. de (2007). MAS-ML: A Multi-Agent System
Modeling Language. Conference on Object Oriented Programming Systems
Languages and Applications (OOPSLA), ACM Press, pp. 304-305.
Silva, V. T.; Corts, M.; Lucena, C. (2004). An Object-Oriented Framework for
Implementing Agent Societies. MCC32/04. Technical Report, PUC-Rio. Brasil.
Silva, V. T.; Lucena, C. (2004), In: K. Sycara, M. Wooldridge (Eds.), Journal of
Autonomous Agents and Multi-Agent Systems, Kluwer Academic Publishers.
Weiss, G. (1999). Multiagent Systems: A Modern Approach to Distributed Artificial
Intelligence. MIT Press, Massachusetts.
Wooldridge, M.; Ciancarini, P. (2001), Agent-Oriented Software Engineering: the State
of the Art, In Agent-Oriented Soft. Eng., LNCS1957,Springer, p. 1-28.
10

NormML: A Modeling Language to Model Norms
Karen Figueiredo, Viviane Torres da Silva
Computer Science Department, Universidade Federal Fluminense (UFF)
Rua Passos da Ptria 156, Bloco E, 24210-240, Niteri, Brazil
{kfigueiredo, viviane.silva}@ic.uff.br
Abstract. Norms in multi-agent systems are mechanisms used to restrict the
behavior of agents by defining what agents are obligated, permitted or
prohibited to do and by stating stimulus to their fulfillment while defining
rewards and discouraging their violation while pointing out punishments. In
this paper we propose a normative modeling language called NormML that
makes possible the modeling of the main properties and characteristics of the
norms. In addition, we also propose a mechanism to validate the norms at
design time, i.e., to check if the norms respect the constraints defined by the
language.
1. Introduction
Norms are used to regulate the behavior of the agents in open multi-agent systems
(MAS) by describing their permissions, prohibitions and obligations. Norms can be
defined at design time together with the modeling of the system, or created at runtime by
agents that have the power to do so [Lpez y Lpez 2003]. In this paper we focus on the
description of norms at design time. The modeling of norms is an important part of the
specification of a system and should be treated as an essential task of MAS design.
Norms refer to actions and entities that compose a system. So, the refinement of the
system may influence the norms and the definition of a new norm will only be possible
if the actions, agents and roles being mentioned in the norm are being considered in the
system design.
Although there are many modeling languages and notations, proposed by
methodologies and organizational models, that provide support to the modeling of
norms, there is still a need for an approach that contemplates the main properties and
characteristics of a norm, i.e., the key elements that compose a norm: deontic concept,
involved entities, actions, activation constraints, sanctions and context. In this paper we
identify these elements by following the premise that norms restrict the behavior of
system entities during a period of time and define the sanctions applied when violated
or fulfilled. Such elements were found out after investigating some specification and
implementation languages used to describe and implement norms, such as [Garca-
Camino et al. 2006, Silva 2008, Vasconcelos et al. 2007].
It is the aim of the paper to present a normative modeling language called
NormML that is able to model the main elements that compose the norms. The
remainder of this paper is organized as follows. Section 2 discusses the support given by
the modeling languages and the notations provided by the methodologies and
organizational models analyzed to model the norm elements that we have identified. In
11

Section 3 we provide some background material about meta-modeling and about a
domain-specific language (DSL) for modeling role based access control policies called
SecureUML [Basin et al. 2006] that is the basis of our modeling language. Section 4
presents the normative modeling language NormML that is an extension of its
preliminary version presented in [Silva et al. 2010]. In this section we also details the
mechanism used to check for conflicts between the modeled norms. Finally, Section 5
concludes and presents some future work.
2. Related Work
We have analyzed how two MAS modeling languages, seven notations of
methodologies and three organization models support the modeling of norms and the
elements refereed in the above section
1
.
Deontic concept: In multi-agent systems, concepts of deontic logic [Meyer and
Wieringa 1991] have been used to describe normative behavior restrictions for the
agents in the form of obligations (what the agent must execute), permissions (what the
agent can execute) and prohibitions (what the agent cannot execute). Most of
modeling languages and methodologies make available the deontic concept of
obligation, but only few works provide the three deontic concepts: obligation,
permission and prohibition. Methodologies such as Secure Tropos [Giorgini et al 2006]
and SODA [Omicini 2001] and the organization model proposed in [Hbner et al. 2002]
do only offer the concepts of obligation and permission since they consider that
everything that is not permitted is automatically prohibited. In the Secure Tropos
methodology the concept obligation can be represented by the delegation relationship
and the concept of permission by the ownership and trust relationships. NormML,
different from the majority, includes all the three deontic concepts (obligation,
permission and prohibition) to the modeling of norms.
Involved entities: Since norms are always defined to restrict the behavior of entities,
the identification of such entities whose behavior is being restricted is fundamental. A
norm may regulate the behavior of individuals (i.e., a given agent, or an agent while
playing a given role) or the behavior of a group of individuals (i.e., all agents
playing a given role, groups of agents, groups of agents playing roles or all agents in the
system). All languages, methodologies and organization models analyzed propose a
way to describe the entities to which the norm applies. The majority provides
support to describe a norm for a particular agent playing a role. But the ones presented
in [Cossentino 2005, Hbner et al. 2002] do not allow the description of norms that
apply to a group of individuals. By using NormML it is possible to describe norms to
individuals, groups of individuals or all the entities of the system (see Context).
Actions: Since a norm defines restriction over the execution of entities, it is
important to clearly represent the action being regulated. Such actions can be
communicative ones, typically represented by the sending and receiving of a
message, or non-communicative actions (such as to access and modify a resource, to
enter in an organization, to move to another environment, etc.). In this paper we have

1
Due to space limits we could not reference all related works analyzed as we have done in [Silva et al.
2010] for the previews version of the language.
12

not taken into account norms applied to states. All the modeling languages,
methodologies and models analyzed provide a way to restrict non-communicative
actions. In [Cossentino 2005, Dignum 2004, Ferber et al. 2003, Giorgini et al 2006,
Zambonelli et al. 2003] it is also possible to restrict communicative ones. NormML
supports the modeling of both kinds of actions, communicative and non-communicative.
Activation constraints: The norms have a period during while they are active,
i.e., during while their restrictions must be fulfilled. Norms can be activated by one
constraint or a set of constraints that can be: the execution of actions, the specification
of time intervals (before, after, between), the achievement of systems states or temporal
aspects (such as dates), and also the activation/deactivation of another norm and the
fulfillment/violation of a norm. None of the analyzed works supports the description of
all the kinds of activation constraints mentioned. By using NormML all these activation
constraints can be modeled.
Sanctions: When a norm is violated the entity that has violated this norm may
suffer a punishment and when a norm is fulfilled the entity who has followed the
norm may receive a reward. Such rewards and punishments are called sanctions and
should be described together with the norm specification. A small number of languages
and methodologies consider that norms can be violated, and only few of them
provide a way for describing sanctions. The AORML language [Wagner 2003]
assumes that commitments (or obligations) between entities of the system can be
violated, and, as consequence, a sanction should be applied. But the language does not
offer a way to describe this sanction. The organizational models in [Dignum 2004,
Ferber et al. 2003, Hbner et al. 2002] consider that norms can be violated, and,
excluding the work of Hbner et al. (2002), they have mechanisms to describe
sanctions. The Gaia [Zambonelli et al. 2003] and PASSI [Cossentino 2005]
methodologies express norms as organization rules that cannot be violated, and so
there is no need to define a sanction mechanism. None of the analyzed languages or
methodologies allows the description of rewards in case of the fulfillment of a norm.
However, NormML support the definition of both punishments and rewards.
Context: Norms are usually defined in a given context that determines the area of its
application. A norm can, for instance, be described in the context of a given
environment and should be fulfilled only by the agents executing in the environment or
can be defined in the context of an organization and fulfilled only by the agents playing
roles in the organization. All languages, methodologies and organizational models only
define the norms in an organizational context. Besides describing norms in an
organizational context, NormML also provides the environmental context.
3. Background
In this section some background material for the rest of this paper is presented.
NormML is a UML-based modeling language for the specification of norms that
constraint the behavior of MAS entities. The choice for UML as metalanguage allows
for an easy integration of NormML with other MAS modeling languages also based in
UML such as AUML [Odell 2000] and MAS-ML [Silva et al. 2008]. Therefore, Section
3.1 introduces basic notions of models and metamodels, necessary to understand the
design of our language.
13

NormML was designed with the view that norm specification in MAS design
and security policy specification in RBAC Role-Based Acess Control [Ferraiolo et al.
2007] design are closely coupled issues. RBAC security policies specify the permissions
that a user has under a given role, while trying to access system resources. In MAS we
specify the norms that regulate the behavior (or actions) of a role, an agent or an agent
playing a given role. Although we consider security policies and norms coupled issues,
norms can be violated since they only define how the involved entities of the norm
should behave. In Section 3.2 we introduce SecureUML [Basin et al. 2006] that is a
domain-specific language (DSL) for modeling role based access control policies. The
points that motivate us to chose SecureUML were the well-defined syntax, given by its
metamodel, a formal semantics and its specific design for RBAC modeling.
3.1. Models and Metamodels
A modeling language offers a vocabulary (concepts and relations) for creating models.
Such vocabulary is described by the metamodel of the modeling language which
elements formalize the language concepts and their relationships. A metamodel may
include invariants that describe additional properties that the models must fulfill as
instances of the metamodel. Such invariants specify the well-formedness conditions (or
well-formed rules) of a model with respect to its metamodel and the consistency
conditions between metamodel concepts.
By using UML as metalanguage, a metamodel is represented as a class diagram
and its invariants are written in OCL (Object Constraint Language) [OMG 2010]. This
is the choice followed in this work.
3.2. SecureUML
SecureUML provides a language for modeling Roles, Permissions, Actions, Resources,
and Authorization Constraints, along with the relationships between permissions and
roles, actions and permissions, resources and actions, and constraints and permissions.
SecureUML leaves open what the protected resources are and which actions they offer
to clients. ComponentUML [Basin et al. 2006] is a simple language for modeling
component-based systems that provides a subset of UML class models: entities can be
related by associations and may have attributes and methods.
Therefore, Entity, Attribute, Method, Association and AssociationEnd are the
possible protected resources. The actions that can be used to restrict the access to these
resources can be either Atomic or Composite. The atomic actions are intended to map
directly onto actual operations of the modeled system (delete, update, read, create and
execute). The composite actions are used to hierarchically group atomic ones. By using
such SecureUML+ComponentUML
2
it is possible, for instance, to specify the
permissions a user playing a given role must have to execute a method (or to update an
attribute) of a resource. In order to do so, it is necessary to instantiate the metaclasses
User, Role, Permission, ActionExecute, Method (or ActionUpdate) and Attribute.

2
The metamodel of SecureUML+ComponentUML (from now referred as SecureUML metamodel) is available at
http://www.ic.uff.br/~viviane.silva/normML/secureUML.pdf
14

4. The Normative Modeling Language
As stated before, norms are viewed as security policies. While in SecureUML it is
possible to define the permissions a user has, i.e., the constraints that a user, in a given
role, must fulfill to perform actions over the system resources, in NormML it is possible
to define the norms an entity must obey, i.e., it is possible to describe the set of actions
that the agents, roles or agents playing roles in an particular context are obliged,
permitted or prohibited to execute conditioned by the execution of other actions and the
achievement of dates and states. The language also permits the definition of sanctions to
be applied in case of fulfillment or violation of the norms.
The preliminary version of NormML metamodel [Silva et al. 2010] extends the
SecureUML metamodel with the following basic elements: Norm, NormConstraint,
Agent and AgentAction. In current version of the language, the metamodel includes the
following new elements: Organization, Environment, Message, Protocol and Sanction,
new norm constraints and new action types (see Section 4.1). The NormML metamodel
also includes a set of invariants that guarantees the well-formedness of a norm (Section
4.2).
4.1. Metamodel
A norm corresponds to an instance of the NormML metamodel, i.e., it is defined by
instantiating several metaclasses and their relationships. In this section, we present the
NormML metamodel
3
focusing in the definition of the main elements that compose a
norm.
Deontic concept: A norm is either an obligation (represented by the metaclass
NormObligation), a prohibition (represented by the metaclass NormProhibition) or a
permission (represented by the metaclass NormPermission), as illustrated in Fig. 1.
Involved entities: In the preliminary version of the language, a norm could only be
described to regulate the behavior of Agents, the behavior of all agents that play a given
Role, or the behavior of a specific agent when it is playing a given role, captured by the
Agent<->Role relationship. Nowadays, it is also possible to define a norm to a group of
agents by using the metaclass Organization (as pointed up in Fig. 2). In this paper, we
do not make any distinction among the definition of group, team and organization. A
norm can also be defined to all agents executing in a given context. In such case, it is
only necessary to relate the norm to a context without specifying the entities whose
behavior is being regulated (see norm N1 in Fig. 7 for an example).
Actions: NormML inherits four resource kinds from SecureUML: Attribute, Method,
Entity and AssociationEnd. It extends the set of resources with agent and roles actions
represented by the metaclass AgentAction and with roles messages represented by the
metaclass Message that is part of a communication protocol of a role (Protocol
metaclass). Thus, it is possible to describe norms to control the access to attributes,
methods, objects and association ends, to control the execution of the actions of agents
and roles, and also to control the sending and the receiving of messages by roles (Fig.
3).

3
The whole picture of the NormML metamodel is available in http://www.ic.uff.br/ ~viviane/normML/metamode.pdf
15

Fig.1 Deontic concept related
metaclasses at the NormML
Metamodel

Fig. 2. Involved entities related meta
classes at the NormML Metamodel
Each resource kind has a set of actions that can be used to control the access to
the resource. For instance, the actions read, update and full access (read+update) can be
used to regulate the access to attributes. In the case of restrictions applied to actions of
agents and roles (AgentAction metaclass), the behavior that must be used is the
execution of the action (AtomicExecute). Note that AgentAction is the resource and
AtomicExecute is the action being used to control or restrict the access to the resource.
In the case of restrictions applied to messages of roles communication protocols
(Message metaclass), the behavior that must be used is the sending of the message
(AtomicSend), the receiving of the message (AtomicReceive) or the full access
(send+receive) of the message (MessageFullAccess). Fig. 3 illustrates all metaclasses
that define the resources and the actions.

Fig. 3. Actions related metaclasses at the NormML Metamodel
Activation constraints: The preliminary version of NormML allows for the
specification of the time period that a norm is active based on the execution of actions.
16

The language was extended to define activation constraints also based on the definition
of dates and predicates (i.e., values associated with attributes), as shown in Fig. 4.
The activation constraints are represented by the metaclass NormConstraint. If a
norm is conditioned by a Before clause, it means that the norm is active before the
execution of the action(s) and/or the achievement of the date(s) described in the Before
clause. If a norm is conditioned by an After clause, it means that the norm is active only
after the execution of the action(s) and/or the achievement of the date(s) described in the
After clause. In the case of a Between clause, the norm is only active during the period
delimited by two groups of actions and dates. In the case of a norm conditioned by an If
clause, the norm is only active when the value(s) of the attribute(s) described in the If
clause is (are) achieved.

Fig. 4. Activation constraints related
metaclasses at the NormML Metamodel

Fig. 5. Sanction related
metaclasses at the NormML
Metamodel

Sanctions: The current version of NormML supports for the description of sanctions
(Sanction metaclass) to the norms, as shown in Fig. 5. A sanction may be a reward
applied when the norm is fulfilled (by instantiating the metaclass Reward) or a
punishment applied when the norm is violated (by instantiating the metaclass
Punishment). A sanction can state an action or a set of actions to be executed after the
fulfillment/violation of the norm (represented by the SanctionAppliesAction
relationship) or can activate other norms to restrict the behavior of some particular
entities (represented by the SanctionAppliesNorm relationship). For instance, in case an
agent violates a norm, another norm is activated to prohibit the agent of executing a
particular action.
Context: The recent version of NormML makes possible the definition of norms in
two different contexts, as illustrated in Fig. 6: Organization and Environment.
Organizations define roles played by agents and both organizations and agents inhabit
environments.
In order to exemplify the use of NormML to model the norms of a MAS,
consider following norms N1 and N2 (Fig. 7 and 8).
17

N1: All agents executing in the context of the environment MarketPlace are prohibited
to read and updateattributeFullAccessthe attribute price of the entity good.
N2: Sellers are permitted, in the context of the organization WebStore that inhabits the
environment MarketPlace, to update the attribute price of the entity good before it
opens for sale.

Fig. 6. Context related metaclasses at the NormML Metamodel

Fig. 7. Norm N1

Fig. 8. Norm N2
4.2. Validating the Norms
The process of validating a norm encompasses two steps. First, the norm, as an instance
of the NormML metamodel, is checked according to the invariants of the metamodel.
The invariants check if the norm is well-formed according to the metamodel
specification. The second step checks if any given two norms are in conflict. Second, it
is important to check for conflicts among norm. This paper focuses on the first step.
18

The current version of NormML has a set of operations described in OCL to
check the invariants of the norms
4
. Not all the norms that can be instantiated from the
metamodel are well-formed. Below we describe two examples of well-formed rules of
the NormML metamodel. Those were chosen since they represent rules that are related
to the specification of the norms themselves and discuss some of the new elements
included in the actual version of the language.
WFR1: The action to be executed by an entity that is defined in the Before clause of a
Between cannot also be defined in the After clause of such Between to be executed by
the same entity in the same context. If the actions in the Before of a Between and in the
After of a Between are the same, are related to the same entity (an agent, a role or an
agent playing a role) and executed in the same context, this situation does not constitute
a time period, but a moment in the time.
WFR2: If the norm applied to an entity is constrained by an If whose condition is the
value of an attribute, the entity of the norm must have permission to read this attribute.
The entity related to a norm that states an If constraint must be able to read the attribute
associated to the constraint (by a permission of read or full access to the Attribute or to
the Entity which the attribute belongs), otherwise the entity will not be capable of
knowing when the norm is active.
5. Conclusions and Future Work
In this paper we presented the normative modeling language NormML by emphasized
the contributions of the language when compared with other modeling languages and
notations used by methodologies and organization models. In Section 2 we described the
main elements of a norm and pointed out the support given by those approaches on the
modeling of such elements.
With the preliminary version of NormML it was possible (i) to model
permissions, prohibitions and obligations; (ii) to regulate the behavior of agents and
roles; (iii) to define norms that restrict the execution of non-dialogical actions; (iv) to
define activation constraints based on the execution of actions. By using the current
version of NormML it is possible (i) to model norms associated with different contexts;
(ii) to regulate the behavior of groups of individuals (or organizations); (iii) to define
norms that restrict the execution of dialogical actions; (iv) to define activation
constraints based on the definition of deadlines and predicates (values associated with
attributes); and (v) to define sanctions associated with the norms. We are in the process
of extending the language to define norms that restrict the achievement of states. The
development of the operations for the verification of conflicts is still in course. It is also
our aim to develop a graphical tool for modeling and validating norms using NormML.
References
Basin, D., Doser, J. and Lodderstedt, T. (2006) Model driven security: from UML
models to access control infrastructures, ACM TSEM,15(1), pp.39-91.

4
Some of the well-formed rules of the NormML metamodel are available in
http://www.ic.uff.br/~viviane.silva/normML/normML.pdf
19

Cossentino, M. (2005) From requirements to code with the PASSI methodology, In
Agent-oriented Methods, Idea group, pp. 79-106.
Dignum, V. (2004) A model for organizational interaction: based on agents, founded in
logic, PhD dissertation, Universiteit Utrecht, SIKS dissertation series 2004-1.
Ferber, J., Stratulat, T. and Tranier, J. (2009) Towards an integral approach of
organizations: the MASQ approach in multi-agent systems, In Multi-agent
Systems: Semantics and Dynamics of Organizational Models, IGI.
Ferraiolo, D. F., Kuhn, D. R. and Chandramouli, R. (2007) Role-based access control,
Artech House Publishers, 2nd Edition.
Garca-Camino, A., Rodrguez-Aguilar, J., Sierra, C and Vasconcelos, W. (2006)
Norm-oriented programming of electronic institutions, In Proc. 5th AAMAS, ACM
Press, pp. 670-672.
Giorgini, P., Mouratidis, H. and Zannone, N. (2006) Modelling security and trust with
Secure Tropos, In Integrating Security Soft.Eng.:Advances and Future Vision.
Hbner, J. F., Sichman, J. S. and Olivier, B. (2002) A model for the structural,
functional and deontic specification of organizations in multiagent systems, In
Proc. 16th SBIA, LNAI 2507.
Lpez y Lpez, F. (2003) Social power and norms: impact on agent behavior, PhD
thesis, Univ. of Southampton, Department of Electronics and Computer Science.
Meyer, J. J. and Wieringa, R. J. (1991) Deontic logic in computer science: normative
system specification, John Wiley and Sons.
Object Management Group (2010) OCL Specification, OMG,
http://www.omg.org/docs/ptc/03-10-14.pdf, Accessed: May. 1, 2010.
Odell, J., Parunak, H. and Bauer, B. (2000) Extending UML for agents, In Proc.
Agent-Oriented Information Systems Workshop at National Conf. of AI, pp. 3-17.
Omicini, A. (2001) SODA: societies and infrastructures in the analysis and design of
agent-based systems, In Agent-Oriented Software Engineering, LNCS 1957.
Silva, V. (2008) From the specification to the implementation of norms: an automatic
approach to generate rules from norms to govern the behaviour of agents, In
IJAAMAS, Special Issue on Norms in Multi-Agent Systems, (17)1, pp. 113-155.
Silva, V. T., Braga, C. and Figueiredo, K. (2010) A modeling language to model
norms, Proc. of COIN@AAMAS, Toronto, Canada, pp. 25-32.
Silva, V. T., Choren R. and Lucena, C.(2008)MAS-ML: a multi-agent system
modelling language,In IJAOSE, Modeling Lang. for Agent Systems,(2)4pp.382-421.
Vasconcelos, W., Kollingbaum, M. and Norman, T. (2007) Resolving conflict and
inconsistency in norm-regulated virtual organizations, In Proc. AAMAS07.
Wagner, G. (2003) The Agent-Object-Relationship meta-model: towards a unified
view of state and behavior, Information Systems, 28(5), pp. 475504.
Zambonelli, F., Jennings, N. R. and Wooldridge, M. J. (2003) Developing multiagent
systems: the Gaia methodology, ACM TSEM, 12(3):417-470.
20

A Semiotic Taxonomy to Support Multiagent Systems
Situational Development
Sara Casare, Anarosa A.F. Brando, Jaime S. Sichman
Departamento de Engenharia de Computao e Sistemas Digitais
Escola Politcnica Universidade de So Paulo (USP)
Av. Prof. Luciano Gualberto, 158, trav 3 05508-970 So Paulo SP Brazil
{sara.casare, anarosa.brandao, jaime.sichman}@poli.usp.br
Abstract. This paper proposes a MAS Semiotic Taxonomy as a first step
towards combining the advantages from both AOSE methods and AI inspired
Agent Organization (AO) models to provide a set of categories that allows a
better identification of different MAS development aspects related to these two
approaches. The taxonomy has three complementary inspiration sources: (i)
MAS specific development aspects originated from AOSE and AO; (ii)
Situational Method Engineering related concepts, mainly those proposed by
Harmsen; and (iii) method content and method process notions provided by
the Software & System Process Engineering Meta-Model Specification -
SPEM 2.0. An example of the taxonomy use is also presented. This paper
details results presented in an extended abstract of the AAMAS 2010 edition.
1 Introduction
In order to structure the development and to manage the complexity associated with
Multiagent Systems (MAS), several development methods have been proposed in
AOSE field during the last decade, e.g. Gaia (Zambonelli et al, 2003), Tropos
(Bresciani et al, 2004), Ingenias (Pavon et al, 2005) and PASSI (Cossentino, 2005),
among other. Additionally, following the AI tradition in MAS different agent
organization (AO) models such as AGR (Agent, Group, Role) (Ferber et al, 2004),
OperA (Organization per Agent) (Dignum, 2004) and MOISE+ (Model of Organization
for Multiagent Systems) (Hubner et al, 2002) were proposed. While a great part of
methods adopts an agent centered MAS approach, focusing on the agents behavior,
agent organization models consider the notion of group or agent organization as a
leading concept, called by some authors as an organization centered approach (Lemaitre
and Excelente, 1998).
Since AO models are not currently incorporated into AOSE based MAS development
methods, someone who adopts an organization centered approach to build a MAS do
not have tool support for using both AOSE methods and AO models together.
Nevertheless, using only AOSE methods or AO models separately may cause some
project drawbacks. On the one hand, MAS methods that offer a structured development
cycle may not adopt an explicit agent organization model. On the other hand, most AO
models do not provide a structured MAS development cycle in terms of phases, tasks
and work products.
Based on a semiotic approach (Stamper, 1996), this paper proposes a MAS Semiotic
Taxonomy that can be viewed as a first step towards combining the advantages from
21

both AOSE methods and AI inspired AO models, namely a structured project
development cycle using an organization centered approach. In order to develop such a
cycle, this taxonomy provides a set of categories that glues together both AOSE typical
aspects and AO models characteristics, allowing a better identification of different MAS
development aspects related to these two approaches.
This paper is organized as follows: Section 2 presents some MAS development issues,
section 3 presents situational method engineering aspects for MAS. Section 4 outlines
the set of categories that composes the MAS Semiotic Taxonomy while section 5
presents examples of how using this taxonomy to categorize the main development
aspects of a MAS AOSE method and an AO model. Finally, section 6 presents a
discussion about other usages for the Semiotic Taxonomy and points some future work.
2 MAS Development Issues
Lemaitre and Excelente (1998) suggest that the two main MAS research field
approaches are related to its main components: agent and group of agents. Research on
agent approaches proposes several formalisms for representing individual agent
architecture and agents internal knowledge, as beliefs, intentions and desires, among
others. In addition, research on group approaches adopts a sociological and
organizational vision for modeling MAS, involving organizations, teams and inter-agent
relationships notions. An AO model offers both a conceptual framework and syntax for
designing organizational specifications that can be implemented on a traditional agent
platform or by using some organizational middleware. In order to participate in an AO,
agents are supposed to previously know the organization main characteristics. In this
way, they can play available organization roles, contribute to achieve global goals,
participate in organization interactions and be aware of organization norms, as
permissions, obligations and rights (Coutinho et al, 2008). However, there is not
consensus in MAS research field concerning its key concepts, such as the agents and
their groups. An evidence of this lack of consensus is the Agent Metamodel and Profile
- Request For Proposal (RFP) (OMG, 2008a) launched by the Object Management
Group in order to request an agent metamodel representing capabilities applicable to
agents and to agent-based software.
The variety of MAS methods and other MAS development approaches, as AO models,
is due to the specific needs raised on MAS development and to the different approaches
adopted by MAS developers. It shows that a unique method cannot be general enough
in order to be applied to every MAS development project without some level of
customization (Guessoum et al, 2004). Nevertheless, it seems that reinventing a method
for each new project situation wouldnt be a best practice, given that there are a great
number of available methods for MAS development. This scenario suggests that
Method Engineering techniques (Brinkkemper, 1996) and, particularly, Situational
Method Engineering (Harmsen, 1997) seem to be promising approaches to be
considered for MAS development.
3 Situational Method Engineering
Situational Method Engineering is the sub-area of Method Engineering that addresses
the controlled, formal and computer-assisted construction of situational methods out of
method fragments. A Situational Method is a method tailored and tuned to a particular
project situation that is configured in a formal and computer-assisted manner out of
22

standardized and proven building blocks - called Method Fragments - stored in a data
base. A Method Fragment can describe either a whole development method or any
coherent part of it. A project situation involves factors such as users, organization
culture, project team characteristics (size, skill), project goals and system complexity
(Brinkkemper, 1996; Harmsen, 1997). Roughly speaking, building a situational method
consists on reusing portions of existing (and possibly distinct) methods taking into
account a given project situation that encompasses, for example, notions related to the
class of the desired application (like traditional and pervasive computing) and project
perspectives.
Situational method building involves distinct reuse mechanisms, such as assembly-
based (Harmsen, 1997) and method configuration mechanisms (Karlsson, 2005). While
an assembly-based mechanism begins the situational method building with assembling a
set of disconnected method fragment in a bottom-up fashion, method configuration
mechanism does it by taking a base method and modifying it to cover project
characteristics in a top-down fashion, adding or exchanging additional fragments
captured from another methods. However, reusing available MAS development
approaches in order to build a MAS situational method according to a specific project
situation raise some questions, such as: (i) How could project factors, such as team
skills and development procedures, involved in a MAS project be described? (ii) How
could MAS development approaches aspects be described? (iii) Finally, how could
MAS project factors be matched with several MAS development approaches to build an
appropriated method for the MAS project?
Several researchers are dealing with situational method engineering for MAS
development. Among them, Cossentino et al (2008) reported the experience of creating
a new process involving PASSI methodology and Rougemaille et al (2009) discussed
the main aspects related to MAS fragment definition. However, at the best of our
knowledge, we are not aware of researches proposing a broad collection of categories
for classifying and describing MAS aspects in order to support the customization of
situational methods for MAS. Moreover, we claim that a semiotic approach can offer
the backbone for describing MAS development aspects, given that such approach
allows identifying several characteristics typically involved in MAS development
(Casare et al, 2010a). Some of these aspects are its intention and usage (pragmatic), its
meaning (semantic) and its structure (syntactic) and are outlined in the next section.
4 MAS Semiotic Taxonomy
Semiotics deals with the syntactic (structure), semantics (meaning) and pragmatics
(usage) aspects of signs. Stamper (1996) proposed the Semiotic Ladder to treat
information as signs: he has extended the traditional division of Semiotics syntactic,
semantic and pragmatic - by including three new signs aspects called social (social
dimensions), empirics (statistics properties) and physical (hardware properties). Based
on such semiotic approach, we propose to use a MAS Semiotic Taxonomy to classify
several aspects involved in AOSE project development. In order to do so, we take into
account both the MAS development aspects associated with human information related
functions (such as MAS team skill and culture, MAS development usages and
meanings) and the MAS information technology aspects (like notation, language and
development platform). By using this taxonomy, someone that has a MAS project to be
developed can search for a good choice among the existing MAS development
23

approaches, such as AOSE methods and AO models. Having such a taxonomy may
improve, for instance, the performance of a MAS Method Engineer to build a MAS
Situational Method for a specific project situation (Figure 1)

Figure 1: Semiotic Taxonomy used by a MAS Method Engineer
The MAS Semiotic Taxonomy involves the following levels: Social Level, Pragmatic
Level, Semantic Level, Syntactic Level and Empirical Level. Using such a semiotic
perspective, this taxonomy puts together concepts originated from three main sources:
(i) MAS specific development aspects originated from AOSE and AO, (ii) Situational
Method Engineering related concepts, mainly those proposed by Harmsen (1997) and
(iii) method content and method process notions provided by the Software & System
Process Engineering Meta-Model Specification - SPEM 2.0 (OMG, 2008b).
The Semiotic Taxonomy can be used in two ways (Figure 1). First, it helps identifying
MAS development aspects supported by each MAS development approach as a whole.
For instance, in a pragmatic perspective, Tropos can be used to develop agent centered
MAS. Second, this taxonomy helps on classifying method fragments captured from
several MAS development approaches. For instance, in a pragmatic perspective, the
taxonomy could be used to support the search for fragments of MAS development
approaches to build organization centered MAS or to model system requirements in
terms of use cases.
As stated in section 2, a method fragment can describe a whole method or any coherent
part of it. Then, from now on we use the term Method Fragment to refer to both notions:
MAS development approaches as a whole and portions of them. In the following we
describe the Semiotic Taxonomy for MAS main concepts.
4.1 Social Level
Given that MAS projects involve a group of developers embedded in a social context -
as a software company or an academic research group - the Social Level of the Semiotic
Taxonomy allows distinguishing MAS development aspects related to rules,
preferences and procedures in such social development context. The Social Level
categories are: Utilization Degree, Success Degree, Reuse Degree, Validation Degree,
User Participation Degree, Iteration Type and Development Type. They are all inspired
in some fragment aspect defined by Harmsen (1997) and are described bellow.
24

Utilization Degree Category refers to the frequency in which a method fragment has
been applied in previous MAS projects, such as low, medium or high utilization
frequencies. Given that a method fragment can have a high utilization degree but a rare
contribution to the project success, the Success Degree Category allows identifying in
which frequency a method fragment had contributed to a MAS project success or
failure, classifying them as a positive, neutral or negative contributor.
Reuse Degree Category refers to the reutilization level provided by a method fragment,
such as high or low reuse degrees. A MAS project team that prefers reusing components
instead of building new ones could take advantage of choosing method fragments
sourced from Ingenias methods, given that they are among those MAS development
approaches that recommend MAS component library usage. Validation Degree
Category refers to the system validation effort involved in a MAS project, as high
validation or low validation degrees. A project team in charge of a MAS critical system
should use this category to prioritize using method fragment of high validation degree.
User Participation Degree Category refers to the expected user involvement during
MAS development, such as high or low user participation degrees. A MAS project team
that has a rule of involving final users during all system development process could use
this category in order to identify appropriated method fragments. Iteration Type
Category refers to the extent to which a method fragment contributes to a linear or to
an iterative MAS development cycle. Finally, Development Type Category refers to
the MAS building approach such as experimental development or analytical
development. An experimental development approach involves prototype building and
evolution while an analytical development approach is not strongly based on prototypes.
4.2 Pragmatic Level
The Pragmatic Level allows distinguishing MAS development aspects based on their
usage and intention. This level is composed of the following categories: Agent
Discipline Category, Group Discipline Category, Analysis Style Category, MAS
Approach Category, Fragment Source Category, MAS Nature Category and Agent
Architecture Category.
Agent Discipline Category refers to the classification of MAS method fragment
intention concerning the agent model aspects. In order to populate this category we have
adopted some of the main agent concepts presented in the Agent Metamodel and Profile
RFP (OMG,2008a). They are the following: agent, capability, goal, interactive, policy,
and role. Group Discipline Category refers to the classification of MAS method
fragment intention concerning the AO model aspects. To populate this category we have
adopted the dimensions for analyzing organization models proposed by Coutinho et al
(2008): Organizational Structure, Organizational Interactions, Organizational Functions
and Organizational Norms. Organizational Structure refers to the organization static
aspects in terms of groups and roles. Organizational Interactions refers to agent actions
and interactions aspects in a given organization while Organizational Functions refers to
organization global goals, involving goal notions as well as tasks decomposition.
Finally, Organizational Norms refers to normative organizational aspects as norms,
rights and rules.
25

MAS Approach Category refers to the classification of method fragment intention
concerning the two main approaches into MAS research field - the agent approach and
the group approach (Lemaitre and Excelente, 1998). In agent approaches, also called
Agent Centered MAS, social concepts, such as social commitment and goal adoption,
are focused on the agents behavior. In group approaches, also called Organization
Centered MAS, the leading concept is the group and the organization instead of the
agent. Analysis Style Category refers to the classification of method fragment
intention concerning the main abstraction used to gathering and representing MAS
requirements. After analyzing several MAS methods (among them Gaia, Tropos,
PASSI, Ingenias) we have identified three main MAS analysis style: Multiagent based
Analysis (where the main abstractions are the individual agent, roles, interactions and
organizations), Goal based Analysis (that involves the goal notion as its main
abstraction) and Use Case based Analysis (where MAS requirements are described
through use case models).
MAS Nature Category refers to the classification of method fragment intention
concerning open MAS - where agents are able to come in and out any time during the
MAS execution life cycle - and closed MAS, where agents participate in the whole
MAS execution life cycle. Agent Architecture Category refers to the classification of
method fragment intention concerning MAS agent architecture such as deliberative,
reactive or hybrid agent architecture. Finally, Fragment Source Category (Harmsen,
1997) allows identifying the MAS development approach that is the source of a method
fragment.
4.3 Semantic Level
The Semantic Level allows distinguishing MAS development aspects based on their
meaning. In the context of such taxonomy meaning refers to the classification of the
method fragment specific meaning given by a software and process engineering meta-
model, such as SPEM 2.0. This level involves two categories: Fragment Content
Category and Fragment Process Category. The Fragment Content Category classifies a
method fragment in terms of its content and, the Fragment Process Category classifies it
in terms of the MAS development phase.
In order to define the Fragment Content Category we have adopted the related
concepts proposed by SPEM 2.0: Work Product, Process Role, Task and Guidance.
Work Product consists of the things that are used, modified and produced during a
project development, as use case models and organization diagrams. Process Role
identifies a set of skills and competencies, as developer, architect, modeler and tester,
while Task describes a unit of work that can be assigned to a specific process role.
Finally, Guidance provides additional information about work product generation and
task execution, such as guidelines and checklists. For the Fragment Process Category
we have adopted the most common MAS software development stages: Requirement,
Analysis, Design, Implementation and Testing.
4.4 Syntactic Level
The Syntactic Level allows distinguishing MAS development aspects according to their
structure and format. In order to do it, this level takes into account the notation and the
language used in order to structure and to express them. This level involves three
26

categories: Fragment Notation Category, Language Paradigm Category and Fragment
Language Category.
Fragment Notation Category refers to the classification of method fragment structure
in terms of its notation. The main notations adopted by AOSE methods and AO models
are graphical notation (as UML), textual notation (as natural language) and
mathematical notation (as algorithm, first order logic, modal logic). Language
Paradigm Category refers to the classification of method fragment structure in terms
of the language type. Both declarative language (as Prolog) and imperative language (as
Java) are adopted for AOSE methods and AO models. Fragment Language Category
refers to the classification of method fragment specific language. AOSE methods and
AO models involve as main languages those based on UML, AUML (Odell et al., 2000)
and Modal Logic as well as Java and Prolog.
4.5 Empirical Level
The Empirical Level allows distinguishing MAS development aspects according to their
development standards and patterns. It is done through two categories: Code Generation
Category and Development Platform Category.
Code Generation Category refers to the classification of method fragment standards
and patterns concerning the code generation approach as model driven approach
(MDA), automatic code generation and manual code generation while Development
Platform Category refers to the classification of method fragments development
platform, such as BDI platform and object oriented platform.
5 Using the Semiotic Taxonomy
In this section we present two examples of how to use the MAS Semiotic Taxonomy to
categorize some development aspects of an AOSE method and an AO model, Tropos
and MOISE+ respectively. Tropos is an AOSE method that proposes a set of primitive
concepts - as actor, goal, dependency and role - and a process for building agents
involving the phases Early Requirements, Late Requirements, Architectural Design,
Detailed Design and Implementation. The goal of the first two phases is to provide sets
of functional and non-functional requirements for the system to be, while Architectural
Design and Detailed Design phases focus on the system specification.
Table 1 shows an example of how categorizing a set of development aspects of Tropos
in a semiotic perspective. It is worthy to notice that this categorization does not indicate
that a given fragment, i. e. a whole method or part of it, is better or worthy than other.
Instead, it helps selecting the more adequate fragments for a specific project situation.
As an example, let us consider the category Analysis Style, that belongs to the
Pragmatic level of the taxonomy. Regarding this category Tropos is classified as a
goal based analysis method fragment. Hence, whenever a project team is skilled in
this analysis style, Tropos could be a candidate method to be used; on the other hand, if
a project team is more skilled in another analysis style (for instance, use case based
analysis), one could use our taxonomy and realize that Tropos wouldnt be an adequate
method in this situation, and a different method fragment (or a combination of
fragments) could be used.
27

Table 1 Tropos in a semiotic perspective
MOISE+ is an AO model for MAS that distinguishes three organizational dimensions to
explain how a MAS organization can be designed: the Structural Specification, the
Functional Specification and the Deontic Specification. The Structural Specification
addresses the static aspects of an organization and involves as main concepts role, link
and group. The Functional Specification describes how organizational goals should be
achieved, stating how these goals are decomposed and distributed to the agents. Finally,
the Deontic Specification addresses the permissions and obligations related to roles.
These three specifications together form the Organizational Specification. Table 2
shows an example of the proposed taxonomy for categorizing some MOISE+
development aspects in a semiotic perspective.
These two examples show that putting together AOSE and AO techniques give a broad
coverage of the main MAS project development aspects concerning a situational
method creation for building an organization centered MAS. In fact, Tropos offers a
well established MAS development process and models for building agent centered
MAS for closed systems, while MOISE+ offers models for structuring agent
organizations for building organization centered MAS for open systems. Therefore, we
could define a situational method for building organization centered MAS in a top-
down fashion taking Tropos as the base method and adding fragments sourced from
MOISE+ in order to cover the AO aspects. We are currently working on this issue: in
(Casare et al., 2010b) we show how this taxonomy could be used as part of a MAS
Method Fragment definition intended to represent MAS development approaches in a
standardized and coherent way, thus facilitating the configuration of situational
methods.
28

Table 2: MOISE+ in a semiotic perspective
6 Conclusions
The MAS Semiotic Taxonomy proposed in this work offers a broad collection of
categories for classifying and identifying MAS development aspects from a whole
method as well as those MAS development aspects from a specific method portion. This
set of categories provides a clear way of stating the main characteristics of each method
fragment through social, pragmatic, semantic, syntactic and empirical perspectives,
answering part of the questions raised in section 3: how to describe the MAS
development aspects related to the existing development approaches as well as related
to MAS project factors, The remaining question, i.e., how to match the MAS project
factors with several MAS development approaches in order to build a situational
method, is part of our ongoing research work.
In this paper we have shown that a semiotic perspective could facilitate putting together
MAS development approaches from both AOSE and AO fields to take advantages from
both of them to build organization centered MAS. Moreover, it offers a collection of
criteria for choosing method portions among the existing MAS development approaches
in order to reuse them in different project contexts. We claim that such taxonomy could
also be helpful on creating MAS situational methods for a specific MAS project
involving several types of situational method reuse mechanisms, as assembly-based and
configuration mechanisms. In the first case this taxonomy could be used to select each
method fragment in a bottom-up fashion and, in the second case, to select a MAS base
method as well as additional method fragments in a top-down fashion.
Acknowledgments
This work is part of the MEDEIA project from FAPESP, Brazil, grant 2009/10121-4. Authors
are partially supported by CNPq and CAPES, Brazil.
References
Bresciani, P.; Giorgini, P.; Giunchiglia, F.; Mylopoulos, J. and Perini, A. (2004). Tropos: An
Agent-Oriented Software Development Methodology. Journal of Autonomous Agents and
Multi-Agent Systems, 8(3), 203-236.
Brinkkemper, S. (1996). Method Engineering: Engineering of Information Systems
Development Methods and Tools. Information and Software Technology, Vol.38 (4), 275-280.
Casare, S. Brando, A.A.F. and Sichman, J. (2010a) A Semiotic Perspective for Multiagent
Systems Development (Extended Abstract), Proc. of 9th Int. Conf. on Autonomous Agents
and Multiagent Systems (AAMAS 2010), van der Hoek, Kaminka, Lesprance, Luck and Sen
(eds.), May, 1014, 2010, Toronto, p. 1373-1374.
29

Casare, S. Guessoum, Z. Brando, A.A.F. and Sichman, J. (2010b) Towards a New Approach
for MAS Situational Method Engineering: a Fragment Definition, To appear in Proc. of
MALLOW FIPA DPDF, Lyon, August-September 2010.
Cossentino, M. (2005). From Requirements to Code with the PASSI Methodology. In:
Henderson-Sellers, B., Giorgini, P. (Eds.), Agent-Oriented Methodologies, Idea Group
Publishing, 79-106.
Cossentino, M.; Galland, S. ; Gaglio, S.; Gaud, N.; Hilaire, V.; Koukam, A. and Seidita, V.
(2008). A MAS metamodel-driven approach to process composition. Proceedings of the Ninth
Intl Workshop on Agent-Oriented Software Engineering (AOSE-2008) at AAMAS 2008.
Coutinho, L.; Sichman, J. S.; Boissier, O. (2008). Modelling Dimensions for Agent
Organizations. In: Virginia Dignum. (Org.). Multi-Agent Systems: Semantics and Dynamics
of Organizational Models. Hershey: IGI Global, 18-50.
Dignum, V. (2004). A model for organizational interaction based on agents, founded in logic.
Doctoral dissertation, Utrecht University, Utrecht.
Ferber, J.; Gutknecht, O. and Michel, F. (2004). From agents to organizations: an organizational
view of multi-agent systems. In: Agent-Oriented Software Engineering IV International
Workshop (AOSE2003), v. 2935, Springer, 214230.
Guessoum, Z; Cossentino, M. and Pavn, J. (2004). Roadmap of Agent-Oriented Software
Engineering The AgentLink Perspective. In: F. Bergenti, M. P. Gleizes, & F. Zambonelli
(Eds.), Methodologies and software engineering for agent systems, Kluwer, 431-450.
Harmsen, A.F. (1997). Situational Method Engineering. Moret Ernst & Young.
Hbner, J., Sichman, J. and Boissier, O. (2002). A model for the structural, functional, and
deontic specification of organizations in multiagent systems. IBittencourt, G. & Ramalho, G.
L. (Eds.), 16th Brazilian Symposium on AI, SBIA02, LNAI 2507, Berlin: Springer, 118128.
Karlsson, F. (2005). Method Configuration - Method and Computerized Tool support. Doctoral
Dissertation Dept. of Computer and Information Science, Linkoping University.
Lematre, C. and Excelente, C. B. (1998). Multi-agent organization approach. In: The Second
Iberoamerican Workshop on Distributed AI and MAS, Toledo, Espana.
Odell, J., Parunak, H. V. D. and Bauer, B. (2000). Extending UML for Agents. In: Proceedings
of Agent-Oriented Information Systems Workshop, 3-17.
OMG. Object Management Group. Agent Metamodel and Profile (AMP) - Request For
Proposal. (2008a) OMG Document: ad/08-09-26.
OMG. Object Management Group. Software & Systems Process Engineering Meta-Model
Specification, version 2.0. (2008b). OMG document number: formal/2008-04-01.
Pavon, J.; Gomez-Sanz, J. and Fuentes, R. (2005) The Ingenias Methodology and Tools. In:
Henderson-Sellers, B., Giorgini, P. (Eds.), Agent-Oriented Methodologies, Idea Group
Publishing, 236-276.
Rougemaille S.; Migeon, F.; Millan, T.; Gleizes, M.P (2009) Methodology Fragments
Definition in SPEM for Designing Adaptive Methodology: A First Step. In LUCK, M.;
GOMEZ-SANZ, J.J. (Eds.): AOSE 2008, Lecture Notes in Computer Science (LNCS), vol.
5386, Springer-Verlag Berlin Heidelberg, 7485.
Stamper, R. Signs, Norms, and Information System. (1996) Holmqvist, B.; Andersen, P. B.;
Klein, H.; Posner, R. (Eds) Signs at Work: Semiosis & Information Processing in
Organizations, Walter de Gruyter, Berlin, 349-397.
Zambonelli, F., Jenningns, N. R. and Wooldridge, M. (2003) Developing multiagent systems:
The Gaia methodology. ACM Transaction on Software Engineering and Methodology, 12(3),
417-470.
30
Supporting the Development of Personal Assistance Software
Ingrid Nunes, Simone D.J. Barbosa, Carlos J.P. de Lucena
1
Pontical Catholic University of Rio de Janeiro (PUC-Rio) Rio de Janeiro, RJ Brazil
{ionunes,simone,lucena}@inf.puc-rio.br
Abstract. In this paper we present a framework for developing personal assis-
tance software, which follows a reference architecture previously proposed for
this application domain. The framework includes the implementation of a user
metamodel, which allows modeling of users preferences and congurations us-
ing high-level abstractions, typically used in users vocabulary, thus abstracting
from the underlying implementation model. Moreover, the framework provides a
mechanism to adapt applications at runtime based on changes on a user model,
in order to keep the consistency between user and implementation models.
1. Introduction
Recently, Rogoff claimed that the Articial Intelligence (AI) area is going to be the
next big driver of global growth [Rogoff 2010]. He claims that computers are going
to automatically perform a growing range of tasks in the next 50 years. Multi-agent
Systems (MASs), with roots not only in AI but also in distributed systems and software
engineering, have addressed this application domain, including auction staging, mission
scheduling and e-commerce. In such applications, it is not uncommon the existence of
personal agents representing users in the MAS and acting pro-actively on their behalf.
Given that agents represent individuals in these scenarios, there remains a need to person-
alize the software system to meet specic needs of the users [Nunes et al. 2009].
Extensive research work has been carried out in the context of user agents as per-
sonal assistance software. It includes eliciting preferences, learning them by monitoring
users and reasoning about preferences. Even though these works have signicantly ad-
vanced the area of user agents, little research effort has been done regarding the engineer-
ing of these systems. Good (modular, stable, ...) architectures are essential to produce
software with higher quality and easier to maintain. Otherwise, software architectures
may degenerate over time, making their maintenance a hard task, by increasing costs with
refactorings. Since the late 1980s, software architecture has emerged as the principled un-
derstanding of the large-scale structures of software systems [Shaw and Clements 2006].
In our previous work [Nunes et al. 2010], we have proposed a software architec-
ture to build personal assistance software based on agents. It emerged from the analysis of
current software engineering practices adopted to implement this domain of applications
as well as with the goal of empowering users to control their agents. In this paper, we take
one more step for providing a substantial infrastructure to support the development of per-
sonal assistance software. We have developed the rst version of a framework based on
our architecture. The framework provides: (i) the implementation of the user metamodel
detailed in [Nunes et al. 2010], which is ready to be instantiated and persisted; (ii) a mech-
anism to adapt applications at runtime based on changes on the user model. In addition,
due to limitations of existing agent platforms, we provide a belief-desire-intention (BDI)
extension of the JADE platform that is used combined with our adaptation mechanism.
31
The remainder of this paper is organized as follows. Section 2 describes the refer-
ence architecture that guided the development of our framework. Section 3 presents and
details the framework we have been developing, highlighting its adaptation mechanism.
Relevant discussions about our framework are presented in Section 4. Related work is
presented in Section 5, followed by Section 6, which concludes this paper.
2. The Reference Architecture
In our previous work [Nunes et al. 2010], we have proposed a software architecture to
build user-model-based systems, depicted in Figure 1. This architecture emerged from
an analysis of software engineering issues of this kind of system. The architecture relies
on the concept of virtual separation of concerns [K astner and Apel 2009]. The main idea
is to structure the architecture of user-customizable personal assistance systems in terms
of service-oriented agents and physically modularize each variability as much as possi-
ble into agent abstractions. In addition, we provide a high-level user model. This model
is virtual because it is not physically implemented into code, but provides a modularized
view of user customizations. User preferences and congurations are not design or imple-
mentation abstractions, but they are implemented by typical agent abstractions (beliefs,
goals, plans, etc.), i.e., they play their specic roles in the agent architecture. The virtual
user model is a complementary view that provides a global view of user customizations.
This model uses a high-level end-user language, through which users are able to congure
their agents. Next, we briey describe each one of it modules.
Domain Model. It is composed of entities shared by user agents and services,
application-specic, etc.
User Model. This module contains user congurations and preferences expressed in a
high-level language.
User Agents. It consists of agents that provide different services for users, e.g. schedul-
ing and trip planning. Their architecture supports variability related to different
users, and provides mechanisms for reasoning about preferences. These agents
use services provided by a distributed environment (the Services cloud), and their
knowledge is based on the Domain Model.
Synchronizer. The connection between the User Model and User Agents is stored in the
form of trace links, indicating how and where a customization is implemented in
Figure 1. Software architecture to build user-model-based systems.
32
one or more user agent. Adaptations are performed at runtime and are accom-
plished based on the trace links between the User Model and the User Agents
architecture. The Synchronizer is the module in charge of adapting User Agents
based on changes in the User Model.
Applications Interface. Users access user agents services through this module.
Conguration. By means of the Conguration module, users can directly manipulate
the User Model, which gives them the power to control and dynamically modify
user agents, using a high-level language.
Learning. Changes in the User Model may be performed or suggested by the Learning
module, which monitors user actions to infer possible changes in the User Model.
Security. It aggregates policies that restrict this communication, assuring that conden-
tial information is kept safety secured.
3. A Framework for Developing Personal Assistance Software
In this section, we present the framework we have been building in order to support the
development of personal assistance software. The framework follows the architecture
presented in the previous section, however some of its modules (learning and security)
have not been addressed yet, as Figure 1 shows. Our framework covers the User Model,
Synchronizer and Conguration modules.
In this paper, we focus on detailing the implemented user model (Section 3.1) and
on the adaptation mechanism (Section 3.2) that keeps the system implementation consis-
tent with the current state of the user model. In addition, we present an implementation of
the BDI architecture [Rao and Georgeff 1995] that we have built on top of JADE
1
frame-
work that is used by our adaptation mechanism (Section 3.3).
3.1. User Model
The User Model plays a key role in our framework. It models how an assistance soft-
ware is personalized to a user. It is important to highlight that this model uses high-level
abstractions, typically found in users vocabulary, thus abstracting from the underlying
implementation model and empowering the user to customize the application.
Our approach distinguishes user congurations from preferences, which we col-
lectively refer to as customizations. Congurations are direct and determinant interven-
tions that users perform in a system, such as adding/removing services or enabling op-
tional features. They can be related to environment restrictions, e.g., a device congura-
tion, or functionalities provided by the system. Preferences represent information about
the users values that inuence their decision making, and thus can be used as resources in
agent reasoning processes. They typically indicate how a user rates certain options better
than others in certain contexts. System changes of this nature can be exemplied by the
addition/removal of plans from a user agent plan library, which must be in accordance
with how a user would act for accomplishing a certain goal.
Our framework provides an implementation of the User metamodel, which we
have proposed in [Nunes et al. 2010]. This metamodel is ready to be instantiated. This
instantiation is accomplished in a stepwise fashion, rst by specic-application develop-
ers (development time) and then by users (runtime), as detailed in the remainder of this
1
http://jade.tilab.com/
33
Preference Description Example
DontCare Allows indicating a set of elements the user does not care about. <target1> ... <targetN> are in-
different for me.
MaxMin Indicates that the user preference is to minimize or maximize a
certain element.
I prefer to maximize/minimize
<target>.
Order Expresses an order relation between two elements. A set of in-
stances of the Order preference comprises a partial order
I prefer <target1>to <target2>.
Rating Allows users rating an element. By dening a RatingDomain
for an element, users can rate this element with a value that be-
longs to the specied domain. This domain can be numeric (either
continuous or discrete), with specied upper and lower bounds. In
addition, an enumeration can be specied.
I rate <target> with the value
<rate>.
ReferenceValue Enables users to indicate one or more preferred values for an ele-
ment. It can be interpreted as the user preference is a value on the
order of the provided value.
I prefer <target>as close as pos-
sible to <reference value>.
Table 1. Preference statements represented in our approach.
section. Our framework also provides persistence to these models as well as a software
component to be added to Java Swing
2
applications to manage user models at runtime.
The User metamodel is composed of four parts: (a) Variability model; (b) Prefer-
ences Denition Model; (c) Variability Model Conguration; and (d) Preferences Model.
(a) and (b) are instantiated by developers and dene rules for the User Model. (c) and (d)
comprise the User Model represent users congurations and preferences, respectively,
and must be in accordance with (a) and (b). The User Model can be managed by users
or by the learning module. The Variability model allows modeling variable traits within
the domain, which are used for dening user congurations. It denes the possible con-
gurations of the system. It consists of variable features, which are the system-specic
characteristics that can be chosen by users. These features can be optional or alternative.
Alternative features are organized into feature groups, which dene the number of alter-
native features that can be chosen in a group. In addition, constraints can be dened to
establish valid combinations of these features.
The purpose of the Preferences Denition model is to dene how (preferences
statements) users can express their preferences and about which elements (preference tar-
gets) of the Ontology Model, which is part of the Domain model and denes the concepts
and their slots used in the system. Even though it is desirable that users be able to express
preferences in different ways, it is necessary to have agents that can deal with them. For
instance, if application agents can deal only with quantitative preference statements, user
preferences expressed in a qualitative way will have no effect on the system behavior.
Our framework provides ve types of preference statements (Table 1). The cur-
rent version of the framework does not support the specication of conditions over the
preferences, as it is dened in the metamodel proposed in [Nunes et al. 2010]. As shown
in Table 1, preferences statements contains targets, which are the objects referred in the
statement. Table 2 describes the four kinds of preferences target supported.
The User Model is instantiated based on our metamodel and these two described
models. The Variability Model Conguration consists of a set of chosen optional and
alternative features, and the Preferences Model is a set of preference statements. The
current version of our framework veries if the Variability Model Conguration is con-
2
http://java.sun.com/docs/books/tutorial/uiswing/
34
Preference Description Example
Class It refers to classes (or concepts) of the Ontology model. I prefer notebook to desktop.
Property It refers to properties (or slots) of classes. It can refer only to
the property (color of a notebook) or the value of the property
(notebook color is pink). In addition, the property can be
referred in a nested context, e.g. Notebook.screen.size.
I dont like notebooks whose
color is pink.
EnumerationValue It refers to values of an enumeration. I prefer red to blue. (Enumer-
ation is Color)
Value It refers to values of a value domain. Value is a rst-class
abstraction of our model. It describes preferences not over
characteristics of the object but the value it brings.
Cost is more relevant than
quality.
Table 2. Preference targets that can be referenced by preference statements.
sistent with the Variability Model, and if the Preferences Model is consistent with the
Preferences Denition Model. However, we do not provide a mechanism to detect incon-
sistencies among preferences, e.g., I prefer A to B, I like B, and I dislike A.
3.2. Adaptation Mechanism
In our proposed architecture, and consequently in our framework, there are two repre-
sentations of a system and its current state, which are in different levels of abstractions:
(i) User model which represents users congurations and preferences in a high-level
language and can be managed by the end-user; and (ii) User Agents an implementation
level representation of the system. It consists of software components that implement all
user customizations, but are congured according to a specic state of the user model.
Therefore, a set of customizations represented in the User Model in a high-level of ab-
straction is implemented, and represented, with lower level abstractions, such as compo-
nents, agents, beliefs and plans.
At this point it is important to dene some terms used to detail our adaptation
mechanism. A software component is any software asset that is part of the implemented
system. There are two types of coarse-grained software components: components and
agents. The former presents a reactive behavior, as opposed to the latter, which presents
autonomy and pro-activity as well as is able to communicate through messages with other
agents. Agents are composed of ner-grained software components, namely capabilities,
beliefs, goals and plans.
The implementation level representation, i.e., User agents, is mandatory in the
system it is how the system is implemented and shows the expected behavior. On
the other hand, the User model is a complementary representation that provides a global
view of user customizations and abstracts implementation details, which are not neces-
sary to dene specic user customizations. This model brings the following advantages:
(i) it provides a common language for users to specify their customizations; (ii) it helps
on mixed initiatives in which users can verify and adjust customizations inferred by the
system; and (iii) it provides a modular reasoning about user customizations, which is per-
formed using high-level abstractions and is independent of implementation technologies.
However, given that we have two representations of the same system, there is a
need for keeping them consistent. The User Model drives the system behavior and deter-
mines how the current state of the system should be, and User agents must be congured
to be in accordance with it, and be adapted when the User Model changes. Our framework
provides an adaptation mechanism, which is responsible for keeping this consistency.
35
The algorithm that is performed to accomplish this task is presented in Algo-
rithm 1. It receives as input the previous and the updated versions of the User Model
as well as a map of adaptation rules. The main idea of the algorithm is to generate and
perform a set of adaptation actions that must be performed in the system according to
changes in the two versions of the user model.
Algorithm 1: Adaptation algorithm
Input: UM: previous user model; UM
: updated user model; rulesMap: adaptation rules

mapped to the events they observe
events = diff(UM, UM
);
adaptationRules = ;
foreach Event e events do
rules = e.get(rulesMap);
if rules = null then
adaptationRules = adaptationRules rules;
actions = ;
foreach Rule r adaptationRules do
actions = actions r.getAdaptationActions(UM, UM
, events);
foreach Action a actions do
a.doAction();
The core of our adaptation algorithm is the adaptation rules. An adaptation rule is
an interface that denes the following methods:
Set<Event> getObservableEvents(); Provides the set of events that this rule
is listening to. This method is used to build the map of adaptation rules (a map
from events to the rules that listen to them); and
List<AdaptationAction> getAdaptationActions(UserModel
oldUserModel, UserModel newUserModel, Set<Event> events) throws
AdaptationException; Generates the list of actions that must be performed
according to the changes in the User Model.
An adaptation action, in turn, is an interface that denes the method void
doAction() throws AdaptationException. In Figure 2, we illustrate an ex-
ample of a simple rule, the Optional Feature adaptation rule, which adds and removes
components, agents, etc., based on the addition or removal of a feature. The rule is asso-
ciated with a feature F and a set of ComponentAdaptationAction. It listens to two
kinds of event: AddFeature(F) and RemoveFeature(F). The framework provides a set of
types of rules and actions, which can be extended for specic applications. However,
instances of rules and actions are application-specic. The predened set of rules and
actions is still under development. Figure 2 presents two actions: one that adds/removes
components and another that adds/removes agents.
It is important to notice that actions are represented with Strings. We have made
extensive use of the Spring framework
3
. It provides a mechanism for dening software
components (Beans) and establishing dependencies among them in a XML le. The
actions are referenced in the Optional Feature adaptation rule by its name in the Spring
denition le. In addition, all application-specic rules and actions are dened in this
3
http://www.springsource.org/
36
Figure 2. Optional Feature adaptation rule.
le. They are instances of the rules (e.g. Optional Feature and Preference Statement) and
actions (e.g. add/remove component, agent, belief and plan) that our framework provides.
3.3. A BDI layer for JADE
As presented previously, we have adopted an agent-based solution to design and imple-
ment the application domain we are addressing, i.e. personal assistance software. We
have made this choice due to several reasons: (i) agent-based architectures are composed
of human-inspired components, such as goals, beliefs and motivations, thus reducing the
gap between the user model (problem space) and the solution space; (ii) plenty of agent-
based AI techniques have been proposed to reason about user preferences, and they can
be leveraged to build personalized user agents; and (iii) agent architectures are very ex-
ible, thus facilitating the implementation of user customizations. For instance, there is an
explicit separation of what to do (goals) from how to do it (plans).
We have adopted the BDI architecture [Rao and Georgeff 1995] to design and im-
plement agents. This architecture is a widely used agent architecture and is highly inspired
by human reasoning model, thus being in accordance with our argument (i). Several agent
platforms that implement the BDI architecture have been proposed, for instance Jason,
Jadex and Jack. In particular, these three platforms are based on the Java language. How-
ever, agents are implemented in these platforms in a Domain-specic Language (DSL)
in specic le types (e.g. XML), which are processed and run in the Java platform. As
a consequence, this prevents us from using some features of the Java language, such as
reection and annotations, that help on the implementation of our adaptation mechanism.
Due to this limitation of these BDI agent platforms, we have implemented a BDI
layer on top of JADE. JADE is a Java-based agent platform that provides a robust infras-
tructure to implement agents, including behavior scheduling, communication and yellow
pages service. We have leveraged these features provided by JADE, and built a BDI
reasoning mechanism to JADE agents. Agents developed with our JADE extension are
implemented in pure Java language, i.e. not in XML les. These are some of the main
characteristics of our JADE extension:
Use of capabilities. Agents aggregate a set of capabilities, which are a collection
of beliefs and plans. This allows modularizing particular agents behaviors.
Java generics for beliefs. Beliefs can store any kind of information and are associ-
ated with a name. If the value of a belief is retrieved, it must be cast to its specic
37
type. We have used Java generics to capture incorrect castings in compile time.
Plan bodies are instance of JADE behaviors. In order to better exploit JADE
features, in particular its behaviors hierarchy, plan bodies in our extension are
subclasses of JADE behaviors. To make this possible, they have to implement the
PlanBody interface of our extension as well.
Due to space restrictions, we do not present the class diagram that represents our
JADE extension. We refer the reader to [Nunes 2010] for further details of it, including
its download.
4. Discussions
In this section, we present relevant discussion related to the reference architecture we are
implementing and the framework we have been developing.
Relationship with Software Product Lines. Software Product Lines (SPLs)
[Pohl et al. 2005] are becoming an essential software reuse technique that has been ap-
plied in the construction of mass-produced software systems. A SPL is a family of related
software products built from a common set of software components, where each compo-
nent typically implements a distinguishable feature. SPLs exploit common and variable
features of a set of systems and lead to the development of exible architectures that sup-
port the derivation of customized systems. Customized user agents can be seen as a SPL
of user agents that are tailored to specic users. As a consequence, SPL techniques are
used to support the development of this family of agents. However, the main difference
between personalized user agents and SPLs is that the latter contemplates only user con-
gurations, but not user preferences, which are essential to make a system that is able to
act on the users behalf. In addition, our adaptation rules and actions do not require a full
mapping between variation points of the Variability Model to the elements that implement
them. There is only the need for establishing the actions that must be performed in order
to (dis)connect software components. No action needs to be taken regarding software
components that are associated with the one being (dis)connected and are not bound to
the rest of the running system.
In our framework, all software components are loaded in the application startup,
and their connections evolve over time. However, it is interesting to investigate ap-
proaches of dynamically (un)loading software components for mobile applications, in
which issues such as memory usage are extremely important to be taken into account.
Instantiating our Framework. The main features of the current version of our
framework are: (i) it has the infrastructure needed to instantiate and persist the User meta-
model we proposed in [Nunes et al. 2010]; and (ii) it provides an adaptation mechanism
to evolve the system to be consistent with the User Model. These are the main tasks
that are necessary to instantiate the framework: (a) choose the database to persist mod-
els; (b) dene and implement the Domain Model; (c) dene Variability and Preferences
Denition Models. These models are directly persisted in the database; (d) implement
User Agents using variability implementation techniques; (e) dene adaptation rules and
actions. These are dened in a Spring conguration le.
Our framework was built using an approach in which the domain (personal as-
sistance software) was extensively analyzed, and then the framework with its frozen and
38
hot-spots was designed and implemented. We have instantiated our framework for an
application that provides traveling services.
5. Related Work
Most of the works related to agent-based personal assistance software address eliciting
and reasoning about user preferences. They focus on the domain of recommender systems
and which are the user preferences, so that the system is able to provide a recommendation
of one or a subset of a set of choices. So they do not address the impact of preferences on
the system behavior and how they are realized, which is the goal of our work. Next we
introduce and discuss work related to this issue.
A multi-agent infrastructure, named Seta2000, for developing personalized web-
based systems is presented in [Ardissono, L. et al. 2005]. It supports the development of
recommender systems by the provision of two main behaviors: personalized suggestion
of items, and the dynamic generation of user interfaces. The main contribution from
a personalization perspective of Seta2000 is the reusable recommendation engine that
can be customized to different application domains. Even though this work provided a
reusable infrastructure to build web-based recommender systems, it did not provide new
solutions in the context of personalized systems: it leverages existing recommendation
techniques and provides an extensible implemented agent-based solution. This can be
seen in the related work reported in [Ardissono, L. et al. 2005], in which Seta2000 is
compared to general purpose agent platforms, such as JADE.
Huang et al. [Huang et al. 2008] describes a personalized recommendation sys-
tem based on multi-agents. The system provides an implicit user preferences learning
approach, and distributes responsibilities of the recommendation process among different
agents, such as learning, selection & recommendation and information collection agent.
These agents are an underlying infrastructure of an intelligent user agent. As the previous
discussed work, this system adopts existing techniques to build recommendation systems.
One of the biggest projects in the context of personalized user agents is the
Cognitive Assistant that Learns and Organizes (CALO) project
4
[Berry et al. 2006,
Berry et al. 2009], whose goal is to support a busy knowledge worker in dealing with
the twin problems of information and task overload. Along the project, the research effort
was mostly concentrated in the PTIME agent, which is an autonomous entity that works
with its user, other PTIME agents, and other users, to schedule meetings and commit-
ments in its users calendar. One main issue of this work is that the solution is highly
coupled with the domain being explored (meetings scheduling). In addition, as there is
only one concern being addressed by PTIME (scheduling), there are not multiple con-
cerns related to user customizations, which is a problem we are looking at. Furthermore,
this research work did not address user congurations, i.e. the system that all users are
managing are not tailored for their needs in the sense of features that the system provides.
Despite this limitations, the CALO project substantially advanced on the development of
user agents, also taking into account human-computer interaction (HCI) issues that are
essential to improve the chances of users adopting personal agents. Therefore, lessons
learned from this project [Berry et al. 2009] can be leveraged in our work.
4
http://caloproject.sri.com/
39
6. Conclusion
We presented a framework for developing personal assistance software, which follows a
reference architecture previously proposed for this application domain. Our framework
provides the implementation of a user metamodel, which captures user congurations and
preferences in a high-level way. The implementation also provides means for persisting
instantiated models. In addition, the framework aggregates interface components that al-
lows manipulating user models in a graphical manner. Moreover, our framework includes
a mechanism for adapting applications at implementation level based on changes on the
user model. This mechanism uses as input adaptation rules and actions, which are exe-
cuted when the changes on the user model comprises the context of the rule application.
Providing an infrastructure that uses a high-level user model to drive adapta-
tions on personal assistance software has several advantages: (i) user customizations are
implementation-independent; (ii) the vocabulary used in the user model becomes a com-
mon language for users specifying congurations and preference; (iii) the user model
modularizes customizations, allowing a modular reasoning about them. Future work in-
cludes addressing modules (learning and security) currently not covered by our frame-
work.
References
Ardissono, L. et al. (2005). A multi-agent infrastructure for developing personalized web-
based systems. ACM Trans. Internet Technol., 5(1):4769.
Berry, P., Peintner, B., Conley, K., Gervasio, M., Uribe, T., and Yorke-Smith, N. (2006).
Deploying a personalized time management agent. In AAMAS 06, pages 15641571.
Berry, P. M., Donneau-Golencer, T., Duong, K., Gervasio, M., Peintner, B., and Yorke-
Smith, N. (2009). Evaluating user-adaptive systems: Lessons from experiences with a
personalized meeting scheduling assistant. In IAAI09, pages 4046.
Huang, L., Dai, L., Wei, Y., and Huang, M. (2008). A personalized recommendation
system based on multi-agent. In WGEC 08.
K astner, C. and Apel, S. (2009). Virtual separation of concerns - a second chance for
preprocessors. Journal of Object Technology, 8(6):5978.
Nunes, I. (2010). A bdi extension for jade. http://www.inf.puc-rio.br/ionunes/bdi4jade/.
Nunes, I., Barbosa, S., and Lucena, C. (2010). An end-user domain-specic model to
drive dynamic user agents adaptations. In SEKE 2010, USA.
Nunes, I., Lucena, C. J., Cowan, D., and Alencar, P. (2009). Building service-oriented
user agents using a software product line approach. In ICSR 09, pages 236245.
Pohl, K., B ockle, G., and van der Linden, F. J. (2005). Software Product Line Engineer-
ing: Foundations, Principles and Techniques. Springer-Verlag.
Rao, A. and Georgeff, M. (1995). BDI-agents: from theory to practice. In ICMAS95.
Rogoff, K. (2010). Grandmasters and global growth. Project Syndicate. Available at
http://www.project-syndicate.org/commentary/rogoff64/English.
Shaw, M. and Clements, P. (2006). The golden age of software architecture. IEEE Softw.,
23(2):3139.
40

Usando Objetos de Conhecimento para Compartilhar
Conhecimento na plataforma Jason
i

Ana Paula Lemke
1
, Pier Cludio Michelon Nicotti
1
, Marcelo Blois Ribeiro
1
e Rafael
H. Bordini
2

1
Faculdade de Informtica Pontifcia Universidade Catlica do Rio Grande do Sul
Av. Ipiranga, 6681 90619-900 Porto Alegre, RS Brasil
2
Instituto de Informtica - Universidade Federal do Rio Grande do Sul
Caixa Postal 15064 - 91501-970 - Porto Alegre, RS - Brasil
ana.lemke@pucrs.br, pier.nicotti@acad.pucrs.br,
marcelo.blois@pucrs.br, r.bordini@inf.ufrgs.br
Abstract. Agent-based applications provide many promising capabilities
(including proactivity and learning) but development techniques for agent-
based applications is still incipient compared to other programming
paradigms. Agent-based technologies are not likely to become widespread
until there are adequate infrastructures for the development of multi-agent
systems. For instance, agent platforms usually cannot support representing
the agents procedural knowledge in a structure suitable for it to be reused
and shared with other agents. This paper introduces the use of knowledge
objects into Jason agents. Knowledge objects encapsulate all the required
elements to solve a given problem and they can be used and shared among
agents.
Resumo. Mesmo com todas as caractersticas atraentes prometidas pelas
aplicaes baseadas em agentes (como pr-atividade e aprendizado), seu
desenvolvimento ainda inexpressivo se comparado com outros paradigmas
de programao. Uma das razes para isto a falta de infra-estrutura adequada
para auxiliar no desenvolvimento das aplicaes. Por exemplo, a maioria das
plataformas no d suporte representao e compartilhamento de pacotes de
conhecimento entre agentes, o que permitiria a eles formalizar, transmitir e
reusar o conhecimento disponvel. Neste sentido, este artigo introduz o uso de
objetos de conhecimento em agentes Jason. Objetos de conhecimento
encapsulam o conhecimento necessrio para o alcance de um objetivo e tem
potencial para serem usados e compartilhados por agentes em diversas
plataformas.
1. Introduo
O desenvolvimento de agentes de software inteligentes se confunde com a prpria busca
de tecnologias inteligentes pelos pesquisadores de Inteligncia Artificial. A idia de se
criar um software inteligente, capaz de pensar de forma similar a um ser humano,
sempre atraiu inmeros pesquisadores (Ferber 1999).

i
Estudo desenvolvido pelo Intelligent Systems Engineering Group da PUCRS, financiado pela Dell
Computadores do Brasil Ltda. com recursos da Lei 8.248/91 e pelo Conselho Nacional de
Desenvolvimento Cientfico e Tecnolgico CNPq.
41

Aplicaes baseadas em agentes geralmente so desenvolvidas com o apoio de
plataformas ou frameworks. Existem diversas plataformas para auxiliar na criao de
sistemas multiagentes (SMAs), como Jason (Bordini et al. 2007). A plataforma Jason,
desenvolvida por Jomi Hbner e Rafael Bordini, implementa a semntica operacional
de uma verso estendida da linguagem AgentSpeak(L) (Rao 1996), fornecendo uma
infra-estrutura para o desenvolvimento de SMAs com uma srie de caractersticas
customizveis pelo usurio (Jason 2009).
Na linguagem AgentSpeak, originalmente concebida para programao de um
nico agente, o agente reage a um conjunto pr-determinado de eventos, sendo que a
maneira como os eventos so tratados tambm conhecida a priori. Assim, quando no
h planos relevantes ou aplicveis para tratar um evento, seu tratamento postergado (o
evento introduzido no final da fila de eventos) ou o evento simplesmente descartado.
Na plataforma Jason, o mecanismo de comunicao adicionado linguagem AgentSpeak
prev a troca de crenas, regras de inferncia, e planos (i.e., regras para raciocnio
prtico) usando comunicao baseada em atos de fala. Embora o mecanismo de
comunicao possibilite que os agentes compartilharem esses elementos, no h
mecanismos para o compartilhamento de pacotes de conhecimento entre os agentes. Ou
seja, se um agente Jason necessita de mltiplas estruturas (sejam elas planos, crenas ou
regras) para realizar uma tarefa, preciso identificar quais so as estruturas necessrias
e gerenciar o envio de mltiplas mensagens de requisio de conhecimento.
Para auxiliar no desenvolvimento de agentes capazes de compartilhar
conhecimento de forma modular com outros agentes, as plataformas para
desenvolvimento de SMAs deveriam satisfazer alguns requisitos, como: (1) fornecer
algum tipo de representao para o conhecimento de domnio dos agentes, visto que
para os agentes interpretarem e inferirem novos conhecimentos com base no
conhecimento existente, esse deve estar codificado em uma linguagem formal; (2)
definir um modelo para o encapsulamento do conhecimento em pacotes de
conhecimento coesos; e, por fim, (3) oferecer meios para que os agentes possam
compartilhar esses pacotes de conhecimento entre si. O fato que a busca e o
compartilhamento de pacotes de conhecimento no so procedimentos apresentados
pela maioria das plataformas, como a Jason.
Neste sentido, este artigo introduz o uso de objetos de conhecimento em agentes
Jason. Objetos de conhecimento encapsulam o conhecimento necessrio para o alcance
de um objetivo e podem ser usados e compartilhados pelos agentes. Para evoluir a
plataforma Jason, criando uma nova plataforma com suporte a gesto do conhecimento
dos agentes, foi utilizado o framework Ontowledge (Lemke et al. 2007). O Ontowledge
um framework desenvolvido em Java para dar suporte a agentes que no possuem o
conhecimento necessrio para atingir algum objetivo novo que lhes foi dado. A
instanciao do Ontowledge plataforma Jason foi possvel graas s caractersticas
customizveis apresentadas por ela.
Como poder ser visto no decorrer do artigo, com o Ontowledge instanciado os
desenvolvedores podem indicar uma srie de objetivos (ou eventos de interesse) para o
agente sem indicar como eles sero atingidos. Quando um objetivo precisa ser
alcanado, um objeto de conhecimento pode ser recuperado e utilizado pelo agente. Os
objetos de conhecimento recuperados por um agente podem ser armazenados em sua
base de conhecimento local para uso em situaes futuras (o que poderia ser
considerado uma forma de aprendizado) ou podem ser descartados depois do uso (o que
42

particularmente til quando os agentes esto executando em dispositivos com recursos
limitados, como PDAs e telefones celulares).
A habilidade de se adaptar para alcanar um objetivo essencial em domnios
reais por vrias razes. Em primeiro lugar, o conhecimento do agente pode ser
insuficiente para alcanar um objetivo. Tambm, os recursos necessrios para executar
um plano podem estar temporariamente indisponveis. E, por mais que se tente prever as
situaes possveis, o ambiente imprevisvel e incerto, o que acaba tornando
impossvel a tarefa de predizer o futuro.
O restante deste artigo est organizado da seguinte forma: na Seo 2 so
apresentadas as principais caractersticas da plataforma Jason; na Seo 3 descrita a
nova arquitetura dos agentes Jason (resultante da instanciao do framework
Ontowledge); na Seo 4 discorre-se sobre trabalhos relacionados e, por fim, na Seo 5
so apresentadas as consideraes finais.
2. A plataforma Jason
Quando se fala da plataforma Jason, preciso discorrer sobre dois assuntos: a linguagem
para programao de agentes suportada (extenso da linguagem AgentSpeak) e o
interpretador Jason, que quem executa os agentes descritos com a linguagem.
De maneira geral, a especificao de um agente Jason compreende a
especificao de um conjunto de crenas que formaro a sua base de crenas inicial,
uma lista de objetivos e um conjunto de planos. As crenas formam o componente
informativo do agente. Os objetivos indicam os estados que o agente quer alcanar (os
chamados achievement goals) ou retornam o resultado da unificao do predicado de
teste com uma das crenas do agente (os chamados test goals). Na prtica, so os
objetivos de realizao ou alteraes nas crenas que iniciam a execuo dos planos. Os
planos possuem um evento ativador, um contexto (conjunto de crenas que devem ser
verdadeiras para o plano ser considerado aplicvel) e uma seqncia de aes bsicas ou
sub-objetivos que o agente deve atingir ou testar quando o plano executado. Aes
internas podem ser usadas no contexto e no corpo de um plano. Aes internas so
aes definidas pelo usurio que executam internamente no agente. Elas so
programadas tipicamente na linguagem Java e tm o nome precedido pelo nome da
biblioteca de aes seguido do sinal . na descrio dos planos do agente. Algumas
aes de uso geral so disponibilizadas junto com a plataforma e, portanto, o nome da
biblioteca do usurio omitido, como, por exemplo, as aes internas .send e .print.
Depois de explicados os elementos bsicos de uma agente Jason, necessrio
entender como o interpretador os executa. Conforme descrito em (Bordini et al. 2007),
o ciclo de raciocnio dos agentes pode ser dividido em 10 grandes passos. Os primeiros
quatro passos so relacionados atualizao da base de crenas do agente com
informaes percebidas a partir do ambiente ou comunicadas por outros agentes. Os
demais passos so relacionados com a interpretao do programa propriamente dito, o
que normalmente inicia com a seleo de um evento para o tratamento no restante do
ciclo de raciocnio.
Para cada evento selecionado, primeiro so identificados os planos relevantes
(planos cujo evento ativador unifica com o evento que est sendo tratado). De acordo
com os autores, se no forem encontrados planos cujo evento de disparo unifique com
um evento externo (evento gerado pela atualizao de crenas em resposta a percepes
43

do ambiente), o evento descartado. Se o mesmo acontecer para um evento interno
(evento gerado pelo prprio agente para executar objetivos secundrios), ento
possvel configurar o interpretador para que o evento seja recolocado na lista de
eventos. Como os planos tm um contexto associado, alm de verificar o evento
ativador, necessrio verificar se o conjunto de crenas associado ao plano verdadeiro
com base nas informaes que o agente possui. Caso positivo, o plano dito aplicvel.
Quando eventos internos ou externos no podem ser tratados devido falta de planos
aplicveis, o evento pode ser descartado ou recolocado na fila de eventos (conforme
configurao utilizada no interpretador).
Depois de identificados os planos aplicveis para o tratamento de um evento,
necessrio selecionar um para execuo (o que indica que o agente tem a inteno de
executar o plano). Para selecionar um plano aplicvel, existe a funo de seleo de
opo que, na implementao padro, seleciona o primeiro plano aplicvel declarado no
cdigo-fonte do agente. Os ltimos dois passos do ciclo de raciocnio do agente so
relacionados com a seleo de uma inteno para a execuo e a execuo propriamente
dita de um passo dessa inteno. Tipicamente, o agente pode ter vrias intenes
pendentes para executar, visto que a cada ciclo de raciocnio no mximo uma frmula
de uma das intenes executada.
3. Compartilhando Objetos de Conhecimento na Plataforma Jason
Para oferecer aos agentes Jason a possibilidade de compartilhar automaticamente
pacotes de conhecimento entre si quando identificada uma necessidade de
conhecimento, as sees a seguir descrevem o processo de instanciao do Ontowledge
plataforma Jason e discutem o impacto dessa integrao na criao e execuo dos
agentes. No Ontowledge, o conhecimento dos agentes representado utilizando
ontologias, definida a noo de objetos de conhecimento e so disponibilizados
mtodos para permitir que os agentes usem e compartilhem esses objetos (Lemke et al.
2007). Os trs requisitos que deveriam ser apresentados pelas plataformas de forma a
permitir a criao de agentes capazes de compartilhar seus conhecimentos (citados na
Seo 1) so satisfeitos quando a plataforma possui o Ontowledge instanciado.
Durante a concepo do Ontowledge, vrios pontos de flexibilidade foram
definidos para respeitar as particularidades de cada plataforma. Entretanto, algumas
evolues precisaram ser feitas para possibilitar a instanciao ao Jason. Por exemplo, a
operao responsvel pelo carregamento dos itens de um objeto de conhecimento
passou a ser um ponto de customizao do framework. Assim, os planos puderam ser
adicionados aos agentes Jason na ordem correta (na implementao padro do mtodo,
no havia qualquer ordem para o carregamento dos itens do objeto de conhecimento). A
necessidade de evolues na arquitetura do Ontowledge justificada pelas inmeras
diferenas apresentadas pelas plataformas disponveis. Em trabalhos anteriores (Lemke
e Blois 2009), o Ontowledge foi instanciado plataforma SemantiCore, cujo
funcionamento dos agentes bastante diferente do funcionamento dos agentes Jason. As
evolues realizadas no Ontowledge so tambm uma contribuio deste estudo.
Por fim, a principal estratgia de pesquisa utilizada neste estudo, de acordo com
a classificao de Oates (Oates 2006), a projeto e criao (do ingls design and
creation). Pesquisas guiadas por essa estratgia tm foco no desenvolvimento de novos
produtos de TI (Tecnologia da Informao) e geralmente so avaliadas com base em
testes de software e provas de conceito.
44

3.1. Caractersticas da arquitetura desenvolvida
Para entender as extenses feitas na plataforma Jason, primeiro necessrio entender o
que so e para que servem os objetos de conhecimento propostos pelo framework
Ontowledge. Sempre que um agente com o Ontowledge instanciado no possui o
conhecimento necessrio para atingir um objetivo, um objeto de conhecimento
recuperado e o seu contedo automaticamente adicionado arquitetura do agente. Um
objeto de conhecimento encapsula todos os elementos requeridos para resolver
determinado problema, definio similar a knowledge source (Ferber 1999).
No Ontowledge, um objeto de conhecimento representado por uma srie de
itens (classe KOItem), que so pontos de flexibilidade da arquitetura. Os itens
GoalITEM e RestrictionITEM so itens pr-definidos e de uso exclusivo do
framework. O item GoalITEM encapsula uma descrio sobre o conhecimento contido
no objeto. Essa descrio utilizada para a seleo do objeto de conhecimento mais
apropriado para determinada necessidade. O item RestrictionITEM encapsula as
restries de compartilhamento associadas ao objeto de conhecimento. Os demais itens,
que compreendem a soluo para o problema descrito, so vinculados aos diferentes
elementos que compem a arquitetura interna do agente ao qual o framework est
instanciado. So esses os itens adicionados arquitetura do agente no momento da
aplicao de um objeto de conhecimento.
Para representar os principais elementos da arquitetura de agentes Jason, foram
criadas duas novas especializaes da classe KOItem: a PlanITEM e a BeliefITEM. A
classe PlanITEM responsvel por gerenciar os planos contidos no objeto de
conhecimento. No entanto, objetos da classe PlanITEM no possuem referncias diretas
a objetos da classe Plan da arquitetura do Jason foi necessrio criar outra classe, a
JasonPlan para fazer esta ligao. A classe JasonPlan estende a classe Plan e
disponibiliza mtodos para o acesso aos atributos do plano e para o controle da posio
do plano na hora do carregamento de um objeto de conhecimento. Caso o plano
contenha aes internas, o cdigo da ao (bytecodes do .class) tambm estar contido
no objeto de conhecimento para que seja feita instanciao dinmica no agente que
aplicar o conhecimento. A classe BeliefITEM responsvel por gerenciar as crenas
de um objeto de conhecimento. O elemento de um objeto de BeliefITEM (o valor de
seu atributo element) referencia um objeto da classe Literal, definida na arquitetura
do Jason. A Figura 1, que apresenta um fragmento do diagrama de classes da
instanciao, mostra os itens de um objeto de conhecimento na plataforma Jason.
Objetos de conhecimento podem ser adicionados ao agente utilizando a ao
interna addKO, que uma especializao da classe DefaultInternalAction. Os
parmetros utilizados na invocao dessa ao so: name, que representa o nome do
objeto de conhecimento; plans, que corresponde a um label ou a uma lista de
labels dos planos relacionados ao objeto de conhecimento; e beliefs, que
corresponde a uma crena ou a uma lista de crenas relacionadas ao objeto de
conhecimento. O objetivo do objeto de conhecimento (seu GoalITEM) criado com
base nos eventos ativadores dos planos contidos no objeto. Embora existam extenses
que permitem que agentes Jason trabalhem com ontologias (veja (Klapiscak e Bordini,
2008)), at o momento utiliza-se apenas o evento ativador dos planos nos objetivos dos
objetos de conhecimento. A seguir ilustrada a criao de um objeto de conhecimento
45

chamado ko1, cujo plano associado possui como label a string "Enter Room" e que
tem a crena position(out):
* ia.addKO(ko1, "Enter Room", position(out))
Para recuperar objetos de conhecimento de outros agentes, o framework
Ontowledge fornece o mecanismo de aquisio de conhecimento que, de maneira
resumida, executa as seguintes atividades: (1) recupera a descrio do conhecimento
faltante (no caso do Jason, corresponde ao evento sem planos relevantes ou aplicveis);
(2) define a lista de destinatrios da mensagem de requisio de conhecimento; e (3)
envia a mensagem aos agentes da lista de destinatrios. Como a indicao de
conhecimento faltante deve ser sinalizada ao Ontowledge pelo prprio agente, foi
preciso estender a classe Agent da arquitetura do Jason. Na classe especializada foi
sobrescrito o mtodo selectEvent(), que passou a sinalizar ao Ontowledge as
necessidades de conhecimento do agente e tambm o recebimento de mensagens de
requisio ou distribuio de conhecimento vindas de outros agentes do sistema.
Figura 1. Fragmento do diagrama de classes da instanciao (com nfase na
estrutura dos objetos de conhecimento).
O recebimento de mensagens de requisio e de entrega de conhecimento
garantido por dois novos tipos de mensagens
ii
criados no mtodo inicializador do agente
(o mtodo initAg tambm foi sobrescrito). O processamento das novas mensagens
feito por duas aes internas: a requestKnowledge e a deliverKnowledge (ambas
so especializaes da classe DefaultInternalAction). A ao
requestKnowledge tem como objetivo encaminhar ao Ontowledge as mensagens de
requisio de conhecimento recebidas de outros agentes. Cada vez que recebida uma
solicitao de conhecimento feita uma verificao entre o conhecimento requerido e o
oferecido pelo agente. Depois de realizada a verificao, os objetos de conhecimento
mais compatveis so enviados ao agente solicitante.
A ao deliverKnowledge encaminha ao Ontowledge as mensagens de
entrega de conhecimento recebidas pelo agente (em resposta a uma solicitao). Essas
mensagens so colocadas em uma lista que, depois de transcorrido o tempo de espera,

ii
Optou-se por no utilizar as performativas askHow e tellKnow para no alterar a semntica associada a elas, visto
que aqui so compartilhados objetos de conhecimento e no apenas planos.
46

computada pelo mecanismo de carregamento de conhecimento. esse mecanismo o
responsvel por analisar o conhecimento recebido e selecionar um objeto de
conhecimento para aplicao. Aplicar um objeto de conhecimento significa adicionar os
itens do objeto de conhecimento arquitetura do agente.
A Figura 2 ilustra como os mecanismos do Ontowledge se relacionam entre si e
como eles so inicializados durante o ciclo de raciocnio de um agente Jason. Como se
pode observar, mensagens de distribuio e solicitao de conhecimento so
encaminhas ao Ontowledge para tratamento. Os demais eventos percebidos pelo agente
so tratados pelas funes de seleo disponveis em sua arquitetura. A customizao de
algumas dessas funes permite que o Ontowledge seja sinalizado sempre que no
houver planos relevantes ou aplicveis para o tratamento de determinado evento (salvo
situaes em que j tenha sido solicitado conhecimento sem sucesso). Quando o
Ontowledge recebe a sinalizao de conhecimento faltante, inicializado o processo de
aquisio e aplicao de conhecimento. Uma vez aplicado um objeto de conhecimento,
reiniciado o processo de unificao do evento que gerou a solicitao de
conhecimento com os planos disponveis no agente.
As aes que esto com preenchimento na Figura 2 ainda no foram
operacionalizadas nos agentes Jason. Elas correspondem outra funcionalidade provida
pelo Ontowledge: a substituio do conhecimento obsoleto ou ineficiente. Atravs da
verificao da satisfao alcanada com o uso de um objeto de conhecimento, agentes
com o Ontowledge instanciado so capazes de avaliar seus prprios desempenhos. Para
tanto, cada vez que um objeto de conhecimento utilizado para atingir um objetivo, um
registro de execuo criado para armazenar os resultados alcanados com o seu uso.
Os critrios para atribuir esta classificao esto associados com o prprio objetivo do
objeto de conhecimento (veja na Figura 1 que a classe KOGoal tem como atributo uma
lista de sentenas de verificao).
Figura 2. Fluxo de aes executadas durante o ciclo de vida de um agente
Jason com o Ontowledge instanciado.
47

3.2. Um exemplo de uso na plataforma Jason modificada
A aplicao desenvolvida para exemplificar os mecanismos da nova arquitetura uma
adaptao do exemplo Domestic Robot, cujo cdigo acompanha a distribuio do
Jason. No cenrio descrito h um rob domstico (agente Robot) que tem como objetivo
servir cervejas para o seu proprietrio (representado pelo agente Owner). Para mostrar o
compartilhamento de conhecimento entre os agentes, foi criado o agente Guest que,
assim como o agente Owner, possui os objetivos de adquirir e de tomar cervejas.
Entretanto, diferentemente do agente Owner, o agente Guest no possui o
conhecimento necessrio para buscar e beber as cervejas. Assim, necessrio que ele
interaja com o agente Owner para adquirir conhecimento e atingir os seus objetivos.
A Figura 3 apresenta o cdigo dos agentes Owner e Guest. As linhas 5 e 9 de
Guest.asl mostram que o agente Guest possui apenas a vontade de pegar uma
cerveja (o sub-objetivo declarado, mas no h plano associado). O mesmo ocorre com
o sub-objetivo drink (linha 7). O agente Owner possui objetos de conhecimento que
encapsulam o conhecimento necessrio para adquirir e para beber cervejas
(respectivamente, linhas 6 e 7 de Owner.asl).

Figura 3. Cdigos dos agentes Owner e Guest.
O agente Guest comea sua execuo enviando uma mensagem de requisio
de conhecimento aos outros agentes do sistema (observe nas linhas 2, 4 e 5 de
Guest.asl que o agente comea sua execuo tentando pegar cervejas, sub-objetivo
para o qual no h planos). Considerando que o agente Owner comeou sua execuo
primeiro (e, portanto, j adicionou os objetos de conhecimento em sua base de
conhecimento), este responde a mensagem de solicitao com o objeto de conhecimento
chamado get (adicionado na linha 6 de Owner.asl). Com isto, o agente Guest passa
a ter o conhecimento necessrio para pedir cervejas ao rob. Uma vez que a cerveja
entregue (o que acrescenta a crena has(_,beer)a sua base de crenas), outra
solicitao de conhecimento criada para que o agente Guest possa beber a cerveja
48

recebida (sub-objetivo !drink(beer)). Logo, com ajuda dos mecanismos do
framework Ontowledge, o anfitrio pode ensinar ao seu convidado como solicitar
cervejas ao seu rob domstico e beber as cervejas recebidas.
O desenvolvimento de aplicaes permite investigar se o compartilhamento de
objetos de conhecimento melhora as habilidades de um agente e tambm explorar o
potencial da arquitetura proposta. Entretanto, difcil avaliar de forma quantitativa os
benefcios alcanados durante o ciclo de vida dos agentes. Isto ocorre, principalmente,
porque os resultados da execuo de um plano so fortemente relacionados com o
contexto em que o agente est inserido no momento que deseja realizar um determinado
objetivo, ou seja, h uma srie de mtricas cujas medidas so dependentes de contexto.
De qualquer forma, pretende-se, como trabalho futuro, avaliar agentes desenvolvidos na
plataforma Jason com e sem o framework Ontowledge instanciado.
4. Trabalhos relacionados
Para permitir que agentes desenvolvidos no Jason cooperassem, outra extenso j foi
proposta em 2004. Em (Ancona et al. 2004), os autores propem a integrao da
abordagem Coo-BDI (Ancona e Marcardi 2003) a agentes Jason. Ainda que o resultado
dessa integrao apresente similaridades com o resultado da descrita neste artigo, h
importantes diferenas entre as propostas. Primeiro, acredita-se que um plano (nico
elemento compartilhado pelos agentes segundo a abordagem Coo-BDI) representa
apenas um fragmento do conhecimento necessrio para um agente agir de forma a
alcanar um objetivo. Pode haver casos onde, para um agente executar um plano, seja
necessria a existncia de certas crenas, que tambm precisam ser recuperadas. Outra
diferena entre as propostas a possibilidade de utilizao do histrico de execuo. A
abordagem Coo-BDI no verifica os resultados obtidos com os planos recuperados de
outros agentes.
As caractersticas da arquitetura VERSAG (Gunasekera et al. 2008) tambm
apresentam algumas similaridades com a arquitetura resultante da instanciao do
Ontowledge plataforma Jason. A arquitetura VERSAG, cuja implementao est sendo
feita com base na plataforma Jade (Jade 2010), permite o desenvolvimento de agentes
portadores de componentes de software (os comportamentos de um agente so
implementados como componentes de software portveis que podem ser compartilhados
e implantados em tempo de execuo). Essa arquitetura foi criada com o propsito de
permitir a adaptao dos agentes ao contexto em que eles esto inseridos, ou seja, a
busca e o compartilhamento de componentes de software esto sempre relacionados ao
contexto fsico (do dispositivo) em que o agente est atuando. Embora os autores
indiquem que os agentes devem localizar as capabilities necessrias para que as tarefas
sejam cumpridas, no indicado como o casamento entre as descries de tarefas e as
capabilities disponveis. Na verdade, o exemplo apresentado mostra que a descrio das
tarefas j contm a identificao das capabilities que devem ser localizadas.
5. Consideraes
Esse artigo apresentou o desenvolvimento de uma extenso da plataforma Jason, tendo
em vista a necessidade de compartilhamento de pacotes de conhecimento entre os
agentes na ausncia de planos relevantes ou aplicveis para lidar com um evento. Para a
criao de agentes capazes de gerir seus conhecimentos, foi utilizado o framework
Ontowledge. A arquitetura resultante da instanciao do Ontowledge Jason possibilita,
49

entre outras coisas, o reuso do conhecimento existente, visto que o conhecimento pode
ser compartilhado entre os agentes e utilizado em diferentes situaes e contextos.
De maneira geral, so contribuies desse artigo: (i) a descrio da integrao do
framework Ontowledge em uma plataforma para desenvolvimento de SMAs, o que
pode ser utilizado como guia para outros pesquisadores que objetivam instanciar o
framework em outras plataformas; a adio de novas habilidades aos agentes
desenvolvidos no Jason; e a prpria evoluo do framework Ontowledge, que teve
alguns novos pontos de flexibilidade criados em decorrncia de sua nova instanciao.
Como trabalho futuro, cita-se a implementao dos pontos de flexibilidade que
daro aos agentes Jason a possibilidade de utilizar o histrico de execuo para substituir
o conhecimento insuficiente. Para tanto, ser necessrio criar primitivas para armazenar
os resultados alcanados pelo agente durante sua execuo. A infra-estrutura para a
avaliao dos resultados obtidos j est implementada necessrio apenas sinalizar
que uma inteno foi alcanada e informar os resultados obtidos pelo agente. Depois
desses ajustes, a arquitetura ser disponibilizada para uso.
Referncias
Ancona, D. e Mascardi, V. (2003) Coo-BDI: Extending the BDI model with
cooperativity. In: Proc. of DALT-03, 2003.
Ancona, D., Mascardi, V., Hbner, J. e Bordini, R. (2004) Coo-AgentSpeak:
Cooperation in AgentSpeak through Plan Exchange. In: Proc. of AAMAS2004.
Blois, M., Escobar, M., e Choren, R. Using Agents and Ontologies for Application
Development on the Semantic Web. Journal of the Brazilian Computer Society, vol.
1, 2007.
Bordini, R., Hubner, J., e Wooldridge, M. (2007) Programming Multi-Agent Systems in
AgentSpeak Using Jason. John Wiley & Sons, v. 1. 273 p.
Ferber, J. (1999) Multi-agent systems: an introduction to distributed artificial
Intelligence. Boston: Addison-Wesley, 1999, 528p.
Gunasekera, K., Zaslavsky, A., Krishnaswamy, S. e Loke, S. (2008) VERSAG:
Context-Aware Adaptive Mobile Agents for the Semantic Web. In: 32nd Annual
IEEE International Computer Software and Applications Conference, pp. 521-522.
JADE Homepage (2010) http://jade.tilab.com/.
Jason Homepage (2009) http://jason.sourceforge.net/JasonWebSite/Jason%20Home.php
Klapiscak, T., Bordini, R. (2008) JASDL: A Practical Programming Approach
Combining Agent and Semantic Web Technologies. In: Proc. of DALT 2008, pp.
91-110.
Lemke, A., Blois, M. (2009) Using Knowledge Objects to Exchange Knowledge in a
MAS platform. In: Proc. of SEKE 2009, Boston, pp. 206-211.
Lemke, A., Blois, M. e Choren, R. (2007) A Knowledge Management Framework for
Semantic Multi-Agent Systems. In: Proc. of AOIS 2007, Trondheim, pp. 683-696.
Oates, B. (2006) Researching Information Systems and Computing. Sage Publications
Ltd, 2006, 341p.
Rao, A. (1996). AgentSpeak(L): BDI Agents Speak Out in a Logical Computable
Language. In: Proc. of Seventh MAAMAW, 1996.
50
A Quantitative Study about the Hidden Risk of Using
Time-Scheduler Mechanisms to Control Execution Flow in
JADE-Based MAS
Pier-Giovanni Taranti
1
, Ricardo Choren
2
, Carlos Jos e Pereira de Lucena
1
1
PUC-Rio, Rua M. de S ao Vicente 225 Rio de Janeiro/RJ, Brazil
2
SE/8 - IME, Pca General Tib urcio, 80 Rio de Janeiro/RJ, Brazil
{ptaranti,lucena}@inf.puc-rio.br, choren@ime.eb.br
Abstract. The use of time-scheduler mechanisms in Multi-Agent Systems (MAS)
is a usual way to solve execution control design issues. However, such mecha-
nisms have a drawback which is usually left unattended at design time: there is
no guarantee that a programmed execution will truly be carried out in the ex-
pected moment. Thus this shortcoming remains hidden in the software project,
since it can be only veried by specic non-functional tests. This paper presents
a quantitative experiment that measures this problem when the system becomes
loaded and when the number of agents increases for JADE-based MAS. Some
observations about consequences of such a problem, its risks and mitigation
actions are also presented.
1. Introduction
Multi Agent System (MAS) are systems composed of multiple interacting agents,
which are computer systems that are situated in some environment, and that are ca-
pable of autonomous action in this environment in order to meet its design objectives
[Wooldridge and Jennings 1995, Wooldridge 2002]
Often, MAS is designed as an asynchronous system. The information exchange
between agents is carried out using agents messages. By denition, agents are not suppo-
sed to agree and comply with all the received messages, and this is because of the auto-
nomy principle. Due to these complex characteristics, it is not possible to assure the time
spent in an agent computation, and it is very hard to synchronize agents to guarantee that
some actions will not be carried after or before a certain moment in time.
To allow some control of the system synchronization for MAS implemented with
JADE Platform [JADE 2010, Bellifemine et al. 2007], time schedulers can be used to
tame the execution ow. A usual approach is the use of time-step and time-to-execution
control mechanisms. The rst one denes a waiting time between the start moment of
two subsequent cycles. The second mechanism species a start moment for the cycle
execution.
The issue that arises from the usage of these approaches is the doubt if the de-
signers could truly depend on it. Time-control mechanism uses the system time, often
taken from the hardware clock, to verify if it is time to execute some action. The ve-
rication is continually performed, following the system design. These approaches can
assure that, in a normal execution, the needed code will be executed. However, there are
51
no guarantees about the time-accuracy for these systems and, because of possible delays
in these mechanisms, the system could be taken to achieve unexpected states.
This paper presents a study about the error spread when using such time-control
mechanisms in JADE-based MAS. The measures were taken in relation to the expected
time-to-execution.
The paper is organized as follows: the section 2 presents an explanation about
how time-control mechanisms are implemented. The section 3 presents the JADE imple-
mentation for the mechanisms. Section 4 presents the methodology used to take measures
and presents raw results and comparisons. In section 5 is discussed the risk involved and
some mitigation actions. Section 6 discusses related works issue and section 7 presents
the conclusions.
2. TimeControl Mechanisms
For the considered scope of this work, time-control mechanism is a piece of code that
allows programming actions to be carried out in a determined moment. These mecha-
nisms, which implementation can vary in some way, aim to assure some control on the
software execution ow.
The implementation of these mechanisms is made considering a periodic execu-
tion, i.e a time-step approach, or a unique execution to be performed in a specic moment,
i.e a time-to-execution approach. The implementation is well known: a loop veries if the
trigger is meet, and if it is true, then the action is carried out. The loop implementation
often includes some waiting time between verications.
An inspection of the software code makes clear how these mechanisms are idea-
lized: The current time is veried and, if it is greater than the programed starting time,
the code is executed. The question is that the moment when the execution will start is not
the moment initially programed: the execution will be carried in a posterior moment. The
difference between the programed time and the real moment when the execution starts is
an intrinsic error of the schedule mechanisms. The issue discussed in this paper is not the
time-control mechanism usage itself, but the risk of not considering its intrinsic error.
When the MAS is operating without resource limitations, mainly memory and
processor, this error can be easily disregarded. However, when the system is overloaded
and the agents start to compete for resources, the error increases fast. The consequence in
execution time is that the MAS can reach unpredictable and undesirable states, since the
programed events will be delayed and any expected synchronism between actions can be
lost
The next section presents two mechanisms for time control existent on the JADE
Framework.
3. JADE Implementations for Time-Control Mechanisms
JADE is a framework for MAS development. Since it is FIPA compliant [FIPA 2010],
JADE is an option in academia to develop use-cases, often based in toy problems. These
toy problems are chosen to allow the demonstration of a theory.
To support the development task, JADE provides a set of computer libraries. These
libraries include classes to instantiate concepts which are related to Agent-Oriented Pro-
52
gramming (AOP), such as: behaviors, agents, communication, etc. Besides, the frame-
work is well documented and has an active group in the Internet that support newbies and
experienced users. The TickerBehaviour.java is an example of class that supports time
control mechanisms. This class executes some actions that are inside the onTick method
at each cycle. The WakerBehaviour.java is an example of control that executes only one
time, in a previously determined moment. JADE has other time-control mechanisms pro-
gramed, such as: Timer.java, TimerDispatcher.java and TimerListener.java, though these
mechanisms are used only internally by the framework.
To measure the consequences of the internal error in JADE-based MAS, when
using time-control mechanisms, an experiment was developed: An agent was imple-
mented with three behaviors that contains only the code needed to collect information
for analyzing. In order to avoid interferences in the measures, it was decided do not im-
plement iterations between agents. That is: implemented agents have only behaviors for
data logging. The experiment is explained in next section, that shows also a number of
the obtained results.
4. Methodology
The objective of the experiment was to prove a direct relationship between the delay in
behaviors execution, the load and the number of instantiated agents in MAS. Although
this relationship could be observed by developers, there is an absence of works which can
demonstrate this relationship by experimentation.
The experiment was executed as follows: A MAS was created to generate the
samples, using the JADE framework. This MAS was composed by a number of equal
agents, and these agents execute all the same three behaviors. The behaviors extend the
class TickerBehaviour, and they have a step-rates of 1000, 2000 and 4000 milliseconds.
To allow collecting samples on different situations, 23 MAS were instantiated:
The rst set, with 3 MAS containing 30, 300 and 3000 agents, for evaluating exponential
growing in the number of agents. The second set with the rst MAS containing 10 agents
and the following MAS containing a number of agents from 100 to 2000 agents ( using
steps of 100 agents ). The second set intends to evaluate linear growing in the number of
agents in a MAS. The duration of each MAS execution was 30 minutes.
An articial load was inserted in each behavior, and this load was also equally
varied for each MAS execution. It was decided to adopt a sine function for inserting the
load variation. This load was inserted using the code below :
millis = (long) (100
*
Math.sin(Math.PI
*
(System.currentTimeMillis() - startTime)/
(EXPERIMENT_DURATION_MINUTES
*
60000)));
Thread.sleep(millis);
After instantiating the MAS, it was necessary to dene the approach for measuring
the delays, i.e the error. After some tests, it was decided to use a non-dimensional value,
which calculus is presented below:
Error =
T
executed
T
programed
1
This value indicates how much the execution time is greater then the programmed.
As example, if a cycle with 2000 milliseconds for the step-time starts with 2400 millise-
conds, then the error will be 0.2. The time is measured in milliseconds from the nal of
53
Figure 1. 30 agents MAS
the last execution, following the original JADE implementation for the TikerBehaviour
class.
Figure 2. 3,000 agents MAS
To store the samples, a formatted register was made using CSV les, which were
later manipulated using the Gnuplot software [Janert 2009], besides some text editors.
For each execution were generated 3 les of samples, with the number of samples varying
between 0.65 to 1,700 thousands in each le.
All executions were carried out in the same host, one PC with an Intel Core Duo
processor and 4GB of RAM. The operational system was the OpenSuse Linux 11.2. All
programs, except the MAS, were turned off for testing. The MAS were started using the
JRE default congurations.
The initial analysis were made to verify the behavior of the delay along the time.
In this rst step, MAS with 30, 300 and 3,000 agents were used. It was veried that
the load inuence is stronger when the number of agents is lower. When the number of
agents was increased, the load inuence was very reduced, as it can be seen in gures
54
1 and 2. Each dot in these graphs represent the measured error for a behavior execution
in a specic execution time moment. A great error was observed at starting time for all
executions, in a short period. This error is due to an overload that occurs when charging
agents and behaviors, and it was not considered during the analysis.
It is important to stress that the error scale in the rst gure is 40 times minor than
in the second one. The error level in the 3,000 Agents MAS indicates that the behaviors
often could only achieve times 5 fold greater then the programed. The graphic showed in
the gure 2 also indicates that the execution was delayed for almost all behavior execu-
tions.
The next step of the experiment was to represent the error as a function of the
load and the number of agents. A separated graphic for each MAS execution was plotted
representing the error level as function of the load. After this, a linear regression was
performed for each set of data. The linear regressions were plotted within the samples as
solid lines, and gures 3 to 8 present some of these 20 data sets. Each dot in these graphs
represent the error level of a behavior execution for a specic load. These graphics have
different scale for presenting the error level, because of visualization needs.
The experiment shows that for the initial iterations, with a number of agents not
grater then 700, only the angular coefcient (slope) of the regression function vary, and
the error level is next to 0 when the load is low (gure 3 and 4). The error meet values
next to 10% when the load was next to 100 milliseconds.
The y-intercept of the linear regression started to be inuenced by a number of
agents grater than 800. Figures 5 and 6 shows the experiment for 800 and 1200 agents.
It is important to observe that, though the linear regression is similar for both gures, the
samples dispersion is greater in the 1200 agents MAS, which had more occurrences in
high level of error.
In MAS with a number of agents greater than 1300, the inuence of the load
was reduced. The sample was concentrated in a horizontal strip, and the linear regression
shows a line with slope near lo zero, how can be observed in gures 7 and 8. This scenario
indicates that exists point where the load reduction will not affect the error, since this error
55
56
was caused mainly by the number of agents.
The last graphic is showed in the gure 9. This one presents a complete overview
of the experiment. It is necessary to highlight that the error did not present a linear in-
crease behavior. There is a peak in the iterations with 900 and 1,000 agents. The iterations
for these MAS its borders were executed 3 times to conrm the anomaly.
5. Error Consequences and Risk Mitigation
The experiment proved the initial hypothesis, which is the error existence and the load
and number of agents inuence on this error. It is showed that the error does not increase
in a liner behavior, thus it is very risky to estimate future values.
All iterations of the presented experiment had been performed in the same en-
vironment (i.e hardware and operational system) for reducing external inuences in the
sample, however some other experiments carried out in other hardware environment with
the same operational system and JRE version had produced different level of errors, indi-
cating that the error is environment-dependent.
57
The criticality level of the error in not achieving the expected moment for an
execution depends on the considered MAS and on the actions scheduled. As example, a
delay in a behavior responsible for erasing old registers possibly is a non-critical error.
However, a delay in the account balance verication for a nancial system could be a
critical error.
The denition of the level of criticality that evolves the possible errors should be
established at design time, when risk assessment is done and the mitigation actions are
established and formally registered in the risk management plan. The data observation
allows to afrm that the error exists and also that it is dependable of the environment.
A well done software design could reduce the error by providing bigger step-time and
reducing the load, however it is not possible to guarantee the error level in a produc-
tion environment without specic non-functional tests to carry out the verication of the
system performance.
Because of the involved variables, such as: number of agents, load inside each
programmed execution, hardware, network connections, it can be assumed that the error
needs to be measured in the real environment, or in a simulated environment that could
offers a similar situation to allow perform the system verication.
The system verication is an important mitigation action to reduce the risk. This
verication will increase the project total cost, however, it will increase the system reli-
ability. In addiction, the tests performed during the verication could provide the ope-
Figure 9. A 3D graphics, Error as function of load and agents number
58
rational limits for operating the MAS, within a condence interval. These tests are an
ad-hoc activity, since MAS testing is a challenge, and although the researches about the
theme, there is an absence of tools and theory for supporting the task. Besides, the existent
works commonly focus on the functional aspects of the MAS testing, not covering non-
functional aspects (e.g [Nguyen et al. 2009, Coelho et al. 2006, Rodrigues et al. 2005]).
The mitigation in execution time could be performed by including some triggers
in the system that are able to detect anomalous behaviors. This can be done by instru-
menting the code with executable asserts. These asserts can measure the error level and
launch a corrective action or exception when this error pass the established level. The
JML [Leavens et al. 2009] presents a complete framework to implement assertions. It is
also possible to use the native Java support to assertions [Mahmoud 2005] or even to im-
plement these assertions by hands. An example for detection of error greater than 0.05 is
showed above:
Public class Verify Send extends Misbehavior {
.....................
private void onTick() {
if(nowTime-lastTime > period && nowTime-lastTime < period
*
1.05){
System.out.println("agent "+ a.getLocalName()+
" is executing with delay greater than 5%");
System.out.println("The systen is being shuting down -" +
" an inconsistent state was achieved");
System.exit(1);
}
}
...................
}
6. Related Works
The bibliographic research did not achieve success in locate other works that explicitly
had focus on the risks and the consequences of time-control mechanisms used in MAS.
The same occurs when trying to locate experimental data published on the issue.
7. Conclusions
This paper presents a quantitative experiment about the delays in scheduled events in
JADE-based MAS. The inuence of the number of agents in the MAS and the load of
the scheduled actions were analyzed, for the experiment. These delays can cause errors in
execution time, since actions will be performed before the expected moment. These errors
critically depends on the considered MAS. Some possible mitigation actions were also
presented, such as performing non-functional tests at development time and to include
tests in execution time to verify the error level.
It is recognized that time schedulers are an important resource to control the data
ow in execution time. The work does not intend to recommend its non-use. However,
it is stated that, when using time schedulers to control critical functions in the system,
it is necessary to perform non-functional tests in an environment similar to production
environment to measure and dene the operation limits in which the system performance
can be guaranteed.
59
The experiment has focus on JADE-based MAS. A future work could cover other
agent frameworks, that use time scheduler mechanisms, to evaluate if the results can be
extended to it.
It is desirable to redo the bibliographic research, covering other areas where simi-
lar issues could appear and to consider the applicability of the proposed solutions. Some
of the possible areas to be veried are parallel programming, distributed programing and
service oriented architecture implementation.
The experiment is part of a research related to the use of MAS for simulation. The
next steps of this research is to develop an architecture that will be able to tame the error
in scheduled events, in order to avoid inconsistent states in the simulation model.
References
Bellifemine, F. L., Caire, G., and Greenwood, D. (2007). Developing Multi-Agent Systems
with JADE (Wiley Series in Agent Technology). John Wiley & Sons.
Coelho, R., Kulesza, U., von Staa, A., and Lucena, C. (2006). Unit testing in multi-agent
systems using mock agents and aspects. In SELMAS 06: Proceedings of the 2006
international workshop on Software engineering for large-scale multi-agent systems,
pages 8390, New York, NY, USA. ACM.
FIPA (2010). Foundation for intelligent physical agents. http://www.pa.org/.
JADE (2010). Java agent development framework. http://jade.tilab.com.
Janert, P. K. (2009). Gnuplot in Action: Understanding Data with Graphs. Manning
Publications Co. ISBN 978-1-933988-39-9.
Leavens, G. T., Poll, E., Clifton, C., Cheon, Y., Ruby, C., Cok, D., and Kiniry, J. (2009).
Jml reference manual (draft). http://www.jmlspecs.org/OldReleases/jmlrefman.pdf.
vericado em janeiro de 2010.
Mahmoud, Q. H. (2005). Using assertions in java technology.
http://java.sun.com/developer/technicalArticles/JavaLP/assertions/. vericado
em janeiro de 2010.
Nguyen, C. D., Perini, A., Tonella, P., Miles, S., Harman, M., and Luck, M. (2009).
Evolutionary testing of autonomous software agents. In AAMAS 09: Proceedings
of The 8th International Conference on Autonomous Agents and Multiagent Systems,
pages 521528, Richland, SC. International Foundation for Autonomous Agents and
Multiagent Systems.
Rodrigues, L. F., Carvalho, G. R. D., de Barros, R., Jose, C., and Lucena, P. (2005).
Towards an integration test architecture for open mas. In In: Software Engineering for
Agent-oriented Systems - SEAS05.
Wooldridge, M. and Jennings, N. (1995). Intelligent Agents: Theory and Practice. The
Knowledge Engineering Review, 10(2):115152.
Wooldridge, M. J. (2002). An Introduction to MultiAgent Systems. John Wiley & Sons,
Inc.
60
Definindo Logicamente Componentes Subsumption
Gustavo L. Campos
1
, Mariela I. Corts
1
, Enyo J. T. Gonalves
1, 2

1
Universidade Estadual do Cear, Fortaleza - CE Brasil
2
Universidade Federal do Cear, Quixad - CE Brasil
{gustavo, mariela}@larces.uece.br, enyotavares@uece.br
Resumo. A arquitetura Subsumption foi desenvolvida visando o controle de
comportamentos de robs mveis capazes de realizar tarefas complexas em
ambientes fsicos dinmicos. Vrios aspectos nos componentes dessa
arquitetura podem ser adequados ao projeto de mecanismos de tomada de
deciso para agentes autnomos de software. Entretanto, o projeto destes
mecanismos no uma tarefa trivial. Este artigo apresenta um conjunto de
definies lgicas que permitem a descrio e execuo dos principais
componentes envolvidos no projeto com Subsumption.
Abstract. The subsumption architecture was developed to control the behavior
of mobile robots able to perform complex tasks in dynamic physical
environments. Several aspects of the fundamental components of this
architecture can be tailored to the design of mechanisms for decision-making
software for autonomous agents. However, due to the high level of parallelism
implicit in the subsumption, the design of these mechanisms is not a trivial task.
This article presents a set of logical definitions that allows the description and
implementation of key components involved in the project with subsumption.
1. Introduo
Agentes autnomos orientados por comportamentos so sistemas que buscam alcanar
metas em ambientes parcialmente observveis, estocsticos, dinmicos e multiagentes
[Russell e Norvig 2001]. Devido s aes e interaes entre agentes, um agente deve
selecionar rapidamente aes considerando apenas percepes locais do ambiente. Assim, a
concepo de comportamentos deve combinar adequadamente caractersticas deliberativas
e reativas em uma arquitetura hbrida [Georgeff 1987] e [Fergunson 1992].
Os agentes deliberativos, como os agentes lgicos e os agentes BDI [Weiss
1999], constroem uma representao simblica do mundo e selecionam suas aes
empregando o raciocnio lgico sobre essas representaes [Kraus 2001]. Por sua vez,
os agentes reativos, como os agentes baseados em regras condio-ao [Russell e
Norvig 2003] e em Subsumption [Brooks, 1986], selecionam suas aes com base na
percepo atual do ambiente, no constroem um modelo simblico para representar o
mundo e no fazem raciocnio simblico complexo.
A Subsumption visa o controle de robs mveis em ambientes dinmicos, onde o
desempenho dos agentes reativos baseados em regras condio-ao baixo [Conel,
1987]. O tempo de resposta e alguns aspectos em seus componentes permitem tanto o
projeto de comportamentos muito simples, caso dos insetos em sociedade, quanto de
comportamentos mais complexos, caso de humanos e de determinados sistemas artificiais
orientados por metas e utilidade, e com aprendizagem [Russell e Norvig, 2003].
61
O projeto do mecanismo de seleo de aes do agente Subsumption
decomposto no projeto de comportamentos orientados s tarefas a serem realizadas no
ambiente. O projeto envolve a definio de nveis de competncia (camada), onde cada
nvel uma especificao informal de um comportamento. Cada camada Subsumption
contm um conjunto de processadores que funcionam em paralelo e interagem entre si
trocando informaes por meio de linhas de comunicao. O alto nvel de paralelismo
na Subsumption torna a concepo e teste de um agente autnomo uma tarefa dificil. A
grande vantagem que seus principais componentes podem ser adaptados concepo
de comportamentos adequados a diversos tipos de agentes autnomos. Mais
recentemente, diversas classes de arquiteturas de controle em camadas foram
originadas com base na Subsumption [Weiss, 1999].
Este artigo ressalta alguns dos aspectos presentes nos componentes da
arquitetura, destacando um conjunto de definies lgicas que podem ser utilizadas na
concepo e no teste de uma Subsumption. Mais especificamente, essas definies
permitem que comportamentos especficos empregando os componentes fundamentais
da arquitetura sejam declarados e executados em sistemas de programao em lgica,
permitindo a anotao do processamento interno realizado pelos componentes, que os
erros sejam percebidos e corrigidos, e que os comportamentos sejam melhorados.
O artigo organizado em seis sees. A Seo 2 esboa a idia por trs da
Subsumption, destacando seus principais componentes. A Seo 3 exemplifica um projeto
especfico de comportamento envolvendo uma Subsumption de duas camadas. A Seo 4
apresenta as definies lgicas empregadas na Seo 5 para descrever e executar os
componentes da arquitetura. A Seo 6 apresenta as consideraes sobre a abordagem.
2. Agentes Autnomos e Subsumption
O desenvolvimento de agentes autnomos com Subsumption consiste em descrever um
comportamento complexo atravs de vrios comportamentos mais simples, que
intercalam-se para gerar o comportamento original. O projetista especifica uma
hierarquia de subordinao envolvendo as competncias bsicas para gerar o
comportamento desejado. Cada nvel de competncia d origem a uma camada de
controle, que pode ser construda sobre uma ou mais camadas (Figura 1) [Brooks,
1986]. As camadas nos nveis mais baixos esto relacionadas com tarefas bsicas e de
sobrevivncia do agente. As camadas nos nveis mais elevados realizam tarefas mais
especficas e relacionadas ao objetivo do agente.

Figura 1. Hierarquia de nveis de competncia.
As informaes dos sensores so alimentadas para todas as camadas, enquanto
que e a informao sobre a ao a ser executada por algum atuador depende do resultado
das interaes entre camadas. Cada camada composta por um conjunto de processadores
que funcionam assincronamente, sem um controle central, recebendo mensagens por meio
de linhas de entrada, que so processadas e enviadas para suas linhas de sada. Um
62
processador em uma camada superior pode obter ou injetar dados nos processadores das
camadas inferiores. As linhas de sadas dos processadores nas camadas superiores podem,
por algum tempo, suprimir (S) o fluxo de dados nas linhas de entradas ou inibir (I) o fluxo
de dados nas linhas de sada dos processadores nas camadas inferiores ( Figura 2).

Figura 2. Linhas de comunicao com/do processador
Cada processador uma mquina de estados finitos, estendida de variveis para o
armazenamento de estruturas de dados que so relevantes ao processo de transio de
estados da mquina. Cada estado identificado por um nome. A entrada Reset fora o
processador a voltar ao seu estado inicial (Nil). Existem quatro tipos de estados diferentes
que dependem das entradas e das variveis de armazenamento: (1) no estado sada envia
uma mensagem para sua linha de sada; (2) no estado efeito lateral atribu um valor a uma
de suas variveis de armazenamento; (3) no estado despacho por condio muda para um
de dois estados possveis; e (4) no estado despacho por evento muda para um de vrios
estados possveis. Empregando estes estados e os esquemas de ligao, diversos tipos de
comportamentos podem ser especificados. Brooks (1986) props o controle de um agente
rob em uma Subsumption composta por oito nveis de competncia, onde o
comportamento mais simples, Nvel 0, consiste em evitar obstculos e o mais complexo,
Nvel 7, em raciocinar sobre o comportamento de outros agentes no ambiente.
3. Componentes da arquitetura Subsumption
Esta seo destaca uma parte da especificao do comportamento vagar pelo ambiente
evitando obstculos, que foi abstrada das descries que Brooks (1986) realizou em
linguagem Lisp [Seibel 2005] dos principais mdulos processadores de uma arquitetura
de trs camadas, capaz de implementar o comportamento explorando o ambiente,
vagando e evitando obstculos.
3.1 Camadas
No mecanismo de controle proposto por Brooks (1986), o comportamento vagar pelo
ambiente evitando obstculos implementado em duas camadas. A primeira camada,
Nvel 0, implementa o comportamento evitar obstculos no ambiente e a segunda
camada, Nvel 1, implementa o comportamento vagar pelo ambiente, que, ao subordinar
a primeira camada e, consequentemente, viabilizar a troca de mensagens entre
processadores nas duas camadas, implementa o comportamento mais complexo vagar
pelo ambiente evitando obstculos. A Figura 3 destaca as camadas e seus processadores.
A camada Evitar Obstculos responsvel por impedir que o rob colida com
objetos no ambiente ou com outros agentes que se aproximem com certa velocidade. O
processador Sonar constri um mapa do ambiente com as informaes dos sensores do
rob. O processador Sentir Fora considera os objetos no mapa que esto ao redor do
agente como foras repulsivas e calcula uma fora resultante. O processador Fuga
monitora a fora produzida por Sentir Fora e envia comandos para o processador
Motor, que comanda a parte fsica do rob. Este processador executa em loop at que o
63
movimento tenha terminado ou at que o comando Halt seja recebido, obrigando o
motor a parar imediatamente. O processador Coliso monitora o mapeamento gerado
por Sonar e, caso a coliso seja iminente, envia um comando para o motor parar (halt).

Figura 3. Nveis 0 e 1 da Subsumption.
A camada Vagar subordina a camada Evitar Obstculos, utilizando a
competncia evitar obstculos para permitir a locomoo do agente com segurana pelo
ambiente. Ela adiciona dois novos processadores subsumption do rob. O processador
Vagar responsvel por gerar uma direo para o agente. O processador Evitar
Obstculos utiliza a fora calculada pelo processador Sentir Fora no Nvel 0 e combina
sua direo com a direo gerada por Vagar para gerar, ou no, uma trajetria final para
o agente seguir. Se a trajetria for gerada, por meio de supresso, ao ser injetada na
entrada do processador Motor, essa sada substitui a sada gerada pelo processador
Fuga, permitindo ao agente vagar pelo ambiente evitando os obstculos que encontrar.
3.2 Processadores
Para descrever alguns dos processadores e simular o funcionamento das duas camadas
de processadores, optou-se por representar as informaes em suas linhas de entrada e
sada, bem como os valores das variveis de armazenamento, por meio de termos que
podem ser: cadeias de smbolos para identificar objetos especficos denominadas
tomos, e estruturas simblicas formadas a partir de tomos para identificar objetos de
uma maneira indireta ou objetos cujas partes precisem ser nomeadas. Para descrever o
funcionamento do processador Evitar Obstculos no Nvel 1, foram realizadas algumas
suposies a respeito do funcionamento de alguns dos processadores no Nvel 0 e das
informaes em suas linhas de entrada e sadas.
No que diz respeito camada Evitar Obstculos no Ambiente, Nvel 0, sups-se
que: (1) o processador Sonar fornece em sua linha de sada um mapa de foras
repulsivas, (2) que o processador Sentir Forca utiliza esta informao em sua linha de
entrada e gera em suas linhas de sada uma descrio da fora repulsiva resultante em
torno do agente, FSonar, na forma de uma estrutura simblica forca(M,D), onde M
uma varivel para representar a magnitude da forca como, por exemplo, os valores
(strings) alto e baixo, e D uma varivel para representar a direo como, por exemplo,
p/frente e p/trs; (3) que o processador Fuga recebe a informao sobre a fora repulsiva
FSonar em sua linha de entrada e produz em sua linha de sada uma descrio de
comando, Comando, na forma de uma estrutura comandofuga(M,D), onde M e D
so variveis que tambm representam magnitude e direo.
A Figura 4 destaca o processador Evitar Obstculos da camada Vagar no Nvel
1. Este processador recebe nas suas linhas de entrada a fora repulsiva FSonar, gerada
pelo processador Sentir Fora no Nvel 0, e a informao sobre FDireo gerada por
64
Vagar no Nvel 1. Conforme a representao adotada para FSonar, optou-se por
representar FDireo por meio de uma estrutura da forma heading(M,D).
Estruturalmente, a informao na linha de sada do processador Evitar Obstculo,
comandoevitar(M,D), semelhante informao Comando na linha de sada do
processador Fuga, j que ambas so alimentadas para a entrada do processador Motor.

Figura 4. Processador Evitar Obstculos da camada Vagar.
Os valores da nica varivel interna de armazenamento, FRes, associada ao
processador foram representados por estruturas da forma foraresultante(M,D). Na
figura, fora/2 representa uma funo que recebe como entrada as estruturas simblicas
em FSonar e FDireo e retorna como sada uma estrutura simblica que valor de
FRes. Por sua vez, fora_significante/2 uma funo que recebe como entrada a
estrutura FRes e um valor de limiar e verifica se o valor em FRes excede algum limiar
como, por exemplo, se o movimento resultante durar menos que 1.0 segundos.
O estado inicial de Evitar Obstculos, Nil, do tipo 4, ou seja, despacho por
evento. O funcionamento do processador pode ser descrito em termos das transies que
ocorrem a partir deste estado, ou seja: (A) se as informaes sobre FSonar e FDireo
estiverem disponveis em suas linhas de entrada, o processador transita para o estado
Planejar, que um estado tipo 2, ou seja, efeito lateral; (B) a funo fora(FSonar,
FDireo) avaliada e o resultado instanciado na varivel interna FRes, e o
processador transita para o estado Ir, que um estado do tipo 3, ou seja, despacho por
condio; (C e D) a funo fora_significante(FRes, 1.0) avaliada e, se for verdadeira,
o processador transita para o estado inicial Nil, seno, transita para o estado Iniciar, que
um estado do tipo 1, ou seja, sada; e (E) no estado Iniciar o processador envia as
informaes em Comando para sua linha de sada e transita para o estado inicial.
4. Linguagem para definio de componentes
A seo apresenta algumas definies lgicas para a descrio dos principais aspectos
relacionados aos componentes das arquiteturas em camadas, semelhantes
Subsumption. As definies permitem especificar a estrutura interna dos processadores
e o modo como se comunicam. Diferentemente da formalizao especifica (trs
camadas referentes aos comportamentos simples: evitar obstculos, vagar e explorar)
realizada por Brooks (1986) em linguagem Lisp, as definies foram formalizadas em
linguagem PROLOG e, como consequncia, podem ser especializadas para quaisquer
processadores e esquemas de comunicao, alm de permitir que as especificaes
resultantes sejam executadas automaticamente, que o funcionamento dos processadores
interligados seja anotado, que os erros sejam detectados e os ajustes realizados.
4.1 Definindo processadores e seus funcionamentos
Na proposta de Brooks (1986) cada processador uma mquina de estados estendida
para incluir os quatro tipos de estados possveis, a noo de varivel de armazenamento
e a existncia de vrias linhas de entrada e sada. O estado inicial o estado no qual o
funcionamento do processador comea e, em geral, denotado por Nil. Conforme o
diagrama que descreve o processador Evitar Obstculos na Seo 3, alm do alfabeto de
65
termos, do conjunto de estados e do estado inicial, um componente essencial na
especificao do processador a definio da funo transio associada. Esta funo
deve considerar os quatro tipos de estados possveis. Para cada informao na entrada e
nas variveis, s pode ocorrer exatamente uma transio saindo de cada estado.
Pode-se dizer que a funo transio do processador mapeia uma configurao
de entrada, ou seja, um par formado pelo estado corrente do processador e o conjunto de
termos nas linhas de entrada e armazenados nas variveis do processador, em um par
formado pelo conjunto de termos a serem enviados para as linhas de sada do
processador e uma configurao de sada, ou seja, um par formado por um novo estado
e um novo conjunto de termos armazenados nas variveis internas do processador. O
Quadro 1 apresenta uma definio genrica de funo transio que pode ser empregada
para definir logicamente qualquer processador especfico a partir da especializao das
frases e customizao de alguns predicados que compem a definio.
Quadro 1 Definio PROLOG funo transio de estados.
Tipo 1 delta(Processa,1,EstCorrente,LisEntradas,LisVariaveis,LisSaidas,TipoEstNovo,EstNovo):-
enviar_mensagem_saida(LisEntradas,LisVariaveis,LisSaidas).
Tipo 2 delta(Processa,2,EstCorrente,LisEntradas,LisVariaveis,_,TipoEstNovo,EstNovo):-
setar_variavel(LisEntradas,LisVariaveis).
computar_predicado(LisEntradas,LisVariaveis), !.
delta(Processa,3,EstCorrente,LisEntradas,LisVariaveis,_,TipoEstNovo,EstNovo).
condicao1(LisEntradas),!.
...
delta(Processa,4,EstCorrente,LisEntradas,LisVariaveis,_,TipoEstNovo,EstNovo):-
condicaoN(LisEntradas).
delta(Processa,4,EstCorrente,_,_,_,TipoEstNovo,EstNovo):- atrasar(Tempo).
O primeiro argumento de cada frase na definio delta/8 identifica o nome do
processador. O segundo e o terceiro identificam, respectivamente, o tipo e nome de um
estado corrente de onde partem as transies. O quarto argumento identifica os valores
armazenados nas variveis e as leituras nas linhas de entrada, antes das transies
ocorrerem. Estes argumentos representam as informaes de entrada na definio. Os
outros argumentos podem ser vistos como representando as sadas. O quinto argumento
identifica as variveis internas do processador. O sexto, os valores nas suas linhas de
sada. O stimo e o oitavo, respectivamente, o tipo e o nome do prximo estado (novo),
obtido como resultado da leitura da entrada e/ou de algum outro evento, conforme o tipo
de estado corrente. Os predicados enviar_mensagem_saida/3, setar_variavel/2,
computar_predicado/2, condio1/1, ..., condioN/1 e atrasar/1 identificam estas
leituras e os eventos implcitos em cada tipo de estado, e devem ser customizados de
acordo com as caractersticas de um processador especfico.
Assim como no caso dos autmatos, a funo transio de um processador pode
ser estendida para descrever seu funcionamento. Em qualquer instante de
funcionamento pode-se considerar que o processador est em alguma configurao, ou
seja: em um estado, recebendo termos em suas linhas de entradas, a partir da qual
realiza algum tipo de evento e transita para uma prxima configurao. A funo
transio estendida corresponde ao caso em que o processador executa uma sequncia
de transies, podendo realizar leitura de termos nas suas linhas de entrada e variveis
de armazenamento, e outros eventos internos. A definio de funo transio estendida
escrita em linguagem PROLOG apresentada no Quadro 2.
66
Quadro 2 Definio PROLOG da funo transio de estados estendida.
deltaest(Processa,EstCorrente,LisEntradas,LisVariaveis,LisSaidas,EstNovo):-
delta(Processa,_,EstCorrente,LisEntradas,LisVariaveis,LisSaidas,_,EstNovo1,cont),!,
deltaest(Processa,EstNovo1,LisEntradas,LisVariaveis,LisSaidas,EstNovo).
deltaest(Processa,EstCorrente,LisEntradas,LisVariaveis,LisSaidas,EstNovo):-
delta(Processa,_,EstCorrente,LisEntradas,LisVariaveis,LisSaidas,_,EstNovo,fim).
Conforme pode ser percebido a definio deltaest/6 genrica e no precisa ser
especializada para processadores individuais. Considerando esta definio e a definio
de um estado inicial, o Quadro 3 apresenta a definio genrica de processador.
Quadro 3 Definio PROLOG do processador.
processador(Processa,LisEntradas,LisVariaveis,LisSaidas):-
inicial(Processa,EstInicial),
deltaest(Processa,EstInicial,LisEntradas,LisVariaveis,LisSaidas,_).
Vale ressaltar, a definio acima pode ser utilizada para definir e executar
qualquer processador especfico, em qualquer nvel (camada) de competncia, bastando
que o estado inicial do processador seja definido de acordo com predicado inicial/2.
4.2 Definindo linhas de comunicao entre processadores
O Quadro 4 define formalmente os trs meios de comunicao entre processadores em
uma mesma camada e entre processadores de camadas diferentes, ou seja, as linhas de
injeo direta de informao, de supresso e de inibio.
Quadro 4 Definio PROLOG ligaes entre processadores.
linha(ProcessaFonte,Saidafonte, ProcessaDestino,Entradadestino):-
Entradadestino = Saidafonte.
suprimir(ProcessaFonte,Entradasupressora,Saidainibida, ProcessaDestino,Entradasuprimida,Tempo):-
not Entradasupressora = [],!,
Entradasuprimida = Entradasupressora,
suprimir(ProcessaFonte,Entradasupressora,Saidainibida, ProcessaDestino,Entradasuprimida,Tempo):-
Entradasuprimida = Saidainibida.
inibir(ProcessaFonte,Entradainibidora,Saidainibida, ProcessaDestino,Entradainibida,Tempo):-
not Entradainibidora = [],!,
Entradainibida = [].
inibir(ProcessaFonte,Entradainibidora,Saidainibida, ProcessaDestino,Entradainibida,Tempo):-
Entradainibida = Saidainibida.
A primeira frase define a ligao no formato de uma linha, linha/4, que alimenta
a sada de um processador para a entrada de outro. A segunda e a terceira frase definem
a ligao supresso, suprimir/6, onde a sada de um processador suprime o sinal na
entrada de outro processador. As duas ltimas frases definem a ligao inibio,
inibir/6, onde a sada de um processador inibe a sada de outro.
4.3 Definindo a Subsumption
Considerando estas definies todas as ligaes necessrias a qualquer sistema de
controle em camadas com os aspectos da Subsumption podem ser especificadas. O
Quadro 5 apresenta a definio genrica da arquitetura.
Quadro 5 Definio PROLOG da Subsumption.
subsumption(Entradas):-
<seqncia de predicados elementares, predicados de ligaes e predicados
de processadores, considerando Entradas e separados por vrgulas>.
A especializao da definio subsumption/1 para uma organizao especifica
de processadores interligados, permite executar a organizao e observar (anotar) os
aspectos dos componentes em todas as etapas de funcionamento, tanto do
67
funcionamento interno dos processadores quanto da comunicao entre eles. A prxima
seo destaca a especificao de uma parte dos processadores que compem a
Subsumption vagar pelo ambiente evitando obstculos, discutida na Seo 3.
5. Definindo componentes
O Quadro 6 apresenta a definio da funo transio do processador Evitar
Obstculos descrito na Figura 4, ou seja, na camada Vagar.
Quadro 6 Funo transio Evitar Obstculos.
delta(evitar,1,iniciar,_,Variaveis,Saidas,4,nil,fim):- Variaveis = [FResultante],
seguir_forca(FResultante,Comando),
Saidas = [Comando].
delta(evitar,2,planejar,Entradas,Variaveis,_,3,ir,cont):- selec_direcao(Entradas,FResultante),
Variaveis = [FResultante].
delta(evitar,3,ir,_,Variaveis,_,1,iniciar,cont):- Variaveis = [forcaresultante(Magnitude,_)],
forca_significante(Magnitude,1),!.
delta(evitar,3,ir,_,_,[[]],4,nil,fim).
delta(evitar,4,nil,Entradas,_,_,2,planejar,cont):- Entradas = [Forca,Heading],
not Forca = [], not Heading = [],!.
delta(evitar,4,nil,_,_,[[]],_,_,fim).
Cada estado considera apenas as entradas, variveis e/ou sadas relevantes. O
oitavo argumento, que no est presente na definio genrica de funo transio no
Quadro 1, foi necessrio para o registro de um ciclo do processamento dos
componentes. O registro deste ciclo pode ser realizado empregando-se a definio
processador/4, descrita no Quadro 3, definindo-se previamente seu estado inicial
incial/2. O Quadro 7 apresenta o registro de um ciclo do processador Evitar Obstculos
considerando valores de entrada especficos e o estado inicial inicial(evitar,nil).
Quadro 7 Funcionamento do processador Evitar Obsttculos.
?- processador(evitar, [forca(alta, frente), heading(alta, frente)], Variaveis, Saidas).
Entradas Modulo Evitar = [forca(alta, frente), heading(alta, frente)]
Entrada nil = [forca(alta, frente), heading(alta, frente)] | nil nao gera saida |
Estado Novo = planejar
Entrada planejar = [forca(alta, frente), heading(alta, frente)] | planejar nao gera sada |
Variaveis = [forcaresultante(alta, atras)] | Estado Novo = ir
ir nao utiliza entradas - utiliza Variaveis = [forcaresultante(alta, atras)] | ir nao gera
saida - Cond. satisf. | Estado Novo = iniciar
inicio utiliza entradas - utilliza Variaveis = [forcaresultante(alta, atras)] | Saida iniciar =
[comandoevitar(alta, atras)] | Estado Novo nil
Saidas Modulo Evitar = [comandoevitar(alta, atras)
Variveis = [forcaresultante(alta, atras)] | Sadas = [comandoevitar(alta, atras)]
A parte sombreada do Quadro 7 apresenta o registro do funcionamento do
processador. Esse registro considera as duas mensagens nas linhas de entrada do
processador, ou seja, os contedos de Fora e FDireo na Figura 3, respectivamente
supostas sadas dos processadores Sentir Fora no Nvel 0 e Vagar no Nvel 1. Partindo
do estado inicial nil, todas as transies foram registradas at o retorno a nil e a gerao
da sada do processador, ou seja, o contedo de Comando na Figura 3, que vai suprimir
uma das entradas do processador Motor. Alm do mais, as partes no sombreada da
figura apresentam, respectivamente antes e depois da parte sombreada: (1) a maneira
como a consulta ao processador deve ser realizada e (2) a resposta obtida para a
consulta, inclusive o contedo da varivel de armazenamento.
68
O Quadro 8 apresenta a definio correspondente a uma parte da Subsumption
da Figura 3, ou seja, o comportamento vagar pelo ambiente evitando obstculos. A
definio uma especializao da definio subsumption/1 no Quadro 5 e descreve uma
seqncia de predicados elementares, predicados de ligaes e predicados de
processadores para a anotao do funcionamento interno do subsistema em questo.
Quadro 8 Parte da Subsumption descrita na Figura 3.
subsumption(Entradas):-
Entradas = [Estadomotor], gerar_forca(Forca,X), Saidasentir = [Forca],
processador(sentirforca,_,_,Saidasentir), ge_direo(X,FDireo),
Saidavagar = [FDireo], processador(vagar,_,_,Saidavagar),
linha(sentirforca,Saidasentir,evitar,Entevitar1), linha(vagar,Saidavagar,evitar,Entevitar2),
concatena(Entevitar1,Entevitar2,Entradaevitar),
processador(evitar,Entradaevitar,Variavelevitar,Saidaevitar),
linha(sentirforca,Saidasentir,fuga,Entradafuga),
processador(fuga,Entradaafastar,_,Saidafuga), Saidafuga = [Comandofuga],
Saidaevitar = [Comandoevitar],
suprimir(evitar,Comandoevitar,Comandofuga,motor,Entradamotor,15),
processador(motor,Entradamotor,_,Saidamotor), continua?,!,
Saidamotor = [Estadomotornovo], subsumption(Saidamotor).
subsumption(_).
O Quadro 9 apresenta o registro de apenas um ciclo do funcionamento dos
processadores que compem o subsistema para a situao em que a entrada do
processador Motor suprimida pela sada do processador Evitar Obstculos no Quadro 6.
Ao final do registro, novas leituras devem ser colecionadas pelos sensores e alimentadas
para as linhas de entrada dos processadores.
Quadro 9 Funcionamento da Subsumption.
?- subsumption([_]).
Incio Funcionamento Processador Sentir Fora
Entradas = [mapa(conjuntodepontos)]
Saidas = [forca(alta, frente)]
Fim Processamento Sentir Fora
Incio Funcionamento Processador Vagar
Entradas = []
Estado nil nao utiliza entradas e variveis | nil nao gera saida | nil gera um atraso de 10
segundos | Estado Novo = geradirecao
geradireca nao utiliza entradas e variveis | Saida geradirecao = [heading(alta, frente)] |
Estado Novo = nil
Saidas = [heading(alta, frente)]
Fim Funcionamento Processador Vagar
Funcionamento Processador Evitar Obstculos conforme Quadro 7
Incio Funcionamento Processador Fuga
Entradas = [forca(alta, frente)]
Entrada nil = [forca(alta, frente)] | Estado nil nao gera saida | Estado Novo = decidir
Entrada decidir = [forca(alta, frente)] | Estado decidir nao gera saida - Cond. satisf. |
Estado Novo = afastar
Entrada afastar = [forca(alta, frente)] | Saida afastar = [comandoafastar(alta, frente)] |
Estado Novo nil
Saidas = [comandoafastar(alta, frente)]
Fim Funcionamento Processador Fuga
Incio Funcionamento Processador Motor
Uma Entrada do processador motor foi suprimida pela saida do processador evitar obstac.
Entradas = comandoevitar(alta, atras)
Saidas
Fim Funcionamento Processador Motor
69
6. Consideraes finais
Conceber agentes autnomos Subsumption que requisitem vrias camadas para a
implementao de um comportamento complexo no uma tarefa trivial. A falta de
modularidade de um projeto para o outro e o alto nvel de paralelismo implcito na
arquitetura ainda dificultam mais a tarefa. Assim, apesar da Subsumption ter dado
origem a toda uma classe de arquiteturas de controle em camadas desenvolvidas mais
recentemente, os aspectos relacionados aos seus componentes ainda podem ser muito
bem utilizados, isto , podem ser adaptados e utilizados na concepo de
comportamentos em camadas, sejam eles reativos ou deliberativos. Considerando esta
uma das grandes vantagens da Subsumption, o artigo deu nfase aos principais
componentes da arquitetura, um meio de especific-los, de executar configuraes de
componentes e detectar erros de funcionamento, corrigir os mesmos e melhorar seus
desempenhos. As definies lgicas apresentadas so genricas o suficiente e podem ser
especializadas e customizadas para conceber qualquer comportamento projetado com os
componentes Subsumption.
Referncias
Brooks, R. A. (1986) A Robust Layered Control System for a Mobile Robot. In
IEEE Journal of Robotics and Automation, RA-2, pp 14-23.
Conell, J. H. (1987) Creature Building with the Subsumption Architeture, IJCAI-87,
Milo, Itlia, 1124-1126.
Epstein, J. M. (2002) Modeling civil violence: An agent-based computational
approach, Proceedings of the National Academy of Sciences of the United States
of America, 99, pp. 7243-50.
Ferguson, I. A. (1992) TuringMachines: An Architecture for Dynamic, Rational,
Mobile Agents, Thse de doctorat, University of Cambridge, UK.
Gavrilets, S. (2003) Models of speciation: what have we learned in 40 years?,
Evolution, 57(10):2197-2215.
Georgeff, M. P.; Lansky, A. L. (1987) Reactive reasoning and planning. In
Proceedings of the Sixth National Conference on Artificial Intelligence (AAAI-
87), pages 677-682, Seattle, WA.
Kauffman, S. A. (2003). Molecular Autonomous Agents, Philosophical Transactions
of the Royal Society of London Series A- Mathematical Physical and
Engineering, 361:1807, pp. 1089 99.
Kraus, S. (2001) Strategic Negotiation in Multi-Agent Environments, The MIT Press.
Parunak, H. V. D.; Savit, R.; Riolo, R. L. (1998) Agent-Based Modeling vs.
Equation-Based Modeling: A Case Study and Users' Guide, In Conte Sichman
and Gilbert, editors, Multi-agent systems and Agent-based Simulation (MABS'98),
volume 1534 of LNAI series. Springer-Verlag.
Russell, S.; Norvig, P. (2003) Artificial Intelligence: A Modern Approach, New
Jersey: 2th Ed. Prentice-Hall.
Seibel, P. (2005) Practical Common Lisp. Apress, 2005.
Weiss, G. (1999) Multiagent Systems: A Modern Approach to Distributed Artificial
Intelligence, Massachucetts: MIT.
70

Algoritmo Gentico Aplicado a um Agente para a Seleo
de Leiles do Tipo CDA do TAC
Robson G. F. Feitosa
1,2
, Rafael A. F. do Carmo
2
, Paulo de T. G. Oliveira
2
, Enyo J.
T. Gonalves
2,3
, Gustavo A. L. de Campos
2
, Jerffeson T. de Souza
2

1
Instituto Federal de Educao Cincia e Tecnologia do Cear, Campus Crato (IFCE)
Crato, CE Brasil
2
Centro de Cincias e Tecnologia Universidade Estadual do Ceara (UECE)
Laboratrio de Computao Natural e Inteligente (LACONI) Fortaleza, CE Brasil
3
Universidade Federal do Cear (UFC), Campus Quixad Quixad, CE Brasil
{robsonf,carmorafael, paulo.de.tarso}@gmail.com,
{gustavo,jeff}@larces.uece.br, enyotavares@uece.br
Resumo. Este trabalho descreve uma abordagem baseada em algoritmo
gentico para resoluo do problema de seleo de leiles CDA no cenrio do
TAC Classic. Para validar a abordagem, foi necessrio efetuar algumas
adaptaes no cenrio. Atravs da anlise dos resultados dos experimentos,
pode-se comprovar a viabilidade do uso do algoritmo gentico aplicado ao
problema de otimizao multiobjetivo descrito neste trabalho.
1. Introduo
O comrcio eletrnico, e-commerce, tem despertado grande interesse nas mais diversas
comunidades ao redor do mundo. Segundo Vytelingum (2006), os leiles do tipo
Continuous Double Auction (CDA) so, atualmente, os mecanismos de negociao mais
comuns adotados em e-commerce. Basicamente, o funcionamento de um leilo CDA
ocorre da seguinte forma: durante um intervalo de tempo pr-fixado, os participantes
submetem, de forma assncrona, ofertas de venda de bens e lances de compra; no
momento em que o valor de um lance de compra ficar maior ou igual a uma oferta de
venda, a transao realizada.
Os leiles CDA so amplamente utilizados por instituies especializadas em
compra e venda de ttulos e mercadorias, e.g. mercado de cmbio internacional e a bolsa
de valores. Ainda de acordo com Vytelingum (2006), a bolsa de valores New York Stock
Exchange (NYSE) movimenta cerca de 12,4 trilhes de dlares em transaes anuais; o
que demonstra o grau de importncia desse mercado para a economia mundial.
Mercados como o NYSE (New York Stock Exchange) negociam diversos bens
em paralelo, atravs de leiles simultneos e independentes. Dessa forma, alm dos
problemas clssicos, tais como determinao da quantidade e valor dos bens,
encontrados na negociao CDA, os participantes desse mercado devem analisar
simultaneamente a evoluo das vrias cotaes, em detrimento de suas preferncias
para escolher em quais leiles efetivamente participar. Contudo, resolver esse problema
no uma tarefa trivial, principalmente para humanos; uma vez que se trata de um
problema clssico de alocao, semelhante ao problema da mochila [Horowitz e Sahni
1974], que possui uma alta ordem de complexidade.
71

O estudo realizado por [Das et al. 2001] comprovou que agentes inteligentes
podem superar o desempenho de humanos, durante aes de negociao. Estes agentes
podem ser empregados na monitorao simultnea de vrios mercados, no
processamento de grande volume de informao e na execuo de clculos complexos
quase que instantaneamente.
Visando fomentar a pesquisa de alto nvel em agentes negociadores,
pesquisadores da Universidade de Michigan criaram o ambiente TAC (Trading Agent
Competition) [Wellman e Wurman 1999]. O TAC composto de um frum sobre o
tema de agentes negociadores e, uma srie de torneios anuais. Ele ainda fornece uma
infra-estrutura completa de software para o desenvolvimento e simulao de agentes
negociadores, o que facilita a gerao de conhecimento na rea.
O TAC Classic um dos torneios criados e disponibilizados pelo frum TAC.
Nele, os agentes desempenham o papel de agncias de viagens cujo objetivo formar
pacotes de viagens de acordo com sua carteira de clientes. Para isso, os agentes devem
comprar bens de viagens (passagens areas, dirias em hotis e ingressos de
entretenimento). Cada bem negociado em leiles de determinado tipo, que ocorrem
simultaneamente, de forma separada. Por exemplo, ingressos de entretenimento so
negociados em leiles separados, simultneos e do tipo CDA.
Este artigo descreve uma abordagem baseada em algoritmo gentico para a
seleo de leiles CDA no cenrio do TAC Classic. Para isso, o trabalho foi organizado
em mais cinco sees. A Seo 2 apresenta informaes sobre os mecanismos de
negociao do TAC Classic. A Seo 3 descreve a abordagem proposta. A Seo 4,
alguns trabalhos relacionados. A Seo 5 apresenta os primeiros resultados obtidos com
a abordagem no ambiente. Finalmente, a Seo 6 apresenta algumas concluses e
trabalhos futuros.
2. Continuos Double Auction (CDA) do TAC Classic
No TAC Classic, existem trs tipos de ingressos de entretenimento que esto
disponveis para quatro dias: Luta de Crocodilos (Aw), Parque de Diverso (AP) e
Museu (Hu). Os agentes esto livres para negociar esses ingressos entre si atravs de
leiles do tipo Continuous Double Auction. No total, 8 agentes negociam seus ingressos
em 12 leiles.
A cada dia, est disponvel um total de 8 ingressos para cada evento, totalizando
96 ingressos
1
. Cada agente recebe um conjunto inicial de 12 ingressos, que so
distribudos da seguinte forma: quatro ingressos de um evento para o dia 1 ou 4; dois
ingressos de um evento (diferente do anterior) para o dia 1 ou 4; quatro ingressos de um
evento para o dia 2 ou 3; dois ingressos de um evento (diferente do anterior) para o dia 2
ou 3.
Nos leiles do tipo CDA, os agentes submetem ofertas de compra e venda de
bens no leilo, e caso uma oferta de compra combine com uma de venda, a transao
realizada. O mecanismo que define a natureza dos lances em vlidos ou no
denominado protocolo de mercado, ou market protocol,que o protocolo onde so

1
Sendo 8 ingressos para cada um dos 3 tipos, em cada um dos 4 dias, todos os dias exceto o 5 dia
quando no ocorrem eventos; ou seja: 8 x 3 x 4 = 96.
72

definidas as regras para o processo de negociao do mercado. Nele so especificadas as
regras de visibilidade e acesso das informaes disponveis entre os participantes, bem
como a validade de uma transao e quando ela ocorre, em termos de valores para preo
e quantidade [Vytelingum 2006]. Em Oliveira (2008) pode-se encontrar a descrio do
protocolo de mercado para o CDA do TAC Classic.
Os agentes enfrentam dois problemas principais durante os 12 leiles CDA
simultneos em andamento no ambiente. Baseados nos preos correntes de compra e
venda dos ingressos (outstandigs) nos leiles e nas preferncias dos 8 clientes, os
agentes devem decidir quais leiles participar e/ou abandonar. Segundo, selecionados os
leiles para participar, a questo chave encontrada pelos agentes o problema de
determinao dos lances [Boyan e Greenwald 2001]. Este artigo apresenta uma
abordagem para o primeiro problema.
O primeiro problema pode ser visto como um problema de alocao, ou seja,
dado um conjunto de leiles que o agente pode participar; como alocar a participao do
agente de acordo com as preferncias dos cliente e de uma medida de avaliao de
desempenho especificada no cenrio TAC Classic? possvel observar que a
formalizao deste problema de alocao equivale formalizao do problema da
mochila, que possui alta complexidade [Garey e Johnson 1979].
E para mensurar o desempenho do agente, Stone e Greenwald (2000)
descreveram a seguinte funo utilidade:
utiliuaue = 1uuu - penaliuaueviagem+bonusBotel +bonusIngiesso (2.1)
Sendo a penalidadeViagem, uma funo que penaliza a alocao de passagens
em dias no correspondentes ao desejado pelo cliente; bonusHotel e bonusIngresso,
valores dados pelos clientes caso se consigam atender suas preferncias de hotis e
entretenimento.
3. A Abordagem Baseada em Algoritmo Gentico
Um problema de alocao pode ser definido formalmente como um problema de
otimizao, onde se deve maximizar ou minimizar um, ou mais objetivos, sujeito a uma
srie de restries. Para resolver o problema de seleo de leiles CDA do TAC Classic,
foi empregada uma abordagem fundamentada em uma metaheurstica gentica que
soluciona o problema de otimizao descrito a seguir.
3.1. Formalizao do problema
O problema de seleo dos leiles de entretenimento que um agente no TAC Classic
deve participar consiste na escolha dos ingressos de entretenimento que devem ser
comprados ou vendidos, com o objetivo de maximizar o lucro do agente. Para isso, os
agentes TAC precisam analisar sua carteira de clientes, e os preos de cotao para
compra e venda.
Para apoiar o processo de seleo aqui descrito, foi utilizada uma matriz com
valores histricos de preo Pr
ij
, que estimam o preo de transao
2
no leilo ij, onde i
representa o dia do entretenimento (assumindo valores inteiros no intervalo de 1 a 4); e,

2
Esse valor calculado atravs da mediana de um vetor ordenado de preos de transaes passadas.
73

j o tipo de entretenimento (assumindo valores inteiros no intervalo de 1 a 3, onde 1
equivale ao tipo AW, 2 ao tipo AP e 3 ao tipo MU).
Foram utilizados trs objetivos para conduzir o processo de seleo dos leiles.
O primeiro objetivo o Ganho
k
, que equivale ao dinheiro ganho pelo agente devido
alocao do ingresso l
Ij
k
para um cliente C
k
da sua carteira, ou seja:
uanho
k
= 1uuu + l
Ij
k
- Pimio
Ij
k
j e ]
R
(S.1)
I e Nd
R

onde, dado um conjunto de ingressos do agente T
ij
, l
Ij
k
guarda quais ingressos devem ser
alocados ao cliente C
k
, assumindo os valores 0 ou 1 que indicam, respectivamente, se o
ingresso foi ou no alocado ao cliente C
k
; e, Pimio
Ij
k
o valor pago pelo cliente C
k
,
dada a alocao ij.
O segundo objetivo o Inventrio, que corresponde estimativa do dinheiro
retido nas mos do agente devido aos ingressos ij no alocados aos clientes, ou seja:
Inventiio = T
Ij
- l
Ij
A
- Pi
Ij
3
j=1
4
I=1
(S.2)
onde l
ij
A
indica se o agente deve incrementar (1), ou no (0), o nmero de ingressos ij
para venda.
O terceiro objetivo a DespesaOperacional
k
, que equivale a estimativa do
dinheiro que o agente gastar para comprar ingressos para o cliente C
k
, ou seja.
Bespesa0peiacional
k
= l
Ij
k
- Pi
Ij
j e ]
R
(S.S)
I e Nd
R

A formulao do problema de otimizao consiste em maximizar _ uanho
k
8
k=1
;
minimizar Inventiio; e, maximizar _ Bespesa 0peiacional
k
8
k=1
; sujeito s seguintes
restries:
vk e Clientes: vi e Nu
k
: _ l
Ij
k
j e ]
R 1
vk e Clientes: vj e }
k
: _ l
Ij
k
1
I e Nd
R
vk e Clientes: vi e Nu
k
: vj e }
k
: l
Ij
k
- b
o
Ij
mximo que o agente poue pagai na compia uo ingiesso ij

vi e Nu: vj e Entietenimentos: T
Ij
- l
Ij
A
- a
o
Ij
minimo que o agente poue iecebei na venua uo(s)ingiesso(s)ij

_ _ T
Ij
-
Nc
j= 1
Nd
I=1
l
Ij
A
_ _ _ l
Ij
k
j e ]
R
I eNd
R

Nc
k=1

onde Clientes a carteira de clientes; Nu
k
equivale ao conjunto de dias que o cliente C
k

tem para entretenimento; Nd o nmero de dias disponveis para montagem de pacotes
de entretenimento; Entretenimento = {1,2,3} so os tipos de entretenimento disponveis
para os agentes; Ne o nmero de tipos de entretenimentos; J
k
o conjunto de
entretenimentos disponveis para um cliente C
k
; a
o
ij
o preo de cotao de venda no
leilo do tipo ij; b
o
ij
preo de cotao de compra no leilo do tipo ij.
74

3.2. A Soluo Proposta
Foram levados em considerao diversos pontos para a escolha do algoritmo para
resolver o problema de otimizao formulado, tais como, facilidade de utilizao,
simplicidade na representao das solues, complexidade e qualidade das solues
geradas. Portanto o algoritmo escolhido segundo estes critrios foi o algoritmo gentico,
mais especificamente, o Nondominated Sorting Genetic Algorithm II (NSGA-II) [Deb et
al. 2002].
O NSGA-II um algoritmo gentico desenvolvido para resolver problemas de
otimizao multiobjetivo. Este algoritmo tem complexidade 0(NN
2
) onde M o
nmero de objetivos e N o tamanho da populao. Alm de elitismo, o algoritmo
utiliza um operador de diversificao no-paramtrico que calcula a distncia entre
solues e escolhe as existentes que esto mais dispersas pelo Pareto-front, fazendo
com que no apenas as melhores solues permaneam na prxima gerao, mas
tambm solues diversas e distantes umas das outras.
Para o problema formulado neste trabalho, cada soluo (gene) foi codificada
como sendo um vetor ordenado, onde um conjunto de quatro alelos representa um
cliente, e cada alelo representa um possvel dia de viagem para o cliente. Cada alelo
pode assumir um valor no intervalo de inteiros entre 0 e 3, ou seja: 0 se no for alocado
ingresso; 1 se for alocado 1 ingresso do tipo AW no dia dado pela posio do alelo no
conjunto de cada cliente; 2 se for alocado 1 ingresso do tipo AM; e 3 caso seja alocado
1 ingresso do tipo MU.
Os valores assumidos pelos alelos equivalem ao valor do ndice j, da estrutura de
trs dimenses l
ij
k
, descrita na formalizao do problema. Ou seja, quando l
ij
k
igual a
0, o alelo de posio (t + ((h -1) 4) ) recebe o valor 0; e, quando l
ij
k
igual a 1, o
alelo de posio (t + ((h -1) 4) ) recebe o valor j.
A Figura 1 apresenta parte de um gene descrito de acordo com o esquema
elaborado. Nela o cliente C1 chega cidade no dia 1 e retorna no dia 4, portanto so
alocados tickets para ele nos dias 1 a 3 (no necessariamente em todos). J o cliente C2
permanece os 5 dias na cidade e o cliente C8 chega no dia 2 e retorna no dia 5.

Figura 1. Exemplo de gene de uma soluo vlida
Desta forma, as operaes de mutao e reproduo podem ser executadas de
uma maneira simples pelo algoritmo gentico utilizado. A mutao troca os valores de
um alelo qualquer por outro valor dentro dos possveis [0..3], respeitando as restries;
e, a reproduo se faz atravs de operaes simples que dividem os genes em dois
pedaos e os combinam em ordem aleatria.
Kehagias et al. (2006) descreveu a estratgia adotada pelo agente Mertacor em
mercados CDA. Park e Birmingham (2004) levantam uma srie de questionamentos,
visando o projeto e implementao de agentes para CDA. Eles descrevem uma
estratgia denominada P-Strategy, que utiliza a tcnica de cadeias de Markov para
75

simular o comportamento de outros agentes e estimar o andamento do processo de
negociao. J trabalhos como o Schvartzman (2009) demonstram a viabilidade de
utilizao de estratgias apoiadas em teoria dos jogos mais aprendizado por reforo.
He et al. (2003) descrevem o uso de um controlador Fuzzy, com mecanismo de
inferncia Sugeno na deciso dos valores de novos lances. Para isso, foram utilizados
como entrada do controlador a estimativa de um preo de equilbrio, bem como os
valores de cotao. A calibrao de alguns parmetros do controlador feita
dinamicamente, de acordo com a anlise da estimativa de demanda e suprimento no
mercado.
Oliveira (2008) adaptou a abordagem descrita em [He et al. 2003], para o
processo de negociao CDA do TAC Classic. Ele realizou um estudo comparativo
entre os mecanismos de inferncia Sugeno e Mandami utilizados no controlador
nebuloso do agente. Neste trabalho, no foi utilizado nenhum mecanismo de seleo
para a escolha de qual leilo participar, o que fazia com que o agente participasse de
todos os leiles, inclusive, os que ele no tinha interesse.
Vytelingum (2006) fez um apanhado sobre os aspectos comportamentais e
estruturais do CDA. Ele avaliou estratgias de CDA bem conhecidas como: Kaplan,
Zero-Intelligence e Gjerstad-Dickhaut e props uma estratgia denominada Adaptive-
Aggressiveness Bidding Strategy.
Nos trabalhos relacionados a agentes TAC, observa-se o uso de diversas tcnicas
para a seleo de leiles dependentes, que vo desde programao inteira busca A*
[Oliveira e Si 2006]. Contudo, no se observa nenhuma abordagem utilizada,
especificamente, para a seleo de leiles do tipo CDA, haja vista, que as estratgias
dos mesmos estavam intrinsecamente relacionadas dependncia entre os leiles.
Segundo Ribeiro et al. (2007) pesquisadores utilizam-se de uma variedade de
modelos de otimizao multiperodo, incluindo otimizao estocstica, para desenvolver
um modelo dinmico de alocao tima de ativos. Entretanto, a complexidade destes
modelos e o grande esforo computacional que demandam, acabam por desestimular
seu uso na prtica dos profissionais da rea financeira. Ele, ainda, descreve a escolha
da carteira tima de investimento segundo um modelo que representa um problema de
otimizao estocstica. Para resolver o problema foram utilizados tcnicas de gerao
de rvores de cenrios na modelagem de incertezas, transformando o problema em um
problema determinstico.
Outras abordagens utilizam tcnicas de otimizao para a seleo de carteira de
investimento, dentre elas, Ko e Li (2008) empregaram redes neurais; Gupta et al. (2008)
empregaram lgica Fuzzy; e Lin e Liu (2008) empregaram um algoritmo gentico
aplicado ao problema de otimizao que foi descrito.
5. Estudo de Caso
Para validar a abordagem, foi utilizada uma verso modificada do ambiente TAC
Classic, para que seja analisado o desempenho do agente apenas em leiles do tipo
CDA. Foi realizado um isolamento dos leiles CDA de entretenimento com o objetivo
de diminuir o nmero de variveis aplicadas ao problema principal do agente.
76

5.1. Metodologia
Oliveira (2008) criou um mtodo de avaliao emprico para agentes em leiles do tipo
CDA. O medo consiste em: (1) alterar o servidor TAC Classic, isolando os leiles de
entretenimento, dos demais leiles; (2) selecionar um conjunto de agentes competitivos;
(3) iniciar uma bateria de jogos
3
, configurando os agentes para participarem de um
determinado nmero de jogos; (4) ao final de cada bateria analisar os logs do servidor
para recuperar a quantidade de itens comprados e vendidos por cada agente, bem como
a quantidade de lances enviados por cada agente, a mdia da pontuao final e a
colocao de cada agente ao final de cada bateria de testes.
Ao todo, quatro agentes foram selecionados: Mertacor, SICS02, UTTA06 e
DummyAgent. Destes, exceto o agente exemplo, todos foram finalistas da competio
TAC Classic 2006. Alm disso, SICS02 e Mertacor tambm foram finalistas em 2005,
ano em que este ltimo foi o campeo do evento. Todos esses agentes esto disponveis
no site do torneio (http://www.sics.se/tac).
Como o objetivo deste trabalho foi avaliar o impacto da utilizao do algoritmo
gentico ao problema j descrito, foi necessrio incorporar ao mtodo critrios de
comparao entre a estratgia com uso do algoritmo gentico e a estratgia sem a
utilizao da heurstica. Dessa forma, a anlise dos logs foi realizada para recuperar a
mxima pontuao possvel de cada agente, conforme descrito posteriormente; bem
como a pontuao final obtida por cada agente (Equao 2.1), ao final de cada jogo.
5.2. Resultados
O agente que utiliza o mecanismo de seleo de leiles foi denominado LaconiBot, j o
agente que utiliza as mesmas estratgias de negociao, exceto, o mecanismo de seleo
de leiles denominado DealerBot. Ou seja, o LaconiBot uma verso estendida do
DealerBot, com o acrscimo do mecanismo de seleo de leiles. Mais informaes
sobre o DealerBot podem ser encontradas em Oliveira (2008). Os resultados da anlise
dos logs so ilustrados nas tabelas 1, 2, 3 e 4 a seguir.
Tabela 1. Pontuao e classificao para todos agentes para 10, 20 e 40 jogos
Position
10 jogos 20 jogos 40 jogos
Agent Avg Score Agent Avg Score Agent Avg Score
1 Mertacor 9439.83 Mertacor 9523.81 Mertacor 9464.17
2 DealerBot 9359.04 LaconiBot 9297.71 LaconiBot 9335.94
3 DummyAgent 9296.10 UTTA06 9249.29 DealerBot 9304.02
4 LaconiBot 9255.68 DealerBot 9212.94 UTTA06 9213.16
5 UTTA06 9109.38 DummyAgent 9203.76 DummyAgent 9198.56
6 SICS02 8324.38 SICS02 8436.60 SICS02 8356.05
Tabela 2. Pontuao e classificao da simulao Laconi Vs DealerBot
Position
1 DealerBot 9227.62 LaconiBot 9323.60 LaconiBot 9306.47
2 LaconiBot 9222.67 DealerBot 9266.86 DummyAgent 9195.24
3 DummyAgent 9205.44 UTTA06 9234.72 DealerBot 9193.67
4 UTTA06 9203.37 DummyAgent 9201.69 UTTA06 9187.97
5 SICS02 8256.07 SICS02 8239.37 SICS02 8478.62

3
Um jogo corresponde ao perodo de funcionamento do CDA, para o TAC equivale a 9 minutos. A cada novo jogo, os agentes
recebem uma nova carteira de preferncias dos seus clientes.
77

Tabela 3. Pontuao e classificao da simulao Laconi Vs Mertacor
Position
1 Mertacor 9460.43 Mertacor 9562.20 Mertacor 9469.79
2 LaconiBot 9372.86 LaconiBot 9321.54 LaconiBot 9254.27
3 UTTA06 9249.43 UTTA06 9298.85 DummyAgent 9222.63
4 DummyAgent 9230.95 DummyAgent 9233.11 UTTA06 9180.90
5 SICS02 8234.58 SICS02 8337.40 SICS02 8356.34

Tabela 4. Pontuao e classificao da simulao DealerBot Vs Mertacor
Position
1 DealerBot 9347.63 Mertacor 9518.15 Mertacor 9558.85
2 Mertacor 9316.15 SICS02 9368.68 DealerBot 9345.54
3 UTTA06 9234.74 DealerBot 9325.48 UTTA06 9237.42
4 SICS02 9169.22 DummyAgent 9255.28 DummyAgent 9205.06
5 DummyAgent 9143.40 UTTA06 9128.85 SICS02 9189.23

Para a anlise do desempenho da abordagem foram escolhidos 2 parmetros:
percentual do timo
4
obtido por cada agente ao final das baterias de teste; e, colocao
final dos agentes para cada bateria de teste. Os grficos nas s abaixo sintetizam alguns
destes resultados.

Figura 2. Percentual do timo nas simulaes com os agentes

4
A pontuao mxima, ou tima, de cada agente pode ser calculada como o somatrio do retorno
mximo da funo utilidade (2.1) para todos seus clientes, somada da venda dos bens sobressalentes pelo
valor mximo de $200.0 e a compra de bens faltosos por $0.0.
78

A anlise dos resultados, no que diz respeito aos parmetros utilizados, conduz
s seguintes concluses:
1. Analisando os grficos da Figura 2, percebe-se que a abordagem de seleo de
leiles (LaconiBot) aumentou o percentual do timo obtido pelo agente, quando
comparado com o desempenho do agente que no possui estratgia de seleo de
leiles (DealerBot).
2. A anlise da Tabela 1 e Tabela 2 revela que houve uma melhora na pontuao
final do agente que utiliza a abordagem descrita neste trabalho (LaconiBot)
quando comparado com o agente que no a utiliza (DealerBot). Tendo em vista
que LaconiBot ficou a frente do DealerBot, em quatro das seis baterias de jogos,
onde ambos agentes participavam. J comparando a Tabela 3 com a Tabela 4,
percebe-se que a estratgia do agente LaconiBot se mostra mais estvel que a do
DealerBot, pois no houve mudanas bruscas de posies, uma vez que ele
permaneceu na 2 posio durante as 3 baterias de jogos. J o DealerBot oscilou
da 1 3 posio durante a mesma quantidade de jogos.
6. Concluses e Trabalhos Futuros
A pesquisa em comrcio eletrnico, agentes negociadores e estratgias de negociao
em ambientes CDA tm sido impulsionada por pesquisadores no mundo inteiro atravs
do uso de tcnicas estatsticas e de inteligncia artificial. Como contribuio, o presente
trabalho provou empiricamente que a abordagem aqui descrita para a seleo de leiles
CDA, aplicada ao cenrio do TAC, mostrou-se vivel, trazendo reais benefcios ao
desempenho de um agente negociador. Futuramente, pretende-se comparar o
desempenho de outras metaheuristicas aplicadas ao mesmo cenrio. Pretende-se
tambm generalizar a abordagem descrita para apoiar a seleo de leiles em qualquer
cenrio CDA e apoiar a seleo de leiles em mercados que se utilizem de outros
mecanismos de negociao; bem como, fornecer um framework completo para apoiar o
desenvolvimento de estratgias para a seleo de leiles nos mais diversos cenrios de
comrcio eletrnico.
Referncias
Boyan, J. and Greenwald, A. (2001) Bid determination in simultaneous actions an
agent architecture. Proceedings of the 3rd ACM conference on Electronic
Commerce. ACM New York, NY, USA.
Das, R.; Hanson, J.E.; Kephart, J.O.; Tesauro, G. (2001) Agent-Human Interactions in
the Continuous Double Auction. Proceedings of the Seventeenth International Joint
Conference on Artificial Intelligence. Washington: B. Nebel, Vol.17, No.1, pp. 1169-
1178.
Deb, K.; Pratap D.; Agarwal, S.; Meyarivan, T. (2002) A Fast and Elitist
Multiobjective Genetic Algorithm: NSGA-II. IEEE Transactions on Evolutionary
Computation. Vol.6, No.2, pp. 182-197.
Garey, M. R. and Johnson, D. S. (1979) Computers and Intractability: A Guide to the
Theory of NP-completeness. W.H. Freeman and Comp., San Francisco.
Gupta P.; Mehlawat, M. K.; Saxena A. (2008) Asset portfolio optimization using fuzzy
mathematical programming. Information Sciences. Vol.178, No.6,pp.1734-1755.
79

He, M.; Leung, H. F.; Jennings, N. R. (2003) A Fuzzy Logic Based Bidding Strategy
for Autonomous Agents in Continuous Double Auctions. IEEE Trans on
Knowledge and Data Engineering. pp.1345-1363.
Horowitz, E. and Sahni, S. (1974) Computing partitions with applications to the
Knapsack problem. Journal of ACM, 21. pp.277 292.
Kehagias, D.; Toulis, P.; Mitkas, P. (2006) A Long-Term Profit Seeking Strategy for
Continuous Double Auctions in a Trading Agent Competition. Advances in
Artificial Intelligence. Vol. 3955/2006. Springer Berlin / Heidelberg. pp.116-126.
Ko, Po-Chang and Lin, Ping-Chen (2008) Resource allocation neural network in
portfolio selection. Expert Systems with Applications, Vol.35, pp.330-337.
Lin, Chang-Chun and Liu, Yi-Ting (2008) Genetic algorithms for portfolio selection
problems with minimum transaction lots. European Journal of Operational
Research. Vol. 185, No.1,pp.393-404.
Martello, S. and Toth, P. (1990) Knapsack Problems: Algorithms and Computer
Implementations. JohnWiley & Sons, New York.
Oliveira, F. and Si, Y.W. (2006) Strategic Issues in Trading Agent Competition: TAC-
Classic. Proceedings of the 2006 IEEE/WIC/ACM international conference on Web
Intelligence and Intelligent Agent Technology. Pp518-522.
Oliveira, P. T. G. (2008) Uma Abordagem Fuzzy para o Mercado de Entretenimento
da Trading Agent Competition. Monografia - Universidade Estadual do Cear,
Fortaleza, Julho 2008.
Park, E. D. and Birmingham, W. (2004) Use of Markov Chains to Design an Agent
Bidding Strategy for Continuous Double Agents. Journal of Artificial Intelligence
Research. pp.175214.
Ribeiro, C. O.; Sosnoski, A. A. K. B.; Russi, B. (2007) Otimizao Multiperodo de
Carteiras de Investimento utilizando a tcnica de Gerao de rvores de Cenrios.
ENEGEP, 2007, Foz do Iguau.
Schvartzman, L. J. and Wellman, M. P. (2009) "Stronger CDA strategies through
empirical game-theoretic analysis and reinforcement learning", AAMAS '09:
Proceedings of The 8th International Conference on Autonomous Agents and
Multiagent Systems, International Foundation for Autonomous Agents and
Multiagent Systems, 249-256.
Stone, P.; Greenwald, A. (2000) The first international trading agent competition:
Autonomous bidding agents. Electronic Commerce Research (Springer) 5: 229-265.
Vytelingum, P. (2006) The Structure and Behaviour of the Continuous Double
Auction. PhD, School of Electronics and Computer Science, University of
Southampton.
Wellman, M. and Wurman, P. (1999) A trading agent competition for the research
community, IJCAI-99 Workshop on Agent-Mediated Electronic Commerce,
Stockholm.
80

Adaptao de Agentes de Software ao Contexto com o uso
de Aspectos
i

Ana Paula Lemke e Marcelo Blois Ribeiro
Faculdade de Informtica Pontifcia Universidade Catlica do Rio Grande do Sul
Av. Ipiranga, 6681 90619-900 Porto Alegre, RS Brasil
{ana.lemke, marcelo.blois}@pucrs.br
Abstract. Agent technology is increasingly seen as an attractive approach to
develop applications for pervasive environments. However, many existing
agent platforms support only the development of agents able to deal with a
limited set of situations. The difficulty of writing software for pervasive
environments comes from the fact the developer cannot anticipate all the
circumstances in which the application will be used, and predict all necessary
decisions at design time. Considering this issue, this paper introduces an
application composed of context adaptive agents in Stock Market domain. One
of the characteristics of the application is the separation between adaptive and
non-adaptive (default) agent behaviors. A generic architecture will be defined
based on the presented application.
Resumo. A tecnologia de agentes cada vez mais citada para o
desenvolvimento de aplicaes em ambientes pervasivos. No entanto, a
maioria das plataformas disponveis apia apenas a criao de agentes capazes
de lidar com um conjunto limitado de situaes. A dificuldade de produzir
software para ambientes pervasivos vem justamente do fato de o projetista no
poder prever todas as circunstncias em que a aplicao ser usada, e tomar
todas as decises em tempo de projeto. Considerando essa necessidade, este
artigo apresentar o desenvolvimento de uma aplicao composta de agentes
adaptativos ao contexto no domnio da Bolsa de Valores. Uma das
caractersticas da aplicao a separao do comportamento adaptativo do
comportamento padro dos agentes. Uma arquitetura genrica ser definida
com base na aplicao desenvolvida.
1. Introduo
Em Cincia da Computao, a utilizao da noo de contexto no desenvolvimento de
aplicaes conscientes de contexto consideravelmente recente - o termo est vinculado
rea desde a dcada de 90 - e geralmente remete a pesquisadores que trabalham com
computao pervasiva e ubqua. Embora a utilizao da noo de contexto seja recente,
a adaptao de aplicaes ao contexto j estudada h muitos anos em outras reas da
Cincia da Computao, como em Sistemas Multiagentes (SMAs). SMAs geralmente
so considerados complexos em relao a sua estrutura e funcionalidade [WEI96]. Em

i
Estudo desenvolvido pelo Intelligent Systems Engineering Group da PUCRS, financiado pela Dell Computadores
do Brasil Ltda. com recursos da Lei 8.248/91 e pelo Conselho Nacional de Desenvolvimento Cientfico e
Tecnolgico CNPq.
81

muitas aplicaes, at mesmo naquelas em que o ambiente parece extremamente
simples, difcil ou mesmo impossvel, determinar corretamente, em tempo de projeto,
os possveis comportamentos e atividades realizados pelos SMAs [WEI96, GUN08].
Diferentemente dos programas tradicionais, agentes de software operam em
ambientes que so muitas vezes percebidos de forma parcial e que mudam
constantemente [SIM08], o que evidencia a necessidade de aprendizado e/ou adaptao.
Segundo Gunasekera et al. [GUN09], a presena de um grande nmero de agentes, o
aumento de complexidade de seus comportamentos, a observao parcial do ambiente e
a adaptao simultnea de comportamentos em mltiplas entidades fazem do processo
de aprendizagem em agentes ainda hoje um desafio.
A definio e o uso de contexto um aspecto importante em se tratando de
aprendizagem e adaptao. Na literatura, solues tm sido propostas para facilitar o uso
de contexto e aumentar o desenvolvimento de aplicaes baseadas em contexto. Em
geral, o foco tem sido considerar situaes pr-definidas e mtodos de representao
diretos como meio para desenvolver as aplicaes (como j indicado em [KHE05]).
Atualmente, no h uma forma difundida e aceita para representar o contexto e tambm
no existem mtodos adequados para raciocnio sensvel ao contexto [GON07].
Permitir aos agentes analisar o contexto em que esto inseridos, mudando seus
comportamentos quando necessrio, possibilita que essas entidades utilizem de fato a
sua habilidade de adaptao. Assim, este artigo apresenta o desenvolvimento de uma
aplicao composta de agentes adaptativos ao contexto no domnio da Bolsa de Valores.
Uma das caractersticas da aplicao desenvolvida a separao do comportamento
adaptativo do comportamento padro dos agentes. Com base na aplicao desenvolvida
pretende-se definir uma arquitetura genrica.
O restante deste artigo est organizado da seguinte forma: a Seo 2 discorre
sobre conceitos e trabalhos relacionados a agentes adaptativos ao contexto; a Seo 3
descreve as principais caractersticas da aplicao desenvolvida; e, por fim, na Seo 4
so apresentadas as consideraes finais.
2. Agentes Adaptativos ao Contexto
2.1. Definies Gerais
Contexto qualquer informao relevante execuo de uma entidade que pode ser
utilizada para descrever o seu estado interno ou o ambiente em que a entidade est
inserida (adaptao da definio apresentada em [DEY99]).
Sistemas adaptativos ao contexto so sistemas baseados em computador capazes de
reconhecer mudanas no domnio em que esto inseridos (domnios com os quais
compartilham interfaces) e, ao mesmo tempo, capazes de modificar seus
comportamentos para se adaptar as novas condies sem a necessidade de interao
direta com o usurio [SIT07].
Agentes adaptativos inteligentes so sistemas ou mquinas que utilizam
metodologias computacionais complexas ou baseadas em inferncia para modificar
ou transformar parmetros de controle, bases de conhecimento, metodologias para a
resoluo de problemas, o curso de ao, ou qualquer outro objeto de forma a efetuar
satisfatoriamente um conjunto de tarefas que so de interesse do usurio [IMA04].
82

2.2. Infra-estrutura para o desenvolvimento de Agentes Adaptativos ao Contexto
McKinley e co-autores [MCK04] indicam que h duas maneiras de implementar
adaptao de software, que so a adaptao composicional e a parametrizada. Na
abordagem composicional, as aplicaes so capazes de se reconfigurar dinamicamente,
em tempo de execuo, para se adequar ao ambiente corrente. So exemplos de
adaptao composicional as abordagens propostas em [AMO09, GUN08, HAN07]. A
adaptao parametrizada permite a modificao de variveis do programa que
determinam seu comportamento. Assim, possvel modificar parmetros de forma a
adotar diferentes estratgias pr-definidas, mas no possvel adotar estratgias no
conhecidas a priori [MCK04]. Exemplos de abordagens baseadas em adaptao
parametrizada podem ser encontrados em [SIM08, LER03, RAM03].
A Tabela 1 sumariza as principais caractersticas dos trabalhos citados (as
caractersticas no citadas nos artigos esto com o smbolo -). Os aspectos utilizados
para comparar os trabalhos foram identificados durante a execuo de uma reviso na
literatura. De fato, esses aspectos poderiam ser reescritos e interpretados como
requisitos que deveriam ser contemplados pelas propostas. Como pode ser observado na
tabela, so poucos os trabalhos que citam a verificao das adaptaes realizadas e que
utilizam um meta-modelo para classificar as informaes contextuais. Tambm, o
comportamento adaptativo de grande parte das propostas realizado no nvel de seleo
de entidades definidas em tempo de projeto. Por ltimo, apenas Amor e Fuentes
[AMO09] disponibilizam uma ferramenta para uso. No entanto, a ferramenta
disponibilizada por eles no poderia ser utilizada para apoiar no desenvolvimento da
aplicao que est sendo apresentada neste artigo. Na proposta dos autores, o contexto
representado pelos componentes e aspectos ativos no agente e as nicas adaptaes
possveis so sobre o mecanismo para a codificao de mensagens.
A ltima linha da Tabela 1 antecipa as principais caractersticas que devero ser
apresentadas pela arquitetura genrica que ser desenvolvida com base na aplicao
descrita neste artigo (a arquitetura simplificada, desenvolvida juntamente com a
aplicao, j apresenta algumas dessas caractersticas, conforme ser descrito na
prxima seo). De maneira geral, o objetivo da pesquisa propor uma arquitetura para
o desenvolvimento de agentes de software adaptativos ao contexto que possibilite a
verificao da satisfao atingida com as adaptaes realizadas. O escopo de adaptao
compreender, principalmente, os planos de ao e as aes dos agentes.
Tabela 1. Sumarizao das caractersticas dos trabalhos citados.

Fonte
Tipo de
soluo
Avaliao da
adaptao
Soluo
genrica
Contexto Escopo da adaptao Ferramenta
P
a
r
a
m
e
t
r
i
z
a
d
a
s

[LER03]
Mecanismo /
algoritmo
- -
Memrias
passadas
Execuo de aes No
[SIM08]
Linguagem de
programao
Sim Sim
Eventos
ocorridos na
execuo
Execuo de aes No
[RAN03] Middleware Sim (humana) Sim Genrico Execuo de aes -
C
o
m
p
o
s
i
c
i
o
n
a
i
s

[GUN08] Arquitetura - Sim -
Adio de capabilities /
Migrao de agentes
No
[HAN07] Plataforma Sim (humana) Sim -
Adio e remoo de
componentes
No
[AMO09] Arquitetura - Sim
Componentes e
aspectos ativos
Codificao de
mensagens
Sim
Soluo
proposta
Arquitetura Sim Sim Genrico Plano de ao e aes Sim
83

3. Desenvolvendo Agentes Adaptativos ao Contexto com Aspectos
Mesmo que as informaes sobre o contexto j possam estar disponveis s aplicaes,
ainda no se sabe ao certo qual o impacto que elas exercem sobre os sistemas. Ento, em
busca de uma arquitetura genrica (que possa ser utilizada no desenvolvimento de
aplicaes em diferentes domnios e cientes de diferentes informaes contextuais), nas
prximas sees ser descrito o desenvolvimento de uma aplicao composta por
agentes adaptativos ao contexto no domnio da Bolsa de Valores. Uma das
caractersticas da arquitetura da aplicao a separao do comportamento adaptativo
do comportamento padro dos agentes. Para tanto, foi utilizada programao orientada a
aspectos. Ento, antes de se falar da aplicao propriamente dita, sero feitas algumas
consideraes sobre o uso dessa tecnologia no desenvolvimento de aplicaes
adaptativas ao contexto.
3.1. Utilizao de Aspectos em Aplicaes Adaptativas ao Contexto
Dey e colaboradores [DEY01] indicam que a separao de interesses um dos
requisitos que um framework para lidar com contexto deve contemplar. A separao de
interesses indicada por eles refere-se aquisio e ao uso do contexto. Na literatura de
agentes, ainda no h uma definio geral de quais so os interesses transversais que
devem ser modelados como aspectos. Segundo Amor e Fuentes [AMO09], ()
identifying crosscutting concerns specific to agents is still an open issue. Para eles, as
propriedades de comunicao tipicamente cortam diferentes mdulos da arquitetura
dos agentes e, portanto, caracterizam os interesses transversais. J Garcia e Lucena
[GAR08] consideram como interesses transversais caractersticas de agncia, como
interao, adaptao, autonomia, colaborao, aprendizagem e mobilidade.
Neste trabalho, como se pretende adaptar o comportamento dos agentes em
decorrncia de mudanas em seus contextos, os interesses transversais so mais
relacionados s informaes contextuais do que aos componentes do agente. Entretanto,
modificaes nos comportamentos podero resultar em adaptaes em outras estruturas
do agente, ou seja, para que o agente consiga executar um comportamento adaptado
pode ser necessrio, por exemplo, interceptar o recebimento de certas mensagens. Ento,
o comportamento do agente poderia ser considerado, tambm, um interesse transversal.
H algumas questes que ainda limitam o uso da programao orientada a
aspectos para o desenvolvimento de aplicaes adaptativas ao contexto. De acordo com
Grassi e Sindico [GRA07], abordagens orientadas a aspectos propem solues para
lidar com conscincia de contexto no nvel de cdigo-fonte, sem considerar o nvel de
projeto mais abstrato. J em [SIN08] criticado o restrito conjunto de eventos no fluxo
de execuo de uma aplicao que so considerados como pontos de juno (locais onde
h interceptao e possivelmente insero de comportamentos adaptativos). Outros
problemas so decorrentes do tipo de weaving (mecanismo que tece os aspectos aos
componentes da aplicao) utilizado na soluo proposta.
Mesmo apresentando algumas limitaes, a programao orientada a aspectos
parece ser apropriada para o desenvolvimento de aplicaes adaptativas ao contexto.
Alguns dos benefcios obtidos com o seu uso so a modularizao da soluo e a
separao dos interesses de adaptao do restante do comportamento funcional da
aplicao, simplificando seu desenvolvimento e manuteno.
84

3.2. Elementos bsicos da arquitetura
A Figura 1 ilustra os principais elementos da arquitetura da aplicao desenvolvida. Para
que os agentes tivessem cincia do contexto no qual estavam inseridos, foi necessrio
fornecer uma infra-estrutura para o gerenciamento do contexto. Na arquitetura definida,
trs tipos de agentes so responsveis pela coleta, processamento e distribuio das
informaes contextuais. Agentes do tipo Information Source Monitor so responsveis
por capturar informaes contextuais de diferentes sensores de hardware ou software.
Como exemplos de informaes contextuais citam-se: a temperatura de uma sala, a
posio de uma pessoa e a variao do cmbio do dlar. H um agente monitor
associado a cada fonte de informao contextual.
As variaes no contexto percebidas pelos agentes monitores so sinalizadas aos
agentes gerenciadores de contexto (Context Manager), que ento as redirecionam para
agentes do tipo Context Interpreter para interpretao. A idia de utilizar interpretadores
de contexto no nova. Dey e co-autores, em [DEY01], j indicam que retirando a
interpretao do contexto das aplicaes possvel reutilizar os interpretadores em
mltiplas situaes. Uma aplicao deve ter ao menos um agente do tipo Context
Manager, que pode estar vinculado a vrios agentes responsveis por interpretar o
contexto. As informaes interpretadas so utilizadas pelos agentes gerenciadores de
contexto para construir o contexto atual de um agente cliente. o agente cliente (ou
Context Adaptive Agent) quem possui um contexto e alvo de adaptaes.

Figura 1. Principais elementos da arquitetura da aplicao desenvolvida.
Para observar o contexto corrente e sinalizar qualquer necessidade de adaptao,
um agente cliente possui adaptadores (ou Adaptors). Diferentes mecanismos reativos ou
adaptativos podem ser utilizados para analisar o contexto, como: mecanismos baseados
em regras, raciocnio baseado em casos, algoritmos para aprendizado de mquina, entre
outros. Os aspectos de adaptao (Adaptation Aspects) indicam o que fazer quando
atingido determinado contexto ou, em outras palavras, o que deve ser modificado no
caso de um contexto favorvel a adaptao (fato que sinalizado por um adaptador). Os
aspectos de adaptao tambm so encapsulados pelo agente. Alm de informaes
contextuais, os pontos de atuao dos aspectos de adaptao podem ser compostos por
qualquer outro ponto de juno relacionado estrutura ou execuo do agente. Desta
forma, um agente pode se adaptar com base em seu contexto e em eventos internos
ocorridos em sua arquitetura.
85

3.3. Exemplo de uso: Agentes Adaptativos ao Contexto na Bolsa de Valores
A Figura 2 apresenta o diagrama de classes da aplicao desenvolvida em Java e
AspectJ (devido ao tamanho do modelo, foram omitidos os mtodos concretos do tipo
get, set, add e remove). Muito embora parea contraditrio defender o uso de weaving
em tempo de execuo e propor a utilizao da AspectJ (linguagem conhecida,
principalmente, pela utilizao de weaving em tempo de compilao), na documentao
da linguagem (verso 5) dito que, apesar de no haver suporte explcito para weaving
em tempo de execuo, utilizando-se padres de codificao possvel habilitar e
desabilitar dinamicamente as sugestes.
Para a criao dos agentes, foi utilizada a infra-estrutura provida pelo framework
SemantiCore [BLO07]. O SemantiCore um framework desenvolvido em Java que
dispe de primitivas para a criao de aplicaes baseadas em agentes. Todos os agentes
da aplicao so especializaes da classe SemanticAgent (as classes especializadas
esto sinalizadas com o esteretipo SemanticAgent na Figura 2).
A classe BrokerAgent representa o agente que possui o objetivo de vender
aes em um intervalo de tempo pr-estabelecido (as aes devem ser negociadas antes
do fechamento das negociaes no dia em que o objetivo inicializado). Para alcanar o
objetivo, o agente utiliza um plano de ao chamado Vender Aes, representado pelo
mtodo sellStock da classe BrokerAgent. Os demais mtodos da classe (ou as
outras aes do plano) so invocados dentro do mtodo sellStock. No mtodo
verifyBestTimeToSell verificado continuamente o melhor momento para a venda
das aes. A maneira padro de fazer essa avaliao baseada no cruzamento de duas
mdias mveis exponenciais, uma curta (6 perodos) e outra longa (12 perodos).
Um sistema de mdias mveis duplas utilizado para identificar tendncias e
verificar posies de compra e venda de aes. Nesses sistemas, a mdia mvel mais
longa utilizada para indicar a tendncia e a mdia mvel mais curta para identificar os
pontos de entrada [ELD06]. Quando a mdia mvel de curto perodo cruza a mdia
mvel de longo perodo para cima, considera-se tendncia de alta (bom momento para
comprar aes). J se a mdia mvel de curto perodo cruza a mdia mvel de longo
perodo para baixo, um sinal de sada (ou momento de vender aes). Assim, o agente
BrokerAgent aguarda o cruzamento das mdias mveis exponenciais para ofertar as
aes no mercado e realizar a venda.
Como mdias mveis com perodos curtos so mais suscetveis as variaes do
mercado [ELD06], a estratgia padro utilizada pelo agente BrokerAgent consiste em
vender as aes a qualquer sinal de queda. At aqui, no h qualquer adaptao do
agente ao contexto. Porm, quando o mercado est otimista, poderia ser utilizada uma
estratgia menos conservadora, com mdias mveis de perodo maior (que so menos
suscetveis a pequenas oscilaes), como as de perodo 12 e 24. Desta forma, a venda
das aes poderia ser postergada e os lucros ampliados, uma vez que em um contexto
otimista, possvel que a ao se valorize ao longo do dia.
Vrios fatores externos, como o valor do dlar americano, podem influenciar na
cotao de uma ao e indicar o humor do mercado. No geral, o preo do dlar e o
ndice Bovespa (principal indicador do mercado de aes brasileiro) caminham em
sentidos opostos na imensa maioria das vezes. Assim, quando a cotao do dlar cai,
geralmente o preo das aes valorizado e vice-versa. Para acompanhar a cotao do
86

dlar, foi criado o agente DollarIS (especializao de InformationSource) que
utiliza a pgina da ADVFN (http://br.advfn.com/p.php)

como fonte de informao. O
agente DollarInterpreter (especializao de ContextInterpreter)
responsvel por interpretar as informaes percebidas por um agente do tipo DollarIS.

Figura 2. Implementao do exemplo de uso.
A adaptao realizada no agente BrokerAgent consiste em substituir, sempre
que o contexto se mostra favorvel (cotao do dlar em baixa), o corpo do mtodo
verifyBestTimeToSell por um cdigo que utiliza mdias mveis com perodos 12 e
24. Para viabilizar a troca de estratgias, foram definidos um adaptador e um aspecto de
adaptao. A implementao do mtodo verifyChanges da classe DollarAdaptor
bastante simples: feita uma verificao de strings para verificar se o dlar est ou no
em baixa. O resultado da verificao armazenado na tabela contexts (classe
Adaptor) para ser utilizado nos pontos de atuao do aspecto
OptimisticContextAspect (especializao do aspecto abstrato
AdaptationAspect), como indica o cdigo a seguir.
1 aspect OptimisticContextAspect extends AdaptationAspect {
2 pointcut modifyEMA(ContextAdaptiveAgent ca):
3 call(boolean BrokerAgent.verifyBestTimeToSell(..))&&
4 target (ca) &&
5 if (Adaptor.applicationHasContext(ca, "Dollar")) &&
6 if (Adaptor.verifyApplicationContext(ca, "Dollar"));
7 boolean around (ContextAdaptiveAgent ca): modifyEMA (ca)
8 {
9 // verificao dos cruzamentos das mdias mveis 12 e 24
10 }
87

Como pode ser visto na linha 3, a adaptao ocorre no momento da invocao do
mtodo verifyBestTimeToSell. As demais clusulas do ponto de atuao so
relacionadas verificao do contexto corrente do agente. Primeiro, verificado se o
agente que invocou o mtodo possui em seu contexto informaes referentes ao dlar
(linha 5). Depois, na linha 6, verificado se o contexto est favorvel para a adaptao.
Para exemplificar o comportamento de um objeto da classe BrokerAgent em
execuo, vamos considerar que o mtodo sellStock do agente Broker1 foi
invocado por seu usurio por volta das 11h00min do dia 11 de maro de 2010 e que as
aes que se desejava vender eram da Petrobrs (PETR4). Como o cenrio era favorvel
para adaptao nesse dia (a cotao do dlar abriu negativa com variao de -0,1416%
no fechamento), foi utilizado um sistema de mdias mveis com perodos 12 e 24 para
identificar o melhor horrio para a venda das aes.
A Figura 3 mostra os sistemas de mdias mveis duplas criados com as
informaes da ao PETR4 no dia 11 de maro de 2010. Como pode ser visto na
Figura 3.a, utilizando-se um sistema de mdias com perodos 6-12 a venda ocorreria por
volta de 11h40min, sendo que as aes seriam negociadas por aproximadamente R$
37,00. Com a adaptao, o agente venderia as aes por volta das 13h03min por um
preo de aproximadamente R$ 37,31 por ao (Figura 3.b). A Figura 3.c apresenta a
interface desenvolvida para o acompanhamento da execuo do plano sellStock.

Figura 3. (a) Mdias mveis de perodos 6-12. (b) Mdias Mveis de perodos
12-24. (c) Interface para o acompanhamento da execuo do plano Sell Stock.
88

O desenvolvimento da aplicao mostrou que vivel utilizar aspectos para a
adaptao de agentes ao contexto. Porm, para que seja definida uma arquitetura
genrica com base na aplicao desenvolvida, devero ser formalizadas algumas
questes. Primeiro, necessrio definir explicitamente os locais na execuo de um
agente onde sero feitas as adaptaes (modelo de join points). Depois, preciso definir
primitivas para facilitar a utilizao de informaes contextuais nos pontos de atuao
(pointcuts), estendendo assim o paradigma orientado a aspectos.
4. Consideraes Finais
Esse artigo apresentou o desenvolvimento de uma aplicao composta de agentes
adaptativos ao contexto no domnio da Bolsa de Valores. A aplicao desenvolvida
indica que utilizando programao orientada a aspectos possvel modularizar a
soluo, separando o comportamento adaptativo do restante do comportamento do
agente. Devido forma como a arquitetura da aplicao foi estruturada, foi possvel
utilizar as informaes contextuais nos pontos de atuao.
O objetivo geral dessa pesquisa vai alm do desenvolvimento de uma aplicao
em um domnio especfico a idia disponibilizar uma arquitetura genrica que
permita a modificao de partes de elementos estruturais de um agente, adaptando o seu
comportamento de acordo com as mudanas percebidas em seu contexto. Sero
caractersticas da nova arquitetura: a verificao da satisfao atingida com as
adaptaes realizadas; a possibilidade de aprendizado multiagentes, onde o
conhecimento adquirido atravs de interao entre os agentes; e a utilizao de um
modelo de contexto genrico, o que permitir o uso de vrias informaes contextuais.
Para que a arquitetura apresente as caractersticas de aprendizado multiagentes e
avaliao das adaptaes realizadas, estuda-se a utilizao do framework Ontowledge
[LEM07]. O Ontowledge um framework desenvolvido em Java para dar suporte a
agentes que no possuem conhecimento para atingir determinado objetivo. Sempre que
um agente com o Ontowledge tem uma necessidade de conhecimento, um objeto de
conhecimento recuperado e o seu contedo automaticamente adicionado a
arquitetura do agente. Outra funcionalidade fornecida pelo framework a verificao da
satisfao alcanada com o uso de um objeto de conhecimento (registros de execuo
so criados para armazenar os resultados alcanados pelo agente).
Referncias
[AMO09] Amor, M.; Fuentes, L. Malaca: A component and aspect-oriented agent
architecture. Information and Software Technology. vol. 51-6, 2009.
[BLO07] Blois, M.; Escobar, M.; Choren, R. Using Agents and Ontologies for
Application Development on the Semantic Web. Journal of the Brazilian Computer
Society, vol. 1, 2007.
[DEY01] Dey, A.; Abowd, G.; Salber, D. A conceptual framework and a toolkit for
supporting the rapid prototyping context-aware applications. Human-Computer
Interaction, vol. 16-2, 2001.
[DEY99] Dey, A.; Abowd, G. Towards a better understanding of context and context-
awareness. Technical Report, College of Computing - Georgia Institute of Technology,
1999, 12p.
89

[ELD06] Elder, A. Aprenda a operar no mercado de aes. Rio de Janeiro: Campus,
2006, 11 edio, 317 p.
[GAR08] Garcia, A.; Lucena, C. Taming Heterogeneous Agent Architectures - Using
aspect-oriented techniques to construct high-quality multi-agent systems.
Communications of the ACM, vol. 51-1, May 2008.
[GON07] Gonzlez, S.; Mens, K.; Heymans, P. Highly dynamic behaviour adaptability
through prototypes with subjective multimethods. In: Symposium on Dynamic
languages, 2007.
[GRA07] Grassi, V.; Sindico, A. Towards model driven design of service-based context-
aware applications. In: ESSPE 2007, 2007.
[GUN08] Gunasekera, K.; Zaslavsky, A.; Krishnaswamy, S.; Loke, S. VERSAG:
Context-Aware Adaptive Mobile Agents for the Semantic Web. In: COMPSAC, 2008.
[GUN09] Gunasekera, K.; Krishnaswamy, S.; Loke, S.; Zaslavsky, A. Runtime Efficiency
of Adaptive Mobile Software Agents in Pervasive Computing Environments. In:
ICPS09, 2009.
[HAN07] Han, S.; Song, S.; Youn, H. Dynamic Software Adaptation with Dependence
Analysis for Multi-Agent Platform. In: Fifth International Conference on
Computational Science and Applications, 2007.
[IMA04] Imam, I. Adaptive applications of intelligent agents. In: International
Symposium on Computers and Communications, 2004.
[KHE05] Khedr, M. "Enhancing Applicability of Context-Aware Systems Using Agent-
Based Hybrid Inference Approach", In: IEEE VTC Spring, 2005.
[LEM07] Lemke, A.; Blois, M.; Choren, R. A Knowledge Management Framework for
Semantic Multi-Agent Systems. In: Proc. of AOIS 2007, 2007.
[LER03] Lerman, K.; Galstyan, A. Agent Memory and Adaptation in Multi-Agent
Systems. In: AAMAS03; 2003.
[MCK04] McKinley, P.; Sadjadi, S.; Kasten, E.; Cheng, B. Composing Adaptive
Software. Computer, vol. 37-7, 2004.
[RAN03] Ranganathan A.; Campbell R. A Middleware for Context-Aware Agents in
Ubiquitous Computing Environments. In: Middleware, 2003.
[SIM08] Simpkins, C.; Bhat, S.; Isbell, C.; Mateas, M. Towards adaptive programming:
integrating reinforcement learning into a programming language. In: 23rd SIGPLAN,
2008.
[SIN08] Sindico, A.; Bartolomeo, G.; Grassi, V.; Salsano, S. Design and development of
a context oriented language for middleware based applications. In: 2008 Workshop on
Next generation Aspect Oriented Middleware, 2008.
[SIT07] Sitou, W.; Spanfelner, B. Towards Requirements Engineering for Context
Adaptive Systems. In: COMPSAC 2007, 2007.
[WEI96] Weiss, G. Adaptation and learning in multi-agent systems: Some Remarks and a
Bibliography. Lecture Notes in Artificial Intelligence, vol. 1042, 1996.
[WEY08] Weyns, D.; Bouck, N.; Holvoet, T. A field-based versus a protocol-based
approach for adaptive task assignment. Autonomous Agents and Multi-Agent Systems,
vol. 17-2, 2008.
90
ALIEM: Ferramenta de Recomendao para
Alinhamento de Esquemas
Guylerme V. S. Figueiredo, Andrew Diniz da Costa, Carlos Jos Pereira Lucena,
Marco Antnio Casanova
Departamento de Informtica
Pontifcia Universidade Catlica do Rio de Janeiro (PUC-Rio)
Rio de Janeiro RJ Brasil
{gfigueiredo, acosta, lucena, casanova}@inf.puc-rio.br
Abstract. A common problem in companies is to perform alignment of
schemas in order to integrate different systems, such as legacy systems with
independent data schemas. Depending on the size of each schema, the cost
and time to perform the integration may become too high. Aiming at handling
such integrations, the paper presents a tool based on software agents that are
responsible for recommending possible alignments. Besides, the paper
describes a case study that uses the proposed tool. The case study performs
the alignment of different databases used for systems related with oil
exploration and production.
Resumo. Um problema comum em empresas quando h a necessidade de
realizar o alinhamento de esquemas, como, por exemplo, em sistemas legados
com diferentes esquemas de dados independente. Dependendo do tamanho de
cada esquema, o custo e o tempo para a integrao podem se tornar grandes.
Visando auxiliar tais integraes, o artigo apresenta uma ferramenta baseada
em agentes de software responsvel por recomendar como diferentes
esquemas de dados podem ser alinhados. Alm disso, o artigo descreve um
estudo de caso aplicado na indstria que usa a ferramenta proposta para
realizar o alinhamento de diferentes esquemas. Tal estudo de caso realiza um
alinhamento a partir de duas aplicaes responsveis por apoiar a atividade
de explorao e produo de petrleo.
1. Introduo
Um problema comum em ambientes corporativos de empresas a redundncia de
dados, principalmente em sistemas legados. Baseado em tal problema, diversas tcnicas
de alinhamento de esquemas conceituais foram propostas na literatura desde o trabalho
pioneiro de Rahm e Bernstein (2001) e Euzenat e Shvaiko (2007).
Quando se fala em alinhamento de esquemas estamos nos referindo que a partir
de similaridades encontradas em diferentes esquemas de banco de dados, h a
possibilidade de mesclar tabelas similares a fim de formar uma nica tabela que
atenda a todos os sistemas. Essa nova tabela deve desconsiderar o conceito do negcio a
que os sistemas so aplicados.
Segundo Rahm e Bernstein (2001) e Euzenat e Shvaiko (2007) as tcnicas de
alinhamento de esquemas, em geral, so classificadas em sintticas, semnticas e
91
hbridas. Na anlise sinttica, as evidncias para gerar o alinhamento so extradas das
definies dos esquemas, como nomes e descries das classes e propriedades, tipos de
dados das propriedades, relacionamentos e assertivas. Nas tcnicas semnticas, as
evidncias so extradas a partir de amostras de dados obtidas das fontes de dados. Por
fim, tcnicas hbridas combinam as duas anteriores para produzir os alinhamentos.
Convm destacar que as tcnicas sintticas baseiam-se no princpio de
similaridade mencionado no trabalho CASANOVA et al. (2007). J as tcnicas
semnticas baseiam-se na interpretao, tradicionalmente aceita, de que termos so
similares se denotam o mesmo conjunto de objetos QUINE (1968).
Na literatura h um conjunto de ferramentas propostas, como, por exemplo,
Erwin Data Modeler (2010), Infosphere Data Architect (2010), DB Designer (2010) que
permitem criao e visualizao de modelos de dados, porm, nenhuma delas
automatiza o processo de alinhamento de esquemas ou realiza anlises de pontos de
convergncia que permitam auxiliar no processo de alinhamento.
Baseado nesse contexto, o artigo prope uma ferramenta de recomendao para
apoiar administradores de dados no alinhamento de esquemas a partir do princpio de
similaridade sinttico. Como a idia da ferramenta ter autonomia e pr-atividade para
monitorar e verificar quais bases distribudas criadas por diferentes SGBDs poderiam
ser alinhadas a partir de mudanas realizadas, o paradigma de sistema multi-agente
[Jennings e Wooldridge 2000] [Wooldridge e Jennings 1998] foi usado.
O artigo est estruturado da seguinte forma. Na seo 2 so apresentados os
trabalhos relacionados. Na seo 3 a ferramenta de ALInhamento de EsqueMas
(ALIEM) apresentada em detalhes. Na seo 4 um estudo de caso baseado no
alinhamento de dois sistemas de apoio para atividade de explorao e produo de
petrleo descrito, enquanto que na seo 5 a concluso e os trabalhos futuros so
apresentados.
As ferramentas Erwin Data Modeler (Computer Associates), Infosphere Data Architect
(IBM), DB Designer (fabForce), assim como diversas outras so ferramentas de
modelagem de dados. Utilizando estas ferramentas, o administrador de dados capaz de
visualizar os modelos de dados e encontrar pontos de similaridade, porm, em nenhuma
delas existe qualquer funcionalidade que permita automatizar o processo de
alinhamento de esquemas, nem mesmo gerar algum relatrio com os pontos de
similaridade a fim de facilitar o trabalho do administrador de dados.
Existe tambm no mercado, uma ferramenta chamada Rochade (ASG) que um
repositrio de metadados. Essa ferramenta possui em sua arquitetura conectores que
realizam a leitura de metadados de diversos bancos de dados. Esses conectores acessam
um determinado SGBD e realizam a leitura dos metadados, como nome de tabelas,
nome de esquemas, etc. Aps essa leitura, ela grava em um banco de dados essas
informaes. No entanto, ela somente armazena os metadados coletados, i.e, no realiza
operaes de anlise de similaridade sobre a informao coletada. Por outro lado, a
ferramenta ALIEM aplica tcnicas de alinhamento de esquemas para identificar pontos
de similaridade.
92
3. ALIEM
ALIEM uma ferramenta de recomendao para Alinhamento de Esquemas de
diferentes bancos de dados e que estende o framework Jade [Bellifemine et al 2007], um
FIPA complaint framework desenvolvido em Java para implementar sistemas multi-
agentes (SMAs).
A Figura 1 ilustra o modelo conceitual do ambiente em que a ferramenta pode
ser utilizada. Perceba que para cada esquema de dados h um agente Parser responsvel
por recuperar as informaes de um esquema analisado de forma peridica e em seguida
encaminh-las para um agente central, chamado de Manager. As informaes enviadas
pelo agente Parser ao agente Manager so as seguintes: nome de instncia de banco de
dados, nome dos esquemas de banco de dados, nome das tabelas e nome das colunas e
seus respectivos tipos de dados. Na Figura 2 apresentada a relao conceitual entre
essas informaes.
Figura 1. Modelo Conceitual do uso da ferramenta ALIEM.
Figura 2. Relao das informaes recuperadas pelos agentes Parser.
Assim que o agente Manager recebe as informaes enviadas pelos agentes
Parser, ele verifica quais alinhamentos de esquema podem ser realizados. O resultado da
93
verificao armazenado em um relatrio que deve ser usado como base pela equipe
que deseja consolidar o alinhamento.
Atualmente, a ferramenta implementa anlises sinttica com base na
comparao de nomes. A primeira anlise realizada pelo agente Manager em relao
aos nomes de tabelas presentes em diferentes esquemas. J a segunda anlise realizada
em relao s colunas, onde sero feitas duas verificaes: por nomes de colunas iguais
e por tipos de dados (ex: caracter, nmero inteiro, etc) de cada coluna.
Na Figura 3 ilustrado o diagrama de classes da ferramenta proposta. A classe
ParserAgent representa o agente Parser, enquanto que a classe ManagerAgent
representa o agente Manager. Como o ALIEM utiliza o framework Jade para
representar o conceitos de agentes de software, definimos que as estratgias de
recuperao de dados devem ser aplicadas a partir da extenso de um comportamento
representado pela classe ParserBehavior. Tal classe estende a classe OneShotBehaviour
do Jade, que permite sua execuo para que o agente Manager possa depois identificar
se h esquemas de diferentes sistemas para serem alinhados. Atualmente, a ferramenta
permite a coleta de dados a partir do Oracle ou a partir de scripts SQL.
OclDataMapper uma classes utilizada pelo comportamento OclParserBehavior
para coletar informaes do Oracle, enquanto que a classe DataMapper permite persistir
os dados recuperados pelos agentes Parser em uma base de dados que ser usada pelo
agente Manager com o propsito de identificar os alinhamentos a serem realizados.
Atualmente, a ferramenta permite que o agente Manager realize tais anlises a partir de
bancos de dados onde so armazenados os dados coletados pelos Parsers.
Para definir uma nova estratgia de recomendao de alinhamento a partir de
bases criadas em algum outro SGBD, siga os seguintes passos:
1. Estenda a classe ParserBehavior para criar um comportamento que permita
recuperar informaes de bases criadas em um SGBD desejado. Alm disso,
implemente o mtodo loadMetaData;
2. Crie uma instncia da classe ParserAgent e inclua o comportamento explicado
nesse agente;
3. Estenda a classe Conn para criar a forma de conexo com o SGBD pretendido;
4. Crie uma nova classe que implemente a interface DBDataMapper a fim de
realizar as leituras necessrias no catlogo de metadados do SGBD.
94
Figura 3. Diagrama de Classes
4. Estudo de Caso: Sistema de Petrleo
O estudo de caso escolhido para comprovar o uso da ferramenta explicada na seo 3
um alinhamento de esquemas de dois sistemas de uma empresa de petrleo. Um dos
sistemas tem como objetivo para apoiar o Centro de Controle Operacional (CCO) nas
atividades de extrao de leo e gs, enquanto que o outro sistema ajuda na manuteno
de arquivos de Memria Tcnica (MENTEC), que so procedimentos, padres e outros
arquivos tcnicos que precisam ser armazenados. Como os dois sistemas so de apoio
para atividade de explorao e produo de petrleo, h certos conceitos que so usados
e representados pelas bases dos dois sistemas.
Percebendo a necessidade de criar um esquema nico de banco para que as
informaes possam ser usadas de forma compartilhada pelos dois sistemas, as equipes
de banco de dados dos projetos usaram a ferramenta ALIEM para realizar o
alinhamento desejado.
O sistema CCO possui uma base de dados criada no Oracle, enquanto que a base
do sistema MENTEC foi criada tambm no Oracle, porm, para nosso estudo de caso,
foi extrado o script DDL do schema. Neste estudo de caso utilizamos o script DDL pois
95
podem existir casos que o modelo no est necessariamente implementado em um
SGBD. Nas Figuras 4 e 5 so apresentados os modelos relacionais dos sistemas CCO e
MENTEC, respectivamente. Perceba que os conceitos poo (tabela POCO) e usurio
(tabela CADUSER) so usados nas duas bases distintas. Visando consolidar os
diferentes esquemas, ALIEM permitiu que o responsvel pelo alinhamento usasse como
base as informaes geradas pela ferramenta para identificar os pontos possveis para
alinhamento, e assim consolidar tal tarefa
Figura 4. Modelo relacional do sistema Centro de Controle Operacional
5. Concluso e Trabalhos Futuros
No artigo foi apresentado uma ferramenta de alinhamento de esquemas que baseia-se
em tcnicas de anlise sinttica, alm de um estudo de caso que a utiliza para alinhar
esquemas de dois sistemas distintos relacionados ao domnio de apoio para atividade de
explorao e produo de petrleo.
Como existe um conjunto de tcnicas sintticas propostos na literatura,
pretende-se incluir novas estratgias, alm de explorar tcnicas de anlise semntica,
para que melhores anlises possam ser realizadas pela ferramenta.
Outro trabalho a ser realizado ser prover estratgias que permitam realizar a
coleta de informaes de esquemas criados em outros SGBDs, alm do Oracle. A partir
disso, o usurio interessado em utilizar a ferramenta no ter que se preocupar em
implementar novas formas de coleta.
96
Figura 5. Modelo relacional do sistema Memria Tcnica.
References
RAHM, E., aand BERNSTEIN, P. (2001) A survey of approaches to automatic schema
matching. The VLDB Journal 10, 4, 334350.
EUZENAT, J., and SHVAIKO, P. (2007) Ontology matching. Springer-Verlag.
97
GOMES, Raphael do Vale Amaral, (2010) Matchmaking Uma infraestrutura para
alinhamento de esquemas.
CASANOVA, M. A. ; BREITMAN, Karin Koogan ; BRAUNER, Daniela F. ; Marins,
A.. (2007) Database Conceptual Schema Matching. Computer (Long Beach), v. 40,
p. 102-104.
QUINE, W.V., (1968) Ontological Relativity. J. of Philosophy, Vol. 65, No. 7, p.
185-212.
MELNIK, S., GARCIA-MOLINA, H., and RAHM, E. (2002) Similarity flooding: a
versatile graph matching algorithm and its application to schema matching. In:
Proc. 18th Int'l. Conf. on Data Engineering, pp. 117128.
MADHAVAN, J., BERNSTEIN, P. A., and RAHM, E. (2001) Generic schema
matching with Cupid. In: Proc. 27th Int'l. Conf. on Very Large Data Bases, pp. 49
58.
BILKE, A., AND NAUMANN, F. (2005) Schema matching using duplicates. In:
Proc. 21st Int'l. Conf. on Data Engineering, pp. 6980.
BRAUNER, Daniela F. ; CASANOVA, M. A. ; MILIDIU, Ruy (2007). Towards
Gazetteer Integration Through an Instance-based Thesauri Mapping Approach. In:
Clodoveu A. Davis Jr; Antonio M.V.M. Monteiro. (Org.). Advances in
Geoinformatics. Heidelberg: Springer, v. , p. 235-245.
BRAUNER, Daniela F. ; GAZOLA, A. ; CASANOVA, M. A. ; BREITMAN, Karin K
(2008). ADAPTATIVE MATCHING OF DATABASE WEB SERVICES EXPORT
SCHEMAS. In: International Conference on Enterprise Information Systems., 2008,
Barcelona. Proceedings of ICEIS 2008 Tenth International Conference on Enterprise
Information Systems.. isboa : INSTICC Institute for Systems and Technologies of
Information, Control and Communication,. p. 49-56.
LEME, Luiz Andr P. ; BRAUNER, Daniela F. ; Breitman, Karin K. ; CASANOVA,
M. A. ; Gazola, Alexandre.(2008) Matching object catalogues. Innovations in
Systems and Software Engineering, v. 4, p. 315-328,.
LEME, Luiz Andr P. ; CASANOVA, M. A. ; BREITMAN, Karin K ; FURTADO, A.
L. (2009) Instance-based OWL Schema Matching. In: 11th International Conference
on Enterprise Information Systems, 2009, Milan. Enterprise Information Systems.
Berlin : Springer. v. 24. p. 14-26.
LEME, Luiz Andr P.(2009) Conceptual schema matching based on similarity
heuristics. 2009. Tese (Doutorado em Informtica) - Pontifcia Universidade Catlica
do Rio de Janeiro concluda.
Bellifemine, F., Caire, G., Trucco, T., Rimassa, G., (2007) Jade Programmers Guide.
Jennings, N. R. and Wooldridge, (2000) M. Agent-oriented software engineering, In
Bradshaw, J. (Ed.) Handbook of Agent Technology, AAAI/MIT Press.
Wooldridge, M. and Jennings, N. R. (1998) Pitfalls of agent-oriented development,
Proceedings of the Second International Conference on Autonomous Agents
(Agents'98), ACM Press, pp. 385-391.
98
ERWin Data Modeler (2010), available at
http://erwin.com/products/detail/ca_erwin_data_modeler/, June.
Infosphere Data Architect (2010), available at http://www-
01.ibm.com/software/data/optim/data-architect/, June.
DB Designer (2010), available at http://www.fabforce.net/dbdesigner4/, June.
ASG web site (2010), available at
http://www.asg.com/products/productarea_list.asp?id=metadata, June.
99

Sociedade Brasileira
de Computao
UFBA
O
R
G
A
N
I
Z
A
O
R
E
A
L
I
Z
A
O
P
A
T
R
O
C
N
I
O
FAPESB
Pesquisa do Estado da Bahia
Fundao de Amparo
Secretaria da Indstria,
Comrcio e Minerao
EVENTOS SATLITES
XVII Sesso de Ferramentas
III FEES
Frum de Educao em Engenharia de Software
XV WTES
Workshop de Teses e Dissertaes em
Engenharia de Software
IV LTPD
Workshop on Languages and Tools for
Parallel and Distributed Programming
I WB-DSDM
Workshop Brasileiro de Desenvolvimento de
Software Dirigido por Modelos
IV LA-WASP
Latin American Workshop on
Aspect-Oriented Software Development
AutoSoft 2010
First Workshop on Autonomous
Software Systems
IV WDDS
Workshop de Desenvolvimento
Distribudo de Software
I WOES
Workshop Brasileiro de Otimizao em
I WJP
Workshop sobre Diretrizes para Jovens
Pesquisadores em Engenharia de Software
SBES
XXIV Simpsio Brasileiro de
SBLP
XIV Simpsio Brasileiro de
Linguagens de Programao
SBCARS
IV Simpsio Brasileiro de
Componentes, Arquitetura e
Reutilizao de Software

CBSOFT2010 AutoSoft Anais

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CBSOFT2010 AutoSoft Anais

Hochgeladen von

Copyright:

Verfügbare Formate

http://cbsoft.dcc.ufba.

: updated user model; rulesMap: adaptation rules

mximo que o agente poue pagai na compia uo ingiesso ij

minimo que o agente poue iecebei na venua uo(s)ingiesso(s)ij

Das könnte Ihnen auch gefallen