In approaching a paper, a reviewer has a few questions ready. What is the paper about? How does the method described work? Where is it situated relative to other work? But perhaps the first question to ask is this: Why should I read the paper? Dynamic slicing has the general advantage over static slicing in that it can be more precise: while a static slicer cannot usually predict which branch is taken, a dynamic slicer, necessarily, results in one choice at a branch. So, there is a generic reason for pursuing the work.
In general, justification of a technique comes down to its applicability and usefulness. The authors do not stress this, but do give an example in section 5.3 of the paper where they make a comparison between their technique and static slicing (their references 3 and 20) in a particular example, with a bug inserted: the dynamic slice is indeed more useful in debugging in this case. This gives us some confidence that the technique is of value, at least in a toy example.
As far as the other questions go, we are given a clear picture of what dynamic slicing means to the authors, and how this differs from dynamic slicing for sequential imperative programming languages, for which slicing was first performed. They make the somewhat puzzling claim that performing slicing for a concurrent specification language requires a new definition of “slicing criterion,” while discussing static slicing for the same language in their discussion of related work, and indeed making the comparison between the static and dynamic in section 5.3, as noted earlier.
There is also a clear discussion of how the technique is implemented: this is by means of a translation to Erlang, but it is unfortunate that they don’t discuss the existing work on slicing Erlang (for example [1,2,3]), nor any potential application of the technique to the language.
Finally, there’s a question about precisely how innovative this approach is, fundamentally. The work addresses concurrency, and in particular concurrent specification languages, but there is a restriction to this: in order to have a dynamic slice, there has to be an implementation whose behavior can be tracked, and so the specification must be an “executable specification.” This means that the work covers communicating sequential processes (CSP) and could be extended to, say, the calculus of communicating systems (CCS). On the other hand, many specification languages are by their nature nonexecutable, and so require entirely different mechanisms for an expression of what it means to take a static slice. That remains a challenge for them and others in the field.