Introduction to Formal Methods
Introduction to Formal Methods;
Preconditions, Postconditions, and
Invariants Revisited;
Z language Example (Pressman)
1
What are formal methods?
Formal methods are mathematically based.
They are an attempt to deal with contradictions,
ambiguities, vagueness, incomplete statements, and
mixed levels of abstraction.
They are most valuable for systems which have:
--safety concerns (e.g., airplane systems, medical
devices)
--security concerns
2
When are formal methods useful?
Formal methods can be used to:
--Mathematically PROVE correctness of a system
--Reduce faults
Formal methods can provide:
--program specification: define program is supposed to do
--program verification: PROVE program does what the
specification says it will do
Possible automated verification techniques:
--automated theorem proving
--model checking: exhaustively check all possible “states” of
3
the model that has been developed
Formal techniques
Formal techniques:
--use set theory, logic to specify systems
--increase probability of complete, consistent, unambiguous
specifications
--require specialized training for developers
--have high start-up costs; may require high overhead; some
concepts (e.g., timing, reliability) difficult or impossible to
capture in formal systems
--may be difficult for the customer to understand
--do not replace more traditional approaches
--may be “heavyweight” or “lightweight”
4
When are formal methods useful?
Some examples*:
--diagnosing subtle problems in a LAN recovery protocol
--developing an aircraft collision avoidance system
--developing process control systems
*G. Huling, Introduction to use of formal methods in software and hardware, WESCON/94,
Sep 1994, pp. 48-52, DOI 10.1109/WESCON.1994.403628 (available from IEEE Xplore)
Potentially useful for systems in domains such as:
--security
--avionics
--medical devices
5
When are formal methods useful?
“Heavyweight” formal methods vs “lightweight” formal methods
(which use partial specification and focused application):
“Many factors influence deciding when and where to use lightweight
and heavyweight formal methods. For large complex projects, the
application of a heavyweight formal method is virtually impossible
thus the lightweight formal method is a good candidate. When we are
dealing with safety-critical systems or even, perhaps, trusted
systems (in the ISO 15408 sense), using the lightweight formal
method is debatable. In these cases, it may be better to use a
heavyweight formal specification and analysis if time and cost
permit.”
Application of Lightweight Formal Methods in Requirement Engineering1
V. George ,and R. Vaughn,
Crosstalk, The Journal of Defense Engineering
http://www.stsc.hill.af.mil/crosstalk/2003/01/george.html
6
accessed august 12, 2010
"Ten Commandments" of formal methods
(Pressman, Software Engineering, A Practitioner's Approach):
1. Choose the appropriate notation
2. Formalize but don't overformalize
3. Estimate costs
4. Have a formal methods "guru" on call
5. Do not abandon traditional development methods
6. Document sufficiently
7. Don't compromise quality standards
8. Do not be dogmatic
9. Test, test, test, ….
7
10. Reuse
Preconditions, postconditions, invariants
Earlier we looked at adding statements to ensure correct program
behavior:
precondition: logical condition that a caller of an operation
guarantees before making the call
postcondition: logical condition that an operation guarantees
upon completion
invariant: logical condition that is preserved by transformations
These conditions are all expressed as logical statements
--they can be quantified:
--they can be used to support testing at different levels
8
We will also be concerned with how the STATE of a system or
component changes:
e.g., if the system or a component is in state S, it can be modified
to a new state S’
9
What is Z?
A complete formal system
We will use an example formal specification language: Z
system described through a set of "schemas”, which have
data invariant(s)
state(s)
S: represents change is state S;
changed entity r is denoted by r’
operations-- with precondition(s) / postcondition(s)
10
Example (from Pressman, Software Engineering, A
Practitioner’s Approach): “Block Handler” (note: this is just a
simple example to demonstrate Z syntax, it is not meant to
represent a “safety-critical system” which would be appropriate
for strict formal specification)
Used
blocks
Unused
(free)
blocks
2 5 7 8 10
11 12
13469
2
5 8 11
7
Queued for entry into Unused
Blocks
released
to
queue
when
files
deleted
11
Z example (2)
2 5 7 8 10
11 12
13469
Z specification:
-------BlockHandler---------------------2
5 8 11
used,free:  BLOCKS
BlockQueue: seq P BLOCKS
----------------------------------------------used  free =  
used  free = AllBlocks 
 i: dom BlockQueue . BlockQueue i  used 
7
 i,j : dom BlockQueue . i  j 
BlockQueue i  BlockQueue j = 
12
Some Z notation
2 5 7 8 10
11 12
13469
Z specification:
set
-------BlockHandler---------------------2
5 8 11
intersection used,free:  BLOCKS
BlockQueue: seq P BLOCKS
union
----------------------------------------------- sequence
used  free =  
contained in
“then”
used  free = AllBlocks 
and
.
 i: dom BlockQueue BlockQueue i  used 
 i,j : dom BlockQueue . i  j 
BlockQueue i  BlockQueue j = 
in
for all
7
implies
empty set
intersection
13
Z example (3)
13469
2
5 8 11
7
---------RemoveBlock------------------------- BlockHandler
----------------------------------------------------#BlockQueue > 0,
2 5 7 8 10
11 12
used’ = used \ head BlockQueue 
free’ = free  head BlockQueue 
BlockQueue’ = tail BlockQueue
------------------------------------------------------
---------AddBlock------------------------------ BlockHandler
Ablocks? : BLOCKS
----------------------------------------------------Ablocks?  used,
used’ = used 
free’ = free 
BlockQueue’ = BlockQueue ^ (Ablocks?)
------------------------------------------------------ 14
Modifications
1. What if BlockQueue is replaced by BlockStack?
2. What are postconditions for the operations?
2 5 7 8 10
11 12
13469
2
5 8 11
7
15
Additional Z Notation
16
Z Sequence Notation
17
Z example revisited (1)
Example (from Pressman, Software Engineering, A
Practitioner’s Approach): “Block Handler”
Used
blocks
Unused
(free)
blocks
2 5 7 8 10
11 12
13469
2
5 8 11
7
Queued for entry into Unused
Blocks
released
to
queue
when
files
deleted
18
Modifying the example
Examples:
1. Change BlockQueue to BlockStack:
2. Output size of BlockQueue in AddBlock or
RemoveBlock
3. Make BlockQueue part of “free” instead of
“used”
19
Modifying the example
20
Formal methods in project (exercise)
Class exercise:
--Describe a priority queue in Z notation
--Are there operations you need which have not yet been defined
in these slides on the Z notation?
21