Topics covered Formal specif ication in the sof tware process I - - PDF document

1

Formal Specif ication

• Techniques f or the

unambiguous specif ication of sof tware

Objectives

• To explain why f ormal specif ication

techniques help discover problems in system requirements

• To describe the use of algebraic

techniques f or interf ace specif ication

• To describe the use of model- based

techniques f or behavioural specif ication

2

Topics covered

• Formal specif ication in the sof tware

process

• I nterf ace specif ication
• Behavioural specif ication

Formal methods

• Formal specif ication is part of a more

general collection of techniques that are known as ‘f ormal methods’

• These are all based on mathematical

representation and analysis of sof tware

• Formal methods include

– Formal specif ication – Specif ication analysis and proof – Transf ormational development – Program verif ication

3

Acceptance of f ormal methods

• Formal methods have not become

mainstream sof tware development techniques as was once predicted

– Other sof tware engineering techniques have been successf ul at increasing system quality. – Market changes have made time- to- market rather than sof tware with a low error count the key f actor. Formal methods do not reduce time to market – Formal methods are hard to scale up to large systems

Use of f ormal methods

• Their principal benef its are in

reducing the number of errors in systems so their main area of applicability is critical systems

• I n this area, the use of f ormal

methods is most likely to be cost- ef f ective

4

Specif ication in the sof tware process

• Specif ication and design are

intermingled.

• Architectural design is essential to

structure a specif ication.

• Formal specif ications are expressed

in a mathematical notation with precisely def ined vocabulary, syntax and semantics.

Specif ication

Specif ication and design

Requirements Def inition Requirements Def inition Requirements Specif ication Requirements Specif ication Architectural Design Architectural Design Sof tware Specif ication Sof tware Specif ication High- level Design High- level Design Design I n creasin g C

• n

tracto r I n vo lvem en t Decreasin g C lien t I n vo lvem en t

5

Specif ication in the sof tware process

Requirements Def inition Requirements Def inition Requirements Specif ication Requirements Specif ication System Modeling System Modeling Architectural Design Architectural Design Formal Specif ication Formal Specif ication High- level Design High- level Design

Specif ication techniques

• Algebraic approach

– The system is specif ied in terms of its

• perations and their relationships
• Model- based approach

– The system is specif ied in terms of a state model that is constructed using mathematical constructs such as sets and sequences. Operations are def ined by modif ications to the system’s state

6

Formal specif ication languages

• 1. CSP
• 2. Petri Nets
• 1. Z
• 2. VDM
• 3. B

Model- based Lotos Larch Algebraic Concurrent Sequential

Use of f ormal specif ication

• Formal specif ication involves investing

more ef f ort in the early phases of sof tware development

• This reduces requirements errors as it

f orces a detailed analysis of the requirements

• I ncompleteness and inconsistencies can

be discovered and resolved

• Hence, savings as made as the amount of

rework due to requirements problems is reduced

7

Specif ication Specif ication Design & I mplementation Design & I mplementation

Validation Validation

Without f ormal specif ication With f ormal specif ication Cost

Development costs with f ormal specif ication

I nterf ace specif ication

• Large systems are decomposed into

subsystems with well- def ined interf aces between these subsystems

• Specif ication of subsystem interf aces

allows independent development of the dif f erent subsystems

• I nterf aces may be def ined as abstract

data types or object classes

• The algebraic approach to f ormal

specif ication is particularly well- suited to interf ace specif ication

8

Sub- system interf aces

Sub- system A Sub- system A Sub- system B Sub- system B I nterf ace

• bjects

The structure of an algebraic specif ication

Sort <name> I mports <list of specif ication names> Sort <name> I mports <list of specif ication names> I nf ormal description of the sort and its operations I nf ormal description of the sort and its operations Operation signatures setting out the names and the types of the parameters to the operations def ined

• ver the sort

Operation signatures setting out the names and the types of the parameters to the operations def ined

• ver the sort

Axioms def ining the operations over the sort Axioms def ining the operations over the sort <Specif ication Name> (Generic Parameter)

9

Specif ication components

• I ntroduction

– Def ines the sort (the type name) and declares other specif ications that are used

• Description

– I nf ormally describes the operations on the type

• Signature

– Def ines the syntax of the operations in the interf ace and their parameters

