Section 19.2. MOTIVATION

19.2. MOTIVATION

To motivate the need for modularizing the design of behavior that crosscuts other behaviors, we use the simple example of requiring that operations be traced at runtime. Tracing is a particularly pervasive requirement that potentially impacts every operation in every class of a system. Without a means to separate its design, the potential for scattering and tangling across a system is enormous. A simplified design for tracing an operation in class X is contained in Figure 19-1 (using UML [17]).

Figure 19-1. Pervasive trace design.

From a structural design perspective, the design elements supporting tracing may be separated into a class, TRace, upon which any class requiring trace behavior may depend. However, to design the trace behavior of operations, this separation is not possible to maintain. In the interaction diagram, we see that when the foo() operation of class X is invoked, it immediately calls the traceEntry() operation of class trace with a parameter denoting the name of the entered method, i.e., foo. Likewise, when the foo() operation has finished and is about to return, it finally calls the traceExit() operation of class trace. Any other operations requiring trace behavior would need to be designed analogously.

This design has a number of difficulties. First, any new operation requiring trace behavior must specify an interaction model indicating thisa tedious and error-prone process. Secondly, changing or eliminating the trace behavior design requires changes to all operation interaction models. Finally, reuse of this design in a different system is not straightforward. Structurally, the TRace class may simply be copied, but the trace behavior must be redefined in the interaction specification of each operation to be traced.

These problems are mitigated by modularizing the design for crosscutting behavior into a theme. In particular, when modularized, crosscutting behavior specifications can be easily reused in different circumstances.