![](bg2.png)
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) identified 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 refined 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 refined, 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 refined models or implementation artifacts.
In Gaia and Gaia-like methodologies (Roadmap, PAOSE, Message/UML, Ingenias)
the phases of design are defined 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 first elements (roles, interactions, ontology concepts) of the sys-
tem are identified these concepts have to enter the models. Here the first decomposition
into sub-organizations [10] of the system takes place. For the roles, their responsibilities
and abilities have to be defined. Consequently, the defined responsibilities also define
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 defined. For the reason of these interconnections between roles and interactions
we believe that the identification of interactions and roles cannot be achieved separately
but only jointly with the identification 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
35