Formal Methods in

Software
Engineering

Shakeel Ahmad

1 Week-I 10/12/2019
 Grading Policy
i. Project 10 Marks
ii. Assignment & Quizzes 08 Marks
iii. Mid-term 12 Marks
iv- Final-term 30 Marks

2 10/12/2019
 Book and Material

1. Modern Formal Methods and Applications, Hossam A. Gabbar, Springer-

Verlag 2006.
2. Formal Software Development: From VDM to Java, Charatan, Quentin, and
Aaron Kans. Palgrave Macmillan, 2003.
3. Understanding Z: a Specification Language and its Formal Semantics. J. M.
Spivey. 1988. Cambridge University Press, New York, NY, USA.

Website: www.tinyurl.com/itlectures

10/12/2019
Notorious Bugs – BYTE, September 1995
http://www.byte.com/art/9509/sec7/art20.htm

– 1987 : Therac-25 – The Bug that killed

 Notorious Bugs – BYTE, September 1995
http://www.byte.com/art/9509/sec7/art20.htm

– 1990: AT&T long distance break down

Notorious Bugs – BYTE, September 1995
http://www.byte.com/art/9509/sec7/art20.htm

– 1991: Patriot Missile – Hitting own

barracks, leaving 28 dead and
98 wounded.
 Introduction to
Formal Specification
 Background

A specification may have many uses, in many

forms -
- Management
– Specification in English
– Programmers
– Written in a pseudo (or real) programming language
– CS & Management
– Improve quality of software systems
– Provide proof & verifications

8
 9 Background

– Need to be precise
– Management
– Must be able to agree what is to be implemented
 10 Background

– Need to be precise
– Programming
– Written in language is probably no use

– Expensive to create
– Long
– Include un-necessary details
– Performance not effect of operation
– Difficult to understand
 11 Background

– Precise definition of Effects of various operations rather

than its performance details Information to be displayed to
users
– No need of
– How the operations are to be done
– How the data is to be stored Etc

The details is no use of specify the effect of the

system
12 Background

– Also may need a specification to

– Prove certain properties
– Prove that certain combinations of states never occur
– Value of a given variable never go outside certain bounds

– Correctness of system can be proven

13 Purpose of Formal
Specification

– To state what system should do without describing

how to do it

– To reduce faults in systems

– Invest more effort in early stage of system development
– Requirement errors can be discovered as early as
possible and resolved
14 Specification Parts

– A specification need to include

– Details of the system
– The states it can occupy
– Invariants which will always hold

– Dynamic aspects
– All operations which are possible
– The relations of inputs to outputs
– Changes of state that can occur
15 Specification Parts

– A specification will include

– Functional requirements
– The effect of xxx will be
– The output of command yyy will be as specified in standard zzz
– The system will produce a report on salesman effectiveness
 16 Specification Parts

– A specification will include

– Non-functional requirements (properties)
– All data access should be via company supplied subroutines
– The system should be immune to power failures
– The response time must be …
17 Specification Parts

– A specification will include

– Design directives
– The system will collect data from …
– The VDU display will be in the form …
– The designer will use SSADM
18 Specification Parts

– A specification will include

– Goals
– Response times should be minimised
– It should run in 748kb of memory
– Data statements
– The system must maintain the average temperature over the
preceding …
19 Definition – Formal
Specification

– The specification will be

– A strict mathematical definition of the effect of the
required operation
– Usually expressed in mathematical notions with precisely defined
vocabulary, syntax and semantics
– Definition is not necessarily in the form in which it can be
programmed
20 Definition – Formal
Specification
– In computer science, formal methods refers to
mathematically based techniques for the specification,
development and verification of software and hardware
systems.
21 Definition – Formal
Specification

– The approach is especially important in high-integrity systems, for

example where safety or security is important, to help ensure that
errors are not introduced into the development process.

From Wikipedia, the free encyclopedia.

http://en.wikipedia.org/wiki/Main_Page
 22 Definition with a scientist’s
quote
– Formal methods are particularly effective early in
development at the requirements and
specification levels.
– Software engineers want to be real engineers.
– Real engineers use mathematics.
– Formal methods are the mathematics of software
engineering. Therefore, software engineers should use
formal methods.

(Mike Holloway, NASA)

23 Formal Methods Parts

– Program specification
– Program verification
– Automated theorem proving
– Model checking
 24 Program Specification

– A program specification is the definition of what a

computer program is expected to do

– It can be
– informal, in which case it can be considered as a
blueprint or user manual from a developer point of view,
or formal, in which case it has a definite meaning defined
in mathematical or programmatic terms.
 25 Program Verification

– In computer science, program verification is the

process of formally proving that a computer
program does exactly what is stated in the
program specification it was written to realize

– Program verification is more specific in that it aims

to verify the code itself, not only some abstract
model of the program.
– Intel, AMD: verify chips
– BMW: automotive system
26 Automated Theorem
Proving

