Weaving Multiple Aspects in Sequence Diagrams - Transactions on Aspect-Oriented Software Development - page 195

Fig. 17. Impossible weaving
operator of composition can easily be adapted to the Theme approach to keep
the advantages of the two approaches.
Similarly to our approach, Whittle and Araujo ([29] and [2]) represent be-
havioral aspects with scenarios. Aspectual scenarios are modeled as interaction
pattern specifications (IPSs introduced in [12]) and are composed with specifi-
cation scenarios. The weaving process defined in [29] composes scenarios with
instantiation and ad-hoc composition operators. The weaving process proposed
by [2] is performed in two steps. The first step is to generate state machines from
the aspects and from the specification. The weaving process is then a composi-
tion of these state machines. However, in these two approaches, the detection of
join points is not automated: users have to specify them with a binding relation
between an aspect and a specification. Moreover, their composition operator for
SDs is not defined formally.
In [26], Stein et al. introduce a way to express various conceptual models of
pointcuts in aspect-oriented design. But, they do not provide a way to detect
the join points specified by these pointcuts. By contrast, in our approach the
detection of the join points and their composition is automatic.
More generally, in [10] and [11], Douence et al. are interested in event pattern
matching, which is close to our approach. A significant difference is that they use
a monitor to perform event pattern matching at runtime on a program execution,
whereas our weaving is made statically at a modeling level. Similar to Douence et
al., Walker and Viggers [28] have proposed declarative event patterns as a means
to specify patterns of events to detect sequence of events in the execution of a
system based on a context-free-language-based pattern matching, while Allan et
al. [1] have proposed a new history-based language feature called tracematches
that enables the programmer to trigger the execution of extra code by specifying
a regular pattern of events in a computation trace. Our approach differs from
both in that we allow the entire pattern (join point) to be replaced or completed,
rather than just the final event in the pattern. We can do that because our