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

can be represented, and how dynamic responsibilities and dynamic components
(not shown here) can be used to capture requirements for agent systems. UCMs
also integrate a simple data model, performance annotations, and a simple action
language used for analysis. However, activity diagrams have better support for
object flows and a better integration with the rest of UML.
On the other hand, UCMs are integrated with goal-oriented models described
with the Goal-oriented Requirement Language (GRL), the second modeling no-
tation in the URN. With URN, the goals of stakeholders and the system are
modeled on GRL graphs, showing the impact of often conflicting goals and var-
ious alternative solutions proposed to achieve the goals. Softgoals (which relate
to non-functional requirements), hard goals (which relate to functional require-
ments), and solutions impact each other in either a negative or positive way. The
solutions from the GRL graphs are refined by the UCM model which provides
the structural and behavioral details of scenarios for the solution.
Two editing tools for UCMs have been developed at Carleton University and
the University of Ottawa. The tools make it possible to create, maintain, analyze,
and transform UCM models. The original UCM Navigator (UCMNav)[27]is
only a UCM tool whereas the new Eclipse-based jUCMNav [33] is a true URN
tool that offers GRL modeling in addition to UCM modeling.

2.2 Use Case Maps Example

This section discusses a simplified example which further illustrates the UCM
notation. Given the following requirements, the basic UCM model in Fig. 3 can
be created consisting of two use cases:

R1. Users shall be able to make reservations.
R2. System shall authenticate users before any access to a reservation (such as
making, canceling, ...).
R3. System shall add failed reservation attempts to a waiting list from which
they will be taken when another reservation is canceled in the future.

In the make reservation use case, the system first checks for authorization and
only if the user is authorized is the reservation made. If the reservation is not
successful, the reservation is added to a waiting list. In the cancel reservation
use case, the system again checks for authorization and only if the user is au-
thorized is the cancellation performed. After the cancellation, the system tries
to fulfill a reservation from the waiting list. Note that the components in this
case correspond to objects, but this is just one of the possible interpretations of
a UCM component. Considering that there exist other non-functional require-
ments (such as security) that need to be added to the use cases and considering
that there exist other features that interact with making and canceling reserva-
tions (such as waiting lists) and that need to be added to the use cases, there is
clearly a need for better modularization. A more advanced UCM model which
extracts the common behavior into a plug-in map is shown in Fig. 4.
Even though stubs structure the UCM model considerably better, the cancel
and make reservation use cases still include descriptions of non-related behavior