# Cross-Cutting Concern

Cross-Cutting Concern (CCC) ist ein Begriff der Informatik, der im Kontext des Teile-und-Herrsche-Prinzips so genannte querschnittliche Belange einer Software bezeichnet, die deshalb nicht einfach modularisiert werden können, weil herkömmliche Modularisierungsansätze (insbesondere die Objektorientierung) nicht greifen. Meist sind es nichtfunktionale Anforderungen an Software wie etwa Sicherheitsaspekte, die bei konventioneller Programmierung quer verstreut über den gesamten Code realisiert werden – beispielsweise immer wiederkehrende Prüfungen der Form „darf dieser Code gerade ausgeführt werden?“. Die Aspektorientierte Programmierung (AOP) bietet die Möglichkeit, solchen Code zentral zu formulieren. Gleichzeitig müssen Regeln dafür angegeben werden, wie dieser Code automatisch an den richtigen Stellen eingewoben oder ausgeführt werden kann.
Die kostengünstige und termingerechte Entwicklung und Wartung qualitativ hochwertiger Software ist das Primärziel der Softwaretechnik. Um dieses Ziel zu erreichen, ist eine möglichst gut modularisierte Software mit einer möglichst geringen Komplexität notwendig. In einem konventionellen System, wobei hier auch die objektorientierten Ansätze hinzugehören, können Kernfunktionalitäten für sich allein betrachtet nach den Regeln der Kunst sauber in Module getrennt werden. Es gibt jedoch Anforderungen wie Fehlerbehandlung, Performance und Sicherheit in jedem System, die alle Kernfunktionalitäten betreffen und sich deshalb nicht eindeutig einem Software-Modul zuordnen lassen. Dies führt dazu, dass Fragmente solcher querschnittlicher Funktionen aufgrund fehlender Kohäsion nicht zugeordnet und ungekapselt im ganzen Code verstreut sind. Diese Anforderungen verhindern in konventionellen Software-Systemen eine saubere Modularisierung und beeinträchtigen Pflege, Verständlichkeit, Wiederverwendbarkeit und (Rück)-Verfolgbarkeit. Verantwortlich hierfür ist bei konventionellen Programmiersprachen die Systemdekomposition, die nur eine Dimension zulässt. In diesem Zusammenhang spricht man auch von dominanter Dekomposition, d. h. ein natürlicherweise mehrdimensionales Problem muss eindimensional gelöst werden.

## Identifikation, Separation und Integration

Jeder Entwicklungsprozess mit Aspektorientierung besteht aus den drei grundlegenden Phasen Identifikation, Separation und Integration:

### Identifikation

In der Phase der Identifikation werden die relevanten Core Concerns und übergreifende Anforderungen (Cross-Cutting Concerns) mit Hilfe von verschiedenen Verfahren erkannt.

### Separation

In der Phase der Separation geht es darum, alle Concerns unabhängig voneinander zu definieren, wenn notwendig zu operationalisieren, modular zu entwerfen und zu implementieren. Das Stichwort hierzu heißt Separation of Concerns und wird auf Edsger W. Dijkstra (1976) zurückgeführt. Solcherart modular implementierte Core Concerns (‚Kernfunktionalitäten‘) werden Komponenten genannt; modular implementierte Cross-Cutting Concerns werden als Aspekte bezeichnet. Auch in konventionellen Ansätzen sind durchaus Möglichkeiten zur Separation of Concerns vorhanden (zum Beispiel im Bereich von nichtfunktionalen Anforderungen), jedoch beschränken sie sich dort auf die Identifikation, Spezifikation und Operationalisierung. Daneben müssen in der Phase der Separation auch die Integrationsregeln definiert werden, nach denen die Concerns später zum Gesamtsystem zusammengefügt werden sollen.
Obwohl David Parnas den Begriff in seinem Essay On the Criteria To Be Used in Decomposing Systems into Modules (1972) nicht explizit erwähnt, wird die Erfindung des Begriffs Separation of Concerns oft jedoch in der Literatur ihm zugeschrieben.

### Integration

In der Phase der Integration werden die fertig implementierten Komponenten und Aspekte anhand der Integrationsregeln zum Gesamtsystem zusammengefügt. Speziell in der Programmierung mit Aspektorientierung wird die Integration mit weaving (‚Weben‘) bezeichnet. In einigen Ansätzen wird die Integration auch Komposition (englisch composition) genannt, was keinesfalls mit der gleichnamigen Assoziation im Unified-Modeling-Language-Klassendiagramm gleichgesetzt werden darf.

## Ziel

