1. Chapter 27
Formal Specification

2. 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.

3. Formal methods
Formal specification is part of a more general collection of techniques known as “formal methods.”
All are based on the mathematical rep-resentations and analysis of requirements and software.
(cont’d)

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

5. Acceptance and use
Formal methods have not become mainstream as was once predicted, especially in the US. Some reasons:
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)

6. Acceptance and use (cont’d)
Market changes have made time-to-market rather than quality the key issue for many systems. (Formal methods do not reduce time-to-market.)
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)

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

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

9. 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.

10. Formal specification in the software process
elicitation
a “back-end” element of requirements elicitation/analysis/specification/validation

11. 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.

12. 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 ambi-guities, incompleteness, and inconsistencies are discovered and resolved.
Hence, rework due to requirements prob-lems is greatly reduced.

13. Development costs with formal specificationg d I m l C W h u r
V&V
V&V

14. Algebraic Specification of sub-system interfaces
Large systems are normally comprised of sub-systems with well-defined interfaces.
Specification of these interfaces allows for their independent development.
(cont’d)

15. Algebraic Specification of sub-system interfaces (cont’d)
Sub-system interfaces are often defined as abstract data types (“sorts”) or objects.
The algebraic approach is particularly well-suited to the specification of such interfaces.

16. 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

17. The structure of an algebraic specification
TION NAME > (Gener
ic P ar
ameter)
Introduction
sort
< name >
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

18. 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.

19. 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.)

20. List specification a FIFO linear list
( Elem )
a FIFO linear list
sort
List
imports
INTEGER
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
operator names + type info for argument(s) & result
Cons (List, Elem) → List
Head (List) →
Elem
Length (List) →
Integer T
ail (List) →
List 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
defines Tail in terms of Create and Cons
Length (Cons (L, v)) = Length (L) + 1 T
ail (Create) = Create T
ail (Cons (L, v)) = if L
=Create
then
Create
else
Cons (T
ail (L), v)

21. Recursion in specifications
Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v)
Tail (Cons ( [5, 7], 9)) = ?

22. Recursion in specifications
Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v)
Tail (Cons ( [5, 7], 9)) = ?

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

35. 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]

36. Exercise L Head (Tail (L)) [ ] What does Head (Tail (L)) do? [a]
[a, b]
[a, b, c]
undefined
undefined b b

37. 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

38. Proof that Head (Tail ([a, b])) = b

39. Proof that Head (Tail ([a, b])) = b

40. Proof that Head (Tail ([a, b])) = b
Head (Tail ([a, b])) = Head (Tail (Cons ([a], b)))

41. Proof that Head (Tail ([a, b])) = b
Head (Tail ([a, b])) = Head (Tail (Cons ([a], b)))

42. Proof that Head (Tail ([a, b])) = b
Head (Tail ([a, b])) = Head (Tail (Cons ([a], b)))
= Head (Cons (Tail ([a]), b)) (axiom 6)

43. Proof that Head (Tail ([a, b])) = b
Head (Tail ([a, b])) = Head (Tail (Cons ([a], b)))
= Head (Cons (Tail ([a]), b)) (axiom 6)

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))

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))

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)

47. 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)

48. List specification a FIFO linear list
( Elem )
a FIFO linear list
sort
List
imports
INTEGER
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
operator names + type info for argument(s) & result
Cons (List, Elem) → List
Head (List) →
Elem
Length (List) →
Integer T
ail (List) →
List 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
defines Tail in terms of Create and Cons
Length (Cons (L, v)) = Length (L) + 1 T
ail (Create) = Create T
ail (Cons (L, v)) = if L
=Create
then
Create
else
Cons (T
ail (L), v)

49. 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)

50. 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!

51. Model-based specification
Algebraic specification can be cumbersome when object operations are not indepen-dent 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)

52. 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)

53. Model-based specification (cont’d)
The basic building blocks of Z-based speci-fications are schemas.
Schemas identify state variables and define constraints and operations in terms of those variables.

54. The structure of a Z schema
Natural numbers (0, 1, 2, …)
NAME
Container
contents: N
capacity: N
SIGNATURE
(defines schema state)
(invariants, pre- & post-conditions)
PREDICATE
contents ≤ capacity

55. An insulin pump insulin delivery glucose level text messages
dose delivered

56. 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.

57. Insulin pump schema signature
(cont’d)

58. Insulin pump schema signature (cont'd)

59. 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.

60. Insulin pump schema predicate

61. 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.

62. RUN schema operations change state imports state & predicates[ Л
Note Л
x′ - value of x after operation

63. RUN schema (cont'd) Л Л Л ]

64. Sugar OK schema predicateЛ [ Л Л Л ]

65. 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.

66. 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)

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

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

69. Example 1 Sort a non-empty array LIST[1..N] into increasing order.
Pre-cond: N ≥ 1
Post-cond:

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]

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]…

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] Л ???
Suppose LIST is initially [18, -4, 6] and after “sorting” is [1, 2, 3]…

73. where PERM(A,B)  “A is a permutation of B (and vice-versa)”
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)”

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.

75. 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.

76. Example 2
Pre-cond: N ≥ 1 Л “LIST is ordered” (?)
Post-cond:

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:

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:

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)]

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
FOUND := False
End

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)]
Consider the “search” program: Begin
FOUND := False
End

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 Л …) V (NOT FOUND Л …)]

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 Л …)]

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)]

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)]
Consider the “search” program: Begin
LIST := [1, 2, 3]
Key := 17
FOUND := False
End

86. where UNCH(X1, X2, …)  For_Every i, Xi = Xi’
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(X1, X2, …)  For_Every i, Xi = Xi’

87. Exercise
See PRE- AND POST-CONDITION SPECIFICATION EXERCISES  on course website.

88. 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 correct-ness conditions associated with the control structures relative to the intended function.

89. 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)

90. 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.

91. 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)

92. Program specification (cont’d)
f = (y  0  x, y := x+y, 0)
specifies a program for which:

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

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...

95. 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).

96. 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

97. 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

98. 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

99. 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

100. Key points
Formal system specification complements informal specification techniques.
Formal specifications are precise and unam-biguous. 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)

101. 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)

102. 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.

103. Chapter 27
Formal Specification