ch10.pps

7/29/2019 ch10.pps

1/41

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

Formal Specification

7/29/2019 ch10.pps

2/41


Objectives

To explain why formal specificationtechniques help discover problems in systemrequirements

To describe the use of algebraic techniquesfor interface specificationTo describe the use of model-based

techniques for behavioural specification

7/29/2019 ch10.pps

3/41


Topics covered

Formal specification in the software processSub-system interface specificationBehavioural specification

7/29/2019 ch10.pps

4/41


Formal methods

Formal specification is part of a more generalcollection of techniques that are known as formalmethods.

These are all based on mathematical representationand analysis of software.Formal methods include

Formal specification; Specification analysis and proof; Transformational development; Program verification.

7/29/2019 ch10.pps

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 than

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

7/29/2019 ch10.pps

6/41


Use of formal methods

The principal benefits of formal methods arein reducing the number of faults in systems.Consequently, their main area of applicabilityis in critical systems engineering. There havebeen several successful projects whereformal methods have been used in this area.

In this area, the use of formal methods ismost likely to be cost-effective because highsystem failure costs must be avoided.

7/29/2019 ch10.pps

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

Specification in the software process

Specification and design are inextricablyintermingled.

Architectural design is essential to structurea specification and the specification process.Formal specifications are expressed in amathematical notation with precisely defined

vocabulary, syntax and semantics.

7/29/2019 ch10.pps


Specification and design

7/29/2019 ch10.pps


Specification in the software process

7/29/2019 ch10.pps


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 of rework due to requirements problems isreduced .

7/29/2019 ch10.pps


Cost profile

The use of formal specification means thatthe 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 costsshould be reduced as the specification process

reduces errors and ambiguities in therequirements.

7/29/2019 ch10.pps


Development costs with formal specification

7/29/2019 ch10.pps


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 mathematicalconstructs such as sets and sequences.

Operations are defined by modifications to thesystems state.

7/29/2019 ch10.pps


Formal specification languages

Sequential Concurrent

Algebraic Larch (Guttag et al., 1993)},OBJ (Futatsugi et al.,1985)}

Lotos (Bolognesi andBrinksma, 1987)},

Model-based Z (Spivey, 1992)}VDM (Jones, 1980)}B (Wordsworth, 1996)}

CSP (Hoare, 1985)}Petri Nets (Peterson, 1981)}

7/29/2019 ch10.pps

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 or object classes.

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

7/29/2019 ch10.pps

16/41


Sub-system interfaces

7/29/2019 ch10.pps

17/41


The structure of an algebraic specification

sor t < n ame >

impo r ts < LIST OF SPECIFICATION NA MES >

Infor mal descr iption ofthesor t and its oper ations

Oper ationsignatures setting out the names and the types of the p arameters to th e op erations defin ed over th e so r t

Axioms defining the oper ations o ver the sor t

< SP ECIFICATION NA ME >

7/29/2019 ch10.pps

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.

Axioms Defines the operation semantics by defining axioms which

characterise behaviour.

7/29/2019 ch10.pps

19/41


Systematic algebraic specification

Algebraic specifications of a system may bedeveloped in a systematic way Specification structuring;

Specification naming; Operation selection; Informal operation specification; Syntax definition; Axiom definition.

7/29/2019 ch10.pps

20/41


Specification operations

Constructor operations . Operations whichcreate entities of the type being specified.Inspection operations . Operations whichevaluate entities of the type being specified.To specify behaviour, define the inspector operations for each constructor operation.

7/29/2019 ch10.pps

21/41


Operations on a list ADT

Constructor operations which evaluate tosort List Create, Cons and Tail.

Inspection operations which take sort list asa parameter and return some other sort Head and Length.

Tail can be defined using the simpler constructors Create and Cons. No need todefine Head and Length with Tail.

7/29/2019 ch10.pps

22/41


List specification

