Transcript Formal Methods for Software Engineering Part III

Formal Methods for
Software Engineering
Part III:
Applications of Formal Methods
Lecture 9:
MSC & the Tau SDL tool
Holger Hermanns
Contents of this lecture
The state of affairs.
Data in SDL.
Time in SDL.
Sequences of messages: MSC.
Validation of SDL specs.
‘Simulation’ and ‘Coverage’
‘Random walk’
State space exploration
What to do with a validated spec.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
2
The state of affairs
In Part I we used Z as a formalism to model the static aspects of
software systems, i.e.
definition of system states & data structures
definition of operations & preconditions
The tool Z-Eves was used for specification support and analysis.
In Part II we used LTS as a model and FSP as a formalism to
model the dynamic aspects of software systems, i.e.
definition of system behaviour (control flow)
definition of control distribution (concurrency)
We used the tool LTSA for modelling support and analysis.
In Part III we are supposed to apply these methods and concepts.
We will be using the Telelogic Tay tool-suite.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
3
This Part
We apply the concepts, methods and tools you learnt to love in
contexts that are relatively close to what the people out there
are facing.
Last week we got hands on an 'industrial' FSP variant: SDL.
This week seems I must guide you deeper into the
jungle of ‘handy’ languages.
I shall
round off the SDL introduction,
introduce MSCs,
tell you that some people believe that MSCs and
SDL are a perfect couple, and
Tell about the modelling and analysis capabilities of the
Telelogic Tau Tool Suite.
Assumptions for today:
You still remember these ideas around FSP, and in particular the notions of trace and bisimulation.
You have a feeling about the SDL constructs and how they are used to specify distributed concurrent systems in SDL.
You are starting to worry about the upcoming exam.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
4
Contents of this lecture
The state of affairs.
Data in SDL.
Time in SDL.
Sequences of messages: MSC.
Validation of SDL specs.
‘Simulation’ and ‘Coverage’
‘Random walk’
State space exploration
What to do with a validated spec.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
5
Data in SDL
not much more to say about (for our purposes)...
Data is owned by individual processes. No global variables.
Sharing of variables is achieved through message passing
via signals - or a mechanism called import/export.
Basic data types are predefined.
More complex data types need to be defined through ASN.1
(abstact syntax notation), at least according to the standard.
Tools take this more easy, ‘C’-like data structures are ususally
supported.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
6
process F
Data in SDL
S
DCL
x Integer;
x>5
x:=1
The ordinary thing:
x:=x+1
S
The not so ordinary thing: export/import
process A
block K
EXPORT(x)
DCL EXPORTED
x Integer:=1;
writes out a value
process B
REMOTE
X;
S
y:=IMPORT(x)
A
DCL
y Integer;
B
IMPORTED
x Integer;
y>5
y:=y+1
S
reads the value written out last
allows to implement non-buffered synchronisation (under the hood)!
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
7
Contents of this lecture
The state of affairs.
Data in SDL.
Time in SDL.
Sequences of messages: MSC.
Validation of SDL specs.
‘Simulation’ and ‘Coverage’
‘Random walk’
State space exploration
What to do with a validated spec.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
8
Time in SDL
much more to say about...
a matter of (scientific/philosophical) debate.
Some snippers from the standard:
" Time only progresses if all input buffers are empty. "
" Taking a transition takes a positive, but negligible amount of time. "
Why is time interesting to discuss?
because SDL allows one to set timers and to react on timeouts,
and allows to refer to the current time (NOW).
this construct appears handy, and is often used.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
9
Timers
process Q
TIMER
Wait;
*
SET(NOW+5,Wait)
W
F
Wait
Z
G
-
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
10
What happens when a timer expires
Recall the input queue
under the hood of each
process?
Well, an expiring timer
just appends a signal to
the local queue.
This implies that reaction
to timeouts may not be
immediate.
process Q
Q
*
SET(NOW+5,Wait)
W
F
Wait
Z
G
-
FFFFFFFFFFFFF
Wait
[F]
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
11
Contents of this lecture
The state of affairs.
Data in SDL.
Time in SDL.
Sequences of messages: MSC.
Validation of SDL specs.
‘Simulation’ and ‘Coverage’
‘Random walk’
State space exploration
What to do with a validated spec.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
12
The remainder of this lecture
Puts SDL in the context of the Tau SDL tool, and
emphasises some generally valid/useful …
observations,
techniques,
obstacles …
in the context of the tool, and relative to the LTSA tool.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
13
MSC: Message Sequence Charts
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
14
MSC: Message Sequence Charts
coin/ @Environment
/coin @Paybox
entryfee/ @Paybox
/entryfee @Controller
unlock/ @Controller
/unlock @Barrier
visitor:= @Controller
push/ @Environment
/push @Environment
rotated/ @Environment
/rotated @Barrier
locked/ @Barrier
/locked @Controller
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
15
MSC: Message Sequence Charts
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
16
MSC - How simple!
Traces?
Traces?
Traces?
Traces?
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
17
Definition: Basic MSC
A (basic) MSC M is a tuple (P,E,L,c, )
a set P of process labels (labelling the instance axis),
a finite set E events E = S  R  A, consisting of
send events S (buh/)
receive events R (/buh)
action events A (task executions etc)
a labeling function L: EP (putting events on the instance axis),
a bijection c:S  R (for send-receive edges)
precedence relation   E  E
Send of a message occurs before its receipt
Events on the same instance are totally ordered
Must be well-formed: no cycles in precedence graph
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
18
MSC - How simple!
Traces?


