Formal Methods in SE

Software Verification Using Formal Methods

By: Qaisar Javaid, Assistant Professor

Formal Methods1

Formal Methods2

Formal Methods in Block Handler

Concept

Current methods of software development involves only combination of diagrams, text, tables etc.

No methods are used to test the correctness of the end result in each of stages of software development for e.g. requirement specification, design etc.

This may lead to contradictions, ambiguities, incompleteness, vagueness etc.

This may not be a good option for safety-critical or mission critical systems,where failure may have high price

Concept Formal methods allow a software engineer to

create a specification that is more consistent and unambiguous

Set theory and logic notations are used to create a clear statement of facts (requirements) which can then be analyzed to prove correctness and consistency

Since specification is created using mathematical notation, it is inherently less ambiguous than informal modes of representation.

Definitions Data InvariantA data invariant is a condition that is true throughout the

execution

of the system that contains a collection of data. E.g. maximum

number elements in any system, duplication not allowed in a

system.

StateA state is the stored data that a system accesses and alter.

Definitions

OperationIt is defined as action that takes place in a system and reads

or writes data to a state

It is associated with 2 conditions1) Precondition 2) Postcondition Precondition defines whether the operation is valid or not and Postcondition defines what happens when an operation has completed its action

ExampleBlock Handler

A common part of any operating system which handles the memory blocks

Provides free blocks of memory to new created files and regains blocks when file is removed.

It keeps tracks of free blocks or the unused blocks and the used blocks

Whenever a block is freed, it is added to the queue of unused blocks and similarly whenever a block is needed first block from the queue of unused bock is given for use.

Block Handler Mathematical Definition of state, data invariant

and operation for such system will be as follows:

1. StateCollection of free blocks, collection of used blocks, and the queue of returned blocks. Mathematically they are defined as

used: P Blocks

free: P BLOCKS

BlockQueue: seq P BLOCKS

Block Handler Data Invariant1 No block will be marked as both unused and used

used П free = 0

2. The collection of used blocks and blocks that are unused will be the total collection of blocks that make up the files

used U free = ALLBLOCKS

BLOCK Handler Operations

Operation for removing block from the queue

Precondition#BLOCKQUEUE > 0

Postconditionused = used + BLOCKQUEUE blocks(used)free = free – BLOCKQUEUE blocks(used)

Selection criteria Factors that should be taken into consideration

while using formal methods are as follows1. Estimate Cost

Formal methods have high start up cost. Training staff, acquisition of support tools and use of contract consultants results in high first time cost

2. Use formalization and not over formalizationIt is not necessary to apply formal methods to every aspects of a major system. Components that are safety critical should only be built using formal methods

Selection criteria

3. IntegrationIt is possible to integrate and in many cases desirable, to integrate formal methods with conventional or object oriented methods. A combination, if properly applied, can produce excellent results

4. Should maintain quality standardsSQA activities must continue to be applied as systems are developed

Selection criteria

5. One should not be dogmaticFormal methods are not a guarantee of correctness. It is possible that the final system, even when developed using formal methods, may have small omissions, minor bugs, and other attributes that do not meet expectations

6. Test, Test and Test againFormal methods do not absolve the software engineer from the need to conduct well planned, thorough tests

Formal Methods14

Formal Clean Room SE

The name is derived from the 'Cleanroom' process in semiconductor fabrication. The philosophy is defect avoidance rather than defect removal.

This software development process is based on: Incremental development; Formal specification; Static verification using correctness arguments; Statistical testing to determine program reliability.

Cleanroom software development

The Cleanroom process

Constructstructuredprogram

Definesoftware

increments

Formallyverifycode

Integrateincrement

Formallyspecifysystem

Developoperational

profileDesign

statisticaltests

Testintegratedsystem

Error rework

Cleanroom process characteristics Formal specification using a state transition

model. Incremental development where the customer

prioritises increments. Structured programming - limited control and

abstraction constructs are used in the program.

Static verification using rigorous inspections. Statistical testing of the system

Formal specification and inspections The state based model is a system

specification and the inspection process checks the program against this mode.l

The programming approach is defined so that the correspondence between the model and the system is clear.

Mathematical arguments (not proofs) are used to increase confidence in the inspection process.

Specification team. Responsible for developing and

maintaining the system specification.

Development team. Responsible for developing

and verifying the software. The software is NOT

executed or even compiled during this process.

Certification team. Responsible for developing a

set of statistical tests to exercise the software after

development. Reliability growth models used to

determine when reliability is acceptable.

Cleanroom process teams

The results of using the Cleanroom process have been very impressive with few discovered faults in delivered systems.

Independent assessment shows that the process is no more expensive than other approaches.

There were fewer errors than in a 'traditional' development process.

However, the process is not widely used. It is not clear how this approach can be transferred to an environment with less skilled or less motivated software engineers.

Cleanroom process evaluation

Formal Methods

Thanks

21