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 (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

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 post-state 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

23

Notice the framing

constraint. Why?

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

28

concrete data concrete operation

data operation

datarefinement

operationrefinement

deferredrefinement

directrefinement

abstractionrelation

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) and names[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

33

OpA

OpC

PreA

PostCPreC

PostC

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