PUC-Rio

Agents and Objects: An Empirical Study on the

Design and Implementation of MASs

Alessandro Garcia Claudio SantAnna Christina Chavez Viviane Silva Carlos Lucena Arndt von Staa

SoC+Agents Group www.teccomm.les.inf.puc-rio.br/SoCAgents

May 3rd, 2003

Motivation
!
Complexity of modern software systems Emergent features and application domains

Distribution and Openness Knowledge Integration Mobile Computing

Pervasive Computing E-Commerce Personalization

Fact: new properties into the software systems

Goal-orientation, autonomy, adaptation, collaboration, mobility, intelligence

= Agent Properties

Does Object-Oriented Software Engineering provide:

Suitable abstractions for modularizing MAS properties?

Classes, objects, methods, attributes, inheritance... UML, Java Programming Language, Design Patterns... 3 Viewpoints: Construction, Maintenance, and Reuse

The Problem

Object vs. Agent Properties

the features of objects and classes are not directly aligned with agency features

To what extent do OO abstractions produce MAS design and code that is reusable and maintainable?

explicit separation of concerns low coupling and high cohesion

Agents vs. Objects: Limited Understanding

Adaptation Agent Type Autonomy Collaboration Agenthood

Conceptual Level

Agent Type Goals

Role

Organization

Analysis and Design Level

GAIA, Common-KADS, Tropos, MAS-ML, AUML...

Agent-Based Software Engineering

Design Patterns [Kendall, 1999]

? ?
Object Pattern

?
Attribute Aspect Method Advice

Object-Oriented Software Engineering

Design Level

T-Rex, JADE, Retsina, JAFIMA, ZEUS,

Object Pointcut Legend:

Concern Abstraction

Dominates

Implementation Level

Lack of Empirical Studies

Several researchers say: Forget objects Lets construct a new software engineering, new design methods and techniques, new programming languages from the scratch Objects and agents are entities essentially different!

Arguments are not based on empirical evidence Limited understanding about the interplay between object and agent properties in practice

Past Experience with MAS Engineering (I)

Fact 1: Poor Separation of Agency Concerns
MAS #1: Web Development Environment MAS #2: Web Searcher

Autonomy Autonomy

MAS #3: Virtual Market

MAS #4: Negotiation

Autonomy

Autonomy

Past Experience with MAS Engineering (II)

Fact 2: Lack of reuse of identical roles and agent types Fact 3: Lack of reuse of agent services Fact 4: Agent Schizophrenia Potential Problem Causes: 1 OO abstractions do not provide suitable support for reuse and maintenance of MASs 2 OO abstractions are OK the investigated MASs were not well structured according common change and reuse concerns

Our Work (I)

An Empirical Study Goal: Improve our knowledge about the interplay between agency concerns and OO abstractions Comparison:

Pattern-Oriented Development: classes, patterns, Aspect-Oriented Development: classes, aspects,

3 Viewpoints: Construction, Maintenance and Reuse MAS concerns were identified from different sources

Literature examples and MASs developed at our lab Agent-oriented design and programming languages

Our Work (II)

Agents vs. Objects Objects

State: attributes Behavior: methods State: beliefs, actions, and goals Behavior: actions, properties (autonomy, adaptation, interaction, )

Agents: objects with attitude

Objects as building blocks of agents

Reactive agents Large-scale MASs Different agent types and roles Multiple properties

An Example: Portalware MS

Agent Types Interface Agent User Agent Information Agent Naming Agent Roles User Agent: editor, content supplier, reviewer Information Agent: caller and answerer

An Example: Portalware

Types of Agents in Portalware

Interface Agents Information Agents User Agents Naming Agents

Software Agents

Collaboration
Learning

Mobility
Adaptation Interaction Autonomy

The Pattern-Oriented Method

1st step: Agenthood
1. Define an Agent class to represent applications agents 2. Create classes to model the state components of the agents 3. Describe the state elements as attributes of the Agent class 4. Create methods on the Agent class to update the state elements 5. Create methods on the Agent class to implement common capabilities

2nd step: Agent Types

1. Use inheritance to define the different agent types of the application 2. Create methods on the subclasses to define specific capabilities 3. Create new beliefs, plans, and goals by extending the corresponding classes

