Software-Architekturen bedingen zur Implementierung der sogenannten Kernfunktionalitäten (Core Concerns) die Integration von Querschnittfunktionalitäten, die auch als Crosscutting Concerns bezeichnet werden. Deren Implementierung beschränkt sich nicht auf einzelne Komponenten, sondern ist auf viele Bereiche über das gesamte System verteilt. Somit werden völlig unterschiedliche Kernfunktionalitäten mit der Anwendung einer bestimmten Funktionalität konfrontiert.
Die Problematik der Crosscutting Concerns ist nicht neu - es gibt sie schon, seitdem es Software- Systeme gibt. Mit Crosscutting Concerns werden Funktionalitäten wie Authentifizierung, transaktionales Verhalten, verteilte Kommunikation oder Persistenz umschrieben. Insbesondere in größeren Projekten führt die Verwendung objektorientierter Mechanismen zu einer Kopplung zwischen Core- sowie Crosscutting Concerns. Dadurch beeinflusst werden Kriterien wie Wartbarkeit, Pflege und Wiederverwendbarkeit einer Software. Es gibt verschiedene Lösungsansätze zur Modularisierung von Crosscutting Concerns wie Design Patterns, Inversion oder die aspektorientierte Programmierung ( AOP).
Zunächst werden Concerns als spezifische Anforderungen bezeichnet, die im Zusammenhang mit einem Software-System behandelt werden. Dabei beschreiben Core Concerns die Kernfunktionalitäten eines solchen Systems. Crosscutting Concerns definieren hingegen allgemeine Aufgabe - auch Querschnittsaufgaben genannt - zur Behandlung grundlegender Anforderungen an ein Software-System, deren Funktionalität in mehreren Modulen wiederholt implementiert ist. Man spricht auch davon, dass Crosscutting Concerns die Core Concerns oder auch andere Crosscutting Concerns quer schneiden.
Beispiele für Crosscutting
Typische Beispiele für Crosscutting Concerns sind:
- Die Erfassung von Daten.
- Funktionen zum Reporting und zur Protokollierung.
- Die Prüfung der Integrität von Transaktionen.
- Die Prüfung von Fehlern.
- Sicherheit und Authentifizierung .
- Persistenz von Daten.
- Funktionen zur Steigerung der Performance.
Im Zusammenhang mit Crosscutting Concerns wird häufig auch von technischen Anforderungen gesprochen, oder das diese funktionalen Charakter haben. Nicht gleichzusetzten sind Crosscutting Concerns und Aspekte, hier sind Aspekte als implementierte Crosscutting Concerns zu definieren. Ebenso ist eine Verbindung der Begriffe Anforderung und Concerns zu vermeiden. Anforderungen sind eher als eine Spezifizierung von Concerns im Detail anzusehen. In der Literatur wird der Ansatz zur Trennung von Core- und Crosscutting Concerns auch als asymmetrisch bezeichnet.
Unterschiede des Crosscuttings
Beim Crosscutting werden unterschieden:
Dynamisches Crosscutting. Das Verhalten von Ob-jekten wird durch Hinzufügen weiterer Schritte in die Ausführung von Methoden modifiziert.
Statisches Crosscutting. Dieses modifiziert die Strukturen eines Programms. Möglichkeiten sind dazu sowohl durch die Anpassung der Vererbungshierarchie als auch durch Hinzufügen von weiteren Datenstrukturen und Methoden zu einer Klasse. Auch eine Initiierung zusätzlicher Überprüfungen der Übersetzung ist möglich.
Ein zentrales Prinzip des Software-Engineerings ist das von Dijkstra (1976) eingeführte Separation of Concerns - was allgemein eine Trennung der Anliegen bedeutet. Konkret im Zusammenhang mit Concerns erklärt es, dass ein Concern nur Teile einer Software für genau einen Verantwortungsbereich identifiziert, kapselt oder auch manipuliert. Gleichsam gilt dieses in Folge dessen auch für Crosscutting Concerns. Sowohl Core- als auch Crosscutting Concerns sind qualitativ hochwertig, wenn diese
- eine starke Kohäsion und schwache Kopplung haben,
- ihre Datenstrukturen und Methoden kapseln und
- ihre Details der Implementierung gegenüber anderen Concerns verdecken ( Information Hiding).
Das Prinzip setzt jedoch voraus, dass Concerns möglichst unabhängig voneinander spezifiziert sowie implementiert werden können, um dann letztendlich erst möglichst spät zu einem Gesamtsystem zusammengefügt zu werden. Das Problem dabei ist, dass die objektorientierten Programmiersprachen kein anderes Konstrukt außer den Klassen für die Modellierung von Crosscutting Concerns anbieten. Daraus ergeben sich die beiden folgenden typischen Probleme:
Code Tangling. Die Vermischung verschiedener Concerns in einem Modul - der gesamte Code ist in einer Klasse gekapselt.
Code Scattering. Crosscutting Concerns sind über mehrere Module verteilt - gleiche Funktionalität ist über verschiedene Klassen verteilt.
Das widerspricht neben dem Separation of Concern auch den Prinzipien der Kapselung sowie der funktionalen Dekomposition, womit die hierarchische Zerlegung eines Software-Systems in Teilfunktionen umschrieben wird.
Mögliche Lösungsansätze zur Modularisierung von Crosscutting Concerns können sein:
- Verwendung von Design-Pattern (Muster), beispielsweise das Observer-Pattern für Logging und Prüfung der Sicherheit, das Command-Pattern für Undo-/Redo-Mechanismen oder das Decorator-Pattern für die Anreicherung von Funktionalität.
- Inversion auf Control - das bedeutet die Indirektion des Kontrollflusses über einen Container (z.B. den EJB-Container) oder einen speziellen Interpreter. Auch die Anpassung des Verhaltens über sogenannte Metadaten ist dabei eine Möglichkeit.
- Aspektorientierte Programmierung - Modellierung der Crosscutting Concerns durch Aspekte.
Ein konkreter Ansatz hinsichtlich Crosscutting Concerns aus der Praxis soll hier noch kurz vorgestellt werden - das Framework Enterprise JavaBeans (EJB) der Firma Sun. Dabei werden in einem Applikationsserver Crosscutting Concerns für die sogenannten Enterprise Beans wie Ausfallsicherheit, Clustering, transaktionales Verhalten, Sicherheit und Persistenz von der EJB- Laufzeitumgebung zur Verfügung gestellt. Die Funktion setzt allerdings voraus, dass der Anwender die Kontrolle für all seine Komponenten an das Laufzeitsystem übergibt, und mit diesem über entsprechende Schnittstellen interagiert. Das Framework zielt speziell auf Client-Server-Architekturen.