Page 109 -

6 What Software Engineering Has to Offer to Agent-Based Social Simulation 105

“entity” when we talk about both. There are three different diagram types that are
relevant for defining entity templates: UML class diagrams (to define structure),
UML state machine diagrams (to define behaviour) and UML activity diagrams
(to define logic). Often only a subset of these is required. When developing the
templates, we create the different diagrams in parallel and in an iterative manner as
often one informs and inspires the development of the other. As with the stereotypes,
getting the entity templates right is not hard science and will therefore require many
iterations.
In software engineering UML class diagrams are used to define the static
structure of the software to be developed by showing classes (which are blueprints
to build specific types of objects) and the relationships between classes. These
relationships define the logical connections between classes (association, aggrega-
tion, composition, generalisation, dependency). UML class diagrams can be very
complex, and for our purposes it is often enough to consider individual classes.
Therefore we focus on how to define individual classes here. In UML classes
are depicted as rectangles with three compartments. The first compartment is
reserved for the class name. This is simply the name of the entity as defined in
the scope table (e.g. “user” for our user agent template). The second compartment
is reserved for attributes (constants and variables). Often we would capture key
state variables (e.g. “energy saving awareness”), key parameters and key output
variables (e.g. “own energy consumption”) here. The third compartment is reserved
for operations that the user may perform. For each operation, we define some
function names that indicate what kind of additional code we have to produce
later (e.g. “moveToNewLocation()”). The brackets indicate that this is a function.
Figure 6.4 shows as an example the user class definition we developed in parallel
with the other template diagrams in several focus group discussion sessions.
In software engineering, UML state machine diagrams (sometimes just called
“state charts”) are used to represent the dependencies between the state of an object
and its reaction to messages or other events. State machine diagrams show the states
of a single object, the events or the messages that cause a transition from one state
to another and the actions that result from a state change. A state machine diagram
has exactly one state machine entry pointer which indicates the initial state of the
agent. A state in a state machine diagram models a situation during which some
invariant condition holds. Usually time is consumed while an object is in a specific
state. A simple state is a state that does not have substates, while a composite state is
a state that has substates (nested states). The relevant components of a state machine
diagram are depicted and described in Table 6.5.
In our case we use state machine diagrams to define the behaviour of our entities.
This type of diagram is particularly useful as it can be automatically translated into
source code by IDEs who support such features. One can use several diagrams
(e.g. one representing physical states and one representing mental states) for the
same entity. A state machine diagram is not always meaningful (e.g. if there are no
relevant states that need to be represented to capture the behaviour) or necessary
(e.g. “energy saving awareness” could be expressed in states “aware” and “not
aware” but also as a state variable that represents the level of awareness). There is