Formal Methods for

the Specification and the Verification

of Concurrent and Distributed Systems

Daniele Gorla
Dipartimento di Informatica
“Sapienza" Università di Roma

Cordoba - April 1st, 2013

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 1 / 38
Outline

1 Motivations for using Formal Methods

2 Importance of Concurrent (Reactive) Systems
3 Reactive systems: models, languages, verification tools
4 Reactive systems: applications

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 2 / 38
Outline

1 Motivations for using Formal Methods

2 Importance of Concurrent (Reactive) Systems
3 Reactive systems: models, languages, verification tools
4 Reactive systems: applications

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 2 / 38
Outline

1 Motivations for using Formal Methods

2 Importance of Concurrent (Reactive) Systems
3 Reactive systems: models, languages, verification tools
4 Reactive systems: applications

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 2 / 38
Outline

1 Motivations for using Formal Methods

2 Importance of Concurrent (Reactive) Systems
3 Reactive systems: models, languages, verification tools
4 Reactive systems: applications

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 2 / 38
The correctness problem
Software is vital for modern society.
Software these days
manages our finances
regulates communication and power generation
controls airplanes
controls safety-critical industrial processes
processes security-critical information
is inside just about anything:
I mobile devices, smart devices, smart cards, cars

The correctness problem is of evergrowing importance.

The efficient development of “dependable” software (i.e. implements the
specification of its intended behaviour correctly)

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 3 / 38
The correctness problem
Software is vital for modern society.
Software these days
manages our finances
regulates communication and power generation
controls airplanes
controls safety-critical industrial processes
processes security-critical information
is inside just about anything:
I mobile devices, smart devices, smart cards, cars

The correctness problem is of evergrowing importance.

The efficient development of “dependable” software (i.e. implements the
specification of its intended behaviour correctly)

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 3 / 38
Software defects may cause BIG failures
Despite its fundamental scientific and practical importance, not
enough attention has been devoted to the correctness and
dependability of systems.
As a result, system crashes are commonplace, sometimes leading to
very costly and even disastrous system failures
I Intel’s Pentium-II bug (1994): in floating-point division unit (Byte
magazine estimated that 1 in 9 billion floating point divides with random
parameters would produce inaccurate results).
I Ariane-5 crash (ESA, $7 billion dollars, 1996): the acceleration caused
a data conversion from a 64-bit floating point to a 16-bit signed integer
value to overflow and raise a hardware exception.
I ...

Tony Hoare (2006): programming is the only engineering

profession that spends half its time and effort on detecting and
correcting mistakes made in the other half of its time.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 4 / 38
Software defects may cause BIG failures
Despite its fundamental scientific and practical importance, not
enough attention has been devoted to the correctness and
dependability of systems.
As a result, system crashes are commonplace, sometimes leading to
very costly and even disastrous system failures
I Intel’s Pentium-II bug (1994): in floating-point division unit (Byte
magazine estimated that 1 in 9 billion floating point divides with random
parameters would produce inaccurate results).
I Ariane-5 crash (ESA, $7 billion dollars, 1996): the acceleration caused
a data conversion from a 64-bit floating point to a 16-bit signed integer
value to overflow and raise a hardware exception.
I ...

Tony Hoare (2006): programming is the only engineering

profession that spends half its time and effort on detecting and
correcting mistakes made in the other half of its time.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 4 / 38
What are formal methods?

Wikipedia (by R. W. Butler)

In computer science, specifically software engineering and hardware
engineering, formal methods are a particular kind of mathematically-based
techniques for the specification, development and verification of software
and hardware systems.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 5 / 38
Concurrent Systems
Ubiquitous computing has increased the interest in systems
which involve multiple processors and multiple programs or processes
which are to some extent autonomous yet at times need to interact or
communicate in order to function effectively.

What is Concurrent Programming

Multiple processes (or threads) working simultaneously
A sequential program has a single thread of control.
A concurrent program has multiple threads of control allowing it
I to perform multiple computations in parallel and
I to control multiple external activities which occur at the same time.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 6 / 38
Why Concurrent Programming

