Paper based on “Exploiting UML in the design of multi ... - People

goldbashedAI and Robotics

Nov 15, 2013 (3 years and 6 months ago)

62 views

Paper based on “Exploiting UML in the design of multi
-
agent systems”


By Federico Bergenti and Agostino Poggi










Submitted by Padmaja Havaldar


CIS

890


Dr. Scott Deloach





Abstract:


Designing agent
-
based systems is a complex and demanding task.
As agents are in itself software systems, they
should be treated as such and well known software engineering principles should be taken into consideration while
designing agent based systems.(Towards UML based analysis and design of multiagent systems

S.Fl
ake,
G.Geiger, J.M. Kuester). In this paper, we are investigating how UML can be exploited to design a multi agent
system at the agent level and its relevance to the concepts covered in our course, which deals with agent oriented
software engineering. The
paper presents a brief background on UML and a set of agent oriented diagrams intended
to
provide an UML
-
based notation to model:
i)

the architecture of the multi
-
agent sys
-
tem,
ii)
the ontology followed
by agents and
iii)

the interaction protocols used to

co
-
ordinate agents. We then see how this work is related to the
concepts studied in our course.


1 Introduction:

This report is based on the paper “Exploiting UML in the design of multi
-
agent systems” by Federico Bergenti and
Agostino Poggi. Federico Berg
enti is a Ph.D. student in Information Technology at the Faculty of Engineering of the
University of Parma. His research focuses on software agents, object
-
oriented technologies and their use to develop
distributed, multimedia and collaborative systems. Ag
ostino Poggi is a professor at the Dipartimento di Ingegneria
dell’Informazione in Italy and is a member of the Faculty of Engineering of the University of Parma. His
research
focuses on agent and object
-
oriented technologies and their use to develop distr
ibuted and multimedia systems.

The architectural design is made up of three levels: the macro level, the micro level and the atomic level. The
development processes adopted by agent
-
oriented software engineering require modeling a system at the agent lev
el
of abstraction.
This agent level of abstraction considers agents as atomic entities that communicate to implement the
functionality of
the system.
This communication is supported by an agent communication language, such as FIPA
Agent Communication langu
age, ACL [5] or KQML, which stands for Knowledge Query and manipulation
language [2], and by an ontology used to associate a meaning with content messages.

KQML was conceived as both a message format and a message
-
handling protocol to support run
-
time kno
wledge
sharing among agents. This language is divided into three layers, the content layer which bears the actual content of
the message, the communication level that encodes a set of features to the message which describe the lower level
communication par
ameters and the message layer that is used to encode a message that one application would like to
transmit to another. The FIPA ACL is a language for the communication between agents

[15].

The agent level is at a higher level of abstraction than the objec
t level and no diagrammatic notation is available to
support the agent level yet. In this paper, the authors tackle the problem of providing a diagrammatic notation for the
agent abstraction level exploiting an UML based notation that can be managed by any

off the shelf CASE tool. The
authors introduce
four agent
-
oriented diagrams, which use s
tereotypes to associate classes with an agent oriented
semantic
. Section 2 in the paper gives background information on UML (
Unified modeling language
), section 3
intr
oduces
ontology diagram
which provides an UML
-
based notation to model ontologies. Section 4 discusses the
problem of modeling the architecture of a multi
-
agent system introducing
architecture diagram
s. Section 5
introduces
role diagrams
and
protocol diagra
m
s. Section 6 discusses some related work that was covered in the
context of our course.

In order to explain the features of these proposed agent
-
oriented diagrams, the authors use an example of the agent
-
based service defined in the FIPA Audio/Video Enter
tainment and Broadcasting
(FIPA AVE
B) specification [4].



2 UML:


The UML (
Unified Modeling language
) is an object
-
oriented graphical modeling language with well
-
defined syntax
and semantics. It helps you specify, visualize, and document models of softwa
re systems, including their structure
and design, in a way that meets all of these requirements. The syntax and semantics are specified semi
-
formally
though underlying semantic models (meta
-
model), descriptive text, and constraints. The UML is an extensibl
e
language, which allows new constraints to be added to address new issues in software development without
changing the original syntax and semantics. (1) Constraints place semantic restrictions on particular design
elements. (2) Tagged values allow new at
tributes to be added to particular elements of the model. (3) Stereotypes
allow to add new elements representing a subclass of an existing element.[16]

In object
-
oriented software, UML is quickly becoming the notation of choice for visual modeling. When w
e view
agents as the next step beyond objects, the need arises to explore extensions to UML to accommodate the
requirements of agents.



Figure 1 a) Conceptual framework

The concept of software architecture, which software system consists of software

comp
onents and their connectors, is utilized to properly represent multi
-
agent
architecture


The UML unifies and formalizes the methods of many approaches to the object
-
oriented software lifecycle and
supports the following kinds of models:

Static model
s
-

suc
h as class and package diagrams describe the static semantics of data and messages.

Dynamic model
s
-

including interaction diagrams (i.e., sequence and collaboration diagrams), state charts, and
activity diagrams.

Use cases
-

the specification of actions
that a system or class can perform by interacting with outside actors.

