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

Make Reservation

Security Reservation

start success

makeReservation

checkAuthorization

[success] [reservationOK]

[fail]

[reservationFailed]

WaitingList

fail

fail

addToWaitingList

Cancel Reservation

Security Reservation

start

checkAuthorization cancelReservation

[success]

[fail]

WaitingList

success

fail

tryReservationsFromWaitingList

Fig. 3. Basic UCM reservation use cases

(the stubs related to authorization and the responsibilities related to waiting
lists). A further improvement of the UCM model in Fig. 4 is shown in Fig. 5. Now,
each individual plug-in map only deals with one concern. Top-level maps (often
called root maps) describe how the different concerns are composed together.
However, root maps often turn out to be rather complicated. Scalability is also
an issue as, for example, the Authorization stub has to be added explicitly to each
root map. Furthermore, the description of making a reservation is in one plug-in
map only because no other use case exists that needs to be interleaved with
making a reservation. Figure 5 only shows the situation where behavior has to
be added before or after making and canceling reservations. Often however, use
cases are interleaved, causing the behavior for making a reservation to be split
up into several maps (see Fig. 6 — the disjoint plug-in maps in Make Reservation
Part 1 and Part 2 only contain parts of the behavior for making a reservation).
This makes it much harder to understand and maintain individual use cases.
AoUCM address these problems.

2.3 Modeling Techniques for Aspect-Oriented Requirements

About a decade ago, aspect-oriented programming (AOP) [26] introduced a new
way of structuring software systems. With this new modularization, it is possible
to address problems of object-oriented software engineering that occur because
the units of interest to the requirements engineer cannot readily be encapsulated
with object-oriented units [21]. This results in scattering (parts of a requirements
unit are scattered over many classes) and tangling (one class contains parts of