Modeling

the System Organization of

Multi-Agent Systems in Early Design Stages with

Coarse Design Diagrams

Lawrence Cabac and Kolja Markwardt

Department of Informatics, TGI, University of Hamburg, Germany

Abstract. In this paper we propose to use a coarse system overview from the

beginning of the analysis stage to better support the development team of multi-

agent systems in ﬁnding an architectural approach direction to the envisioned

system. For this we propose to transfer the syntax of use cases modeling to the

analysis / architectural design stage of designing preliminary roles and interac-

tions. The reasons to use this is that modeling with use case syntax is lightweight,

intuitive and well-known to most developers. We also present a plugin for RE-

NEW which is capable of drawing use cases and generating code structures for

multi-agent applications in the context of MULAN.

1 Introduction

In opposition to usual engineering approaches, which are usually top-down oriented,

the agent-oriented approach is usually a bottom-up process [5]. From the design of the

small, detailed parts and principles, such as rules, goals and concepts of communica-

tion, emerges the organizational structure in the fused, composed system of aggregated

entities and processes. This effect is often described by the sociological concept of the

micro-macro link [8]. Especially in multi-agent-based simulation these effects are of

importance and are often the main target of investigation.

In agent-oriented software engineering, additionally the controlled design of the or-

ganizational structure of the designed system is not only of importance but the main

cause in the design process. The obvious solution to this challenge is a hybrid approach

that incorporates both approaches. A bottom-up design of the system’s parts and a con-

trolled top-down design view on the desired organizational structure.

For this cause we model the basic elements of the designed system in a applica-

tion matrix of roles and interactions. On one hand this matrix shows basically, which

roles are involved in which interactions and on the other hand it shows the participating

roles for the interactions. This is an intuitive coarse perspective on the system since

the roles are deﬁned in their behavior, abilities and responsibilities. Deﬁnition of inter-

action behavior is one of the foremost actions in the design phase of many common

agent-oriented methodologies.

The representation of the matrix can be done as simple table (spreadsheet) or as di-

agram. We have opted for a diagrammatic representation, which owns the syntax of use

case diagrams but offers a completely other semantics and application context, i.e. not

Cabac L. and Markwardt K. (2009).

Modeling the System Organization of Multi-Agent Systems in Early Design Stages with Coarse Design Diagrams.

In Proceedings of the 7th International Workshop on Modelling, Simulation, Veriﬁcation and Validation of Enterprise Information Systems, pages 33-42

DOI: 10.5220/0002203100330042

 SciTePress

in the requirements engineering phase but in the analysis/design. This coarse design al-

lows us to intuitively model the coarse organizational structure of a multi-agent system

in early stages of the design phase. In addition, through the tool support we are able to

generate code base skeletons for the envisioned system. In Section 2 we describe the

semantics, the approach, its integration into the development process and the resulting

models.

Section 3 offers an extensive example and discusses the presented technique in the

context of our experiences and in relation to other approaches. Section 4 discusses re-

lated work and similar approaches.

2 Coarse Design with Use Case Diagram Elements

The construction of multi-agent application depends in many methodologies on the

fact that (earlier) identiﬁed requirements are used in an analytical phase to achieve a

profound and – among the development team – agreed-on insight of the envisioned

system. Then in a design phase this insight is turned – with the help of the artifacts

developed in the analysis phase – into a design of the system; usually a set of models

representing partitions of the system. Consequently, this design is reﬁned and turned

into a detailed design and this is followed by an implementation.

Many currently used methodologies have the goal to transform early models from

the analysis into reﬁned, more detailed models in design and implementation. This can

be achieved (automatically or – more often – semi-automatically) by transformation or

generation from existing models into reﬁned models or implementation artifacts.

In Gaia and Gaia-like methodologies (Roadmap, PAOSE, Message/UML, Ingenias)

the phases of design are deﬁned as analysis, architectural design and detailed design.

Following the Gaia terminology the analysis phase consists of the preliminary or coarse

description of the sub-organization, the environment, the roles, the interactions and the

