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

enhances the identification of such relations (see Fig. 12 ). Ramesh and Jarke [27]
show a more detailed model about traceability where these and other more specific
relations are explained. The UML 2.0 specification [31] also covers such
relationships. In [19] the authors show another taxonomy of trace relationships. The
model shown in Fig. 12 is based on the previous models covering some important
trace relationships of interest for crosscutting identification.
As shown in Fig. 12 , we focus just on the following types of trace relationships:
refinement, elaboration, evolution and representation. These relationships may be
applied to different domains where we can find them. For example:
• Refinement: In software development we usually find refinements between

different abstraction levels. For instance, the first abstraction could refer to the
concerns a system must deal with and the second one to the software artifacts
which address such concerns (this could be extended to any phase in software
development). As another example, the Model Driven Architecture (MDA) [24]
provides a way to build software based on different refinements or
transformations between models or artifacts belonging to different abstraction
levels [e.g. Computational Independent Model (CIM), Platform Independent
Model (PIM) and Platform Specific Model (PSM)]. In most of the case studies
we showed in Sect. 5, we identified some examples of refinement relations. For
instance, we related concerns to requirements artifacts or design classes.

• Elaboration: We can find relationships between models of the same abstraction

level. In such situations, we elaborate or add some extra information to a model
in order to get a new model. For instance at requirement level we can elaborate a
use case based on a previous one. In MDA, model-to-model transformations at
the same abstraction level (e.g., PIM-to-PIM) are also examples of this kind of
trace relationship.

• Representation: In requirements engineering it is very common to have different

representations of the same user needs. For instance, we can represent the
requirements as statements extracted from a requirement elicitation document and
we can also represent such requirements as viewpoints or use cases. We can link
both kinds of representation by means of trace relationships. In the Course
Management System shown in Sect. 5.3 we can identify this kind of relationships. In
this case study we related requirements to actions. Actions are integrated into an
Action View which is a different representation of the same requirements.

• Evolution: With this type of dependencies we can relate gradual changes of

software artifacts over time (as in adaptive maintenance). The “evolves-to”
relationship exists between modified (structural and/or behavioral) elements in
artifacts.
Other types can be defined depending on the goal of traceability to be achieved.

6.2 Languages and Decomposition

Our definition of crosscutting is based on a mapping from source to target
(represented in the dependency matrix with source and target elements). In some
cases it is possible to avoid tangling, scattering and crosscutting by choosing another
decomposition of source and target, a possibility determined by the expressive power