AGENT-ORIENTED DESIGN PATTERNS

T. Tung Do, Manuel Kolp, St

ephane Faulkner, Alain Pirotte

Information System Unit, University of Louvain

1, Place des Doyens, 1348 Louvain-La-Neuve, Belgium

Keywords:

agent oriented software engineering, design patterns, multi-agent systems

Abstract:

Multi-Agent Systems (MAS) architectures are gaining popularity over traditional ones for building open, dis-

tributed, and evolving software required by today’s corporate IT applications such as eBusiness systems, web

services or enterprise knowledge bases. Since the fundamental concepts of multi-agent systems are social and

intentional rather than object, functional, or implementation-oriented, the design of MAS architectures can be

eased by using social patterns. They are detailed agent-oriented design idioms to describe MAS architectures

as composed of autonomous agents that interact and coordinate to achieve their intentions, like actors in hu-

man organizations. This paper presents social patterns and focuses on a framework aimed to gain insight into

these patterns. The framework can be integrated into agent-oriented software engineering methodologies used

to build MAS. We consider the Broker social pattern as a combination of patterns and use it to illustrate the

framework. The automatation of patterns design is also overviewed.

1 INTRODUCTION

The explosive growth of application areas such

as electronic commerce, knowledge management,

peer-to-peer and mobile computing has profoundly

changed our views on information systems engineer-

ing. Systems must now be based on open archi-

tectures that continuously evolve to accommodate

new components and meet new requirements. These

new requirements call, in turn, for new concepts and

techniques for engineering and managing information

systems. Therefore, Multi-Agent System (MAS) ar-

chitectures are gaining popularity over traditional sys-

tems, including object-oriented ones.

Developing enterprise information systems with a

MAS architecture permits a better match between sys-

tem architectures and their operational environment.

A MAS can be seen as a social organization of au-

tonomous software entities (agents) that can ﬂexibly

achieve agreed-upon intentions through their interac-

tions. MAS support dynamic and evolving structures

which can change at run-time to beneﬁt from the ca-

pabilities of new system entities or replace obsolete

ones.

MAS architectures become rapidly complicated

due to the ever-increasing complexity of these new

business domains and their human or organizational

actors. An important technique that helps to manage

this complexity when constructing and documenting

such architectures is the reuse of development experi-

ence and knowhow. Over the past few years, design

patterns have signiﬁcantly contributed to the reuse of

design expertise, improvement application documen-

tation and more ﬂexible and adaptable designs. The

idea behind a pattern is to record the essence of a so-

lution to a design problem so as to facilitate its reuse

when similar problems are encountered.

Considerable work has been done in software

engineering on deﬁning design patterns (see e.g.,

(Gamma, 1995)). Unfortunately, they focus on

object-oriented rather than agent-oriented systems. In

the area of MAS, little emphasis has been put on so-

cial and intentional aspects. Moreover, the proposals

of agent patterns that address those aspects (see e.g.,

(Aridor, 1998; Deugo, 1999; Hayden, 1999)) are not

aimed at the design level, but rather at the implemen-

tation of lower-level issues like agent communication,

information gathering, or connection setup. For in-

stance, the FIPA (FIPA) identiﬁed and deﬁned a set of

agent’s interaction protocols that are only restricted to

the communication.

Since there is a fundamental mismatch between the

concepts used by the object-oriented paradigm (and

other traditional mainstream software engineering ap-

proaches) and the agent-oriented view, there is a need

to develop patterns that are speciﬁcally tailored to

the development of multi-agent systems using agent-

oriented primitives.

Tung Do T., Kolp M., Faulkner S. and Pirotte A. (2004).

AGENT-ORIENTED DESIGN PATTERNS.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 48-53

DOI: 10.5220/0002646300480053

 SciTePress

The catalogue of social patterns proposed in (Kolp,

2001) constitutes a contribution to the deﬁnition of

agent-oriented design patterns for MAS architectures.

This paper proposes and conceptualizes the SKwyRL

patterns framework to explore social patterns and fa-

cilitate the building of MAS during detailed design as

well as the generation of code for agent implemen-

tation. It models and introspects the patterns along

different complementary dimensions.

The paper is organized as follows. In Section 2, we

overview the patterns. Section 3 proposes the frame-

work and illustrates its different modeling dimensions

through the Broker pattern. The automation of social

patterns is overviewed in Section 4. Section 5 points

to some conclusions.

2 SOCIAL PATTERNS

In the following, we present patterns based on social

and intentional dimensions that are recurrent in multi-

agent and cooperative systems. Pair patterns describe

direct interactions between negotiating agents, while

