FORMAL METHODS IN

SOFTWARE ENGINEERING
LECTURE # 01
INTRODUCTION TO FORMAL METHODS
INSTRUCTOR: SAIMA ZAREEN
ASSISTANT PROFESSOR
DEPARTMENT OF SOFTWARE ENGINEERING
[email protected]
OBJECTIVES

• IN THIS COURSE STUDENTS WILL LEARN HOW TO REPRESENT COMPUTING

SYSTEMS WITH BOTH STATE-BASED AND PROCESS BASED ALGEBRA MODELS.

• THEY SPECIFY COMPUTING SYSTEMS FORMALLY,

• REASON ABOUT SPECIFICATIONS,

• AND VERIFY THEIR PROPERTIES.

• THEY CONNECT SPECIFICATIONS TO PROGRAMMES THROUGH

• REFINEMENT AND

• DECOMPOSITION.

• THEY USE THEOREM PROVING AND MODEL CHECKING TOOLS.

BOOK

• THE B METHOD AN INTRODUCTION BY STEVE

SCHNEIDER
 GRADING POLICY

• QUIZES 10%

• ASSIGNMENTS 5%

• PROJECT 10%

• MID TERM 25%

• FINAL EXAM 50%

WHY FORMAL METHODS ARE
REQUIRED?

• HISTORY OF SOFTWARE BUGS

• SOFTWARES ENCOUNTERED NOTORIOUS BUGS

THAT WERE THE CAUSE OF FINANCIAL LOSE AND
DEATHS OF MANY PEOPLE.

• FAMOUS BUGS ARE

FAMOUS BUGS CONTD..

i. THERAC-25 (1985-1987)

• COMPUTERIZED RADIATION THERAPY MACHINE

CALLED THE THERAC-25.

• KILLED MANY PEOPLE, CONTROLLER COULD NOT

STOP RADIATION DUE TO SOFTWARE BUG, LATER
ON THE PROBLEM WAS FIXED, AFTER KILLING
MANY PEOPLE LIFE.
 FAMOUS BUGS CONTD..

• IN APRIL 1992 THE FIRST F-22 RAPTOR CRASHED

WHILE LANDING AT EDWARDS AIR FORCE BASE,
CALIFORNIA.

• THE CAUSE OF THE CRASH WAS FOUND TO BE A

FLIGHT CONTROL SOFTWARE ERROR
 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
FAMOUS BUGS CONTD..

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.
APPLE MAPS GIVES US
DIRECTIONS TO NOWHERE (2012)
IMPORTANCE OF SOFTWARE

• SOFTWARE IS PRESENT EVERYWHERE MICROWAVE OVEN,

CARS AND SOFTWARE USE IS EXPANDED.

• THAT MEANS A SMALL SOFTWARE ERROR CAN CAUSE YOUR

MICROWAVE OVEN TO EXPLODE, WHERE SYSTEM FAILURE
CAN CAUSE LOSSES MORE THAN THE SYSTEM ITSELF.

• A SOFTWARE PROBLEM CAN CAUSE LIFE LOSES.

• WE HAVE TO BE CAREFUL FOR THE USE OF SUCH SYSTEMS,

WHERE LOSS OF LIFE IS A BIGGER LOSS.
IMPORTANCE OF FORMAL
METHODS IN SOFTWARE
• THIS IS WHAT WE ARE GOING TO STUDY IN FORMAL
METHODS.

• METHODS TO ENSURE THAT SOFTWARE IS

• CORRECT

• RELIABLE
IMPORTANCE OF FORMAL
METHODS IN SOFTWARE CONTD..
• THESE TWO ATTRIBUTES DEAL WITH THE
SOFTWARE QUALITY.

• TO ACHIEVE SOFTWARE QUALITY, WE APPLY

DIFFERENT TECHNIQUES.

• TESTING

• VERIFICATION

• VALIDATION
TESTING

• BLACK BOX TESTING

• TEST INPUT VERSUS OUTPUT

• INPUT

• TWO NUMBERS

• OUTPUT

• AVERAGE

• WHITE BOX TESTING

• TEST THE STRUCTURE OF PROGRAM.

• FOR LOOPS TESTING, CONDITION TESTING

CAN WE TEST EVERY SYSTEM?
"TESTING CAN SHOW THE PRESENCE OF ERRORS, BUT NOT
THEIR ABSENCE."
     - EDSGER DIJKSTRA
TESTING CONTD..

• IN TESTING WE DEVELOP TEST CASES AND DEFINE SCENARIOS, IT

IS NOT POSSIBLE TO HAVE ALL SCENARIOS .

