Chapter 27 Formal Specification

Chapter 27 Formal Specification Chapter 27 Formal Specification Slide 1

Objectives To explain why formal specification helps discover problems in system requirements. To describe the use of: Algebraic specification techniques, and Model-based specification techniques (including simple pre- and post-conditions). And to introduce Function-based program specification. Chapter 27 Formal Specification Slide 2

Formal methods Formal specification is part of a more general collection of techniques known as formal methods. All are based on the mathematical representations and analysis of requirements and software. (cont d) Chapter 27 Formal Specification Slide 3

Formal methods (cont d) Formal methods include: Formal specification Specification analysis and property proofs Transformational development Program verification (program correctness proofs) (axiomatic, function theoretic) Specifications are expressed with precisely defined vocabulary, syntax, and semantics. (e.g., model checking ) Chapter 27 Formal Specification Slide 4

Acceptance and use Formal methods have not become mainstream as was once predicted, especially in the US. Some reasons: 1. Less costly techniques (e.g., inspections / reviews) have been very successful at increasing system quality. (Hence, the need for formal methods has been reduced.) (cont d) Chapter 27 Formal Specification Slide 5

Acceptance and use (cont d) 2. Market changes have made time-tomarket rather than quality the key issue for many systems. (Formal methods do not reduce time-to-market.) 3. Limited scope of formal methods. They re not well-suited to specifying the look and feel of user interfaces. (Many interactive applications are GUI-heavy today.) (cont d) Chapter 27 Formal Specification Slide 6

Acceptance and use (cont d) 4. Formal methods are hard to scale up for very large systems. (Although this is rarely necessary.) 5. Start-up costs can be high. 6. The risks of adopting formal methods on most projects are perceived to outweigh the benefits. Chapter 27 Formal Specification Slide 7

Acceptance and use (cont d) However, formal specification is an excellent way to find (some common types of) requirements errors and to express requirements unambiguously. Projects which use formal methods invariably report fewer errors in the delivered software. (cont d) Chapter 27 Formal Specification Slide 8

Acceptance and use (cont d) In systems where failure must be avoided, the use of formal methods is justified and likely to be cost-effective. In particular, the use of formal methods is increasing in critical system development where safety, reliability, and security are important. Chapter 27 Formal Specification Slide 9

Formal specification in the software process Requirements specification Formal specification Requirements elicitation definition High-le vel design System modelling Ar chitectural design a back-end element of requirements elicitation/analysis/specification/validation Chapter 27 Formal Specification Slide 10

Formal specification techniques Algebraic approach system is specified in terms of its operations and their relationships via axioms. Model-based approach (including simple pre- and post-conditions) system is specified in terms of a state model and operations are defined in terms of changes to system state. Function-based approach system is specified in terms of its functional behaviour via mathematical abstractions known as intended program functions. Chapter 27 Formal Specification Slide 11

Use of formal specification Formal specification is a rigorous process and requires more effort in the early phases of software development. This reduces requirements errors as ambiguities, incompleteness, and inconsistencies are discovered and resolved. Hence, rework due to requirements problems is greatly reduced. Chapter 27 Formal Specification Slide 12

Development costs with formal specification C o s t V&V D e s i g n a n d I m p l e m e n t a t i o n V&V D e s i g n a n d I m p l e m e n t a t i o n S p e c i f i c a t i o n S p e c i f i c a t i o n W i t h o u t f o r m a l s p e c i f i c a t i o n W i t h f o r m a l s p e c i f i c a t i o n Chapter 27 Formal Specification Slide 13

Algebraic Specification of subsystem interfaces Large systems are normally comprised of sub-systems with well-defined interfaces. Specification of these interfaces allows for their independent development. Interface objects Sub-system A Sub-system B (cont d) Chapter 27 Formal Specification Slide 14

Algebraic Specification of subsystem interfaces (cont d) Sub-system interfaces are often defined as abstract data types ( sorts ) or objects. The algebraic approach is particularly wellsuited to the specification of such interfaces. Chapter 27 Formal Specification Slide 15

