Self-healing Software Systems

1. Self-healing Software Systems Mauro Pezzè University of Lugano and University of Milano Bicocca

2. Why self healing? Software fails Verification & validation are hard New factors amplify problems dynamic behavior / emerging scenarios unexpected environment interactions multi vendors / multi owners

3. Dynamic autonomous changes the provider independently updates the service implementation statically unpredictable evolution Service provider communicate publish bind Service requestor Service broker find the application dynamically reconfigure the services the broker dynamically discover new service

4. unpredictable environment interactions statically unpredictable interactions

5. Multi vendors / owners Web Application JSF JDBC DB … DB DB JSP Log4J Tomcat JDK Tomcat Server

6. Multi vendors / owners Web Application JSF JDBC DB … DB DB JSP Log4J Tomcat JDK Tomcat Server

7. Self-healing

8. Self-healing natural systems

9. Self-healing software systems? • similarly to natural systems • focus on some classes of problems • maybe incomplete recovery • may imply changes in the body • does not work for all problems • differently from natural systems • recover from expected as well as unexpected problems • built-in as well as emerging mechanisms • potentially hazardous novel interactions

10. Inspirebut not copy from natural systems

11. focus on some classes of problems Integration failures • common in presence of evolving/emerging behaviors • often due to uncovered incompatibilities - misunderstandings • hard/impossible to identify during classic testing • easy to correct once diagnosed

12. Inconsistent interpretation of parameters or values Mars Climate Orbiter FAULTmeters – yard mismatch FIXconverter

13. Violations of domains, capacity, size Buffer overflow FAULTmeters – yard mismatch FIXconverter

14. …Integration Faults Side effects on parameters or resources FAULTconflict on temporary file FIXrename misunderstood functionality FAULTInconsistent interpretation of web hits FIXconvert

15. Explicit control loops

16. IBM

17. Shaw

18. Detect failuresautomatically

19. Detecting failures automatically • Application independent failures • memory faults • deadlocks • race conditions • Exceptions • Application dependent failures • Oracles • Assertions

20. From design specs to code assertions

21. Getting Assertions Right setId public abstract void setId(java.lang.String id) Set the component identifier of this UIComponent (if any). […] Component identifiers must obey the following semantic restrictions (note that this restriction is NOT enforced by the setId() implementation): • The specified identifier must be unique among all the components […] that are descendents of the nearest ancestor UIComponent [...], or within the scope of the entire component tree […]. JSF Specification 1.2, javax.faces.component.UIComponent

22. public class UIComponent { private String id = “default”; public UIComponent(String id) { this.id = id; } public void setId(String id) { this.id = id; } public void doSomething() { this.id =“whatever”; } }

23. requirement Java service pages specification Java server faces implementation annotation generation

24. Observations • 1 Property = 56 Assertions

25. Properties and Frequency

26. Properties and Frequency

27. Properties and Frequency

28. Properties ✔ UML Stereotypes Platform independent 1:n Mapping Rules AJ Pointcuts Property Templates Platform specific AJ Advice Runtime Checks Concept Prototype

29. Diagnosing Faults

30. Debugging • hard manual activity • compare multiple execution (need multiple runs)

31. Locating faults automatically

32. Infer information from running systems

33. Generating models from system runs

34. System behavior

35. System behavior

36. Reality is Different! Over-Generalization and Over-Restriction Over-Generalization Over-Restriction

37. Models derived dynamically … x < 0 Daikon kTail Adabu gkTail

38. kTail A. Biermann and J. Feldman. On the synthesis of finite state machines from samples of their behavior. IEEE Transactions on Computer, 21:592–597, 1972.

39. From Sequence of Events to Protocols a -> a -> a -> b -> c a -> b -> c a -> a -> b -> c a -> a -> a -> a -> a -> c

40. kTail TRACES a -> a -> a -> b -> c a -> b -> c a -> a -> b -> c a -> a -> a -> a -> a -> c PTA (1) (2) FSA

41. Build the PTA TRACES a -> a -> a -> b -> c a -> b -> c a -> a -> b -> c a -> a -> a -> a -> a -> c PTA (1)

42. 2 FUTURES 2-future(2) = {aa,ab,bc} 2-future(5) = {aa, bc} 2-future(11) = {} 2-future(8) = {c} … k=2

43. 2-future(8) = {c} 2-future(12) = {c}

45. 2-future(11) = {} 2-future(13) = {}

47. 2-future(2) = {aa, ab, bc} 2-future(3) = {aa, ab, bc}

49. …