Transcript zed
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
specifications for modularizing • 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.,
S 1
S 2
where
S 1
and
S 2
are schemas 18
Schema Calculus
• Schema operator for every logical connective and quantifier • Conjunction and disjunction are most useful • Merge declarations and combine predicates,
S 1
[
D 1
|
C 1
]
S 2 S 1
[
D 2 S 2
|
C 2
] [
D 1
;
D 2
|
C 1
C 2
] 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
abstraction relation
data
data refinement
operation
operation refinement
concrete data concrete operation
deferred refinement direct refinement
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., Pre A Pre C The final state which results from AddBirthday1 represents an abstract state which AddBirthday could produce, i.e., Post C Post A Op A Pre A Post C Op C Pre C Post C 33
Correctness of
AddBirthday1
• • Pre A Pre C, i.e., Does this hold? Yes, because: 34
Correctness of
AddBirthday1
• • Post C Post A Read the proof (p. 46) Abs(Post C ) Post A 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