Algebraic specification components Introduction defines the sort (type name) and declares other specifications that are used Description informally describes the operations on the type (the three other components are formal) Signature defines the syntax of the operations in the interface and their parameters Axioms defines the operation semantics by defining axioms which characterize behavior Chapter 27 Formal Specification Slide 16

The structure of an algebraic specification < SPECIFICA TION NAME > (Gener ic P ar ameter) sort < name > Introduction imports < LIST OF SPECIFICA TION NAMES > Inf or mal descr iption of the sor t and its oper ations Oper ation signatures setting out the names and the types of the parameters to the operations defined over the sort Axioms defining the oper ations o v er the sor t Chapter 27 Formal Specification Slide 17

Types of operations Constructor operations: operations which create or modify entities of the type Inspection operations: operations which evaluate (i.e., reveal) entities of the type being specified Rule of thumb for defining axioms: define an axiom which sets out what is always true for each inspection operation over (i.e., after applying) each (primitive) constructor operation. Chapter 27 Formal Specification Slide 18

Operations on a (FIFO linear) List abstract data type Constructor operations which create or modify sort List: Create, Cons and Tail Inspection operations which discover attributes of sort List: Head and Length (LISP fans: Tail = CDR, Head = CAR) Tail is not a primitive operation since it can be defined using Create and Cons. (Thus, axioms are not required for Head and Length over Tail.) Chapter 27 Formal Specification Slide 19

List specification LIST ( Elem ) sort List imports INTEGER a FIFO linear list Defines a list where elements are added at the end and removed from the front. The operations are Create, which brings an empty list into existence; Cons, which creates ( Constructs ) a new list with an added member; Length, which evaluates the list size; Head, which evaluates the front element of the list; and Tail, which creates a list by removing the head from its input list. Undefined represents an undefined value of type Elem. Create List Cons (List, Elem) List Head (List) Elem Length (List) Integer T ail (List) List operator names + type info for argument(s) & result 1 2 3 4 5 6 Head (Create) = Undefined exception (empty list) Head (Cons (L, v)) = if L =Create then v else Head (L) Length (Create) = 0 Length (Cons (L, v)) = Length (L) + 1 T ail (Create) = Create Create and Cons T ail (Cons (L, v)) = if L =Create then Create else Cons (T ail (L), v) defines Tail in terms of Chapter 27 Formal Specification Slide 20

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? Chapter 27 Formal Specification Slide 21

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? Chapter 27 Formal Specification Slide 22

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) Chapter 27 Formal Specification Slide 23

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) Chapter 27 Formal Specification Slide 24

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) Chapter 27 Formal Specification Slide 25

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) Chapter 27 Formal Specification Slide 26

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) Chapter 27 Formal Specification Slide 27

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) Chapter 27 Formal Specification Slide 28

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) Chapter 27 Formal Specification Slide 29

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) Chapter 27 Formal Specification Slide 30

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) = Cons (Cons (Create, 7), 9) (axiom 6) Chapter 27 Formal Specification Slide 31

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) = Cons (Cons (Create, 7), 9) (axiom 6) Chapter 27 Formal Specification Slide 32

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) = Cons (Cons (Create, 7), 9) (axiom 6) = Cons ( [7], 9) Chapter 27 Formal Specification Slide 33

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) = Cons (Cons (Create, 7), 9) (axiom 6) = Cons ( [7], 9) Chapter 27 Formal Specification Slide 34

Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) = Cons (Cons (Create, 7), 9) (axiom 6) = Cons ( [7], 9) = [7, 9] Chapter 27 Formal Specification Slide 35

Exercise What does Head (Tail (L)) do? L [ ] [a] [a, b] [a, b, c] Head (Tail (L)) undefined undefined b b Chapter 27 Formal Specification Slide 36

