sws-introduction 1 software specification introduction lambert meertens
TRANSCRIPT
SWS-Introduction 1
Software Specification
Introduction
Lambert Meertens
SWS-Introduction 2
Why specifications?
Suppose we place a mail order for a nut with one supplier, and for a bolt with another supplier.
How can we know that the nut will fit the bolt, other than by trying?
If we have specifications of the nut and the bolt, we should be able to find the answer.
SWS-Introduction 3
Basically everything that is relevant — which depends on the context.
For a bolt:• outer/inner diameter
• speed
• length
• shape of the head
• material
• . . .
What properties are specified?
} all within aspecifiedtolerance
For determining whether a nut fits a bolt, the shape of the head is not relevant.It may be relevant for other purposes.
SWS-Introduction 4
What is relevant for software?
“Observable” properties
Usually: the input-output relation(what output can correspond to what input)
Sometimes: timing properties(response is given within W milliseconds)
Rarely: other resource use(bytes of RAM, stack space, program size)
SWS-Introduction 5
Specifications must be precise
Given a specification S and a proposed implementation I, it must be possible to determine the answer to the question:
Is S satisfied by I?
The answer should be “yes” or “no” — no “maybe’s”!
Notation: S╞ I
SWS-Introduction 6
Simplest to specify: functions
One (or at most one) output to every given input.
Example:sqrt :: Real(0) → Real(0)
x,y : y sqrt x x yy
Q: What is problematic about this spec?
SWS-Introduction 7
Simple to specify: relations
Zero or more possible outputs to any given input.
Example:
rootOf :: Real Real(0)
x,y : y rootOf x x yy
SWS-Introduction 8
More challenging to specify: reactive systems
Reactive systems can be “interactive” (with a user in the loop), but also a component in embedded software (such as a plant control).
Specification approaches:• automaton (states & input/output transitions)
• relation between input and output traces
• predicate on input/output traces
SWS-Introduction 9
Inconsistent specifications
A specification that has no solutions is called “inconsistent”.
Example:
intSqrt :: Nat → Nat
x,y : y intSqrt x x yy
SWS-Introduction 10
Underspecification
A specification may allow several solutions.
Example:
Errable A : Result AException String
intSqrt :: Nat → Errable Nat
x,y : Result y intSqrt x x yy
Q: What can we say about intSqrt 2 ?
SWS-Introduction 11
Overspecification
A specification may fix details that are irrelevant, or may unduly constrain the solutions.
Example:“The Unlock signal shall be fired 500 msec after the Verified event.”
Better:“. . . within 500 msec after . . .”“. . . between 450 and 550 msec after . . .”
SWS-Introduction 12
Compositionality
Given composition operators we want to use, relevant properties are also those needed to determine relevant properties of the composite.
Conversely, useful composition operators allow us to determine relevant properties.
f g g•f
SWS-Introduction 13
Refinement
Specification S is refined by specification R when every implementation of R is an implementation of S, or, in symbols:
S R : I : R╞ I S╞ I
The relation is reflexive and transitive.
Specifications that are each other’s refinement are called equivalent.