• PROGRAM TO SHOW EQUALITY OF TWO STRINGS.

• ISEQUAL(“CAT”, ”DOG”) EXPECTED FALSE

• ISEQUAL(“TESTING”, ”TESTING”) EXPECTED TRUE

• ISEQUAL(“HOUSE”, ”HOME”) EXPECTED FALSE

• ISEQUAL(“HOUSE”,”MOUSE”) EXPECTED FALSE.

• NO NUMBER OF TEST CASES ASSURE THIS.

 TESTING CONTD..

• SAME IS CASE WITH STRUCTURAL TESTING, WHITE BOX TESTING.

• WHAT IS WRONG WITH THE FOLLOWING CODE?

RELIABILITY

• OBVIOUSLY THERE IS NO GUARANTEE IN LIFE

BUT EVERY ONE WANTS TO HAVE RELIABLE
SOFTWARE.
• IF ,YOU FLY IN A PLANE 100 TIMES PLANE CRASHES
5 TIMES DUE TO SOFTWARE ERROR THEN ,WILL
YOU TRAVEL THROUGH PLANE?
MODEL BASED VERIFICATION
TECHNIQUES
• THESE VERIFICATION TECHNIQUES ARE BASED ON
MODELS DESCRIBING THE POSSIBLE SYSTEM BEHAVIOR
IN A MATHEMATICALLY PRECISE AND UNAMBIGUOUS
MANNER.

• PRIOR TO ANY FORM OF VERIFICATION

• THE ACCURATE MODELING OF SYSTEMS OFTEN LEADS TO

THE DISCOVERY OF INCOMPLETENESS, AMBIGUITIES, AND
INCONSISTENCIES IN INFORMAL SYSTEM SPECIFICATIONS
MODEL BASED VERIFICATION
TECHNIQUES CONTD..
• THE SYSTEM MODELS ARE ACCOMPANIED BY
ALGORITHMS THAT SYSTEMATICALLY EXPLORE ALL
STATES OF THE SYSTEM MODEL.

• THIS PROVIDES THE BASIS FOR A WHOLE RANGE OF

VERIFICATION TECHNIQUES RANGING FROM AN
EXHAUSTIVE EXPLORATION (MODEL CHECKING) TO
EXPERIMENTS WITH A RESTRICTIVE SET OF SCENARIOS
IN THE MODEL (SIMULATION), OR IN REALITY (TESTING).
• ANY VERIFICATION USING MODEL-BASED
TECHNIQUES IS ONLY AS GOOD AS THE MODEL
OF THE SYSTEM.
• MODEL CHECKING IS A VERIFICATION TECHNIQUE
THAT EXPLORES ALL POSSIBLE SYSTEM STATES IN A
BRUTE-FORCE MANNER.

• SIMILAR TO A COMPUTER CHESS PROGRAM THAT

CHECKS POSSIBLE MOVES, A MODEL CHECKER, THE
SOFTWARE TOOL THAT PERFORMS THE MODEL
CHECKING, EXAMINES ALL POSSIBLE SYSTEM
SCENARIOS IN A SYSTEMATIC MANNER.
• IN THIS WAY, IT CAN BE SHOWN THAT A GIVEN
SYSTEM MODEL TRULY SATISFIES A CERTAIN
PROPERTY.

• IT IS A REAL CHALLENGE TO EXAMINE THE

LARGEST POSSIBLE STATE SPACES THAT CAN BE
TREATED WITH CURRENT MEANS, I.E.,
PROCESSORS AND MEMORIES.
• TYPICAL PROPERTIES THAT CAN BE CHECKED USING
MODEL CHECKING ARE OF A QUALITATIVE NATURE.

• IS THE GENERATED RESULT OK?, CAN THE SYSTEM

REACH A DEADLOCK SITUATION, E.G., WHEN TWO
CONCURRENT PROGRAMS ARE WAITING FOR EACH
OTHER AND THUS HALTING THE ENTIRE SYSTEM?

• BUT ALSO TIMING PROPERTIES CAN BE CHECKED:

• MODEL CHECKING HAS BEEN SUCCESSFULLY
APPLIED TO SEVERAL ICT SYSTEMS AND THEIR
APPLICATIONS.
CHARACTERISTICS OF MODEL
CHECKING
• MODEL CHECKING IS AN AUTOMATED
TECHNIQUE THAT, GIVEN A FINITE-STATE
MODEL OF A SYSTEM AND A FORMAL PROPERTY,
SYSTEMATICALLY CHECKS WHETHER THIS
PROPERTY HOLDS FOR (A GIVEN STATE IN) THAT
MODEL.
DIJKSTRA’S GAME
DIJKSTRA’S GAME CONTD..

