Analysis of Crosscutting in Early Software Development Phases Based on Traceability - Transactions on Aspect-Oriented Software Development - page 88

order to make a more realistic study of crosscutting in systems, both concerns related
to functional and non-functional properties must be analyzed. Otherwise, we obtain
results where every concern is crosscutting the other concerns as shown in this case.

5.3 Course Management System

We show in this section the application of the framework to another previously
published case study, a Course Management System (CMS). The case study consists
of a system for managing the students who register for several courses. This example
was introduced in [4] where the authors present an approach for identifying and
modeling crosscutting concerns at requirement and design stages. This approach is
based on the concept of theme. A theme is an element of design (collection of
structures and behaviors that represent one feature) and can be one of two different
kinds in the approach: base and crosscutting themes. In order to identify the
crosscutting themes at requirement level in the system, the authors introduce the
concept of action view. The action view is a representation of the requirements,
grouping them in the form of actions and relating them with the original requirements.
The actions are key words which the developer must identify by looking at the
requirements document and picking out sensible words.
In [4], the authors present the following requirements for the CMS:

• R1: Students can register for courses

• R2: Students can unregister for courses

• R3: When a student registers then it must be logged in his record

• R4: When a student unregisters it must also be logged

• R5: Professors can unregister students

• R6: When a professor unregisters a student it must be logged

• R7: When a professor unregisters a student it must be flagged as special

• R8: Professors can give marks for courses

• R9: When a professor gives a mark this must be logged in the student's record.

For these requirements, the authors [4] presented the following actions: register,
unregister, logged, give and flagged. Taking these actions and requirements, the
authors present an action view where such requirements are related with the
corresponding actions. We apply the framework to identify crosscutting by filling in
the dependency matrix in the same way as it is done in the action view [4]. As we can
see in Table 12 , the results offered by the crosscutting matrix are the same as those
shown in the action view in [4].
In the crosscutting matrix we can observe how there are several actions which are
considered to be crosscutting themes. Obviously, in real systems, requirements often
refer to more than one action so that we usually obtain many crosscutting themes. In
[4], the authors assume the same. In order to avoid this problem, they remove some
relationships between actions and requirements by analyzing the requirements and
deciding the main action addressed by each requirement. The result of this process is
a new action view which is called clipped action view . However, this is an ad-hoc
approach that could lead to (un)predictable results. Our framework may complement
Theme/Doc in order to properly take such decisions by means of the number of