1 Performance: To gain from multiprocessing hardware (parallelism).

2 Distribution: Some problems require a distributed solution, e.g. client
server systems on one machine and the database on a central server
machine.
3 Ease of programming: Some problems are more naturally solved by
concurrent programs.
4 Increased application throughput: an I/O call need only block one
thread.
5 Increased application responsiveness: High priority threads for user
requests.
6 More appropriate structure: For programs which interact with the
environment, control multiple activities and handle multiple events.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 7 / 38
Examples of Concurrent Systems

Operating systems kernels, windowing systems on PC’s

Communication protocols

Web servers, database servers

Embedded real-time systems, electronics, mobile phones, . . .

Safety critical control systems (automotive, aerospace, railway)

Reactive Systems (after David Harel and Amir Pnueli, 1985)

The previous systems compute by reacting to stimuli from their
environment and are known as Reactive Systems.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 8 / 38
(Concurrent) Programming is error prone
Therac-25 computerised radiation therapy machine (at least six
accidents between 1985 and 1987): concurrent programming errors
contributed to accidents causing deaths and serious injuries.
Mars Pathfinder (1997): ‘priority inversion’ among concurrent tasks
caused the on-board computer to reset repeatedly thus reducing
availability for exploration and eventually leading to loss of
communication.
...

For sure you have experienced deadlock on your machine and

pressed restart, even if you have a Mac!

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 9 / 38
(Concurrent) Programming is error prone
Therac-25 computerised radiation therapy machine (at least six
accidents between 1985 and 1987): concurrent programming errors
contributed to accidents causing deaths and serious injuries.
Mars Pathfinder (1997): ‘priority inversion’ among concurrent tasks
caused the on-board computer to reset repeatedly thus reducing
availability for exploration and eventually leading to loss of
communication.
...

For sure you have experienced deadlock on your machine and

pressed restart, even if you have a Mac!

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 9 / 38
Concurrent systems are complicated
Many components may execute in parallel: the complexity arises from
the combinations of ways in which their parts can interact.
The design of such systems requires ways of keeping these
interactions under control.
Concurrency by its very nature introduces phenomena not present in
sequential systems, such as deadlock and livelock.
I Deadlock: a number of components are each awaiting an interaction
from some other component before they can themselves continue.
I Livelock: components descend into an endless sequence of interaction
among themselves, excluding any other components and the outside
world.
These phenomena arise not from individual components but from the
way they are combined.
Nondeterminism can also arise naturally in parallel compositions, for
example when race conditions arise.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 10 / 38
Concurrent systems are complicated
Many components may execute in parallel: the complexity arises from
the combinations of ways in which their parts can interact.
The design of such systems requires ways of keeping these
interactions under control.
Concurrency by its very nature introduces phenomena not present in
sequential systems, such as deadlock and livelock.
I Deadlock: a number of components are each awaiting an interaction
from some other component before they can themselves continue.
I Livelock: components descend into an endless sequence of interaction
among themselves, excluding any other components and the outside
world.
These phenomena arise not from individual components but from the
way they are combined.
Nondeterminism can also arise naturally in parallel compositions, for
example when race conditions arise.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 10 / 38
Concurrent systems are complicated
Many components may execute in parallel: the complexity arises from
the combinations of ways in which their parts can interact.
The design of such systems requires ways of keeping these
interactions under control.
Concurrency by its very nature introduces phenomena not present in
sequential systems, such as deadlock and livelock.
I Deadlock: a number of components are each awaiting an interaction
from some other component before they can themselves continue.
I Livelock: components descend into an endless sequence of interaction
among themselves, excluding any other components and the outside
world.
These phenomena arise not from individual components but from the
way they are combined.
Nondeterminism can also arise naturally in parallel compositions, for
example when race conditions arise.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 10 / 38
Classical View of Computing
Characterization of a Classical Program
A program transforms an input into an output.

