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

Make Reservation

Reservation

Authorization

start success

makeReservation

[reservationOK]

[reservationFailed]

WaitingList

fail

addToWaitingList

Cancel Reservation

Reservation

Authorization

start

cancelReservation

WaitingList

success

tryReservationsFromWaitingList

Security

Security

start success

checkAuthorization

[success]

[fail]

fail

Fig. 4. Advanced UCM reservation use cases — first attempt

many different requirements units). This problem has also been referred to as the
tyranny of the dominant decomposition [36], as a chosen modularization tech-
nique (e.g., objects) inevitably will cause unwanted side-effects in the software
design (e.g., scattering and tangling). The UCM model in Fig. 5 exhibits signs
of scattering and tangling. The Authorization stub is scattered over multiple root
maps and various concerns are tangled in each of the root maps. Examples for
requirements units (or concerns ) for which aspects provide a better encapsula-
tion than objects are authorization/authentication, caching, concurrency man-
agement, debugging, distribution, logging, testing, transaction management, or
even a feature or use case [25].
Initially, aspect-orientation focused on the implementation level leading to an
ever-growing number of tools that provide extensions for aspects to major pro-
gramming languages [9, 10]. Essentially, aspects identify locations in a program
(called joinpoints ) through parameterized expressions (called pointcuts ). Aspects
also specify behavior (called advice ) which will be inserted into the specified loca-
tions. As advices may change the behavior of already existing structural entities
thus violating proper object-oriented modularization, entities external to an as-
pect are referenced in a structured way (with the help of intertype declarations ).