1. Multi-Agent Systems: Methodologies
Daniel Hallin
Marlon Etheredge
Utrecht University
February 26, 2014

2. Outline
Why would we use agents?
Methodologies: {AAII, Gaia, Tropos}
Frameworks: {AUML, DESIRE}
Framework in Z
Prometheus
Why wouldn’t we use agents?
Mobile Agents and their application
Questions

3. Why would we use agents?
Appropriateness of agents
Natural metaphore
Wrap legacy components
Dynamic environment (adaptivity)
Distributability, share control or expertise

4. What is a methodology?
A system development methodology refers to the framework that is
used to structure, plan, and control the process of developing an
information system
Modeling language and conceptual framework
Analysis, Design and Implementation techniques
Tabel : Definition from (CMS) Office of Information Service (2008)

5. Overview
OO
(∼1960)
UML
(∼1990)
Agents in
Z (1995)
AAII
(1996)
Gaia
(2000)
AUML
(2001)
Promentheus
(2004)
DESIRE
(1997)

6. DESIRE (Brazier et al. 1997)
Method of describing compositional systems
Graphical notation
Graphical tool
Modeling of:
Task (de)composition
Information exchange
Sequencing of (sub)tasks
Subtask delegation
Knowledge structures

7. DESIRE Example
Model including agents and information link with the external
world (Brazier et al. 1997)

8. AUML (Bauer et al., 2001)
Effort solving differences and inconsistencies in different
approaches
Bring together agent-based methodologies and emerging OO
standards
Extension of UML:
Agent roles
Multithreaded lifelines
Extended message semantics
Parameterized nested protocols
Protocol templates

9. AUML Example
Protocol diagram of the English-Auction protocol for surplus flight
tickets (Bauer et al., 2001)

10. GAIA (Wooldridge et al. 2000)
Provides tools for the Analysis– and Design processes
Treats Requirement capture as individual process
Borrows terminology from OO analysis and design

11. GAIA Concepts
Abstract
Roles
Permissions
Responsibilities
Protocols
Activities
Liveness Properties
Safety Properties
Concrete
Agent Types
Services
Acquaintances

12. GAIA Organization
System
Roles
Interactions
Activities
Responsibilities
Permissions
Protocols
Safety properties
Liveness
properties
Figuur : Organization structure in GAIA

13. TROPOS (Bresciani et al., 2004)
Covers the Analysis-, Design- and Implementation processes
Early phases of requirement analysis

14. TROPOS Concepts
An Actor is an entity with goals and intentionality within a system
Role, abstract characterization of social actors behaviour
Set of roles played by one agent is called a position
A goal represents an actor’s strategic interests.
Distinction between hard goals and soft goals
Some of the further concepts are Plans, Resources (objects and
info), Dependencies (actor relationships), Capabilities and Belief.

15. TROPOS Developing process
Actor model & Dependency model
Goal model
Plan model
Figuur : Developing process in TROPOS

16. AAII (Kinny et al., 1996)
Extension of OO
Internal model: State of agent (BDI)
External model: System-wide, agents and their relations
Agent class model: Agents that can appear in a system
Agent instance model: Agent classes that can appear

17. AAII Example (Kinny et al., 1996)
1. Identify roles of application domain, elaborate agent class
hierarchy (abstract)
2. Define responsibilities and provided services of each agent role
e.g. monitor environment and notify agents of changes in the
environment
3. Define plans, how will an agent reach a certain goal e.g. for
notifying other agents of changes in the environment,
information should be sent to another agent by means of a
message. Internal modeling of agents can be performed
4. Refine the agent hierarchy to encapsulate commonality,
introduce concrete classes and determine beliefs

18. Agents in Z (Luck & d’Inverno, 1995)
Entity: Inanimate, attributes
Object: Capabilities
Agent: Goals
Autonomous agent: Motivations
Agents are functional, rather than rational, acting or one
another
... if I want to store coffee in a cup, then the cup is my agent for storing coffee. It has been
ascribed or has adopted my goal to have the coffee stored. It is, therefore, the goals of an agent
which are its defining characteristics.
oindent
(Luck & d’Inverno)

19. Prometheus
Promethues: A Pragmatic Methodology
for Engineering Intelligent Agents

20. Prometheus
Covers the Analysis, Design and Implementation phases.
The development process generates artifacts, important for
testing and debugging.
Support for detailed design of the agents internals.

21. Prometheus
Three design phases
System Specification Phase
Architectural Design Phase
Detailed Design Phase
Tool support
Prometheus Design Tool
JACK Support

22. Prometheus - Methodology overview
System specification phase
Percepts and Actions
Basic functionalities
Scenarios
Shared data sources

23. Prometheus - Methodology overview
Architectural design phase
Identify and describe agents
System overview diagram
Interaction protocols

24. Prometheus - Methodology overview
Detailed design phase
Agent internals
Overviews
Agent overview
Capability overview
Descriptors
Capability descriptors
Event descriptors
Data descriptors
Plan descriptors

25. Prometheus - Methodology overview