Denotational semantics:
a meaning of a program is a partial function from states to states

states ,→ states

Nontermination is bad!
In case of termination, the result is unique.

Is this all we need?

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 11 / 38
Reactive View of Computing
Characterization of a Reactive System
A Reactive System is a system that computes by reacting to stimuli from
its environment.

Key Issues:
parallelism
communication and interaction

Nontermination is good!

The result (if any) does not have to be unique.

The classical denotational approach is not enough for modelling Reactive

Systems

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 12 / 38
Analysis of Reactive Systems

Reactive Systems’ distinguishing features

Interaction (many parallel communicating processes)
Nondeterminism (results are not necessarily unique)
Nontermination is good (systems are expected to run continuously)
There may be no visible result (exchange of messages is used to
coordinate progress)

Even short concurrent programs may be hard to analyze, thus we need to

face a few questions:
1 How can we develop (design) a system that “works”?
2 How do we analyze (verify) such a system?

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 13 / 38
Analysis of Reactive Systems

Reactive Systems’ distinguishing features

Interaction (many parallel communicating processes)
Nondeterminism (results are not necessarily unique)
Nontermination is good (systems are expected to run continuously)
There may be no visible result (exchange of messages is used to
coordinate progress)

Even short concurrent programs may be hard to analyze, thus we need to

face a few questions:
1 How can we develop (design) a system that “works”?
2 How do we analyze (verify) such a system?
A Theory of Concurrency is necessary.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 13 / 38
Concurrency Theory
To deal with concurrent and reactive systems and guarantee their correct
behavior in all possible environments, we need:
1 To study mathematical models for the formal description and analysis
of systems.
2 To devise formal languages for the specification of the possible
behaviour of systems.
3 To develop verification tools and implementation techniques
underlying them.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 14 / 38
Concurrency Theory
To deal with concurrent and reactive systems and guarantee their correct
behavior in all possible environments, we need:
1 To study mathematical models for the formal description and analysis
of systems.
2 To devise formal languages for the specification of the possible
behaviour of systems.
3 To develop verification tools and implementation techniques
underlying them.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 14 / 38
Concurrency Theory
To deal with concurrent and reactive systems and guarantee their correct
behavior in all possible environments, we need:
1 To study mathematical models for the formal description and analysis
of systems.
2 To devise formal languages for the specification of the possible
behaviour of systems.
3 To develop verification tools and implementation techniques
underlying them.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 14 / 38
Concurrency Theory
To deal with concurrent and reactive systems and guarantee their correct
behavior in all possible environments, we need:
1 To study mathematical models for the formal description and analysis
of systems.
2 To devise formal languages for the specification of the possible
behaviour of systems.
3 To develop verification tools and implementation techniques
underlying them.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 14 / 38
A Concurrency Theory
Important Questions:
What is the most abstract view of a reactive system?
Does it capture their relevant properties?
Is it compositional?

Chosen abstraction: the notion of process

Systems evolution is based on process transformation:
A process performs an action and becomes another process.

The Motto (after Tony Hoare and Robin Milner, 1980)

Everything is (or can be viewed) as a process!
Channels, buffers, shared memory, tuple spaces, senders, receivers, . . .
all are processes.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 15 / 38
A Concurrency Theory
Important Questions:
What is the most abstract view of a reactive system?
Does it capture their relevant properties?
Is it compositional?

Chosen abstraction: the notion of process

Systems evolution is based on process transformation:
A process performs an action and becomes another process.

The Motto (after Tony Hoare and Robin Milner, 1980)

Everything is (or can be viewed) as a process!
Channels, buffers, shared memory, tuple spaces, senders, receivers, . . .
all are processes.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 15 / 38
Classical vs. Reactive Computing

Classical Reactive/Concurrent
interaction no yes
nontermination undesirable often desirable
unique result yes no
semantics states ,→ states ???

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 16 / 38
Classical vs. Reactive Computing

