ITWissen.info - Tech know how online

Crosscutting Concerns

Software architectures require the integration of crosscutting 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 - they have existed as long as software systems

have existed.Crosscutting concerns are used to describe functionalities such as authentication, transactional behavior, distributed communication, or persistence. Especially 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 modularize crosscutting concerns like design patterns, inversion or aspect-oriented programming

(AOP)

Core Concerns and Crosscutting Conc

Core Concerns and Crosscutting Conc

erns First, concerns are referred to as specific requirements that are addressed in the context of 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. Crosscutting Concerns arealso said to crosscut Core Concerns or even other Crosscutting Concerns.

Examples of Crosscutting

Typical examples of Crosscutting Concerns are:

  • Data collection.
  • Reporting and logging functions.
  • Checking the integrity oftransactions.
  • The checking of errors.
  • Security and authentication .
  • Persistence of data.
  • Functions to enhance performance.
In the context of Crosscutting Concerns, we often also speak of technical requirements, or that they are functional in nature. 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 for the separation of core and Crosscutting Concerns is called also asymmetrical

Differences of the

Crosscutting With the Crosscutting are differentiated:

Dynamic Crosscutting

. Thebehavior of objects is modified by adding further steps

to theexecution of methods

Static

crosscutting.

This modifies the structures of a program. Possibilities for this are both by adapting the inheritance hierarchy and by adding further data structures and methods to a class

. It isalso possible to initiate additional checks on the translation.

A central principle of software engineering is the Separation of Concerns introduced by Dijkstra (1976) - which generally means a separation of concerns. Specifically in the context of Concerns, it explains that a Concern only identifies, encapsulates or even manipulates parts of a software for exactly one area of responsibility. Similarly, this consequently applies to Crosscutting Concerns. Both core and crosscutting Concerns are of 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).
However, the principle presupposes that concerns can be specified and implemented as independently of each other as possible, in order to be finally combined into a complete system as late as possible. The problem with this is that object-oriented programming languages

do not offer any construct other than classes for modeling crosscutting concerns. This results in the following two typical problems:code tangling. The mixing of different Concerns in one module - all the code

is encapsulated in one classCode Scattering

. Crosscutting Concerns are distributed over several modules - the same functionality is distributed over different classes.This contradicts not only the Separation of Concern but also the principles of encapsulation

and functional decomposition, which describes the hierarchical decomposition of a software system into subfunctions.Possible solutions for 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 approach regarding Crosscutting Concerns from the practice is to be introduced here still briefly - the FrameworkEnterprise JavaBeans (EJB) of the company Sun. Crosscutting Concerns for the so-called Enterprise Beans such as failure safety, clustering, transactional behaviour, 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.

Informationen zum Artikel
Englisch: Crosscutting Concerns
Updated at: 09.11.2013
#Words: 1066
Links: