Formal Specification

● Techniques for the 
unambiguous specification of 
software

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  1

Objectives
● To explain why formal specification techniques 
help discover problems in system requirements
● To describe the use of algebraic techniques for 
interface specification
● To describe the use of model­based techniques 
for behavioural specification

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  2

Topics covered
● Formal specification in the software process
● Interface specification
● Behavioural specification

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  3

Formal methods
● Formal specification is part of a more general 
collection of techniques that are known as ‘formal 
methods’
● These are all based on mathematical 
representation and analysis of software
● Formal methods include
• Formal specification
• Specification analysis and proof
• Transformational development
• Program verification

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  4

Acceptance of formal methods
● Formal methods have not become mainstream 
software development techniques as was once 
predicted
• Other software engineering techniques have been successful at 
increasing system quality. Hence the need for formal methods 
has been reduced
• Market changes have made time­to­market rather than software 
with a low error count the key factor. Formal methods do not 
reduce time to market
• The scope of formal methods is limited. They are not well­
suited to specifying and analysing user interfaces and user 
interaction
• Formal methods are hard to scale up to large systems
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  5
Use of formal methods
● Formal methods have limited practical 
applicability
● Their principal benefits are in reducing the 
number of errors in systems so their mai area of 
applicability is critical systems
● In this area, the use of formal methods is most 
likely to be cost­effective

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  6

Specification in the software process
● Specification and design are inextricably 
intermingled.
● Architectural design is essential to structure a 
specification.
● Formal specifications are expressed in a 
mathematical notation with precisely defined 
vocabulary, syntax and semantics.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  7

 R
edqufirnem n
ttosR
espquciS
rfpem n I
Dncr
e
a
si
n
g
 
c
o
teaciiofsationA n
lit
era c to r 
in
v
o
l
e
mn
t
rcdhitsecgnuralspS
o
fecitw areionH
idghs­lenvl
Specification and design

D esign
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  8
R
edqufirnem n R
e
q
u
s
p
c
ttosm
S
y i
r
fe ma
sodtlem n
t
s
i
o F
o
s
p
e
c
hr
i
f
i
t
em
ca
l
t
i
o
n
u
r
a
l H
i
g
h
­
l
e
d
s
i
gv
l
n
Specification in the software process

A
r
c
ing dsgn
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  9
Specification techniques
● Algebraic approach
• The system is specified in terms of its operations and their 
relationships
● Model­based approach
• The system is specified in terms of a state model that is 
constructed using mathematical constructs such as sets and 
sequences. Operations are defined by modifications to the 
system’s state

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  10

Formal specification languages

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  11

Use of formal specification
● Formal specification involves investing more 
effort in the early phases of software development 
● This reduces requirements errors as it forces a 
detailed analysis of the requirements 
● Incompleteness and inconsistencies can be 
discovered and resolved
● Hence, savings as made as the amount of rework 
due to requirements problems is reduced

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  12

 C
ostIm D
eplsm V
a
l
i
d
igen atdionSa
t
i
o
n De s ign  ad V
a
l
id
a
t
i
o
n
p
e
c
i
f
a
tI
m
p
i
o
nl m e t i
o n
Development costs with formal specification

S
pecifation
W
isptho
©Ian Sommerville 2000
u
teci faorim anl sW ipecth form
ationl
Software Engineering, 6th edition. Chapter 9  Slide  13
Interface specification
● Large systems are decomposed into subsystems 
with well­defined interfaces between these 
subsystems
● Specification of subsystem interfaces allows 
independent development of the different 
subsystems
● Interfaces may be defined as abstract data types 
or object classes
● The algebraic approach to formal specification is 
particularly well­suited to interface specification
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  14
 S
ub­sA I
n
t
e
r
f
a
o
b
jc
e
t
s
ytem S ub­sB
Sub­system interfaces

ytem
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  15
 < SP
TIO
sort
< na
impo
 < L
 OF
Inf
or ic 
TIO
mal  ar
am
iptio
Opet a
ation at
the p
Axio
atio
vetr 
The structure of an algebraic specification

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  16

Specification components
● Introduction
• Defines the sort (the type name) and declares other 
specifications that are used
● Description
• Informally describes the operations on the type
● Signature
• Defines the syntax of the operations in the interface and their 
parameters
● Axioms
• Defines the operation semantics by defining axioms which 
characterise behaviour

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  17

Systematic algebraic specification
● Algebraic specifications of a system may be 
developed in a systematic way
• Specification structuring.  
• Specification naming.  
• Operation selection.  
• Informal operation specification
• Syntax definition
• Axiom definition

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  18

Specification operations
● Constructor operations. Operations which create 
entities of the type being specified
● Inspection operations. Operations which evaluate 
entities of the type being specified
● To specify behaviour, define the inspector 
operations for each constructor operation

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  19

