Spring 2019

Formal Methods in
Software Engineering
Introduction

By
Rubina Shaheen
 2/33

Importance of Software

Software has become critical to modern life

Process Control (oil, gas, water, . . . )

Transportation (air traffic control, . . . )
Health Care (patient monitoring, device control . . . )
Finance (automatic trading, bank security . . . )
Defense (intelligence, weapons control, . . . )
Manufacturing (precision milling, assembly, . . . )
 3/33

E MBEDDED S OFTWARE

Software systems are embedded everywhere

 3/33

E MBEDDED S OFTWARE

Software systems are embedded everywhere

Some of them are critical
 3/33

E MBEDDED S OFTWARE

Software systems are embedded everywhere

Some of them are critical

Failing software costs money and life!

 5/33

S OFTWARE S YSTEMS ARE G ROWING V ERY L ARGE

Car software:
The GM Volt contains +10M lines of code: how do you verify
that?
Current cars admit hundreds of onboard functions: how do
you cover their combination?
E.g., does braking when changing the radio station and
starting the windscreen wiper, affect air conditioning?
 6/33

FAILING S OFTWARE C OSTS M ONEY

Thousands of dollars for each minute of factory down-time

Huge losses of monetary and intellectual investment

• Rocket boost failure (e.g., Ariane 5)

Business failures associated with buggy software

• (e.g., Ashton-Tate dBase)
 7/33

FAILING S OFTWARE C OSTS L IVES

Potential problems are obvious:

• Software used to control nuclear power plants
• Air-traffic control systems
• Spacecraft launch vehicle control
• Embedded software in cars

A well-known and tragic example:

Therac-25 radiation machine failures
 8/33

THE P ECULIARITY OF S OFTWARE S YSTEMS

Tiny faults can have catastrophic consequences