3rd step: Basic Properties

1. Use the Mediator pattern to define the basic properties (adaptation, interaction, autonomy) and their composition 2. Associate the Mediator pattern with the Agent class

4th step: Collaboration and Roles

1. Use the Role pattern to define the different agent roles and their composition 2. Associate the Mediator pattern with the the Role pattern to modularize the collaboration concern

Aspect-Oriented Software Development

OO Solution
Crosscutting Concerns

Aspect-Oriented Solution
Aspect
Join Points

Classes

Improve separation of concerns Improve maintainability and reuse of classes and crosscutting concerns AspectJ and Hyper/J

The Aspect-Oriented Method (I)

OO Solution
Autonomy, Interaction, Adaptation, ...

Aspect-Oriented Solution A

Improve separation of agency concerns Improve reuse and maintenance of MASs

The Aspect-Oriented Method (II)

1st step: Agenthood
1. Define an Agent class to represent applications agents 2. Create classes to model the state components of the agents 3. Describe the state elements as attributes of the Agent class 4. Create methods on the Agent class to update the state elements 5. Create methods on the Agent class to implement common capabilities

2nd step: Agent Types

1. Use inheritance to define the different agent types of the application 2. Create methods on the subclasses to define specific capabilities 3. Create new beliefs, plans, and goals by extending the corresponding classes

3rd step: Basic Properties

1. Use an aspect to define each basic property (adaptation, interaction, autonomy) and their composition 2. Associate the aspects with the Agent class

4th step: Collaboration and Roles

1. Use an aspect to define each agent role 2. Attach the roles aspects to the respective agent types 3. Create an aspect to modularize the collaboration concern and attach it with the respective collaborative agent type

The Experimental Setting

Subjects (Experienced Programmers): 2 PhD Students x 2 PhD Students Almost 2 years: January 2001 December 2002 Training on Aspect-Oriented Software Development Code Standardization each design and code implemented the same scenarios different programming styles

The Pattern-Oriented Solution

Strategy Pattern

Plan

Agent

Property

Mediator Pattern

ailability Plan

Searching Plan

Interface Agent

Autonomy

Interaction Adaptation

Composite Pattern

Knowledge
Role Pattern

Collaboration

Counter Proposal

Proposal

Collaborative Agent

Collaboration Core

Collaboration Role

Middle Agent

User Agent

Information Agent

Content Supplier

Answerer Editor

Caller

The Aspect-Oriented Solution

Autonomy Plan Agent Interaction ailability Plan Searching Plan Interface Agent Knowledge Middle Agent Counter Proposal Proposal User Agent Editor Content Supplier Information Agent Caller Answerer Collaboration Adaptation

Evaluation: The Construction Viewpoint

Some OO abstractions are useful to represent concerns of reactive MASs Classes: agent types and knowledge Inheritance:

reuse of basic agent actions specialization: hierarchy of agent types, role hierarchies, plan hierarchy and action hierarchy

Both methods provided improved separation of concerns Complementary in certain contexts

Evaluation: The Construction Viewpoint

Limitations of patterns Choosing the suitable patterns is time-consuming Combination of patterns is challenging

Example: The Role Pattern x The Mediator Pattern

Explosion of classes to address MAS concerns Some concerns are not encapsulated as a single pattern Difficult to understand the association between agency properties and specific agent types Limitations of aspects The identification of the join points is not trivial

Limitations of the Pattern-Oriented Approach

Strategy Pattern

Plan

Agent

Property

Mediator Pattern

ailability Plan

Searching Plan

Interface Agent

Autonomy

Interaction Adaptation

Composite Pattern

Knowledge
Role Pattern

Collaboration

Counter Proposal

Proposal

Collaborative Agent

Collaboration Core

Collaboration Role

Interface Agent

User Agent

Information Agent

Content Supplier

Answerer Editor

Caller

Collaboration Concern Pattern

Evaluation Framework

Evaluation Framework Focus: Reusability and Maintainability Based on the Basilis GQM Methodology Definition of a Quality Model Definition of a Metrics Suite The Reuse and Evolution Scenarios

The Quality Model and Metrics

