Formal Specification by sandyk2012


									                                         Formal Specifications
Formal Specification - Techniques for the unambiguous specification of software

 To explain why formal specification techniques help discover problems in system requirements

 To describe the use of

•algebraic techniques (for interface specification) and

•model-based techniques(for behavioural specification)

 To introduce Abstract State Machine Model

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 representation and analysis of software

 Formal methods include

•Formal specification

•Specification analysis and proof

•Transformational development

•Program verification

 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

 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

 Data Invariant

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

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


It is defined as action that takes place in a system and reads or writes data to a state

It is associated with 2 conditions

1) Precondition

2) Postcondition

Precondition defines whether the operation is valid or not and Postcondition defines what happens when an
operation has completed its action

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

 Mathematical Definition of state, data invariant and operation for such system will be as follows:


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

used, free: P BLOCKS

BlockQueue: seq P BLOCKS

 Data Invariant

1No 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


Operation for removing block from the queue




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

Selection criteria
 Factors that should be taken into consideration while using formal methods are as follows

1.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 formalization

It 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


It 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 standards

SQA activities must continue to be applied as systems are developed

5.One should not be dogmatic

Formal 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 again

Formal methods do not absolve the software engineer from the need to conduct well planned, thorough tests

Model Checking
 The technical challenge is to devise an algorithm for handling large spaces

 Rebeca uses compositional verification

 There are two general approaches in model checking

1.Temporal Model Checking

2.Model checking with a automaton spec

 The difference is between the specification
•First one : Temporal Logic

•Second one : Automaton

 Model checking is completely automatic

 It produces counter examples

•The counter example usually represents subtle error in design

 The main disadvantage : state explosion problem!

Acceptance of formal methods
 Formal methods have not become mainstream software development techniques as was once predicted

•Other software engineering techniques have been successful at increasing system quality. Hence the need for
formal methods has been reduced

•Market changes have made time-to-market rather than software with a low error count the key factor. Formal
methods do not reduce time to market

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

•Formal methods are hard to scale up to large systems

Use of formal methods
  Their principal benefits are in reducing the number of errors in systems so their main area of applicability is critical

•Air traffic control information systems,

•Railway signalling systems

•Spacecraft systems

•Medical control systems

 In this area, the use of formal methods is most likely to be cost-effective

 Formal methods have limited practical applicability

Specification in the software process
 Specification and design are inextricably mixed.

 Architectural design is essential to structure a specification.

  Formal specifications are expressed in a mathematical notation with precisely defined vocabulary, syntax and

Specification and design
Specification in the software process

Specification techniques
 Algebraic approach

•The system is specified in terms of its operations and their relationships

 Model-based approach

•The system is specified in terms of a state model that is constructed using mathematical constructs such as sets and

•Operations are defined by modifications to the system’s state

Formal specification languages
Use of formal specification
 Formal specification involves investing more effort in the early phases of software development

This reduces requirements errors as it forces a detailed analysis of the requirements

 Incompleteness and inconsistencies can be discovered and resolved !!!

Hence, savings as made as the amount of rework due to requirements problems is reduced

Development costs with formal specification

1. Interface specification
 Large systems are decomposed into subsystems with well-defined interfaces between these subsystems

 Specification of subsystem interfaces allows independent development of the different subsystems

 Interfaces may be defined as abstract data types or object classes

The algebraic approach to formal specification is particularly well-suited to interface specification

Sub-system interfaces
The structure of an algebraic specification

Behavioural specification
 Algebraic specification can be cumbersome when the object operations are not independent of the object state

 Model-based specification exposes the system state and defines the operations in terms of changes to that state

OSI reference model

To top