Ziel der Aspektorientierung ist es, die Integration im Entwicklungsprozess möglichst lange hinauszuzögern. Dadurch differenzieren sich wesentlich auch die konventionellen von den Ansätzen mit Aspektorientierung. Bei den konventionellen Ansätzen erfolgt die Integration notgedrungen bereits in der Entwurfsphase, weil die entsprechenden Programmiersprachen keine Möglichkeiten haben, überlappende Concerns in mehreren Dimensionen zu realisieren. Bei den aspektorientierten Ansätzen bleiben die Concerns auch während der Entwurfs- und Implementierungsphase noch getrennt und werden – je nach Ansatz – zur Übersetzungs- oder zur Laufzeit zusammengefügt. Dies bietet den Vorteil, dass die einzelnen Aspekte im Quellcode immer noch sauber modularisiert sind, was die Wiederverwendung, die Verständlichkeit und die (Rück-)Verfolgbarkeit verbessert.

## Anforderung

Ein Cross-Cutting Concern ist eine Anforderung an ein Softwareprodukt, die modulübergreifend einzuhalten oder umzusetzen ist.
Beispiele für Cross-Cutting Concerns sind Fehlerbehandlung, Logging, Tracing und Sicherheitsanforderungen. Typischerweise gehören sie nicht zur Kernfunktionalität der Software, sondern stellen Zusatz- oder Metaanforderungen dar.
Damit ergibt sich auch eine besondere Problematik: bei vielen Softwareprojekten mit größerer Mitarbeiterzahl konzentrieren sich die Entwickler primär auf die Kernfunktionalität, gleichzeitig erfordert die Implementierung von Cross-Cutting Concerns einen hohen Anpassungs- und Koordinierungsaufwand.
Möglichkeiten zur Lösung dieses Problems bestehen in der Auswahl geeigneter Softwareentwicklungsprozesse, etwa generative Programmierung, die Verwendung spezifischer Frameworks und Sprachen und die Verwendung von Patterns wie Mix-in-Klassen oder Aspekten.

## Concerns
### Begriffsdefinition

Obwohl der Concern-Begriff mehr oder weniger verständlich ist, ist es schwierig, in der Literatur eine Definition zu finden. Häufig wird der Begriff nämlich nicht definiert, sondern lediglich anhand von Aufzählungen eingeführt, so zum Beispiel in Mehmet Aksits, Lodewijk Bergmans (2001): “[…] concerns, such as access control, synchronization […]”.
* Gegenstand der Betrachtung. Starkes Interesse oder Beachtung (englisch regard), üblicherweise aufgrund einer persönlichen Bindung oder Beziehung (Merriam-Webster, 2004).
* Irgendeine Sache, die an einem Software-System interessiert (Stan Sutton, Isabelle Rouvellou, 2002).
* Irgendeine Sache, die an einem System interessiert, d. h. ein Ziel oder eine Menge von Eigenschaften, die das System erfüllen muss (Isabel Sofia Brito, Ana Moreira, 2004).
* Belang (englisch interest), welcher die Entwicklung oder den Betrieb eines Systems betrifft, oder irgendein anderer Aspekt, der für einen oder mehrere Beteiligte (englisch stakeholder) kritisch oder sonst wichtig ist (IEEE, 2000).
* Spezifische Anforderung oder Gesichtspunkt, welche(r) in einem Software-System behandelt werden muss, um die übergreifenden Systemziele zu erreichen (Ramnivas Laddad, 2003).
* Maßgebliches Systemziel auf oberster Ebene, das üblicherweise aus den kritischen Geschäftszielen des Auftraggebers abgeleitet wird (Ian Sommerville, Peter Sawyer, 1997).
Die Definitionen widersprechen sich nicht, sondern setzen lediglich andere Schwerpunkte. Welche Definition sich am besten eignet, erfolgt anhand der folgenden beiden Merkmale:
* Herkunft
** Die Bedeutung des Worts Concern ‚Anforderungen‘ deutet darauf hin, dass Concerns etwas sind, wofür sich die an der Entstehung eines Systems Beteiligten im Allgemeinen und der Auftraggeber im Besonderen Interesse zeigen, die sie persönlich betreffen und daher nicht ignorieren. Die Definition des Concern-Begriffs soll folglich eine Aussage darüber machen, woher Concerns kommen, nämlich dass Concerns aus Anliegen oder Anforderungen von Beteiligten resultieren.
* Bezugspunkt
** Concerns werden nicht zum Selbstzweck definiert, sondern sind verbindliche Vorgaben für die Gestaltung eines Systems. Also soll die Definition des Concern-Begriffs auch eine Aussage treffen, worauf sich Concerns beziehen, in unserem Fall auf Software-Systeme. Im Sinne von Ramnivas Laddad (2003) ist ein Software-System nichts anderes als die Realisierung einer Menge von Concerns. Vorgaben, die sich nicht auf das System, sondern auf den Entwicklungsprozess beziehen (zum Beispiel Zeit- und Kostenvorgaben) sind in diesem Sinne keine Concerns.
Die Definition von Ramnivas Laddad wird hier favorisiert, da diese am prägnantesten Herkunft („Anforderung […], um die […] Systemziele zu erreichen“) als auch den Bezugspunkt („Software-System“) umfasst.