26. Prometheus - Methodology overview

27. Prometheus - System specification
Percepts & Actions
How the system is interacting with environment
Distinguished from event
Examples of percepts
User enters an URL, User clicks a button, System receives an
email.
Examples of actions
Place order, Bank transaction, System sends an email.

28. Prometheus - System specification
Goals and Functionality
Describes overall system behaviour
A goal divides into related functionalities

29. Prometheus - System specification
Functionality example:
NAME: Welcoming
Description: Welcomes a visitor to the website.
Percepts/events/messages: CustomerArrived (message)
Messages sent: CustomerInformationRequest (message)
Actions: DisplayCustomisedWWWPage
Data used: CustomerDB, CustomerOrders
Interactions:
CustomerManager (via CustomerInformationRequest, CustomerInformation)

30. Prometheus - System specification
Scenarios
Describes a chain of events in the system
Similar to use cases in OO
Every step in a scenario is one of the following:
incoming event/percept (→ receiving functionality)
message (sender → receiver)
activity (functionality)
action (functionality)

31. Prometheus - System specification
Scenario example:
Scenario: Book Order
Overview: The user orders a book. . . . The books are shipped,
stock updated, and the user notified.
Context: Assumes the book is in stock.
Steps: 1. EVENT BookOrder (→ Online Interaction)
2. DeliveryOptionQuery (Online Interaction → Transport Information)
.
.
.
8. Register order (Order Handling) Writes data: CustomerOrders
9. ACTION EmailCourierCompany (Order Handling)
10. DecreaseStock (Order Handling → Stock Manager)
Variations: steps 9 (email courier) and 10 (decrease stock) replaced with notification of delay (Order Handling to Customer Contact)
and then order more stock (Order Handling to Stock Manager).

32. Prometheus - Methodology overview

33. Prometheus - Architectural Design
Methods for creating and selecting types of Agents
Grouping functionalities
Simple descriptive name
Data coupling diagram, minimize shared data objects
Agent acquaintance diagram, minimize linkage.

34. Prometheus - Architectural Design
Reasons for grouping functionalities:
Functionalities are/seem related
Functionalities require the same information/data
Reasons for not grouping functionalities:
Functionalities are/seem unrelated
Functionalities exists on different hardware
Security and privacy
Modifiability

35. Prometheus - Architectural Design
Figuur : Data coupling diagram

36. Prometheus - Architectural Design
Generating Agent descriptors
How many of this type of agent?
Lifetime of agent
Agent initialization
Agent demise
What data to monitor?
What events to react to?

37. Prometheus - Architectural Design
Agent descriptor example:
Name: Sales Assistant agent
Description: greets customer, follows through site. . .
Cardinality: one/customer.
Lifetime: Instantiated on customer arrival at site. . .
Initialization: Obtains cookie. Reads Customer DB.
Demise: Closes open DB connections.
Functionalities included: Online Interaction, Sales Transaction. . .
Uses data: Customer DB, Customer Orders, Book DB.
Produces data: Customer preferences, orders, queries
Goals: Welcome customer; Update customer details. . .
Events responded to: new arrival; customer query. . .
Actions: Display information to customer (greetings, bookinfo. . . )
Interacts with: Warehouse Manager (book request protocol) . . .

38. Prometheus - Architectural Design
The System overview diagram combines:
Environmental events, generated from the percepts.
Agents
Shared data objects

39. Prometheus - Architectural Design
Figuur : System overview diagram

40. Prometheus - Architectural Design
Interaction diagrams
UML-sequence diagrams
Generated from scenarios
Interaction protocols
Specified in AUML
Generated from generalizing interaction diagrams

41. Prometheus - System specification
Scenario example:
Scenario: Book Order
Overview: The user orders a book. . . . The books are shipped,
stock updated, and the user notified.
Context: Assumes the book is in stock.
Steps: 1. EVENT BookOrder (→ Online Interaction)
2. DeliveryOptionQuery (Online Interaction → Transport Information)
.
.
.
8. Register order (Order Handling) Writes data: CustomerOrders
9. ACTION EmailCourierCompany (Order Handling)
10. DecreaseStock (Order Handling → Stock Manager)
Variations: steps 9 (email courier) and 10 (decrease stock) replaced with notification of delay (Order Handling to Customer Contact)
and then order more stock (Order Handling to Stock Manager).

42. Prometheus - Methodology overview

43. Prometheus - Detailed Design
Implementing agent internal structures
Not specific to a given agent model
Well suited for BDI systems (PRS, dMARS, JAM or JACK)

44. Prometheus - Detailed Design
Capabilities
Describe agents’ internals
Initially generated from system specification artifacts
Can be nested
Contains plans, events and data

45. Prometheus - Detailed Design
Capabilities descriptors
Describes external interface to the capability
Capability descriptor example:
Name: Name of capability
External interface to the capability: Events used/produced
Natural language description: Description of behaviour
Interaction with other capabilities: Other capabilities
Data used/produced by the capability: Data read/written
Inclusion of other capabilities: If nested

