The Z Specification Language
Based on
J. M. Spivey. An Introduction to Z and formal specifications,
Software Engineering Journal, 4(1):40-50, January, 1989.
1
Outline
• Basic notation of Z for specifying states and operations
• Modularizing specification using schema calculus
• Refining specifications
2
Formal Specifications
• Use mathematical notation to describe properties of a
system.
• Describe “what” the system must do without saying
“how” it is to be done.
• Serve as a single, reliable reference point for those who
investigate the customer’s needs, programmers, testers
and those who writes instruction manuals for the system.
• Is independent of the program code.
3
Underlying Ideas of Z (“Zed”)
• Can use mathematical data types, e.g.,
numbers and sets, to model the data in a
system
• Can decompose a specification into small
pieces called schemas, the main
ingredient in Z.
• Can use schemas to describe both static
and dynamic aspects of a system.
4
Characteristics of Z
• Based on sets and predicates (ZermeloFraenkel set theory)
• Semi-graphical or visual notation (e.g.,
open boxes and x? and y!)
• Schema for both data and operations
• Schema calculus for modularizing
specifications
• Informal texts for explaining formal ones
• ISO standard, ISO/IEC 13568:2002
5
Static vs. Dynamic Aspects
• Static aspects
– The states that a system can occupy.
– The invariant relationships that are maintained as the
system moves from state to state.
• Dynamic aspects
– The operations that are possible.
– The relationship between their inputs and outputs.
– The changes of state that happen.
6
How to Specify Static Aspects?
• Use schemas---math in a box with a name attached---to
describe the state space, i.e., state
components/variables along with constraints.
• Example: BirthdayBook for recording people’s birthdays
– known: set of names with birthdays recorded
– birthday: function from names to birthdays
– Q: What does the constraint/invariant say?
7
State Schema: More Examples
• Simple text editor with limited memory
• Editor state modeled by two state variables, the texts to
the left and right of the cursor
8
Example: Birthday Book
• One possible state
• Stated properties
–
–
–
–
–
No limit on the number of birthdays recorded
No premature decision about the format of names and dates
Q: How many birthday can a person have?
Q: Does everyone have a birthday?
Q: Can two persons share the same birthday?
9
Exercise
• Write a Z specification to describe the state
space of the following system.
A teacher wants to keep a register of students in her
class, and to record which of them have completed
their homework.
10
How to Specify Dynamic Aspects?
• Use schemas to describe operations
– Syntactic: name, input and output, state components
– Semantic/behavior: input/output relationship, state change/side effect
• Example: AddBirthday
–
–
–
–
Q: What’re inputs, outputs, and the state components referred to?
Q: Is it total or partial?
Q: What’s the pre and post-conditions?
Q: What’s the meaning (semantic domain) of operation schemas?
11
 And  Notation
• Syntactic sugar for introducing pre and poststate variables, e.g.,
– BirthdayBook  [BirthdayBook; BirthdayBook’]
– BirthdayBook  [BirthdayBook | ?]
12
Stating and Proving Properties
• E.g., known’ = known  {name?}
13
More Example: FindBirthday
• Use of  notation
• Specify no state change
14
More Example: Remind
• Use of set comprehension notation
– Selection (|) vs. collection ()
• Q: What does it return?
15
More Example: InitBirthdayBook
• Describes the initial state of the system
• By convention, use Init as prefix
• Q: Initially, any maplet in the birthday function?
16
Exercise
•
Write a Z specification to describe the operations of the following system.
A teacher wants to keep a register of students in her class, and to record which
of them have completed their homework.
– An operation to enroll a new student
– An operation to record that a student (already enrolled in the class) has finished
the homework
– An operation to enquire whether a student (who must be enrolled) has finished
the homework (answer in the set {yes, no}).
ANSWER ::= yes | no
17
Schema Calculus
• Modularize specifications by building large schemas
from smaller ones, e.g.,
– Separating normal operations from error handling
– Separating access restrictions from functional behaviors
– Promoting and framing operations, e.g., reading named a file
from reading a file
– …
=> Separation of concerns
• How?
Provide operations for combining schemas, e.g.,
S1  S2
where S1 and S2 are schemas
18
Schema Calculus
• Schema operator for every logical connective
and quantifier
• Conjunction and disjunction are most useful
• Merge declarations and combine predicates,
S1 [D1 | C1]
S2 [D2 | C2]
S1  S2  [D1; D2 | C1  C2]
19
Example
20
More Examples
• Strengthening specifications by making
partial operations total.
• Q: How to make AddBirthday total?
21
Strengthening AddBirthday
REPORT ::= ok | already_known
22
RAddBirthday
Notice the
framing
constraint. Why?
23
Strengthening FindBirthday and
Remind
24
RFindBirthday and RRemind
REPORT ::= ok | already_known | not_known
25
Exercise
• Specify a robust version of the class register system.
A teacher wants to keep a register of students in her class, and to
record which of them have completed their homework.
– An operation to enroll a new student
– An operation to record that a student (already enrolled in the class) has
finished the homework
– An operation to enquire whether a student (who must be enrolled) has
finished the homework (answer in the set {yes, no}).
ANSWER ::= yes | no
26
Refinement---From Specification to
Designs and Implementation
• Previously, Z to specify a software module
• Now, Z to document the design of a programs
• Key idea: data refinement
– Describe concrete data structures (<-> abstract data
in specification)
– Derive descriptions of operations in terms of concrete
data structures
– Often data refinement leads to operation refinement
or algorithm development
27
Specification Refinement
• Done in a single or multiple steps
• Referred to as direct refinement and deferred refinement
data
abstraction
relation
operation
data
refinement
concrete data
operation
refinement
deferred
refinement
direct
refinement
concrete operation
28
Implementation of Birthday Book
•
•
•
•
Expressive clarity in abstract data structure
Efficiency and representation in concrete data structure
One possible representation
NAME[] names;
DATE[] dates;
Q: Any better representation in Java?
29
Concrete State Model, BirthdayBook1
•
Arrays modeled mathematically modeled as functions:
•
I.e., names[i] as names(i) andnames[i] = v as
30
Abstraction Relation, Abs
•
•
Relation between abstract state space and concrete
state space, e.g., BirthdayBook and BirthdayBook1
Q: Why abstract relation?
31
Operation Refinement, AddBirthday1
• Manipulate names and dates arrays
32
Correctness of Operation Refinement
•
•
Whenever AddBirthday is legal in some abstract state,
the implementation AddBirthday1 is legal in any
corresponding concrete state, i.e., PreA  PreC
The final state which results from AddBirthday1
represents an abstract state which AddBirthday could
produce, i.e., PostC  PostA
PreA
PreC
OpA
OpC
PostC
PostC
33
Correctness of AddBirthday1
•
•
PreA  PreC, i.e.,

Does this hold? Yes, because:
34
Correctness of AddBirthday1
•
•
PostC  PostA
Read the proof (p. 46)
Abs(PostC)  PostA
35
Implementation of AddBirthday1
void addBirthday(NAME name, DATE date) {
hwm++;
names[hwm] = name;
dates[hwm] = date;
}
36
Refinement of FindBirthday
37
Refinement of Remind
38
Refinement of InitBirthdayBook
39
Exercise
• Implement the class register system specified earlier.
Use two arrays.
NAME[] names;
YesOrNo[] finished;
where YesOrNo is an enum consisting of yes and no.
Document:
– the concrete state space
– the abstraction relation
– the concrete operations
40