– Automated theorem proving is the proving of

mathematical theorems by a computer program.
Depending on the underlying logic, the problem of
deciding the validity of a theorem varies from
trivial to impossible.
 27 Model checking

– Model checking is a method to algorithmically

verify formal systems. This is achieved by verifying
if the model, often deriving from a hardware or
software design, satisfies a formal specification.
The specification is often written as temporal logic
formulas.
28 Formal vs. Informal
Methods

– Formal specification vs. SSADM

– SSADM (Structured Systems Analysis and Design Method)

– now government standard
– Widely used in industry
29 Formal vs. Informal
Methods

– Lots of possible inconsistencies

– Decision tables
To prove that, if you use “don’t care” entries, the result is
completely and uniquely defined?
– Computer tools to help overcome the difficulties,
but are still basic problems
30
Mathematics vs. Natural
Language for System
Specification

– Deficiencies of natural language

– Can be vague
– Can be ambiguous
– Can be self-contradictory
– Can be incomplete
– Encourages imprecise thinking
– Cannot easily handle abstractions
 31 Mathematics – good features

– Easily handle abstractions

– Can be used for reasoning about, and describing a

system

– Is concise

– Is non-ambiguous
 32 Mathematics – good features

– Is applied widely to the real world

– Can approximate where exactness is unnecessary

– Changes slower than computing

33 Formal Notation –
drawbacks

– The customer cannot easily understand the

specification

– The mathematics used is unfamiliar to many of the

staff

– In real world, getting user requirements document

is a problem
34
Cleanroom software engineering
and formal methods

– Both demand a specialized specification

approach, and each applies a unique verification
method.
– Both are quite rigorous, and neither is used
widely by the software engineering community.
– If you must build “bullet-proof” software,
these methods can help immeasurably.
35

The Clean room Process Model

36

The Cleanroom Strategy-I

Increment Planning—adopts the incremental strategy
Requirements Gathering—defines a description of customer level
requirements (for each increment)
Box Structure Specification—describes the functional specification
Formal Design—specifications (called “black boxes”) are iteratively
refined (with an increment) to become analogous to architectural and
procedural designs (called “state boxes” and “clear boxes,”
respectively).
Correctness Verification—verification begins with the highest-level box
structure (specification) and moves toward design detail and code using
a set of “correctness questions.” If these do not demonstrate that the
specification is correct, more formal (mathematical) methods for
verification are used.
Code Generation, Inspection and Verification—the box structure
specifications, represented in a specialized language, are transmitted
into the appropriate programming language.
37

The Cleanroom Strategy-II

Statistical Test Planning—a suite of test cases that exercise of

“probability distribution” of usage are planned and designed
Statistical Usage Testing—execute a series of tests derived
from a statistical sample (the probability distribution noted
above) of all possible program executions by all users from a
targeted population
Certification—once verification, inspection and usage testing
have been completed (and all errors are corrected) the
increment is certified as ready for integration.
 38

Box Structure Specification

black box
clear box

The white box specification

describes a software
specification at a lower level state box
in hierarchy. It does not
describe the implementation
of the process. The black box
and white box
views/specifications can be
composed of concurrent sub-
specifications.
 39
– Specification-based testing technique is also known as ‘black-box’ or
input/output driven testing techniques because they view the software as a
black-box with inputs and outputs.
– The testers have no knowledge of how the system or component is structured
inside the box. In black-box testing the tester is concentrating on what the
software does, not how it does it.
– The definition mentions both functional and non-functional testing. Functional
testing is concerned with what the system does its features or functions. Non-
functional testing is concerned with examining how well the system does. Non-
functional testing like performance, usability, portability, maintainability, etc.
– Specification-based techniques are appropriate at all levels of testing (component
testing through to acceptance testing) where a specification exists. For example,
when performing system or acceptance testing, the requirements specification or
functional specification may form the basis of the tests
10/12/2019
40

Box Structures

black box
state box

clear box
 41
Box Structures

A black-box specification describes an abstraction, stimuli, and response using the

notation shown in . The function f is applied to a sequence, S*, of inputs (stimuli), S,
and transforms them into an output (response), R. For simple software components, f
may be a mathematical function, but in general, f is described using natural language
(or a formal specification language).

Many of the concepts introduced for object-oriented systems are also applicable for
the black box. Data abstractions and the operations that manipulate those
abstractions are encapsulated by the black box. Like a class hierarchy, the black box
specification can exhibit usage hierarchies in which low-level boxes inherit the
properties of those boxes higher in the tree structure.

10/12/2019
 42 State-Box Specification

– The state box is “a simple generalization of a state machine” [MIL88]. As

