Formal Methods in Software Engineering

(1)

Formal Methods in Software Engineering

Zoltán Istenes

(2)

Formal Methods in Software Engineering

Zoltán Istenes Publication date 2014

Supported by TÁMOP-4.1.2.A/1-11/1-2011-0052.

(3)

Chapter 1. Overview

1. Introduction

Formal methods and the Eötvös Loránd University Faculty of Informatics The Eötvös Loránd University has a long tradition in teaching informatics related topics.

The Faculty of Informatics has a very solid foundation in mathematics, thanks to the use of such formal approaches as logic, automates, formal languages, compilers, Petri nets, modelling tools and approaches etc.

The department of Software Technology and Methodology considers as its main task to both teach and research the theoretical bases, methodologies and technologies of programming.

The “Formal Methods in the Software Technology” course, using the B method and Atelier B as a guiding support, taught at our University, aligns this tradition.

2. Intended audience, prerequisites, learning outcome

Intended audience, prerequisites, learning outcome

The intended audience of this teaching material are the Computer Science students at the Master level.

Prerequisites:

• Programming in “classical”, imperative programming languages (such as C, C++, C#, Java, Ada, etc.)

• Logic, predicate calculus Learning outcome:

• Students will understand the importance of the use of the formal methods such as the B method.

• Students will be able to specify, refine, implement and create executable code, using formal methods.

• Students will be able to prove formally the correctness of the program (specification or implementation) they created.

• Students will be able to use the B method and it‟s software tool the Atelier B.

3. Coverage

Coverage

This teaching material will cover:

• the B method with Classical B

• the Atelier B tool

• the basic creation of specifications, and implementations

• the ProB model checker tool

• ...

(6)

Overview

This teaching material will not cover:

• Event-B (event driven distributed programming)

• the Rodin tool

• construction of projects containing multiple machine‟s and their relations

• the deep understanding of the interactive proving process, the proving methods, the different proving strategies

• the creation of source code and the creation of the executable (machine) code

• ...

4. History and origin

History and origin

Concepts:

• Jean-Raymond Abrial : B method

• Tony Hoare, Edsgar Dijkstra : weakest precondition, guarded commands

• Cliff Jones : Pre and Post conditions

• Jean-Raymond Abrial : Z specification notation

• ...

Tools:

• Click‟n‟Prove : Dominique Cansell

• JBtools : Jannis Buttlar

• B-Toolkit : Ib Holm Sorensen

• Rodin : European Union ICT Project ADVANCE (2011 to 2014). European Union Projects DEPLOY (2008 to 2012). RODIN (2004 to 2007).

• Atelier-B : Clearsy

5. Software engineering

Software engineering

Software engineering.

• requirements

• specification

• design

• prototyping

• implementation

(7)

Overview

• verification

• maintenance

6. Formal methods

Formal methods

In computer science, formal methods refers to mathematically based techniques for the specification, development and verification of software and hardware systems. The approach is especially important in high- integrity systems, for example where safety or security is important, to help ensure that errors are not introduced into the development process.

Formal methods are particularly effective early in development at the requirements and specification levels, but can be used for a completely formal development of an implementation (e.g., a program).

Formal methods are best described as the application of a fairly broad variety of theoretical computer science fundamentals, in particular logic calculi, formal languages, automata theory, and program semantics, but also type systems and algebraic data types to problems in software and hardware specification and verification.¹

7. The whole picture...

The whole picture...

1.

software engineering - safety critical systems 2.

formal methods - specification 3.

abstract machine notation - pseudo-programming language to express abstract specifications and implementation

4.

B method - using abstract machine notation, from specification trough refinements to implementation and executable code,

5.

Atelier B - toolkit to support development using B method, automatic and interactive profs

1http://en.wikipedia.org/wiki/Formal_methods

(8)

Chapter 2. Motivation

1. Can you write a correct programme?

Simple program

Exercise.

Write a simple program and write down what does it do!

Any program, any programming language!

Write down in English what it do!

Verify if it‟s really does what ou have written!

Check it!

Double check it!

1.1. Sum of two integer numbers

Sum of two integer numbers

Example description:

Write a program that calculate the sum (add) of two integer numbers

Example code:

import java.util.Scanner;

public class sum{

public static void main(String [] args){

int a;

int b;

Scanner read=new Scanner(System.in);

System.out.println("1␣Number:␣");

a = read.nextInt();

System.out.println("2␣Number:␣");

b = read.nextInt();

System.out.println("Sum:␣"+ (a+b));

} }

Adding two integer numbers

Doyou think that the previous program can add (calculate the sum of) two integer number?

Let‟s try it!

Run and test:

$java sum

(9)

Motivation

1 Number:

5

2 Number:

7 Sum: 12

Everything seems OK...

But are you sure ?

Are really sure that the program can calculate two sum of two integer numbers?

Any integer numbers?

What are the numbers used by computers?

More tests:

1 Number:

2147483646 2 Number:

1

Sum: 2147483647

Still OK!

But try:

1 Number:

2147483647 2 Number:

1

Sum: -2147483648

Numbers...

Computers, programming languages (mostly) uses fixed-precision numbers. Overflow and underflow (and other "problems") can occur.

Floating point numbers are even worse, see Intel Floating Point Unit (FPU) division problem.

Bigger numbers in Lisp

(defun fact (n) (if (= n 0) 1 (* n (fact (- n 1))))) fact

(fact 5) 120 (fact 10) 3628800 (fact 1000)

40238726007709377354370243392300398571.. [a 2625 digit number]

(fact 100000)

(10)

Motivation

*** - Program stack overflow. RESET

Number representation / calcul precision limits.

In some programming languages (lisp for example) number representation (calculus precision) is not limited by the processor (CPU) number representation but by the computer memory.

But the calculus precision is (still) limited!

1.2. Calcul of the precondition

Sum of two ...

.

Calculate the sum of two integers where the result can be represented as a 32 bit integer number...

.

Can you calculate the domain (min and max values) of the two integers to sum?

.

Can you calculate the precondition of the "sum" operation?

.

How can you calculate the preconditions of the operations and the domain of the variables for a little more complex program?

.

Can you correct the program?

.

Can you tell now exactly what the program is doing?

.

How can you be sure, that you program works correctly?

.

Can you prove that?

2. Safety critical systems

Safety critical systems

Safety critical system.

A life-critical system or safety-critical system is a system whose failure or malfunction may result in:

• death or serious injury to people, or

(11)

Motivation

• loss or severe damage to equipment or

• environmental harm.

Risks of this sort are usually managed with the methods and tools of safety engineering.

Infrastructure

(Circuit breaker, Emergency services dispatch systems, Electricity generation, transmission and distribution, Fire alarm, Fire sprinkler, Fuse (electrical), Fuse (hydraulic), Telecommunications, Burner Control systems),

Medicine (Heart-lung machines, Mechanical ventilation systems, Infusion pumps and Insulin pumps, Radiation therapy machines, Robotic surgery machines, Defibrillator machines),

Nuclear engineering (Nuclear reactor control systems, Nuclear reactor cooling systems),

Recreation (Amusement rides, Climbing equipment, Parachutes, SCUBA Equipment),

Transport,

Railway (Railway signalling and control systems, Platform detection to control train doors, Automatic train stop),

Automotive (Airbag systems, Braking systems, Seat belts, Power Steering systems, Advanced driver assistance systems, Electronic throttle control, Battery management system for hybrids and electric vehicles, Electric Park Brake, Shift by wire systems, Drive by wire systems, Park by wire),

Aviation (Air traffic control systems, Avionics, particularly fly-by-wire systems, Radio navigation RAIM, Engine control systems, Aircrew life support systems, Flight planning to determine fuel requirements for a flight),

Spaceflight (Human spaceflight vehicles, Rocket range launch safety systems, Launch vehicle safety, Crew rescue systems, Crew transfer systems) http://en.wikipedia.org/wiki/Life-_critical_system

3. Famous failures in software technology

20 Famous Software Disasters

“To err is human, but to really foul things up you need a computer.” -Paul Ehrlich http://www.devtopics.com/20-_famous-_software-_disasters

http://www.devtopics.com/20-_famous-_software-_disasters-_part-_2/

3.1. Ariane 5

ARIANE 5 - Flight 501 Failure See video: http://www.youtube.com/watch?v=gp_D8r-_2hwk

(12)

Motivation

At 36.7 seconds after H0 (approx. 30 seconds after lift-off) the computer within the back-up inertial reference system, which was working on stand-by for guidance and attitude control, became inoperative. This was caused by an internal variable related to the horizontal velocity of the launcher exceeding a limit which existed in the software of this computer."

Ariane 5, Flight 501 Failure report : http://www.di.unito.it/~damiani/ariane5rep.html

3.2. Floating point bug

Pentium FDIV bug

The Pentium FDIV bug ¹ was a bug in the Intel P5 Pentium floating point unit (FPU). Because of the bug, the processor would return incorrect results for many calculations used in math and science. Intel blamed the problem on a few missing entries in the lookup table used by the company. The error was rarely encountered by users (Byte magazine estimated that 1 in 9 billion floating point divides with random parameters would produce inaccurate results). However, both the flaw and Intel‟s initial handling of the matter were heavily criticized. Intel ultimately recalled the defective processors.

The presence of the bug can be checked manually by performing the following calculation in any application that uses native floating point numbers, including the Windows Calculator or Microsoft Excel in Windows 95/98.

The correct value is:

However, the value returned by the flawed Pentium is incorrect at or beyond four digits:

Formal methods for safety critical systems

.

In safety critical systems (and in many other systems) the "correctness" and "provability" of the system is crucial.

.

The "correctness" and "provability" can be verified against, (relative) to a specification, description of the desired, required functionality of the system.

.

Verify "by hand" the correctness of the system in not enough and/or not possible. A formal, mathematical approach is needed.

1http://en.wikipedia.org/wiki/Pentium_FDIV_bug

(13)

Motivation

.

To "mathematically" (formally) prove the correctness of the system,

• the specification must be a formal specification,

• the system (functionality) must be described (expressed) formally,

• a formal verification tool must be used the verify the correctness against the specification.

.

Formal methods provides the necessary methodology and tools...

(14)

Chapter 3. Formal methods

1. Formal methods in computer science

Formal methods

In computer science, formal methods refers to mathematically based techniques for the specification, development and verification of software and hardware systems. The approach is especially important in high- integrity systems, for example where safety or security is important, to help ensure that errors are not introduced into the development process. Formal methods are particularly effective early in development at the requirements and specification levels, but can be used for a completely formal development of an implementation (e.g., a program).

Security

Security.

A simple and clear definition of effective security could be: a secure system is a system which does exactly what we want it to do and nothing that we don‟t want it to do even when someone else tries to make it behave differently.

2. Limits of the formal methods

WIYSIWYG

.

WISIWIG = What Is You See Is What You Get

.

WISIWIG = What Is You Specify Is What You Get

Proved or Not proved

Proved.

From specification trough refinements to implementation and source code.

Not proved.

• "Wish of the customer", informal descriptions, "oral specifications"

• the prover of the B method/Atelier B (itself, however...

http://shemesh.larc.nasa.gov/people/cam/publications/bug99.pdf)

• compiler (from source code to machine, executable code)

• the hardware: the computer, the processor, etc...

• the other software elements: operating system, editor, etc...

Use of the formal methods at different levels

(15)

Formal methods

Formal methods can be used at a number of levels¹ :

• Level 0: Formal specification may be undertaken and then a program developed from this informally. This has been dubbed formal methods lite. This may be the most cost-effective option in many cases.

• Level 1: Formal development and verification may be used to produce a program in a more formal manner.

For example, proofs of properties or refinement from the specification to a program may be undertaken. This may be most appropriate in high-integrity systems involving safety or security.

• Level 2: Theorem provers may be used to undertake fully formal machine-checked proofs. This can be very expensive and is only practically worthwhile if the cost of mistakes is extremely high (e.g., in critical parts of microprocessor design).

Programming language semantics

As with the sub-discipline of programming language semantics, styles of formal methods may be roughly classified as follows² :

• Denotational semantics, in which the meaning of a system is expressed in the mathematical theory of domains. Proponents of such methods rely on the well-understood nature of domains to give meaning to the system; critics point out that not every system may be intuitively or naturally viewed as a function.

• Operational semantics, in which the meaning of a system is expressed as a sequence of actions of a (presumably) simpler computational model. Proponents of such methods point to the simplicity of their models as a means to expressive clarity; critics counter that the problem of semantics has just been delayed (who defines the semantics of the simpler model?).

• Axiomatic semantics, in which the meaning of the system is expressed in terms of preconditions and postconditions which are true before and after the system performs a task, respectively. Proponents note the connection to classical logic; critics note that such semantics never really describe what a system does (merely what is true before and afterwards).

Operational and axiomatic semantics

• If the formal specification is in an operational semantics, the observed behavior of the concrete system can be compared with the behavior of the specification (which itself should be executable or simulateable).

Additionally, the operational commands of the specification may be amenable to direct translation into executable code.

• If the formal specification is in an axiomatic semantics, the preconditions and postconditions of the specification may become assertions in the executable code.

3. Abstract Machine Notation

Abstract Machine Notation

The B-Method uses the notion of Abstract Machines to specify and design software systems.

Abstract Machines are specified using the Abstract Machine Notation (AMN) which is in turn based on the mathematical theory of Generalised Substitutions.

3.1. Operator binding and priorities

(16)

Formal methods

Notes on operator binding

Compound formulae (e.g. A => B & C) are given an unambiguous interpretation by the operator binding rules:

• All operators bind to the left (are left-associative) except “.” which binds to the right.

• Each symbol (e.g. &) is given a priority, and the highest priorities bind strongest, e.g. A => B & C is equivalent to A => (B & C).

• In case of equal priority the leftmost operator binds the strongest, e.g. A & B & C <=> (A & B) & C. The priorities of infix operators are listed on the next slide.

Infix Operator Priorities

Priority Operator

10 ^.

3 ^{mod * /}

2 ^{- +}

1 ^..

0 /\ \/ |->

0 <| <<| |> |>> <+ +> >< circ

0 ^ -> <- /|\ \|/

0 < <= > >= /= /:

-1 <-> --> +->

-1 >-> >+> +->> >->> -->> <-- ,

-2 <: <<: /<: /<<: :=

-4 = == : <=> ::

-5 ^{& or}

-6 => ==>

-7 ^{; || []}

-8 ^|

3.2. Predicates

Predicates

(17)

Formal methods

Let z be a Variable List, x Variable, E and F be Expression Lists, P and Q be Predicates, and S, T be Sets.

z\E means that there are no free occurrences in E of the variables in z.

General Predicates

P & Q Conjunction: “P and Q”

P => Q Implication: “P implies Q” or “if P then Q”

not(P) Negation: “Not P”

!z.(Q => P) Universal quantification: “For all z where Q, P”. The predicate Q must, for each variable x in the list z, contain a constraining predicate, i.e. x: S, x <: S, x <<: S or x = E, where z\S, z\E

P or Q Disjunction: “P or Q”

P <=> Q Equivalence: “P is equivalent to Q”. An abbreviation for (P => Q) & (Q => P)

#z.P Existential quantification: “For some z, P holds”. The predicate Q must, for each variable x in the list z, contain a constraining predicate, i.e. x: S, x <: S, x <<: S or x = E, where z\S, z\E.

Predicates on Expressions

E = F Equality: E equals F.

E /= F Inequality: E is not equal to F.

3.3. Expressions

Expressions Let E and F be Expressions. E,F Expression list.

E |-> F Ordered pair (maplet).

3.4. Sets

Sets

Let z be a Variable List, P be a Predicate, E and F be Expressions, and S and T be sets.

E : S Set membership: the predicate “E belongs to S” or “E is an element

(18)

Formal methods

of S”.

E /: S Set non-membership: the predicate “E does not belong to S”, i.e.

not(E: S).

S <: T Set inclusion: the predicate “S is included in T”, i.e. “every element of S is also an element of T”.

S /<: T Set non-inclusion: the negation of the predicate S <: T.

S <<: T Strict set inclusion: the predicate “S is included in T, but is not equal to T”.

S /<<: T String set non-inclusion: the negation of the predicate S <<: T.

Set Expressions

{z | P} Set comprehension: the subset such that P. The predicate P must, for each variable x in the list z, contain a constraining predicate, i.e. x: S, x <: S, x <<: S or x = E, where z\S, z\E.

{z | z: S & P} Set comprehension: the subset of S such that P. e.g.

{x,y | x,y: S*T & P}.

S * T Cartesian product: the set of Ordered Pairs whose first component is from S and second component is from T.

POW(S) Power set: set of all subsets of S. x: POW(S) <=> x <: S.

S \/ T Set union: the set of elements which are elements of S or T.

S /\ T Set intersection: the set of elements which are elements of S and T.

S - T Set difference: the set of elements which are elements of S, but not of T.

{} Empty set: the set with no elements.

Set Expressions

POW1(S) Non-empty subset: Set of all non-empty subsets of S.

POW1(S) = POW(S) - {}.

FIN(S) Finite subsets: Set of all finite subsets of S.

FIN1(S) Non-empty finite subsets: Set of all non-empty finite subsets of S.

FIN1(S) = FIN(S) - {}.

{E} Singleton set: Provided that E is not an Expression List, and E: S, E is

(19)

Formal methods

a singleton set: {x | x: S & x = E}.

{E,F} Set enumeration: Provided that F is not an Expression List, this is the set with elements from E together with element F.

{E,F} = {E} \/ {F}.

union(U) Generalised union: the generalised union of a set U of subsets of S (U: POW(POW(S))). union(U) =

{x | x: S & #s.(s: U & x: s)}.

inter(U) Generalised intersection: the generalised intersection of a set U of subsets of S (U: POW(POW(S))). inter(U) =

{x | x: S \& !s.(s: U => x: s)}.

3.5. Natural numbers

Natural Numbers

A Natural Number (i.e. a non-negative integer) is an Expression, and the Natural Numbers form an infinite set.

Let m and n be Natural Numbers, E and F be Expressions, and P be a Predicate.

Predicates on Natural Numbers

m > n Strict inequality: m is greater than n.

m < n Strict inequality: m is less than n.

m >= n Inequality: m is greater than or equal to n.

m <= n Inequality: m is less than or equal to n.

Natural Numbers Natural Number Expressions

NAT The set of natural numbers.

NAT1 The set of non-zero natural numbers.

min(S) Minimum of a non-empty subset, S, of NAT.

max(S) Maximum of a non-empty finite subset, S, of NAT.

m+n Addition: the sum of m and n.

m-n Difference: the difference of m and n (defined for m >= n).

m*n Product: the product of m and n.

m/n Division: the integer division of m by n.

(20)

Formal methods

m mod n Remainder: the remainder of the integer division of m by n.

n .. m Interval: the set of non-negative integers between n and m inclusive.

Natural Numbers

card(S) Cardinality: the cardinality of the finite set S: the number of elements in S.

SIGMA(z).(P | E) Set summation: the sum of values of the natural number expression E, for z such that P holds. For each variable x in the list z, P must contain a constraining predicate of the form x: S, x <: S, x <<: S or x= F, where z\S, z\F.

PI(z).(P | E) Set product: the product of values of the natural number expression E, for z such that P holds. For each variable x in the list z, P must contain a constraining predicate of the form x: S, x <: S, x <<: S or x= F, where z\S, z\F.

3.6. Relations

Relations

A Relation is a set of Ordered Pairs. Therefore, any set operation may also be applied to Relations. Let S, T, U and V be sets, and r, r1, r2 be relations from S to T, and let E and F be Expressions. Also let s <: S and t <: T.

Relational Expressions

S <-> T Relation: Set of relations from S to T. Equivalent to POW(S * T).

dom(r) Domain of r:

The set {x | x: S & #y.(x,y: r)}.

ran(r) Range of r:

The set {y | y: T & #x.(x,y: r)}.

p;q Relational composition: Composition of relations p and q, where p: S <-> T and q: T <-> U.

The set

{x,z | x,z: S * U & #y.(y: T & x,y: p & y,z: q)}. Also denoted by q circ p.

q circ p Composition of relations q and p. The same as p;q.

id(S) Identity on S. The set {x,y | x,y: S * S & x = y}.

(21)

Formal methods

Relations

s <| r Restriction of r by s. Also known as domain restriction. The relation formed from r by keeping only the pairs where the first element is in s.

The set {x,y | x,y: r & x: s}.

r |> t Co-restriction of r by t. Also known as range restriction. The relation formed from r by keeping only those pairs where the last element is in t.

The set {x,y |x,y: r & y: t}.

s <<| r Anti-restriction of r by s. Also known as domain subtraction. The relation formed from r by keeping only those pairs where the first element is in the complement of s.

The set {x,y | x,y: r & x: S-s}.

r |>> t Anti-co-restriction of r by t. Also known as range subtraction. The relation formed from r by keeping only those pairs where the last element is in the complement of t.

The set {x,y | x,y: r & y: T-t}.

Relations

r~ Inverse of r. The relation formed from r by interchanging the elements of each pair.

The set {y,x | y,x: T * S & x,y: r}.

r[s] Image of set s under relation r.

The set consisting of all those elements related to some element in the set s through relation r.

The set {y | y: T & #x.(x: s & x,y: r)}.

r1 <+ r2 Overriding of r1 by r2. The set (dom(r2) <<| r1) \\/ r2.

r1 +> r2 Overriding of r2 by r1. The set r2 <+ r1.

p >< q Direct product of p and q, where p: S <-> U and q: S <-> V.

The set

{x,(y,z) | x,(y,z): S * (U * V) & x,y: p & x,z: q}.

p || q Parallel product of p and q. where p: S <-> T and q: V <-> U.

The set {(x,y),(m,n) | (x,y),(m,n): (S*T) * (V*U) &

(x,m: p & y,n: q)}.

(22)

Formal methods

Relations

iterate(r,n) The nth iterate of r (where n: NAT), i.e. r composed with itself n times (defined only for r: S <-> S).

iterate(r,0) = id(S) and

iterate(r,n+1) = r;iterate(r,n).

closure(r) The reflexive transitive closure of r (defined only for r: S <-

> S).

closure(r) = UNION(n).(n: NAT | iterate(r,n)).

prj1(S,T) Projection:

prj1(S,T) = {(x,y),z | (x,y),z: (S*T)*S & z = x}.

prj2(S,T) Projection:

prj2(S,T) = {(x,y),z | (x,y),z: (S*T)*T & z = y}.

3.7. Functions

Functions

A Function is a Relation with the additional property that each element of the domain is related to a unique element in the range. Any operation applicable to Relations may also be applied to Functions. Let S and T be sets, z a Variable List, E be an Expression, and P be a predicate.

S +-> T Set of partial functions from S to T (also known as „many-to-one relations‟).

The set {r | r : S <-> T & (r~;r) <: id(T)}.

S --> T Set of total functions from S to T.

The set {f | f : S +-> T & dom(f) = S}.

S >+> T Set of partial injections from S to T (also known as „one-to-one relations‟).

The set {f | f : S +-> T & f~ : T +-> S}.

S >-> T Set of total injections from S to T.

The set S >+> T /\ S --> T.

Functions

S +->> T Set of partial surjections from S to T.

(23)

Formal methods

The set {f | f: S +-> T & ran(f)=T}.

S -->> T Set of total surjections from S to T.

The set S +->> T /\ S --> T.

S >->> T Set of bijections from S to T.

The set S -->> T /\ S >-> T.

%z.(z: S & P | E) Function construction.

The function {x,y | z: S & y=E & P} where y\E and y\P, with domain {z | z: S & P}.

%z.(P | E) Function construction.

The predicate P must, for each variable x in the list z, contain a constraining predicate i.e.

x: S, x <: S, x <<: S or x = E, with z\S, z\E.

f(x) For x: dom(f), f(x) denotes the value of the function f at x, i.e. x |-> f(x): f.

3.8. Sequences

Sequences

A sequence over a set S is a function from NAT to S whose domain is an interval 1..n for some natural number n. Let s, t be sequences of elements from S, e be an element of S, and E and F be expressions.

<> The empty sequence.

seq(S) The set of finite sequences of elements from S.

seq1(S) The set of finite non-empty sequences of elements from S.

seq1(s) = seq(s) - {<>}.

iseq(S) The set of injective sequences of elements from S.

iseq(S) = seq(S) /\ (NAT1 >+> S).

perm(S) The set of bijective sequences of elements from a finite set S. A sequence belonging to perm(S) is said to be a „permutation‟ of S. For finite S, perm(S) = 1..card(S) >->> S.

s\^t The concatenation of sequences s and t.

e -> s The sequence formed by prepending e to s.

s <- e The sequence formed by appending e to s.

size(s) The size of the finite sequence s.

(24)

Formal methods

Sequences

[E] Provided that E is not an Expression List, [E] is the singleton sequence with element E, i.e [E] = E -> <>.

[E,F] Provided F is not an Expression List, then this is [E] with F appended. Equivalent to [E] <- F.

rev(s) The reverse of s.

s /|\ n The sequence obtained from s by retaining only its first n elements, where n <= size(s).

s \|/ n The sequence obtained by removing the first n elements of s, where n <= size(s).

first(s) The first element of the non-empty sequence s.

last(s) The last element of the non-empty sequence s.

tail(s) The sequence s with its first element removed (s must be non-empty).

front(s) The sequence s with its last element removed (s must be non-empty).

conc(s) The generalised concatenation of a sequence of sequences, s. For a sequence t, conc(<>) = <> and conc(s <- t) = conc(s)\^t.

3.9. Variables

Variables, Variable Lists and Identifiers

A Variable is an Identifier.

An Identifier is a string of length 2 or more of alphanumeric characters ( a to z, A to Z, 0 to 9 ASCII codes) or underscore „_‟, with at least one letter.

An Upper Case Identifier is an Identifier made only from upper case letters and underscore.

An Infix operator is either a string of non-alphanumeric characters (excluding „_‟ “‟ „$‟ and „?‟) or an Identifier declared as an Infix Operator in the AMN Symbol Table, e.g. „mod‟.

Let z be a Variable List and x be a Variable.

z,x ((z,x)) is a Variable List.

3.10. Generalised Substitutions

Generalised Substitutions

Let x be a Variable, z be a variable List, P and R be predicates, E and F be Expressions, and S, T be Generalised Substitutions.

[S]P is a predicate obtained by replacing the variables in P according to the rules below.

(25)

Formal methods

[x:= E]F An expression obtained by replacing all free occurrences of x in F by E.

z\A Non-freeness: z is not free in E, i.e. there are no free occurrences of z in the Predicate or Expression A.

x:= E Simple substitution. Substitute E for x in a Predicate or Expression formula. (Note that the applicability of a simple substitution on a formula is limited by non-freeness conditions when the formula is a quantified expression or a set comprehension).

x,y:= E,F Simultaneous substitution. Substitute several Expressions for several Variables.

x:=E || y:=F Simultaneous substitution. A form equivalent to the above simultaneous substitution.

Generalised Substitutions

P | S Pre-conditioning of S by P. [P | S]R = P & [S]R.

P ==> S Guarding of S by P. [P ==> S]R = P => [S]R.

S [] T Choice between S and T. [S [] T]R = [S]R & [T]R.

@z.S Unbounded choice. [@z.S]R = !z.[S]R

S;T Sequencing. [S;T]R = [S][T]R.

skip No-op.

(26)

Chapter 4. The B method

1. Overview of the B method

1.1. Main components

Main components of the B method

Abstract machine.

In the first and the most abstract version, which is called Abstract Machine, designer should specify the goal of the design.

Refinement.

Then, during a refinement step, he may pad the specification in order to clarify the goal or to turn the abstract machine more concrete by adding more details about data structures and algorithms that explain how the goal may be achieved. The new version, which is called Refinement, should be proven to be coherent and including all the properties of the Abstract Machine.

Implementation.

The refinement in its turn may be refined one or many times to obtain a deterministic version which is called Implementation. During all of the development steps the same notation is used and the last version may be translated to Ada, C or C++ language.

1

From specification to source code

1http://en.wikipedia.org/wiki/B-_Method

(27)

The B method

1.2. Characteristics

Characteristics of the B method

• Use same language in specification, design and programation.

• Mechanism include encapsulation and data locality.

• Clear and close introduction for refinement concept.

• Originated in the 1980s by Jean-Raymond Abrial.

• B method is a tool-supported formal methods based around AMN (Abstract Machine Notation), used in the development of correct software.

• B method has been used in some major safety-critical system applications in Europe.

2

Brief Description of the B Method : B method notation

The B method uses a notation based on the mathematical concept of theory sets. The notation is useable throughout the development cycle, meaning that you obtain a uniform formal setting which replaces conventional specifications from preliminary design to code generation.

2http://en.wikipedia.org/wiki/B-_Method

(28)

The B method

The initial expression of need is generally produced using natural language, or combined descriptions (e.g., charts, automatons, logical tables, Petri networks and methods such as SADT or SA-RT).

The B development process begins with the construction of a model that incorporates all descriptions of the need and describes the system‟s main state variables. Also described are the properties (or invariants) which these variables must meet and their transformation by services (or operations). The obtained B model constitutes the specifications of what the system must implement (the "what").

The B model is then refined until a complete implementation of the software system is obtained (the "how").

Several refinements may be needed to satisfy the specifications.

B method - development, coherence

Using B in the development of a system is therefore about:

• removing all ambiguity from the interpretation of the need,

• building specifications that are coherent and compliant with the need (the "model"),

• developing the software system implements the specifications, in successive stages.

The coherence of the model, and the conformity of the final program in relation to this model are guaranteed by mathematical proofs. Automatic proof tools, such as those provided by Atelier B, must be used to demonstrate these proofs concretely.

The formal definition of the substitutions enables Proof Obligation to be demonstrated, to ensure that an operation call preserves the static properties of the abstract machine (the "invariant").

Refinement

The refinement mechanism consists in reformulating the variables and operations of the abstract machine successively, to obtain a module that eventually constitutes a computer program. The intermediary stages of reformulation are called "refinements" and the final level of refinement is called "implementation." Each B component (abstract machine, refinement or implementation) is structured using a unique language, the B Language.

During each refinement, it is necessary to prove that the behavior of an operation is compatible with the operation stated at the abstract level. The code of an implementation will thus effectively conform with the specifications of the corresponding abstract machine.

Refinements and profs

(29)

The B method

What is B method?

The B-Method is designed to provide a notation and a method for requirement modeling, software interface specification, software design, implementation and maintenance, thus supporting the major phases of a software process. Incremental construction of layered software as well as its incremental verification and validation are the guiding principles of the B-Method.

Tools supports the method over the entire software process and comprises a large suite of tools which can run automatically or interactively. All tools are integrated into a window-based development environment. The tool supports the incremental construction of the software. The validation processes are supported by static analysis which employ and checking, by dynamic analysis using simulation, as well as proof of correctness using an integrated theorem prover.

B method - Abstract Machine Notation

The B-Method is a collection of mathematically based techniques for the specification, design and implementation of software components. Systems are modelled as a collection of interdependent Abstract Machines, for which an object-based approach is employed at all stages of development. An Abstract Machine is described using the Abstract Machine Notation (AMN). A uniform notation is used at all levels of description, from specification, through design, to implementation.

AMN is a state-based formal specification language in the same school as VDM and Z. An Abstract Machine comprises a state together with operations on that state. In a specification and a design of an Abstract Machine the state is modelled using notions like sets, relations, functions, sequences etc.. The operations are modelled using Pre- and Post-conditions using AMN.

In an implementation of an abstract machine the state is again modelled using a set-theoretical model, but this time we already have an implementation for the model. The operations are described using a pseudo- programming notation that is a subset of AMN.

(30)

The B method

B method : checking specifications for consistency and correstness

The B-Method prescribes how to check the specification for consistency (preservation of invariant) and how to check designs and implementations for correctness (correctness of data refinement and correctness of algorithmic refinement).

The B-Method further prescribes how to structure large designs and large developments, and promotes the re- use of specification models and software modules, with object orientation central to specification construction and implementation design.

A great deal of attention has been paid to making the notational aspect of the method as simple as possible. To the engineer, the formal notation looks like a simple pseudo programming notation. And as mentioned above, there is no real distinction between the specification notation and the programming notation.

2. Industrial use of the B method

Industrial use of the B-method

• Paris metro line 14

• 117.000 B loc

• 29.000 proofs

• 87.000 ADA loc

• Paris CDG airport metro

• 180.000 B loc

• 43.000 proofs

• 140.000 ADA loc

• 98% automatic proved

(31)

The B method

3

Ateleir B used in metros around the world

3Source: http://en.wikipedia.org/wiki/Paris_Metro_Line_14

(32)

The B method

4

3. The B language

3.1. Substitution

Definition of the substitution .

the is: change all free occurrence of the in to

Example for free and binded variables: :free variable, : binded variable

Substiution, initialisation - example ...

VARIABLES z INVARIANT R

INITIALISATION

4Source: http://www.tools.clearsy.com/

(33)

The B method

H ...

.

...

VARIABLES tanulo INVARIANT

tanulo DIAKOK INITIALISATION

tanulo:=

...

.

the initialisation keeps the invariant property

Definition of the operations with substitution .

G;H P

.

PRE P THEN G END Q

.

IF P THEN G ELSE H END Q

.

CHOICE G OR H END Q

.

ANY x WHERE P THEN G END Q

(34)

The B method

.

G; WHILE P DO H

VARIANT E

INVARIANT I

END Q

Operation, substitution verification - example

INVARIANT rfree RES INITIALISATION rfree:=

OPERATIONS alloc(rr)= PRE rr rfree

THEN rfree:=rfree-{rr} END;

.

PRE P THEN G END Q

3.2. Abstract machine structure, proofs

Abstract machine structure

MACHINE machine (x) CONSTRAINTS P

CONSTANTS y

PROPERTIES Q

INITIALISATION H

OPERATIONS

(35)

The B method

opname = PRE L THEN G END END

machine, opname : identifiers

x,x, z :identifier lists

P, Q, R, L : predicates

G, H : substitutions

Proof of the coherence of an abstract machine

MACHINE machine (x) CONSTRAINTS P

CONSTANTS y

PROPERTIES Q

INITIALISATION H

OPERATIONS

opname = PRE L THEN G END END

.

constraints consistence

.

properties consistence

.

"implementability"

.

correctness of the initialisation

.

(36)

The B method

correctness of the operations

3.3. Abstract machine and implementation

Abstract machine and concrete machine

absztrakt concrete

variable

invariant

initialisation

op. output

op. precondition

op. substitution

.

correctness of an operation

(the is where is substituted by )

Abstract machine and concrete machine correspondance - example

abstrakt concrete

variable

invariant

initialisation

.

(37)

The B method

Structure of a B specification

.

sets, constants, variables

.

invariant

.

initialisation

.

operations

(38)

Chapter 5. Software tools of the B method

1. Atelier B

Atelier B made by Clearsy

"Ateler B, the industrial tool to efficiently deploy the B method"

"Developed by ClearSy, Atelier B is an industrial tool that allows for the operational use of the B Method to develop defect-free proven software (formal software). Two versions are available: Community Edition available to anyone without any restriction, Maintenance Edition for maintenance contract holders only.

It is used to develop safety automatisms for the various subways installed throughout the world by Alstom and Siemens, and also for Common Criteria certification and the development of system models by ATMEL and STMicroelectronics. Additionally, it has been used in a number of other sectors, such as the automotive industry, to model operational principles for the onboard electronics of three car models. Atelier B is also used in the aeronautics and aerospace sectors."¹

Atelier B - Presentation

Atelier B is a tool enabling the operational use of B method. In a coherent environment, it provides many functions for managing projects in B language.

These functions can be divided into three categories:

• proof aid, to demonstrate proof obligations using suitable proof tools

• development aid: automatic management of dependence between B components,

• user comfort tools: graphical representation of projects, display of project status and statistics, project archiving.

Atelier B is either used via a Man Machine Interface in QT format or using the commands directly (command mode). Atelier B is multi-user. Tasks that can be automated during project development are the following:

• syntax verification of components

• automatic proof obligation generation

• automatic translation of B installations to C or Ada language

From now on, Atelier B is available in Windows, Linux, Mac OS AND Solaris.²

Atelier B - The main functions of Atelier B

• Languages supported

• B

• Event B

1Ateleir B presentation from Clearsy at http://www.atelierb.eu/en/

2Presentation of the Atelier B tool is from http://www.atelierb.eu/en/atelier-_b-_tools/

(39)

Software tools of the B method

• Automatic refinement

integration of an automatic refinement tool (BART). BART enables refinement and implementation generation using a refinement rule base that can be expanded by the user. BART operates on a refinement rule basis. Additional refinement rules can be added for refinement personalisation of certain components.

• Syntax analysers

These are used to carry out all syntax verifications of files in B language:

• a model editor has been integrated into Atelier B. This integrates a syntax analyser, automatic completion as well as navigation functions throughout the model.

• the Type Checker first carries out a grammatical verification of a B component, and then a certain number of contextual verifications including the type control and the control of identifier scopes. Components have to pass through the Type Checker before being proved and before any other of the verifications presented below

• the B0 Checker carries out verifications specific to the BO language used in the installations (a sub- division of B language) to ensure that they can be translated.

• the project checker checks all the components of a project to control its architecture (the links between the components). The project must have been checked before the final translation of the project.

• B models can be saved in pdf, rtf and LaTeX formats.

• Proof tools

These have the following functions:

• the automatic generation of the proof obligations using the components in B language

• a B component is correct when its proof obligations are demonstrated

• proof in automatic mode: most of the proof obligations are demonstrated without user intervention

• the proof in interactive mode used when the automatic mode has failed: the user guides the prover in its proof obligation demonstration using interactive commands (lemma additions, proof by case etc.)

• the predicate prover: predicate demonstration: demonstration of rules added by the user

• viewing poof obligations, their origin and their status (trivial, proved, non-proved)

• the management of a validated rule base including more than 2 200 rules

• Automatic translators

The installations make up the coding stage for a development in B language. They are written using a B language sub-assembly, similar to an imperative programming language. In order to facilitate code generation on any target system, the installations are translated automatically to standard programming language. The programmes obtained can then be compiled and assembled on the target machine to produce the executable software.

(40)

• The graphic representation of projects

It is used for the graphic representation of the components of a project and their links, by positioning them automatically on the graph. The user can choose different display options, for example the type of links to be viewed, the view of the whole dependence graph of a project or the dependence graph of a component.

• Project management

Atelier B offers large size project management services (including for example 500 components). In particular:

• Atelier B used by several users in a network. These users can work on the same project at the same time

• to archive and restore a whole project

• to architecture a project or several sub-projects or libraries. As such, Atelier B enables large and modular developments by several developer teams

• to view the overall status of a project, by supplying for each component, its status (passed to Type Checker, translated to C or to Ada), the number of proof obligations and the percentage proved

• to generate automatically the dependencies between the project‟s components. As such, to carry out an action (passage through the Type Checker, through the proof obligation generator etc.) on a selection of components, Atelier B reports the action(s) required for the components on which it depends.

Download and installing Atelier B

http://www.atelierb.eu/en/

http://www.atelierb.eu/en/download-_atelier-_b/

"The new licence associated with the Atelier B V4 is distributed free of charge to all those who wish to use Atelier B for research, teaching and development of their industrial projects. As soon as the tool is used for the first time it is allocated for an unlimited time.

The atelier B V4 comprises all the tools required for developing an industrial project and is available in WINDOWS, MAC, LINUX, SOLARIS

Users, companies and research or teaching organisations can subscribe to a maintenance contract for the intermediate versions (corrective or with new functional features).

The licence contract supplied with Atelier B can be downloaded and is available for consultation here in French and English." ³

1.1. Starting a new project in Atelier B

The first Atelier B project

1.

Launch Atelier B

2.

3http://www.atelierb.eu/en/download-_atelier-_b/

(41)

Creation of a new project (setting project parameters)

3.

Creation (edit) of an abstract machine (specification)

4.

Type check

5.

Generation of the proof obligations

6.

using the automatic prover

7.

B0 check

Atelier B ...

Launching Atelier B

Opening screen with recent projects, tutorial, websites...

Atelier B ...

Local projects...

(42)

Atelier B ...

Creating (naming) a new (software development) project

Atelier B ...

Setting project parameters: directories, configuration, etc..

(43)

1.2. Creation of an abstract machine

Atelier B ...

Creating (naming) a new specification (machine)...

In Atelier B vocabulary specification called machine...

Atelier B ...

Preview of the (empty) specification

(44)

Atelier B ...

Opening and editing a specification

Atelier B ...

Specification (with some syntax errors indicated)

(45)

Atelier B ...

Specification (all syntax error corrected)

1.3. Type checking

Atelier B ...

Specification type checked...

(46)

Key checked : OK

1.4. Generating the proof obligations

Atelier B ...

Generation of proof obligations (POs)

Proof obligations generated, # of proof obligations : 4, # proved: 0, # of unproved: 4

Atelier B ...

Using the automatic prover

(47)

# of proof obligations : 4, # proved: 4, # of unproved: 0

Atelier B ...

B0 check

B0 check is : OK

Specification, refinement and proof 1.

creation of an abstract machine

(48)

2.

creation of an implementation of the abstract machine

3.

interactive proof of the abstract machine and the implementation

4.

interactive proof of the unproved proof obligations

Atelier B ...

Creation of a new project

Atelier B ...

Setting project parameters

(49)

Atelier B ...

Creation of a new abstract machine (a new specification)

Atelier B ...

Edit of the abstract machine

(50)

1.5. Creation of an implementation

Loop specification

MACHINE Looptest2 CONCRETE_VARIABLES xx

INVARIANT

xx : 0..10 --> NAT INITIALISATION

xx := (0..10) * {0}

OPERATIONS nulla=

BEGIN

xx := (0..10) * {0}

END END

Loop implementation

IMPLEMENTATION Looptest2_i REFINES Looptest2

INITIALISATION xx:=(0..10) * {0}

OPERATIONS nulla=

VAR ii IN ii:=-1;

WHILE ii /= 10 DO xx(ii+1):=0;

ii:=ii+1 INVARIANT

(51)

ii : INTEGER &

xx : 0..10 --> NAT &

ii : -1..10 &

!jj.(jj:(0..ii) => xx(jj)=0) VARIANT

11-ii END END END

Atelier B ...

Type checked, PO generated, Unproved...

1.6. Automatic proving

Atelier B ...

Abstract machine automatic proved 100% (4/4)...

(52)

Atelier B ...

Implementation automatic proved partially (16/14), 2 Unproved...

1.7. Interactive proving

Atelier B ...

Launching the interactive prover. 14 POs proved (PO1-14), 2 POs (PO15-16) unproved

(53)

Atelier B ...

Hypotheses and the predicate to prove...

Atelier B ...

first step is "Prove" (pr)

(54)

Atelier B ...

next step is "Predicate Prover with first level of hypothesis" (pp1)

success, the prof obligation (PO15) is proved...

Atelier B ...

interactive proving of the next (PO16) prof obligation, hypotheses and the predicate to prove...

(55)

Atelier B ...

first step is "Prove" (pr)...

Atelier B ...

next step is "Predicate Prover with first level of hypothesis" (pp1)

(56)

success, the prof obligation (PO15) is proved...

Atelier B ...

All the proof obligations are proved. Leaving (exit) the interactive prover, propose to save "User Pass" (the trace of the proving)

Atelier B ...

Creation of an "User Pass"...

(57)

Atelier B ...

Preview of the "User Pass" : for the operation "nulla", "pr" then "pp1"

Atelier B ...

Now everything (abstract machine and the implementation) is proved, 0 Unproved...

(58)

1.8. B0 check

Atelier B ...

The B0 check...

Atelier B ...

The B0 check is OK...

(59)

Launching the ProB animation...

2. ProB

The ProB tool...

ProB.

ProB is an animator and model checker for the B-Method (see the B-Method site of Clearsy).

It allows fully automatic animation of many B specifications, and can be used to systematically check a specification for range of errors. The constraint-solving capabilities of ProB can also be used for model finding, deadlock checking and test-case generation.

4

ProB ...

Starting the tool

4http://www.stups.uni-_duesseldorf.de/ProB/index.php5/The_ProB_Animator_and_Model_Checker

Formal Methods in Software Engineering

Formal Methods in Software Engineering

Zoltán Istenes

Formal Methods in Software Engineering

Table of Contents

Chapter 1. Overview

1. Introduction

2. Intended audience, prerequisites, learning outcome

3. Coverage

4. History and origin

5. Software engineering

6. Formal methods

7. The whole picture...

Chapter 2. Motivation

1. Can you write a correct programme?

1.1. Sum of two integer numbers

1.2. Calcul of the precondition

2. Safety critical systems

3. Famous failures in software technology

3.1. Ariane 5

3.2. Floating point bug

Chapter 3. Formal methods

1. Formal methods in computer science

2. Limits of the formal methods

3. Abstract Machine Notation

3.1. Operator binding and priorities

3.2. Predicates

3.3. Expressions

3.4. Sets

3.5. Natural numbers

3.6. Relations

3.7. Functions

3.8. Sequences

3.9. Variables

3.10. Generalised Substitutions

Chapter 4. The B method

1. Overview of the B method

1.1. Main components

1.2. Characteristics

2. Industrial use of the B method

3. The B language

3.1. Substitution

3.2. Abstract machine structure, proofs

3.3. Abstract machine and implementation

Chapter 5. Software tools of the B method

1. Atelier B

1.1. Starting a new project in Atelier B

1.2. Creation of an abstract machine

1.3. Type checking

1.4. Generating the proof obligations

1.5. Creation of an implementation

1.6. Automatic proving

1.7. Interactive proving

1.8. B0 check

2. ProB