formal methods - alexandru ioan cuza universitydlucanu/cursuri/svs/resurse/formalmethods.pdf ·...
TRANSCRIPT
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
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
Varieties
Logic:
thm proving PVS, COQ, Isabele
Temporal logic: CTL, LTL
Game theory
Categories, co-algebras
Multi-agent systems
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’sapproach]
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’sapproach]
Practically Form af an Event
xxx =any x, y, … where
P(x, y,…, v;,w;,…)then
S(x, y;,…,v, w,…)end
an exampleany x, where
P(x, v)then
v := E(x, v)end
Guidelines to Formal System Studies (Abrial’sapproach)
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
abstractconcret
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’sapproach]
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’sapproach]
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
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