Formal Methods

1
 Background - Problems in Software Development
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?
2
 Background - Problems in Software Development
An example of informal /Ambiguous specification:

“A software system for an Automated Teller Machine (ATM) needs to

provide services on various accounts. The services include operations
on current account & savings account, transferring money between
accounts, managing foreign currency account, and change password.
The operations on a current or savings account include deposit,
withdraw, show balance, and print out transaction records.”

3
 Background - Problems in Software Development
A better way to write the same specification:
“A software system for an ATM needs to provide services

The services include The operations on a current or

① operations on current account savings account include

② operations on savings account ① deposit

③ transferring money between accounts ② withdraw

④ managing foreign currency account, ③ show balance

⑤ change password. ④ print out”

4
Specification - Natural Language
◼ Deficiencies of natural language
◼ Can be vague

◼ Can be ambiguous

◼ Can be self-contradictory

◼ Can be incomplete

◼ Encourages imprecise thinking

◼ Cannot easily handle abstractions

5
Weakness of Natural Language Specifications
Withdraw:

“Receives a requested amount to withdraw from the bank account

and, if there are sufficient funds in the account, meets the request.

Returns a Boolean value indicating success or failure of the attempt to

withdraw money from the account.”

Natural language descriptions do not have a fixed meaning, they are ambiguous.
These notations do not have a fixed semantics
Incomplete specifications
A specification can be considered incomplete when the behaviour
is not completely defined.

Withdraw:

“Receives a requested amount to withdraw from the bank account

and, if there are sufficient funds in the account, meets the request.

Returns a boolean value indicating success or failure of the

attempt to withdraw money from the account.”
Incomplete Specifications
A specification is inconsistent when contains contradictions within.

Withdraw:

“Receives a requested amount to withdraw from the bank account

and, if there are sufficient funds in the account, meets the request.

Returns a boolean value indicating success or failure of the attempt

to withdraw money from the account.”

OVERDRAFT?
Formal Languages
It is desirable to use a specification notation with a fixed, unambiguous,
semantics.

Notations that have a fixed semantics are known as formal notations, or formal
languages.

A fixed semantics is achieved by defining a language in a completely unambiguous

way using a mathematical framework.
A possible solution to these problems:

Formal Languages / Methods

10
 Formal Methods for the Problems
Formal methods = Formal Specification
+
Refinement
+
Formal Verification

Set theory, logics, algebra, etc.

11
Formal Methods: Definition
◼ Mathematically based techniques for the specification,
development and verification of software and hardware systems.

◼ Can determine if:

◼ Specifications are satisfied

◼ Implementation of a system is correct

◼ Proving properties of a system

12
Introduction to Formal
Specification

13
Formal Specification Language

◼ Formal Methods centred around a notation known as a formal

specification language
Formal Semantics
◼ Mathematical base allows precise notions

◼ Unambiguous

◼ Allows consistency, correctness in specification and implementation

Increase Human Understanding of Specified System

&
Allow the possibility of formal reasoning and development

14
Levels of Formal Specification
LEVEL 0 1. 1. Requirements Only
Formal Specification 2. No Analysis/Proof
3. Cost effective

2. 1. Produce a program in a more formal manner

LEVEL 1
2. Use proofs of properties or refinements from
Formal Verification
formal specification
3. Costly

3. 1. Use theorem prover

LEVEL 2
Theorem Provers 2. Fully formal machine-checked proofs.
3. Expensive, hard and often costly
4. Formally prove the entire system 15
Purpose of Formal Specification
◼ To state what system should do without describing how
to do it

◼ To reduce faults in systems

◼ Invest more effort is early stage of system development
◼ Requirement errors can be discovered as early as possible and
resolved

16
Specification Parts
◼ A specification need to include
◼ Details of the system
◼ The states it can occupy

◼ Invariants which will always hold

◼ Dynamic aspects
◼ All operations which are possible

◼ The relations of inputs to outputs

◼ Changes of state that can occur

17
Specification Parts

◼ A specification will include

◼ Functional requirements
◼ The effect of xxx will be

◼ The output of command yyy will be as specified in standard zzz

◼ The system will produce a report on salesman effectiveness

18
Specification Parts
◼ A specification will include
◼ Non-functional requirements (properties)
◼ All data access should be via company supplied subroutines

◼ The system should be immune to power failures

◼ The response time must be …

19
Specification Parts
◼ A specification will include
◼ Design directives
◼ The system will collect data from …

◼ The VDU display will be in the form …

◼ The designer will use SSADM

❖ Visual Display Unit

❖ Structured Systems Analysis and Design Method
20
Specification Parts
◼ A specification will include
◼ Goals
◼ Response times should be minimised

◼ It should run in 512MB of memory

◼ Data Statements
◼ The system must maintain the average temperature over the preceding …

21
Definition - Formal Specification
◼ The approach is especially important in high-integrity
systems, for example where safety or security is
important, to help ensure that errors are not
introduced into the development process.

From Wikipedia, the free encyclopedia. http://en.wikipedia.org/wiki/Main_Page

22
Definition - with a Scientist’s Quote
◼ Formal methods are particularly effective early in
development at the requirements and specification levels.
◼ Software engineers want to be real engineers.

◼ Real engineers use mathematics.

◼ Formal methods are the mathematics of software engineering.

Therefore, software engineers should use formal methods.

(Mike Holloway, NASA)

