Formal Methods through an Introduction to Z

1. Formal Methods Formal Methods through an Introduction to Z A notation for formal specification of systems and a formal tool for precise design of software Z (pronounced Zed), uses mostly familiar mathematical notation and properties to precisely specify the system under description

2. Formal Methods Formal Methods (in the plural), is a collective term applied to mathematical methods and techniques used to specify, design and verify systems. Their use has been prevalent in software and complex electronic hardware development. A formal method (in the singular), is a coherent set of such mathematical techniques and notations used as a methodology to specify, design and/or verify a system. Zed is one such formal method.

3. Formal Methods Formal Methods come under multiple scopes and uses: Level 0: Formal Specification. This is when mathematical rigor is used to only specify the requirements of a system Level 1: Formal Specification and Derivation. This is when mathematical rigor is used to not only specify a system but also used that specification to derive mathematically, that is, translate the specification to a program Level 2: Fully Formal. This is when the derivation (as per a level 1 method) is proven for correctness against the original specification.

4. Formal Methods Formal methods may be grouped into three general categories: Axiomatic Methods: where the system is specified in terms of state changes defined in terms of pre- and post-conditions, variants and invariants. Propositional and predicate logic are an important feature of such methods. Z belongs to this category. Operational Methods: where the operation of the system is formally specified as a sequence of operations. Denotational Methods: where the system is specified using domain theory.

5. Z Specification As all other formal methods, Z uses the powerful notion of abstraction. Z specifies a system using: Mathematically defined data types and Decompositions called Schemas

6. Z Specification A schema describes both the static and the dynamic aspects of a system. Dynamic State Transitions Events (operations) Transformations (relationship of input to output) Static Individual states Invariants maintained

7. Z Specification The Z language also allows us to combine and relate separately defined schemas in a mathematically logical fashion. Z also permits a progression of decomposition. We can construct a progression of related specifications that eventually arrives at the API or the equivalent of the API of an implementation façade.

8. Z Specification To learn how to speak any language, we first need to learn some vocabulary and some simple rules of grammar. Both the vocabulary and the grammar of Z should be largely familiar to you. Over the next few pages, we will cover some of these (without necessarily going into the details and subtleties of their definitions and uses). Some of these symbols and concepts are unique to Z but most are in general use elsewhere in mathematics. In this treatment we use the ObjectZ dialect of Z, one that allows for the notion of class, inheritance and a few other OO “nice to have”s.

9. Z Specification Sets and Types [X] Type X data type ::=m1|m2|…..|mn X = = Y Y stands for X Z Set of Integers N Set of natural numbers (0) N1 Set of positive integers (1) t S t is an element of set S t S t is not an element of set S S T S is contained in T

10. Z Specification ST S is strictly contained in T (ST) S T S is not contained in T S T Set of intersection of S and T S T Set of the union of S and T PS Powerset of S: the set of all subsets of S FS Finite powerset of S: the set of all finite subsets of S SS The distributed intersection of all sets in SS SS The distributed union of all sets in SS  Or { } The null or empty set

11. Z Specification S\T Difference: elements that are in S but not in T #S Size or cardinality: number of elements in S {D|p.t} Set of t’s such that given declaration D, P holds disjoint Sq the sets in the sequence sq are disjoint sq partition S the sets in sq partition the set S Logic true, false logical constants P not P

12. Z Specification • PQ conjunction: “P and Q” • PQ disjunction: “P or Q” • PQ implication: “If P then Q” • PQ equivalence: : “If P then Q and if Q then P” • t=r term t is equal to term r • tr term t is not equal to term r, that is: (t=r) • Predicates: • x:T.P for all x of type T, P holds x: T.P there exists an x of type T, for which P holds

13. Z Specification Relations: XY the set of ordered pairs of X’s and Y’s XY the set of relations from X to Y; = =P(XY) x R y x is related to y by R; (x,y) R dom R the domain of relation R; = ={x:X | (x:X . x R y) . x} ran R the range of a relation R; = ={y:Y | (x:X . x R y) . y} SR the relation R is domain restricted to S RS the relation R is range restricted to S R~ the inverse of R

