0

 Course administration
 Why FMSE ?
 Course Objectives
 Problems in software development
 Formal Methods
 Formal Logic
 Etc.

1
 Formal Methods in
Software
Engineering

Software Importance
Why ? What ? How ?
Engineering? of Software?

2
 The course is about learning to develop abstract Models of complex
systems, either in software or the real-world

 We shall cover developing different types of models primarily using

Formulas i.e. Maths

3
 Systems are increasingly dependent on software components e.g.
microwave oven, washing machine, cars etc.  increased complexity
because of embedded software

 Maintaining reliability in software-intensive systems is very difficult

4
 History of software bugs
 Softwares encountered notorious bugs that were the cause of financial
lose and deaths of many people.

 Famous bugs are

i. Therac-25 (1985-1987)
 A bug in the code controlling the Therac-25 radiation therapy machine
was directly responsible for at least five patient deaths in the 1980s
when it administered excessive quantities of X-rays.
 Reading http://sunnyday.mit.edu/papers/therac.pdf

5
ii. Ariane 501
On 4 June 1996, the Ariane 501 satellite launch failed terribly 40
seconds after initiation of the flight sequence, incurring a direct cost of
approximately $370 million
 Reading: The ARIANE 5 Software Failure, Mark Dowson, Software
Engineering Notes vol 22 no 2, pp 84

iii. The Millennium Bug, or Y2K

Two digits were used to show the date, e.g. 98 instead of 1998, the
year 2000 could only be represented as ’00′, which might confuse
computers into thinking it meant the year 1900

6
iv. Pentium bug
 Software error in microcode of Pentium microprocessor, which
resulted in error of floating point calculations problems.
 Intel had to take back all the Pentiums, and it caused huge loss of
dollars.

 Etc….

7
 Beyond the financial impact, the media emphasized the loss of
confidence shown by users that had a much broader and dramatic effect
to the company

 How to avoid bugs?

 With core focus on problems occur during software development

i. Software Development ?
ii. Problems in software development ?
iii. Tackle with problems ?

8
 Process of computer programming, documenting, testing, and bug
fixing  a software product.

 Software development life cycle (SDLC) is a framework defining tasks

performed at each step in the software development process

 Examples:
 Waterfall Model
 Iterative Model
 Spiral Model
 Prototyping Models
 etc.

9
 Specification Program

Construct
S P

What to do How to do it
 How to ensure that S is not ambiguous so that it can be correctly
understood by all the people involved?
 How can S be effectively used for inspecting and testing P?
 How can software tools effectively support the analysis of S,
transformation from S to P, and verification of P against S?

10
Testing
 Is a technique for detecting errors or problems in implemented software,
hardware, or non-computer systems e.g white box, black box testing etc.

Output fulfill
Set of finite inputs System specifications ?

Verification
 checking the software with respect to the specification  developing
product right

Validation
 checking the software with respect to the user requirements  developing
right product
11
 Requirements
analysis
Validation

Formal
Specification

Verification

Design

Verification
Coding

Testing

12
Bug-free software: A Myth?

 "Testing can show the presence of errors, but not their absence."
Edsger Dijkstra
 With thousands of examples, theorem cannot be proven correct.

 Example: To disprove a mathematical theorem, all you need is a single

counter-example. E.g. All numbers < 100,000,
-1000, -102, -1000000, 0, 1, 3, 500, 1000, . .. . (Holds), 100, 000, . . . (fails)

13
 Test case is only an example/scenario
 One scenario may works
 All scenarios may not work

 Overhead with test cases: Not possible to write huge number

of test cases

 Formal Proof is alternative  will be covered in Lecture #2

14
Black-box Testing?
 Test two equal Strings .
 isEqual (“Cat”, Dog”) – Expected output: False
 isEqual (“Testing”, Testing”) – Expected output: True
 isEqual (“House”, Home”) – Expected output: False
 Many number of possibilities

15
15
 Example Function
 Programming Exp:.
