Revision 1

1
Revision 1

• Formal Methods se304/cs407

2
Software sucks

• It comes in
• Late
• Over budget
• Full of errors
• 85 of software development time is spent on
  defect removal

3
Solution

• Since the beginning of computer science (1940s)
• The need for formalism has been recognised
• We can use elements of mathematics to improve
  software quality

4
How

• Maths gives us the language of proofs, and
  reasoning about formulae and statements
• Allows us to create a specification that is
• Clear
• Consistant
• Complete

5
Then

• From our clear, consistent, complete
  specification we can
• By refinement
• Develop better software

6
So why does software still suck?

• Software is rarely developed according to a
  formal model
• Formal methods are not enough

7
Why is FM rarely used?

• Because it
• Requires expertise
• Is expensive in the short term
• Considerably lengthens development time
• Though it does shorten the testing phase
• Computer scientists see it as hard and the ad
  hoc, intuitive method of s/w development as
  easy
• They seem to forget how hard testing is

8
Why is FM not enough?

• Writing a computer program is always
• Translating a human idea into a digital program
• Humans do not think formally
• There will never be a way to prove that you have
  correctly implemented a system
• Correct is too ambiguous in this context

9
So

• FM can greatly reduce the length of the testing
  phase
• But does not remove the need for that phase
• Work needs to be done on making it more
  accessible
• And cheaper

10
Design by Contract

• DBC is not exactly formal methods
• It does introduce some of the concepts
• Pre-condition, post-condition
• Invariant
• A contract is agreed between the supplier and
  the client
• The contract is enforced by language constructs

11
Design by Contract

• Two-sided agreement
• If the client uses system according to the
  contract
• The supplier guarantees that it will behave
  according to the contract
• eg if the client calls a method longest() with
  non-null strings, the supplier will return the
  longest string

12
Design by Contract

• DBC is like FM in that
• Implementation details are unimportant
• If you change your implementation, but it still
  meets the contract, theres no problem
• eg sqrt()
• Linear search
• Binary search
• Newtons method
• Contract abstracts from implementation

13
Advantages

• Avoid constantly checking arguments
• Less buggy, more reliable code
• Automatic generation of documentation
• Necessarily up-to-date
• Better maintainability
• Reduced testing effort
• Automatic test production
• Complexity control
• Thorough, formal thought processes
• Blame assignment

14
Contracts as documentation

• Necessarily up-to-date
• For each method, states
• What is assumed
• What is ensured
• More abstract than code
• Automatic checking

15
JML

• There are several options for doing DBC in Java
• We looked at JML Java Modelling Language
• Uses Java comments with _at_ symbols
• //_at_ requires
• /_at_ ensures _at_/
• Why inside comments?

16
Pre-, post-conditions
17
JML keywords

• requires
• Pre-condition
• ensures
• Normal post-condition
• signals
• Exceptional post-condition
• pure
• Method with no side-effects

18
Informal/formal assertions

• //_at_ requires ( x must be less than y )
• //_at_ requires x lt y

19
Questions

• What is a pre-condition for?
• Who benefits from it?
• What is a post-condition for?
• Who benefits from it?
• When might you use \old(E)?