Formal methods

1
SWENG 580 advanced software engineering
Formal methods
Why are formal methods needed? What is a formal
method?
2
A story (1)

• We have just finished writing a large program.
• Among other things, the program computes, as
  intermediate results, the quotient q and
  remainder r arising from dividing a non-negative
  integer x by a positive integer y.
• r x q 0
• while r gt y do
• begin r r-y q q1 end
• Were now ready to debug the program

3
A story (2)

• With respect to the remainder-quotient
  calculation, we realize that the divisor should
  initially be greater than 0 and that upon its
  termination the variables should satisfy the
  formula x yq r.
• So, we add some output statements to check the
  calculations
• write(dividend x, x, divisor y y)
• r x q 0
• while r gt y do
• begin r r-y q q1 end
• write(yq r , yqr)
• Unfortunately we get voluminous results because
  the segment is within a loop!

4
A story (3)

• We need to be more selective in what we print, so
  we use assertions.
• If an assertion is found to be false at any time
  a message and dump of program variables is
  printed
• y gt 0
• r x q 0
• while r gt y do
• begin r r-y q q1 end
• x yq r
• Assertion checking detects an error during a test
  run because y 0 just before a calculation and
  it takes only 4 hours to find the error in the
  calculation of y and fix it.

5
A story (4)

• But then we spend a day tracking down an error
  for which we received no false-assertion message.
  We finally determine that the remainder-quotient
  calculation resulted in x6, y 3, q 1, r 3
• Sure enough, both assertions are true with these
  values the problem is that the remainder
  should be less than the divisor!
• We determine that the loop condition should be r
  y instead of rgty.
• If only the result assertion were strong enough
  (x yq r and r lt y)
• y gt 0
• r x q 0
• while r y do
• begin r r-y q q1 end
• x yq r and r lt y

6
A story (5)

• Things go fine until one day we get
  incomprehensible output.
• It turns out that the remainder-quotient
  calculation resulted in a negative remainder r
  -2.
• We find that r was negative because x was 2.
• Another error in calculating the input to the
  calculation, but we should have caught it
  earlierall we had to do was make the initial and
  final assertions for that segment strong enough
• 0 x and 0 lt y
• r x q 0
• while r y do
• begin r r-y q q1 end
• x yq r and 0 r lt y

7
A story (6)

• Wouldnt it be nice to be able to invent the
  right assertions to use in a less ad hoc fashion.
  
• Why cant we think of them?
• Does it have to be a trial-and-error process?
• Part of the problem is carelessness
• we should have written the initial (0 x and 0 lt
  y) and final (x yq r and 0 r lt y)
  assertions before writing the program segment
  for they form the definition of quotient and
  remainder.

8
A story (7)

• But what about the error in the loop
  conditioncould we have prevented that from the
  beginning?
• Just before the loop it seems that part of our
  result, x yq r holds, since xr and q0 and
  it holds after each iteration . So lets insert it
  as an assertion.
• 0 x and 0 lt y
• r x q 0
• 0 x and 0 lt y and x yq r
• while r y do
• begin 0 x and 0 lt y and x yq r
• r r-y q q1
• 0 x and 0 lt y and x yq r
• end
• x yq r and 0 r lt y
• Now, given the condition, how can we prove it is
  correct?
• When the loop terminates the condition is
  falsewe want r lt y, so that the complement, r
  y must be the correct loop condition!!

9
A story (8)

• In this example its not too difficult, all we
  need to do is be able to write Boolean
  expressions.
• But, in less simple cases we must also reason
  with them
• to simplify them,
• to prove that one follows from another,
• to prove that one is not true in some state,
• Also, knowing how to reason about assertions is
  one thing knowing how to reason about programs
  is another.
• This is the study of program correctness which
  has led to the discovery of methods for
  developing programs.
• This is what formal methods allow us to do.

10
What is a formal method?

• 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.
  Encyclopedia of Software Engineering 1994

11
Formal method types

• Can be classified into five broad types
• Model-based
• Explicit definition of state and operations which
  transform the state. (Z, VDM)
