Contents

A trace monitor observes the sequence of actions in a software system, and when it detects that this sequence matches a given pattern, it executes some extra code of its own. Trace monitors are often specified declaratively using patterns based on regular expressions, context free grammars or logical formulae, and then the trace monitor implementation is generated from the specification. Trace monitors are particularly useful for runtime verification, and many variations have been proposed. Despite this intense interest, there have been hardly any systems that implement the idea in its full generality, because it is hard to generate e#cient code from a purely declarative statement of the pattern. This paper identifies and addresses the challenges faced in generating e#cient trace monitors from declarative pattern-based specifications

On the Semantics of Matching Trace Monitoring Patterns

Abstract. Trace monitor specifications consist of a pattern that is matched against the trace of events of a subject system. We investigate the design choices in defining the semantics of matching patterns against traces. Some systems use an exact-match semantics (where every relevant event must be matched by the pattern), while others employ a skipping semantics (which allows any event to be skipped during matching). The semantics of exact-match is well established; here we give a semantics to skipping also by providing a translation to exact-match. It turns out the translation is not surjective: a pattern language with skipping semantics is strictly less expressive than one with exact-match semantics. That proof suggests the addition of a novel operator to a skipping language that makes it equivalent to exact-match. Another design decision concerns the atoms in patterns: are these unique runtime events, or can multiple atoms match the same runtime event? Many specification formalisms chose predicates for atoms, and then overlap is natural. There are some exceptions, however, and we examine the consequences of that design choice in some depth.

Keynote Address:.QL for Source Code Analysis Oege de Moor, Mathieu Verbaere, Elnar Hajiyev,

Many tasks in source code analysis can be viewed as evaluating queries over a relational representation of the code. Here we present an object-oriented query language, named.QL, and demonstrate its use for general navigation, bug finding and enforcing coding conventions. We then focus on the particular problem of specifying metrics as queries. 1

Adding Open Modules to AspectJ

AspectJ does not provide a mechanism to hide implementation details from advice. As a result, aspects are tightly coupled to the implementation of the code they advise, while the behaviour of the base code is impossible to determine without analysing all advice that could modify its behaviour. The concept o