Introduction to the Z Formal

Specifications Language

Slide 1
Z as a specification language
 A formal specification notation based on set
theory
 Has been developed at the Programming
Research Group at the Oxford University
Computing Laboratory since the late 1970s.
 Probably now the most widely-used specification
language
 An international standard for the Z notation is
being developed under the guidance of ISO.

Slide 2
Z as a specification language
 Specification are built from components called
schemas.
 Schemas are specification building blocks
 Graphical presentation of schemas make Z
specifications easier to understand
 Mathematical notation of schemas allows the
building of formal completeness and consistency
proofs to validate the specifications

Slide 3
Z schemas
 Introduce specification entities and defines
invariant predicates over these entities
 A predicate is a Boolean expression
 Some predicates can have side-effects that change
the state of the entities involved
 Schemas can be included in other schemas and
may act as type definitions
 Names are local to schemas
 In many respects, Z schemas are akin to objects.

Slide 4
Problem: storage tank monitoring
 A storage tank is monitored by a control system.
 The system consists of a container which holds
something and a indicator panel which shows the
current fill level and the danger level.
 If the storage tank goes over the danger level, a
warning light must be lighted on the indicator
panel.
 Fill operations must be specified as to ensure the
tank to be refilled but never overfilled.

Slide 5
A container specification
Schema variable declarations
Schema name
Schema predicates

Container
contents: N
capacity: N

contents <= capacity

 [contents: N; capacity: N | contents <= capacity]

Container 

Slide 6
The Z Notation
 A schema includes
 A name identifying the schema
 A signature introducing entities and their types
 A predicate part defining relationships between the entities in
the signature by stating a logical expression which must always
be true (an invariant).

Slide 7
An indicator specification

Indicator

light: {off, on}

reading: N
dangerLevel: N

light = on  reading >= dangerLevel

 If the storage tank goes over the danger level, a warning

light must be lighted on the indicator panel.

Slide 8
Specification of a storage tank
StorageTank

Container
Indicator

reading = contents
capacity = 250000
danger_level = 245000

Slide 9
Specification of a storage tank
StorageTank

contents: N
capacity: N
reading: N
dangerLevel: N
light: {off, on}
contents <= capacity
light = on  reading >= dangerLevel
reading = contents
capacity = 250000
danger_level = 245000

Slide 10
A partial spec. of a fill operation

FillOK
StorageTank
amount?: N

contents + amount? <= capacity

contents’
= contents + amount?

Slide 11
Z conventions
 A schema name prefixed by the Greek letter
Delta () means that the operation changes some
or all of the state variables introduced in that
schema
 A variable name decorated with a ? represents an
input
 A variable name decorated with a quote mark
(N’) represents the value of the state variable N
after an operation

Slide 12
Z conventions
 A schema name prefixed by the Greek letter Xi
() means that the defined operation does not
change the values of state variables
 A variable name decorated with a ! represents an
output

Slide 13
A partial spec. of a fill operation

FillOK
StorageTank
amount?: N

contents + amount? <= capacity

contents’
= contents + amount?

Slide 14
Storage tank fill operation
OverFill

StorageTank
amount?: N
r!:seq CHAR

capacity < contents + amount?

r! =“Insufficient tank capacity – Fill cancelled”

Fill

FillOK  OverFill

Slide 15
Full problem specification
 [content: N; capacity: N | content <= capacity]
