Chapter 9
Formal Specifications
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 1
Formal Specification

Techniques for the unambiguous
specification of software
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 2
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 3
Topics covered



Formal specification in the software process
Interface specification
Behavioural specification
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 4
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 5
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 6
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 7
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 8
Specification and design
Increasing contractor involvement
Decreasin g client involvement
Requir ements
definition
Requir ements
specification
Architectur al
design
Software
specification
High-level
design
Specification
Design
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 9
Specification in the software
process
Requirements
specification
Formal
specification
Requirements
definition
High-le vel
design
System
modelling
©Ian Sommerville 2000
Ar chitectural
design
Software Engineering, 6th edition. Chapter 9
Slide 10
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 11
Formal specification languages
Algebraic
Model-based
©Ian Sommerville 2000
Sequential
Larch (Guttag, Horning et
al., 1985; Guttag,
Horning et al., 1993),
OBJ (Futatsugi, Goguen
et al., 1985)
Z (Spivey, 1992)
VDM (Jones, 1980)
B (Wordsworth, 1996)
Concurrent
Lotos (Bolognesi and
Brinksma, 1987),
CSP (Hoare, 1985)
Petri Nets (Peterson,
1981)
Software Engineering, 6th edition. Chapter 9
Slide 12
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 13
Development costs with formal specification
Cost
Validation
Design and
Implementation
Validation
Design and
Implementation
Specification
Specification
Without formal
specification
©Ian Sommerville 2000
With formal
specification
Software Engineering, 6th edition. Chapter 9
Slide 14
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 15
Sub-system interfaces
Interface
objects
Sub-system
A
©Ian Sommerville 2000
Sub-system
B
Software Engineering, 6th edition. Chapter 9
Slide 16
The structure of an algebraic specification
< SPECIFICATION NAME > (Gener ic Parameter)
sort < name >
imports < LIST OF SPECIFICATION NAMES >
Informal descr iption of the sor t and its operations
Operation signatures setting out the names and the types of
the parameters to the operations defined over the sort
Axioms defining the operations over the sort
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 17
Specification components

Introduction
•

Description
•

Informally describes the operations on the type
Signature
•

Defines the sort (the type name) and declares other
specifications that are used
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 18
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 19
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 20
Operations on a list ADT

Constructor operations which evaluate to sort
List
•

Inspection operations which take sort list as a
parameter and return some other sort
•

Create, Cons and Tail
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 21
List specification
LIST ( Elem )
sort List
imports INTEGER
Defines a list where elements are added at the end and remo
ved
from the front.
The operations are Create
, which brings an empty list
into existence, Cons, which creates a ne
w list with an added member
,
Length, which valuates
e
the list siz
e, Head, which valuates
e
the front
element of the list, and
Tail, which creates a listybremoving 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
Tail (List) ® List
Head (Create) = Undefinedexception(empty list)
Head (Cons (L, v)) = if L = Create then v else Head (L)
Length (Create) = 0
Length (Cons (L, v)) = Length (L) + 1
Tail (Create ) = Create
Tail (Cons (L, v)) =if L = Create then Create else Cons (Tail (L), v)
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 22
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 23
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 24
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 25
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 26
Sector specification
SECTOR
sort Sector
imports INTEGER, BOOLEAN
Enter - adds an aircraft to the sector if safety conditions are satisfed
Leave - removes an aircraft from the sector
Mo ve - moves an aircraft from one height to another if safe to do so
Lookup - Finds the height of an aircraft in the sector
Cre ate - creates an empty sector
Put - adds an aircraft to a sector with no constraint checks
In-space - checks if an aircraft is already in a sector
Occupied - checks if a specified height is available
Enter (Sector, Call-sign, Height)  Sector
Leave (Sector, Call-sign)  Sector
Mo ve (Sector, Call-sign, Height)  Sector
Lookup (Sector, Call-sign)  Height
Cre ate  Sector
Put (Sector, Call-sign, Height)  Sector
In-space (Sector, Call-sign)  Boolean
Occupied (Sector, Height)  Boolean
Enter (S, CS, H) =
if
In-space (S, CS ) the n S exception (A ircraft already in sector)
elsif Occupied (S, H) the n S exception (Height conflict)
else Put (S, CS, H)
Leave (Create, CS) = Create exception (A ircraft not in sector)
Leave (Put (S, CS1, H1), CS) =
if CS = CS1 the n S else Put (Leave (S, CS), CS1, H1)
Mo ve (S, CS, H) =
if
S = Create the n Create exception (No aircraft in sector)
elsif not In-space (S, CS) the n S exception (A ircraft not in sector)
elsif Occupied (S, H) the n S exception (Height conflict)
else Put (Leave (S, CS), CS, H)
-- NO-HEIGHT is a co nstant indicating that a valid height cannot be returned
Lookup (Create, CS) = NO-HEIGHT exception (A ircraft not in sector)
Lookup (Put (S, CS1, H1), CS) =
if CS = CS1 the n H1 else Lookup (S, CS)
Occupied (Create, H) = false
Occupied (Put (S, CS1, H1), H) =
if
(H1 > H and H1 - H Š 300) or (H > H1 and H - H1 Š 300) the n true
else Occupied (S, H)
In-space (Create, CS) = false
In-space (Put (S, CS1, H1), CS ) =
if CS = CS1 the n true else In-space (S, CS)
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 28
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 modelbased specification. It combines formal and
informal description and uses graphical
highlighting when presenting specifications
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 29
The structure of a Z schema
Schema name
Schema signature
Schema predicate
Container
c ontents :
c apac ity :
c ontents Š c apac ity
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 30
An insulin pump
Ins ulin res erv oir
Needle
ass embly
Pump
Cloc k
Sens or
Controller
Alarm
Display1
Display2
Pow er s upply
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 31
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 32
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 33
Insulin pump schema
Insulin_pump
reading? :
dose, cumulative_dose:
r0, r1, r2:
// used to record the last 3 readings taken
capacity:
alarm!: {off, on}
pump!:
display1!, display2!: STRING
dose Š capacity  dose Š 5  cumulative_dose Š 50
capacity • 40  display1! = " "
capacity Š 39  capacity •10  display1! = "Insulin low"
capacity Š 9  alarm! = on display1! = "Insulin very low"
r2 = reading?
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 34
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 35
DOSAGE schema
DO SAGE
Insulin_Pump
(
dose = 0 
 (
 r1 •r0) ( r2 = r1)) 
(( r1 > r0)  (r2 Š r1)) 
(( r1 < r0)  ((r1-r2) > (r0-r1)))
) 
dose = 4 
(
(( r1 Š r0)  (r2 =r1)) 
(( r1 < r0)  ((r1-r2) Š (r0-r1)))
) 
dose =(r2 -r1) * 4 
(
(( r1 Š r0)  (r2 > r1)) 
(( r1 > r0)  ((r2 - r1) • (r1 - r0)))
)
)
capacity' = cap acity - dose
cumulative_dose' = cumulative_dose + dose
r0' = r1  r1 ' = r2
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 36
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 37
Output schemas
DISPLAY
Insulin_Pump
display2!' = Nat_to_string (dose) 
(reading? < 3  display1!' = "Sugar low" 
reading? > 30  display1!' = "Sugar high" 
reading? • 3 and reading? Š 30  display1!' = "OK")
ALARM
Insulin_Pump
( re ading? < 3  re ading? > 30 )  alarm!' = on 
reading? • 3 reading? Š 30 )  alarm!' = off
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 9
Slide 38
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 39
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 40
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 41