2IX20 Software Specification

UML ACTIVITY DIAGRAMS

Based on the slides provided by M.Seidl,

M.Scholz, C. Huemer and G.Kappel,
authors of the book UML@Classroom
Under the Creative Commons Attribution-
NonCommercial 4.0 International licence.
See http://www.uml.ac.at/en/lernen.

Jeroen Keiren

Mathematics & Computer Science / Formal System Analysis

'Leap year glitch' shuts some New Zealand fuel pumps

Today (February 29) self-service fuel pumps

at Allied Fuel, Gull, Z Energy and BP in New
Zealand were not working due to issues with
payment system used.

• “System had stopped working due to a

leap year glitch”
• Just an issue with New Zealand code
“while Invenco was unsure how it
Image source: https://www.nzherald.co.nz/hawkes-bay-today/news/february-
• 29-allied-fuel-pumps-around-nz-ground-to-a-halt-as-systems-forget-leap-
year/XEQBK5JLBZG6LO3VGUQ6Q2WGC4/
happened, it would investigate the glitch Source: https://www.reuters.com/world/asia-pacific/leap-year-glitch-shuts-
some-new-zealand-fuel-pumps-2024-02-29/

over the coming days”

2 2IX20 UML Activity diagrams
Sequence diagrams: Exercise

3 2IX20 UML Activity diagrams

UML activity diagrams

Diagram

Structure Behavior
Diagram Diagram

Class Package Profile Object Activity State Machine Interaction Use Case
Diagram Diagram Diagram Diagram Diagram Diagram Diagram Diagram

Deployment Composition Component Sequence Communication Interaction Timing

Diagram Structure Diagram Diagram Diagram Overview Diagram
Diagram Diagram

4 2IX20 UML Activity diagrams

Introduction

• Focus of activity diagram: procedural processing aspects

• Flow-oriented language concepts
• Based on
• languages for defining business processes
• established concepts for describing concurrent communicating processes (token
concept as found in petri nets)
• Concepts and notation variants cover broad area of applications
• Modeling of object-oriented and non-object-oriented systems

5 2IX20 UML Activity diagrams

Activity diagrams

• Activities
• Actions
• Events
• Call behaviour

6 2IX20 UML Activity diagrams

Activity

• Specification of user-defined behavior at different levels of granularity

• Examples:
• Definition of the behavior of an operation in the form of individual instructions
Modeling the course of actions of a use case
• Modeling the functions of a business process

7 2IX20 UML Activity diagrams

Activity

• An activity is a directed graph

• Nodes: actions and activities
• Edges: for control and object flow
Output
• Control flow and object flow define the execution parameter
• Optional:
• Parameter
• Pre- and postconditions
Input
parameter

Node Edge

8 2IX20 UML Activity diagrams

Action

• Basic element to specify user-defined behavior

• Atomic but can be aborted
• No specific rules for the description of an action
• àDefinition in natural language or in any programming language
• Process input values to produce output values
• Special notation for predefined types of actions, most importantly
• Event-based actions
• Call behavior actions

9 2IX20 UML Activity diagrams

Edges

• Connect activities and actions to one another

• Express the execution order
• Types Control flow
• Control flow edges
• Define the order between nodes
Object flow edges
• Used to exchange data or objects
• Express a data/causal dependency between nodes
Object flow
• Guard (condition)
• Control and object flow only continue if guards in
square brackets evaluate to true

10 2IX20 UML Activity diagrams

Event-Based Actions (1/3)

• To send signals
• Send signal action

11 2IX20 UML Activity diagrams

Event-Based Actions (2/3)

• To accept events
• Accept event action

12 2IX20 UML Activity diagrams

Event-Based Actions (3/3)

• To accept events
• Accept time event action

13 2IX20 UML Activity diagrams

Call Behavior Action

• The execution of an action can call an activity

• Content of the called activity can be modeled elsewhere
• Advantages:
Name of the called activity
• Model becomes clearer
• Reusability

Inverted fork symbol

14 2IX20 UML Activity diagrams

Example: Accept Event Action

15 2IX20 UML Activity diagrams

Notation Elements (1/2)
Name Notation Description
Represents an action (atomic!)
Action node

Represents an activity (can be broken

Activity node
down further)

Connection between the nodes of

Edge
an activity

Action A refers to an activity of

Call behavior action
the same name

16 2IX20 UML Activity diagrams

Notation Elements (2/2)
Name Notation Description

Send signal action Transmission of a signal to a receiver

