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

Table 7. Two dependency matrices to be cascaded

dependency matrix 1

requirements

r[1] r[2] r[3] r[4]

c[1] 1 0 0 1

c[2] 0 1 0 0

c[3] 0 0 1 1

dependency matrix 2

modules

m[1] m[2] m[3] m[4] m[5]

r[1] 1 0 0 0 1

r[2] 0 1 0 0 0

r[3] 0 1 1 0 0

r[4] 0 0 0 1 1

matrices are shown in Table 7 . The first dependency matrix relates concerns with
requirements. The second dependency matrix relates requirements with modules. The
resulting dependency matrix relates concerns with modules (see Table 8 ). This matrix
can be used to derive the crosscutting matrix for concern x concern with respect to
modules.
The crosscutting matrix in Table 8 is not symmetric. Based on this matrix we
conclude, for the given dependency relations between concerns and modules, that:
concern c[1] is crosscutting concern c[3]; concern c[2] does not crosscut any other
concern; concern c[3] is crosscutting concerns c[1] and c[2].

Table 8. The resulting dependency matrix and crosscutting matrix based on cascading of the
matrices in Table 7

resulting dependency matrix

modules

m[1] m[2] m[3] m[4] m[5]

c[1] 1 0 0 1 2

c[2] 0 1 0 0 0

c[3] 0 1 1 1 1

crosscutting matrix

concerns

c[1] c[2] c[3]

c[1] 0 0 1

c[2] 0 0 0

c[3] 1 1 0

We summarize the cascading operation in Fig. 5. From this description it is clear that
cascading can be used for traceability analysis across multiple levels, e.g., from concerns
to implementation elements, via requirements, architecture and design (c.f. [30]).