Container 
 [light:{off,on};reading: N; dangerLevel: N
Indicator 
| light = on reading >= dangerLevel]
 [Container; Indicator | reading=content;
StorageTank 
capacity=250000; dangerLevel = 245000]
FillOK  [StorageTank; amount?: N |
contents + amount? <= capacity;
content’ = content + amount?
 [StorageTank; amount?: N; r!: seq CHAR |
OverFill 
capacity < contents + amount?;
r! =“Insufficient tank capacity – Fill cancelled”
 [FillOK  OverFill]
Fill 
Slide 16
Operation specification
 Define the “normal” operation as a schema
 Define schemas for exceptional situations
 Operations may be specified incrementally as
separate schema then the schema combined to
produce the complete specification
 Combine all schemas using the disjunction (or)
operator (written )

Slide 17
Z Notations
 A schema includes
 A name identifying the schema
 A signature introducing entities and their types
 A predicate part defining invariants over these entities
 Conventions
 Marks before a schema,

Delta ( means changes

Xi means no changes
 Marks after a state variable,

? means input

! means output

‘ represents the value of the variable after an operation

Slide 18
Z symbols
Sets:
S:PX S is a set of Xs
S:FX S is a finite set of Xs
xS x is a member of S
xS x is not a member of S
ST S is a subset of T
ST union of S and T
ST intersection of S and T
S\T difference of S and T
 empty set
N set of natural numbers : {0,1,2, …}
Z set of integer numbers : {...-2,-1,0,1,2, …}
max(S) maximum value of the (non-empty) set S
min(S) minimum value of the (non-empty) set S
#S cardinality of S
Slide 19
Z symbols
Functions:
f : X Y f is a partial function from X to Y
f : XY f is a total function from X to Y
dom f domain of f
ran f range of f
f : {x1  y1, x2  y2} extensional function definition
f  {x1  y1} extensional addition of mappings

Logic:
P negation
PQ conjunction
PQ disjunction
PQ equivalence
PQ implication

Slide 20
Key points
 Z specifications are made up of a mathematical model of
the system state and a definition of operations on that
state
 A Z specification is presented as a number of
schemas
 Schemas may be combined to make new schemas
 Operations are specified by defining their effect on the
system state.
 Operations may be specified incrementally. Different
schemas can be combined to complete the specification.
 The notation used is very cryptic, though great effort is
made toward understandability.

Slide 21
Z Specification Examples

Slide 22
 Example 1
Specifications for a
Data Dictionary

Slide 23
Data dictionary specification
 A data dictionary is used as an example. This 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 semantic data models
 Creation date
 Operations for lookup, addition, replacing, and deletion of
entries are to be formally specified.
 An operation for extracting and sorting all entity, relation
or attribute entries has to be specified.

Slide 24
Given sets
 Z does not require everything to be defined at
specification time
 Some entities may be ‘given’ and defined later
 The first stage in the specification process is to
introduce these given sets
 [NAME, DATE]
 We don’t care about these representations at this stage

Slide 25
Type definitions
 There are a number of built-in types (such as
INTEGER) in Z
 Other types may be defined by enumeration
 SemModelTypes = { relation, entity, attribute }
 Schemas may also be used for type definition.
The predicates serve as constraints on the type

Slide 26
Specification using functions
 A function is a mapping from an input value to an
output value
 SmallSquare = {11, 24, 39, 416, 525, 636, 749}
 The domain of a function is the set of inputs over
which the function has a defined result
 dom SmallSquare = {1, 2, 3, 4, 5, 6, 7 }
 The range of a function is the set of results which
the function can produce
 rng SmallSquare = {1, 4, 9, 16, 25, 36, 49 }

Slide 27
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
 Extract. Extract and sort by name all entries having a specified
type

Slide 28
Data dictionary entry
DataDictionaryEntry

entr y: NAME
desc: seq char
type: Sem_model_types
creationDate: DATE

#description <= 2000

Slide 29
Data dictionary as a function
DataDictionary
DataDictionaryEntry
ddict: NAME  {DataDictionaryEntry}

InitDataDictionary

DataDictionary

ddict’ = Ø

Slide 30
Add operation
AddSuccess

DataDictionary
name?: NAME
entry?: DataDictionaryEntry

name? dom ddict

ddict’ = ddict 
{name?  entry?}

AddFailure

DataDictionary
name?: NAME
error!: seq char
name?  dom ddict
error! = “Name already in dictionary”

Slide 31
Lookup operation
LookupFound

DataDictionar y
name?: NAME
entry!: DataDictionaryEntry

name?  dom ddict

entry! = ddict (name?)

LookupNotFound

DataDictionary
name?: NAME
error!:seq char
name? dom ddict
error! = “Name not in dictionary”

Slide 32
Function over-riding operator
 The replacing entry function 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}

Slide 33
Replace operation

Replace

DataDictionary
name?: NAME
entry?: DataDictionaryEntry

ddict’ = ddict  {name? entry}

Slide 34
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}

Slide 35
Delete entry
DeleteFound

DataDictionary
name?: NAME

name?  dom ddict

ddict’ = {name?} ddict

DeleteNotFound
DataDictionary
name?: NAME
error!: seq char
name?  dom ddict
error = “entity specified for deletion does not exist in the dictionary”

Slide 36
Extracting entities of specific type
Extract
DataDictionary
inType? : SemModelTypes
return!: seq {DataDictionaryEntry}
1
n : dom ddict  ddict(n).type = inType?  ddict(n)  return!
2
i : 1 <= i <= #return!  return!(i).type = inType?
3
i : 1 <= i <= #return!  return!(i)  rng ddict
4
i,j : i,j  return!  (i<j)  return!.name(i) <NAME return!.name(j)

1. For all entries in ddict whose type is inType, there is an entry in

return. This does not ensure that all elements of return are elements of
ddict, hence the necessity of the next two constraints.
2. The type of all members of return is inType.
3. All members of return are members of the range of ddict.
4. return is sorted by its name attribute
Slide 37
Add, Lookup and Delete
Add

AddSuccess  AddFailure

Lookup

LookupFound  LookupNotFound

Delete

DeleteFound  DeleteNotFound

Slide 38
Data dictionary specification

TheDataDictionary

DataDictionary
InitDataDictionary
Add
Lookup
Delete
Replace
Extract

Slide 39
 Example 2

Modular Specifications for a

Birthday Book

Slide 40
Birthday book specification
 A system which records people’s birthdays
 Operations include addition and query of
birthdays
 The system must be able to give a list of
birthdays occuring on any given day

Slide 41
Z schemas
 Z schemas represent both the static and dynamic
aspects of a system
 Static
 the states it can occupy
 the invariant relationships (constraints) that are maintained on
the state as its values are changed
 Dynamic
 the operations that are possible on the system state
 the relationships between operations inputs and outputs
 the changes of states that happen during the application of
operations

Slide 42
Data dictionary modeling
 The database is modeled as a function mapping
persons’ names to their birthday dates
 Operations are
 Add. Makes a new entry {name  birthday} in the birthday
book
 Find. Given a name, returns the birthday
 Remind. Returns a list of the persons having their birthday on a
given date

Slide 43
Birthday book
BirthdayBook

known : P NAME
birthday : NAME  DATE

known = dom birthday

 birthday: is a function which, when applied to a name,

gives the birthday associated with it
 known: the set of names with birthdays recorded
 Derived component of the state.
 Might not be part of the implementation.
 Gives clarity to the specifications.

Slide 44
Birthday book
 Only one constraint is implied:
 As birthday is defined as a function, each person can only have
one birthday
 Does not make any unnecessary assumptions on
implementation constraints
 maximum number of records
 definition of NAME and DATE
 ordering of records

Slide 45
Intitial system state
InitBirthdayBook

BirthdayBook
known = 

 known = dom(birthday), hence if known is

empty, birthday is empty.

Slide 46
Add operation
AddBirthday

Birthday Book
name? : NAME
date? : DATE

name?  known
birthday’ = birthday  {name?  date?}

 The schema does not say what happens if the

precondition is not met
 Complete specifications should take into account all state
cases that can arise
 Will be settled later in a modular way

Slide 47
Add operation
 How does this ensure that:
 known’ = known  {name?}
 A proof of it can be derived using the system invariant
properties and the inherent properties of dom
known’ = dom birthday’ [spec of BirthdayBook]
= dom(birthday  {name?  date?})[spec. of AddBirthday]
= dom birthday  dom {name?  date?} [dom distributivity]
= dom birthday  {name?} [dom definition]
= known  {name?} [spec. of BirthdayBook]
 The possibility to build such proofs is a major advantage
of formal specification techniques

Slide 48
Find operation
FindBirthday

BirthdayBook
name? : NAME
date! : DATE

name?  known
date! = birthday(name?)

 Including BirthdayBook is equivalent to include

predicates known’ = known and birthday’ = birthday
 What happens if the name looked for is not in the
database? Again, this schema does not provide a complete
specification.

Slide 49
Remind operation
Remind

BirthdayBook
today? : DATE
cards! : P NAME

cards! = {n : known | birthday(n) = today?}

 Specifies a definition of the output of the operation with

regard with the system state
 Does not specify how the search is implemented
 Exactly specifies the problem to be solved, while leaving
maximal freedom to designers and programmers

Slide 50
Specification completeness
 The specification does not take into account special state
cases leading to errors
 Adding a new record for someone already in the system
 Trying to find a person unknown to the system
 Implementing such incomplete specifications will
probably lead to a broken system
 Designers/programmers will have to invent their own solutions to the
problem, which might not be agreed by the client
 System might lose some data
 System might behave correctly, but without giving warnings to the
user on faulty inputs, or give meaningful messages on empty output

Slide 51
Specification completeness
 Solution:
 Develop new schemas to enable the covering of special cases in
all operations
 Combine these new schemas with the existing ones to form a
robust version of the system specification
 Advantages:
 Provides an incremental and modular description of the
specifications
 Specifications are easier to understand

Slide 52
Specification completeness
 Add an extra output result! of type REPORT to each operation
on the system that returns:
 ok if the operation is successful
 alreadyKnown or notKnown appropriately if an error happens
 The type REPORT is defined as a free definition

REPORT = {ok,alreadyKnown,notKnown}

 Three schemas are defined to provide a definition of the

states applying to the output of the appropriate REPORT
value

Slide 53
Specification completeness
Success
result! : REPORT
result! = ok

AlreadyKnown
BirthdayBook
today? : DATE
result! : REPORT
name?  known
result! = alreadyKnown
NotKnown
BirthdayBook
today? : DATE
result! : REPORT
name?  known
result! = notKnown
Slide 54
Complete addition operation
RAddBirthday

(AddBirthday  Success)  AlreadyKnown

RAddBirthday
BirthdayBook
name? : NAME
date? : DATE
result! : REPORT
name?  known 
birthday’ = birthday  {name?  date?} 
result! = ok

name?  known 
birthday’ = birthday 
result! = alreadyKnown

Slide 55
Complete find operation
RFindBirthday

(FindBirthday  Success)  NotKnown

RFindBirthday
BirthdayBook
name? : NAME
date! : DATE
result! : REPORT

name?  known 
date! = birthday(name?) 
result! = ok

name?  known 
birthday’ = birthday 
result! = notKnown
Slide 56
Complete remind operation
RRemind

Remind  Success

RRemind
BirthdayBook
today? : DATE
cards! : P NAME
result! : REPORT
name?  known
cards! = {n : known | birthday(n) = today?}
result! = ok

Slide 57
Key Points
 Z specifications provide a mathematical model of
a system encompassing both static (state) and
dynamic (operations) aspects
 Specifications completeness is a key quality to
achieve
 Completeness can be achieved incrementally
using modular schema composition
 Incremental composition leads to more
manageable and understandable specifications

Slide 58
Z specification examples (part II)

Slide 59
Example: DATE

Slide 60
Format of DATE
 Date could have different formats:
 November 7,2001
 11/07/2001
 7-11-2001
 …
 Assume
 using this format: dd mm yyyy,
with which today is 7 11 2001
 do not care about zeroes

Slide 61
Initial suggestion
DATE
day: 1..31
month:1..12
year: 1900.. 9999

 Problems: invalid dates caused by


different days in different months

leap year

year overflow

Slide 62
Definition of leap_year

leap_year: P (N)

year:1990..9999  leap_year(year) 
(year mod 4 = 0)  (year mod 100 0  year mod 400 = 0)

Slide 63
DATE
DATE
day: 1..31
month:1..12
year: 1900.. 9999

month {2,4,6,9,11} 
month  {4,6,9,11}  day  30 
month = 2   leap_year(year)  day  28 
month = 2  leap_year(year)  day  29

Slide 64
Example: Radiation Safety
interlock system

Slide 65
An Interlock System
 A safety interlock system is designed to prevent people
from being exposed to radiation.
 An interlock system:
 Ensures that all appropriate radiation areas are clear of personnel prior
to the use of radiation sources
 Prevents people from entering areas where radiation levels exceed
certain limits
 Ensures that anyone entering an area where there is significant
radiation is exposed to a minimal dose of radiation.
 Necessary to control access not only to the directly
radiated areas, but also to adjoining areas due to leakage.

Slide 66
Radiation Safety Interlock System
 Building a hypothetical system
 Be able to determine whether rooms are clear of personnel
before activating the radiation source
 Prevent activation if they are not clear of personnel
 Assume there is some way of determining when people enter or
leave a room, such as using “magnetic badges”.

Slide 67
Plan of building

RS
1

Slide 68
Radiation Safety Interlock System
 The radiation source goes through four phases:
 Switched off:

RS is switched off

People are allowed to access any room
 Powered up:

RS is powered up

Room 1 contains no people. and the door must be locked
 Discharged

A beam is discharged into room 2

Rooms 1 and 2 must contain no people

Door to room 2 locked
 Full activated

Rooms 1 and 2 and the adjoining room 3 must contain no people.

Slide 69
Types definition
 status of the radiation source
 STATUS ::= SwitchOff | PowerUp | Discharge |Activated
 status of the doors
 DOORS ::= Open | Locked
 number of rooms
num_of_rooms: N1
num_of_rooms = 3
1. Declared external to any schema
2. Global to any part of the specification declared after it
3. N1: positive natural number ( >0 )

Slide 70
The state of the system
State
num_in_room: seq1 N
doors: seq1 DOORS
status_of_system: STATUS
#num_in_room = num_of_rooms
#doors = num_of_rooms

1. num_in_room: the number of people in each room

2. doors: the number of doors associated with each room,
either they are all open, or they are all locked.
3. seq1: non-empty sequence

Slide 71
Initial State
 Initial state
 All the rooms are empty
 RS is switched off
 All doors are open

Init
State

ran num_in_room = {0}

ran doors = {Open}
status_of_system = SwitchOff

Slide 72
Enter a room
 If a person enters a room, the number of people in that room is
incremented.
 A person can only enter a room if the relevant doors are open.

Enter_room
 State
room_no?: N

doors(room_no?) = Open
num_in_room = num_in_room  {room_no?  num_in_room(room_no?) + 1}
doors = doors
status_of_system  = status_of_system

 The status of radiation source and doors are unaffected.

Slide 73
Leave a room
 If a person leaves a room, the number of people in that room is
decremented.

Leave_room
 State
room_no?: N

num_in_room = num_in_room  {room_no?  num_in_room(room_no?) - 1}

doors = doors
status_of_system = status_of_system

Slide 74
Operation of Changing the status
 Phase 1: the RS goes from “switched off” to “powered
up”
 Room 1 must be clear of people
 Its door is locked
Phase 1
State

status_of_system = SwitchOff  num_in_room(1) = 0

doors = doors  { 1  Locked}
status_of_system = PowerUp

Slide 75
Operation of Changing the status
 Phase2: the RS goes from “powered up” to “discharge”
 Room 2 must be clear of personnel
 The appropriate door(s) locked.

Phase 2
State

status_of_system = PowerUp  num_in_room(2) = 0

doors = doors  { 2  Locked}
status_of_system = Discharged

• What about room 1?

Slide 76
Operation of Changing the status
 Phase3: the RS goes from “discharge” to “full activated”
 Room 3 must be clear of personnel
 The appropriate door(s) locked.
Phase 3
State

status_of_system = Discharged  num_in_room(3) = 0

doors = doors  { 3  Locked}
status_of_system = Activated

Slide 77
Operation of Changing the status
 On switching off the system, we can make all rooms available.

Deactive
State

dom doors = dom doors  ran doors = {Open}

status_of_system = SwitchOff

Slide 78
Exceptions
 What is the response of the system if we attempt
to power up while someone is in room 1?
 What happens if someone enters a room that is
supposed to be locked?
 …

Slide 79
Writing Specifications
 Start from informal descriptions
 Define the required types
 Define the state variables
 Define the relationships
 Looking for verbs in the descriptions associated with the objects
 If possible, build ER diagrams
 Different levels of abstraction
 Define the initial state
 Identify the operations, define a reasonable system
 Consider exception
 Combine
Slide 80