CH 9

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 modelbased techniques
for behavioural specification

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

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

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 timetomarket 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
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 costeffective

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.

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
idghslenvl
Specification and design
D esign
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
Specification techniques
● Algebraic approach
• The system is specified in terms of its operations and their
relationships
● Modelbased 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

Formal specification languages

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

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 welldefined 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 wellsuited to interface specification
S
ubsA I
n
t
e
r
f
a
o
b
jc
e
t
s
ytem S ubsB
Subsystem interfaces
ytem
< 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

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

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

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

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.

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]

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

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

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
• Inspace. Determine if a given aircraft is in the sector
• Occupied. Given a height, determine if there is an aircraft
within 300m of that height

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
fcs 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 Inspace 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

Behavioural specification
● Algebraic specification can be cumbersome when
the object operations are not independent of the
object state
● Modelbased 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
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

Insu
Need
Cl
Pum
assem
Con
Al
Sens
An insulin pump
Dis
Disp
Pow
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
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.

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
!
=!
=
∀
Ι
ν
σ∀
Ι
ν
σ
υ
λ
ι
ν
υ
λ
ι
ϖ
εο
ω
ρ
ψ
λ∀
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
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
)
σ
ε
+
δο
σ
ε
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

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

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

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
● Modelbased techniques model the system using
sets and functions. This simplifies some types of
behavioural specification

CH 9

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CH 9

Hochgeladen von

Copyright:

Verfügbare Formate

Formal Specification

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Das könnte Ihnen auch gefallen