Exercise Are axioms 1-6 sufficient to prove ANY true assertion of the form Head (Tail (L)) = v? Consider ONE EXAMPLE: Head (Tail ([a, b]) = b Chapter 27 Formal Specification Slide 37

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Chapter 27 Formal Specification Slide 38

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Chapter 27 Formal Specification Slide 39

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) Chapter 27 Formal Specification Slide 40

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) Chapter 27 Formal Specification Slide 41

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) Chapter 27 Formal Specification Slide 42

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) Chapter 27 Formal Specification Slide 43

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) = Head (Cons (Tail (Cons ([ ], a)), b)) Chapter 27 Formal Specification Slide 44

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) = Head (Cons (Tail (Cons ([ ], a)), b)) Chapter 27 Formal Specification Slide 45

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) = Head (Cons (Tail (Cons ([ ], a)), b)) = Head (Cons ([ ], b)) (axiom 6) Chapter 27 Formal Specification Slide 46

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) = Head (Cons (Tail (Cons ([ ], a)), b)) = Head (Cons ([ ], b)) (axiom 6) Chapter 27 Formal Specification Slide 47

List specification LIST ( Elem ) sort List imports INTEGER a FIFO linear list Defines a list where elements are added at the end and removed from the front. The operations are Create, which brings an empty list into existence; Cons, which creates a new list with an added member; Length, which evaluates the list size; Head, which evaluates the front element of the list; and Tail, which creates a list by removing the head from its input list. Undefined represents an undefined value of type Elem. Create List Cons (List, Elem) List Head (List) Elem Length (List) Integer T ail (List) List operator names + type info for argument(s) & result 1 2 3 4 5 6 Head (Create) = Undefined exception (empty list) Head (Cons (L, v)) = if L =Create then v else Head (L) Length (Create) = 0 Length (Cons (L, v)) = Length (L) + 1 T ail (Create) = Create Create and Cons T ail (Cons (L, v)) = if L =Create then Create else Cons (T ail (L), v) defines Tail in terms of Chapter 27 Formal Specification Slide 48

Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) = Head (Cons (Tail (Cons ([ ], a)), b)) = Head (Cons ([ ], b)) (axiom 6) = b (axiom 2) Chapter 27 Formal Specification Slide 49

Question So, we can prove Head (Tail ([a, b])) = b using the given axioms, but how could one show that the axioms are sufficient to prove ANY true assertion of the form Head (Tail (L)) = v? (Hint: consider mathematical induction on the length of L.) Moral: Showing correctness and completeness of algebraic specifications can be tricky! Chapter 27 Formal Specification Slide 50

Model-based specification Algebraic specification can be cumbersome when object operations are not independent of object state (i.e., the result of previous operations). (System State) Model-based specification exposes the system state and defines operations in terms of changes to that state. (cont d) Chapter 27 Formal Specification Slide 51

Model-based specification (cont d) Z (pronounced zed and named after Zermelo-Fraenkel set theory) is a mature notation for model-based specification. Combines formal and informal descriptions and incorporates graphical highlighting. Based on notation used in axiomatic set theory, lambda calculus, and first-order predicate logic. (cont d) Chapter 27 Formal Specification Slide 52

Model-based specification (cont d) The basic building blocks of Z-based specifications are schemas. Schemas identify state variables and define constraints and operations in terms of those variables. Chapter 27 Formal Specification Slide 53

The structure of a Z schema NAME SIGNATURE Container contents: N capacity: N Natural numbers (0, 1, 2, ) (defines schema state) PREDICATE contents capacity (invariants, pre- & postconditions) Chapter 27 Formal Specification Slide 54

An insulin pump insulin Needle assembly delivery Sensor glucose level Insulin reservoir Pump Controller Clock Alarm Display1 Display2 text messages dose delivered Power supply Chapter 27 Formal Specification Slide 55

Modelling the insulin pump embedded control system The schema models the system as a number of state variables: reading? from glucose level sensor dose, cumulative_dose r0, r1, r2 last 3 glucose level readings capacity capacity of insulin reservoir insulin_available insulin reservoir level alarm! signals exceptional conditions pump! output for pump device display1!, display2! text messages & dose Names followed by a? are inputs, names followed by a! are outputs. Chapter 27 Formal Specification Slide 56

