1. Introduction to Formal Methods
Preconditions, Postconditions, and Invariants Revisited;
Z language Example (Pressman)

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

3. --use set theory, logic to specify systems
Formal techniques
Formal techniques:
--use set theory, logic to specify systems
--increase probability of complete, consistent, unambiguous specifications
--have high start-up costs; may require high overhead; some concepts (e.g., timing, reliability) difficult or impossible to capture in formal systems
--do not replace more traditional approaches

4. Ten commandments of formal methods
"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, ….
10. Reuse

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

6. A complete formal system
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)
operations-- with precondition(s) / postcondition(s)

7. Z example (1)
Example (from Pressman, Software Engineering, A Practitioner’s Approach): “Block Handler”
Used blocks
Unused
(free)
blocks
11 12
Blocks released to queue when files deleted 2
5 8 11 7
Queued for entry into Unused

8. -------BlockHandler---------------------- used,free:  BLOCKS
Some Z notation
Z specification:
BlockHandler
used,free:  BLOCKS
BlockQueue: seq P BLOCKS
used  free =  
used  free = AllBlocks 
 i: dom BlockQueue . BlockQueue i  used 
 i,j : dom BlockQueue . i  j 
BlockQueue i  BlockQueue j = 
set
intersection
union
sequence
contained in
“then”
and
implies in
empty set
for all
intersection

9. -------BlockHandler---------------------- used,free:  BLOCKS
Z example (2)
Z specification:
BlockHandler
used,free:  BLOCKS
BlockQueue: seq P BLOCKS
used  free =  
used  free = AllBlocks 
 i: dom BlockQueue . BlockQueue i  used 
 i,j : dom BlockQueue . i  j 
BlockQueue i  BlockQueue j = 

10. ---------RemoveBlock--------------------------  BlockHandler
#BlockQueue > 0,
used’ = used \ head BlockQueue 
free’ = free  head BlockQueue 
BlockQueue’ = tail BlockQueue
AddBlock
Ablocks? : BLOCKS
Ablocks?  used,
used’ = used 
free’ = free 
BlockQueue’ = BlockQueue ^ (Ablocks?)
Z example (3)

11. 1. What if BlockQueue is replaced by BlockStack?
Modifications
1. What if BlockQueue is replaced by BlockStack?
2. What are postconditions for the operations?