bool equal = strlen(String1)== strlen(String2);
If (equal)
for ( i =0; i<strlen(String1); i++)
equal = String1[i] = = String2 [i];
return equal;

 isEqual (“Cat”, Dog”) – Expected output: _____  actual : ____

 isEqual (“Testing”, Testing”) – Expected output:___ actual : ___
 isEqual (“House”, mouse”) – Expected output:___ actual : ___
16
16
Q: Write two example strings along with corresponding function
output e.g (Laptop, Desktop), (happy, angry) etc and justify your
output.

17
18
1. Statement coverage
2. Branch coverage
3. Path Coverage

19
20
 N=20
 1 Million possible paths
 Can we test then all paths for all values of N?
 Can we take this type of chances with critical software?
 Flying a plane, reactors and so on.
 System failure can be more expensive than the system itself. .
 . Human lives and resources.. .
 FM can find errors with far fewer test cases than testing (white box, black
box etc.)

21
 In computer science and software engineering, formal methods are
techniques and tools based on mathematics and formal logic used for the
specification, development and verification of software and hardware
systems.
 Formal methods for software also referred to as Software Reliability
Methods

 Characteristics:
 Correctness
 Consistency
 Completeness

22
• Multiple definitions:
 The study of reasoning : specifically concerned with whether
something is correct or false.
 Formal logic focuses on the relationship between statements as
opposed to the content of any particular statement.

23
Example 1: Imagine some one is a mechanic and he know that
either the fuel filter is clogged or the fuel pump is defective. But
he just replaced the fuel filter. So he 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.

24
 Methods to ensure that software is

 Correct

 Reliable

 These two attributes deal with the software quality.

25
 It is very important to note that formal verification:
 does not prevent the need for testing and other assertion techniques.
 cannot fix bad assumptions in the design,
 can help identify errors in reasoning

 So, Formal Verification if used, it will be used as an additional tools

for assertions and not as a replacement tool  High cost

 Example: identification of design flaws after formal review

26
 Can be expensive
 Only used fully on safety-critical system components

 Can only prove that model of system satisfies given property

(“requirements”)
 Model may be wrong
 requirements may be inadequate or wrong

27
 Build models of our system
 Use Mathematical techniques such as predicate calculus, propositional
calculus etc.
 We analyse the correctness of these models using mathematical
techniques

 What is a Model? Why Model required and How it help us?

 Diskstra’s Game

28
 Rules:
Out balls In ball
(2 black out, 1 black in) b-2+1, w = b-1, w
f(b , w) = (2 white out, 1 black in) b+1, w-2
(1 of each out, 1 white in) b-1, w-1+1 = b-1, w

Mathematical models use functions.

I. Function f(b , w) ?
II. Will the game end or not?
III. If given w white and b black ball, can you determine the color of
last ball?

29
1. Total Even number of white balls , last ball color ? 1 ball game
end
2. Total Odd number of white balls, last ball color ?

2 ball game
Hypothesis : last ball color depends on parity 3 possible combinations
of white balls:
1. Even white balls  Black ball left at the end
2. Odd white balls  White ball left
3 ball game

If we play with 100 balls, then can we prove our

hypothesis?

30
f(b,w)=
 (2 black out, 1 black in) b-2+1, w = b-1, w or (w-0)
We reduce the number of black balls by 1 and we maintain
the number of white balls.

• (2 white out,1 black in) w-2,b+1

We reduce the number of white balls by 2 and increase the
number of black balls by 1.

• (1 of each out,1 white) in b-1,w-1+1=(w) or (w-0)

we reduce the number of black balls by 1 and maintain the
number of white balls.

31
 Total number of balls removed in each move is 1.

 Parity(even/odd number) of white balls does not change.

 Yes we will say the parity of white balls determine the outcome of
the game.

 Hence hypothesis is correct.

32
 Problems in software development
 Testing vs Formal Methods
 Specification
 Limitations of FM
 Dijkstra’s game

33
34