Implementation models
-

such as component models and deployment diagrams describing the component
distribution on different platforms.

O
bject constraint language (OCL)
-

is a simple form
al language to express more semantics within an UML
specification. It can be used to define constraints on the model, invariant, pre
-

and post
-
conditions of operations and
navigation paths within an object net [18].


3 Ontology Diagrams

In recent years, a
number of sub fields of artificial intelligence have been aiming to increase the ability of their
systems to interact with humans and other external agents by developing and sharing ontologies.
Ontologies mean
formally specified models of bodies of knowled
ge defining the concepts used to describe a domain and the
relationships that hold between them
.

Typically, ontology identifies classes of objects that are important in a
domain, and organizes these classes in a subclass
-
hierarchy. Each class is characteri
zed by properties shared by all
elements in that class. Important relations between classes or between the elements of these classes are also part of
an ontology [16].

At the agent level of abstraction, the design of a multi
-
agent system requires describin
g a model of the world in
which agents live. This is traditionally accomplished by providing the agents with an ontology that describes this
model of the world in terms of:



entities

that populate the world



relations

between such entities [17]

UML can be u
sed to model ontologies at the agent level, exploiting ontology diagrams. At the agent abstraction
level, agents are considered atomic. They are modeled properly only in terms of the messages they can send and
receive. An ontology diagram should comprise o
f only entities and relations that agents may wish to talk about.
Relations between entities should be modeled as predicates between entities. This allows exploiting an ontology
diagram as a diagrammatic description of the features that agents may use to c
reate a content message.

The semantic of ontology diagrams generalizes the common semantic of class diagrams hiding the implementation
details, as not all the elements usually found in a class diagram are meaningful when used in an ontology diagram.
The cl
asses comprised in an ontology diagram represent classes of entities comprised in ontology, just like the
classes in a class diagram represent classes of objects. Some features available in class diagrams are not permitted in
ontology diagrams. For instanc
e, entity classes are not allowed to contain private and protected methods and
attributes. At the agent level of abstraction, public methods are not allowed because the actors communicating to
implement the system are the agents and not the entity belongin
g to an ontology. These restrictions imply that the
classes comprised in an ontology diagram are allowed to only contain public attributes.

Example of an ontology diagram:

Figure 1 shows an ontology diagram describing a subset of the ontology defined in th
e FIPA AVEB specification.
This diagram defines a class of entities called
FIPAAVDescription
characterized by a string called
titl
e. The
stereotype
entity
is introduced to allow the multi
-
agent architect keeping the entities belonging to the ontology apart

from the objects used at the object level. Figure 1 shows that the classes
FIPATVProgramDescription
and
FIPAMovieDescription
extend the class
FIPAAVDescriptio
n,

i.e. these classes contain all attributes characterizing the class
FIPAAVDescriptio
n. [17]




Figure 2. Part of the ontology diagram for the FIPA AVEB ontology.


4 Architecture diagrams:

Designing a multi
-
agent system at the agent level requires modeling the architecture of the multi
-
agent system and
the interactions between agents. Such elements
can be modeled using some UML class diagrams; we call
architecture diagrams
that identify the roles that agents play in the system. Each role is associated with a class, that
we call agent class, and we introduce the stereotype agent to tag such classes be
cause they equal the ones used in
agent
-
oriented use case diagrams. Associations between agent classes describe possible associations between agents
playing different roles An agent class can be used to associate a set of actions with a role. Actions are r
epresented as
public methods of the class. Such methods must be declared void because no concept of return value is defined for
actions performed by agents. The complete specification of an agent role requires describing a set of characteristics
containin
g



the supported interaction protocols;



the accepted content messages, taking into account the ontology;



the semantic of each message.

The latter two entries of this list support architecture diagrams. Figure 2 shows the architecture diagram of the
system
defined in the FIPA AVEB specification. [1]





Figure 3. Architecture diagram of the system defined in the FIPA AVEB specification.

5.
Protocol

diagrams and role models:

An agent interaction protocol (AIP) describes a communication pattern as an allowed

sequence of messages between
agents and the constraints on the content of those messages. UML’s dynamic models are useful for expressing
interactions among agents
Object protocols, the object
-
oriented counterpart of interaction protocols, are not
consider
ed a fundamental element in the design of a system at the object level. This is the main reason why UML
does not provide diagrams to model object protocols.

The authors propose to use protocol diagrams and role
diagrams as an UML
-
based notation to model in
teraction protocols. These diagrams are based on collaboration
diagrams and class diagrams respectively. A protocol diagram is a collaboration diagram that comprises of classes
declared in a role diagram. These classes are labeled with the stereotype role
to keep them apart from other kinds of
classes, such as agent or entity classes. A role class models a role played by an agent in an interaction protocol. This
role is meaningful only in the scope of the protocol in which it is defined and it is described
in terms of the
communicative acts that an agent playing that role must support. As an example, figure 3 shows the FIPA reactive
contract net protocol de
-
fined in the FIPA AVEB specification.


6 Related Works:

Our course introduces us to the

M
ulti agent
Systems engineering methodology

(MaSe) and the agent tool which is
developed to

