Lesson 01 - Formal Specification

1.0 Introduction

In the Second Week of Advanced Software Engineering course, you will learn how
to find the formal specification in software development process as well as where
you are going to apply formal specification in the development stage. And also you
will learn the techniques of formal specification and how they remove areas of
doubt in a specification and avoid some problems of language misinterpretation.
The principal value of using formal methods in the software process is that it
forces an analysis of the system requirements at an early stage. Correcting errors
at this stage is cheaper than modifying a delivered system.

Formal specification techniques are most cost – effective in the development of

critical systems where safety, reliability and security are particularly important.
They may also be use to specify standards.

Learning outcomes

After completion of this lesson you will be able to

• Describe how formal specification techniques are used in critical system
development.
• Reason out how formal specifications help avoiding ambiguous
requirements.
• Justify why formal specification techniques help discover problems in
system requirements.
• Use algebraic techniques for interface specification.

• Describe the use of model-based techniques for behavioural specification.

• Apply model-based techniques for behavioural specification.

Formal Specification Page 1 of 13

Formal Methods

Formal specification is part of a more general collection of techniques that are

known as ‘formal methods’.

Formal methods are used to refer to any activities that rely on mathematical
representations of software including formal system specification, specification
analysis and proof, transformational development, and program verification. All of
these activities are dependent on a formal specification of the software.

1.1 Formal Specification in the Software Process

Critical System development usually involves a plan-based software process

that is based on the waterfall model of development. Both the system
requirements and the system design are expressed in detail and carefully
analyzed and checked before implementation begins.

If a formal specification of the software is developed, this usually comes

after the system requirements have been specified but before the detail
system design. Figure 1.1 shows the relative position of Formal Specification
within the flow of Software Design

Specified the Formal Detail System

System Specification Design
Requirement
s

Figure 1.1 Stage of specifying formal specification in software

development process

As details of the specification are developed specification also increases.

In such a situation, you have to create a formal specification for making

detailed system analysis to reveal errors and inconsistencies in the informal

Formal Specification Page 2 of 13

 requirement specification. This error detection is probably the most potent
argument for developing a formal specification.

It helps you to discover requirements problems that can be very expensive

to correct later.

Depending on the process used, specification problems discovered during

formal analysis might influence changes to the requirement specifications if
this has not already been agreed. If the requirement specification has been
agreed and is included in the system development contract, you should raise
the problems that you have found with the customer. It is then up to the
customer to decide how they should be resolved before you start the system
design process.

Developing and analyzing a formal specification front-leads software

development costs.

Figure 1.2 Development costs with formal specification

Formal Specification Page 3 of 13

 Two fundamental approaches to formal specifications have been used to
write detailed specifications for industrial software systems.

I. An algebraic approach
System is described in terms of operations and their relationship.

II. Model–based approach

Model of the system is built using mathematical constructs such as sets
and sequences, and the system operations are defined by how they
modify the system state.

Different languages have been developed to specify sequential and

concurrent systems using these models.

Table 1.1 examples of the languages in each of these classes

Sequential Concurrent
Algebraic Larch (Guttag et al., Lotos (Bolognesi and
1993) Brinksma, 1987)
Model - based OBJ(Futatsugi et al., CSP (Hore, 1985)
1985) Pertri Nets
(Perterson, 1981)

Table 1.1 shows examples of the languages developed for each of these
models. You can see from this table the most of these languages were
developed in the 1980s.

It takes several years to refine a formal specification language, so most

formal specification research is now based on these languages and is not
concerned with inventing new notations.

1.2 Sub – system Interface Specification

Large Systems are usually decomposed into sub – systems that are
developed independently. Sub-systems make use of other sub system, so an

Formal Specification Page 4 of 13

 essential part of the specification process is to define sub – system
interfaces. Once the interfaces are agreed and defined the sub systems can
then be designed and implemented independently.

Sub–system interfaces are often defined as a set of objects or components.

Figure 1.3 Sub-system interfaces