Qualities Factors Principles Separation of Concerns Understandability Size Reusability Flexibility Coupling Cohesion Metrics
CDC CDO CDLOC VS LOC NOA WMC CBC LCOM AC

Maintainability Modifiability Extendibility

CC AOp COp AR CR ALOC CLOC CoC CoLOC

The Reuse and Evolution Scenarios

S1) Change on the Agent Roles (Evolution) S2) Creation of an Agent Type (Evolution) S3) Reuse of the Agenthood Concern (Reuse) S4) Inclusion of Collaboration in an Agent Type (Reuse and Evolution) S5) Reuse of Roles (Reuse) S6) Creation of a new Agent Instance (Evolution) S7) Change of the Definition of Agenthood (Reuse and Evolution)

Results (I)

The Aspect-Oriented Approach provided: Better support for maintainability and reusability More concise MAS in terms of:

lines of code (LOC metric): 1231 x 1445 system vocabulary (VS metric): 56 x 62 component vocabulary (NOA metric) - use of patterns

Less coupled components than the pattern-oriented approach

CBC Metric - E.g.: Editor role: 18 x 23, Caller role: 19 x 25 DIT Metric - Patterns abuse the inheritance mechanism high inheritance couplings

Results (II)

The Aspect-Oriented Approach provided: Better support for separation of MAS concerns

CDC, CDO, CDLOC

Lack of cohesion in the aspects

LCOM metric
WMC metric (complexity of the advices/pointcuts)

Some more complex operations

Results (III)
The aspect-oriented approach required less modification and extension of the selected MAS
MODIFIABILITY Changed Entities S1 S2 S3 S4 S5 S6 S7 1 0 0 0 1 0 5 1 0 0 0 1 0 1 Changed Added Operations Entities 3 2 2 2 2 0 0 3 2 2 3 1 0 0 5 4 4 8 0 0 0 5 4 4 8 0 0 0 Added Operations 2 0 0 0 1 0 0 3 0 0 0 1 0 0 EXTENSIBILITY Changed Added Added Relations. Relations. LOCs 0 0 0 0 0 0 5 0 0 0 0 0 0 2 15 10 10 29 4 0 1 15 10 10 25 2 0 1 101 98 84 86 84 86 188 167 16 14 15 15 0 0 Changed LOCs 1 0 0 0 0 0 5 1 0 0 8 0 0 1 Copied Entities 0 0 0 0 0 0 0 0 Copied LOCs 0 0 6 40 0 0 6 0

PO AO PO AO PO AO PO AO PO AO PO AO PO AO PO AO PO AO PO AO

Ongoing Work

Empirical and theoretical validation of the proposed metrics Investigation of MASs containing cognitive agents electronic marketplace (PUC-Rio) urban traffic management (USP - Sao Paulo) Investigation of MASs designed and implemented outside of our group (SELMAS colleagues) Facet: An Aspect Language for Multi-Agent Systems

Component language: subset of TAO Facets: support crosscutting concerns in MAS design

Results and Publications

Qualitative Study
A. Garcia, V. Silva, C. Chavez, C. Lucena. Engineering Multi-Agent Systems with Aspects and Patterns. Journal of the Brazilian Computer Society, Special Issue on Software Engineering and Databases, August 2002.

The Aspect-Oriented Approach for Developing MASs

A. Garcia, C Lucena, D. Cowan. Agents in Object-Oriented Software Engineering. Software: Practice & Experience, Elselvier, 2003. (Accepted to Appear) A. Garcia et al. Promoting Advanced Separation of Concerns in Intra-Agent and Inter-Agent Software Engineering. Workshop on ASoC at OOPSLA'2001, Tampa Bay, USA, October 2001. A. Garcia, V. Silva, C. Chavez, C. Lucena. Engineering Multi-Agent Systems with Aspects and Patterns. Journal of the Brazilian Computer Society, Special Issue on Software Engineering and Databases, August 2002.

Results and Publications

TAO: The Conceptual Framework for Agent-Based Software Engineering

V. Silva, A. Garcia, A. Brando, C. Chavez, C. Lucena, P. Alencar. Taming Agents and Objects in Software Engineering. In: "Software Engineering for Large-Scale Multi-Agent Systems". Springer-Verlag, LNCS 2603, April 2003.