• Algebraic
• Implicit definition of operations without
  defining state. (PLUSS, OBJ)
• Process algebras
• Explicit model of concurrent processes
  represent behavior with constraints on allowable
  communication between processes. (CSP, CCS)
• Logic-based
• Use logic to describe properties of systems.
  (Temporal and interval logics)
• Net-based
• Implicit concurrent model in terms of data flow
  through a network, including conditions under
  which data can flow from one node to another.
  (Petri-nets)

12
Formal method concepts

• Data invariant
• condition that holds throughout the execution of
  the system that contains the data
• State
• the stored data which a system accesses and
  alters
• Operation
• an action that reads or writes data to a state
• Precondition defines a condition that must hold
  for the operation to be valid
• Postcondition defines a condition that holds
  after the (valid) operation was executed

13
Example block handler (1)
Unused blocks
14
Example block handler (2)

• State
• collection of free blocks
• collection of used blocks
• queue of returned blocks
• Data invariant
• No block is marked as both used and unused
• All sets of blocks held in the queue will be
  subsets of the collection of currently used
  blocks
• There will be no elements of the queue that will
  contain the same block number
• The collections of used blocks and unused blocks
  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

15
Example block handler (3)

• Some operations
• An operation that removes a collection of used
  blocks from the front of the queue and places
  them in the collection of unused blocks
• Precondition Queue must have at least one item
  in it
• Postcondition Blocks must be added to the
  collection of unused blocks
• An operation that adds a collection of blocks to
  the end of the queue
• Precondition Blocks to be added must be in the
  collection of used blocks
• Postcondition Collection of blocks is at the end
  of the queue

16
Mathematical preliminaries

• Working knowledge needed in
• sets and sequences
• logical notation used in predicate calculus

17
Quick revision of set theory

• the empty set or Æ
• Definition by extension e.g. A 1, 2, 3, B
  5, 12, 13, 3, 2
• membership Î e.g. 2 Î A, 2 Î B, 5 Î B
• non-membership Ï but 5 Ï A
• Definition by comprehension x Î X P(x) where
  P is some property (constructive set
  specification) that each member of the set X may
  or may not possess.
• e.g. S b Î B even(b) 2, 12
• Cardinality the number of elements in a set
• e.g. Æ 0, A 3, B 5
• subset Í X Í Y if and only if
• every member of X is a member of Y, or
  formally
• ?x((x Î X) Þ (x Î Y))
• proper subset Ì X Ì Y Û (X Í Y) Ù (X ¹ Y)

18
Constructive specifications

• n N n lt 3 n 0, 1, 2
• x,y N xy10 (x,y2) (1, 81), (2, 64),
  (3, 49),

19
Set operators

• ?x
• union È x Î (X È Y) Û (x Î X) Ú (x Î Y)
• e.g. A È B 1,2,3,5,12,13
• Intersection Ç x Î (X Ç Y) Û (x Î X) Ù (x Î Y)
• e.g. A Ç B 2,3
• Difference \ x Î (X \Y) Û (x Î X) Ù (x Ï Y)
• or - e.g. A\B 1 and B\A 5, 12, 13
• Complement " the difference between a set and
  the set
• of which it is a subset
• e.g. "S B\S 5, 13, 3
• Powerset à ÃX s s Í X
• or set e.g. set X
• ?,1,2,3,1,2,1,3,2,3,1,2,3

20
Sequences

• Consider the set (1,Jones), (2,Wilson),
  (3,Shapiro), (4,Jones)
• The first elements of the pairs are known as the
  domain of the sequence and the collection of
  second elements is the range of the sequence.
• Can write the sequence as ltJones, Wilson,
  Shapiro, Jonesgt
• In sequences the order is important, so ltJones,
  Wilsongt ? ltWilson, Jonesgt
• And duplication is allowed.
• As in sets, there are operators
• Catenation, lt1,2,3gt lt4,5,6gt lt1,2,3,4,5,6gt
• head headlt1,2,3,4,5,6gt 1
• tail taillt1,2,3,4,5,6gt lt2,3,4,5,6gt
• last lastlt1,2,3,4,5,6gt 6
• front frontlt1,2,3,4,5,6gt lt1,2,3,4,5gt
• The empty sequence ltgt