This describes the data and operation that can be accessed through the sub-
system interface. You can therefore define a sub-systems interface
specification by combining the specification of the objects that make up the
interface.

Precise sub–system interface specification are important because sub–system

developers must write code that uses the services of other sub systems
before these have been implemented.

The interface specification provides information for sub system developers

so they know what services will be available in other sub systems and how
these can be accessed.

Clear and unambiguous sub–system interface specifications reduce the

chances of misunderstanding between a sub–system providing some service
and the sub-systems using that service.

Formal Specification Page 5 of 13

 The algebraic approach was originally designed for the definition of abstract
data type interfaces. In an abstract data type, the type is defined by
specifying the type operation rather than the type representation.
Therefore, it is similar to an object class. The algebraic method of formal
specification defines the abstract data type in terms of relationship
between the type operations.

The structure of an algebraic specification

<SPECIFICATION NAME>

sort <name>
Imports<LIST OF SPECIFICATION NAMES>

Informal description of the sort 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

The body of the specification has four components

Introduction
An Introduction declares the sort (the type name) of the entity being
specified. A sort is the name of a set of objectives with common
characteristics. It is similar to a type in a programming language. The
introduction may also include an ‘imports’ declaration, where the names of
specification defining other sorts are declared. Importing a specification
makes these sorts available for use.

Formal Specification Page 6 of 13

 Description
A description part, where the operations are described informally. This
makes the formal specification easier to understand. The formal
specification complements this description by providing an unambiguous
syntax and semantics for the type operations.

Signature
The signature part defines the syntax of the interface to the object class or
abstract data type. The names of the operations that are defined, the
number and sorts of their parameters, and the sort of operation results are
described in the signature.

Axioms
The axioms part defines the semantics of the operations by defining a set of
axioms that characterize the behaviour of the abstract data type. These
axioms relate the operations used to construct entities of the defined sort
with operations used to inspect its values.

The process of developing a formal specification of a sub–system interface

includes the following activities
• Specification structuring
• Specification naming
• Operation selection
• Informal operation specification
• Syntax definition
• Axiom

Formal Specification Page 7 of 13

 The example of a simple data structure (a linked list) given bellow explains
the technique of algebraic specification.

LIST (Elem)
sort List
imports INTEGER

Defines a list where elements are added at the end and

