comp 2600 formal methods for software engineeing
play

COMP 2600: Formal Methods for Software Engineeing Specification in - PowerPoint PPT Presentation

COMP 2600: Formal Methods for Software Engineeing Specification in Z: Introduction and Examples Dirk Pattinson Australian National University Semester 2, 2013 Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 1 / 24 System Specification in Z


  1. COMP 2600: Formal Methods for Software Engineeing Specification in Z: Introduction and Examples Dirk Pattinson Australian National University Semester 2, 2013 Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 1 / 24

  2. System Specification in Z Logic ◮ we have met first-order logic – speaks about properties of structures ◮ formal notion of proof – those statements which are true Set Theory ◮ basic mechanism to speak about, well, sets ◮ basic operations to construct sets: power sets, products etc. System Specification in Z Logic + Set Theory ◮ Set Theory speaks about types ◮ Logic speaks about properties ( Z is one particular specification formalism – there are others.) Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 2 / 24

  3. Specification and Proof Functional Programs ◮ techniques to show that a function has a desired property ◮ to verify that a program meets its specification Imperative Programs ◮ techniques to reason about state changes brought about by a program ◮ to verify that a program meets its specification. System Specification ◮ What on earth is a specification? ◮ How can we write down and combine specifications? Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 3 / 24

  4. Our View on System Specification Basic Tenet A Type is a Set. An operation is a function on sets. (Hardcore theorists may disagree. But we take this view here.) Specification is Abstract ◮ we don’t care about the how . Only the what matters. ◮ we don’t care about the internal structure of types. ◮ we don’t care about implementation. But we care a lot about the effects of operations! Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 4 / 24

  5. Why should we care at all? Specification as Contract ◮ typical requirement specifications are English prose. Often several hunderes of pages. ◮ Ambiguities abound! Specifications are a way to be precise . Specification as Language ◮ Software developmens typically involves large teams. Often hundereds of people. ◮ Interfaces matter! Specifications are a way to be precise . Specifications are Machine-Checkable ◮ formal language enables tool support ◮ idealy spans the whole software life cycle. (But of course, specification is not a magic bullet.) Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 5 / 24

  6. Introductory Example Spivak’s Birthday Book ◮ consists of a set of people – my friends ◮ every person has a birthday – which may be unknown. But I know the birthdays of all my friends! Data / Property Split Data: ◮ my friends: a subset of the set of people. ◮ the mapping: a partial function from people to birthdays Constraint. ◮ The birthdays of my friends are known. (This structure / property split is typical. We’ll see it all the time .) Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 6 / 24

  7. A more abstract view Static Aspects: Legal Data Data The basic containers that store information Constraint Containers may not be filled at random. Examples abound: ◮ lists that have to be sorted ◮ August 57 is an invalid date ◮ . . . I know the birthdays of my friends ;-) Dynamic Aspect: Operations on Legal Data Operations Described in terms of before / after relation Examples abound: ◮ after inserting a tuple into a database, we have it ◮ ordered insert into an ordered list produces an ordered list ◮ . . . looking up a birthday gives the correct date ;-) Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 7 / 24

  8. Birthday Book: Basic Types Basic Ingredients ◮ Person and Date. These are types (i.e. sets) and we don’t care about their structure. But we need to declare them. Like so: [Person, Date] ◮ types declared in this way are called given types . Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 8 / 24

  9. Birthday Book: Structure and Constraints People known to me ( P is powerset) ◮ every element of known is a subset of Person . ◮ so known : P Person – note the role of P as type constructor! Records of birthdays ( � → is partial functions) ◮ everybody has at most one birthday. ◮ so birthday : Person � → Date – note � → as type constructor! I know my friends’ birthdays ( dom is domain) ◮ every element of known is in the domain of birthday (and vice versa) ◮ so known = dom birthday – note dom as built-in function! Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 9 / 24

  10. Birthday Book as Z-Specification Graphical Notation [ Person , Date ] BirthdayBook known : P Person birthday : Person � → Date known = dom birthday Terminology ◮ The bit in the box is a Z-schema . It encapsulates the fundamental structure / property pattern. ◮ the bit above the horizontal line declares structure ◮ and the bit below is the constraint. ◮ The schema together with the declatration is an example of specification , also called Z-document . Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 10 / 24 (So far lots of overhead to express something very simple . . . )

  11. � Built in Type Constructors BirthdayBook known : P Person birthday : Person � → Date known = dom birthday Type Constructors Z has a number of built in type constructors, containing powerset → partial functions P → total functions ↔ relations integers seq sequences Z (we will see more later. I’ll try and provide a cheat sheet.) Types are expressions built from type constructors using given types. Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 11 / 24

  12. Built in Functions BirthdayBook known : P Person birthday : Person � → Date known = dom birthday Built in Functions/ Relations Z has a number of built in functions and relations, containing dom the domain of a function/relation ≤ less than ∈ set membership ♯ cardinality Every function/relation has a type which may be polymorphic. There are more builtins than shown above. Constraints are just formulae of predicate logic involving these. Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 12 / 24

  13. Operations: A simple Example AddBirthday inputs person ? and date ? outputs none action add the person/date pair to birthdays (By convention, input variables end in ? and output variables end in ! .) Precondition ◮ the new person should not be in the birthday book already. ◮ so person ? �∈ known . (before-values of schema variables have the declared name) Postcondition ◮ after the update, the new birthday is known ◮ so birthday ′ = birthday ∪ { person ? �→ date ? } (after-values of schema variables are primed, e.g. birthday ′ ) Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 13 / 24

  14. AddBirthday as a Schema Explicit Variant AddBirthday known : P Person ; known ′ : P Person → Date ; birthday ′ : Person � birthday : Person � → Date person ? : Person date ? : Date known = dom birthday ; known ′ = dom birthday ′ person ? �∈ known ; birthday ′ = birthday ∪ { person ? �→ date ? } This is overkill . . . but shows that operations are schemas ◮ the new schema incorporates two copies of BirthdayBook ◮ one for before (non-primed) and one for after (primed) ◮ augmented with input variables and just one formula! Surely we can do better . . . Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 14 / 24

  15. Operations on Schemas Priming a Schema If S is a schema, then S ′ is the schema where all variable names in declaration and constraints have been primed. Example BirthdayBook known : P Person birthday : Person � → Date ; known = dom birthday ; BirthdayBook ′ known ′ : P Person birthday ′ : Person � → Date known ′ = dom birthday ′ Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 15 / 24

  16. Operations that change state Delta, or before/after If S is a schema, then ∆ S is the union of S and S ′ (both of variables and constraints, separately). Example BirthdayBook known : P Person birthday : Person � → Date known = dom birthday ; ∆ BirthdayBook known : P Person ; known ′ : P Person → Date ; birthday ′ : Person � birthday : Person � → Date known = dom birthday ; known ′ = dom birthday ′ Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 16 / 24

  17. Schema Import Adding a Birthday, More Concisely AddBirthday ∆ BirthdayBook person ? : Person date ? : Date person ? �∈ known birthday ′ = birthday ∪ { person ? �→ date ? } Schema Import on the Sly ◮ we have included a schema as a declaration ◮ this adds all declared variables and constraints (Schema import as above is an important mechanism for defining schemas. It saves lots of writing!) Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 17 / 24

  18. Birthday Lookup As a schema FindBirthday ∆ BirthdayBook person ? : Person date ! : Date person ? ∈ known date ! = birthday ( person ?) (Note the convention of banged variables ( date ! ) designating output.) Question Is this a good specification, at least for the case where name ? ∈ known ? Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 18 / 24

  19. Birthday Book from Hell Is this a good specification? FindBirthday ∆ BirthdayBook person ? : Person date ! : Date perosn ? ∈ known date ! = birthday ( person ?) birthday ′ = ∅ ; known ′ = ∅ Strenghening of Schemas Every implementation that is consistent with the augmented schema is consistent with the original schema (without the red bits). ◮ this is trivial – we just ask that more assertions are satisfied ◮ but it shows that there’s something we haven’t thought about . . . Dirk Pattinson (ANU) COMP 2600 Semester 2, 2013 19 / 24

Recommend


More recommend