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.

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

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.

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.

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.

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?

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.

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

Notice the framing constraint. Why? 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 deferred refinement data operation abstraction relation data refinement operation refinement direct refinement concrete data 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) 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 OpA OpC PreA PostC PreC 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