rules.

2.1 System Analysis with Coarse Design Diagrams

Each role is involved in certain interactions as well as each interaction is associated

with a number of roles. Thus, this relationship is often referred to as organizational

matrix of the application. Moreover, in PAOSE [1,2,3] the organizational matrix is also

sometimes written as a table (spreadsheet). In or after the initial start of the architectural

design phase when the ﬁrst elements (roles, interactions, ontology concepts) of the sys-

tem are identiﬁed these concepts have to enter the models. Here the ﬁrst decomposition

into sub-organizations [10] of the system takes place. For the roles, their responsibilities

and abilities have to be deﬁned. Consequently, the deﬁned responsibilities also deﬁne

the organization of the matrix. For the interactions precisely the participants according

to the desired objectives according to the abilities and responsibilities of the roles have

to be deﬁned. For the reason of these interconnections between roles and interactions

we believe that the identiﬁcation of interactions and roles cannot be achieved separately

but only jointly with the identiﬁcation of them. Instead of a separated approach we pro-

pose an incremental one. Here the design is done in a coarse manner and is successively

and incrementally reﬁned. The result or the incremental process is a joint coarse model

of roles and interactions as well as their relations that resembles a use case diagram but

is in fact the multi-agent system overview diagram.

For the coarse design of the organizational matrix of roles and interactions we pro-

pose, here, an alternative to the spreadsheet notation, which suits much more the intu-

itive modeling in software processes. We propose to use the well-known syntax of the

use case diagrams for the application matrix with a semantic difference.

Actors

in use

cases represent

agent roles

of the designed system.

Use cases

represent the

interactions

in the system – not like in the usual semantics the interactions with the system.

The

matrix is spanned by the arc connections in the diagram.

By using the well-known and simple syntax it is easy for developers to intuitively

adopt this technique into the development process. Especially when this stage of the

development / design is done within the group of developers it is essential that the tech-

nique has to be lightweight and easily understandable for all participants. in the early

stages of analysis, which is usually accompanied by discussions, the technique has also

to allow for easy manipulation, adaption, revisions and incremental advances.

In this stage the main important tasks are:

– that the roles, which deﬁne the decomposition of the system, are named and their

abilities and responsibilities are sketched,

– that the interactions are named and their workﬂow and their triggers are sketched

and

– that the participants of the interactions are associated with them.

Additionally, already many concepts of the system are used during discussion. These

should be collected and can directly enter the ontology for the system (or if not used by

the agents these concepts can enter the ontology of the development system team: the

glossary). Furthermore, already ﬁrst mappings of agent roles and agents in the system

enter the discussion. Although also this does not primarily interest the developers at this

stage, these assumptions can enter the later models (agent model). This is sometimes

already included in the diagram through clustering of actors/roles or through the con-

nection of several actor/roles to one actor/agent. In the latter case the new actor/agent

can be displayed differently to achieve a distinction between roles and agents (color,

annotation)

2.2 Alternatives

There are many possibilities for alternatives to the presented modeling technique of

using use case syntax for the application matrix.

Spreadsheet matrix → easily generatable.

UML: communication diagram → ﬁts not so good

In usual use case diagrams the actors represent real users of the system and use cases represent

scenarios of interactions with the system. Use cases are often used to describe existing systems

and how they are used by the users.

Prometheus: The system diagram in Prometheus [9] covers the interactions and the

agents. Thus, offering the same possibility as the coarse design diagram. However,

it includes also environmental information and is far more detailed and more over-

loaded.

2.3 Project Kick-off

Each software development project has to be started at some point. Usually parts of the

requirement engineering is done before the real start (kick-off) of the process and de-

pending on the type of system either still requirements have to be deﬁned or they can be

clear and obvious. Also the question where requirements engineering ends and analysis,

coarse design or architectural desing start is not clear and depends on the developers,

the techniques they are using, the paradigm applied and the personal preference of the

participants.

We assume that all participants agree on and have a notion of the envisioned system.

