ABZ Conference, London 2008 Building a Model-Checker for Z John Derrick, Siobhán North and Anthony...

ABZ Conference, London 2008

Building a Model-Checker for Z

John Derrick, Siobhán North and Anthony Simons

Department of Computer ScienceUniversity of Sheffield

ABZ Conference, London 2008 slide 2

Overview Tool support for Z refinement Z2SAL translation strategy Basic types, free types, schemas The mathematical toolkit Evaluation and performance

translations andcircumlocutions!


What Tools for Z? CADiZ (Toyn & McDermid)

type checker, schema layout CZT project (Miller, et al.)

Parser, checker for LaTeX-Z/ZML markup of ISO-Z AST toolkit for java … more modules to follow

ProZ (Plagge & Leuschel) validates Z, based on ProB tool (Leuschel & Butler)

Alloy and Z (Bolton) recoding Z in Alloy, check refinements

SAL translation (Smith & Wildman; Derrick et al.) leverage existing checkers, rich input language


Advantages of Symbolic Analysis Laboratory

from SRI (de Moura, et al.), good user base rich input language has finite types, tuples, arrays,

records, recursion (?), modules … core engine based on BDD compilation, symbolic

simulation using Bűchi automata many tools: simulator, model-checker, bounded

model-checker, … checks both LTL and CTL properties

Z-to-SAL translation strategy perhaps easier than building a native Z model-checker


Issues Bounding the infinite

Z supports infinite models, uninterpreted symbols SAL needs finite models, concrete bounded ranges

Mismatched models Z has separate operation schemas acting upon the data SAL compiles all input, output, local vars into a single

FSM with transitions representing the operations Z functions are partial; SAL functions are total Monolithic set types; vs. judgements on ordered

variables Non-constructive specifications

Z can express non-constructive specifications SAL tools require a computable update step


Translator Bespoke Z parser/SAL generator

we use our own Java parser for LaTeX-Z allows rapid prototyping, experimentation much easier than (poorly documented ) CZT ASTs

Optimisation during analysis model bounds set by range indicators found in the Z early elimination of trivially satisfied predicates

Template-driven generation Z structures map onto related SAL structures we use our own SAL libraries for the Z math toolkit


Strategy Types, constants

translate unbounded Z types into bounded SAL types translate uninterpreted Z constants into SAL variables,

or simplify to constants (by symbolic reasoning) State, operation schema variables

translate state schema vars into LOCAL vars translate operation in?, out! to INPUT, OUTPUT vars

State init, operation schemas translate all schemas into an executable MODULE Z operations become the transitions of the FSM Z pre-, post-conditions become SAL guarded

commands


Z Types Built-in types

1 NZNAT : TYPE = [1..3];NAT : TYPE = [0..3];INT : TYPE = [-1..3];

Basic types[PERSON] PERSON : TYPE = {PERSON__1,

PERSON__2, PERSON__3};

Free typesREPORT ::= REPORT : TYPE = DATATYPE ok | ok,

error «MESSAGE» error (message : MESSAGE)END;


Z Constants Uninterpreted

Either, pick a suitable constant value:

max : max : NAT = 3; Or, treat as a local variable:

max : LOCAL max : NAT Axiomatic Definitions

Treat as a constrained local variable:

max : | max < 3 LOCAL max : NAT…DEFINITION invariant__ = … AND max < 3 …

… more on invariant__ next …


Z State Schema Data declarations

treat as local vars in FSM module

State predicate define var invariant__

as an abbreviation

level : State

1 < level max

State : MODULE = BEGIN LOCAL level : NAT LOCAL invariant__ : BOOLEAN … DEFINITION invariant__ = (1 < level AND

level <= max … ) …END;


Z Init Schema – 1 Initialisation

set of assignments

Problems SAL init, update is constructive Z may be equational

StateInit

level = 2

State : MODULE = BEGIN LOCAL level : NAT … DEFINITION … INITIALIZATION level = 2; … …END;

… how to handle? …


Guarded Commands SAL transition language

usual syntax: if guard then constructive assignments

[ c1 AND c2 … AND cn --> v1’ = e1; v2’ = e2; … vn’ = en ]

Z2SAL translation idea : move all update expressions back into the guard enables equational reasoning for update expressions

[ c1 AND c2 … AND cn AND v1’ = e1 AND v2’ = e2 … AND vn’ = en -->

v1’ IN { x : NAT | TRUE }; v2’ IN { y : INT | TRUE }; … vn’ IN { z : NAT | TRUE };]

sense: vars exist a posteriori


Z Init Schema – 2 Non-constructive

if the assignment holds then the initial state is

valid (empty consequent)

