Next I want to you point to some problems that we had to overcome in order to build a useful program slicing tool. To the best of our knowledge our suggestions represent significant contributions to the state of the art of program slicing.
One problem is that we do not only want to perform program slicing on toy programs but on existing programs for debugging and maintenance. This rises the need for intermodular slices in order to slice large programs that are built of modules. Of course, one can also slice monolithic programs, but all of us will agree that modularization and abstraction are the key concepts for mastering complexity. Our program slicer reuses slicing information that has been computed during previous executions.
There are program slicers that perform mainly static analysis and other program slicers that perform dynamic analysis by executing and profiling a program. During dynamic analysis, actual user input is recorded and used to make the slice preciser. We restricted our program slicing tool to static analysis but include feedback from the user. Thereby our program slicer can be classified as semi-dynamic because it allows the programmer to specialize the program to one use-case that he or she has in mind without actually executing the program.
Another well-known problem of program slicers is, that they tend to include everything into the slice. But a slice that consists of the whole program is surely not a big help for the user. We therefore aimed at a very fine granularity and perform slicing on an expression basis on the nodes of the abstract syntax tree.