Software seems particularly prone to faults:
Ariane 5
Mars Climate Orbiter, Mars Sojourner
London Ambulance Dispatch System
Denver Airport Luggage Handling System
Pentium-Bug
(more at http://www5.in.tum.de/~huckle/bugse.html)
 9/33

O BSERVATION

Building software is what most of you will do after

graduation

You’ll be developing systems in the context above

Given the increasing importance of software,
• you may be liable for errors
• your job may depend on your ability to produce reliable systems

What are the challenges in building reliable software?

 10/33

ACHIEVING R ELIABILITY IN E NGINEERING

Some well-known strategies from civil engineering:

Precise calculations/estimations of forces, stress, etc.

Hardware redundancy (“make it a bit stronger than
necessary”)
Robust design (single fault not catastrophic)
Clear separation of subsystems (any airplane flies with
dozens of known and minor defects)
Design follows patterns that are proven to work
 11/33

W HY THIS DOES NOT W ORK FOR S OFTWARE

Software systems compute non-continuous functions

Single bit-flip may change behaviour completely
Redundancy as replication doesn’t help against bugs
Redundant SW development only viable in extreme cases
No physical or modal separation of subsystems
Local failures often affect whole system
Software designs have very high logic complexity
Most SW engineers untrained in correctness
Cost efficiency more important than reliability
Design practice for reliable software is not yet mature
Importance of Formal Methods in
Softwares….

WHY ARE THEY REQUIRED??

IMPORTANCE OF FORMAL METHODS IN SOFTWARE

Methods to ensure that software is

• Correct
• Reliable
 12/33

HOW TO E NSURE S OFTWARE C ORRECTNESS ?

A Central Strategy: Testing

(others: SW processes, reviews, libraries, . . . )

Black Box Testing

Checking output against inputs.

White Box Testing

Checking structure
 13/33

LIMITATIONS OF T ESTING

Testing can show the presence of errors, but not their

absence
(exhaustive testing viable only for trivial systems)

Representativeness of test cases/injected faults is subjective

How to test for the unexpected? Rare cases?

Testing is labor intensive, hence expensive

Example : Imagine you’re a mechanic and
you know that either the fuel filter is
clogged or the fuel pump is defective. But
you just replaced the fuel filter. So you
know the problem must be with the fuel
pump.

Either it’s the fuel filter or it’s the fuel pump.

It’s not the fuel filter. It’s the fuel pump.
 14/33

C OMPLEMENTING T ESTING : F ORMAL V ERIFICATION

A Sorting Program:
i n t * sort(i n t * a) {
...
}
 14/33

C OMPLEMENTING T ESTING : F ORMAL V ERIFICATION

A Sorting Program:
i n t * sort(i n t * a) {
...
}

Testing sort:
√
sort({3, 2, 5}) == {2, 3, 5}
√
sort({}) == {}
√
sort({17}) == {17}
 14/33

C OMPLEMENTING T ESTING : F ORMAL V ERIFICATION

A Sorting Program:
i n t * sort(i n t * a) {
...
}

Testing sort: Typically missed test cases

√
sort({3, 2, 5}) == {2, 3, 5} sort({2, 1, 2}) == {1, 2, 2} ☒
√
sort({}) == {} sort(null) == exception ☒
√
sort({17}) == {17} isPermutation(sort(a), a) ☒
 15/33

F ORMAL V ERIFICATION AS T HEOREM P ROVING

Theorem (Correctness of sort()) For any given non-null int

array a, calling the program sort(a) returns an int array that is
sorted wrt ≤ and is a permutation of a.

However, methodology differs from mathematics:

1. Formalize the expected property in a logical language
2. Prove the property with the help of an (semi-)automated tool
 16/33

WHAT ARE F ORMAL M ETHODS ?

The Encyclopedia of Software Engineering defines

formal methods in the following manner:
Formal methods used in developing computer systems
are:
• mathematically based techniques for
describing system properties. Such formal
methods provide frameworks within which
people can:
• specify, develop, and verify systems in a
systematic, rather than ad hoc manner.
 16/33

WHAT ARE F ORMAL M ETHODS ?

A method is formal if it has a sound mathematical basis,
typically given by a formal specification language.
This basis provides a means of precisely defining notions
like:
• consistency
• completeness, and more relevantly specification,
• implementation and correctness.
Correctness:
the property that an abstract model fulfills a set of
well defined requirements.
Consistency:
to be consistent, facts stated in one place in a
specification should not be contradicted in another
place.
 16/33

WHAT ARE F ORMAL M ETHODS ?

Rigorous techniques and tools for the development and

analysis of computational (hardware/software) systems

Applied at various stages of the development cycle

Also used in reverse engineering to model and analyze

existing systems
 16/33

WHAT ARE F ORMAL M ETHODS ?

Rigorous techniques and tools for the development and

analysis of computational (hardware/software) systems

Applied at various stages of the development cycle

Also used in reverse engineering to model and analyze

existing systems

Based on mathematics and symbolic logic (formal)

 18/33

W HY USE F ORMAL M ETHODS

Mathematical modeling and analysis contribute to the overall

quality of the final product

Increase confidence in the correctness/robustness/security

of a system

Find more flaws and earlier (i.e., during specification and

design vs. testing and maintenance)
 19/33

F ORMAL M ETHODS : THE V ISION

Complement other analysis and design methods

Help find bugs in code and specification

Reduce development, and testing, cost

Ensure certain properties of the formal system model

Should be highly automated

 21/33

A W ARNING

The notion of “formality” is often misunderstood

(formal vs. rigorous)

The effectiveness of formal methods is still debated

There as still persistent myths about their practicality

and cost

Formal methods are not yet widespread in industry

They are mostly used in the development of safety, business,

or mission critical software, where the cost of faults is high
 22/33

THE MAIN P OINT OF F ORMAL M ETHODS IS NOT

To show “correctness” of entire systems

• What is correctness? Go for specific properties!

To replace testing entirely

• Formal methods do not go below byte code level
• Some properties are not formalizable

To replace good design practices

There is no silver bullet!

No correct system w/o clear requirements & good design
 23/33

O VERALL BENEFITS OF U SING F ORMAL M ETHODS

Forces developers to think systematically about issues

Improves the quality of specifications, even without formal
verification
Leads to better design
Provides a precise reference to check requirements against
Provides documentation within a team of developers
Gives direction to latter development phases
Provides a basis for reuse via specification matching
Can replace (infinitely) many test cases
Facilitates automatic test case generation
• Higher quality software
• Verifiability of implementation
• Insight and understanding
• Minimized maintenance and cost
• Automated assistance
• Simulation, animation, execution
• Formal analysis
• Guidance for testing
• Transformation technology
• Reduced liability and risks
• Standard satisfaction
Use of Formal methods

• There is an increasing interest about formal methods and

their applications.

• Formal methods have the potential to provide increased

confidence in a system by satisfying the standards set by
regulatory bodies.
Formal methods are not meant to

• to show correctness" of entire systems

to replace testing entirely

• Formal methods work on models, on source code

• to replace good design practices

• One can't formally verify messy code with unclear

specs.

• We are not developing(programming) a complete

system using Formal methods.
Formal methods are meant for

But ….
• Formal proof can replace (infinitely) many test cases

• Formal methods improve the quality of specs (even

without formal verification)

• Formal methods guarantee specific properties of

system model
SUMMARY

• Formal methods are used to ensure correctness and

reliability of software systems

• Formal methods are based on mathematical models.

• Formal methods are difficult to apply but results are

fruitful.

• Formal methods does not mean we are programming a

part of the system.

• We are verifying the system correctness using formal

methods.