SE306 Formal Methods

1. Introduction

03/17/22 SE306-1 1
 Topics
• What are formal methods?
• Why formal methods?
• Formal method details
– Formal specification
– Formal proofs
– Model checking
– Abstraction
• Limitation
• Seven myths

03/17/22 SE306-1 2
 Software Engineering and Formal Methods

 Every software engineering methodology is based on a

recommended development process
 proceeding through several phases:
 Requirements, Specification, Design
 Coding, Unit Testing
 Integration and System Testing, Maintenance

 Formal methods can

 Be a foundation for designing safety critical systems
 Be a foundation for describing complex systems
 Provide support for program development

03/17/22 SE306-1 3
 What are Formal Methods?

 Techniques and tools based on mathematics and formal logic

 Can assume various forms and levels of rigor
 Informal
 Low
 Medium
 High

03/17/22 SE306-1 4
 Why Consider Formal Methods?
 The development of a formal specification provides insights
and an understanding of the software requirements and
software design
 Clarify customers’ requirements
 Reveal and remove ambiguity, inconsistency and
incompleteness
 Facilitate communication of requirement or design
 Provides a basis for an elegant software design
 Traceability
 System-level requirements should be traceable to
subsystems or components

03/17/22 SE306-1 5
03/17/22 SE306-1 6
 Formal Methods Concepts

Formal Methods

Formal Formal Model Abstraction

checking
specification Proofs

03/17/22 SE306-1 7
 Formal Specification

 The translation of non-mathematical description (diagrams, table,

natural language) into a formal specification language
 It represents a concise description of high-level behavior and
properties of a system
 Well-defined language semantics support formal deduction about
the specification

03/17/22 SE306-1 8
 Type of Formal Specifications

 Model Oriented: Construct a model of the system behavior using

mathematical objects like sets, sequences etc.
 Statecharts, SCR (Software Cost Reduction), VDM, Z
 Petri Nets, CCS, CSP (communicating sequential processes),
Automata theoretic models
 Property Oriented: Use a set of necessary properties to describe
system behavior, such as axioms, rules etc.
 Algebraic semantics
 Temporal logic models.

03/17/22 SE306-1 9
 Formal Proofs

 Proof is an essential part of specification

 Proofs are constructed as a series of small steps, each of which is
justified using a small set of rules
 Proofs can be done manually, but usually constructed with some
automated assistance

03/17/22 SE306-1 10
 Model Checking
 A technique relies on building a finite model of a system and
checking that a desired property holds in that model
 Two general approaches
 temporal model checking
 automaton model checking
 Use model checkers
 SMV

03/17/22 SE306-1 11
 Abstraction

 Representation of the program using a smaller model

 Allows you to focus on the most important central properties and
characteristics
 Getting the right level of abstraction is very important in a
specification.

03/17/22 SE306-1 12
 Abstraction -- Mathematical Models

 Abstract representations of a system using mathematical entities

and concepts
 Model should capture the essential characteristics of the system
while ignoring irrelevant details
 Model can be analyzed using mathematical reasoning to prove
system properties or derive new behaviors.
 Two types
 Continuous models
 Discrete models

03/17/22 SE306-1 13
 Abstraction -- Formal Specification Process
Model
 Clarify requirements and high level design
 Articulate implicit assumptions
 Identify undocumented or unexpected assumptions
 Expose defects
 Identify exceptions
 Evaluate test coverage

03/17/22 SE306-1 14
 Benefits of Formal Specifications

 Higher level of rigor leads to better problem understanding

 Defects are uncovered that would be missed using traditional
specification methods
 Allows earlier defect identification
 Formal specification language semantics allow checks for self-
consistency
 Enables the use of formal proofs to establish fundamental system
properties and invariants

03/17/22 SE306-1 15
 Limitations to Formal Methods

 Requires a sound mathematical knowledge of the developer

 Different aspects of a design may be represented by different
formal specification methods
 Useful for consistency checks, but formal methods cannot
guarantee the completeness of a specifications
 For the majority of systems they do not offer significant cost or
quality advantages over others

03/17/22 SE306-1 16
 Seven Myths on Formal Methods

 By Anthony Hall, Praxis Systems

1. Formal Methods can guarantee that software is perfect

2. They work by proving that programs are correct
3. Only highly critical systems benefit from their use.
4. They involve complex mathematics
5. They increase the cost of development
6. They are incomprehensible to clients (means: clients cannot understand)
7. Nobody uses them for real projects.

03/17/22 SE306-1 17
1. Formal Methods can guarantee that software
is perfect

 Not true.
 Formal methods are fallible
 mistakes in modeling
 mistakes in doing proofs
 Formal methods help eliminate certain sort of errors.

03/17/22 SE306-1 18
 2. They work by proving that programs are
correct

 Not true.
 The fact is that formal methods are all about specifications.
 The main activities included are:
1. Writing a formal specification
2. Proving properties about the specifications
3. Constructing a program by mathematically
manipulating the specifications and
4. Verifying a program by mathematical argument.

03/17/22 SE306-1 19
 3. Only highly critical systems benefit from
their use.

 Not true.
 The fact is that formal specifications help with any system.
 Applying formal methods can benefit many areas, including
fitness for purpose, maintainability, ease of construction, and
better visibility.
 Formality offers ways to ensure the right software to be built.
 Experiences shows that it is easier to build a system from a
formal specification than by using other methods.

03/17/22 SE306-1 20
 4. They involve complex mathematics

 Not true
 The fact is that the mathematics for specifications is easy.
 Of course, before engineers can use formal methods, they
must be trained
 The mathematics is easy but it does not mean that everything
is easy.
 The main difficulty is making the right connections between
the real world and mathematical formalism.
 However, these are problems of any kind of specification, not
a problem introduced by formality.

03/17/22 SE306-1 21
 5. They increase the cost of development

 Not true.
 The fact is that writing a formal specification decreases the
cost of development.
 It is difficult to compare the cost of developing software
under different methods.
 However, experiences show that developing software with
formal methods are lower cost.
 Life-Cycle changes:
 More time is spent on the specifications phase before
implementation starts.
 Therefore the implementation, integration, and testing phase
are shorter.

03/17/22 SE306-1 22
 6. Formal methods are unacceptable to users

 Not true
 The fact is that formal specifications help users understand
what they are getting.
 The specifications captures what the user wants before it is
built.
 Formal specification should be accompanied with explanation
in natural language.
 Experience has shown that documents produced from a
formal specification can be more comprehensible, more
accurate, shorter, and more useful than informal
specifications.

03/17/22 SE306-1 23
 7. Nobody uses them for real projects

 Not true
 The fact is that formal methods are used daily on industrial
projects.
 Used much more in European countries than in USA

03/17/22 SE306-1 24