Cross-Cutting Concern

Cross -Cutting Concern ( CCC ) is a term in computer science that refers to so-called cross-sectional concerns of software in the context of the divide-and -conquer principle, which can not be easily modularized because conventional modularization approaches do not apply ( in particular, object orientation ). Most of them are non-functional requirements for software, such as security aspects that are scattered all with conventional programming implemented throughout the code - for example, recurring tests of the form " may this code being executed? ". The aspect -oriented programming (AOP ) offers the possibility to formulate such a code centrally. At the same rules for it must be specified how this code can be woven or automatically executed in the right places.

The cost-effective and timely development and maintenance of high quality software is the primary goal of software engineering. To achieve this objective, as well as possible a modular software with a minimum of complexity is required. In a conventional system, this directory also includes the object-oriented approaches, core functionality can be cleanly separated into modules considered on its own according to the rules of art. However, there are requirements such as error handling, performance and security in any system that affect all core functionalities and can therefore assign a software module is not unique. This means that such fragments of cross-sectional functions are due to lack of cohesion is not assigned and unenclosed throughout the source. These requirements prevent in conventional software systems a clean modularization and affect care, comprehensibility, reusability, and (re) - traceability. This is due in conventional programming languages ​​Systemdekomposition that allows only one dimension. In this context one also speaks of dominant decomposition, that is, a naturally multi-dimensional problem has to be solved one-dimensional.

• 4.1 Definition of Terms
• 4.2 Categorization of Concerns
• 4.3 Core Concerns and Crosscutting Concerns 4.3.1 Definition Core Concerns
• 4.3.2 Definition crosscutting concerns

• 4.5.1 Definition Scattering
• 4.5.2 Definition Tangling

Identification, separation and integration

Each development process with aspect orientation consists of three basic stages of identification, separation and integration:

Identification

In the phase of identifying the relevant core and overarching requirements ( crosscutting concerns ) are detected with the help of various methods.

Separation

In the stage of separation it comes to define all Concerns independently when necessary to operationalize, modular design and implement. The keyword this is called separation of concerns and to Edsger Dijkstra (1976 ) returned. Of such modular implemented Core Concerns, core functions ' components are called; implemented modular crosscutting concerns are called aspects. In conventional approaches are certainly possibilities for separation of concerns exist ( eg in the field of non-functional requirements ), however they are limited there to the identification, specification and operationalization. In addition, the integration rules must be defined according to which the Concerns to be joined to the overall system in the later stage of separation.

Although David Parnas the term is not explicitly stated in his essay On the Criteria To Be Used in Decomposing Systems into Modules ( 1972), the invention of the concept of separation of concerns but is often in the literature attributed to him.

Integration

In the phase of integration the completed implemented components and aspects based on the integration rules are assembled to form the complete system. Especially in programming with aspect orientation will integrate with weaving, weaving called '. In some approaches, the integration and composition (English composition ) is called, which in no way Modeling Language class diagram may be equated with the same association in Unified.

Target

The aim of aspect orientation is to delay the integration in the development process as long as possible. This differentiate significantly the conventional of the batches with aspect orientation. In the conventional approaches, the integration is necessarily already in the design phase, because the relevant programming languages ​​do not have any possibilities to realize overlapping Concerns in several dimensions. In the aspect-oriented approaches, Concerns remain even separated during the design and implementation phase, and - depending on the approach - for translation or assembled at runtime. This offers the advantage that the individual aspects are still clean modularized in the source code, which improves reuse, understandability and the (re - ) traceability.

Requirement

A cross-cutting concern is a requirement of a software product to be respected or implemented across modules.

Examples of cross- cutting concerns are error handling, logging, tracing, and security requirements. Typically, they do not belong to the core functionality of the software, but represent additional or Metaanforderungen

This also results in a particular problem: in many software projects with a greater number of employees, the developers focus primarily on the core functionality, at the same time requires the implementation of cross- cutting concerns a high adaptability and coordination effort.

Possible solutions to this problem are the selection of appropriate software development processes, such as generative programming, the use of specific frameworks and languages ​​and the use of patterns as mix-in classes or aspects.

Concerns

Definition of Terms

Although the concern concept is more or less understandable, it is difficult to find in the literature a definition. Frequently the term is in fact not defined, it merely on the basis of lists, such as in Mehmet Aksits, Lodewijk Bergmans (2001): " [ ... ] Concerns, : such as access control, synchronization [ ... ] ".