46. Prometheus - Detailed Design
Agent overview diagram and Capability overview diagram
Similar to System overview diagram
Provides high level view of task/event flow

47. Prometheus - Detailed Design
Event descriptors
Descriptors to specify all events.
Specifies purpose and data
Event coverage: How many plans are applicable?
Plan descriptors
Constrained to a single triggering event.
Data descriptors

48. Prometheus - Methodology overview

49. Prometheus - Prometheus Design Tool
Prometheus Design Tool, allows:
Edit design in terms of Prometheus concepts
Use of crosschecking to find design inconsistencies
Generate diagrams and design descriptions

50. Prometheus - Prometheus Design Tool
Cross checking procedures:
Find undefined references and unreachable components.
Check for correct type usage.
Check scenarios for inconsistency.
Check interface consistency of agents and capabilities.

51. Prometheus - JACK Development
Environment
JACK support for Prometheus
Concepts provided by JACK corresponds to Prometheus
detailed design
Agent structure generated by JDE are compilable, runnable
code
Drag and drop design tool
Crosschecking between diagram and entities

52. Mobile Agents
Capable of transmitting program and states across network
Origin in Telescript (General Magic, Inc.)
Replacement of remote procure calls
Risks:
Serialization: Sending of program and its state
Inconsistent platforms/architectures: Unix vs. Windows
Security: RAM/CPU/HDD/Other processes
Synchronization: Termination of connection/packet loss

53. Mobile Agents Overview
Mobile agents, where agents are transported between
environments, rather than v := B− > m(Args) from a class A in
RPC

54. Telescript (White, 1994)
Tickets, indicating the place to travel to and the time to
complete an operation
Agents might meet locally, or transfer remotely
Program counter, represents program state, serialization
Permits control limitations on travel and resource access
(money, lifetime, size), security
Object oriented, interpreted, programmable (high level),
transferable (low level)

55. Telescript (White, 1994)
HelloPlace : class ( WebPlace ) =
(
public
initialize : op (...) = {
;
*. setDoc ( INDEXKEY , *. createPage ());
};
createPage : op () HTMLParent | Nil = {
page := HTMLPage (" Hello World ");
HTMLString ( page , nil ," Hello World " ,
HTML_TITLE ,1 , HTML_CENTER , true );
HTMLRule ( page );
HTMLString ( page , nil ,
" A Telescript place created this page .");
return page ;
};
);
Example place, creating an HTML page (D¨mel, 1996)
o

56. Agent T(i)c(k)l(e) (Gray, 1995)
Tcl: Scripting language, commonly used with Tk as Tcl/Tk
Agent Tcl supports multiple languages, Tcl, Java and Scheme
as well as easy addition of additional languages
Scripts are interpreted, therefore easily transferable (jump)
Jump captures the complete state and transfers the whole to
a new machine, execution is then continued
Agents are digitally signed so the owner can be identified
Access control is used to limit resources

57. Agent Tcl (Gray, 1995)
agent_begin # register with the local agent server
set output {}
set machineList { muir tenaya ... }
foreach machine $machineList {
agent_jump $machine # jump to each machine
append output [ exec who ] # any local processing
}
agent_jump $agent ( home ) # jump back home
# display output window
agent_end # unregister
Example migration of a ‘who’ agent (Gray, 1997)

58. Aglets (Oshima & Lange, 1997)
Java objects
Extending the Aglet class: onCreation (initialize), run
(executed at destination), dispatch (on travel),
handleMessage (incoming message)
Agent Transfer Protocol (ATP)
Program state as collection of variables (and their values)
Overview of the Aglet classes (Oshima & Karjoth, 1997)

59. Other Mobile Agent Frameworks
Fraglets (Tschudin, 2003): Framework built around ‘fraglets’,
computational fragments implementing a chemical reaction
model where computations are carried out by having fraglets
react with each other
JADE (Bellifemine et al., 2000): Software framework used to
develop agent-based applications in compliance with the FIPA
(Foundation for Intelligent Physical Agents) specifications

60. Pitfall #1
Figuur : You oversell agent solutions, or fail to understand where agents
may usefully be applied

61. Pitfall #2
Figuur : You get religious or dogmatic about agents

62. Pitfall #3
Figuur : You do not know why you want agents

63. Pitfall #4
Figuur : You want to build generic solutions to one-offproblems
pitfall-universal

64. Pitfall #5
Figuur : You believe that agents are a silver bullet

65. Pitfall #6
’
Figuur : You decide that you want your own agent architectured

66. Pitfall #7
Figuur : Your agents use too much Al

67. Pitfall #8
Figuur : You forget that you are developing software

68. Pitfall #9
Figuur : You see agents everywhere

69. Pitfall #10
Figuur : You have too few agents

70. Pitfall #11
Figuur : You spend all your time implementing infrastructure

71. Pitfall #12
Figuur : Your agents interact too freely or in an disorganized way

72. Thank You
Multi-Agent Systems: Methodologies
Daniel Hallin
Marlon Etheredge
Questions?