1 / 20

2.4 The Z Notation

2.4 The Z Notation. [Reference: M. Spivey: The Z Notation, Prentice Hall]. Formal Languages. A language is formal if its syntax and semantics are formally defined (mathematically) (e.g. Petri Nets, Finite Automata, Predicate Logic)

neila
Download Presentation

2.4 The Z Notation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 2.4 The Z Notation [Reference: M. Spivey: The Z Notation, Prentice Hall]

  2. Formal Languages A language is formal if its syntax and semantics are formally defined (mathematically) (e.g. Petri Nets, Finite Automata, Predicate Logic) Formal languages allow for the design, the development, the verification, the testing and the maintenance of a system: remove ambiguities and introduce precision, structure information at an appropriate abstraction level. support the verification of design properties, are supported by tools and systems. Using mathematics (and formal methods) may appear to be expensive, but in the long run it pays off (and how!). The Z Notation

  3. Properties of Z • Is a very expressive formal language. • Based on first-order logic with equality and typed set-theory. • Has a mathematical toolkit: a library of mathematical definitions and abstract data-types (sets, lists, bags, …). • Supports the structured modeling of a system, both static and dynamic: • modeling/specification of data of the system, • functional description of the system (state transitions). • Is supported by several tools and systems. The Z Notation

  4. Z and other Formal Languages/Methods • A number of successfully employed Formal Methods are based on first order logic with type-theory, e.g. • VDM („Vienna Development Method“, 80‘s), • B (applied extensively in France) • Other formal languages: • Equational logic or Horn logic (in algebraic specifications), • Higher-order logic (HOL). • Z: • Applied successfully since 1989 (Oxford University Computing Laboratory), e.g. British government requires Z-specifications for security-critical systems. • Is an ISO standard. The Z Notation

  5. The Birthday Book Example • A system which records people’s birthdays • System issues a reminder when the birthday comes around The Z Notation

  6. The Birthday Book Example - Schema Schema name BirthdayBook known: P NAME birthday: NAME→DATE Variable declaration | Invariants (variable relationships) known = dom birthday One instance satisfying the invariant: known = {John, Mike, Susan} birthday= {John → 25. Mar, Mike → 20. Dec, Susan → 20. Dec.} The Z Notation

  7. Z syntax overview A specification in Z is presented as a collection of schemas Each schema consists of: Schema name Variable declaration (static description part) Identification of variables Invariants (dynamic part) Definition of operations Input/Output relation State changes Z uses only rigourous mathematical notations from (typed) set theory and first order logic The Z Notation

  8. The Birthday Book Example – Details to BirthdayBook BirthdayBook known: P NAME birthday: NAME→DATE | known = dom birthday • P: power set, →: partial function • dom domain • The set known is the same as the domain of the function birthday – the set of names to which it can be validly applied. • Facts about dom (examples of the laws obeyed by mathematical data types): • dom(f  g) = (dom f )  (dom g) • dom {a → b} = {a} | The Z Notation

  9. The Birthday Book Example - Operation AddBirthday ∆BirthdayBook name? : NAME date? : DATE name?  known birthday‘ = birthday  {name? → date?} • ∆  introduces a schema describing a change • Introduces variables: known, birthday (state before change) • known‘, birthday‘ (state after the change) • ?  Input variables • !  output variables • Constraint: All variables with the same name have the same type The Z Notation

  10. A simple proof of a system property • Expectation: set of known names will be augmented with the new name Property: known‘ = known  {name?} • Proof: known‘ = dom birthday‘ [invariant after] = dom (birthday  {name? → date?} [spec. of AddBirthday] = dom birthday  dom {name? → date?} [fact about ‘dom’] = dom birthday  {name?}[fact about ‘dom’] = known  {name?} □ [invariant before] • Proof based on mathematical laws and axioms The Z Notation

  11. Find operation FindBirthday BirthdayBook name? : NAME date! : DATE name?  known date! = birthday (name?) The Z Notation Finds birthday (date) for a given name Ξ  introduces a schema without a change Constraint: all variables with the same name are of the same type

  12. Remind operation Remind BirthdayBook today? : DATE cards! : PNAME cards! ={ n : known  birthday (n) = today? } The Z Notation Finds people who have birthday on a given date (to send them birthday cards) No precondition!

  13. Initial state InitBirthdayBook BirthdayBook known =  The Z Notation

  14. Strengthen the specification (1/2) The Z Notation • What is the problem with this spec? • Assumes everything works according to plan • No provision for mistake • What happens if user attempts to add a birthday for someone already known to the system? • Or if we try to find a birthday of someone not known to the system? • Should the system ignore such behavior? • Should the system break down by displaying rubbish? • Does this mean we should write a brand new spec?

  15. Strengthen the specification (2/2) The Z Notation • How to strengthen the specification? • Combine separate schema • Add an extra output (or report) to each operation on the system • Outputs can be: • Ok • Already-known • Not-known

  16. Success Operation Success result!: REPORT result! = ok The Z Notation • To combine schema use conjunction or disjunction: • AddBirthday  Success is a schema which produces an entry in the birthday book (for correct inputs) and reports success • The result is an operation which, for correct input, both acts as described by AddBirthday and produces the result ok.

  17. AlreadyKnown Operation AlreadyKnown  BirthdayBook name? : NAME result! : REPORT name?  known result! = already_known ^ The Z Notation Define a schema for each possible error in the input RAddBirthday = (AddBirthday  Success) v AlreadyKnown

  18. A robust version of AddBirthday RAddBirthday ∆BirthdayBook name? : NAME date? : DATE result! : REPORT (name?  known  birthday‘ = birthday  {name? → date?}  result! = ok) (name?  known  birthday‘ = birthday  result! = already_known) The Z Notation

  19. A robust version of FindBirthday NotKnown BirthdayBook name? : NAME result! : REPORT name?  known result! = not_known ^ The Z Notation RFindBirthday = (FindBirthday  Success) v NotKnown

  20. A robust version of FindBirthday • It is not enforced that output values are set • cf. http://spivey.oriel.ox.ac.uk/mike/zrm/zrm.pdf page 20 • RFindBirthday checks whether a given name is present, returning a report and, if possible, the date itself The Z Notation

More Related