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.