Insulin pump schema signature INSULIN_PUMP_STATE //Input device definition switch?: (off, manual, auto) ManualDeliveryButton?: Reading?: HardwareTest?: (OK, batterylow, pumpfail, sensorfail, deliveryfail) InsulinReservoir?: (present, notpresent) Needle?: (present, notpresent) clock?: TIME //Output device definition alarm! = (on, off) display1!, string display2!: string clock!: TIME dose!: (cont d) Chapter 27 Formal Specification Slide 57

Insulin pump schema signature (cont'd) // INSULIN_PUMP_STATE (Cont'd) // State variables used for dose computation status: (running, warning, error) r0, r1, r2: capacity, insulin_available : max_daily_dose, max_single_dose, minimum_dose: safemin, safemax: CompDose, cumulative_dose: Chapter 27 Formal Specification Slide 58

Schema predicates Each Z schema has a predicate part which defines conditions that are always true (schema invariants) For the insulin pump schema, for example, it is always true that: The dose must be less than or equal to the insulin available in the reservoir. No single dose may be more than 4 units of insulin, and the total dose delivered in a 24 hour time period must not exceed 25 units of insulin (safety constraints). display2! shows the amount of insulin to be delivered. Chapter 27 Formal Specification Slide 59

Insulin pump schema predicate // INSULIN_PUMP_STATE (Cont'd) r2 = Reading? dose! insulin_available insulin_available capacity // The cumulative dose of insulin delivered is set to zero once every 24 hours clock? = 000000 cumulative_dose = 0 // If the cumulative dose exceeds the limit then operation is suspended cumulative_dose max_daily_dose ( status = error display1! = Daily dose exceeded ) // Pump configuration parameters capacity = 100 safemin = 6 safemax = 14 max_daily_dose = 25 max_single_dose = 4 minimum_dose = 1 display2! = nat_to_string (dose!) clock! = clock? Chapter 27 Formal Specification Slide 60

The dosage computation The insulin pump computes the amount of insulin required by comparing the current reading with two previous readings. If these suggest that blood glucose is rising then insulin is delivered. Information about the total dose delivered is maintained to allow the safety check invariant to be applied. Note that this invariant always applies - there is no need to repeat it in the dosage computation. Chapter 27 Formal Specification Slide 61

