1

Introduction to Formal Methods

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

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 the model that has been developed

4

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”

5

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

6

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 Engineering1V. George ,and R. Vaughn,

Crosstalk, The Journal of Defense Engineeringhttp://www.stsc.hill.af.mil/crosstalk/2003/01/george.html

accessed august 12, 2010

7

"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

8

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

9

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’

10

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)

11

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)

1 3 4 6 9 2 5 7 8 10 11 12

2 5 8 11 7

Unused(free) blocks

Queued for entry into Unused

Blocks released to queue when files deleted

Used blocks

12

Z example (2)

Z specification:

-------BlockHandler----------------------used,free: BLOCKSBlockQueue: seq P BLOCKS

-----------------------------------------------used free = used free = AllBlocks

i: dom BlockQueue . BlockQueue i used i,j : dom BlockQueue . i j

BlockQueue i BlockQueue j =

1 3 4 6 9 2 5 7 8 10 11 12

2 5 8 11 7

13

Some Z notation

Z specification:

-------BlockHandler----------------------used,free: BLOCKSBlockQueue: 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

contained in

and

implies

“then”

in

intersectionfor all

empty set

intersection

unionsequence

1 3 4 6 9 2 5 7 8 10 11 12

2 5 8 11 7

14

Z example (3) ---------RemoveBlock-------------------------- BlockHandler

-----------------------------------------------------#BlockQueue > 0,used’ = used \ head BlockQueue free’ = free head BlockQueue BlockQueue’ = tail BlockQueue

------------------------------------------------------

---------AddBlock------------------------------- BlockHandlerAblocks? : BLOCKS

-----------------------------------------------------Ablocks? used,used’ = used free’ = free BlockQueue’ = BlockQueue ^ (Ablocks?)

------------------------------------------------------

1 3 4 6 9 2 5 7 8 10 11 12

2 5 8 11 7

15

Modifications

1. What if BlockQueue is replaced by BlockStack?

2. What are postconditions for the operations?

1 3 4 6 9 2 5 7 8 10 11 12

2 5 8 11 7

16

Additional Z Notation

17

Z Sequence Notation

18

Z example revisited (1)

Example (from Pressman, Software Engineering, A Practitioner’s Approach): “Block Handler”

1 3 4 6 9 2 5 7 8 10 11 12

2 5 8 11 7

Unused(free) blocks

Queued for entry into Unused

Blocks released to queue when files deleted

Used blocks

19

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”

20

Modifying the example

21

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?