Mediation patterns feature intermediate agents that

help other agents reach agreement about an exchange

of services.

2.1 Pair Patterns

The Booking pattern involves a client and a number

of service providers. The client issues a request to

book some resource from a service provider. The

provider can accept the request, deny it, or propose

to enter the client in a waiting list, until the requested

resource becomes available.

The Subscription pattern involves a yellow-page

agent and a number of service providers. The

providers advertise their services by subscribing to

the yellow pages. A provider that no longer wishes to

be advertised can request to be unsubscribed.

The Call-For-Proposals pattern involves a client and

a number of service providers. The client issues a

call for proposals for a service to all service providers

and then accepts proposals that offer the service for a

speciﬁed cost. The client selects one service provider

to supply the service.

The Bidding pattern involves a client and a number

of service providers. The client organizes and leads

the bidding process, and receives proposals. At every

iteration, the client publishes the current bid; it can

accept an offer, raise the bid, or cancel the process.

2.2 Mediation Patterns

In the Monitor pattern, subscribers register for

receiving, from a monitor agent, notiﬁcations of

changes of state in some subjects of their inter-

est. The monitor accepts subscriptions, requests

information from the subjects of interest, and alerts

subscribers accordingly.

In the Broker pattern, the broker agent is an ar-

biter and intermediary that requests services from

providers to satisfy the request of clients. The rest

of the paper details latter the pattern to illustrate the

SKWYRL social patterns framework.

In the Matchmaker pattern, a matchmaker agent

locates a provider for a given service requested by

a client, and then lets the client interact directly

with the provider, unlike brokers, who handle all

interactions between clients and providers.

In the Mediator pattern, a mediator agent coordinates

the cooperation of performer agents to satisfy the

request of an initiator agent. While a matchmaker

simply matches providers with clients, a mediator

encapsulates interactions and maintains models of the

capabilities of initiators and performers over time.

In the Embassy pattern, an embassy agent routes

a service requested by an external agent to a local

agent. If the request is granted, the external agent

can submit messages to the embassy for translation

in accordance with a standard ontology. Translated

messages are forwarded to the requested local agent

and the result of the query is passed back out through

the embassy to the external agent.

The Wrapper pattern incorporates a legacy system or

database into a multi-agent system. A wrapper agent

is an embassy that interfaces system agents with the

legacy system/database by acting as a translator. This

ensures that communication protocols are respected

and that the legacy system/database remains decou-

pled from the rest of the agent system.

3 THE SKWYRL SOCIAL

PATTERNS FRAMEWORK

This section describes SKWYRL

, a conceptual

framework based on ﬁve complementary modeling di-

Socio-Intentional ArChitecture for Knowl-

edge Systems and Requirements ELicitation

