Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität and Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

Slide 2 H. Schlingloff, Logical Specification B-method Aiming at program development and proof  refinement, implementation, code generation  generalized substitution Substitution is written in prefix notation  [x:=t]  instead of  [x:=t]  [x:=2](x  5) is (2  5), a true statement Program specification  admissible starting states specified by formula , desired final states specified by formula   a program is a generalized substitution  such that (  [  ]  )

Slide 3 H. Schlingloff, Logical Specification Basic Structure of an Abstract Machine MACHINE Name (Parameters) VARIABLES list of variables INVARIANT invariant predicate  INITIALISATION initialization substitution  init OPERATIONS outputs  name(inputs) ≙ substitution  END Proof obligations  The machine shall initiate in a valid state: [  init ]   The operations shall preserve the invariant - (     [  ]  ), where  is the pre-condition of the operation, and  is the substitution of the operation

Slide 4 H. Schlingloff, Logical Specification Generalized Substitutions [  1 ;  2 ]  is [  2 ][  1 ]  [  1 ||  2 ]  is [  1 ][  2 ]  (disjoint sets of variables) [x,y:=s,t]  is [tmp:=t][x:=s][y:=tmp]  [IF  THEN  1 ELSE  2 END]  is ((  [  1 ]  )  (¬  [  2 ]  )) [SELECT  1 THEN  1 WHEN  2 THEN  2 END]  is ((  1  [  1 ]  )  (  2  [  2 ]  )) [SKIP]  is  [ANY x WHERE  THEN  END]  is  x (  [  ]  ) [CHOICE  1 OR  2 END]  is ([  1 ]   [  2 ]  ) [PRE  THEN  END]  is (   [  ]  ) …

Slide 5 H. Schlingloff, Logical Specification Modularization An abstract B machine can  USE  SEE  INCLUDE  PROMOTE  EXTEND other abstract machines That way, it is possible to build complex libraries of abstract machines Rich libraries are available for most basic types

Slide 6 H. Schlingloff, Logical Specification Refinement Program transformation  A step from specification to implementation  Elimination of nondeterminism  Making a design decision  Concretizing data types and operations  Preserving interfaces, transparent to the outside Two kinds of refinement  Data refinement  Operation refinement

Slide 7 H. Schlingloff, Logical Specification Refinement Relation Mapping between concrete and abstract variables (keyword REFINES)  same signature of operations (name, params, result)  additional variables possible Compatibility constraints  initialization and operations must be compatible  weaker pre-condition, stronger post-condition: - the concrete operations shall be possible whenever the corresponding specification is possible - the values established by the concrete initialization and operations shall be mapped, by the refinement relation, to a subset of those established in the specification

Slide 8 H. Schlingloff, Logical Specification Example 1

Slide 9 H. Schlingloff, Logical Specification Example 2

Slide 10 H. Schlingloff, Logical Specification Refinement proof pattern  being a substitution,  a predicate:  [  ]  states that all executions of  establish   ¬[  ]¬  states that there exists an execution of  establishing . (     [  ]  ) Let  be the refinement relation,  M a substitution on the abstract state,  R a substitution on the concrete state, the formula [  R ]¬[  M ]¬  states that all executions of the concrete substitution  R establish that there exists an execution of the abstract substitution  M establishing  Proof obligation: The abstract and concrete invariant imply this condition

Slide 11 H. Schlingloff, Logical Specification Implementation in B Implementation is a special case of refinement An implementation is a deterministic specification which can be translated into some programming language Implementation uses sequencing, loops, and other special substitutions Implementation uses library machines for basic data types (boolean, real, set, array, …)

Slide 12 H. Schlingloff, Logical Specification Loops Syntax WHILE T : formula DO B : substitution VARIANT V : expression INVARIANT I : formula END The loop variant states the maximum number of times that the body will be executed (used to prove loop termination) The loop invariant is a formula that shall be valid each time the control condition is evaluated (used to prove termination and post-condition)

Slide 13 H. Schlingloff, Logical Specification Semantics of Loops Denotational: least fixpoint of predicate transformer Operational: by proof obligations

Slide 14 H. Schlingloff, Logical Specification Example proof

Slide 15 H. Schlingloff, Logical Specification Tool support for B Basic features  syntax checker  type checker  interactive and semi-automated proof  code synthesis Advanced features  graphical interaction  project management Atelier B, B-Toolkit, ProB animator, StudioB, B4free / Click‘n‘Prove, Brama

Slide 16 H. Schlingloff, Logical Specification OCL Object constraint language Part of UML Specifies constraints on model elements  „A constraint is a restriction on one or more values of (part of) an object-oriented model or system“ Different kinds of constraints  invariant - a constraint that must always be met by all instances of a class  precondition of an operation - a constraint that must always be true before the execution of the operation  postcondition of an operation - a constraint that must always be true after the execution of the operation  guard of a transition – a constraint that must be met before a state transition fires

Slide 17 H. Schlingloff, Logical Specification Semantics of UML 2 13 diagram types Common meta-model Instances (objects) can occur in several diagrams, different views onto the same thing A structure diagram, e.g. a class, defines a collection of objects with similar properties, attributes and methods  signature A behavioural diagram, e.g. a statechart, defines a collection of behaviours of objects  change of model in time