Asynchronous Wait for an event E or a time

accept (timing)
event T
event action

17 2IX20 UML Activity diagrams

Activity diagrams

• Beginning
• Termination
• Alternatives
• Concurrency

18 2IX20 UML Activity diagrams

Beginning and Termination of Activities (1/3)

• Initial node
• Starts the execution of an activity
• Provides tokens at all outgoing edges
• Keeps tokens until the successive nodes accept them
• Multiple initial nodes to model concurrency

19 2IX20 UML Activity diagrams: control flow

Beginning and Termination of Activities (2/3)

• Activity final node

• Ends all flows of an activity
• First token that reaches the activity final node terminates the entire activity
• Concurrent subpaths included
• Other control and object tokens are deleted
• Exception: object tokens that are already present at the output parameters of
the activity

20 2IX20 UML Activity diagrams: control flow

Beginning and Termination of Activities (3/3)

• Flow final node

• Ends one execution path of an activity
• All other tokens of the activity remain unaffected

21 2IX20 UML Activity diagrams: control flow

Alternative Paths – Decision Node

• To define alternative branches

• „Switch point“ for tokens
• Outgoing edges have guards
• Syntax: [Boolean expression]
• Token takes one branch
• Guards must be mutually exclusive
• Predefined: [else]
• Decision behavior
• Specify behavior that is necessary for the evaluation of the guards
• Execution must not have side effects

22 2IX20 UML Activity diagrams: control flow

Alternative Paths – Merge Node

• To bring alternative subpaths together

• Passes token to the next node

• Combined decision and merge node

• Decision and merge nodes can also be used to model loops:

23 2IX20 UML Activity diagrams: control flow

Example: Alternative Paths

24 2IX20 UML Activity diagrams: control flow

Concurrent Paths – Parallelization Node

• To split path into concurrent subpaths

• Duplicates token for all outgoing edges

• Example:

25 2IX20 UML Activity diagrams: control flow

Concurrent Paths – Synchronization Node

• To merge concurrent subpaths

• Token processing
• Waits until tokens are present at all incoming edges
• Merges all control tokens into one token and passes it on
• Passes on all object tokens

• Combined parallelization and synchronization node:

26 2IX20 UML Activity diagrams: control flow

Example: Equivalent Control Flow

… equivalent to …

27 2IX20 UML Activity diagrams: control flow

Example: Create and Send Invitations to a Meeting

• While invitations are printed, already printed invitations are addressed.

• When all invitations are addressed, then the invitations are sent.

28 2IX20 UML Activity diagrams: control flow

Example: Conduct Lecture (Student Perspective)

NOT equivalent … why?

29 2IX20 UML Activity diagrams: control flow

Connector

• Used if two consecutive actions are far apart in the diagram

• Without connector:

• With connector

30 2IX20 UML Activity diagrams: control flow

Notation Elements (1/2)
Name Notation Description

Initial node Start of the execution of an activity

End of ALL execution paths of an

Activity final node
activity

End of ONE execution path of an

Flow final node
activity

31 2IX20 Lecture 6
Notation Elements (2/2)
Name Notation Description

Decision node Splitting of one execution path

into alternative execution paths

Merging of alternative execution

Merge node paths into one execution path

Splitting of one execution path

Parallelization node into concurrent execution paths

Synchronization node Merging of concurrent execution

paths into one execution path

32 2IX20 Lecture 6
Activity diagrams

• Token concept
• Data
• Weights

33 2IX20 UML Activity diagrams

Token

• Virtual coordination mechanism that describes execution exactly

• No physical component of diagram
• Mechanism that grants execution permission to actions
• If action receives token, it can be executed
• When action has completed, it passes token to a subsequent action and
execution of this action is triggered
• Guards can prevent passing of token
• Tokens are stored in previous node
• Control token and object token
• Control token: “execution permission" for a node
• Object token: transport data + “execution permission”

34 2IX20 UML Acitivity diagrams: token concept

 Example: Token (Control Flow)
x x
x x x x x
x x

x x

x x x
x
End !
x x
x x

… all outgoing edges of all initial nodes are assigned a token…. … a merge node individually passes each token it gets to its outgoing
edge
… if all incoming edges of an action have a token, the action is activated and is ready
for execution … a parallelization node duplicates an incoming token for all outgoing
edges
… before the execution, the action consumes one token from every incoming edge; … a synchronization node waits until all incoming edges have a token,
after the execution, the action passes one token to every outgoing edge merges them to a single token and passes it to its outgoing edge
… a decision node passes the token to one outgoing edge (depending on the result of the … the first token that reaches the activity final node terminates the
evaluation of the guard) entire activity