A bonus for Z can assert the invariant

in the initial state abbreviates a large

conjunction of terms

State : MODULE = BEGIN LOCAL level : NAT … DEFINITION … INITIALIZATION [ level = 2 AND invariant__ --> ] …END;


Z Operation Schema – 1 Input, output vars

exist in one SAL scope must rename uniquely

Δ Statein? : out! : REPORT

Inc

level + in? maxlevel’ = level + in?out! = ok

State : MODULE = BEGIN LOCAL level : NAT INPUT Inc__in? : NAT OUTPUT Inc__out_ : REPORT … DEFINITION invariant__ = … INITIALIZATION … AND invariant__ … TRANSITION … AND invariant__’ … …END; assert invariant__’

after each step…


Z Operation Schema – 2 Pre-, post-conditions

guarded commands update FSM vars

Δ Statein? : out! : REPORT

Inc

level + in? maxlevel’ = level + in?out! = ok

State : MODULE = BEGIN LOCAL level : NAT INPUT Inc__in? : NAT OUTPUT Inc__out_ : REPORT … TRANSITION [ Inc : level + Inc__in? <= max AND level’ = level + Inc__in? AND Inc__out_’ = ok AND invariant__’ --> level’ IN { x : NAT | TRUE} [] … ]END;


MathToolkit General strategy

define Z math data types in separate SAL text-units parameterized CONTEXTs reused with different types

Sets, relations translate sets, relations into Bryant’s ordered

propositions specific problems with cardinality, product-types

Functions, sequences, bags translate partial Z functions into total SAL functions requires bottom elements, rules for bottom still working on sequences, bags


Set Contextset {T : TYPE;} : CONTEXT = BEGIN Set : TYPE = [T -> BOOLEAN]; empty : Set = LAMBDA (elem : T) : FALSE; … contains? (set : Set, elem : T) : BOOLEAN = set(elem); union (setA : Set, setB : Set) : Set = LAMBDA (elem : T) : setA(elem) OR setB(elem); …END

LOCAL members : set{PERSON;} ! SetINITIALIZATION members = set{PERSON;} ! empty

set definition; and usage


Ordered Propositions Bryant’s encoding for sets

conversion into ordered propositions over elements monolithic “set” has no direct representation set type is a function from element boolean polylithic judgements over ordered elements

Pros and Cons highly efficient compilation into BDDs set-operations boolean graphs for each element difficult to count the elements in a set but Z needs a cardinality operation


Brute Force Countingcount3 {T : TYPE; e1, e2, e3 : T} : CONTEXT = BEGIN Set : TYPE = [T -> BOOLEAN]; size? (set : Set) : NATURAL = IF set(e1) THEN 1 ELSE 0 ENDIF + IF set(e2) THEN 1 ELSE 0 ENDIF + IF set(e3) THEN 1 ELSE 0 ENDIF;END

LOCAL num : NATLOCAL friends : set{PERSON;} ! Set… num = count3{PERSON; PERSON__1, PERSON__2,

PERSON__3} ! size?(friends) …

count3 definition; and usage

Z2SAL generates counting contexts, as required


Relation Encoding Follows set encoding

set type ordered propositions over elements relation type set of pairs ordered props. over

pairs Encoding choices

re-implement all set-ops in the relation context provide only the rel-ops in the relation context, and re-

use all set-ops from the set context SAL typing issue

set{…}!Set ≠ relation{…}!Relation because type names specific to their local context

solution: pick only one local context to export “public” names by which types are known in main context


Relation Contextrelation {X, Y : TYPE;} : CONTEXT = BEGIN XY : TYPE = [X, Y]; Domain : TYPE = [X -> BOOLEAN]; Relation : TYPE = [XY -> BOOLEAN]; … domain (rel : Relation) : Domain = LAMBDA (x : X) : EXISTS (y : Y) : LET (pair : XY) = (x, y) IN rel(pair); …END

PERSON__X__NAT : TYPE = [PERSON, NAT];LOCAL phonebook : set{PERSON__X__NAT;} ! Set… friends = relation{PERSON, NAT;} ! domain(phonebook) …

relation definition; and usage

SAL bug : type subst. expects single symbol; can’t subst. structure


Partitioning Z MathOps Multiple contexts

relation type also defined as set of pairs allows reuse of set-ops for relations specific rel-ops provided by relation context can we extend this idea?

Partitioning criteria package mathops by the number of type params eg: give separate contexts for closure{X;},

relation{X,Y;} and compose{X,Y,Z;}


Function Encoding Follow relation encoding?

function type set of pairs similar to relation impose extra restrictions on range

supports empty, partial, mutable functions slower execution, bigger search space