removed from the front. The operations are Create,
which brings an empty list into existence, Cons, which
creates a new list with an added member, Length, which
evaluates the list size, Head, which evaluates the front
elements of the list, and Tail, which creates a list by
removing 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) = Undefined exception (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 (Cons (L,v)) = if L = Create then else Con (Tail (L), v)

Operations on an abstract data type usually fall into two classes.

• Constructor operations
This creates or modify entities of the sort defined in the specification.
Typically, these are given names such as Create, Update, Add or, in this
case, Cons, meaning construct.

• Inspection operations
This evaluates attributes of the sort defined in the specification.
Typically, these are given names such as Eval or Get.

Formal Specification Page 8 of 13

1.3 Behavioral specification

The simple algebraic technique described above can be used to describe

interfaces where the object operations are independent of the object state.
That is, the results of applying an operation should not depend on the
results of previous operations. Where this condition does not hold, algebraic
techniques can become cumbersome. Furthermore, as they increase in size,
that algebraic descriptions of system behavior become increasingly difficult
to understand.

An alternative approach to formal specification that has been more widely

used in industrial projects is model-based specification. Model-based
specification is an alternative to formal specification where the system
specification is expressed as a system state model.

The Z notation is a mature technique for model – based specification. It

combines formal and informal description and uses graphical highlighting
when presenting specification.

The structure of a Z schema

Schema name Schema signature Schema predicate

Container
contents : N
capacity : N

Contents”< capacity

Modeling the insulin pump

Formal Specification Page 9 of 13

 The Z schema for the insulin pup declares a number of state variables
including:
Input variables such as switch? (the device switch), InsulinReservoir? (the
current quantity of insulin in the reservoir) and Reading? (the reading from
the sensor);
Output variables such as alarm! ( a system alarm), display1!, display2! (the
displays on the pump) and dose!(the dose of insulin to be delivered).

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 4 units of insulin and the total
delivered in a time period must not exceed 25 units of insulin.
This is a safety constraint;

Display2! shows the amount of insulin to be delivered.

Insulin pump schema

INSULIN_PUMP_STATE
// Input device definition
Switch?:(off, manual, auto)
ManualDeliveryButton?:N
Reading?:N
HardwareTest?: (OK, batterylow, pumpfail, sensorfail, deliveryfail)
InsulinReservoir?:(present, notpresent)
Needle?: (present, notpresent)
Clock?:TIME
//Output device definition
alarm! = (on, off)

Formal Specification Page 10 of 13

 display1!, string
display2!:string
clock!: TIME
dose!: N
// State variables used for dose computation
status: (running, warning, error)
r0, r1, r2:N
capacity, insulin_available : N
max_daily_dose, max_single_dose, minimum_dose: N
safemin, safemax : N
CompDose, cumulative_dose: N

State invariants
R2 = Reading?
Dose< insulin_available
Insulin_available < capacity
//The cumulative dose of insulin delivered is set to zero once every 24
hours
Clock? = 000000 cumulative_dose = 0
//If the cumulative does exceeds the limit then operation is suspended
Cumulative dose > max_daily_dose ^ status = error ^

Display1! = “ Daily dose exceeded”

// Pump configuration parameters
Capacity = 100 ^ safemin = 6 ^ safemax =14
Max_daily_dose = 25 ^ max_single_dose = 4 ^ minimum_dose = 1
display2! = nat_to_string(dose!)
clock! = clock?

Formal Specification Page 11 of 13

 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.

Run Schema

INSULIN_PUMP_STATE

switch? = auto_
status = running v status = warning
Insulin_available > max_single_dose
cumulative_dose < max_daily_dose

//The dose of insulin is computed depending on the blood sugar level

(SUGAR_LOW V SUGAR_OK V SUGAR_HIGH)

//1. If the computed insulin dose is zero, don’t deliver any insulin

CompDose = 0 dose! = 0

V
//2. The maximum daily dose would be exceed if the computed dose was
delivered so the insulin dose is set to the difference between the maximum
allowed daily dose and the cumulative dose delivered so far

CompDose + cumulative_dose > max_daily_dose alarm! = on ^ status’

= warning ^ dose! = max_daily_dose-cumulative_dose
V

//3.The normal situation. If maximum single dose is not exceeded then

deliver the computed dose. If the single dose computed is too high, restrict
the dose delivered to the maximum single dose.

CompDose + cumulative_dose < max_daily_dose

(CompDose < max_single_dose dose! = CompDose
V

Formal Specification Page 12 of 13

 CompDose > max_single_dose dose! = max_single_dose )

Insulin_available’ = insulin_available – dose!

Cumulative_dose’ = cumulative_dose + dose!

Insulin_available < max_single_dose*4 status’ = warning^

display1! = “Insulin low”

r1’ = r2
r0’ = r1

SUGAR OK schema

r2 > safemin V r2 ^ safemax

// sugar level stable or falling

r2 < r1 CompDose = 0

// sugar level increasing but rate of increase falling

r2 >r1 ^ (r2 – r1) < (r1 – r0) CompDose = 0

//sugar level increasing and rate of increase and rate of increasing

compute dose
// a minimum dose must be delivered if rounded to zero

r2>r1 ^ ( r2 – r1)> (r1-r0) ^ (round ((r2 –r1/4) = 0 )

CompDose = minimum_dose

r2>r1 ^ ( r2 – r1)> (r1-r0) ^ (round ((r2 –r1/4) > 0 )

CompDose = round ((r2 –r1/4)

Summary
In this chapter we discussed about formal specification techniques
that can be used to add details to a system requirements
specification in detail such as how we use algebraic techniques for
interface specification, and describe the use of model – based
techniques for behavioural specification, and also how to apply
model – based techniques for behavioural specification.

Formal Specification Page 13 of 13