35 2IX20 UML Acitivity diagrams: token concept

Object Node

• Contains object tokens

• Represents the exchange of data/objects
• Is the source and target of an object flow edge
• Optional information: type, state

36 2IX20 UML Activity diagrams: object flow

Object Node

• Notation variant: object node as parameter

• For activities
Input Output
parameter parameter

• For actions (“pins”)

37 2IX20 UML Activity diagrams: object flow

Example: Object Node

38 2IX20 UML Activity diagrams: object flow

Central Buffer

• For saving and passing on object tokens

• Transient memory
• Accepts incoming object tokens from object nodes and passes them
on to other object nodes
• When an object token is read from the central buffer, it is deleted
from the central buffer and cannot be consumed again

39 2IX20 UML Activity diagrams: object flow

Data Store

• For saving and passing on object tokens

• Permanent memory
• Saves object tokens permanently, passes copies to other nodes

40 2IX20 UML Activity diagrams: object flow

Weight of Edges

• Minimal number of tokens that must be present for an action to be

executed
• Default: 1
• All tokens present have to be consumed: 0 (also all or *)

41 2IX20 UML Activity diagrams: object flow

Notation Elements
Name Notation Description

Object node Contains data or objects

Parameter for
activities
Contains data and objects as input
Parameter for and output parameters
actions (pins)

42 2IX20 UML Activity diagrams: object flow

Activity diagrams

• Partitioning

43 2IX20 UML Activity diagrams

Partition

• “Swimlane”
• Graphically or textual
• Allows the grouping of nodes and edges of an activity due to
responsibilities
• Responsibilities reflect organizational units or roles
• Makes the diagram more structured
• Does not change the execution semantics

44 2IX20 UML Activity diagrams: partitions

Partition: Example

• Example:
• partitions Student and Institute Employee (with subpartitions
Professor and Secretary)

45 2IX20 UML Activity diagrams: partitions

Example: Partitions

46 2IX20 UML Activity diagrams: partitions

Multidimensional Partitions

Graphical notation … or alternatively textual notation

47 2IX20 UML Activity diagrams: partitions

Example: Issue Student ID on Paper (1/3)

State machine diagram of Student ID:

48 2IX20 UML Activity diagrams: partitions

Example: Issue Student ID on Paper (2/3)

Activity diagram – control flow:

49 2IX20 UML Activity diagrams: partitions

Example: Issue Student ID on Paper (3/3)

Control flow (green) and object flow (red) in one activity diagram

50 2IX20 UML Activity diagrams: partitions

Notation Elements
Name Notation Description

Grouping of nodes and edges

Partition
within an activity

51 2IX20 UML Activity diagrams: partitions

Activity diagrams

• Exception handlers
• Interruptible regions

52 2IX20 UML Activity diagrams

Exception Handling – Exception Handler

• Predefined exceptions
• Defining how the system has to react in a specific error situation
• The exception handler replaces the action where the error occurred

• If the error e occurs…

• All tokens in Action A are deleted
• The exception handler is activated
• The exception handler is executed instead of Action A
• Execution then continues regularly

53 2IX20 UML Activity diagrams: exception handling

Example: Exception Handler

54 2IX20 UML Activity diagrams: exception handling

Exception Handling– Interruptible Activity Region

• Defining a group of actions whose execution is to be terminated

immediately if a specific event occurs. In that case, some other
behavior is executed

55 2IX20 UML Activity diagrams: exception handling

Exception Handling– Interruptible Activity Region

• If E occurs while B or C are executed

• Exception handling is activated
• All control tokens within the dashed rectangle (= within B and C) are deleted
• D is activated and executed

• No “jumping back” to the regular execution!

56 2IX20 UML Activity diagrams: exception handling

Example: Interruptible Activity Region

57 2IX20 UML Activity diagrams: exception handling

Notation Elements

Name Notation Description

Exception handler is executed instead of

Exception Handler
the action in the event of an error e

Interruptible Flow continues on a different

activity region path if event E is detected

58 2IX20 UML Activity diagrams: exception handling

Activity diagrams

• Example

59 2IX20 UML Activity diagrams

Example: Phone call

60 2IX20 UML Activity diagrams: example

Example: Phone call

Disadvantages
1. To understand alternatives, one has to read
them simultaneously with the main scenario.
2. Missing alternatives are difficult to spot.
3. Main scenario enforces sequential execution,
missing potential for concurrent execution.