(http://www.isys.ucl.ac.be/skwyrl/)

AGENT-ORIENTED DESIGN PATTERNS

mensions to investigate social patterns. Each dimen-

sion reﬂects a particular aspect of a MAS architecture.

Other modeling frameworks like AUML (Bauer,

2001) represent the detailed design of a MAS by

adapting and extending object-oriented concepts. We

believe that a conceptual framework primarily based

on MAS concepts (such as beliefs, intentions, goals,

. . . ) is more appropriate than extended object-

oriented frameworks that treat agents as objects of a

particular type.

• The social dimension identiﬁes the relevant agents

in the system and their intentional interdependen-

cies.

• The intentional dimension identiﬁes and formalizes

services provided by agents to realize the intentions

identiﬁed by the social dimension, independently

of the plans that implement those services. This

dimension answers the question: ”What does each

service do?”

• The structural dimension operationalizes the ser-

vices identiﬁed by the intentional dimension in

terms of agent-oriented concepts like beliefs,

events, plans, and their relationships. This dimen-

sion answers the question: ”How is each service

operationalized?”

• The communicational dimension models the tem-

poral exchange of events between agents.

• The dynamic dimension models the synchroniza-

tion mechanisms between events and plans.

The social and the intentional dimensions are spe-

ciﬁc to MAS. The structural, communicational, and

dynamic dimensions of the architecture are also rele-

vant for traditional (non-agent) systems, but we have

adapted and extended them with agent-oriented con-

cepts. This section details the dimensions and illus-

trates them with the Broker pattern.

3.1 Social Dimension

The social dimension speciﬁes a number of agents

and their intentional interdependencies using the i*

model (Yu, 1995). Figure 1 shows a social-dimension

diagram for the Broker pattern. Agents are drawn

as circles and their intentional dependencies as ovals.

An agent (the depender) depends upon another agent

(the dependee) for an intention to be fulﬁlled (the de-

pendum). Dependencies have the form depender →

dependum → dependee.

The Broker pattern can be considered as a com-

bination of (1) a Subscription pattern (shown en-

closed within dashed boundary (a)), that allows ser-

vice providers to subscribe their services to the Bro-

ker agent and where the Broker agent plays the role of

yellow-page agent, (2) one of the other pair patterns

Figure 1: Social diagram for the Broker pattern

(Booking, Call-for-Proposals, or Bidding) whereby

the Broker agent requests and receives services from

service providers (in Figure 1, it is a Bidding pat-

tern, shown enclosed within dotted boundary (b)), and

(3) interaction between Broker and client: the Broker

agent depends on the client for sending a service re-

quest and the client depends on the Broker agent to

forward the service.

To formalize intentional interdependencies, we

use Formal Tropos (Fuxman, 2001), a ﬁrst-order

temporal-logic language that provides a textual no-

tation for i* models and allows to describe dynamic

constraints. A forward service dependency can be

deﬁned in Formal Tropos as follows.

Dependum Forward Service

Mode: Achieve

Depender: Client cl

Dependee: Broker br

Fulﬁllment:

(∀sr : ServiceRequest, st : ServiceT ype)

request(cl, br, sr) ∧ provide(br, st)

∧ of T ype(sr, st) → ♦ received(cl, br, st)

[Broker br successfully provides its service to client cl if all

requests sr from cl to br, that are of a type st that br can

handle, are eventually satisﬁed]

3.2 Intentional Dimension

While the social dimension focuses on interdepen-

dencies between agents, the intentional view aims

at modeling agent rationale. It is concerned with

the identiﬁcation of services provided by agents and

made available to achieve the intentions identiﬁed in

the social dimension. Each service belongs to one

agent. Service deﬁnitions can be formalized as in-

tentions that describe the fulﬁllment condition of the

service. The collection of services of an agent deﬁnes

its behavior.

Table 1 gives an informal deﬁnition for

several services of the Broker pattern. The

FindBroker service allows a client to ﬁnd

a broker that can handle a given service re-

quest. The client then sends the request to the

broker through the SendServiceRequest

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

Table 1: Some services of the Broker pattern

Service Name Informal Deﬁnition Agent

FindBroker Find a broker that can Client

provide a service

SendService Send a service request Client

Request to a broker

QuerySP Query the knowledge for Broker

Availability information about the

availability of the

requested service

SendService Send an answer to the Broker

RequestDecision client

RecordBR Record a negative answer Client

Refusal from a broker

RecordBR Record a positive answer Client

Acceptance from a broker

RecordClient Record a service request Broker

ServiceRequest received from a client

CallFor Send a call for proposals Broker

Proposals to service providers

RecordAndSend Record a service received Broker

SPInformDone from a service provider

service. The broker can query its belief knowl-

edge with the QuerySPAvailability

service and answer the client through the

SendServiceRequestDecision service.

If the answer is negative, the client records it

with its RecordBRRefusal service. If the an-

swer is positive, the broker records the request

(RecordClientServiceRequest service) and

then broadcasts a call (CallForProposals

service) to potential service providers. The

client records acceptance by the broker with the

RecordBRAcceptance service.

The Bidding pattern could be used here, but this

presentation omits it for brevity.

The broker then selects one of the service

providers among those that offer the requested ser-

vice. If the selected provider successfully returns

the requested service, it informs the broker, that

records the information and forwards it to the client

(RecordAndSendSPInformDone service).

Services can also be formalized in Formal Tropos

(Fuxman, 2001).

3.3 Structural Dimension

While the intentional dimension answers the question

”What does each service do?”, the structural dimen-

sion answers the question ”How is each service oper-

ationalized?”.

Services are operationalized as plans, that are se-

quences of actions. The knowledge that an agent has

(about itself or its environment) is stored in its beliefs.

An agent can act in response to the events that it han-

dles through its plans. A plan, in turn, is used by the

agent to read or modify its beliefs, and send events to

other agents or post them to itself.

The structural dimension models these agent-

oriented concepts (plan, belief, event, agent) with an

UML style class diagram extended for MAS. Due to

lack of space, in this paper, we do not study them.

A more detail deﬁnition of these concepts could be

found in (Do, 2003).

3.4 Communication Dimension

Agents interact with each other by exchanging

events. The communicational dimension models,

in a temporal manner, events exchanged in the

system. We adopt the sequence diagram model

proposed in AUML (Bauer, 2001) and extend

it: agent name/role:pattern name expresses the role

(role) of the agent (agent name) in the pattern (pat-

tern name); the arrows are labeled with the name of

the exchanged events.

Customer1/

Client:BR

bk1/

Broker:BR ServiceProvider:BR

sp1/

Subscribe/ Unsubscribe

AcceptedSubscriptionSent

RefusedSubscriptionSent

BRRefusalSent

CallForProposalSent

RefusalSent

ProposalSent

pattern

ServiceRequestSent

BRAcceptanceSent

RejectedProposalSent

AcceptedProposalSent

CallForProposalSent

FailureServiceSent

InformDoneServiceSent

ServiceForwarded

ServiceRequestSent

InformFailure

pattern

Bidding

Figure 2: Communication Diagram - Broker

Figure 2 shows the sequence diagram of our Bro-

ker pattern. It also depicts the subscription (SB)

and bidding patterns the broker pattern embeds.

The client (customer1) sends a service request

(ServiceRequestSent) containing the charac-

teristics of the service that it wishes to obtain from

the broker. The broker may alternatively answer

with a denial (BRRefusalSent) or a acceptance

(BRAcceptanceSent).

In case of acceptance, the broker sends a call

for proposals to the registered service providers

(CallForProposalSent). The bidding pattern

is then applied to model the interaction between

AGENT-ORIENTED DESIGN PATTERNS

the broker and the service providers. The service

provider either fails or achieves the requested ser-

vice. The broker then informs the client by sending

a InformFailureServiceRequestSent or a

ServiceForwarded, respectively.

3.5 Dynamic Dimension

In MAS, a plan can be invoked by an event that it han-

dles and it can create new events. Relationships be-

tween plans and events can rapidly become complex.

To cope with this problem, we propose to model the

synchronization and the relationships between plans

and events with activity diagrams extended for agent-

oriented systems (See Figure 3). These diagrams

specify the events that are created in parallel, the con-

ditions under which events are created, which plans

handle which events, and so on.

Plan 1

(alternative 1)

Plan 2

(alternative 2)

Caption

Internal Event

Plan

External Event

Synchronization bar

Branch

RecordAndSendSPInformDone

......

FindBRWithMM

FindBR

RecordBRRefusal

RecordAndSendSPFailure

Proposal

Sent

For

Call

Inform

Done

Service

Sent

Client

AvailabilityQueried

Broker

QuerySPAvailability

SP not found or

constraints provided by

client can not be satisfied

CallForProposal

FailureServiceSent

Reservation

Started

BRRefusedExternal

Service Provider

InformeFailure

RecordBRFailure

ServiceForwarded

RecordBRForwardedService

BRFound

SendServiceRequest SendServiceRequestDecision

ServiceRequestSent

RecordClientServiceRequest

RecordBRAcceptance

BRAcceptanceSent

BRAcceptancePosted

Bidding

pattern

Figure 3: Dynamic Diagram - Broker

An event is represented by a arrow, a plan is repre-

sented by an oval. If an event is handled by alternative

plans, they are enclosed in a round-corner box. Syn-

chronization and branching are represented as usual.

We omit the dynamic dimension of the Subscrip-

tion and the Bidding patterns, and only present in Fig-

ure 3 the activity diagram speciﬁc to the Broker pat-

tern. It models the ﬂow of control from the emission

of a service request sent by the client to the reception

by the same client of the realized service result sent

by the broker. Three swimlanes, one for each agent

of the Broker pattern, compose the diagram. In this

pattern, the FindBroker service described in Sec-

tion 3.2, is either operationalized by the FindBR or

the FindBRWithMM plans (the client ﬁnds a broker

based on its own knowledge or via a matchmaker).

At a lower level, each plan could also be modeled

by an activity diagram for further detail if necessary.

Figure 4: JACK Code Generation

4 CODE GENERATION

The main motivation behind design patterns is the

possibility of reusing them during detailed design and

implementation. Numerous CASE tools such as Ra-

tional Rose (Rose) and Together (Together) include

code generators for object-oriented design patterns.

Programmers identify and parameterize, during de-

tailed design, the patterns that they use in their ap-

plications. A code skeleton for patterns is then au-

tomatically generated and programming is thus made

easier.

Such tools are not yet available for agent design

patterns. A recent development in the SKWY RL pat-

terns framework is the proposal a code generator for

the social patterns introduced in Section 2. Figure 4

shows the main window of the tool. It is developed

with Java and produces code for JACK (JACK), an

agent-oriented development environment built on top

of Java. JACK extends Java with speciﬁc capabilities

to implement agent behaviors. On a conceptual point

of view, the relationship of JACK to Java is analogous

to that between C++ and C. On a technical point of

view, JACK source code is ﬁrst compiled into regular

Java code before being executed.

In the SKWYRL code generator, the programmer

ﬁrst chooses which social pattern to use, then the

roles for each agent in the selected pattern (e.g., the

Broker agent plays the broker role for the Bro-

ker pattern but can also play the client role for the

Bidding pattern and the yellow-page role for the Sub-

scription pattern in the same application). The pro-

cess is repeated until all the patterns in the application

are identiﬁed. The code generator then produces the

generic code for the patterns (the .agent, .event, .plan,

.bel JACK ﬁles).

Figure 5 shows an e-business broker developed

with JACK. The code skeleton was generated with

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

Figure 5: An E-Business Broker

our code generator using the Broker pattern. The

customer sends a request to the broker to buy or sell

DVDs, specifying titles, quantity, and deadline for an-

swering the request. When receiving the customer re-

quest, the broker interacts with the E MediaShops to

obtain the DVDs (bottom-right corner of the ﬁgure).

At every iteration, the broker can accept an offer, raise

the bid, or cancel the process.

5 CONCLUSION

Patterns ease the task of developers describing sys-

tem architectures. This paper has introduced the

SKWYRL social patterns framework designed for

agent methodologies like TRO PO S to formalize a code

of ethics for social patterns (MAS design patterns in-

spired by social and intentional characteristics), an-

swering questions like: “what can one expect from

a broker, mediator, or embassy?”. The framework is

used to:

• deﬁne social patterns and answer the above ques-

tion according to the ﬁve modeling dimensions of

TROPOS: social, intentional, structural, communi-

cational, and dynamic.

• drive the design of the details of a MAS architec-

ture in terms of those social patterns during the

detailed-design phase.

The paper has overviewed some social design pat-

terns on which we are working. The ﬁve dimensions

of the framework have been illustrated through the

Broker pattern.

Future research directions include the precise for-

malization of a catalog of social patterns, including

the characterization of the sense in which a particu-

lar MAS architecture is an instance of a conﬁguration

of patterns. We will also compare and contrast social

patterns with classical design patterns proposed in the

literature.

REFERENCES

Y. Aridor and D. B. Lange. “Agent Design Patterns: Ele-

ments of Agent Application Design”, in Proc. of the

2nd Int. Conf. on Autonomous Agents (Agents’98), St

Paul, Minneapolis, USA, 1998.

B. Bauer, J. P. Muller and J. Odell “Agent UML: A Formal-

ism for Specifying Multiagent Interaction”, in Proc.

of the 1st Int. Workshop on Agent-Oriented Software

Engineering (AOSE’00), Limerick, Ireland, 2001. he

Netherlands, 2002.

D. Deugo, F. Oppacher, J. Kuester and I. V. Otte. “Patterns

as a Means for Intelligent Software Engineering”, in

Proc. of the Int. Conf. on Artiﬁcial Intelligence (IC-

AI’99), Vol. II, CSRA, 1999.

T. Tung Do, M. Kolp, T. T. Hang Hoang and A. Pirotte. ”A

Framework for Design Patterns for Tropos”, in Proc.

of the 17th Brazilian Symposium on Software Engi-

neering (SBES 2003), Maunas, Brazil, 2003.

Foundation for Intelligent Physical Agents (FIPA).

http://www.ﬁpa.org

A. Fuxman, M. Pistore, J. Mylopoulos and P. Traverso.

“Model Checking Early Requirements Speciﬁcations

in Tropos”, in Proc. of the 5th IEEE Int. Symposium on

Requirements Engineering (RE’01), Toronto, Canada,

2001.

E. Gamma, R. Helm, J. Johnson and J. Vlissides. Design

Patterns: Elements of Reusable Object-Oriented Soft-

ware, Addison-Wesley, 1995.

S. Hayden, C. Carrick and Q. Yang. “Architectural Design

Patterns for Multiagent Coordination”, in Proc. of the

3rd Int. Conf. on Agent Systems (Agents’99), Seattle,

USA, 1999.

JACK Intelligent Agents. http://www.agent-software.com/.

M. Kolp, P. Giorgini and J. Mylopoulos. “A Goal-Based

Organizational Perspective on Multi-Agents Architec-

tures”, in Proc. of the 8th Int. Workshop on Intelli-

gent Agents: Agent Theories, Architectures, and Lan-

guages (ATAL’01), Seattle, USA, 2001.

Rational Rose. http://www.rational.com/rose/.

Together. http://www.togethersoft.com/.

E. Yu. Modeling Strategic Relationships for Process

Reengineering, PhD thesis, University of Toronto, De-

partment of Computer Science, Canada, 1995.

AGENT-ORIENTED DESIGN PATTERNS