Software Engineering Chapter (10)

8/3/2019 Software Engineering Chapter (10)

1/41

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 10 Slide 1

Formal Specification


2/41


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 forbehavioural specification


3/41


Topics covered

Formal specification in the software process

Sub-system interface specification

Behavioural specification


4/41


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 representationand analysis of software.

Formal methods include

Formal specification;

Specification analysis and proof; Transformational development;

Program verification.


5/41


Acceptance of formal methods

Formal methods have not become mainstreamsoftware development techniques as was oncepredicted Other software engineering techniques have been

successful at increasing system quality. Hence the needfor formal methods has been reduced;

Market changes have made time-to-market rather thansoftware with a low error count the key factor. Formalmethods do not reduce time to market;

The scope of formal methods is limited. They are not well-suited to specifying and analysing user interfaces anduser interaction;

Formal methods are still hard to scale up to largesystems.


6/41


Use of formal methods

The principal benefits of formal methods are

in reducing the number of faults in systems.

Consequently, their main area of applicability

is in critical systems engineering. There have

been several successful projects where

formal methods have been used in this area.

In this area, the use of formal methods ismost likely to be cost-effective because high

system failure costs must be avoided.


7/41


Specification in the software process

Specification and design are inextricably

intermingled.

Architectural design is essential to structure

a specification and the specification process.

Formal specifications are expressed in a

mathematical notation with precisely defined

vocabulary, syntax and semantics.


8/41


Specification and design


9/41


Specification in the software process


10/41


Use of formal specification

Formal specification involves investing moreeffort in the early phases of softwaredevelopment.

This reduces requirements errors as it forcesa detailed analysis of the requirements.

Incompleteness and inconsistencies can bediscovered and resolved.

Hence, savings as made as the amount ofrework due to requirements problems isreduced.


11/41


Cost profile

The use of formal specification means that

the cost profile of a project changes

There are greater up front costs as more time

and effort are spent developing thespecification;

However, implementation and validation costs

should be reduced as the specification process

reduces errors and ambiguities in therequirements.


12/41


Development costs with formal specification


13/41


Specification techniques

Algebraic specification

The system is specified in terms of its

operations and their relationships.

Model-based specification

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 thesystems state.


14/41


15/41


Interface specification

Large systems are decomposed into subsystemswith well-defined interfaces between thesesubsystems.

Specification of subsystem interfaces allowsindependent development of the differentsubsystems.

Interfaces may be defined as abstract data types orobject classes.

The algebraic approach to formal specification isparticularly well-suited to interface specification as itis focused on the defined operations in an object.


16/41


Sub-system interfaces


17/41


The structure of an algebraic specification


18/41


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.

A

xioms Defines the operation semantics by defining axioms whichcharacterise behaviour.


19/41


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.


20/41


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.


21/41


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 simplerconstructors Create and Cons. No need to

define Head and Length with Tail.


22/41


List specification


23/41


24/41


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 isbreached.


25/41


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 itscurrent height;


26/41


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.


27/41


Sector specification (1)


28/41


Sector specification (2)


29/41


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 criterionholds.


30/41


31/41


The structure of a Z schema


32/41


Modelling the insulin pump

The Z schema for the insulin pump declares

a number of state variables including:

Input variables such as switch? (the device

switch), InsulinReservoir? (the current quantityof insulin in the reservoir) and Reading? (the

reading from the sensor);

Output variables such as alarm! (a system

alarm), display1!, display2! (the displays on thepump) and dose! (the dose of insulin to be

delivered).


33/41


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 theinsulin reservoir;

No single dose may be more than 4 units of insulin and

the total dose 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.


34/41


Insulin pump schema

INS ULIN_ PUM P _S TAT E

//Inpu t device de finition

switch ?: (off, m anu al, auto)M anu alDe liver yButton?: NR eading?: NH ardwareTe st?: (OK, batter ylow, pump fai l , se nsor fai l, del iveryfail )InsulinR eservoir?: (present, notpresent)N eedle?: (present, notpresent)clock?: TIME

//Ou tput dev ice d efinition