• Axioms

– Def ines the operation semantics by def ining axioms which characterise behaviour

Systematic algebraic specif ication

• Algebraic specif ications of a system

may be developed in a systematic way

– Specif ication structuring. – Specif ication naming. – Operation selection. – I nf ormal operation specif ication – Syntax def inition – Axiom def inition

10

Specif ication operations

• Constructor operations. Operations

which create entities of the type being specif ied

• I nspection operations. Operations

which evaluate entities of the type being specif ied

• To specif y behaviour, def ine the

inspector operations f or each constructor operation

I nterf ace specif ication in critical systems

• Consider an air traf f ic control system

where aircraf t f ly through managed sectors of airspace

• Each sector may include a number of

aircraf t but, f or saf ety reasons, these must be separated

• I n this example, a simple vertical

separation of 300m is proposed

• The system should warn the controller if

aircraf t are instructed to move so that the separation rule is breached

11

A sector object

• Critical operations on an object

representing a controlled sector are

– Enter. Add an aircraf t to the controlled airspace – Leave. Remove an aircraf t f rom the controlled airspace – Move. Move an aircraf t f rom one height to another – Lookup. Given an aircraf t identif ier, return its current height

Primitive operations

• I t is sometimes necessary to introduce

additional operations to simplif y the specif ication

• The other operations can then be

def ined using these more primitive

• perations
• Primitive operations

– Create. Bring an instance of a sector into existence – Put. Add an aircraf t without saf ety checks – I n- space. Determine if a given aircraf t is in the sector – Occupied. Given a height, determine if there is an aircraf t within 300m of that height

12

Sector specif ication

E nte r (S, CS, H) = if In-space (S, CS ) the n S exc eption (Aircra ft alre ady in se ctor) elsif Occupie d (S , H) the n S exc eption (Height conflict) else Put (S , CS, H) Leave (Create, CS) = Create exception ( Aircraft not in sector) Leave (Put (S, CS1, H1), CS) = if CS = CS1 the n S else Put (Leave (S, CS), CS1, H1) Mo ve (S , CS, H) = if S = Create the n Create e xce ption (No aircra ft in s ector) elsif not In-spa ce (S , CS) the n S exception ( Aircraft not in sector) elsif Occupie d (S , H) the n S exception ( He ight c onflict) else P ut (Lea ve (S, CS), CS, H)

• - NO-HEIGHT is a consta nt indicating that a valid height cannot be re turne d

Lookup (C rea te , CS) = NO-HEIGHT e xce ption (Air c raft not in se ctor) Lookup (P ut (S, CS 1, H1), C S) = if CS = CS 1 the n H1 else Lookup (S, CS) Oc cupie d (Crea te, H) = false Oc cupie d (Put (S, CS1, H1), H) = if (H1 > H and H1 - H Š 300) or ( H > H1 and H - H1 Š 300) the n true els e Oc cupie d (S, H) In-space (Cre ate, CS ) = f a ls e In-space (Put (S, CS1, H1), CS ) = if CS = CS 1 the n true else In-spa ce (S, CS) sort Se ctor imports INTEGER , BOOLE AN Enter - a dds a n airc raft to the se ctor if s afety conditions a re s atis f e d Leave - re move s an aircraft from the se ctor Move - moves a n a ircraft from one he ight to another if safe to do so Lookup - Finds the height of an aircra ft in the s ector Cre a te - creates an e mpty sec tor Put - a dds a n airc ra f t to a se ctor with no constraint c hecks In-space - che cks if a n aircra ft is already in a sector Occupied - checks if a spe cifie d height is available Enter (Se ctor, Call-sign, He ight) ? Se ctor Le ave (Sec tor, Call-sign) ? Sector Move (Se ctor, Call-s ign, He ight) ? Se ctor Lookup (Se ctor, Call-sign) ? Height Cre ate ? Sector Put (S ector, Call-sign, Height) ? Se ctor In-spa ce (Sector, Ca ll-sign) ? Boolea n Occupied (Sector, Height) ? Boolea n SECT OR

Specif ication commentary

• Use the basic constructors Create

and Put to specif y other operations

• Def ine Occupied and I n- space using

Create and Put and use them to make checks in other operation def initions

• All operations that result in changes

to the sector must check that the saf ety criterion holds