Modular Decomposition

The separation of concerns principles states actually that each concern of a given software design problem should be preferably mapped to one module in the system. Or putting it differently, the problem should be decomposed into modules such that each module has one concern. The advantage of this is that concerns are localized and as such can be easier understood, extended, reused, adapted etc. This decomposition process is illustrated in figure 1. The design problem is decomposed into concerns C1 to Cn and each of these concerns is mapped to a separate module M. A module is an abstraction of a modular unit in a given design language (class, function, procedure, etc).

Figure 1. Mapping Concerns C1..Cn to Modules M1..Mn

Crosscutting Concerns

Many concerns can indeed be mapped to single modules. Some concerns, however, cannot be easily separated, and given the design language we are forced to map such concerns over many modules. This is called crosscutting. In figure 2, for example, concern C3 is mapped to the modules M2, M3, M4 and M5. We say that C3 is a crosscutting concern or an aspect. Examples of aspects are monitoring, logging, synchronization, load balancing etc. Aspects are not the result of a bad design but have more inherent reasons. A bad design including mixed concerns over the modules could be refactored to a neat design in which each module only addresses a single concern. However, if we are dealing with these crosscutting concerns this is in principle not possible, that is, each refactoring attempt will fail and the crosscutting will remain. A crosscutting concern is a serious problem since it is harder to understand, reuse, extend, adapt and maintain the concern because it is spread over so many places. Finding the places where the crosscutting occurs is the first problem, adapting the concern appropriately (without unforeseen effects) is another problem.

Figure 2. Concern C3 crosscuts Modules M2, M3, M4 and M5

Things may even get worse if we have to deal with multiple crosscutting concerns. For example in figure 3 we have to deal with 2 crosscutting concerns C3 and C5.

Figure 3. Crosscutting concerns C3 and C5

Tangled Concerns

Since we cannot easily localize and separate crosscutting concerns several modules will include more than one concern. We say that the concerns are tangled in the corresponding module. For example in figure 3, the concerns C2, C3 and C5 are tangled in the module M2. Note that concern C2 is not crosscutting. 

Joinpoints

Figure 4 represents the same information as in figure 3. Hereby, the modules have been aligned over the vertical axis and the concerns over the horizontal axis. The circles represents the places where the concerns crosscut a module. These are called joinpoints. Joinpoints can be at the level of a module (class) or be more refined and deal with sub-parts of the module (attribute, operation) etc. Crosscutting can be easily identified if we follow a concern in a vertical direction (multiple joinpoints). Tangling can be detected if we follow each module in the horizontal direction (multiple joinpoints).

Figure 4. Crosscutting, Tangling, and Joinpoints