Traces?
Holger Hermanns
Traces?
Formal Methods for Software Engineeiring - Lecture 9
19
Semantics of Basic MSC
 *, the transitive closure of , defines a partial order on
E
A trace of MSC M is a linearization of the partial order
*.
every trace is a finite sequence of events that “obeys” the
precedence.
each event occurs exactly once in a trace and only after all its
preceding events have already occurred in the trace so far.
always finite.
Semantics of MSC M
is the set of all possible traces.
can be represented as a finite LTS (and hence in FSP, if you like).
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
20
Need to introduce partial orders?
A relation is a set of pairs drawn from some set, say E.
A reflexive relation is a relation that contains the pair
(e,e) for each element e of E.
A transitive relation is a relation which contains the pair
(e,g) whenever it contains both (e,f) and (f,g).
A partial order is a reflexive and transitive relation.
The werkcolleges of FMSE are partially ordered (in time).
A total order is a partial order which for each pair (e,f)
of E (with ef) does either contain (e,f) or (f,e) - but not
both.
Holger Hermanns
The hoorcolleges of FMSE are totally ordered (in time).
Formal Methods for Software Engineeiring - Lecture 9
21
MSC: Timers
process Q
*
F
SET(NOW+5,Wait)
W
Wait
Z
G
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
22
MSC: Timers
process Q
*
F
SET(NOW+5,Wait)
W
Wait
Z
G
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
23
MSC and SDL
SDL has from the very beginning been devised
in combination with MSC (ITU standard Z.100/Z.120)
Within SDL, MSC are used
for requirements engineering
for test case engineering
as example scenarios which the SDL system is supposed to comply to
as a logging means for traces generated from an SDL system
MSC has spinned off as a requirements engineering formalism.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
24
The Case for MSCs
Most high level modelling formalisms
are state-based, and
correspond to executable specifications
(not only the ones you have seen)
Difficult to capture “informal” initial sketches.
Scenario-based requirements modelling is
useful in the early design stages.
That’s the main strength of MSCs.
 MSCs are one of the heavier used UML mosaic pieces.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