The development group meets and wants to start the development phase. Thus, we are in

the analytical phase (Gaia) or at the coarse design (PAOSE). Now, in an agent-oriented

methodology the participants have deﬁned roles, interactions and functional concepts

(ontology) to get a notion of the to-be-envisioned design, or to agree on a design. It

seems obvious that if such a task is done by a group that process of coarse design is

a controversial, time-consuming task that needs elaboration, negotiation, reﬂection, re-

elaboration, re-negotiation and re-reﬂection for there are several indiviuals in the team

who have possibly competing and developing interests and insight into the system.

This process of competing, cooperating, negotiating individuals that need to be co-

ordinated, self-coordinated or self-organized is exactly the kind of process we attribute

to intelligent agent societies. For this reason we have given the development process and

the development team the guiding metaphor of the multi-agent system of developers[1].

To support this process and to direct it to a result we want to apply a technique that

has the following attributes:

– Easily understandable for all participants.

– Is unobtrusive and thus does not hinder the discussion.

– It can be applied on the ﬂy during discussion (light-weight).

– It should integrate with the development process (code generation).

With the use case diagrams as a coarse design modeling technique and the plugin im-

plementation (together with a Velocity-based

code generation) we are able to achieve

those goals.

2.4 Tool Integration

The UseCase Plugin is integrated as a plugin into our tool-set of a Petri net-based multi-

agent development environment. The plugins functionality consists in (1) a palette that

Note that we beleive that software development is an incremental, evolutionary, concurrent

and dynamic process. Thus, the idealization made in this paper cannot be achieved in a real

setting and stages, phases or tasks have to be reitterated during development as necessary.