RUN schema RUN INSULIN_PUMP_STATE operations change state Note [ switch? = auto status = running status = warning insulin_available max_single_dose cumulative_dose < max_daily_dose // The dose of insulin is computed depending on the blood sugar level (SUGAR_LOW SUGAR_OK SUGAR_HIGH) // 1. If the computed insulin dose is zero, don t deliver any insulin CompDose = 0 dose! = 0 Л // 2. The maximum daily dose would be exceeded if the computed dose was delivered so the insulin dose is set to the difference between the maximum allowed daily dose and the cumulative dose delivered so far Л CompDose + cumulative_dose > max_daily_dose alarm! = on status = warning dose! = max_daily_dose cumulative_dose imports state & predicates x - value of x after operation Chapter 27 Formal Specification Slide 62

RUN schema (cont'd) // RUN (cont'd) // 3. The normal situation. If maximum single dose is not exceeded then deliver the computed dose. If the single dose computed is too high, restrict the dose delivered to the maximum single dose. Л CompDose + cumulative_dose < max_daily_dose ( CompDose max_single_dose dose! = CompDose Л Л CompDose > max_single_dose dose! = max_single_dose ) insulin_available = insulin_available dose! cumulative_dose = cumulative_dose + dose! insulin_available max_single_dose * 4 ( status = warning display1! = Insulin low ) r1 = r2 r0 = r1 ] Chapter 27 Formal Specification Slide 63

Sugar OK schema predicate SUGAR_OK [ r2 safemin r2 safemax // sugar level stable or falling Л r2 r1 CompDose = 0 // sugar level increasing but rate of increase falling r2 > r1 (r2-r1) < (r1-r0) CompDose = 0 Л // sugar level increasing and rate of increase increasing compute dose // a minimum dose must be delivered if rounded to zero r2 > r1 (r2-r1) (r1-r0) (round ((r2-r1)/4) = 0) CompDose = minimum_dose Л Л r2 > r1 (r2-r1) (r1-r0) (round ((r2-r1)/4) > 0) CompDose = round ((r2-r1)/4)] Chapter 27 Formal Specification Slide 64

Specification via Pre- and Post- Conditions Predicates that (when considered together) reflect a program s intended functional behavior are defined over its state variables. Pre-condition: expresses constraints on program variables before program execution. An implementer may assume these will hold BEFORE program execution. Chapter 27 Formal Specification Slide 65

Specification via Pre- and Post- Conditions (cont d) Post-condition: expresses conditions / relationships among program variables after execution. These capture any obligatory conditions AFTER program execution. Language: predicate calculus Predicates (X>4) Connectives (Л, V,,, NOT) Universal and existential quantifiers ( for every, there exists ) Rules of inference (if A Л (A B) then B) Chapter 27 Formal Specification Slide 66

Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: Post-cond: Chapter 27 Formal Specification Slide 67

Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: Post-cond: Chapter 27 Formal Specification Slide 68

Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: N 1 Post-cond: Chapter 27 Formal Specification Slide 69

Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: N 1 Post-cond: For_Every i, 1 i N-1, LIST[i] LIST[i+1] Chapter 27 Formal Specification Slide 70

Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: N 1 Post-cond: For_Every i, 1 i N-1, LIST[i] LIST[i+1] Suppose LIST is initially [18, -4, 6] and after sorting is [1, 2, 3] Chapter 27 Formal Specification Slide 71

Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: N 1 Post-cond: For_Every i, 1 i N-1, LIST[i] LIST[i+1] Л??? Suppose LIST is initially [18, -4, 6] and after sorting is [1, 2, 3] Chapter 27 Formal Specification Slide 72

Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: N 1 Post-cond: For_Every i, 1 i N-1, LIST[i] LIST[i+1] Л PERM(LIST,LIST ) where PERM(A,B) A is a permutation of B (and vice-versa) Chapter 27 Formal Specification Slide 73

Example 2 Search a non-empty, ordered array LIST[1..N] for the value stored in KEY. If present, set FOUND to true and J to an index of LIST which corresponds to KEY. Otherwise, set FOUND to false. Chapter 27 Formal Specification Slide 74

Example 2 Search a non-empty, ordered array LIST[1..N] for the value stored in KEY. If present, set FOUND to true and J to an index of LIST which corresponds to KEY. Otherwise, set FOUND to false. Chapter 27 Formal Specification Slide 75

Example 2 Pre-cond: N 1 Л LIST is ordered (?) Post-cond: Chapter 27 Formal Specification Slide 76

Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: Chapter 27 Formal Specification Slide 77

Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: Chapter 27 Formal Specification Slide 78

Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л ) V (NOT FOUND)] Chapter 27 Formal Specification Slide 79

Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л ) V (NOT FOUND)] Consider the search program: Begin End FOUND := False Chapter 27 Formal Specification Slide 80

Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л ) V (NOT FOUND)] Consider the search program: Begin End FOUND := False Chapter 27 Formal Specification Slide 81

Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л ) V (NOT FOUND Л )] Chapter 27 Formal Specification Slide 82

Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л There_Exists i, 1 i N J=i Л LIST[J]=Key) V (NOT FOUND Л )] Chapter 27 Formal Specification Slide 83

Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л There_Exists i, 1 i N J=i Л LIST[J]=Key) V (NOT FOUND Л For_Every i, 1 i N, LIST[i] KEY)] Chapter 27 Formal Specification Slide 84

Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л There_Exists i, 1 i N J=i Л LIST[J]=Key) V (NOT FOUND Л For_Every i, 1 i N, LIST[i] KEY)] Consider the search program: Begin LIST := [1, 2, 3] Key := 17 FOUND := False End Chapter 27 Formal Specification Slide 85

Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л There_Exists i, 1 i N J=i Л LIST[J]=Key) V (NOT FOUND Л For_Every i, 1 i N, LIST[i] KEY)] Л UNCH(LIST,KEY) where UNCH(X 1, X 2, ) For_Every i, X i = X i Chapter 27 Formal Specification Slide 86

