A Comparison between Asynchronous Backtracking Pseudocode

and its JADEL Implementation

Federico Bergenti

, Eleonora Iotti

, Stefania Monica

and Agostino Poggi

Dipartimento di Matematica e Informatica, Universit

a degli Studi di Parma, Parma, Italy

Dipartimento di Ingegneria dell’Informazione, Universit

a degli Studi di Parma, Parma, Italy

Keywords:

Asynchronous Backtracking, JADEL, Distributed Constraint Satisfaction Problems.

Abstract:

In this paper, a comparison between the pseudocode of a well-known algorithm for solving distributed con-

straint satisfaction problems and the implementation of such an algorithm in JADEL is given. First, background

and motivations behind JADEL development are illustrated. Then, we make a description of the problem and

a brief introduction to JADEL. The core of this work consists in the translation of the algorithm pseudocode

in JADEL code, which is described in details. Scope of the paper is to evaluate such a translation, in terms of

closeness to pseudocode, complexity, amount of code written and performance.

1 INTRODUCTION

JADEL (JADE Language) is an agent-oriented

domain-speciﬁc language based on JADE (Java

Agent DEvelopment framework, jade.tilab.com).

JADE (Bellifemine et al., 2005) is a software frame-

work for implementing agents and multi-agent sys-

tems, which are compliant with FIPA speciﬁca-

tions (Foundation for Intelligent Physical Agents,

2002). It consists of a middleware and it offers sev-

eral APIs and graphical tools that support multi-agent

systems development. JADE can be considered a con-

solidated tool, and it has been used for many rel-

evant applications, e.g., (Poggi and Bergenti, 2010;

Bergenti et al., 2011; Bergenti et al., 2013a; Bergenti

et al., 2014). As notable example, JADE has been in

daily use for service provision and management in

Telecom Italia for more than 6 years, serving mil-

lions of customers in one of the largest broadband

networks in Europe (Bergenti et al., 2015a). More-

over, JADE allows use of agent technology in vari-

ous areas, such as agent-based social networks mod-

eling (Bergenti et al., 2013b) and localization (Mon-

ica and Bergenti, 2016; Bergenti and Monica, 2016;

Monica and Bergenti, 2015). JADE was conceived

and developed in the early 2000’s, and its main de-

sign decisions were based on the available technolo-

gies. In particular, one of such technologies is Java,

which in those days was a novel and promising tech-

nology. Developers wanted to use Java, and the com-

mon opinion was that such a technology would have

been able to change software implementation pro-

cesses. Java represented an important step in the fast

progress of Web-oriented technologies, and it con-

tributed signiﬁcantly to the growth of the Web. In such

a context, a pure Java approach seemed to be a per-

fect solution for a software framework that aims at

becoming a solid and reliable instrument, and which

can be also compatible with most of the other new

technologies. Such a choice turned out to be suc-

cessful, and nowadays JADE is recognized as one

of the most popular FIPA compliant agent frame-

works (Kravari and Bassiliades, 2015). Nevertheless,

our experience in using agent technologies and teach-

ing it to graduate students shows a slow regression of

the use of JADE. As a matter of fact, JADE develop-

ment of multi-agent systems is often perceived as a

difﬁcult task, due to two main reasons. First, JADE

is constantly expanding and its continuous growth—

in terms of features, projects, and available APIs—

increases the complexity of the framework. For ex-

ample, there is a high number of implementation de-

tails that a developer must handle, in order to obtain a

non-trivial multi-agent system. Second, the language

that made success in the early 2000’s is now less

appealing to multi-agent system developers. In fact,

Java does not natively support agent-oriented tech-

nologies and methodologies. This is perceived as a

limitation and a source of errors. In order to address

such problems, we are working on a formal semantics

of JADE (Bergenti et al., 2015b).

JADEL project is motivated by the need of sim-

250

Bergenti F., Iotti E., Monica S. and Poggi A.

A Comparison between Asynchronous Backtracking Pseudocode and its JADEL Implementation.

DOI: 10.5220/0006205902500258

In Proceedings of the 9th International Conference on Agents and Artiﬁcial Intelligence (ICAART 2017), pages 250-258

ISBN: 978-989-758-220-2

pliﬁcation and renovation of JADE users experience.

JADEL provides abstractions and constructs which

focus on basic agent-oriented features of JADE, and it

aims at enforcing the expressiveness of such features

and simplifying the construction of multi-agent sys-

tems. A ﬁrst idea of JADEL can be found in (Bergenti,

2014), and more recent developments are discussed

in (Bergenti et al., 2016c), where an overview of

JADEL syntax and its informal semantics is presented

and a ﬁrst example is used to illustrate the described

syntax. Then, in (Bergenti et al., 2016a) and (Bergenti

et al., 2016b), the JADEL support at FIPA Interac-

tion Protocol is shown. This work shows an usage

of JADEL when the pseudocode of an algorithm is

