AOT Lab
Dipartimento di Ingegneria
dell’Informazione
Università degli Studi di Parma
Multi-Agent Systems
Implementation and Testing
Giovanni Caire1, Massimo Cossentino2,
Alessandro Negri3, Agostino Poggi3, Paola Turci3
1TILab
2ICAR
- Consiglio Nazionale delle Ricerche (CNR)
3 AOT Lab - DII, University of Parma
From Design
to Implementation
 Issues connected with the transition from the design phase
to the implementation phase
 Diagrammatic notations and tools which should support developers
• Refinements of the design models
• Deployment of the system
• Need of reducing the prototype implementation time
 Four main research lines:
 Representation of the interactions between agents and their
relationship with the architecture of the single agent
 Deployment diagram of MASs
 Pattern reuse
 Testing
 This work is organized as an activity within FIPA Modeling
TC
AT2AI04 – Vienna, April 15th, 2004
2
Implementation Level –
MAS Interactions
 Two dimensional plane: Component vs. Interconnection
 The diagram is placed at the:
• Agent-object boundary in the component dimension
▫ Looking at the diagram one can recognize
◦ Agent-level entities
◦ Object-oriented artifacts with which the entities are expressed
• Agent-society boundary in the interconnection dimension
▫ Looking at the diagram one can see
◦ The part of the social structure the agent participate in as a
whole
◦ Which internals parts of each agent get actually involved in the
ongoing interaction
AT2AI04 – Vienna, April 15th, 2004
3
Choosing the Perspective:
UML Activity Diagrams
 Our work lies within the AUML initiative. We look at
standard UML diagrams as the basis for our
notation
 Properties that our diagram should have
• Showing interactions at a detailed level
• Showing agents and objects
• Showing inter-agent and intra-agent links
 Among the various UML diagrams, we decided to use
the Activity Diagram, because:
• Combines structural and behavioural aspects
• Can have precise constraints (e.g. temporal)
• Can be recursively expanded with sub-activities
• Provides flexible clustering with swim lanes
AT2AI04 – Vienna, April 15th, 2004
4
Different Levels of Detail (1)
 Exploiting the recursive aggregation of activities
allowed by UML activity diagram
 Global vision of the system, low level of detail
• One swim lane for each agent
• Activities within each swim lane group the dynamics of an agent
▫ Links between activities represent
◦ Message exchange, when they cross swim lanes
◦ Task creation or activation, when they connect activities within
the same swim lane
• At this level, the activities granularity is comparable to an agent
behaviour
AT2AI04 – Vienna, April 15th, 2004
5
Multi-Level Representation of Agent
Behaviour Diagram - Example
Machine Tool Agent
Product Agent
MachineTool
<<Conversation>>
conv1
Product
[ManufactRqst, RDF, ContractNet]
MachineTool.
ProdtPhaseContract_Partpt
MachineTool.
NewProductionBegin
Product. Planner
Plan
MachineTool.
Manufacturing
[ P roductQueueEmpty ]
[ P roductionCompleted ]
ProductDone
done
MachineTool. ProductionPhaseComplt
Product.
ProdtPhaseContract_Init
[ Not ProductQueueEmpty ]
The most compact MAZBD configuration
AT2AI04 – Vienna, April 15th, 2004
6
Different Levels of Detail (2)
 ... a more detailed activity diagram
• One different swim lane for each agent behaviour
• Each activity addresses a method level entity
• Is modelling methods as activities a proper approach?
▫ Shows the object-oriented idioms to be used to effectively
represent and implement agent oriented concepts
◦ Agent has control over the life cycle of its tasks, which cannot
be accessed from the outside
◦ Tasks can use agent internal data as a common repository, to
share information among them
 A specific CASE tool should support the zooming
