1. 10.6.2008 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

2. Slide 2 H. Schlingloff, Logical Specification 10.6.2008 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 (  [  ]  )

3. Slide 3 H. Schlingloff, Logical Specification 10.6.2008 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

4. Slide 4 H. Schlingloff, Logical Specification 10.6.2008 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 (   [  ]  ) …

5. Slide 5 H. Schlingloff, Logical Specification 10.6.2008 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

6. Slide 6 H. Schlingloff, Logical Specification 10.6.2008 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

7. Slide 7 H. Schlingloff, Logical Specification 10.6.2008 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

8. Slide 8 H. Schlingloff, Logical Specification 10.6.2008 Example 1

9. Slide 9 H. Schlingloff, Logical Specification 10.6.2008 Example 2 http://www-public.int-evry.fr/~gibson/Teaching/B/Lectures

10. Slide 10 H. Schlingloff, Logical Specification 10.6.2008 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

11. Slide 11 H. Schlingloff, Logical Specification 10.6.2008 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, …)

12. Slide 12 H. Schlingloff, Logical Specification 10.6.2008 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)

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

14. Slide 14 H. Schlingloff, Logical Specification 10.6.2008 Example proof

15. Slide 15 H. Schlingloff, Logical Specification 10.6.2008 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

16. Slide 16 H. Schlingloff, Logical Specification 10.6.2008 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

17. Slide 17 H. Schlingloff, Logical Specification 10.6.2008 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