Successfully reported this slideshow.
Upcoming SlideShare
×

# The Power of Probabilistic Thinking (keynote talk at ASE 2016)

9,086 views

Published on

keynote talk presented at the 31st IEEE/ACM International Conference on Automated Software Engineering (ASE 2016), Singapore, 7 September 2016

Published in: Technology
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

### The Power of Probabilistic Thinking (keynote talk at ASE 2016)

1. 1. National University of Singapore
2. 2. – Norman Vincent Peale,  The Power of Posi,ve Thinking “Do not build up obstacles  in your imagina:on.”
3. 3. Pop Quiz What Do These Things Have in Common? www.nbcnews.com An Earthquake
4. 4. Pop Quiz What Do These Things Have in Common? www.healthina:on.com A Heart Attack
5. 5. Pop Quiz What Do These Things Have in Common? www.freerepublic.com President Trump
6. 6. Pop Quiz What Do These Things Have in Common? ✓ They are governed by stochas:c phenomena ✓ We have a reasonable understanding of their causes ✓ We base our understanding on past observa:ons - At various levels of abstrac:on (Simple) Answer:   They are events to which experts assign a probability based on models Software is like this too!
7. 7. Certainty in  SoKware Engineering “My program is correct.” “The speciﬁca,on is sa,sﬁed.” A simplistic viewpoint, which permeates most of our  models, techniques and tools
8. 8. Example Model Checking ! ¬p → ◊q( )∧"( ) Model Checker ✓ ✕ State Machine Model Temporal  Property Results Counterexample Trace System Requirements
9. 9. Example Model Checking ! ¬p → ◊q( )∧"( ) Model Checker ✕ State Machine Model Temporal  Property Results Counterexample Trace System Requirements
10. 10. Why Apply a  Probabilis:c Viewpoint?
11. 11. Why Apply a  Probabilis:c Viewpoint?
12. 12. Why Apply a  Probabilis:c Viewpoint? ✓ Perfect and complete requirements are improbable ✓ Execu:on and tes:ng are akin to sampling … and we use tes:ng to increase conﬁdence! ✓ The behavior of the execu:on environment is random and unpredictable ✓ Frequency of execu:on failures is (hopefully) low There are many random phenomena  and “shades of grey”  in software engineering But our models, techniques and tools rarely capture this
13. 13. NATO Conference on SE  Rome, 1969 h[p://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1969/DIJKSTRA.html – Edsger W. Dijkstra (on more than one occasion!) “Tes:ng shows the presence, not the absence of bugs.”
14. 14. Probabili:es at Garmisch, 1968 John Nash, IBM Hursley h[p://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968/GROUP1.html Naur & Randell, SoDware Engineering: Report on a Conference sponsored by the NATO Science CommiLee, Garmisch, Germany, 7th to 11th October 1968, January 1969.
15. 15. Some Previous Eﬀorts with Probabilis:c Approaches • Performance Engineering (many) • Cleanroom SoKware Engineering (Mills) • Opera:onal Proﬁles  and SoKware Reliability Engineering (Musa, …) • Quan:ta:ve Goal Reasoning in KAOS (Lamsweerde, Le:er) • Sta:s:cal Debugging (Harrold, Orso, Liblit, …) • Probabilis:c Programming & Analysis (Poole, Pfeﬀer, Dwyer, Visser, …) • Probabilis:c and Sta:s:cal Model Checking (many)
16. 16. Probabilis:c Model Checking ! ¬p → ◊q( )∧"( ) Model Checker ✓ ✕ State Machine Model Temporal  Property Results Counterexample Trace System Requirements P≥0.95 [ ] 0.4 0.6 Probabilis:c Probabilis:c
17. 17. Probabilis:c Model Checking ! ¬p → ◊q( )∧"( ) Model Checker ✓ ✕ State Machine Model Temporal  Property Results Counterexample Trace System Requirements P=? [ ] 0.4 0.6 Quan:ta:ve Results 0.9732Probabilis:c Probabilis:c
18. 18. Example The Zeroconf Protocol s1s0 s2 s3 q 1 1 {ok} {error} {start} s4 s5 s6 s7 s8 1 1-q 1-p 1-p 1-p 1-p p p p p 1 Pr(unsuccessful message probe)Pr(new address in use) from the PRISM group  (Kwiatkowska et al.) P≤0.05 [ true U error ] 0.1 0.9 0.5 0.5 0.10.10.1 0.9 0.9 0.9
19. 19. Some Previous Eﬀorts with Probabilis:c Approaches • Cleanroom SoKware Engineering • Opera:onal Proﬁles & SoKware Reliability Engineering • Quan:ta:ve Goal/Requirements Reasoning in KAOS • Performance Engineering • Sta:s:cal Debugging • Probabilis:c Programming and Analysis • Probabilis:c Model Checking We lack an holistic approach for the whole software development lifecycle
20. 20. Challenges in Taking a Probabilis:c Viewpoint 1. Some Things Are Certain, Or Should Be 2. Educa:on and Training 3. Popula:on Sizes and Sample Sizes 4. Determining the Probabili:es 5. Pinpoin:ng the Root Cause of Uncertainty
21. 21. Challenges Some Things Are Certain, Or Should Be
22. 22. Challenges Some Things Are Certain, Or Should Be
23. 23. Challenges Some Things Are Certain, Or Should Be Need to mix probabilistic and non-probabilistic approaches
24. 24. Challenges Educa:on and Training
25. 25. Challenges Educa:on and Training
26. 26. Challenges Educa:on and Training
27. 27. Challenges Educa:on and Training
28. 28. Challenges Popula:on Sizes and Sample Sizes
29. 29. Challenges Determining the Probabili:es ! ¬p → ◊q( )∧"( ) Model Checker ✓ State Machine Model Temporal  Property Results System Requirements P≥0.95 [ ] 0.4 0.6 Quan:ta:ve Results 0.9732Probabilis:c Probabilis:c
30. 30. Challenges Determining the Probabili:es ! ¬p → ◊q( )∧"( ) Model Checker ✕ State Machine Model Temporal  Property Results Counterexample Trace System Requirements P≥0.95 [ ] Quan:ta:ve Results Probabilis:c Probabilis:c 0.41 0.59 0.6211
31. 31. Example The Zeroconf Protocol Revisited s1s0 s2 s3 q 1 1 {ok} {error} {start} s4 s5 s6 s7 s8 1 1-q 1-p 1-p 1-p 1-p p p p p 1 from the PRISM group  (Kwiatkowska et al.) The packet-loss rate is determined by an empirically es,mated probability distribu,on Pr(packet loss) 0.1 0.9 0.5 0.5 0.10.10.1 0.9 0.9 0.9
32. 32. Perturbed Probabilis:c Systems (Current Research) • Discrete-Time Markov Chains (DTMCs) • “Small” perturba:ons of probability parameters • Reachability proper:es P≤p[ ] • DRA proper:es • Linear, quadra:c bounds on veriﬁca:on impact see papers at ICFEM 2013, ICSE 2014, CONCUR 2014,  ATVA 2014, FASE 2016, ICSE 2016, IEEE TSE 2016 • Markov Decision Processes (MDPs) • Con:nuous-Time Markov Chains (CTMCs) S? U S!
33. 33. Asympto:c  Perturba:on Bounds • Perturba:on Func:on where A is the transi:on probability sub-matrix for S? and b is the vector of one-step probabili:es from S? to S! • Condi:on Number • Predicted varia:on to probabilis:c veriﬁca:on  result p due to perturba:on Δ: ρ x( )= ι? i A x i i b x( )− Ai i b( )( )i=0 ∞ ∑ κ = lim δ→0 sup ρ(x − r) δ : x − r ≤ δ,δ > 0 ⎧ ⎨ ⎩ ⎫ ⎬ ⎭ ˆp = p ±κΔ
34. 34. Case Study Results Noisy Zeroconf (35000 Hosts, PRISM) p Actual Collision Probability Predicted Collision Probability 0.095 -19.8% -21.5% 0.096 -16.9% -17.2% 0.097 -12.3% -12.9% 0.098 -8.33% -8.61% 0.099 -4.23% -4.30% 0.100 1.8567 ✕ 10-4 — 0.101 +4.38% +4.30% 0.102 +8.91% +8.61% 0.103 +13.6% +12.9% 0.104 +18.4% +17.2% 0.105 +23.4% +21.5%
35. 35. Challenges Pinpoin:ng the Root Cause of Uncertainty “There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say, we know there are some things we do not know. But there are also unknown unknowns – the ones we don’t know we don’t know.” — Donald Rumsfeld
36. 36. The Changing Nature of  SoKware Engineering ✓ Autonomous Vehicles ✓ Cyber Physical Systems ✓ Internet of Things see Deep Learning and Understandability versus  SoDware Engineering and Veriﬁca,on by Peter Norvig, Director of Research at Google h[p://www.youtube.com/watch?v=X769cyzBNVw
37. 37. Example Aﬀec:ve Compu:ng
38. 38. Example Aﬀec:ve Compu:ng When is an incorrect emo,on classiﬁca,on a bug, and when is it a “feature”? And how do you know?
39. 39. Uncertainty in Tes:ng (Current Research) Test  Execu:on System Under Test Result Interpreta,on Acceptable✓
40. 40. Uncertainty in Tes:ng (Current Research) Test  Execu:on System Under Test Result Interpreta,on Unacceptable Acceptable✓ ✕
41. 41. Uncertainty in Tes:ng (Current Research) Test  Execu:on System Under Test Result Interpreta,on Unacceptable Acceptable Acceptable ✓ ✕ ✕
42. 42. Uncertainty in Tes:ng (Current Research) Test  Execu:on System Under Test Result Interpreta,on Unacceptable Acceptable Acceptable ✓ ✕ ✕ Acceptable misbehaviors can mask real faults!
43. 43. One Possible Solu:on Distribu:on Fi{ng System Under Test Training  Data WEKA Sebastian Elbaum and David S. Rosenblum, “Known Unknowns: Testing in the Presence of Uncertainty”, Proc. FSE 2014.
44. 44. One Possible Solu:on Distribu:on Fi{ng System Under Test WEKA Sebastian Elbaum and David S. Rosenblum, “Known Unknowns: Testing in the Presence of Uncertainty”, Proc. FSE 2014.
45. 45. One Possible Solu:on Distribu:on Fi{ng System Under Test Result Interpreta,on Acceptablep < 0.99 Test  Execu:on WEKA Sebastian Elbaum and David S. Rosenblum, “Known Unknowns: Testing in the Presence of Uncertainty”, Proc. FSE 2014.
46. 46. One Possible Solu:on Distribu:on Fi{ng System Under Test Result Interpreta,on Unacceptable Acceptablep < 0.99 Test  Execu:on WEKA p < 0.0027 Sebastian Elbaum and David S. Rosenblum, “Known Unknowns: Testing in the Presence of Uncertainty”, Proc. FSE 2014.
47. 47. One Possible Solu:on Distribu:on Fi{ng System Under Test Result Interpreta,on Unacceptable Acceptable Inconclusive p < 0.99 Test  Execu:on WEKA p < 0.37 p < 0.0027 Sebastian Elbaum and David S. Rosenblum, “Known Unknowns: Testing in the Presence of Uncertainty”, Proc. FSE 2014.
48. 48. Conclusion There is poten:ally much to be gained by relaxing the tradi:onal absolu:st view of soKware engineering And there are great research opportuni:es in  applying a probabilis:c viewpoint
49. 49. – Norman Vincent Peale,  The Power of Posi,ve Thinking “Do not build up obstacles  in your imagina:on.”
50. 50. National University of Singapore