operation
AT2AI04 – Vienna, April 15th, 2004
7
Multi-Level Representation of Agent
Behaviour Diagram - Example
Product
ProductPlanner
ProductProdtPhaseContract_Init
MachineToolAgent
MachineTool
<<Message>>
Product.
Product
Product. setup
Product.Planner. Planner
Product.ProdtPhaseContract_Init.
ProdtPhaseContract_Init
newBehavior
Product.ProdtPhaseContract_Init.
action
Product.Planner.
action
Product.
register_to_df
Msg1 : ProductRqstConv
[ManufactRqst, RDF, ContractNet, cfp]
MachineTool.
ProdtPhaseContract_Partpt
<<Message>>
Msg2 : ProductRqstConv
[ManufactRqst, RDF, ContractNet, propose]
Product.ProdtPhaseContract
_Init. sendcfp
Product.Planner.
PhasePlanner
MachineTool.
NewProductionBegin
<<Message>>
Msg3 : ProductRqstConv
[ManufactRqst, RDF, ContractNet, accept]
[ Not ProductionCompleted ] / New Behavior
Product.Planner.
PlanManager
Product.ProdtPhaseContract_Init.
handlePropose
MachineTool.
Manufacturing
[ ProductQueueEmpty ]
ProposalEvaluationResult( Accept )
Product.ProdtPhaseContract_Init.
sendAccept
[ ProductionCompleted ]
MachineTool. ProductionPhaseComplt
done
<<Message>>
ProdtPhaseContract_Init.
handleInform
SendMsg
Msg4 : ProductRqstConv
[ManufactRqst, RDF, ContractNet, inform-done]
The MAZBD diagram with the Product agent expanded
AT2AI04 – Vienna, April 15th, 2004
8
Hierarchical Approach to Testing
 Testing activity has been divided into different steps
 Agent tests
• Black box testing of the agent behaviour: in most cases the agent
interacts with a society of other agents using communications, so
testing a behaviour consists of starting an interaction and evaluating its
result
▫ MAZBD diagrams at the agent level detail
• White box testing of the agent structure: in this case every agent’s
behaviour is seen as a black box and we test a subsystem (the agent
class and some other behaviour classes)
▫ MAZBD diagrams at the more detailed level
 Society tests
• Integration of different agents to verify their interaction (a sort of
integration testing)
• Society seen as a whole
 ...
AT2AI04 – Vienna, April 15th, 2004
9
Multi-Agent Systems
Testing Activities
 Objective: to create a support for developing tests in multiagent systems
 The approach is similar to that followed by the OO community in the
development of XUnit testing framework family
 In particular we focused our attention on the founder of that family:
JUnit a regression testing framework
 Testing of agent-based applications
 Implementation of a Testing Framework
• Objective: to execute tests in a uniform and automatic way
▫ the tests follows the same pattern of execution and produce the results in the same
format (binary i.e. passed/failed)
▫ the tests don’t require human support during execution nor to evaluate the passed/failed
condition
AT2AI04 – Vienna, April 15th, 2004
10
The Testing Framework
 Agent based framework build on top of JADE, implemented
by Telecom Italia Lab in collaboration with AOTLab of the
University of Parma
 Simply acts as a support for running tests and visualizing
results
 Binary representation of results
 Ability to report all causes of failure
 Log of all operations accomplished in three formats:
• On screen (standard output)
• On textual file (logxxx.txt)
• On html file (logxxx.html), ready to be published on the Web
AT2AI04 – Vienna, April 15th, 2004
11
Supported Tests
 The framework is based on a two level model:
 Task-tests: tests related to a specific capability of a
single agent such as the ability to create, send or
receive a specific message, to automatically reply to an
incoming request from another agent, etc…
 Agent-tests: tests related to a group of capabilities of a
single agent
AT2AI04 – Vienna, April 15th, 2004
12
The Testing Framework:
Class Diagram
Test
TestGroupExecutor
TestGroup
Abstract class that must be
behaviour
Class arepresenting
a group
of teststhat
thatexecutes
have to
extended in order to create
new Generic
the
tests
included
in
a
be executed
in sequence and require common
“Test” object. In particular
it
“TestGroup”
using a Finite State
configurations
provides methods:
Machine
 initialize()/shutdown(): methods to be
 load(): used for special