Velocity: a Java-based template engine (http://velocity.apache.org/).

provides the tools to draw the basic elements such as actors, cases and arcs and (2) a

generator based on Velocity that produces the generated output.

Fig. 1. The main window of Renew with the UseCase Plugin its palette, menu entries

and a use case example.

Figure 1 shows besides the main window of our development environment the addi-

tional elements provided to the GUI by the plugin: menu entries for the palette, for

generation of the image maps and for the creation of an application’s folder structure

and the palette for the basic drawing elements – here detached from the Window for

better recognition.

3 Examples: Coarse Design

In this section we present two examples for the modeling of the application matrix. One

is a workﬂow management system and the other one is a multi-agent multi-user game.

We use the previously described use case element syntax. However, the semantics and

pragmatics behind the diagrams are different form the usual application of use case di-

agrams and should not be confused with that. We call this model coarse design.

From the pragmatic point of view the largest difference between usual use case mod-

eling and the coarse design modeling lies in the stage or phase in which the model is

used. While use case diagrams are usually created during the requirements engineering

phase, coarse design is done after that and starts in the architectural design phase. How-

ever, as a system overview of all (or at least a closed partition of all) interactions and

roles it comes handy in all stages of development and should be maintained throughout

the whole process.

An addition to the plugin responsible for the documentation of the application (MulanDoc)

allows for the integration of the diagram as an image map into the web-based API documen-

tation.

3.1 A Workﬂow Management System

Figure 2 shows an agent-based workﬂow management system that follows the deﬁni-

tion of the Workﬂows Management Coalition’s (WfMC) reference architecture. The

management system is represented by the WFMS agent role.

Fig. 2. Coarse design of an agent-based workﬂow management system (WFMS).

Dependent agents (or sub-components) are workﬂow data base (WFDB) the account

manager (AM), the workitem dispatcher (WD), the workﬂow engines (WFE), the work-

ﬂow enactment service (WFES) and a user of the workﬂow management system. An

agent owning the user role acts as a proxi/placeholder some real (human) user. Several

interactions have been deﬁned; e.g.: login, logout, request workitem, cancel or conﬁrm

activity and so on. Many of which (the ones involving the proxi user) are interactions

that can be interpreted also as interactions with the system. However, most require sev-

eral internal agents and some interactions are solely internally. Although the system has

not been built yet, the system’s structure is clearly conceivable from the coarse design.

Whether the system is build with exactly this structure is not of importance. The

main importance is that the development team has a means to develop a common vision

on the system from which further discussions can start. The Use Case Plugin allows to

extract a table from the diagram, which can be used to have yet another different view

on the system and also to compare with the existing designed system. Table 1 shows the

extracted table for the agent-based workﬂow management system.

Table 1. Generated matrix table from diagram.

accountmanager

WIDispatcher

WFES

WFDEFDB

User

WFMS

offerWorkitemList × ×

edit Workﬂow Instance × ×

request Workitem × × ×

init Workﬂow × × × ×

show State × × × × ×

Edit RRR × ×

authenticate × × × × ×

cancelActivity × × × ×

dbEdit × × ×

updateWorkItemList × ×

3.2 Generating Code Bases From Coarse Design Diagrams

The coarse design models are used to generate the applications source code directory

as well as model skeletons, code skeletons for the roles, interactions and ontology as

well as all conﬁguration and build ﬁles needed to compile the project. The diagram

is further used in other stages of the development process to add to the API docu-

mentation’s overview. In the html-based API Documentation,

which is automatically

generated from all design artifacts, the coarse design diagram is integrated and overlaid

with hyperlinks that lead from diagram elements directly to the documentations for the

represented artifacts.

4 Related Work

Use case diagrams are widely used to model requirements of (software) systems. This

is also done in agent-oriented methodologies. “Creating use-cases has proven to be a

very effective and sufﬁcient method to discover requirements” [7, p. 6]. Examples for

such a use are ROADMAP and ADELFE. In opposition to this traditional use of the

use case syntax we redeﬁne the semantics behind the diagram elements and transport

the technique from the requirements to the (coarse) design of the system.

Adapting the semantics of use case diagrams or diagram elements have been done

frequently within agent-oriented methodologies. It seems the temptation to use a human-

like icon for an agent is very high and the effect – the intuitive understanding of the

diagram element – is seldom missed.

Mulandoc generates a hyperlink document with and from all relevant design artifacts in a

MULAN-based multi-agent application including interaction diagrams, protocol nets, decision

components, knowledge base ﬁles and combines those with a generated application matrix as

well as the coarse design diagram. Thus it supplements the Java API documentation.

– In RAP/AOR use cases-like models are used alternatively to interaction frames

to model agent interactions. Agent can be modeled interchangeably as actors or

as systems while the cases depict interactions between agent and system (also an

agent).

– In MAS CommonKADS use cases are used to model interactions/cases of human

and artiﬁcial agents with a system (also an agent). The notation distinguishes be-

tween the human and the artiﬁcial (square head) agent. An artiﬁcial agent can be

depicted as (square headed) actor or as system depending on the focus.

– In PASSI use case diagrams are used for requirements engineering. Here the actors

are used in a more traditional sense as human agents / users but also sometimes as

external (outside of the system) resources.

– In INGENIAS use case diagram (with a slight variation in syntax) are used to deﬁne

the users interactions with the envisioned system. Here user roles, which deﬁne the

position of the human agents and are outside of the system, are related to use cases.

To sum up the usage of use case diagrams in agent-oriented requirements engineer-

ing. In general agents are seen as part of the system – depicted by the system border

in use case diagrams – and actors are often used to represent users of the system (hu-

man agents). However, depending on the grade of abstraction and the focus also agents

are sometimes depicted as actors. This reﬂects the ambiguous deﬁnition and the non-

ﬁtness into traditional modeling approaches of the agent concept. In opposition, in our

approach we model the application matrix as identiﬁed agent roles, their interactions

and the connections of both in the stage of analysis or coarse design.

However, the application matrix can be found in central models of almost all agent-

oriented methodologies. In Gaia this information is deﬁned in the preliminary role and

interaction model. In Prometheus[9] the systems model contains the matrix of interac-

tions and agents. However, it is hidden behind several other aspects that are deﬁned in

this central diagram (perceptions, data). Instead as an alternative the agent acquaintance

models show the social network of the agents withholding the information about inter-

actions.

In (object-oriented) software engineering use case modeling is a common and well-

established technique [6] (especially in analysis of systems). Also system elements (e.g.

components) are modeled frequently as actors (e.g. system use cases [4]) similar to the

above mentioned approaches. In contrast, in our presented approach we do not deﬁne

any use cases. Instead we focus on the use case diagram for a coarse and concise design

of the system.

Fig. 3. Screen-shot of a browser window showing a coarse design image with hyperlink

overlay.

5 Conclusions

In this paper we present a simple technique for the modeling of the application matrix

in multi-agent system, which constist in roles and interactions. The resulting models

can be facilitated for a variaty of causes throughout the development process from the

early stages over generation of code bases to the documantation.

In early stages (coarse design) the light-weight technique presented here allows to

model on-the-ﬂy – while the ongoing developers group discussion – in a coarse manner

the basic system decomposition and coarse overview in an intuitive way. It allows to

be changed rapidly during development. From the artifact, which also reﬂects the orga-

nization of the development team, a system code project folder can be generated that

allows for immediate and concurrent beginning of detailed design / coding. Also other

representations can be derived from the model; i.e. the matrix as a spreadsheet or table.

Additionally, the model is automatically integrated in the hypertext-based API docu-

mentation of the multi-agent system, including navigation with hyperlinks included in

the diagram image.

References

1. Lawrence Cabac. Multi-agent system: A guiding metaphor for the organization of software

development projects. In Paolo Petta, editor, Proceedings of the Fifth German Conference on

Multiagent System Technologies, volume 4687 of Lecture Notes in Computer Science, pages

1–12, Leipzig, Germany, 2007. Springer-Verlag.

2. Lawrence Cabac, Till D

orges, Michael Duvigneau, Daniel Moldt, Christine Reese, and

Matthias Wester-Ebbinghaus. Agent models for concurrent software systems. In Ralph

Bergmann and Gabriela Lindemann, editors, Proceedings of the Sixth German Conference

on Multiagent System Technologies, MATES’08, volume 5244 of Lecture Notes in Artiﬁcial

Intelligence, pages 37–48. Springer-Verlag, 2008.

3. Lawrence Cabac, Till D

orges, Michael Duvigneau, Christine Reese, and Matthias Wester-

Ebbinghaus. Application development with Mulan. In Daniel Moldt, Fabrice Kordon, Kees

van Hee, Jos

e-Manuel Colom, and R

emi Bastide, editors, Proceedings of the International

Workshop on Petri Nets and Software Engineering (PNSE’07), pages 145–159, Siedlce,

Poland, June 2007. Akademia Podlaska.

4. Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley Longman, 2000.

5. J. Ferber. Multi-Agents Systems - An Introduction to Distributed Artiﬁcial Intelligence.

Addison-Wesley, 1999.

6. Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar

Overgaard. Object-oriented

Software Engineering; A Use Case Driven Approach. Addison-Wesley, Wokingham, Eng-

land, 1992.

7. Thomas Juan, Adrian R. Pearce, and Leon Sterling. ROADMAP: extending the gaia method-

ology for complex open systems. In AAMAS, pages 3–10. ACM, 2002.

8. Michael K

ohler, Daniel Moldt, Heiko R

olke, and R

udiger Valk. Linking micro and macro

description of scalable social systems using reference nets. In Klaus Fischer, Michael Flo-

rian, and Thomas Malsch, editors, Socionics: Sociability of Complex Social Systems, volume

3413 of Lecture Notes in Artiﬁcial Intelligence, pages 51–67. Springer-Verlag, 2005.

9. Lin Padgham and Michael Winikoff. Prometheus: a methodology for developing intelligent

agents. In AAMAS, pages 37–38. ACM, 2002.

10. Franco Zambonelli, Nicholas R. Jennings, and Michael Wooldridge. Developing multiagent

systems: The Gaia methodology. ACM Transactions on Software Engineering and Method-

ology, 12(3):317–370, July 2003.