Using GDT4MAS as a Formal Support for Engineering Multi-Agents
Systems
Bruno Mermet and Ga¨ele Simon
GREYC-UMR 6072 and University of Le Havre, Universit´e de Caen Basse-Normandie,
Campus Cˆote de Nacre, Boulevard du Mar´echal Juin, 14032, CAEN cedex 5, France
Keywords:
Agent-oriented Software Engineering, Formal Specification, Formal Verification.
Abstract:
This paper focuses on multi-agent systems engineering process. An assessment of current needs in this do-
main, based on the analysis of systems already developed, is performed. This assessment shows that the formal
verification of MAS is one of these needs. It is then shown how the formal approach GDT4MAS provides
answer to many of the other needs. This approach is based on a MAS formal specification associated to a
proof process allowing to establish the correctness of properties of the system. The main purpose of this pa-
per is to show that, unlike most other formal approaches for MAS, GDT4MAS can at the same time propose
formal aspects making a proof possible and contribute to different general aspects of agent-oriented software
engineering, even when formal verification is not a concern.
1 INTRODUCTION
Most failures in software development are a con-
sequence of miss-adapted methodologies or of the
weaknesses of tools that are used. In the domain
of standard software, recent years led to the design
of new methodologies (relying on the agile concepts)
and to the development of new tools to reduce the ra-
tio of unsucessful developments (Beck et al., 2001;
Martin, 2009).
However, as it has been explained in other
works (Ahmad and Rahimi, 2009), Multi-Agent Sys-
tems are specific softwares and require their own
methods and tools. Moreover, we are mainly inter-
ested in formal specification and formal verification,
and these techniques, which are also very specific, re-
quire their own methods and tools.
This led to the design of the GDT4MAS method
and model, presented in (Mermet and Simon, 2009).
GDT4MAS proposes its own language to specify, de-
sign and implement MAS. But, as this model relies on
concepts that are shared by most MAS architectures,
it provides characteristics that may be useful for any-
one interested in the development of MAS, even for
people that are not interested in formal methods.
The goal of this article is then to show how
GDT4MAS tackles many requirements that are ex-
hibited by several works dealing with Agent Oriented
Software Engineering and why using GDT4MAS
may help MAS designers.
In the next section, we present the concepts of
GDT4MAS that must be known to understand this ar-
ticle. In section 3, we explain why it may be interest-
ing to verify Multi-Agent Systems, and we show why
GDT4MAS is a good candidate to perform such a
task. Then, we explain how this model helps in the de-
velopment process where several kinds of stakehold-
ers take place. Section 5 presents how incremental de-
velopment can be instanciated thanks to GDT4MAS.
In the next section, it is shown how several kinds of
MAS architectures can be modeled thanks to the ex-
pressiveness of GDT4MAS.
2 GDT4MAS
2.1 Main Concepts
We only summarize here the essential parts of
GDT4MAS.More details can be found in (Mermet
and Simon, 2009; Mermet and Simon, 2011; Mermet
and Simon, 2013).
When specifying MAS with GDT4MAS, 3 parts
have to be specified: the environment, the types of
agents and the agents themselves, that are instances of
each type of agent, with specific initialisation values.
In the sequel, we briefly present these different parts.
407
Mermet B. and Simon G..
Using GDT4MAS as a Formal Support for Engineering Multi-Agents Systems.
DOI: 10.5220/0005556904070412
In Proceedings of the 10th International Conference on Software Engineering and Applications (ICSOFT-EA-2015), pages 407-412
ISBN: 978-989-758-114-4
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
The environment is specificied by a set of typed
variables and an invariant property i
E
.
The type of an agent is specified by a set of typed
variables, an invariant and a behaviour.
The behaviour of an agent is mainly defined by a
Goal Decomposition Tree (GDT). The GDT is a tree
of goals, whose root corresponds to the main goal
of the agent (in the standard version of GDT4MAS,
agents have only one main goal). A plan is associated
to each goal. Such a plan, when executed with suc-
cess, must achieve the goal and is expressed either by
a single action of by a set of subgoals linked together
by a decomposition operator.
A goal G is mainly described by a name n
G
, a sat-
isfaction condition sc
G
and a guaranted property in
case of failure gpf
G
.
The satisfaction condition (SC) of a goal is spec-
ified formally by a formula that is satisfied when the
execution of the goal succeeds. On the other hand,
the GPF of a goal specifies what happens when a goal
execution fails (of course, it is meaningless for an NS
goal, that is to say a goal that always succeed).
SC and GPF are state transition formulae (STF),
because they express a relation between two states,
called initial state and final state. In the sequel, we
will use the term non-deterministic state transition
formula when for a given initial state, several final
states satisfy the STF. For example, formula x
> x is
a non-deterministic STF because, for a given initial
state (x = 0 for instance), several final states (x
= 2,
x
= 10) satisfy the formula.
2.2 GDT Example
Figure 1 shows an example of GDT. The goal of this
behaviour is to light a given room n (n is a parameter
of the GDT). In order to do that, the agent tries to
enter into the room. As a cellular eye detects when
someone enters into the room and switches the light
on, this looks like a suitable plan. However, if the
cellular eye does not work as expected (this is why
the goal Entering into the room is NNS, i.e. not NS),
the agent will have to use the switch. More details can
be found in (Mermet and Simon, 2013)
2.3 Agents
Agents are specified as instances of types of agents,
with effective values for the agent type parameters.
2.4 Proof Principles
The proof mechanism provided by GDT4MAS aims
at proving the following properties: agents pre-
Figure 1: Example of a GDT.
serve invariant properties (Mermet and Simon, 2013),
agents behaviour are sound, that is to say, plans asso-
ciated to goals are correct and agents achieve liveness
properties that may be associated to their agent type.
Moreover, this proof mechanism relies on a few
important principles: proof obligations (properties to
be proven) can be generated automatically from a
GDT4MAS specification, proof obligations are ex-
pressed in first-order logic and can be verified by any
adequate automatic theorem prover and finally, the
proof system is compositional: the proof of the cor-
rectness of an agent is decomposed into several small
independent proof obligations.
2.5 Holonic GDT4MAS
An extension of GDT4MAS has been presented
in (Mermet and Simon, 2011), where it has been
shown that the execution of the goal of an agent can
be performed thanks to several sub-agents (a holonic
agent is itself made of sub-agents).
Figure 2 illustrates the usage of the ParAnd opera-
tor. The root goal in this figure corresponds to one of
the goals of a holonic agent. To achieve this goal, two
sub-agents, A
1
and A
2
, represented by hexagons, are
started by the holonic agent. A
1
(whose behaviour is
described by a GDT that is not presented here) tries to
achieve its main goal, whose satisfaction condition is
SC
1
and A
2
tries to achieve a goal whose satisfaction
condition is SC
2
. If either A
1
or A
2
fails, the execu-
tion of the other sub-agent is stopped. But if both sub-
agents achieve their main goal, then the parent goal is
achieved.
Figure 2: Example of a holonic agent.
ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications
408
3 VERIFICATION OF AGENT
BEHAVIOURS
For more than ten years, many papers have focused
on the necessity to bring guarantees on the correct-
ness of multi-agents systems. Indeed, it appears that it
is one of the main reasons explaining the small accep-
tance of MAS in industry (Ahmad and Rahimi, 2009).
Moreover, it is also established that formally verifying
MAS is certainly the adequate solution (Demazeau,
2004).
However, papers dealing with formal specification
of MAS are scarce, for several reasons:
formally verifying MAS is a very hard problem.
Indeed, formal verification of standard software
is already a complex problem, and solutions pro-
vided by formal methods cannot be applied to
whole huge systems. So, as MAS are more com-
plex systems, trying to formally verifying them
seem vain for many people.
Most MAS formal verification systems con-
sider verifying the whole system behaviour (as
METATEM for instance (Fisher, 2006)), which
is certainly a too complex task on real-size sys-
tems. On Standard softwares, formal verifica-
tion generally concern only the safety core of the
sofware (Abrial, 1996); So, trying to apply formal
verification techniques to whole MAS is likely to
lead to failure.
Many formal verification works use a dedicated
specification language that is only used for the
specification and for the verification and then, the
system must be implemented in a traditional pro-
gramming language. As a consequence, they may
be few links between the verified specification and
the implemented program (Ahmad and Rahimi,
2009; Abrial, 1996).
Trying to reuse standard formal verification meth-
ods to MAS leads to defeat. In particular, the au-
tonomy of agents is not consistent with the main
concepts of these tools: indeed, standard formal
methods rely on the fact that the whole system is
known when the verification is performed (Abrial,
1996). This is not suitable to MAS, where au-
tonomous agents can be part of the system.
most work so far dealing with formal verification
of MAS rely on model-checking (Raimondi and
Lomuscio, 2004; Kacprzak et al., 2004), which
is not the most suitable choice in most cases. In-
deed, model-checking is a verification mechanism
that is mainly dedicated to finite-state systems, as
it consists in an exhaustive test of the system. But
in multi-agent systems, as agents actions are in-
terlaced, studying the whole set of possible traces
is most of the time not feasible.
GDT4MAS clearly proposes a solution to the first
problem, as it is a method designed to perform formal
verification.
Moreover, when using GDT4MAS, it is easy to
formally specify and verify safety parts, while not
verifying less essential parts. Of course, in this lat-
ter case, the correctness is established under the as-
sumption that non-formalized parts are correct. This
clearly provides a solution to the second problem.
An other important characteristics of GDT4MAS
is that a generalized translation system of a
GDT4MAS specification in any imperative language
using automata has been designed (and formally veri-
fied), and a version for Java as been implemented. So,
the verified specification can be automatically trans-
lated into Java to be executed, or to interact with other
Java programs. As a consequence, the formal speci-
fication need not to be transcripted by hand in a pro-
gramming language.
In addition, as GDT4MAS has been designed to
verify MAS, the autonomy of agents is well taken
into account. Verification of agents are performed
independently of the other agents, and only proofs
depending on agents interactions (based on external
goals) take into account the instances of agent types.
Finally, GDT4MAS relies on theorem proving,
that seems, for us, to be a quite better solution than
model-checking. Indeed, model-checking is well
suited for finite-state systems, which is not true for
MAS. When considering the potential huge number
of agents in a MAS, and the massive distributed as-
pect that it implies, it greatly reduces the potential ap-
plications of techniques relying on model-checking.
To conclude, GDT4MAS proposes a wide-
purpose method, going from the early specification to
the executable code via formal verification.
4 SEPARATION OF
ENGINEERING TASKS
During the whole development process of a software,
several tasks have to be performed, and these tasks
may be devoted to different persons, according to
their skills. In standard software development pro-
cesses, the following tasks are often distinguished:
requirement engineering, design (preliminary and de-
tailed), implementation and test. When dealing with
formal verification, an other task must be added: the
verification task. However, the way the result of each
task is used by the others is often fuzzy.
UsingGDT4MASasaFormalSupportforEngineeringMulti-AgentsSystems
409
Distinguishing tasks and roles is a very important
point in a software developmentprocess, for two main
reasons:
it helps in scheduling the development process
and in parallelizing work;
it helps in attributing to each stakeholder the most
suitable tasks.
When using GDT4MAS, the development process
is also decomposed into several steps:
the first step consists in determining agent types
(with their capabilities) and environment vari-
ables;
the second step consists in specifying the root
goals and the variables of the agent types;
the third step consists in progressively decompos-
ing goals of agents into sub-goals.
These steps matched more or less the requirement
engineering, preliminary design and detailed design
tasks. The implementation task is missing because it
may be performed automatically at the end of the third
step.
The formal aspects can be handled in parallel dur-
ing each step:
during the first step, it consists in formally speci-
fying the environment invariant and the agent ac-
tions;
during the second step, it consists in formally
specifying the main goal (satisfaction condition
and gpf) of each agent type and the invariant of
each agent type;
during the third step, it consists in formally spec-
ifying each subgoal, and in verifying invariants
and goal decompositions.
The fact that formal aspects may be isolated from
the rest is very important. Indeed, a developer is sel-
dom at ease with formal methods, and a method that
clearly separates the formal aspects from the other
tasks has greater chances to please. Indeed, an indus-
trial firm may continue to use the skills of its employ-
ees, and only a few new ones should be hired. More-
over, when specification and verification roles are dis-
tinguished, the hardest part (the verification) can be
devoted to an expert of the prover.
This segregation of formal aspects is seldom
present in formal verification systems that are pro-
posed for MAS, and this is certainly one of the major
aspects that explain they are seldom used (Ahmad and
Rahimi, 2009).
However, tests are not tackled by GDT4MAS. Of
course, when formal methods are used, tests are less
necessary. But they remain useful, as they consider
also parameters that are not taken into account by the
formal verification (the environment of execution, the
system or the compiler for instance). So, it is the re-
sponsibilty of the development team to manage tests.
But we aim at improving GDT4MAS in order to use
it to help in writing test cases.
5 INCREMENTAL
DEVELOPMENT
For several years, it has been established that most
software development projects fail because they are
badly managed (Zeller, 2009). Thus, recent develop-
ment methods rely on incremental technique. This
is for instance the case of the “incremental develop-
ment”, but this is also the basis of the Test-Driven-
Development technique (Beck, 2002).
Incremental development can be considered in
two opposite directions. In standard development,
the incremental aspect is mainly implemented in a
bottom-up way: a small compoment is first designed
and developed to obtain a first prototype, and then,
new components are progressively designed, devel-
oped and merged with the previous propotype.
When developing agents, it is not easy to use
a bottom-up incremental development because the
goal-oriented specification of agents and the notion
of plan look more like a top-down specification.
And this is exactly one of the main principles of
GDT4MAS. Specifying the resolution of a goal by
a set of subgoals and a decomposition operator di-
rectly implements a top-down method. Moreover, in
GDT4MAS, two principles are essential to make this
process efficient.
Firstly, decompositions of sibling nodes are in-
dependant. This facilitates the progressive design of
the resolution process of different subgoals of a given
goal, and this is a very important notion to facilitate
incremental development.
Secondly, decompositions rely on the refinement
principle. The refinement notion is a key notion in the
formal specification domain. There are several def-
initions of refinement, but all the definitions of the
action refinement share a common aspect that we can
informally summarize by the following sentence: an
action a
2
refines an action a
1
if and only if all the state
changes allowed by a
2
are also allowed by a
1
(Back
and Sere, 1991). For instance, x
> x is refined by
x
> x+ 5, which is refined by x
= x+ 10.
This implies that thanks to refinement, we can re-
duce indeterminism of goals, and as a consequence,
it is completely possible to use indeterminism in goal
specifications. In GDT4MAS, indeterminism is al-
ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications
410
lowed in goals specifications via non-deterministic
STF, and so, we have extended the notion of action
refinement to the notion of goal refinement.
Refinement is a key notion to make incremental
top-down development. Indeed, a top level goal can
be abstract and non deterministic. It is then possible
to refine it by decomposing it into more deterministic
goals, that can then be also refined and so on. More-
over, refinement makes possible the introduction of
new variables. Indeed, as the STF x
> x does not
specify anything on variable y, it can be refined by the
following STF: y
= 4 x
= x+ y
. It is so possible to
start with very high level goals, and incrementally de-
tail their implementation by reducing the indetermin-
ism thanks to goal refinement/goal decomposition.
6 MODELING DIFFERENT
AGENT MODELS
As explained in section 4, when using GDT4MAS,
during the third development step, agent behaviours
must be designed. Depending on the agent type, dif-
ferent models of agents may be used. GDT4MAS
gives to the designer a large choice of models. The
goal of this section is to show how some of them can
be specified with GDT4MAS.
6.1 Specifying Agents with Goals
Whatever the model of agents is used, agents are most
of the time described using the notion of goal. This
is for instance the case in models relying on BDI
agents, like Agentspeak (Rao, 1996). This is also
the case of GDT4MAS. Moreover, goals are often
divided into two categories: achievement goals and
maintain goals. Both types are present in GDT4MAS.
Achievement goals are represented by standard
goals of GDT4MAS. However, two types of achieve-
ment goals are distinguished: progress goals (the re-
sulting state is expressed as a modification of the ini-
tial state, for instance x
= x + 1) and state-reaching
goal (the resulting state is expressed in an absolute
way, for instance, x
= 5).
The semantics given to “maintain goals” varies
from one article to another. A maintain goal con-
sists either in guaranteeing that a property remains al-
ways true or in re-establishing a property each time
it becomes false. The first case can be directly ex-
pressed in GDT4MAS by invariants. In the second
case, a progress goal can be expressed thanks to an
agent whose main goal expresses the property to es-
tablish, and whose triggering context is the negation
of this property. So, as soon as the property becomes
false, the execution of the agent begins in order to re-
establish the desired property.
In many agent models or agent-oriented lan-
guages, when an agent must achieve a goal, it tries
a plan then perhaps another, and so on. But it is not
clear to understand why the agent tries an other plan
or not, according to the goal. Is it because the goal
has not been achieved ? Or because the plan could
not be completed ? And when a goal is removed from
the goal base, is it because it has been achieved ? Or
because it seems it is impossible to achieve ? Or be-
cause it is obsolete ? In GDT4MAS, we determine
which goals are non-necessarily satisfiable, and the
operational semantics of the GDT operators relies on
the fact that a goal has been achieved or not. This
criterion is seldom considered in agent specification
models.
GDT4MAS takes into account that a goal may be
achieved even if the execution of the plan associated
to this goal (ie. its decomposition) has failed. In-
deed, it has been shown that, because of side effects,
this may happen (Mermet and Simon, 2009).Forget-
ting this fact may lead to specify incorrect behaviours.
6.2 Expressiveness of GDT4MAS
Through several articles, the expressiveness of
GDT4MAS seems adapted to model most problems
tackled by multi-agent systems.
For instance, it has been shown in (Mermet and
Simon, 2011) that agents mixing cognitive and reac-
tive behaviours can be easily specified thanks to the
holonic extension of GDT4MAS.
The exception management is also a key issue
in MAS (Klein et al., 2003), But it is rarely han-
dled by MAS models and languages (Platon et al.,
2008) like AgentSpeak for instance. However, once
again, thanks to the holonic extension of GDT4MAS,
this can be clearly specified with GDT4MAS, as ex-
plained in (Mermet and Simon, 2011).
Finally, many communication styles can ben spec-
ified with GDT4MAS. To our knowledge, this is the
only formal model dedicated to MAS that manage this
aspect of MAS. Communications are indeed ignored
in other formal systems such as METATEM for in-
stance.
7 CONCLUSION
Throughout this article, we have shown that
GDT4MAS presents very interesting characteristics
to help in engineering multi-agent systems. Although
UsingGDT4MASasaFormalSupportforEngineeringMulti-AgentsSystems
411
this model has been designed in order to formally ver-
ify MAS, its characteristics can be re-used in a wider
context of MAS engineering. It is moreover interest-
ing to notice that, most of the time, these character-
istics were not preconceptions, but they are the con-
sequence of the will of the designers of the model to
have a usable formal verification system.
Of course, an important requirement to use a
model to support engineering is that CASE-tools exist
for this model. We have chosen not to detail this as-
pect in this article to focus on the characteristics of the
model. But it is important to notice that GDT4MAS
has been designed from the beginning to be supported
by tools. For instance, a platform has been developed
to execute specifications either automatically or step
by step. This platform also generates proof obliga-
tions in a format compatible with the automatic prover
PVS. Morover, a web application is being developed
to help in editing GDT4MAS specifications.
In order to increase the use of Multi-Agent Sys-
tems, it is crucial to provide models that help in de-
signing and implementing such complex systems, and
it is also important to provide techniques that increase
the confidence in such systems. GDT4MAS is cer-
tainly a good candidate for that.
REFERENCES
Abrial, J.-R. (1996). The B-Book. Cambridge Univ. Press.
Ahmad, R. and Rahimi, S. (2009). Motivation for a new for-
mal framework for agent-oriented software engineer-
ing. IJAOSE, 3(2/3):252–276.
Back, R.-J. and Sere, K. (1991). Stepwise refinement of
action systems. Structured Programming, 12(1):17–
30.
Beck (2002). Test Driven Development: By Exam-
ple. Addison-Wesley Longman Publishing Co., Inc.,
Boston, MA, USA.
Beck, K. et al. (2001). Manifesto for agile software devel-
opment.
Demazeau, Y., editor (2004). Systmes Multi-Agents, vol-
ume 29 of ARAGO. OFTA.
Fisher, M. (2006). Metatem: The story so far. In Proceed-
ings of the Third International Conference on Pro-
gramming Multi-Agent Systems, ProMAS’05, pages
3–22, Berlin, Heidelberg. Springer-Verlag.
Kacprzak, M., Lomuscio, A., and Penczek, W. (2004). Ver-
ification of multiagent systems via unbounded model
checking. In AAMAS’04.
Klein, M. et al. (2003). Using domain-independent excep-
tion handling services to enable robust open multi-
agent systems: The case of agent death. Autonomous
Agents and Multi-Agent Systems, 7(1-2):179–189.
Martin, R. C. (2009). Clean Code: A handbook of agile
software craftsmanship. Prentice Hall.
Mermet, B. and Simon, G. (2009). GDT4MAS: an exten-
sion of the GDT model to specify and to verify Multi-
Agent Systems. In et al., D., editor, Proc. of AAMAS
2009, pages 505–512.
Mermet, B. and Simon, G. (2011). Specifying recursive
agents with gdts. Autonomous Agents and Multi-Agent
Systems, 23(2):273–301.
Mermet, B. and Simon, G. (2013). A new proof system to
verify gdt agents. In Zavoral, F., Jung, J. J., and Bad-
ica, C., editors, IDC, volume 511 of Studies in Com-
putational Intelligence, pages 181–187. Springer.
Platon, E., Sabouret, N., and Honiden, S. (2008). An archi-
tecture for exception management in multiagent sys-
tems. IJAOSE, 2(3):267–289.
Raimondi, F. and Lomuscio, A. (2004). Verification of mul-
tiagent systems via orderd binary decision diagrams:
an algorithm and its implementation. In AAMAS’04.
Rao, A. S. (1996). AgentSpeak(L): BDI agents speak out
in a logical computable language. In van Hoe, R., ed-
itor, Seventh European Workshop on Modelling Au-
tonomous Agents in a Multi-Agent World, Eindhoven,
The Netherlands.
Zeller, A. (2009). Why Programs Fail: A Guide to System-
atic Debugging. Morgan Kaufmann, Burlington, MA,
2 edition.
ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications
412