cs205: engineering software university of virginia fall 2006

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

2. What was the real problem?

4. What are the lessons?

5. Recommendations

8. Bertrand Meyer’s Analysis “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.” http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html

9. 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. 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. 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. 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. Floyd-Hoare Rules pre-condition post-condition 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.

14. 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- condition could be satisfied.

15. 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. 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. 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. If Axiom side-effect-free (b) • (P b { s1 } Q) • (P b { s2 } Q) P { if b then s1 else s2 } Q

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

20. 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. Handling Loops % Pre-condition: ? while (n <= x) { n := n + 1; result := result * n; } % Post-condition: result = x!

22. 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