Classical Reactive/Concurrent
interaction no yes
nontermination undesirable often desirable
unique result yes no
semantics states ,→ states LTS

Labelled Transition Systems (LTS) describe process behaviour and permit

modelling directly systems interaction.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 17 / 38
Models for Concurrent Processes
Two main mathematical models (or variants thereof) are used:

Kripke Structures
State Labelled Automata: States are labelled with the properties that are
considered relevant (e.g. the value of - the relation between - some
variables)

Labelled Transition Systems (LTS)

Transition Labelled Automata: Transition between states are labelled with
the action that induces the transition from one state to another.

We shall rely on LTS and actions will play an important role.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 18 / 38
Models for Concurrent Processes
Two main mathematical models (or variants thereof) are used:

Kripke Structures
State Labelled Automata: States are labelled with the properties that are
considered relevant (e.g. the value of - the relation between - some
variables)

Labelled Transition Systems (LTS)

Transition Labelled Automata: Transition between states are labelled with
the action that induces the transition from one state to another.

We shall rely on LTS and actions will play an important role.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 18 / 38
Models for Concurrent Processes
Two main mathematical models (or variants thereof) are used:

Kripke Structures
State Labelled Automata: States are labelled with the properties that are
considered relevant (e.g. the value of - the relation between - some
variables)

Labelled Transition Systems (LTS)

Transition Labelled Automata: Transition between states are labelled with
the action that induces the transition from one state to another.

We shall rely on LTS and actions will play an important role.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 18 / 38
Models for Concurrent Processes
Two main mathematical models (or variants thereof) are used:

Kripke Structures
State Labelled Automata: States are labelled with the properties that are
considered relevant (e.g. the value of - the relation between - some
variables)

Labelled Transition Systems (LTS)

Transition Labelled Automata: Transition between states are labelled with
the action that induces the transition from one state to another.

We shall rely on LTS and actions will play an important role.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 18 / 38
Labelled Transition System (LTS)

A 4-tuple S = (Proc , Act , −→, q0 ) where:

Proc is a set of states (or processes).
Act is a set of labels (or actions).
−→ ⊆ Proc × Act × Proc is a ternary relation on states called the
transition relation.
q0 ∈ Q is a special state called initial state (may be missing).

a
We will use the infix notation s −→ s 0 meaning that (s , a , s 0 ) ∈−→.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 19 / 38
Labelled Transition System (LTS)

A 4-tuple S = (Proc , Act , −→, q0 ) where:

Proc is a set of states (or processes).
Act is a set of labels (or actions).
−→ ⊆ Proc × Act × Proc is a ternary relation on states called the
transition relation.
q0 ∈ Q is a special state called initial state (may be missing).

a
We will use the infix notation s −→ s 0 meaning that (s , a , s 0 ) ∈−→.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 19 / 38
Graphical representation of LTSs
Example (A Simple Example: S = (Proc , Act , −→) where:)
Proc = { q0 , q1 , q2 , q3 , q4 }
Act = { play , work , τ }
−→=
{(q0 , play , q1 ), (q0 , work , q2 ), (q1 , work , q3 ), (q2 , play , q3 ), (q3 , τ, q4 )}

An LTS is usually represented by a transition graph, whose nodes are the

states and whose arcs are the transitions.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 20 / 38
Graphical representation of LTSs
Example (A Simple Example: S = (Proc , Act , −→) where:)
Proc = { q0 , q1 , q2 , q3 , q4 }
Act = { play , work , τ }
−→=
{(q0 , play , q1 ), (q0 , work , q2 ), (q1 , work , q3 ), (q2 , play , q3 ), (q3 , τ, q4 )}

An LTS is usually represented by a transition graph, whose nodes are the

states and whose arcs are the transitions.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 20 / 38
Graphical representation of LTSs
Example (A Simple Example: S = (Proc , Act , −→) where:)
Proc = { q0 , q1 , q2 , q3 , q4 }
Act = { play , work , τ }
−→=
{(q0 , play , q1 ), (q0 , work , q2 ), (q1 , work , q3 ), (q2 , play , q3 ), (q3 , τ, q4 )}