given. The scope of such an exercise is to illustrate

the steps from pseudocode to implementation, and to

analyze the effort spent in doing such a task. Due to

the distributed nature of JADE, the algorithm chosen

as case study is a well-known procedure for solving

distributed constraint satisfaction problems.

The paper is organized as follows. First, in Sec-

tion 2, distributed constraint satisfaction problems are

deﬁned and the notation is ﬁxed. Then, in Section 3,

JADEL main abstractions and features are presented.

Section 4 shows the pseudocode together with the ac-

tual implementation, and, ﬁnally, Section 5 gives an

evaluation of the work. A brief recapitulation of the

work and its main results concludes the paper.

2 DISTRIBUTED CONSTRAINT

SATISFACTION PROBLEMS

A Constraint Satisfaction Problem (CSP) is a prob-

lem that consists in a ﬁnite set of variables and a ﬁ-

nite set of constraints over such variables, i.e., predi-

cates deﬁned on variables. As in (Yokoo et al., 1998),

we denote variables as x

, x

, . . . , x

. Each variable x

takes values in a domain, called D

. Constraints are

predicates deﬁned on D

× ··· × D

k j

, indicated by

p(x

, . . . , x

k j

). A constraint is satisﬁed if the values

assigned to its variables make the predicate true. A

CSP is solved if and only if a value is assigned to each

variable, and each assignment satisﬁes all constraints.

A Distributed Constraint Satisfaction Problem

(DCSP) is a CSP where constraints and variables are

distributed among agents. Such agents control a num-

ber of variables and they know some predicates. Each

agent ﬁnds an assignment of its variable, i.e., a pair

, d) where d ∈ D

, that satisﬁes its known con-

straints. By interacting among each others, they can

obtain the assignments performed by other agents,

and check if constraints are still satisﬁed. Informally,

a DCSP is solved if each agent ﬁnds a local solu-

tion that is coherent with other agents local solutions.

More speciﬁcally, a DCSP is solved if and only if each

agent has assigned a value to all of its variables and

all the constraints for all agents are satisﬁed by such

an assignment.

In (Yokoo and Hirayama, 2000), a survey of the

main algorithms for solving DCSPs is given. In par-

ticular, pseudocode and examples are shown for the

asynchronous backtracking, the asynchronous weak-

commitment search, the distributed breakout, and the

distributed consistency algorithms. We focus on the

asynchronous backtracking, called ABT. ABT algo-

rithm solves DCSPs that follow three assumptions:

each agent owns exactly one variable, all constraints

are in the form of binary predicates, and each agent

knows only the constraints that involve its variable.

We call x

the agent that owns the variable with the

same name. Because it is not necessarily true that

all agents in a multi-agent system know each others,

they can communicate only if there is a connection

between the sender and the receiver of the message.

For each agent, the agents who are directly connected

with it are called neighbors. In ABT, each agent main-

tains an agent view, which is the agent local view of its

neighbors assignments. Communication is addressed

by using two types of messages: OK and NoGood,

which work as instruments for exchanging knowledge

on constraints. More precisely, OK messages are used

to communicate the current value of the sender agent

variable, and NoGood messages provide the recipi-

ent with a new constraint. Agents are associated to a

priority order, which can be, e.g., the alphabetical or-

der of their names (or variables). OK messages ﬂow

from top to bottom of the priority list of agents, and

NoGood messages, instead, go up from lowest prior-

ity agents to highest ones. Core of the algorithm is the

check agent view procedure, which controls if the cur-

rent known assignments are consistent with the agent

value. If not, procedure backtrack is used to send No-

Good constraints to neighbors. The rest of the algo-

rithm is given in terms of event handling constructs

which react at other agents messages. Its pseudocode

is shown and commented in Section 4, together with

its JADEL implementation.

3 A BRIEF OVERVIEW OF JADEL

JADEL provides some main abstractions, namely,

agents, behaviours, communication ontologies, and

roles in interaction protocols.

A JADEL agent can be deﬁned by using the key-

word agent followed by its name. It has a life cy-

cle that consists in a start-up phase followed by an

A Comparison between Asynchronous Backtracking Pseudocode and its JADEL Implementation

251

execution phase and a take-down phase. In the start-

up phase the agent performs the instructions given in

its on-create handler, and in the take-down phase

it performs the instructions given in its on-destroy

handler. Usually, a sequence of tasks is added into the

internal list of the agent during its initialization, and

such tasks are performed during the execution phase.

New tasks can be added dynamically during the agent

life cycle, and old tasks can be removed. Note that, as

in JADE, agents are single-threaded entities that are

provided with an internal scheduler for the manage-

ment of their tasks. In JADE nomenclature, tasks are

called behaviours. Each behaviour describes an action

that the agent can perform. In fact, in JADEL, adding

tasks to the agent list is done by means of the expres-

sion activate-behaviour.

JADEL behaviours are associated to a type, which

can be cyclic or oneshot. Cyclic behaviours repre-