overridden to perform initializations/
initialization requirements
TestGroup
initialization
cleanings
to all tests
and to return a Behaviour
to
the “TesterAgent”
Get next Test and call
 clean(): used at the end of
its load() method
the execution of the test to
TestSuiteAgent
release resources
eventually
No more tests
Execute the
allocated A JADE GuiAgent.
test Behaviour
TesterAgent
It is
the agent responsible
 passed()/failed():
utilityof the graphical
Abstract
class
be extended
user interface.
Itmust
creates/kills
the to
methods
calledthat
from
within
Get result and
call clean()
perform
a
group
of
tests
implemented
as
an
“TesterAgents”
responsible
and
the test to declare
if it isof agent-testsTestGroup
shutdown
instance
of the
“TestGroup”
class
communicates
with
them
via ACL messages
passed
or not
The testing framework class diagram
AT2AI04 – Vienna, April 15th, 2004
13
The Testing Framework: the GUI
 Through the GUI is possible:
 to load a group of tests
 to view the task-tests in the group loaded and to select a
subset to be executed
 to give a particular configuration to the agent-tests
 to execute the tests in sequence automatically
 to have a final report indicating the number of tests
passed/failed, the time elapsed and, for each task-test
failed, the causes of failure (usually the exception
thrown)
AT2AI04 – Vienna, April 15th, 2004
14
The Testing Framework: the GUI
AT2AI04 – Vienna, April 15th, 2004
15
The Testing Framework:
Description of the Tests
 To describe the tests we use two XML files
 testerList.xml: contains the list of all agent-test that have been developed.
To be able to run a test its name must be listed in this file.
 FFFTestsList.xml: contains a list of all task-tests that are managed by the
FFFTesterAgent
 Example of AMSTestsList.xml:
<TestsList> …
<Test name="Agent creation and destruction" skip="false">
<TestClassName>test.domain.ams.tests.TestCreateKillAgent</TestClassName>
<WhatTest> Tests creating and killing agents by requesting the AMS to
perform the CreateAgent and KillAgent actions of the
JADEManagementOntology. </WhatTest>
<HowWorkTest> The test creates a remote container C1 in the load phase and
then … </HowWorkTest>
<WhenTestPass> The test passes if all the above operations have the expected
effect and no exception is thrown.</WhenTestPass>
</Test> … </TestsList>
AT2AI04 – Vienna, April 15th, 2004
16
Example
 Example of test implementation
public class TestCreateKillAgent extends Test {
…
public Behaviour load(Agent a, DataStore ds, String resultKey)
throws TestException {
…
jc = TestUtility.launchJadeInstance("Container-1", null, new String("container -host "+TestUtility.getLocalHostName()+" -port
"+String.valueOf(Test.DEFAULT_PORT)), null);
ret = Test.TEST_FAILED;
SequentialBehaviour sb = new SequentialBehaviour(a) {…}
… return sb; }
public void clean(Agent a) {
jc.kill(); }
}
AT2AI04 – Vienna, April 15th, 2004
17
Discussion and Conclusion
 MAZBD diagram
 Can be used within the existing tools of UML
 It represents a valuable support for the implementation of
MAS and the testing activity
 The testing framework represents a good tool for the
testing of MASs based on JADE
 Released as JADE add-on under LGPL licence
(http://jade.cselt.it)
AT2AI04 – Vienna, April 15th, 2004
18
Discussion and Conclusion
but ...
 more work needs to be done to gather more comments
within the FIPA community and not only …
 Open issues:
• Integration of MABD diagrams with Agent Factory to reduce
prototyping time.
• The Testing Framework now supports only agent level tests: we
are working to give a support for more complex tests (e.g.
society tests).
AT2AI04 – Vienna, April 15th, 2004
19