1. 1 Requirements Specification and Verification Using Z A. Rasoolzadegan July, 2009 AUT CEIT

2. 2 Z (pronounced `zed') - Introduction Named after Zermelo-Fränkel set theory A formal specification language based on set theory and first order predicate logic Makes it easier to write mathematical description of complex dynamic systems such as software, Originally proposed by Abrial in 1977 with the help of Steve Schuman and Bertrand Meyer Developed further at the Programming Research Group at the Oxford University Computing Laboratory (OUCL) and elsewhere since the late 1970s,

3. 3 Introduction (Cont.) Mathematical Language  set theory standard set operators, set comprehensions, Cartesian products, and power sets.  mathematical logic first order predicate calculus Schemas language  used to describe the state of a system, the ways in which that state may change system properties

4. 4 Introduction (Cont.) We may refine a specification, yielding another description that is closer to executable code, We may reason about these specifications using the proof techniques of mathematical logic, Z is not intended for the description of non- functional properties neither for timed & concurrent behavior Various tools for formatting, type-checking and aiding proofs in Z are available, The ISO completed a Z standardization effort in 2002

5. 5 The importance of proof At the specification stage:  help us to understand the requirements upon a system, and  can assist us in identifying any hidden assumptions At the design stage:  can show us not only that a design is correct,  but also why it is correct. At the implementation stage:  help us to ensure that a piece of code behaves according to the specification A significant contribution to quality improvement

6. 6 The importance of proof (Cont.) A specification without proofs  is untested: it may be inconsistent; it may describe properties that were not intended, or omit those that were; it may make inappropriate assumptions.

7. 7 The logical language of Z  Propositional Logic  Predicate Logic

8. 8 Propositional Logic Propositional connectives

9. 9 Propositional Logic (Cont.) These inference rules form part of the natural deduction system that we use to conduct our proofs: modus ponens rule

10. 10 Propositional Logic (Cont.)

11. 11 Exp. Disjunction is commutative: Proof:

12. 12 Proof:

13. 13 Proof:

14. 14 Proof:

15. 15 The logical language of Z  Propositional Logic  Predicate Logic

16. 16 Predicate Logic Is a powerful technique to expressing the universal and existential statements (quantified predicates)

17. 17 Predicate Logic (Cont.) A special case:

18. 18 Predicate Logic (Cont.) A special case:

19. 19 to denote the unique object x from a such that p

20. 20 Set Theory Mathematical objects are often seen as well-defined collections of other objects The Z notation is based upon set theory Specifications in Z find their meanings as operations upon sets All the set theory we require for specification, refinement, and proof:  the notions of set membership, extension, Comprehension, the power set and Cartesian product constructors. the set of finite subsets of a

21. 21 Set Theory (Cont.) Some axioms of Zermelo-Fraenkel set theory: This inference rule is supported by two axioms of Zermelo-Fraenkel (specification & replacement):

22. 22 Set Theory (Cont.)

23. 23 Exp. Proof:

24. 24 Object Definition in Z In the Z notation, there are several ways of defining an object:  declarations,  abbreviations,  axioms,  free types and  schemas.

25. 25 Object Definition in Z - Declarations The simplest way to define an object If the object is a given set, or basic type:  introduces a new basic type called Type If the object is a variable:  introduces a new variable x, drawn from the set A  If this set is not Z, it must be defined elsewhere in the specification

26. 26 Object Definition in Z - Abbreviations Introduces a new name for term: Generic abbreviations:

27. 27 Object Definition in Z - Axiomatic definitions where the predicate expresses the constraints upon the object or objects introduced in the declaration. Axiomatic definition of the set of natural numbers:

28. 28 Object Definition in Z - Axiomatic definitions Generic definitions: Exp. Generic definition to define the subset symbol:

29. 29 Proof:

30. 30 Relations In a formal specification, it is often necessary to describe relationships between objects Binary Relations: Elements of relations: If R is a relation of type, and A is any subset of X, then denotes the domain restriction of R to A:

31. 31 Relations (Cont.) If B is any subset of Y, then denotes the range restriction of R to B: domain subtraction of A from R range subtraction of B from R:

32. 32 Relations (Cont.) If R is a relation of type, and A is any subset of X, then denotes the relational image of A under R: Relational inverse: Relational composition:

33. 33 Functions Partial functions: Total functions:

34. 34 Functions (Cont.)

35. 35 Functions (Cont.) Function description using Lambda notation:

36. 36 Functions on relations

37. 37 Functions (Cont.) Set of all finite functions from A to B: Overriding :

38. 38 Properties of functions

39. 39 Functions (Cont.) Size/Cardinality:

40. 40 Sequences If X is a set, then the set of all finite sequences of objects from X is defined by the following abbreviation:

41. 41 Sequences (Cont.) Filter :

42. 42 Functions on sequences Using recursion principle: Exp.

43. 43 Proof:

44. 44 Construct a proof that filter is distributive using structural induction: Inductive hypothesis: Induction: Structural induction

45. 45 Proof Lemma1 & Lemma2 using the following rules: Lemma1 Lemma2

46. 46 Object Definition in Z In the Z notation, there are several ways of defining an object: declarations, abbreviations, axioms,  free types and  schemas.

47. 47 Free Types Exp. 1: Exp. 2: Exp. 3: recursive type definition

48. 48 Free Types (Cont.) axiomatic definition : constructor functions constants Any subset of T that contains all of the constants and is closed under the constructors must be the whole of T. A set S is closed under d and E if the image of E.S = T. under d is within S itself.

49. 49 Object Definition in Z In the Z notation, there are several ways of defining an object: declarations, abbreviations, axioms, free types and  schemas.

50. 50 Schemas Language In the Z notation there are two languages:  The mathematical language: is used to describe various aspects of a design:  objects, and the relationships between them  The schema language: is used to structure and compose descriptions:  collating pieces of information,  encapsulating them, and  naming them for re-use. Abstract data type: a collection of variables, and a list of operations that may change their values. We encapsulate these variables within a schema,

51. 51 Schemas Exp:

52. 52 Schemas (Cont.) In our mathematical language, there are four ways of introducing a type:  as a given set,  as a free type,  as a power set, or  as a Cartesian product. If we require a composite type, one with a variety of different components, then the schema language offers a useful alternative: S: SchemaOne S.a S.c

53. 53 Schemas (Cont.) Schemas as declarations

54. 54 Schemas (Cont.) Characteristic binding :

55. 55 Schemas (Cont.) Call : free If we choose Z to be the actual parameter, we obtain a schema that is equivalent to SchemaTwo Generic schemas:

56. 56 Schema Operators Conjunction & Disjunction allows us to specify different aspects of a specification separately, and then combine them to form a complete description

57. 57 Schema Operators (Cont.) Exp:

58. 58 Schema Operators (Cont.)

59. 59 Decoration To describe an operation upon the state, we use two copies of State:  One representing the state before the operation;  the other representing the state afterwards. Decorate the components of the second schema, adding a single prime to each name:

60. 60 Decoration (Cont.)

61. 61 Schema Operators (Cont.) Quantification: existential quantification hiding universal quantification

62. 62 Promotion / framing

63. 63 Predicate part of AnswerGlobal Predicate part of

64. 64 Promotion / framing (Cont.)

65. 65 Free promotion A promotion is said to be free if and only if the promotion schema satisfies An example of a free promotion:

66. 66 A promotion that is not free is said to be constrained. An example of a constrained promotion:

67. 67 Proof opportunities arising from A.D.T. The construction of an abstract data type presents two important proof opportunities:  a demonstration that the various requirements upon the data type are consistent and not contradictory.  a demonstration that each operation is never applied outside its domain, in a situation for which the results of the operation are not defined. In the Z notation, we use the language of schemas to construct the data type To show ,we have only to show that the constraint part of the state schema is satisfiable.  This is usually achieved by proving an initialisation theorem: we show that an initial state, at least, exists. To show ,we must investigate their preconditions.

68. 68 The initialisation theorem The state of the system is modeled as an object of schema type, the predicate part of which represented a state invariant:  a list of requirements that should be true in any valid state If the predicate part includes a contradiction, then the data type description is vacuous:  it is impossible to fulfil the requirements, therefore no state exists. To fulfil the requirements, it is enough to establish that at least one state exists.

69. 69 1. The initialisation theorem (Cont.)

70. 70 1. The initialisation theorem (Cont.) The initialisation theorem is therefore Now the initialisation theorem should be proved

71. 71 1. The initialisation theorem (Cont.) Proof:

72. 72 2. Precondition investigation

73. 73

74. 74 2. Precondition investigation (Cont.)

75. 75 2. Precondition investigation (Cont.) Exp:

76. 76 2. Precondition investigation (Cont.)

77. 77 2. Precondition investigation (Cont.)

78. 78 2. Precondition investigation (Cont.)

79. 79 2. Precondition investigation (Cont.)

80. 80 2. Precondition investigation (Cont.) If Promote is free then:

81. 81 Case Study: A File System We show how the schema notation can be used to specify a simple file system:  Representing concrete data structures and a set of operations upon them,  We show also how the preconditions of the various operations can be calculated,  How the description of a single file can be promoted to an indexed component of a file system

82. 82 A programming interface To set down exactly what it is that we intend to model:  a list of operations upon the file system,  complete with a description of their intended affects. We may divide the operations into two groups:  those that affect the data within a single file,  those that affect the file system as a whole.

83. 83 A programming interface (Cont.) At the file level, there are four operations:  read: used to read a piece of data from a file;  write: used to write a piece of data to a file; overwrite an existing part of the file  add: used to add a new piece of data to a file; extend the file to accommodate the new data  delete: used to delete a piece of data from a file.

84. 84 A programming interface (Cont.) At the file system level, there are four operations:  create: used to create a new file;  destroy: used to destroy an existing file;  open: used to make a file available for reading and writing of data;  close: used to make a file unavailable for reading and writing.

85. 85 Operations upon files storage keysdata elements

86. 86 Operations upon files (Cont.)

87. 87 Operations upon files (Cont.)

88. 88 A more complete description A failed operation upon the file state will always produce a report as output:

89. 89 A more complete description (Cont.)

90. 90 A more complete description (Cont.) A successful operation will always produce a report of the same value:

91. 91 A more complete description (Cont.)

92. 92 A file system A file system contains a number of files indexed using a set of names.

93. 93 A file system (Cont.) We may choose to promote the operations defined above.  The local state is described by File,  The global state is described by System,  and the promotion is characterized by the schema Promote:

94. 94 A file system (Cont.)

95. 95 A file system (Cont.) We define four operations using this promotion:

96. 96

97. 97

98. 98 A file system (Cont.) We will now extend our free type of report messages to take account of the errors that may occur in file access and file management operations:

99. 99

100. 100 A file system (Cont.)

101. 101 The final formal description of the file system.

102. 102 Formal Analysis 1. Initialisation theorem:  To check that our state invariant contains no contradictions there exists a binding of file and open which satisfies the constraint part of SystemInit

103. 103 Initialisation theorem Proof:

104. 104 Initialisation theorem (Cont.) Since we are using File as a type, we should also prove that: Proof:

105. 105 Formal Analysis (Cont.) 2. Precondition investigation: As an example, consider the operation KeyRead, defined by:

106. 106 Precondition investigation (Cont.) 1:

107. 107 Precondition investigation (Cont.) 2:

108. 108 Precondition investigation (Cont.) This is a free promotion 3:

109. 109 Precondition investigation (Cont.)

110. 110 Precondition investigation (Cont.)

111. 111 Precondition investigation (Cont.) For each operation, we list the partial operations used in its definition, together with their preconditions. In every case, the disjunction of these preconditions is true our operations are total.

112. 112 Data Refinement Refinement:  Developing a specification in such a way that it leads us towards a suitable implementation by adding more information in each step of refinement.  The process of improvement involves the removal of indeterminism, or uncertainty. The refinement must be correct  It is important that our new, more detailed description is consistent with our original specification:

113. 113 Relations and indeterminism Total relations:  If R and S are total relations, then R refines S exactly when  Wherever S relates the same element x to two distinct elements y 1 and y 2, R may remove a degree of uncertainty by omitting either

114. 114 Partial relations:  we may consider their totalised versions  If is a partial relation between types X and Y then: Relations and indeterminism (Cont.)

115. 115 Relations and indeterminism (Cont.)

116. 116 Relations and indeterminism (Cont.) If are two partial relations of the same type, then refines precisely when

117. 117 Relations and indeterminism (Cont.) The changesto is a refinement of the corruptsto

118. 118 Data types and data refinement A data type X is a tuple, where: Both xi and xf are total, but each xo i may be partial

119. 119 Data types and data refinement (Cont.) A program is a sequence of operations upon a data type. It may be seen as a relation between input and output, recorded by the initialisation and finalisation steps at the beginning and end of this sequence Exp. is a program that uses the data type

120. 120 Data types and data refinement (Cont.) The choice of data representation within the data type is not relevant to the overall behaviour of the program It is encapsulated by initialisation and finalisation. Thus programs may be parameterised by data types:

121. 121 Data types and data refinement (Cont.) An abstract data type X may be totalised: If data types A and C share the same indexing set, then A is refined by C if and only if for each program P(A): If A and C are both indexed by the set I, then this definition requires us to prove that, for sequences in seq I In practice, this may be a difficult result to establish

122. 122 Simulations

123. 123 Simulations (Cont.) If data types A and C share the same indexing set, then the programs P(A) and P(C) will have the same number of steps:  One for each operation involved.  We may therefore compare the two programs on a step- by-step basis.

124. 124 Simulations (Cont.)

125. 125 Forwards/Downwards Simulation

126. 126 Forwards Simulation (Cont.)

127. 127 Backwards/Upwards Simulation

128. 128 Backwards/Upwards Simulation

129. 129 Relaxing and unwinding By considering domain and range restrictions, we can obtain an equivalent set of requirements that mention neither totalisation nor lifting. These requirements constitute a more relaxed set of rules for data refinement.

130. 130 Relaxed rules for simulations

131. 131 Specification statements To describe operations upon an abstract data type we may use  Schemas  Specification statements: abstract programs consisting of  a precondition,  a postcondition,  a list of variables.

132. 132 Specification statements (Cont.) Describes an operation that  begins in a state satisfying precondition,  ends in a state satisfying postcondition,  only those variables listed in frame are affected.

133. 133 Specification statements (Cont.)

134. 134 Specification statements (Cont.) The following specification statement describes the operation of finding an approximate root for a function.  a value m such that f (m) is close to zero.  within a particular interval [a,b].  It will fail if no such value exists:

135. 135 Assignment A program in the refinement calculus may consist of a mixture of specification statements and code.

136. 136 Refinement of Specification statements If a program P is correctly refined by another program Q, then we write:

137. 137 Refinement of Specification statements (Cont.) Exp.

138. 138 Refinement of Specification statements (Cont.) Exp.

139. 139 Refinement of Specification statements (Cont.) Suppose that we want to swap two variables without using a third variable to store the intermediate value:

140. 140

141. 141 Conditional statements

142. 142 Iteration

143. 143 References Jim Davies and Jim Woodcock, Using Z: Specification, Refinement and Proof, Prentice Hall International Series in Computer Science, 1996, ISBN 0-13-948472-8. Gerard O’Regan, Mathematical Approaches to Software Quality, Springer –Verlag London Limited, 2006, ISBN -13: 978-1-84628-242-3.

144. 144 Thank you for your attention! Questions ??? ?