1 / 26

Model-Based Diagnosis for d ebugging

Model-Based Diagnosis for d ebugging. Niv Gafni , Yair O ffir and Eliav Ben- zaken Information System Engineering Ben Gurion University. Vision.

huela
Download Presentation

Model-Based Diagnosis for d ebugging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Model-Based Diagnosis for debugging NivGafni, YairOffir and Eliav Ben-zaken Information System Engineering Ben Gurion University

  2. Vision 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. Vision cont. 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? if ok(battery) AND ok(ignition) THEN start(engine)

  5. The Problem Domain 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. Stakeholders 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 Bug Report Prioritize Diagnoses Set of Possible Diagnoses MBD Engine

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

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

  10. Pacman Example

  11. Pacman Example

  12. Pacman Example

  13. Pacman Example

  14. Pacman Example

  15. Pacman Example

  16. Pacman Example

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

  18. How to check?

  19. Knowledge • Most probable cause: Eat Pill

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

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

  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.

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

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

  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.

  26. Questions?

More Related