1. ECSE 6780- Software Engineering 1I - 1 - HO 3 © HY 2012 Lecture 3 Formal Methods through an Introduction to Z Formal Methods 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. ECSE 6780- Software Engineering 1I - 2 - HO 3 © HY 2012 Lecture 3 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. ECSE 6780- Software Engineering 1I - 3 - HO 3 © HY 2012 Lecture 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. ECSE 6780- Software Engineering 1I - 4 - HO 3 © HY 2012 Lecture 3 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. ECSE 6780- Software Engineering 1I - 5 - HO 3 © HY 2012 Lecture 3 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. ECSE 6780- Software Engineering 1I - 6 - HO 3 © HY 2012 Lecture 3 Z Specification A schema describes both the static and the dynamic aspects of a system. Static Individual states Invariants maintained Dynamic State Transitions Events (operations) Transformations (relationship of input to output)

7. ECSE 6780- Software Engineering 1I - 7 - HO 3 © HY 2012 Lecture 3 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. ECSE 6780- Software Engineering 1I - 8 - HO 3 © HY 2012 Lecture 3 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. ECSE 6780- Software Engineering 1I - 9 - HO 3 © HY 2012 Lecture 3 Sets and Types [X]Type Xdata type ::=m 1 |m 2 |…..|m n X = = Y Y stands for X Z Set of Integers N Set of natural numbers (  0) N 1Set of positive integers (  1) t  St is an element of set S t  St is not an element of set S S  TS is contained in T Z Specification

10. ECSE 6780- Software Engineering 1I - 10 - HO 3 © HY 2012 Lecture 3 S  TS is strictly contained in T (S  T) S  TS is not contained in T S  TSet of intersection of S and T S  TSet of the union of S and T P SPowerset of S: the set of all subsets of S F SFinite powerset of S: the set of all finite subsets of S  SSThe distributed intersection of all sets in SS  SSThe distributed union of all sets in SS  Or { }The null or empty set Z Specification

11. ECSE 6780- Software Engineering 1I - 11 - HO 3 © HY 2012 Lecture 3 S\TDifference: elements that are in S but not in T #SSize or cardinality: number of elements in S {D|p.t}Set of t’s such that given declaration D, P holds disjoint Sqthe sets in the sequence sq are disjoint sq partition S the sets in sq partition the set S Logic true, falselogical constants  Pnot P Z Specification

12. ECSE 6780- Software Engineering 1I - 12 - HO 3 © HY 2012 Lecture 3 P  Qconjunction: “P and Q” P  Qdisjunction: “P or Q” P  Qimplication: “If P then Q” P  Qequivalence: : “If P then Q and if Q then P” t=rterm t is equal to term r t  rterm t is not equal to term r, that is:  (t=r) Predicates:  x:T.Pfor all x of type T, P holds  x: T.Pthere exists an x of type T, for which P holds Z Specification

13. ECSE 6780- Software Engineering 1I - 13 - HO 3 © HY 2012 Lecture 3 Relations: X  Ythe set of ordered pairs of X’s and Y’s X  Ythe set of relations from X to Y; = = P (X  Y) x R yx is related to y by R; (x,y)  R dom Rthe domain of relation R; = ={x:X | (  x:X. x R y). x} ran Rthe range of a relation R; = ={y:Y | (  x:X. x R y). y} S  Rthe relation R is domain restricted to S R  Sthe relation R is range restricted to S R ~ the inverse of R Z Specification

14. ECSE 6780- Software Engineering 1I - 14 - HO 3 © HY 2012 Lecture 3 Functions: X  Ythe set of partial functions from X to Y = ={f:X  Y | (  x:X | x  dom f. (  1 y:Y.x f y))} X  Ythe 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 Z Specification

15. ECSE 6780- Software Engineering 1I - 15 - HO 3 © HY 2012 Lecture 3 Sequences: seq Xthe set of sequences with elements drawn from X = ={S:N  X | dom S= 1…#S} seq 1 Xset of non-empty sequences of X iseq Xset of non-duplicate sequences of X #Sthe length of sequence X the empty sequence the sequence of x 1 through to x n Z Specification

16. ECSE 6780- Software Engineering 1I - 16 - HO 3 © HY 2012 Lecture 3 ^ concatenation = = head S= = S 1 last S= = S #S tail S^S1= = S frontS^ = = S where = =last S rev Sthe sequence S in reverse order Z Specification

17. ECSE 6780- Software Engineering 1I - 17 - HO 3 © HY 2012 Lecture 3 Schemas: Class Schema: Class Name[generic parameter] inherited classes type definitions constant definitions state schema initial state schema operation schemas history invariant Z Specification

18. ECSE 6780- Software Engineering 1I - 18 - HO 3 © HY 2012 Lecture 3 State Schema items: seq T #items  max declaration predicate Z Specification

19. ECSE 6780- Software Engineering 1I - 19 - HO 3 © HY 2012 Lecture 3 items = = Initial State Schema: INIT Operational schemas declarations predicates Operation name Z Specification

20. ECSE 6780- Software Engineering 1I - 20 - HO 3 © HY 2012 Lecture 3 Schema decorations: | name: Tname is a constant of type T item ?: Titem is an input or accepts input item !: Titem 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 Z Specification Ξ

21. ECSE 6780- Software Engineering 1I - 21 - HO 3 © HY 2012 Lecture 3 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. ECSE 6780- Software Engineering 1I - 22 - HO 3 © HY 2012 Lecture 3 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 ::= N 1

23. ECSE 6780- Software Engineering 1I - 23 - HO 3 © HY 2012 Lecture 3 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. ECSE 6780- Software Engineering 1I - 24 - HO 3 © HY 2012 Lecture 3 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. ECSE 6780- Software Engineering 1I - 25 - HO 3 © HY 2012 Lecture 3 A Library System  Library abook?  onshelf location’ = location  {abook? aspot?} abook?: BOOK aspot? : SHELF AddtoLibrary  We have read two variables abook and aspot and

26. ECSE 6780- Software Engineering 1I - 26 - HO 3 © HY 2012 Lecture 3 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. ECSE 6780- Software Engineering 1I - 27 - HO 3 © HY 2012 Lecture 3 A Library System Let’s add another operation: Add an operation that given the name of a book, it finds its shelf Ξ Library abook?  onshelf aspot! = location(abook?) abook?: BOOK aspot! : SHELF FindLocation

28. ECSE 6780- Software Engineering 1I - 28 - HO 3 © HY 2012 Lecture 3 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. ECSE 6780- Software Engineering 1I - 29 - HO 3 © HY 2012 Lecture 3 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. Ξ Library ashelf?  dom location books! = {n: onshelf | location(n) = ashelf?} ashelf?: SHELF books! : BOOK ShelfContents