To debug a faulty program, a developer needs to set breakpoints at suspicious code locations, first. When the program is suspended at a breakpoint, the developer can analyse whether the current program state is expected according to some requirements.
Setting breakpoints is not a simple task because a set of unrestrictive breakpoints may result in many unnecessary suspensions. Some techniques [2,4] have been used to decrease the effort of setting breakpoints. However, there are some cases that make the existing debugging techniques clumsy. Consider the following examples:
- Case 1: Finding out where a local variable is set to be null in a method with a long body. First, the developer needs to find out all assignments to this local variable and the set breakpoints to these places. Second, he/she has to observe the value of the local variable when the program is suspended.
- Case 2: Suspending the program at place A only after place B has been reached. First, the developer needs to set two breakpoints at places A and B. Second, he has to disable the breakpoint at A until breakpoint at B is reached .
- Case 3: Locating the faulty code indirectly leading to errors. For example, a stream object cannot be read after it has been closed. If this is violated, the developer needs to find out where the stream was closed. Setting a breakpoint at stream.close()requires work for checking whether the stream object is the one leading to the exception later .
In the above three cases, the developer is likely to have some redundant suspensions before he/she reaches the position he/she expects. This is mainly because breakpoints cannot exchange information with each other.
The goal of this project is designing and implementing a debugging language which allows:
- specifying advanced breakpoints for suspending programs at the faulty execution state, and
- automating some common debugging tasks.
As an example, consider advanced breakpoint for case 3 in pseudo-code below.
In the script, each breakpoint has a unique name and exposes some context values to breakpoints which refer to it. The definitions of bp1 and bp2 are pointcut expressions of AspectJ  which is the most popular aspect-oriented programming language. Besides, tasks performed at this breakpoint can also be specified. The figure below gives a crude sample in the form of an Eclipse view.
To accomplish this project, you will perform the following tasks:
- Designing the grammar for the debugging language;
- Implementing the parser for the debugging language (e.g., using the ANTLR parser generator);
- Connecting debugging scripts to an aspect-oriented backend (provided);
- Implementing the user interface in Eclipse.
 E. Bodden. Stateful breakpoints: a practical approach to deﬁning parameterized runtime monitors. In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering, ESEC/FSE ’11, pages 492–495, New York, NY, USA, 2011. ACM.
 R. Chern and K. De Volder.Debugging with control-ﬂow breakpoints. In Proceedings of the 6th international conference on Aspect-oriented software development, AOSD ’07, pages 96–106, New York, NY, USA, 2007. ACM.
 R. Laddad. AspectJ in Action: Enterprise AOP with Spring Applications. Manning Publications Co., Greenwich, CT, USA, 2009.
 R. A. Olsson, R. H. Crawford, and W. W. Ho.A dataﬂow approach to event-based debugging. Software – Practice and Experience, 21:209–229, 1991.