Formal modeling with Z

1Spring 2005Specification and Analysis of Information Systems

Eran Toch

http://www.technion.ac.il/~erant

Winter 2007

Session 7: Formal Specification with Zed

Analysis and Specification of Information Systems

2

Agenda

• Introduction

• Hello World

• Schema Specification

• Schema Operations

Intro | Hello World | Schema | Operations

3

Motivation for Formal Specification

: ShooppingCart

addProduct (p)

customer

• Was the product really added?

• Were there any side affects?

• What was the state of the shopping cart before and after the operation?


4

Motivation – cont’d

• What is the type of cart? What is the type of p?

• Is “cart := cart + p” a legal operation?

• Do we cover all possibilities? What if p is null?

• Why are these questions interesting at all?

S addProduct(p) | cart := cart + p

/ cart := Empty


5

Motivation: Ariane 5

• A European satellite launch rocket

• Development time: 10 years

• Development costing €7 billion

• Cargo + rocket costing €500 million


6

Ariane 5 First launch

A data conversion from 64-bit floating point to 16-bit signed integer value had failed.


7

What are Formal Specification Methods?

1. Mathematical notation

12345

cedba

2. Well-defined data structures:• Sets• Relations• Functions

3. Clear Behavior specification, based on logical expressions

Pre / post


8

Reasoning

• Examples:– Prove that all actions will result in a discrete set of states.– Prove that some system properties are bounded. – Prove that error states are unreachable.– Prove that certain states are reachable.

Reasoning over System Properties


9

Using Zed in System Development

Formal Specification

Design Implementation

Z Schemas

Design Documents

(UML)Testable System

Verification

Validation

10

Advantages of Formal Specification

Withoutfromal

specification

With formalspecification

Specification

Design andImplementationValidation


11

Zed Specification Language

• Based on typed set theory

• The most widely-used formal specification language

• Built upon schemas– Basic building blocks– Allow modularity– Easier to understand by using

graphical presentation

• pronounced “Zed” ZIntro | Hello World | Schema | Operations

12

Agenda

• Introduction

• Hello World



13

Container

contents: Ncapacity: N

contents capacity

Schema name

Schema signature

Schema predicates

Z Schema

• Schema predicates are always true

• Predicates can refer only to elements in the signature


14

Type definitions

• Built-in types:– Z - Integers (…,-3,-2,-1,0,1,2,3,…) – N == {n : Z | n 0} (positive integers)

– N1 == {n : Z | n > 0} (positive, non-zero, integers)

– R – Real numbers– Char - characters

• Types may be defined by enumeration– Sem_model_types = { relation, entity, attribute }

• Some entities may be ‘given’ and defined later– [NAME, DATE, PERSON]

• Schemas can be used as types


15

An indicator specification

Indicator

light : { off, on }reading: Ndanger_level: N

light = on reading danger_level


16

Storage tank specification

Storage_tank

ContainerIndicator

reading = contentscapacity = 5000danger_level = 50


17

Specifying Complex Operations

Normal operation Exceptional 1

Exceptional 2

Combined operation


18

A partial spec. of a fill operation

Fill_OK

Storage_tankamount?: N

contents + amount? capacitycontents’ = contents + amount?

Delta (): the operation changes the state of the attribute

? represents an input

Dash (N’), represents the value after an operation


19

Storage tank fill operation

OverFill

Storage_tankamount?: Nr!: seq CHAR

capacity < contents + amount?r! = “Insufficient tank capacity – Fill canceled”

Xi () means that the defined operation does not change the values of state variables

! represents an output


20

The Fill Operation

Fill

Fill_OK OverFill

Operations may be specified incrementally as separate schema then the schema combined to produce the complete specification


21

Agenda

• Introduction

• Hello World



22

Data dictionary specification

• A data dictionary is part of a CASE system and is used to keep track of system names

• Data dictionary structure– Item name– Description– Type. Assume in these examples that the allowed types are

those used in E/R models– Creation date


23

Example: Data dictionary entry

DataDictionaryEntry

name: NAMEtype: sem_model_typescreation_date: DATEdescription : seq Char

#description 2000

[NAME, DATE]

sem_model_types = { relation, entity, attribute }


24

Data dictionary modeling

• A data dictionary may be thought of as a mapping from a name (the key) to a value (the description in the dictionary)

• Operations are– Add. Makes a new entry in the dictionary or

replaces an existing entry– Lookup. Given a name, returns the description.– Delete. Deletes an entry from the dictionary– Replace. Replaces the information associated with an entry


25

Basic Data Representation

DataDictionary

ddict: NAME DataDictionaryEntry


