1. 1 cs205: engineering software university of virginia fall 2006 Avoiding Software Disasters

2. 2 cs205: engineering software What was the real problem?

3. 3 cs205: engineering software

4. 4 What are the lessons?

5. 5 cs205: engineering software Recommendations

6. 6 cs205: engineering software

7. 7

8. 8 Bertrand Meyer’s Analysis http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html “Reuse without a contract is sheer folly! Without a precise specification attached to each reusable component -- precondition, postcondition, invariant -- no one can trust a supposedly reusable component.”

9. 9 cs205: engineering software Ken Garlington’s Critique Design contracts unlikely to solve this problem: –Specification would need to correctly identify precondition –Code review would need to correctly notice unsatisfied precondition –Or, run-time handler would need to recover correctly http://home.flash.net/~kennieg/ariane.html

10. 10 cs205: engineering software Software Disasters Subscribe to RISKS to get a regular reminder of software disasters: http://catless.ncl.ac.uk/Risks Last week’s issue: –European power outage (82m people) –Canadian phone outage –Radiation therapy computer (included a version change problem like Ariane 5) –Train brakes –Aegis cruiser crippled in Gulf –Election problems

11. 11 cs205: engineering software Program Verification “There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.” Sir Tony Hoare, 1980 Turing award lecture

12. 12 cs205: engineering software Axiomatic Semantics Reason about programs using axioms (mathematical rules about program text fragments) Depends on informal (almost formal) understanding of logic Allows reasoning about all possible executions Can prove interesting properties about some programs –Not possible to prove any interesting properties about an arbitrary program (Halting problem)

13. 13 cs205: engineering software Floyd-Hoare Rules P { code fragment } Q Partial correctness: For all execution states which satisfy P, if the code fragment terminates, the resulting execution state satisfies Q. Total correctness: For all execution states which satisfy P, the code fragment terminates and the resulting execution state satisfies Q. pre-condition post-condition

14. 14 cs205: engineering software A simple example true { while (true) x = 1; } 2 + 2 = 5 Partial correctness: Yes! Since code doesn’t terminate, any post-condition is satisfied. Total correctness: No!Since code doesn’t terminate, no total correctness post- conditioncould be satisfied.

15. 15 cs205: engineering software Assignment Axiom P[e/x] { x = e  side-effect-free(e) } P P is true after x := e, iff P with e substituted for x was true before the assignment.

16. 16 cs205: engineering software Assignment Example wp { x = x + 1 } x = 3 P[e/x] { x := e  sef(e) } P wp = (x = 3)[x + 1/x] wp = ((x + 1)= 3) wp = (x = 2)

17. 17 cs205: engineering software Weakest Preconditions P { S } Q Given Q and S, what is the weakest P such that P { S }  Q x = 2 { x = x + 1 } x = 3 Is there a stronger precondition? Is there a weaker precondition? Is there always a weakest precondition for any S and Q?

18. 18 cs205: engineering software If Axiom side-effect-free (b)  (P  b { s1 } Q)  (P   b { s2 } Q) P { if b then s1 else s2 } Q

19. 19 cs205: engineering software If Example P { if (x < 3) { x := x + 1 } else { x := x – 1 } } x  3

20. 20 cs205: engineering software If Example side-effect-free (x < 3)  (P  x < 3 { x := x + 1 } x  3 )  (P   (x < 3) { x := x – 1 } x  3 ) P { if (x < 3) then x := x + 1 else x := x – 1 } x  3 weakest-precondition: P = x  3  x  2

21. 21 cs205: engineering software Handling Loops % Pre-condition: ? while (n <= x) { n := n + 1; result := result * n; } % Post-condition: result = x!

22. 22 cs205: engineering software Charge Avoid a software disaster for your projects –Coordinate with your team closely: all your code should be working together now –Make sure simple things work before implementing “fancy features” Subscribe to RISKS to get a regular reminder of software disasters: http://catless.ncl.ac.uk/Risks