21
Logic operators

• Ø not
• Ù and
• Ú or
• Û equivalent
• Þ implies
• " for all (universal quantification)
• there exists (existential quantification)
• E.g. "i,j N igtj Þ i2gtj2
• States that for every pair of values in the set
  of natural numbers, if i is greater than j, i2 is
  greater than j2.

22
Example block handler (1)

• State
• collection of free blocks
• collection of used blocks
• queue of returned blocks
• Formally writtenBLOCKS set consisting of
  every block numberAllBlocks set of blocks that
  lie between 1 and MaxBlocksused, free P
  BLOCKSBlockQueue seq P BLOCKS
• .

23
Example block handler (2)

• Data invariant
• No block is marked as both used and unusedused Ç
  free ?
• All sets of blocks held in the queue will be
  subsets of the collection of currently used
  blocks"i dom BlockQueue BlockQueue i Í used
• There will be no elements of the queue that will
  contain the same block number"i,j dom
  BlockQueue i ¹ j Þ
• BlockQueue i Ç BlockQueue j ?
• The collections of used blocks and unused blocks
  will be the total collection of blocks that make
  up filesused È free AllBlocks
• There will be no duplicate block numbers in the
  collection of unused blocksfree is a set!
• There will be no duplicate block numbers in the
  collection of used blocksused is a set!

24
Example block handler (3)

• Operation 1
• An operation that removes a collection of used
  blocks from the front of the queue and places
  them in the collection of unused blocks
• Precondition Queue must have at least one item
  in itBlockQueue gt 0
• Postcondition Blocks must be added to the
  collection of unused blocksused used \ head
  BlockQueue Ùfree free È head BlockQueue Ù
  BlockQueue tail BlockQueue
• Operation 2
• An operation that adds a collection of blocks to
  the end of the queue
• Precondition Blocks to be added must be in the
  collection of used blocksAblocks Í used
• Postcondition Collection of blocks is at the end
  of the queueBlockQueue BlockQueue ltAblocksgt
  Ùfree free Ù used used

25
Formal specification with Z (1)

• BlockHandler
• used, free P 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 Æ

26
Formal specification with Z (2)

• RemoveBlock
• DBlockHandler
• BlockQueue gt 0,
• used used \ head BlockQueue Ùfree free È
  head BlockQueue Ù BlockQueue tail BlockQueue

27
Formal specification with Z (3)

• AddBlock
• DBlockHandler
• Ablocks? BLOCKS
• Ablocks? ? used,
• BlockQueue BlockQueue ltAblocksgt Ùfree
  free Ù used used

28
The ten commandments of formal methods

• 1. Thou shalt choose the appropriate notation
• 2. Thou shalt formalize, but not overformalize
• 3. Thou shalt estimate costs
• 4. Thou shalt have a formal method guru on call
• 5. Thou shalt not abandon thy traditional
  development methods
• 6. Thou shalt document sufficiently
• 7. Thou shalt not compromise thy quality
  standards
• 8. Thou shalt not be dogmatic
• 9. Thou shalt test, test, and test again
• 10.Thou shalt reuse.
• J.P. Bowen M.G. Hinchey, Ten Commandments of
  Formal Methods.
• IEEE Computer, 28(4)56-63, April 1995.

29
Key points

• Conventional software engineering specifications
  are fraught with ambiguities, vagueness,
  contradictions and incompleteness
• Formal methods help us overcome these
  deficiencies
• They have a sound mathematical basis, typically
  given by a formal specification language
• This basis provides a means of precisely defining
  notions like consistency and completeness
• More importantly it provides a means for precise
  specification, implementation, and correctness

30
References

• D. Gries, The Science of Programming,
  Springer-Verlag, 1981.
• R Pressman, Software Engineering A
  Practitioners Approach, 5th Ed, McGraw-Hill,
  2000.