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

also handling them earlier in the software life-cycle, for instance at design time
[6], or during requirements analysis [2,14,24,29] and notably through the Early
Aspect community and the series of Early Aspect workshops[3].
At modeling level, even complex behavioral aspects can easily be described
for instance as pairs of UML 2.0 Sequence Diagrams (SDs), one SD for the point-
cut (specification of the behavior to detect), and the second one for an advice
representing the wanted behavior at the join point. This is usually fine enough
for informal documentation purposes, or even intuitive enough when a single
aspect has to be woven. The idea of Model Driven Engineering is however that
it should be possible to use these modeling artifacts beyond mere documentation
purposes, for example for validation purposes (simulation or test case generation)
and also for code generation, including targeting non-aspect-oriented platforms
(e.g. vanilla Java, or real-time embedded systems). A more precise semantics of
both join point detection and advice weaving is then needed.
In this paper, we focus on finite scenarios expressed by means of SDs. We
will call base scenario a scenario which describes the concern that determine
the dominante structure of the system, and behavioral aspect a pair of scenarios
which describes a concern that crosscuts the base scenario. For join point detec-
tion at modeling time, we need to statically find where in the base scenarios are
the join points. The partial order induced by a SD and the hierarchical nature
of UML 2.0 SD (similar to High-Level Message Sequence Charts [13]) makes it
necessary to address the problem at the semantic level [18] with static analysis
techniques such as loop unrolling, etc.
For the composition of the advice into the base SD, when we are weaving
a single aspect into a base SD and when a join point 1 is a strict sequences of
messages, the composition is trivial once the join point has been identified: the
advice SD just replaces the portion of the SD that is matched by the pointcut at
the join point. However weaving multiple aspects at the same join point can be
dicult if a join point is simply defined as a strict sequence of messages, because
aspects previously woven might have inserted messages in between.
The contribution of this paper is to propose a new interpretation for point-
cuts expressed as SDs to allow them to be matched by join points where some
messages may occur between the messages specified in the pointcut. However,
with this new way of specifying join points, the composition of the advice with
the detected part cannot any longer be a replacement of the detected part by
the advice. We have to consider the events (or the messages) of the join point
which are not specified within the pointcut and merge them with the behavior
specified within the advice. We thus propose a formal definition of a new merge
operator, called an amalgamated sum , and describe its implementation on the
meta-modeling platform Kermeta [19].
1 Note that in this paper, we borrowed the term “join point” from AspectJ terminology.
In contrast to AspectJ, however, we consider “join points” as a representation of an
element or a collection of elements of the language of scenario used rather that as
“well-defined points in the execution of the program” (cf. [16]). The term join point
will be formally defined in Sect. 3.