Operations on a list ADT
● Constructor operations which evaluate to sort List
• Create, Cons and Tail
● Inspection operations which take sort list as a 
parameter and return some other sort
• Head and Length.
● Tail can be defined using the simpler 
constructors Create and Cons. No need to define 
Head and Length with Tail.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  20

 sort
 List
impor
 INTE
ΛΙΣΤ
(
DefineΕλεµ
from th
 
T ation
into e
, Con
v, whic
Length
a
eleme
T
ae
, v
e
he o
, wh
xisten ings
w lis
 He
v
a ,
luate
lu
il, w
y re
vind
input li
List specification

Create
→→
Ηεαδ
→ 

Head 
Τ
α Λιστ
Ελεµ
Λενγτη
Ιντεγ
exce
if
 L (em
Λιστ
ιλthen(Λ
else
 = Cr
 v 
 He (
Length
T
aif
©Ian Sommerville 2000
il (Cr
then
 L else
il (Co
 = Cr
 Cre
 Co
ail 
Software Engineering, 6th edition. Chapter 9  Slide  21
Recursion in specifications
● Operations are often specified recursively
● Tail (Cons (L, v)) = if L = Create then Create     
else Cons (Tail (L), v)
• Cons ([5, 7], 9) = [5, 7, 9]
• Tail ([5, 7, 9])  =  Tail (Cons ( [5, 7], 9))  = 
• Cons (Tail ([5, 7]), 9) = Cons (Tail (Cons ([5], 7)), 9) =
• Cons (Cons (Tail ([5]), 7), 9) = 
• Cons (Cons (Tail (Cons ([], 5)), 7), 9) =
• Cons (Cons ([Create], 7), 9) = Cons ([7], 9) =  [7, 9]

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  22

Interface specification in critical systems
● Consider an air traffic control system where 
aircraft fly through managed sectors of airspace
● Each sector may include a number of aircraft but, 
for safety reasons, these must be separated
● In this example, a simple vertical separation of 
300m is proposed
● The system should warn the controller if aircraft 
are instructed to move so that the separation rule 
is breached

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  23

A sector object
● Critical operations on an object representing a 
controlled sector are
• Enter. Add an aircraft to the controlled airspace
• Leave. Remove an aircraft from the controlled airspace
• Move. Move an aircraft from one height to another
• Lookup. Given an aircraft identifier, return its current height

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  24

Primitive operations
● It is sometimes necessary to introduce additional 
operations to simplify the specification
● The other operations can then be defined using 
these more primitive operations
● Primitive operations
• Create. Bring an instance of a sector into existence
• Put. Add an aircraft without safety checks
• In­space. Determine if a given aircraft is in the sector
• Occupied. Given a height, determine if there is an aircraft 
within 300m of that height

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  25

 tE
 L
iM
tC
rP sm
Σ
no
aΕ
 ru
­o r
p
e
v
k
Χ
u SΤ
pe
Ο
a
  s
r
­c
Ρ
d
et
 
I
Fo
N
s
m
i
nr
T
oE
a
v
dnG
 
e
s
 
thiR
,
r
c
n 
B
a
f
 
i
e O
t
r
go
c
hL
 
t
a
f
t
 
oh E A
N
e
 
s
r
o
m
a c
 
n
ait
o
h
r
cr
 
i
f
e
g
a
f
ts
a
c
h
i
nfe
t
o
r
 
ty
e 
c
o
n
a
 
s
cd
i
t
o
h
e
r
 
t
on
s
 
fa
r
e
 
s
f
oa
t
i
s
df
e
d
 
o
Sector specification

 IO tE
­n
c
iΛ
tΧ
rΠ
εΜe
s
n
 Ινρ
(υ α a
p ϖ e
εde
S
( Σcs
­
εr
e
 
χa
n
h
c
t
o
τ 
r
οe
,
ρs
i
r
k
 
C
,
Χa
cs
an
 
f
 
i
l
­
α
λm
t
a
n
g
−
σ
ι o
γp
 
a
s
p
n
,
νy
i
r
c
e
 
H
)s
→ e
ac
t
o
r
f
i
s
e
d
i
g
t
Σ
ε  
h
)
 
χw
ai
l
→
τ
οt
h
 
n
r
e
a
d
g
Σ
ρo
y
s
ε
χc
 
τn
i
v
ο
ρas
t
r
a
i
 
e
c
l
bn
t
 
c
o
rh
e
ck
s
(E ο
−ε σ κ
α
π υ
τ
Σεπ χ→το
ρ
(Σ
,ε
Χ χ
τ
αο
λρ
−
,σ
ι
γ
Χν
,
α
λ −,
Η
σΗ
ε
ι
νγ ε ι
γ
η
Η
η
τ
) )
→
Βιγ
οη
Σ
ε
χ
λ
ατ
ο
νρ
t e
 L Οnie
fa
χ e
rlvis
 fe
(eS
, ( C
ι  P
εδ
ISC
,u
n
­O
c
e
t
 
=S
 rP
Σ
s
a
(
C
ε
p
u
t
 
(
SH
a
,)
χ
τ
c
i
S
,
 
C
1
ο
e
t=
ρ
d
C
S
h
Η
 
(
S
)
 
1
,
e
ε
,
 
C
=
H
n
ι
C
1
S
γ
η
S
H
r
)
τ
)
 
)
e
a
,
 
C
l
s tt
→
e
Sh
e
n
x
 
)
=
P
u  
c
t S
e
(
Le
x
p
t
i
o
a
vc
e
n
ep
 t
i
(
A
So
i
,n
 
(
A
H
e
r
c
a
f
 
C
S
)i
r
c
g
h
t
 
n
o
,
C
Sa
f
t
 
o
t
 
i
n
1
,
Ha
l
r
e
a
n
f
i
c
t
)
s
e
c
t
o
1
)d
y
 
i
r
)n
s
e
ct
o
r
)
M
  ­L o
 e
io
fN v
(lO e
,s ­e
,H
  E n
O
P
Io
c
GS
=
t
HC
I
u
 
(
TH
n
L)
r
e
­
s
i
e
i
sa=
a
p
dt
c
(
v
e
ct
h
 
S
,
 
o ne
n
(
S
H
 
C
s 
C
,
t
)
t
ah
n r
S
te
a
t
)
n
S
 
C
i
dhe
,
c 
 n
H
ax
c
e
S
 
)
t
i
n
gp
x
 
t
hti
o
c
e
a
t
 n 
(
N
o
p
t
i
n
H
e
v
a
l 
a
i
r
(
A
g
h
t
i
d
 
h
ec
a
f
o
i
g
ht
 
i
n
s
o
l
c
)
t
 
c
a
ne
c
t
 
i
n
o
to
r
)
s
e
c
t
 
b
e
 
ro
r
)
t
u
r
ne
d
i In
 O
i ip k
fc­s e
u
 ffl au
C
pp
(s
e
 CS
e  
(C
P
d=
Or
u
C
P
H
ce
1a
 
(
S
r
e
u
>t
1
t,
a
 
(
S
H
p
i 
t
eC
h
dS
1
e
,
 
H
C
n
 
()
 
=
,
n
)
S
1
d H
=
 N
1
 
f
,
HO
)
,
e
a
1
­  C
l
)­
sH
E
I
S
)
 
e
L
,
 
H
)
²
3=G
o
=
0 He
T
k
u
p
 
o
r
)
 x
