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’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

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()