• Object of contemplation. Strong interest or attention ( engl. regard ), usually because of a personal connection or a relationship ( Merriam- Webster, 2004).
• Any thing on a software system interested ( Stan Sutton, Isabelle Rouvellou, 2002).
• Any thing that interested in a system that is a goal or a set of properties that the system must meet ( Isabel Sofia Brito, Ana Moreira, 2004).
• Belang (English interest), which relates to the development or operation of a system, or any other aspect of one or more of the parties ( engl. stakeholder ) critical or otherwise important ( IEEE, 2000).
• Specific requirement or aspect, that (R) must be treated in a software system to achieve the overall system objectives ( Ramnivas Laddad, 2003).
• Relevant target system at the top level, which is usually derived from the critical business objectives of the client (Ian Sommerville, Peter Sawyer, 1997).

The definitions are not contradictory, but simply set other priorities. Which definition best fits, is based on the following two characteristics:

• Origin The meaning of the word Concern, requirements ' suggests that Concerns have something for which to show interest in the development of a system stakeholders in general and the principal is in particular that affect them personally and therefore can not ignore. Consequently, the definition of the term concern is to make a statement about where Concerns come, namely that Concerns arising from requests or requirements from stakeholders.

• Concerns are not defined for its own sake, but are binding targets for the design of a system. So the definition of the term concern is to make a statement, whereupon Concerns relate, in our case on software systems. Within the meaning of Ramnivas Laddad (2003), a software system is nothing other than the realization of a set of Concerns. Requirements that are not on the system but on the development process relate (for example, time and cost constraints ) are no Concerns in this sense.

The definition of Ramnivas Laddad here is favored since this most succinctly origin ( " request [ ... ] to [ ... ] to achieve system goals ") and also includes the reference point ("Software ") system.

Categorization of Concerns

It is difficult to classify the Concern - term sense because it is not very precisely defined and it depends on the client, which he considered as a request ( Concern ) and what is not. As a result, unstable categories may occur that change in the situation. For this reason, apart from a categorization with the exception of the division in Core Concerns and crosscutting concerns.

The following categorization demonstrates why it is problematic to categorize Concerns: According to João Araújo et al. (2002) there are cross -cutting core functionality / crosscutting concerns at the requirements level (for example, security, response time ) and crosscutting concerns on the Entwurfs-/Implementierungsebene due to technological limitations (for example, synchronization, error handling). The boundary between requirements and design decisions is variable and depends on the client. Depending on how this line is drawn in each individual case, including the Concerns of the respective category.

Core Concerns and Crosscutting Concerns

Ramnivas Laddad (2003 ) distinguishes between core functionality / Core Concerns and crosscutting core functionality / crosscutting concerns.

Definition Core Concerns

Realize the core functionality of a system.

Definition of crosscutting concerns

• Realize the functions of a system, which the Core Concerns ( core functionality ) or other crosscutting concerns cross cut such as logging or authentication.
• Two Concerns are "cross- cutting" when these methods Concerns cut ( Tzilla Elrad et al., 2001).

According Tzilla Elrad et al. (2001), one should always bear in mind that requirements ( Concerns ) are always only relative to a particular decomposition " cross cutting".

The distinction between core and crosscutting concerns is not equally important in all approaches. Thus, for example, in the Hyper / J and Multi-Dimensional Separation of Concerns ( MDSOC ) all Concerns explicitly treated equally and no distinction is made between core functionality and cross -cutting core functionalities. Such approaches are also called symmetric, while approaches that differentiate between Core Concerns and crosscutting concerns, which are called asymmetric.

Separation of Concerns

Various elements of the task to be represented as possible in different elements of the solution.

Scattering and Tangling

Definition Scattering

A single request ( Concern ) affects several design and code modules.

Scattering leads firstly to redundant or at least similar code blocks in all the affected modules and, unfortunately in poor maintainability, as well as to a high error rate for modifications. On the other hand, it is hardly possible to follow, in which modules a particular requirement has been implemented.

Tangling, confusion 'refers to a single module and arises when this module contains the implementations of several ( fragments of ) Concerns. Peri Tarr et al. (1999) defined as follows:

Definition Tangling

Code fragments that affect several requirements are mixed in a single module.

Tangling leads firstly causes poorly readable code, which has a negative impact on the maintainability and thus indirectly on the life and efficiency of the software. Secondly affected modules are poorly reusable from Tangling, because they contain several fragments of Concerns. And thirdly, it is difficult to impossible to trace which Concerns implemented a specific module.