Matthias Kunze · Mathias Weske

Behavioural
Models
From Modelling Finite Automata to
Analysing Business Processes
Behavioural Models
Matthias Kunze Mathias Weske
•

Behavioural Models
From Modelling Finite Automata to
Analysing Business Processes

123
Matthias Kunze Mathias Weske
Zalando SE Hasso Plattner Institute (HPI)
Berlin University of Potsdam
Germany Potsdam
Germany

ISBN 978-3-319-44958-6 ISBN 978-3-319-44960-9 (eBook)

DOI 10.1007/978-3-319-44960-9
Library of Congress Control Number: 2016949114

© Springer International Publishing Switzerland 2016

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publication does not imply, even in the absence of a specific statement, that such names are exempt from
the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authors or the editors give a warranty, express or implied, with respect to the material contained herein or
for any errors or omissions that may have been made.

Printed on acid-free paper

This Springer imprint is published by Springer Nature

The registered company is Springer International Publishing AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
 for M. A. J.
M.K.

for Daniela, Jonathan, Emilia, and Theresa

M.W.
Foreword

Bridges and buildings are here to stay and thus mainly need static descriptions
for engineering them. Software is designed and built to perform actions in
various forms. Designing complex behaviour is a difficult and error-prone task
that enforces solid intellectual capabilities to understand the temporal and
often very dynamic behaviour of a software system. Behaviour is generally
more difficult to design than the pretty static data and architectural structures
of software systems.
In the age of digitalisation of virtually every domain, designing appropriate
software systems is one of the big challenges of our time. Their scope, their
complexity, and their interactions with users can only be understood with
a solid theory that is at the same time practically applicable. Designing
and understanding behaviour of systems becomes relevant not only for the
software itself, but for intelligent and smart technical solutions that usually
embody several interacting subsystems, often running in a cloud environment.
Intelligent products will allow, but also enforce us to interact with them in
complex behavioural patterns that need to be designed well and thoroughly
understood and analysed when composing even more complex systems, ser-
vices and business processes. Interactions between intelligent components that
autonomously control our traffic, electric power and water supply system also
need to be established very precisely in order to avoid errors that might have
severe consequences.
Whereas most engineering disciplines use mathematical calculus for de-
scribing continuous behaviour, computer science has developed a solid theory
for digital transitions between concretely definable set of states. This theory
has been defined and explored in various variants of finite automata, state
machines, temporal logics, Petri nets, and business processes. They all have
a shared understanding of state and discrete state changes using events and
actions.
The book written by Matthias Kunze und Mathias Weske covers the core
of this theory and incrementally adds and discusses the various extensions that
have been created over the last few decades. This includes traditional sequential

VII
VIII Foreword

behaviour and concurrent behaviour, the latter of which is particularly useful

to model systems with independent subsystems. The book very nicely shows
how these different variants of the digital theory are related to each other.
It also discusses how concurrent models, such as Petri nets and interacting
systems, relate to sequential state transition systems. The book gives deeper
insights on how to model interactions between software systems and their users
in form of business process models and behavioural patterns to describe them.
Modelling behaviour is without doubt an important aspect of systems
engineering. But an equally important question is how to constructively de-
rive an implementation from the model and how to analyse and understand
the complex models that have been built. As implementing those models is
relatively straightforward the book concentrates very much on the analysis of
the modelled behaviour. It discusses the concept of state spaces as underlying
semantic concept that allows us to compare model behaviour not only by
the model structure but by the behavioural semantics of models. It describes
several relations between behavioural models based on model checking. It also
discusses several forms of behavioural extension, refinement and inheritance.
These techniques are very helpful to reuse common parts of business processes
as well as standards and to individualize them to the specific needs of software
development projects. The concepts introduced in this book are the core for
all forms of software development that build on reusable, high quality assets.
The reader thus gets a thorough understanding of the various behavioural
modelling techniques and how they relate to each other. This will help the
reader to use behavioural modelling techniques when designing their own
system and trying to understand early whether the implementation will behave
properly.
This text reads very well without giving up the claim of providing a solid
formally grounded content and technical presentation. The book by Kunze
and Weske provides a valuable in-depth overview of modelling in the digital
era. It will thus be helpful for practitioners to understand the core assets as
well as for students who get an easy accessible, yet formally grounded overview
of behavioural modelling techniques and their analysis forms.

Prof. Dr. Bernhard Rumpe

RWTH Aachen University, June 2016
Preface

Engineers are experiencing increasing requirements regarding the functionality

and reliability of systems to be built. To cope with the resulting complexity,
they use models to specify and analyse systems. In general, systems can be
specified from several different perspectives, including structure and behaviour.
The structure of a system refers to its architecture and the data that is
stored and manipulated. System behaviour covers the dynamic aspects of
systems. It describes essentially how systems operate. From its beginning
more than half a century ago, the computer science community has developed
methods and techniques to capture the behaviour of systems. Today, engineers
and system designers use standardised methods and techniques to describe
systems in terms of both, their structural and their behavioural aspects.
With the increasing complexity of systems, the demand for modelling and
analysis of systems is also growing. As a result, a thorough understanding of
the principles and concepts of behavioural modelling and its application in
today’s standard modelling techniques is essential for any software engineer
and any system designer.
We wrote this book as a textbook for students of computer science and
software engineering, and also for programmers and system analysts who are
interested in the question “How can we represent the behaviour of the system
we are developing and how can we prove its essential properties?”
To answer this question, this book takes readers on a journey from the
fundamentals of behavioural modelling to advanced techniques for modelling
and analysing sequential and concurrent systems. Undergraduate students will
want to focus on Parts I and II of this book, while graduate students and
researchers might find Part III especially valuable.
This book is based on lectures that the second author gave to students
of IT systems engineering at the University of Potsdam. The core aspects
of behavioural modelling were covered in a lecture on system modelling for
first-year students. Advanced concepts were covered in lectures related to
business process management.

IX
X Preface

This book consists of three parts. The foundations of behavioural modelling

are addressed in Part I. Chapter 2 introduces discrete dynamic systems by
demarcating them from continuous systems. Transition systems are introduced
as a basic formalism to represent the behaviour of discrete dynamic systems
and causality is discussed, which is a fundamental concept for modelling
and reasoning about behaviour. Part II forms the centre of gravity of the
book. It is devoted to models of behaviour. Chapter 3 introduces sequential
systems by investigating different types of automata, ranging from simple finite
automata to automata with output and extended automata with variables and
assignments. The chapter concludes with state machines, which are a realisation
of extended automata in the UML industry standard. Concurrent systems are at
the centre of Chapter 4. State machines with orthogonal states are introduced,
since these can represent concurrent behaviour. Concurrency can also be
represented by asynchronous interactions of several independent, sequential
systems. The chapter concludes by introducing several different types of Petri
nets, which provide important concepts for modelling and analysing concurrent
behaviour of systems. Business process models are covered in Chapter 5. Based
on a set of workflow patterns, whose semantics is represented by Coloured
Petri nets, this chapter looks at the Business Process Model and Notation
(BPMN), which is the industry standard for modelling business processes.
The semantics of BPMN process diagrams and collaboration diagrams are
defined by a mapping to Petri nets. Part III investigates how the behaviour of
systems can be analysed. The basis of this part is formed by Chapter 6, which
introduces the concept of state spaces. State spaces can be regarded as unified
models of behaviour, which, can therefore serve as a basis for behavioural
analysis. The state space of sequential systems described by different types
of automata and the state space of concurrent systems are investigated. The
comparison of behaviour is covered in Chapter 7 by looking at behavioural
equivalence, inheritance, and similarity. The formal analysis of behavioural
models is covered in the verification Chapter 8, which looks at temporal logic
and model checking before investigating the behavioural properties of systems
and, ultimately, business process compliance.
Many people have a share in the success of a book project. The authors
thank the members of the Business Process Technology research group at the
Hasso Plattner Institute for their support and commitment. In particular, we
thank Marcin Hewelt, Luise Pufahl, and Kimon Batoulis for proofreading of
book chapters. We also thank our students in the bachelor’s and master’s pro-
grammes for their involvement and their critical suggestions, which – through
the lectures – found their way into this book as well.

Berlin and Potsdam, June 2016 M.K. and M.W.

Contents

Part I Foundations 1
1 Introduction 3
1.1 Behavioural Models . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Motivating Example . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 On Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Models in Computer Science . . . . . . . . . . . . . . . . . . . . 13
1.5 Modelling in System Development . . . . . . . . . . . . . . . . 17

2 Discrete Dynamic Systems 21

2.1 Characterisation of Dynamic Systems . . . . . . . . . . . . . . 21
2.2 Transition Systems . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Events and Causality . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 Application of Discrete Dynamic System Models . . . . . . . . 33
Bibliographical Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Part II Models of Behaviour 37

3 Sequential Systems 39
3.1 Finite Automata . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2 Automata with Output . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Extended Automata . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4 State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Bibliographical Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4 Concurrent Systems 81
4.1 State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2 Interacting Systems . . . . . . . . . . . . . . . . . . . . . . . . 93
4.3 Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Bibliographical Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 124

XI
XII CONTENTS

5 Business Process Models 125

5.1 Workflow Patterns . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.2 Introduction to Business Process Modelling . . . . . . . . . . . 137
5.3 Business Process Model and Notation . . . . . . . . . . . . . . 141
Bibliographical Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Part III Analysis of Behaviour 161

6 State Spaces 163
6.1 Introduction to State Spaces . . . . . . . . . . . . . . . . . . . 164
6.2 State Spaces of Sequential Systems . . . . . . . . . . . . . . . . 166
6.3 State Spaces of Concurrent Systems . . . . . . . . . . . . . . . 178
Bibliographical Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 185

7 Comparing Behaviour 187

7.1 Behavioural Equivalence . . . . . . . . . . . . . . . . . . . . . . 188
7.2 Behavioural Inheritance . . . . . . . . . . . . . . . . . . . . . . 206
7.3 Behavioural Similarity . . . . . . . . . . . . . . . . . . . . . . . 216
Bibliographical Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 228

8 Verification 231
8.1 Overview of Verification . . . . . . . . . . . . . . . . . . . . . . 232
8.2 Temporal Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
8.3 Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
8.4 Behavioural Properties . . . . . . . . . . . . . . . . . . . . . . . 253
8.5 Business Process Compliance . . . . . . . . . . . . . . . . . . . 257
Bibliographical Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 271

References 273

Index 277
 Part I

Foundations
1
Introduction

This first chapter introduces the topic and the scope of the book, and it
describes the motivation for using behavioural models to capture the dynamic
aspects of a system. This chapter is intended to elucidate the underlying
principles of the modelling of behaviour, elaborating on what behaviour is and
what models are.

1.1 Behavioural Models

This section looks at the main concepts of this book: behaviour and models.
So, what actually is the behaviour of a system? In simple terms, the behaviour
of a system is the way it works, how it operates. If we look closely at how a
system operates, we find that it interacts with its environment by responding
to various stimuli and that it performs actions.
This characterisation of behaviour applies to a wide variety of systems,
ranging from simple programs to complex computer systems, and to business
processes that might be completely automated or might be carried out entirely
manually by humans. While computer systems and systems involving human
work show considerable differences, their behaviour can nevertheless be char-
acterised in the same way, that is, by interaction with the environment based
on stimuli, as visualised in Fig. 1.1.
The behaviour of a system is driven by a stimulus in the system’s environ-
ment. We call such stimuli events. When an event is important for a system,
the system reacts in some way, as defined by the behaviour of the system. In
this context, the term “event” subsumes a wide variety of concepts, such as
happenings in the real world, changes in the environment of the system, and
actions carried out by the system or input entered.
To illustrate these concepts, the example of an automatic teller machine
(ATM) will be used. This machine allows customers of a bank to withdraw
money from their bank accounts. Upon the event that an incorrect personal

© Springer International Publishing Switzerland 2016 3

M. Kunze and M. Weske, Behavioural Models,
DOI 10.1007/978-3-319-44960-9_1
4 1 Introduction

  

 


 

Fig. 1.1: A system and its environment

identification number (PIN) is entered, the machine reacts by informing the

customer about the problem and refusing to pay out cash.
The reaction of a system might also be to simply ignore an event or to
register it but show no reaction that is observable in the environment. When
the ATM expects the customer to input a PIN, it will not react to any other
input, except pressing the cancellation button.
The reaction of a system, however, depend not only on events, but also
on previous interaction of the system with its environment, of which it might
keep knowledge. We refer to this internal knowledge of a system as its state. If
the customer enters a wrong PIN for the third time, the ATM will not release
the customer’s debit card.
With a basic understanding of the behaviour of a system, we now look
at the term “model”. In general, a model is a simplified representation of an
original. Since we are interested in system behaviour, this book looks at models
that are simplified representations of system behaviours.
Models enable us to understand originals by mapping them to a simplified
representation. An example of models is architectural blueprints of buildings,
which allow architects to reason about a planned building and serve as a
specification for construction.
In the context of computer science, the Unified Modeling Language (UML)
is an expressive framework for modelling computer systems. UML distinguishes
between structural and behavioural models. Structural models emphasise the
static aspects of a system, such as the main components that constitute it or
data structures for its implementation. Behavioural models, on the other hand,
focus on how systems operate and interact with their environment.
Similarly to the blueprints, behavioural models provide a specification for
the design of a system. They describe what is supposed to happen within a
system to ensure its proper operation, and how the system reacts to events
that occur in its environment.

1.2 Motivating Example

Information technology is playing an increasingly important role in people’s
lives. We use information systems to plan trips, to purchase goods, and to
 1.2 Motivating Example 5

stay in touch with our family, friends, and colleagues. Our economy depends
on information technology, from the design of products and services to their
development and deployment and to marketing and after-sales services.
Given the continuous growth in the scope and functionality of information
technology, not only are the information technology systems involved becoming
more and more complex, but also the interactions between them. Every software
system of significant complexity consists of several subsystems that interact
with each other.
Some typical subsystems are databases, client software, and application
servers. People working in the field of software architectures have developed
methods and techniques to describe how complex software systems are designed
and built. While software architectures are important to represent the structure
of software systems, however, the power and complexity of software systems
result to a large extent from their behaviour.
An example of an online shop can be used to illustrate system behaviour.
When a customer points a web browser at an online shop, the shop shows
products for sale. The customer selects some of these products by putting them
in a shopping cart. Next, the customer completes the purchase by providing
payment and shipping information. Finally, the products ordered are shipped
to the customer by a logistics service provider.
These actions are events generated by the customer’s web browser, which
belongs to the environment of the online shop. The online shop reacts to
these events by internal actions, for instance by updating the internal data for
payment and shipment information and by showing the customer a confirmation
page.
Today’s online shops are far more complex than the one discussed here,
but this simplified scenario suffices for the illustration of system behaviour.
When the behaviour of an online shop is investigated, the events that drive
its interaction with its environment have to be addressed first. In the above
scenario, we can identify the events and their reactions as shown in Table 1.1.

Table 1.1: Events and reactions for a simplified online shop

Event Reaction
Checkout Record payment and shipment information
Pay order Initiate shipment
Ship products Archive order

Looking at these events, we observe that the online shop cannot accept
every event at every possible point in time. In fact, these events depend on
each other; they are causally related. For instance, the order can only be paid
6 1 Introduction

for by the customer when the purchase has been completed, otherwise there is
nothing to make a payment for.
To capture these dependencies, we refer to the concept of states, which
represent the knowledge of the system about previous interactions with its
environment. Every system, once switched on, starts in an initial state, in
which it accepts certain events to which it reacts and other events that it will
ignore. We can represent the relation between events and states for the online
shop in graphical form as a first, fairly simple behavioural model, which is
shown in Fig. 1.2.

  

 
        
      

Fig. 1.2: States of an online shop

When a customer has entered the online shop, the system is in a state
Shop entered. When it is in this state, the customer can select products and
add them to the shopping cart. When the customer proceeds to the checkout,
triggered by the event Checkout, this state is left and a subsequent state
Shopping completed is entered, in which payment and shipping information are
recorded. This is realised by a directed arc, called a state transition, labelled
with the name of the event that causes the system to transition to the next
state.
The Order paid state comes next. This state can only be entered after the
payment has been settled, indicated by the event Pay order, received from the
payment system of the online seller in the state Shopping completed. When the
products have been delivered to the customer’s shipment address, indicated
by the event Ship products, the purchase ends and the state Products shipped
is entered.
This diagram is a description of the behaviour of the online shop, a behav-
ioural model. On the one hand, it is a simplification that shows only its major
states and the transitions between them that are caused by events accepted
from the shop’s environment. On the other hand, it constrains the way the
shop performs interactions with its environment. This is a general pattern of
behavioural models: they restrict behaviour and only allow systems to behave
in a defined manner.
For instance, after the Shopping completed state has been entered, the
customer can no longer put products in the shopping cart. This is the case
because the behavioural specification of the shop does not accept an event
add products to cart in this state. In Fig. 1.2, this becomes apparent, since the
diagram has no such state transition from the Shopping completed state. The
diagram, as simple as it is, provides constraints on how the system should be
constructed.
 1.3 On Modelling 7

This discussion leads to a key aspect of behavioural models: they can be

used for system development to make sure that requirements are met and that
the system is designed and implemented as intended. Behavioural models can
also be used to analyse whether a system actually satisfies its specification.
These are the two main aspects of behavioural models, and we will revisit
them throughout the book.

1.3 On Modelling
After sketching some of the basic aspects of models as simplified representations
of originals, this section investigates models and their properties in more detail.

1.3.1 Modelling Fundamentals

We use models in our daily life to cope with the complexity around us. Subway
maps (Fig. 1.3), for instance, provide us with information about stations along
subway lines; profiles of people in social networks tell us whether some of
our friends have new jobs. An engineering plan of a kitchen (Fig. 1.4) helps
us to design the kitchen to meet our needs while providing the constructors
with information about how to construct the furniture and where to put the
appliances. Subway maps, personal profiles, and engineering plans are models.

Fig. 1.3: Map of a public transportation system (excerpt of “Netzplan Stadt

Kassel” by http://nvv.de, licensed under CC BY-SA 3.0)

A model is a simplification of an original that is developed to achieve a

particular goal for a certain group of people. The “original” is an important
8 1 Introduction

concept in modelling, since it represents an entity in the real world, which

might or might not exist at the time of modelling, as will be explored shortly.
For each model, there exists a modelling goal and the target group of the
model, i.e., the persons for whom the model has been developed. We will now
investigate these aspects of models for the examples mentioned.
For a public transportation map, the original is clearly the public trans-
portation system of a city, with lines and stations. The original also contains
physical distances between stations; it contains trains, train drivers, and many
more entities needed to make the system operate. The goal of the transportation
map – the goal of the model – is to provide information for travellers regarding
stations and the possibilities of changing between lines to reach a particular
destination. Therefore, the target group of the model consists of travellers who
intend to use the subway system. Since further details of the original, such
as physical distances between stations and technical information about the
trains, are not important for achieving the modelling goal, we abstract these
properties away.

Fig. 1.4: Plan of a kitchen for engineering purposes

In case of a personal profile in a social network, the original is clearly the

person to whom the profile belongs. Just as in the case of the subway map, not
all aspects of a person are retained in the personal profile, just the ones that
are relevant for the target group of the model. Target groups vary between
 1.3 On Modelling 9

social networks. If the network centres around professional information such as

education, academic background, and current position, then the target group
is mainly the person’s colleagues. But the information might also be used by
recruiters who are seeking prospective candidates for open positions.
Using the kitchen example, we can study another aspect of models in
general and of engineering models in particular. The engineering plan of a
kitchen prescribes how the kitchen should be built. The original of that model
is the kitchen, but that kitchen does not exist when the engineering plan is
being developed. This is quite different from the other examples, in which the
original existed when the model was being designed.
The non-existence of the original is a typical aspect of engineering models.
A model is used to design and construct an original, for instance a kitchen, a
building, or a software system. However, modellers have an original in mind
when developing the model.
It is a typical property of system engineering that several persons are
involved in the design of those systems. Models provide a communication
vehicle for the persons involved in the design of a system. Design alternatives
can be discussed using models, and responsibilities can be associated with
model elements. The discussion concludes when agreement about the system
design has been reached.
The corresponding model is then used during the construction phase.
However, this does not mean that no further changes to the model are possible.
Depending on the development context, models may be modified and refined
during later steps of the design and construction process of software systems.

Descriptive and Prescriptive Models

This discussion also shows that models come in two flavours. If a model
describes an existing original, it is a descriptive model. It is called descriptive
because it describes an existing original. A model is prescriptive if it prescribes
how an original should be constructed.
A subway map is a descriptive model because it describes the existing
original, i.e., a subway system. The same holds true for the profile of a person
on a social network. The profile describes an existing original, which is the
person to whom the profile belongs. In the case of the engineering plan, the
original did not exist when the plan was developed. It therefore serves as a
prescriptive model, since it prescribes how the kitchen should be constructed.
During engineering projects, prescriptive models turn into descriptive mod-
els. This is the case for most engineering plans, such as the one used to construct
the kitchen. The engineering plan of the kitchen serves as a prescriptive model,
a blueprint for how to build the kitchen. When the construction of the kitchen
is completed, the engineering plan can be considered a descriptive model, since
it now describes the kitchen. At that point in time, there exists an original
that the model describes.
10 1 Introduction

Modelling Languages
We express ourselves in languages. This holds true for verbal and written
communication in natural language, but it is also true for communication via
models. Models are expressed in languages. The examples of models discussed
so far have used different modelling languages.
A graph language was used to represent the states and state transitions
of an online shop. That language consists of labelled nodes, which can be
connected by arcs. Graphs are used to describe various aspects of computer
systems.
The language of engineering plans was used to express the kitchen plan. It
consists of model elements that represent, for instance, walls, windows, and
doors. Kitchen appliances are important elements of the original, so they are
represented by corresponding language elements. Finally, measurements are
provided to allow the construction of the kitchen as planned.
Each of these diagrams uses a different modelling language. When designing
a modelling language, the key concepts of the language need first to be defined.
In the case of behavioural models, the key concepts to be expressed (and
therefore the central concepts to be represented in a modelling language) are
events and states. These concepts are associated with each other. Each state
transition is bound to an event and relates two states in an order, namely a
source state and a target state.
Once the concepts and their relationships are understood, a notation for
expressing models in that language is required. We could have used squares
and dotted arcs to express state transition diagrams, but we have opted for
ellipses and solid directed arcs instead. Ellipses represent states, while arcs
represent state transitions. States and state transitions are labelled to give
these elements meaning. It is important that the arcs are directed, because –
for each state transition – the source and target states need to be expressed.
These steps represent, basically, how modelling languages can be defined.
Later in this book, several modelling languages to express behavioural
models will be introduced. The conceptual models of these languages are
typically defined by mathematical formalisms. We can already define a simple
conceptual model for the above state diagrams. Each state diagram consists of
a set of states S and a relation R between states, such that R ⊆ S × Σ × S
is a set that consists of pairs of states, each bound to an event. Each triple
(s, δ, t) ∈ R represents the fact that there is a transition from a source state
s to a target state t, which is triggered by the event δ. This conceptual
model, represented mathematically, is the basis of the language. We have
introduced a notation consisting of ellipses (for states) and directed arcs (for
state transitions) in Fig. 1.2.

1.3.2 Properties of Models

In modelling theory, models are characterised by three important properties
that were identified by Stachowiak (1973).
 1.3 On Modelling 11

Mapping Models and their elements can be mapped to an original, which

may or may not exist when the model is being developed. If the original
does not exist in the real world, it does exist in the mind of the model
designer.
Abstraction A model does not cover all aspects of the original, but only
those properties that are important to achieving the modelling goal. All
other properties of the original are abstracted away.
Pragmatics A model can substitute for an original for a particular purpose,
which is described by the modelling goal.
These properties will now be investigated for the example models introduced
above.
When travellers use a subway map, they have no difficulty in mapping the
model elements to the original. For instance, the graphical representations
of the stations in the model are mapped to the original stations, and the
lines between them to tracks that connect the stations physically. The subway
map is clearly an abstraction, since not all aspects of the subway system are
represented. Examples of these omitted aspects are the physical distances
between the stations and the technical aspects of the railways. The map can
serve as a substitute for the subway system because it allows travellers to plan
their itineraries.
These model properties also hold for the second example, that of a personal
profile on a social network. We assume that the person created the profile and
the profile can be accessed on the internet by the general public. Persons map
only certain attributes of themselves to the profile, certainly not all of them.
This means that the personal profile is an abstraction of the original. Only
those properties of the person that are required to fulfil the modelling goal are
listed. The profile of the person satisfies the pragmatics property, since it can
substitute for the real person as far as the modelling goal is concerned.
Looking at engineering plans in general and the kitchen plan in particular,
the above three properties can be found as well. Elements of the model, such
as kitchen appliances, windows, and physical distances, can be mapped to
the original. Engineering models do not cover all aspects of the original. For
instance, when one is planning the layout of a kitchen, the colour of the walls
and the finish of the floor are irrelevant and are therefore abstracted away.
Nevertheless, the kitchen plan serves as a substitute for the original, because
it allows the constructors to plan how the kitchen will be constructed.

Originals and Models

Typically there are several different aspects to be investigated for one original,
often related to different groups of persons. Considering the kitchen example,
an engineering plan serves as a model for constructors of the kitchen. It focuses
on the relevant aspects for this target group and disregards, for instance, the
visual appearance of the kitchen, which is definitely relevant for the owner. To
12 1 Introduction

serve this new modelling goal, another model of the kitchen has to be designed,
one that shows the visual appearance of the kitchen. This model is shown in
Fig. 1.5.

Fig. 1.5: Plan of a kitchen that shows its visual appearance

As this example shows, we might want to investigate different aspects of a

given original. As a result, we need to associate different modelling goals with
one original. In the case of the kitchen these goals include (i) representing
construction details and (ii) showing the visual appearance of the kitchen. This
is a typical situation in engineering projects. To serve these needs, computer
science has developed a variety of modelling techniques that allow us to
investigate different aspects of a system. These aspects will be elaborated on
further in the next section.

Goals of Models
Before turning to models in computer science, we shall take a broader view of
modelling by discussing why we model. We model to represent the aspects of
an original which are relevant for a particular modelling goal. With a model of
the core aspects at hand, people can comprehend the relevant aspects of the
original. So, comprehension is one main reason why we model. This applies
to all models, from the subway map to the personal profile and the kitchen
model, both the visual and the engineering model. Models are important for
the comprehension of complex systems.
 1.4 Models in Computer Science 13

In virtually all engineering projects, several persons are involved in the

design and development of the engineering artefact. This holds true for aircraft,
buildings, consumer electronics, and software systems. The persons involved
need to understand the implication of their work in the overall context. Models
provide a vehicle for communication between persons. They are useful because
they concentrate on one specific aspect of the planned original. As a result,
the persons involved are not distracted by an information overload that is
not relevant for the modelling purpose. Models are crucial for communication
between persons related to a specific aspect of an original, i.e., the modelling
goal.
Typically, several different designs have to be discussed and the engineers
need to agree on a design that will be implemented. Engineering models allow
engineers to discuss different design alternatives effectively and to communicate
the advantages and disadvantages of particular designs. Models are a basis for
reaching consensus in system design among a group of engineers.
Consensus building is an iterative process, involving the design, critical
evaluation, validation, reflection, and redesign of the model until the persons
involved agree that the modelling goal has been fulfilled. These aspects will be
highlighted in the next section in the context of models in computer science.

1.4 Models in Computer Science

To introduce models in computer science, we discuss structural models first.
Structural models describe how systems are organised. Architectural models
and data models are examples of structural models. To deal with the complexity
of data in software systems in general and in database systems in particular,
data models have been introduced. Data models represent the core aspects of
the data in a particular domain. The term “domain” refers to the application
scenario that the software system is to support. In the case of the online
shop, customers, orders, and articles are data objects and therefore part of
the domain.

1.4.1 Properties of Data Models

In this section, we use data models to introduce some basic concepts of

modelling, which will also be relevant to behavioural models.
A data model is shown in Fig. 1.6. It is expressed in the language of entity
relationship diagrams. The diagram represents three types of entities that are
relevant for the online shop, namely customers, orders, and articles. These
entity types are visualised by rectangles. Properties of the entities that are
considered relevant are also represented in the data model. Each customer
has a name, a customer identification, and an address. All other properties of
customers, such as age and gender, are omitted. The corresponding properties
of orders and articles are also shown in Fig. 1.6.
14 1 Introduction

&XVWRPHU 2UGHU $UWLFOH

‫ۆ‬EHORQJVWR LQFOXGHV‫ڼ‬
&XVWRPHU,' 2UGHU,' $UWLFOH,'
1DPH 'DWH 1DPH
$GGUHVV $PRXQW 3ULFH
4XDQWLW\

Fig. 1.6: A data model for customers, orders, and articles

In addition to entity types and their properties, data models allow us to

represent relationships between entities. These are called relationship types,
shown as undirected arcs between entity types. The data model in Fig. 1.6
shows, for instance, a relationship between the entity types Customer and Order.
This relationship type represents the fact that orders belong to customers. The
same holds true for articles and orders, so that each order refers to a set of
articles.
Earlier in this chapter, mapping, abstraction, and pragmatics were in-
troduced as properties of models in general. We shall use data models to
discuss why these properties also hold for models in computer science. Before
investigating this aspect in more detail, the original described by the data
model needs to be discussed. The original consists of concrete customers,
orders, and articles that the online shop has or, at some point in time, will
have.
The elements of the data model can be mapped to the original. In particular,
the entity type Customer can be mapped to all customers, and the attributes
of customers can be mapped to the properties of the customers to be stored in
the database system, for instance the name of a customer. The relationship
between customers and orders can be mapped to concrete relationships between
customers and orders. We conclude that the mapping property is satisfied,
because every element of the data model can be mapped to one aspect of the
original.
The data model is an abstraction of the original in many ways. The first
abstraction is the selection of the attributes in the entity types to represent
specific properties of the original. For instance, customers are represented by
their name, their address, and a customer identity. Other properties that the
original customer has, such as age and marital status, are abstracted away.
A second type of abstraction relates to the classification of all customers
into a single entity type. All customers that the online shop has (and will ever
have) are represented by a single entity type called Customer. The data model
abstracts away the thousands of individual customers that the online shop
might have and only represents their structure.
The data model provides pragmatics, since the relevant properties of entities
and their relationships are captured in the data model. These pragmatics of
the data model allow us to derive a database schema, which can store customer
data, order data, and article data for the online shop.
 1.4 Models in Computer Science 15

1.4.2 Model Properties of Behavioural Models

Not only structural models in computer science, such as data models, but also
behavioural models have model properties. To illustrate this, we return to the
behavioural aspects of the online shop example and show a variant of a state
transition diagram in Fig. 1.7.
In addition to the diagram in Fig. 1.2, the current version identifies one
state as the initial state (Shop entered) and one state as the final state (Products
shipped), represented by the incoming arrow in the initial state and the double
border of the final state.

  
 
          
          

 
  

Fig. 1.7: States of an online shop, with initial and final states

This model describes the behaviour of the system from start to finish.
States are traversed from the point in time at which the customer enters the
online shop until the completion of the ordering process. This is a model that
describes the behaviour of an original.
The original might not be as tangible as it is in the case of the data
model or the kitchen engineering plan; the original is the software system
that implements the online shop. The original may be very complex indeed: it
might include a database system to store the information required to run the
online store, and further software components such as a web interface and an
application server.
The state diagram shown in Fig. 1.7 is a behavioural model of the online
shop, since it describes its states and the events that trigger transitions between
them. Before discussing the model properties of mapping, abstraction, and
pragmatics, the concept of a state has to be elaborated on.
In programming, a state of a system – the state of a program in execution –
can be represented by an assignment of program variables to concrete values
that those variables have at a given point in time. This is a very detailed
characterisation of the state of a dynamic system.
In the online shop discussed so far, the state is more abstract and far less
detailed. Considering the shopping state, the value of the (variable) shopping
cart can change, depending on which articles have been selected by the customer.
The state transition to the paying state depends on a single variable. This
is the variable that records whether the customer has decided to complete
shopping. Therefore, the state of the online shop is an abstraction of the
programmatic state of the system.
16 1 Introduction

Behavioural models can represent both detailed states and high-level states.
The use of the model depends on the modelling goal. If the behaviour of
programs is the centre of attention then detailed representation of states has
to be considered, which might use the current values of program variables.
To reduce complexity and to allow one to cope with the complexity of
software systems, abstract characterisations of states may sometimes be more
useful than detailed characterisations. It should to be stressed that even when
detailed states are considered in a state diagram, the diagram provides an
abstraction. For instance, if the state of an integer variable is represented by a
state diagram, the states abstract away the physical aspects of the variable,
such as its internal representation or the memory locations of the values stored.
To this end, even a program expressed in a programming language is a model
that abstracts away the details of the program’s representation in the computer
system.
Owing to the abstraction of states in the online shop example, not all
actions that are performed by the system actually trigger a transition in the
state diagram. For instance, when the system is in the shopping state, the
customer may put additional products in the shopping cart. This results in a
series of actions by the system, such as updating the data for the shopping
cart storage. However, only certain actions actually cause a state transition,
for instance choosing to proceed to checkout, which triggers a state transition
from the shopping state to the paying state.
Which actions cause a state transition and which actions do not change
the state of the system is a modelling decision. The modelling goal of the
state diagram shown in Fig. 1.7 is to represent the main states of the online
shop. Therefore, the particular contents of the shopping cart and the actions
taken to change those contents are not relevant. Consequently, these actions
do not cause a change in the behavioural model. Proceeding to checkout,
however, results in a state change to Shopping completed that is relevant to
the modelling goal. This is why a corresponding state change is represented in
the model.
This discussion suggests that the model shown in Fig. 1.7 satisfies the
abstraction property of models: many actions have been disregarded, and
detailed system states have been abstracted away. By using the concept of
abstraction, we can reduce the complexity of the online shop to a few states
that are considered relevant to achieving the modelling goal.
The mapping property of models is satisfied as well, because we can map
elements of the model to the original. For instance, from the incoming arc
in the Shop entered state we can conclude that the system always starts in
that state. It can be mapped to a situation in which the system allows the
customer to browse the online shop and to add articles to the shopping cart.
The behavioural model provides pragmatics, because it can serve as a
replacement for the original during the design phase. For instance, engineers
can discuss with business experts whether to allow resuming shopping after
shopping has been completed and payment information has been entered.
 1.5 Modelling in System Development 17

Notice that this is disallowed by the original state diagram shown in Fig. 1.2,
but it is allowed by the diagram shown in Fig. 1.7, because of the edge from
the Shopping completed state to the Shop entered state.
This is one of the main purposes of engineering models: to discuss alterna-
tives in the design of a system. Models are a concise way of specifying important
aspects of the system to be developed, without people being distracted by
technical details of the software code. A further aspect of system design emerges
here. Systems should always satisfy the constraints which are represented in
the models that describe them.

1.5 Modelling in System Development

Having introduced the fundamental concepts of the modelling of software
systems, we look at the role of modelling during system design and development
in this section. We do so using a simple system development methodology,
which is shown in Fig. 1.8.

(QDFWPHQW 'HVLJQ

,PSOHPHQWDWLRQ

Fig. 1.8: System development methodology

The methodology consists of three phases. Typically the Design phase

comes first, in which the requirements of the system are elicited and several
different models for constructing the system are developed.
After the design phase has been completed, the Implementation phase of the
system starts. When the implementation has been completed and the system
has been successfully tested, the system is deployed in the target environment.
During the Enactment phase, the system runs and serves its purposes. New
requirements can occur, so that the design phase has to be entered once again
to modify the models in such a way that these satisfy the new requirements.
Then, the implementation and enactment phases are entered once again.
In the case of the online store, imagine you are a software engineer who is in
charge of developing the software for it. The first step consists of understanding
what the online shop is supposed to provide to its customers and of developing
a design for the system. When you have completed the design, the system is
implemented.
18 1 Introduction

When the implementation has been completed and tests do not show any
errors, i.e., the system behaves as specified in the models, the software for the
online shop can be deployed and made available on the internet. At this point,
the enactment phase starts.
During enactment, new requirements might emerge. For instance, a product
reviewing system might be needed, which allows customers to write reviews of
the articles they have bought. In this case, the requirements for the extension
of the online store’s functionality have to be elicited and the system design
has to be extended accordingly, before re-entering the implementation phase
and finally the enactment phase.

5HTXLUHPHQWV
(QDFWPHQW 0RGHOOLQJ
HOLFLWDWLRQ

$QDO\VLV
,PSOHPHQWDWLRQ 9DOLGDWLRQ
9HULILFDWLRQ

Fig. 1.9: System development methodology with detailed design phase

After this introductory discussion of a system development lifecycle, we

now give detail of the role of modelling and analysis in this context. Figure 1.9
shows how the initial lifecycle is extended by refining the design phase. This
now contains three phases: Requirements elicitation, Modelling, and Analysis.
During the requirements elicitation phase, the scope of the system to
be developed is characterised, and the main building blocks of the software
are identified. During this phase, information is gathered, organised, and
represented, typically in different formats. Textual information is used to
describe different aspects of the system in an informal way.
Once there is an understanding of the scope and intended use of the system,
the informal requirements are used to develop models. During the modelling
phase, the informal and often ambiguous textual information developed during
the requirements elicitation phase is concretised by models. These models
capture both structural and behavioural aspects of the system. Data models
and architecture diagrams are examples of structural models, whereas state
diagrams and process diagrams are behavioural models. We will investigate
several types of behavioural models in detail later in this book.
Modelling is an iterative process, in which several different stakeholders are
involved. Depending on the system to be designed, the stakeholders may include
domain experts, modelling experts, software architects, software engineers,
and also other persons who can provide valuable input to the system design.
 1.5 Modelling in System Development 19

Once an initial model has been captured in the modelling phase, the model
is analysed. There are two kinds of analysis, informal and formal analysis. In
the informal analysis, the stakeholders discuss the model and evaluate whether
the model meets the modelling goals.
Typically, the first version of the model does not fully meet the modelling
goal, so that the model needs to be modified. This domain-specific, informal
analysis is called validation. Validation is a human activity. Stakeholders
communicate and answer the question of whether the model represents the
original in a sufficiently detailed manner, i.e., whether it satisfies the modelling
goal.
The formal analysis is called verification and uses mathematical precision to
answer questions in an algorithmic fashion. Formal analysis can be conducted
if the model is expressed in a mathematically precise manner, i.e., if it is a
formal model. This book will introduce a series of formal modelling languages
and ways to verify properties of models expressed in those languages. With
today’s modelling and verification techniques, generic properties of behavioural
models such as absence of deadlocks can be proven. In addition, domain-specific
properties such as compliance properties can also be investigated in the context
of system verification.
2
Discrete Dynamic Systems

This chapter introduces discrete dynamic systems by first looking at models

for dynamic and static aspects of systems, before covering continuous and
discrete systems. Transition systems are discussed and formally defined, since
these play an important role in behavioural modelling. Causality and events
are covered, because these concepts form the basis of system behaviour. An
application scenario is introduced to illustrate the concepts covered in this
chapter.

2.1 Characterisation of Dynamic Systems

Every system that we build shows some behaviour, and this is of a dynamic
nature. This section introduces a taxonomy of system models to represent
dynamic systems. The taxonomy is organised in three dimensions. The first
dimension organises models regarding the static and dynamic aspects repre-
sented. The second dimension refers to the granularity of the state changes of
a system, which can happen either continuously or in discrete steps. The final
dimension organises models in those that represent sequential behaviour and
those that allow us to model concurrent behaviour of dynamic systems.

2.1.1 System Models for Static and Dynamic Aspects

Software systems are complex entities that can only be described by looking
at different aspects in turn, using different models. We choose the type of
model depending on the particular modelling goal. If we are interested in the
structural aspects of a system, we use different modelling languages from what
we use for modelling dynamic aspects. Rather than talking about dynamic
and static systems, we discuss dynamic and static aspects of a system, using
the appropriate modelling languages.
In the previous chapter we discussed two modelling languages that can
be used to represent the dynamic and static properties of a system, i.e., data

© Springer International Publishing Switzerland 2016 21

M. Kunze and M. Weske, Behavioural Models,
DOI 10.1007/978-3-319-44960-9_2
22 2 Discrete Dynamic Systems

models and state diagrams. With state transitions, we can model dynamic
aspects and with data models static ones.
Data models describe a static aspect of a system, because they provide a
blueprint of the data stored in the system. In the example shown in Fig. 1.6,
each customer has a customer identification, a name, and an address, while
each order has an order identification, data, and an amount. Data models
specify the structure of the data processed by systems; they do not make any
stipulations about the behaviour of the system, i.e., about dynamic aspects,
respectively.
For instance, data models cannot be used to specify that a customer can put
articles in a shopping basket only after the customer has been authenticated.
Causal dependencies cannot be expressed in data models, nor in other types of
static models, such as software architectures. Therefore, data models and also
software architectures provide a means to express static aspects of systems.
In contrast, state diagrams are dynamic models, since they explicitly
consider states and the state transitions that a system can perform. In case
the of the online shop, the state diagram explicitly introduced in Fig. 1.7
represents the states of the shop and the state transitions that are possible.
We can use state diagrams to impose constraints on the behaviour of systems,
for instance by allowing an order to be paid for only after shopping has been
completed. Since state diagrams allow us to express constraints on system
behaviour, they describe dynamic aspects of systems.

2.1.2 Continuous and Discrete Systems

Computer systems are discrete systems, where a state is specified by a collection

of binary values. But there might be system components that are of continuous
nature, for instance components containing sensors that provide continuous
values. Dynamic systems can be organised into continuous and discrete systems.
In a continuous system model, states are represented by a continuous
domain and state transitions are specified by a continuous function, whereas
state changes occur in steps in discrete dynamic systems.
An example of a continuous system is an inductor–capacitor circuit, which,
in the simplest case, is an electric circuit consisting of an inductor and a
capacitor. It is used, for instance, to isolate frequencies in complex signals.
Figure 2.1a shows a schematic view of such a circuit, where L stands for the
inductor and C for the capacitor.
Without going into the technical details, the LC circuit works as follows.
If a charged capacitor is connected to an inductor, an electric current will
flow through the inductor, thereby discharging the capacitor, which creates a
magnetic field in the inductor. Once the capacitor is discharged, the magnetic
field induced in the inductor causes an electric current to flow in the circuit
in the same direction. This results in the capacitor being charged again, this
time in reverse polarity. Then the process starts all over again.
 2.1 Characterisation of Dynamic Systems 23

voltage
current

& /

(a) LC circuit (b) Variation of voltage and electric current with time

Fig. 2.1: System model of an inductor–capacitor circuit

The LC circuit is a continuous system. The state of the system, i.e., its
voltage and current, consists of continuous dimensions. The state transitions are
continuous functions that change the state over time, as depicted in Fig. 2.1b.
As the capacitor is charged with the opposite polarity by the induced magnetic
field in the inductor, the voltage and current alternate between positive and
negative values.
This diagram shows that the voltage is highest when the capacitor is
maximally charged and no electric current is flowing through the circuit,
whereas the current is maximum when the capacitor is discharged and the
voltage is zero. Owing to electrical resistance in the circuit, the maximum
values of the current and voltage slowly decrease.
The majority of models in computer science, however, are not concerned
with continuous behaviour, as one is interested in the operations that a system
performs to achieve its goal. Examples are the operations executed by an
algorithm and the activities carried out to decide whether a credit application
should be granted or not.
For this purpose, the continuous time dimension is discretised. That is, it
is split into intervals and the system is described only at the expiration of
each interval. As a consequence, the states of a system can be represented by
a set instead of by a continuous dimension. Depending on the modelling goal,
a state may include an identity, a textual description, or a composite model
itself, for instance a data model. Then, the state transitions form a temporal
relation between states.
This is in line with the physical construction of a computer. In the electrical
circuits of a CPU, low and high voltages denote values of 0 and 1, respectively.
As the voltage is a continuous function of time, a clock is introduced and
voltages are interpreted only at clock ticks. Discrete dynamic systems adopt
this concept by imposing a discrete time model. At any point in time, the
system is in one particular state, whereas the state of the system may change
when a clock tick occurs.
24 2 Discrete Dynamic Systems

As mentioned above, computer systems are of a discrete nature. We have

witnessed this property in the online store example and its state diagram,
which consists of a set of discrete states and transitions between them.
Since discrete dynamic system models are at the centre of this book, the key
properties of these models will be illustrated by an additional example, shown
in Fig. 2.2. This figure shows the states of a machine that produces metal
casings. Regarding the modelling language, we are using the same conceptual
model as we have already used in the first version of the online shop example.
However, there is a slight difference in the notation: states are represented by
circles, not by ellipses. We will use this notation again later in this book to
express different types of state diagrams.
In Fig. 2.2, circles represent the states of the machine; state transitions are
shown by directed arcs. The arrowhead of an arc denotes the target state that
can be reached from the source state through a state transition. The machine
starts when a piece of metal is available as raw material for the production
of a casing. The piece is first cut into a rectangular shape, which is then
bent into a cylinder. The edges are welded and, finally, the casing is cooled.
The model abstracts away the actual time needed to produce the casings and
represents only the ordering of states.

0DWHULDO &\OLQGHU -RLQW &DVLQJ

3DUWFXW
UHDG\ PRXOGHG ZHOGHG FRROHG

Fig. 2.2: Model of a machine that produces metal casings

The above example describes a machine that performs production steps,

without investigating the nature of the state transitions. A variant of the
diagram is shown in Fig. 2.3, in which each state transition is marked with a
label that describes an action carried out during production. This model is
richer, since it identifies the actions required for each state transition.

3URGXFW
UHDG\
2EWDLQUDZ $VVHPEOH
0DQX PDWHULDOV SURGXFW 3URGXFW
0DFKLQH
IDFWXULQJ PDQX
IURP UHDG\
VWDUW IDFWXUHG
ZDUHKRXVH
3URGXFW
IDXOW\

5HF\FOHSURGXFWPDWHULDOV

Fig. 2.3: Model of a manufacturing process

 2.1 Characterisation of Dynamic Systems 25

When production starts, raw material needs to be obtained from the

warehouse and placed into the machine. Once the machine is ready, the
product can be assembled. When the manufacture of a product is completed,
the product is tested. The test can result in two different states: either the
test succeeds and the product is ready for shipment, or the product fails the
test and must be recycled, and production starts again.

2.1.3 Sequential and Concurrent System Models

The systems discussed so far are of a sequential nature. In the online shop, a
customer first enters the shop and selects products, before submitting payment
information. Finally, the products are shipped and the process completes.
Sequential behaviour can be characterised by a sequence of state transitions.
The sequence of states of the online shop can be seen in the state diagram
shown in Fig. 1.2.
Sequential behaviour can also include choices. In a state diagram, a choice
is represented by a state with multiple transitions. We have seen this type
of state diagram in the manufacturing machine example. Figure 2.3 shows
this situation because, after the product has been manufactured, either the
state Product ready or the state Product faulty is reached. In either case, the
behaviour of the system is sequential. Models to capture the behaviour of
sequential systems will be covered in Chapter 3.

6\VWHP0RGHO

6WDWLF '\QDPLF

&RQWLQXRXV 'LVFUHWH

6HTXHQWLDO &RQFXUUHQW

Fig. 2.4: Classification of systems and system models

Whenever a system contains several subsystems that can proceed indepen-

dently of each other, sequential models are not adequate for capturing the
behaviour of the system. The behaviour of these types of systems is called
concurrent, because there are subsystems that are active and can proceed
at the same time, concurrently. Specific modelling concepts and languages
have been introduced to represent concurrent systems. These concepts and
languages will be covered in Chapter 4.
26 2 Discrete Dynamic Systems

A categorisation of systems and their respective system models is shown

in Fig. 2.4. The top part of that figure shows a broad classification of system
models into static and dynamic ones. The respective models have been sketched
in this section.
Some key properties of sequential and concurrent systems have also been
touched upon. A complete picture of system models will be provided in Chap-
ters 3 and 4, when sequential and concurrent system models are investigated.

2.2 Transition Systems

In order to reason about the behaviour defined by discrete dynamic system
models, state transition systems need to be formally defined.

2.2.1 State Transition System

A state transition system was informally introduced in the previous chapter

to describe the behaviour of an online shop, as shown in Fig. 1.2. A state
transition system consists of a set of states and a state transition relation. It
is formally defined as follows.

Definition 2.1 A state transition system is a pair (S, δ), where

• S is a finite set of states,

• δ ⊆ S × S is a state transition relation. 

The set of states and the state transition relation can be visualised by a
graph representation, which consists of nodes and edges. Each state s ∈ S is
represented by a node, and each state transition (s, s ) ∈ δ by an edge between
states s and s . Since (s, s ) is an ordered pair, the edge is directed from s to
s .
From Definition 2.1, it follows that two nodes can be connected by at most
one edge in the same direction.
To illustrate the concept of a state transition system, we revisit the be-
havioural model of the online shop shown in Fig. 1.2. For convenience, we
abbreviate the states as follows: Shop entered (se), Shopping completed (sc),
Order paid (op), and Products shipped (ps). Formally, this state transition
system can be described by (S, δ), such that

S = {se, sc, op, ps}.

The four states, represented by ellipses in the graphical representation of the

state transition system, are reflected by the four elements in the set of states.
With these states, the transition relation shown in Fig. 1.2 is defined by
 2.2 Transition Systems 27

δ = {(se, sc), (sc, op), (op, ps)}

The three arcs shown in the graphical representation of the state transition
system in Fig. 1.2 are reflected by the three tuples in the transition relation.

3URGXFW
UHDG\
SU
0DQX 3URGXFW
IDFWXULQJ 0DFKLQH PDQX
UHDG\
VWDUW IDFWXUHG
PV PU SP
3URGXFW
IDXOW\
SI

Fig. 2.5: State transition system of production machine

To discuss the semantics of state transition diagrams in more detail, a

variation of the production process introduced earlier is shown in Fig. 2.5. The
variant used here has the same states as in the one discussed earlier, but the
state transitions are not labelled.
This state transition system consists of five states with their respective
abbreviations: Manufacturing start (ms), Machine ready (mr), Product manu-
factured (pm), Product ready (pr), and Product faulty (pf). (S, δ) of this state
transition diagram are defined as follows:

S = {ms, mr, pm, pr, pf },

δ = {(ms, mr), (mr, pm), (pm, pr), (pm, pf ), (pf , ms)}.

At each point in time, the state transition system is in exactly one state s,
from which it may transition to another state s if there exists a state transition
(s, s ) ∈ δ.
If more than one state transition is possible for a given state s, for instance,
if there are two state transitions (s, s ), (s, s ) ∈ δ such that s = s , then s
and s are exclusive, i.e., exactly one state transition is chosen.
In the example, there are two transitions possible in the state Product
manufactured. Each time this state is reached, one of the transitions is used
and the other is discarded.
For instance, if in the first iteration the product is faulty, then the lower
transition to the state Product faulty is chosen and manufacturing is started
again. If the second iteration results in a product that meets its specification,
the upper transition to the state Product ready is chosen.
28 2 Discrete Dynamic Systems

2.2.2 Labelled State Transition System

So far the behaviour of discrete dynamic systems has been represented by

states and state transitions. The state transition diagram of the online shop,
for instance, had several states and transitions between them. However, we
did not represent any actions in the system that actually triggered these
transitions. In this section, we present not only the modelling of the states and
state transitions of a system, but also that of the actions that trigger these
transitions.

6KRS &KHFNRXW 6KRSSLQJ 3D\RUGHU 2UGHU 6KLSSURGXFWV 3URGXFWV

HQWHUHG FRPSOHWHG SDLG VKLSSHG
VH & VF 3 RS 6 SV

Fig. 2.6: States and labelled state transitions for an online shop

Figure 2.6 shows a variant of the state transition diagram for the online
shop that captures these actions. This version of the model is much richer,
since it associates actions that the system takes with state transitions. Given
this model, system designers have to make sure that the shop transits from the
state Shop entered to the state Shopping completed only by an action called
Checkout.
The term “action” refers to any function or procedure that the system
executes to perform a state change. The abstraction property of models also
applies to state transitions. It is a modelling decision which functionality is
associated with a particular action. Therefore, the term “action” subsumes
function calls, procedure calls, and other types of events that may happen.
The model does not define any further constraints on how the checkout
action should be implemented. In the example of the online shop, this action
is typically implemented by a button in the user interface of the online shop.
When that button is clicked on, a procedure is called on the server side, which
sends a web page to the browser with the shopping cart and further information,
for example, the overall amount payable.
Models like the one shown in Fig. 2.6 are called labelled state transition
systems. They are very useful during system design, because they constrain
the execution of procedures to certain states of the system. For instance,
invoking the checkout action in the state Order paid would not make sense,
and therefore this action is disallowed in the labelled state transition diagram
shown in Fig. 2.6.
On the other hand, certain sequences of actions by the system are allowed
in the labelled state transition diagram. In the case of the online shop, the
only sequence that is allowed is Checkout, Pay order, Ship products. When we
discuss the behaviour of systems using labelled state transition diagrams, such
actions are typically referred to as “input”. So we can say that the online shop
 2.2 Transition Systems 29

can reach the state Shopping completed from the state Shop entered with the
input Checkout.
To generalise, each state transition is associated with some input, and
different inputs are represented by different symbols. The set of all input
symbols of a transition system is called its alphabet, denoted by Σ. Generally
speaking, the alphabet consists of all labels in the state transition system.
Each of these labels refers to exactly one action that can be performed by the
system.

Definition 2.2 An alphabet is a finite, non-empty set of symbols, denoted by

Σ. The symbols in Σ refer to actions that a system can perform. 

Owing to the abstraction that models provide, the software system can
perform many more actions. However, the alphabet of a labelled state transition
system represents all of the actions of a software system that are relevant
for the modelling purpose. In this book, we consider finite alphabets only, as
we are concerned with the modelling of systems for which the set of possible
actions that the system can perform is known a priori.

Definition 2.3 A labelled state transition system is a tuple (S, Σ, δ) such that

• S is a finite set of states,

• Σ is a finite alphabet, and
• δ ⊆ S × Σ × S is a state transition relation. 

In a labelled state transition system, each state transition (s, l, s ) ∈ δ

consists of a source state s and a target state s and is assigned a label l ∈ Σ.
The graphical representation of a labelled transition system is much like that of
a state transition system. Each tuple (s, l, s ) ∈ δ is represented by a directed
arc from s to s , which is labelled by l.
By using the abbreviations for the state and transition labels, we can
express the labelled state transition diagram shown in Fig. 2.6 as

S = {se, sc, op, ps},

Σ = {C, P, S},
δ = {(se, C, sc), (sc, P, op), (op, S, ps)}.

The elements of the state transition relation are no longer pairs of states
but triples, consisting of the source state, transition label, and target state.
The introduction of labels also allows us to define multiple transitions
between a given pair of states. As a consequence, there may be several edges
leading from one state to another in the graphical representation of the system
model, each of which has a different label.
30 2 Discrete Dynamic Systems

The semantics of such a situation is that the system model allows different
state transitions from a state s to a state s . Since the labels of the state
transitions are different, the actions performed by the system are different, too.
However, their effects on the modelled state change of the system are identical.
This is the result of abstraction during the modelling process. In the real
system a different action is executed, which might also have slightly different
effects on the state of the system, but this difference is not relevant to the
model and therefore is abstracted away.
An example of such a situation is given in Fig. 2.7a, where there are different
ways of sending a quote. The model expresses these different ways (sending
the quote by either email, fax, or letter), showing the system engineers that
several alternative ways of sending the quote need to be developed. However,
after sending the quote using any of these ways, the system is in the state
Quote sent.

6HQGTXRWHE\HPDLO ^6HQGTXRWHE\HPDLO
6HQGTXRWHE\ID[
5HTXHVW 6HQGTXRWHE\ID[ 4XRWH 5HTXHVW 6HQGTXRWHE\OHWWHU` 4XRWH
UHFHLYHG VHQW UHFHLYHG VHQW

6HQGTXRWHE\OHWWHU
(b)
(a)

Fig. 2.7: Two labelled transition systems for a quote management system that
have several state transitions between a given pair of states

To reduce the visual complexity of a labelled state transition system, state

transitions that share the same source and target states can written in a
compact way using a single arc. This is shown for the above example in
Fig. 2.7b. The label of the arc lists the set of inputs of these state transitions.
This is a visual simplification but has no impact on the state transition relation.
Basically, two slightly different notations have been used to express the same
set of concepts.

2.2.3 Sequences of Inputs

Traversing the state transitions of a labelled transition system leads to se-

quences of symbols. Assuming that each labelled state transition represents an
operation or activity carried out by the system, the sequences of a transition
system denote a set of valid actions and the order in which they can be carried
out. A sequence can, therefore, be interpreted as one possible behaviour of the
system modelled.
 2.2 Transition Systems 31

The set of all sequences that a labelled transition system can generate
characterises the set of all possible behaviours of that system. We formalise
these sequences based on the alphabet of labelled transition systems.

Definition 2.4 For an alphabet Σ, we define sequences as follows.

• A sequence σ of length n ∈ N is defined by a function σ : {1, . . . , n} → Σ

that assigns a symbol to each position in the sequence. We refer to the ith
position in the sequence by σ(i), 1 ≤ i ≤ n; |σ| = n is the cardinality of σ.
• The set of all sequences of length n ∈ N is denoted by Σ n ; ε denotes the
empty sequence, such that |ε| = 0.

• Σ ∗ is the set of all sequences of finite length, i.e., Σ ∗ = i ≥ 0 Σ i . 

A sequence is an ordered list of symbols from the alphabet. For a sequence

σ with σ(1) = A, σ(2) = B, and σ(3) = C, we can also write A, B, C .
We shall now illustrate this concept using the online shop example. Fig-
ure 2.8 shows a new version of the labelled state transition diagram, which
allows customers to resume shopping after checkout. This new behaviour is
represented by a state transition from the state Shopping completed to the
state Shop entered, which is labelled Resume shopping (R).

5HVXPHVKRSSLQJ 5

6KRS &KHFNRXW 6KRSSLQJ 3D\RUGHU 2UGHU 6KLSSURGXFWV 3URGXFWV

HQWHUHG FRPSOHWHG SDLG VKLSSHG
VH & VF 3 RS 6 SV

Fig. 2.8: Online shop labelled state transition system with loop

The labelled state transition diagram shown in this figure defines several
sequences. In fact, owing to the cycle in the diagram, an infinite number of
different behaviours are specified by the diagram. Consider a simple case, in
which a user enters the shop, proceeds to checkout, and pays for the order,
before the products are shipped. This behaviour is represented by the sequence

C, P, S .

If the customer chooses instead to resume shopping after the first checkout,
the following sequence occurs:

C, R, C, P, S .

Intuitively, these sequences start at the beginning of the process and end when
the shopping process is completed. However, sequences are not limited to
32 2 Discrete Dynamic Systems

this property. Any partial behaviour of the system can be represented by a

sequence; hence, the following sequences are also valid for the state transition
diagram shown in Fig. 2.8:

P, S , R, C, P , S , R, C, R, C, R, C, R, C, P .

In contrast, the following sequences do not represent valid behaviour of the

online shop:
S, P , R, S, C, P , S, C , R, R .
We can formalise these considerations in the following definition.

Definition 2.5 Let (S, Σ, δ) be a labelled state transition system. The state
transition relation for sequences δ ∗ ⊆ S × Σ ∗ × S is defined as follows.

• (s1 , σ, sk ) ∈ δ ∗ holds if σ = l1 , . . . , lk−1 and (si , li , si+1 ) ∈ δ for 1 ≤ i < k.

• The empty sequence does not advance the state of the system:

(s, ε, s ) ∈ δ ∗ =⇒ s = s


With this definition, we can show that R, C, R, C, R, C, R, C, P is a correct

sequence by providing the states before the sequence is traversed (in this case
the state sc) and the state after sequence traversal, op. It holds that

(sc, R, C, R, C, R, C, P , op) ∈ δ ∗

because

(sc, R, se), (se, C, sc), (sc, R, se), (se, C, sc),

(sc, R, se), (se, C, sc), (sc, P, op) ∈ δ.

This shows that for each label in the sequence, there is a corresponding state
transition in the state transition system that originates from the current state.
Owing to the loop in the labelled state transition system, it would of course
suffice to show that

(sc, R, se), (se, C, sc), (sc, P, op) ∈ δ.

2.3 Events and Causality

In this section we provide an abstract view of discrete dynamic systems, which
serves as a foundation for the remainder of this book. This view is based on
two essential concepts for specifying the behaviour of dynamic systems: events
and causality.
 2.4 Application of Discrete Dynamic System Models 33

An event is something that happens, a concrete occurrence in a particular

system or its environment. Events happen in the real world, such as receiving a
parcel, sending a letter, or inserting a 50 ct coin into a ticket vending machine.
Events also happen in software systems, such as pressing the checkout button
in an online shop, submitting a form with payment details, or invoking a
procedure.
Behavioural models use events and provide an ordering between events or,
more generally, define execution constraints between events. The reason for
these execution constraints is causality.
We can illustrate the concepts of events and causality by applying them
to the online shop example shown in Fig. 2.8. The labelled state transition
system captures the behaviour of the online shop. The online shop has four
states and three state transitions. State transitions represent events. When the
system is in the state Shop entered, the checkout event C can occur. However,
the payment of the order event P can only occur after the checkout event has
occurred.
The reason for this execution ordering of events is causality, and the effect
is causal ordering. Two events are causally ordered if the occurrence of one
event depends on the occurrence of the other event beforehand. In the example,
we can pay for the order (event P ) only after checkout has occurred (event C).
Therefore, the event P is causally dependent on C. There is no way that the
system can allow P to happen if C has not happened before it.
By defining causality between events, models can specify the behaviour
of dynamic systems. We have discussed causality for labelled state transition
systems, but in the remainder of this book, several techniques for expressing
causality of events in a dynamic system will be covered.
The causality defined by the state transition system shown in Fig. 2.8 can
be uncovered by looking at the execution sequence

C, R, C, P, S .

This execution sequence starts with checkout, C, followed by an event that

indicates resumption of shopping, R. Since R is causally dependent on C and
C has already occurred, this sequence of events is a valid behaviour of the
system, as specified by the labelled state transition system. Executing C, R
brings us back to the state Shop entered. Now, again, checkout has to occur,
before a payment event P can occur and the products are shipped as indicated
by the event S.

2.4 Application of Discrete Dynamic System Models

This section uses an example to investigate the mapping, abstraction, and

pragmatics properties of behavioural models that specify discrete dynamic
systems.
34 2 Discrete Dynamic Systems

The basis of this summarising example is the online shop shown in Fig. 2.6.
That diagram focused on the main phases of the online shop, disregarding
essential functionality such as authentication of users.

6KRS $XWKHQWLFDWH &XVWRPHU %HJLQ 6KRSSLQJ

HQWHUHG DXWKHQWL
VH $ FDWHG FD VKRSSLQJ % VK

&KHFNRXW
&

6KRSSLQJ 3D\RUGHU 2UGHU 6KLSSURGXFWV 3URGXFWV

FRPSOHWHG SDLG VKLSSHG
VF 3 RS 6 SV

Fig. 2.9: Online shop labelled state transition system with authentication

The state transition diagram in Fig. 2.9 represents an updated version of

the online shop which includes authentication. After entering the online shop,
customers have to authenticate first before they begin shopping. If they have
already registered at the online shop, they can use their credentials to log on
to the system.
If this is not the case, they first have to register. In any case, a customer can
start to fill their shopping cart only after they have been authenticated. This
makes sure that every shopping cart can be associated with an authenticated
customer.
When the customer has selected the desired products, they can proceed to
checkout by selecting the checkout button on the web page of the online shop.
Thereby the Checkout state transition is performed, and the system changes
its state to Shopping completed.
Both states involved are abstractions of the original, i.e., the software
system that implements the online shop. But the Checkout state transition
is also an abstraction, because it represents an action in the software system
that triggers the state change.
Technically, many operations are executed to achieve this state change.
After the user has clicked on the appropriate button, the client sends an HTTP
request to the web server of the online store. On receiving this request, the
web server invokes a procedure in the application server that finally invokes a
stored procedure in the database system to store the information persistently,
including the contents of the customer’s shopping cart.
This discussion shows the abstraction that takes place regarding state
transitions in behavioural models.
The mapping property of models also holds, because the selection of the
checkout button leads to a state change in the system, which is represented
in the model. This state change is also reflected on the client side, i.e., the
 2.4 Application of Discrete Dynamic System Models 35

web page that is sent to the customer’s web browser. This page shows the
contents of the shopping cart and associated information, for example, the
amount payable. The state transition in the model can be mapped to a series
of steps that are taken by the system to complete shopping.
The model also satisfies the pragmatics property, because it can serve as
a replacement for the software system. We can discuss the behaviour of the
system and the states that are reachable from a given state without being
distracted by details of the technical implementation. The pragmatics property
is important when it comes to new requirements that have to be incorporated
into a software system.
Based on the version of the online shop specified in Fig. 2.9, we now assume
that new requirements emerge.

6KRS %HJLQ &KHFNRXW 6KRSSLQJ

HQWHUHG 6KRSSLQJ FRPSOHWHG
VH VKRSSLQJ % VK & VF

$XWKHQWLFDWH
$

&XVWRPHU 3D\RUGHU 2UGHU 6KLSSURGXFWV 3URGXFWV

DXWKHQWL SDLG VKLSSHG
FDWHG FD 3 RS 6 SV

Fig. 2.10: Labelled state transition system for online shop after new require-
ments have been incorporated

By analysing web logs, the management team finds out that in many cases
customers have left the shop without authenticating. The inference is that
customers do not want to authenticate before they browse the shop and find
products that they like. Clearly, before paying for their order, customers need
to have authenticated, but they do not need to do so before then. This leads to
a the new requirement to delay authentication until the latest possible point
in time, i.e., immediately before payment.
The labelled state transition system proves useful in redesigning the online
shop accordingly. The management team decides to shift the state Customer
authenticated to after the state Shopping completed but before the state Order
paid. This allows customers to enter the shop and immediately start shopping,
before being asked for authentication. The resulting extended version of the
online shop is shown in Fig. 2.10.
36 2 Discrete Dynamic Systems

Bibliographical Notes
The fundamentals of modelling, including the model characteristics discussed
in this chapter, were introduced in a seminal book by Stachowiak (1973). There
are several books on modelling in computer science. Henderson-Sellers (2012)
looks at modelling from a mathematical and ontological perspective. Different
aspects related to the syntax and the semantics of models in computer science
are discussed by Harel and Rumpe (2004).
In a book edited by Embly and Thalheim (2011), different types of concep-
tual models are discussed, ranging from data models to interaction modelling
and modelling of systems requirements. The representation and analysis of
business processes are the central features of a textbook by Weske (2012),
which introduces the concepts of process modelling and a set of languages to
represent business processes.
 Part II

Models of Behaviour
3
Sequential Systems

In this chapter, techniques to model sequential systems are covered. We start

by introducing finite automata, which allow us to capture behaviour using just
a few concepts. In the succeeding sections, automata are enriched with output
and with further concepts, including variables and conditional state transitions.
This discussion brings us to state machines, the current standard for modelling
sequential systems; state machines are part of the Unified Modeling Language.
We have seen in the previous chapter that labelled transition systems model
the behaviour of discrete dynamic systems by a set of states that a system
may be in and actions that lead to state transitions. Since a system can only
be in one state at any given point in time and state transitions can appear
only one after another, these models capture sequential behaviour.

Definition 3.1 A system shows sequential behaviour if all events of the system
are totally ordered. 





Fig. 3.1: A ticket vending machine

To illustrate sequential behaviour of a discrete dynamic system, we in-

troduce a ticket vending machine. As sketched in Fig. 3.1, the machine can

© Springer International Publishing Switzerland 2016 39

M. Kunze and M. Weske, Behavioural Models,
DOI 10.1007/978-3-319-44960-9_3
40 3 Sequential Systems

communicate with its environment by receiving input and providing output.

The customer can select tickets from a user menu and insert coins into a slot.
The machine can return tickets and, if too much has been paid, give change.
The ticket vending machine has sequential behaviour because all of the
steps that occur from the selection of tickets by the customer to returning the
tickets and the change are totally ordered. The state of the vending machine
can be modelled by a labelled state transition diagram. The state of the
vending machine can be changed by actions that are performed. Choosing a
ticket and inserting a coin are examples of such actions.

3.1 Finite Automata

State transition systems, as introduced in Section 2.2, capture behavioural
aspects of dynamic systems by use of a discrete set of states and state transitions.
In many cases, however, it is essential to capture also the start and termination
of a system. This allows us to specify the behaviour of systems from start to
finish. Extending labelled state transition systems with initial and final states
results in finite automata.
The assumption of finite automata is that the system is in a particular
state when it is started. This state is called the initial state. Every system has
exactly one initial state.
In the example of the ticket vending machine, the system is in its initial
state when it has been turned on and is ready for operation. Hence, the
first possible action is selecting a ticket. If such an initial state had not been
determined, it would have been possible to start by entering coins without
first choosing a ticket, which is not a desirable behaviour of the system.
If a final state is reached, the system can terminate. In most cases, finite
automata should allow a final state to be reached, but there are also situations
in which continuous operation of the system is desired. We will discuss such
a system later in this section; this is a variant of the ticket vending machine
that returns to the initial state immediately after issuing a ticket.
In the current version of the ticket vending machine, however, the purchase
terminates when the ticket has been supplied and any change has been returned.
If the system is in a state that is not a final state and that state cannot be
left, then the system is stuck, which denotes a behavioural defect.
More than one final state may be devised for a system. For instance, if the
purchase of a ticket is cancelled, the system cannot terminate by supplying a
ticket but must return all coins that have been inserted so far. A model must
represent all of the different outcomes that are relevant for the modelling goal
by different final states. These considerations lead to the following definition of
automata, which extends transition systems by adding initial and final states.

Definition 3.2 An automaton is a tuple A = (S, Σ, δ, s0 , F ), such that

• S is a set of states,
 3.1 Finite Automata 41

• Σ is a finite alphabet,
• δ ⊆ S × Σ × S is a state transition relation,
• s0 ∈ S is the initial state, and
• F ⊆ S is a set of final states. 

With this definition, we can specify an automaton that captures the be-
haviour of the ticket vending machine. This automaton is depicted in Fig. 3.2.

1¼

select
Ticket ticket 0¼ 50ct 0.5¼ 50ct 1¼ 50ct 1.5¼ confirm Ticket
selection paid paid paid paid supplied

1¼

cancel
cancel Ticket
cancel cancelled
cancel

Fig. 3.2: A finite automaton for a ticket vending machine

The initial state of the automaton is denoted by an incoming arc that has
no source state. In the diagram, this state is called Ticket selection. The system
has two outcomes, representing the selling of the ticket and the cancellation
of the vending process. These outcomes are represented by two final states,
called Ticket supplied and Ticket cancelled. In the graphical representation of
automata, final states are denoted by a double border.
Our ticket vending machine comes with several simplifications. We assume
that all tickets cost 1.50 A C and the machine accepts only precise amounts of
50 ct and 1 A
C coins, i.e., it does not need to give any change. These assumptions
lead to the following alphabet that covers the possible inputs to the ticket
vending machine:

Σ = {select ticket, 50 ct, 1 A

C, confirm, cancel}.

The symbols 50 ct and 1 A C represent inserting a coin of the corresponding

value. Since it is possible to pay 1.50 A
C using different combinations of coins,
and different orderings of inserting them, several states have to be introduced
to capture the amount of money that has already been inserted:

{0 A
C paid, 0.5 A
C paid, 1 A
C paid, 1.5 A
C paid} ⊂ S.

In the state 0 A
C paid, a customer may insert either a 50 ct coin or a 1 A C coin
and the value of the coin inserted is stored in different subsequent states. These
42 3 Sequential Systems

alternatives are represented by the following state transitions, which share the
same source state:

(0 A
C paid, 50 ct, 0.5 A
C paid) ∈ δ,
(0 A
C paid, 1 A
C, 1 A
C paid) ∈ δ.

If the customer inserts a 50 ct coin first, then they might insert another 50 ct
coin or a 1 A
C coin. However, if 1 A
C was inserted first, adding another 1 A
C would
exceed the ticket price. Hence, in the state 1 AC paid, the automaton accepts
only a 50 ct coin.
The complete set of tuples in δ is shown in Fig. 3.2. In particular, each
arc from state s to s labelled l in the automaton is represented by a state
transition (s, l, s ) ∈ δ.
The automaton allows us to cancel the ticket purchase at any time after
starting but before completing the purchase. Therefore, state transitions with
the label cancel have been introduced accordingly.
In order to extend the ticket vending machine in such a way that it offers
tickets at different prices, new states need to be introduced. For each different
ticket type, a new state that starts accepting coins needs to be created. For
each of these states, the logic to accept the correct amount of money needs to
be adapted. This leads to an increasing number of states and state transitions.
Nevertheless, the automaton will still be finite.

Definition 3.3 An automaton A = (S, Σ, δ, s0 , F ) is finite if and only if the

set of states S is finite. 

To properly model the behaviour of computer systems, the number of

reachable states of any corresponding automaton needs to be finite, since part
of the modelling goal is to define all relevant states that the system can be
in, and the capabilities the system offers in those states. However, extending
automata with more elaborate concepts can lead to infinite automata. These
will be sketched in Section 3.3.
If the set of states and the alphabet of an automaton are finite, then the
state transition relation δ is also finite. This follows from Definition 3.2, where
the state transition relation is defined as δ ⊆ S × Σ × S. That is, there exists
at most one state transition from any source state to any target state for each
symbol of the alphabet. Altogether, this leads to |δ| ≤ |S| · |Σ| · |S| tuples in
the state transition relation.

3.1.1 Sequences to Capture the Behaviour of Automata

The behaviour of a sequential system can be expressed by the set of execution

sequences that are provided by an automaton that models the behaviour
of the system. To express a correct execution of the system, an execution
 3.1 Finite Automata 43

sequence needs to be complete with respect to the initial and final states of
the automaton.
Execution sequences have already been introduced in Section 2.2. Here, we
refine the notion of execution sequences for automata such that every sequence
starts in the initial state and ends in a final state of the automaton. We refer
to these sequences as complete execution sequences, from now on.
For the example automaton shown in Fig. 3.2, each execution sequence
starts with select ticket and terminates with either confirm or cancel. An
example of a complete execution sequence is

select ticket, 50 ct, 1 A

C, confirm .

Alternatives are modelled in the automaton by different state transitions that

emerge from a given state. In this example, the customer inserts first a 50 ct
coin and then a 1 AC coin. The customer might also have chosen to insert the
coins in the reverse order.
Each case yields a different execution sequence. Also, as the customer may
choose to cancel the ticket purchase, several different execution sequences are
possible, including

select ticket, cancel ,

select ticket, 1 A
C, cancel .

We can describe the behaviour of the ticket vending machine by the sequences
that the corresponding automaton can generate. The set of all these sequences
for a given automaton is called the language of the automaton.1

Definition 3.4 Let A = (S, Σ, δ, s0 , F ) be a finite automaton. The language

LA of A is the set of all sequences that start in the initial state and end in a
final state, i.e., LA = {σ | (s, σ, s ) ∈ δ ∗ , s = s0 ∧ s ∈ F }. 

The language of the automaton shown in Fig. 3.2 consists of the follow-
ing complete execution sequences. First, three execution sequences lead to
purchasing of the ticket:

select ticket, 50 ct, 50 ct, 50 ct, confirm ,

select ticket, 50 ct, 1 A
C, confirm ,
select ticket, 1 A
C, 50 ct, confirm .

We can cancel after 1.5 A

C has been inserted:

1
In theoretical computer science, sequences are called “words”. Since we use
automata to model the behaviour of systems, however, we use the term “execution
sequence” rather than “word”.
44 3 Sequential Systems

select ticket, 50 ct, 50 ct, 50 ct, cancel ,

select ticket, 50 ct, 1 A
C, cancel ,
select ticket, 1 A
C, 50 ct, cancel .

Or we can cancel after smaller amounts have been paid:

select ticket, cancel ,

select ticket, 50 ct, cancel ,
select ticket, 50 ct, 50 ct, cancel ,
select ticket, 1 A
C, cancel .

We could also use these sequences to define the behaviour of the system.
However, as this example already shows, it is quite hard to understand and
discuss the operations of a system using sequences alone. Graphical representa-
tion by automata helps people to model and discuss the behaviour of systems.
This also includes the maintenance of systems, for instance, when new system
requirements emerge.
To discuss this aspect, we suppose that the ticket vending machine is
extended in a way that allows us to represent multiple purchasing processes
that are carried out one after another with a single automaton. Figure 3.3
shows the corresponding adaptation. The automaton returns to its initial state
whenever a ticket is supplied or the purchase is cancelled.
This example shows that the initial state of an automaton can have incoming
arcs, and final states can have outgoing state transitions. It is even possible
that the initial state is also a final state at the same time.
After a ticket has been supplied, the automaton returns to the state
Ticket selection through a reset action. So far, actions have represented inter-
actions of the customer with the vending machine. The reset action, however,
is not triggered externally by a customer, but internally by the system. Never-
theless, the behavioural specification of the system needs to take this action
into account.
Recall that a complete execution sequence always terminates in a final state.
Since Ticket selection is the only final state of the automaton shown in Fig. 3.3,
every complete sequence needs to terminate in the state Ticket selection. As
this is the initial state of the automaton, the empty sequence ε constitutes a
complete execution sequence in terms of Definition 3.4:

(Ticket selection, ε, Ticket selection) ∈ δ ∗ .

The automaton allows an arbitrary number of iterations, to reflect the many

tickets that the vending machine may sell to its customers. Therefore, the set
of execution sequences is unbounded. Nevertheless, the automaton shown in
Fig. 3.3 is finite, because the number of states it consists of is finite.
 3.1 Finite Automata 45
reset

1¼

select
Ticket ticket 0¼ 50ct 0.5¼ 50ct 1¼ 50ct 1.5¼ confirm Ticket
selection paid paid paid paid supplied

cancel
1¼
cancel

cancel

cancel

Fig. 3.3: A finite automaton that returns to its initial state

3.1.2 Deterministic Finite Automata

In each labelled transition system and each automaton studied so far, one
action leads to exactly one subsequent state. For instance, in the online shop
example shown in Fig. 2.8, the action Checkout (C) leads from the state
Shop entered (se) to the state Shopping completed (sc). In the state se with
a given input C , there is exactly one state that can be reached in one step,
namely sc.
We call this behaviour deterministic because, given a state (here se) and
an action (C ), the next state is uniquely determined (sc). In deterministic
automata, all transitions from a given state s have different labels, i.e.,
(s, l, s ), (s, l , s ) ∈ δ ∧ s = s =⇒ l = l .
Different arcs that emerge from a given state are distinguished by different
actions, denoted by different symbols from the alphabet Σ that label the state
transitions in an automaton. This makes sure that all choices are deterministic.
If we take a close look at Definition 3.2, however, this constraint cannot
be found. State transitions are defined by a relation, i.e., a set of tuples that
consists of a source state, an action from the alphabet, and a target state. The
definition does not exclude the possibility of two different state transitions
that share the same source state and the same symbol:
(s, l, s ), (s, l, s ) ∈ δ =⇒
 s = s .
If, from a state s, there is more than one next state s , s possible with a
given input l, the choice is not determined by the automaton. To describe
the behaviour of the system, we must recognise that all choices are possible,
and the next state is not determined by the input label. Therefore, we call
this behaviour non-deterministic. Non-deterministic finite automata will be
addressed below.
46 3 Sequential Systems

The considerations regarding deterministic finite automata lead to a defini-

tion that makes sure that for any given state with any given input symbol,
there is at most one state transition possible. We can express this by refining
state transitions. State transitions are no longer defined by a relation, but by a
function. The mapping property of functions guarantees the desired property
of determinism: each element of the domain of a function is assigned to exactly
one element of the function’s codomain.

Definition 3.5 A finite automaton A = (S, Σ, δ, s0 , F ) is a deterministic finite

automaton if and only if the state transition relation is a partial function
δ : S × Σ  S. If δ is a total function, the automaton is called complete. 

In a deterministic finite automaton, for each state and for each symbol
from the alphabet, there is at most one state transition that leads to a target
state. Hence, the state transition is a function that maps a pair consisting of a
source state and a symbol to a target state.
The automaton shown in Fig. 3.3 is deterministic. This is due to the fact
that all outgoing arcs of each state have different labels. For instance, the state
0AC paid has three outgoing arcs, each of which has a different label, leading
to different next states.
This example also shows that not every input symbol can be applied in
every state. This is a desired property, since a system cannot perform all
actions in all states. Automata constrain the availability of actions to certain
states. Mathematically, this constraint can be expressed by defining the state
transition function to be a partial function.
A partial functions relates only a subset of its domain to elements of its
codomain. Hence, a state transition does not need to be defined for every
combination of source state and input symbol.
For example, in Fig. 3.3, the symbols select ticket and confirm are not
represented by any state transition that leaves the state 0 A
C paid. In a complete
automaton, every state has an outgoing state transition for every symbol of
the alphabet. For the reason stated above, virtually all systems are described
by partial state transition functions.
The state transition relation of a finite automaton can also be illustrated by
a matrix. Table 3.1 shows the matrix for the ticket vending machine automaton
introduced in Fig. 3.3.
In the matrix, the leftmost column denotes the source states and the
topmost row denotes the symbols from the alphabet. At the intersection of a
source state and a symbol is the target state. Therefore, we find the target
state s at position (s, l) of the matrix if and only if δ(s, l) = s .
This representation shows in which states a certain input symbol can be
read. For instance, the confirm symbol can only be read in state the 1.5 A C paid,
whereas the symbol cancel can be read in all states except Ticket selection
and Ticket supplied.
 3.1 Finite Automata 47

Table 3.1: The state transition relation of the automaton in Fig. 3.3

select 50 ct 1A
C confirm cancel reset
ticket
Ticket 0AC
selection paid
0A
C paid 0.5 A
C 1AC Ticket
paid paid selection
0.5 A
C paid 1AC 1.5 A
C Ticket
paid paid selection
1A
C paid 1.5 A
C Ticket
paid selection
1.5 A
C paid Ticket Ticket
supplied selection
Ticket Ticket
supplied selection

The matrix shows that for each combination of source state and input
symbol there exists at most one target state, which satisfies the requirement of
a deterministic finite automaton. It also has a lot of gaps, where a combination
of source state and symbol has no target state because the state transition
relation of the automaton is a partial function. For complete finite automata,
there are no gaps in the state transition matrix.

3.1.3 Non-deterministic Finite Automata

In contrast to deterministic automata, non-deterministic automata have several

transitions from one source state with the same input symbol that lead to
different target states.

Definition 3.6 An automaton A = (S, Σ, δ, s0 , F ) is a non-deterministic fi-

nite automaton, if it has at least one non-deterministic choice, i.e.,

∃ s, s, s ∈ S, s = s , l ∈ Σ : (s, l, s ), (s, l, s ) ∈ δ.

In systems design, a non-deterministic choice would lead to different states

of a system, even though the same action has been performed in the same
state. Such ambiguity is typically undesired in the design of computer systems.
Computer systems most often do have deterministic behaviour. However, non-
determinism is an important aspect when it comes to analysing systems, and
this is why this concept is introduced.
48 3 Sequential Systems

An abstract example of a non-deterministic automaton is depicted in

Fig. 3.4. This automaton accepts arbitrary sequences of symbols in Σ = {0, 1}
if and only if the second last symbol is a 1. The sequences are of arbitrary
length. Examples of complete sequences are 0, 1, 0, 1 and 1, 0, 1, 1, 0, 0 .
The initial state A has two outgoing state transitions labelled 1, one leading
to state A and the other to state B. This non-deterministic behaviour is also
represented in the matrix representation of the state transition relation of the
automaton in Table 3.2, where the combination of the source state A and the
input symbol 1 leads to a set of target states {A, B}. In state A, the automaton
processes symbols 0 and 1 until only three symbols are left in the sequence. If
the next symbol is a 1, the automaton can reach state B, which ultimately
leads to the automaton reaching its final state.
This discussion sketches the semantics of non-deterministic automata. Just
as in a deterministic finite automaton, the semantics is the set of sequences that
it can accept. In the case of a non-determinisitic finite automaton, however,
there need to be smart choices for a given input sequence. The automaton
could process the complete sequence while remaining in state A, but then its
final state would not be reached. There is also the option that the last three
input symbols are processed by entering states B, C, and finally D, which
leads to a proper termination. Hence, this sequence can be accepted by the
automaton.

Table 3.2: State

^` transition relation
of the automaton
shown in Fig. 3.4
 ^` ^`
$ % & '
0 1
A {A} {A, B}
Fig. 3.4: An abstract non-deterministic finite automa-
B {C} {C}
ton
C {D} {D}

Non-deterministic finite automata can be translated into deterministic

automata that show the same behaviour. The latter are more complex, since
additional states and state transitions are required. In the worst case, the
number of states grows exponentially, which makes analysis far more difficult.
We will confine our attention to deterministic automata in the remainder of
this chapter and return to non-deterministic automata only later, when we
address the analysis of discrete dynamic systems.
 3.2 Automata with Output 49

3.2 Automata with Output

In the first part of this chapter, automata were used to model the behaviour
of sequential systems that interact with their environment by responding to
input. The ticket vending machine illustrated this approach: customers provide
input to the automaton. Depending on the input provided and the current
state of the automaton, corresponding state transitions occur. In particular,
an inserted symbol represents an action that results in the transition from one
state to a subsequent state.
This approach neglects the fact that systems also provide output to their
environment. From a modelling perspective, we can state that the finite
automata studied so far abstract away the output provided by the systems.
In this section, finite automata are enhanced with output, which allow the
modelling of systems with dedicated input and output more precisely.
Owing the limited expressiveness of finite automata discussed so far, the
output of the ticket vending machine had to be modelled by a particular state,
for instance the state Ticket supplied. For the same reason, the automaton
was also not able to accept arbitrary amounts of money and return change.
Analogously to the representation of the input of an automaton by its
input alphabet Σ, its output is captured by an output alphabet, denoted by Λ.
The output of an automaton can depend solely on the state the automaton is
in, or it can be bound to a state transition. These two kinds of automata with
output are named Moore automata and Mealy automata, respectively.

3.2.1 Moore Automata

The output of a Moore automaton depends only on its current state, and this
output is provided whenever the state is entered. We capture this intuition by
the following definition.

Definition 3.7 A Moore automaton is a tuple AMoore = (S, Σ, Λ, δ, λ, s0 , F ),

where

• (S, Σ, δ, s0 , F ) is a deterministic finite automaton,

• Λ is a finite output alphabet, and
• λ is a function that assigns an output sequence to each state, i.e.,
λ : S → Λ∗ . 

The output function enables the automaton to produce several symbols as

output when entering a state. If no output is required in a state s, we assign
the empty sequence to the output function, λ(s) = ε.
To explain the output function with an example, we extend the ticket
vending machine with the capability to accept larger amounts of money than
the ticket price and return change.
50 3 Sequential Systems

Figure 3.5 shows the corresponding Moore automaton. To focus on the

output and avoid unnecessary complexity, we have removed the cancellation
transitions and the iteration to reset the automaton to its initial state after a
ticket has been supplied. This Moore automaton shows how one ticket can be
purchased and how change is returned, if necessary.

2¼SDLG
2¼ / 50ct confirm

3¼SDLG confirm
1¼
/ 1¼,50ct
1¼ 2¼

select
Ticket
Ticket ticket 0¼SDLG 50ct 50ct 50ct confirm
0.5¼SDLG 1¼SDLG 1.5¼SDLG supplied
selection / selection
/ ticket

1¼
2.5¼
/ 1¼ confirm
2¼

Fig. 3.5: A Moore automaton that returns change

In Moore automata, the output is represented by an additional label on

the state, separated by a forward slash. For instance, the label of the second
reachable state, 0 A
C / selection, consists of
• the state label, 0 AC paid, which represents the amount of inserted coins,
and
• the output in that state, selection, an output message that represents the
ticket selection of the customer.
If, in the state 0 A
C paid, a 2 A
C coin is inserted, the ticket is paid for and
the machine returns 50 cents change. This behaviour of the system is captured
in the state 2 A
C paid by the output sequence 50 ct . In the annotation of such
a diagram, we omit the angle brackets of the output sequences. The ticket
vending machine accepts no more coins when the amount inserted is greater
than or equal to the ticket price.
If the customer has paid 3 A C, the machine returns 1.50 A C. That is, two
coins must be returned in change. This is possible because the output function
maps to a sequence of output symbols, here a sequence of returned coins.
The output in the state 3 A C paid is a sequence 1 A C, 50 ct . This is expressed
by a comma-separated list of output symbols in the diagram. Note that the
automaton modelled will always return this sequence of change coins.
 3.2 Automata with Output 51

The automaton does not provide an output for each state. For instance, in
the state 0.5 A
C paid, the forward slash separator and the output are missing.
In the graphical representation of states in which the automaton produces no
output, the output is omitted, as well as the forward slash that separates the
state identifier from the output sequence.
Just like the state transition function of a finite automaton, the output
function can be represented by a matrix. This is depicted in Table 3.3 for the
automaton in Fig. 3.5. An empty output sequence is denoted by .

Table 3.3: Output function of the Moore automaton in Fig. 3.5

s∈S λ(s) s∈S λ(s)

Ticket selection  2A
C paid 50 ct
0A
C paid selection 2.5 A
C paid 1 A
C
0.5 A
C paid  3A
C paid 1 A
C, 50 ct
1A
C paid  Ticket supplied ticket
1.5 A
C paid 

3.2.2 Mealy Automata

Moore automata generate an output sequence whenever a state is reached.

Even if a state is reached by different state transitions, the output is always the
same. The situation is different for Mealy automata, because these associate
output sequences with state transitions. Thereby, different ways to enter a
given state can generate different output sequences.

Definition 3.8 A Mealy automaton is a tuple AMealy = (S, Σ, Λ, δ, λ, s0 , F ),

where

• (S, Σ, δ, s0 , F ) is a deterministic finite automaton,

• Λ is a finite output alphabet, and
• λ is a partial function that assigns each state transition an output sequence,
i.e.,
λ : S × Σ  Λ∗ , with(s, l, ω) ∈ λ ⇐⇒ (s, l, s ) ∈ δ.


Mealy automata assign output sequences to state transitions. That is, if

there exists an output sequence ω for a pair consisting of a source state s and
an input symbol l in the output function, i.e., (s, l, ω) ∈ λ, there also exists a
state transition (s, l, s ) ∈ δ with an identical source state and input symbol
that leads to a state s .
52 3 Sequential Systems

The close coupling of the state transition function and the output function
can also be expressed by a combination of the two functions that maps source
states and input symbols to output sequences and target states:

δ̂ : S × Σ  Λ∗ × S.
The combined state transition function then comprises tuples (s, l, ω, s ). Con-
sequently, state transition arcs in Mealy automata that lead from a source
state s to a target state s are labelled by the input symbol (l), a forward slash
(/), and the output sequence (ω).
The diagram in Fig. 3.6 depicts a Mealy automaton for the ticket vending
machine. If a state transition emits no output, i.e., the empty sequence ε, the
forward slash and the empty-sequence brackets are omitted.

2¼ / 50ct

1¼ 2¼/1¼

select
Ticket ticket 0¼ 50ct 0.5¼ 50ct 1¼ 50ct 1.5¼ confirm Ticket
selection paid paid paid 1¼ / 50ct paid / ticket supplied
/ selection

1¼ 2¼ / 1¼,50ct

Fig. 3.6: A Mealy automaton that returns change

For any given input, the Mealy automaton behaves exactly like the Moore
automaton shown in Fig. 3.5. That is, for a given sequence of input symbols,
both automata provide the same sequence of output symbols.
The Mealy automaton, however, has a different structure. In particular,
fewer states are required. If two or more state transitions share the same source
state and the same target state but are labelled with different input symbols,
they can have different output sequences in a Mealy automaton. In a Moore
automaton this is not possible, so that multiple states are required to capture
the same behaviour.
Consider the state transitions that lead from the state 0.5 A C paid to the
state 1.5 A
C paid. The state transition labelled 1 AC results in an empty output
sequence, as the amount of 1.5 AC is reached exactly, whereas the state transition
that takes 2 A
C as input needs to return change, resulting in the output sequence
1AC.
The output function of a Mealy automaton can be represented by a matrix,
similarly to Moore automata. However, the actual output sequences depend
on the source states and input symbols. The combined output function of the
automaton, denoted by δ̂, is depicted in Table 3.4. This function maps pairs
 3.2 Automata with Output 53

of a source state and an input symbol to pairs of an output sequence and a

target state. The matrix shows the source state in the leftmost column and
the input symbol in the top row.

Table 3.4: Output function of the Mealy automaton in Fig. 3.6

select ticket 50 ct 1A
C
Ticket Selection (0 A
C paid, selection)
0A
C paid (0.5 A
C paid,  ) (1 A
C paid,  )
0.5 A
C paid (1 A
C paid,  ) (1.5 A
C paid,  )
1A
C paid (1.5 A
C paid,  ) (1.5 A
C paid, 50 ct)
1.5 A
C paid

2A
C confirm
Ticket Selection
0A
C paid (1.5 A
C paid, 50 ct)
0.5 A
C paid (1.5 A
C paid, 1 A
C )
1A
C paid (1.5 A
C paid, 1 A
C, 50 ct)
1.5 A
C paid (Ticket supplied, ticket)

3.2.3 Conclusion
Finite automata with output can be used to describe the behaviour of dynamic
systems by their internal states and state transitions and by the output
generated. State transitions can be triggered from the system’s environment
by actions, represented by the input alphabet, to which the automaton reacts
and gives feedback, represented by the output alphabet.
The typical application of finite automata is in capturing behaviour in
terms of processing sequences of input. However, finite automata can also
model the internal aspects of software systems. In this case, the actions that a
software system performs are represented by input symbols. For example, if a
new customer needs to be stored in an enterprise application, the execution of
the procedure that stores the customer can be represented by an input symbol,
for instance Store new customer. The system can then reach a state Customer
stored.
Finite automata are widely used to represent the behaviour of systems, often
using a specific variant of automata, namely state machines. State machines
are part of the UML standard; they are based on extended automata, which
are introduced next.
54 3 Sequential Systems

3.3 Extended Automata

The previous section illustrated the use of finite automata for modelling the
behaviour of systems. While there are many application scenarios for which
finite automata are well suited, the abstraction level of finite automata is quite
high. Although abstraction is an important aspect of modelling in general and
systems modelling in particular, in certain cases we might want to represent
more detailed information in system models. Extended automata serve these
goals by extending finite automata with concepts such as variables, assignments,
and conditional state transitions.
Finite automata rely on a fixed input alphabet, which can impede efficient
modelling. For example, assume that the ticket vending machine discussed in
the previous section provides tickets for different destinations and, therefore,
different ticket prices. Each ticket price requires its own input symbol and
leads to additional states that represent the price of the selected ticket. The
same applies if a wider selection of coins and notes needs to be accepted: new
input symbols must be introduced, which in turn leads to a more complex
automaton to process the input.
The primary aim of models is to represent concepts in the domain that is
being modelled. Instead of just producing output symbols, state transitions
may yield additional effects, for example computation of change or displaying
a message on a display. On the other hand, we want to avoid complex models
that cannot serve as a basis for communication among stakeholders. We can
resolve this dilemma by introducing a more elaborate modelling technique,
based on extended automata.
This section introduces a number of extensions to finite automata with
output that make them more expressive with respect to modelling the behaviour
of computer systems. To avoid overloading the book with formalisms that
are not required for understanding the concepts and applying them, we will
introduce extended automata rather informally and discuss their semantics
primarily by means of examples.

3.3.1 Variables, Assignments, and Conditions

The first extensions to finite automata are variables, assignments, and condi-
tions. These concepts will be introduced by extending the example of the ticket
vending machine that guided us through previous sections. Assume that the
public transport company that runs the ticket vending machine offers three
types of tickets.
A ticket of type A costs 2.60 A
C, a ticket of type B costs 2.90 A
C, and a ticket
of type C costs 3.20 A
C. To extend the ticket vending machine with these ticket
choices and more elaborate means to accept payment, we introduce three
integer (int) variables that reflect the price in euro cents, where, for instance,
a ticket of type A costs 260 cents.
 3.3 Extended Automata 55

• int p represents the price of a ticket, for instance, p := 260;

• int a represents the amount of money the customer has paid already;
• int r represents the amount of money to be returned to the customer in
change.

Variables are symbols associated with a value that is bound to a specific

domain. As our variables represent amounts of money, we use the integer
domain. The term “variable” conveys the fact that this value may change over
time. For instance, the value of the variable a changes as the customer inserts
coins into the ticket vending machine.
To represent this behaviour in an extended automaton, a value can be
assigned to a variable through a state transition. Therefore, we extend the
label of a state transition by appending variable assignments to the transition’s
output. The variable assignment is separated from the output by a semicolon
symbol. If a variable is not assigned in a state transition, it keeps the value it
carried before the state transition occurred.
These concepts are illustrated by the example shown in Fig. 3.7. This
automaton offers tickets at three prices, as discussed above. To concentrate on
variables and assignments, only the first part of the automaton is shown.
The initial state Ticket selection has three outgoing state transitions, which
represent the fact that a ticket of a particular price is chosen; this is captured by
the respective action. For instance, the action ticket A represents the selection
of ticket A by the customer. For this state transition, the automaton produces
the output sel. A, separated by a forward slash from the input.
The mapping property of the model means that displaying the selection of
ticket A and its price is represented by the output symbol sel. A. The variable
assignment p := 260 follows the output, separated by a semicolon.
If the output sequence is empty or no assignments are defined, the corre-
sponding part is omitted from the transition label along with the separators.

{ ticket A / sel. A; p:=260

{ ticket B / sel. B; p:=290
Ticket { ticket C / sel. C; p:=320 } ...
Paying
selection

{ 10ct / a := a + 10,
int p:=0 { 50ct / a := a + 50,
int a:=0 { 1¼/ a := a + 100 }

Fig. 3.7: Part of an extended automaton for the vending machine

Variables are separate components of automata, because they add state

information to the system model. For every state that an extended automaton
is in, each variable has its own value.
56 3 Sequential Systems

If the automaton is in the state Paying, the variable p can have three differ-
ent values, 260 ct, 290 ct, or 320 ct, depending on the assignment. Furthermore,
when coins of value 10 cents, 50 cents, or 1 A C are inserted, the variable a is
increased by the value of the inserted coin, while the automaton returns to
the state Paying. Hence, the variable a can be assigned infinitely many values
in the same state of the automaton.
Initial values can be specified for each variable. In the automaton shown in
Fig. 3.7 this is done by an annotation in the bottom left corner of the diagram.
In this figure, int denotes the fact that the integer numbers are the domain
of the variables. The initial values are set to 0; these are assigned when the
system enters the initial state for the first time.

Conditional State Transitions

In the automata discussed so far, every state transition with a source state s
could be triggered when the automaton is in s. However, we might want to
constrain a state transition to certain conditions. The concept of a conditional
state transition is therefore introduced here using the example of the ticket
vending machine.
After the customer has selected a ticket, the customer needs to insert coins
to pay for it. An extended automaton with a state Paying and a self-loop was
introduced above. The self-loop is followed whenever a coin is inserted. The
amount already inserted is represented by the variable a. When, for example,
a 50 cents coin is inserted, the value of a is incremented by 50.
The automata discussed so far have done nothing to prevent overpaying.
However, the customer should only be allowed to insert coins if the amount
currently inserted is less than the price of the ticket. This property of the
system can be reflected in an extended automaton using conditional state
transitions. For the sake of simplicity, we consider 10 cents, 50 cents, and 1 A
C
coins only. An extension to other coins and notes is, however, straightforward.
A condition is an expression in first-order logic over the variables of an
automaton. With variables a for the amount and p for the price, we can define
an expression that returns true if and only if the amount is smaller than the
price, by a < p. By use of a conditional state transition of this form, we can
make sure that a coin can only be inserted if that condition holds. The state
Paying in Fig. 3.8 has state transitions that loop back to that state and accept
inserted coins as long as the above expression holds.
To represent conditional state transitions, we extend the state transitions
with a condition expression, resulting in the following labelling scheme:
[ condition ] input / output; assignments
condition is a first-order logic expression over the set of variables of the
automaton. The state transition can occur only if the expression evaluates
to true. The default expression is the logical constant true.
 3.3 Extended Automata 57
{ ticket A / sel. A; p:=260
{ ticket B / sel. B; p:=290 [a •p] IJ [r = 0] IJ
{ ticket C / sel. C; p:=320 } / r := a±p / ticket
Ticket Returning Ticket
Paying
selection change supplied

int p:=0 { [a < p] 10ct / a := a + 10, { [ r •50] IJ / 50ct; r := r±50,

int a:=0 { [a < p] 50ct / a := a + 50, { [50 > r > 0] IJ / 10ct; r := r±10}
int r:=0 { [a < p] 1¼/ a := a + 100 }

Fig. 3.8: Extended automaton for the vending machine

input is an action of the automaton, represented by a symbol from the input

alphabet Σ.
output is a sequence of symbols from the output alphabet Λ. Here, we use
Mealy-style output for extended automata.
assignments is a sequence of variable assignments that are carried out as
part of the state transition. It is possible to assign several variables in one
state transition. Since some of the assignments may refer to old or new
values of variables that are assigned in the same transition, the assignments
are ordered.

The outgoing state transitions of the state Paying in Fig. 3.8 are interpreted
as follows. If a < p and the customer inserts a 50 cents coin, the assignment
a := a + 50 increases the amount of a by 50. Similarly, the amount is increased
by 100 if the user inserts a 1 AC coin. Notice that no coins can be inserted if
sufficient funds have been inserted, i.e., if a ≥ p holds.
In Table 3.5, we provide an example execution of the extended automaton
for the ticket vending machine. The state of the automaton is given in the
leftmost column and the assignment of its variables in the rightmost column.
The second and third columns show the input and output of the state transitions
leaving that state.
In the initial state Ticket selection, all variables are assigned their initial
values. From this state, the customer chooses a ticket of type A, represented
by a state transition with input ticket A and output sequence sel. A . This
state transition also updates the assignment of the variable p (price) with the
price of the chosen ticket and leads to the state Paying, which waits for coins
to be inserted.
In the example, the customer inserts 50 cents. The automaton traverses
the respective state transition, increases the amount of money inserted, a, by
50 and returns to the state Paying. When coins are inserted, this behaviour is
repeated as long as the condition a < p holds true.
After the fourth iteration, marked by Paying* , we have a = 300, and
the condition a < p is not true any more. Hence, the state transitions that
accept coins cannot be used. On the other hand, the state transition leading
58 3 Sequential Systems

Table 3.5: Example execution of the automaton in Fig. 3.8

State State transition Assignment

Input Output
Ticket selection p = 0, a = 0, r = 0
ticket A sel. A
Paying p = 260, a = 0, r = 0
50 ct 
Paying p = 260, a = 50, r = 0
1A
C 
Paying p = 260, a = 150, r = 0
1A
C 
Paying p = 260, a = 250, r = 0
50 ct 
Paying *
p = 260, a = 300, r = 0
τ 
Returning change p = 260, a = 300, r = 40
τ 10 ct
Returning change p = 260, a = 300, r = 30
τ 10 ct
Returning change p = 260, a = 300, r = 20
τ 10 ct
Returning change p = 260, a = 300, r = 10
τ 10 ct
Returning change p = 260, a = 300, r = 0
τ ticket
Ticket supplied p = 260, a = 300, r = 0
 3.3 Extended Automata 59

to Returning change is enabled, because its condition a ≥ p evaluates to true.

This transition is followed without reading any input symbol. State transitions
with this property are called silent state transitions, discussed next.

Silent State Transitions

In the automata discussed so far, a state transition can only occur, if an input
symbol is read. On a more abstract level, this means that a state transition is
always associated with an interaction of a software system with its environment,
for instance, the insertion of a coin into a ticket vending machine.
However, there are situations in which a state transition should occur
without any interaction. We have encountered such a situation in the ticket
vending machine example in Fig. 3.3. There, we introduced a state transition
with the label reset to show that the automaton returns to its initial state and
is ready to serve new customers once the ticket has been supplied.
However, reset does not reflect any input by a customer, in contrast to all
other state transitions of the ticket vending machine. To reflect this automatic
transition of the system, a specific type of transition is used, a silent state
transition. A silent state transition is denoted by a specific input symbol τ ∈ Σ.
This represents a state transition that is not associated with any action of the
system to be modelled. Silent state transitions are also called τ -transitions.
We have used a silent state transition in the advanced ticket vending
machine shown in Fig. 3.8. The state Paying accepts inserted coins until the
customer has inserted sufficient funds. That is, if a ≥ p, no coins can be inserted
any more. Instead, the automaton proceeds to the state Returning change
without any interaction with the customer. This transition is achieved by a
τ -transition.
Silent state transitions can be associated with a condition, an output
sequence, and variable assignments. In the sample automaton, the τ -transition
from Paying to Returning change computes the amount of money to be re-
turned to the customer, r := a − p, if the condition a ≥ p evaluates to true.
The execution example in Table 3.5 shows that the ticket vending machine
has accepted an amount that is greater than the ticket price, namely a = 300
for a ticket price p = 260, as shown in the state marked Paying* . The silent
state transition computes the change to be returned and assigns it to the
variable r.
Iterating over state Returning change, the automaton returns change to
the customer. As long as the amount to return is larger than 50 cents the
automaton returns 50 cents coins, and only for small amounts does it return
10 cents coins.
This behaviour is also achieved by silent state transitions. All outgoing state
transitions of the state Returning change are qualified by mutually exclusive
conditions. That is, it is not possible that any two conditions evaluate to true
at the same time. Hence, it is clear which state transition is to be chosen,
based on the value of r.
60 3 Sequential Systems

The automaton iterates over the state Returning change until the change
has been returned and the condition r = 0 holds true. Then the automaton
outputs the ticket and terminates. All these state transitions are carried out
without customer interactions, because they are τ -transitions.

Non-deterministic Choices

Attention must be paid to conditions in extended automata, since it is possible

to specify several state transitions that are triggered by the same action, i.e.,
have the same input symbol. This is useful, for instance for producing different
outputs or assigning different values to variables based on conditions.
However, if two or more state transitions share the same input symbol and
these transitions are associated with conditions that are not mutually exclusive,
i.e., at least two conditions can be evaluated to true at the same time, then the
automaton cannot choose deterministically between the corresponding state
transitions. As a consequence, the automaton becomes non-deterministic.
For example, assume the alternative end of the extended automaton shown
in Fig. 3.9. We have changed the condition of the second state transition that
iterates over Returning change, which now reads 50 > r ≥ 0: a small detail
which has significant implications.

[r = 0] IJ
/ ticket Ticket
... Returning
change supplied

{ [ r •50] IJ / 50ct; r := r±50,

{ [50 > r•0] IJ / 10ct; r := r±10}

Fig. 3.9: A non-deterministic alternative for the extended automaton

If r = 0, both outgoing state transitions are enabled and the automaton

must decide whether to return another 10 cents coin – which would result in
returning too much money – or to supply the ticket. Since the two cannot
be differentiated by their input (both are τ -transitions), the choice cannot
be made deterministically. The automaton satisfies Definition 3.6 for non-
deterministic automata, in that two state transitions that share source state
and input symbol are enabled by their condition.
The same issue occurs if a state has more than one outgoing state transition
and at least one of them is silent. Imagine two state transitions (s, τ, s ) and
(s, l, s ). In the state s, the automaton must decide whether to wait for the
action l or whether to proceed using the τ -transition. Without mutually
exclusive conditions, this decision must be made non-deterministically. If the
conditions are mutually exclusive, however, the decision is still deterministic.
 3.3 Extended Automata 61

3.3.2 From Automata to Programs

Automata can be used to model the behaviour of sequential systems. By con-

centrating on states and state transitions as the main concepts, we can abstract
away details that are not required in the early phases of system development
projects. By introducing variables and conditions, we make automata richer
and more expressive. In this section, the step from extended automata to
computer programs will be discussed.
A computer program consists of a list of statements, which are processed
sequentially during program execution. At each point in time, an executing
program is in a specific state. In the field of computer architecture, this very
detailed state is represented by the instruction pointer. The current values of
all variables of the program belong to this state as well.
Modelling allows us to abstract away detailed states such as those of an
executing computer program. However, there are some very important states
(according to the modelling goal) in the program that can be represented
directly by states of an extended automaton that models the program. To
illustrate these concepts, we shall discuss a computer program for the ticket
vending machine shown in Fig. 3.8. The program, expressed in pseudocode, is
shown in Program 3.1.
The states of the automaton are shown by comments in the program code.
The statements of the program implement state transitions. This is to be
expected, because statements are executed one after another and change the
value of variables and, therefore, change the state of the system.
When the program is executed, the variables are first declared and assigned
their initial values, before the state Ticket selection is entered. The state
transition to the state Paying is associated with several statements, for reading
the selection of the ticket by the customer and determining the ticket price,
which is stored in the variable p.
After these statements have been executed, the program reaches the state
Paying. When the machine receives a coin as input, the value of the coin is
interpreted and the variable a is set accordingly. The self-loop that represents
the insertion of several coins by the customer is represented in the program by a
while statement. Coins are inserted until a sufficient amount is reached, i.e., a <
p does not evaluate to true any more. The state transition to Returning change
is completed by calculating the change r that needs to be returned. When the
change has been returned to the customer, the system supplies the ticket.
The role of silent transitions can be illustrated by this example as well.
Most state transitions of the automaton are associated with input, either the
selection of the ticket type or the insertion of a coin. However, the last three
state transitions are silent transitions, meaning that no action is associated with
these transitions. This property of the extended automaton is also reflected in
the program, which requires no input to proceed.
This is the case for the state transition that proceeds from the state Paying
to Returning change if a >= p. The same applies to the state transition that
62 3 Sequential Systems

// declaration of variables
int p :=0 ,
a :=0 ,
r :=0;

// state Ticket selection

input ( ticket );
switch ticket {
case A : p := 260;
case B : p := 290;
case C : p := 320;
}

// state Paying
while a < p {
input ( coin );
switch coin {
case 1 AC: a := a + 100;
case 5 ct : a := a + 50;
case 10 ct : a := a + 10;
}
}
r := a - p ;

// state Returning change

while r != 0 {
if r >= 50 {
r := r - 50;
output (50 ct );
} else if r >= 10 {
r := r - 10;
output (10 ct );
}
}
output ( ticket );

// state Ticket supplied

// automaton reaches the final state

Program 3.1: Ticket vending machine

 3.3 Extended Automata 63

iterates over the state Returning change, where the while loop starts and
continues to return change without any input while r > 0.
The reader might find it valuable to reflect on the model properties of
abstraction, mapping, and pragmatics of the extended automaton, the model,
and the original, i.e., the program.

3.3.3 Time in Automata

Finite automata abstract away time in such a way that only the causal order
of actions that can be carried out is captured in the model. However, cases
exist where the modelling goal requires a notion of time. For instance, a smoke
detector must raise an alarm if it detects smoke in its vicinity. However, to
avoid false alarms from cigarette-smoking passers-by, it might be required that
the alarm should be raised only if smoke has been detected continuously for
at least ten seconds. Such behaviour cannot be modelled with the automata
that we have studied so far.
However, variables and conditions equip us with the capability to capture
quantitative information about the passage of time in automata. Timed au-
tomata introduce local clocks – integer variables that serve as counters. As
time passes, these counters are increased by the environment of the system
and can be used to enable or disable state transitions according to timing
constraints.
We can make use of the modelling of time in the ticket vending machine.
A customer might select a ticket but then decide to leave without proceeding
with a purchase, following customers should be welcomed with the same initial
state as the first customer. Therefore, the machine should return to the initial
state after some time of inactivity.
To add this time-out behaviour to the automaton, we insert a new state
Ready to pay, shown in Fig. 3.10. Once the customer has selected a ticket, a
clock is started before this state is entered. The clock is represented by an
integer variable t, which is initialised in the state transitions leaving the state
Ticket selection by the assignment t := 0.

^WLFNHW$VHO$S W  ^>W”@FWD 

^WLFNHW%VHO%S W  ^>W”@FWD 
^WLFNHW&VHO&S W ` ^>W”@¼D `
7LFNHW 5HDG\WR 
3D\LQJ
VHOHFWLRQ SD\

WLPHULQWW 
>W!@IJ
LQWS  ^>DS@FWD D
LQWD  ^>DS@FWD D
LQWU  ^>DS@¼D D`

Fig. 3.10: A timed automaton that cancels inactive ticket purchases

64 3 Sequential Systems

Timed automata abstract real time away to the extent that state transitions
require no time and time passes only while an automaton is residing in a state.
Variables that serve as clocks need to be distinguished from regular variables.
This is done by the keyword timer in the declaration of the variable. When the
automaton enters the state Ready to pay, the clock t starts to tick, as defined
by the initialisation of the timer variable in the state transitions. We stipulate
that the clock value is incremented every second. Outgoing transitions of this
state can define constraints using the current clock value.
The automaton accepts coins that are inserted within the first 60 seconds
only, denoted by the condition t ≤ 60. If the customer inserts coins in time,
the automaton proceeds to the state Paying in the same manner as in Fig. 3.8,
but with initial funds, i.e., the value of the first coin inserted. For the sake of
simplicity, we have omitted the rest of the automaton from the diagram. If
the automaton remains in the state Ready to pay for more than one minute
without customer interaction, i.e., t > 60, it returns to the initial state.
An automaton can have multiple clocks, because time is discrete in the
system model, and the clock ticks need to be related to real time, for example
minutes or milliseconds. In the above example, one tick represents the passing
of one second.

3.4 State Machines

The extended automata discussed so far are the basis of an industry standard,
the state machines of the Unified Modeling Language (UML). In this section,
UML state machines are introduced. In particular, triggers and effects are
discussed, before more advanced concepts are introduced.

3.4.1 From Automata to UML State Machines

Even though the terms “finite automata” and “state machines” are often used
synonymously, we shall use mainly “state machine” from here onwards. Finite
automata with output and extended automata form the conceptual background
to behavioural modelling using UML state machines.
While state machines and extended automata share many concepts, for
instance states, state transitions, and variables, state machines use a different
notation. In state machines, states are represented by rectangles with rounded
corners.
However, there are also conceptual differences between extended automata
and state machines. We shall discuss these aspects using the state machine
shown in Fig. 3.11. This shows the same behaviour as the extended ticket
vending machine depicted in Fig. 3.8 as an extended automaton. Since the
labels of state transitions will not be discussed until later in this section, they
have been omitted from Fig. 3.11.
 3.4 State Machines 65

,QLWLDO 7LFNHW
VWDWH VXSSOLHG
7LFNHW 5HDG\WR 5HWXUQLQJ
3D\LQJ
VHOHFWLRQ SD\ FKDQJH

Fig. 3.11: A UML state machine of the ticket vending machine

In finite automata, the initial and final states are regular states, as defined in
Definition 3.3. As such, they can have incoming and outgoing state transitions
and can be traversed during the execution of an automaton.
In UML state machines, in contrast, the initial state is a so-called pseu-
dostate that represents an entry point of the automaton. It is shown as a filled
circle. It has no incoming arc and exactly one outgoing arc. The automaton
cannot remain in this state, as the only outgoing state transition from the
initial state represents the initialisation of the automaton. Therefore, this state
may only have an action assigned that initialises the system; otherwise, no
action is provided.
Final states denote the definitive termination of the automaton and, hence,
must not have any outgoing arcs. A final state is drawn as a filled circle with
a solid circle around it. Different outcomes of an automaton are modelled by
different final states.

Triggers

In finite automata, state transitions are triggered by actions, for instance the
selection of a particular ticket or the insertion of a coin into a ticket vending
machine. These actions are represented by the automaton’s input alphabet. In
order to extend the automaton with new actions or inputs, the input alphabet
needs to be modified. For instance, for each new coin or note that the ticket
vending machine is to accept, a new input symbol needs to be introduced.
The modelling goal of a ticket automaton may, however, focus not on the
actual coins and notes that will be accepted by the automaton but rather on
the amount of money. Hence, it is beneficial to abstract away the actual input
and use a more flexible approach to represent different inputs.
In state machines, this can be achieved by so-called triggers. Triggers cause
state transitions based on some action carried out, some input provided, or
some event that influences the system. Triggers may have parameters, which
can be used by variables in the state transitions.
The following example can be used to illustrate triggers in state machines.
The model of the ticket vending machine should abstract away the actual
coins to be inserted, and represent only the amount of money that has been
inserted so far. Therefore, a trigger insert(amount) is introduced, where insert
represents the action of inserting money into the ticket vending machine, and
amount is a parameter that carries the value of the inserted coin or note.
66 3 Sequential Systems

Parameters can be used in a condition of the same state transition. They

can also be assigned to a variable of the automaton. For instance, a state
transition

select(ticket, price) / s := ticket; p := price

represents the following actions:

• The customer selects a ticket, which has a certain price.
• The value of the parameter ticket is assigned to the variable s.
• The value of the parameter price is assigned to the variable p.
In this example, the method by which the ticket and price are determined
is abstracted away. A trigger with parameters reduces the number of state
transitions, since the different input symbols, namely ticket A, ticket B, and
ticket C are represented by the variable ticket.
Just as in extended automata, state machines allow us to define conditions
of state transitions. In the specification of UML state machines, these conditions
are called guards. The labelling of state transitions in state machines is slightly
different from that which we have used for extended automata: the trigger is
followed by a guard. For instance, a state transition labelled

insert(amount) [p > a] / a := a+amount

allows money to be inserted as long as the price p of a ticket is greater than

the amount a inserted so far.
Although the concrete syntax is different, conditions in extended automata
and guards in state machines share the same semantics. Guards are evaluated
when the corresponding trigger occurs, and the state transition can only be
carried out, if the guard evaluates to true.
The different order of trigger and guard compared with extended automata
is due to the introduction of trigger parameters. To incorporate parameter
values into guards, the guard must be evaluated after the trigger has been
executed. The ordering of trigger and guard conveys this by the reading
direction of left to right.
Additionally, UML state machines introduce two particular types of triggers
that we have previously modelled as conditions in extended automata.
In timed automata, the expiration of a clock is modelled as a condition
which states that the value of a clock variable exceeds a particular value;
for instance, the state transition label [t ≥ 60] indicates that after the clock
variable has reached a value of 60, the state transition is triggered.
In state machines, clocks are made more explicit by introducing time
triggers, indicated by the keyword after. A transition in a state machine
labelled with the trigger “after 60s” denotes that the state is left via that
state transition 60s after it has been entered. This makes the declaration and
initialisation of clock variables unnecessary.
 3.4 State Machines 67

State machines also offer the keyword at to denote that a state transition
is triggered at a certain point in time; for example, “at December 31, 23:59:59”
models the transition to a new year.
In a similar fashion, state machines introduce variable triggers by the
keyword when. A variable trigger is executed when the corresponding variable
is assigned a particular value. For instance, “when a = 5” denotes that a state
transition is triggered when the variable a is assigned the value 5.

7LFNHWVHOHFWLRQ ,GOH
HQWU\GLVSOD\ PHQX  HQWU\GLVSOD\ FRPPHUFLDO
DIWHUV

VHOHFW WLFNHWSULFH 
FDQFHO GLVSOD\ WLFNHW 
S SULFHV WLFNHW

DIWHUV
5HDG\WRSD\
HQWU\GLVSOD\ SD\S 

LQVHUW DPRXQW
D DPRXQW
FDQFHO
UHWXUQ D

3D\LQJ LQVHUW DPRXQW >S!D@

HQWU\GLVSOD\ SD\ SD D DDPRXQW

FRQILUP>D•S@
SULQW7LFNHW V 
UHWXUQ DS

DIWHUV
7LFNHWVXSSOLHG
^$%&`V QXOO
HQWU\GLVSOD\ ³FKDQJH´
LQWS 
DS 
LQWD 

Fig. 3.12: Ticket vending machine modelled as a UML state machine

So far, extended automata and state machines are to a large extent equiva-
lent. Figure 3.12 shows the extended automaton of Fig. 3.8 as a state machine.
Here, we observe the same states Ticket selection, Ready to pay, Paying, and
Ticket supplied and also state transitions that use triggers, guards, and assign-
ments.
68 3 Sequential Systems

Effects

State transitions also have output that uses parameters. For example, the
following output is associated with the transition that leads to the state Ticket
supplied in Fig. 3.12:

confirm [a ≥ p] / printTickets(s); return(a − p),

specifying that on confirming the purchase and if the amount is greater or

equal to the ticket price, the ticket is printed and the change is given.
UML state machines unify variable assignments and outputs into a common
concept called an effect. An effect is a specification of a behaviour that comprises
a sequence of operations, such as the assignment of variables or the invocation
of functions.
The return of change by the state machine can be represented by a func-
tion return(amount), where amount carries the funds to be returned. This
technique complies with the above modelling goal and is in line with the
abstraction that we have chosen to model inserted coins.
Effects can be added to both states and state transitions of a state machine,
which allows one to combine the Mealy and Moore styles of modelling the
output of finite automata, as shown in Fig. 3.12. Effects that are added to
states can be triggered when the state is entered or when it is left. In state
machines, this is visualised by an additional compartment at the top of the
rectangle that represents the state. Keywords denote when an effect is triggered:
entry denotes that the effect is to be triggered when the state is entered, and
exit denotes triggering upon leaving the state, i.e., before proceeding to an
outgoing state transition.
A sequence of effects can be separated by semicolons. For example, in
Fig. 3.12 every state prints a message on the screen of the ticket vending
machine. This might also be followed by a variable assignment.
Effects added to state transitions replace the output and variable assign-
ments of extended automata. UML specifies the following labelling scheme,
which we have already seen in the examples above:
triggers [ guard ] / effects
triggers is a comma-separated list of triggers, which allows a number of
alternative triggers of a state transition to be grouped together. Each
trigger can provide a set of parameters, which is enclosed in parentheses.
guard is a Boolean expression that is evaluated after a trigger has been
executed and therefore can refer to parameters of the trigger. The state
transition can only be carried out if the guard evaluates to true.
effects is a semicolon-separated list of effects, including variable assignments
and operations.

Effects added to state transitions are useful for storing trigger parameters
in variables, since these parameters are available only in the scope of the state
 3.4 State Machines 69

transition. In the state machine shown in Fig. 3.12, this method is used to
store the chosen ticket selection and ticket price, as well as the amount of
money inserted.
Clocks were introduced for extended automata as variables that are incre-
mented while the automaton remains in a state. In state machines, time can
be employed in a similar fashion.
Figure 3.12 shows an additional feature of the ticket vending machine that
leverages clocks. If the machine is in the state Ticket selection for more than
one minute, it proceeds to the state Idle and starts showing commercials on the
screen. A time trigger using the keyword after is used for this state transition.
The state Idle is left if any interaction happens, i.e., if the customer
presses any button, denoted by the label “∗”. The same happens if there is no
interaction for five minutes in the state Ready to pay. From the diagram, one
can observe that a timer can be used in different states.

3.4.2 Hierarchy of States

So far, this chapter has shown that the behaviour of sequential systems can be
modelled by automata or, in the context of UML, state machines. Examples
have been used to illustrate the concepts of this modelling and their application.
To ease comprehension, these examples have been of limited complexity. In
real-world application scenarios, however, not only simple but also complex
systems have to be represented in behavioural models.
The automata introduced so far can also be used to represent complex
behaviour. The resulting models, however, would also become complex, so that
communication and agreement about the behaviour represented would become
very difficult.
To deal with complexity in automata, we can abstract from behaviour
away and represent such behaviour by specific states. A single state may
then represent behaviour captured by a subautomaton. Since a state in a
subautomaton can represent a further subautomaton, these automata are
organised hierarchically. States that are described by a subautomaton are
called composite states. Composite states are addressed in the next section.
To illustrate the concept of hierarchical state machines, we consider the
ticket vending machine example again. Figure 3.13 focuses on one part of the
state machine that was introduced in Fig. 3.12. In that automaton, the steps
involved in selecting a ticket are modelled by a single state, Ticket selection.
The output of selecting a ticket is represented by the state transition labelled
select(ticket, price), plus a timing constraint. This means that the individual
steps involving the selection of a ticket are abstracted away.
In practice, however, the selection of a ticket involves a number of steps,
such as choosing a ticket fare, choosing a period for which the ticket will be
valid, and finally confirming the purchase. In each of these steps, it should
be possible to return to a previous step to make changes. If our goal is to
70 3 Sequential Systems

,GOH dŝĐŬĞƚƐĞůĞĐƚŝŽŶ
HQWU\GLVSOD\ FRPPHUFLDO

DIWHUV

VHOHFW WLFNHWSULFH FDQFHO

DIWHUV 5HDG\WRSD\
HQWU\GLVSOD\ SD\S 
VWULQJV 
LQWS 
LQWD 


Fig. 3.13: The composite state Ticket selection in a collapsed representation,

hiding the internal behaviour of the state Ticket selection

develop a software system that implements a ticket vending machine, we need

to represent this behaviour as well.
Assume that we intend to represent the detailed behaviour of the system in
the state Ticket selection. Basically, there are two ways of achieving this goal.
Enrichment The state machine is enriched with detailed information regard-
ing the internal behaviour of the state Ticket selection. From a modelling
perspective, two issues emerge. First, states of different importance and
of different granularity are represented side by side in one state machine.
Second, the state machine becomes complex, so that comprehension will
suffer.
Refinement The behaviour of the system within the state Ticket selection
is represented in a separate state machine. The state Ticket selection is
marked accordingly, to show that the detailed behaviour of the system in
that state is modelled in a separate state machine. This alternative keeps
the models simple and eases understanding. Furthermore, the states in
one state machine are on the same level of abstraction.
Based on the refinement option, the state machine depicted in Fig. 3.13 consists
of states which are on the same level of abstraction. The state Ticket selection
is refined by another state machine that represents the behaviour inside the
state Ticket selection. The nesting is represented by a decomposition icon in
the lower right corner of the box representing the composite state. The icon
indicates two states connected by a state transition.
The internal behaviour of the system in the state Ticket selection is rep-
resented by the state machine shown in Fig. 3.14. Since this state machine
details the behaviour of the system in one state, it is called a submachine or
subautomaton.
 3.4 State Machines 71

7LFNHWVHOHFWLRQ
 

VHOHFW VHOHFW
IDUH SHULRG
)DUH 3HULRG &RQILU FRQILUP
VHOHFWLRQ VHOHFWLRQ PDWLRQ
EDFN EDFN

Fig. 3.14: Subautomaton of ticket selection state

When a state is refined with a subautomaton, the execution time spent in

the state is partitioned into the states of the subautomaton. To illustrate this
observation, we consider the state Ticket selection of the original state machine.
The system resides in this state until the selection is completed. However,
when we consider the detailed behaviour captured in the subautomaton, the
time spent is partitioned into the states Fare selection, Period selection, and
Confirmation, as shown in Fig. 3.14.
When Ticket selection is entered through any of its incoming state transi-
tions, the internal state machine is initialised. If the automaton remains in the
state Ticket selection for more than one minute without any internal action,
the time trigger after 60s is fired and the automaton proceeds to the state
Idle.
In the introductory chapter, we identified mapping, abstraction, and prag-
matics as important properties of models. If a behavioural model contains
details that are not required for a particular modelling goal, the pragmatics of
the model is impaired. This is due to the fact that the details in the model
make it hard for people to comprehend, discuss, and analyse the behaviour of
the model. In such cases, we should abstract these details away.
Refinement and abstraction require the notion of a hierarchy, where the
internal behaviour of a state is determined by an automaton of its own. The
internal behaviour can be hidden in the model and captured in a second model,
referred to in the first model. It can also be shown in a composite state, as
will be discussed below. Hierarchical automata offer a number of benefits.
• Depending on the level of detail required in a model, the behaviour of a
system in a certain state can be hidden. The hierarchical structure allows
us to reveal this detailed behaviour if required. Different levels of detail
can therefore be captured in hierarchical automata.
• Not only states but also state transitions can be grouped together, which
reduces the complexity of the state machine diagram and makes it more
comprehensible.
• Entry effects can be specified for composite states that are executed when-
ever an internal state is entered from a state outside the composite state.
The same applies to exit effects. Hence, these effects can be used to ensure
72 3 Sequential Systems

that internal states and state transitions occur only in a certain context,
for instance when variables are assigned or timers are started.

3.4.3 Composite States

The existence of state machines with hierarchical states shows that states can
reference other state machines that describe their internal behaviour. States
with this property, i.e., states that contain internal logic, are called composite
states. A state machine that captures the internal behaviour of a composite
state is called the submachine of that state.
It is possible to nest composite states in other composite states which then
yields a hierarchy of states. At the lowest level of this hierarchy there are states
that are not composite. Every state, composite or not, can have no more than
one direct parent.
Each submachine must have an initial state, which is triggered when the
composite state is entered. Hierarchical state machines can also use pseu-
dostates for initial states, as discussed earlier in this section. A state machine
cannot reside in a pseudostate and, therefore, the outgoing transition of the
initial state is triggered immediately. The submachine is then in the state that
is the target state of the initial state transition. If this state is a composite
state, then again the initial state of its submachine is triggered, and so on.
As a consequence, if an automaton is in a composite state, it is always
in a substate of that composite state as well. Hence, at any point in time,
exactly one non-composite state of an automaton is active, whereas a number
of composite states – the direct and indirect parent states of the non-composite
state – are active as well.
Figure 3.13 showed the collapsed form of the composite state Ticket selec-
tion. In Fig. 3.15 we show its submachine. Visually, submachines are nested
in an expanded composite state. When the composite state Ticket selection
is entered, the initial state transition of its submachine is triggered and the
state Fare selection is entered. In that state, the customer is presented with
different fares, A, B, or C , to choose from.
Upon a choice of, for instance, ticket A, the price for the chosen fare is set,
p := 260 cent, and the submachine proceeds to the next state, Period selection.
It is possible to return to a previous state, denoted by the state transitions
labelled back. Eventually, the customer will confirm the ticket selection, which
terminates the submachine and leads to leaving the composite state.
Hierarchical automata allow not only grouping but also state transitions
to be grouped. If all states of a submachine have an outgoing state transition
with the same label, then these state transitions can be grouped into a single
state transition with the composite state as its source.
In Fig. 3.15, the composite state Ticket selection is the source state of
the state transition labelled cancel and therefore the state transition can be
triggered from every state of the submachine. If, for instance, the submachine
is in the state Period selection and the customer chooses to cancel the ticket
 3.4 State Machines 73

7LFNHWVHOHFWLRQ

)DUHVHOHFWLRQ
HQWU\GLVSOD\ IDUH^$%&`

WLFNHW$S V $

FDQFHO EDFN WLFNHW%S V %
WLFNHW&S V &

3HULRGVHOHFWLRQ
HQWU\GLVSOD\ YDOLGSHULRG
HQWU\GLVSOD\ ^VLQJOHGD\PRQWK`

VLQJOHV VVLQJOH
EDFN ZHHNS SāāV VZHHN
PRQWKS SāāV VPRQWK

&RQILUPDWLRQ
HQWU\GLVSOD\ WLFNHWV
HQWU\GLVSOD\SULFHS

FRQILUP
VWULQJV 
LQWS 
LQWD 

Fig. 3.15: Composite state with state machine contained in it

selection, then the submachine is terminated without proceeding to any sub-

sequent state. The composite state Ticket selection is left, proceeding to the
target state of the cancel state transition.
Since Ticket selection is the target state, it is revisited. Its initial state is
entered and the submachine is reinitialised, starting the ticket selection process
all over again.
With the basic understanding of hierarchical automata that we now have,
we shall now discuss more elaborate features of state machines, i.e., transitions
that enter and leave composite states. State transitions can also cross the
boundaries of a composite state. That is, a state transition can connect a state
inside a composite state with a state outside that composite state.
If a state transition leads to a substate of a composite state from a state
outside that composite state, then the initial state of the submachine is
bypassed and the submachine starts at the target state of the state transition.
To illustrate this aspect of composite states, consider Fig. 3.16, which
depicts an extension of the ticket vending machine introduced above. We have
added a new state Start that greets the customer with a welcome message and
offers quick access to tickets that are valid for a single journey, for each of the
fares A, B, and C . For each of these choices, we have added a state transition
74 3 Sequential Systems

6WDUW
HQWU\GLVSOD\ ZHOFRPH

WLFNHW$ FDQFHO WLFNHWPHQX

S V $VLQJOH
7LFNHWVHOHFWLRQ
WLFNHW%
S V %VLQJOH
WLFNHW&
S V &VLQJOH )DUHVHOHFWLRQ
HQWU\GLVSOD\ IDUH^$%&`

WLFNHW$S V $

EDFN WLFNHW%S V %
WLFNHW&S V &

3HULRGVHOHFWLRQ
HQWU\GLVSOD\ YDOLGSHULRG
HQWU\GLVSOD\ ^VLQJOHGD\PRQWK`

VLQJOHV VVLQJOH
EDFN ZHHNS SāāV VZHHN
PRQWKS SāāV VPRQWK

&RQILUPDWLRQ
HQWU\GLVSOD\ WLFNHWV
HQWU\GLVSOD\SULFHS
FRQILUP

VWULQJV 
LQWS 
LQWD  ͘͘͘

Fig. 3.16: Transitions can cross boundaries of composite states

that leads the customer directly to the state Confirmation, represented by a

single arc in the diagram.
This means that the parts of the submachine that are not relevant to the
specific behaviour intended are bypassed. In this example, selection of the fare
and the period of validity are not relevant, since the customer has already
selected these ticket properties in the starting state.
If, for example, the customer chooses ticket A, the composite state Ticket
selection is entered. This state has no entry effect. Then Confirmation is
entered and its entry effect is carried out, which shows the customer the ticket
selected. The customer can now confirm the selection or return and change
the period or fare.
If a composite state has an unlabelled outgoing state transition edge, this
edge is triggered immediately when the internal state machine has terminated.
In the example in Fig. 3.16, choosing confirm in the state Confirmation leads
to the final state of the state machine and, thus, to its termination. In each
 3.4 State Machines 75

state of the submachine, the user can cancel the interaction. This behaviour is
represented by the state transition from the state Ticket selection to the state
Start.
If a state transition leads from a state inside a submachine to a state
outside that submachine, the composite state can be left without reaching its
final state. This is different from a state transition that has the composite
state as its source state, where the state transition can be triggered from any
state inside the composite state.
This example shows that state transitions that lead to composite states
may cause inconsistencies in the submachine’s variables. For instance, if the
price had not been set as part of the effect of the state transition from Start to
Confirmation, it could not have been used in the state Confirmation. Modellers
need to be aware of this aspect of composite state transitions.
As mentioned above, effects of the entering and leaving of states can also
be specified for composite states. When a composite state is entered, the entry
effect is triggered before the submachine is initialised. When a composite state
is left, the exit effect is triggered after the termination of the submachine, i.e.,
after final state has been reached.
The entry and exit effects of a composite state are always executed when
the composite state is entered or exited, no matter whether the state transition
that causes the entry or exit crosses the boundaries of the composite effect or
is attached to the composite state itself.
Exit effects are executed from the innermost state, i.e., the non-composite
state, outwards to the parent states. Entry effects are executed in the reverse
direction, starting from the outermost composite state that is entered. As the
submachine of a composite state is initialised on entry, effects attached to the
initial state transition are executed as well.

6 6
H[LWH[ HQWU\HQ

LQ
7WUDQV
6 6
H[LWH[ HQWU\HQ

Fig. 3.17: Order of effects for state transitions in composite states

These considerations lead to a well-defined ordering of effects if the states

of a submachine have entry and exit effects and if effects are added to state
transitions. We can explain this with the abstract example shown in Fig. 3.17.
Assume that the state machine is in the state S1.1 . Since the state transition
with the trigger T starts from the composite state S1 , it can be triggered
from S1.1 . State transitions of composite states are inherited by all direct and
indirect successor states of the hierarchy.
76 3 Sequential Systems

If T is triggered, S1.1 is left, executing its exit effect ex 1.1 , followed by the
exit effect of its direct parent state S1 , i.e, ex 1 . Next, the effect of the state
transition trans is executed. Upon entering S2 , first the entry effect of the
composite state en 2 is executed. Then the submachine of the composite state is
initialised. Since the initial state is a pseudostate, its outgoing state transition
is triggered immediately, and the effect in 2 is executed. The submachine enters
state S2.1 , and its entry effect en 2.1 is executed.
In conclusion, triggering of T leads to a state transition from S1.1 to S2.1 ,
causing the following sequence of effects to be carried out:

ex 1.1 , ex 1 , trans, en 2 , in 2 , en 2.1 .

3.4.4 History States

We have used Fig. 3.16 to discuss two ways of entering a submachine. On

the one hand, if the composite state is the target of a state transition, the
submachine is initialised upon triggering of the state transition. In the example,
this is achieved by the transition from the state Start to the composite state
Ticket selection.
On the other hand, a state transition can be connected to a target state
that lies within a composite state, which bypasses the initial state and starts
the submachine directly in the target state. This happens if the customer
chooses a single ticket directly in the state Start, which triggers a transition
to the state Confirmation, which is a substate of the composite state Ticket
selection.
In addition to these variants of entry into a composite state, there is an
additional variant, regarding the re-entering of a composite state. We shall now
introduce this concept with an example involving the ticket vending machine.
In the design of the system, we want to allow the customer to select the date
of the trip at any time during ticket configuration.
We can achieve this behaviour by adding a substate Date selection to the
state Ticket selection, as shown in Fig. 3.18. Since the date can be selected
at any time, we would need several substates involving date selection. We
could model the state Date selection outside the state Ticket configuration,
so that this state transition becomes possible from every substate of Ticket
configuration. However, how can we make sure that we will reach the correct
substate when re-entering Ticket configuration? If, for instance, we choose to
select the date from the state Period selection we have to return to the state
Period selection after selecting the date. This applies analogously for the other
substates of the composite state.
UML state machines provide us with a way of representing this behaviour,
using a so-called history state. A history state is depicted by a circle enclosing
the letter “H”. It is a pseudostate similar to the initial state, as it is an entry
point rather than a state in which an automaton can reside.
 3.4 State Machines 77

7LFNHWVHOHFWLRQ

VHOHFW WUDYHOGDWH
GDWH WUDYHOGDWH

6WDUW
'DWHVHOHFWLRQ
HQWU\GLVSOD\ ZHOFRPH 
GDWH WRGD\ HQWU\GLVSOD\ GDWH

FRQILUP VHOHFW
WLFNHW$ FDQFHO WLFNHWPHQX
GDWH
S V $VLQJOH
7LFNHWFRQILJXUDWLRQ
WLFNHW%
S V %VLQJOH
+
WLFNHW&
S V &VLQJOH
)DUHVHOHFWLRQ
HQWU\GLVSOD\ IDUH^$%&`

WLFNHW$S V $

EDFN WLFNHW%S V %
WLFNHW&S V &

3HULRGVHOHFWLRQ
HQWU\GLVSOD\ YDOLGSHULRG
HQWU\GLVSOD\ ^VLQJOHGD\PRQWK`

VLQJOHV VVLQJOH
EDFN ZHHNS SāāV VZHHN
PRQWKS SāāV VPRQWK

&RQILUPDWLRQ
HQWU\GLVSOD\ WLFNHWV
HQWU\GLVSOD\SULFHS
HQWU\GLVSOD\YDOLGIURPGDWH
FRQILUP

DIWHUV
VWULQJV 
͘͘͘
,GOH LQWS 
LQWD 
HQWU\GLVSOD\ FRPPHUFLDO GDWHGDWH QXOO

Fig. 3.18: The history state allows returning to the last visited state in a
submachine
78 3 Sequential Systems

The use of the history state is illustrated here with the example shown in
Fig. 3.18. At any point during the ticket selection process, the customer can
choose a travel date, starting from which the selected ticket will be valid.
The state Date selection can be accessed from any substate of the composite
state Ticket configuration via the state transition labelled select date. The
state Date selection shows the current travel date and allows it to be changed;
this can be done repeatedly if required. Upon triggering of confirm, the
corresponding state transition leads to a history state within the composite
state Ticket configuration. The history state then activates the state in which
the submachine resided when it was left for date selection.
If, for instance, the submachine was in the state Period selection when the
customer chose to change the travel date, the submachine will be entered in
the same state, using the history state. The entry effect of Period selection is
carried out.
In Fig. 3.18, we have added a state Idle of the kind that we introduced
earlier along with the state transition for the time trigger. Hence, the state
Ticket selection is now complete and shows the expanded form of the composite
state depicted in Fig. 3.13. The design of our ticket vending machine is thus
concluded.

Bibliographical Notes
In this chapter, automata were introduced as a conceptual basis for modelling
discrete dynamic systems that also offers an intuitive notation for capturing
them graphically. Automata go back to Huffman (1954), Mealy (1955), and
Moore (1956), who envisioned ways to describe sequential switching circuits.
Imagine an electrical relay board that has input switches that can be in the
position on or off, and an output of lights that can also be on or off. Switching
circuits can be used to represent a theory of combinatorial logic, where the
output (lights) is a function of the input (switches). Sequential switching
circuits are an extension, in that they allow “remembering” of the state of
previous inputs. Consequently, the output is a function of the current input
and the previous states. This can be projected onto automata, where the
output depends on the current state and the input that led to that state.
Non-deterministic finite automata were first studied by Rabin and Scott
(1959). These authors argue that the benefit of non-deterministic automata lies
in the small number of internal states and the “ease in which specific machines
can be described”. Rabin and Scott also showed that every non-deterministic
automaton can be replaced with a behaviourally equivalent deterministic
automaton. In the worst case, the latter has 2|S| states, where S is the set of
states in the non-deterministic automaton.
Automata generally capture only the ordering of actions, and not the real-
time behaviour of discrete dynamic systems. To overcome this limitation, Alur
 3.4 State Machines 79

and Dill (1994) proposed a simple, powerful addition to extended automata

that consisted of logical clocks and timed constraints on state transitions.
Hopcroft et al. (2003) wrote an excellent textbook about the theory of
automata that goes beyond what we have presented in this chapter. These
authors studied the capability of automata to recognise patterns in strings of
symbols. Applied to programming languages, automata form a foundation of
compiler construction.
State machines have their origin in statecharts, which were proposed by
Harel (1987), where hierarchical states were also introduced. This notation
has been incorporated into the UML. The UML is maintained by the Object
Management Group (2015). A textbook by Booch et al. (2005) provides an
overview of the different model types in the UML, covering both structural
and behavioural models.
4
Concurrent Systems

This chapter looks at concurrent systems. It does so by extending state

machines with means to express concurrent behaviour. Mechanisms to express
interacting systems are introduced with communication diagrams and sequence
diagrams. The chapter closes with a discussion of Petri nets, which allow us to
express concurrent behaviour elegantly; Petri nets will also be instrumental in
the analysis of system behaviour, which is covered in Part III.
To investigate concurrent systems, we first discuss the specific properties of
sequential systems and use these properties to distinguish concurrent systems
from sequential ones.
All of the system models that we have discussed so far have captured
sequential behaviour. As was discussed in Section 2.3, the key to behavioural
modelling is representing causality. An event b is causally dependent on an
event a if b can only happen after a has happened.
To capture the behaviour of a ticket vending machine, we introduced finite
automata. Returning to the example shown in Fig. 3.2, we can buy a ticket by
first selecting a fare followed by inserting a 1 AC coin and a 50 cents coin into
the vending machine. If we consider the ticket selection and the insertion of
a coin as events, it turns out that these events are causally related: we can
insert a coin only after we have selected a ticket.
This observation can be generalised to all events that occur during an
interaction with an automaton: all events that actually occur are causally
related. This means that for each pair of events a and b that happen, there is
a path in the automaton involving those events. This path can be oriented in
either direction, and a and b can also be part of a loop. In any case, a and b
are causally related.
Sequential behaviour is illustrated by the finite automaton shown in Fig. 4.1.
The automaton contains state transitions labelled a, b, c, d, and e, so that
events a to e can occur. These events cannot happen in an arbitrary order,
since the automaton defines a causal relationship between them.
When the automaton is in the start state s1 , only event a can happen; in
state s2 , however, event b or c can happen. This means that b can only happen

© Springer International Publishing Switzerland 2016 81

M. Kunze and M. Weske, Behavioural Models,
DOI 10.1007/978-3-319-44960-9_4
82 4 Concurrent Systems


 

   

Fig. 4.1: Finite automaton captures sequential behaviour: all events are causally
related

once a has happened: b is causally dependent on a. The same holds for event
c, which can only happen after a has happened.
The characterisation of sequential behaviour relates only events that actu-
ally occur in a particular execution sequence. It does not relate events at the
level of the model. For instance, there is no path involving b and d in the finite
automaton. But then, b and d cannot happen in sequence in any execution.
A causal dependency between events a and b does not mean that b must
happen after a has happened. The example has shown that c can happen after
a, bringing the automaton to the state s3 . Instead, it means that b can only
happen after a has happened.
In a sequential system every event that occurs is causally dependent
on the event that occurs previously.
In the sample finite automaton shown in Fig. 4.1, the following complete
execution sequences can occur: a, c, d, e , a, b, e . In either case, every event
that occurs is causally dependent on the event that has just occurred: in the
first execution sequence, e depends on d, d depends on c, and c depends on a.
In the second execution sequence, e depends on b, which depends on a.
Systems with this property are called sequential systems, because the events
can occur only in a sequence that is defined by the model, for instance, by a
finite automaton. We now turn our attention to concurrent systems, where the
constraint of causal dependencies between events in sequential systems does
not apply any more.
In a concurrent system, events that occur do not need to be causally
dependent on events that have previously occurred.

This means that in a concurrent system, not all events are causally related;
several events can occur independently of each other. A typical concurrent
system consists of several subsystems, which can – for some time – proceed
independently of each other.
A purchasing scenario will serve as an example of a concurrent system. A
customer wants to purchase a laptop computer and sends a request for quote to
three sellers. The customer can now proceed by allocating a budget, planning
which software tools to install on the laptop, and so on. When a seller receives
a message requesting a quote, the seller decides whether to prepare and send
 4.1 State Machines 83

a quote message to the customer. Assuming all sellers submit a quote, the
customer receives three quotes, selects one, and sends an order to one selected
seller.
This example of a typical interaction between business processes describes
a concurrent system. The system consists of four subsystems, the customer and
three sellers. Each seller’s activities to prepare a quote are causally independent
from the activities performed by the other sellers and by the customer. We will
return to similar examples when we discuss concurrency in business process
models later in this chapter.
The remainder of this chapter is organised as follows. Section 4.1 investigates
the ability of state machines to represent concurrent behaviour. Interactions
among subsystems of a concurrent system are discussed in Section 4.2. Petri
nets are the centre of attention in Section 4.3.

4.1 State Machines

We have already investigated the basic modelling constructs of UML state
machines. In this section, we will discuss how state machines can be used to
express concurrent behaviour.
When software systems are being designed, complexity needs to be managed.
These systems consists of many parts, some of which depend on each other,
while others are independent of each other. Decomposing a software system
into several subsystems helps in managing this complexity.

4.1.1 Decomposition of Behaviour

To discuss the design of subsystems in the context of concurrent systems,

we introduce a variant of a vending machine, which sells lemon soda and
orange soda, each at a price of 2 A
C. Since the choice of the product does not
determine the price, there is no causal dependency between choosing a drink
and paying for it. This means that the user can start paying before, during, or
after choosing the beverage. However, there is a causal dependency between
paying and getting the drink, which will be discussed below.
To model the behaviour of the vending machine, we modularise the vending
machine’s behaviour into two sequential subsystems. One of these is responsible
for selecting and providing the beverage, and the other for receiving the
payment. When the system starts, each subsystem starts in a well-defined
state. Figure 4.2 shows two automata, one for each subsystem of the vending
machine.
The behaviour for selection of a beverage is depicted in Fig. 4.2a. The
automaton starts in an initial state that offers a choice between orange soda
and lemon soda. Depending on the input the automaton advances to the
next state, which represents the selected beverage. When the confirm event is
84 4 Concurrent Systems

FRQILUP
2UDQJH RUDQJHVRGD 2UDQJH
VHOHFWHG VXSSOLHG
RUDQJH

'ULQN
VHOHFWLRQ
FRQILUP
OHPRQ /HPRQ OHPRQVRGD /HPRQ
VHOHFWHG VXSSOLHG

(a) Automaton A1 for drink selection

¼ ¼

FW FW FW FW FRQILUP 3XUFKDVH

¼SDLG ¼SDLG ¼SDLG ¼SDLG ¼SDLG
FRPSOHWH

¼

¼
(b) Automaton A2 for payment

Fig. 4.2: Specification of subsystems for soft drink vending machine

received by the automaton, the selected soda is supplied and the final state of
the automaton is reached.
The second automaton, shown in Fig. 4.2b, models the payment process.
A number of coins are inserted until the amount of 2 A C is paid. Notice that
overpaying is not possible in this automata, since, for instance, in the state
1AC paid, the automaton does not accept a 2 A C coin. The state transition
confirm leads to the completion of the purchase.
The behaviour of the vending machine is defined by the composition of
the two automata. When the system starts, both automata are in their initial
states. Each subsystem progresses independently in a way that depends on the
input. At any point in time, one state transition of either automaton can take
place. Since the two automata can proceed independently of each other, they
are concurrent. For instance, selecting orange may take place before, after, or
at the same time as a 1 A C coin is inserted.
Earlier in this section we characterised sequential execution by stating
that consecutive events are always causally related. However, if we investigate
the drink vending machine, there are events that occur consecutively but are
not causally related. This applies, for instance, to the events orange, and 2 A
C.
Therefore, the drink vending machine is a concurrent system.
The behaviour of the system will now be discussed in more detail, using a
formal representation of the states of the system which is a combination of
the states of each of its subsystems. Formally, we can capture the state of a
composite system as follows.
 4.1 State Machines 85

Let C(A1 , A2 , . . . , An ) = (S, Σ, δ, s0 , F ) be a composite automaton that

consists of automata A1 , . . . , An , with Ai = (Si , Σi , δi , s0i , Fi ). Then, the
states of C are the Cartesian product of the states of the automata, i.e.,
S = S 1 × · · · × Sn .
Let A1 be the automaton for drink selection and A2 that for payment.
When a purchase starts, the composite system is in the state

(Drink selection, 0 A
C paid) ∈ S1 × S2 .

In this state, the system offers several state transitions based on the inputs to
the automata. For instance, selecting lemon in the drink selection automaton
leads to the composite state

C paid) ∈ S1 × S2 ,
(Lemon selected, 0 A

whereas inserting a 2 A
C coin into the payment automaton in the start state
leads to
C paid) ∈ S1 × S2 .
(Drink selection, 2 A
However, a confirm input in the state (Lemon selected, 0 A
C paid) results in the
state
(Lemon supplied, 0 AC paid) ∈ S1 × S2 ,
because A2 does not accept the event confirm in the state 0 A C paid, whereas
A1 does so in the state Lemon selected. In this state, the composite automaton
has provided the beverage without payment, which is an undesired behaviour.
This example shows two facets of behavioural modelling. On the one hand
it is beneficial to modularise the definition of behaviour into independent
subsystems, because less complex models suffice to specify the behaviour.
On the other hand, the subsystems of a given system always have some
dependencies, otherwise they would not be part of one system. In the above
example, the machine should provide the beverage only after the payment has
been received.
The required synchronisation of state transitions in distinct subsystems is
taken into account in UML state machines by orthogonal states.

4.1.2 Orthogonal States

In the example of the soft drink vending machine, we observed that concurrent
behaviour can be captured by several automata that together describe the
behaviour of a system. This section introduces state machines with orthogonal
states, which allow us to represent concurrent behaviour in one automaton,
rather than in several automata as presented. The idea is very similar to that
discussed above: a state machine can be in several states at the same time.
These states are called orthogonal states.
Orthogonal states are an extension of the composite states of UML state
machines that were discussed in subsection 3.4.3. In contrast to composite
86 4 Concurrent Systems

states, an orthogonal state does not have only one submachine, but at least
two submachines. Each submachine is contained in its own region and all
submachines of an orthogonal state are active concurrently.

2UWKRJRQDO6WDWH

5HJLRQ$
6$ 6$
6

5HJLRQ%
6% 6%

Fig. 4.3: An orthogonal state that contains two concurrent submachines

The orthogonal state shown in Fig. 4.3 contains two submachines, each of
which is contained in one region; these regions are Region A and Region B,
respectively. For the sake of simplicity, we have omitted the labels of state
transitions. Regions can be horizontally or vertically aligned, and are named
by a label in the respective region. To avoid confusing the name of a region and
the name of the orthogonal state, the latter is put into a rectangle attached to
the orthogonal state, as shown at the top of Fig. 4.3.
The execution semantics of the orthogonal states and their submachines
in this example can be described as follows. Once the orthogonal state has
been entered through the state transition from S1 , each submachine triggers
its initial pseudostate, entering the state (SA.1 , SB.1 ). Then, each submachine
progresses normally and independently of the other submachine, in a way that
depends on the input to the system.
The orthogonal state can be exited in two ways, similarly to a composite
state. If the orthogonal state has an unlabelled outgoing state transition, that
transition is triggered once all submachines have terminated by reaching their
respective final states. Orthogonal states may also possess labelled outgoing
state transitions. If such a state transition is triggered, each submachine is
exited immediately, independent of the state it is currently in.
In contrast to composite states, orthogonal states have no entry or exit
effects. However, orthogonal states and composite states can be nested, and
states of submachines can have effects. Then, the ordering of entry and exit
effects applies, as discussed for composite states in Section 3.4.3.
So far, we have covered the basics of concurrency in state machines. That is,
two or more submachines progress independently of one another. In most cases,
however, the individual parts of one system are not completely independent of
one another, as we have already seen in the example of the soft drink vending
machine.
 4.1 State Machines 87

The submachines of orthogonal states can use shared variables to represent

dependencies among their state transitions. To elaborate further on this aspect,
an example of a home automation system will now be introduced, which
consists of several subsystems. In the course of this section, this system will be
extended with more features. We start with an automatic heating system, which
consists of a heating regulation subsystem and a heating control subsystem.
The heating regulation subsystem automatically turns the heating in a
room on and off in order to maintain a constant temperature, which is stored in
a variable temp. At this point, we assume that the room has just one window.
When the window is opened, the heating is turned off to avoid wasting energy.
When the window is closed again, heating resumes to maintain the temperature
of the room.
If the window is open for more than 10 minutes, the heating system should
also return to heating, if necessary. At any point in time (independently of the
state of the heating regulation), the temperature temp is adjustable. This is
achieved by the heating control subsystem.
+HDWLQJ5HJXODWLRQ

ĐƚŝǀĞ

ZKHQW WHPS ZLQRSHQ

+HDWLQJRII +HDWLQJRQ ,QDFWLYH
ZKHQW •WHPS ^ZLQFORVH
^DIWHUV`
+HDWLQJ
&RQWURO

VHW7HPSHUDWXUH QHZBWHPS 
6WDQG%\
WHPS QHZBWHPS

LQWWHPS 

Fig. 4.4: State machine model for a heating system with two concurrent
subsystems in an orthogonal state

Figure 4.4 shows how such a heating system can be modelled using state
machines with orthogonal states. Since the complete system consists of one
orthogonal state, we have omitted the initial and final states of the parent au-
tomaton. When the system is started, the two submachines Heating Regulation
and Heating Control are started in their respective initial states.
Heating Regulation maintains the room temperature by means of the states
Heating off and Heating on and their respective state transitions. We have
used t() to represent the current room temperature. The submachine starts in
state Heating off of the composite state Active. When the room temperature
drops below the desired temperature, i.e., t() < temp, the submachine turns
88 4 Concurrent Systems

the heating on. This is achieved by the state transition to Heating on with
a variable trigger, indicated by the keyword when, that fires as soon as the
condition on the variable temp is met. In the same way, the heating is turned
off as soon as the desired room temperature temp is reached, i.e., t() ≥ temp.
The events win.open and win.close represent the opening and closing,
respectively, of the window. We assume that these events are emitted by sensors
attached to the window. If the window is opened in any of the substates of
the composite state Active, the heating should be turned off. This has been
modelled using the state Inactive. A time trigger is used to leave the state
Inactive after 10 minutes, i.e., 600 seconds.
To set the desired temperature temp independently of the current state of
Heating Regulation, a region is added to the orthogonal state that contains
a simple state machine consisting of one state StandBy. In that state the
machine can receive a new temperature, modelled as an input setTemperature
with an input parameter new_temp. In this case, the machine updates the
temperature with the new value, i.e., temp := new_temp. This is possible
because all variables in a state machine are global and are therefore shared
between the submachines of an orthogonal state. Therefore, Heating Regulation
reacts immediately, based on the new desired temperature.

4.1.3 State Transitions

We have already argued that the states of a concurrent system are a combination
of the states of its concurrent parts. This applies to state transitions as well. In
this section, different ways to represent dependencies between state transitions
of orthogonal state machines are discussed.

Signalling of State Transitions

In essence, the signalling of state transitions is achieved by one state machine

emitting an output, the signal, and another state machine receiving this signal
as input. To illustrate this concept, the home automation system will be
extended.
The system now needs to be able to cope with three windows instead of
just a single window as in the previous version. Each window is equipped with
a sensor that signals when it is opened or closed. We refer to these events by,
for instance, the name win1.open to indicate that window 1 has been opened
and win3.close to indicate that window 3 has been closed.
The modularisation principle allows us to encapsulate the monitoring of
window states in a separate submachine that signals to the heating regulation
system when a window is opened and when all windows are closed. This is
represented by the region Window Monitor in the state machine depicted in
Fig. 4.5.
 4.1 State Machines 89

^ZLQRSHQRZV 
^ZLQRSHQRZV  ^ZLQRSHQRZV
:LQGRZ0RQLWRU

^ZLQRSHQRZV ` ^ZLQRSHQRZV

&ORVHG 2SHQ ^ZLQRSHQRZV
HQWU\ZLQFORVH HQWU\ZLQRSHQ ^ZLQFORVHRZV
^ZLQFORVH>RZV @ ^ZLQFORVHRZV
^ZLQFORVH>RZV @ ^ZLQFORVHRZV`
^ZLQFORVH>RZV @`
+HDWLQJ5HJXODWLRQ

ĐƚŝǀĞ

ZKHQW WHPS ZLQRSHQ

+HDWLQJRII +HDWLQJRQ ,QDFWLYH
ZKHQW •WHPS ^ZLQFORVH
^DIWHUV`

+HDWLQJ&RQWURO

LQWRZV 
LQWWHPS 

Fig. 4.5: Home automation system with separate window monitor. Signalling
is achieved by Window Monitor emitting win.open, received by Heating Regu-
lation.

The details of the submachine in the region Heating Control are omitted;
the submachine is still the same as in Fig. 4.4 and is contained in the orthogonal
state, but it has been collapsed in the diagram for the sake of simplicity.
In Fig. 4.5, the submachine in the region Window Monitor consists of two
states. The state Closed indicates that all windows are closed. Upon entry, this
state yields the output effect win.close, which serves as a signal and can be
observed by other submachines of the same orthogonal state, i.e., by Heating
Regulation. Analogously, the state open indicates that some windows are open.
The state machine counts the number of open windows in the integer variable
ows.
If the window monitor is in the state closed and a window is opened, ows
is set to one. The window monitor transits to the state open, for which the
entry effect is carried out, emitting the signal win.open. This signal is used as
a state transition trigger in the Heating Regulation submachine.
This example shows how an output effect of a state transition in one region
can be used as the input trigger of a state transition in another region, which
enables interaction between orthogonal submachines.
We refer to this mechanism as signalling of state transitions, because an
output of one region resembles a signal that is sent to another region. A signal
is instantaneous. It is received and processed by any submachine that is in
90 4 Concurrent Systems

a state which allows it to accept that input. If no submachine is in such a

state, the signal is lost: it is neither buffered nor stored to be received later.
For instance, if the Heating Regulation submachine is in the state Inactive,
the signal win.open does not have any effect.
By encapsulating the processing of window sensor events into a separate
subsystem and providing signals for submachine interaction, two benefits are
achieved. First, only the Window Monitor subsystem needs to be adapted for
the particular number of windows in a room; the Heating Regulation region
does not need to be changed. Second, the information about the overall state
of the windows can now also be reused in other subsystems of the home
automation system.

Synchronising of State Transitions

State transitions of orthogonal automata can also be related by synchronisation.

In this context, synchronisation means that a transition of a state machine in
one region can only occur if a state machine in another region is in a defined
state.
To illustrate this concept, we extend the home automation system with a
burglar alarm subsystem, which works as follows. Initially, the subsystem is
inactive. When all of the windows are closed, it can be activated by entering a
security code. Then the resident can leave the house and close the door. When
the door or a window is opened, a timer is started. If the security code is
correctly entered again within 30 seconds, the alarm is deactivated. Otherwise,
an alarm bell is started, which remains active until the correct security code is
entered.
This behaviour is modelled by the state machine in the region Burglar
Alarm of the orthogonal state shown in Fig. 4.6. To simplify the presentation,
we have collapsed the regions Heating Regulation and Heating Control. In
addition, only the relevant variables are declared.
To activate the alarm by inserting a code, a parametrised trigger insert(cd)
is used, where cd is the inserted code, which is then stored in the variable code.
Every time insert(cd) is triggered, the parameter cd may carry a different
value.
If the alarm is activated, that is, if the submachine is in the internal state
StandBy of the composite state Active, the automaton can receive the signal
win.open provided by the Window Monitor submachine. Additionally, a door
sensor sends door.open if the room’s only door is opened. Multiple doors can
be accounted for by a door monitor that can be constructed similarly to the
window monitor.
Assume that Window Monitor is in the state Closed. If, in this state, one of
the windows win1 , win2 , and win3 is opened, the window monitor transitions
to the state Open, and upon entering this state the signal win.open is sent.
This signal can be received in the state StandBy of Burglar Alarm, which then
proceeds to the state Ready. The same happens if the door is opened.
 4.1 State Machines 91

LQVHUW FG >FRGH FG@

,QDFWLYH

LQVHUW FG >:LQGRZ0RQLWRULQFORVHG@FRGH FG

%XUJODU$ODUP

ĐƚŝǀĞ

^ZLQRSHQ ^LQVHUW FG >FRGHFG@

^GRRURSHQ` ^DIWHUV` $ODUP
6WDQG%\ 5HDG\
GRDODUP

^ZLQRSHQRZV 
^ZLQRSHQRZV
:LQGRZ0RQLWRU

^ZLQRSHQRZV 
^ZLQRSHQRZV ` ^ZLQRSHQRZV
&ORVHG 2SHQ ^ZLQRSHQRZV
HQWU\ZLQFORVH HQWU\ZLQRSHQ ^ZLQFORVHRZV
^ZLQFORVH>RZV @ ^ZLQFORVHRZV
^ZLQFORVH>RZV @ ^ZLQFORVHRZV`
^ZLQFORVH>RZV @`

+HDWLQJ5HJXODWLRQ

+HDWLQJ&RQWURO

VWULQJFRGH ´´
LQWRZV 

Fig. 4.6: Home automation system extended with a burglar alarm

In the state Ready, the alarm is about to ring loudly, unless the correct
code is entered within a short amount of time.
This is achieved by two outgoing state transitions of the state Ready and
one outgoing state transition attached to the state Active. If a code cd is
inserted and this code is the same as the previously stored code code, the
burglar alarm returns to the state Inactive. If the code entered is wrong, i.e.,
code = cd, or no code has been inserted within 30 seconds, the submachine
proceeds to the state Alarm, which sounds an alarm. This state can only be
left by entering the correct code.
The correct code can also be inserted when the submachine is in the state
Active, for instance to disable the alarm before entering or leaving the house.
If we look closely at the state transition from Inactive to Active, a new
variant of a guard is found:
[Window Monitor in closed].
This guard expresses the condition that the state transition can only occur if
the submachine in the region Window Monitor is in the state closed. That is,
the alarm can only be activated, if all windows are closed. In many situations,
such a condition about the state of other submachines in the orthogonal
92 4 Concurrent Systems

state proves useful, because signals are instantaneous and are not stored. For
instance, the signal win.close can only be processed during a state transition.
However, if all windows are closed, the window monitor is in the state Closed,
which we can refer to.
To summarise, using a state transition guard that requires other subma-
chines to be in a particular state, we can synchronise state transitions between
submachines.
The synchronisation of state transitions enables us to complete the model of
the soft drink vending machine introduced at the beginning of subsection 4.1.1.
The corresponding state machine is depicted in Fig. 4.7. The submachines of
the orthogonal state Running have been derived from the extended automata
in Fig. 4.2.

5XQQLQJ

FRQILUP>3D\PHQWLQ¼SDLG@
2UDQJH RUDQJHVRGD
'ULQN6HOHFWLRQ

RUDQJH VHOHFWHG
'ULQN
6HOHFWLRQ FRQILUP>3D\PHQWLQ¼SDLG@
OHPRQ /HPRQ OHPRQVRGD
VHOHFWHG

FRQILUP>'ULQN6HOHFWLRQLQ2UDQJHVHOHFWHG__
FRQILUP>'ULQNVHOHFWLRQLQ/HPRQVHOHFWHG@
¼ ¼
3D\PHQW

FW FW FW FW

¼SDLG ¼SDLG ¼SDLG ¼SDLG ¼SDLG

¼

¼

VKXWRII

Fig. 4.7: State machine of the soft drink vending machine with synchronised
state transitions

Recall that the specification based on two separate extended automata

suffered from the anomaly that a drink could be supplied with insufficient
funds inserted into the machine because the state transitions triggered by
confirm were not synchronised. We could resolve this issue by adding further
guards to the state transitions.
 4.2 Interacting Systems 93

If the submachine in the region Drink Selection is in the state Orange

selected, it can only proceed with the trigger confirm when the Payment
submachine is in the state 2 A C paid. Vice versa, the submachine in the region
Payment must wait for the selection of a drink before it can terminate. Hence,
through mutual waiting conditions, we have achieved synchronisation of the
state transitions: all submachines accept the trigger confirm simultaneously, if
and only if all submachines are ready to accept it.
Figure 4.7 also shows how termination of all submachines triggers the
unlabelled state transition leaving the state Running: once a paid-for drink has
been supplied, the orthogonal state is exited and re-entered through the state
transition at the top of the orthogonal state, resetting the machine so that it
can sell another beverage. When the machine is shut off , all submachines of
the orthogonal state are immediately terminated, no matter which state they
might reside in.

4.2 Interacting Systems

The previous section has addressed the modelling of single systems that show
concurrent behaviour using orthogonal states. However, monolithic systems
are rather an exception, because the majority of software systems interact
with other systems.
An example is an online shop that accepts orders and payments, and is
responsible for delivering products to customers. For this purpose, the online
shop needs to interact with the customers, payment services, and logistics
providers. In such settings, collections of autonomous systems interact in order
to coordinate their activities. We refer to these settings as interacting systems.
Each part of an interacting system is an independent system that may
show sequential or concurrent behaviour internally. Since the focus of this
section is on the interaction of systems and the resulting behaviour, the term
“interacting systems” is used; interaction is also a key aspect of distributed
systems.
Any attempt to model all systems involved in a distributed system as a
single entity, that is, a state machine with orthogonal states, would result in a
complex and probably incomprehensible model. Therefore, modularisation is
used. Each system is modelled on its own, capturing its internal behaviour using,
for example, state machines. In addition, interactions have to be captured
as well. This section looks at some methods and techniques to represent
interactions of systems.

4.2.1 Interaction by Communication

To illustrate the interaction between systems by communication, an online

shop for fulfilling orders will be discussed. This shop is responsible for, among
94 4 Concurrent Systems
UHFHLYHSD\PHQW
KDQGRYHUSDFNDJH FRQILUPDWLRQ
2QOLQH6KRS

GHOLYHUSDFNDJH
/RJLVWLFV3URYLGHU

UHFHLYHSDFNDJH
LQLWLDWHSD\PHQW
&XVWRPHU

3D\PHQW6HUYLFH
H[HFXWHWUDQVDFWLRQ

WLPH

Fig. 4.8: Communication messages in the online shop example

other things, sending shipments to customers and receiving payments. We

assume that the customer’s order has already been received.
Time diagrams are a useful technique for expressing communication between
systems. In time diagrams, each system is represented by a horizontal line,
and communication is represented by directed arcs between these lines. In
time diagrams, time proceeds from left to right. Figure 4.8 shows such a
time diagram, where activity of a system is depicted by black bars and the
interaction between systems is shown by circles connected by directed arcs.
In this example, the Online Shop hands over a package to a Logistics
Provider, which delivers it to the Customer. After receiving the package, the
customer initiates a transaction with a Payment Service. When the transaction
is completed, the Online Shop is notified.
This example differs from the ones examined previously in several respects.
First, we are no longer studying a single system with an internal behaviour,
but a number of autonomous systems that interact with each other. This
section concentrates on models that represent interactions between systems,
not on the internal behaviour of systems.
Each system is controlled only by the organisation that runs it. System
internals, such as states, variables, and events, are not shared beyond organi-
sational boundaries and therefore are not accessible to the other systems. As a
consequence, shared variables as used in state machines are no longer a feasible
means of communication.
Instead, systems communicate by exchanging messages. A system can send
and receive messages, and decide on its own which messages to receive and
how to proceed after receiving a certain message. Hence, an individual system
 4.2 Interacting Systems 95

cannot be forced into any particular behaviour by other systems, which leads
to a loose coupling of these systems.
In the example at hand, the payment service provider accepts a request
message for a financial transaction. The message contains all required informa-
tion, including account holders and bank account numbers and the amount of
funds to be transferred. Upon a successful transaction, the payment provider
sends a notification message to the receiver of the funds – the online shop – to
communicate that the payment has been carried out.
It is important to understand that time diagrams abstract away the types
of messages sent. The definition of a message includes information items, for
instance an electronic record of a successful payment, and physical items, such
as the goods ordered. In time diagrams, both types of messages are represented
by directed arcs (see Fig. 4.8).
The use of messages as a means for communication enables further abstrac-
tion, depending on the goal of the model. In Fig. 4.8, the temporal ordering
of various events is shown; for instance, handing over of the package occurs
prior to delivering the package. However, to gain an overview of the processes
of the online shop, one might not be interested in the details, but only in the
order in which shipment and payment are carried out.

VKLSSDFNDJH UHFHLYHSD\PHQW
2QOLQH6KRS

&XVWRPHU
UHFHLYHSDFNDJH
PDNHSD\PHQW

WLPH

Fig. 4.9: Abstract communication in the online shop example

This more abstract representation is depicted in Fig. 4.9, where only the
interaction of Online Shop and Customer is shown. This figure abstracts away
the transport of the package by the logistics provider and captures it by a
single message that is sent from the online shop to the customer. The same
applies to the payment and the payment provider.

4.2.2 Synchronous and Asynchronous Communication

This section discusses the implications of synchronous communication and

asynchronous communication for the behaviour of systems, in particular for
concurrency.
96 4 Concurrent Systems

Synchronous Communication

In synchronous communication, messages can only be transmitted if the sender

and receiver are both ready to perform their communication tasks. This means
that the sender is blocked until the receiver is ready to receive, and the receiver
is blocked until the sender is ready to send. A real-world example of synchronous
communication is a telephone call between two persons. Communication can
only start when both parties are ready.
In computer systems, there are two types of synchronous communication,
called delivery-based and response-based communication. In delivery-based
communication, the sender waits for an acknowledgement of the message by the
recipient. The sender can only proceed with computation when that message
has been received.
This type of communication is used if the sender of a message is interested
in its successful delivery. Synchronous delivery-based communication requires
two messages: a request message sent from a sending system to a receiving
system and a confirmation or acknowledgement sent back.
The term synchronous refers to the property that the sender cannot proceed
until it has received a response message from the receiver – it is blocked. This
blocking of the sender between sending a message and receiving the acknowl-
edgement synchronises the sender and receiver. Once the acknowledgement
has been received, the sender can be sure that the message has been received.
Delivery-based synchronous communication requires that the receiver confirms
only the reception of the message, not its processing.
Message transfer by facsimile is an example of delivery-based communi-
cation. A document is sent from one fax machine over a telephone line to
another fax machine. Upon successful, complete reception of the document, the
receiving machine returns a receipt to the sending fax machine. The connection
between the two machines is kept alive until the receipt is received by the
sender.
In this example, the blocking of the sender in synchronous communication
is illustrated by the fact that we cannot send further messages until an
acknowledgement of the successful transmission of the previous facsimile
message has arrived and the synchronous communication has completed.
Figure 4.10 illustrates this interaction using synchronous delivery-based
communication between two systems. Two possible situations are depicted in
the time diagrams, where the receiver is or is not ready to receive a message.
In both cases, system A sends a message, which is received by system B.
The horizontal shift between the sending event snd(m) and its reception
rcv(m) demarcates the time taken to deliver the message. This could be due,
for instance, a delay in a computer network or the physical transportation of
goods by a logistics provider.
An acknowledgement message ack is immediately returned to the sending
system and the receiver starts to process the message, as depicted in Fig. 4.10a.
 4.2 Interacting Systems 97

snd(m) rcv(ack) VQG P UFY DFN

A $

B %
rcv(m) UFY P
B is ready
snd(ack) VQG DFN
%LVEXV\

time WLPH
(a) Receiver ready (b) Receiver busy

Fig. 4.10: Synchronous delivery-based communication

Consequently, after the sending of a message, both the sender and the receiver
are active at the same time.
If, however, the receiver is not ready to receive a message because it is
currently busy with another task, then the delivery of the message will be
delayed. This delay is depicted by the segmented message arc in Fig. 4.10b. It
is also possible that the receiver may not accept a message from the sender A
if it is expecting a message from another party beforehand.
Recall that the sender can only proceed once its message has been received
and acknowledged. This may result in an undesired situation: if the receiver
chooses never to receive the message, then the sender cannot proceed.
Response-based communication is very similar to delivery-based communi-
cation. Rather than waiting for an acknowledgement, the sender is blocked
until a response message is received. This message contains information that
is provided by the recipient in response to the initial message.
Response-based communication is depicted in Fig. 4.11. Instead of con-
firming the delivery of the original message immediately after reception, the
recipient waits until the message has been processed and only then returns a
response to the sender.
Synchronous response-based communication is sometimes also referred to
as remote procedure call or RPC. System A wants to execute a procedure
that is available on system B. Hence, it sends a message m that contains all
required information to B; B then executes the procedure, and returns the
result as a response message res to A.
This concept is also used by HTTP requests sent by web browsers. The
browser sends a request message to a web server. Upon reception, the web
server retrieves the requested information, compiles a web-page of dynamic
content, and returns the result to the browser, which then renders it and shows
it to the user.
Just as in delivery-based communication, the sender is blocked until the
response has been received. Here, the response is sent only after the processing
of the message has been completed, as shown in Fig. 4.11a. If the receiver is
98 4 Concurrent Systems

snd(m) rcv(res) snd(m) rcv(res)

A A

B B
rcv(m) snd(res) rcv(m) snd(res)
B is ready B is busy

time time
(a) Receiver ready (b) Receiver busy

Fig. 4.11: Synchronous response-based communication

currently busy, then the response is delayed as well. We have all witnessed this
waiting when trying to access overloaded web sites. This situation is depicted
in Fig. 4.11b.
The two variants of synchronous communication share the benefit that the
sender knows that its message has been received or responded to, but also
the drawback that the sender is blocked and cannot proceed until a response
has been received. Hence, if the receiver is unable or unwilling to accept the
sender’s message or respond to it, the sender is stuck.

Asynchronous Communication

In asynchronous communication, senders are not blocked after sending messages.

Instead, a message can be sent and the sender can proceed immediately.
Asynchronous communication is depicted in Fig. 4.12.

snd(m) snd(m)
A A

B B
rcv(m) rcv(m)
B is ready B is busy

time time
(a) Receiver ready (b) Receiver busy

Fig. 4.12: Asynchronous communication

If the receiver is ready, as shown in Fig. 4.12a, it accepts the message

as soon as it arrives and can process it. If the receiver is busy, however,
 4.2 Interacting Systems 99

message delivery and processing is delayed, as depicted in Fig. 4.12b. The

communication model assumes that the message is delivered as soon as the
receiver is ready to receive it.
In asynchronous communication, the receiver may possibly not accept a
message; for instance, it may terminate before accepting the message. Since
the sender has no record of message delivery, it does not know about this.
As a consequence, message delivery cannot be guaranteed in asynchronous
communication.
An example of asynchronous communication is the sending of an email
message. After sending an email, the sender can continue with whatever task
is at hand. The email will be delivered to the inbox of the recipient, but the
sender cannot assert that the message has been read.
When modelling the interaction between systems, one has to keep in mind
that messages may not be delivered instantaneously, as delivery takes time.
We have already observed that messages take time when we discussed the
abstraction of message-based interaction: the delivery of a parcel could be
modelled by several messages involving a logistics provider or as a direct
interaction between an online shop and a customer.

snd(m1) snd(m2) snd(m1) rcv(ack1) snd(m2) rcv(ack2)

A A

B B
rcv(m2) rcv(m1) rcv(m1) rcv(m2)

time time
(a) Asynchronous (b) Synchronous delivery-based

Fig. 4.13: Order of message sending

As a consequence, we must not assume that messages are received in the

order in which they were sent, because they may overtake each other. This
is shown in Fig. 4.13a. Here, system A first sends message m1 and then m2 .
However, message m1 is delayed for some reason and is only received after m2 .
The overtaking of messages can be avoided by using synchronous com-
munication, as illustrated in Fig. 4.13b. Using, for example, synchronous
delivery-based communication, system A can only send m2 after m1 has been
received and its reception has been confirmed by returning an acknowledgement.
Here, the sending order of messages m1 and m2 is guaranteed to be preserved
in their reception.
Despite these observations regarding the order in which messages are sent,
the receiving system itself may prescribe an order of receiving messages. For
100 4 Concurrent Systems

instance, Fig. 4.14 describes a situation where system B only accepts a message
from system A after it has received and processed a message from system C .
Although message m1 , sent by system A, reaches system B before m2 has even
been sent, it is not immediately accepted by system B. Only after m2 from
system C has been processed can message m1 be accepted.

snd(m1) rcv(res1) snd(m1)

A A

B B

C C
snd(m2) rcv(res2) snd(m2)

time time
(a) Synchronous response-based (b) Asynchronous

Fig. 4.14: Order of message reception

Using synchronous communication, as shown in Fig. 4.14a, this leads to

blocking of system A for as long as it takes to process both messages. Hence,
system A also waits for system C , indirectly.
Again, this waiting condition can be resolved by using asynchronous com-
munication, as depicted in Fig. 4.14b. Here, the reception of message m1 is
also delayed until message m2 has been processed, but system A is not blocked
any more.
The interaction of systems may introduce anomalies due to mutual waiting
conditions. For instance, in synchronous communication, a deadlock will occur
if one systems sends several messages in a given order but the receiving system
expects those messages in another order.
Let the sender system send message m1 before m2 . Owing to the use of
synchronous communication, m2 can only be sent after m1 has been responded
to. However, the receiver will only accept m2 before m1 . Therefore the reception
and response to m1 will be delayed. In this situation, both systems are stuck
and cannot proceed.
A similar situation can also occur in asynchronous communication if a
system A is waiting for a message from a system B, whereas B waits for a
message from A before either system can continue. Mutual waiting conditions
lead to behavioural anomalies, which can also span more than two interacting
systems.
 4.2 Interacting Systems 101

This discussion shows how behavioural anomalies can be introduced in

interacting systems. These problems occur despite the fact that each individual
system is designed in a correct way; the anomalies are the result of faulty
interaction between these systems. In Chapter 8, we introduce techniques to
detect and resolve such anomalies using formal approaches.

4.2.3 Sequence Diagrams

Sequence diagrams allow one to capture the interaction between systems,

where the term “system” is used in a very generic form and is not limited
to computer systems. Sequence diagrams are part of the UML standard and
were derived from Message Sequence Charts, an earlier standard for modelling
message exchange between computer systems and their environment.
Besides software applications and components thereof, the term “system”
includes web services, and business processes of different organisations that
interact with each other. This also includes humans who interact with a system
or with each other. Hence, the modelling technique in itself allows for different
levels of abstraction; from the overall interaction of two organisations to the
very detailed exchange of messages or invocation of operations, including
parameters passed and values returned between two software components.
The above description of sequence diagrams refers to concrete systems, not
to types of system. A concrete system is represented by a particular instance.
This enables the modelling of several instances of the same type, for instance
a pool of workers who accept tasks when they are available. We refer to these
concrete systems, or system instances, as participants in what follows.
Sequence diagrams encompass only the observable interaction behaviour
of systems, i.e., their interface with other systems, and not their internal
behaviour. In our earlier discussion of the principle of modularisation, we have
suggested that we need to distinguish between the internal and the external
behaviour in different system models. This allows, for instance, one system to
be replaced with another if both have the same interface.
Finally, sequence diagrams assume essentially that, in principle, the mes-
sages sent and received by any one system are sequential, which means that
they are causally ordered. Nevertheless, the model expresses concurrency, as
subsets of systems may communicate with each other at the same time, and
several systems may be active at the same time. We will also see that sequence
diagrams allow the explicit modelling of concurrent fragments.

Messages

Sequence diagrams consist of a number of participants, and messages that

they send to each other. Figure 4.15 shows three examples. Each participant
is represented by a lifeline – a vertical dashed line with a rectangle at the
top. The label of the rectangle identifies the participant. It is possible, but
102 4 Concurrent Systems

not required, to model a human participant by a stick man figure instead of a

rectangle.
Each participant is an instance of a system type. This needs to be expressed
according to the UML naming scheme as follows:
[instance-identifier] : system type
The instance identifier is optional and is only required if several instances of
the same system type interact with each other. If the instance identifier is
omitted, the label starts with a colon to express that the participant is, in
fact, an instance of the type. In all of the examples in Fig. 4.15, an instance of
system type A communicates with an instance of system type B.

$ % $ % $ %

(a) Synchronous (b) Synchronous (c) Asynchronous

delivery-based response-based

Fig. 4.15: Message types in sequence diagrams

A message sent from one system to another is modelled as a directed arc.

In subsection 4.2.2, three communication models were introduced. In sequence
diagrams, these are represented by different notations for the message arcs.
A solid arc with a filled arrowhead represents a synchronous message. If the
communication model presumes that the communication is delivery-based, no
return arc is shown, as depicted in Fig. 4.15a. Note that even though the return
arc is missing, the instance of system type B in fact sends an acknowledgement
message to the instance of system type A. Hence, acknowledgement messages
are not shown in sequence diagrams.
In contrast, in synchronous response-based delivery the return message
is represented explicitly by a dashed arc with an open arrowhead, as shown
in Fig. 4.15b. Asynchronous communication, where the sender is not blocked
after sending, is depicted by a solid arc with an open arrowhead. An example
is shown in Fig. 4.15c. The ordering of messages is represented by the vertical
arrangement. Interactions start at the top of sequence diagrams and flow to
the bottom. Obviously, in Fig. 4.15b, a response message is returned after the
respective request message.
Sequence diagram focus on behavioural modelling, where the ordering
of messages is essential. Therefore messages are depicted by horizontal arcs.
The vertical distance between messages does not express a proportional time
interval between the sending or reception of the messages. The actual time
 4.2 Interacting Systems 103

delay between sending and receiving a message is abstracted away in sequence

diagrams.
If an activity of a participant is irrelevant and only the order of sent and
received messages is important, we can use lifelines and messages, as shown in
Fig. 4.15. It is also possible to explicitly model so-called episodes, which are
intervals in which a participant is active. Episodes are represented by narrow
white bars that cover the lifeline of a participant.

2QOLQH6KRS /RJLVWLFV3URYLGHU &XVWRPHU 3D\PHQW6HUYLFH

VHQG LQYRLFHDPRXQW

VXEPLW SDUFHOGHVW
VXEPLW SDUFHO

VXEPLW SDUFHO VLJQ

SD\ DPRXQW

QRWLI\

Fig. 4.16: Sequence diagram for the online shop scenario showing episodes
where participants are active

An example is shown in Fig. 4.16; the online shop is active over the course of
the complete interaction depicted, whereas the other participants are activated,
when they receive a message and remain active for the time required to process
that message.
For instance, the Logistics Provider is activated by the message sub-
mit(parcel) from the Online Shop. It then delivers the parcel to the customer;
it remains active until it receives a confirmation as a response message from
the Customer. The Customer is active as soon as they receive an invoice,
waiting for the delivery of the parcel. The Payment Service is active only for
the duration of a financial transaction, i.e., from receiving a request from a
Customer until sending the notification to the Online Shop. Waiting for a
response to a synchronous response-based communication is considered time
spent active, although the sender is blocked until the response message is
received.
Figure 4.16 also shows that messages can be labelled with a name and a
set of parameters, passed along with the message:
message-name [(parameter 1 [, parameter 2 [, ...] ] )]
104 4 Concurrent Systems

The message can carry any number of parameters, which are surrounded by
parentheses. If no parameters are included, the parentheses can be omitted.
For instance, the label send(invoice, amount) expresses the fact that an
invoice is sent to a customer, which contains the invoice document and the
amount payable as parameters. After receiving the parcel, the customer uses
the latter parameter to initiate the payment with the Payment Service by
passing the same amount as a parameter of the message pay.
To match a response in synchronous response-based communication with
the message originally sent, the message name and parameters are repeated.
Additionally, the response is passed as a return value separated by a colon from
the message declaration. In Fig. 4.16 the message submit(parcel) is responded
to with the signature (sign.) of the customer.

2QOLQH6KRS &XVWRPHU 3D\PHQW6HUYLFH

VHQG LQYRLFHDPRXQW

SD\ DPRXQW

WUDQVIHU 2QOLQH6KRS
WUDQVIHU &XVWRPHUDPRXQW

QRWLI\ &XVWRPHUDPRXQW

Fig. 4.17: Sequence diagram with a message where sender and receiver are the
same participant

Participants can also send a message to themselves. This can be used to

express the fact that some behaviour of a participant is executed depending
on the reception of a message.
An example is shown in Fig. 4.17, where the processing of a financial
transaction by the Payment Service is depicted in more detail. When a pay
message is received, the Payment Service executes the operation transfer,
passing as parameters the Online Shop as the payee and the Customer as the
payer, along with the amount to be transferred. As the example shows, it is
possible to use not only variables as parameters in sequence diagrams, but
also the participants involved.
If the sender and receiver of a message are identical, the message is processed
in a separate scope of execution. This is represented by another activity bar
stacked on top of the activity bar from which the message has been sent,
as illustrated in Fig. 4.17. It is important to understand that this does not
express concurrency, i.e., the behaviour of the Payment Service shown is still
 4.2 Interacting Systems 105

sequential, as the activity initiated by pay(amount) is suspended for the time

during which the activity triggered by the transfer message is active.

Combined Fragments

With the properties of sequence diagrams that we have explored so far, we

can express simple sequences of interactions. However, we cannot model more
complex scenarios, for instance where alternatives need to be differentiated or
where some parts of the behaviour may be repeated. UML sequence diagrams
offer notational elements for combining parts of the behaviour into so-called
combined fragments. In this section, we introduce types of combined fragments
to model concurrency, alternatives, and loops.
A combined fragment consists of a rectangular frame that is drawn over
the lifelines of the participants that are involved in the fragment. The fragment
type, and thereby its semantics, is denoted by a keyword in the top left corner
of the fragment. Fragments contain one or more regions, separated by a dashed
line, which are called operands in UML sequence diagrams. The fragment type
specifies how the behaviour of these operands is combined. Fragments can also
be nested.

2QOLQH6KRS O/RJLVWLFV3URYLGHU O/RJLVWLFV3URYLGHU

SDU
JHW3ULFH GHVW

JHW3ULFH GHVW S

JHW3ULFH GHVW

JHW3ULFH GHVW S

DOW
VXEPLW SDUFHOGHVW
>SS@

>HOVH@
VXEPLW SDUFHOGHVW

Fig. 4.18: Choosing the best price with combined fragments

106 4 Concurrent Systems

Figure 4.18 shows an excerpt from the shipping process that involves the
online shop and several logistics providers. Here, we see two instances of the
same system type Logistics Provider. These are distinguished by instance
identifiers l1 and l2 . In the model, the Online Shop first obtains prices for a
delivery from each Logistics Provider using the synchronous response-based
message getPrice(dest) and then chooses the least expensive offer for the
shipment of a parcel.
The sequence diagram features two fragment types. The upper fragment,
with the keyword par, consists of two operands that are carried out concurrently.
The messages between the online shop and the logistics providers can be sent
and received in any order, as long as the order of messages within each operand
is preserved. For example, getPrice(dest) can be sent first to the logistics
provider l2 and then to l1 , whereas the response from l2 can be received before
the response from l1 . The process continues after this combined fragment, i.e.,
when the sequences modelled in each operand have been carried out completely.
The return values of a response-based message can be used in the remainder
of the sequence diagram. In the example in Fig. 4.18, the Online Shop chooses
the logistics provider with the lower of the prices p1 and p2 . This behaviour
is achieved by the alternative fragment, identified by the keyword alt, which
denotes that exactly one of its operands is chosen for execution. Which of
the alternatives is chosen is determined by a guard that is attached to each
operand. If the price p1 of logistics provider l1 is the best price, i.e., p1 < p2 ,
then l1 is chosen, modelled by the message submit(parcel,dest) sent to l1 .
To avoid the possibility of the process getting stuck, every alternative
fragment should have a default operand, denoted by a guard else, which is
chosen if no other guard evaluates to true. In the example in Fig. 4.18, the
second logistics provider l2 is chosen as the default, that is, if l1 is not cheaper
than l2 .
Iterations of parts of a sequence diagram are represented by the keyword
loop. The example in Fig. 4.19 shows a login procedure for the online shop.
Customers enter their username un and password pw. The response res is a
Boolean variable that indicates a successful login with a true value, and false
otherwise.
In contrast to par and alt fragments, which have at least two operands,
loops have only one operand, which can also have a guard. Similarly to the
case of alternative operands, a guard states that the operand is executed if
the guard evaluates to true. In the example, the login procedure is repeated if
the previous attempt has failed, i.e., res = false.
Additionally, loops can have minimum and maximum iteration numbers,
denoted in parentheses following the keyword loop:
loop(min,max).
Independently of the guard, the loop is guaranteed to be executed at least min
and at most max times. In the example, the Customer can attempt to login at
most three times: once before the loop and twice within the loop. If the third
 4.3 Petri Nets 107

&XVWRPHU 2QOLQH6KRS

ORJLQ XQSZ

ORJLQ XQSZ UHV

ORRS 
ORJLQ XQSZ
>UHV IDOVH@
ORJLQ XQSZ UHV

DOW ORFN XQ
>UHV IDOVH@
ORFNHG XQ

>HOVH@ ZHOFRPH XQ

Fig. 4.19: Sequence diagram showing a loop fragment for repeated attempts to
log in to the online shop

attempt fails, i.e., res = false, the alt fragment chooses to lock the Customer’s
account and inform the customer about this action with a locked(un) message.
UML allows the following configurations for the minimum and maximum
numbers of loop iterations.
• loop(a,b) denotes that the loop is executed at least a and at most b times,
where a and b are natural numbers, a ≥ 0, and b ≥ a.
• loop(a,*) means that the operand is repeated at least a times, with a ≥ 0.
No upper limit of repetitions is given.
• loop(*) indicates that the number of iterations is not restricted at all; it
has the same meaning as loop(0,*).
Recall that the guard has a lower priority than the configuration with minimum
and maximum numbers of iterations loop(a,b). This means that the guard is
only evaluated if a ≤ c ≤ b for the current iteration counter c.

4.3 Petri Nets

In 1962, Carl Adam Petri generalised the theory of automata in his doctoral
thesis, entitled “Kommunikation mit Automaten”, laying the foundation for
Petri nets. In the following decades, researchers and practitioners have adopted
his ideas and developed numerous extensions and comprehensive theories.
Today, Petri nets are one of the most prominent techniques for capturing the
behaviour of concurrent systems.
108 4 Concurrent Systems

One of the reasons for the success of Petri nets is their dual characteristic;
the graphical and mathematical representations of Petri nets are equivalent.
Petri nets are bipartite graphs that consist of places, transitions, and directed
arcs between them. The graph is bipartite because each arc connects a place
to a transition or a transition to a place.
The mathematical foundation of Petri nets allows formal reasoning about
their properties, for instance, to identify anomalies in the behaviour of the
systems described. Petri nets are defined as follows.

Definition 4.1 A Petri net is a tuple N = (P, T, F ) with

• a finite set P of places,
• a non-empty, finite set T of transitions, such that T ∩ P = ∅, and
• a flow relation F ⊆ (P × T ) ∪ (T × P ). 

An example of a Petri net N = (P, T, F ) that follows the above definition

is the following:
P = {p1 , p2 , p3 },
T = {t1 , t2 , t3 },
F = {(p1 , t1 ), (t1 , p2 ), (p2 , t2 ), (p2 , t3 ), (t2 , p3 ), (t3 , p3 )}.
Figure 4.20 shows the graphical representation of this Petri net. Places are
depicted as circles and transitions as rectangles. The flow relation connects
places with transitions and transitions with places through directed arcs.

t2
t1
p1 p2 p3
t3

Fig. 4.20: Petri net showing an exclusive choice

A place p ∈ P is an input place of a transition t ∈ T if and only if there

exists an arc from p to t, that is, if and only if (p, t) ∈ F . Similarly, a place
p ∈ P is an output place of a transition t ∈ T if and only if there exists an arc
from t to p, that is, if and only if (t, p) ∈ F .
The set of input places, the preset for a transition t, is denoted by •t =
{p|(p, t) ∈ F }. The set of output places, the postset, for a transition t is denoted
by t• = {p|(t, p) ∈ F }. In Fig. 4.20, for instance, the postset of the transition t1
consists of one place, t1 • = {p1 }, as the preset of the transition t3 , •t3 = {p2 }.
A Petri net defines the behaviour of a system by a static structure, the
net. Places represent passive components of the system, while transitions are
active components. In the context of the modelling of dynamic systems, places
and transitions can have different interpretations.
 4.3 Petri Nets 109

• A transition may represent an event that can occur, whereas an input place
of a transition denotes a precondition that needs to be satisfied for the
event to occur; an output place denotes a postcondition.
• A transition may represent a task to be carried out. Its input places may
represent resources that are required for the task to be carried out, and
its output places may represent the resources that are released after the
task’s completion.
• A transition can also represent a computational step in an algorithm. An
input place may denote the activation of this step and an output place its
termination. At the same time, input places may represent input data for
the computation and output places the result of the computational step.
To summarise, Petri nets are structures that consist of places, transitions,
and arcs between them. A distinctive aspect of Petri nets is their ability to
characterise behaviour by tokens on places and rules about how the distribution
of these tokens within a Petri net might change. Tokens are represented by
black filled circles on places in a Petri net. A token on a place might represent
that a precondition is met, that resources are available, or that input data is
available.
The Petri net shown in Fig. 4.20 contains a token on p1 . Formally, the
tokens in a Petri net are captured in its marking.

Definition 4.2 Let N = (P, T, F ) be a Petri net. A marking of N is a function

M : P → N, mapping the set of places to the natural numbers including 0,
such that M (p) returns the number of tokens on the place p ∈ P . The set of
all markings of N is denoted by M. A Petri net system is a pair S = (N, M0 ),
where N is a Petri net and M0 ∈ M is the initial marking. 

A marking of a Petri net represents the state of a system that is characterised

by a distribution of tokens over the places of the net. In Fig. 4.20, the initial
marking is denoted by

1 if p = p1
M0 (p) =
0 else

For the sake of brevity, we shall use a shorthand version to denote the
marking of a net, which lists all places that carry at least one token. The
marking of the Petri net shown in Fig. 4.20 can be expressed by [p1 ]. There
is exactly one token on the place p1 and no token on any other place. If a
Petri net has one token on the places p2 , p3 and p5 , we express the marking
by [p2 , p3 , p5 ] in this shorthand.
As discussed earlier, the transitions are the active components in Petri
nets. Transitions can change the state of a system. In Petri net theory, we say
a transition fires. When a transition fires, the state of the system can change.
Rules that define under what conditions a transition can fire and what the
result of the firing of a transition is are called firing rules.
110 4 Concurrent Systems

Since there are different types of Petri nets, there are different firing rules.
In general, a transition can fire only if sufficiently many tokens reside on its
input places. When a transition fires, tokens on its input places are consumed
and new tokens are produced on its output places.
A transition can fire only if it is enabled. The firing of a transition is
regarded as an atomic step that does not consume time. Therefore, on the
firing of a transition t, the deletion of tokens in the input places of t, the firing
of t, and the generation of tokens on the output places of t occur as one atomic
step. “Atomic” means that the operation is indivisible. Later in this section,
we will introduce the most important types of Petri nets for the modelling of
behaviour, based on their respective firing rules.
Before doing so, another example of a Petri net will be introduced that
shows the wide applicability of the approach. Figure 4.21 shows a Petri net
representing a bicycle manufacturing process. The transitions have labels in
natural language, which makes the net easily understandable. Also, some places
have text labels, for instance “orders” and “bicycles”.
This Petri net can be interpreted as follows. When an order comes in, first a
frame has to be taken from the inventory. Afterwards, the wheels are mounted,
before the brakes and the drive train are attached. As will be discussed shortly,
the brakes and drive train can be attached in any order. Once both components
have been attached to the frame, the bicycle can be tested.

p2 p3
attach
orders p1 brakes bicycles
get attach test
frame wheels bicycle
attach
drive train
p4 p5

Fig. 4.21: A manufacturing process represented by a Petri net

4.3.1 Condition Event Nets

The basic type of Petri nets is condition event nets. The intuition behind
condition event nets is as follows. Places represent conditions and transitions
represent events. This means that a token on a place models the fact that a
condition is met. This assumption has implications for the markings that are
permitted in condition event nets.
Since a condition can be either true or false, there can be either no token
on a place (the condition is false) or one token (the condition is true). It does
not make sense to have multiple tokens on a place. Therefore, the number of
tokens on a given place is at most one in condition event nets.
Figure 4.22 shows the manufacturing process as a condition event net. In
particular, the Petri net system is shown with one token on the place p1 , one
 4.3 Petri Nets 111
p2 p3
attach
orders p1 brakes bicycles
get attach test
frame wheels bicycle
attach
drive train
p4 p5

Order B Order A

Fig. 4.22: A condition event net representing a manufacturing process

token on p2 and one token on p5 . The tokens represent cases in the operational
business of the manufacturing company.
Order A is represented by two tokens and Order B by one token. This state
is valid in this condition event net, because there is no place with more than
one token. Firings of transitions have to be forbidden in a condition event net,
if the resulting marking would be disallowed.
This property holds for attaching the wheels, for instance. There is a token
in the preset of the attach wheels transition, but if the transition were fired,
there would be two tokens on p2 . Therefore, in condition event nets, a transition
is enabled only if there is a token on each place in its preset and no tokens
on its output places. Situations where a place is both in the preset and in the
postset of a transition will be covered below.

Definition 4.3 Let N = (P, T, F ) be a Petri net and M a set of markings. If

N is a condition event net, then M (p) ≤ 1 holds for all places p ∈ P and all
markings M ∈ M.

• A transition t ∈ T is enabled in a state M ∈ M, if M (p) = 1 for all input

places p ∈ •t and M (q) = 0 for all output places q ∈ (t• \ •t) that are not
at the same time input places of the transition t.
• The firing of a transition t ∈ T in a marking M ∈ M results in a marking
M  ∈ M, where
∀ p ∈ •t : M  (p) = M (p) − 1 and
∀ q ∈ t• : M  (q) = M (q) + 1. 

Based on the firing rules for condition event nets, the Petri net shown in
Fig. 4.20 can be discussed in more detail. Here, we assume that this Petri net
is a condition event net. The transition t1 is enabled, because there is a token
on each place in its preset, i.e., on [p1 ], and there is no token on any place in
its postset, i.e., on [p2 ].
Firing of t1 changes the marking of the Petri net to [p2 ]. In this state,
the transitions t2 and t3 are enabled at the same time. However, when one
transition fires, the token on p2 is removed and the other transition is no longer
enabled. This situation is called a conflict. Two transitions are in conflict
112 4 Concurrent Systems

if firing one transition disables the other transition. In our example, firing
t2 disables t3 and, of course, vice versa. Hence, an exclusive choice is made
between these transitions.
In condition event nets, the firing of transitions represents the occurrence
of events. Therefore, the Petri net shown in Fig. 4.20 encodes sequences of
events. In fact, two sequences of events are possible, t1 , t2 and t1 , t3 . This
Petri net encodes sequential behaviour because each event that can occur is
causally dependent on the event that has occurred before it. For instance, t2
can only happen once t1 has happened; the same holds for t3 . This means that
Petri nets can be used to represent sequential behaviour.
Petri nets can also represent concurrent behaviour. As discussed at the
beginning of this chapter, when a system shows concurrent behaviour, consec-
utive events do not need to be causally related; they can occur independently
of each other. These considerations are illustrated by the example shown in
Fig. 4.23.

p2 p4
t2
t1
p1
t3
p3 p5

Fig. 4.23: Petri net showing concurrency

In the marking shown in that figure, t1 is enabled. When t1 fires, it puts

one token on each place of its postset. Therefore, the firing of t1 results in
the marking [p2 , p3 ]. In this state, the transitions t2 and t3 are enabled at the
same time. However, these transitions are not in conflict, since the firing of
one transition does not disable the other transition. For instance, firing of t2
results in a marking [p3 , p4 ], under which t3 is still enabled, and vice versa.
This example illustrates how Petri nets can encode concurrent behaviour: t2
and t3 can fire independently of each other and are therefore concurrent.
Petri nets can also be used to represent resources which are required to
perform certain activities. In the manufacturing process example, a mechanic
is required to perform the process activities, for instance getting the frame,
attaching the wheels, and attaching the brakes. We can model resources by
tokens. If a resource is required to perform the activity represented by a
transition t, a resource token is put on a place in the preset of t. This means
that t can only fire once the resource is on that place.
These aspects are illustrated by the Petri net shown in Fig. 4.24, where
mechanic 1 and mechanic 2 are represented by places with those labels. A
token on the place mechanic 1 means that a mechanic is available to perform
the next task. In this case, the get frame transition can fire only if there is a
token on the orders place and a token on the mechanic 1 place. The mechanic
gets the frame, and attaches the wheels and brakes. After the brakes have been
 4.3 Petri Nets 113

attached, the token representing the mechanic is put back on the mechanics 1
place, indicating their availability for the next bike.

mechanic 1 mechanic 2

p2 p3
attach
orders p1 brakes bicycles
get attach test
frame wheels bicycle
attach
drive train
p4 p5

Fig. 4.24: Manufacturing process with representation of resources

Notice that the Petri net allows the brakes and the drive train to be
attached in any order. This is facilitated by the concurrency in the Petri net.
In any case, however, the bike can only be tested after both the brakes and
the drive train have been attached.

4.3.2 Place Transition Nets

The discussion of the manufacturing process example has shown that not
all scenarios can be modelled adequately by condition event nets. If places
represent storage, then the storage capacity is limited to one. However, when
we look at real-world systems, this limitation does not apply. For instance, a
manufacturing company might be able to receive many orders at the same
time. There might be storage for many bikes that are in production, not just
for one, as represented by the Petri net shown in Fig. 4.25.

p2 p3
attach
orders p1 brakes bicycles
get attach test
frame wheels bicycle
attach
drive train
p4 p5

Order B Order A

Fig. 4.25: A manufacturing process defined by a condition event net, with two
instances

In fact, the process limits the work procedures of the manufacturing

company significantly. In the state shown in Fig. 4.25, we could not attach
brakes to the bike for Order B, because the bike represented by the token on
the place p3 has not yet been tested!
114 4 Concurrent Systems

To overcome this limitation, place transition nets were introduced. These

nets allow multiple tokens on a given place. In the general case, the number
of tokens on a place is unbounded, but there can also be capacity constraints
regarding the number of tokens on places. These constraints have implications
for the firing behaviour of transitions.
In addition, place transition nets extend condition event nets in terms of
the numbers of tokens consumed and produced by firings of transitions. For
each transition, we can define the number of tokens that are consumed in each
of its input places when the transition fires. The number of tokens produced
in each output place by the firing of the transition can also be defined. This is
done by a weighting function.

Definition 4.4 Let N = (P, T, F ) be a Petri net. (P, T, F, ω) is a place tran-

sition net, where ω : F → N is a weighting function that assigns a natural
number to each arc, its weight.
 
• A transition t ∈ T is enabled in a state M ∈ M if M (p) ≥ ω (p, t) for all
input places p ∈ •t.
• The firing of a transition t ∈ T in a marking M ∈ M results in a marking
M  ∈ M, where
 
∀ p ∈ •t : M  (p) = M (p) − ω (p, t) and
 
∀ q ∈ t• : M  (q) = M (q) + ω (t, q) . 

This definition states that a transition t is enabled if each input place p

of t contains at least the number of tokens defined by the weight of the arc
(p, t). The definition does not restrict the maximum number of tokens that
can reside on the places of the net.
When a transition t fires, the number of tokens consumed in each of its
input places are determined by the weight of the corresponding arc from the
input place to the transition. That is, from each input place p of the transition
t, ω (p, t) tokens are withdrawn. Hence, in the marking M  that results 
from firing t, the number of tokens on p, i.e., M  (p), equals M (p) − ω (p, t) ).
Consequently, firing a transition does not necessarily consume all of the tokens
that reside on an input place of that transition.
Analogously, the numbers of tokens produced on each output place q of a
transition t is determined by the weight of the corresponding
 arc (t, q) from
the transition to the output place, such that ω (t, q) tokens are added to q.
An example of a place transition net with weighted arcs is shown in
Fig. 4.26. Places can be considered as storage for objects of a certain type, and
tokens represent the number of items. For instance, three tokens on the frames
place represent the fact that three frames are available. Firing the transition
get frame removes one token from the frames place. A new token is produced
on the place p1 , indicating the frame that will become a new bike.
 4.3 Petri Nets 115
p2 p3
attach
orders p1 brakes bicycles
get attach test
frame wheels bicycle
attach
drive train
p4 p5
2 2

frames wheels brakes drive trains

Fig. 4.26: Place transition net representing consumption of material

By the weighting of the arc from the wheels place to the attach wheels
transition, the net represents the fact that two wheels are taken from the
supply and attached to the frame when the transition attach wheels fires. Place
transition nets allow us to define complex system behaviour in a more compact
way than condition event nets can.

p2 p3
attach
orders p1 brakes bicycles
get attach test
frame wheels bicycle
attach
drive train
p4 p5
2 2

frames wheels brakes drive trains

Fig. 4.27: State of the Petri net shown in Fig. 4.26 after attaching the wheels
and the drive train

To illustrate the continuation of the manufacturing process, Fig. 4.27 shows

the state of the place transition net after the wheels and the drive train have
been attached to the frame. We observe also that one token has been removed
from the drive trains, indicating the consumption of this resource. Owing to
the concurrency characteristics of Petri nets, the transition attach brakes could
have been executed before attach drive train as well.

4.3.3 Extended Petri Nets

The classes of Petri nets introduced so far are adequate to represent a broad
range of system behaviours. However, there are situations in which the mod-
elling constructs provided by these nets are not adequate to express complex
behaviour. Extended Petri nets allow us to represent such behaviour in a
compact and comprehensible manner. A broad range of extensions to classical
116 4 Concurrent Systems

Petri nets has been proposed in the literature, and this section looks at two of
them: inhibitor arcs and reset arcs. In both cases, the structure of the Petri
nets is not changed: Petri nets remain bipartite graphs. These extensions are
realised by two new types of arcs, inhibitor arcs and reset arcs.

Inhibitor Arcs

In the Petri nets introduced so far, a transition can fire if there is a sufficient
number of tokens on its input places and, in the case of condition event nets,
after firing of the transition no place contains more than one token. Inhibitor
arcs reverse this approach. A transition can fire only if there are no tokens
on places that are connected to the transition by an inhibitor arc. That is, a
token in such a place prevents, or inhibits, the transition’s firing.
Inhibitor arcs only affect the enabling and not the firing semantics of a
Petri net. Therefore, inhibitor arcs can be combined with different types of
Petri nets. Since we will use mainly place transition nets in the remainder of
this book, place transition nets will be extended with inhibitor arcs.

Definition 4.5 Let N = (P, T, F, ω) be a place transition net. A place transi-

tion net extended with inhibitor arcs is defined by N  = (P, T, F, ω, I), where
I ⊆ P × T denotes the inhibitor arcs of the Petri net. For each transition
I
t ∈ T , we define • t = {p | (p, t) ∈ I} as the inhibiting places of t. A transition
t ∈ T is enabled in a marking M ∈ M if t is enabled in the original place
transition net N and there is no token on any of its inhibiting places, i.e.,
I
∀ p ∈ • t : M (p) = 0. 

Inhibitor arcs are distinguished graphically from regular arcs in Petri nets:
an inhibitor arc is shown by an edge with a small circle at the end, connected
to the transition that can fire only if the connected place is empty.
Two different Petri nets that represent parts of a back-ordering process in
the warehouse of the bike manufacturer are shown in Fig. 4.28. At the top of
each net, we see a part of the bike manufacturing process presented above.
In Fig. 4.28a, a normal place transition net is shown. In this net, back-
ordering of drive trains can be done arbitrarily often. Each time, five drive
trains are ordered. After the drive trains are received, they are put on the drive
trains place, which represents the storage of drive trains by the bike company.
Figure 4.28b shows a variant of this Petri net, involving an inhibitor arc. This
arc makes sure that drive trains can only be ordered if no drive trains are
available, i.e., if no token is on the drive trains place.

Reset Arcs

Now that we have introduced inhibitor arcs, this section looks at reset arcs in
Petri nets. Recall that inhibitor arcs affect the enabling of transition firings,
 4.3 Petri Nets 117

͘͘͘ attach ͘͘͘ ͘͘͘ attach ͘͘͘

drive train drive train
p4 p5 p4 p5

drive trains drive trains

5 5
back-order receive back-order receive
drive trains drive trains drive trains drive trains

(a) Back-ordering Petri net without (b) Back-ordering Petri net with in-
inhibitor arc hibitor arc

Fig. 4.28: Illustration of place transition nets with inhibitor arcs

but they do not affect the actual firing. In some sense, reset arcs reverse the
semantics of inhibitor arcs in that they do not affect the enabling of transitions,
but do affect firing behaviour.
In particular, when a transition fires, all places that are connected to that
transition by reset arcs are cleansed of all their tokens, i.e., these places are
reset. In general, reset arcs can be applied to various classes of Petri nets.

Definition 4.6 Let N = (P, T, F, ω) be a place transition net. A place tran-

sition net extended with reset arcs is defined by N  = (P, T, F, ω, R), where
R ⊆ T × P denotes the reset arcs of the Petri net. For each transition t ∈ T , we
R
define • t = {p | (t, p) ∈ R} as the reset places of t; t is called a reset transition
R
if and only if • t =
 ∅. A transition t ∈ T is enabled in a marking M ∈ M if
and only if t is enabled in M in the place transition net N . The firing of a
transition t ∈ T in a marking M ∈ M results in a marking M  ∈ M, such that
M  is the marking resulting from firing of t in the original Petri net N and M 
R
is derived from M  by M  (p) = 0, ∀ p ∈ • t and M  (p) = M  (p), otherwise. 

An example of a place transition net with reset arcs is shown in Fig. 4.29a.
Here, firing the transition clear inventory removes all tokens from all places
that are connected to it with a reset arc, effectively removing all items from
all inventory places of the bike manufacturer. There are several different ways
to represent reset arcs in extended Petri nets. If a transition t has a single
or only a few reset places, those reset places can be connected to t with an
arc with a double arrowhead, as shown in Fig. 4.29a. If there are several reset
places for a transition t, we can mark a region of the Petri net and connect
that region to t using a single reset arc. The region can be considered as a
shorthand notation for a reset arc to each place in it. Figure 4.29b shows the
corresponding Petri net using a reset region.
118 4 Concurrent Systems

IUDPHV ZKHHOV EUDNHV GULYHWUDLQV IUDPHV ZKHHOV EUDNHV GULYHWUDLQV

FOHDU FOHDU
LQYHQWRU\ LQYHQWRU\

(a) Petri net for clearing the in- (b) Petri net for clearing the inven-
ventory using inhibitor arcs tory using cancel region

Fig. 4.29: Illustration of place transition nets with reset arcs

Based on the definitions of inhibitor arcs and reset arcs, we can define
extended Petri nets as follows.

Definition 4.7 Let N = (P, T, F, ω) be a place transition net. An extended

place transition net is defined by N  = (P, T, F, I, ω, R), where I ⊆ P × T
denotes the inhibitor arcs and R ⊆ T × P denotes the reset arcs of the Petri
net. The enabling of N  is extended as described in Definition 4.5, and the
firing behaviour of N  is extended as described in Definition 4.6. 

cancellation
request cancelled order
cancel
production

p2 p3
attach
orders p1 brakes bicycles
get attach test
frame wheels bicycle
attach
drive train
p4 p5

Fig. 4.30: Manufacturing process represented by an extended Petri net involving

reset arcs and an inhibitor arc

Extended Petri nets and the associated notation are illustrated in Fig. 4.30,
which shows a variation of the bike manufacturing process discussed above. In
this example, reset places are used to cancel an order. This is achieved by a
transition cancel production, which removes all tokens from the manufacturing
process in the region enclosed by the dashed line. Using inhibitor arcs, this
Petri net also specifies that an order can be cancelled only before a bike has
been tested.
 4.3 Petri Nets 119

Although this example provides an illustration of reset arcs and inhibitor

arcs, it is not entirely appropriate if many orders are managed by the net. If
there are several orders, then performing the cancel production transition once
will cancel all orders that are currently active. However, a cancellation request
should cancel only one order, and the remaining orders should proceed.
We cannot represent this property of running several cases simultaneously in
a single net with the Petri nets discussed so far, because we cannot differentiate
between different tokens. If the tokens were to carry values we could then
remove only specific tokens. For example, cancelling an order with the order
number 1234 would remove only those tokens which carry the same order
number. The next section introduces coloured Petri nets, which are able to
represent values in tokens.

4.3.4 Coloured Petri Nets

In traditional Petri nets, such as condition event nets or place transition nets,
tokens cannot be distinguished from each other. That is, while tokens may
represent items of material or information, transitions cannot define which
items need to be consumed and generated upon firing.
This drawback is addressed by coloured Petri nets, where a token is an
object that carries data in much the same way as variables in programming
languages. Hence, these tokens can be distinguished from each other and can
serve as both inputs and outputs of firing transitions.
Coloured Petri nets enrich classical Petri nets by extending their known
structural elements, while preserving the fundamental semantics and bipartite
graph structure of Petri nets.

• Tokens are extended with a colour in a figurative sense. Tokens carry

structured data values, by which they are distinguishable just as if they
were wearing different colours.
• Places are extended with a data structure definition, called a colour set.
This determines the type, that is, the data structure, of all tokens that can
reside on a place.
• Arcs are extended with arc expressions that determine how tokens are
consumed and how they are produced when a transition fires.
• Finally, transitions are extended with guard conditions that must evaluate
to true, in order for the transition to be enabled.
Since this book is not primarily about Petri nets or coloured Petri nets, we
shall content ourselves with an informal description and refer the reader to
the bibliographical notes of this chapter for a formal definition.
An example of a coloured Petri net is shown in Fig. 4.31, illustrating a
simplified procedure for selling tickets. Because of the extensions involved in
coloured Petri nets, we have highlighted the names of places in bold in the
following figures to ease comprehension.
120 4 Concurrent Systems

NLGV
LI D” Q SD\UHGXFHG
QWNLG WLFNHW
YLVLWRUV WKHQ Q SULFH
ŚŽůĚĞƌƐ
7RP QD
-DQH FKHFN
DJH
3HWHU
LI D! Q SD\UHJXODU
SULFH QWUHJ
WKHQ Q
JURZQXSV

Fig. 4.31: Coloured Petri net for selling tickets

This example shows a net with three transitions. Based on the outcome of
the check age transition, which takes as input a token that represents a visitor
to a museum, either a reduced or a regular entry fee has to be paid for the
visitor to become a ticket holder. The coloured Petri net has different places
with the following colour sets:

visitors (name : string, age : integer),

kids (name : string),
grown-ups (name : string),
ticket holders (name : string, ticket : ticket).
The colour set of a place determines the data structure of tokens residing
on that place. For instance, the colour set of the place visitors determines that
every token consists of two attributes: name, of type string, and age, of type
integer.
Recall that tokens do not flow through a net but are consumed and produced
by the firing of transitions. In coloured Petri nets, the firing semantics is
determined by arc expressions. For arcs connecting input places with transitions,
the arc expression determines so-called bindings. A binding is a function that
maps data values to variables of the Petri net.
Bindings are used to determine whether a transition is enabled. In general,
a transition is enabled under a binding if the values of the variable of that
binding match the values of the token in the transition’s input places. Arc
expressions also determine how a new token is produced and what values it
carries, according to the data structure imposed by the colour set of the output
place. These concepts will now be illustrated by an example.
Returning to the example shown in Fig. 4.31, we can investigate the enabling
of the transition age check. This transition is enabled under bindings b1 , b2 ,
and b3 , defined as follows:

b1 (n) = Tom, b1 (a) = 11 ,

b2 (n) = Jane, b2 (a) = 24 ,
b3 (n) = Peter, b3 (a) = 5 .
 4.3 Petri Nets 121

When the transition fires, one binding is chosen, and tokens with the bound
values are consumed and produced. Assuming that age check fires under the
binding b2 , the variable n is bound to Jane and a to 24 during firing.
Outgoing arcs of a transition can be expressed using logical clauses that
determine which output places tokens are produced on, and how. In the
example, if the age variable a of the transition check age is less than or equal
to 12, a token that consists only of a name is produced in the place kids;
otherwise, a token is produced in the place grown-ups.

NLGV
LI D” Q SD\UHGXFHG
QWNLG WLFNHW
YLVLWRUV WKHQ Q SULFH
ŚŽůĚĞƌƐ
7RP QD FKHFN
DJH
3HWHU
LI D! Q SD\UHJXODU
SULFH QWUHJ
WKHQ Q
JURZQXSV
-DQH

Fig. 4.32: Coloured Petri net for selling tickets after the transition check age
is fired

Figure 4.32 shows the state of the coloured Petri net after check age has
fired under the binding b2 . According to the arc expression (n, a), the token
(Jane, 24) is removed from the input place and a new token (Jane) is produced
on the grown-ups place, as determined by the arc expression.
In the next step, the net might choose to check the age of another visitor or
proceed with the transition pay regular price. In the latter case, a new token
is produced on the place ticket holders, which represents Jane with the ticket
that she has bought.
We have not yet addressed transition guards in coloured Petri nets. There-
fore, we introduce a second example, which also shows how these nets can
be used to specify not only processes but also interconnected networks of
processes on a detailed level.
Consider a warehouse of a bike manufacturer, which consists of a central
storage place, i.e., an inventory, and an inbound dock, where back-ordered
items are delivered to. The warehouse also has an outbound dock, where
items are requested and handed out. This is shown in Fig. 4.33, where places
represent these storage areas. New items are collected from the inbound dock
and taken to the inventory, to be transferred to the outbound dock if requested.
The places inbound dock, inventory, and outbound dock have the same
colour set (prod: string, num: integer). A token on any of these places denotes
that num items of product reside on that place.
For every token on the place inbound dock, there exists a binding to the
transition add that leads to the token’s consumption and the production of
122 4 Concurrent Systems
LQERXQG RXWERXQG
GRFN LQYHQWRU\ >QXP!  GRFN
SURGQXP UHT SURG@
SURGQXP SURGQXP SURGQXP
DGG UHPRYH
SURGQXP

UHTXHVW
SURGQXP  SURG UHT
SURGQXP  QXPQXP

FRQVROLGDWH

>SURG SURG@

Fig. 4.33: Warehouse management represented by coloured Petri net

an identical token in the inventory. Hence, this transition merely moves the
token from one place to another.
When an item is requested in the outbound dock, a token that carries the
name req of the required product is placed on the request place. If the place
inventory carries at least one token, then there exists a binding which maps
token values to transition variables for the transition remove. However, this
transition may not be able to fire, because of its guard.
For instance, it may be that a token (brake) is on the place request and
the only token in the place inventory is (frame, 7 ). A frame should not be
handed out if a brake was requested. Hence, the guard of the transition remove
ensures that more than 0 items of prod are in the inventory, and that the item
taken from the inventory is of the same product type as the requested item,
by means of req = prod.
In this case, the binding is important, because only the variables of a
transition can be used in the guard. If we assume additionally that a token
(brake, 12) was in the place inventory, two bindings would exist for the remove
transition:

b1 (prod) = frame, b1 (num) = 7, b1 (req) = brake,

b2 (prod) = brake, b2 (num) = 12, b2 (req) = brake.
The condition req = prod ensures that the transition is enabled only under
the binding b2 . When the transition fires, the token (brake, 12) is removed
from the place inventory and (brake) is consumed from the place request.
Moreover, a new token (brake, 1) is produced in the outbound dock and the
inventory is updated with a token (brake, 11) that accounts for the removed
item. Production of the latter token is achieved by the arc expression (prod,
num - 1), which creates a new token, decrementing the number of items for
the given product.
Finally, we discuss the function of the consolidate transition in Fig. 4.33.
The transition is responsible for joining together several tokens that represent
the same product type. This is required if several items of the same product
 4.3 Petri Nets 123

type are delivered to the warehouse. Assume that the place inventory carries
a token (brake, 5), stating that five brakes are in stock. Additionally, four
new brakes are added to the stock by placing a token (brake, 4) on the place
inbound dock and firing the transition add, which moves this token to the place
inventory, which now contains two tokens for brakes.
From a theoretical perspective, this not problematic, as places can carry any
number of tokens. However, from a practical point of view this is undesirable,
because the transition remove does not delete these tokens when the supply is
emptied for a given product type, but rather returns a token with num = 0 to
the place inventory, when it consumes a token with num = 1. As a result, as
the net operates, more and more tokens accumulate on the place inventory.
This shortcoming is mended by the consolidate transition, which consumes
two tokens of the same product type and merges them into one token in the
inventory. This is possible because of the way bindings work in coloured Petri
nets.
Recall that the data of a token is stored as a tuple. A token does not
include variable names, but consists only of a tuple of values. Arc expressions
read these tuples and assign them to variables of a transition, which yields a
binding. In this way, it is also possible that more than one token is consumed
or produced on a place as a result of an arc expressions in a coloured Petri net.
The arc expression (prod 1 , num 1 ), (prod 2 , num 2 ) denotes that two tokens
are required for the binding of transition consolidate. In our example, with
two tokens for the brake product type – (brake, 5) and (brake, 4) – in the place
inventory, the binding of these two tokens to the variables of the transition is
as follows:

b(prod 1 ) = brake,
b(num 1 ) = 5,
b(prod 2 ) = brake,
b(num 2 ) = 4.

The transition consolidate can fire because the guard prod 1 = prod 2 is
satisfied for this binding. If there were other tokens with different product
types in the place inventory, bindings with different values for prod 1 and prod 2
would exist as well, but these would not satisfy the guard.
Upon firing, consolidate consumes these two tokens for the same product
type, removes them from the inventory, and produces only one token as a
result on the place inventory, for which it sums the numbers num 1 and num 2 .
In our example, a new token (brake, 9) is produced in the inventory.
This can be executed repeatedly, whenever there exist at least two tokens
for the same product type. Looking at the coloured Petri net in Fig. 4.33, we
see highly concurrent behaviour as, at the same time, new items can be added
to and removed from the warehouse. Simultaneously, the consolidation process
makes sure that the warehouse is always being tidied up.
124 4 Concurrent Systems

In the next chapter, coloured Petri nets are used to define the semantics of
workflow control flow patterns, which are the conceptual basis of the control
flow constructs used in behavioural models describing business processes.

Bibliographical Notes

Models to represent and analyse concurrency in computer systems have been

instrumental in the process by which computer science has become a research
discipline. Communicating Sequential Processes (CSP), introduced by Milner
(1980), provide an approach to representing processes that interact with each
other by sending and receiving messages. This allows us to model concurrent
systems whose components show sequential behaviour. An alternative, formal
approach was introduced by Hoare (1978). The Calculus of Communicating
Systems (CCS) allows us to reason about concurrent systems.
Orthogonal states of automata were introduced by Harel (1987), using stat-
echarts. The possibility of representing concurrency in automata by orthogonal
states was incorporated into the UML standard, as detailed by the Object
Management Group (2015).
Petri nets were introduced by Petri (1962). The idea of “zero testing” using
inhibitor arcs was proposed by Flynn and Agerwala (1973). Petri nets with
inhibitor arcs were introduced by Hack (1976). A number of excellent textbooks
on Petri nets are available. The book by Reisig (2013) focuses on the modelling
aspects of Petri nets, analysis techniques, and practical applications. Coloured
Petri nets are at the centre of the book by Jensen and Kristensen (2009).
5
Business Process Models

Arguably, business process modelling is the most widely used form of modelling
effort in today’s organisations. The key role of business process models is to
capture the essence of how work is organised and conducted in business and
administrative organisations. From a formal perspective, a business process
model represents the behaviour that an organisation can perform. These models
are used as blueprints for designing working procedures for human workers.
They are also crucial in the development of software systems that support
business processes, completely or in part. This chapter takes two perspectives
on the modelling of business processes by looking at workflow control flow
patterns and an industry-standard business process modelling language.
Workflow patterns were introduced to provide a language-independent char-
acterisation of several different aspects of business process models, including
data, resources, exceptions, and control flow structures. Since the behaviour
of systems is the central theme of this book, we shall cover only control
flow patterns. These patterns represent recurring control flow structures that
are found in business process models and in languages designed to express
these models. Section 5.1 introduces the most important control flow patterns.
Coloured Petri nets are used to specify their behavioural semantics.
In Section 5.2, some key concepts in business process modelling are intro-
duced, before the most important elements of the industry-standard Business
Process Model and Notation, BPMN, are covered. We start by looking at busi-
ness process diagrams, and discuss their elements and the execution semantics
of these elements. Business process diagrams concentrate on single organisations
and their processes. Since concurrency can be found when business processes
interact, this section also covers collaboration diagrams. Finally, a mapping
from business process diagrams to Petri nets will be introduced, which serves
as a basis for a formal analysis of business process models.

© Springer International Publishing Switzerland 2016 125

M. Kunze and M. Weske, Behavioural Models,
DOI 10.1007/978-3-319-44960-9_5
126 5 Business Process Models

5.1 Workflow Patterns

Workflow control flow patterns were introduced to represent the complete
collection of the control flow structures that we can think of. Therefore, the
primary goal of workflow patterns is not to list the patterns that are most
frequently found in business processes and in languages to express them.
To provide a solid basis for a discussion of the behavioural aspects of
business process models, this section introduces the most important control
flow patterns. The selection was inspired by studies of the control flow structures
most frequently used in practice, as will be detailed in the bibliographical
notes in this chapter.
In the remainder of the section, the most important workflow control
patterns are presented using coloured Petri nets. Regarding the labels of places
in the nets used in this chapter, we stipulate that initial places carry labels
i1 , i2 , . . . , internal places p1 , p2 , . . . , and final places o1 , o2 , . . . . All places have
the same colour set c: integer, i.e., all tokens have the same structure and
carry a case identifier as a data attribute. The arc expressions ensure that the
case identifier is propagated throughout all places of the coloured Petri net.
This can be seen below in Fig. 5.1.

5.1.1 Sequence Pattern

The most basic control flow construct is the sequence pattern. Two activities
A and B need to be executed in a sequence A, B if B is causally dependent
on A. We have already used this pattern throughout this book. In business
processes, the sequence pattern is abundant. The following list shows examples
of sequences of activities A, B.
• A ticket can only be issued (activity B) after the ticket has been paid for
(A).
• A credit request can only be processed (B) after the request has been
received (A).
• A document can only be sent (B) after it has been written (A).
These examples show causality between activities A and B. In general,
causality does not imply a direct sequence of execution; instead, there can be
several consecutive sequence patterns.

F F F F
$ %
L S R

Fig. 5.1: Sequence pattern expressed as a coloured Petri net

The sequence pattern is shown in Fig. 5.1 as a coloured Petri net. The
firing of the transition A puts a token on the place p1 , which enables B. Hence,
the transition B can only fire after A has fired, realising the sequence pattern.
 5.1 Workflow Patterns 127

5.1.2 Parallel Split Pattern

The parallel split pattern facilitates the concurrent execution of activities in

process models. The behavioural semantics of this pattern is defined by the
coloured Petri net shown in Fig. 5.2. The firing of the transition A puts one
token on the place p1 and one token on the place p2 . Thereby, the transitions
B and C are enabled. In this state, B and C can fire independently of each
other, resulting in their concurrent execution. The parallel split pattern is also
known as the and split.

F F
%
F S R
F
$
L
F F F
&
S R

Fig. 5.2: Parallel split pattern expressed as a coloured Petri net

Whenever activities are independent of each other, they can be executed

concurrently. The following examples show situations in which an activity A
is followed by the concurrent execution of activities B and C.

• After a credit request has been received (activity A), the legal status of
the applicant can be checked (B) concurrently with checking his or her
financial situation (C).
• After receiving an order, an online store might choose to start packaging
the ordered goods (B) while processing the credit card transaction (C).
• After accepting an offer to organise a workshop (A), we can select a venue
(B) while inviting the keynote speakers at the workshop.
The name of this pattern might be misleading, since the pattern does not
enforce parallel execution in the sense that activities are executed at the same
time, parallel in time. Rather, the word “parallel” represents the concurrent
execution of activities, which was discussed in Chapter 4.

5.1.3 Synchronisation Merge Pattern

The synchronisation merge pattern is used to wait for the completion of

concurrent execution branches. This pattern complements the parallel split
pattern, which is used to create concurrent execution branches. A Petri net
representation of the execution semantics of the synchronisation merge pattern
is shown in Fig. 5.3. The synchronising transition C can only fire, if there is a
token on p1 and a token on p2 ; this results in the synchronisation of concurrent
128 5 Business Process Models
F F
$ F
L S
F
&
R
F F
% F
L S

Fig. 5.3: Synchronisation merge pattern expressed as a coloured Petri net

execution branches. The synchronisation merge pattern is also known as the

and join and can be used in an analogous way to synchronise many paths.
The examples introduced in the context of the parallel split pattern can be
extended to illustrate the synchronisation merge pattern.
• A decision on a credit request (C) can only be made after both the legal
status (activity A) and the financial situation of the applicant (B) have
been checked.
• A parcel can only be sent (C) after the ordered goods have been packaged
(A) and the credit card transaction has been processed (B).
• We can start the marketing activities for our workshop (C) only after we
have selected a venue (A) and invited the keynote speakers (B).

F F
$ F
L S
F
&
R
F F
% F
L S

Fig. 5.4: Synchronisation merge pattern with tokens representing different

process instances, i.e., different cases

Using coloured Petri nets allows the processing of several process instances
using a single net. To illustrate this observation, we consider a situation in
which there are tokens for several process instances in the coloured Petri net
shown in Fig. 5.4. These tokens have different case identifiers. In the figure,
tokens with different case identifiers are visualised using different colours. The
process instance with the identifier c = 1 (light grey) is already completed, as
represented by the token on the final place.
Cases 2 (grey) and 3 (black) are still active. The transition C is enabled for
the binding b(c) = 3, because there is one token for case 3 on both of its input
places. In contrast, C is not enabled for the binding b (c) = 2, since there is no
token satisfying this binding on p2 . When C fires under the binding b(c) = 3,
 5.1 Workflow Patterns 129

the tokens with value 3 are removed from p1 and p2 , and a token with value 3
is put on o1 , completing this process instance.

5.1.4 Exclusive Choice Pattern

Decisions in processes can be represented by the exclusive choice pattern. To be

precise, it is not the decision itself that can be represented but its outcome in
the process. For instance, after a credit request has been decided on, either an
activity to grant the request or an activity to notify the client about rejection
of the request is executed. It is important that the decision is taken by the
process, based on data that is available to that process.
A Petri net representation defining the execution semantics of the exclusive
choice pattern is shown in Fig. 5.5, using arc expressions. Upon firing of the
transition A, a condition cond is evaluated. If that condition evaluates to true,
a token is put on p1 and no token is put on p2 , whereas no token is put on p1
and one token is put on p2 if cond evaluates to false.
The modeller has to make sure that the conditions of several choices
are logically disjoint and cover all situations that might arise at this point.
Otherwise, it is possible that several branches might be enabled or the net
might become stuck, as no condition evaluates to true and produces a token
on the output place of the exclusive choice transition. The exclusive choice
pattern is also known as the exclusive-or split.

F F
LIFRQGWKHQF %
HOVHHPSW\
S R
F
$
L
LIFRQGWKHQHPSW\ F F
&
HOVHF
S R

Fig. 5.5: Exclusive choice pattern expressed as a coloured Petri net

Exclusive choices are very frequent in business process models, as illustrated

in the following situations.
• If a credit card transaction completes successfully (A), the ordered goods
are shipped to the customer (B). Otherwise, a notice to pay the amount,
payable by money transfer, is sent to the customer (C).
• If we decide to hire a job applicant (A), we send a welcome message to
him or her (B). Otherwise, a rejection message is sent (C).
• If we are unable to finish the draft of a textbook on time (A), we send a
message to the publisher asking for an extension. Otherwise, we send the
manuscript (C).
130 5 Business Process Models

5.1.5 Simple Merge Pattern

The simple merge pattern is used to combine multiple alternative flows in a
process. Therefore, it can be considered as complementary to the exclusive
choice pattern. A Petri net representation defining the simple merge pattern is
shown in Fig. 5.6. The alternative branches are completed by the transitions
A and B. When either of these transitions fires, a token is put on p1 , which
realises the merge by enabling the transition C. In this example only A can
fire, because B is not enabled. The simple merge pattern is also known as the
exclusive-or join.

F
$
F
L
F F
&
S R
F F
%
L

Fig. 5.6: Simple merge pattern expressed as a coloured Petri net

In business process models, alternative execution branches are often com-

bined using the simple merge pattern. The following examples provide further
illustrations of this control flow pattern.
• After the amount payable has been paid by a credit card transaction (A)
or by money transfer (B), the ordered goods are sent to the customer (C).
• After a welcome message has been sent to a new staff member (A) or a
rejection message has been sent to an applicant (B), the application is
archived (C).
But there are also situations in which the state of the process is different
after completion of an alternative execution branch. In the example of the
completion of a textbook mentioned in subsection 5.1.4, it would not make
sense to merge the execution branches after asking for an extension or sending
the manuscript, because the situations are quite different. After asking for an
extension, we wait for an acknowledgement while concurrently continuing the
writing of the book. After submitting the draft, we need to wait for feedback
from the publisher.
In business process modelling, it is good style to mark different outcomes
of a process by different final places, so that merging alternative branches is
not always appropriate.

5.1.6 Multi-Choice Pattern

The multi-choice pattern is a generalisation of the exclusive choice pattern.
While the structures of these patterns are identical, the multi-choice pattern
 5.1 Workflow Patterns 131

allows different conditions on each of the arc expressions originating from the
transition A, as shown in Fig. 5.7. This means that any subset of the places in
the postset of A can receive a token. It is the responsibility of the modeller to
ensure that not all subsets are the empty set, i.e., for each process instance, at
least one branch is chosen. The multi-choice pattern also subsumes the parallel
split pattern, since all of the conditions of the former might evaluate to true.
The multi-choice pattern is also known as the inclusive-or split.

F F
LIFRQGWKHQF %
HOVHHPSW\
S R
F
$
L
LIFRQGWKHQF F F
&
HOVHHPSW\
S R

Fig. 5.7: Multi-choice pattern expressed as a coloured Petri net

The following examples illustrate the use of the multi-choice pattern.

• After deciding to go on a business trip (A), we can book a train ticket (B)
and a hotel room (C), or either of them. If the destination is close, we
might not need hotel accommodation, or we might decide to go by car,
so that no train ticket has to be booked. Notice that at least one of the
alternatives needs to be chosen, so that not using a car and not booking a
hotel room is not allowed by that process model.
• After receiving an insurance claim (A), we can choose to check the contract
details of the client (B) and, optionally, to invite an external reviewer
to provide an evaluation (C). This situation can be represented by the
multi-choice pattern, even though A is performed in any case and B is
optional.
• When renting a car (A), we can order additionally a satellite navigation
system (B), and we can order extra insurance coverage to reduce liability
in the case of an accident (C). The two choices can be made independently
of each other, and this can be represented by the multi-choice pattern.

5.1.7 Structured Synchronising Merge Pattern

The multi-choice pattern provides a very flexible way of representing choices

in process models. However, although the split behaviour can be represented
very well using coloured Petri nets, the merge behaviour is complex. From a
set of incoming branches, it needs to synchronise those which might provide a
token at some point. We cannot use the synchronisation merge, as this waits
for all incoming branches. We cannot use the simple merge pattern either, as
this waits only for one incoming branch.
132 5 Business Process Models

Instead, we use the structured synchronisation merge, which must wait

for a subset of the incoming branches. This is known as the inclusive-or join
problem. The problem is due to the fact that the join node cannot know which
of the input edges to wait for. In the general case, the or join is unable to decide
on its firing based on local information, i.e., the signalling of its incoming
branches.
Fortunately, there is an elegant solution to the inclusive-or join problem,
if the or split and the or join are well structured. By “well structured” we
mean that any path originating from the or split will eventually lead to a
corresponding or join. The semantics of this control flow pattern is illustrated
in the coloured Petri net shown in Fig. 5.8. Notice that the transition A
represents the inclusive or split, which has three behavioural options: either B
is enabled by putting a token on the place p1 , C is enabled by putting a token
on p2 , or B and C are enabled by putting a token on p1 and p2 .

LIFRQGWKHQHPSW\HOVHF

S S
F F F F
% '
S F
LIFRQGWKHQF
HOVHHPSW\ R
F F
$ (
L LIFRQGWKHQF
HOVHHPSW\
S F
F F
&
S

LIFRQGWKHQHPSW\HOVHF

Fig. 5.8: Structured synchronisation merge pattern expressed as a coloured

Petri net

The structured synchronisation merge is realised by the transition E. Re-

gardless of the decision taken by the or split transition A, there will eventually
be one token on p4 and one token on p5 . This is achieved by the arc expressions
on the edges that originate from the or split transition A. If cond 1 evaluates to
true and the transition B becomes enabled, then the firing of D puts a token
on p5 . In contrast, A puts a token on p5 if cond 1 does not evaluate to true.
Analogous considerations hold for the condition cond 2 .
This approach is also known as false token passing. By false token passing,
we mean the putting of tokens on p4 and p5 by A. These are considered as “false”
tokens, because the respective path has been bypassed and the transitions on
that path have not been executed. However, these tokens do not differ from
other tokens in the net, as they comply with the same colour set.
 5.1 Workflow Patterns 133

This pattern covers only the structured case; for the general case of deciding
the inclusive-or join, the reader is referred to the bibliographical notes at the
end of this chapter.

5.1.8 Structured Discriminator Pattern

The structured discriminator pattern realises a particular join semantics. It

can be used when multiple concurrent branches need to be joined, but the
subsequent activity needs to be started after the first incoming branch has
been signalled. The discriminator can be reset only after all incoming branches
have been signalled.

F
$
L F
F
$ F S
F F
L %
 F R
P āF F
F
F F S
$P UHV
F
LP S

Fig. 5.9: Structured discriminator pattern expressed as a coloured Petri net

The semantics of the structured discriminator pattern is shown in Fig. 5.9.

The transitions A1 tto Am represent the concurrent paths that will be joined
by the discriminator; the token on p2 indicates that the discriminator can start
its operation.
When the first A-transition fires, a token is put on p1 , which enables the
transition B. When B fires, one token is put on the final place, o1 , and one
token is put on p3 . The discriminator now has to wait for the remaining
A-transitions. As the m − 1 remaining A-transitions fire, the respective tokens
are put on p1 . Notice that B is not enabled, since there is no token on p2 .
B can be enabled again only after the discriminator has been reset, which is
described next.
A token can be put on p2 only by the reset transition res. As represented
by the arc expression, this transition can be enabled only if p1 contains m − 1
tokens. This is realised by the arc expression (m − 1) · c, which denotes that
the firing of res consumes m − 1 tokens. Since B has already fired, the reset
transition is enabled and can fire, putting a token on p2 . Now, the discriminator
is reset and can begin operation again from the beginning.
The following examples illustrate the semantics of this control flow pattern
for incoming branches A1 , A2 , A3 of a discriminator and a subsequent activity
B.
134 5 Business Process Models

• We ask three managers to allocate resources for a business trip (activities

A1 , A2 , A3 ) and we can proceed after one of them has done so (B).
• We ask three flight services to reserve a flight (A1 , A2 , A3 ), and we can
proceed by booking the flight (B) as soon as one of them has done so. The
other reservations are collected, but we do not react to them.
• We ask three hardware vendors for quotes for a laptop computer and collect
their responses (A1 , A2 , A3 ). Once we have received the first response, we
accept it and continue by placing an order (B).
Notice that the semantics of the discriminator is not perfectly represented
by the coloured Petri net. As discussed already, B is enabled when the first A
fires and puts a token on the place p1 . However, according to the Petri net
firing semantics, B does not need to fire immediately at this point in time: B
could wait until more A’s have fired. This would violate the semantics of the
structured discriminator pattern, since B should fire immediately after the
first A has fired. A greedy firing behaviour of B would fix this problem, in
which case B fires immediately after an A puts a token on p1 .
The Petri net representation of the structured discriminator pattern is
based on an additional assumption, which is related to the processing of
loops. It is assumed that iterations of a given loop do not overtake each other.
Otherwise, iterations could interfere with each other, resulting in misbehaved
execution of the structured discriminator pattern.

5.1.9 Multiple-Instances Patterns

There are several patterns that relate to multiple instances of a given activity
in a process model. These patterns differ with respect to the synchronisation
of all instances after completion and with respect to the point in time at which
the number of instances is determined.
Consider a process with activities A, B, and C, which are executed se-
quentially. For each case there is one instance of A and one instance of C, but
several instances of activity B. This situation can be encountered, for instance,
in a procurement scenario, where an order consists of a number of line items,
and where each line item represents a product ordered. After the order has
been accepted (one instance of A), we check the availability of each line item
(several instances of B, one for each product ordered), before packaging the
goods (one instance of C).
The synchronisation here refers to the fact that C synchronises all instances
of the multiple-instance activity B. In this example, the synchronisation is
required because the goods cannot be packaged before the availability of
each product has been checked. The absence of synchronisation of multiple
instances would allow C to start before the termination of the multiple instances
activities, which occurs rarely in practice.
Regarding the point in time when the number of instances is determined,
there are three alternatives.
 5.1 Workflow Patterns 135

• Multiple instances with a priori design time knowledge. The number of

instances is determined at design time, i.e., when the process is modelled.
When a bike is being assembled, for instance, the activity get wheel always
needs to be executed exactly two times, so we know the number of instances
of that activity at design time.
• Multiple instances with a priori run time knowledge. There are cases in
which the number of instances is known only during process execution. In
the first variant of this pattern, the number of instances is known before the
multiple-instances activity starts. Therefore, the term run time refers to
the run time of the multiple-instances activity. The procurement example
can be represented by this pattern, because we know only during process
execution how many different products have been ordered. But this number
is determined before the multiple-instances activity starts.
• Multiple instances without a priori run time knowledge. In some scenarios,
the number of instances required can only be determined while the multiple-
instances activity is being executed. Therefore, we do not have a priori
run time knowledge. This situation is dealt with by dynamically adding
new instances of the activity during the execution of the multiple-instances
activity. An example of this pattern is a reviewing process, where additional
experts can be asked for a review in the case of conflicting reviews.

F QāF F F QāF F
$ % &
L S S R

Fig. 5.10: Pattern of multiple instances with a priori design time knowledge
expressed as a coloured Petri net

The semantics of the first multiple-instances pattern – a priori design time

knowledge – is shown in Fig. 5.10. Its representation in a coloured Petri net is
very simple. The transition A puts n tokens on the place p1 , where n represents
the number of instances of B. Again, this is realised by an arc expression that
states that n tokens with value c are produced when A fires. Consequently, the
multiple-instances activity B can fire n times, which represents the n instances
of that activity. The multiple instances of B are synchronised because the
subsequent activity C is enabled only when n tokens reside on p2 , which means
that all instances of B have to complete before C can start.

5.1.10 Deferred Choice Pattern

Earlier in this chapter we discussed the exclusive choice pattern, in which a

decision was taken on how to continue a process. This decision was based on
a condition that was evaluated during process execution. For instance, if the
risk of granting credit is regarded as low, then credit can be granted.
136 5 Business Process Models

The deferred choice pattern also takes a decision on how to continue a

process given several alternatives. However, there is a significant difference
between these patterns. While the exclusive choice pattern allows the process
to take the decision by evaluating a condition, the deferred choice pattern
allows several things to happen, and the environment – rather than the process –
decides on the alternative chosen.
In fact, the deferred choice pattern occurs quite frequently in business
processes. For instance, consider a credit request process in which a bank
requires additional information from a client. After sending the request, the
bank makes a deferred choice: either the client responds within a defined time
span, for instance, one week, or a reminder is sent. The key point here is that
the decision is not taken by the bank, but by the environment. In this case,
the decision is taken by the client, who does or does not decide to send the
material within the time span that has been communicated to him or her.
In Section 5.2, we study the deferred choice pattern using a dedicated
business process language.

F
%
F R
F F
$
L S
F F
&
R

Fig. 5.11: Deferred choice pattern expressed as a coloured Petri net

The execution semantics of the deferred choice pattern is shown in Fig. 5.11.
After A has been executed, a token is put on p1 , which enables both B and
C. In this state, either of transitions B and C can fire, i.e., either event can
happen. In the credit request example, A refers to the sending of the request
from the bank to the client, B refers to receiving the response, and C represents
a time-out event, which occurs after the defined time span has expired. Note
that the two transitions are in conflict: if one transition fires, its consumption
of the token on p1 disables the other transition.

5.1.11 Cancel Case Pattern

The cancel case pattern is used to stop the execution of a process in any
state that the process can be in. Cancelling a case is conceptually challenging,
because the process can be in any state when cancellation occurs. To realise
this pattern in a traditional Petri net without reset arcs or inhibitor arcs,
one dedicated transition is required for each state the process can be in that
removes tokens from the respective places. For instance, a transition t might
 5.2 Introduction to Business Process Modelling 137

be responsible for cancelling the process in the state [p1 , p3 , p4 ], if that state
can be reached by the process.
Since the resulting Petri net would be very complex, we use a coloured
Petri net with reset arcs and inhibitor arcs (see subsection 4.3.3), to represent
the cancel case pattern, as shown in Fig. 5.12. First of all, one token is put
on each of the places p1 and p2 , where the token on p1 is used to start the
case. The place p2 is used to indicate that the process is active. Notice that
the case cannot be cancelled in the state [p1 , p2 ], because of the token on p1 ,
which inhibits firing of the Cancel case transition.
When the case starts, the token on p1 is removed by firing the first transition
T of the case. During the case’s execution, it can be cancelled by firing the
transition Cancel case. When this happens, all tokens in the case are removed,
as defined by the cancel region of the reset arc. Also, the token on p2 is
consumed. When the Cancel case transition fires, the process reaches the final
state [o].

S F
F F

F 6WDUW F (QG F
FDVH FDVH
L S S R
&DQFHO
F F FDVH F F

7  7
F F

Fig. 5.12: Cancel case pattern expressed as a coloured Petri net

If the case is not cancelled and terminates normally, a token is put on the
place p3 . Thereby, the Cancel case transition becomes inhibited and cannot fire.
This is important, since cancelling a completed case needs to be prevented. The
complete process ends with firing of the End case transition, which removes
tokens from p2 and p3 , reaching the final state.

5.2 Introduction to Business Process Modelling

From a business perspective, organisations create value by performing work.
When one is analysing how work is performed in organisations, the individual
activities have to be investigated, as well as their logical ordering. Business
process models capture activities performed in organisations and causality
between activities.
138 5 Business Process Models

A business process consists of a set of activities that are performed in

coordination in an organisational and technical environment. These
activities jointly realise a business goal. Each business process is enacted
by a single organisation, but it may interact with business processes
performed by other organisations.
We shall use a simple business process diagram to discuss the essential aspects of
business process modelling, before providing further details of business process
diagrams. Figure 5.13 shows a simple business process diagram involving the
processing of an insurance claim. We see a set of activities with a causal
ordering between them.

&ODLP
$SSURYHG
DSSURYH 3UHSDUH
OHWWHURI
DSSURYDO
'HFLGHRQ
5HJLVWHU FODLP
FODLP FRYHUDJH
&ODLP 3UHSDUH
5HFHLYHG OHWWHURI
UHMHFW UHMHFWLRQ
&ODLP
5HMHFWHG

Fig. 5.13: Simple business process diagram involving an insurance claim

The process starts with receiving a claim. This is represented by the start
event in the business process diagram. Whenever such an event occurs, i.e.,
whenever a claim is received, a new process instance is created. The first
activity to be executed is registering the claim, followed by an activity to
decide on the coverage of the claim. The process diagram shows that the
process can continue in two different ways. The actual alternative chosen
depends on the decision taken. In this example, either a letter of approval is
prepared or a letter of rejection is prepared. The process has two alternative
end events, representing its two possible outcomes.
Since business process diagrams represent activities that are performed and
events that occur, as well as causal relationships between them, business process
diagrams are behavioural models. The originals represented by business process
diagrams are concrete instances of processes performed by organisations, such
as the processing of a particular insurance claim: for instance, a claim for the
theft of a road bike of type Complexon Bravo belonging to a client Martin
Wilder with identification number 1123221 on 19 February 2015.

5.2.1 Relation to Stachowiak’s Characteristics of a Model

We shall use this example to argue that business process diagrams satisfy the
model characteristics introduced by Stachowiak.
 5.2 Introduction to Business Process Modelling 139

The mapping property of Stachowiak’s characteristics states that elements

of originals are mapped to elements of models. In this case, some particular
activities that are performed during the business of organisations are mapped to
activities in process models. The causal ordering between activities is mapped
to arcs in process models indicating execution ordering. Alternative paths that
can be taken during process executions are represented by gateways, such as
the one shown in Fig. 5.13.
Abstraction in business process models has two main aspects. The first
one relates to the properties of the originals, i.e., the properties of process
instances that are performed in the daily business of companies and other
organisations. We do not want to represent all such properties in business
process models. Instead, we are interested in representing only those properties
of the originals that are relevant for a particular modelling goal. These include
activities, events, gateways that capture decisions, sequence flow, data objects,
and, as will be discussed below, concurrency.
The second aspect of abstraction relates to classification. Rather than
having a process model for each original, i.e., for each process instance, similar
process instances are classified and represented by one model. For instance, in
the insurance claim example, instances of the insurance claim process, i.e., all
cases, are represented by one process model.
To capture different variations of process instances, for example acceptance
and rejection of claims, different execution alternatives have to be represented
in models. Owing to this aspect of abstraction, process models need to capture
the behaviour of different instances. In this context, an interesting question
emerges: Which process instances should be represented by one process model?
There is no formal or automatic way of answering this question; rather, it is
the responsibility of the human modeller.
The pragmatics of a model require that the model can substitute for the
original for some modelling purpose. Business process instances are hard to
grasp and hard to capture. This is due to their intangibility. Many activities
are performed by many people in organisations. Sometimes it is hard to
understand which activities actually belong to the same process and what the
causal relationships between these activities actually are.
When we want to analyse or improve a business process, for instance to
reduce the processing time of insurance claims, a representation of the process
is required, which will serve as a basis for arguing, reasoning, and agreement.
This basis is a process model. We can discuss alternative process designs by
adding or deleting activities, by assigning new responsibilities, or by altering
decisions. The business process model is changed until the stakeholders agree
on the improved process model. In the next step, the implementation of the
modified process starts. This discussion shows that business process models do
in fact substitute for the originals, so that the pragmatics aspect is satisfied
by business process models as well.
140 5 Business Process Models

5.2.2 Process Activity Lifecycle

Business process activities are performed during process executions. Different

states occur, from the creation of an activity until the activity is terminated. To
capture these states properly, state transition diagrams are used. Figure 5.14
shows a state transition diagram that captures the states and state transitions
of activities.

initialize enable begin terminate

not started closed

init ready running terminated

skipped

skip

Fig. 5.14: State transition diagram of activity instances

When an activity is created, it enters the state init. In this state, the
activity is not yet ready for execution. By means of the enable state transition,
the activity enters the state ready. Activities that are in this state can enter
the state running by means of the begin state transition. Finally, there is a
state transition from running to terminated, indicating the completion of the
process.
We shall use the insurance claim example shown in Fig. 5.13 to illustrate
the states and state transitions of activities. When a claim is received, activi-
ties for the corresponding process instance are created and initialised. Since,
immediately after receiving the claim, only the Register claim activity can
be executed, only this activity is in the state ready. Maintaining the state of
activities is important, since users can only select activities to be started which
are ready.
If a particular activity is not required in a process instance, then the activity
can be skipped. This is represented by a skip state transition from the not
started complex state to skipped. When an activity is terminated or skipped, it
is closed.
The skipping of activities happens in the sample process, if the claim is
accepted and a letter of approval is prepared. In this situation, no letter of
rejection has to be prepared. Consequently, the respective activity enters the
state skipped and, thereby, is closed.
State transition diagrams are useful for capturing the behaviour of indi-
vidual activities in a business process. To capture the behaviour of complete
 5.3 Business Process Model and Notation 141

business processes, a mapping from business process diagrams to Petri nets is

required, and this will be introduced. Before doing so, however, we will discuss
business process diagrams and their model elements in more detail.

5.3 Business Process Model and Notation

This section sketches the Business Process Model and Notation, or BPMN.
BPMN has been the industry standard in business process modelling for
several years. This language provides a rich set of language elements, but many
business processes can be captured by using just a few of them.
Rather than introducing the complete set of language elements, this section
focuses on the most important ones, such as activities, events, gateways, and
sequence flow. We concentrate on the sequential and concurrent behaviour
that can be specified in business process diagrams. After introducing the basic
concepts of the language, we define the behaviour of business process diagrams
by providing a mapping to Petri nets.

5.3.1 Activities and Events

Activities are, arguably, the most important elements in business processes.

Above, we have discussed the states and state transitions that activities go
through during their execution. Since the behaviour of business process models
expressed in BPMN can be precisely specified by Petri nets, this section looks
at different ways to define the behaviour of activities using Petri nets.
To illustrate these different ways to define the behaviour of activities, we
consider a simple business process model consisting of two activities, namely
one start event and one end event only; this is shown in Fig. 5.15. The process
starts with receiving a paper to be reviewed (event Pr), followed by preparing
the review (PR) and sending the review (SR), before the termination of the
process is signalled by the end event Rs.

3UHSDUH 6HQG
5HYLHZ 5HYLHZ
35 65
3DSHU 5HYLHZ
5HFHLYHG 3U 6HQW 5V

Fig. 5.15: BPMN business process diagram of a simple reviewing process

When the execution of this process is investigated in detail, we see that the
first thing that happens is the receipt of the paper, which is represented by
the start event Paper received. When this event happens, the Prepare review
activity enters the state ready, as depicted in Fig. 5.14. We can map this
behaviour to a Petri net as follows.
142 5 Business Process Models

The start event of a business process is represented by a place. As long as

the start event has not occurred, there is no token on that place. When the
start event occurs, a token is put on that place. This means that we can map
start events in business process models to places in Petri nets, such that the
occurrence of an event is represented by a token on the respective place, as
shown in Fig. 5.16.

3DSHU
5HFHLYHG 3U 3U 3U
(a) BPMN start (b) Event has not (c) Event has (just)
event occurred occurred

Fig. 5.16: Mapping of a start event to a Petri net

There is an alternative way of representing start events in Petri nets. A

start event can also be mapped to a transition with a single input place. A
token on that input place represents that fact that the start event is ready to
happen but has not happened yet. The difference from the first mapping, of a
start event to a place, is the occurrence of the event.
In the first mapping, the process cannot influence the occurrence of the
start event. Whenever a token is put on the place that represents the start
event, the event has occurred. In the second mapping, once there is a token
on the place, the process can decide when the start event will occur. This is a
subtle difference in the semantics. Both alternatives are valid mappings from
start events to Petri nets. In the remainder of this chapter, the first mapping
alternative is used.
Since the more advanced constructs of BPMN are not covered in this section,
the expressive power of coloured Petri nets will not be required. Therefore,
place transition nets will suffice to represent BPMN process models properly.
The states that each activity goes through need to be represented in the
corresponding Petri net. In order to illustrate this approach, we consider
Fig. 5.17. Each activity is mapped to a Petri net, which consists of places
that represent the states ready, running, and terminated, respectively. The
transitions of the Petri net represent the state transitions for the beginning
(b) and termination (t) of the activity.
When a token is put on the ready place, the process activity enters the
state ready. This is represented properly by the firing rule of the Petri net: the
beginning transition can fire, since there is a token on all places in its input
set. When the beginning transition fires, a token is removed from the ready
place and put on the running place. This token remains on the running place,
representing the execution of the activity; it is in the state running. When
the termination transition fires, the token is removed from the running place
 5.3 Business Process Model and Notation 143

and a token is put on the terminated place. Thereby, the activity lifecycle
introduced in Fig. 5.14 is mapped to a Petri net, abstracting away skipping of
process activities.

3UHSDUH 35E 35W

5HYLHZ
35 35UHDG\ 35UXQQLQJ 35WHUPLQDWHG

(a) BPMN (b) Petri net

activity

Fig. 5.17: Mapping of a process activity to a Petri net, taking into account the
activity lifecycle

To map the business process shown in Fig. 5.15 to a Petri net, events and
activities have to be mapped accordingly. In the case of sequential activities,
the terminated place of the first activity can be merged with the ready place
of the second one.
To illustrate this merging of places, consider activities A and B that are
executed sequentially. The terminated place of activity A can be merged with
the ready place of activity B. This captures the semantics of BPMN, since,
after A terminates, B immediately enters the state ready. Along the same lines,
the place representing a start event can be merged with the ready place of
the first activity, and the termination place of the last activity can be merged
with the place representing the end event.

35E 35W 65E 65W

3U 35UXQQLQJ 35WHUPLQDWHG 65UXQQLQJ 65WHUPLQDWHG
35UHDG\ 65UHDG\ 5V

Fig. 5.18: Mapping of process model shown in Fig. 5.15 to a Petri net, taking
into account the activity lifecycle

Figure 5.18 shows the corresponding Petri net. For illustration purposes, we
have marked merged places with the labels of both of the original places. Since
the labelling of places is not relevant for the execution semantics of Petri nets,
we will drop the labels of places where appropriate. The corresponding Petri
net, alongside the mapped business process diagram, is shown in Fig. 5.19.
The mapping from activities to Petri nets discussed so far takes the activity
lifecycle into account. However, for some tasks of process model analysis, such
as checking soundness, the different states of process activities are not relevant.
Therefore, a simplified mapping from process activities to Petri nets is now
introduced, which abstracts away the running state of activities.
144 5 Business Process Models

3UHSDUH 6HQG
5HYLHZ 5HYLHZ
35 65
3DSHU 5HYLHZ
5HFHLYHG 3U 6HQW 5V

(a) BPMN process model

35E 35W 65E 65W

(b) Petri net

Fig. 5.19: Business process model and corresponding Petri net

When we do so, each process activity can be represented by a single

transition with one input place and one output place. A token on the input
place indicates that the activity is in the state ready, and the execution of the
activity is represented by the firing of the transition. Thereby, we abstract
away the execution time of the activity, and the running state as well. After
firing of the transition, a token is put on the output place of the transition,
representing the termination of the process activity. The mapping and the
Petri net resulting from this mapping are shown in Fig. 5.20. Figure 5.21 shows
the corresponding Petri net for the process diagram depicted in Fig. 5.15.

3UHSDUH
5HYLHZ
35 35

(a) BPMN (b) Petri net

activity

Fig. 5.20: Mapping from a process activity to a Petri net that abstracts away
the running state

35 65

Fig. 5.21: Petri net corresponding to the business process model shown in
Fig. 5.15 with abstraction of the running state

5.3.2 Capturing Sequential Behaviour

BPMN business process diagrams are the state-of-the-art technique for mod-
elling business processes. BPMN is a rich language that provides many elements
 5.3 Business Process Model and Notation 145

with well-described semantics. This section does not aim at providing the com-
plete syntax and semantics of BPMN. Rather we concentrate on the most
important language elements. Examples will be used to illustrate the language
elements and their semantics.
Figure 5.22 shows a business process model expressed as a BPMN business
process diagram. The model represents the activities that are performed and
their logical ordering during a typical reviewing process in academia.

$FFHSW *HW3DSHU 3UHSDUH 6HQG

5HYLHZLQJ *3 5HYLHZ 5HYLHZ
\HV

$5 35 65
'HFLGHRQ 5HYLHZ
5HYLHZLQJ 6HQW 5V
'5
5HYLHZLQJ 6HQG
QR

5HTXHVW &DQFHO
5HFHLYHG 5U ODWLRQ 6&
&DQFHOODWLRQ
6HQW &V

Fig. 5.22: BPMN business process diagram of a reviewing process

The process starts when a reviewing request is received, which is represented

by a start event with a message marker and an appropriate label in the business
process diagram. In BPMN, a real-world happening that is relevant to a business
process is represented by an event. Events do not consume time. Start events
do not have any incoming edges; when a start event occurs, a new process
instance is created.
After receiving the request, we have to decide whether or not we intend to
perform the review. This is represented by an activity in the process model.
Of course, we can decide whether to perform the review only after receiving
the reviewing request. This causal relationship is captured by the sequence
flow edge between the start event and the activity.
Depending on our decision, there are two possible continuations of the
process. If we intend to perform the review, the process continues with accepting
the review. If not, we send a cancellation message. The implication of the
decision is represented by a gateway with two outgoing flows. Since these
flows have conditions attached, they are known as conditional flows. In this
example, the conditions are represented by yes and no. Depending on the goal
of the process model, which may ranged from comprehension of the process to
automation of it, different expression languages can be used.
Since this book is concerned with the behaviour represented by models,
we abstract away the concrete conditions and allow all behaviours. In the
example two behaviours are possible, i.e., accepting or cancelling the reviewing
invitation. We will return to a formal representation of the behaviour of a
business process model by introducing a mapping to Petri nets. Before doing
so, however, we will investigate more complex process structures.
146 5 Business Process Models
PRUHUHYLHZVOHIW
DOO
UHYLHZV
$FFHSW *HW3DSHU 3UHSDUH 6HQG GRQH
5HYLHZLQJ *3 5HYLHZ 5HYLHZ

\HV
$5 35 65
'HFLGHRQ 5HYLHZ
5HYLHZLQJ 6HQW 5V
'5
5HYLHZLQJ 6HQG
QR
5HTXHVW &DQFHO
5HFHLYHG 5U ODWLRQ 6&
&DQFHOODWLRQ
6HQW &V

Fig. 5.23: Business process diagram of a reviewing process involving multiple

papers to be reviewed

Figure 5.23 shows a variation of the reviewing process involving multiple

papers to be reviewed. The process ends only after all reviews have been
submitted. This behaviour is captured by a loop involving an exclusive-or
gateway that decides whether or not to iterate the loop. This example also
shows that the activity PR has two incoming sequence flows. The semantics of
BPMN states that an activity with multiple incoming sequence flows can be
executed if any one of these sequence flows is signalled.
The process model still captures sequential behaviour. However, the activi-
ties to be executed depend on the number of papers received. Since nothing is
said about the number of papers to be reviewed, the loop can have an arbitrary
number of iterations.
To assign a formal behavioural semantics to the business process diagrams,
we use the mapping of events and activities to Petri nets introduced above.
Before doing so, however, a mapping of data-based exclusive-or splits to Petri
nets has to be provided.
A naive mapping would simply map the exclusive-or split to one place,
which would be the input place of several transitions. As soon as one of them
fires, the token is removed, so that no other transition can fire, realising the
exclusive choice. An example of this naive mapping is shown in Fig. 5.24b for
the process model shown in part Fig. 5.24a.
The naive mapping permits an exclusive choice between the alternatives.
In the example, after deciding on reviewing, either reviewing is accepted or
a cancellation is sent. However, there is a flaw in the naive mapping. This
flaw becomes obvious when the activity lifecycle is considered. In the naive
mapping, after deciding on reviewing, both alternative activities are enabled.
They are enabled at the same time.
However, this is not a correct mapping of an exclusive-or split. This is due
to the fact that the split represents an explicit decision. After that decision,
exactly one of the activities following the split is enabled; the other is not
enabled.
 5.3 Business Process Model and Notation 147

$FFHSW
5HYLHZLQJ
$5
'HFLGHRQ
5HYLHZLQJ
'5
6HQG
&DQFHO
ODWLRQ 6&

(a) Business process model in-

cluding exclusive-or split

$5 $5

'5 '5

6& 6&

(b) Naive mapping to (c) Correct mapping to Petri net

Petri net

Fig. 5.24: Mappings of data-based exclusive-or split to Petri net

A correct mapping of the exclusive-or split to a Petri net is shown in

Fig. 5.24c. We have obtained this by adding transitions that realise the decision.
Since these activities do not correspond to activities in the process model, we
call them τ -transitions. These transitions are represented by black bars. Their
firing semantics is identical to the firing semantics of other transitions that
represent process activities.
After introducing this mapping of the exclusive-or split, we can apply the
mapping to the business process diagram shown in Fig. 5.23. Since we are
interested only in the ordering of activities and not in their internal structuring,
it suffices to use the simplified mapping, which abstracts away the running
state of activities. The result of that mapping is shown in Fig. 5.25. This Petri
net provides a formal semantics of the corresponding business process diagram.
A more complex modelling element of BPMN is used in Fig. 5.26 to express
the receipt of messages during the execution of a subprocess. To keep the
example simple, we consider the reviewing of one paper only. The activities of
getting the paper and of preparing the review are organised into a subprocess.
Subprocesses are activities that have an internal structure. In general, a
subprocess might contain a complex business process model.
Subprocesses also provide a scope in which activities of a business process
are executed. We can attach events to activities in general and to subprocesses
in particular, for instance message events. There are two types of events that
can be attached: interrupting and non-interrupting attached events. If an
interrupting attached event occurs while a subprocess is being executed, a new
148 5 Business Process Models

$5 *3 35 65 65

'5

6&

Fig. 5.25: Petri net representing the behaviour of the business process diagram
shown in Fig. 5.23

$FFHSW *HW3DSHU 3UHSDUH 6HQG

5HYLHZLQJ *3 5HYLHZ 5HYLHZ
\HV

$5 35 65
5HYLHZ
'HFLGHRQ 6HQW 5V
5HYLHZLQJ &DQFHOODWLRQ
'5 5HFHLYHG
5HYLHZLQJ &U
5HTXHVW 6HQG 6HQG
QR

5HFHLYHG 5U &DQFHO $SRORJ\

ODWLRQ 6& 6$
&DQFHOODWLRQ $SRORJ\
6HQW &V 6HQW $V

Fig. 5.26: Business process diagram of a reviewing process involving cancellation

thread is started and the subprocess is interrupted. Non-interrupting attached

events result in concurrent behaviour and will be discussed below.
Interrupting attached events are illustrated by the business process diagram
shown in Fig. 5.26. This diagram shows that a subprocess can be interrupted
upon receiving a message. This is represented in the process model by an
attached event Cancellation Received. When a cancellation message is received
while the subprocess is active, the subprocess is interrupted, i.e., reviewing
does not continue. In this case the process continues with the sending of an
apology. If the event occurs while the subprocess is not active, for instance
before the review is accepted, the event does not have any effect.
Since interrupting attached events require the interruption of running
activities, a mapping to Petri nets has to take into account the lifecycle of
process activities. Therefore, the simple mapping used so far to characterise
the semantics of business process diagrams is no longer sufficient. Instead,
the detailed mapping of activities to Petri nets shown in Fig. 5.18 has to be
used. Since the detailed lifecycle is required only in the subprocess containing
the attached event, we will use the simple mapping in the other parts of the
process model. The resulting Petri net is shown in Fig. 5.27.
 5.3 Business Process Model and Notation 149

$5 *3E *3W 35E 35W 65

'5 W W W W

6&

6$

Fig. 5.27: Petri net defining the execution semantics of the business process
diagram shown in Fig. 5.26

We can study precisely in which states of the business process this can-
cellation is possible. There are four possibilities for cancelling the subprocess,
represented by the transitions t1 to t4 in the Petri net in Fig. 5.27.
The subprocess can be cancelled when reviewing has been accepted. In this
state, the subprocess is enabled, so that the cancellation can be achieved by
firing of t1 . Cancellation can also occur while the Get Paper activity is active.
The removal of the respective token by t2 interrupts that activity and cancels
the subprocess. Cancellation can also occur after getting the paper and before
preparing the review; this is achieved by firing of the transition t3 . Finally, the
subprocess can be cancelled during preparation of the review by t4 .
Notice that the subprocess can no longer be cancelled when the review has
been prepared, because in that state the subprocess has already terminated.

5.3.3 Capturing Concurrent Behaviour

There are several different ways to express concurrency in business process

diagrams. Before we discuss the corresponding gateways and their semantics, we
shall continue with the discussion of attached events. When a non-interrupting
attached event occurs while an activity is being executed, a new thread is
started concurrently with the subprocess.
To illustrate this modelling element, consider Fig. 5.28. During the sub-
process that involves getting the paper and preparing the review, a reminder
can be received. This is a typical situation, where reminders are sent in an
attempt to avoid delays in reviewing processes.
When the reminder is received, it is read, which hopefully leads to faster
reviewing. While the subprocess is active, we can receive multiple reminders.
However, when the subprocess is completed, we can no longer receive reminders.
It is important that the receipt of the reminder does not interrupt the reviewing
process. Non-interrupting attached events are represented by events on the
border of activities by a dashed border.
150 5 Business Process Models

5HDG
5HPLQGHU
55
5HPLQGHU
5HDG 5HUH
5HPLQGHU
5HFHLYHG 5HUF

$FFHSW *HW3DSHU 3UHSDUH 6HQG

5HYLHZLQJ *3 5HYLHZ 5HYLHZ
\HV
$5 35 65
5HYLHZ
'HFLGHRQ 6HQW 5V
5HYLHZLQJ
'5
5HYLHZLQJ
5HTXHVW 6HQG
QR

5HFHLYHG 5U &DQFHO
ODWLRQ 6&
&DQFHOODWLRQ
6HQW &V

Fig. 5.28: Business process diagram of a reviewing process involving reminders

Figure 5.29 shows a Petri net that defines the semantics of the business
process diagram shown in Fig. 5.28. The interesting part of this Petri net is
the representation of the non-interrupting attached event.
We can receive a reminder only during the execution of the subprocess. This
is represented by a place p, which contains a token only when the subprocess is
active. This can be achieved by the transition AR (Accept Reviewing) putting
a token on p on entering the subprocess and by the termination transition of
the Prepare Review activity PRt removing a token from p. As long as there
is a token on p, the transition Rerc (Reminder Received) can fire. Each firing
results in a token on q, which allows the transition to read the reminder (RR)
to fire. This Petri net is shown in Fig. 5.29.

$5 *3E *3W 35E 35W 65

S
'5

T
6& 5HUF 55

Fig. 5.29: Petri net of a business process diagram involving non-interrupting

attached events shown in Fig. 5.28

This Petri net can also be used to argue that the process allows concurrent
activities. If we consider the state of the Petri net shown in Fig. 5.29, we
can see that the Prepare Review activity is currently running: in the Petri
net, the transition to begin the preparation of the review has fired, while the
 5.3 Business Process Model and Notation 151

terminating transition has not fired. At the same time, there are two unread
reminders and one read reminder. This means that, concurrently, additional
reminders can be read and the preparation of the review can terminate.
In fact, three transitions can fire independently of each other, i.e., con-
currently: the transition to terminate the preparation of the review (PRt )
the transition to receive an additional reminder (Rerc), and the transition to
read a reminder (RR). Even after completion of review preparation there is
concurrency in the Petri net, which then involves the transitions RR and SR.
While we can express concurrency by non-interrupting attached events,
this is not the most common way to represent concurrency in business process
models. Typically, parallel gateways are used. An example of a business process
model with parallel gateways is shown in Fig. 5.30.

6HQG 5HFHLYH 6HQG

5HTXHVWWR 5HYLHZ $FFHSWDQFH
5HYLHZHU 1RWLILFDWLRQ

\HV
65 55 6$1
3DSHU
$FFHSWHG
'HFLGHRQ 6HQG 5HFHLYH 'HFLGHRQ 3D
5HYLHZHUV 5HTXHVWWR 5HYLHZ $FFHSWDQFH
'5 5HYLHZHU 55 '$
65
6XEPLWWHG
3DSHU
5HFHLYHG 6U 6HQG 5HFHLYH 6HQG
5HTXHVWWR QR 5HMHFWLRQ
5HYLHZHU 5HYLHZ 1RWLILFDWLRQ
65 55 651
3DSHU
5HMHFWHG
3U

Fig. 5.30: Reviewing process involving parallel gateways

This figure depicts a reviewing process from the point of view of the
programme committee chair, who invites reviews for papers that have been
submitted to a conference. Each paper is reviewed by three reviewers. These
reviews are performed concurrently. When all three reviews have been received,
the programme committee chair decides on acceptance or rejection, based on
the reviews received. (This is a simplification of real-world reviewing processes.)
Discussing the behaviour in more detail, we see that the process starts with
receiving a submitted paper, followed by the selection of three reviewers for
that paper. The parallel split gateway determines that all activities following
that gateway are enabled concurrently. Therefore, the programme committee
chair can choose to send the requests in any order. Notice that any concurrent
execution of these activities is permitted by this process model, provided that
a review can be received only after the respective invitation has been sent.
The parallel join gateway waits for all incoming edges to be signalled, and
only then signals its outgoing edge. In this case, the decision on acceptance
can only be made after all three reviews have been received.
152 5 Business Process Models

65 55 6$1

'5 65 55 '$

65 55 651

Fig. 5.31: Petri net representing the behaviour of the business process diagram
shown in Fig. 5.30

The Petri net representing the behaviour of this business process diagram
is shown in Fig. 5.31. The concurrent execution of inviting the reviewers and
waiting for their reviews is illustrated in this figure. In the state shown, the
request has been sent to reviewer 1, but the review has not been received yet.
The request to reviewer 2 has not been sent, while reviewer 3 has already
submitted their review to the programme committee chair.
The term “parallel gateway” is indeed somewhat misleading. This control
flow structure does not prescribe that the next activities have to be done in
parallel, meaning at the same time. Any concurrent interleaving is permitted.
In the context of BPMN – in fact, in most languages for behavioural modelling –
the word parallel can be translated as concurrent.
BPMN provides an additional way to express concurrency. This is based
on so-called multiple-instances activities. When a multiple-instances activity
is enabled, several instances are started. Depending on the type of multiple-
instances activity – both sequential and parallel types are possible, represented
by different markers – these activities are performed sequentially or concur-
rently.
Figure 5.32 shows a parallel multiple-instances subprocess with the respec-
tive marker. Since sending a request and receiving a review belong together,
these tasks are combined into a subprocess. Assuming that the number of
instances of the multiple-instances subprocess is three, the behaviours repre-
sented by the business process diagrams shown in Fig. 5.30 and Fig. 5.32 are
equivalent. This means that the Petri net shown in Fig. 5.31 represents the
execution semantics of the reviewing process involving this multiple-instances
subprocess as well.

5.3.4 Collaboration Diagrams

The language elements introduced so far and the examples to illustrate these
have centred around individual business processes, i.e., business processes
that are performed by a single organisation. When we investigate the paper-
reviewing process in detail, however, we find activities of sending and receiving
messages. In this section, the communication between business processes will
 5.3 Business Process Model and Notation 153

6HQG
$FFHSWDQFH

\HV
1RWLILFDWLRQ
3DSHU
$FFHSWHG
'HFLGHRQ 6HQG 5HFHLYH 'HFLGHRQ
5HYLHZHUV 5HTXHVWWR 5HYLHZ $FFHSWDQFH
5HYLHZHU
6XEPLWWHG
3DSHU
5HFHLYHG 6HQG

QR
5HMHFWLRQ
1RWLILFDWLRQ
3DSHU
5HMHFWHG

Fig. 5.32: Reviewing process involving a multiple-instances subprocess

be our focus. In BPMN, collaboration diagrams are used to represent the

interaction of business processes.

&DQFHOODWLRQ 5HYLHZ
5HFHLYHG &DQFHOOHG
&U 5F
3&&KDLU

6HQG
5HYLHZLQJ
5HTXHVW 65 $FFHSWDQFH
3DSHU 5HFHLYHG
5HFHLYHG $U
3U 6HQG 5HFHLYH
3DSHU 5HYLHZ
63 55
5HYLHZ
5HFHLYHG 5U

$FFHSW *HW3DSHU 3UHSDUH 6HQG

5HYLHZLQJ *3 5HYLHZ 5HYLHZ
$5 35 65
\HV

5HYLHZ
6HQW 5V
5HYLHZHU

'HFLGHRQ
5HYLHZLQJ
'5
5HYLHZLQJ
5HTXHVW
QR

6HQG
5HFHLYHG &DQFHOOD
5U WLRQ 6&
&DQFHOODWLRQ
6HQW &V

Fig. 5.33: Collaboration diagram of reviewing process, involving programme

committee chair and reviewer
154 5 Business Process Models

We stay with the paper-reviewing example and look at it from a global

perspective. The collaboration diagram shown in Fig. 5.33 consists of two
business process models, that for the programme committee chair and that for
a reviewer. Pools are used to show the boundaries of these processes.
In BPMN, pools are used to represent independent organisational entities
that communicate by message flow only. This means that all causal dependen-
cies between activities residing in different pools have to be expressed by means
of message flow. The concept of message flow is rather generic; it subsumes the
flow of electronic messages, fax messages, and letters, as well as the transport
of physical goods, for instance parcels or containers in logistics environments.
In the reviewing example, the programme committee chair communicates
with the reviewers by messages. Although the implementation details of the
communication are not reflected in process models, we can think of exchanges
of email messages between the persons involved.
The collaboration starts when the programme committee chair has received
a paper for reviewing. The chair sends a reviewing request to a reviewer.
The receipt of this message starts a new process instance for the reviewer. In
collaboration diagrams, message flow is represented by dotted edges, which are
oriented from the sending activity to the receiving activity. Note that BPMN
allows sending and receiving to be represented by events and activities.
After the reviewer has received the reviewing request, that person decides
whether or not to perform the review and responds, by sending either a
cancellation or an acceptance message. This decision by the reviewer has
implications for the behaviour of the programme committee chair.
In order to discuss these implications in detail, we consider the state of the
process after the reviewing request has been sent. The programme committee
chair waits for one of two events to happen: either a cancellation is received or
an acceptance notice is received. This means that the programme committee
chair does not take the decision, but reacts to the decision taken by the
reviewer. This behaviour can be represented by the deferred choice pattern, as
introduced in subsection 5.1.10.
In BPMN, the deferred choice pattern can be represented by event-based
gateways. An event-based gateway enables all following events. In our example,
after the reviewing request has been sent, an event indicating the receipt
of a cancellation and an event indicating the receipt of an acceptance may
occur. Whichever occurs first decides the continuation of the process. If the
cancellation event occurs, the process is terminated in the Review Cancelled
event. If, for some reason, an acceptance note is received after that event, the
process is no longer able to receive it, because that event can no longer happen.
Assuming the reviewer wants to perform the review, they send an acceptance
note, which is received by the programme committee chair. The process
continues with the chairperson sending the paper and waiting for the review.
When the reviewer gets the paper, they prepare the review and send it, and
the collaboration is completed.
 5.3 Business Process Model and Notation 155

Now that we have discussed the interaction between the business processes
in some detail, we will discuss the concurrent behaviour represented here. We
observe that the two processes are, at least in part, executed concurrently. This
is due to the fact that the sending of a message represents a behaviour similar
to a parallel split: it opens a new thread of control in the business process of
the communication partner. On the other hand, a receive event corresponds to
a parallel join, since a receive activity needs to wait for an incoming message.
Notice that the collaboration diagram represents concurrent behaviour
even though all business processes involved are sequential. The concurrency is
introduced only by communication between the parties.
3&&KDLU

6HQG 5HFHLYH
5HYLHZLQJ &RQILUPDWLRQ
5HTXHVW 65 5&

65 5&
5HYLHZHU

5HFHLYH 6HQG
5HTXHVW &RQILUPDWLRQ
55 6&
55 6&

(a) Send and receive activities (b) Petri net representation

Fig. 5.34: Mapping of send and receive activities and send and receive events
to a Petri net

We now illustrate this concurrent behaviour by mapping the collaboration

diagram to a Petri net. Before doing so, we have to introduce a mapping of send
activities (and send events) and of receive activities (and receive events) to
Petri nets. When activities are represented by a single transition, this mapping
can be directly used to represent send and receive events.
A collaboration involving send and receive activities and the corresponding
Petri net are shown in Fig. 5.34. Figure 5.34a shows a simplified communication
between the programme committee chairperson and a reviewer. The chairperson
sends a message to request a review, and the reviewer responds by sending a
confirmation.
A Petri net that represents the behaviour of the collaboration diagram in
Fig. 5.33 is shown in Fig. 5.35. Notice that the sending of the review request
acts as a parallel split, since firing of the transition SR puts one token on each
of the places in its output set.
The event-based gateway is also well represented by the Petri net, because
after SR has fired, either the transition Cr (Cancellation Received) or the tran-
sition Ar (Acceptance Received) can fire. However, either of these transitions
156 5 Business Process Models

3&&KDLU
&U

65

$U 63 55

$5 *3 35 65

'5

6&
5HYLHZHU

Fig. 5.35: Petri net representing the behaviour of the collaboration diagram
shown in Fig. 5.33

can fire only after the reviewer has decided to either perform the review (AR)
or sent a cancellation (SC ).
This example shows how an event-based gateway can be used to express
the deferred choice pattern. It also shows that the Petri net structure that
represents the deferred choice pattern can be found in the mapped Petri net
in Fig. 5.35.
The previous version of the reviewing process contains concurrency only
through the interaction between the business processes. The next example
provides a more complete picture of a real-world reviewing process. It looks
at the end-to-end process, including the author, the programme committee
chairperson, and the reviewers. We call it an end-to-end process because
it covers the interaction starting from the author sending the paper to the
programme committee chair until the receipt of a notification message by the
author.
It is a typical situation that a client (in this case the author) starts an
interaction by submitting a request (in this case a paper) and completes
the interaction by receiving a response (the notification). In this sense, this
example can serve as a blueprint for business processes such as the handling
of an insurance claim or of an application for a loan in the banking sector.
The collaboration diagram involving the business processes of the author,
the programme committee chair and the reviewers is shown in Fig. 5.36. The
collaboration starts when the author submits a paper to the programme
 5.3 Business Process Model and Notation 157

5HMHFWLRQ
5HFHLYHG
5U
$XWKRU

6XEPLW
3DSHU 63 $FFHSWDQFH
5HFHLYHG
$U

5HYLHZLQJ
5HTXHVW 5HYLHZ
5HYLHZHU

5HFHLYHG 5U 6HQW 5V

3UHSDUH 6HQG
5HYLHZ 5HYLHZ
35 65

6HQG
6HQG $FFHSWDQFH
5HFHLYH 1RWLILFDWLRQ
\HV
5HTXHVWWR 5HYLHZ
5HYLHZHU 6$1 3DSHU
65 55
$FFHSWHG
'HFLGHRQ 'HFLGHRQ 3D
3&&KDLU

5HYLHZHUV $FFHSWDQFH
'5 '$
6HQG 5HFHLYH
5HTXHVWWR 5HYLHZ 6HQG
6XEPLWWHG 5HYLHZHU
QR

3DSHU 55 5HMHFWLRQ

65 1RWLILFDWLRQ
5HFHLYHG
6U 651 3DSHU
5HMHFWHG
3U

3UHSDUH 6HQG
5HYLHZHU

5HYLHZ 5HYLHZ
35 65
5HYLHZLQJ 5HYLHZ
5HTXHVW 6HQW 5V
5HFHLYHG 5U

Fig. 5.36: Collaboration diagram involving the author, the programme com-
mittee chairperson, and two reviewers
158 5 Business Process Models

committee chairperson. After sending the paper, the author waits to receive a
notification, which is realised by an event-based gateway.
The chairperson decides on the reviewers and sends reviewing requests to
two reviewers concurrently. To keep the example reasonably small, we assume
that the reviewers start preparing their review as soon as they have received
the message. After the chairperson has received both reviews, he or she decides
whether to accept the paper, and sends the appropriate message to the author.
On receiving this message, the corresponding event following the event-based
gateway fires.

$XWKRU
5U

63

$U

5HYLHZHU
35 65

65 55 6$1

'5 '$

65 55 651

3&&KDLU

35 65
5HYLHZHU

Fig. 5.37: Petri net of the collaboration diagram shown in Fig. 5.36. The boxes
indicating the parts of the Petri net that map the respective participants have
been added for the purpose of illustration

To conclude the presentation of BPMN, the mapping of the collaboration

diagram to a Petri net is shown in Fig. 5.37. To ease understanding of this
 5.3 Business Process Model and Notation 159

Petri net, regions are used to demarcate the parts of the net that map to the
various participants.
The process starts with the author submitting a paper to the programme
committee chairperson. Upon receiving the paper, the chairperson opens two
concurrent branches, one for each reviewer invited. When Reviewer 1 submits a
review, the transition RR1 can fire. When RR2 has also fired, the chairperson
can decide whether to accept or reject the paper. The corresponding message
is sent by the transitions SR and SA, respectively. The deferred choice of the
author process reflects him or her waiting for a notification message. When
that message is received, the collaboration concludes.

Bibliographical Notes
With workflow patterns, van der Aalst et al. (2003) introduced an important
basis for business process modelling languages. A revised version was provided
by Russell et al. (2006). That version includes a richer set of patterns and a
formalisation based on coloured Petri nets.
The inclusive-or join has the reputation of being the most complex workflow
control flow pattern. This was highlighted by Kindler (2006), where the term
vicious circle was used to illustrate the complexity of the problem. Replacing an
inclusive-or join was addressed by Favre and Völzer (2012), while the execution
semantics of the inclusive-or join in the context of BPMN was covered by
Gfeller et al. (2011).
There are textbooks on business process management that provide a broader
perspective on the matter. Weske (2012) introduces the concepts of business
process management and provides a description of the most important business
process modelling languages, including BPMN and its various types of diagrams.
Organisational aspects of business processes are covered in the book by Dumas
et al. (2013), which also looks at process identification, discovery, and redesign.
The BPMN standards document is available by the Object Management
Group (2011). A mapping of BPMN to Petri nets was introduced by Dijkman
et al. (2008). zur Muehlen and Recker (2008), and Kunze et al. (2011a) have
investigated the occurrence of control flow structures in collections of process
models. These results inspired the selection of workflow control flow patterns
presented in this chapter.
 Part III

Analysis of Behaviour
6
State Spaces

Starting from some general aspects of behavioural modelling, different lan-

guages for modelling the behaviour of discrete dynamic systems have been
covered in this book. The resulting behavioural models can be used for many
purposes, ranging from representing behavioural requirements during system
design to providing a blueprint of a system’s behaviour to be used during
implementation.
An important purpose of behavioural models is verification, for instance
proving that a behavioural model has certain properties. When desirable
properties of behavioural models can be shown, then these properties also hold
for systems that are based on those models. In addition, if we can show that a
model does not have undesirable properties, such as deadlocks, the resulting
system will also not show that behaviour. In general, the quality of software sys-
tems can be improved by verification of behavioural models. In this argument,
however, it is assumed that models are normative for system implementations.
By “normative” we mean that a system always behaves exactly as specified in
the model. Although this is still a challenge in software development projects,
model-driven software engineering has developed methods and techniques to
provide consistency between models and implementations.
Investigating the state space of a system is essential for model verification.
Therefore, state spaces of behavioural models will be used extensively in
Chapters 7 and 8. Based on the behavioural models discussed so far and the
languages used to express them, this chapter looks at the states that can be
reached by a system during operation. The set of states of a system is called
its state space. In the first section, fundamental concepts regarding the state
spaces of dynamic systems are covered. Section 6.2 looks at the state space of
sequential systems, which are described by different types of automata, ranging
from finite automata to extended and hierarchical automata.
The state spaces of concurrent systems are covered in Section 6.3. Since
independent parts of a system can proceed concurrently, the set of states that
a concurrent system can assume is generally much larger than the state space
of a sequential system.

© Springer International Publishing Switzerland 2016 163

M. Kunze and M. Weske, Behavioural Models,
DOI 10.1007/978-3-319-44960-9_6
164 6 State Spaces

6.1 Introduction to State Spaces

The state space of a dynamic system is characterised by a set of states and
state transitions between them. In this section we focus on how to represent the
state space of a system. This means that we are facing a modelling challenge.
However, rather than modelling the behaviour of a system, we are modelling
its state space. This means that the original to be represented in the model
is the state space of the system and we are seeking a modelling language in
which to express it.
To introduce the state space of dynamic systems, we revisit the ticket
vending machine discussed in Chapter 3. A finite automaton models the ticket
vending machine by states and state transitions between them; it is shown
again in Fig. 6.1.
At each point in time, the system is in exactly one state. When the system
starts, it is in the initial state, called Ticket selection. The ticket vending
machine can change its state by reading input symbols, in particular, it can
do this by accepting coins and input from the user, for instance selecting a
ticket or cancelling the vending process.

1¼

select
Ticket ticket 0¼ 50ct 0.5¼ 50ct 1¼ 50ct 1.5¼ confirm Ticket
selection paid paid paid paid supplied

1¼

cancel
cancel Ticket
cancel cancelled
cancel

Fig. 6.1: Finite automaton for a ticket vending machine

As this discussion shows, a finite automaton models the behaviour of

the ticket machine by states and state transitions. Effectively, the system is
already described by states and state transitions, i.e., the behavioural model
is equivalent to the state space of the system!
This situation occurs when one is modelling sequential systems using
simple finite automata. As the language used to model a dynamic system
becomes more expressive, however, mappings need to be developed that map
the behavioural model of a system to its state space, which is represented by
an automaton.
Before we investigate the state space of dynamic systems using more
expressive modelling languages, a variant of the ticket vending machine will be
investigated to discuss the concept of reachable states. Although reachability
 6.1 Introduction to State Spaces 165

will be explored in detail in Chapter 8, the basic idea behind this important
concept is introduced in this section because it is based on state spaces of
dynamic systems.

)UHH
WLFNHWV
¼
FRQILUP

VHOHFW
7LFNHW WLFNHW ¼ FW ¼ FW ¼ FW ¼ FRQILUP 7LFNHW
VHOHFWLRQ SDLG SDLG SDLG SDLG VXSSOLHG

¼

FDQFHO
FDQFHO 7LFNHW
FDQFHO FDQFHOOHG
FDQFHO

Fig. 6.2: Variant of the ticket vending machine, including a state that cannot
be reached

In the ticket vending machine shown in Fig. 6.2, one state and one state
transition have been added. The state Free tickets has a state transition to the
state Ticket supplied, which means that if the system is in the former state,
a ticket can be supplied without payment. This variant of the ticket vending
machine serves an illustrative purpose, but it might also be introduced by a
modelling error.
It might seem that the state Free tickets is harmful, because free tickets
might be provided by the system. However, when we investigate the behaviour
of the ticket vending machine in more detail, it turns out that this is not
the case. Despite the new state and the state transition to the state Ticket
supplied, the vending machine cannot dispense a ticket without payment. This
is due to the fact that the state Free tickets cannot be reached from the initial
state. There is no sequence of inputs that allows the automaton to reach the
state Free tickets.
This example shows a very simple case in which not all states of a system
can actually be reached. The concept behind this example is that of reachability
of states. When analysing dynamic systems, it is essential to investigate the
states that are reachable and to analyse their properties.
The ticket vending machine shown in Fig. 6.2 has one state that is not
reachable, namely, the state Free tickets. All other states are reachable from
the initial state. Since the behavioural model is represented by an automaton
without extensions, the model and its state space are equivalent. As one state is
166 6 State Spaces

not reachable, the set of reachable states consists of all states of the automaton,
except for the state Free tickets.
To summarise, the state space of a dynamic system is characterised by its
states and the state transitions between them. To analyse a dynamic system, it
is important to consider the set of reachable states, which are all states which
can be reached from the initial state. In general, state transitions represent
operations performed by the system, which, in general, change the system
state.

6.2 State Spaces of Sequential Systems

If a system is specified by a finite automaton without any output and without
extensions, it suffices to represent the states of the state space by their labels
only. However, since this section looks at finite automata with extensions, the
concept of a state needs to be refined. We start by investigating how states in
the state spaces of Moore and Mealy automata can be represented.

6.2.1 Moore Automata

As introduced in Section 3.2, Moore automata are finite automata that can
generate output when states are reached. To discuss the state spaces of Moore
automata, consider Fig. 6.3, which shows the state space of the Moore automa-
ton for the ticket vending machine introduced in Fig. 3.5. The ticket vending
machine allows one to select a ticket and pay for it with 50 cents, 1 A C, and
2AC coins. Recall that Moore automata provide the output directly in a state.
The output of this Moore automaton provides information about the ticket
selection, given change, and supplies the printed ticket.
For finite automata without any output, each state of the state space can be
specified just by the label of the respective state in the finite automaton. Since
Moore automata generate output, however, a variable needs to be introduced
to represent the current value of the output, which contributes to the state of
the system.
By abstracting away the state labels of the automaton, a state in the state
space of a Moore automaton can be represented by the current value of the
output variable. In order to capture the values of variables, the concept of
a valuation is introduced. Even though Moore automata have only a single
variable, we shall introduce the general case where a system has an arbitrary
number of variables, which will be required when extended automata are
discussed later in this chapter.

Definition 6.1 Let V be a set of variables {v1 , v2 , . . .} and let dom(vi ) be

the domain of vi ∈ V , i.e., the set of values vi can assume. Variables with
undefined values are represented by ⊥ ∈ dom(vi ), vi ∈ V . dom(V  ) refers to
the union of the domains of all variables in V , i.e., dom(V ) = i dom(vi ).
 6.2 State Spaces of Sequential Systems 167

¼SDLG
¼ Y FW FRQILUP

¼SDLG FRQILUP
¼
Y ¼FW
¼ ¼

VHOHFW
7LFNHW WLFNHW
¼SDLG FW ¼SDLG FW ¼SDLG FW ¼SDLG FRQILUP 7LFNHW
VHOHFWLRQ VXSSOLHG
Y VHOHFWLRQ Y ٣ Y ٣ Y ٣
Y ٣ Y WLFNHW

¼
¼
Y ¼ FRQILUP
¼

Fig. 6.3: State space of Moore automaton

A valuation, val(V ) : V → dom(V ), is a mapping that assigns each variable

in vi ∈ V a value, such that val(vi ) ∈ dom(vi ). The set V corresponds to the
set of all valuations. 

Valuations are essential components for describing states. They allow us to

provide concrete values of variables and bind these to states in the state space
of a dynamic system. Hence, the set of variables V corresponds to the set of
variables of a dynamic system.
In Fig. 6.3, the output variable is called v. To focus on the core concept
of state spaces and to reduce complexity, we abstract away the sequences of
output values that can be generated by Moore automata and represent each
output sequence by a single variable v. This is not a limitation, since dom(v)
can also be a structured type, for instance a list type.
We represent the output of the Moore automaton in a variable v, so that
V = {v}. In the initial ticket selection state, no output is generated by the
automaton, so that v = ⊥. Since in the state 0 A C paid the automaton outputs
the selection made by the user, v = selection holds in that state. In the final
state, the ticket is provided, so that in the final state, v = ticket.
This discussion shows that each state in the state space is characterised by
an assignment of values to system variables, i.e., by a valuation.

Definition 6.2 Let A = (Sm , Σ, Λ, δ, λ, s0 , F ) be a Moore automaton, as

formalised in Definition 3.7, and let V = {v}, where v represents an output.
The state space of A, M(A) = (S, Σ, δ, s0 , F ), consists of the automaton’s
input alphabet, its transition relation, its initial state, and its final states.
168 6 State Spaces

Each state in the state space is represented by a valuation of the system

variable v, determined by the output function. Let s ∈ Sm be a state of the
Moore automaton with output λ(s). In the state space of the Moore automaton,
this state s is represented by a valuation s ∈ S, such that s (v) = λ(s). 

This definition is illustrated by the sample state space of the Moore au-
tomaton introduced in Fig. 6.3. Each state in the state space is a valuation
that assigns values to the variable v.
The initial state of the Moore automaton does not have any output; there-
fore, this state is represented by s0 (v) = ⊥. In the next state of the automaton,
an output is generated, resulting in s1 (v) = selection. This state represents
the fact that, on entering the 0 A C paid state, the automaton generates the
selection as output. When a 2 A C coin is inserted into the automaton, it enters
the 2 AC paid state, outputting 50 cents. Therefore, s2 (v) = 50 ct.
It is worth mentioning the state space of a Moore automaton has the same
structure as the Moore automaton itself. That is, each state of the automaton
is represented by exactly one state in the state space. This is so because
every output of a Moore automaton belongs to exactly one state, so that no
additional states are required to capture the output with variables.

6.2.2 Mealy Automata

Mealy automata are also able to generate output. In contrast to Moore au-
tomata, Mealy automata associate this output with state transitions rather
than with states, as introduced in Section 3.2.
This property has implications for the representation of the state space
of a Mealy automaton. This is due to the fact that the value of the output
variable v is not related directly to states, but rather to state transitions. The
automaton can enter a state by traversing different transitions, which might
generate different output values for the same state. Hence, for a given state of
the state space, the output variable would assume different values.
Consider a state s of a Mealy automaton, and state transitions (s , a, s),

(s , b, s) that both lead to s. Then, the automaton can reach the state s with
different values a and b of the output variable. Since the state space of a
dynamic system is based on the values of variables, these situations have to
be distinguished. As a result, the state space contains two states s1 , s2 , with
s1 (v) = a and s2 (v) = b.
To illustrate these concepts, we now investigate the Mealy automaton
shown in Fig. 6.4. This automaton describes the same ticket vending machine
from the previous section, but this time using outputs as part of the state
transitions. In general, this leads to more compact states, as we have discussed
in subsection 3.2.2.
The state space of the Mealy automaton is shown in Fig. 6.5. When we
investigate the 1.5 A
C paid state of the Mealy automaton, it turns out that the
 6.2 State Spaces of Sequential Systems 169

2€ / 50ct

1€ 2€/1€

select
Ticket ticket 0€ 50ct 0.5€ 50ct 1€ 50ct 1.5€ confirm Ticket
selection paid paid paid 1€ / 50ct paid / ticket supplied
/ selection

1€

Fig. 6.4: The Mealy automaton shown in Fig. 3.6

state space has three corresponding states. These states differ in the value of
the output variable, which assumes values ⊥ (representing no output), 50 ct,
and 1 AC, respectively.
In general, for each state transition with a different output value which
leads to a state s in a Mealy automaton, a separate state is required in the
automaton’s state space. Based on these considerations, the state space of a
Mealy automaton is defined as follows.

¼SDLG
¼ Y FW FRQILUP

¼SDLG FRQILUP
¼
Y ¼
¼ ¼

VHOHFW
7LFNHW 7LFNHW
WLFNHW ¼SDLG FW ¼SDLG FW ¼SDLG FW ¼SDLG FRQILUP
VHOHFWLRQ VXSSOLHG
Y VHOHFWLRQ Y ٣ Y ٣ Y ٣
Y ٣ Y WLFNHW

¼
¼
Y ¼ FRQILUP
¼

Fig. 6.5: State space of the Mealy automaton shown in Fig. 3.6

Definition 6.3 Let A = (Sm , Σ, Λ, δm , λ, s0m , Fm ) be a Mealy automaton

and let V = {v}, where v is the automaton’s output variable. The state space
of A, M(A) = (S, Σ, δ, s0 , F ), consists of:
• The input alphabet Σ of the Mealy automaton.
170 6 State Spaces

• A set of states S = {s|s : V → dom(V )}, such that for each state transition
(s , l, s ) ∈ δm in the Mealy automaton with output ω, i.e., (s , l, ω) ∈ λ,
there is a state s in the state space, such that s(v) = ω. We say that s
corresponds to s . If s is a final state in the Mealy automaton, then s is
a final state in its state space.

Since the initial state s0m of the Mealy automaton does not have any incoming
arcs, the corresponding state s0 in the state space has no output, which is
represented by s0 (v) = ⊥.
There is a transition between the states s and s in the state space, i.e.,
(s, s ) ∈ δ, iff there is a transition between the states corresponding to s and
s in the Mealy automaton. 

This definition is illustrated by the Mealy automaton shown in Fig. 3.6

and the corresponding state space shown in Fig. 6.5.
In the initial state Ticket selection of the automaton, there cannot be any
output, so that the initial state of the state space is s0 (v) = ⊥. The transition
to the next state has an associated output selection, so that the next state of
the state space is s1 (v) = selection.
The “duplication” of states can be witnessed for the 1.5 A C paid state of
the Mealy automaton, which occurs in states 1.5 A C paid, 2 AC paid, 2.5 A
C paid,
and 3 AC paid. In each state a different amount has to be returned, which
is represented by different values of the system variable v. In particu-
lar, 1.5 A
C paid(v) = ⊥, 2 A C paid(v) = 50 ct, 2.5 A C paid(v) = 1 A C, and
3AC paid(v) = 1.5 A C.
On close examination, we can observe that the state space of the Mealy
automaton in Fig. 6.5 is identical to the state space of the Moore automaton
in Fig. 6.3. While this observation is interesting, it does not come as a surprise:
following Definition 6.3, a new state is created in the state space for each
state transition with an individual output that leads to the same state in the
automaton.
This is exactly the same as the assumption that is fundamental to Moore
automata, where the output is related to states. Therefore, by generating the
state space of a Mealy automaton, we have effectively turned it into a Moore
automaton.

6.2.3 Extended Automata

Extended automata, which were introduced in Section 3.3, augment the capa-
bilities of finite automata with variables, conditions, and assignments. They are
an extension of both Moore and Mealy automata, because they can have many
variables and output can be associated with both states and state transitions.
Values of variables are assigned as part of state transitions and allow
complex computations. If an extended automaton is in a particular state, its
 6.2 State Spaces of Sequential Systems 171

variables may have values that depend not only on the state, but also on the
execution sequence that has to that state.
An example of an extended automaton is depicted in Fig. 6.6. It has
variables i, j, each of which can assume values from a finite set of natural
numbers, i.e., i ∈ {0, 1} and j ∈ {0, 1, 2}. The state transition triggered by the
action A updates the value of i by adding 3 and computing the remainder of
the division of i by 2. The latter operation is called “modulo” and denoted by
mod. For instance, 1 mod 2 = 1, 2 mod 2 = 0, and 3 mod 2 = 1.
As a result of this computation, i has a value of either 0 or 1. The state
transition B updates the variable j in a similar manner. Only if the values of
the variables i and j are equal in the state s2 can the automaton terminate,
which is triggered by the action C .

^`L  $L  L PRG

^`M 
>L M@&
6 6 6

%M  M PRG

Fig. 6.6: Extended automaton with variables i and j and transitions with
assignments

Table 6.1 shows an example execution sequence σ of the above automaton

in the topmost row. The remaining rows show the state of the extended
automaton and the values of the variables i and j before and after the state
transitions of the execution sequence. The sequence is not complete, as it does
not terminate in the state s3 .

Table 6.1: States resulting from an execution sequence of the automaton shown
in Fig. 6.6

σ  A , B , A , B , A , B , A , B , A , B , A , B 
State S1 S2 S1 S2 S1 S2 S1 S2 S1 S2 S1 S2 S1
i 0 1 1 0 0 1 1 0 0 1 1 0 0
j 0 0 2 2 1 1 0 0 2 2 1 1 0

This table illustrates that the values of the variables i and j do not coincide
with the states s1 and s2 , but depend on the execution sequence that has led
to the state. For instance, the first time s2 is visited, i = 1 and j = 0, whereas
the second time s2 is visited, i = 0 and j = 2.
172 6 State Spaces

Just as with Mealy automata, the state space of an extended automaton is

not structurally equivalent to the automaton. Each variable assignment yields
a new state in the automaton’s state space.
Extended automata are an extension of output automata, since they allow
us to represent multiple variables. The values of variables can be changed
by assignments, associated with state transitions. Assignments can also be
associated with entering a state and with leaving a state.
The state space of the sample extended automaton can be derived from
Table 6.1; it is shown in Fig. 6.7. Notice that the states are represented by
valuations. With the system variable v representing the label of the state in
the automaton, the triple (S1 , 0, 0) for the state s0 represents s0 (v) = S1 ,
s0 (i) = 0, and s0 (j) = 0.

s0 s2 s4 s6 s8 s10
(S1,0,0) (S1,1,2) (S1,0,1) (S1,1,0) (S1,0,2) (S1,1,1)

A B A B A B A B A B A B

s1 s3 s5 s7 s9 s11
(S2,1,0) (S2,0,2) (S2,1,1) (S2,0,0) (S2,1,2) (S2,0,1)

C C

s12 s13
(S3,1,1) (S3,0,0)

Fig. 6.7: The state space of the automaton shown in Fig. 6.6

The start state s0 in the state space is represented by (S1 , 0, 0), meaning
that the automaton is in the state S1 and the state s0 is represented by
s0 (i) = 0 and s0 (j) = 0. From this state, the automaton can proceed to s1
by way of action A updating i with its new value 1, which yields a new state
s1 , with s1 (i) = 1 and s1 (j) = 0. Eventually, the state s11 is reached, which
is represented by (S2 , 0, 1). The state transition B leads to the state s0 , the
initial state of the state space.
This discussion shows that the definition of the state space of an extended
automaton is very similar to that for a Mealy automaton. Instead of a single
variable, extended automata have multiple variables. However, in each state,
each variable has exactly one value. Just as in the case of output automata, a
state in the state space of an extended automaton is a valuation on a set V of
variables.
 6.2 State Spaces of Sequential Systems 173

When we introduced extended automata, we concentrated on the main

concepts and their applications rather than on a formal definition. Therefore, in
the following definition, the state space will also be introduced only informally.

Definition 6.4 Let M be an extended automaton and let V = {v1 , v2 , . . . , vn }

be the set of its variables, such that dom(vi ) is the domain of vi ∈ V and
dom(V ) = i dom(vi ). The state space of M , M(M ) = (S, Σ, δ, s0 , F ) consists
of a set of states S = {s|s : V → dom(V )}, such that s(vi ) represents the
value of vi in the state s.
For a state transition (s , l, s ) in the extended automaton, in order to determine
a valuation of a state s ∈ S corresponding to that state transition, the following
assignments need to be evaluated in order:

• the exit clause of the state s ,

• the assignments associated with the state transition l,
• the entry clause of s .

In the state space, l is the label of the resulting transition leading to s. The
state s is a final state in the state space iff s is a final state in the extended
automaton. The initial state of the state space corresponds to the initial state
of the automaton, where only the entry clause has been evaluated. 

This definition is illustrated by the example shown in Fig. 6.7. The initial
state of the state space is s0 ∈ S, represented by (S1 , 0, 0), since S1 is the initial
state of the extended automaton and there is no entry clause in that state,
which might change the initial values of the variables. If the variables had not
been initialised, then they would have had the value ⊥. Using Definition 6.4,
the state space of the extended automaton can be derived, as explained above.

6.2.4 Unreachable States

The state space of an extended automaton is required if we wish to analyse

the automaton and detect various issues. One such issue is unreachable states.
A state of an automaton is unreachable if there exists no execution sequence
starting at the initial state that leads to the state in question. All states that
would only be reachable through an unreachable state are unreachable as well.
If a final state of an automaton is unreachable, then the automaton cannot
terminate.
So far, we have investigated reachable states of automata. Given a behav-
ioural model M with a set of variables V and a set of reachable states S, the
set of unreachable states SU can be characterised by all valuations that are not
in the set S, i.e., SU = (V → dom(V )) − S. Some of these valuations might be
represented in the behavioural model, as was discussed earlier in this chapter
in the context of the state Free tickets of the ticket vending machine.
174 6 State Spaces

LQWL  $L  LPRG 

LQWM 
>L M@&
6 6 6

%M  M PRG

Fig. 6.8: A modified extended automaton

This section discusses reachable states in more detail by investigating a

slight modification of the extended automaton, depicted in Fig. 6.8. We have
changed the variable assignment for i such that the modulo operation is applied
first and the sum only afterwards. This causes i to assume a value of either 3
or 4.
Glancing at the automaton does not disclose any issues. However, when
the state space is created, it turns out that there exists no state in which i = j,
so that C can never be triggered, and the automaton cannot terminate.

s0 s2 s4 s6
(S1,0,0) (S1,3,2) (S1,4,1) (S1,3,0)

A B A B A B A

s1 s3 s5 s7
(S2,3,0) (S2,4,2) (S2,3,1) (S2,4,0)

Fig. 6.9: State space of the extended automaton shown in Fig. 6.8, with a loop
and without a final state

The state space is shown in Fig. 6.9. Notice that the state space is a cyclic
graph, which shows the non-terminating nature of the automaton. This is due
to the fact that in the state S2 of the extended automaton, i = j always holds,
which prevents the automaton from reaching the final state S3 .

6.2.5 Infinite State Spaces

The examples introduced so far have used finite domains of variables. However,
some automata have variables with an infinite domain, where there exists no
upper bound on the value a variable can assume. Since each different value
that a variable can assume results in a different state in the state space, the
number of states in the state space becomes infinite as well.
Before we introduce an approach to dealing with situations like this, we
will present an example of an automaton with unbounded variable values. This
 6.2 State Spaces of Sequential Systems 175

is a variant of the extended automaton introduced earlier in this section, and

it is shown in Fig. 6.10.

LQWL  $L L

LQWM 
> LPRG   MPRG @&
6 6 6

%M M

Fig. 6.10: An extended automaton with an infinitely large state space

The values of the variables can be computed easily. Initially, the automaton
is in the state S1 , and both variables have the initial value zero. On entering
the state S2 , the value of i is incremented by 3, and returning to the state S1
increments j by 2. After the first iteration of the cycle involving S1 and S2 ,
we have i = 3 and j = 2.
The final state, S3 , can be reached after the third and the fourth iteration
of the loop made up of S1 and S2 , and afterwards every fifth and sixth iteration.
After the third iteration, i = 9 and j = 4, so that (i mod 2) = (j mod 3) = 1.

s0 s2 s4 s6 s8 s10
(S1,0,0) (S1,3,2) (S1,6,4) (S1,9,6) (S1,12,8) (S1,15,10)

A B A B A B A B A B

s1 s3 s5 s7 s9 . .. .
(S2,3,0) (S2,6,2) (S2,9,4) (S2,12,6) (S2,15,8)

C C

s11 s12
(S3,9,4) (S3,12,6)

Fig. 6.11: State space of the extended automaton with an infinitely large state
space shown in Fig. 6.10

Despite the possibility of reaching the final state, the automaton can also
use the transition B to start the next iteration. This is also possible if the
condition associated with the state transition C can be evaluated to true.
The state space of the automaton is shown in part in Fig. 6.11. It is easy
to see that after iteration n in the state S2 , i = n · 3, and j = (n − 1) · 2. It
176 6 State Spaces

is also easy to see that there is no upper bound on either of these variables,
resulting in an infinite state space.
Infinite state spaces are used in formal verification of discrete dynamic
systems in Chapter 8.

6.2.6 Hierarchical Automata

Hierarchical automata have composite states, i.e., states whose internal behav-
iour is determined by another state machine. The grouping of states and state
transitions in hierarchical automata has implications for the state spaces of
these automata.
When we introduced hierarchical automata in subsection 3.4.3, we explained
that a hierarchical automaton is always in exactly one state, which is a non-
composite state. Composite states are used to group states and to ease the
representation of state transitions.
Therefore, there exists one state in the state space for each non-composite
state of a hierarchical automaton. The state transitions between these states
can be added as well. If the hierarchical automaton uses variables, conditions,
or assignments, the methods for creating the state spaces of extended au-
tomata need to be followed, as explained above. To ease the presentation, this
section abstracts away these advanced properties of hierarchical automata and
concentrates on their nested structure.

'
6

&
6

$ % *
6 6 6
7
+

( )

6

Fig. 6.12: A hierarchical automaton

Since state spaces do not use composite states, these states can be eliminated
by connecting all incoming state transitions of a composite state to the initial
state of the automaton. Hierarchical automata and UML state machines share
the concept of pseudostates for an initial state and for history states. These are
entry points to a state machine. However, the automaton cannot reside in a
pseudostate; instead, the next state is entered instantly. Therefore, pseudostates
are not available in state spaces and need to be eliminated as well.
 6.2 State Spaces of Sequential Systems 177

State transitions that have a composite state as the source state and a
target state st in the automaton need to be replicated for each internal state
of the composite state. This means that each internal state is connected to st .
History states require special treatment. Since they allow the automaton to
return to an internal state that was active when the composite state was left,
it is necessary to store the state that was active. However, this is not possible
in state spaces. Therefore, the part of the state machine that is executed after
re-entering a composite state through a history pseudostate needs to be copied
for each internal control state.

6
& '

&

$ % *
6 6 6 7

( ) ( )

6 6

Fig. 6.13: The state space of the hierarchical automaton shown in Fig. 6.12

These concepts will now be illustrated by an example. The hierarchical

automaton is shown in Fig. 6.12, and Fig. 6.13 shows the corresponding state
space.
Since there is a direct correspondence of the states of the automaton to the
states in the state space, we have used the labels of the states of the automaton
in the state space as well. The initial state is S1 , which allows us to enter
the composite state by the transition A. By traversing the initial pseudostate,
the state S2.1 is immediately reached. Therefore, in the state space, there is a
transition from S1 to S2.1 , labelled A.
The state S4 is reachable from every state in the composite state; therefore,
there is a transition from both internal states to S4 in the state space.
The history state and the duplication of the state transition are discussed
next. Since the automaton can reach the state S3 from both S2.1 and S2.2 ,
there needs to be a transition to S3 from both states. To make sure that
the automaton enters the right substate when the transition F is followed,
there need to be two representations of S3 , namely S3.1 and S3.2 , where one is
connected to S2.1 and the other is connected to S2.2 .
178 6 State Spaces

6.3 State Spaces of Concurrent Systems

When we introduced concurrency in Chapter 4, we focused on models repre-
senting several subsystem that can proceed independently of each other. As
a result, there are consecutive events in the system which are not causally
related. State machines with orthogonal regions, process diagrams, and Petri
nets were used to express models that contain concurrency.
In this section, the state space of concurrent systems will be explored. When
we look at individual states, there is no difference between sequential and
concurrent systems. In both types of systems, states are valuations that assign
a value to each variable. However, concurrent systems have independent parts,
such as subsystems that do not have causal relations with each other. The
independence of subsystems allows independent progress of these subsystems,
which has implications for the state space.

6.3.1 Orthogonal States

To illustrate these considerations, the first approach to expressing concurrency

will be revisited: state machines with orthogonal regions. Figure 6.14 shows
such a machine that represents the behaviour of (a simplified version of) a car
radio and navigation system. The functionality of the system is partitioned
into three regions, representing the operation of the subsystems, i.e., the radio,
the navigation system, and the operation of a mobile phone.
To discuss the behaviour of the car radio and navigation system, we
investigate the state machine shown in Fig. 6.14. The orthogonal state is
entered via the initial pseudostate. Once started, the system can be terminated
using the Shut down radio navigation (DRN ) transition, which interrupts
operation of the system. The main functionality of the system is represented
by an orthogonal state, which consists of three substates.
The radio subsystem is represented by a simple state machine, which allows
us to start the radio (SR), to change the station (CS), and to shut down the
radio (DR). Notice that we can change the station multiple times.
The navigation subsystem is represented by the second region in the
orthogonal state. When the navigation subsystem is ready, an address can be
entered (EA), which brings the state machine to the state Route computed
(RC ). Then the Start route (ST ) transition brings the navigation subsystem to
the state Navigate (N ). Finally, the route can be cancelled or the driver reaches
the destination, in which case the Navigation ready (NR) state is entered.
The phone subsystem is entered in the state Phone ready (PR). In this
state, we can receive calls (RC ) and make calls (MC ), which brings the state
machine to the Phone conversation (PC ) state. After the call is terminated
(TC ), the phone is ready again.
The subsystems of the car radio and navigation system are independent
of each other because events occurring in the individual subsystems are not
 6.3 State Spaces of Concurrent Systems 179

5136WDWH

6WDUWUDGLR 65
5DGLRRII 5DGLRRQ &KDQJH
5DGLR

52) 521 VWDWLRQ &6

6KXWGRZQUDGLR '5

1DYLJDWLRQ2II 12
6KXWGRZQ '1
6WDUW
1DYLJDWLRQ

(QWHU
1DYLJDWLRQ DGGUHVV ($ 5RXWH URXWH 67
1DYLJDWH 1
UHDG\ 15 FRPSXWHG 5&

&DQFHO5RXWH &5

5HFHLYHFDOO 5&
0DNHFDOO 0&
3KRQHUHDG\ 3KRQHFRQ
3KRQH

35 YHUVDWLRQ 3&
7HUPLQDWHFDOO 7&
8QUHJLVWHU
SKRQH 83
3KRQHRII 32

6KXWGRZQUDGLR
QDYLJDWLRQ '51

6\VWHP2II 62

Fig. 6.14: State machine of car radio navigation system with orthogonal states

causally related. For instance, we can change the radio station while the system
is navigating, and we can cancel navigation while making a phone call.
The key question in this section relates to the state space of concurrent
systems. As indicated above, the state space of a system is represented by the
values of its variables, and by events that represent system behaviour by state
transitions. Since behavioural models restrict the events that can occur during
run time, we are interested in the ordering of system events, represented by
state transitions.
As this discussion shows, all interleavings of events generated by orthogonal
subsystems represent valid system behaviour. Therefore this semantics of a
concurrent system is called interleaving semantics. For other semantics of
concurrent systems, the reader is referred to the bibliographical notes of this
chapter.
Part of the state space of the car radio and navigation system is shown
in Fig. 6.15. Since there are no dependencies between the state transitions
in the three orthogonal substates, the number of states equals the product
of the numbers of states in the submachines. Hence, the number of states
resulting from the orthogonal state is 2 · 4 · 3 = 24. This is due to the fact
that the radio subsystem has two states, the navigation subsystem has four
180 6 State Spaces
^Z 

V
52)
Z͕D 
12 ^  ^
35 hW
hW   ^d 
E
V V
521  521 D͕Z
15 5&
35 35

D͕  hW 

Z
E ^Z Z
^Z Z

V V ^d 
52)
 52)
15 5& hW
35 35 

hW Z͕ Z͕
d
D D
d

^Z  ^Z 
V V
52)  52) ^d 
15 5&
 
3& 3&
ZE ZE
^Z  E  d 

 ZE
V
52)  
15 E  V
32 62
ZE
 

Fig. 6.15: Part of the state space of the car radio and navigation system.
Overall, the state space consists of combinations of states of the orthogonal
state machines plus the final state.

states, the phone subsystem has three states, and all combinations of states
represent valid states in the state space. Notice that we do not represent the
initial pseudostates in the state space, since these are immediately left after
being entered.
Owing to the large number of states and state transitions resulting from
this, we deliberately included only an excerpt of the complete state space in
Fig. 6.15. Note that in any state, the radio navigation system can be shutdown
entirely, represented by the action DRN that originates from the orthogonal
state in Fig. 6.14. For the state space, this means that there exists a state
transition from each state to the final state s24 labelled SO, assuming that
the 24 states resulting from the orthogonal state are s0 through s23 . We have
left out the transitions to s24 for the sake of clarity, and only sketched that
behaviour by several incoming state transitions to s24 .
To investigate the behaviour of the car radio and navigation system, its
states have to be considered. In the example, it suffices to use three variables,
 6.3 State Spaces of Concurrent Systems 181

each of which represents the current state of one subsystem. The variable vR
is responsible for maintaining the state of the radio, vN for the navigation
system, and vP for the phone.
After the radio and navigation system is started up, the orthogonal state is
entered. In each submachine, the pseudostate is entered, which is immediately
followed by the corresponding first state of each submachine. As a result, the
system is in the state s0 = (ROF , NR, PR), meaning that the radio is off,
s0 (vR ) = ROF , the navigation is ready, s0 (vN ) = NR, and the phone is ready
as well, s0 (vP ) = P R.
In s0 , the following events might occur, corresponding to state transitions
in the three subsystems:
• In the radio subsystem, the radio can be started (event SR).
• In the navigation subsystem, an address can be entered (EA) or the
navigation can be shut down (DN ).
• In the phone subsystem, a call can be made (MC ) or received (RC ), or
the phone can be unregistered (UP).
• The radio navigation system can be shut down entirely (DRN )
These behavioural alternatives are reflected in the state space shown in
Fig. 6.15. Since the two transitions MC and RC lead to the same system state,
we have marked the corresponding edge with both labels.
It is a typical situation in concurrent systems that several events can occur
at each point in time. For example, in the state s0 , any of the seven events
mentioned in the list above can happen. Each walk through the state space of
a concurrent system serialises the events in an order in which they can occur.
In fact, one specific execution sequence of the concurrent system is represented
by a walk from the start state to an end state.
This example also shows the so-called state explosion problem. This problem
is due to the increasing number of states in the state space of concurrent systems.
The example shown has just nine states in the submachines, but 24 states
in the state space of the orthogonal state. In general, the number of states
increases exponentially in the degree of concurrency. For instance, a business
process model with concurrent execution of 20 branches, each of which contains
a single activity only, will result in 220 states, which exceeds a million states.
The bibliographical notes of this chapter contain references to papers looking
at techniques for reducing the state space of concurrent systems.

6.3.2 Dependencies between Orthogonal States

Regarding the state spaces of state machines, so far we have assumed that all
transitions in orthogonal states are independent. This assumption, however,
does not hold in general, as was discussed in Section 4.1 for a soft drink vending
machine. In this section, the implications of these dependencies for the state
spaces of state machines with orthogonal states are investigated.
182 6 State Spaces

To illustrate these dependencies, we revisit the soft drink vending machine

shown in Fig. 4.7. This machine consists of an orthogonal state with two
regions, one of which is responsible for drink selection and the other for
handling payment. The dependency between these orthogonal states results
from the fact that a beverage can only be dispensed after payment has been
made.
This dependency was handled by synchronising the state transitions in the
state machines of the respective orthogonal states. In particular, the drink
could only be dispensed when the payment state was in the 2 A C paid substate,
i.e., if sufficient funds had been paid.

¼ ¼

2UDQJH FW 2UDQJH FW 2UDQJH FW 2UDQJH FW 2UDQJH

VHO VHO¼ VHO¼ VHO¼ VHO¼
¼SDLG SDLG SDLG SDLG SDLG
¼
FRQILUP
¼

RUDQJH RUDQJH RUDQJH RUDQJH RUDQJH

¼ ¼

'ULQNVHO FW 'ULQNVHO FW 'ULQNVHO FW 'ULQNVHO FW 'ULQNVHO WHUP
¼SDLG ¼SDLG ¼SDLG ¼SDLG ¼SDLG

¼
OHPRQ OHPRQ OHPRQ OHPRQ OHPRQ
¼

FRQILUP
¼ ¼

/HPRQ FW /HPRQ FW /HPRQ FW /HPRQ FW /HPRQ

VHO VHO¼ VHO¼ VHO¼ VHO¼
¼SDLG SDLG SDLG SDLG SDLG

¼

¼

Fig. 6.16: State space of the soft drink vending machine shown in Fig. 4.7

To study the implications of this dependency, we examine the state space

of the soft drink vending machine, shown in Fig. 6.16.
Each state in the state space represents a pair of states in the soft drink
vending machine. This pair includes one state for each submachine. Therefore,
the state (Drink sel., 0 A
C paid) represents the state in which the state Drink
 6.3 State Spaces of Concurrent Systems 183

Selection is in the substate Drink Selection, while the state Payment is in the
substate 0 AC paid. The concurrent behaviour described by the state machine
with orthogonal states can be seen from the rather complex state space. To
keep the state space manageable, we have abstracted away the transition to
shut off the vending machine.
In the state space, the dependency between orthogonal states described
above is represented by the confirm transitions. These can only occur if
sufficient funds have been paid and the beverage has been chosen. Hence, any
dependency between orthogonal states reduces the concurrency of the state
space. In the example, for instance, a confirm transition is only possible if the
state machines of the orthogonal states are in the corresponding substates.

6.3.3 State Spaces of Petri Nets

Petri nets are an important formalism for representing concurrent behaviour.
We discussed their foundations in Section 4.3 and their role in formalising the
behaviour of business processes in Section 5.2.
Representing the state space of a Petri net (P, T, F ) with a set P of places,
a set T of transitions, and a flow relation F is straightforward. The state of a
Petri net is represented by a token distribution. We have formalised this token
distribution by a function M : P → N.

S S S S R
65 55 W 6$1

L S W S S S W S S
'5 65 55 '$

S S S S R
65 55 W 651

Fig. 6.17: Petri net in a state which is given by a marking

To illustrate the state space of a Petri net, we revisit a net representing a

business process with concurrency, as shown in Fig. 6.17. This figure shows
a Petri net with three tokens that collectively represent the state of the net.
Formally, the state is represented by a marking M , such that M (p2 ) = M (p4 ) =
M (p9 ) = 1 and M (p) = 0 otherwise, i.e., ∀ p ∈ P − {p2 , p4 , p9 }. The marking
M shown in the figure is represented by [p2 , p4 , p9 ].
States of place transition nets with multiple tokens on a given place are
represented by a list of places, where a superscript on a place name denotes
the number of tokens on that place. For instance, a marking of a Petri net with
three tokens on the place p1 , two tokens on the place p2 , and one token on p3
is represented by [p31 , p22 , p13 ]. For places with a single token, the superscript
can be omitted, so this state can also be represented by [p31 , p22 , p3 ].
184 6 State Spaces

Fig. 6.18: State space of the Petri net shown in Fig. 6.17
 6.3 State Spaces of Concurrent Systems 185

Based on the representation of states of Petri nets by markings, we now

investigate the state space of Petri nets.
Let the start state of the Petri net be [i], in which there is a single token
on the initial place and no other token in the net. It is a typical situation in
Petri nets representing business processes that the system starts with a single
token on a place which does not have any incoming arcs.
In the start state of the net shown in Fig. 6.17, only the transition DR
can fire, which results in a state transition to [p0 ]. When t1 fires, the state
[p1 , p2 , p3 ] is reached. There are three concurrent branches of the Petri net,
so that three continuations of the process are possible. Either SR1 , SR2 , or
SR3 can fire next, resulting in the states [p4 , p2 , p3 ], [p1 , p5 , p3 ], and [p1 , p2 , p6 ],
respectively. Notice that t2 can fire only in the state [p7 , p8 , p9 ], so that this
transition can fire only after the three concurrent branches have completed.
The complete state space is shown in Fig. 6.18. The figure was generated by
a tool called PIPE2, which uses generic labels for states. However, the labels
associated with the state transitions are the same as those in the Petri net, so
that the relationship of the Petri net to the state space is well represented.
The state S15 in Fig. 6.18 corresponds to the state of the Petri net shown
in Fig. 6.17. This state can be reached from the start state by following the
transitions labelled DR, t1 , SR1, SR3, RR3 .
This section has shown how the state spaces of Petri nets can be computed.
Each state in a Petri net is represented by a distribution of tokens in the
net. Since Petri nets abstract concrete values away, typically no valuation
function is associated with the state spaces of Petri nets. If a Petri net contains
variables, as for instance coloured Petri nets do, the values of these variables
also contribute to a state. Therefore, the same concepts as used for capturing
the states of extended automata can also be used to capture the states of Petri
nets.

Bibliographical Notes
Some of the approaches to modelling the behaviour of discrete dynamic systems
also look at the state spaces generated by those models. There are several
different tools for computing the state space of concurrent systems. In this
chapter we used PIPE2 to compute the state space shown in Fig. 6.18. More
information about that tool can be found at http://pipe2.sourceforge.net/.
The state explosion problem was discussed by Valmari (1998). Techniques
to reduce the state space of concurrent systems were introduced by Clarke
et al. (1999a). There are several different semantics that can be associated
with models that capture concurrent behaviour. In this book we have used
interleaving semantics, which captures the behaviour by all possible interleav-
ings of actions. There is also truly concurrent semantics; readers interested in
this advanced topic are referred to Winskel and Nielsen (1995). An overview of
different execution semantics for Petri nets was given by Juhás et al. (2007).
7
Comparing Behaviour

In the previous chapter, we have shown how state spaces can be used to
capture the behaviour of discrete dynamic system models, expressed in dif-
ferent modelling languages. In this chapter, we investigate how this universal
representation allows us to compare behavioural models.
Behavioural comparison of systems is essential in a number of situations.
Take, for instance, a model of a system’s interactions, which abstracts away
the internal behaviour of the system. This model can be represented, for
instance, as a sequence diagram. The internal behaviour of the system can be
represented by another model, for instance a state machine.
In order to ensure that an implementation of the system complies with
its specification, one needs to compare the two models and verify that they
show the same behaviour regarding interactions. To address these issues, this
chapter introduces notions of behavioural equivalence.
We can also use comparison of models of the same system. Recently, the
development of software systems has seen a major paradigm shift. A software
system is no longer a final product, but rather is under constant evolution
and modernisation. Replacing a component of a software system with a more
efficient or more versatile one must not break the overall system. This can
be ensured by comparing the behaviour of the two components and showing
that the new component refines the behaviour of the old one. The concept of
behavioural inheritance can be used to investigate these properties.
In addition to behavioural equivalence and inheritance, behavioural similar-
ity is also investigated in this chapter. This concept is less strict and allows us
to measure to what degree two systems resemble each other, even if they show
distinct behavioural features. Behavioural similarity enables one, for instance,
to search among a number of system models to avoid creating duplicates of
what already exists and, thus, can help one to reduce the maintenance effort
related to the management of model repositories.
A large body of research work has addressed how the behaviour of two
systems can be compared, including behavioural equivalence, behavioural
inheritance, and behavioural similarity. In this chapter, we cover the most

© Springer International Publishing Switzerland 2016 187

M. Kunze and M. Weske, Behavioural Models,
DOI 10.1007/978-3-319-44960-9_7
188 7 Comparing Behaviour

prominent approaches to comparing the behaviour of systems. For each of

these comparison methods, a number of approaches based on state spaces will
be discussed. Using state spaces allows us to compare behavioural models inde-
pendently of the modelling language that has been used for their specification.
The bibliographical notes at the end of the chapter point to further material
that will allow readers to study the topic in more detail.

7.1 Behavioural Equivalence

This section considers how one investigates whether two systems or, more pre-
cisely, two system models show equivalent behaviour. Behavioural equivalence
serves various purposes, for example to compare two different models that
describe a given system from different perspectives.
To facilitate comparing behavioural models that are specified in different
languages, state spaces can be used as a unified representation of system
behaviour, as discussed in Chapter 6. However, different models may result in
different state spaces that nevertheless represent the same behaviour.

E E

V V
V V V V
D D E D
(a) (b)

Fig. 7.1: Different state spaces with the same behaviour

To illustrate this observation, Fig. 7.1 shows an example of two state spaces
that express the very same behaviour. Both systems allow actions a and b to
be executed in an alternating fashion, starting with a and terminating with
b. In both systems, arbitrarily many iterations of this pair of events can be
executed.
Following the above reasoning, behavioural equivalence cannot be defined
on the basis of the structure of state spaces. Therefore, the notion of an
impartial observer who monitors a running system and observes the events
that occur has been devised. Based on this concept, behavioural equivalence
can be defined as follows.
Two systems are behaviourally equivalent if an observer is not able to
distinguish their behaviours.

This notion provides a framework to define different equivalence relations:

whether two systems can be distinguished depends on the particular observer
 7.1 Behavioural Equivalence 189

employed. Observers differ in the information that they take into account
during observation.
For example, one observer might only consider the actions that two systems
can carry out, whereas another observer could also rely on decisions that
can be taken during a system run. Hence, equivalence relations differ in the
definition of an observer and the abstraction that the observer applies when
comparing systems.
Behavioural equivalence can be considered as a binary relation between
system models. Let M be the set of models; then E ⊆ M × M is an equivalence
relation. If two models m1 , m2 ∈ M are equivalent, then (m1 , m2 ) ∈ E. Based
on this notion, we shall now discuss properties of behavioural equivalence
relations.
Any equivalence relation – and therefore also E – is reflexive, symmetric,
and transitive. E is reflexive because a model is always equivalent to itself; it
holds that ∀ m ∈ M : (m, m) ∈ E.
It is symmetric; that is, if one system is equivalent to another system, then
the second system is also equivalent to the first system. Mathematically we
can express this property as ∀ m1 , m2 ∈ M : (m1 , m2 ) ∈ E =⇒ (m2 , m1 ) ∈ E.
Equivalences are transitive, meaning that if one system is equivalent to a
second system and the second system is equivalent to a third system, then the
first and the third system are also equivalent: ∀ m1 , m2 , m3 ∈ M : ((m1 , m2 ) ∈
E ∧ (m2 , m3 ) ∈ E) =⇒ (m1 , m3 ) ∈ E.
These properties allow many different system models to be partitioned into
clusters, called equivalence classes, where all members of one class are pairwise
equivalent in their behaviour.
To decide consistency between two behavioural models, an observer is
used. This observer assumes the abstraction of the more abstract of the two
system models, i.e., the behavioural interface, and tries to mimic all possible
behaviours of this model in the internal behaviour.
The observer is capable of monitoring only the publicly observable actions,
which are the sending and receiving of messages. The general idea is as follows.
If the behavioural interface and the internal behaviour are equivalent in their
actions from the viewpoint of the observer, they are consistent.
Since the internal behaviour shows more detail than the behavioural inter-
face, we understand the internal behaviour of a system as a refinement of its
behavioural interface. Refinements allow traversing between different levels of
abstraction. A behavioural interface, for instance, is more abstract than an
implementation of a system, as it abstracts away the internal behaviour and
incorporates only those concepts that are relevant for the system’s interaction
with other systems.
In one or several refinement steps, the level of abstraction is lowered by
adding internal actions and decisions. However, not all possible refinements
preserve an implementation’s consistency with its specification; this requires
us to establish a relation between the implementation and its specification and
to examine it.
190 7 Comparing Behaviour

To compare the internal behaviour of a system with its interface, we need

to find a way to ignore internal actions of a system that cannot be observed
and, consequently, do not have any effect on the behavioural interface.

7.1.1 Practical Applications

Above, we have elaborated on the role of notions of equivalence in comparing

two system models that represent behaviour at the same level of abstraction.
However, these notions can also be used to compare behavioural models on
different levels of abstraction. This occurs, for instance, when one is comparing
the interaction behaviour of a system with its internal implementation.
In Section 4.2, message-based communication was introduced as a means
to describe interactions between systems. Sequence diagrams, for instance,
abstract away the internal behaviour of a system and explicitly capture only
that part of the system’s behaviour that is relevant for its interaction with
other systems.
This enables agreement about an interaction among several participants
without the need to disclose the internals of the participants’ systems. To
illustrate this aspect and to justify the use of ideas of equivalence to compare
the behaviour of system models that define different aspects of a given system,
an example is depicted in Fig. 7.2.
In this example, we return to the online shop introduced earlier in this
book. The online shop allows customers to select products, and it also provides
functionalities for invoicing and shipment. The behaviour of the online shop is
represented by two models, one of which focuses only on the interactions of
the online shop with a customer, while the other model represents the internal
behaviour of the shop.
In Fig. 7.2a, the shop’s public behaviour is shown, using a sequence diagram.
The internal behaviour of the shop is shown in Fig. 7.2b, using a state machine.
The interaction model shows that each interaction starts with a customer
placing an order. This synchronous communication might be achieved by
the customer clicking on the checkout button in their web browser. After it
has received the order, the online shop sends an invoice. This asynchronous
communication models an email conversation between the online shop and the
customer.
At a later point, the customer pays the amount stated in the invoice, for
instance using a bank transfer. This is modelled by an asynchronous message,
because the customer does not wait for the funds to arrive, which will take
a couple of days, owing to the processing time of the bank. Here, the model
abstracts away the participation of a bank. Finally, the shop sends the products
to the customer.
Investigating the internal behaviour of the online shop in Fig. 7.2b, we
observe a number of actions that are not reflected in the interaction. One
example is the check of whether the ordered products are in stock, and the
appropriate actions. If the products are in stock, they are reserved for the
 7.1 Behavioural Equivalence 191

5HDG\

UHFHLYH
RUGHU

2UGHU
SODFHG
>SURGXFWVLQVWRFN@ >SURGXFWV
UHVHUYHSURGXFWV QRWLQVWRFN@

,QYRLFH %DFN2UGHU
3URGXFWV
UHVHUYHG

VHQG VHQG EDFNRUGHU

LQYRLFH LQYRLFH SURGXFWV
3URGXFWV
,QYRLFH ,QYRLFH EDFN
UHFHLYHG UHFHLYHG
RUGHUHG
&XVWRPHU 2QOLQH6KRS UHFHLYH UHFHLYH UHFHLYH
SD\PHQW SD\PHQW SURGXFWV

SODFHRUGHU 3D\PHQW 3D\PHQW 3URGXFWV

UHFHLYHG UHFHLYHG UHFHLYHG

VHQGLQYRLFH

VHQG VHQG
SD\DPRXQW VKLSPHQW VKLSPHQW
SURGXFWV
VHQW

VHQGVKLSPHQW DUFKLYH
RUGHU

(a) Interaction model (b) Model of internal behaviour

Fig. 7.2: Behavioural models of an online shop

customer, to be shipped as soon as the customer’s payment arrives. Otherwise,

products need to be back-ordered, while the payment is settled with the
customer concurrently. In this case, the goods can only be sent if the orthogonal
state has terminated, i.e., if the back-ordered goods have been received and
the customer has paid.
Since the behaviour of the online shop is defined by two models, there
must not be any contradictions in the behaviour specified by these models.
We adopt the following terminology: the interaction model expressed by the
sequence diagram is referred to as the behavioural interface, because it shows
only the interface of the system.
192 7 Comparing Behaviour

The relationships between the behavioural interfaces and internal be-

haviours of interacting systems and participants are shown in Fig. 7.3. For
each participant in an interaction, here the buyer and seller, the respective
behavioural interface is shown by a grey rectangle. The internal actions, events,
and decisions of these systems are defined in the internal behaviour, represented
by white rectangles. Note that the impartial observer introduced above is able
to observe only interactions, and not internal actions.

%X\HU 6HOOHU
%X\HU 6HOOHU
LQWHUIDFH LQWHUIDFH
%X\HUQ 6HOOHUQ

&RPSDWLELOLW\ &RQVLVWHQF\

Fig. 7.3: Consistency and compatibility in the interaction of systems

Using this figure, we introduce the terms compatibility and consistency.

Compatibility between a set of behavioural interfaces ensures that their inter-
action is correct. This means that all messages sent can also be received and
that the interaction does not lead to a deadlock situation, in which a partner
gets stuck, owing to incorrect interactions. Checking compatibility requires
notions of behavioural correctness, which we shall introduce in Chapter 8.
The relation between the behavioural interface of a system and its internal
behaviour is referred to as consistency. If the internal behaviour is consistent
with the behavioural interface, then the system behaves as specified in the
interaction model.
If we ensure compatibility between the behavioural interfaces and consis-
tency between every system’s interface and its internal behaviour, it is not
required to check whether the internal behaviour of one system is compatible
with the internal behaviour of another system. That is, interaction partners
need only to agree on their observable behaviour and can ensure proper
interaction by locally verifying the consistency of a system’s internal behaviour
with its interaction interface.
A benefit of the separation between compatibility and consistency is
reusability of behavioural interfaces and the separation of concerns about
the interfaces and implementations. Once the interaction has been defined,
customers can interact safely with a number of different online shops, if their
internal behaviour is consistent with the same behavioural interface.
In the remainder of this section, we shall use the online shop as a running
example, but reduce its complexity for ease of presentation.
 7.1 Behavioural Equivalence 193

7.1.2 Trace Equivalence

Trace equivalence is the first type of equivalence that we introduce. It is based

on the assumption that the behaviour of a system can be characterised by the
set of traces that it can produce. We have already elaborated on traces earlier in
this book, using the term “complete execution sequences” in subsection 3.1.1.
In that context we stated that the language of an automaton – the behaviour
of the system modelled by the automaton – consists of the set of all complete
execution sequences, or traces. The same applies to state spaces.
This means that we can use traces of state spaces to characterise system
behaviour. A trace corresponds to a complete execution sequence that starts
in the initial state and terminates in a final state. Given this preliminary
definition, two systems are trace equivalent if they allow the same set of traces
to occur.

Definition 7.1 Let m1 , m2 ∈ M , and let A1 = M(m1 ), A2 = M(m2 ) be the

automata that represent the respective state spaces. The models m1 and m2
are trace equivalent iff the traces generated by the two automata are identical,
i.e., iff LA1 = LA2 . 

For an example of trace equivalence, we investigate three actions that are

carried out as part of the process of handling a purchase order in an online shop:
send shipment (a), send invoice (b), and settle payment (c). These actions can
be carried out independently of each other, i.e., they are concurrent. For
example, customers may pay the amount due immediately after ordering and
before the online shop sends the shipment and invoice. Any other order of
these actions is assumed to be valid as well.

D E F

D F E

E D F

E F D D

F D E E

F E D F

(a) m1 (b) m2

Fig. 7.4: Two BPMN business process diagrams that specify concurrent execu-
tions
194 7 Comparing Behaviour

Figure 7.4 shows two BPMN business process diagrams, m1 and m2 . These
models are different in their structure, but they use the same set of activities.
These models will now be used to study trace equivalence in detail.
As a first step in the task of deciding the trace equivalence of these models,
the corresponding state spaces are derived from m1 and m2 . These state
spaces are shown in Fig. 7.5. For the sake of readability, we have used the
abbreviations a, b, and c for the actions above.

D E F
V V

V F V
D E
D
E V V F
E
V V
V V
E F D F D F
V V D

F E E E
V V V V
D
V V
F D F D
F E D
V V V V
E

(a) (b)

Fig. 7.5: State spaces of the BPMN business process diagrams shown in Fig. 7.4

We observe that the state spaces differ in the number of states and in the
state transitions as well. In Fig. 7.5a, the order in which the actions are carried
out is chosen in the first state, resulting in six different sequences of these
actions. Nevertheless, any ordering of these actions is allowed.
In contrast, Fig. 7.5b allows one to choose from the set of actions stepwise.
First, an action can be chosen from all actions. After the first action is executed,
the next action can be chosen from the remaining two, and so on.
We first look at the traces of the state space A1 , shown in Fig. 7.5a, of the
business process model m1 .

LA1 = { a, b, c , a, c, b , b, a, c , b, c, a , c, a, b , c, b, a }

Next, the traces of the process model m2 are investigated; its state space,
A2 , is shown in Fig. 7.5b. Choosing the upper branch results in the trace
a, b, c . However, after choosing a we can also select c next, which results in
the trace a, c, b . Consequently, the state space of m2 shows exactly the same
set of traces as m1 . Therefore the languages of the state spaces are identical:
LA1 = LA2 . As a result, the business process diagrams m1 and m2 shown in
Fig. 7.4 are trace equivalent.
 7.1 Behavioural Equivalence 195

The trace equivalence introduced so far does not take the internal actions
of the systems into account. Rather, both business process models use the
same set of actions; they are on the same level of abstraction.
On the other hand, the abstraction of the internal state of a system is an
apt assumption when one is reasoning about the interaction of systems, as we
have argued in subsection 4.2.1. Therefore, trace equivalence is a well-suited
candidate for verifying that a behavioural interface fits its implementation.
To use trace equivalence, however, it is necessary to ignore the internal state
transitions that are not represented in the behavioural interface.

VHQG VHQG UHFHLYH

LQYRLFH V VKLSPHQW UHWXUQ V
UHFHLYH
RUGHU
V V V

VHQG VHQG UHFHLYH

VKLSPHQW V LQYRLFH SD\PHQW V

Fig. 7.6: Behavioural interface of the order-handling process of an online shop

Figure 7.6 shows the behavioural interface of an online shop – the seller of
the goods in the above scenario. The process starts with the shop receiving
the order from a customer, followed by the concurrent sending of the shipment
and the invoice, which is then followed either by the receipt of the payment or
by the receipt of returned goods from the customer.
The behavioural interface of the order-handling process is composed only
of the send and receive actions that are required for the interaction with the
customer. This model produces the following traces:

receive order, send invoice, send shipment, receive payment ,

receive order, send shipment, send invoice, receive payment ,
receive order, send invoice, send shipment, receive return ,
receive order, send shipment, send invoice, receive return .

Because the sending of the shipment and of the invoice are concurrent, they can
occur in either order. Additionally, the process needs to distinguish between
two alternative incoming messages, i.e., the receipt of the payment and of the
returned goods, which results in four different traces.
If we look at the internal behaviour of the order handling process depicted
in Fig. 7.7, we perceive more actions that show up in the traces, as illustrated
by the following trace:

receive order, prepare shipment, send shipment,

send invoice, receive return, close order .
196 7 Comparing Behaviour

UHFHLYH FORVH
UHWXUQ T RUGHU
UHFHLYH SUHSDUH VHQG VHQG
RUGHU VKLSPHQW LQYRLFH VKLSPHQW
T T T T T T

UHFHLYH FORVH
SD\PHQW T RUGHU

Fig. 7.7: Internal behaviour of the order-handling process of an online shop

This trace is not reflected in the behavioural interface at all. However, to

compare the behavioural interface of a system and its internal behaviour, we
need to ignore the internal actions, i.e., the actions underlined above, which are
not contained in the behavioural interface. The observer deciding equivalence
is only capable of monitoring publicly observable actions.
Hence, internal actions are represented by silent transitions and are therefore
removed from the traces before comparing those traces with the traces of the
behavioural interface. For the above trace, the removal of internal actions leads
to the following trace:

receive order, send shipment, send invoice, receive return .

This trace is also contained in the set of traces of the behavioural interface,
which means that, for this trace, the implementation complies with the be-
havioural interface. However, in order to decide trace equivalence between a
behavioural interface and the internal behaviour of a system implementing
that interface, this property must hold for all traces.
Looking at the internal behaviour of the order-handling process, we observe
that the shipment is always sent before the invoice. While this may be a
valid assumption for an implementation of the online shop, it violates the
specification of the behavioural interface, which states that either of these
actions may occur before the other.
This means that a trace that is allowed by the interface is not allowed by
the implementation. Therefore, the behavioural interface, Fig. 7.6, and the
internal behaviour in Fig. 7.7 are not trace equivalent.
As a consequence, the internal behaviour cannot be used to handle orders
in the online shop. Since interaction partners rely only on the specification
of the interface, a customer may insist on receiving an invoice first and only
afterwards the shipment, as offered by the online shop’s behavioural interface.
If the communication with the customer is synchronous, the customer would
wait forever for the invoice while being incapable of receiving the shipment.
Figure 7.8 shows the internal behaviour of another order-handling process.
In contrast to Fig. 7.7, it provides explicitly for the selling of a gift voucher,
which is shipped and invoiced like a regular order. However, gift vouchers are
non-refundable and, therefore, the customer may not send the order back but
has to pay in every case.
 7.1 Behavioural Equivalence 197

VHQG VHQG
LQYRLFH U VKLSPHQW

U U U U
SUHSDUH UHFHLYH
VKLSPHQW SD\PHQW
LVJLIW VHQG VHQG FORVH
VKLSPHQW U LQYRLFH
YRXFKHU RUGHU

UHFHLYH DQDO\VH
RUGHU RUGHU UHFHLYH
U U U SD\PHQW U

LVQRWJLIW FORVH
YRXFKHU VHQG VHQG RUGHU
LQYRLFH U VKLSPHQW

U U U U

SUHSDUH UHFHLYH
VKLSPHQW UHWXUQ
VHQG VHQG
VKLSPHQW U LQYRLFH

Fig. 7.8: Internal behaviour of an order-handling process that allows the buying
of gift vouchers

Looking at the publicly observable traces of this model, it is obvious that

all four traces of the behavioural interface shown in Fig. 7.6 are reflected.
Furthermore, the internal behaviour does not add additional traces that are
not mirrored by the interfaces. Because the trace sets of the two systems –
behavioural interface and internal behaviour – are identical, these systems
are trace equivalent. Consequently, the internal behaviour complies with the
specification of the interface from the perspective of an observer who is deciding
trace equivalence.
However, if we look at the state spaces of the two systems, a considerable
difference can be uncovered. The behavioural interface always lets the customer
decide whether they want to pay the invoice or return the ordered goods. In
the internal behaviour, however, this choice is not available to the customer
if they have ordered a gift voucher. Despite trace equivalence, these systems
may be considered not to be in compliance, because the choice of whether to
pay or return the goods is made at different points in the state space.

7.1.3 Bisimulation

The inability to determine the moment of choice in behavioural systems is

one of the main drawbacks of trace equivalence. In response to this weakness,
bisimulation was introduced, which is a stronger equivalence criterion than
trace equivalence and asserts that two systems can simulate each other, hence
the name.
To characterise simulations of automata, we adopt the perspective of an ob-
server once more. However, since we are interested in the point where execution
sequences diverge from each other, this observer is capable of recording not
198 7 Comparing Behaviour

only traces, but also the choices that are offered by a system during observation.
Hence, a bisimulation observer also takes into account the alternative state
transitions that can be processed in every state of a system.
Simulation means that if one system offers a choice, i.e., a set of alternative
state transitions in a certain state, any equivalent system must offer the same
set of state transitions in a corresponding state. Bisimulation requires that
the simulation property is symmetric, i.e., that two behavioural models can
simulate each other. The correspondence of states is denoted by a bisimulation
relation between two systems.

Definition 7.2 Let A = (S, Σ, δ, s0 , F ) and A = (S  , Σ  , δ  , s0 , F  ) be state

spaces with initial states s0 and s0 , respectively. B ⊆ S × S  is a bisimulation
relation between the states of these systems if and only if

i. (s0 , s0 ) ∈ B,
ii. (x, x ) ∈ B ∧ (x, l, y) ∈ δ =⇒ ∃ y  ∈ S  : (x , l, y  ) ∈ δ  ∧ (y, y  ) ∈ B,
iii. (x, x ) ∈ B ∧ (x , l, y  ) ∈ δ  =⇒ ∃ y ∈ S : (x, l, y) ∈ δ ∧ (y, y  ) ∈ B.

If every state of A and A is included in the bisimulation relation, then these

systems are bisimulation equivalent or bisimilar. 

The above definition ensures that the state spaces of two systems simulate
each other by establishing a correspondence between states that offer the same
set of state transitions. If the state spaces simulate each other, the systems
described by those state spaces are bisimulation equivalent, or bisimilar.
To illustrate bisimulation, we shall use an abstract example before returning
to our online shop later. Consider the automata depicted in Fig. 7.9. Note that,
while the system in Fig. 7.9b, consisting of the states {s1 , s2 , s3 , s4 }, is deter-
ministic, the system in Fig. 7.9a, which consists of the states {q1 , q2 , q3 , q4 , q5 },
is non-deterministic owing to the non-deterministic choice with label a in the
state q1 . Nevertheless, both systems produce exactly the same set of traces,
{ a, b , a, c }, and are therefore trace equivalent.
We will now investigate if these systems are also bisimilar. The first con-
dition of Definition 7.2 requires that the initial states of the two systems
correspond to each other, which means that they are one tuple in the bisimula-
tion relation B. Since bisimulation is a symmetric relation, s0 must correspond
to s0 and vice versa. In the example in Fig. 7.9, this constitutes the initial
tuple in the bisimulation relation, i.e., (q1 , s1 ) ∈ B.
The second condition of the definition states that if two states simulate each
other, i.e., (x, x ) ∈ B, then both states must offer the same state transitions.
This means that if there exists a state transition with label l ∈ Σ that originates
from x and leads to y, i.e., (x, l, y) ∈ δ, then there must also exist a state
transition with the same label l ∈ Σ that leads from x to a state y  , i.e.,
(x , l, y  ) ∈ δ  . Furthermore, the target states of these transitions must also
 7.1 Behavioural Equivalence 199

T
D E

T T V
E
D E D
T V V

F F
T V

(a) Non-deterministic system (b) Deterministic system

Fig. 7.9: Automata representing state spaces

be in the bisimulation relation, i.e., (y, y  ) ∈ B. This condition must hold for
every state x ∈ S and every transition that originates from x.
In our example, the state q1 in Fig. 7.9a has two state transitions labelled
a. For each target state of these transitions, q2 and q5 , there must be a
corresponding state in Fig. 7.9b to satisfy bisimilarity. Looking at the system,
we observe only one state transition labelled a. Hence, the state s2 is the
corresponding state for both q2 and q5 , i.e., (q2 , s2 ) ∈ B and (q5 , s2 ) ∈ B.
Consequently, both of these states must offer the same set of choices of state
transitions themselves. The state q5 has a state transition labelled b, leading
to q3 , which is mirrored in Fig. 7.9b by the state transition from s2 to s3 ,
i.e., (q3 , s3 ) ∈ B. Likewise, both of the state transitions b and c from q2 are
mirrored, leading to (q3 , s3 ) ∈ B and (q4 , s4 ) ∈ B.
Since the two systems are rooted in corresponding initial states, the above
definition ensures that, no matter how far the two systems proceed in a mutual
simulation, each state transition in one system will be simulated by the other
system, leading to corresponding states. The example shows how rooting the
bisimulation relation in the initial states of two systems being compared leads
to chaining of corresponding states and state transitions.
We have already shown that the second condition holds for our systems,
that is, the deterministic system in Fig. 7.9b simulates the non-deterministic
system in Fig. 7.9a. To verify bisimilarity of these systems, we must also show
that the non-deterministic system simulates the deterministic system. Looking
at the systems in Fig. 7.9, it becomes clear that this is not the case, because
of different moments of choice. In the deterministic system in Fig. 7.9b the
choice between b and c is made after a, whereas this is not the case in the
non-deterministic system in (a). If the state transition to q5 labelled a is chosen,
then it is not possible to choose between b and c any more. The transition b is
the only continuation offered in this state.
One might ask why we chose a non-deterministic system in the example
above. The reason is as follows. For two deterministic systems that are without
silent state transitions and produce finite sets of bounded traces, bisimulation
and trace equivalence coincide.
200 7 Comparing Behaviour

In a deterministic system, every choice can be made only from a set of

state transitions with different inputs. As a consequence, it is not possible to
have identical traces with different moments of choice, because at the moment
of choice the traces of a deterministic system diverge. In contrast, in a non-
deterministic system, a choice between two state transitions with identical
inputs is possible. This is illustrated by the state q1 of Fig. 7.9a, which offers
a choice between two state transitions with the same label.
We have introduced behavioural equivalence as a way to compare a system’s
behavioural interface with its internal behaviour, where the internal behaviour
includes actions that are not visible to an external observer. As a consequence,
the internal actions of the deterministic system depicted in Fig. 7.8 are invisible.
The view of a bisimulation observer of the system looks like Fig. 7.10, where
the symbol τ represents silent state transitions.

VHQG VHQG
LQYRLFH U VKLSPHQW

U U U U
IJ UHFHLYH
SD\PHQW
VHQG VHQG
IJ VKLSPHQW U LQYRLFH IJ

UHFHLYH
RUGHU IJ UHFHLYH
U U U SD\PHQW U

IJ VHQG VHQG IJ
LQYRLFH U VKLSPHQW

U U U U

IJ UHFHLYH
UHWXUQ
VHQG VHQG
VKLSPHQW U LQYRLFH

Fig. 7.10: View of an observer of the internal behaviour of an order handling

process

Recall that a bisimulation observer is capable of observing all state transi-

tions, but cannot distinguish internal state transitions from one another. That
is the reason why all internal state transitions have been labelled with τ in
Fig. 7.10. Although the internal behaviour is deterministic, the choices made
internally cannot be distinguished by the observer, and hence they are treated
as non-deterministic. Therefore, bisimulation offers a more accurate means to
ensure equivalence of a system’s specification and implementation.
Nevertheless, the above definition of bisimilarity is not suitable for compar-
ing a behavioural interface with the internal behaviour of a system, because it
does not take silent state transitions into account. Comparing the behavioural
interface of the order-handling process presented on page 195 and the internal
behaviour of the system shown in Fig. 7.10, we conclude that the states r2  ,
 7.1 Behavioural Equivalence 201

r3  , r4  , r9  , r10  , r15  , and r13  cannot participate in the bisimulation relation,

because the interface does not offer corresponding states.
Therefore, variants of bisimulation have been proposed that also account for
silent state transitions, namely weak bisimulation and branching bisimulation.

Weak Bisimulation

Weak bisimulation is based on the assumption that an observer can only

determine traces of observable actions and the choices that are offered by a
system, and is not capable of detecting the internal evolution of the system
being observed. Therefore, weak bisimulation requires that if one system offers
a set of alternative state transitions in one state, each of these choices must
be offered in the first corresponding state or after a sequence of unobservable
state transitions.
Formally, this is expressed by relaxing conditions ii and iii of Definition 7.2.

Definition 7.3 Let A = (S, Σ, δ, s0 , F ) and A = (S  , Σ  , δ  , s0 , F  ) be state

spaces with initial states s0 and s0 , respectively. B ⊆ S × S  is a weak bisimu-
lation relation between the states of these systems, if and only if:

i. The initial states of A and A are in the bisimulation relation: (s0 , s0 ) ∈ B.
ii. If (x, x ) ∈ B and (x, l, y) ∈ δ then it must be true that either l = τ and
(y, x ) ∈ B or there exists a sequence σ  = τ, . . . , τ, l, τ, . . . , τ that leads
from x to y  , i.e., (x , σ  , y  ) ∈ δ ∗  and (y, y  ) ∈ B.
iii. If (x, x ) ∈ B and (x , l, y  ) ∈ δ then it must be true that either l = τ and
(x, y  ) ∈ B or there exists a sequence σ = τ, . . . , τ, l, τ, . . . , τ that leads
from x to y, i.e., (x, σ, y) ∈ δ ∗ and (y, y  ) ∈ B. 

If every state of A and A is included in the weak bisimulation relation,

then these systems are weak bisimulation equivalent or weak bisimilar.
In the above definition, the subsequence τ, . . . , τ represents any sequence,
possibly empty, consisting only of silent transitions in the internal behaviour
from the viewpoint of an observer. The third condition of the definition of
bisimulation is relaxed in the part of the above definition that mirrors it.
The relaxed bisimulation condition is illustrated by the example shown in
Fig. 7.11, which represents yet another internal behaviour of the behavioural
interface of the order-handling process presented on page 195. This figure shows
the system from an observer’s viewpoint, that is, all internal state transitions
are indistinguishable and therefore labelled τ . We have numbered these actions
only for the sake of comprehension. τ1 represents the action prepare shipment,
and τ2 stands for resupply stock. The latter action is used to update the stock
some time after a shipment has been sent. However, it is possible that the
customer may return the goods before the stock is resupplied, in which case a
resupply is not necessary any more.
202 7 Comparing Behaviour
UHFHLYHUHWXUQ

VHQG VHQG UHFHLYH

LQYRLFH X VKLSPHQW UHWXUQ X
UHFHLYH
RUGHU IJ IJ
X X X X X

VHQG VHQG UHFHLYH

VKLSPHQW X LQYRLFH SD\PHQW X

Fig. 7.11: Another order-handling process, with silent transitions

Starting from the initial states of the behavioural interface shown in

Fig. 7.6 and the system shown in Fig. 7.11, we observe that the initial states
of the two systems are in a weak bisimulation relation: (s1 , u1 ) ∈ B. Since
both systems offer the transition receive order in both states, we also have
(s2 , u2 ) ∈ B. Following the above relaxation of bisimulation, we conclude that
also (s2 , u3 ) ∈ B, because the state transition from u2 to u3 is silent and s2
and u3 offer the same set of state transitions, send invoice and send shipment,
to choose from. Furthermore, we can work out that (s3 , u4 ) and (s4 , u5 ) are
bisimilar states.
The state u6 in Fig. 7.11 illustrates the second relaxation of the original
definition of bisimulation. If (s5 , u6 ) ∈ B, then they must offer the same
choices, receive return and receive invoice, each after a possibly empty set
of silent state transitions. This is in fact the case, because u6 offers a state
transition receive return to u8 and a sequence τ, receive payment to u9 . The
“shortcut” with the different moment of choice provided by the state u6 is not
problematic, as it leads directly to one of the choices offered in the behavioural
interface, but preserves all options for choice if this “shortcut” is not taken.
The same applies for the mirrored condition iii in Definition 7.3.
From here, it follows straightforwardly that (s7 , u8 ) and (s6 , u9 ) are in the
bisimulation relation, and we conclude that the behavioural interface and the
internal behaviour are, indeed, weak bisimulation equivalent.

Branching Bisimulation
Branching bisimulation is a stronger notion of equivalence than weak bisimula-
tion and preserves the branching structure of a system even in the presence of
silent transitions, hence its name. Branching bisimulation requires that the
same set of choices is offered before and after each unobservable action. Hence,
where weak bisimulation abstracts away the internal evolution of a system,
branching bisimulation takes all intermediate steps into account.
Formally, branching bisimulation requires the following reformulation of
the definition of bisimulation presented in Definition 7.2.

Definition 7.4 Let A = (S, Σ, δ, s0 , F ) and A = (S  , Σ  , δ  , s0 , F  ) be state

spaces with initial states s0 and s0 , respectively. B ⊆ S × S  is a weak bisimu-
lation relation between the states of these systems if and only if
 7.1 Behavioural Equivalence 203

i. The initial states of A and A are in the bisimulation relation: (s0 , s0 ) ∈ B.
ii. If (x, x ) ∈ B and (x, l, y) ∈ δ then it must be true that either l = τ and
(y, x ) or there exists a sequence σ  = τ, . . . , τ, l, τ, . . . , τ that leads from
x to y  , i.e., (x , σ  , y  ) ∈ δ ∗  , such that every state si passed through
in this sequence corresponds to x , i.e., ∀ 1 ≤ i < |σ  | : (x, si ) ∈ B, and
(y, y  ) ∈ B.
iii. If (x, x ) ∈ B and (x , l, y  ) ∈ δ then it must be true that either l = τ and
(x, y  ) or there exists a sequence σ  = τ, . . . , τ, l, τ, . . . , τ that leads from
x to y, i.e., (x, σ, y) ∈ δ ∗ , such that every state si passed through in this
sequence corresponds to x , i.e., ∀ 1 ≤ i < |σ| : (x , si ) ∈ B, and (y, y  ) ∈ B.


The internal behaviour of the order-handling process depicted in Fig. 7.11

is not branching bisimulation equivalent to the behavioural interface shown in
Fig. 7.6 because the branching structure of the interface is lost in the internal
behaviour. For branching bisimulation to hold, the state u2 in Fig. 7.11 would
need to offer the state transitions send shipment and send invoice as well.
Likewise, the state u6 would need to offer receive payment as an additional
alternative.
From a practical point of view, branching bisimulation is very strict. The
above example shows that it may in fact be too strict for many use cases
where a behavioural interface and a corresponding internal behaviour are to
be compared.
Consider a case where systems communicate using only asynchronous
communication without buffers (see page 98). In such a case, the receiver
must be ready to receive a message at the exact time when it arrives, as the
message is not stored until the receiver is ready to accept it. Here, branching
bisimulation equivalence ensures that the receiver is always in a state that offers
the same communication capabilities as those promised by its specification –
the behavioural interface. Hence, a communication partner can safely rely on
the interface without the need to worry about the internal state of the other
partner.

7.1.4 Discussion

Above, we have introduced trace equivalence, weak bisimulation, and branch-

ing bisimulation as equivalence relations for behavioural models. Consistency
between a behavioural interface and the internal behaviour of a system imple-
menting that interface was introduced as an important application of these
equivalence relations. Consistency ensures that interaction partners that rely
on the compatibility of their interfaces can interact successfully with one
another without the need to verify consistency of their internal behaviour.
We have already mentioned that these equivalence relations differ in their
204 7 Comparing Behaviour

capability to distinguish systems. In fact, they show a clear hierarchy in their

discriminating power.

V Y
D D

V Y IJ
E IJ E
V Y Y

(a) (b)

U
D
D
T T U U
IJ D
IJ
T U
IJ E E
T T U

(c) (d)

X
D

X
IJ X

E
X

(e)

Fig. 7.12: State spaces of various system models, used to illustrate different
equivalence relations

We say that an equivalence relations A is more discriminating than an

equivalence relation B, denoted by A  B, if all pairs of models that are
equivalent in A are also equivalent in B, whereas models that are equivalent
in B may be distinguished in A. Vice versa, this means that systems that are
not equivalent in B are also not equivalent in A. The equivalence relations
introduced in this section show the following hierarchy in their discriminating
power:

branching bisimulation  weak bisimulation  trace equivalence

This hierarchy is illustrated by the behavioural models shown in Fig. 7.12
and described in Table 7.1, for which we have chosen models that allow the
differences between the equivalence relations covered here to be characterised.
 7.1 Behavioural Equivalence 205

In the following, we briefly compare pairs of models in Fig. 7.12 and discuss
whether the models are equivalent with respect to an equivalence relation.
Recall that equivalence relations are transitive.

Table 7.1: Equivalence relations for pairs of the models shown in Fig. 7.12

Fig. 7.12 (a) + (b) (a) + (c) (a) + (d) (a) + (e)
trace equivalence   
weak bisimulation equivalence  
branching bisimulation equivalence 

Trace equivalence is the least discriminating of the equivalence relations

presented here. Two systems are trace equivalent if they produce the same set
of traces perceivable by an external observer. In Fig. 7.12, all systems except
for (b) produce the same set of observable traces { a , b }. In contrast, system
(b) produces { a, b , b } and is therefore not trace equivalent to any of the
other systems.
Trace equivalence neglects the moment of choice, i.e., the point where
the traces of the internal behaviour of a system diverge. This characteristic
property leads to treating the aforementioned systems as equivalent, despite
their obvious differences. Bisimulation tackles this problem by including the
choices offered at intermediate steps in a system’s trace in the observation.
Weak bisimulation discriminates between those systems that differ in their
moments of choice. If a choice is offered in one system, the same choice must
be offered in the other system, after a possibly empty sequence of silent state
transitions. As we have argued above, this notion subsumes trace equivalence
and is therefore more discriminating.
In Fig. 7.12, systems (a) and (c) are not equivalent, owing to their different
moments of choice. When the option a is offered in the state q2 in (c), b cannot
be chosen any more, whereas it can be chosen in (a). In contrast, systems (a),
(d), and (e) are weak bisimilar. In (d), if an observer does not choose a in
the state r1 , i.e., the observer follows the silent transition τ , the same choice
between a and b is offered in the target state r2 again. Likewise, (e) and (a)
are weak bisimilar, because the very same choice between a and b is offered
after a silent state transition.
Branching bisimulation is the most discriminating equivalence relation
presented here, as it requires that all alternative state transitions of one system
must be offered in every corresponding state that offers at least one of the
alternatives. In the state r1 of system (d) in Fig. 7.12, only the state transition
labelled a is offered, and not b at the same time, hence the non-equivalence.
In contrast, in system (e), the choice between a and b offered by system (a) is
206 7 Comparing Behaviour

completely mirrored in the state u1 , and hence these systems are branching
bisimilar.

IJ

D E T D E V
T T V V

(a) (b)

Fig. 7.13: Example illustrating the problem of infinite silent sequences in

branching bisimulation

Although branching bisimulation is already a very discriminating equiva-

lence relation, we can construct an example where two very different models
are accepted as branching bisimilar. This is illustrated in Fig. 7.13. Equivalence
holds here because, in every state, the same set of observable actions is offered.
However, system (b) has a loop that can cause it to remain in the state s2
forever. Despite the fact that these systems are equivalent in terms of all the
equivalence relations presented above, they are quite different indeed, because
in Fig. 7.13b the state transition b might never be executed.

7.2 Behavioural Inheritance

The notion of behavioural inheritance is borrowed from the object-oriented
analysis and design methods used in software technology. There, objects are
organised into classes, which have various relationships, including inheritance.
If a class B inherits from a class A, then objects in B inherit all features of
class A. However, these objects can have additional features. Owing to their
relative positioning, A is called a superclass and B is called a subclass.
A typical example of inheritance is where class A represents vehicles and
class B trucks. Trucks have all of the properties of vehicles, such as a license
plate number, but trucks have additional features such as a payload. It is also
evident that all objects of subclass B are at the same time objects of class A,
because every truck is also a vehicle.
In this section, the concept of inheritance is applied to the behaviour of
discrete dynamic systems. In this context, inheritance corresponds to extension
of the behaviour that is provided by a system.
This is different from behavioural refinement, which we discussed in the
previous section. Refinement is a relation between models on different levels
of abstraction, for instance a specification-level and an implementation-level
model of a system. Actions, events, and decisions that are present in the
 7.2 Behavioural Inheritance 207

system’s implementation are abstracted away in the specification. The consis-

tency of these models requires hiding unobservable state transitions from the
comparison.
In contrast, extension is a relation between two models on the same level of
abstraction. An example is provided by two models, each of which describes the
implementation of a specific software system. If a behavioural model B inherits
from a behavioural model A, then B allows new behaviour but preserves all of
the existing behaviour of A. Consequently, a system designed on the basis of
A can be safely replaced by one based on B.

VHOHFW
SURGXFW FKHFNRXW
T T T

(a)

VHOHFW UHJLVWHU FKHFNRXW

SURGXFW
V V V V

FKHFNRXW
(b)

Fig. 7.14: Examples of behavioural inheritance

Figure 7.14 shows an example of behavioural inheritance introduced by

extensions of behaviour. The two models represent a simplified process for
ordering goods online. In system (a), the customer selects a product and then
proceeds to checkout. System (b) adds new behaviour that allows the customer
to register before proceeding to checkout. This step can, however, also be
skipped.
System (b) is an extension of system (a) because it preserves the behaviour
of the latter, i.e., it allows checking out without registration, while it adds
new, optional behaviour.
In the next section, we introduce an example that serves as a use case of
behavioural inheritance, along with a number of extension operations. As will
be discussed later in this chapter, several behavioural inheritance relations
have been established, serving different needs.
Despite their differences, several key properties hold true for all inheritance
relations. An inheritance relation is transitive, i.e., if one system is an extension
of a second system, which is in turn an extension of a third system, then the
first system is also an extension of the third system by the same inheritance
relation. Every inheritance relation is also reflexive, as a system can easily
be replaced by itself. In that case, the additional behaviour is empty. Finally,
and in contrast to equivalence relations, inheritance relations are not required
to be symmetric. In fact, in the primary use case in which one model adds
208 7 Comparing Behaviour

a non-empty set of features to its parent model, the inheritance relation is

antisymmetric. This means that the relation is asymmetric unless the two
models being compared are identical.

7.2.1 Practical Applications

Behavioural inheritance serves two particular purposes. First, inheritance

enables the reuse of existing behavioural models in different situations. In such
cases, some core behaviour is in all situations, whereas extensions serve unique
situations individually. Architecturally, we encapsulate the core behaviour in a
shared system component, whereas extensions reuse this component internally.
Here, inheritance of behaviour ensures that all extensions are compatible with
the core module.
The second use case of behavioural inheritance addresses the iterative
process of altering an existing system, for instance to support a wider set
of requirements, to be more efficient, or to be more secure. In such cases,
changes in the procedures of the system can cause inconsistencies and lead to
behavioural anomalies. In the worst case, some desired states of the system may
become unreachable or the system may get stuck in a state, resulting in a so-
called deadlock. Again, behavioural inheritance can avoid such inconsistencies
by limiting the set of allowed change operations such that inconsistencies are
avoided.
In the following, we address different categories of change operations that
can be applied to the behaviour of a system, and briefly elaborate on their
effect on the state space of the system. Examples of these change operations
will be given later in this section. In most cases, such changes consist of the
addition of new features, but they may also include changing existing features,
replacing parts of the behaviour, or even removing certain behavioural aspects.

Addition of alternative behaviour. Alternative behaviour generally refers

to a set of different paths in the state space of a discrete dynamic system.
Hence, adding alternative behaviour includes the extension of an existing
state space by adding new state transitions between existing states as well
as adding new states. For instance, a new state transition could introduce
a shortcut between two states, where previously several state transitions
were necessary. Another possibility is the introduction of iterations that
allow part of the behaviour of the system to be repeated. Finally, we could
introduce a new set of states and add a state transition that diverges at
some point and never returns to the original state space.
Addition of optional behaviour. Optional behaviour refers to an action
or sequence of actions that can be carried out as part of the execution of a
system, but is not required to be. With regard to the state space, optional
behaviour adds execution sequences that emerge from one state and return
to the same state again, thereby adding a loop to the state space of the
system.
 7.2 Behavioural Inheritance 209

Addition of mandatory behaviour. Alternative and optional behaviour

are not required to occur in the extended system, but they can nevertheless
be executed. Mandatory behaviour, in contrast, cannot be avoided and will
always be executed as part of the behaviour of the system. The addition of
mandatory behaviour always adds new actions to the behaviour of a system.
This can be done by inserting new actions into a sequence or by adding
an action or a set of actions that is executed concurrently with existing
actions. In both cases, new state transitions that cannot be avoided in the
general case are added to the state space.
Parallelisation of sequential behaviour. One typical procedure to im-
prove the performance of a system is the parallelisation of actions that
were previously executed in sequence. If these actions are really executed
in parallel, this can lead to a significant reduction in run time. In the
state space of a system that is derived by use of interleaved semantics, this
parallelisation leads to adding alternative, interleaved sequences of these
actions. This is different from adding alternative behaviour, in that no
new actions are added to the system’s behaviour.
Resequencing of behaviour. The last category of change operations for
the behaviour of discrete dynamic systems comprises all changes other
than those mentioned above, for example, a reordering of actions such as
swapping two actions or moving one action to an earlier or later stage in
the system’s execution. Copying of actions, such that an action is executed
several times but not as a loop in the state space, and the elimination of
actions, i.e., the deletion of state transitions, from the state space are also
included.
These change operations can be combined. For instance, the replacement
of an action is a combination of removing an action, i.e., eliminating a state
transition from the state space, and adding a new action, i.e., a new state
transition with a different label, at the same position in the state space. What
we have referred to as actions above could also be modules of behaviour, i.e.,
a closed set of states and transitions between them with one entry and one
exit state. Hence, change operations can also be applied hierarchically.

7.2.2 Trace inheritance

The notion of inheritance that we introduce in this section is a straightforward

application of trace semantics and is closely related to the trace equivalence
introduced in subsection 7.1.2: a system B is an extension of another system
A with regard to trace inheritance if all traces in the language of A are also
allowed in B. In short, this implies a subset relation between the trace sets of
the two systems, i.e., LA ⊆ LB .
To illustrate behaviour inheritance, we introduce a new example, which
will be used throughout this section. The system depicted in Fig. 7.15 de-
scribes a module of a database application which offers functionality to
210 7 Comparing Behaviour

EHJLQ UHDG XSGDWH FRPPLW

WUDQVDFWLRQ UHFRUG UHFRUG WUDQVDFWLRQ
V V V V V

Fig. 7.15: Original program

begin a transaction, read a record from the database, update a record, and
commit the transaction. A database transaction allows a number of database
operations to be bundled together such that either all operations are executed
successfully or no change is made to the database at all when the transaction
is committed. This mechanism avoids database inconsistencies. The system in
Fig. 7.15 provides only a single execution trace,

begin transaction, read record, update record, commit transaction .

EHJLQ UHDG XSGDWH FRPPLW

WUDQVDFWLRQ UHFRUG UHFRUG WUDQVDFWLRQ
U U U U U

FDQFHO
FDQFHO WUDQVDFWLRQ
WUDQVDFWLRQ

Fig. 7.16: Addition of an alternative branch

In comparison, the system model shown in Fig. 7.16 also offers the possibility
to cancel a transaction. In that case, no changes are made to the database.
This system generates the following traces:

begin transaction, read record, update record, commit transaction ,

begin transaction, read record, update record, cancel transaction ,
begin transaction, read record, cancel transaction .

On comparing the traces of these two systems, it immediately becomes clear

that the second system is a valid extension of our original database module,
as it allows replaying of the trace of the original system. Additional behaviour
is only offered alternatively.
This, once again, stresses the advantage of behavioural inheritance for
reuse in similar situations. Any system component that could use the original
database module can interact successfully with the new module, as that
component would not need to cancel transactions. However, the new module
also adds new features that can be used by other modules to cancel an already
begun database transaction.
If we were to add an action insert record between the read record and
update record actions of the original system, as shown in Fig. 7.17, the re-
sulting extension would violate trace inheritance, as the new system requires
 7.2 Behavioural Inheritance 211

insert record to be executed. System components that were suitable for the
original system would then fail, as they would not be able to insert a record.
The same applies if we were to remove a state transition, say read record.

7.2.3 Projection Inheritance

The example above has shown that the insertion of actions can introduce
anomalies into a system’s behaviour. This is not true in general, however.
This section introduces projection inheritance. Projection inheritance is based
on the proposition that actions which are not present in the system from
which behaviour is inherited are only internal actions. If the effects of these
actions are ignored, then the two systems must be branching bisimilar to
satisfy projection inheritance. This notion is called projection inheritance,
because when we investigate inheritance we project onto the common actions
and abstract away internal actions.
Consider a system B with a set of actions ΣB which inherits from a system
A with a set of actions ΣA . Since B inherits behaviour from A, it contains all
actions of A, i.e., ΣA ⊆ ΣB . B may also contain actions that are not present
in A. In this context, projection refers to hiding all additional actions, i.e., all
state transitions that are labelled with a symbol in ΣB \ ΣA are treated as
silent state transitions. Branching bisimulation can be decided for A and B.
On comparing Fig. 7.17 with the original database module shown in
Fig. 7.15, it turns out that there is an additional action insert record. Following
the above informal definition of projection inheritance, this action is treated as
a silent state transition. The two systems are then branching bisimilar, because
they offer the same set of choices in all pairs of corresponding states. After
the sequence begin transaction, read record has been executed, the external
behaviour of the system in Fig. 7.17 offers the choice to update a record
after a silent state transition, which coincides with the definition of branching
bisimulation.

EHJLQ UHDG LQVHUW XSGDWH FRPPLW

WUDQVDFWLRQ UHFRUG UHFRUG UHFRUG WUDQVDFWLRQ
X X X X X X

Fig. 7.17: Insertion of an action in a sequence

For the same reason, projection inheritance also allows one or several
actions to be added in a parallel branch. Imagine an extension of our original
database module that allowed us to insert a new record independently of, and
therefore concurrently with, the reading and updating of another record. As a
consequence of the interleaved semantics, this extension would lead to a system
with the state space depicted in Fig. 7.18. This system offers a number of
choices during its execution. For instance, in the state v1 the environment, i.e.,
212 7 Comparing Behaviour

another software module, may choose between read record and insert record.
If reading a record is chosen, another choice is offered between updating and
inserting a record, and so on.

XSGDWH LQVHUW
UHFRUG Y UHFRUG
UHDG LQVHUW
UHFRUG Y Y Y
EHJLQ UHFRUG FRPPLW
WUDQVDFWLRQ XSGDWH WUDQVDFWLRQ
Y Y Y UHFRUG
LQVHUW UHDG
UHFRUG Y UHFRUG

Fig. 7.18: Addition of a parallel action

If insert record is treated as a silent transition, this system is also branching

bisimilar to the original system shown in Fig. 7.15. In the state v2 , the
choices offered are read record and read record again, the latter after the silent
transition from state v2 to v4 . Similarly, if the first of these read record state
transitions, leading to state v3 , is chosen, the system offers a choice between
update record and update record again. Consequently, after each possible action,
the extended system simulates the original system if we abstract away the
effects of internal actions, which shows that the two models are branching
bisimilar.
In contrast to trace equivalence, projection inheritance prohibits the ad-
dition of alternative behaviour as a change operation for the extension of a
system. Recall Fig. 7.16, where the extended system offers new state transitions
cancel transaction in the states r3 and r4 , which lead directly to the final state.
These state transitions violate branching bisimulation because, for instance, in
the state r3 the extended system offers a choice between update record and a
silent transition (representing cancel transaction) that leads to the final state.
That state transition, however, is not present in the original system.
Again, elimination of an action breaks the inheritance relation. Hence,
actions that are present in the parent system must be reflected in the child
system as a necessary condition for projection inheritance.

7.2.4 Protocol Inheritance

The third inheritance relation introduced here is also based on branching

bisimilarity. However, in contrast to ignoring the effects of internal actions by
treating them as silent state transitions, such actions are not allowed to be
executed. The general idea of protocol inheritance is that the parent system
A serves as a protocol for any system B that inherits from A. Hence, if the
behaviour of system B cannot be distinguished from the behaviour of a system
A when only actions that are present in A are executed, then B is a valid
 7.2 Behavioural Inheritance 213

extension of A. This results in the removal of all state transitions in the state
space of B that carry labels not present in A. For protocol inheritance to hold,
the remaining behaviour must then be branching bisimilar to A.
Protocol inheritance excludes the insertion of mandatory behaviour. In
both cases, that is inserting an action into a sequence and adding a parallel
action, removal of the state transition that represents the added action would
result in disconnecting the state space.
For example, removing the state transition insert record in Fig. 7.17 would
disconnect the state space such that states u4 , u5 , and u6 would become un-
reachable from the initial state. This clearly invalidates branching bisimulation.
The same applies to added actions that are executed in parallel, owing to
the interleaved semantics of the state spaces. As can be seen in Fig. 7.18,
blocking the state transition insert record would also cut the state space into
two disconnected parts.
One particular exception exists for adding mandatory behaviour: protocol
inheritance allows mandatory behaviour to be appended to the final state of
the parent system if all state transitions that originate in this state are not
present in the parent system. In this case, these new transitions would be
blocked to verify protocol inheritance and the child system would not be able
to leave this state either, which preserves branching bisimilarity. However, it
is arguable that the system would then not reach its final state.
The addition of alternative behaviour can preserve protocol inheritance if
the actions offered as additional choices are not present in the parent system.
In the earlier example of this kind of change operation (see Fig. 7.16) blocking
of cancel transaction would lead to exactly the same behaviour as that of the
original system.

EHJLQ UHDG XSGDWH FRPPLW

WUDQVDFWLRQ UHFRUG UHFRUG WUDQVDFWLRQ
Z Z Z Z Z

UHDG
UHFRUG

Fig. 7.19: Addition of an alternative that introduces repetition

However, additional alternatives that diverge with an action that is also

present in the parent system are not blocked according to the definition of
protocol inheritance. An example is given in Fig. 7.19. Here, the added state
transition read record from the state w4 to w3 is not blocked, because an action
with the same label is also present in the parent system. Hence, a choice is
offered in w4 that is not mirrored in the parent system, and hence the two
systems are not branching bisimilar.
As in the case of projection inheritance, elimination of actions also violates
protocol inheritance. Likewise, no other form of resequencing of actions can be
214 7 Comparing Behaviour

accepted either, since these changes affect the state space but are not blocked,
because no new actions have been introduced.

7.2.5 Discussion
Three relations for behaviour inheritance have been introduced, trace in-
heritance, projection inheritance, and protocol inheritance. The differences
and commonalities have been discussed by means of the change operations,
introduced in subsection 7.2.1. Up to this point, however, two change operations
have been omitted.
The first such change operation, the addition of optional behaviour, refers
to a loop that can be iterated arbitrarily often, i.e., not at all, once, or several
times. A simple example is shown in Fig. 7.20. The original database module
shown in Fig. 7.15 has been extended with an optional action insert record that
can be carried out arbitrarily often after read record and before update record.

EHJLQ UHDG XSGDWH FRPPLW

WUDQVDFWLRQ UHFRUG UHFRUG WUDQVDFWLRQ
[ [ [ [ [

LQVHUW
UHFRUG

Fig. 7.20: Addition of optional behaviour

Following the discussion above, it should be clear that this kind of change
operation can be allowed for all of the inheritance relations explored so far.
Trace equivalence accepts this change unconditionally, as the non-iteration of
the extension yields the original traces of the system. Projection inheritance
and protocol inheritance accept this change only if the added behaviour consists
of new actions.
For projection inheritance, branching bisimulation holds if all of the optional
behaviour is treated as silent transitions; for protocol inheritance, only the
first action must be new, i.e., not present in the parent system, to prevent
the behavioural extension to be entered. In the above example, all inheritance
relations are preserved.
Second, parallelisation of sequential behaviour has not been addressed. We
assume that some set of actions are independent of one another, that is, the
execution of one action is not a condition for the execution of another. These
actions could be executed in any order or in parallel. Figure 7.21 shows the
state space of a behavioural modification of our original database module that
does not add new actions. Instead, the previously sequentially ordered actions
read record and insert record are now carried out concurrently. This introduces
a number of choices into the system each time the next action to be carried
out is chosen. In the example, such a choice is offered in the state y2 .
 7.2 Behavioural Inheritance 215

UHDG XSGDWH
UHFRUG \
EHJLQ UHFRUG FRPPLW
WUDQVDFWLRQ WUDQVDFWLRQ
\ \ \ \

XSGDWH UHDG
UHFRUG \ UHFRUG

Fig. 7.21: Parallelisation of actions

Looking at trace inheritance, we infer that the set of the traces that result
from parallelisation of actions also includes the original sequential sequence.
However, for the projection and protocol inheritance relations, both of
which are based on branching bisimulation, we come to the conclusion that
neither of them can accept parallelisation as an inheritance-preserving change
operation. Since no new action is added to the system, no action can be
hidden or blocked. However, the extended system offers choices that cannot be
simulated by the parent system. Consequently, branching bisimulation does
not hold.
When comparing the three inheritance relations that we have introduced,
we observe that there is no clear hierarchy or order of strictness among them.
For each relation, a different subset of change operations preserves inheritance.
An overview of the allowed change operations is depicted in Table 7.2. The
change operations annotated with an asterisk (∗ ) preserve the corresponding
inheritance relation only if the behavioural extension consists of new actions
in the case of projection inheritance, or at least starts with new actions in the
case of protocol inheritance.

Table 7.2: Overview of allowed change operations for inheritance relations

mandatory behaviour
alternative behaviour

sequential behaviour
optional behaviour

Parallelisation of

Resequencing of
Addition of

Addition of

Addition of

behaviour

Trace inheritance   
Projection/protocol inheritance ∗
Projection inheritance ∗ ∗
Protocol inheritance ∗ ∗
Lifecycle inheritance ∗ ∗ ∗
216 7 Comparing Behaviour

The table also lists two more inheritance relations, namely projection/pro-
tocol inheritance and lifecycle inheritance. These inheritance relations result
from combining protocol and projection inheritance. The more restrictive
inheritance relation – projection/protocol inheritance – applies if, for a given
parent behaviour and its extension, both protocol and projection inheritance
apply at the same time. Lifecycle inheritance is less restrictive than projection
inheritance and protocol inheritance. Lifecycle inheritance holds if, for any
extension in a child model, either protocol or projection inheritance holds.
Hence it subsumes the allowed change operations for both of these inheritance
relations.

FDQFHO
WUDQVDFWLRQ

EHJLQ UHDG LQVHUW XSGDWH FRPPLW

WUDQVDFWLRQ UHFRUG UHFRUG UHFRUG WUDQVDFWLRQ
] ] ] ] ] ]

FDQFHO
WUDQVDFWLRQ
FDQFHO
WUDQVDFWLRQ

Fig. 7.22: Example of an extension that satisfies lifecycle inheritance

Figure 7.22 shows an example of an extension of the behaviour of our

original database module introduced at the beginning of this section, such that
it is a valid child behaviour with respect to lifecycle inheritance. The state space
shows an extension with respect to mandatory behaviour: the inserted action
insert record would invalidate protocol inheritance, but it preserves projection
inheritance. The second extension adds alternative behaviour – the possibility
to cancel a transaction in various states – which would invalidate projection
inheritance but preserves protocol inheritance. Consequently, Fig. 7.22 does
not show a valid extension with regard to projection inheritance, protocol
inheritance, or projection/protocol inheritance.

7.3 Behavioural Similarity

Behavioural equivalence and behavioural inheritance are binary relations
between pairs of discrete dynamic models or, to be precise, their respective
state spaces. This means that such a relation either holds between two models
or does not. This is well suited to verifying consistency between a behavioural
specification and an implementation and to replacing one system with another
one that extends its behaviour, because these situations require accuracy to
avoid behavioural anomalies.
But there are other use cases involving behavioural models. These have
been created over time by a number of people in different contexts. In many
 7.3 Behavioural Similarity 217

scenarios, several models describe the same components of a system. However,

owing to different modelling languages, the use of different terminology, and
different modelling perspectives, these models are rather heterogeneous and
neither equivalence nor inheritance offers a means to discover such duplicates.
Therefore, a weaker relation is required that tolerates differences but rewards
commonalities between system models. This is where similarity helps.
Behavioural similarity is different from behavioural equivalence and inheri-
tance. The most notable difference is that similarity is not a binary relation
between two models. We cannot say that two models are similar or not, but
we can say how similar two models are to each other. If we have three systems
A, B, and C, and if A and B share significantly more features than A and
C, we say that the former two models are more similar than the latter. Thus,
similarity quantifies the commonalities and differences between models by a
numeric value.
Moreover, distinctive features that are present in one system but not the
other are not treated as silent transitions or blocked from execution, but rather
are used to identify the difference between the models.
We characterise behavioural similarity as a function that takes as arguments
the state spaces of two system models and computes their similarity value:

sim : A × A → [0, 1].

Here, A is the set of automata representing the state spaces of discrete dynamic
systems. The similarity function can assume values between 0 and 1, where
0 indicates minimum similarity. A similarity value of 1 indicates maximum
similarity, or equality, from the perspective of the similarity function.
Behavioural similarity functions have a number of properties. Similarity
is reflexive, i.e., the similarity between a system and itself is maximal, i.e.,
sim(A, A) = 1, and symmetric, i.e., sim(A, B) = sim(B, A). This means that
it does not matter in which order two systems are compared.

7.3.1 Practical Applications

Behavioural similarity offers a number of benefits when it comes to analysing

collections of system models and identifying those that share a significant
amount of commonality. Behavioural similarity is useful for analysing sets
of business process models. Every product manufactured and every service
provided is the result of a series of actions that constitute a business process.
Since process models are an essential knowledge asset, they need to be managed
effectively. In particular, the discovery and reuse of existing knowledge becomes
challenging when companies maintain hundreds or thousands of process models.
For a concrete scenario, we consider a merger of two companies. The
management is confronted with the need to consolidate the business processes
of the two organisations. While each will have their particular processes,
they will also share many processes, which are unlikely to be identical. Near-
218 7 Comparing Behaviour

duplicate process models may also originate from different information systems,
different departments of an organisation, or different views of the same business
process.

2UGHU
UHSODFHPHQW
$QDO\VH
SUREOHP
2UGHUVSDUH 5HSDLU 6HWWOH
SDUWV PDFKLQH SD\PHQW

(a) Process model A

$QDO\VH 2UGHUVSDUH 5HSDLU 7HVW 6HWWOH

SUREOHP SDUWV PDFKLQH PDFKLQH SD\PHQW

(b) Process model B

Fig. 7.23: Process models for repair processes

For an example, consider the two process models shown in Fig. 7.23,
which describe the repair processes of two washing machine repair companies.
Process model A starts with the activity Analyse problem and, based on
the results, continues with Order spare parts and Repair machine, or with
Order replacement, i.e., the ordering of a completely new washing machine.
After the machine is repaired, Settle payment is executed. If, however, a
replacement machine is ordered, then payment can be settled concurrently
with ordering the replacement, since the price for the replacement is already
known. Process model B also starts with Analyse problem, but it does not
include replacing the machine. Therefore, the activity Order spare parts is
performed and followed by iterating Repair machine and Test machine until
the machine is fixed. Eventually, the activity Settle payment is performed as
well.
The two process models share a number of activities and also some be-
haviour. For instance, both processes start with analysing the problem and
terminate with settling payment. Furthermore, in both processes the machine is
repaired after spare parts have been ordered. However, there are also significant
differences, such as the alternative option to not repair the machine at all but
to order a replacement in the first process.
Upon studying these models more closely, it becomes obvious that neither
the equivalence relations nor the inheritance relations introduced earlier in this
chapter are suitable for identifying the commonalities between the models, as
both models add activities that are not present in the other model. This shows
the need for a more relaxed notion of how to compare behavioural models.
 7.3 Behavioural Similarity 219

The discovery of similarity and the consolidation of redundancy in process

models has been reported to be a tedious and time-consuming task. Hence,
automatic means to identify commonalities among business process models
are required. Behavioural similarity provides a means to identify variants of a
behavioural model and create clusters of similar models that can be managed
in a consistent manner.
In the following, we introduce two similarity functions that address the
aforementioned problem. The consolidation of models will not be discussed
here, but it is referred to in the bibliographical notes of this chapter.

7.3.2 Trace Similarity

To provide a straightforward indication of the commonalities between two

behavioural models, we could compare their sets of traces and find out how
many traces they have in common. If they have some traces in common, the
two system could serve for some common use cases. To infer traces from process
models, the state spaces need to be computed. To do this, a BPMN process
model can be translated into a Petri net, as introduced in Section 5.2. The
result of applying this to the models shown in Fig. 7.23 is shown in Fig. 7.24.
In the remainder of this section, we shall use abbreviations corresponding to
the names of the activities in the process models.

25

$3

26 50 63

(a) Petri net A

$3 26 50 70 63

(b) Petri net B

Fig. 7.24: Petri nets for the process models shown in Fig. 7.23

Recall that additional silent transitions are inserted into Petri nets to
represent exclusive and parallel gateways in process models. These have no
effect on their own, but preserve the branching structure of the business
process. From the Petri net, we can derive the state space following the
strategy discussed in subsection 6.3.3. This provides us with the state spaces
shown in Fig. 7.25, where the silent transitions of the Petri nets are represented
as silent state transitions labelled τ .
220 7 Comparing Behaviour

V
25 63
IJ
VIJ
 V V
IJ
63 V 25
$3
V V

IJ 26 50 IJ 63
V V V V V

(a) State space S(A)

$3 26 IJ 50 70 IJ 63
U U U U U U U U

IJ
(b) State space S(B)

Fig. 7.25: State spaces derived from the Petri nets shown in Fig. 7.24

Now, we can compute the traces of these systems. Similarly to the approach
to comparing traces in trace equivalence, silent state transitions are ignored as
they have no effect on the environment of the process.

Comparing Traces
Traces are a purely sequential representation of the behaviour of a concurrent
system, which coincides with the sequentialisation applied when the state
space is derived from that system. If a set of activities are concurrent in the
original model, we will find a number of traces that comprise all permutations
of them in the orders in which they can be interleaved. Similarly to the state
explosion problem mentioned on page 181, this can lead to an exponential
growth in the number of traces.
Process model A in Fig. 7.23 allows the following traces:
AP, OR, SP ,
AP, SP, OR ,
AP, OS, RM, SP .
Looking at process model B in Fig. 7.23, we observe that the set of traces
is actually infinite. This is due to the loop around RM and TM , which is not
restricted in the model:
AP, OS, RM, T M, SP ,
AP, OS, RM, T M, RM, T M, SP ,
AP, OS, RM, T M, RM, T M, RM, T M, SP ,
...
 7.3 Behavioural Similarity 221

If a model of a discrete dynamic system contains loops, the set of traces

can grow infinitely large. For each possible iteration, another trace is created.
If the number of iterations is not limited, then the length of the trace is also
not bounded.
Although this makes it impossible to compare the complete sets of traces
of the two state spaces, we can see that none of the traces in the state space
in Fig. 7.25a is contained in the set of traces of the state space in Fig. 7.25b.
Consequently, from this perspective, the models have no commonalities.

n-grams of Traces

Another approach to discovering behavioural similarity uses only snippets of a

system’s traces, called n-grams, in the comparison. The n-grams of a system
are the set of all execution sequences of length n that can appear in any of
the system’s traces; their use remediates the problems of exponentially large
and even infinite state spaces due to concurrency and iterations, respectively.
Furthermore, comparing them is less restrictive than comparing complete
traces.
Here, we make use of 2-grams, which consist of all pairs of actions that
occur directly after one another in the traces of the system. The first system
(Fig. 7.25a) has the following 2-grams:

AP, OR , OR, SP , AP, SP , SP, OR , AP, OS , OS, RM , RM, SP .

The second system (Fig. 7.25b) yields these 2-grams:

AP, OS , OS, RM , RM, T M , T M, SP , T M, RM .

In the above listings we have underlined those 2-grams, which are common
to the state spaces of the two business processes. To compute the similarity
between two sets of n-grams, we use the Jaccard similarity, which divides the
number of common elements in two sets by the number of the elements in the
union of these sets:
|A ∩ A |
sim Jaccard (A, A ) =
|A ∪ A |
To apply this to the sets of n-grams of the traces of two systems, we divide
the number of common n-grams by the total number of n-grams. For the above
2
2-grams this results in sim trace (S(A), S(B)) = 10 : two out of ten 2-grams are
common to the two processes, which leaves us with a trace similarity of 0.2
for our process models for the repair business. If none of the n-grams of two
systems are shared, the numerator equals 0, which yields a similarity of 0.
At the other extreme, if all n-grams of the trace sets of the two systems are
identical, the numerator equals the denominator, which results a similarity of
1, which indicates the equality of the two systems with regard to the similarity
function.
222 7 Comparing Behaviour

It is important to mention that n-grams are an abstraction of traces, and

therefore comparing n-grams is weaker than comparing traces. In other words,
n-gram equivalence is generally less discriminating than trace equivalence,
which is the very reason why it is suited for behavioural similarity. This is
demonstrated by the fact that the above process models show commonalities
in their 2-grams but not in their complete traces.
Thus, we infer that if the n-grams of two systems are identical, this does
not imply that their traces are identical as well. For an example, assume a
system that limits the number of test–repair cycles and provides only the
following trace:

AP, OS, RM, T M, RM, T M, SP .

This system is not trace equivalent to the state space in Fig. 7.25b, but has
an identical set of 2-grams.
The length of the n-grams, determined by n ∈ N, is a configuration
parameter for the strictness of the n-gram similarity function. The greater n
is, the stricter the similarity function becomes. For instance, a value of n = 1
gives a set equal to the set of actions of the system, because every 1-gram
consists of exactly one action and duplicate n-grams are ignored. Consequently,
1-gram similarity completely ignores the behaviour of a system, as all temporal
ordering relations between the actions are lost.
On the other hand, increasing n leads to increasing the length of the
subsequences that are compared by the n-gram similarity function. If n = 3,
only subsequences of three successive actions in the two systems are identified
as commonality. If n = 5, we need to find identical subsequences of at least
five actions, and so on. If n is at least as large as the length of the longest
trace of a system, i.e. n ≥ maxσ ∈ LA (σ), then n-gram equivalence coincides
with trace equivalence, because every n-gram is identical to one trace of the
system. Empirical studies have shown that the most effective similarity results
are obtained for the value n = 2.

7.3.3 Behavioural Profile Similarity

Although trace equivalence is considered as the weakest type of equivalences

among the spectrum of behavioural equivalences, it discriminates between
processes where the order of actions is changed or actions are skipped. Trace
similarity using n-grams alleviates this problem by breaking traces up into
smaller sequences that are compared. At the same time, n-grams look only
at local commonalities and fail to incorporate commonalities in the overall
system.
In the above repair processes, we see a number of such commonalities.
For example, both business processes start with Analyse problem and every
other activity that both processes have in common is executed after that
activity. Similarly, with the exception of the concurrently executed activity of
 7.3 Behavioural Similarity 223

ordering a replacement, all common activities are terminated before settling

payment. Moreover, in both process models the activities Analyse problem,
Order spare parts, and Settle payment can be executed at most once. These
commonalities are not considered by n-grams.
To alleviate these problems, a behavioural abstraction has been introduced,
namely behavioural profiles.

Behavioural Profiles

A behavioural relation consists of all pairs of actions (x, y), with x, y ∈ Σ,

of a discrete dynamic system that are executed in a certain order when they
appear together in a trace of the system. It does not matter whether and how
many actions are executed between x and y.
Behavioural relations provide a behavioural abstraction of the traces of
a system which focuses on the execution order of actions and neglects other
behavioural details, for instance optionality, causal dependencies, and iteration.
Studies have shown that they capture a significant share of the behavioural
characteristics of process models. The following relations are differentiated.
The strict order relation, denoted by → ⊆ Σ × Σ, captures all pairs of
actions in a system that are always executed in the same order when they
co-occur in one trace. In the example of the repair process shown in Fig. 7.25a,
the activity Order spare parts is always executed after Analyse problem if both
activities appear in the same trace. Behavioural relations also look at activities
that are not executed directly after one another. Since Settle payment is always
executed after Order spare parts if these activities co-occur, they are also in a
strict order relation.
If a pair of actions can be executed in any order, they are in an interleaving
order relation, || ⊆ Σ × Σ. This is the case, for example, for the activi-
ties Order replacement and Settle payment in the process model depicted in
Fig. 7.23a. Because these activities are concurrent, they can be executed in
interleaving order in the corresponding state space in Fig. 7.25a. The activities
Repair machine and Test machine are also in interleaving order because, in
the loop in Fig. 7.25b, either can be executed after the other. If one action
can be executed more than once in a process, it is also in an interleaving order
relation with itself.
The third behavioural relation is the exclusiveness relation, denoted by
+ ⊆ Σ × Σ. This relation captures all pairs of actions that cannot be executed
together in one trace and are, therefore, exclusive to each other. If an action
cannot be executed more than once in a system run, it is exclusive to itself.
The three behavioural relations introduced above comprise the behavioural
profile of a discrete dynamic system. These relations are disjoint, which means
that no pair of activities is contained in more than one of them. While the
interleaving order and exclusiveness relations are symmetric and reflexive, the
strict order relation is antisymmetric and irreflexive. Note that none of the
relations states that two actions must occur in the same trace.
224 7 Comparing Behaviour

Behavioural relations characterise a dynamic system completely, which

means that, for any two actions, behavioural profiles express what execution
order they can appear in, if they appear together in one trace.
For some pairs, none of the relations apply. For instance, the pair (RM , OS)
is not contained in any behavioural relation. This is the case because none
of the above behavioural relations applies. The activities cannot be executed
in this order, i.e., Repair machine (RM ) before Order spare parts (OS), but
they are also not exclusive to each other, nor are they in interleaving order.
In fact, a fourth behavioural relation, inverse strict order, denoted by ←,
captures these pairs. These four behavioural relations partition the Cartesian
product Σ × Σ. Since the inverse strict order relationship is not required in
the remainder of this chapter, we will not address it further.
We can depict the behavioural profile of a system as a matrix that indicates
for each pair of actions, which behavioural relation they are in. The behavioural
profiles depicted in Table 7.3 have been computed from the state spaces of the
repair processes described above. For now, the shading of fields in the matrix
should be ignored.

Table 7.3: Behavioural profiles for the repair processes shown in Fig. 7.23

AP OS RM OR SP AP OS RM TM SP
AP + → → → → AP + → → → →
OS · + → + → OS · + → → →
RM · · + + → RM · · || || →
OR · · · + || TM · · · || →
SP · · · · + SP · · · · +
(a) Profile A (b) Profile B

Such behavioural matrices are read as follows. A pair of actions (x, y)

comprises an action listed in a row (x) and an action listed in a column (y).
The symbol at the intersection of the row and column shows which behavioural
relation the pair of actions belongs to. For example, in the behavioural profile
A in Table 7.3, the pair (RM , RM ) is in the exclusiveness relation, because
Repair machine (RM ) can be executed at most once per trace, whereas the
same pair is in the interleaving relation in the behavioural profile B, owing to
the inclusion of this action in a loop.
Looking at these behavioural profiles, we see that all activities in each
repair process are related to each other, no matter how far apart they are in
the process model, i.e., how many activities are executed between them. For
instance, all activities except for Analyse problem (AP) are in a strict order
 7.3 Behavioural Similarity 225

relation with that activity. Therefore, behavioural profiles provide a global

characterisation of the behaviour of a system.

Similarity of Behavioural Profiles

Since every behavioural profile relation is essentially a set of pairs of activities,

we can again use the Jaccard similarity to compute the similarity of behavioural
profiles.
An elementary similarity function would take the number of relation pairs
common to both profiles and divide it by the number of pairs in the union of
the two profiles. In the behavioural profiles of the repair processes in Table 7.3,
we have highlighted the pairs of actions that are in the same behavioural
relation in both profiles. Counting the number of common relation pairs and
9
the number in the union of all pairs, we determine the similarity to be 21 ≈ 0.43.
However, this similarity does not take the differences between the particular
behavioural relations into account.
Different relations express different strictness in the way in which the
behaviour of models is discriminated. Arguably, exclusiveness is the strictest
relation, because it states that two actions cannot be executed in the same
system run, i.e., they do not co-occur in one trace. Strict order and interleaving
order are less restrictive as they denote that pairs of actions may co-occur
in a trace. Here, strict order is more restrictive, because it requires that two
actions always show the same execution order when they occur together in a
trace. Consequently, interleaving order is the least strict behavioural relation
because it does not restrict the execution order of a pair of actions at all.
As a result of the above discussion, the behavioural profiles are in the
following order with respect to their strictness, where A  B means that A is
stricter than B:

exclusiveness (+)  strict order (→)  interleaving order (||)

In order to incorporate the different characteristics of the behavioural
relations into a similarity measure, we introduce the following aggregated
similarity, which uses weights to put a chosen emphasis on each behavioural
relation:

sim Profile (A, A ) = (wi · sim i (A, A ))
i ∈ {+,→,||}

Here, sim i refers to the Jaccard similarity for each of the behavioural rela-
tions, and wi ∈ [0, 1] denotes the weight applied to that relation such that
w+ + w→ + w|| = 1.
We have computed the elementary similarity values for each relation set.
Table 7.4 gives an overview, which indicates that the strongest similarity
between the repair processes is obtained with the strict order relation. Despite
226 7 Comparing Behaviour

Table 7.4: Elementary similarity values for each of the behavioural profile
relations

Similarity
3
sim + = 7
≈ 0.43
6
sim → = 10
= 0.6
0
sim || = 4
=0

the fact that each model adds an activity compared with the other, 60% of
their actions are still executed in the same order.
The considerable similarity in terms of exclusiveness results from the
reflexive pairs of activities Analyse problem (AP), Order spare parts (OS), and
Settle payment (SP), which can be executed at most once. Finally, the two
processes share nothing with respect to interleaving order relations, because the
interleaved execution includes different activities in the two models, resulting
in a similarity value of 0.
Based on the elementary similarity values, we have also computed the
aggregated similarity, sim Profile , for different weights, as listed in Table 7.5.
The last row indicates the average aggregated similarity where the weights of
all individual relation sets are equal.

Table 7.5: Aggregated profile similarity values

Weights Profile similarity

1 1
w+ = 2
w→ = 2
w|| = 0 sim Profile ≈ 0.51
1 1
w+ = 2
w→ = 0 w|| = 2
sim Profile ≈ 0.21
1 1
w+ = 0 w→ = 2
w|| = 2
sim Profile ≈ 0.3
1 1 1
w+ = 3
w→ = 3
w|| = 3
sim Profile ≈ 0.34

Putting a stronger emphasis on the strict order relation increases the

similarity with respect to the average, because the two processes have their
largest commonality in the strict ordering of actions. Analogously, stressing
exclusiveness or interleaving order reduces the similarity. In the end, it depends
on the use case which combination of values should be used. Studies have
shown that the best results are indeed achieved with a strong focus on strict
order, followed by exclusiveness, with interleaving order being weighted least.
 7.3 Behavioural Similarity 227

7.3.4 Dimensions of Similarity

In this section two approaches to measuring the similarity of discrete dynamic

systems, based on trace similarity and behavioural profile similarity, have
been presented. A large body of work exists that includes an abundance of
different methods to identify commonalities and differences among behavioural
models. Three basic dimensions by which similarity can be measured have
been distinguished.
The first dimension is based on the assumption that behavioural models
can be expressed as directed graphs, i.e., these models are made up of nodes
and directed edges of various types. We have already introduced a number of
such languages, for instance state machines, Petri nets, and BPMN diagrams.
Comparing the structure of these graphs allows one to evaluate how much
two models resemble each other structurally. The most prominent methods for
doing this are based on common subgraphs, i.e., fragments that are shared
by two model graphs, and graph edit distances, which represent the effort
required to transform one graph into another by adding and removing nodes
and edges; the less effort that is required, the more similar the models are.
The second dimension is behaviour. Instead of comparing the structure
of model graphs, their actual behaviour, expressed by traces or state spaces,
is compared. On the one hand, this allows one to compare models that are
expressed using different modelling languages. On the other hand, two models
with different structures can have exactly the same behaviour. An example
of such a pair of business processes is shown in Fig. 7.26. We leave it to the
reader to convince themselves that the two process models are truly branching
bisimilar.

$ & $ &

% ' % '

(a) (b)

Fig. 7.26: Two process models that have a different structure but exactly the
same behaviour

The third dimension of similarity is based on in the naming of model

elements. If a number of models of the same system have been created by
different individuals, it is likely that they will differ not only in their structure
and behaviour, but also in the labels that are used for actions, events, conditions,
and participants. Hence, in order to compare two models, first a relation
between the state transitions of one model and those of the second model
228 7 Comparing Behaviour

must be established. This is called an alignment. For example, an alignment

of actions denotes which action in one system corresponds to which action in
another system, such that they have the same effect when executed in either
system.
It is not always possible to obtain a one-to-one alignment of actions in a
pair of models. Some actions present in one model may be missing in the other;
sometimes one action in one model represents the effect of two actions in the
other model. These differences can be taken into account in measurements of
the similarity of process models, resulting in a more accurate assessment of
commonalities and differences. However, for the sake of simplicity, we have
excluded such considerations in this book. The bibliographical notes point to
a number of publications that address this issue.

Bibliographical Notes
The idea of comparing the behaviour of systems goes back to Moore (1956),
who described a thought experiment to determine the behaviour of a system.
Here, an automaton, i.e., a sequential system, that accepts input and provides
output is connected to an experimenter – a machine that successively sends
input to the automaton and receives its output. Moore elaborated on the
conclusions that could be drawn by such an experimenter. From his standpoint,
two systems that cannot be distinguished by the same experimenter are
behaviourally equivalent.
Later, Hoare (1978) extended the notion of sequential systems by adding
concurrency and introduced trace semantics – the basis of trace equivalence.
Trace semantics provides a sequential representation of concurrency by in-
terleaving actions that can be carried out in parallel. Hoare claimed that
the behaviour of a system can be described entirely by a possibly infinite
set of traces. Hence, if two systems have the same sets of traces, they are
equivalent. In Hoare (1980), a complete process algebra was presented that
provides many useful properties and operations for capturing and composing
system behaviour.
Park (1981) and Milner (1982) proposed the concept of bisimulation,
which examines whether two systems are able to simulate each other. Milner
(1982) also introduced observation equivalence, i.e., weak bisimulation, as
a means to compare systems that have silent state transitions. Branching
bisimulation was introduced by van Glabbeek (1993) to provide a stronger
notion of equivalence than weak bisimulation that also incorporates silent state
transitions. Behavioural equivalence relations were also covered by Pomello
et al. (1992), van Glabbeek and Goltz (2001), and Hidders et al. (2005), who
provided formalisations and comparisons of these relations.
Behavioural inheritance was studied by Basten (1998) for the lifecycles of
objects in a software system. Later, van der Aalst and Basten (2002) showed
how projection and protocol inheritance can be applied to problems related to
 7.3 Behavioural Similarity 229

the changing of system components. As a basis for the discussion of change

operations, we refer to Mansar and Reijers (2005), who introduced operations
to redesign business processes. Similarly, Weber et al. (2008) reported on a
number of change operations to refactor behavioural specifications in order to
improve their quality and to eliminate anomalies.
Kunze (2013) provided a comprehensive survey of approaches to behaviour
similarity. Comparison of traces by use of n-grams was introduced by Mahleko
et al. (2005). Behavioural profiles were developed by Weidlich et al. (2009),
based on earlier work on behavioural relations by van der Aalst et al. (2004) and
Eshuis and Grefen (2007). Weidlich (2011) provides a thorough investigation
of behavioural profiles and their computation. An application of behavioural
profiles to the alignment of process models was proposed by Weidlich et al.
(2011). That paper also showed that behavioural profiles can be computed
efficiently. The profile similarity function was proposed by Kunze et al. (2011b)
and later extended by Kunze (2013).
The concept of alignment emerged from the field of data and schema
integration, where it refers to the identification of relations between the entities
in two conceptual models, see Euzenat and Shvaiko (2007). Similar approaches
have been followed for alignments between business processes, as in Weidlich
et al. (2010).
8
Verification

The book has introduced a variety of techniques to model the behaviour of

discrete dynamic systems. We can use automata, sequence diagrams, and
business process models to describe the behaviour of software systems. Using
behavioural models, the stakeholders involved in the design and development
of a system can share design proposals, discuss different alternatives, and agree
on a plan for how to develop the system.
The final chapter of this book turns to the verification of behavioural models.
Verification addresses the formal correctness of a system model and, therefore,
requires a strong grounding in precise formalisms to meet the requirements of
completeness and mathematical accuracy.
The verification of discrete dynamic systems is as old as the design and
modelling of these systems – dating back over half a century already – and a
wealth of research publications and many books have been dedicated to this
topic. Consequently, we have not aimed to capture the topic in its entirety
in a single chapter. Instead, we shall introduce behavioural verification from
a practical perspective. In Section 8.1, we show how system models, desired
properties, and verification play together, and present an iterative approach
to ensuring the correctness of a system design.
Temporal logic is introduced as a way to formally capture temporal rela-
tions, i.e., properties involving several states of a state space, in Section 8.2.
Section 8.3 introduces techniques to formally verify properties specified as
temporal logic formulas. Owing to the formal nature of verification, which
means that both the system model and the desired properties are expressed
with mathematical precision, it is possible to conduct the verification auto-
matically by use of model-checking software tools. Section 8.4 elaborates on
some fundamental types of behavioural properties such as reachability, safety,
liveness, and fairness properties, which are essential in the formal analysis of
system behaviour.
Finally, we introduce an approach to verifying behavioural properties of
business processes. In particular, BPMN-Q is introduced, which simplifies the
formulation of desired properties of business processes by offering a graphi-

© Springer International Publishing Switzerland 2016 231

M. Kunze and M. Weske, Behavioural Models,
DOI 10.1007/978-3-319-44960-9_8
232 8 Verification

cal modelling language for business process compliance rules. We show how
compliance rules translate to formal specifications and how BPMN-Q helps to
identify compliance violations in business process models.
This chapter gives an overview of system verification by introducing the
main concepts. Business process compliance is used mainly as an example
to illustrate the steps involved in the design and verification of systems. We
should point out that the steps are identical when one is verifying other types
of system properties.
Even though a few formal definitions cannot be avoided, we have deliber-
ately ignored formal completeness for the sake of comprehension. The chapter
concentrates on the main concepts and aims to provide an entrance into a
more comprehensive body of literature on system analysis and verification,
which is referred to in the bibliographical notes at the end of this chapter.

8.1 Overview of Verification

In the context of system development, models can be used in different ways,
ranging from informally discussing initial ideas about the functionality of a
system to a detailed specification of a system that can be used during system
implementation.
Verification takes a complementary view of models by investigating their
formal properties. The key idea behind formal verification is as follows. On
the one hand, if we can show that a model satisfies some desirable properties,
the corresponding system will show exactly the same properties. On the other
hand, if we can show that the model is free from undesirable behaviour, such
as deadlocks, the system will be free from these behavioural anomalies as well.
This understanding is based on the assumption that the system developed
behaves as specified in the model. While there are approaches that aim at
automatically generating systems from models, there is no substitute for well-
educated software engineers for making sure that systems are implemented as
they were specified.
In Section 1.5 we introduced a generic methodology for developing systems,
comprising of the phases design, implementation, and enactment. This book is
dedicated to the system design phase, which is divided into system modelling
and analysis. In the context of behavioural analysis, verification addresses the
formal correctness of a system model with regard to certain properties that the
system must show or avoid. For instance, some systems, such as ticket vending
machines and traffic lights, are designed to run continuously and therefore
should always return to some initial state, whereas a business process should
always terminate properly.
Designing a system requires an iterative approach. In the modelling phase,
a system design is created, as well as set of properties that need to be satisfied
by the system. Verification is the process of checking whether a property is
satisfied. If this is not the case, the system model needs to be mended to
 8.1 Overview of Verification 233

remove the defect that has been discovered. An overall picture of modelling
and verification is shown in Fig. 8.1.

UHILQH &RXQWHU
H[DPSOH

6\VWHP GHILQH 6WDWH IRUPDOSURSHUW\

PRGHO VSDFH QRWVDWLVILHG

0RGHO
FKHFNHU

3URSHUW\ IRUPDOLVH )RUPDO IRUPDOSURSHUW\

PRGHO VSHFLILFDWLRQ VDWLVILHG

6\VWHPPRGHO
YHULILHG

Fig. 8.1: Overall picture of system design and verification

The central items in this figure are the system model, which specifies the
behaviour of a system, and a property model, which captures a desired property
to be satisfied by the system model. Here, the system model is a behavioural
model, such as an extended automaton, a sequence diagram, or a business
process model. This model represents the behaviour of the system. As argued
before, the state space of a system model serves as a uniform representation of
the behaviour of the system, and therefore serves as a basis for system analysis.
Desired properties of a behavioural system, as well as properties that are
undesired and must be avoided, can be captured in different ways. Initially, such
properties are typically of an informal nature. Since formal verification requires
formal models, these properties have to be formalised. This formalisation step
results in a formal specification of the property, which can then be checked.
This formal specification uses temporal logic, which will be introduced in the
next section.
Verification is based on a specific component that is able to check formal
specifications of properties against the state space of a system model automat-
ically. This component is known as a model checker. A model checker takes as
input the state space of a system and a formal specification of a property. It
checks whether that particular property is actually satisfied in the state space.
If the property holds, the system model is verified.
If the system model does not satisfy the formal property, the model checker
not only returns a negative result, but also provides a counterexample. This
counterexample shows one behaviour of the system that leads to the violation
of the formal property.
This counterexample is valuable for improving the system design. The main
use of the counterexample is shown in Fig. 8.1. As it shows undesired behaviour,
234 8 Verification

it directly fuels the refinement of the system design. However, the counter
example might also expose problems in the formalisation of the property or in
the abstraction of the system model to the state space. Regardless of the origin
of the verification failure, such a counterexample provides useful information
to the engineers that enables them to improve the design of the system.

8.2 Temporal Logic

When analysing and comparing dynamic systems earlier in this book, we have
used states as a key abstraction to model behaviour. A state represents a
snapshot of a system at one point in time. Depending on the modelling goal, a
state may be rather abstract and may characterise some informal milestone
that the system has reached. It may, however, also be detailed and capture
the values of all system variables.
In Chapter 6, the concept of valuation was introduced as a function that
assigns to each variable a value in its domain. Since each state in the state
space also represents the value of every variable, we can treat the state s ∈ S
as the valuation function for the system variables V :

s : V → dom(V ).

This interpretation of the states in a state space allows us to reason about

the behaviour of discrete dynamic systems. In fact, we can even describe
the behaviour of a complete system by formulas that involve states and an
extended state transition relation.
These considerations will now be illustrated by an example. The following
formulas describe the behaviour of a system by providing an automaton
(S, Σ, δ, s0 , F ) with a set V of system variables:

V = {v1 , v2 }, (1)
Σ = {l}, (2)
∀ s, s ∈ S : |{s | (s, l, s ) ∈ δ, l ∈ Σ}| = 1, (3)
 
∀ s ∈ S \ {s0 } : |{s | (s , l, s) ∈ δ, l ∈ Σ}| = 1 ∧ (4)
|{s | (s , l, s0 ) ∈ δ, l ∈ Σ}| = 0,
∀ (s, l, s ) ∈ δ : s (v1 ) = s(v1 ) + s(v2 ) ∧ s (v2 ) = s(v1 ), (5)
s0 (v1 ) = 1, s0 (v2 ) = 0 (6)
F = ∅. (7)

This behavioural specification is expressed in its entirety using only predicate

logic. The relation between two states is expressed by the state transition
relation in lines (3) to (5). Line (3) states that every state has exactly one
outgoing state transition, and line (4) that every state except the initial state
 8.2 Temporal Logic 235

has exactly one incoming state transition. The initial state has, of course, no
incoming state transition.
For all state transitions, i.e., all tuples in δ, the values of the variables
in the target state s are computed from the values of these variables in the
source state s, which is expressed in line (5). The variables are declared in line
(1) and initialised in line (6). Line (7) explicitly states that this automaton
has no final state. Since all state transitions represent the same function, there
exists only one label l in the alphabet (see line (2)).
This means that the state transitions impose updating of the variables when
advancing from one state to the next, leading to the progression of states and
variables shown in Table 8.1. In fact, the state transition relation implements
the behaviour of computing the numbers of the Fibonacci sequence, which are
stored in the variable v1 .
The Fibonacci sequence is infinite. Since every state represents one partic-
ular assignment of the variables v1 and v2 , there exist an infinite number of
states. Consequently, the above automaton is infinite.

Table 8.1: States of the Fibonacci automaton

State s0 s1 s2 s3 s4 s5 s6 s7 . . .
v1 1 1 2 3 5 8 13 21 . . .
v2 0 1 1 2 3 5 8 13 . . .

Using states as valuations, and predicate logic for the state transition
relation as a means to put these valuations in relation, is feasible for simple
examples such as the one above. However, it becomes cumbersome and very
complex when we try to express more complicated behaviours.
Temporal logic enables us to put states into relation by means of temporal
operators. A temporal operator could, for example, be used to express the
condition that if one action has been executed, another action must be executed
as well before the system halts.
The term temporal logic refers to the ordering of actions and events in
the state space, and does not address real-time semantics, such as that of
timed automata, which were discussed in subsection 3.3.3. In general, two
major types of temporal logic are distinguished: linear temporal logic and
computation tree logic. Both address the ordering of events and actions, but
they differ in their expressiveness and in how paths in the state spaces are
evaluated.
Figure 8.2 depicts the state space of a software system that leads a customer
care agent through the various steps of placing a courier delivery: that is, an
express messenger picks up a shipment from one location and transports it
to another location. The system starts in the state s0 , where the customer
236 8 Verification

IURP
IURP WR
WR SDLG
IURP SDLG VHQW
SDLG UHFRUG VHQW ILQ
VKLSPHQW
UHFRUG GHWDLOV KDQJXS
DFFRXQW V V V IJ
QXPEHU

KDQJXS

V FXVWRPHULV IURP
UHJLVWHUHG
IURP WR
WR SDLG
QHZ IURP VHQW VHQW
FXVWRPHU
V V V V
UHFRUG UHFRUG VHWWOH
DFFRXQW VKLSPHQW
GHWDLOV GHWDLOV SD\PHQW

Fig. 8.2: State space of a courier customer care system

indicates whether he or she is a new customer or already has an account

number. In the latter case, which leads to state s1 , the customer’s account
number is recorded by the agent. Using the account number, the customer’s
address and payment information are retrieved. This is represented by the
state annotations from and paid.
We call these state annotations atomic propositions. An atomic proposition
indicates that a certain property holds in a state, while abstracting away
actual values of the variables in the state space. Atomic propositions provide
an abstraction that can be used in verification. We use this abstraction if we
are not interested in the actual values of the customer’s address and payment
information but only, for example, in whether these data are present in the
system.
Similarly, the atomic proposition to indicates that the recipient of the
shipment has been recorded, and paid indicates that the shipping has been paid
for. If the relevant property does not hold for a state, the atomic proposition
evaluates to false. In state space diagrams, we have set atomic propositions in
italics to distinguish them from labels of states and state transitions, and we
have only shown those propositions that are true in a given state. For instance,
in state s0 , none of the atomic propositions is true, and hence none are shown
for that state.
If the customer indicates that they are a new customer, their account
information, such as name and address, are recorded, leading to the atomic
proposition from evaluating to true in the state s4 . In this state, the system
may detect that a customer with this information has already registered,
leading to s1 .
 8.2 Temporal Logic 237

Otherwise, the customer care system records the shipment details and
settles the payment. The final state, denoted by the atomic proposition fin, is
reached after the customer hangs up the phone.

8.2.1 Linear Temporal Logic

Temporal logic extends predicate logic with temporal operators. Before these
operators are introduced, the evaluation of expressions has to be addressed.
The basis of temporal logic is state spaces, which were introduced in
Chapter 6. In subsection 2.2.3, we introduced execution sequences as a means
to express system runs by series of actions that are carried out in a particular
order. So far, the focus of behavioural analysis has been on state transitions.
In temporal logic, we are interested in the atomic propositions that are
true in certain states. Therefore the concept of computations is introduced. A
computation π is the sequence of states that is traversed in a system run. A
sample computation in the above system is given by the following sequence of
states:

π = s0 , s1 , s4 , s5 , s6 , s7 .

Computations are infinite sequences of states, because time does not stop.
This is apparent in the silent state transition that creates an iteration of the
final state s7 in Fig. 8.2. Once a system has reached a final state that will
never be left, it will remain in that state forever, iterating the silent state
transition as time passes. When we display computations in this chapter, this
property is represented by an overline on the state that is repeated infinitely
often.
Each state defines atomic propositions that hold while the system is in
that state. For example, in the state s5 the following propositions hold:

{from, to, sent}.

If we were interested in the names of states and the actions that had been
carried out to reach those states, we could have captured this information in
atomic propositions as well.
Using atomic propositions and Boolean operators, i.e., predicate logic, we
can reason about the properties of a state. Linear temporal logic (LTL) allows
us to reason about computations, i.e., sequences of states.
Let M = (S, Σ, δ, s0 , F ) be the state space, let π ∈ S ∗ be a computation
that starts in a state s ∈ S, and let ϕ be a predicate logic formula. Then the
formula holds for π if it holds for the first state s = π(1) in the path.
We can express an LTL formula for any computation of the system or for a
particular state. In the latter case, the formula must hold for all computations
that originate from that state:

M, s |= ϕ =⇒ ∀ π, π(1) = s : M, π |= ϕ.
238 8 Verification

In the example of the customer care system shown in Fig. 8.2, the formula
M, s1 |= from ∧ paid evaluates to true because the atomic propositions from
and paid evaluate to true. In contrast, this is not the case in the state s5 ,
which is expressed by M, s5 |= from ∧ paid.
The semantics of temporal operators is defined on the basis of computations.
In LTL, a computation is represented by a linear sequence of states, hence the
name “linear temporal logic”.
To reason about system behaviour (characterised by sequences of states),
temporal logic complements predicate logic with temporal operators. These
temporal operators are the next operator (a property holds in the next state of
the computation), the until operator (property 1 holds until property 2 holds),
the eventually operator (eventually a property will hold), and the globally
operator (a property holds in all states).
Let π = s1 , s2 , . . . , sn be a computation. We refer to the ith position of
a computation by π(i), where π(i) ∈ S, because a computation is a sequence
of states in the state space M. Recall that a computation is not required to
start in the initial state of a system. In the above computation, π(1) is the
first state s1 , π(2) the second state s2 , and so on.
Next The next operator (denoted by X) requires that an expression ϕ holds
in the next state of the computation:

M, π |= X(ϕ) ⇐⇒ M, π(2) |= ϕ.

Eventually The eventually operator (denoted by F) requires that the expres-

sion ϕ must hold in the current state or in some future state:

M, π |= F(ϕ) ⇐⇒ ∃ i ≥ 1 : M, π(i) |= ϕ.

Globally The globally operator (denoted by G) requires that an expression ϕ

holds in every state in π:

M, π |= G(ϕ) ⇐⇒ ∀ i ≥ 1 : M, π(i) |= ϕ.

Until The until operator U combines two expressions in the form ψUϕ. It
requires that ψ evaluates to true and will continue to be true in every
reachable state until a state π(i) is reached in which ϕ is true. Note that
ϕ might already be true in the first state of the computation:

M, π |= ψ U ϕ ⇐⇒ ∃ i ≥ 1 : M, π(i) |= ϕ ∧ ∀ 1 ≤ j < i : M, π(j) |= ψ.

As discussed above, LTL represents computations by linear sequences of

states. When we introduced temporal operators in LTL, just one sequence,
π, was used. This sequence was used to define the semantics of temporal
operators.
 8.2 Temporal Logic 239

However, in LTL we can also evaluate temporal expressions for a given

state. So far, we have used the term

M, π |= ϕ

to indicate that in M, for a computation π, the property ϕ holds. We can also

use the term

M, s |= ϕ

to indicate that in all paths starting from the state s, the property ϕ holds.
LTL formulas in which states are used are called state formulas. LTL formulas
in which paths are used are called path formulas.
To illustrate temporal operators in LTL, the customer care system shown
in Fig. 8.2 is revisited. It is reasonable to assume that every parcel that has
been paid for will be sent. This property of the system can be expressed in
LTL by the following state formula:

M, s0 |= G(paid → F(sent)).

This formula states that, globally, that is, in all states reachable from the initial
state s0 , if the atomic proposition paid is true, then a state must eventually
be reached in which sent is true.
The formula uses an implication, denoted by p → q, which can also be
written as ¬p ∨ q, because either p does not hold, or if p holds then q must hold
as well. Consequently, the above LTL expression is equivalent to the following
one:

M, s0 |= G(¬paid ∨ F(sent)).

We can conclude that in any state, either of the two conditions ¬paid and
F(sent) must hold. In order to find out whether this formula holds, we identify
all states for which ¬paid is violated, because only then do we need to evaluate
the second condition. That is, we search for states where paid is true.
The atomic proposition paid is true in the states s1 , s2 , s6 , and s7 . Hence,
we need to examine whether, from any of these states, a state is reachable in
which sent evaluates to true as well.
• M, s1 |= F(sent), because in the state s3 that is reachable from state s1 ,
sent is true.
• M, s2 |= F(sent), because in this state sent is true. This is an example,
where the eventually operator is satisfied immediately, without the need to
progress to another state.
• M, s6 |= F(sent), for the same reason. In this case, sent holds even before
paid. However, none of the LTL operators makes an assumption about the
history of a computation.
• M, s7 |= F(sent). In the final state s7 , sent holds as well.
240 8 Verification

Consequently, the LTL formula holds for all computations that start in a state
where paid is true. We conclude that the following LTL formula holds:

M, s0 |= G(paid → F(sent)).

It is worth discussing why the formula above uses the globally operator.
For comparison, consider the following statement without this operator:

M, s0 |= paid → F(sent).

This formula states that if the atomic proposition paid is true in the state
s0 of the state space M, then it must eventually be followed by a state in
which sent evaluates to true. However, on investigating the state space shown
in Fig. 8.2, we see that paid is not true in the state s0 and, therefore, the
right-hand side of the implication is not required to hold.
By enclosing the statement with the globally operator, we express the
condition that in all states reachable from s0 the implication must hold.
In the remainder of this section, a number of equivalences and implications
are listed that are useful for formulating and transforming LTL formulas.
The first equivalence states that in a state space M, for a path π, the
negation of a property ϕ holds if and only if on the same path the property
does not hold:

M, π |= ¬ϕ ⇐⇒ M, π |= ϕ.

On a path, the property ϕ ∧ ψ holds if and only if on the path the property ϕ
and the property ψ hold:

M, π |= ϕ ∧ ψ ⇐⇒ M, π |= ϕ ∧ M, π |= ψ.

On a path, the property ϕ ∨ ψ holds if and only if on the path the property ϕ
or the property ψ holds:

M, π |= ϕ ∨ ψ ⇐⇒ M, π |= ϕ ∨ M, π |= ψ.

On a path, the property ϕ ∧ ψ holds in the next state if and only if in the next
state the property ϕ and the property ψ hold:
numerical zero is a small circle whose diameter is approximately equal to two-thirds of
that of O.
M, π |= X(ϕ ∧ ψ) ⇐⇒ M, π |= X(ϕ) ∧ X(ψ).

On a path, the property ϕ ∧ ψ holds globally if and only if the property ϕ

holds globally and the property ψ holds globally:
 8.2 Temporal Logic 241

M, π |= G(ϕ ∧ ψ) ⇐⇒ M, π |= G(ϕ) ∧ G(ψ).

The following formula comprises an implication, not an equivalence. It states

that if eventually a state is reached in which ϕ and ψ are both true, then this
state also satisfies the single expressions F(ϕ) and F(ψ). However, the opposite
is not true, because the right-hand side of the statement does not ensure that
ϕ and ψ are true in the same state:

M, π |= F(ϕ ∧ ψ) =⇒ M, π |= F(ϕ) ∧ F(ψ).

When evaluating temporal logic formulas, we can also take advantage of

implications and equivalences. If, for a computation π, a property ϕ holds,
then, obviously, this property holds eventually as well:

M, π |= ϕ =⇒ M, π |= F(ϕ).

If, for a computation π, a property ϕ holds in the next state then the condition
that this property shall hold eventually is satisfied as well:

M, π |= X(ϕ) =⇒ M, π |= F(ϕ).

For a computation π, a property ϕ holds eventually, if and only if this property

holds in the current state or it holds in the next state, eventually:

M, π |= F(ϕ) ⇐⇒ M, π |= ϕ ∨ X(F(ϕ)).

On a path, it is not true that a property ϕ holds globally if and only if

eventually a state can be reached in which ϕ is violated, i.e., in which ¬ϕ
holds:

M, π |= ¬G(ϕ) ⇐⇒ M, π |= F(¬ϕ).

Negation affects temporal relations. We now investigate how the Boolean

negation operator can be propagated to subformulas of LTL expressions.
On a path π a property ϕ holds globally if and only if we can never find a
state in which ϕ is violated, i.e., in which ¬ϕ holds:

M, π |= G(ϕ) ⇐⇒ M, π |= ¬F(¬ϕ).
242 8 Verification

As indicated earlier, the until operator states that a property will eventually
hold, which leads to the following equivalence:

M, π |= F(ϕ) ⇐⇒ M, π |= true U ϕ.

The last two statements show that in fact the temporal operators X and U
are sufficient to express any LTL formula, as the globally operator G can be
constructed using the eventually operator F, and F can in turn be constructed
using the until operator U. The atomic proposition true is understood as a
constant that always evaluates to true. Again, the last statement emphasises
that the property expressed by the second operand of the until operator must
eventually become true.
Above, we have explained that LTL formulas hold for a computation if they
hold for the first state of that computation. As a consequence, an LTL formula
applied to a state in the state space implicitly holds for every computation
that starts in that state.
It is interesting to know that two systems that are trace equivalent also
satisfy the same set of LTL expressions. If we say that a system model satisfies
an LTL formula, we mean that the formula holds in the initial state of the
system. Consequently, all computations of the system that start in the initial
state must satisfy the LTL expression. These computations are equivalent to
the traces of the system, because traces are sequences of actions that start in
the initial state and end in a final state of a system.
In subsection 7.1.2, we argued that two systems that are trace equivalent
have identical sets of traces. If two systems have the same set of traces, then
they also have the same set of computations, and hence satisfy the same LTL
expressions.

8.2.2 Computation Tree Logic

Linear temporal logic is only able to express properties regarding all execution
sequences that start in a certain state. Thus, we can only investigate whether
a property holds in all possible behaviours of the system.
However, it is also useful to investigate whether there exists some behaviour
with a certain property. An example of such a property is “from any state, it
is possible to reach the final state”. This property cannot be expressed in LTL,
because an LTL formula is evaluated for all computations originating from a
given state. Figure 8.3 shows an example that illustrates this observation.
In the state space shown, it is possible to reach the final state s2 , because
in the state s1 action c can be chosen. However, it is also possible that this
will never happen. In LTL, the expression F(fin) would not be evaluated to
true, because there is a possible behaviour of the system in which s2 is not
reached.
 8.2 Temporal Logic 243
E

ILQ
D F
V V V IJ

Fig. 8.3: State space of a system that exposes a limitation of LTL

If we want to express the property that s2 can be reached, we need additional

capabilities. Computation tree logic (CTL) does not represent system behaviour
by a set of linear sequences originating from a given state. Rather, CTL uses
the notion of a computation tree. Using the tree structure of computations,
we can express the condition that there exists a computation with a certain
property.
To specify these properties, CTL adds a new concept to temporal logic
formulas, called quantifiers. Quantifiers describe whether a formula applies to
all computations that originate from a specific state or only to at least one of
those computations. The respective quantifiers are called the all quantifier (A)
and the exists quantifier (E).
For example, the following CTL formula expresses the statement “from
any state it is possible to reach the final state” for the state space shown in
Fig. 8.3, where the atomic proposition fin indicates that the terminal state
has been reached:

M, s0 |= AG(EF(fin)).

This CTL formula reads: For all computations that start in s0 , it holds globally
that fin holds eventually.
As discussed earlier, CTL formulas use the branching structure of the state
space. In a state space tree (or computation tree), whenever a state has a
number of outgoing state transitions, each of them leads to a new state. State
transitions cannot converge into the same state again. As a result, each state,
except for the initial state, has exactly one incoming state transition, and at
least one outgoing one, resulting in a tree structure.
A computation tree for the above system is shown in Fig. 8.4. The compu-
tation starts in the state s0 . A state transition labelled a brings the system to
the state s1 . In this state, two things can happen. Either the loop transition b
is taken, bringing the computation to the state s1 , or the transition c is taken,
leading to the state s2 . In s1 , there are again these two alternatives, which
leads to the tree structure of the computation shown in Fig. 8.4.
Since there is a τ -transition in the state s2 of the state space shown in
Fig. 8.3, the system iterates in this state forever. As a consequence, the state
space tree becomes infinite. Nevertheless, the termination of the system is
represented by the atomic proposition fin attached to all final states, which in
our case is just the state s2 .
244 8 Verification

ILQ ILQ ILQ

D F IJ IJ IJ 
V V V V V

E ILQ ILQ
F IJ IJ
V¶ V¶ V¶ 

E ILQ
F IJ 
V´ V´

E 

Fig. 8.4: State space tree for Fig. 8.3

The benefit of the state spaces tree is that it makes the branching structure
of computations explicit. Each state has a unique history, i.e., there exists
exactly one path that leads to a given state.
In computation tree logic, temporal operators and qualifiers are always
paired. This allows us to define whether a property must hold for all computa-
tions or just for one computation. Let M = (S, Σ, δ, s0 , F ) be a state space
and π a path in M. As above, π(1) refers to the first state on the path.
All The all quantifier (denoted by A) expresses the condition that a temporal
logic formula ϕ applies to all paths π starting in a state s:

M, s |= AX(ϕ) ⇐⇒ ∀π | π(1) = s : M, π |= X(ϕ),

M, s |= AF(ϕ) ⇐⇒ ∀π | π(1) = s : M, π |= F(ϕ),
M, s |= AG(ϕ) ⇐⇒ ∀π | π(1) = s : M, π |= G(ϕ),
M, s |= A[ψ U ϕ] ⇐⇒ ∀π | π(1) = s : M, ψ |= ϕ U ϕ.

Exists The exists quantifier (denoted by E) expresses the condition that there
exists at least one computation π that starts in s for which a temporal
logic formula evaluates to true:

M, s |= EX(ϕ) ⇐⇒ ∃π | π(1) = s : M, π |= X(ϕ),

M, s |= EF(ϕ) ⇐⇒ ∃π | π(1) = s : M, π |= F(ϕ),
M, s |= EG(ϕ) ⇐⇒ ∃π | π(1) = s : M, π |= G(ϕ),
M, s |= E[ψ U ϕ] ⇐⇒ ∃π | π(1) = s : M, π |= ψ U ϕ.

In CTL, pairs of quantifiers and the until operator can be written AU(ψ, ϕ),
which is equivalent to A[ψ U ϕ]. We shall use the latter form from now on.
Pairing the temporal logic operators X, F, G, U with the path quantifiers E
and A results in eight possible combinations, illustrated in Fig. 8.5. Since a
 8.2 Temporal Logic 245

EX(ϕ) EF(ϕ) EG(ϕ) E[ψ U ϕ]

AX(ϕ) AF(ϕ) AG(ϕ) A[ψ U ϕ]

Fig. 8.5: Combinations of quantifiers and temporal operators in CTL (ϕ is

true in the black states, ψ is true in the grey states)

CTL formula applies to computation trees that start in a given state, the tree
structure of the state space visualises in a straightforward fashion how CTL
formulas are evaluated. In the following discussion, the state s0 refers to the
root of the computation tree.
In Fig. 8.5, EX(ϕ) states that the property ϕ must hold in at least one
state that immediately succeeds s0 , whereas AX(ϕ) requires that ϕ holds in
all directly succeeding (next) states.
Similarly, EF(ϕ) requires ϕ to become true in at least one reachable future
state, while AF(ϕ) states that, for all computations, ϕ must eventually become
true in some future state. The temporal operator F does not state when a
property becomes true; hence, this may happen after different numbers of state
transitions from the initial state s0 . Nevertheless, AF(ϕ) requires that there
does not exist a single computation, in which ϕ remains false indefinitely.
CTL expressions always refer to paths in the state space and, hence, EG(ϕ)
requires that ϕ always holds along at least one path. In Fig. 8.5, we have
highlighted only one path. However, it may well be the case that several paths
satisfy ϕ globally. Note that the globally operator includes the state in which
the path starts, and hence ϕ must also hold in s0 . AG(ϕ) requires that ϕ holds
henceforth in all future states of all computations.
Finally, E[ψ U ϕ] requires that along at least one path, ψ must hold until
ϕ becomes true. We have visualised this property using different shadings of
states in Fig. 8.5: ψ evaluates to true in the grey states, and ϕ in the black
states. A[ψ U ϕ] only evaluates to true if ψ holds globally and, no matter which
alternatives are chosen, until ϕ becomes true. It is important to recall that
the until temporal operator requires the condition to become true eventually.
This means that a state must be reached where ϕ evaluates to true, no matter
which quantifier is applied to the temporal operator.
246 8 Verification

Looking at the different combinations in Fig. 8.5, we can discover some

relations between quantifiers and temporal operators. For example, AG is the
negation of ¬EF. This observation is in fact obvious, because AG(ϕ) states
that ϕ must hold for all computations in all states, while ¬EF(ϕ) states that
there does not exist any computation where ϕ eventually becomes true. The
following equivalence relations are useful for specifying and transforming CTL
formulas:

M, s |= ¬AX(ϕ) ⇐⇒ M, s |= EX(¬ϕ),
M, s |= ¬EX(ϕ) ⇐⇒ M, s |= AX(¬ϕ),
M, s |= ¬AG(ϕ) ⇐⇒ M, s |= EF(¬ϕ),
M, s |= ¬EG(ϕ) ⇐⇒ M, s |= AF(¬ϕ).

We observe that negation always switches the quantifier. That is, if a property
does not always hold, then there exists at least one path in the computation
tree where it does not hold.
The next set of equivalences are referred to as existential rules:

M, s |= AF(ϕ) ⇐⇒ M, s |= A[true U ϕ],

M, s |= EF(ϕ) ⇐⇒ M, s |= E[true U ϕ],
M, s |= A[ψ U ϕ] ⇐⇒ M, s |= ¬E((¬ϕ) U (¬ψ ∧ ¬ϕ)) ∧ ¬EG(¬ϕ).

These equivalences show that all CTL formulas can be rewritten in such a
way that only the combinations EX, E[_ U _], and AG are required, where the
underscore _ is a placeholder for formulas. For this reason, formulas that use
only these three combinations are said to be in the existential normal form of
CTL.
The relation between the formulas AF(ϕ) and A[true U ϕ], as well as between
EF(ϕ) and E[true U ϕ], becomes apparent in Fig. 8.5 when we assume that the
states shaded grey are true.
The last equivalence in particular deserves an explanation. A[ψ U ϕ] states
that ψ must hold until ϕ becomes true. That is, until this point in time, either
ψ or ϕ must evaluate to true. The first part of the equivalence, ¬E((¬ϕ) U (¬ψ∧
¬ϕ)), addresses this very issue and states that there exists no such path in
which ϕ cannot become true, until both ψ and ϕ are false. Hence, in such
a path there needs to exist a point where both ψ and ϕ are not true. The
second part, ¬EG(¬ϕ), ensures that ϕ becomes true eventually, i.e., that no
path exists where ϕ remains false globally, and thereby forever.

8.2.3 Example of Verification using CTL

We now return to the earlier example of the customer care system for ordering
express deliveries. We showed that every shipment that is paid for is also sent,
which is a system requirement. Changing the perspective, we would also like
 8.2 Temporal Logic 247

to ensure that it is not possible to send a shipment without paying. Assume

that the atomic proposition fin is true if the state space reaches a final state.
The above requirement can be formalised as follows:

M, s0 |= ¬E[¬paid U (sent ∧ fin)].

This CTL formula reads as follows: There exists no path where a shipment is
not paid until the system reaches a final state in which the shipment is sent.
Note that a final state can only be reached by way of the state transition
hang up.
Looking at the example in Fig. 8.2 and assuming that for the final states
s2 and s6 fin is true, it is apparent that no such path exists.
However, the state space is not complete with regard to the possible
system behaviour. Since the customer care agent interacts with the client over
the phone, the client may choose to hang up the phone at any time. This
observation leads to a number of additional final states depending on the point
in time at which the customer hangs up, as depicted in Fig. 8.6.

IURP
SDLG
ILQ

V IJ IURP
IURP WR
WR SDLG
KDQJXS SDLG VHQW
UHFRUG VHQW ILQ
VKLSPHQW
GHWDLOV KDQJXS
V V V IJ
UHFRUG
DFFRXQW IURP
QXPEHU KDQJXS
SDLG FXVWRPHULV
UHJLVWHUHG
V IURP
QHZ IURP WR
FXVWRPHU WR SDLG
IURP VHQW VHQW

V V V V
UHFRUG UHFRUG VHWWOH
DFFRXQW VKLSPHQW
GHWDLOV GHWDLOV SD\PHQW
KDQJXS KDQJXS KDQJXS KDQJXS

V IJ V IJ V IJ

ILQ IURP IURP

ILQ WR
VHQW
ILQ

Fig. 8.6: State space of a customer care system including hang up choices of
customers
248 8 Verification

If we apply the above formula to the system design, it becomes clear that
a path in the computation tree exists that violates the desired property:

π = s0 , s3 , s4 , s5 , s11 .

In every state of π, the atomic proposition paid evaluates to false. In s5 ,

the customer, aware that the messenger has already been sent to pick up
and deliver the parcel, chooses to hang up the phone to commit a fraud and
avoid being charged. By this path, the system reaches the final state s11 and
terminates without the payment being settled.
In Section 8.1, we mentioned that model checkers not only state whether
a temporal logic formula evaluates to true for a given state space, but also
provide a counterexample when a formula is not satisfied. This counterexample
is a specific behaviour of the system that violates the CTL formula; in our
example, for instance, this might be π = s0 , s3 , s4 , s5 , s11 .
This example illustrates the overall picture of verification that we have
introduced at the beginning of this chapter in Fig. 8.1. To design a new
customer care system, its behaviour is represented in models. These models are
then used to derive the state space of the system model, using the techniques
introduced in Chapter 6.
To design the system in a proper way, several properties must hold. We
have investigated one property to rule out a behaviour in which the parcel
is shipped but the funds have not been paid by the customer. The textual
representation of this property serves as an informal property model. This
informal specification is formalised using CTL, resulting in the CTL formula
ϕ stated above, which corresponds to the formal specification of the property
in Fig. 8.1.
The state space and the formal property are now provided to the model
checker, which returns a counterexample. For system designers, this counterex-
ample represents valuable information, because it shows one system behaviour
which violates a desired property. This information can be used to modify the
system model and the state space in such a way that the undesired behaviour
can no longer occur.
In the example at hand, one way of solving the issue is to settle the payment
before recording the shipment details. Such a change would result in the state
space given in Fig. 8.7. Note that the atomic propositions of the states s5 and
s11 have changed, which is the reason we have renamed these states s5 and
s11 , respectively, in the corrected state space.
Considering the hang up actions, this change violates the earlier requirement
that every parcel that is paid for should also be sent. However, it would be the
fault of the customer if they hung up after settling the payment but before
ensuring that the parcel was sent.
In this example, we checked the property manually against the state space
and derived the counterexample. While this is feasible for simple examples, it
would not be possible for complex systems. Fortunately, these checks can be
 8.3 Model Checking 249
IURP
SDLG
ILQ

V IJ IURP
IURP WR
WR SDLG
KDQJXS SDLG VHQW
UHFRUG VHQW ILQ
VKLSPHQW
GHWDLOV KDQJXS
V V V IJ
UHFRUG
DFFRXQW IURP
QXPEHU KDQJXS
SDLG FXVWRPHULV
UHJLVWHUHG
V IURP
QHZ WR
FXVWRPHU IURP SDLG
IURP SDLG VHQW

V V V V
UHFRUG VHWWOH UHFRUG
DFFRXQW VKLSPHQW
GHWDLOV SD\PHQW GHWDLOV
KDQJXS KDQJXS KDQJXS KDQJXS

V IJ V IJ V  IJ

ILQ IURP IURP

ILQ SDLG
ILQ

Fig. 8.7: Corrected state space of a customer care system satisfying the formal
property M, s0 |= ¬E[¬paid U (sent ∧ fin)]

performed automatically. The software components used to do this are called

model checkers. They are based on verification methods, which are addressed
in the next section.

8.3 Model Checking

In the previous section, we introduced LTL and CTL as a means to express
behavioural properties in a formal way. In the overall picture of verification
shown in Fig. 8.1, this means that there is a formal, uniform representation of
a system’s behaviour – the state space of the system model – and a formal
specification of desired properties.
Model checking provides techniques to examine whether a given property is
satisfied by a system or not. Owing to the differences between LTL and CTL,
different strategies for model checking need to be pursued with the two logics.
It is worth mentioning that neither of the temporal logics presented here
subsumes the other. It is intuitive that CTL allows expressions that are not
possible in LTL, in particular with regard to the exists quantifier.
250 8 Verification

It might be a surprise, however, that not all LTL formulas can be expressed
in CTL, as will be discussed in Section 8.4, when behavioural properties are
analysed. Experience shows that most behavioural specifications that are
practically relevant for the design and analysis of software systems can be
expressed in CTL.
In this book, we aim to provide a basic understanding of LTL and CTL
model checking. The topic has already been covered in an exhaustive manner
in several excellent textbooks. Tools exist that can perform model checking
automatically and in a very efficient manner. For details, the interested reader
is referred to the bibliographical notes at the end of this chapter.

8.3.1 LTL Model Checking

The idea of LTL model checking is as follows: a system whose behaviour is

specified by a state space satisfies an LTL formula if and only if each path
in the state space satisfies that formula. This problem can be solved by a
set-theoretic approach.
Let ϕ be an LTL formula. Then, let the set of computations that satisfy ϕ
be called Lϕ , and let the set of all computations that are possible in a state
space M be called LM . Notice that Lϕ and LM are sets of computations.

ࣦࣧ


ࣦɔ

Fig. 8.8: The computations of the system intersect with the computations
satisfying the property ϕ

These sets are shown in the Venn diagram in Fig. 8.8. The set LM on the
left-hand side contains all computations that the system is able to perform,
i.e., the paths of the system. On the right-hand side, all computations that are
permitted by the property ϕ are shown. To illustrate the motivation behind
the LTL model-checking approach, we investigate the subsets shown in this
figure.
The intersection LM ∩ Lϕ contains all computations that both are possible
for the system and at the same time satisfy the desired property. Lϕ − LM
contains all computations that satisfy this property but are not possible system
behaviour. This is why we do not care about that set.
The problematic set is LM − Lϕ , because it contains possible system
behaviour that at the same time violates the desired property. Therefore, in
LTL model checking we check whether this set is empty. If this set is empty,
then the system behaviour satisfies the property. If it is not empty, then we
 8.3 Model Checking 251

have found a violation. In other words, the system satisfies the property if its
computations are a subset of the computations that satisfies the property:

LM ⊆ Lϕ . (1)

If this subset relation holds then the system always behaves in a way that
satisfies the desired property, because LM does not contain any computations
that are not covered by Lϕ . This situation is illustrated in Fig. 8.9.

ࣦɔ ࣦࣧ

Fig. 8.9: The set of computations of the system is included in the set of
computations satisfying the property ϕ

When discussing the overall picture of system verification shown in Fig. 8.1,
we highlighted the fact that model checkers return a counterexample whenever
a violation is found. The Venn diagram shown in Fig. 8.8 can be used to
illustrate the role of a counterexample in this context.
Recall that we can decide the subset relationship between sets by deciding
intersection using negation. In particular, the set of computations that are not
allowed by ϕ are those that result from the negation of ϕ. L¬ϕ refers to this
set of computations that are not covered by Lϕ . This leads to a condition that
is equivalent to the one specified in (1):

LM ∩ L¬ϕ = ∅. (2)

This condition states that there exists no computation in the state space M
that is also in the set of disallowed computations L¬ϕ .
If this condition is violated, there must be at least one element p ∈ LM ∩L¬ϕ .
Since the path p is in both sets, we can conclude that p is a possible system
behaviour and at the same time satisfies the negation of the property ϕ.
Therefore, p is the counterexample we were looking for. This counterexample
is returned to the designer, who can use it to improve the system design.

8.3.2 CTL Model Checking

Although at first glance it seems that CTL is more complex than LTL, because
it adds quantifiers to temporal logic formulas, the approach to checking whether
an expression holds is, in fact, simpler.
This is due to the property that LTL formulas must be examined for every
computation of an automaton. For this reason, LTL model checking is based
252 8 Verification

on the product of automata that comprises the computations of the desired

property expressed in a formula and the state space of the system model. If
an automaton has loops in which the number of iterations is not bounded, it
has infinitely many and infinitely long computations. Hence we cannot check,
whether every computation that starts in a particular state satisfies an LTL
expression. Instead, we need to prove that the language LM complies with the
language of the LTL expression, as we have sketched above.
In contrast, CTL formulas are state formulas. Hence, it is possible to check
for each state of the state space whether a formula holds. As the temporal
operators allow reasoning about the relation between states, this is done
recursively, by breaking the expression up into subformulas.
The CTL model-checking algorithm is based on the idea of marking a state
if a given subformula evaluates to true in that state. The algorithm starts from
the innermost subformula of an expression and iterates over all states. Each
state in which this subformula holds, is marked. Then the algorithm takes the
next subformula and iterates over all states again.
The innermost subformulas of CTL expressions are constructed from atomic
propositions and predicate logic operators (¬, ∧, ∨) only. These can be checked
in a straightforward manner for each state. The following example illustrates
how an expression is separated into subformulas:

Φ = EX(¬p ∧ q).

In this expression, p and q are atomic propositions. The innermost subformulas

are ¬p and q. Marking states in the state space for these atomic propositions
is trivial. The next, outer, subformula is ϕ = (¬p ∧ q) and can also be checked
directly for every state. Consequently, each state marked with ϕ evaluates to
true for ¬p ∧ q.
When the algorithm shifts outwards in the CTL expression, it may encounter
temporal operators and quantifiers. Then the algorithm visits all states that
are marked with the inner subformula and starts to trace state transitions
forwards or backwards in the state space to find states that satisfy the required
temporal relation.
In our example, all states for which ϕ evaluates to true are marked. We
refer to these states as M (ϕ). To check whether EX(ϕ) holds, the algorithm
starts with all states in M (ϕ) and, for each of these states, traces back all
incoming state transitions. For each of these states, EX(ϕ) holds, because they
have a state transition that leads to a state in M (ϕ).
The strategy for checking other combinations of quantifiers and temporal
operators is similar. Owing to the aforementioned equivalences and the exis-
tential normal form, only E[ψ U ϕ] and AG(ϕ) remain to be checked. Recall
that, in this step, all states that satisfy ψ and ϕ have already been marked
accordingly.
For the first of these formulas, the algorithm starts by identifying all states
for which ϕ holds. From each of these states, it uses backtracing. In every
 8.4 Behavioural Properties 253

backtracing step, it checks whether ψ holds. If this is the case, the state is
marked with E[ψ U ϕ] and all incoming state transitions to this state are also
traced back, checking for ψ. This is repeated until ψ is not true in an incoming
state.
AG(ϕ) is checked by tracing all state transitions forwards and ensuring
that in every reachable state in the state space ϕ evaluates to true.
Every time the algorithm checks the next subformula, all states for which
this subformula holds are marked accordingly, until the algorithm terminates
with completing the check for the whole CTL expression that we started with
in the first place. If the initial state is marked with the whole CTL expression,
the system satisfies the requirement entirely.

8.4 Behavioural Properties

In the previous section, we introduced temporal logic as a means to formally
specify properties that a discrete dynamic system should satisfy. LTL and
CTL are very powerful tools that enable us to express many behavioural
properties. In essence, behavioural properties can be divided into four categories,
reachability, safety, liveness, and fairness.
These categories of properties can be used to analyse different types of
system properties. For instance, safety properties express the condition that
something negative should never happen, whereas liveness properties express
the condition that something positive should eventually happen. Understanding
these fundamental behavioural properties is essential for formulating temporal
logic formulas.
In this section, categories of behavioural properties are introduced. We
explain in which situations they are useful and how they can be formalised in
temporal logic. It is worth mentioning that neither LTL nor CTL alone allows
formulas in all categories to be expressed. Knowledge of these limitations is
important, if one is bound to a particular model-checking tool.

8.4.1 Reachability

In the course of this book, we have already elaborated on the most elementary
behavioural property, reachability. For instance, in Chapter 2, reachability was
introduced as the possibility of advancing to a particular state by traversing the
state transitions of a labelled state transition system. In general, reachability
expresses the property of a system that it is able to reach a certain state. It
does not prescribe that the system should always reach that state.
For instance, in the ticket vending machine example shown in Fig. 3.3, we
used reachability to argue that it should be possible to cancel the purchase of
a ticket. Of course, we did not require that a purchase has eventually to be
cancelled.
254 8 Verification

To check reachability properties, statements about the existence of a

computation path are made, which can be expressed in CTL:

CTL: M, s |= EF(ϕ).

In this formula, ϕ represents the desired property. The combination of the

quantifier E and the temporal operator F states that there exists at least one
computation in the computation tree starting from the state s that leads to a
state in which ϕ is satisfied. Note the difference between the above and the
following expression:

CTL: M, s |= AG(EF(ϕ)).

In this formula, reachability of ϕ is required for s and every state that can
occur after s. This can be used to express the condition that it must always
be possible to reach a state where ϕ is true, no matter what happens. In the
ticket vending machine example, this property would be too strong, since in
every reachable state it must be possible to cancel the purchase. This is not
desired, since it would allow us to cancel a purchase even after it had been
completed.
Based on the equivalence of F(ϕ) and (true) U (ϕ), we can restrict the paths
in the state space for which reachability is satisfied. This observation can be
illustrated by a ticket vending machine similar to the one we have introduced
earlier in this book.
Let the atomic proposition init be true only in the initial state of the
automaton. The following expression requires that returning to the initial
state must only be possible if funds have been inserted, i.e., if the amount a of
money paid is larger than 0:

CTL: M, s0 |= AG(E[(a > 0) U init]).

Owing to the property of LTL that it implicitly applies to all computations

that start in a particular state, expressing reachability is not possible in LTL.
However, even if no CTL model-checking tool is to hand, reachability can
be computed rather easily by traversing the state space of the system and
searching for states that satisfy the desired property.

8.4.2 Safety

Negating a reachability expression leads to the exclusion of a certain property

in any computation path. This is the very nature of safety properties, i.e., that
something undesired should not happen.
One of the most prominent generic properties of dynamic systems is freedom
from deadlocks. In a deadlock situation, a system becomes stuck and is unable
to continue. Freedom from deadlocks is a safety property because it implies
that certain undesirable states, i.e., deadlock states, are unreachable.
 8.4 Behavioural Properties 255

Safety can be expressed in both LTL and CTL. Let ϕ be an undesired

property that the system behaviour should not show; the system is considered
safe if ϕ never occurs:

LTL: M, s |= G(¬ϕ),
CTL: M, s |= AG(¬ϕ).

Both of these formulas state that in the current and all future states ϕ will
always evaluate to false. Similarly to reachability, safety can be put under
conditions. The abstract condition “while ϕ holds, ψ must not become true”
is expressed by the following formulas:

LTL: M, s |= (¬ψ) U (¬ϕ),

CTL: M, s |= A[(¬ψ) U (¬ϕ)].

For instance, the statement that “a ticket will not be supplied unless the
ticket purchase has been confirmed” can be expressed as follows, where the
atomic proposition conf indicates that the ticket has been confirmed and supp
indicates that it has been supplied:

LTL: M, s |= ¬supp U conf ,

CTL: M, s |= A[¬supp U conf ].

8.4.3 Liveness

Checking a system only for safety is, in general, not sufficient to ensure the
proper system behaviour, because every safety property can be satisfied by
preventing the system from doing anything at all. For this reason, liveness
properties require that the system makes progress.
Liveness properties can be expressed directly using the eventually temporal
operator F in LTL and CTL:

LTL: M, s |= F(ϕ),
CTL: M, s |= AF(ϕ).

These temporal logic formulas express the condition that some property should
eventually become true. For this reason, liveness properties are sometimes
also referred to as eventuality properties. A well-known example of a liveness
property is the guaranteed termination of a system. It is a bizarre circumstance
that the termination of a program is called a liveness property.
Again, we can put a temporal expression under conditions using the until
operator U instead of F. Recall that in CTL, A[ψ U ϕ] states that a state in
which ϕ evaluates to true must eventually be reached and, until this state is
reached, ψ must be true.
256 8 Verification

Liveness can also be used to ensure the responsiveness of a system, i.e.,

that a certain event will always trigger a particular reaction. This is achieved
by using a logic implication:

LTL: M, s |= G(ψ → F(ϕ)),

CTL: M, s |= AG(ψ → AF(ϕ)).

In LTL, encapsulating the implication into G ensures that for every occur-
rence of ψ a reaction ϕ occurs. This reaction pattern is useful, for instance,
in asynchronous message-based interaction, where an apt statement of the
requirement is “every request (ψ) is eventually responded to by a message
(ϕ)”. In CTL, the same is achieved by encapsulating the implication into AG,
meaning that the implication should hold for all states globally.
Safety and liveness properties are, arguably, the most important kinds
of behavioural properties, because in combination they ensure that desired
behaviour will happen, while undesired behaviour will not happen. In fact,
every temporal logic formula has an equivalent representation comprising a
conjunction of a safety property and a liveness property.

8.4.4 Fairness

The final category of behavioural properties that we present is fairness. Fairness

is an essential underlying assumption for model checking. Recall Fig. 8.3 and
assume the liveness property AF(fin), which requires that the final state s2 , for
which the atomic proposition fin evaluates to true, must eventually be reached.
However, the loop labelled b may never be left, and the system may reside
forever in the state s1 .
Fairness, as an assumption in the process of verification, ensures that all
decisions are taken fairly, which means that no choice is ignored infinitely
often. Assuming fairness in the verification of the state space shown in Fig. 8.3,
the state transition labelled c will eventually be chosen and the system will
eventually terminate. Hence, the liveness property is satisfied.
Fairness, as a behavioural property, states that, under some conditions, a
property will be repeated infinitely often. This property can only be expressed
in LTL:

LTL: M, s |= GF(ϕ).

Fairness properties are important for systems that are designed to run
forever. For instance, when designing an elevator control system, we have to
make sure that it will always be possible to get to the ground floor. Another
example is a traffic light that is modelled to show a green light infinitely often.
Note that this is different from the requirement that the traffic light should
show green forever.
It is important to mention that in general fairness cannot be expressed
in CTL, because CTL does not allow the G and F operators to be combined
 8.5 Business Process Compliance 257

without pairing them with quantifiers. M, s |= AG(AF(ϕ)) is an acceptable

approximation only in a limited set of situations.

8.5 Business Process Compliance

In this chapter, we have introduced temporal logic as an expressive and formally

grounded approach to formulating desired and undesired properties of a system
that can be checked automatically by model checkers. In the overview of model
checking in Fig. 8.1, CTL and LTL are represented by the formal specification
of a property.
So far, we have not yet elaborated on how to define a desired property
in a way that is more intuitive than temporal logic. We have, nevertheless,
described a number of examples of properties by prose text, for instance the
statement in subsection 8.2.1 about the customer care system that “every
parcel that has been paid will also be sent”.
In the specification of compliance rules, such as legal constraints or reg-
ulations affecting business processes, prose text is often used to represent
the desired property of the system. For instance, laws are written in natural-
language text. However, the transformation of natural language into a formal
specification is not trivial and can be automated only to a limited extent.
Another drawback of textual specifications is their complexity and ambiguity. A
precise regulation requires a lot of text, because of which its comprehensibility
suffers significantly.
A similar problem has to be solved to describe the behaviour of discrete
dynamic systems. Rather than being described by informal text or formal state
spaces, behaviour can be captured in models with precise syntax and semantics,
for instance business process models. As will be described in this section, not
only behavioural models, but also desirable properties of dynamic systems
can be expressed in models. These can be translated into formal specifications
automatically. The remainder of this chapter introduces one such modelling
language for expressing the properties of business processes.

8.5.1 BPMN-Q for Compliance Checking

BPMN-Q is a pattern-based, graphical modelling language for compliance rules.

As the name suggests, it is based on Business Process Model and Notation,
which we have discussed in Section 5.2. Essentially, BPMN-Q borrows a
number of notational elements from the BPMN standard, including start and
end events, as well as activities. BPMN-Q adds annotations to capture desired
properties of business processes.
In BPMN-Q, compliance rules are specified by so-called BPMN-Q queries,
which are composed of patterns. BPMN-Q is formally grounded in temporal
258 8 Verification

logic. Each pattern can be translated into a CTL formula. As a result, com-
pliance rules expressed in BPMN-Q can be verified by CTL model-checking
tools.
BPMN-Q is activity-oriented, since elementary patterns prescribe rules
about the presence, absence, and ordering of activities in business processes.
It reuses graphical primitives from BPMN for start events and end events and
for activities, as shown in Fig. 8.10.
The approach is based on the matching of query elements to business
processes. For instance, a BPMN-Q start event matches the initialisation of a
business process. Along similar lines, BPMN-Q end events match every end
event in the business process. If the business process has several end events in
concurrent paths, then the triggering of all of these events indicates termination
of the business process instance and, thus, matches a BPMN-Q end event.

$FWLYLW\ 

(a) Activity (b) Start (c) End (d) Path edge

event event

Fig. 8.10: BPMN-Q modelling primitives

BPMN-Q activities match process activities. Recall that activities in pro-

cess models are translated into state transitions in the state space. However,
temporal logic refers only to atomic propositions for states. In order to match
the activities of a query with activities in a process model, BPMN-Q requires
that each state includes an atomic proposition indicating the activity that has
led to that state.

$  % $  %
©OHDGVWRª ©SUHFHGHVª

(a) (b)

Fig. 8.11: Path edge quantifiers in BPMN-Q

A directed edge in BPMN-Q is a path edge and is not directly comparable

to the sequence flow edges in BPMN. To make the difference clear, the former
is marked with a double forward slash (//), as shown in Fig. 8.10d. A path
edge matches a path of arbitrary length in the state space, that is, a sequence
of any number of state transitions. A path edge is interpreted as “there exists
a path in the state space”. Path edges can have the following annotations.
 8.5 Business Process Compliance 259

Leads-to The keyword «leads to» denotes a response condition. As depicted

in Fig. 8.11a, the occurrence of activity A implies the future occurrence of
activity B.
Precedes The keyword «precedes» is analogous to «leads to» and specifies a
precedence. An example is shown in Fig. 8.11b: If activity B occurs, then
A must have occurred before it.
The difference between «leads to» and «precedes» is visualised using the busi-
ness process model shown in Fig. 8.12. The «leads to» query in Fig. 8.11a
requires that the occurrence of A is eventually responded to with an occurrence
of B. We can conclude that this query is not satisfied, because the process
model allows choosing between activities B and C , owing to the exclusive
gateway. Hence, activity B need not follow A.
In contrast, the «precedes» query shown in Fig. 8.11b, which requires
that an occurrence of activity B is always preceded by activity A is satisfied
indeed. If the upper branch is chosen and B has been executed, then A has
been executed previously. If activity C is chosen, then the condition of the
requirement does not even apply.
On the other hand, we can say that B leads to D in Fig. 8.12, because
after B has been executed, D will always be executed. But B does not precede
D, because activity C may have been executed before D.

A D

Fig. 8.12: Example of the difference between the BPMN-Q «leads to» and
«precedes» path edge quantifiers

Path edges can also include the keyword Exclude, which expresses the
condition that a particular activity must not appear on the path, i.e., cannot
be executed in the sequence that is represented by the path edge. This activity
is referred to by a parameter of the keyword. For instance, Exclude(A) denotes
that execution of activity A is excluded on the path.
In the present example, all activities can be executed (in different compu-
tations), so that any Exclude annotation involving activities in the process
model would not be matched.

8.5.2 Compliance Rules and Patterns

After informally introducing the modelling primitives of BPMN-Q, we now

discuss how they can be used to construct compliance rules. Compliance rules
260 8 Verification

are based on patterns, which are translated into corresponding CTL formulas
that can be checked against the state space of the business process.

Elementary Patterns

Patterns in BPMN-Q can be distinguished into ordering patterns and occur-

rence patterns. Ordering patterns describe in which order a set of activities
must appear. Occurrence patterns require that a particular activity must occur
in every instance of a business process, or ensure the absence of an activity in a
complete process instance or a part of it. We shall first introduce patterns and
their corresponding CTL formulas and then continue with an example of these
patterns. We have already presented an example of the two most essential
BPMN-Q ordering patterns above.
The pattern depicted in Fig. 8.11a is called the response pattern. An
occurrence of activity A is responded to eventually with an occurrence of
activity B. The response pattern is mapped to the following CTL formula:

AG(A → AF(B)).

This pattern is the central requirement for synchronous message-based commu-

nication (see subsection 4.2.2), where every request received must be responded
to.
The second essential pattern is the precedence pattern, denoted by the
keyword «precedes» and shown in Fig. 8.11b. This pattern requires that an
occurrence of activity B is always preceded by an occurrence of activity A.
The following CTL expression formalises the precedence pattern:

AG(¬E[¬A U B]).

This formula states that there exists no path where activity A is not executed
until B has occurred. It mirrors the response pattern in that every response
message must be preceded by a request.

 $
©OHDGVWRª

Fig. 8.13: BPMN-Q global presence pattern

A variation of the response pattern leads to the global presence pattern,

depicted in Fig. 8.13, which states that an activity must be executed at some
time after the process has been initialised. Hence, that activity must occur in
every process instance, which is expressed formally as follows:

AG(start → AF(B)).
 8.5 Business Process Compliance 261

The formalisation of the pattern in CTL is almost identical to that of the

elementary response pattern, except that the start event is not an activity.
Therefore, we introduce an atomic proposition start that holds only in the
initial state of the state space of the business process model.

 ([FOXGH $
©OHDGVWRª

Fig. 8.14: BPMN-Q global absence pattern

Using the Exclude annotation, we can also express the global absence of an
activity in every business process instance. This is shown in Fig. 8.14. This
pattern consists of a path that connects the start and end of a business process.
The exclusion of A states that there exists no such path, on which A occurs
between the start and termination of a business process. Similarly to the start
event, we also introduce an atomic proposition end that is true in every final
state of the state space. This leads to the following CTL expression:

AG(start → A[¬A U end]).

The occurrence of the start event implies that, in every path, the atomic
proposition A must remain false, i.e., activity A must not be executed, until
end becomes true, which indicates the termination of the business process.
A modification of the global absence pattern allows the presence of a
particular activity to be excluded in only some region of a business process,
i.e., between two activities. For this purpose, the start and end events in the
pattern are replaced with particular activities, which is mirrored in the CTL
formula by replacing the atomic propositions start and end with the atomic
propositions for the respective activities.
For an example of a BPMN-Q pattern and its evaluation, recall the business
process for reviewing a scientific manuscript, which we introduced in Fig. 5.26.
Briefly, the process captures the activities from the receipt of a review request
to the sending of the review by the reviewer to the programme committee
chairperson.
Figure 8.15 shows the state space for this business process, derived from
the Petri net that corresponds to the process model. Looking at the state
space, it becomes obvious that it follows a tree structure, which is required for
the proper annotation of states with atomic propositions for activities, as we
have argued above. Also, we have reused the abbreviations of activity names
for the atomic propositions of the states.
For this business process, we state the following compliance rules:
1. In every reviewing process, a decision to accept or reject a review must be
taken.
2. When a review has been accepted, a response must be sent.
262 8 Verification

3. A review cannot be sent before a paper has been received.

The first pattern is comparatively straightforward, as it expresses the global
presence of the activity Decide on Reviewing (DR), which leads, according to
the above pattern, to the following CTL formula:
AG(start → AF(DR)).
Looking at the state space, we see that in every path that starts in the initial
state, the state s1 that satisfies the atomic proposition DR is visited, which
satisfies the compliance rule.
The second rule is an instance of the response pattern. Every acceptance of
a review (AR) must eventually be followed by the sending of the review (SR):
AG(AR → AF(SR)).
This compliance rule is not satisfied, because there exist several paths in the
state space in Fig. 8.15 that start in the state s3 but do not lead to the state s8 –
the only state where SR evaluates to true. In the process model in Fig. 5.26,
this is caused by the interrupting boundary event Cancellation Received, which
cancels the preparation of the review.
The last compliance rule is a little more difficult. Looking at the pattern
in Fig. 8.16, we observe that the occurrence of Get Paper (GP) must not be
preceded by Sending Review (SR). In other words, the review cannot be sent
before a paper has been received by the reviewer.
The BPMN-Q pattern for this kind of compliance rule is called the before
scope absence pattern and states that in the scope before an activity, another

[RU\HV $5 *3E *3W 35E 35W 65 HQG

V V V V V V V V

IJ
W W W W 
V V V V

6$ 6$ 6$ 6$
VWDUW
'5 V V V V
V V
HQG HQG HQG HQG
V V V V

IJ IJ IJ IJ
   

IJ
V V V 

[RUQR 6& HQG

Fig. 8.15: State space tree for the reviewing process presented in Fig. 5.26
 8.5 Business Process Compliance 263

 ([FOXGH 65 *3
©SUHFHGHVª

Fig. 8.16: Example of the before scope absence pattern in BPMN-Q

activity must be absent. This pattern is depicted in Fig. 8.16 and is formalised
by the following CTL formula:

¬EF(start ∧ EF(SR ∧ EF(GP))).

This expression states that no path exists that begins with the start event of
the process, continues at some point with SR and allows GP to be executed
afterwards. Note that the pattern permits SR to be executed after GP.
Looking at the process model, it is obvious that this compliance rule is
satisfied, because GP and SR lie on a path of the business process model and
therefore cannot be executed in the “wrong” order.
However, we should bear in mind that process models and compliance rules
are typically specified by different persons with different responsibilities and
that we are addressing the automatic verification of compliance rules using
CTL and state spaces as formal models for model checking. Hence, we should
apply the CTL formula to the state space shown in Fig. 8.15, verify it using a
CTL model checker, and deduce that in fact no path exists that allows SR to
be executed such that it can be followed by GP.

Advanced Patterns

The patterns introduced above provide building blocks to express more complex
compliance rules by combining them. This results in advanced BPMN-Q
patterns. Looking at the elementary patterns above, we observe that each of
them comprises a start node and an end node, both of which can be events or
activities, and a path edge that is qualified with one of the keywords «leads to»
and «precedes» and may also be annotated with Exclude. In fact, the CTL
formula results from the particular configuration of path edges in the pattern,
the nodes are represented by atomic propositions in the CTL formulas.

$5  35  65
©SUHFHGHVª ©OHDGVWRª

Fig. 8.17: An advanced compliance rule made up of the precedence and response
patterns

To express more advanced compliance rules, we combine several path edges

with nodes in a single BPMN-Q query. An example is shown in Fig. 8.17. The
264 8 Verification

compliance rule comprises two elementary patterns, the precedence pattern,

which requires that if Prepare Review (PR) is executed, the activity Accept
reviewing (AR) has been executed previously, and the response pattern, which
requires that Send Review (SR) is executed after Prepare Review (PR) has
been executed.
Formally, the combination of several elementary compliance patterns implies
their logical conjunction, which leads to the following CTL formula:

AG(¬E[¬AR U PR]) ∧ AG(PR → AF(SR)).

Note that this compliance rule requires the execution of AR and SR only if
PR is executed.
A commonly used pattern is the between scope presence pattern, which
requires that an activity B must always be executed after an activity A and
before another activity C if any one of the activities A and C is executed.
This is modelled in BPMN-Q using a combination of the response and prece-
dence patterns, as depicted in Fig. 8.18. The formalisation of that pattern is
straightforward:

AG(A → AF(B)) ∧ AG(¬E[¬B U C]).

$  %  &
©OHDGVWRª ©SUHFHGHVª

Fig. 8.18: Between scope presence pattern in BPMN-Q

Looking at the pattern closely, we conclude that it requires that B must

eventually follow A if A is executed, and B must precede C if C is executed.
However, it does not require that B and C are executed together.
Extending the between scope pattern slightly, we can express a stronger
compliance rule that states that if either of the activities A and C is executed,
then the other must be executed as well: A precedes C and C responds to A,
and B is executed between them. This extension is shown in Fig. 8.19. We
leave it to the reader to construct the formalisation of this pattern in CTL.


©OHDGVWRª

$  %  &
©OHDGVWRª ©SUHFHGHVª


©SUHFHGHVª

Fig. 8.19: A stronger between scope presence pattern in BPMN-Q

 8.5 Business Process Compliance 265

Another compliance pattern that is in widespread use is the mutual ex-

clusion pattern, which states that of two activities only one can be executed,
whereas the other must not be executed in the same process instance. An
example in the case of the reviewing process illustrated in Fig. 5.26 is the
requirement that a review can be either accepted (AR) or denied (SC ), i.e.,
both activities must never be executed together.
It shall come at no surprise that a pattern with this name is constructed
from elementary absence patterns, i.e., path edges that exclude the execution
of certain activities. The mutual exclusion pattern for abstract activities A
and B is visualised in Fig. 8.20.

 ([FOXGH $ %  ([FOXGH $
©SUHFHGHVª ©OHDGVWRª

Fig. 8.20: Mutual exclusion pattern in BPMN-Q

Looking at the BPMN-Q query, we observe that the execution of activity

B excludes the execution of activity A at any time before or after B. However,
it does not state explicitly that the execution of A implies the absence of B.
Nevertheless, this is also satisfied implicitly. The formalisation of the mutual
exclusion pattern in CTL shows this:

¬EF(start ∧ EF(A ∧ EF(B))) ∧ AG(B → A[¬A U end]).

Let us first elaborate on the second part of the pattern on the right-hand side
of the logical conjunction (∧), which is expressed using the after scope absence
pattern. This subformula states that in all states, it holds globally that the
occurrence of B in the state space requires that A must not ever occur before
the process terminates with the atomic proposition end. Vice versa, this also
means that if B does not occur, then A can occur. However, if A occurs then
B must not have occurred before it, otherwise the compliance rule is violated.
Furthermore, it is also allowed that neither of A and B is executed at all.
The first part of the CTL formula is analogous, but it uses the before scope
absence pattern. Here, the formula requires that no such path exists where
B can be executed after A. Hence, the execution of A excludes the execution
of B, but if A is not executed, then no restriction on the execution of B is
imposed.

Correctness Criteria in BPMN-Q

Before we conclude this section, we shall attempt to shed some light on some
rather generic correctness criteria for process models. The above examples of
compliance rules were domain-specific. That is, for the particular domain of
reviewing scientific publications, we expressed a number of requirements that
266 8 Verification

contribute to the correct execution of the business process of reviewing from

an expert’s point of view.
In contrast, generic correctness criteria are applicable to all business pro-
cesses and, to some extent, even to all discrete dynamic systems, no matter
what business domain they are in. Here, we address two of these criteria that
can be expressed by BPMN-Q queries.

 $ 
©OHDGVWRª

Fig. 8.21: Participation and termination pattern in BPMN-Q

The first generic correctness criterion states that every activity in a business
process model should be able to contribute to the successful termination of the
process. Therefore, we refer to it as the participation and termination pattern.
In detail, this means that every activity participates in a process instance,
and the process eventually reaches an end event after the activity has been
executed. For one activity, this is shown in Fig. 8.21 and is formalised in the
following CTL expression:

EF(start → A) ∧ AG(A → AF(end)).

Recall the semantics of BPMN-Q path edges, which we introduced informally

on page 258. An unqualified path edge is used in the left part of the CTL
formula and states that there exists a path from the initialisation of the
business process, denoted by the atomic proposition start, to the execution of
activity A. The right part of the formula states additionally that if activity A
is executed, then the process must also terminate properly, i.e., reach a state
in which end becomes true.
For an application of this correctness criterion, look at the abstract process
model depicted in Fig. 8.22. After the process starts, a decision needs to be
taken, based on whether activity A or B is executed. If A is executed, another
choice presents itself. If the upper path is chosen, the process terminates
successfully in the only final state, s4 . If the lower path is chosen in the second
choice or activity B is executed, the process gets stuck, because the parallel
join gateway requires that both incoming edges are signalled, but because of
the preceding exclusive split gateway only one of them can terminate. Hence,
in these two cases, the process is in a deadlock and cannot terminate properly.
The deadlock is also apparent in the state space, shown in Fig. 8.22b. The
states s1 , with atomic proposition xor 1.2 , and s5 , with xor 2.2 , represent the
result of making choices, and no final state with the atomic proposition end is
reachable anymore from either state.
Returning to the above correctness criterion, we see that for both activity
A and activity B the first part of the BPMN-Q query is satisfied; there exists
 8.5 Business Process Compliance 267

[RU HQG

V V IJ
[RU $

 V V
VWDUW [RU
 $ 
V V IJ
[RU %

 % V V IJ

(a) BPMN process model (b) State space

Fig. 8.22: A business process with a deadlock

a path from the initial state in the state space to their execution, denoted by
the atomic propositions A and B, respectively, in Fig. 8.22b. For activity A,
there exists also a path to a terminating state, s4 . However, not all paths in
the state space lead to a state where the atomic proposition end becomes true.
Hence, the criterion is violated, because there exists the possibility that the
process does not terminate properly after A has been executed.
Recall, that the correctness query in Fig. 8.21 requires that activity A can
participate in a business process, i.e., it can be executed, and its execution
leads to the successful termination of the process. For a generic correctness
check of a business process, we need to replicate the correctness query for
every activity that exists in the business process model.
Let Σ be the set of activities {a1 , a2 , . . . , an } in a business process model.
The participation of all activities and the proper termination of the process
can be verified as follows:

∀ ai ∈ Σ : EF(start → ai ) ∧ AG(ai → AF(end)).

However, this correctness criterion would not be violated if the business

process ran into a deadlock before any activity was executed. This shortcoming
is solved with the compliance rule shown in Fig. 8.23 that provides a shortcut
to ensuring freedom from deadlocks in behavioural models in general and
business processes in particular.


©OHDGVWRª

Fig. 8.23: BPMN-Q query for freedom from deadlocks

268 8 Verification

The beauty of this correctness query lies in its simplicity, which is also
revealed by its formalisation in CTL:

AG(start → AF(end)).

This correctness rule states unpretentiously that if a process starts, it must

eventually terminate in a final state.

8.5.3 Compliance Checking

For every BPMN-Q compliance pattern and complex query that we have
introduced above, there exists a precise formalisation in CTL. We have also
briefly covered the topic of CTL model checking in subsection 8.3.2. Because
every BPMN-Q compliance rule can be transformed into an equivalent CTL
formula, BPMN-Q compliance rules can be checked against the state space of
a business process model.
As mentioned in Section 8.1, model checkers distinguish between positive
and negative verification results. If a process model satisfies a compliance rule,
i.e., the temporal logic expression is satisfied, nothing remains to be done.
However, if a compliance rule is violated, then the process model needs to be
mended. This can be a difficult task if no information about the reason for
the violation is given. Therefore, model checkers provide information about
the sequence of state transitions that leads to a violation of the temporal logic
expression.
This information is, however, of limited use, because the model checker
returns only the first of potentially many sequences that lead to a violation.
In addition, the sequence of state transitions needs to be mapped back to the
state space and from there to the business process model to identify the root
cause of the violation, which requires manual effort.
For this reason, anti-patterns have been introduced into BPMN-Q as a
means to explain the violation of a compliance rule visually in the business
process model under examination. If the formal property expressed in a
BPMN-Q compliance rule is not satisfied by a business process model, an
anti-pattern rule is constructed. By matching this anti-pattern rule against the
business process model, we can identify and highlight all paths, i.e., complete
fragments of the process model, that violate the compliance rule.
Formally, anti-pattern rules are constructed from compliance rules by the
negation of their formal specifications in CTL. For each BPMN-Q pattern,
an anti-pattern exists. The following example shows this negation for the
response pattern, where we have applied the CTL equivalence rules introduced
in Section 8.2.2.
 8.5 Business Process Compliance 269

¬ (AG(A → AF(B))) (1)

⇐⇒ ¬ (AG(¬A ∨ AF(B))) (2)
⇐⇒ EF(¬(¬A ∨ AF(B))) (3)
⇐⇒ EF(A ∧ ¬AF(¬B)) (4)
⇐⇒ EF(A ∧ EG(¬B)) (5)
In the first step (1), we negate the complete CTL formula and then
resolve the implication in (2). We use the equivalence ¬AG(ϕ) ⇐⇒ EF(¬ϕ)
to propagate the negation to the subformulas of the CTL expression (3). In (4),
we resolve the logical conjunction (∧) using De Morgan’s laws, before we also
resolve the negation of the temporal operator using ¬AF(ϕ) ⇐⇒ EG(¬ϕ).
Recall that the response pattern states that if an activity A is executed, it
is eventually followed by the execution of an activity B. The negation of the
corresponding CTL formula states that, starting from the initial state, there
exists a path (EF) in which A is executed and afterwards there exists a path
that leads to the end of the business process without B ever being executed.
Every path in the state space of the business process that satisfies the
negated CTL formula violates the original compliance rule.

$  ([FOXGH %

Fig. 8.24: BPMN-Q anti-pattern for the response pattern

The negated CTL formula can also be expressed using BPMN-Q, as shown
in Fig. 8.24. Note that the path in the anti-pattern is not qualified. This is the
case because the pattern states that there exists a path, whereas BPMN-Q
path qualifiers apply a path edge to all possible paths (see subsection 8.5.1).
The anti-patterns for the other elementary patterns can be constructed
similarly. Figure 8.25 shows anti-patterns for the precedence, global presence,
and global absence patterns.
If a compliance rule is composed of several elementary patterns, its coun-
terpart is nevertheless constructed by negating the complete CTL formula
for the compliance rule. We have explained earlier that complex rules are
constructed by joining the CTL formalisations of the elementary patterns
using logical conjunction. According to De Morgan’s laws, the negation of
conjoined statements is equivalent to the disjunction of the negated statements.
Formally, this is expressed as follows. Let ϕ1 , ϕ2 , . . . , ϕn be CTL formulas for
elementary compliance patterns:
¬(ϕ1 ∧ ϕ2 ∧ · · · ∧ ϕn ) ⇐⇒ ¬ϕ1 ∨ ¬ϕ2 ∨ · · · ∨ ¬ϕn .
Consequently, ¬ϕ1 , ¬ϕ2 , . . . , ¬ϕn are the anti-patterns of the elementary com-
pliance patterns. The counterpart of a complex compliance rule is, therefore,
the disjunction of the elementary anti-patterns.
270 8 Verification

 ([FOXGH % $

(a) Anti-pattern for the prece-

dence pattern

 ([FOXGH $  $

(b) Anti-pattern for the (c) Anti-pattern for the global ab-
global presence pattern sence pattern

Fig. 8.25: Various BPMN-Q anti-patterns

Finally, we return to the example of the reviewing process to show how

anti-patterns can be used to identify and highlight the fragment of a process
model that violates a compliance rule. Recall the above example of the response
pattern: if reviewing a manuscript has been accepted, a review must be sent
back. The response anti-pattern has already been introduced above, and is
shown in Fig. 8.24.

$FFHSW *HW3DSHU 3UHSDUH 6HQG

5HYLHZLQJ *3 5HYLHZ 5HYLHZ
\HV

$5 35 65
5HYLHZ
'HFLGHRQ 6HQW 5V
5HYLHZLQJ &DQFHOODWLRQ
'5 5HFHLYHG
5HYLHZLQJ &U
5HTXHVW 6HQG 6HQG
QR

5HFHLYHG 5U &DQFHO $SRORJ\

ODWLRQ 6& 6$
&DQFHOODWLRQ $SRORJ\
6HQW &V 6HQW $V

Fig. 8.26: Process model fragment that is highlighted by the response anti-
pattern

Applied to the reviewing process model shown in Fig. 5.26, this anti-pattern
matches the only path that starts in the initial state of the state space, executes
the activity AR (Accept Reviewing), and leads to a final state while SR is never
executed; see Fig. 8.15. This is the case if, during the preparation of the review,
an exception occurs and the reviewer sends an apology back. Figure 8.26 shows
the part of the process model that is highlighted by the BPMN-Q anti-pattern.
 8.5 Business Process Compliance 271

Bibliographical Notes
We started this chapter by arguing that predicate logic was insufficient to
express the desired properties of a behavioural system in an elegant and formal
way. Instead, we proposed the use of temporal logic, which addresses the
relation between states by means of temporal operators.
Temporal logic goes back to Pnueli (1977), who introduced LTL in the
late 1970s. The second type of temporal logic is CTL, which was put forward
by Clarke and Emerson (1981) and Emerson and Halpern (1985). We have
explained that CTL and LTL are not equivalent in their expressiveness and
that neither supersedes the other. This means that there exist expressions in
each of the logics that cannot be expressed in the other.
The visualisation of possible combinations of temporal operators and CTL
qualifiers in Fig. 8.5 was inspired by Alessandro Artale’s lecture notes for his
course on formal methods at the Free University of Bozen-Bolzano.
Combining LTL and CTL leads to CTL*, which was proposed by Emerson
and Halpern (1986). Every formula that can be expressed in LTL or CTL can
also be expressed in CTL*. Put simply, CTL* removes the restriction in CTL
that every temporal operator must be paired with a qualifier, and this allows
more expressive statements.
A variety of extensions to LTL exist; one of the most notable ones is the
use of past temporal operators, which were added by Lichtenstein et al. (1985).
Past linear temporal logic (PLTL) is not more expressive than pure LTL, which
means that the same properties can be stated in both logics, but PLTL allows
more concise expressions in some cases.
Model checking is the process of testing whether a property is satisfied
by a system using a formal specification of the former and the state space
of the latter. Owing to their different semantics, LTL and CTL use different
approaches. LTL model checking is based on a set-theoretic approach that
incorporates the languages of the property and the system, and was introduced
by Lichtenstein and Pnueli (1985). The approach followed in this chapter is
that of Vardi and Wolper (1986). CTL, in contrast, can be checked by an
algorithmic approach, which was first demonstrated by Clarke et al. (1986).
Karsten Wolf’s group at the University of Rostock provides a rich set of
verification and analysis tools that are available under an open source license.
The Low Level Petri net Analyzer (LoLA) allows us to define properties in
CTL* and to verify whether a given Petri net verifies these properties. LoLA
was introduced by Schmidt (2000).
Besides these research publications, a number of excellent textbooks exists
that cover the topics of temporal logic and model checking in an exhaustive
fashion. We mention those of Baier and Katoen (2008), Clarke et al. (1999b),
and Berard et al. (2010).
In particular, the categories of behavioural properties, of reachability, safety,
liveness, and fairness were inspired by Berard et al. (2010). Safety and liveness
272 8 Verification

are interpreted in several different ways in the body of knowledge related to

temporal logic. Kindler (1994) gives an overview of these interpretations.
We should point out that the terms “safety” and “liveness” are susceptible
to misunderstanding in the context of analysing the behaviour of discrete
dynamic systems. In the general context of automata and relations between
states, these terms are used as we have presented them earlier. However, in
the context of Petri nets (see Section 4.3) safeness expresses the condition that
all places are bounded so as to contain at most one token. For instance, every
condition event net is a safe Petri net. The liveness of a Petri net expresses
the condition that the system modelled by the Petri net can always return
to its initial state. As we have argued above, this is a reachability property
in terms of Section 8.4. van der Aalst et al. (2011) provides a comprehensive
discussion and formalisation of these properties of Petri nets.
BPMN-Q was proposed by Awad (2007). Details of the approach are
available in his PhD thesis, Awad (2010). This work introduces a formal
approach to support the checking of compliance rules at the design time of a
system. In this book, we have referred to patterns that are concerned with the
control flow of business processes. The approach of the thesis goes further and
also incorporates access to data objects.
References

van der Aalst WMP, Basten T (2002) Inheritance of workflows: An approach to

tackling problems related to change. Theor Comput Sci 270(1-2):125–203
van der Aalst WMP, ter Hofstede AHM, Kiepuszewski B, Barros AP (2003) Workflow
patterns. Distributed and Parallel Databases 14(1):5–51
van der Aalst WMP, Weijters T, Maruster L (2004) Workflow mining: Discovering
process models from event logs. IEEE Trans on Knowl and Data Eng 16:1128–1142
van der Aalst WMP, van Hee KM, ter Hofstede AHM, Sidorova N, Verbeek HMW,
Voorhoeve M, Wynn MT (2011) Soundness of workflow nets: classification,
decidability, and analysis. Formal Asp Comput 23(3):333–363
Alur R, Dill DL (1994) A theory of timed automata. Theor Comput Sci 126(2):183–
235
Awad A (2007) BPMN-Q: A language to query business processes. In: Reichert M,
Strecker S, Turowski K (eds) Proc 2nd International Workshop on Enterprise
Modelling and Information Systems Architectures (EMISA’07), LNI, vol P-119,
pp 115–128
Awad A (2010) A compliance management framework for business process models.
PhD thesis, Hasso Plattner Institute, University of Potsdam
Baier C, Katoen JP (2008) Principles of Model Checking. MIT Press
Basten T (1998) In terms of nets: System design with petri nets and process algebra.
PhD thesis, Eindhoven University of Technology
Berard B, Bidoit M, Finkel A, Laroussinie F, Petit A, Petrucci L, Schnoebelen P
(2010) Systems and Software Verification: Model-Checking Techniques and Tools.
Springer
Booch G, Rumbaugh JE, Jacobson I (2005) The Unified Modeling Language user
guide, 2nd edn. Addison-Wesley
Clarke EM, Emerson EA (1981) Design and synthesis of synchronization skeletons
using branching-time temporal logic. In: Kozen D (ed) Workshop on Logics of
Programs, Springer, Lecture Notes in Computer Science, vol 131, pp 52–71
Clarke EM, Emerson EA, Sistla AP (1986) Automatic verification of finite-state
concurrent systems using temporal logic specifications. ACM Trans Program
Lang Syst 8(2):244–263
Clarke EM, Grumberg O, Minea M, Peled D (1999a) State space reduction using
partial order techniques. Int J Software Tools Technol Transfer 2(3):279–287

© Springer International Publishing Switzerland 2016 273

M. Kunze and M. Weske, Behavioural Models,
DOI 10.1007/978-3-319-44960-9
274 References

Clarke EM, Grumberg O, Peled D (1999b) Model Checking. MIT Press

Dijkman RM, Dumas M, Ouyang C (2008) Semantics and analysis of business process
models in BPMN. Information & Software Technology 50(12):1281–1294
Dumas M, La Rosa M, Mendling J, Reijers HA (2013) Fundamentals of Business
Process Management. Springer
Embly DW, Thalheim B (eds) (2011) Handbook of Conceptual Modeling: Theory,
Practice, and Research Challenges. Springer
Emerson EA, Halpern JY (1985) Decision procedures and expressiveness in the
temporal logic of branching time. J Comput Syst Sci 30(1):1–24
Emerson EA, Halpern JY (1986) “Sometimes” and “Not Never” revisited: On
branching versus linear time temporal logic. J ACM 33(1):151–178
Eshuis R, Grefen P (2007) Structural matching of BPEL processes. In: European
Conference on Web Services, IEEE Computer Society, Washington, DC, pp
171–180
Euzenat J, Shvaiko P (2007) Ontology Matching. Springer
Favre C, Völzer H (2012) The difficulty of replacing an inclusive or-join. In: Barros
AP, Gal A, Kindler E (eds) Proc Business Process Management, Springer, Lecture
Notes in Computer Science, vol 7481, pp 156–171
Flynn MJ, Agerwala T (1973) Comments on capabilities, limitations and correctness
of Petri nets. In: Lipovski GJ, Szygenda SA (eds) Proc 1st Annual Symposium
on Computer Architecture, December 1973, ACM, pp 81–86
Gfeller B, Völzer H, Wilmsmann G (2011) Faster or-join enactment for BPMN 2.0.
In: Dijkman RM, Hofstetter J, Koehler J (eds) Proc Business Process Model and
Notation: Third International Workshop, BPMN 2011, Springer, Lecture Notes
in Business Information Processing, vol 95, pp 31–43
van Glabbeek RJ (1993) The linear time - branching time spectrum II. In: Theories
of Concurrency: Unification and Extension, Springer, Lecture Notes in Computer
Science, vol 715, pp 66–81
van Glabbeek RJ, Goltz U (2001) Refinement of actions and equivalence notions for
concurrent systems. Acta Informatica 37:229–327
Hack M (1976) Petri net languages. Tech. Rep. MIT-LCS-TR-159, Massachusetts
Institute of Technology
Harel D (1987) Statecharts: A visual formalism for complex systems. Sci Comput
Program 8(3):231–274
Harel D, Rumpe B (2004) Meaningful modeling: What’s the semantics of "semantics"?
IEEE Computer 37(10):64–72
Henderson-Sellers B (2012) On the Mathematics of Modelling, Metamodelling, On-
tologies and Modelling Languages. Springer Briefs in Computer Science, Springer
Hidders J, Dumas M, van der Aalst WMP, ter Hofstede AHM, Verelst J (2005)
When are two workflows the same? In: Australasian Symposium on Theory of
Computing, pp 3–11
Hoare CAR (1978) Communicating sequential processes. Commun ACM 21(8):666–
677
Hoare CAR (1980) A model for communicating sequential processes. Tech. rep.,
Oxford University Computing Laboratory
Hopcroft JE, Motwani R, Ullman JD (2003) Introduction to automata theory,
languages, and computation, 2nd edn. Addison-Wesley
Huffman DA (1954) The synthesis of sequential switching circuits. Tech. Rep. 274,
Massachusetts Institute of Technology
 References 275

Jensen K, Kristensen LM (2009) Coloured Petri Nets - Modelling and Validation of

Concurrent Systems. Springer
Juhás G, Lehocki F, Lorenz R (2007) Semantics of Petri nets: A comparison. In:
Henderson SG, Biller B, Hsieh M, Shortle J, Tew JD, Barton RR (eds) Proc
Winter Simulation Conference, pp 617–628
Kindler E (1994) Safety- and liveness properties: A survey. In: EATCS Bulletin,
vol 53
Kindler E (2006) On the semantics of epcs: Resolving the vicious circle. Data Knowl
Eng 56(1):23–40
Kunze M (2013) Searching business process models by example. PhD thesis, Hasso
Plattner Institute, University of Potsdam
Kunze M, Luebbe A, Weidlich M, Weske M (2011a) Towards understanding process
modeling – the case of the BPM Academic Initiative. In: Business Process Model
and Notation, Springer, Lecture Notes in Business Information Processing, vol 95,
pp 44–58
Kunze M, Weidlich M, Weske M (2011b) Behavioral similarity – a proper metric.
In: Business Process Management, Springer, Lecture Notes in Computer Science,
vol 6896, pp 166–181
Lichtenstein O, Pnueli A (1985) Checking that finite state concurrent programs
satisfy their linear specification. In: Conference Record of the Twelfth Annual
ACM Symposium on Principles of Programming Languages, ACM Press, pp
97–107
Lichtenstein O, Pnueli A, Zuck LD (1985) The glory of the past. In: Proc Logics of
Programs, Springer, Lecture Notes in Computer Science, vol 193, pp 196–218
Mahleko B, Wombacher A, Fankhauser P (2005) Process-annotated service discovery
facilitated by an n-gram-based index. In: e-Technology, e-Commerce, and e-
Services, IEEE Computer Society, Los Alamitos, CA, vol 0, pp 2–8
Mansar SL, Reijers HA (2005) Best practices in business process redesign: Validation
of a redesign framework. Comput Ind 56:457–471
Mealy GH (1955) A method for synthesizing sequential circuits. Bell System Technical
Journal 34(5):1045–1079
Milner R (1980) A Calculus of Communicating Systems, Lecture Notes in Computer
Science, vol 92. Springer
Milner R (1982) A Calculus of Communicating Systems. Springer, Secaucus, NJ
Moore EF (1956) Gedanken experiments on sequential machines. In: Automata
Studies, Princeton University, pp 129–153
zur Muehlen M, Recker J (2008) How much language is enough? Theoretical and
practical use of the Business Process Modeling Notation. In: Bellahsene Z, Léonard
M (eds) Proc Advanced Information Systems Engineering, 20th International
Conference, CAiSE 2008, Springer, Lecture Notes in Computer Science, vol 5074,
pp 465–479
Object Management Group (2011) Business Process Model and Notation (BPMN)
Version 2.0
Object Management Group (2015) Unified Modeling Language (UML) Version 2.5
Park D (1981) Concurrency and automata on infinite sequences. In: Theoretical
Computer Science, Springer, Lecture Notes in Computer Science, vol 104, pp
167–183
Petri CA (1962) Kommunikation mit Automaten. PhD thesis, University of Hamburg
276 References

Pnueli A (1977) The temporal logic of programs. In: 18th Annual Symposium on
Foundations of Computer Science, IEEE Computer Society, pp 46–57
Pomello L, Rozenberg G, Simone C (1992) A survey of equivalence notions for net
based systems. In: Advances in Petri Nets, Springer, Lecture Notes in Computer
Science, vol 609, pp 410–472
Rabin MO, Scott D (1959) Finite automata and their decision problems. IBM J Res
Dev 3(2):114–125
Reisig W (2013) Understanding Petri Nets: Modeling Techniques, Analysis Methods,
Case Studies. Springer
Russell N, Hofstede AHMT, van der Aalst WM, Mulyar N (2006) Workflow control
flow patterns: A revised view. Tech. rep., BPM Center Report BPM-06-22
Schmidt K (2000) Lola: A low level analyser. In: ICATPN, pp 465–474
Stachowiak H (1973) Allgemeine Modelltheorie. Springer
Valmari A (1998) The state explosion problem. In: Lectures on Petri Nets I: Basic
Models, Advances in Petri Nets, Springer, Lecture Notes in Computer Science,
vol 1491, pp 429–528
Vardi MY, Wolper P (1986) An automata-theoretic approach to automatic program
verification (preliminary report). In: Proc Symposium on Logic in Computer
Science (LICS ’86), IEEE Computer Society, pp 332–344
Weber B, Reichert M, Rinderle-Ma S (2008) Change patterns and change support
features: Enhancing flexibility in process-aware information systems. Data Knowl
Eng 66(3):438–466
Weidlich M (2011) Behavioural profiles – a relational approach to behaviour consis-
tency. PhD thesis, Hasso Plattner Institute, University of Potsdam
Weidlich M, Weske M, Mendling J (2009) Change propagation in process models
using behavioural profiles. In: High Performance Computing, Networking Storage
and Analysis, IEEE Computer Society, pp 33–40
Weidlich M, Dijkman R, Mendling J (2010) The ICoP framework: Identification
of correspondences between process models. In: Advanced Information Systems
Engineering, Springer, Berlin, Heidelberg, Lecture Notes in Computer Science,
vol 6051, pp 483–498
Weidlich M, Mendling J, Weske M (2011) Efficient consistency measurement based
on behavioral profiles of process models. IEEE Trans Software Eng 37(3):410–429
Weske M (2012) Business Process Management: Concepts, Languages, Architectures,
2nd edn. Springer
Winskel G, Nielsen M (1995) Models for concurrency. In: Abramsky S, Gabbay DM,
Maibaum TSE (eds) Handbook of Logic in Computer Science, vol 4, Oxford
University Press, pp 1–148
Index

abstraction, 11, 15 definition, 198

activity lifecycle equivalence, 199
state transition diagram, 140 weak bisimulation, 188
alignment, 228 BPMN, 141
alphabet, 29 activities, 141
sequence, 31 collaboration diagram, 153
analysis concurrent behaviour, 149
validation, 19 mapping to Petri nets, 142
verification, 19 sequential behaviour, 145
arc expression, 119 subprocess, 152
atomic proposition, 236 BPMN-Q
automaton, 40 anti-patterns, 268
deterministic, 46 path edge, 258
extended, 54 pattern, 260
state space, 173 before scope absence, 262
finite, 42 between scope presence, 264
Mealy, 51, 168 freedom from deadlocks, 267
state space, 169 global absence, 261, 269
Moore, 49, 166 global presence, 260, 269
state space, 167 mutual exclusion, 265
non-deterministic, 47, 60 participation and termination, 266
timed, 63 precedence, 260, 269
response, 260, 268
behaviour, 3 query, 257
behavioural profile, 223 branching bisimulation
behavioural relation, 223 definition, 202
exclusiveness, 223 equivalence, 202, 205, 211
interleaving order, 223 business process
strict order, 223 definition, 137
behavioural similarity, 217 Business Process Model and Notation,
binding, 120 see BPMN
bisimulation, 188, 197
branching bisimulation, 188 causality, 33

© Springer International Publishing Switzerland 2016 277

M. Kunze and M. Weske, Behavioural Models,
DOI 10.1007/978-3-319-44960-9
278 Index

coloured Petri net, 119 event, 3, 33

arc expression, 119 execution sequence, 32, 43
binding, 120 complete, 43
colour set, 119 execution trace, 188, 193
guard, 119
combined fragment, 105 fairness, 256
communication, 13, 94 Fibonacci sequence, 235
blocking, 96 fragment, 105
message, 94 guard, 66, 106
asynchronous, 98
message, 95 interacting systems, 93
synchronous
delivery-based, 96, 102 Jaccard similarity, 221, 225
response-based, 97, 102 labelled transition system, 29
compatibility, 192 sequence, 32
composite state, 72 language, 43
collapsed, 72 lifecycle inheritance, 216
expanded, 72 lifeline, 101
transition, 73 Linear Temporal Logic, 237
comprehension, 12 equivalence, 240
computation, 237 temporal operator, 238
Computation Tree Logic, 242 liveness, 255
equivalence, 246 LTL, see Linear Temporal Logic
quantifier, see quantifier
concurrent behaviour, 25 mapping, 11, 16
condition, 56 Mealy automaton, 51
condition event net, 111 message communication, 94
consensus, 13 Message Sequence Charts, 101
consistency, 189, 192 model, 4
CTL, see Computation Tree Logic modelling goals, 12
modelling languages, 10
data models, 13 modularisation, 93, 101
deadlock, 100, 208, 232, 254, 266 moment of choice, 197
descriptive models, 9 Moore automaton, 49
deterministic behaviour, 45
development methodology, 17 n-grams, 221
dynamic system, 21 non-deterministic behaviour, 45
discrete, 23 observer, 188
concurrent, 82 orthogonal state, 85
continuous, 22 region, 86
sequential, 39, 82 signal, 89
synchronisation, 92
effect, 68
episode, 103 participant, 101
equivalence, 188 Petri net, 107, 272
bisimulation, 188 Coloured, 119
branching bisimulation, 188 concurrency, 112
trace, 188 conflict, 111
weak bisimulation, 188 definition, 108
 Index 279

exclusive choice, 112 composite state, 73

inhibitor arc, 116 conditional, 56
marking, 109 silent, 59, 200
marking, shorthand notation, 109 state transition system, 26
postset, 108 static system, 21
preset, 108 submachine, 70, 86
reset arc, 116
place transition net, 114 temporal operator, 235, 238
extended, 118 eventually, 238
pragmatics of models, 11 globally, 238
prescriptive models, 9 next, 238
projection inheritance, 211 until, 238
projection/protocol inheritance, 216 trace, 193
properties of models, 10 trace equivalence, 193, 205, 242
abstraction, 11 definition, 193
mapping, 11 trace inheritance, 209
pragmatics, 11 trigger, 65
protocol inheritance, 212 time, 66
variable, 67
quantifier, 243
all, 244
Unified Modeling Language, 4
exists, 244
state machine, 64, 83
reachability, 165, 173, 253
refinement, 189 valuation, 166
variable, 55
safety, 254 assignment, 55
sequence, 30 domain, 55
sequence diagrams, 101 initial value, 56
sequential behaviour, 25
signal, 89 weak bisimulation
similarity function, 217 definition, 201
simulation, 198 equivalence, 201, 205
state, 4, 6 workflow pattern
composite, 72 cancel case, 136
final, 40 deferred choice, 135
initial, 40 exclusive choice, 129
orthogonal, 85 multi-choice, 130
state explosion, 181, 185 multiple-instances, 134
state machine, 64 parallel split, 127
submachine, 70 sequence, 126
state space simple merge, 130
infinite, 174 structured discriminator, 133
tree, 243 structured synchronisation merge, 131
state transition, 6 synchronisation merge, 127