23
Formal Methods - Parts
◼ Program specification

◼ Program verification

◼ Automated theorem proving

◼ Model checking

24
Formal Methods - Program Specification
◼ A program specification is the definition of what a
computer program is expected to do

◼ It can be
◼ informal, in which case it can be considered as a blueprint or
user manual from a developer point of view, or

◼ formal, in which case it has a definite meaning defined in

mathematical or programmatic terms.

25
Formal Methods - Program Verification
◼ In computer science, program verification is the process of
formally proving that a computer program does exactly what is
stated in the program specification it was written to realize

◼ Program verification is more specific in that it aims to verify the

code itself, not only some abstract model of the program.

◼ Intel, AMD: verify chips

◼ BMW: automotive system

26
Formal Methods - Automated Theorem Proving
◼ Automated theorem proving is the proving of
mathematical theorems by a computer program.
Depending on the underlying logic, the problem of
deciding the validity of a theorem varies from trivial to
impossible.

27
Formal Methods - Model Checking
◼ Model checking is a method to algorithmically verify
formal systems. This is achieved by verifying if the
model, often deriving from a hardware or software
design, satisfies a formal specification. The specification
is often written as temporal logic formulas.

28
Formal VS. Informal Methods
◼ Formal specification vs. SSADM

◼ SSADM
◼ now government standard
◼ Widely used in industry

29
Formal VS. Informal Methods
◼ Lots of possible inconsistencies
◼ Decision tables

To prove that, if you use “don’t care” entries, the result is

completely and uniquely defined?

◼ Computer tools to help overcome the difficulties, but

are still basic problems

30
Specification - Mathematics vs. Natural Language
◼ Deficiencies of natural language
◼ Can be vague

◼ Can be ambiguous

◼ Can be self-contradictory

◼ Can be incomplete

◼ Encourages imprecise thinking

◼ Cannot easily handle abstractions

31
Specification - Mathematics - Good Features
◼ Easily handle abstractions

◼ Can be used for reasoning about, and describing a

system

◼ Is concise

◼ Is non-ambiguous

32
Specification - Mathematics - Good Features
◼ Is applied widely to the real world

◼ Can approximate where exactness is unnecessary

◼ Changes slower than computing

33
Formal Notation – Drawbacks

◼ The customer cannot easily understand the specification

◼ The mathematics used is unfamiliar to many of the staff

◼ In real world, getting user requirements document is a

problem

34
 Formal
◼ Logic Specification Methods
◼ Z, VDM, First order logic, temporal logic

◼ State Machines
◼ Finite state machines, communicating state

machines, extended state machines

◼ State Chart, Objectime, Automata

◼ Petri Nets

35
Z

◼ A formal specification technique developed at Oxford

◼ Uses very mathematical notation to provide exact

definitions of a system

◼ System is described in a number of small Z modules,

which can cross-refer each other

◼ Each module is expected to have some descriptive

English text to help users to understand it
36
Summary
◼ Background of formal specification

◼ Parts of specification

◼ Formal specification vs.

◼ SSADM

◼ Natural language

◼ Formal method advantages and drawbacks

◼ Z specification language
37
Good papers to begin with:
◼ “Formal Methods: State of the Art and Future Directions”,
Edmund M. Clarke, Jeannette M. Wing, ACM Computing
Surveys, 1996

◼ “Ten Commandments of Formal Methods ... Ten Years Later”,

Jonathan P., Bowen and Mike Hinchey, IEEE Computer,
39(1):40-48, January 2006.

38
Case Studies: CUTE

◼ CUTE: A Concolic Unit Testing Engine for C

◼ Developed by a team managed by Gul Agha – 2005
◼ Concolic testing
◼ use the symbolic execution to generate inputs
that direct a program to alternate paths
◼ use the concrete execution to guide the
symbolic execution along a concrete path

39
Case Studies: CUTE

◼ CUTE was used to automatically test SGLIB, a

popular C data structure library used in a
commercial tool
◼ CUTE took less than 2 seconds to find two
previously unknown errors!
◼ a segmentation fault
◼ an infinite loop
◼ The homepage of CUTE:
◼ http://osl.cs.uiuc.edu/~ksen/cute/

40
Case Studies: Intel’s Successes
http://www.cse.ogi.edu/S3S/JohnHarrison.pdf

◼ Intel uses formal verification quite extensively

◼ Verification of Intel Pentium 4 floating-point unit with a mixture of
STE and theorem proving
◼ Verification of bus protocols using pure temporal logic model
checking
◼ Verification of microcode and software for many Intel Itanium
floating-point operations, using pure theorem proving
◼ FV found many high-quality bugs in P4 and verified “20%”
of design
◼ FV is now standard practice in the floating-point domain

41
 Case Studies: NASA SATS
◼ Small Aircraft Transportation System (SATS)

http://sats.nasa.gov/

◼ Use of a software system that will sequence aircraft

into the SATS airspace in the absence of an airport
controller
◼ There are serious safety issues associated with
these software systems and their underlying key
algorithms 42
 Case Studies: NASA SATS
◼ The criticality of such software systems necessitates
that strong guarantees of the safety be developed
for them
◼ Under the SATS program NASA Langley researchers
are currently investigating rigorous verification of
these software system using formal methods
◼ Modeling and Verification of Air Traffic
◼ Conflict Detection and Alerting
◼ …

43
Chuti?

Nai
44