Formal Methods
D. Lucanu
Formal methods
Is the mathematics of software engineering
The Free On-line Dictionary of Computing (2003-OCT-10) Mathematically based techniques for the
specification, development and verification of software and hardware systems.
main issues
modeling,
calculation
Formal Methods
Research in Formal Methods is a systematic and
scientific study of issues in computer science, based on solid mathematical principles
Formal Methods apply to systems and constructions used in computer science.
These constructions are described exactly in a formal syntax and are supplied with a formal semantics
whenever appropriate.
Why Formal Methods?
increase understanding of systems
increase clarity of description and help solve problems and remove error
their use increases dependability and usability of
constructions and systems in computer science.
Why Formal Methods?
Software (+ hardware) Engineering is craft, not science.
- Complex
- No margin of error
- Local action has global consequences
- Discrete
- (no intra-, extrapolation, some statistics possible)
Formal Methods
Specification - descriptive
uses languages with a
well-defined syntax and
well-defined semantics
Verification - analysis
model-checking
proof systems
rewrite engines
Specification
Communication between designers.
Control and data.
“What” over “how”.
Reactive, parallel, distributed systems.
Verification
Discrete math calculation
Logic and deduction
All behaviours
Parameters
Hierarchy of abstraction
Model needs to be validated against reality
Issues and choices
Selection:
- Level of formality:
1. Mathematical argument
2. Formal specification
3. Verification system
- Part of system, selected components
- Selected properties
- Part of lifecycle
- Level of abstraction
Specification: varieties
• Model-oriented: operational. Z, B, AsmL, Spec#, ...
• Property-oriented: logical. CTL/LTL, ...
• Concurrency. Process algebra.
Verification: varieties.
• Consistency analysis and type checking
• Validation: animation, challenges.
• Predicting behaviour and verifying refinement
State space exploration, model checking, language inclusion
Theorem proving, proof checking
Certification of critical systems
Can never achieve failure rate of 10-9.
Advantages of FM
Precision engineering
Complexity engineering
Correctness engineering
Automation engineering
History (incomplete)
1956 Noam Chomsky models language
1957 John Backus defines Fortran syntax
1958 Haskel Curry and Robert Feys describe propositions-as-types analogy
1960 Peter Naur applies BNF to ALGOL60
1968 Adriaan van Wijngaarden defines ALGOL68, experiments with , 2 l. grammar
1968 Donald Knuth invents attribute grammars
History
1968 Dana Scott denotational sem. for
1969 Tony Hoare axiomatic semantics
1970 N.G. de Bruijn Automath
1972 IBM Vienna: FM for PL/I design
1974 Goguen Thatcher init. alg. sem. data types
1977 Joseph Stoy book denotational sem.
1978 Dines Bjørner, Cliff Jones VDM
1979 Philips Brussels CHILL design
History
1980 Robin Milner CCS
1980 Jean-Raymond Abrial Z
1980-1990 Gerard Holzmann SPIN
1983 Jan Bergstra ACP
1985 Ed Brinksma LOTOS
1985-1995 ESPRIT: CIP, OBJ, PLUSS, ASL, Larch, SDL, ExSpect, ADJ, ASF, SDF, PSF, PVS, COLD, SPRINT, ERAE, CLEAR, Maude, …
History
1993 VDM Europe becomes FME
1997 Intel establishes FM group after Pentium
1999 FM World
Commercial firms offering FM (Verum, FDR)
FMICS, IFM
2000 –
AsmL
Spec#
Ingredients (incomplete)
Syntax States
Logic Transitions
Proof Execution
Data types Communication
Modularisation Abstraction
Type system Timing
Object orientation Hybrid systems
Semantics
Denotational
Operational
Axiomatic - assertional
Varieties
Logic:
thm proving PVS, COQ, Isabele
Temporal logic: CTL, LTL
Game theory
Categories, co-algebras
Multi-agent systems
Varieties
Equational:
-calculus
term rewriting
type theory
Program derivation
Process algebra
Varieties
Operational:
sequential: Z, VDM, Larch
SOS
I/O automata
Petri nets
Model checking
Graphs
Varieties
Visual: MSC, Petri nets
Applications
Software Engineering,
in particular components, coordination
Embedded Systems (hybrid systems)
Business Processes
Biological Processes
Security
Web services & grid computing
Agents, games, quantum & relativistic comput.
Ten Commandments of Formal Methods [Bowen, Hinchey](revisited)
1. Thou shalt choose an appropriate notation.
2. Thou shalt formalize but not overformalize.
3. Thou shalt estimate costs. (Initialy “Thou shalt guestimate costs”)
4. Thou shalt have a formal methods guru on call.
5. Thou shalt not abandon thy traditional development methods.
6. Thou shalt document sufficiently.
7. Thou shalt not compromise thy quality standards.
8. Thou shalt not be dogmatic.
9. Thou shalt test, test, and test again.
10. Thou shalt reuse.
Guidelines to Formal System Studies [Abrial’s approach]
Mathematical model
refinement
golbal model
The State
constants, variables
invariant properties
The events
observable
mathematical simulation
guard, action
asynchronous
Guidelines to Formal System Studies [Abrial’s approach]
Practically Form af an Event xxx =
any x, y, … where P(x, y,…, v;,w;,…) then
S(x, y;,…,v, w,…) end
an example
any x, where P(x, v)
then
v := E(x, v) end
Guidelines to Formal System Studies (Abrial’s approach)
Consistency: Preservation of the Invariant I(v) P(x, v) I(E(x, v))
Model Refinement
state, events
Proofs of Correct Refinement
any x where P(x, v) then
v := E(x, v) end
any y where Q(y, w) then
w := F(y, w) end
abstract concret
J(v,w)= gluing invariant
I(v) J(v, w) Q(y, w) x.(P(x,v) J((E(x, v), F(y,w)))
Guidelines to Formal System Studies [Abrial’s approach]
Proofs of the Impossibility of Monopoly of New Events
any y where Q(y, w) then
w := F(y, w) end
new event
I(v) J(v, w) Q(y, w) V(F(y,w)) < V(w)
where V(w) is a (natural number) variant expression
Guidelines to Formal System Studies [Abrial’s approach]
Proofs of the Limitations of Deadlocks
abstract event
I(v) J(v, w) P(x, v) disjunction of the concrete guards any x where
P(x, v) then
v := E(x, v) end
Guidelines to Formal System Studies *Abrial’s approach]
deadlock event deadlock b
select
disjunction of guards then
ddlck := true end
disjunction of guards G1 … Gn
Guidelines to Formal System Studies *Abrial’s approach]
AGi = abstract guard CGi = concrete guard
refinement of the deadlock event
I(v) J(v, w) (CG1 … CGn) (AG1 … AGn)
by contraposition
I(v) J(v, w) (AG1 … AGn) (CG1 … CGn)
P(x, v) is just an abstract guard, hence
I(v) J(v, w) P(x, v) (CG1 … CGn)
Stopwatch Specification
start/stop reset/lap
mode
Stopwatch Specification
A stopwatch consists of a display and 3 buttons labeled mode, start/stop and reset/lap. The stopwatch has three major
display modes: time, date and stopper. Users may select a display mode by repeatedly pushing the mode button which switches between the time, date and stopper modes cyclically in this order.
The start/stop and reset/lap buttons are only active when the stopper is displayed. The start/stop button is used to stop the stopper in case it is running, or to resume it if it is not running.
The reset/lap button is used to reset the stopper counter in case it is stopped (not running) or to "freeze" the current stopper display in order to view the current result of the stopper without stopping it.
Stopwatch Specification
Pressing the reset/lap button when the display is "frozen"
simply causes the watch to "unfreeze" and re-sync with the stopper. Pressing the start/stop button when the stopper is
"frozen" will have the usual effect on the stopper except for the fact that the changes will not be visible to the user until the stopper display is "unfreezed" as described above.
Pressing the mode button when the stopper is running
(whether "freezed" or not) will cause the stopwatch to switch modes. The stopper will continue to run (in the background) and may be redisplayed by selecting the stopper display mode.
Stopwatch Specification (AsmL)
Constants
The enumeration DisplayMode represents the three display modes of the stopwatch
namespace Stopwatch enum DisplayMode
TIME DATE
STOPPER
Stopwatch Specification (AsmL)
State Variables
The variable SWDisplayMode holds the current display mode of the stopwatch
var SWDisplayMode as DisplayMode = TIME
The variable SWStopperRunning indicates whether or not the stopper is currently running
var SWStopperRunning as Boolean = false
The variable SWStopperFrozen indicates whether or not the stopper is currently "frozen"
var SWStopperFrozen as Boolean = false
The variable SWStopperReset indicates (when true) that the stopper counter is currently reset (i.e its value is 00:00:00)
var SWStopperReset as Boolean = true
Stopwatch Specification (AsmL)
[Action]
Mode()
if SWDisplayMode = TIME SWDisplayMode := DATE if SWDisplayMode = DATE
SWDisplayMode := STOPPER if SWDisplayMode = STOPPER
SWDisplayMode := TIME
Stopwatch Specification (AsmL)
[Action]
StartStop()
require SWDisplayMode = STOPPER
if SWStopperReset and not SWStopperRunning SWStopperReset := false
SWStopperRunning := not SWStopperRunning
Stopwatch Specification (AsmL)
[Action]
ResetLap()
require SWDisplayMode = STOPPER if SWStopperRunning
SWStopperFrozen := not SWStopperFrozen else
if SWStopperFrozen
SWStopperFrozen := false else
SWStopperReset := true
Stopwatch Specification (AsmL)
A simple stopwatch usage example
The following example illustrates how the model reacts to a simple usage scenario in which a trainer measures the time it takes for an athlete to complete a two lap run:
The trainer presses the mode button causing the stopwatch to display the date
The trainer presses the mode button causing the stopwatch to display the stopper
The trainer presses the reset/lap button causing the stopper to reset
The trainer presses the start/stop button when the athlete begins to run. As a result, the stopper is activated
The trainer presses the reset/lap button as soon as the athlete completes the first lap.
As a result, the stopper display freezes
The trainer presses the start/stop button as the athlete completes the second lap. As a result, the stopper is stopped; however, at this point the display is still "frozen" allowing the trainer to write down the first lap result
The trainer presses the reset/lap button causing the stopper display to sync with the stopper, thereby displaying the second lap results
Following is an equivalent usage scenario that might be created by the test tool:
Stopwatch Specification (AsmL)
property IsInitialState as Boolean get
return
not SWStopperRunning and not SWStopperFrozen and SWStopperReset and
SWDisplayMode = TIME
Stopwatch Specification (AsmL)
[Action(Kind=ActionAttributeKind.Scenario)]
Main()
require IsInitialState step
Mode() step
Mode() step
ResetLap() step
StartStop() step
ResetLap() step
StartStop() step
ResetLap()