alarm ! = (on, o ff)display1!, stringdisplay2!: stringclock!: TIMEdose!: N

// State v ariables use d for dose c omp utat ion

status: (running, warning, error)r0, r1, r2: Ncapacity, insulin_available : Nm ax_da ily_dose, m ax_single_dose , mi nimum _dose: Nsafem in, saf em ax: NC ompD ose, cum ula tive_d o se : N


35/41


State invariants

r2 = R eading?

dose ! insul in_avai lableinsulin_avai lable capaci ty

/ / The cum ulat ive d ose of in su lin de live re d is set to zero o nce every 24 h ours

clock? = 000000cumulat ive_do se = 0

/ / If t he cumu lative do se e xceed s the li m i t then o perat ion is susp end ed

cumulat ive_dose m ax_da ily_dosestatus = errordisplay1!= Da ily dose e xceed ed

/ / Pu m p conf igura tion pa ram eters

capa city = 1 00 safemin = 6 sa fema x = 1 4m ax_daily_dose = 25 ma x_sing le_d ose = 4 min imu m_dos e = 1

disp lay2! = n at_t o_str ing (dose!)clo ck! = cloc k?


36/41


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 theninsulin 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.


37/41


RUN schema (1)

R U N

(INS ULIN_ PUM P_S TAT E

swi tch? = autostatus = runn ingstatus = w arning

insul in_

avai lable m ax_

single_

dosecumulat ive_dose < m ax_daily_dose

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

(SUGAR _LO W SUGAR _OK SUGAR _HIGH )

// 1 . If the compu ted i nsul in do se is zero , dont d el iver any ins ul in

C omp Dose = 0 dose! = 0

// 2. T he m aximu m dai ly dose would be excee ded if the comp uted dos e wa s delivered so the insulindose is set to the d if ference betwe en the max imum a llow ed dai ly do se and the cum ulative dosedelivered so far

C o mp Do s e + cumulat ive_dose > m ax_daily_dosealarm ! = o nstatus = warning dose ! =m ax_daily_dose cum ulat ive_d o s e


38/41


RUN schema (2)

// 3. T he n orma l s itua t ion. If max imum s ingle dose is not exceeded then del iver the computed dose. Ifthe sing le dose c omp uted is too high , res trict the d ose del ivered to the m aximum sin gle d ose

C omp Dose + c umu la ti ve_dose < m ax_daily_dose

( C om pDo se max_s ingle_dose

dose! = C om pDo seC omp D os e > ma x_sing le_d o s edose ! = m ax_single_dose )

insulin_av ai lable = insulin_av ai lab le dose!cumulat ive_dose = cumulat ive_do se + dose!

insulin_av ai lable ma x_single_dose * 4 status = w arningdispla y1! = Insul in l ow

r1 = r 2r0 = r 1


39/41


SugarOK schema

SUGAR _OKr2 sa fem inr2 safem ax

// s uga r leve l stab le or falling

r2 r1 C omp Dose = 0

// s uga r leve l in creas ing b ut rate of increa se falling

r2 > r1 (r2-r1) < (r1- r0) C omp Dose = 0

/ / su gar leve l increas ing a nd rate of in crease i ncreas ing c omp ute do se

// a minimum d ose mu st b e de livered if rounded to zero

r2 > r1

(r2-r1)

(r1-r0)

(round ( (r2-r1) /4) = 0 )

C omp Dose = m in imum_dose

r2 > r1 (r2-r1) (r1-r0) (round ((r 2-r1) /4 ) > 0 ) C omp Dose = r ound (( r2-r1) /4)


40/41


Key points

Formal system specification complements informalspecification techniques.

Formal specifications are precise and unambiguous.They remove areas of doubt in a specification.

Formal specification forces an analysis of thesystem requirements at an early stage. Correctingerrors at this stage is cheaper than modifying adelivered system.

Formal specification techniques are most applicablein the development of critical systems andstandards.


41/41


Key points

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 ofbehavioural specification.

Operations are defined in a model-basedspec. by defining pre and post conditions on

the system state.

Documents

Software Engineering Chapter (10)