Names Entries

26

Function Summary

NameSymboldom fOne-to-one?

ran f

Total function= X Y

Partial function X Y

Injection (total)= XYes Y

Surjection (total)= X= Y

Bijection= XYes= Y


27

Data dictionary initialization

Init_DataDictionary

DataDictionary

ddict’ =


28

Add and lookup operations

Add_OK

DataDictionaryentry?: DataDictionaryEntry

entry?.name dom ddictddict’ = ddict { entry?.name entry? }

Lookup_OK

DataDictionaryname?: NAMEentry!: DataDictionaryEntry

name? dom ddictentry! = ddict(name?)

Accessing sub elements


29

Add and lookup operations

Add_Error

DataDictionaryentry?: DataDictionaryEntryerror!: seq char

entry?.name dom ddicterror! = “Name already in dictionary”

Lookup_Error

DataDictionaryname?: NAMEerror!: seq char

name? dom ddicterror! = “Name not in dictionary”


30

Function over-riding operator

• ReplaceEntry uses the function overriding operator (written ). This adds a new entry or replaces and existing entry.

– phone = { Ian 3390, Ray 3392, Steve 3427}– The domain of phone is {Ian, Ray, Steve} and the range is

{3390, 3392, 3427}.– newphone = {Steve 3386, Ron 3427}– phone newphone = { Ian 3390, Ray 3392, Steve

3386, Ron 3427}


31

Replace operation

Replace_OK

DataDictionaryentry?: DataDictionaryEntry

entry?.name dom ddictddict’ = ddict { entry?.name entry? }


32

Deleting an entry

• Uses the domain subtraction operator (written ) which, given a name, removes that name from the domain of the function

– phone = { Ian 3390, Ray 3392, Steve 3427}– {Ian} phone = {Ray 3392, Steve 3427}


33

Delete entry

Delete_OK

DataDictionaryname?: NAME

name? dom ddictddict’ = { name? } ddict


34

Specifying ordered collections

• Specification using sets does not allow ordering to be specified

• Sequences are used for specifying ordered collections

• A sequence is a function mapping consecutive integers to associated values


35

The Extract operation

Extract

DataDictionaryrep!: seq DataDictionaryEntryin_type?: Sem_model_types

n dom ddict: ddict(n).type = in_type? ddict(n) rng rep!1 i #rep!: rep!(i).type = in_type?1 i #rep!: rep!(i) rng ddicti,jdom rep!: (i < j) rep!(i).name <NAME rep!(j).name


36

Extract predicate

• For all entries in the data dictionary whose type is in_type?, there is an entry in the output sequence

• The type of all members of the output sequence is in_type?

• All members of the output sequence are members of the range of ddict

• The output sequence is ordered by entry name


37

Agenda

• Introduction

• Hello World



38

Schema Operators: , , , ,

• For any of the binary types to be allowed, its two arguments must have type compatible signatures.

• I.e., the types of arguments with the same name must be identical– X Y – conjunction of X,Y predicates– X Y – disjunction of X,Y predicates (good for

normal/exception situations) X – negation of a schema– XY – if X predicates are true, then Y predicates are true– X Y - iff


39

\ - Hiding

• The hiding operation S \ (x1,…,xn) removes from the schema S the components x1,…,xn explicitly listed

• These components must exist

• Useful for situations in which we want to discuss partial elements of the schema– X \ (limit) Y


40

- projection

• S T hides all the components of S except those that are also components of T.

• The schemas S and T must be type compatible,

• But T may have components that are not shared by S

• The signature of the result is the same as the signature of T


41

Composition

• If Op1 and Op2 are schemas describing two operations, then Op1,

• Then Op1 ; Op2 is a schema which describes their sequential composition

• Composition is legal only if:– Each dashed component in Op1 must match an undashed

component with the same name– Each elements with the same name must have the same type


42

Composition - Example

What would Inc ; Inc do?


43

pre

• The “pre” operator allows us to discuss schemas before they were executed

• If S is a schema, and x1’,…,xn’ are the components of S that have the ‘ decoration y1!,…,yn! are the components that have the decoration !,

• then the schema “pre S” is the result of hiding these variables of S, so that,– Pre S = S \ (x1’,…,xn’, y1!,…,yn!)


44

Example: State Machine

• A state machine has:– States– An initial state

• From where the machine start from

– Final states:• If the machine reaches the

final state, it halts and “accept”

– Given a state and an event, a transition will perform an optional action and move to the destination state

• An action is performed by outputting the name of the action

S-1

S-2

E1 | a1

E0

E2 | a1

E3 | a2

Example

Education

Formal modeling with Z