processing occurs, a system responds to events (stimuli) by making a transition
from the current state to some new state.
– As the transition is made, an action may occur. The state box uses a data
abstraction to determine the transition to the next state and the action
(response) that will occur as a consequence of the transition. the state box
incorporates a black box. The stimulus, S, that is input to the black box arrives
from some external source and a set of internal system states, T. Mills [MIL88]
provides a mathematical description of the function, f, of the black box
contained within the state box: g : S* _ T* __ R _ T where g is a sub-function
that is tied to a specific state, t. When considered collectively, the state-sub
function pairs (t, g) define the black box function f.
10/12/2019
43 Clear-Box Specification

– The clear-box specification is closely aligned with

procedural design and structured programming. In essence,
sub function g within the state box is replaced by the
structured programming constructs that implement g.
These, in turn, can be refined into lower-level clear boxes
as stepwise refinement proceeds. It is important to note
that the procedural specification described in the clear-box
hierarchy can be proved to be correct.

10/12/2019
44

Design Refinement & Verification

If a function f is expanded into a sequence g and h, the

correctness condition for all input to f is:
• Does g followed by h do f?
When a function f is refined into a conditional (if-then-else),
the correctness condition for all input to f is:
• Whenever condition <c> is true does g do f and
whenever <c> is false, does h do f?
When function f is refined as a loop, the correctness
conditions for all input to f is:
• Is termination guaranteed?
• Whenever <c> is true does g followed by f do f, and
whenever <c> is false, does skipping the loop still do f?
45

Advantages of Design Verification

– It reduces verification to a finite process.

– It lets cleanroom teams verify every line of design and
code.
– It results in a near zero defect level.
– It scales up.
– It produces better code than unit testing.
46

Cleanroom Testing
– statistical use testing
– tests the actual usage of the program
– determine a “usage probability distribution”
– analyze the specification to identify a set of stimuli
– stimuli cause software to change behavior
– create usage scenarios
– assign probability of use to each stimuli
– test cases are generated for each stimuli according to the usage
probability distribution
47

Certification

1. Usage scenarios must be created.

2. A usage profile is specified.
3. Test cases are generated from the profile.
4. Tests are executed, and failure data are recorded and
analyzed.
5. Reliability is computed and certified.
48

Certification Models

Sampling model. Software testing executes m random test

cases and is certified if no failures or a specified numbers of
failures occur. The value of m is derived mathematically to
ensure that required reliability is achieved.
Component model. A system composed of n components
is to be certified. The component model enables the analyst
to determine the probability that component i will fail prior to
completion.
Certification model. The overall reliability of the system is
projected and certified.
49 Z

– A formal specification technique developed at

Oxford
– Uses very mathematical notation to provide exact
definitions of a system
– System is described in a number of small Z
modules, which can cross-refer each other
– Each module is expected to have some descriptive
English text to help users to understand it
50 Summary

– Background of formal specification

– Parts of specification
– Formal specification vs.
– SSADM
– Natural language
– Formal method advantages and drawbacks
– Z specification language
51

Good papers to begin with:

– “Formal Methods: State of the Art and Future Directions”,

Edmund M. Clarke, Jeannette M. Wing, ACM Computing
Surveys, 1996
– “Ten Commandments of Formal Methods ... Ten Years Later”,
Jonathan P., Bowen and Mike Hinchey, IEEE Computer,
39(1):40-48, January 2006.
Case Studies: CUTE
52

 CUTE: A Concolic Unit Testing Engine for C

 Developed by a team managed by Gul Agha – 2005
 Concolic testing
 use the symbolic execution to generate inputs
that direct a program to alternate paths
 use the concrete execution to guide the
symbolic execution along a concrete path
Case Studies: CUTE
53

 CUTE was used to automatically test SGLIB, a

popular C data structure library used in a
commercial tool
 CUTE took less than 2 seconds to find two
previously unknown errors!
 a segmentation fault
 an infinite loop
 The homepage of CUTE:
 http://osl.cs.uiuc.edu/~ksen/cute/
Case Studies: Intel’s Successes
http://www.cse.ogi.edu/S3S/JohnHarrison.pdf

54

 Intel uses formal verification quite extensively

 Verification of Intel Pentium 4 floating-point unit with a mixture of STE and
theorem proving
 Verification of bus protocols using pure temporal logic model checking
 Verification of microcode and software for many Intel Itanium floating-
point operations, using pure theorem proving
 FV found many high-quality bugs in P4 and verified “20%” of
design
 FV is now standard practice in the floating-point domain
 Case Studies: NASA SATS
55

 Small Aircraft Transportation System (SATS)

http://sats.nasa.gov/

 Use of a software system that will sequence aircraft into

the SATS airspace in the absence of an airport controller
 There are serious safety issues associated with these
software systems and their underlying key algorithms
 Case Studies: NASA SATS
56

 The criticality of such software systems necessitates that

strong guarantees of the safety be developed for them
 Under the SATS program NASA Langley researchers are
currently investigating rigorous verification of these
software system using formal methods
 Modeling and Verification of Air Traffic
 Conflict Detection and Alerting
 …