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

2. Outline Basic notation of Z for specifying states and operations
Modularizing specification using schema calculus
Refining specifications

3. 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.

4. 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.

5. Characteristics of Z
Based on sets and predicates (Zermelo-Fraenkel 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

6. 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.

7. 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?

8. 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

9. 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

10. 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.

11. 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

12.  And  Notation
Syntactic sugar for introducing pre and post-state variables, e.g.,
BirthdayBook  [BirthdayBook; BirthdayBook’]
BirthdayBook  [BirthdayBook | ?] 12

13. Stating and Proving Properties
E.g., known’ = known  {name?} 13

14. More Example: FindBirthday
Use of  notation
Specify no state change 14

15. More Example: Remind Use of set comprehension notation
Selection (|) vs. collection ()
Q: What does it return? 15

16. 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

17. 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

18. 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

19. 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

20. Example 20

21. More Examples
Strengthening specifications by making partial operations total.
Q: How to make AddBirthday total? 21

22. Strengthening AddBirthday
REPORT ::= ok | already_known 22

23. Notice the framing constraint. Why?
RAddBirthday
Notice the framing constraint. Why? 23

24. Strengthening FindBirthday and Remind24

25. RFindBirthday and RRemind
REPORT ::= ok | already_known | not_known 25

26. 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

27. 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

28. Specification Refinement
Done in a single or multiple steps
Referred to as direct refinement and deferred refinement
deferred
refinement
data
operation
abstraction
relation
data
refinement
operation
refinement
direct
refinement
concrete data
concrete operation 28

29. 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

30. Concrete State Model, BirthdayBook1
Arrays modeled mathematically modeled as functions:
I.e., names[i] as names(i) and names[i] = v as 30

31. Abstraction Relation, Abs
Relation between abstract state space and concrete state space, e.g., BirthdayBook and BirthdayBook1
Q: Why abstract relation? 31

32. Operation Refinement, AddBirthday1
Manipulate names and dates arrays 32

33. 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
OpA
OpC
PreA
PostC
PreC 33

34. Correctness of AddBirthday1
PreA  PreC, i.e., 
Does this hold? Yes, because: 34

35. Correctness of AddBirthday1
PostC  PostA
Read the proof (p. 46)
Abs(PostC)  PostA 35

36. Implementation of AddBirthday1
void addBirthday(NAME name, DATE date) {
hwm++;
names[hwm] = name;
dates[hwm] = date; } 36

37. Refinement of FindBirthday37

38. Refinement of Remind 38

39. Refinement of InitBirthdayBook39

40. 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