### Kategorisierung von Concerns

Es ist schwierig, den Concern-Begriff sinnvoll einzuordnen, da er nicht ganz exakt definiert ist und es vom Auftraggeber abhängt, was er als Anforderung (Concern) betrachtet und was nicht. Dies hat zur Folge, dass instabile Kategorien entstehen können, die sich in den jeweiligen Situation ändern. Aus diesem Grund wird von einer Kategorisierung mit Ausnahme der Aufteilung in Core Concerns und Crosscutting Concerns abgesehen.
Die folgende Kategorisierung zeigt auf, weshalb es problematisch ist, Concerns zu kategorisieren: Nach Joāo Araújo et al. (2002) gibt es quer schneidende Kernfunktionalitäten / Crosscutting Concerns auf der Anforderungsebene (zum Beispiel Sicherheit, Antwortzeit) und Crosscutting Concerns auf der Entwurfs-/Implementierungsebene aufgrund von technologischen Einschränkungen (zum Beispiel Synchronisation, Fehlerbehandlung). Die Grenze zwischen Anforderungen und Entwurfsentscheidungen ist fließend und hängt vom Auftraggeber ab. Abhängig davon, wie diese Grenze im Einzelfall gezogen wird, gehören die Concerns zur jeweiligen Kategorie an.

### Core Concerns und Crosscutting Concerns

Ramnivas Laddad (2003) unterscheidet zwischen Kernfunktionalitäten/Core Concerns und quer schneidende Kernfunktionalitäten / Crosscutting Concerns.

#### Definition Core Concerns

Realisieren die Kernfunktionalität eines Systems.

#### Definition Crosscutting Concerns

* Realisieren diejenigen Funktionen eines Systems, welche die Core Concerns (Kernfunktionalitäten) oder andere Crosscutting Concerns quer schneiden, beispielsweise Logging oder Authentisierung.
* Zwei Concerns sind „crosscutting“, wenn sich Methoden dieser Concerns schneiden (Tzilla Elrad et al., 2001).
Laut Tzilla Elrad u. a.(2001) sollte man immer berücksichtigen, dass Anforderungen (Concerns) immer nur relativ zu einer bestimmten Dekomposition „crosscutting“ sind.
Die Unterscheidung zwischen Core und Crosscutting Concerns ist nicht in allen Ansätzen gleichermaßen bedeutend. So werden beispielsweise in der Hyper/J und Multi-Dimensional Separation of Concerns (MDSOC) alle Concerns ausdrücklich gleich behandelt, und es wird nicht zwischen Kernfunktionalitäten und quer schneidende Kernfunktionalitäten unterschieden. Solche Ansätze werden auch symmetrisch genannt, während Ansätze, die zwischen Core Concerns und Crosscutting Concerns unterscheiden, asymmetrisch genannt werden.

### Separation of Concerns

Verschiedene Elemente der Aufgabe sollten möglichst in verschiedenen Elementen der Lösung repräsentiert werden.

### Scattering und Tangling
#### Definition Scattering

Eine einzelne Anforderung (Concern) wirkt sich auf mehrere Entwurfs- und Code-Module aus.
Scattering führt einerseits zu redundanten oder zumindest ähnlichen Code-Blöcken in allen betroffenen Modulen und damit leider zu einer schlechten Pflegbarkeit sowie zu einer hohen Fehleranfälligkeit bei Modifikationen. Anderseits ist es kaum möglich zu verfolgen, in welchen Modulen eine bestimmte Anforderung implementiert wurde.
Tangling ‚Durcheinander‘ bezieht sich auf ein einzelnes Modul und entsteht, wenn dieses Modul die Implementierungen mehrerer (Fragmente von) Concerns enthält. Peri Tarr et al. (1999) definierte wie folgt:

#### Definition Tangling

Code-Fragmente, die mehrere Anforderungen betreffen, sind in einem einzelnen Modul vermischt.
Tangling führt erstens zu schlecht lesbarem Code, was negative Auswirkungen auf die Pflegbarkeit und damit indirekt auch auf die Lebensdauer und die Wirtschaftlichkeit der Software hat. Zweitens sind von Tangling betroffene Module schlecht wiederverwendbar, da sie mehrere Fragmente der Concerns enthalten. Und drittens ist es schwierig bis unmöglich zurückzuverfolgen, welche Concerns ein bestimmtes Modul implementiert.