An LTS is usually represented by a transition graph, whose nodes are the

states and whose arcs are the transitions.

q2

q0 q3 q4

q1

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 21 / 38
Internal and External Actions
An elementary action of an LTS represents the atomic (non-interruptible)
abstract step of a computation that is performed by a process to move
from one state to the other.
Actions represent various activities of concurrent systems.
Visible (or observable) actions
1 Sending a message, channel output
2 Receiving a message, channel input

Internal (or unobservable) actions

1 Updating values
2 Synchronization between subprocesses
3 ...

Handshake communication: two concurrent processes interact by

synchronizing their transitions involving “complementary” actions

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 22 / 38
Internal and External Actions
An elementary action of an LTS represents the atomic (non-interruptible)
abstract step of a computation that is performed by a process to move
from one state to the other.
Actions represent various activities of concurrent systems.
Visible (or observable) actions
1 Sending a message, channel output
2 Receiving a message, channel input

Internal (or unobservable) actions

1 Updating values
2 Synchronization between subprocesses
3 ...

Handshake communication: two concurrent processes interact by

synchronizing their transitions involving “complementary” actions

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 22 / 38
Internal and External Actions
An elementary action of an LTS represents the atomic (non-interruptible)
abstract step of a computation that is performed by a process to move
from one state to the other.
Actions represent various activities of concurrent systems.
Visible (or observable) actions
1 Sending a message, channel output
2 Receiving a message, channel input

Internal (or unobservable) actions

1 Updating values
2 Synchronization between subprocesses
3 ...

Handshake communication: two concurrent processes interact by

synchronizing their transitions involving “complementary” actions

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 22 / 38
Internal and External Actions
An elementary action of an LTS represents the atomic (non-interruptible)
abstract step of a computation that is performed by a process to move
from one state to the other.
Actions represent various activities of concurrent systems.
Visible (or observable) actions
1 Sending a message, channel output
2 Receiving a message, channel input

Internal (or unobservable) actions

1 Updating values
2 Synchronization between subprocesses
3 ...

Handshake communication: two concurrent processes interact by

synchronizing their transitions involving “complementary” actions

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 22 / 38
How can we describe very large LTSs?

As a table?
Rows and columns are labelled by states, entries are either empty or
marked with a set of actions.

As a listing of triples?
→= {(q0 , a , q1 ), (q0 , a , q2 ), (q1 , b , q3 ), (q1 , c , q4 ), (q2 , τ, q3 ), (q2 , τ, q4 )}.

As XML?
<lts><ar><st>q0</st><lab>a</lab><st>q1</st></ar>...</lts>.

Linguistic aspects are important!

The previous solutions are ok for machines . . . not for humans.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 23 / 38
How can we describe very large LTSs?

As a table?
Rows and columns are labelled by states, entries are either empty or
marked with a set of actions.

As a listing of triples?
→= {(q0 , a , q1 ), (q0 , a , q2 ), (q1 , b , q3 ), (q1 , c , q4 ), (q2 , τ, q3 ), (q2 , τ, q4 )}.

As XML?
<lts><ar><st>q0</st><lab>a</lab><st>q1</st></ar>...</lts>.

Linguistic aspects are important!

The previous solutions are ok for machines . . . not for humans.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 23 / 38
How can we describe very large LTSs?

As a table?
Rows and columns are labelled by states, entries are either empty or
marked with a set of actions.

As a listing of triples?
→= {(q0 , a , q1 ), (q0 , a , q2 ), (q1 , b , q3 ), (q1 , c , q4 ), (q2 , τ, q3 ), (q2 , τ, q4 )}.

As XML?
<lts><ar><st>q0</st><lab>a</lab><st>q1</st></ar>...</lts>.

Linguistic aspects are important!

The previous solutions are ok for machines . . . not for humans.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 23 / 38
How can we describe very large LTSs?