Head (Create) = Undefined exception (empty list )Head (Cons (L, v )) = i f L = Create then v else Head (L)Lengt h (Create) = 0Length (Cons (L, v)) = Leng th (L) + 1Tail (Create ) = CreateTail (Cons (L, v )) = i f L = Create then Creat e else Cons (Tail (L ), v)

sor t Listimpor ts INTEGER

Defines alist where elementsareadded at theend and remo vedfromthe f ront. Theoper ations are Create , which br ings an empty listinto e xistence , Cons , which creates a ne w list with an added member ,Leng th, which e valuates the l ist siz e, Head, which e valuates the f rontelement ofthe list, and Tail, which creates alist b y remo ving thehead fromits input list. Undef ined represents an undef ined value oftypeElem.

Create ListCons (List, Elem) ListHead (List) ElemLength (List) IntegerTail (L ist) List

LIST ( Elem )

7/29/2019 ch10.pps

23/41


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]

7/29/2019 ch10.pps

24/41


Interface specification in critical systems

Consider an air traffic control system where aircraftfly 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 300mis proposed.The system should warn the controller if aircraft are

instructed to move so that the separation rule isbreached.

7/29/2019 ch10.pps

25/41


A sector object

Critical operations on an object representinga controlled sector are Enter . Add an aircraft to the controlled airspace;

Leave . Remove an aircraft from the controlledairspace;

Move . Move an aircraft from one height toanother;

Lookup . Given an aircraft identifier, return itscurrent height;

7/29/2019 ch10.pps

26/41


Primitive operations

It is sometimes necessary to introduce additionaloperations to simplify the specification.The other operations can then be defined usingthese 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.

7/29/2019 ch10.pps

27/41


Sector specification (1)

sor t Sectorimpor ts INTEGER, BOOLE AN

Enter - adds an aircraft to t he sect or if safety condi tion s are sati sfedLeave - remo ves an ai rcraft from the sectorMove - moves an aircraft from one heig ht to ano ther if safe to do so

Lookup - Finds t he heigh t ofan aircraft in the sectorCreate - creates an empty secto rPu t - ad ds an aircraft to a sector wit h no constrain t ch ecksIn-space - checks if an ai rcraft is already in a sectorOccupied - checks if a specified h eight i s availabl e

Enter (Sector , Call -s ign, Heig ht) SectorLeave (Sector , Cal l-si gn) Sector

Move (Secto r , Call -s ign, Height ) SectorLook up (Secto r , Call -s ign) Height

Create SectorPu t (Sector , Call -s ign, Height ) SectorIn-space (Sector , Cal l -s ign) BooleanOccupied (Sector , Heigh t) Boolean

SECTOR

7/29/2019 ch10.pps

28/41


Sector specification (2)

Enter (S, CS, H) =if In-space (S, CS ) then S exception (A ircraft already in sector)elsif O ccupied (S, H) then S excep tion (H eight confli ct)else Pu t (S, CS, H)

Leave (Creat e, CS) = Create exception (A ircraft no t in s ecto r)Leave (Pu t (S, CS1 , H 1), CS) =

if CS = CS1 then S else Pu t (Leave (S, CS), CS1, H1)

Move (S, CS, H) =if S = Create then Create exception (No aircraft in sector)elsif not In-space (S, CS) then S exception (A ircraft not in s ector)elsif O ccupied (S, H) then S exception (H eight confli ct)else P ut (Leave (S, CS), CS, H)

-- NO -HEIGHT is a co nstant i ndic atin g that a valid hei ght cannot be returned

Lookup (Create, CS) = NO -HEIGHT exception (A ircraft not in sector)Look up (Pu t (S, CS1 , H1), CS) =

if CS = CS1 then H1 else Lookup (S, CS)

Occupied (Create, H) = falseOccupi ed (P ut (S, CS1, H1), H) =

i f (H1 > H and H1 - H 3 00) or (H > H1 and H - H1 3 00) then trueelse Occupied (S, H)

In-sp ace (Creat e, CS) = fals eIn-space (Pu t (S, CS1 , H 1), CS ) =

