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

group of scenario/use case-based approaches, we will briefly review this group
in more detail.
In Aspect-Oriented Software Development (AOSD) with Use Cases [25], Ja-
cobson and Ng view a well-written use case as a concern and add the notion of
pointcuts to the traditional use case approach. Pointcuts in one use case refer-
ence extension points in other use cases in a textual way. The traditional usage
of extension points is slightly altered as they do not directly reference a use case
anymore but only identify a step in the use case where an extension may occur.
Furthermore, a new kind of use case, the infrastructure use case ,isusedinad-
dition to the traditional application use cases . It describes scenarios required to
address non-functional requirements. Infrastructure use cases do not reference
other use cases directly but pointcuts in a generic perform transaction use case .
This particular use case models abstractly all types of interactions of an actor
with the system, providing a generic description of the system. The perform
transaction use case is eventually mapped to traditional use cases, effectively
weaving aspect behavior described by infrastructure use cases into application
use cases.
In Scenario Modeling with Aspects [41], Whittle and Araujo use UML sequence
diagrams to describe non-aspectual scenarios and interaction pattern specifica-
tions (IPS) to describe aspectual scenarios. IPS are very similar to sequence
diagrams but allow the definition of roles for classifiers, messages, and para-
meters. Binding the roles in IPS to elements of sequence diagrams produces
a composed system, which is then translated into state machines for valida-
tion. Alternatively, the sequence diagrams and IPS are first both translated into
state machine representations [finite state machines and state machine pattern
specifications (SMPS), respectively] and then composed together at the state
machine level [13] with the same binding technique. SMPS are very similar to
state machines but also contain roles identified in IPS. In both cases, the bind-
ing is specified textually and identifies explicitly elements to be bound. On one
hand, this allows for a very flexible composition. On the other hand however,
the explicit binding may cause problems with scalability.
The Aspectual Use Case Driven Approach is the third major research direction
discussed for scenario/use case-based approaches in [20]. Moreira et al. [12, 29]
propose to add extensions to UML use case and sequence diagrams in order
to visualize how crosscutting non-functional requirements are linked to func-
tional requirements expressed by use case diagrams or sequence diagrams. Non-
functional requirements are captured with the help of templates. Moreira and
Araujo [28] builds on this work, extending the set of use case relationships to
include “constrain”, “collaborate”, and “damage” relationships and making use
of activity pattern specifications (APS). The new relationships describe how one
use case impacts another (restricting it, contributing positively to it, or con-
tributing negatively to it). APS extend UML activity diagrams by allowing the
specification of roles similar to IPS [41] and SMPS [13]. APS are used to describe
use cases in more detail. Various activity diagrams are composed by composition
rules which are similar to the binding in [13, 41].