11_ch10

8/3/2019 11_ch10

1/50

1 Note content copyright 2004 Ian Sommerville. NU-specific content 2004 M. E. Kabay. All rights reserved.

FormalSpecificationIS301 Software Engineering

Lectures # 11&12 2004-09-24&27M. E. Kabay, PhD, CISSP

Assoc. Prof. Information AssuranceDivision of Business & Management, Norwich University

mailto:[email protected] V: 802.479.7937

8/3/2019 11_ch10

2/50

8/3/2019 11_ch10

3/50


Topics

Formal specification in the software process

Sub-system interface specification

Behavioral specification

We will use __ of Prof Sommervilles slides

today in our overview of this topic.

More on Friday during the Formal

Specification Workshop.

8/3/2019 11_ch10

4/50


Formal Methods

Formal specification part of more generalcollection of techniques that known asformal methods

These all based on mathematicalrepresentation and analysis of software

Formal methods include

Formal specification

Specification analysis and proof Transformational development

Program verification

8/3/2019 11_ch10

5/50


Poor Acceptance ofFormal Methods

Have not become mainstream softwaredevelopment techniques (as was oncepredicted)

Other software engineering techniques havebeen successful at increasing system quality

Market changes time-to-market rather thansoftware with low error count as key factor

Scope of formal methods limited not well-

suited to specifying and analyzing userinterfaces and user interaction

Formal methods hard to scale up to largesystems

8/3/2019 11_ch10

6/50


Use of Formal Methods

Formal methods have limited practicalapplicability

Principal benefits:

Reducing number of errors in systemsMain area of applicability: critical systems

In this area, use of formal methods mostlikely to be cost-effective

8/3/2019 11_ch10

7/50


Specification in theSoftware Process

Specification and design inextricablyintermingled

Architectural design essential to structure

specificationFormal specifications

Expressed in mathematical notation

Precisely defined

vocabularysyntax

semantics

8/3/2019 11_ch10

8/50


Specification and Design

Architecturaldesign

Requirementsspecification

Requirementsdefinition

Softwarespecification

High-leveldesign

Increasing contractor involvement

Decreasing client involvement

Specification

Design

8/3/2019 11_ch10

9/50


Specification in theSoftware Process

Requirements

specification

Formal

specification

Systemmodelling

Architecturaldesign

Requirementsdefinition

High-leveldesign

8/3/2019 11_ch10

10/50


Specification Techniques

Algebraic approach

System specified in terms of

Its operations and

Their relationships

Model-based approach

System specified in terms of state model

Constructed using mathematicalconstructs; e.g.,

Sets

Sequences

Operations defined by modifications tosystems state

8/3/2019 11_ch10

11/50


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.

8/3/2019 11_ch10

12/50


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 validationcosts should be reduced as thespecification process reduces errors and

ambiguities in the requirements.

8/3/2019 11_ch10

13/50


Specification

Design andImplementation

Validation

Specification

Design andImplementation

Validation

Cost

Without formal

specification

With formal

specification

Development Costs WithFormal Specification

8/3/2019 11_ch10

14/50


Specification techniques

Algebraic specification

The system is specified in terms of itsoperations and their relationships.

Model-based specification The system is specified in terms of a state

model that is constructed usingmathematical constructs such as sets andsequences. Operations are defined by

modifications to the systems state.

8/3/2019 11_ch10

15/50


Interface Specification

Large systems decomposed into subsystems

Well-defined interfaces between thesesubsystems

Specification of subsystem interfaces allowsindependent developmentof differentsubsystems

Interfaces may be defined as abstract datatypes orobjectclasses

Algebraic approach to formal specificationparticularly well-suited to interfacespecification

8/3/2019 11_ch10

16/50


Sub-System Interfaces

Sub-systemA

Sub-systemB

Interfaceobjects

8/3/2019 11_ch10

17/50


WE STOP

HEREFRIDAY

You absolutely have to readthe chapter carefully before

Monday. The rest of this

material is extremelychallenging and you must beprepared before class.

8/3/2019 11_ch10