sent actions that remain in the agent behaviours list

after their execution. This means that the action of a

cyclic behaviour can be used one or more times dur-

ing agent life cycle. A one-shot behaviour, instead,

contains an action that terminates immediately and is

removed from the agent list after one execution. Ac-

tions can be triggered by the reception of a message,

which is an event, or they can start without waiting for

any event. JADEL has a speciﬁc construct for han-

dling message reception that provides also a control

over the type of message that the agent wants to re-

ceive. As a matter of fact, messages can be ﬁltered by

using message templates, so the agent can react at the

correct message.

Ontologies are used in agents communication,

providing a set of propositions, concepts, and predi-

cates. Such terms compose a sort of dictionary, which

is usually organized in a hierarchical structure. Agents

which share such a dictionary can interact by us-

ing common terms as content of their messages.

JADEL provides an entity ontology, together with

a lightweight syntax that aims at simplifying the con-

struction of such dictionaries and their usage.

Finally, JADEL provides an abstraction for man-

aging roles in interaction protocols. Roles are partic-

ular behaviours, which are composed of a set of event

handlers. Each of such handlers covers a different step

of the chosen interaction protocol, by ﬁltering mes-

sages through their performatives, as in FIPA spec-

iﬁcations. Abstractions and constructs provided by

JADEL are a minimal set of entities needed in order

to actually run a JADE multi-agent system. JADEL

sources are translated into a readable and semantically

equivalent Java code that uses JADE APIs. This en-

sures a tight integration with Java and JADE, and it

allows developers to mix JADEL entities with native

JADE source code. JADEL agents can be created by

using JADE middleware, and they rely on the solid

JADE architecture.

4 ABT PSEUDOCODE AND

JADEL IMPLEMENTATION

In this Section, the ABT pseudocode is illustrated

and compared with the respective JADEL implemen-

tation. Pseudocode is taken exactly from (Yokoo and

Hirayama, 2000). JADEL syntax and details of ABT

implementation are described together with the code.

4.1 Agents

ABT pseudocode describes event handlers and main

procedures, but it does not illustrate how agents can

be written. In JADEL, an agent must be deﬁned. Such

an agent is called ABTAgent. It consists of some prop-

erties, among which there are the agent view and the

neighbors set. The initialization of an ABTAgent is

done by ﬁlling the set of neighbors with the iden-

tiﬁers of connected agents, and by setting the prior-

ity of the agent itself. Moreover, ABTAgent provides

two important methods, namely, checkConstraints

and assignVariable. The former checks if all con-

straints are satisﬁed by current assignments in agent

view; the latter selects a value which is consistent with

agent view and assigns it to the variable owned by the

agent. Both methods return a boolean value: true if

the operation was successful and false if it is was

not.

4.2 Procedures

As said in Section 2, core of the ABT algorithm is the

check agent view procedure, which controls if the cur-

rent value my value ∈ D

of the agent x

is consistent

with its agent view. A value d ∈ D

is called consistent

with the agent view if for each value in agent view,

all constraints that involve such value and d are sat-

isﬁed. If this is not the case, the agent has to search

for another value. At the end, if none of the values

in D

satisﬁes the constraints, another procedure is

called, namely, the backtrack procedure. Otherwise,

an OK message is sent to the agent neighbors, which

contains the new assignment. The pseudocode of the

check agent view procedure is shown in Figure 1. In

JADEL implementation of ABT, the check agent view

procedure becomes a one-shot behaviour. In fact, its

action has to be performed only once, when the be-

haviour activates.

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

252

Procedure check agent view

when agent view and my value are inconsistent do

if no value in D

is consistent with agent view

then

backtrack

else

select d ∈ D

where agent view and d are con-

sistent

my value ← d

send(OK, (x

, d)) to neighbors

end if

end do

Figure 1: Procedure check agent view.

oneshot behaviour Chec kA ge nt Vi ew