25
Contents of this lecture
The state of affairs.
Data in SDL.
Time in SDL.
Sequences of messages: MSC.
Validation of SDL specs.
‘Simulation’ and ‘Coverage’
‘Random walk’
State space exploration
What to do with a validated spec.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
26
The Tau SDL Tool
Is waiting for you in
the PC area.
You are expected to
self-study the tool,
following a tutorial.
Times and clusters have
been reserved this week.
See the FMSE webpage
for details.
To compensate, there is
NO werkcollege this week.
http://fmt.cs.utwente.nl/courses/fmse/
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
27
Validation of (SDL) specifications
What for?
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
28
Validation of specifications
What’s the general strategy?
1. Take a design of the system behaviour
(such as an SDL or FSP specification).
2. Take (a set of) system requirements
(given in terms of a set of MSCs,
or as safety or progress properties, or …)
1. Validate that each requirement
is indeed satisfied by the system design.
Sounds simple? Hasn’t been particularly simple in the FSP context?
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
29
Computer-assisted validation
Does a design D satisfy a requirement ?
Theorem proving
Strategy: generate a formal proof that D satisfies .
Applicable if design D can be represented in some adequate
mathematical theory.
State space exploration
Strategy: check systematically and exhaustively
whether each reachable state in D satisfies .
Applicable if the behaviour of D can be finitely represented.
Simulation or Testing
Strategy: Check whether  holds on some executions of D.
Applicable if D is in some sense executable.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
30
Computer-assisted validation
requirement
real system
specification
formalisation
(SDL) system
(MSC) requirement
posssible behaviour
desired behaviour
‘Magic Engine’
modification
NO
next
requirement
YES
ready
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
31
Computer-assisted validation
What’s the obstacle?
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
32
Computer-assisted validation
Does a design D satisfy a requirement ?
What’s the practical obstacle?
State Space Explosion:
The number of possible state combinations
grows exponentially in the number of concurrent processes.
What’s the principal obstacle?
Decidability:
In full generality it is undecidable whether D satisfies .
This depends on the specification, and the requirement.
There is more to say in this respect.
And there is a neat course devoted to this issue:
System Validation
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
33
Tau-assisted validation
Does a design D satisfy a requirement ?
The Tau tool supports simulation,
and some rudimentary form of state space exploration
(a bit like LTSA does, but the flavour is different).
Simulation: generates traces through the state space
user-driven (that’s not really validation, but useful)
State Space Exploration:
explores
randomly (driven by a pseudo random number generator), or
exhaustively up to a given depth.
checks
whether the encountered states satisfy some (built in) sanity requirements.
whether a given MSC (requirement) can be generated.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
34
Simulation within the Tau tool.
The simulator explores a trace through the state space.
It allows you to interactively step through the behaviour,
in various degrees of detail, and
to steer the simulation through various parameters.
Relative to LTSA, the simulation engine of Tau
appears difficult to oversee and use.
Reasons are
language particularities
(many things may happen in a transition body)
difference in language scope and expressiveness
(industrial language vs. toy language)
commercial vs. industrial product.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
35
Validation within the Tau tool
The validator provides automatic state space exploration means.
It allows exploration
randomly (driven by a pseudo random number generator), or
exhaustively up to a given depth.
For the latter, it has some smart techniques built-in
(in particular ‘Bitstate-Hashing’, same as ‘supertrace’ in LTSA)
that allow one to do this rather efficiently (but approximately).
It can check
whether all encountered states satisfy some (built-in)
sanity requirements.
whether a given MSC (requirement) can be generated.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
36
MSC vs. safety and progress.
In LTSA, safety and progress properties are supported.
Tau’s built-in sanity checks
correspond to simple safety
properties.
Since an MSC can (in principle)
be translated into FSP, also the
MSC validation has an equivalent
in the FSP/LTSA context, it
corrsponds to checking a certain
‘deformed’ safety property.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
37
So, LTSA is more powerful than Tau?
Well, if it comes to validation, then yes, indeed. Tau gives
no guarantee that the entire state space is explored.
But recall that
FSP is a toy language relative to SDL;
LTSA is tailored to Finite State Processes, while
SDL is (conceptually) infinite state.
(do you remember why?)
(On general infinite state systems, there is little hope for automatic
exhaustive verification. Nevertheless academia is very active in
interesting fragments of this problem area.)
Tau supports another useful method to combat the problem:
variable abstraction.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
38
Variable abstraction in Tau
Assume that you are validating a property concerning the
locking mechanism of your turnstile barrier.
(“The turnstile can eventually be unlocked”).
Further assume that your SDL specification contains masses of
variables used for purposes like
counting of visitors,
billing,
logging information for the Belastingsverklaring,
etc etc.
Seems a good idea then to not care about these variables in the
property specific validation.
This is the essence of variable abstraction, and it is supported
manually in Tau. The user has the opportunity to mask variables he
guesses to be irrelevant for the validation.
(Semi-)Automatic abstraction is nicer, of course,
and there are tools supporting this around.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
39
Simulation and Validation within Tau.
The simulator and validator explore the state space.
It allows you to
view how much of a
system specification
you have visited
already in a
simulation run.
Is this handy?
Yes, for
debugging
purposes.
But not for
correctness.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
40
State coverage vs. transition coverage
vs. State space coverage.
Simulator and Validator explore the state space.
State coverage and transition coverage refer to the specification
level.
From the tool docu:
This is misleading!
Due to concurrency, it is very well possible
to have a specification that is wrong (e.g. deadlocks), but a fragment of
the state space with 100% of the transitions/states covered does not
show this deadlock.
to have a specification that works 100% correct,
but where less that 100% of the specification are covered.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
41
State/transition coverage viewed in FSP.
Let’s get 100% state and transition
coverage for this process:
COIN =(toss->heads->COIN
(COIN || COIN)
|toss->tails->COIN).
toss
Here is a trace that covers 100% of
the states and transitions:
toss
0


1
2

heads
tails
And still the system is alive and
kicking (it is even back in the initial
state).
toss
toss
0

So, can the system deadlock?
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
1

2

heads
tails
42
Contents of this lecture
The state of affairs.
Data in SDL.
Time in SDL.
Sequences of messages: MSC.
Validation of SDL specs.
‘Simulation’ and ‘Coverage’
‘Random walk’
State space exploration
What to do with a validated spec.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
43
What to do with a validated SDL spec?
Implement the system in software
(and/or hardware, sometimes).
Do this
automatically (code generation)
is supported by the Tau tool;
is often considered inefficient;
One reason: Buffer-based communication disturbing in nondistributed implementations of SDL blocks;
or
manually
specification is reference for the implementers,
specification can provide test-suites for the running code
(more on this next week).
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
44
What you should have learnt today
A bit on data and time in SDL.
Some basics on Basic MSCs.
Background on computer assisted validation.
Tau-assisted validation specifics.
High time to get your hands on this tool.
Holger Hermanns
Formal Methods for Software Engineeiring - Lecture 9
45