18/50


Structure of AlgebraicSpecification

(Generic Parameter)

class* < name >

Imports < LIST OF SPECIFICATION NAMES >

Informal description of class and its operations

Operation signatures setting out names and types of

parameters to operations defined over class

Axioms defining operations over class

*In Figure 10.6and discussion on page 224ff, Sommerville uses

the word sort where USspecialists would use the word class.

8/3/2019 11_ch10

19/50


Specification components

Introduction

Defines the sort (the type name) and declaresother specifications that are used.

Description

Informally describes the operations on thetype.

Signature

Defines the syntax of the operations in the

interface and their parameters.Axioms

Defines the operation semantics by definingaxioms which characterize behavior.

8/3/2019 11_ch10

20/50


Systematic algebraicspecification

Algebraic specifications of a system may bedeveloped in a systematic way

Specification structuring;

Specification naming; Operation selection;

Informal operation specification;

Syntax definition;

Axiom definition.

8/3/2019 11_ch10

21/50


Specification operations

Constructor operations. Operations whichcreate entities of the type being specified.

Inspection operations. Operations which

evaluate entities of the type being specified.To specify behavior, define the inspector

operations for each constructor operation.

8/3/2019 11_ch10

22/50


Operations on a list ADT

Constructor operations which evaluate totype List

Create, Cons (construct) and Tail.

Inspection operations which take type listasa parameter and return some other type

Head and Length.

8/3/2019 11_ch10

23/50


List specification (1)LIST (Elem)

Type List

Imports INTEGER

Defines a list where elements are added at the end andremoved from the front.

The operations Create, which brings an empty list intoexistence,

Cons, which creates a new list with an added member,

Length, which valuates the size,

Head, which valuates the front element of the list, and

Tail, which creates a list by removing the head from itsinput list.

Undefined represents an undefined value of type Elem.

8/3/2019 11_ch10

24/50


List specification (2)

Operation signatures:

Create p List

Cons (List, Elem) p List

Head (List) p Elem

Length (List) p Integer

Tail (List) p List

8/3/2019 11_ch10

25/50


List specification (3)

Axioms defining operations over class

Head (Create) = Undefined exception (empty list)

Head (Cons (L, v))= ifL = Create then v else Head (L)

Length (Create) = 0

