Formal methods

1
CFICSE 2000
Formal methods SP-08 Lt(N) Claude Bernard
2
References

• Software Engineering - a practitioners approach,
  fourth edition, Roger S. Pressman, McGraw-Hill,
  ISBN 0-07-052182-4

3
Formal methods?

• Formal methods are controversial. Their
  advocates claim that they can revolutionize
  software development. Their detractors think
  they are impossibly difficult. Meanwhile, for
  most people, formal methods are so unfamiliar
  that it is difficult to judge the competing
  claims.
• Anthony Hall, 1990

4
So, what are formal methods?

• Formal methods used in developing software
  systems are mathematically based techniques for
  describing system properties. Such formal
  methods provide frameworks within which people
  can specify, develop, and verify systems in a
  systematic, rather than ad hoc, manner.
• A method is formal if it has a sound
  mathematical basis, typically given by a formal
  specification language. This basis provides a
  means of precisely defining notions like
  consistency and completeness, and, more relevant,
  specification, implementation, and correctness.
• The Encyclopedia of Software Engineering

5
Why bother?

• Formal methods seek to avoid problems endemic in
  conventional software engineering approaches.
  These include
• Contradictions. Statements which are at variance
  with one another.
• Ambiguities. Statements which bear more than one
  interpretation.
• Vagueness. A general lack of precision.
• Incompleteness. Missing information.
• Mixed Levels of Abstraction.
• They seek to provide
• rigour
• support for analysis
• support for transformational development

6
Doesnt need mathematics
7
Gets away without mathematics
8
Needs engineering mathematics
9
Formal methods concepts

• Data invariant
• a condition that is true throughout the execution
  of the system that contains a collection of data
• state
• stored data which a system accesses or alters
• operation
• an action that takes place in a system and reads
  or writes data
• an operation is associated with a pre-condition
  and a post-condition

10
Code as a formal system

• a programming language or system typically has
  (more or less well specified)
• definitions
• axioms
• composition rules
• unambiguous semantics
• has virtue of being executable
• any real program is typically too complex to
  analyze in meaningful ways using only the
  programming language specifications

11
Math basics - Set

• a collection of unique objects or elements
• duplication is not allowed
• the order of the element is not important
• the cardinality of a set is the number of
  elements in the set.
• To define a set
• enumeration 3,45, 7, 32
• constructive set specification nNnlt3 . n

12
Math basics - Operator

• membership ?
• not a member ?
• contained ?
• not contained ?
• empty set ?
• union ?
• intersection ?
• difference \
• cross or Cartesian product x

13
Operator's example

• 12 ?3,12,45,7
• 15 ?3,12,45,7
• 1,2 ?4,3,2,1
• 1,5 ?4,3,2,1 is 4,3,2,1,5
• 1,5 ?(4,3,2,1
• 1,5 ?(4,3,2,1 is 1
• 1,5\(4,3,2,1 is 4,3,2,5
• 1,5x4,3,2,1 is (1,4),(1,3),(1,2),(1,1),(5,4),
  (5,3),(5,2),(5,1)

14
Math basics - Sequence

• a mathematical structure which models the fact
  that its elements are ordered
• a set of pairs whose elements range from 1 to
  highest number element
• (1,morning),(2,afternoon),(3,evening),(4,night)
• ltmorning,afternoon,evening, nightgt
• duplication is allowed
• ltmorning, morninggt is not equal to ltmorninggt

15
Math basics

• powerset ?
• implies ?

16
Example - block handler

• part of the filing system of an operating system
  that allocates blocks of memory to files
• during the operation of the system, memory blocks
  are allocated and released as files are created
  and deleted

17
Graphic representation
Used blocks
2 5 7 8 10 11 12
Unused blocks
1 3 4 6 9
Blocks are released to queue when files are
deleted
Queued for entry into unused blocks
7
5 8 11
2
File 3
File 2
File 1
18
Classical or textual representation

• state
• the collection of free blocks
• the collection of used blocks
• the queue of returned blocks

19
Classical or textual representation

• data invariant
• No block will be marked as both unused and used
• All the sets of blocks held in the queue will be
  subsets of the collection of used blocks
• There will be no elements of the queue that will
  contain the same block numbers
• The collection of used blocks and blocks that are
  unused will be the total collection of blocks
  that make up files
• There will be no duplicate block numbers in the
  collection of unused blocks
• There will be no duplicate block numbers in the
  collection of used blocks
• JC add no duplicate block numbers in the total
  collection of blocks

20
Classical or textual representation

• operation
• adds a collection of blocks to the end of the
  queue
• removes a collection of used blocks from the
  front of the queue and places them in the
  collection of unused blocks
• checks whether the queue of blocks is empty

21
Mathematical representation

• state
• data invariant

22
Mathematical representation

• Pre and post conditions

23
Benefits of formal specifications

• precision
• conciseness
• abstraction
• reasoning
• metabenefit understanding derived from the
  specification process

24
Specification languages

• Languages which allow the characteristics of a
  system to be specified within a well-defined
  mathematical framework.
• Model Oriented
• involve the derivation of an explicit model of
  the systems behaviour in terms of abstract
  mathematical objects (sets, states, etc.)
• Property Oriented
• involve the use of axiomatic semantics, pre and
  postconditions of operations applied to abstract
  data types
• Process Algebras
• for communicating processes describe the
  algebras of the communications

25
Specification languages (II)

• Some specification languages (e.g., LOTOS),
  combine features of two or more of these
  approaches (e.g., property-oriented process
  algebra)
• Specification languages are normally densely
  mathematical requirement for informal commentary
• about the same length as the mathematics
• the mathematics is the ultimate authority

26
Specification vs. Modeling

• A pure specification language will deal with the
  external properties of the system only
• more abstract
• easier to reason with
• less bias on the implementation
• A model-based approach will model the internal
  behaviour of the system at a very high level
• more concrete
• easier to construct
• more complex to reason with
• easier to check

27
Z (zed)
28
Z
29
Z
30
Model checkers

• Allow the exhaustive exploration of the possible
  state space of a model, to prove that it does or
  does not possess certain properties
• Frequently used in protocol modeling
• Techniques like binary decision diagrams and
  symbolic model checking allow very large state
  spaces to be explored

31
Theorem provers

• The system and its desired properties are
  expressed as formulas in mathematical logic
• Statements about the properties can be made and
  proven, within the defined formal system
• Range
• highly automated, general purpose programs
• interactive systems with special purpose
  capabilities
• Can deal directly with infinite state spaces
• Often the process of finding the proof is as
  important as the proof itself
• Cant normally provide counterexamples for
  unprovable properties.

32
Transformational development

• The rigorous transformation of a formal
  specification into a software system
• Also known as refinement
• data refinement the transition from mathematical
  data types (sets, sequences, mappings) to more
  concrete data types (arrays, pointers, record
  structures)
• operation refinement the translation of
  operations to operate on the concrete data types
• Proof obligations the requirement to
  demonstrate the correctness of the refinements
• Rarely carried out formally difficult to verify
  an informally developed system against a formal
  specification.

33
The Ten Commandments

• Thou shalt
• choose the appropriate notation
• formalize, but not over formalize
• estimate costs
• have a formal methods guru on call
• not abandon thy traditional development methods
• document sufficiently
• not compromise thy quality standards
• not be dogmatic
• test, test, and test again
• reuse

http//www.cs.reading.ac.uk/people/jpb/
34
The Last Word

• If you want to build systems with ultra-high
  reliability which provide very complex
  functionality and you want to guarantee that they
  are going to work with this very high
  reliability...
• Bev Littlewood, 1993

... you cant do it!