An introductory talk on formal methods in software engineering given at Aligarh Muslim University on 22 Nov 2016 for the UG and PG students.

1. Introduction to Formal Methods
in Software Engineering
Inzemamul Haque
22 Nov 2016

2. Acknowledgement
• Dr. K.V. Raghavan and Dr. Deepak D’Souza for
the content from their course “Formal
Methods in Software Engineering”

3. Outline
• Motivation
• Definition
• Alloy
• Model-checking

4. Motivation
• Software projects fail [Barry Boehm, ICSE’06]
– 90% overrun on cost
– 121% overrun on schedule
– Delivers only 61%
• Finding and fixing bugs consume 50% of total
effort in software development

5. Causes of failure
• User requirements not specified properly

6. Causes of failure
• User requirements not specified properly
• Design does not meet user requirements

7. Causes of failure
• User requirements not specified properly
• Design does not meet user requirements
– More than 50% of all defects due to above two
reasons

8. Causes of failure
• User requirements not specified properly
• Design does not meet user requirements
– More than 50% of all defects due to above two
reasons
• Implementation errors
– Low-level errors such as null-pointer dereference ,
array index out of bounds

9. Causes of failure
• User requirements not specified properly
• Design does not meet user requirements
– More than 50% of all defects due to above two
reasons
• Implementation errors
– Low-level errors such as null-pointer dereference ,
array index out of bounds
– As software ages, size increases, hence complexity
increases
– Hence implementation errors increase with age

10. Causes of failure
• User requirements not specified properly
• Design does not meet user requirements
– More than 50% of all defects due to above two
reasons
• Implementation errors
– Low-level errors such as null-pointer dereference ,
array index out of bounds
– As software ages, size increases, hence complexity
increases
– Hence implementation errors increase with age
Using mathematical
techniques can help

11. Formal methods - definition
• Formal methods in software engineering are
mathematical techniques employed in
software development to make it more
reliable and robust
• Various tools based on these techniques have
been developed

12. Alloy
• Formal modelling of entities and associations
using sets and relations
• Modelling of constraints on the entities
• Analyzing the consistency of the model and
identifying the errors

13. Example – family relationships
• Relationships between “Person” entity
• Constraints:
– Every person has two parents
– Parents of any child are married
– Cannot marry a sibling or a parent
– Every person is married to at most one person
– a married to b implies b is married to a
– A man can only marry a woman and vice-versa

14. How Alloy works
• An Alloy model M is interpreted as a conjunctive
logical formula, fM
• Constraints enforced by signatures as well as facts
automatically become part of fM
• An instance or solution to the model is
– A finite universe U of atoms
– An assignment of subsets of U to the different
signatures
– An assignment of relations to different relations
such that it satisfies fM

15. Modelling notation to logical formula
• For example
“no p: Person | some p.spouse & p.parents”
becomes

17. Model-checking
• Model-checking can be used to check if an
initial design satisfies certain properties
• Given an abstract model like a state machine,
and a specification of behaviour (typically in
temporal logic), model checker tries to check
whether model satisfies the property
• If not provides a counter-example

18. Example
“nocreate” - Once a task has ended it is never created
again.
“nostarve” - Once a task is ready it eventually runs
“stateseq“ - Each task follows specified state motion

19. Temporal logic
• p: an atomic proposition
• X p: property p holds starting in next state
• F p: property p holds eventually in a future
state
• G p: property p holds at all future states
• U(p,q): property q holds eventually and p
holds till that time.

20. Model-checking
• Property P can be expressed as LTL formula, F
• Construct a “Buchi-automata”, A, for not F
• Take “product” of A with transition system of
the model, T
• Look for accepting path in this product
• If such a path exists, this is a counter-example
to the claim that T satisfies the property P
• If no such path exists, then T satisfies P

22. Buchi automata

23. Some model checkers
• SAL – developed by Stanford Research
Institute
• SLAM – developed by Microsoft Research
• BLAST – developed by University of California,
Berkeley

24. VCC
• Works on Hoare Logic