• CONSIDER THE FOLLOWING GAME TO BE PLAYED BY A

SINGLE PERSON WITH AN URN/JAR AND AS MANY W WHITE
BALLS AND B BLACK BALLS AS HE NEEDS.

• TO BEGIN WITH, AN ARBITRARY POSITIVE NUMBER OF

BALLS IS PUT INTO THE URN AND AS LONG AS THE URN
CONTAINS TWO OR MORE BALLS, THE PLAYER REPEATS
THE FOLLOWING MOVES:

• HE SHAKES THE URN AND, WITHOUT LOOKING, HE TAKES

TWO BALLS FROM THE URN;
 DIJKSTRA’S GAME CONTD..

• RULE 1

• IF THOSE TWO BALLS HAVE THE SAME COLOR

• HE THROWS ONE BLACK BALL INTO THE URN,

• RULE 2
• OTHERWISE HE RETURNS ONE WHITE BALL INTO THE URN

• BECAUSE EACH MOVE DECREASES THE TOTAL NUMBER OF BALLS

INTO THE URN BY 1, THE GAME IS GUARANTEED TO TERMINATE
AFTER A FINITE NUMBER OF MOVES AND IT IS NOT DIFFICULT TO SEE
THAT THE GAME ENDS WITH EXACTLY 1 BALL IN THE URN.
 DIJKSTRA’S GAME CONTD..

• THE QUESTION IS:

• WHAT CAN WE SAY ABOUT THE COLOR OF THE FINAL

BALL WHEN WE ARE GIVEN THE INITIAL CONTENTS
OF THE URN?’”

• DIFFICULT TO ANSWER

• LETS PLAY THE SAME GAME WITH DIFFERENT

NUMBER OF BALLS.
 DIJKSTRA’S GAME CONTD..

• ONE BALL GAME

• THE GAME WILL END

WITHOUT PLAYING

• TWO BALLS GAME

• THREE DIFFERENT
COMBINATIONS OF BALLS

• ONE BLACK, ONE WHITE

• ONE WHITE ,ONE WHITE

• ONE BLACK, ONE BLACK

Dijkstra’s game contd..

2 BALL GAME
DIJKSTRA’S GAME CONTD..

• MATHEMATICAL MODELS USE FUNCTIONS.

• WHAT IS A FUNCTION?

• FUNCTION:

• PUTTING THE BALLS IN JAR IS A FUNCTION

 CONCLUSION FROM 2 AND 3
BALLS GAME
• DEPENDS ON PARITY OF WHITE BALLS, EVEN OR ODD PARITY.

• EVEN NUMBER OF WHITE BALLS, LAST BALL IS BLACK COLOR.

• ODD NUMBER OF BALLS, LAST BALL IS OF WHITE.

• IF WE PLAY WITH 100 BALLS, THEN CAN WE ARGUE OR PROVE

OUR HYPOTHESIS? 

• WHAT IS THE COLOR OF LAST BALL, GIVEN W WHITE BALLS AND

B BLACK BALLS?
WHAT IS THE OUTPUT OF
FOLLOWING CODE?
MATHEMATICAL MODEL AND ITS
PROOF
F(B,W)=

 2 BLACK OUT,1 BLACK IN B-2+1, (B-1,W)

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)

WE REDUCE THE NUMBER OF BLACK BALLS BY 1 AND MAINTAIN THE

NUMBER OF WHITE BALLS.
MATHEMATICAL MODEL AND ITS
PROOF CONTD..
• 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.

THE MODEL-CHECKING PROCESS

1. MODELING PHASE

• MODEL DESCRIPTION LANGUAGE OF THE MODEL

CHECKER AT HAND;

• AS A FIRST SANITY CHECK AND QUICK ASSESSMENT

OF THE MODEL, PERFORM SOME SIMULATIONS;

• FORMALIZE THE PROPERTY TO BE CHECKED USING

THE PROPERTY SPECIFICATION LANGUAGE.
2. RUNNING PHASE:

RUN THE MODEL CHECKER TO CHECK THE VALIDITY OF THE

PROPERTY IN THE SYSTEM MODEL.

3. ANALYSIS PHASE:

PROPERTY SATISFIED? → CHECK NEXT PROPERTY (IF ANY);

PROPERTY VIOLATED? → 1. ANALYZE GENERATED

COUNTEREXAMPLE BY SIMULATION; 2. REFINE THE MODEL, DESIGN,
OR PROPERTY; 3. REPEAT THE ENTIRE PROCEDURE. – OUT OF
MEMORY? → TRY TO REDUCE THE MODEL AND TRY AGAIN.
• THE ENTIRE VERIFICATION SHOULD BE PLANNED,
ADMINISTERED, AND ORGANIZED. THIS IS CALLED
VERIFICATION ORGANIZATION.