if CS = CS1 then true else In -space (S, CS)

7/29/2019 ch10.pps

29/41


Specification commentary

Use the basic constructors Create and Put tospecify other operations.Define Occupied and In-space using Create and Put and use them to make checks inother operation definitions.

All operations that result in changes to the

sector must check that the safety criterionholds.

7/29/2019 ch10.pps

30/41


Behavioural specification

Algebraic specification can be cumbersome whenthe object operations are not independent of theobject state.Model-based specification exposes the system stateand defines the operations in terms of changes tothat state.The Z notation is a mature technique for model-based specification. It combines formal and informaldescription and uses graphical highlighting whenpresenting specifications.

7/29/2019 ch10.pps

31/41


The structure of a Z schema

7/29/2019 ch10.pps

32/41


Modelling the insulin pump

The Z schema for the insulin pump declaresa number of state variables including: Input variables such as switch? (the device

switch), InsulinReservoir? (the current quantityof insulin in the reservoir) and Reading? (thereading from the sensor);

Output variables such as alarm! (a system

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

7/29/2019 ch10.pps

33/41


Schema invariant

Each Z schema has an invariant part which definesconditions 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 andthe total dose delivered in a time period must not exceed25 units of insulin. This is a safety constraint;

display2! shows the amount of insulin to be delivered.

7/29/2019 ch10.pps

34/41


Insulin pump schemaINSULIN_PUMP_STATE

//Input device definition

switch?: (off, manual, auto)ManualDel iveryButton?: NReading?: NHardwareTest?: (OK, batterylow, pumpfail, sensorfail, deliveryfail)InsulinReservoir?: (present, notpresent)

Needle?: (present, notpresent)clock?: TIME

//Output device definition alarm! = (on, off)display1!, stringdisplay2!: stringclock!: TIMEdose!: N

// State variables used for dose comp utation status: (running, warning, error)r0, r1, r2: Ncapacity, insulin_available : Nmax_daily_dose, max_single_dose, minimum_dose: Nsafemin, safemax: NCompDose, cumulative_dose: N

7/29/2019 ch10.pps

35/41


State invariants

r2 = Reading?dose! insulin_availableinsulin_available capacity

// The cumulative dose of insul in delivered is set to zero once every 24 hours

clock? = 000000 cumulative_dose = 0

// If the cumu lative dose 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 = 14max_daily_dose = 25 max_single_dose = 4 minimum_dose = 1

display2! = nat_to_string (dose!)clock! = clock?

7/29/2019 ch10.pps

36/41


The dosage computation

The insulin pump computes the amount of insulinrequired by comparing the current reading with twoprevious readings.If these suggest that blood glucose is rising theninsulin is delivered.Information about the total dose delivered ismaintained to allow the safety check invariant to beapplied.Note that this invariant always applies - there is noneed to repeat it in the dosage computation.

7/29/2019 ch10.pps

37/41


RUN schema (1)

RUNINSULIN_PUMP_STATE

switch? = autostatus = running status = warninginsulin_available max_single_dosecumulative_dose < max_daily_dose

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

(SUGAR_LOW SUGAR_OK SUGAR_HIGH )

// 1. If the computed insulin dose is zero, do nt deliver any insulin

CompDose = 0 dose! = 0

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

CompDose + cumulative_dose > max_daily_dose alarm! = on status = warning dose! =max_daily_dose cumulative_dose

7/29/2019 ch10.pps

38/41

7/29/2019 ch10.pps

39/41


Sugar OK schema

SUGAR_OKr2 safemin 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 increasing comp ute 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)

7/29/2019 ch10.pps

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.

7/29/2019 ch10.pps

41/41

Key points

Algebraic techniques are suited to interfacespecification where the interface is definedas a set of object classes.

Model-based techniques model the systemusing sets and functions. This simplifiessome types of behavioural specification.Operations are defined in a model-basedspec. by defining pre and post conditions onthe system state.

ch10.pps

Documents