Z Specifications-Software Engineering-Lecture 12 Slides-Computer Science, Slides of Software Engineering

Download Z Specifications-Software Engineering-Lecture 12 Slides-Computer Science and more Slides Software Engineering in PDF only on Docsity!

LECTURE 12: Z SPECIFICATIONS &

THE SCHEMA CALCULUS

Software Engineering

1 The Truth About Schema Inclusion

• We saw last week how, a schema could be included by just listing its name in the declarations part of a schema. We now look at what this actually means.
• Suppose we had the following definition: S 1 v 1 : T 1 v 2 : T 2 P 1 P 2

and later on S 2 S 1 (* schema inclusion *) v 3 : T 3 P 3

• We now need to introduce schema decoration.
• Suppose we had the following declaration:

S 3 S′ 1 P 4

then this declaration would have been equivalent to S 3 v′ 1 : T 1 v′ 2 : T 2 P 1 P 2

  

with all references to v 1 , v 2 changed to v′ 1 , v′ 2. P 4

• Remember that the decorated form of a variable means “the variable after the operation has been performed”; the undecorated version means “the variable before the operation has been performed”.

• Let’s now consider the ∆ notation.
• Suppose we had:

S 4 ∆S 1 P 5

• This would have been equivalent to

S 4 S 1 (* include S 1 ) S′ 1 ( include S′ 1 *) P 5

2 The Schema Calculus

• One of the nice things about Z is that it allows us some sort of modular construction; we can build things in little pieces and put them together to make big pieces.
• The way we do this is by using the schema calculus.
• First we need to introduce horizontal form schemas (as opposed to the vertical form schemas we have been looking at so far).

• Definition: The following vertical-form schema S Declarations P 1 P 2 · · · Pn

may be defined in the following horizontal form S ̂= [Declarations | P 1 ; P 2 ; · · · Pn]

• The symbol ̂= is for schema definition; it may be read ‘is defined to be’.
• Using ̂=, we can make one schema an alias for another: NewPhoneBook =̂ PhoneBooks
• On the RHS of the ̂= symbol can be any valid schema calculus expression.

• EXAMPLE: Specification of a robust ‘Find’ operation (i.e. one whose behaviour is defined even when the input name is not known).
• First define a schema which assigns the string ‘okay’ to a variable. This schema will be used to signify that an operation has been successful. Success rep! : REPORT rep! = ‘okay′

• The robust ’Find’ operation is

DoFindOp ̂ = (Find ∧ Success) ∨ NotKnown

the full expansion of which is: DoFindOp known : IP NAME known′^ : IP NAME tel : NAME → 7 PHONE tel′^ : NAME → 7 PHONE name? : PHONE phone! : PHONE rep! : REPORT ((dom tel = known ∧ dom tel′^ = known ∧ known′^ = known ∧ tel′^ = tel ∧ name? ∈ known ∧ phone! = tel(name?)) ∧ rep! = ‘okay′) ∨ ( dom tel = known ∧ dom tel′^ = known ∧ known′^ = known ∧ tel′^ = tel ∧ name? 6 ∈ known ∧ rep! = ‘name not known′)

• After logical simplification, the expanded schema becomes: DoFindOp known : IP NAME known′^ : IP NAME tel : NAME → 7 PHONE tel′^ : NAME → 7 PHONE name? : PHONE phone! : PHONE rep! : REPORT dom tel = known ∧ known′^ = known ∧ tel′^ = tel ∧ ((name? ∈ known ∧ phone! = tel(name?) ∧ rep! = ‘okay′) ∨ ( name? 6 ∈ known ∧ rep! = ‘name not known′))