4. RUNNING THE MODEL CHECKER

• THE MODEL CHECKER FIRST HAS TO BE INITIALIZED BY

APPROPRIATELY SETTING THE VARIOUS OPTIONS AND
DIRECTIVES THAT MAY BE USED TO CARRY OUT THE
EXHAUSTIVE VERIFICATION.
• THE ACTUAL MODEL CHECKING TAKES PLACE.
THIS IS BASICALLY A SOLELY ALGORITHMIC
APPROACH IN WHICH THE VALIDITY OF THE
PROPERTY UNDER CONSIDERATION IS CHECKED
IN ALL STATES OF THE SYSTEM MODEL.
5. ANALYZING THE RESULTS

• THERE ARE BASICALLY THREE POSSIBLE

OUTCOMES: THE SPECIFIED PROPERTY IS EITHER
VALID IN THE GIVEN MODEL OR NOT, OR THE MODEL
TURNS OUT TO BE TOO LARGE TO FIT WITHIN THE
PHYSICAL LIMITS OF THE COMPUTER MEMORY.

• WE ANALYZE THE VALIDITY OF PROPERTY

• MODELING ERROR

• PROPERTY ERROR

• DESIGN ERROR
• MODELING

• FINITE-STATE AUTOMATA

• TEMPORAL LOGIC
FORMAL METHOD

• 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.
FORMAL METHOD DEFINITION

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

FORMAL METHOD DEFINITION
CONTD..

• 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.
 HOW FORMAL METHODS ARE
APPLIED?
• WE DEVELOP MODELS OF SYSTEM.

• WITH THE HELP OF MODELS WE WILL ARGUE AND PROVE

CORRECTNESS OF MODELS.

• FORMAL METHOD HAS 2 PARTS:

• LOGICAL THEORY:

• MEANS BY WHICH ONE REASONS ABOUT SPECIFICATIONS, PROPERTIES

AND PROGRAMS PREDICATE CALCULUS, (LOGIC ,PROPOSITIONS).

• STRUCTURING THEORY:

• DEFINES ELEMENTS BEING REASONED ABOUT.

FORMAL METHOD STEPS
• WE WILL DEFINE STATE BASED MODEL FOR OUR COMPUTER PROGRAMS USING FORMAL
METHODS.

1. DEFINE THE SPECIFICATIONS OF THE SYSTEM(INFORMAL SPECIFICATION).

2. DEFINE ABSTRACT MODEL OF SPECIFICATIONS.

i. DEFINE THE STATES OF SYSTEM (STEPS OF A MODEL)

ii. DEFINE INVARIANT(CONDITION)

iii. DEFINE SET OF OPERATIONS FOR MODEL TO FUNCTION.

• SYSTEM/MODEL OPERATION IS ASSOCIATED WITH TWO CONDITIONS

• PRE-CONDITION
• POST CONDITION
3. MODEL VERIFICATION AND IMPLEMENTATION

• MAKE FORMAL MODEL AND USE TOOLS TO PROVE MECHANICALLY THAT FORMAL
EXECUTION MODEL SATISFIES FORMAL REQUIREMENTS.
MODEL TYPES

• TWO TYPES OF MODELS ARE DEFINED

• ABSTRACT MODEL

• ABSTRACTION IS THE PROCESS BY WHICH DATA AND PROGRAMS ARE

DEFINED WITH A REPRESENTATION SIMILAR TO ITS PICTORIAL
MEANING.

• HIGH LEVEL SYSTEM DESIGN

• CONCRETE MODEL

• DETAILED MODEL OF THE SYSTEM ACHIEVED AFTER REFINEMENT OF

ABSTRACT MODEL.
FORMALIZATION SPECTRUM
EXAMPLES OF FORMAL
METHODS
• FORMAL METHODS CAN INCLUDE GRAPHICAL
LANGUAGES.

• FOR EXAMPLE,

• DATA FLOW DIAGRAMS (DFDS)

• PETRI NETS

• FINITE STATE MACHINES FSM

 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
 A FUNDAMENTAL FACT

• FORMALIZATION OF SYSTEM REQUIREMENTS IS

HARD.

• BUT WE CAN FORMALIZE CRITICAL

FEATURES/REQUIREMENTS OF SYSTEM.
TOOLS FOR FORMAL SYSTEMS

• PRO-B TOOL

• ATELIER B

• RODIN TOOL
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.
QUESTIONS