(
S
(
Hce
p
,
 
C
 
> t
o
n
S
)
a
H
1
 (
A
n
d
 r
c
a
H
­f
o
 
H
1
 t
 
i
²
3
0s
c
o
t
)
 )
h
e
n
 t
r
u
e
cS e (C
 =Pre
u at,h
(1
S  CS
)e
1
,n =
fe
 tru
Ha
)ls, e
1 C
S
I n
)­=
sp
a
ce
 (S
, C
S
)
Specification commentary
● Use the basic constructors Create and Put to 
specify other operations
● Define Occupied and In­space using Create and 
Put and use them to make checks in other 
operation definitions
● All operations that result in changes to the sector 
must check that the safety criterion holds

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  27

Behavioural specification
● Algebraic specification can be cumbersome when 
the object operations are not independent of the 
object state
● Model­based specification exposes the system 
state and defines the operations in terms of 
changes to that state
● The Z notation is a mature technique for model­
based specification. It combines formal and 
informal description and uses graphical 
highlighting when presenting specifications
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  28
 S
cCont
h
e
m
a
 conte
n
m
eS
c
h
e
m
a
 
s
capai
g
n
a
tu
r
eS
c
h
e
ma
 
p
r
e
di
c
a
t
e
conte
The structure of a Z schema

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  29

 Insu
Need
Cl
Pum
assem
Con
Al
Sens
An insulin pump

Dis
Disp
Pow
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  30
Modelling the insulin pump
● The schema models the insulin pump as a number 
of state variables
• reading?
• dose, cumulative_dose
• r0, r1, r2
• capacity
• alarm!
• pump!
• display1!, display2!
● Names followed by a ? are inputs, names 
followed by a ! are outputs
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  31
Schema invariant
● Each Z schema has an invariant part which 
defines conditions that are always true
● For the insulin pump schema it is always true that
• The dose must be less than or equal to the capacity of the 
insulin reservoir
• No single dose may be more than 5 units of insulin and the total 
dose delivered in a time period must not exceed 50 units of 
insulin. This is a safety constraint (see Chapters 16 and 17)
• display1! shows the status of the insulin reservoir. 

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  32

 Ird
