Model-Based Diagnosis for debugging

Niv Gafni, Yair Offir and Eliav Ben-zakenInformation System Engineering

Ben Gurion University

1

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.

Vision

  

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.

Vision cont.

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)

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

The Problem Domain

• This is a research project.• The system will serve only Dr. Meir Kaleh and

Mr. Roni Stern for Research Perposes.

Stakeholders

7

Current Software MBD Techniques

Bug Report

MBD Engine

Set ofPossible

Diagnoses

Prioritize Diagnoses

8

Proposed Contribution

Bug Report

MBD Engine

Set ofPossible

Diagnoses

Suggest Further QA Actions

ImprovedPrioritize Diagnoses

9

Proposed ContributionBug Report

MBD Engine

Suggest Further QA Actions

ImprovedPrioritize Diagnoses

A single diagnosis

10

Pacman Example

11

Pacman Example

12

Pacman Example

13

Pacman Example

14

Pacman Example

15

Pacman Example

16

Pacman Example

17

Execution Trace

F1Move

F2Stop

F3Eat Pill

? ? ?

18

How to check?

19

KnowledgeMost probable cause: Eat Pill

20

KnowledgeMost probable cause: Eat PillMost easy to check: Stop

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

22

Non-Functional requirementsPerformance 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 ScenariosMAIN ACTORSR&D.QA crewReacercher

24

44

Compute bug locations

according to observations R&D

Team

QACrew

QACrew

observationsMost likely bug locations

Ask for more observations

Add more observationsAdditional

observations

More accurate bug locations

Ask for more observations

Generate Random Graph

And Code

Run Compiled Program

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

26

Questions?