Software architectures require the integration of cross-cutting concerns in order to implement the so-called core concerns. Their implementation is not limited to individual components, but is distributed over many areas throughout the entire system. Thus, completely different core functionalities are confronted with the application of a certain functionality.
The problem of Crosscutting Concerns is not new - it exists already, since there are software systems. Crosscutting concerns are used to describe functionalities such as authentication, transactional behavior, distributed communication or persistence. Particularly in larger projects the use of object-oriented mechanisms leads to a coupling between core and crosscutting Concerns. This influences criteria such as maintainability, maintenance and reusability of a software. There are different approaches to the modularization of Crosscutting Concerns such as Design Patterns, inversion or the aspect-oriented programming( AOP).
First of all Concerns are called specific requirements, which are treated in connection with a software system. Core Concerns describe the core functionalities of such a system. Crosscutting Concerns, on the other hand, define general tasks - also called crosscutting tasks - for handling basic requirements of a software system whose functionality is implemented repeatedly in several modules. One speaks also of the fact that Crosscutting Concerns crosscut the Core Concerns or also other Crosscutting Concerns.
Examples of Crosscutting
Typical examples of crosscutting concerns are:
- Data Collection.
- Reporting and logging functions.
- The verification of the integrity oftransactions.
- The checking of errors.
- Security and authentication .
- Persistence of data.
- Functions to enhance performance.
In connection with Crosscutting Concerns one often speaks also of technical requirements, or that these have functional character. Crosscutting Concerns and aspects are not to be equated, here aspects are to be defined as implemented Crosscutting Concerns. Likewise a connection of the terms requirement and Concerns is to be avoided. Requirements are rather to be seen as a specification of Concerns in detail. In the literature, the approach to separating core and crosscutting Concerns is also referred to as asymmetric.
Differences in crosscutting
Crosscutting is distinguished between:
Dynamic crosscutting. The behavior of objects is modified by adding further steps to the execution of methods.
Static crosscutting. This modifies the structures of a program. Possibilities are for this both by the adjustment of the inheritance hierarchy and by addition of further data structures and methods to a class. Also an initiation of additional checks of the translation is possible.
A central principle of the software engineering is the separation of Concerns introduced by Dijkstra (1976) - which means generally a separation of the concerns. Concretely in the context of Concerns it explains that a Concern identifies, encapsulates or also manipulates only parts of a software for exactly one area of responsibility. As it were in consequence this applies also to Crosscutting Concerns. Both core and Crosscutting Concerns are qualitatively high-quality, if these
- have strong cohesion and weak coupling,
- encapsulate their data structures and methods, and
- hide their implementation details from other Concerns( information hiding).
The principle presupposes however that Concerns can be specified as independently as possible from each other as well as implemented, in order to be joined then finally as late as possible to a total system. The problem thereby is that the object-oriented programming languages offer no other construct apart from the classes for the modeling of Crosscutting Concerns. This results in the following two typical problems:
Code Tangling. The mixing of different Concerns in one module - all code is encapsulated in one class.
Code Scattering. Crosscutting Concerns are distributed over several modules - same functionality is distributed over different classes.
This contradicts apart from the Separation OF Concern also the principles of the encapsulation as well as the functional decomposition, with which the hierarchical dismantling of a software system is described into partial functions.
Possible approaches to the modularization of Crosscutting Concerns can be:
- Use of design patterns (patterns), for example the Observer pattern for logging and checking security, the Command pattern for undo/redo mechanisms, or the Decorator pattern for enriching functionality.
- Inversion on Control - this means the indirection of the control flow via a container (e.g. the EJB container) or a special interpreter. The adaptation of the behavior via so-called metadata is also a possibility here.
- Aspect-oriented programming - modeling of crosscutting concerns through aspects.
A concrete beginning regarding Crosscutting Concerns from practice is to be introduced here still briefly - the Framework Enterprise JavaBeans (EJB) of the company Sun. Here crosscutting Concerns for the so-called Enterprise Beans such as failure safety, clustering, transactional behavior, security and persistence are made available by the EJB runtime environment in an application server. However, the feature requires the user to hand over control for all its components to the runtime system, and interact with it through appropriate interfaces. The framework specifically targets client-server architectures.