As a table?
Rows and columns are labelled by states, entries are either empty or
marked with a set of actions.

As a listing of triples?
→= {(q0 , a , q1 ), (q0 , a , q2 ), (q1 , b , q3 ), (q1 , c , q4 ), (q2 , τ, q3 ), (q2 , τ, q4 )}.

As XML?
<lts><ar><st>q0</st><lab>a</lab><st>q1</st></ar>...</lts>.

Linguistic aspects are important!

The previous solutions are ok for machines . . . not for humans.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 23 / 38
How can we describe very large LTSs?

As a table?
Rows and columns are labelled by states, entries are either empty or
marked with a set of actions.

As a listing of triples?
→= {(q0 , a , q1 ), (q0 , a , q2 ), (q1 , b , q3 ), (q1 , c , q4 ), (q2 , τ, q3 ), (q2 , τ, q4 )}.

As XML?
<lts><ar><st>q0</st><lab>a</lab><st>q1</st></ar>...</lts>.

Linguistic aspects are important!

The previous solutions are ok for machines . . . not for humans.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 23 / 38
Why operators for describing systems

LTSs describe process behaviour and explicitly focus on interaction.

They can also describe:
sequencing (a ; b)
choice (nondeterminism) (a + b)
interleaving (limited notion of parallelism) (a | b)

But additional operators are needed

to design systems in a structured way (many forms of parallel
composition)
to model systems interaction
to abstract from details
to represent systems with infinite behaviour

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 24 / 38
Why operators for describing systems

LTSs describe process behaviour and explicitly focus on interaction.

They can also describe:
sequencing (a ; b)
choice (nondeterminism) (a + b)
interleaving (limited notion of parallelism) (a | b)

But additional operators are needed

to design systems in a structured way (many forms of parallel
composition)
to model systems interaction
to abstract from details
to represent systems with infinite behaviour

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 24 / 38
How to Describe LTSs?

Syntax Semantics
−→
unknown entity known entity

Programming Language What (denotational) or

−→
how (operational) it computes

−→ Labelled Transition Systems

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 25 / 38
How to Describe LTSs?

Syntax Semantics
−→
unknown entity known entity

Programming Language What (denotational) or

−→
how (operational) it computes

−→ Labelled Transition Systems

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 25 / 38
How to Describe LTSs?

Syntax Semantics
−→
unknown entity known entity

Programming Language What (denotational) or

−→
how (operational) it computes

??? −→ Labelled Transition Systems

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 25 / 38
How to Describe LTSs?

Syntax Semantics
−→
unknown entity known entity

Programming Language What (denotational) or

−→
how (operational) it computes

Process Description Language −→ Labelled Transition Systems

or Process Algebra:
CCS, ACP, CSP, LOTOS, . . .

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 25 / 38
Description of LTSs
Process Algebras as formalisms for expressing LTSs
LTSs are represented by terms of process algebras.
Terms are interpreted via operational semantics as LTSs.

Insight of Robin Milner (1980)

Concurrent (parallel) processes have an algebraic structure.

P1 op P2 ⇒ P1 op P2

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 26 / 38
Process Algebra
Basic Principle
1 Define a few elementary (atomic) processes modelling the simplest
process behaviour.
2 Define appropriate composition operations to build more complex
process behaviour from simpler ones.

Example
1 atomic instruction: input, output, . . .
2 new operators:
I sequential composition (P1 ; P2 )
I parallel composition (P1 | P2 )

Usually given by abstract syntax:

P , P1 , P2 ::= a | P1 ; P2 | P1 | P2

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 27 / 38
Process Algebra
Basic Principle
1 Define a few elementary (atomic) processes modelling the simplest
process behaviour.
2 Define appropriate composition operations to build more complex
process behaviour from simpler ones.

Example
1 atomic instruction: input, output, . . .
2 new operators:
I sequential composition (P1 ; P2 )
I parallel composition (P1 | P2 )

Usually given by abstract syntax:

P , P1 , P2 ::= a | P1 ; P2 | P1 | P2

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 27 / 38
What is a Process Algebra
A set of Terms (processes)
An Operational Semantics associating LTSs to terms
Equivalence Relations equating terms exhibiting “similar” behavior

Set of Operators
Basic Processes
Sequentialization, Choice
Parallel Composition, Abstraction
Recursion

Equivalences
Trace, Testing, Bisimulation Equivalences
. . . many others . . .
Variants taking into account that some actions are unobservable

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 28 / 38
LTS of the process a .nil | a .nil
The LTS of a (concurrent) process has the process expressions as its
states, and its transitions are exactly those which can be inferred from the
inference rules of the semantics of CCS

a .nil | a .Gnil
ww GG
www GG
GG a
a ww GG
ww GG
ww GG
www GG
{w #
nil | a .nil τ a .nil | nil
GG
GG ww
GG www
GGa a ww
GG w
GG www
GG w
G#  {www
nil | nil

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 29 / 38
A CCS process: black-box view
What is a CCS to its environment?
A CCS process is a computing agents that may communicate with its
environment via its interface.
Interface = collection of communication ports/channels, together with an
indication of whether they are used for input or output.

The black-box can be graphically depicted as a flowgraph.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 30 / 38
Flowgraph of a simple communication protocol

A flowgraph depicts the structure of a system, i.e. the linkage among its
components, while its behaviour is described by a transition graph.

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 31 / 38
A simple communication protocol

def
M = put .get .M + put_ack .get_ack .M

def
S = send .msg .ack .S

def
R = msg .recv .ack .R

def
Prot = (S [put /msg , get_ack /ack ]|M |R [get /msg , put_ack /ack ])
\{get , put , get_ack , put_ack }

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 32 / 38
Transition graph of a simple communication protocol

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 33 / 38
Verifying Correctness of Reactive Systems
Let Impl be an implementation of a system (e.g. in CCS syntax).

Equivalence Checking Approach (es. bisimulation, Milner, Park, ’81)

Impl ≡ Spec
≡ is an abstract equivalence, e.g. ∼ or ≈
Spec is often expressed in the same language as Impl
Spec provides the full specification of the intended behaviour

Model Checking Approach (Clarke, Emerson & Quielle, Sifakis, ’81)

Impl |= Property
|= is the satisfaction relation
Property is a particular feature, often expressed via a logic
Property is a partial specification of the intended behaviour

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 34 / 38
Verifying Correctness of Reactive Systems
Let Impl be an implementation of a system (e.g. in CCS syntax).

Equivalence Checking Approach (es. bisimulation, Milner, Park, ’81)

Impl ≡ Spec
≡ is an abstract equivalence, e.g. ∼ or ≈
Spec is often expressed in the same language as Impl
Spec provides the full specification of the intended behaviour

Model Checking Approach (Clarke, Emerson & Quielle, Sifakis, ’81)

Impl |= Property
|= is the satisfaction relation
Property is a particular feature, often expressed via a logic
Property is a partial specification of the intended behaviour

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 34 / 38
Verifying Correctness of Reactive Systems
Let Impl be an implementation of a system (e.g. in CCS syntax).

Equivalence Checking Approach (es. bisimulation, Milner, Park, ’81)

Impl ≡ Spec
≡ is an abstract equivalence, e.g. ∼ or ≈
Spec is often expressed in the same language as Impl
Spec provides the full specification of the intended behaviour

Model Checking Approach (Clarke, Emerson & Quielle, Sifakis, ’81)

Impl |= Property
|= is the satisfaction relation
Property is a particular feature, often expressed via a logic
Property is a partial specification of the intended behaviour

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 34 / 38
Formal Methods . . .
are more and more used in practice
can shorten development time
can push the limits of feasible complexity
can increase quality/reliability of systems dramatically

Strongly recommended especially within the realm of

safety-critical, security-critical, and cost-intensive software

Tool Support is Essential

Automate repetitive tasks
Avoid mistakes, trivial errors, etc.
Cope with large/complex programs
Make verification certifiable

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 35 / 38
Formal Methods . . .
are more and more used in practice
can shorten development time
can push the limits of feasible complexity
can increase quality/reliability of systems dramatically

Strongly recommended especially within the realm of

safety-critical, security-critical, and cost-intensive software

Tool Support is Essential

Automate repetitive tasks
Avoid mistakes, trivial errors, etc.
Cope with large/complex programs
Make verification certifiable

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 35 / 38
Network-Aware Programming
Network-aware systems/applications
I composed of a large number of heterogeneous and autonomous
components
I managed by different authorities
I structure/components can change dynamically in unpredictable ways

Applications/systems are exposed to malicious accesses to their data

and resources
I even worst when process/agent mobility is permitted

Coordination languages allow components of an application to

communicate/collaborate for accomplishing shared goals

To develop tools for controlling execution of coordinated components and

guaranteeing correctness of their interaction

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 36 / 38
Network-Aware Programming
Network-aware systems/applications
I composed of a large number of heterogeneous and autonomous
components
I managed by different authorities
I structure/components can change dynamically in unpredictable ways

Applications/systems are exposed to malicious accesses to their data

and resources
I even worst when process/agent mobility is permitted

Coordination languages allow components of an application to

communicate/collaborate for accomplishing shared goals

To develop tools for controlling execution of coordinated components and

guaranteeing correctness of their interaction

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 36 / 38
Service-Oriented Computing
An emerging paradigm for distributed and e-business computing
Finds its origin in object-oriented and component-based software
development
Aims at enabling developers to build networks of integrated and
collaborative applications, regardless of
I the platform where the applications run (e.g., the operating system)
I the programming language used to develop them
through the use of loosely coupled, reusable software components
A modern attempt to cope with old problems related to
information interchange, software integration, and B2B
Many instantiations: e.g. Web Services and grid computing

To develop formal reasoning mechanisms and verification tools for

checking that the services resulting from a composition meet desirable
correctness properties and do not manifest unexpected behaviors

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 37 / 38
Service-Oriented Computing
An emerging paradigm for distributed and e-business computing
Finds its origin in object-oriented and component-based software
development
Aims at enabling developers to build networks of integrated and
collaborative applications, regardless of
I the platform where the applications run (e.g., the operating system)
I the programming language used to develop them
through the use of loosely coupled, reusable software components
A modern attempt to cope with old problems related to
information interchange, software integration, and B2B
Many instantiations: e.g. Web Services and grid computing

To develop formal reasoning mechanisms and verification tools for

checking that the services resulting from a composition meet desirable
correctness properties and do not manifest unexpected behaviors

D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 37 / 38
Autonomic Computing
Ensembles: Future generation of software-intensive systems featuring
massive numbers of components
complex interactions among components, and with humans and other
systems
operating in open and non-deterministic environments
dynamically adapting to new requirements, technologies and
environmental conditions
Developing software for ensembles creates new difficulties related to e.g.
the large dimension of the systems
the need to adapt to changing environments and requirements
the emergent behaviours resulting from complex interactions
the uncertainty during design-time and run-time

To exploit Adaptation as a powerful means for taming the ever-increasing

complexity of today’s computer systems, networks and applications
D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 38 / 38
Autonomic Computing
Ensembles: Future generation of software-intensive systems featuring
massive numbers of components
complex interactions among components, and with humans and other
systems
operating in open and non-deterministic environments
dynamically adapting to new requirements, technologies and
environmental conditions
Developing software for ensembles creates new difficulties related to e.g.
the large dimension of the systems
the need to adapt to changing environments and requirements
the emergent behaviours resulting from complex interactions
the uncertainty during design-time and run-time

To exploit Adaptation as a powerful means for taming the ever-increasing

complexity of today’s computer systems, networks and applications
D. Gorla Formal Methods for the Specification and the Verification of Concurrent and Distributed Systems
April 1st, 2013 38 / 38