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

Table 9. ( continued )

crosscutting matrix WRT 1 classes

concerns

Distribution-to-
Client

Distribution-
to-Server

concerns Calculation

Distribution-to-Client 0 0 0

Distribution-to-Server 0 0 0

Calculation 0 0 0

1 WRT are the abbreviation of “with respect to”.

So, taking such a decomposition (in classes) and applying the framework, we
obtain the dependency matrix shown in Table 9 . As we can see in the matrix, concerns
Distribution-to-Client and Distribution-to-Server are tangled in the same class
SocketConnection, whereas Calculation concern is scattered over the other classes.
However, as can be seen in the table, the matrix has no crosscutpoint. By means of the
operations described in Sect. 3.2 we obtain the crosscutting matrix shown in Table 9 :
there are no crosscutting concerns in the system.
In many situations, we have tangling, scattering and at the same time crosscutting.
With our definitions, we clearly distinguished scattering and tangling from
crosscutting and, as we stated in Sect. 2.3, scattering and tangling are necessary but
not sufficient conditions for crosscutting. The analysis depends on the chosen
decomposition of source and target, other decompositions being feasible.

5.2 Portuguese Highways Toll System

In order to validate our framework, in this section we apply it to a well-known case
study — the Portuguese Highways Toll System — which has been widely explained
in some publications on the early aspects topic [2, 28]. As we will see at the end of
the section, the results obtained are similar. As a starting point we take the same
decompositions made by the authors of the original case. It can be seen that the
concern decomposition is related to non-functional properties of the system.
The system is based on a road traffic price system where drivers of authorized
vehicles are charged automatically at toll gates. The gates have sensors able to read
information provided by a device installed in the vehicle when it passes through. This
device is called a “gizmo” [28]. When an authorized vehicle passes through the toll gate,
a green light turns on and a display shows the amount to be paid by the driver. If the car
is not authorized, a yellow light turns on and a camera takes a photo of the license plate.
In [28] the authors identified the following stakeholders' requirements (which are
represented by means of viewpoints [16]): ATM (allows the drivers to enter their
information for registration in the system), Vehicle, Gizmo, Police (receives
information about unauthorised vehicles), Debiting System (interacts with the bank to
allow the payment), Toll Gate, Vehicle Owner and System Administrator (modifies
information in the system). Some of these viewpoints have sub-viewpoints. On the
other hand, after analyzing the initial requirements the authors specified the following
concerns: Security, Response Time, Multi-Access System, Compatibility, Legal
Issues, Correctness and Availability.