Follow native SAL encoding? function type ordered mappings over elements only supports total functions faster execution, close to BDD encoding

Totalising strategy by extending partial types with bottom values


Function Contextfunction {X, Y : TYPE; xb : X, yb : Y} : CONTEXT = BEGIN Function : TYPE = [X -> Y]; Domain : TYPE = [X -> BOOLEAN]; … domain (fun : Function) : Domain = LAMBDA (x : X) : fun(x) /= yb; …END

NAT : TYPE = [0..4];PERSON : TYPE = {PERSON__1, PERSON__2, … PERSON__B};LOCAL passport : [PERSON -> NAT]LOCAL citizens : set{PERSON;} ! Set … citizens = function{PERSON, NAT; PERSON__B, 4} !

domain(passport) …

sentinel value, or explicit bottom

xb, yb are formal params for bottom


Extended InvariantNAT : TYPE = [0..4];PERSON : TYPE = {PERSON__1, PERSON__2, … PERSON__B};

LOCAL passport : [PERSON -> NAT]INPUT Apply__citizen? : PERSONOUTPUT Apply__passid_ : NATDEFINITION invariant__ = ( …

AND Apply__citizen? /= PERSON__BAND Apply__passid_ /= 4…AND passport(PERSON__B) = 4

…)

f(xb) = yb asserted globally for each fn shorter fn defns

All Z inputs, outputs must be well-defined


Function Types Z function typology

partial or total, combined with unmarked, surjective, injective, bijective

Encode as distinct SAL types? would require duplicated function contexts provide semantic predicates, rather than extra syntax

surjective? (fun : Function) : BOOLEAN = FORALL (y : Y) : EXISTS (x : X) : fun(x) = y;


Translation Templates Set insertion

friends’ = friends U {pers?} Function insertion

passport’ = passport {citizen? passid!}

…where the literal SAL would be very inefficient…

insert (set : Set, new : T) : Set = LAMBDA (elem : T) : elem = new OR set(elem);

insert (fun : Function, pair : XY) : Function = LAMBDA (x : X) : IF pair.1 = x

THEN pair.2 ELSE fun(x) ENDIF;Z2SAL identifies cases with singleton sets

… likewise for singleton set, function subtraction…


Evaluation Parser evaluation strategy

analyze diverse handwritten LaTeX-Z specs extend parser to recognise alternative LaTeX forms inspect SAL output, simulate SAL output

Math toolkit evaluation strategy create a CONTEXT for a given Z math data type simulate with many Z specs using this data type test using counter-theorems …see next slide…

Example findings can shrink state-space by clamping initial outputs semantic function properties that don’t apply to


Counter-TheoremLOCAL members : set{PERSON;} ! SetLOCAL rented : set{PERSON__X__TITLE;} ! SetLOCAL stockLevel : [TITLE -> NAT]INITIALIZATION [ …]…

th1 : THEOREM State |–G( set{PERSON__X__TITLE;} ! empty? (rented) );

Counter-theorem says: “the State module allows us to derive that the relation rented is always empty”, expected not to hold.

…all vars initialised to empty sets/relations/functions…


Proof Trace

Step Transition

Updates

0 Init members, rented, stockLevel =

1 AddTitle stockLevel(TITLE__2) = 3

2 AddMember PERSON__1 members

3 RentVideo (PERSON__1, TITLE__2) rented

After 3 steps, the counter-theorem is disproved; so the negationholds; i.e. it is possible for a person to rent at least one video


Performance Video shop example in the paper

3 base types: PERSON, TITLE, NAT 4 constructed types: pair, set, relation, function 3 local vars (of set, relation, function types) 8 input/output vars (of basic types) 5 ops (rentVideo, addTitle, delTitle, addMember,

copiesOut) SAL compilation and execution times

about 6-7 seconds to compile to BDDs, Bűchi automata counter-theorems disproved in 1-2 seconds 11,664 initial states 61,568,640 states after 5 steps


What Next? Sequences and bags

experimenting with SAL records for sequences extra field stores length of the sequence issues in preserving the order of a sequence

Porting to CZT MSc team project adapted CZT parser, AST used Visitor-pattern to generate similar SAL output poorly-documented AST is fairly hard to use

PhD project provable refinement of Z-specs by model-checking

SAL translation

ABZ Conference, London 2008

Thank You!

John Derrick, Siobhán North and Anthony Simons

Department of Computer ScienceUniversity of Sheffield

ABZ Conference, London 2008 Building a Model-Checker for Z John Derrick, Siobhán North and Anthony...

Documents

Transcript of ABZ Conference, London 2008 Building a Model-Checker for Z John Derrick, Siobhán North and Anthony...