61 2IX20 UML Activity diagrams: example

Example: Phone call (2) initial node or start marker

The user picks up the telephone

accept signal hook connected to the
telephone line “A”.

decision
[the line
[else]
is free]
send signal Connect the user
Provide the user to the ongoing
with a dial tone. conversation

… final node or stop marker

62 2IX20 UML Activity diagrams: example
Example: Phone call (3)

• Main scenario: The user dials number “B”.

• Alternative step: If the user does not dial a number for a certain
amount of time, a permanent tone is emitted by the switch center, no
further call will be accepted and the user has to replace the hook.

• Two processes:
• wait for the user to dial a number (“main scenario”)
• wait for certain amount of time, say 5 sec;
• When 5 seconds passed, abort the “main scenario” waiting

63 2IX20 UML Activity diagrams: example

Example: Phone call (4)
interruptible activity
region

The user dials number Wait for 5 sec

“B”

interrupting edge

Emit a
permanent tone

64 2IX20 UML Activity diagrams: example

Example: Phone call (5)
interruptible
activity region
The user dials
Wait for 5 sec
number “B”

interrupting edge
(internal) action
Forward the call request Emit a
to the switch center. permanent tone

[line B [else]
is busy]

[B has call [else] Step e

waiting]
Send a busy tone
Step e-2

65 2IX20 UML Activity diagrams: example

 Example: Phone call (6)

• If line “B” is not busy, the call request is forwarded to “B” and a tone is sent
to “A”.
• No indication whether the call request should first be forwarded, and the tone sent
next, or vice versa.
• We should not disallow any of these options. fork

• Execute both in parallel Forward the call Set tone

request to “B” to “A”
• Wait till both call request forwarding
and tone setting are successful.
join

66 2IX20 UML Activity diagrams: example

 Example: Phone call (6)

• If line “B” is busy, and “B” has call waiting the user at “A” will receive a call
waiting tone from the switch center. When line “B” becomes free, sub-
scenario (e)-(g) follows.
merge

• Merge needed to allow multiple Send “call

data flows in same point. waiting” to A
[B busy] [else]
decision
• What would happen if B stays busy all the time? Sub-scenario (e-g)
• Omission in use case!

67 2IX20 UML Activity diagrams: example

Example: Phone call (8)

merge Wait
1 min
Send “call
waiting” to A
[B busy] [else]

decision
Sub-scenario (e-g)

Send a busy tone

Fix omission

68 2IX20 UML Activity diagrams: example

 The user picks up the telephone hook connected to the telephone line “A”.

[line free] [else]

Steps a - f
Provide the user Connect the user to the
with a dial tone. ongoing conversation

Wait The user dials

5 sec number “B”

Emit a Forward the call request

permanent tone to the switch center.

[B call [B busy] [else]

waiting] [else]

Wait Send a busy tone

1 min Forward the call
Send “call waiting” to A Set tone
[else]
request to “B” to “A”
[B busy]

Send a busy tone “B”’s telephone rings.

69 2IX20 UML Activity diagrams: example

Summary

Activity diagram: Read

• Inspired by flow charts • Chapter 8 of reader, Chapters 7-9
• Focus on procedural processing UML@Classroom
aspects Do
• Token concept (a la Petri nets) • Exercises 8.1-8.11
• Separation of control and data • Finish Assignment 1. No instruction
on activity diagrams. Do this yourself
• Weekly test 3
Look around for software bugs and send
them to me

70 2IX20 UML Activity diagrams

Summary: UML diagram types in this course

Diagram

Structure Behavior
Diagram Diagram

Class Package Profile Object Activity State Machine Interaction Use Case
Diagram Diagram Diagram Diagram Diagram Diagram Diagram Diagram

Deployment Composition Component Sequence Communication Interaction Timing

Diagram Structure Diagram Diagram Diagram Overview Diagram
Diagram Diagram

71 2IX20 UML Activity diagrams: example

Reflection

• So far:
• informal (or semi-formal) requirements
• diagrams with sometimes unclear meaning
• useful for communication with different stakeholders, and to refine design

• Remainder of the course:

• languages and models with precise semantics (Promela, Kripke structures, LTS)
• formal requirements (LTL)
• automated verification and testing based on such models

72 2IX20 UML Activity diagrams

Matthias Volk

Lectures coming two weeks taught by Matthias Volk

• Background:
• probabilistic model checking
• fault tree analysis

73 2IX20 UML Activity diagrams