1. Niv Gafni, Yair Offir and Eliav Ben-zaken Information System Engineering Ben Gurion University 1

2. Debugging Software today is a long, expensive and exhausting process. Past studies attempted to predict the buggy functions or code components, trying to simplify the process enough so it will ease the work for the debugging crew.

3. In this project, we will try to take the algorithm one step further so it will work faster and give a better assessment of the buggy component.

4. What is Model-Based Diagnosis? Given: a model of how the system works  Infer what went wrong Example: What if the engine doesn’t start? 4 if ok(battery) AND ok(ignition) THEN start(engine)

5. Using in software R&D When bugs are found, the QA crew generate a report and sends it to the responsible R&D team. The QA crew input Our system with the tests results. In return, our system will offer additional tests, and outputs the most possible bug locations.

6. This is a research project. The system will serve only Dr. Meir Kaleh and Mr. Roni Stern for Research Perposes.

7. Current Software MBD Techniques 7 Bug Report MBD Engine Set of Possible Diagnoses Set of Possible Diagnoses Prioritize Diagnoses

8. Proposed Contribution 8 Bug Report MBD Engine Set of Possible Diagnoses Set of Possible Diagnoses Suggest Further QA Actions Improved Prioritize Diagnoses Improved Prioritize Diagnoses

9. Proposed Contribution 9 Bug Report MBD Engine Suggest Further QA Actions Improved Prioritize Diagnoses Improved Prioritize Diagnoses A single diagnosis

10. Pacman Example 10

11. Pacman Example 11

12. Pacman Example 12

13. Pacman Example 13

14. Pacman Example 14

15. Pacman Example 15

16. Pacman Example 16

17. Execution Trace 17 F1 Move F1 Move F2 Stop F2 Stop F3 Eat Pill F3 Eat Pill

18. How to check? 18

19. Knowledge Most probable cause: Eat Pill 19

20. Knowledge Most probable cause: Eat Pill Most easy to check: Stop 20

21. Functional requirements Generate a random graph. Generate a program code with random bugs. Run the code several times with different augments to produce observations. Compute the diagnostics with statistical probability 21

22. Non-Functional requirements Performance constraints: Speed: calculating diagnosis and suggesting additional use-cases should not take more then 1 minute. SE Project Constraints: a demo version of our system, & data of the different algorithms we used. The system should be highly modular. The system is interactive. 22

23. Usage Scenarios MAIN ACTORS R&D. QA crew Reacercher 23

24. 24 44 Compute bug locations according to observations R&D Team QA Crew QA Crew observations Most likely bug locations Ask for more observations Add more observations Additional observations More accurate bug locations Ask for more observations Generate Random Graph And Code Run Compiled Program Researcher Compiled code observations arguments

25. Risk assessment The system should be able to know what action the QA Crew should perform on the tested software in order to pass through certain code component. that is not always possible because the system don't hold the structure of the code. In the research it can be solved by adding the call graph of the code to the system. As in every resource project that deals with a new algorithm and implementation, there is a risk that the research will not lead to a better solution then the existing solution. 25

26. Questions? 26