lc
id
rχn
s
e
a
o
au
d
,o
 0
p
iα1
tlu
:iπ
 se
m
!pn
_
g
c
r
{ χ?
2
y
f²a
1 p
u
 
:
o
,ιτy
 m
p
l
a
t
i
v
/
o
n
}
d
i
s
p
l
ae
_
d
 
u
y
2
!o
s
e
:
t
o
:
 
S
T
R 
r
e
c
I
N
Go
r
d
 
th
e
 
l
a
s
t
 3
r
ea
d
i
n
g
s 
t
a
ke
n
c p
ac
t
 
∧δ
οσ
ε
″5
∧χ
υ
µυ
λ
α
τ
ι
ϖ
ε
_δ
ο
σε
″
5
0
Insulin pump schema

ρ
2=ρ ψ
εα ≥
4
″
30
⇒
9
χ
δινγ?ι
α
λ
ρ
µπ
λ
α
ψ
χ
τ
!
=1
!
=
≥
0
ο
ν
∧∀
⇒
δ
δ
ι
σ
πσ
π
ψ
1
λ
α
ψ
1
!
=!
=
∀
Ι
ν
σ∀
Ι
ν
σ
υ
λ
ι
ν
υ
λ
ι
ϖ
εο
ω
ρ
ψ
λ∀
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  33
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  34
 D
∆ O
Ι(δο
ν S
σ
εA
G
υ
λ
ισ
ν
=E
_
Π
υ
0
∧
(
ρµ
1π
≥ρ
0
)
∧
(
ρ2
=
ρ
1)
∨
>
< ″
1
−
2>
(
ρ
0
−1
)
DOSAGE schema

)δδο
()χο σ
()σ
ε∨
ε
=
∨
=4
∧
(
ρ
(
ρ
2
−
ρ1
1″
<
)ρ
0
)
∧
(
ρ
∗
4
∧2
=
ρ
1
)
−
2∨
″
(
ρ
0
−1
)
)ρ α π
ι0υ
µ
∋=ρχ
τ
λ
α(
ρ
ψ
∋
=
χ
ϖ
ε
_
1∧
ρ1
α
δ″
>
π
ορ
0
)
(
∧
χ
ι
τ
ψ
−
δ
σ
ε
∋
=
χ
υ
µ
1∋=ρ
2ρ
2
>
ρ
1
−
ο
σ
ε
υ
λ
α
τ
ι)
∨
≥
(
ρ
1
ϖ
ε
_
δ
ο−
ρ
0
)
σ
ε
+
δο
σ
ε
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  35
Output schemas
● The output schemas model the system displays 
and the alarm that indicates some potentially 
dangerous condition
● The output displays show the dose computed and 
a warning message
● The alarm is activated if blood sugar is very low ­ 
this indicates that the user should eat something 
to increase their blood sugar level

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  36

 D
I∆
ιΑ S
Ιδ(ρ
ν
σ
π P
L
υ
ιιεα
α
δλ
ψ
νA
ν
2
γY
_Π
!
∋
?
>
≥υ
µ
=
Ν
<
3
0
απ
α
τ
_
ο
σ
τ
⇒
δ
ι
π
λ
ν
ρ
ε
δρ
ι
ν
γ
(
δ
α
ψ
1
!
∋
=
ι
ν
γ
?
″ο
σ
ε
)
∀
Σ
υ
γ
3
0
⇒∧
α
ρ
λ
ο
ω
∀
∨
η
ι
γ
δ
σ
π
α
ψ1
!
∋
=
∀
ΟΚ
∀
)
Λ Ρ Μ
Output schemas

∆
Ι(ρν
ιεασ
υλν _
Πυ
µ
δινγ?<
3π
∨
ρ
ε
α
δ
ιν
γ
?
>3
0
)
⇒α
λ
ρ
µ
!
≥∧″ φ∋
=
ο
ν
∨
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  37
Schema consistency
● It is important that schemas are consistent. 
Inconsistency suggests a problem with the system 
requirements
● The INSULIN_PUMP schema and the 
DISPLAYare inconsistent
• display1! shows a warning message about the insulin reservoir 
(INSULIN_PUMP)
• display1! Shows the state of the blood sugar (DISPLAY)
● This must be resolved before implementation of 
the system 

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  38

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  39

Key points
● Formal specification techniques are most 
applicable in the development of critical systems 
and standards.
● Algebraic techniques are suited to interface 
specification where the interface is defined as a 
set of object classes
● Model­based techniques model the system using 
sets and functions. This simplifies some types of 
behavioural specification

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 9  Slide  40