Quantitative Studies
A. Garcia et al. Agents and Objects: An Empirical Study on the Design and Implementation of MAS. In: SELMAS03 Proceedings. May 2003. (Accepted to Appear) A. Garcia et al. Agents and Objects: An Empirical Study on Software Engineering. TR 06-03, PUC-Rio, Brazil, February 2003.

Additional Contributions and Publications

A System of Aspect-Oriented Patterns for MASs

O. Silva, A. Garcia, C. Lucena. The Reflective Blackboard Architectural Pattern. In: "Software Engineering for Large-Scale Multi-Agent Systems". Springer-Verlag, LNCS, March 2003. (Accepted to Appear)

T-Rex: A Reflective Architecture for Mobile Agents

O. Silva, A. Garcia, C. Lucena. T-Rex: A Reflective Tuple Space Environment for Dependable Mobile Agent Systems. Workshop on Wireless Communication and Mobile Computation (WCSF'2001), Recife, Brazil, August 2001.

SELMAS02 and SELMAS03

A. Garcia, C. Lucena. Software Engineering for Large-Scale Multi-Agent Systems SELMAS 2002. (Post-Workshop Report) ACM Software Engineering Notes, August 2002. A. Garcia, C. Lucena, J. Castro, A. Omicini, F. Zambonelli. Software Engineering for Large-Scale Multi-Agent Systems. LNCS 2603, Springer, January 2003. (To be published)

Colocar mais referencias Usar sugestes dos revisores Dizer q outras pessoas conceberam o mtodo orientado a aspectos Ler sobre varivel dependente e independente. Trabalho em andamento Aspects in AOSE [S:P&E] The Facet Abstraction

Crosscutting Concerns in AO Languages New Abstraction to TAO MAS of SELMAS02 colleagues: Coordination, Trustworthy, Fault Tolerance, Display FacetTAO: An Aspect-Oriented Language for AOSE

SoC+Agents Group
MAS Applications VMarket CommercePipe VGroups Portalware SELMAS 2002, 2003

Modeling Language

TAO: Conceptual Framework

Empirical Studies

Metrics & Quality Model T-Rex

Methods

Aspect-Oriented Approach

Cooperations
SoC + Agents
Metodologia Framework Conceitual
R D

T-Rex

Teste em SMAs

USP

I
Aplicao Mtodo

Our Approach

The 1st principle: the objects are not aware of the agency aspects added (obliviouness) The 2nd principle: with the separation of agent services from their agency properties, reuse and evolution is improved (quantification)

Our Aspect-Oriented Approach (III)

Roles modularized as aspects

CALLER ANSWERER ReceiveSearchAsk() SendResult()

SendSearchAsk() ReceiveResult() ActivatesCaller()

<<crosscuts>>

<<crosscuts>>

InformationAgent
search(Keyword) search( KWList )

AspectJ
Object

method call reception join points ASPECT

introduction pointcuts advices

<<crosscuts>>

method call join points

Our example
object autonomy interactive reactive agent proactive agent autistic

Outline

Motivation Research Questions The Problem Results Goals Publications Background Aspect-Oriented Software Development Design Patterns The Aspect-Oriented Method for MAS Development Empirical Studies My Doctoral Research: A Roadmap

! ?

Problems

The Problem (I)

Objects x Agents state

contains description of its behavior

behavior

autonomy, adaptation, interaction

From agents to objects: conceptual gaps

Introduo

Engenharia de Software Orientada a Agentes Agentes (Propriedades Internas)

Estado: crenas, objetivos, planos, aes Comportamento:

Autonomia Interao Adaptao

Mobilidade Colaborao (Papis) Aprendizagem

Propriedades Externas

Organizaes Ambientes

Software Engineering of MASs

Agenthood

Intra-Agent Concerns Agent Types

Agenthood

goals knowledge services

Autonomy, Interaction, Adaptation Collaboration, Intelligence, Mobility Inter-Agent Concerns Roles and Organizations

Coordination, Mobility, Context-Awareness, Trustworthy...

O Problema
Modelos do SMA
Propriedades Internas Propriedades Externas

Fase de Especificao (orientada a agentes)

Mtodo ad hoc

Como separar tais propriedades?

Fase de Desenvolvimento (orientada a objetos)

SoC?

Data Collection

Together Tool Manual Collection SoC Metrics

O Problema
Modelos do SMA
Propriedades Internas

Autonomia, colaborao, Adaptao...

Fase de Especificao (orientada a agentes)

Mtodo ad hoc

Vrias Metodologias

Fase de Desenvolvimento (orientada a objetos)

SoC Manuteno Reutilizao

Introduo
Modelos do SMA
Propriedades Internas Propriedades Externas

Fase de Especificao (orientada a agentes)

Fase de Desenvolvimento (orientada a objetos)

Games Simulation O que algumas pessoas acreditam e que ja estamos implementando MASs, mas com the OO notions at Artificial, Simulated Environment hand

LARGE-SCALE SYSTEMS
E-commerce, E-learning, Information filtering Virtual development environments...

Environment: Web/Internet Environment: Web/Internet A Big ORB A Big ORB

Soluo e Objetivos

Soluo: Mtodo para Desenvolvimento de SMAs Objetivos: Entender se o paradigma de objetos adequado para o desenvolvimento de SMAs

Objetos, mtodos e atributos Herana, agregao, associao, delegao, ...

Prover um mtodo orientado a aspectos para o desenvolvimento de SMAs

How this research advances the state of the art of AOSE? Limitations of related work? Contribute to a better understanding of the interplay between agents and objects how? Experimenting and analyzing the problems arguments are not based on empirical sources our philosophy/methodology is different lets to look to working abstractions (such as OO, patterns,) and find the real problems underpinning the development of agents with existing abstractions. we think a good way to show the added value of agents is showing how it goes from OO to agents,

Background

Software Engineering of MASs Abstractions in OO Software Engineering Using OO Abstractions for Developing MASs

AOSE Researchers

Methods and languages totally independently from the object paradigm

Past Experience with MAS Engineering

Concern1

MAS #1

Concern2

Empirical Results Ongoing

- Of course, you can use OO to implement MAS, but the question is: - Is it provide support for maintainable and reusable support? - If no, why? - Of course, it does not provide evidence that OO does not provide support for MAS - it could be related to design decisions of the MAS engineers - schedule restrictions

Empirical Studies
MAS Applications VMarket CommercePipe VGroups Portalware Avestruz

Problems encountered: lack of reuse of agency concerns across MAS projects prohibitive maintenance Possible causes: poor separation of concerns lack of unified terminology object schizophrenia

Validao (Estudos Empricos)

Fatores: Reusabilidade e Facilidade de Manuteno Mtodo Orientado a Padres OO (mediator, role, observer...) Estudo Qualitativo (1a. Fase) Elaborao de cenrios

Dificuldade de reutilizao Dificuldade de manuteno

Estudo Quantitativo (2a. Fase) Uso do mtodo GQM Definio de um conjunto de mtricas

Redefinio de mtricas clssicas (coeso, acoplamento, tamanho...) Criao de mtricas para SoC

Resultados (1a. Fase)

Soluo OO baseada em padres Escolha do padro apropriado problemtica

Vrios padres para o mesmo problema em SMA (mediator, chain of responsibility...)

Combinao de mltiplos padres no trivial

Padro Role x Padro Mediator

Abuso de herana Exploso de classes Object Schizophrenia Adaptaes intrusivas (reutilizao e manuteno) Objetos, herana, agregao, ..., padres no fornecem suporte a SMAs reutilizveis e fceis de manter

Resultados (1a. Fase)

Soluo proposta Benefcios

Melhor SoC Suporte para Reutilizao e Manuteno

Dificuldades

Papis x planos Descoberta dos aspectos (especficos de aplicao) nem sempre so fceis

Ainda precisvamos melhorar nosso entendimento sobre os mtodos e SMAs e SOOs Estudo Quantitativo (em desenvolvimento) Outros projetos (Marketplace) Projetos SMA fora do TecCoom (SELMAS02 workshop)

Conclusions

Based on the research results, what is the new thing to say independently from the use of patterns or not, OO abstractions do not fit very well with agency properties the aspect-oriented approach is generally better...

Motivation (III)

Software Engineering and Programming: A Historical Perspective

Object

O que algumas pessoas acreditam e que ja estamos implementando MASs, mas com the OO notions at hand

An Example: Portalware

Agenthood Properties Autonomy

An agent is capable of acting without direct external intervention It has its own control thread and can accept or refuse a request message An agent communicates with the environment and other agents by means of sensors and effectors an agent adapts/modifies its mental state according to messages received from the environment

Interaction

Adaptation

An Example: Portalware

Additional Properties Collaboration

cooperation and/or negotiation with other agents an agent can learn based on previous experience while reacting and interacting with its external environment an agent is able to transport itself from one environment to another

Learning

Mobility

Motivation (II)

Abstractions are used to isolate concerns UML Abstractions Class, object, method, attribute, specialization Additional Design Abstractions Design patterns [Gamma, 95] Java Abstractions Class, object, method, attribute, inheritance Method call, interface, ...

Looking at Existing MASs

How agency concerns are structured based on OO abstractions? TecComm Lab Portalware, MAS Framework, Avestruz, VMarket, CommercePipe What are software engineering concerns to MAS developers? 3 viewpoints: Construction, Reuse, Maintenance

The Construction Viewpoint

Agenthood

Agency Concerns Agent Types

Agenthood

goals knowledge actions

Autonomy, Interaction, Adaptation Collaboration, Learning, Mobility Roles and Organizations

Coordination, Mobility, Context-Awareness, Trustworthy...

The Construction Viewpoint

Definition of Agent Types services, goals and knowledge Definition of the Agenthood Properties Agenthood and other Properties structure the property strategies and algorithms associate agent types with properties associate properties with agent services and knowledge compose the properties Definition of Roles attach the roles with agent types Organizations, Environments

Maintenance and Reuse Viewpoint

Change the number of agent types Change agent services Change algorithms related to agent properties degree of autonomy learning technique Addition of agent roles in different contexts Reuse Reuse Reuse Reuse agent types agent services algorithms related to agent properties agent roles in different contexts

Agents x Objects: Poor Understanding

Several agent-oriented languages and methods

Several OO implementation frameworks for MASs: T-Rex, JADE, Retsina, JAFIMA, ZEUS, Few software engineering approaches to support agents in OO design and implementation A set of design patterns [Kendall, 1999]

Agents x Objects: Poor Understanding

Several agent-oriented languages and methods GAIA, Common-KADS, Tropos, MAS-ML, ... Several OO implementation frameworks for MASs: T-Rex, JADE, Retsina, JAFIMA, ZEUS, Few software engineering approaches to support agents in OO design and implementation A set of design patterns [Kendall, 1999]

Using Patterns for Developing MASs

Based on solutions (patterns) documented in the literature Kendalls Patterns [Kendall, 99] Encapsulates the interaction concern Uses sensors and effectors (change the sensors) Mediator Pattern Modularizes each agency behavioral property

interaction, adaptation, autonomy, collaboration...

Mediate the use of these properties Role Pattern Decouples the agent services from the agent roles Encapsulates the collaboration concern

The Aspect-Oriented Approach

Separation of Concerns Aspects (and classes) encapsulate the agency concerns of interest Reusability Reuse of Aspects and Classes Maintainability Obliviousness Quantification

Aspects and AspectJ

Aspects: concerns that crosscut system components Examples: logging, distribution, exception handling, and so on... Several approaches: AOP, MDSoC, Composition Filters, ... Abstractions in AOSD

Components: Classes and Aspects

AspectJ e Hyper/J

Past Experience with MAS Engineering (II)

public class PAgent { private String agentName; ... ... protected Interaction theInteraction; protected Autonomy theAutonomy; protected Adaptation theAdaptation; // Constructors

public PAgent(String aName, Vector pl) { init(); agentName = aName; theInteraction = new Interaction(this); theAutonomy = new Autonomy(this); theAdaptation = new Adaptation(this); planList = pl; System.out.println(" Name == " + agentName); } ... ... ... /* Interface for Interaction */ public void receiveMsg(Message msg) { theAutonomy.makeDecision(msg); theAdaptation.adaptBeliefs(msg); } public void outcomingMsg(Message msg) { theInteraction.outcomingMsg(msg); } }

Figure 9. An example of code shadowing

Goals, Questions & Metrics (GQM)

Goal Evaluate the reusability and ease of evolution of the implemented multi-agent systems in order to compare the object-oriented development with the aspectoriented development. Questions 1. How easy is it to evolve the system? 1.1. How easy is it to understand the system? 1.1.1. How concise is the system? 1.1.1.1. How many components (aspects/classes) are there? 1.1.1.2. How many lines of code are there? 1.1.1.3. How many attributes are there? 1.1.1.4. How many methods and advices are there? 1.1.2. How well are the agency concerns localized? 1.1.2.1. How scattered is the agenthood definition? 1.1.2.2. How scattered are the agent fundamental concerns? 1.1.2.2.1. How scattered is the autonomy concern? 1.1.2.2.2. How scattered is the interaction concern? 1.1.2.2.3. How scattered is the adaptation concern? 1.1.2.3. How scattered are the agent alternative concerns? 1.1.2.3.1. How scattered is the collaboration concern? 1.1.2.4. How scattered are the agent roles? 1.1.2.5. How scattered is the definition of agent types and their instances? 1.1.2.5.1. How scattered is the user agent type definition? 1.1.2.5.2. How scattered is the definition of a user agents instance? 1.1.2.5.3. How scattered is the information agent type definition? 1.1.2.5.4. How scattered is the definition of an information agents instance? 1.1.3. How high is the coupling of the system? 1.1.3.1. How high is the coupling between components? 1.1.4. How high is the cohesion of the system? 1.1.4.1. How high is the cohesion of the system components?

How well are the agency concerns localized?

How high is the coupling between system components?

Components = classes or aspects Operations = methods or advices

The Aspect-Oriented Method (III)

Sensor
AUTONOMY ControlThreads HowManyThreads() MakesDecision() StartsThreadControl() PerformsPlan()
Introduction Part

Effector

INTERACTION
Inbox Outbox ReceiveMsg() SendMsg() Receive() Send()

ADAPTATION SuspendedPlans GetNextPlan() AdaptBeliefs() AdaptGoal() AdaptPlan ()

<<crosscuts>>
Agent

<<crosscuts>>

BeliefList GoalList PlanList updateBelief() addGoal() setGoal() addPlan() setPlan()

<<crosscuts>>

Advices Part

The Aspect-Oriented Method (IV)

Improved support for MAS maintenance and evolution

MOBILITY
dispatch() retract()

CALLER
sendSearchAsk() receiveResult()

ANSWERER
after(search*):Transfer() receiveSearchAsk() sendResult()

<<crosscuts>>
after(search*):StartsCaller() after(search*):StartsAnswerer()

InformationAgent
search(Keyword) search(KWList)

The Pattern-Oriented Method (I)

Separation of Concerns Patterns encapsulate the MAS concerns of interest Improve the design vocabulary Reusability Reuse of the pattern and its solution elements Maintainability Planning for Change

The Investigated Methods

The methods are concerned with concerns independently of implementation architecture: JADE, JAFIMA, RETSINA, ZEUS, IBM AGLETS communication language: KQML, ACL... ontology description: DAML+OIL, SHOE...

Ongoing Work

Investigation of MASs containing cognitive agents electronic marketplace (PUC-Rio) urban traffic management (USP - Sao Paulo) Investigation of MASs designed and implemented outside of our group (SELMAS colleagues)

The Metrics
Metrics
Vocabulary Size (VS) Lines of Code (LOC) Number of Attributes (NOA) Weighted Methods per Component (WMC) Coupling Between Components (CBC) Lack of Cohesion in Methods (LCOM) Depth of Inheritance Tree (DIT) Concern Diffusion over Components (CDC) Concern Diffusion over Operations (CDO) Concern Diffusions over LOC (CDLOC)

Answered Questions
How many components (classes/aspects) are in the design? How many lines of code are there in the implementation? How many attributes are there in the components? How many operations (methods/advices) are there? How high is the coupling between components? How high is the cohesion of the systems components? How high is the coupling between components? How high is the cohesion of the systems components? How well are the agency concerns localized in terms of components? How well are the agency concerns localized in terms of operations? How well are the agency concerns localized in termos of LOC?

Principles
Size Size Size Size Coupling Cohesion Coupling and Cohesion Separation of Concerns Separation of Concerns Separation of Concerns