Exercise See PRE- AND POST-CONDITION SPECIFICATION EXERCISES on course website. Chapter 27 Formal Specification Slide 87

Function-based specification Defines required program behavior in terms of intended program functions. These define mappings from initial to final data states and can be (manually) expanded into program control structures. The correctness of an expansion (program) can be determined by considering correctness conditions associated with the control structures relative to the intended function. Chapter 27 Formal Specification Slide 88

Relations and functions A relation, r, is a set whose members (if any) are all ordered pairs. The set composed of the first member of each pair is called the domain of r and is denoted D(r). Members of D(r) are called arguments of r. A function, f, is a relation such that for each x D(f) there exists a unique element (x,y) f. (cont d) Chapter 27 Formal Specification Slide 89

Relations and functions (cont d) We often express this as y = f(x), where y is the unique value corresponding to x in the function f. It is the uniqueness of y that distinguishes a function from a relation. Chapter 27 Formal Specification Slide 90

Program specification Program data mappings may be specified via use of a concurrent assignment function. The domain of the function corresponds to the initial data states that would be transformed into final data states by a suitable program. Consider, for example, the conditional function: f = (y 0 x, y := x+y, 0) (cont d) Chapter 27 Formal Specification Slide 91

Program specification (cont d) f = (y 0 x, y := x+y, 0) specifies a program for which: Chapter 27 Formal Specification Slide 92

Program specification (cont d) f = (y 0 x, y := x+y, 0) specifies a program for which: the final value of x is the sum of the initial values of x and y, and Chapter 27 Formal Specification Slide 93

Program specification (cont d) f = (y 0 x, y := x+y, 0) specifies a program for which: the final value of x is the sum of the initial values of x and y, and the final value of y is 0... Chapter 27 Formal Specification Slide 94

Program specification (cont d) f = (y 0 x, y := x+y, 0) specifies a program for which: the final value of x is the sum of the initial values of x and y, and the final value of y is 0... if y is initially 0. Otherwise, the program would not terminate (since f is not defined in this case). Chapter 27 Formal Specification Slide 95

Example 3 f = (y 0 x, y := x+y, 0) Is f equivalent to the function computed by the following program? If y 0 then x := x+y y := 0 end_if Chapter 27 Formal Specification Slide 96

Example 3 f = (y 0 x, y := x+y, 0) Is f equivalent to the function computed by the following program? NO! If y 0 then x := x+y y := 0 end_if Chapter 27 Formal Specification Slide 97

Example 4 f = (y 0 x, y := x+y, 0) Is f equivalent to the function computed by the following program? While y <> 0 do x := x+1 y := y-1 end_while Chapter 27 Formal Specification Slide 98

Example 4 f = (y 0 x, y := x+y, 0) Is f equivalent to the function computed by the following program? YES! While y <> 0 do x := x+1 y := y-1 end_while Chapter 27 Formal Specification Slide 99

Key points Formal system specification complements informal specification techniques. Formal specifications are precise and unambiguous. They remove areas of doubt in a specification. Formal specification forces an analysis of the system requirements at an early stage. Correcting errors at this stage is cheaper than modifying a delivered system. (cont d) Chapter 27 Formal Specification Slide 100

Key points (cont d) Formal specification techniques are most applicable in the development of critical systems. Algebraic techniques are particularly well suited to specifying interfaces of objects and abstract data types. In model-based specification, operations are defined in terms of changes to system state. (cont d) Chapter 27 Formal Specification Slide 101

Key points (cont d) A program s required functional behaviour may also be specified via an intended function. The domain of the function corresponds to the initial data states that would be transformed into final data states by a suitable program. Chapter 27 Formal Specification Slide 102

Chapter 27 Formal Specification Chapter 27 Formal Specification Slide 103