support the development of multi agent systems using MaSE
.
The

MaSe methodology builds upon the
work of many agent based approaches for analyzing, designing and building multi

agent systems and combines them
into a complete end
-
to
-
end methodology.[14]

The primary focus of MaSE is to help a designer take an initial set of
requirements and analyze, design, and implement a working multi agent system
. It is divided into seven phase
s:
Capturing goals, applying use cases, refining roles, creating agent classes, constructing conversations, assembling
agent’s classes and system design. [14].

A major strength of MaSE is the ability to track changes throughout the process. Every object c
reated during the
analysis and design phases can be traced forward or backward through the different steps to other related objects.
For instance, a goal derived in the Capturing Goals step can be traced to a specific role, task, and agent class.
Likewise,

an agent class can be traced back through tasks and roles to the system level goal it was designed to
satisfy [14].

The agent Tool supports the entire lifecycle from the Goal Hierarchy diagram down to code generation. Using
MaSE and agent Tool, we can dev
elop a multiagent systems development methodology, along with an automated
toolset, that supports multiple types of agent architectures, languages, and Communications frameworks [14].


7 Conclusion:

The agent level of abstraction allows modeling a system

in terms of communicating agents.
UML
-
based notation
can be used to
model a system at the agent level. The authors in this paper show how UML can be used to model a
system at the agent abstraction level. In particular, new diagrams are introduced:




ontolo
gy diagrams



architecture diagrams.


These diagrams should be integrated with AUML to support the multiagent architect.

Architecture diagrams allow modeling the architecture of the multi
-
agent system in terms of a set of agent classes
connected through re
lations. Each class is characterized by the actions that an agent belonging to it can be requested
to perform. Role diagrams and protocol diagrams are intended to support the multi
-
agent architect in the definition
of interaction protocols. Role diagrams c
an be used to specify the roles that agents may play in a protocol, while
protocol diagrams model an interaction protocol defined over a set of roles as the set of all possible conversations
compatible with it. Ontology diagrams allow
defining a model of t
he world composed of entities and relations
. The
MaSE methodology, which we studies in our course is also based on UML.
The diagrams presented in this paper
have been developed in the same spirit as the UML notation for class diagrams. The key difference b
etween object
oriented and agent oriented development methodologies would be that the class diagrams are at the software level
and the actor diagrams are at the knowledge level.



References


1 S. Crane field and M. Pruvis,
“UML as an Ontology Modelling L
anguage
”, in Proceedings

of the Workshop on Intelligent Information Integration, 1999.

2 T. Finin, Y. Labrou and J. Mayfield,
“KQML as an Agent Communication Language
”, in

J. M. Bradshaw (Ed.) Software Agents, MIT Press, 1997.

3 FIPA Technical Committee C,

“Extending UML for the Specification of Agent Interaction

Protocols
”, response to the OMG Analysis and Design Task Force UML RTF 2.0 Request

for Information, 1999.

4 FIPA,
“FIPA ’97 Specification Part 6: Audio/Video Entertainment and Broadcasting
”,

availa
ble at http://www.fipa.org.

5 FIPA,
“FIPA ’99 Specification Part 2: Agent Communication Language
”, available at

http://www.fipa.org.

6 M. R. Genesereth and R. E. Fikes,
“Knowledge Interchange Format
-

Version 3
-

Reference

Manual
”, technical report Logic
-
9
2
-
1, Stanford University, 1992.

7 M. R. Genesereth, N. Singh and M. Syed,
“A Distributed and Anonymous Knowledge

Sharing Approach to Software Interoperation
”, International Journal of Cooperative Information

Systems 4(4):339
-
367, 1995.

8 C. A. Iglesias, M.

Garijo and J. C. A. González,
“Survey of Agent
-
Oriented Methodologies
”,

in Proceedings of the Workshop on Agent Theories, Architectures and Languages,

1998.

9 J. Odell and C. Bock,
“Suggested UML Extensions for Agents
”, response to the OMG

Analysis and De
sign Task Force UML RTF 2.0 Request for Information, 1999.

10 J. Odell, H. Van Dyke Parunak and B. Bauer,
“Representing Agent Interaction Protocols in

UML
”, in Proceedings of Agents 2000, 2000.

11 OMG,
“The Common Object Request Broker Architecture and Spe
cification
”, available at

http://www.omg.org.

12

P. F. Patel
-
Schneider and B. Swartout, “Description
-
Logic Knowledge Representation

System Specification”, DARPA KSE technical report, 1993.

13

J. Treur, “Methodologies and Software Engineering for Agent Syst
ems”, available at

http://www.cs.vu.nl/~treur
.

14
.

Mark F. Wood Scott A. DeLoach,

“An Overview of the Multiagent Systems Engineering Methodology”

15.

Agent oriented software construction with UML by Federico Berg
enti and Agostino Poggi

16.
Cranefield Stephen Purvis Martin, “UML as an ontology modeling language”

17.
Hongsoon Yim, Kyeh yun Cho, Jongwoo Kim , and Sungjoo Park,”Architecture centric object oriented design
method for multiagent systems “

18
. Odell, Paru
nak,”E
xtending UML for agents