Length (Cons (L, v) = Length (L) + 1

Tail (Create) = Create

Tail (Cons (L, v) = ifL = Create then Create else Cons

(Tail (L), v)

8/3/2019 11_ch10

26/50


Recursion in specifications

Operations are often specified recursively.

Tail (Cons (L, v)) = if L = Create then Createelse 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]

8/3/2019 11_ch10

27/50


Interface Specification inCritical Systems

Consider air traffic control system whereaircraft fly through managed sectors ofairspace

Each sector may include number of aircraftbut, for safety reasons, these must beseparated

In this example, simple vertical separation of300m proposed

The system should warn controller if aircraftinstructed to move so that separation rulebreached

8/3/2019 11_ch10

28/50


A Sector Object(Air-Traffic System)

Critical operations on object representingcontrolled sector

Enter: Add aircraft to controlled airspace

Leave: Remove aircraft from controlledairspace

Move: Move aircraft from one height toanother

Lookup: Given aircraft identifier, return itscurrent height

8/3/2019 11_ch10

29/50


Primitive Operations(Air-Traffic System)

Sometimes necessary to introduce additionaloperations to simplify specification

Other operations can then be defined usingthese moreprimitive operations

Primitive operations

Create: Bring instance of sector intoexistence

Put: Add aircraft without safety checks

In-space: Determine if given aircraft insector

Occupied: Given height, determine ifaircraft within 300m of that height

8/3/2019 11_ch10

30/50


Sector Specification (1)

Enter (S, CS, H) = if I n - space (S , C S ) the n S exception (A i rcraf t a l ready in s ector ) elsif Occup i ed (S , H ) the n S exception (Height confl ict) else P ut (S , C S , H )

Leave (C rea t e , C S ) = C rea t e exception (Aircraft not in se ctor)Leave (P u t (S , C S 1, H 1) , C S ) = if C S = C S 1 the n S e lse Put (Leave (S, CS), CS1, H1)

Mo ve (S, CS, H) =

i f S = Crea te the n Create exception (No aircraft in sector) elsif no t In-space (S, CS) the n S exception (Aircraft not in se ctor) elsif Occup i ed (S , H ) the n S exception (Height confl ict) else Put (Leave (S, CS), CS, H)

- - NO -HEIGHT is a co nstant indicat ing that a val id height cannot be returned

Lookup (C rea te , C S ) = N O -H E I GH T exception (Aircraft not in sector)Lookup (P u t (S , C S 1, H 1) , C S ) = i fC S = C S 1 the n H1 else Lookup (S, CS)

Occup ied (Create, H) = falseOccup ied (Put (S, CS1, H1) , H) = if ( H1 > H an d H1 - H 300) or (H > H 1 an d H - H 1 300) the n true e lse Occupied (S, H)

In-space (Create, CS) = false

In-space (Put (S, CS1, H1) , CS ) = i fC S = C S 1 the n true else In-space (S, CS)

sort S ec t o r imports I N TE GE R , B OOLE A N

Enter - a dds a n ai rcraf t to the sector i f safety condi t ions are sat isfedLeav e - removes an ai rcraf t f rom the sector Mo ve - moves an ai rcraf t f rom on e he ight to an other i f safe to do soLook up - Finds the height of an ai rcraf t in the sector

Create - creates an empty sec tor Put - adds an ai rcraf t to a sector w i th no const raint check sIn-space - chec ks i f an ai rcraf t is al ready in a sec tor Oc cupied - checks i f a speci f ied height is avai lable

Enter (Sec tor , Cal l -s ign, Height ) p Sector Leav e (Sector , Cal l -sign) p Sector Mo ve (Sector , Cal l-s ign, Height ) p Sector

Look up (Sector , Cal l -s ign) p HeightCreate p Sector Put (Sec tor , Cal l -s ign, Height ) p Sector In-space (Sec tor , Cal l -sign) p B oo l eanOc cupied (Sector , Height ) p B oo l ean

S E C TOR

This diagram is broken

down into more readable

sections on following

slides.

8/3/2019 11_ch10

31/50



SECTOR

Sort Sector

Imports INTEGER, BOOLEAN

______________________________________________________

Enter adds an aircraft to the sector if safety conditions are satisfiedLeave removes an aircraft from the sector

Move moves an aircraft from one height to another if safe to do so

Lookup Finds the height of an aircraft in the sector

Create creates an empty sector

Put adds an aircraft to a sector with no constraint checks

In-space checks if an aircraft is already in a sector

Occupied checks if a specified height is available

8/3/2019 11_ch10

32/50



_____________________________________________________Enter (Sector, Call-sign, Height) Sector

Leave (Sector, Call-sign) Sector

Move (Sector, Call-sign, Height) Sector

Lookup (Sector, Call-sign)

Height

Create Sector

Put (Sector, Call-sign, Height) Sector

In-space (Sector, Call-sign) Boolean

Occupied (Sector, Height) Boolean

_____________________________________________________

, - ,Look up (Sec tor C al l-sign) p Height

8/3/2019 11_ch10

33/50



Enter (S , C S, H) = if In -space (S , C S ) the n S except ion (A irc raft alread y in se ctor) elsif Occup ied (S , H ) the n S except ion (H eight c onflict) else Put (S , CS , H)

Leav e (C reate, C S) = Create except ion (A irc raf t no t in s ecto r)

Leave (Pu t (S , C S1, H1), C S) = i f CS = C S 1 the n S else Put (Leave (S, CS), C S1 , H1)

Mo ve (S, CS, H) = i f S = C reate the n Create except ion (N o aircraft in s ector) elsif no t In-s pace (S, CS) the n S except ion (A irc raft n ot in secto r) elsif Occup ied (S , H ) the n S except ion (H eight c onflict)

else Pu t (Lea ve (S, CS), C S, H)-- N O -HEIG HT is a co nstant indicat ing that a val id height c anno t be returned

Lookup (Crea te , C S) = N O -HEIG HT except ion (A irc raf t no t in s ecto r)Lookup (Pu t (S , C S1, H1), C S) = i fCS = C S1 the n H1 e lse Lookup (S, CS)

O c cupied (Creat e, H) = fa lseO c cupied (P ut (S, CS1, H 1), H) =

, ,Look up (Sec tor, C al l sign) p Height

Create p Sector Put (Sec tor, C al l-sign, H eight) p SectorIn-space (Sec tor, C al l-sign) p BooleanO c cupied (Sector, Height) p Boolean

, , ,i f CS = C S1 the n S else Pu t (Leave (S CS) C S1 H1)

8/3/2019 11_ch10

34/50



, , ,i f CS = C S1 the n S else Pu t (Leave (S, CS), C S1, H1)

Mo ve (S, CS, H ) = i f S = C reate the n Create except ion (N o aircraf t in s ecto r) elsif no t In-space (S, CS) the n S except ion (A irc raf t no t in s ector) elsif Occup ied (S , H ) the n S except ion (H eight c on fl ic t)

else Pu t (Lea ve (S , CS), C S, H)-- N O -HEIG HT is a co nstant ind icat ing that a va lid height cann ot be returned

Lookup (Crea te , C S) = N O-HEIGHT except ion (A irc raf t no t in s ecto r)Lookup (Pu t (S , C S1 , H1), C S) = i fCS = C S1 the n H1 e lse Lookup (S, CS)

O c cupied (Creat e, H) = fa lseOccupied (Put (S, CS1, H1), H) = i f (H1 > H an d H1 - H 300) or (H > H 1 an d H - H 1 300) the n true else O c cupied (S, H)

In-spac e (C reate, C S) = fa lse

In-spac e (Put (S, C S1, H1) , C S ) = i fCS = C S1 the n true else In-s pace (S, CS)

8/3/2019 11_ch10

35/50


Specification Commentary

Use basic constructors Create and Put tospecify other operations

Define Occupied and In-space using Createand Put and use them to make checks inother operation definitions

All operations that result in changes to sectormust check that safety criterion holds

8/3/2019 11_ch10

36/50


Behavioral Specification

Algebraic specification can be cumbersomewhen object operations not independent ofobject state

Model-based specification

Exposes system state and

Defines operations in terms of changes tothat state

Z notation

Mature technique for model-basedspecification.

Combines formal and informal descriptionand

Uses graphical highlighting when presentingspecifications

8/3/2019 11_ch10

37/50


Structure of Z Schema

contents capacity

Containercontents:capacity:

Schema name Schema signature Schema predicate

e

8/3/2019 11_ch10

38/50


Insulin Pump

Needleassembly

Sensor

Display1 Display2

Alarm

Pump Clock

Power supply

Insulin reservoir

Controller

8/3/2019 11_ch10

39/50


Modeling Insulin Pump

Schema models insulin pump as number ofstate variables

reading?

dose, cumulative_dose

r0, r1, r2

capacity

alarm!

pump!

display1!, display2!

Names followed by ? = inputs,

Names followed by ! = outputs

8/3/2019 11_ch10

40/50


Schema Invariant

Each Z schema has invariant part whichdefines conditions always true

For insulin pump schema always true that

Dose must be less than or equal tocapacity of insulin reservoir

No single dose may be more than 5 units ofinsulin and

Total dose delivered in time period mustnot exceed 50 units of insulin.

Display1! shows status of insulin reservoir.

8/3/2019 11_ch10

41/50


Insulin Pump Schema

Insu l in_pumpreading? :dose, cumulat ive_dose:r0, r1, r2: / / used to record the last 3 rea ding s tak encapaci ty:

ala rm !: {off, on }pump! :d isp lay1! , d isplay 2!: ST RING

do s e cap ac ity do se 5 cum ulativ e_d ose 50

c apacit y 40 dis play1! = " "c ap acity 39 capac ity 10 disp lay1! = "Ins ul in low "capacity 9 alarm ! = on dis play1! = "Ins ul in ve ry low"r2 = reading?

e e e

e

e

uu

8/3/2019 11_ch10

42/50


State invariants

r2 = R ead ing?

dose ! insul in_avai lableinsul in_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? = 000000cum ulat 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 max_dai ly_dose status = errordisplay1!= Da ily dose e xceed ed

/ / Pum p conf igura tion pa ram eters

capa city = 1 00 safemin = 6 sa fema x = 1 4max_ da ily_dose = 25 ma x_sing le_d ose = 4 m inimu m_dos e = 1

disp lay2! = n at_to_ str ing (dose !)clo ck! = cloc k?

8/3/2019 11_ch10

43/50


The dosage computation

The insulin pump computes the amount ofinsulin required by comparing the currentreading with two previous readings.

If these suggest that blood glucose is risingthen insulin is delivered.

Information about the total dose delivered ismaintained to allow the safety check invariantto be applied.

Note that this invariant always applies - thereis no need to repeat it in the dosagecomputation.

8/3/2019 11_ch10

44/50


RUN schema (1)

R UN(I NS UL I N_ PUM P_S TAT E

swi tch? = autostatus = runn ingstatus = w arninginsul in_avai lable

max_single_dose

cumulat ive_dose < max_dai ly_dose

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

(S U GAR _ LO W SUGAR _OK SUGAR _HIGH )

/ / 1. I f the co mpu ted i nsul in do se is zero, dont d el iver any ins ul in

Comp Dose = 0 dose! = 0

/ / 2 . The m aximu m dai ly dose wo uld be excee ded i f 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

Co mp Do s e + cumulat ive_do se > max_dai ly_dose alarm ! = o nstatus = warning dose ! =max _da ily_dose cumulat ive_d ose

8/3/2019 11_ch10

45/50


RUN schema (2)

/ / 3. The norma l s itua t ion. I f ma xim um s ingle d ose is not exce eded the n de l iver the co mpu ted dose. I f the sing le dose c omp uted is too high , res trict the d ose del ivered to the m aximum sin gle d ose

Comp Dose + c umu la ti ve_dose < m ax_ da il y_dose

( Com pDo se max _s ingle_dose

dose! = Com pDo seComp Dose > ma x_sing le_d osedose ! = max_s ingle_dose )

insul in_av ai lable = insul in_av ai lable dose !cumulat ive_dose = cum ulat ive_do se + d ose!

insul in_av ai lable ma x_single_dose * 4status = w arning

display1! = Insul in l ow

r1 = r 2r0 = r 1

8/3/2019 11_ch10

46/50


Sugar OK schema

SUGAR _OKr2 sa fem inr2 safem ax

// s uga r leve l stab le or falling

r2 r1 Comp Dose = 0

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

r2 > r1 (r2-r1) < (r1- r0) Comp 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 ) Comp Dose = m in imum_ dos e

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

8/3/2019 11_ch10

47/50


Key points

Formal system specification complementsinformal specification techniques.

Formal specifications are precise andunambiguous. They remove areas of doubt ina specification.

Formal specification forces an analysis of thesystem requirements at an early stage.Correcting errors at this stage is cheaper than

modifying a delivered system.Formal specification techniques are most

applicable in the development of criticalsystems and standards.

8/3/2019 11_ch10

48/50


Key points

Algebraic techniques are suited to interfacespecification where the interface is defined asa set of object classes.

Model-based techniques model the systemusing sets and functions. This simplifiessome types of behavioral specification.

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

the system state.

8/3/2019 11_ch10

49/50


Homework

Required By Fri 1 Oct 2004

For a total of 25 points, answer fully:

10.2 (5 pts),

10.5 (10),

10.6 (10)

Optional

By Fri 8 Oct 2004

For up to 12 extra points, answer any or allof the following:

10.7 (5), 10.8 (5), 10.10 (2)

8/3/2019 11_ch10

50/50

Documents

11_ch10