for A BTA ge n t {

The keyword for denotes which agents are allowed to

activate such a behaviour. In this case, such agents are

instances of the ABTAgent class. Inside the behaviour,

methods and public ﬁelds of the agent can be called

by using the ﬁeld theAgent, which is implicitly ini-

tialized with an instance of the agent speciﬁed. If no

agent is speciﬁed with the for keyword, theAgent

refers to a generic agent.

The CheckAgentView behaviour does not need to

wait for messages, or events, so the keyword do is

used. It denotes an auto-triggering action.

do {

if(! t he A ge nt . c he ck Co ns t r a i n ts () ) {

if(! t he A ge nt . a ss ig nV ar ia bl e () ) {

activate behaviour

Ba ckt ra ck ( t he A ge nt )

} else {

activate behaviour

Sen dOK ( t he Age nt )

}

The procedure backtrack is deﬁned in Figure 2. First,

a new NoGood constraint has to be generated. Gen-

erating a NoGood is done by checking all assign-

ments that are present into the agent agent view. If

one of these is removed, and then the agent succeeds

in choosing a new value for its variable, it means that

such an assignment is wrong. Hence, that assignment

is added to the NoGood constraint. After this phase,

the new generated NoGood can be empty or not. If no

assignment appears within that new constraint, then

there is no solution for the DCSP. Otherwise, a No-

Good message has to be sent to the lowest priority

agent, and then its assignment has to be removed from

agent view. Then, a ﬁnal check of the agent view is

Procedure backtrack

generate a nogood V

when V is an empty nogood do

broadcast to other agents that there is no solution

terminate this algorithm

end do

select (x

, d

) where x

has the lowest priority in a

nogood

send(nogood, (x

, V )) to x

remove (x

, d

) from agent view

check agent view

Figure 2: Procedure backtrack.

done. JADEL implementation of such a procedure is

another one-shot behaviour, whose code follows pre-

cisely the pseudocode in Figure 2.

oneshot behaviour Ba ckt ra ck

for A BTA ge n t {

do {

var V = new HashMa p <AID , In teger >(

th eAg en t . ag e nt vi ew )

var s or te d Va ri ab le sL i s t = V . ke ySe t .

sort

V. re m ov e ( t he Ag e nt . AID )

for( v : s or te dV ar ia b l e sL is t ) {

var r e mo ved = V . r em o ve (v )

if( the Ag ent . as si gn Va ri ab le (V ) )

V. put (v , re m ov ed )

}

if( V. is Emp ty ){

activate behaviour

Se nd No So lu ti on ( t he Ag e nt )

} else {

activate behaviour

Se nd NoG oo d ( theAg ent , V )

th eAg en t . ag e nt vi ew . re mov e ( V .

key Set . max )

activate behaviour

Ch ec kA ge nt Vi ew ( t he Ag e nt )

}

4.3 Event Handlers

Others procedures speciﬁed in Yokoo ABT pseu-

docode concern the reception of messages.

When the agent receives an OK message, it has to

update its agent view with that new information, then

it must check if the new assignment is consistent with

others in agent view, as in Figure 3. The reception of

a message requires a cyclic behaviour, which waits

A Comparison between Asynchronous Backtracking Pseudocode and its JADEL Implementation

253

when received (OK, (x

, d

)) do

revise agent view

check agent view

end do

Figure 3: Reception of an OK message.

cyclically for an event and checks if such an event is

a message.

cyclic behaviour Re cei ve Ok

for A BTA ge n t {

To ensure that such a message is the correct one,

namely, an OK message, some conditions have to be

speciﬁed. JADEL provides the construct on-when-do

to handle this situation. The clause on identiﬁes the

type of event and eventually gives to it a name. If the

event is a message, the clause when contains an ex-

pression that ﬁlters incoming messages.

on message msg

when {

ontology is ABT Ont o and

performative is INF ORM and

content is OK

}

Conditions in when clause can be connected by log-

ical connectives and, or, and they can be preceded

by a not. They refer to the ﬁelds of the message,

namely, ontology, performative, and content.

Fields that are not relevant can be omitted, and

multiple choices can be speciﬁed. For example a

behaviour can accept REQUEST or QUERY IF mes-

sages, as follows: performative is REQUEST

or performative is QUERY IF. The clause do

is mandatory and contains the code of the action.

do {

extract r ec e iv ed OK as OK

val a = r ec eiv ed OK . a ss ig nm ent

th eAg en t . ag e nt vi ew . r epl ace ( a . index ,

a. val ue )

activate behaviour

Ch ec kA ge nt Vi ew ( t he Ag e nt )

}

The content of the message is obtained by means

of the JADEL expression extract-as, which man-

ages all the needed implementation details and gives

a name and a type to the content. Once the content

of type OK of the message is obtained, its assignment

when received (nogood, (x

, V )) do

record V as a new constraint

when V contains an agent x

that is not its neigh-

bor do

request x

to add x

as a neighbor

add x

to its neighbor

end do

old value ← current value

check agent view

when old value = current value do

send(OK, (x

, current value)) to x

end do

Figure 4: NoGood message reception.

is used to revise the agent view. Then, the behaviour

CheckAgentView is activated.

Finally, the pseudocode of the procedure that man-

ages the reception of a NoGood message is shown in

Figure 4. In JADEL, such a procedure is a cyclic be-

haviour for ABTAgent.

cyclic behaviour Re ce iv eN oG oo d

for A BTA ge n t {

Checking if the event is a message, and then, if the

message is actually a NoGood message, is done simi-

larly to the OK reception, by using the clauses on and

when, as shown in the following code.

on message msg

when {

ontology is ABT Ont o and

performative is INF ORM and

content is NoG ood

}

Inside the do body, the message content is extracted

as a NoGood and it is recorded as a new constraint.

We assume that the agent holds a set of constraints

within the ﬁeld constraint which is accessed by the

agent instance theAgent.

do {

extract r ec ei ve dN oG oo d as N oGo od

val n ew Co ns tr ai nt s = re ce iv ed No Go od .

as si gn me nt Li st

th eAg en t . co ns tr a in ts .

put All ( n e w C o n s t r a i n t s )

Then, if some constraints involve an agent which is

not in the agent neighborhood, a request is sent to

such an agent, in order to create a new link.

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

254

for ( x : ne wC on st ra in ts . key S et ) {

if (! t heA ge nt . n eig hb or s .

co nta in s ( x) ) {

activate behaviour

Se nd Re que st ( t heAgen t , x )

th eAg en t . ne i gh bo rs . add ( x )

}

Finally, the agent view must be checked, and if the

previous value of the agent variable x

remains un-

changed, an OK message is sent.

var o ldV al u e = t he Ag e nt . a ge nt v ie w .

get ( th e Ag ent . AID )

activate behaviour

Ch ec kA ge nt Vi ew ( t he Ag e nt )

if ( ol dV alu e == t heA ge nt . a gen tv ie w .

get ( the Ag ent . AID )) {

activate behaviour

Sen dOK ( t he Age nt )

}

5 EVALUATION

The comparison between ABT pseudocode and its

JADEL implementation is done by deﬁning some

metrics, which help us to get an idea of JADEL

advantages and disadvantages. Then, we compare

JADEL code with an equivalent JADE code, measur-

ing the amount of code written, and the percentage

of domain-speciﬁc features of such a code. Finally,

we shows an example of usage of ABT algorithm and

we measure the time of execution of JADEL, and the

number of messages exchanged.

Methods to evaluate domain-speciﬁc modeling

languages can be found in, e.g., (Challenger et al.,

2015), which focuses on multi-agent systems. Other

surveys, such as (Mernik et al., 2005) and (Oliveira

et al., 2009), highlight the main advantages of

domain-speciﬁc languages usage. Nevertheless, com-

paring a pseudocode with an actual implementation

is a difﬁcult task, due to the informal nature of the

pseudocode, and the implicit technical details it hides.

Moreover, pseudocodes from different authors may

look different, depending on their syntax choices and

their purpose. As far as we know, there are not stan-

dard methods for evaluating the closeness of a code

to a pseudocode, and its actual effectiveness in ex-

pressing the described algorithm. Hence, we limit our

evaluation to the use case of JADEL shown in this pa-

per: the ABT example presented in previous sections.

This choice permits us to make some considerations

about the pseudocode.

First, ABT pseudocode is presented by means of

procedures and event handlers, with the aid of the key-

words when and if. Second, the notation used inside

the ABT pseudocode is the same of the DCSP for-

malization, shown in Section 2. As a matter of fact,

there are agentview and neighbors sets, and assign-

ments are denoted as (x

, d

), where x

is the vari-

able associated with the i-th agent, and d

∈ D

. A

message is identiﬁed according to its type and its

content, i.e., (OK, (x

, d

)) for an OK message, or

(nogood, (x

, V )) for a NoGood. Such characteristics

of ABT pseudocode allow us to talk about ‘similar-

ity’ between it and the JADEL code. In fact, in the

JADEL methodology, both procedures and event han-

dlers are represented as behaviours of the agent. In

particular, procedures are one-shot behaviours that

deﬁne an auto-triggering actions, while event han-

dlers are cyclic behaviours, each of them waits for the

given event and then performs its action. Hence, we

can associate each behaviour with a procedure/event

handler, and analyze each of them separately. Calls

of procedures in ABT pseudocode translate into the

activation of the corresponding behaviour in JADEL.

Also sending a message is done by activating a spe-

ciﬁc JADEL behaviour. Hence, we associate each

send instruction in ABT pseudocode to that activa-

tion. The DCSP notation is used also in JADEL, by

means of the two mappings theAgent.agentview and

theAgent.neighbors, and by deﬁning some ontology

terms. As a matter of fact, terms OK and NoGood

are predicate in a JADEL ontology, and they con-

tain an assignment, and a list of assignments, re-

spectively. Each assignment consists in a index and

a value, i.e., x

and d

, respectively. Index and vari-

ables are intentionally confused because we identify

each agent with its variable. The domain D

of a vari-

able is deﬁned once in the start-up phase of the agent

and it is never modiﬁed during the execution of its ac-

tions. We associate ABT pseudocode notations with

the respective JADEL notation described above. Fi-

nally, the reception of a message is done by using the

construct on-when-do, which is the corresponding of

ABT pseudocode construct when received(. . . ) do.

In summary, (i) ABT procedures are associated

with JADEL oneshot behaviours, (ii) ABT event han-

dlers are associated with JADEL cyclic behaviours,

(iii) procedure calls and send instructions are asso-

ciated with the correct behaviour activation, (iv) ref-

erences to agentview or agent neighborhood are as-

sociated with the respective JADEL agent ﬁelds, (v)

receptions of messages are associated with JADEL

constructs and expressions that concern reception and

A Comparison between Asynchronous Backtracking Pseudocode and its JADEL Implementation

255

Table 1: Metrics for distance between ABT pseudocode and JADEL implementation in terms of number of LOCs, and their

complexity in terms of depth. The depth of an equivalent JADE implementation is also shown.

Distance Complexity

(LOCs) ABT JADEL JADE

Check Agentview 2 2 3 5

Backtrack 6 1 3 6

Receive OK 6 1 1 4

Receive NoGood 7 2 3 4

Table 2: Number of LOC and percentage of Agent-Oriented (AO) features over the total number of LOC, for JADEL and

JADE implementation of the ABT example.

JADEL

ABTAgent ABTOntology Behaviours

LOCs 57 7 138

AO (%) 12 86 41

JADE

ABTAgent ABTOntology Behaviours

LOCs 149 113 380

AO (%) 6 23 20

content extraction from a message. We will say, in

the following, that a line of ABT pseudocode cor-

responds to a line (or, a set of lines) of JADEL im-

plementation, if it falls in one of the previous cases.

Then, for each line of ABT pseudocode, we mea-

sure the number of the corresponding Lines Of Code

(LOC) of JADEL implementation. The absolute value

of the difference between ABT lines and correspond-

ing JADEL LOC is used as a ﬁrst, rough, distance.

For example, in the reception of an OK message,

the ﬁrst line of the pseudocode corresponds to the

on-when-do constructs to capture the correct event.

on message msg

when {

ontology is ABT Ont o and

performative is INF ORM and

content is OK

}

Moreover, the extract-as expression is used to ob-

tain the message content.

extract r ec eiv ed OK as OK

Hence, we can conclude that in this case there are six

LOCs instead of one line of the pseudocode. Thus, the

distance is of 5 LOCs. Such a distance gives us an idea

of the amount of code which is necessary to translate

pseudocode into JADEL, in case of ABT example. A

summary is shown in Table 1.

Then, we want to quantify the ‘complexity’ of the

code. In fact, JADEL code sounds similar to ABT

pseudocode also because of its structure. We use the

depth of each block of code as a measure. As we

can see in Table 1, ABT pseudocode and JADEL

implementation do not differ signiﬁcantly in terms

of complexity. To this extent, JADEL code often re-

quires one more level (the do block), but its struc-

ture is usually very similar to ABT pseudocode. The

complexity measure makes sense when JADEL code

is compared to the equivalent JADE one. Such an

equivalent implementation is obtained directly from

JADEL compiler, which translates JADEL code into

Java and uses JADE APIs. In fact, JADEL enti-

ties translate into classes which can extend JADE

Agent, CyclicBehaviour, OneShotBehaviour, and

Ontology base classes, while JADEL event handlers

translate into the correct methods of JADE APIs, in

order to obtain the desired result. JADE code is au-

tomatically generated from the JADEL one, and this

means that the ﬁnal code may introduce some redun-

dancy or overhead. For this reason, we also write a

JADE code that implements ABT algorithm directly.

Nevertheless, this alternative implementation is as

complex as JADE generated code, because of some

implementation details that JADE requires.

A comparison between JADEL and JADE imple-

mentation is made in terms of amount of code, i.e.,

by counting the number of non-comment and non-

blank LOCs of each entity, namely, the ABTAgent,

the ABTOntology, and all the behaviours. Results are

shown in Table 2. In order to emphasize the advan-

tage in using JADEL instead of JADE, the percent-

age of lines which contains Agent-Oriented (AO) fea-

tures over the total number of LOCs is also shown.

We deﬁne as AO features each reference to the agent

world. For example, keywords agent, behaviour,

ontology are AO features, but also special expres-

sions such as activate-behaviour. In JADE, AO

features are simply the calls to the API. Table 2

shows that the JADEL implementation is far more

lighter than the JADE one, and that it is denser of

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

256

Table 3: Average number of messages exchanged, average elapsed time of execution, and average total number of assignments

of the n-queens problem, for n = 4, 5, 6, 7, 8.

# of Queens Avg. # of Messages Avg. Elapsed Time (ms) Avg. # of Assignments

4 20.54 132.05 11.68

5 15.44 113.19 9.40

6 37.00 236.50 17.00

7 63.63 462.25 32.50

8 197.00 1178.50 77.50

AO features. Such measures can be viewed as an in-

dication of simplicity of JADEL code with respect

to JADE. Finally, we test JADEL implementation of

ABT algorithm on a well-known example of DCSP.

As in (Yokoo et al., 1992), we use ABT for solving

the n-queens problem. The n-queens problem consists

in placing n pieces of chess queens on a n × n chess-

board, so that each queen is safe from others. A solu-

tion of such a problem requires, in fact, that a queen

does not share a row, a column or a diagonal with

any other queen on the chessboard. Formalizing the

n-queens problem needs the use of an agent for each

queen, and the association of each queen to a row of

the chessboard (equivalently, a column). So, the i-th

queen, represented by the variable x

, slides on the i-th

row. This means that the variable x

takes values into

= {1, . . . , n}. Hence, the constraints are formalized

as follows. For each x

, x

, the following inequalities

need to hold: x

6= x

and |x

−x

| 6= |i− j|. The imple-

mentation in JADEL of such a problem requires only

to extend the ABTAgent entity, deﬁning the new con-

straints into the checkConstraints method of the

agent, as follows.

boolean c he ck Co ns tr a i n ts () {

if (! c h ec kN oG oo d C o ns tr ai nt () ) {

return fa lse

}

for( i : 0 .. < my I nd ex ) {

var key = s or te dA ge nt s . g et (i )

if ( a g en tv iew . co n ta in sK ey ( key ) ) {

val va lue = ag ent vi ew . get ( ke y )

if ( my Val ue == v alu e || ( Ma th .

abs ( myV alu e - v alue ) == Math .

abs ( myI nde x - i) ) ) {

return fa lse

}

return tru e

}

We measure the effectiveness of the algorithm in

terms of number of messages and time. Distributed

systems are evaluated by means of their usage of

memory, the time of execution, and the amount of

messages exchanged, but we can only measure those

last two parameters, due to the garbage collector of

Java, that falsify the actual memory usage. Then, an

evaluation of the effectiveness of ABT implementa-

tion is given in terms of the number of assignments

that each agent performs during the computation. Re-

sults are shown in Table 3.

6 CONCLUSIONS

In this paper, a comparison between the implementa-

tion of ABT algorithm with the novel agent-oriented

language JADEL and the ABT pseudocode is shown.

First, JADEL and JADE are brieﬂy presented, then

DCSP problems and ABT algorithm notations are de-

ﬁned and described. Given the ofﬁcial presentation of

ABT pseudocode, we made a point-to-point transla-

tion of such a pseudocode in JADEL. Finally, some

metrics are deﬁned and some measurements are made

in order to evaluate the effectiveness of the language

in such a context, and its closeness to ABT pseu-

docode. The proposed metrics are (i) a measure of dis-

tance, in terms of LOCs, between ABT pseudocode

and its JADEL implementation, (ii) a measure of com-

plexity, based on the depth of the block of codes, (iii)

the number of LOCs and the percentage of AO fea-

tures of JADEL code and JADE equivalent, and (iv)

the average number of messages and time of execu-

tion of JADEL version of ABT, when used for solving

the n-queens problem, for n = 4, 5, 6, 7, 8.

Not all of such metrics can be interpreted as com-

plete or signiﬁcant in every situation, because they

cannot fully describe qualitative factors, such as read-

ability, re-usability or maintainability. In fact, dis-

tance and complexity can be different depending on

the type of pseudocode given, and there is not a stan-

dard way for evaluating pseudocodes due to their in-

herent informality. Also, numbers of LOCs and per-

centage of AO features do not refer to the quality

of the code. However, such measurements help us in

evaluating simplicity and giving an idea of the ex-

pressiveness and effectiveness of the language. As a

matter of fact, JADEL distance from pseudocode is

very small, and we argue that this fact may help devel-

opers in translating an idea of distributed algorithms

into a working JADE multi-agent system. When cod-

ing it directly in JADE, in fact, the number of LOCs

A Comparison between Asynchronous Backtracking Pseudocode and its JADEL Implementation

257

required increases considerably, making its distance

from pseudocode very high. This is mainly due to the

very high number of implementation details that hide

behind JADEL code, and the structure itself of Java

language and JADE APIs. In summary, JADE obtains

good results in simplifying and shortening the task of

writing code. Then, as a last evaluation, the metrics

for distributed systems are used, showing good per-

formance of the language. When using JADE instead

of JADEL, the number of messages is about the same,

while the performance is slightly better, due to the re-

dundancy and overhead introduced by JADEL com-

piler in generating Java code.

As a future development of this work, JADEL can

be tested on other algorithms, making other compar-

ison between pseudocodes and JADEL code, in or-

der to gain a more complete view. Moreover, other fa-

mous agent-oriented programming languages, such as

3APL, Jason, SARL, can be compared with JADEL,

in terms of translating a given pseudocode. Finally,

the best evaluation could be that of JADE developers,

when JADEL will be released. In summary, this pa-

per takes place into a larger project of presentation of

JADEL and evaluation of its possibilities. This work

shows how to produce JADEL code from a pseu-

docode and measures how simple or complex this task

can be.

REFERENCES

Bellifemine, F., Bergenti, F., Caire, G., and Poggi, A.

(2005). JADE – A Java Agent DEvelopment frame-

work. In Multi-Agent Programming. Springer.

Bergenti, F. (2014). An introduction to the JADEL program-

ming language. In Procs. IEEE 26

Int’l Conf. on

Tools with Artiﬁcial Intelligence (ICTAI). IEEE Press.

Bergenti, F., Caire, G., and Gotta, D. (2013a). An overview

of the AMUSE social gaming platform. In Procs.

Workshop Dagli Oggetti agli Agenti (WOA 2013), vol-

ume 1099 of CEUR Workshop Proceedings.

Bergenti, F., Caire, G., and Gotta, D. (2014). Agents on the

move: JADE for Android devices. In Procs. Workshop

Dagli Oggetti Agli Agenti (WOA 2014), volume 1260

of CEUR Workshop Proceedings.

Bergenti, F., Caire, G., and Gotta, D. (2015a). Large-scale

network and service management with WANTS. In

Industrial Agents: Emerging Applications of Software

Agents in Industry. Elsevier.

Bergenti, F., Franchi, E., and Poggi, A. (2011). Agent-based

social networks for enterprise collaboration. In Procs.

Int’l Conf. Enabling Technologies: Infrastructure

for Collaborative Enterprises (WETICE 2011). IEEE

Press.

Bergenti, F., Franchi, E., and Poggi, A. (2013b). Agent-

based interpretations of classic network models. Com-

putational and Mathematical Organization Theory,

19(2).

Bergenti, F., Iotti, E., Monica, S., and Poggi, A. (2016a).

A case study of the JADEL programming language.

In Procs. Workshop Dagli Oggetti agli Agenti (WOA

2016), volume 1664 of CEUR Workshop Proceedings.

Bergenti, F., Iotti, E., Monica, S., and Poggi, A. (2016b).

Interaction protocols in the JADEL programming lan-

guage. In Procs. 6

Int’l Workshop on Programming

Based on Actors, Agents, and Decentralized Control

(AGERE!).

Bergenti, F., Iotti, E., and Poggi, A. (2015b). Outline of a

formalization of JADE multi-agents system. In Procs.

Workshop Dagli Oggetti agli Agenti (WOA 2015), vol-

ume 1382 of CEUR Workshop Proceedings.

Bergenti, F., Iotti, E., and Poggi, A. (2016c). Core fea-

tures of an agent-oriented domain-speciﬁc language

for JADE agents. In Trends in Practical Applications

of Scalable Multi-Agent Systems, the PAAMS Collec-

tion. Springer.

Bergenti, F. and Monica, S. (2016). Location-Aware Social

Gaming with AMUSE. In Trends in Practical Appli-

cations of Scalable Multi-Agent Systems, the PAAMS

Collection (PAAMS 2016).

Challenger, M., Kardas, G., and Tekinerdogan, B. (2015).

A systematic approach to evaluating domain-speciﬁc

modeling language environments for multi-agent sys-

tems. Software Quality Journal.

Foundation for Intelligent Physical Agents (2002). FIPA

speciﬁcations. Multi-agents system standard speciﬁ-

cations. http://www.fipa.org/specifications.

Kravari, K. and Bassiliades, N. (2015). A survey of agent

platforms. Journal of Artiﬁcial Societies and Social

Simulation, 18(1).

Mernik, M., Heering, J., and Sloane, A. M. (2005). When

and how to develop domain-speciﬁc languages. ACM

computing surveys (CSUR), 37(4).

Monica, S. and Bergenti, F. (2015). Location-aware JADE

agents in indoor scenarios. In Procs. Workshop Dagli

Oggetti agli Agenti (WOA 2015), volume 1382 of

CEUR Workshop Proceedings.

Monica, S. and Bergenti, F. (2016). A comparison of accu-

rate indoor localization of static targets via WiFi and

UWB ranging. In Advances in Intelligent Systems and

Computing (PAAMS 2016), Special Session on Agents

and Mobile Devices (AM).

Oliveira, N., Pereira, M. J., Henriques, P., and Cruz, D.

(2009). Domain speciﬁc languages: A theoretical sur-

vey. In INFORUM’09 Simp

osio de Inform

atica. Fac-

uldade de Ci

encias da Universidade de Lisboa.

Poggi, A. and Bergenti, F. (2010). Developing smart emer-

gency applications with multi-agent systems. Int. J.

E-Health Med. Commun., 1(4).

Yokoo, M., Durfee, E. H., Ishida, T., and Kuwabara, K.

(1998). The distributed constraint satisfaction prob-

lem: Formalization and algorithms. IEEE Transac-

tions on Knowledge and Data Engineering, 10(5).

Yokoo, M. and Hirayama, K. (2000). Algorithms for dis-

tributed constraint satisfaction: A review. Autonomous

Agents and Multi-Agent Systems, 3(2).

Yokoo, M., Ishida, T., Durfee, E. H., and Kuwabara, K.

(1992). Distributed constraint satisfaction for formal-

izing distributed problem solving. In Procs. 12

Int’l

Conf. Distributed Computing Systems. IEEE Press.

ICAART 2017 - 9th International Conference on Agents and Artiﬁcial Intelligence

258