Visualizing Early Aspects with Use Case Maps - Transactions on Aspect-Oriented Software Development - page 114

Rashid et al. [32] describe an approach for conflict identification and res-
olution for aspectual requirements. While the example presented in [32] uses
a viewpoint-based approach to requirements engineering, it is argued that the
technique can also be applied to other requirements engineering approaches in-
cluding scenarios/use cases. The topic matter, however, is orthogonal to our
proposed technique.
Araujo and Coutinho [11] discuss aspects in a viewpoint-based requirements
engineering approach that also includes use cases. Non-functional requirements
(defined with templates) and use cases are linked to viewpoints. Use cases that
are included by or extend more than one use case or that crosscut several view-
points are called aspectual use cases . This approach does not discuss composition
of aspectual use cases with other use cases but focuses more on how to extend
the work in [32] for conflict resolution.
Barros and Gomes [15] apply aspect-orientation to UML activity diagrams.
The approach is based on an additional composition operation called activity
addition which allows the fusing of stereotyped nodes in one activity diagram
with nodes in another. Stereotyping is effectively used as a pointcut expression,
identifying explicitly nodes in another activity diagram for behavior merging.
Zdun and Strembeck [42] extend UML activity diagrams with nodes for start
and end points of aspects in order to visualize aspects in a composed system.
In the UCM community, the applicability of UCMs to model aspects was
identified very early on by Buhr [18] but received little attention since then with
the exception of de Bruin and van Vliet [22]. The approach by de Bruin and van
Vliet adds Pre stubs and Post stubs for each location on a UCM that requires
a change. The stubs allow behavior to be added before or after the location by
plugging refinement maps into the stubs. Components on UCMs are identified
by a Name:Type pair . A refinement map can be placed in a Pre or Post stub
only if the component type on the refinement map matches the component type
to which the Pre or Post stub is bound.
Defining and representing aspects must consider a number of factors. It should
be easy to switch from traditional modeling to aspect-oriented modeling. Prefer-
ably, there should not be a difference and the same modeling language should be
used for both in order to avoid having to learn yet another modeling language.
It should be possible to define aspects without influencing the base model. This
is a crucial point of aspect-orientation asthebasemodelmustnotbepolluted
by aspect-specific information. Breaking the modeling paradigm is best avoided,
and therefore aspects, including advice, pointcut expressions, and intertype dec-
larations should be modeled using the same modeling paradigm (e.g., without the
use of graphical and purely textual representations at the same time). Pointcut
expressions should be parameterized to avoid scalability issues. For scenario/use
case-based aspect techniques to be effective at the requirements phase, the em-
ployed technique should be at the right abstraction level where message or data
details of interactions are irrelevant. The composition technique should be flex-
ible and exhaustive in that it allows all frequently encountered compositions to
be expressed.