14. Z Specification Functions: X  Y the set of partial functions from X to Y = ={f:XY | (x:X | x dom f. (1y:Y.x f y))} X Y the set of total functions from X to Y = ={f: X  Y| dom f = X.f} fx or f(x) function f is applied to x

15. Z Specification Sequences: seq X the set of sequences with elements drawn from X = ={S:N X | dom S= 1…#S} seq1 X set of non-empty sequences of X iseq X set of non-duplicate sequences of X #S the length of sequence X < > the empty sequence <x1,…xn> the sequence of x1 through to xn

16. Z Specification <x1,…xn>^<y1,…yn> concatenation = = <x1,…xn,y1,…yn> head S = = S 1 last S = = S #S tail S^S1 = = S frontS^<x> = = S where <x>= =last S rev S the sequence S in reverse order

17. Z Specification Schemas: Class Schema: Class Name[generic parameter] inherited classes type definitions constant definitions state schema initial state schema operation schemas history invariant

18. Z Specification State Schema items: seq T #items max predicate declaration

19. Z Specification Initial State Schema: INIT items = = < > Operational schemas Operation name declarations predicates

20. Z Specification Schema decorations: | name: T name is a constant of type T item ?: T item is an input or accepts input item !: T item is an output or holds an output item’ new state of item after change (item) the schema effects change on item (item) item is left unchanged by schema Ξ

21. Z Specification A simple case example will help bring these concepts together We will develop a specification for a very simple library management system. In this system, each book will be assigned to a shelf location, designated by a number. A shelf location of course may house many books.

22. A Library System We introduce the types we need: [BOOK], [SHELF] We do not for the moment specify what exact type the book variable would be. The book may be identified by an alphanumeric string, such as by the book title; alphabetic, such as by author’s name; numeric, such as by ISBN, etc. It does not matter for the moment. The shelf we decide is simply numbered from 1 to whatever. [SHELF], SHELF ::=N1

23. A Library System So now we can think of an ordered pair of [BOOK,SHELF] which is generic in with respect to BOOK and specified wrt SHELF. This renders the whole ordered pair structure generic, in that it would have to be set to a type (book has to be set to a type) before it can be instantiated. Now we can create a simple class, let us call it Library. We do so by creating a class schema: Library onshelf : P BOOK location: BOOK SHELF onshelf =dom location

24. A Library System Note that we have not placed a limit on the number of records that may be stored nor the order in which they are to be stored. Because location is in a functional relationship with onshelf, there will always be only one location for a book but many books may be placed on the same shelf. But what can this simple system do? How about adding a book/location pair?

25. A Library System AddtoLibrary  Library abook?: BOOK aspot? : SHELF abook? onshelf location’ = location {abook? aspot?}  We have read two variables abook and aspot and

26. A Library System A bit of proof (you probably don’t need to do this but it is a good simple demonstration of the proof capability of Z): Prove that onshelf’ = onshelf  {abook?} Proof: onshelf’ = dom location’[by invariant after] = dom (location {abook?  aspot?} [Spec of AddtoLibrary] = dom location dom{abook?  aspot?}[fact about dom] = dom location {abook?}[fact about functions] = onshelf  {abook?} [invariant before}

27. A Library System Let’s add another operation: Add an operation that given the name of a book, it finds its shelf FindLocation ΞLibrary abook?: BOOK aspot! : SHELF abook? onshelf aspot! = location(abook?)

28. A Library System The new symbol Ξ indicates that the operation FindLocation has induced no change of state. It is in this sense mathematically equivalent to: (onshelf’ = onshelf) (location’ = location) Which due to rules of precedence of symbols may be written as: (onshelf’ = onshelf) (location’ = location)

29. A Library System Another operation may be to find the contents of a shelf. That is, given the number of the shelf, find out what books are on that shelf. ShelfContents ΞLibrary ashelf?: SHELF books! : BOOK ashelf? dom location books! = {n: onshelf | location(n) = ashelf?}