![](bg7.png)
2.2.3. Function, Motivation, and Behaviour Modelling
The functional view of agent-oriented modelling deals with the modelling of activities
performed by agents. In order to enable function modelling, we have in [2] extended
AORML by activities. While an action happens at a time point (i.e., it is immediate), an
activity is being performed during a time interval (i.e., it has duration), and consists of
a set of actions, performed by a particular agent. An activity type (task in [10]), like
“Process quote request” in Figure 4, is defined as a prototypical job function in an
organization which specifies a particular way of doing something [10].
The functional view is closely related to the motivational view which deals with the
modelling of the goals agents are trying to achieve, because goals are attached to
activities. We express goals by means of the Object Constraint Language (OCL) in-
cluded by UML [11].
While the functional view of agent-oriented modelling addresses the mo delling of
business functionality (what has to be done), the behavioural view addresses the
modelling of business behaviour (in which order work has to be done). It also deals
with the decomposition of activities into actions. Modelling of an agent’s behaviour is
based on the semantic framework of Knowledge-Perception-Memory-Commitment
(KPMC) agents introduced in [8, 9] and extended in [2]. The behaviour of a KPMC
agent is encoded by a set of reaction rules. A reaction rule is defined as a quadruple
ε, C → α, F where ε denotes the triggering event term, C denotes the precondition
formula, α denotes the resulting action term, and F denotes the mental effect formula.
An action term specifies the performance of a communicative or non-communicative
action, while a mental effect formula specifies a change in the agent’s beliefs. Reaction
rules are graphically represented as is shown in the legend for Figure 4.
For graphical function and behaviour modelling, an extension to AOR modelling –
activity diagrams – has been introduced in [2]. In activity diagrams, activity types are
visualized as rectangles with rounded left and right sides, as is shown in Figure 4. An
activity can be started by a reaction rule as is shown in Figure 4 where an activity of
the type “Process quote request” is started in reaction to perceiving an action event of
the type request inform (?Quote), presenting a request for quote. When an activity of
the outermost level is started, to its input parameters are assigned the values of the
data items within the triggering event instance. For example, to the input parameter q of
the type Quote of an activity of the type “Process quote request” is assigned the value
of the data item ?Quote within the triggering event.
Through an activity border event of the type START(ActivityType), an activity can
trigger its subactivity or an internal reaction rule. The triggering event type
START(ActivityType) is graphically represented by an empty circle with the outgoing
arrow to the symbol for a subactivity type or an internal reaction rule. In Figure 4,
upon the start of an activity of the type “Process quote request”, its subactivity of the
type “Process line items” is started. Additionally, each activity is associated with
another implicit activity border event of the type END(ActivityType) that can trigger a
subsequent activity or reaction rule. This event type is visualized by drawing a trig-
gering arrow from the activity type symbol to either the symbol of the next activity
type or to the symbol of a reaction rule, as is exemplified by Figure 4.
An activity implicitly passes the values of its input parameters to the activity of the
next level started by it. For example, in Figure 4, an activity of the type “Process quote
204