CS-SE-5031

Formal Methods in
Software Engineering

1
 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

2
 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

3
 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
4
 Formal Methods Concepts

Formal Specification Methods

Formal Formal Model Abstraction

checking
specification Proofs

5
 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

6
 Type of Formal Specifications

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

mathematical objects like sets, sequences etc.
 Statecharts, SCR, VDM, Z
 Petri Nets, CCS, CSP, 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.

7
 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

8
 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

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

10
 Mathematical Models

 Abstract representations of a system using mathematical entities and

concepts

 Model should captures 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

11
 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

12
 Cleanroom software development

 Spend a lot of effort "up-front" to prevent defects

 Formal specification

 Incremental development

 Statistical methods to ensure reliability

13
 Cleanroom Process

 Formal specification using a state transition model

 Structured programming - limited control and abstraction constructs are

used
 Program resembles state machine

 Static verification using rigorous inspections

 Mathematical arguments

 Statistical testing of the system reliability

14
 Cleanroom Process

Formally Error rework

specify
system

Define Construct Formally

Integrate
software structured verify
increment
increments program code

Develop
operational Design Test
profile statistical integrated
tests system

15
 Cleanroom Process

 Incremental development
 Allows freezing of requirements, so formal work can proceed
 Work on critical functionality in early revisions, so it receives
the most testing

16
 Cleanroom Process

 Specification team.
 Develop and maintain system specification

 Development team.
 Develop and verify (mathematically) the software.
 The software is not executed or even compiled during this process

 Certification team.
 Develop set of statistical tests to exercise the software after
development.
 Reliability growth models used to determine when reliability is
acceptable
17
 Test Results

 Successful in the field

 Few errors
 Not more expensive than other processes

 Generally workable
 Higher quality code resulted

18
 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

19
 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 Does not offer significant cost or quality
advantages over others

20