Cross-Cutting Concern – Wikipedia

Dieser Artikel oder Abschnitt bedarf einer grundsätzlichen Überarbeitung. Näheres sollte auf der Diskussionsseite angegeben sein. Bitte hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

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.

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

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

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.

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 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.

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.

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.

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.

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

Realisieren die Kernfunktionalität eines Systems.

• 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.

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

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:

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.

• J. Araujo, J. Whittle, D.-K. Kim: Modeling, Composing and Validating Scenario-Based Requirements with Aspects. In: Proceedings of the 12th IEEE International Requirements Engineering Conference. Kyoto, Japan 2004
• L. Bergmans, M. Aksit: Composing Crosscutting Concerns using Composition Filters. In: Communications of the ACM. Oktober 2001, Vol. 44, No. 10, 51–57
• A. Black, N. Hutchinson, E. Jul, H. Levy: Object Structure in the Emerald System. In: Proceedings of the Object-Oriented Programming Systems, Languages and Applications (OOPSLA’86). ACM Press, Portland, Oregon, USA 1986, 78–86
• A. Bryant, A. Catton, K. De Volder, G. C. Murphy: Explicit Programming, in: Proceedings of the 1st International Conference on Aspect-Oriented Software Development (AOSD 2002). ACM Press, Enschede, Niederlande 2002, 10–18
• S. R. Chidamber, C. F. Kemerer: A Metric Suite for Object Oriented Design. In: IEEE Transactions on Software Engineering. Vol. 20, Issue 6. IEEE Press, Piscataway, New Jersey, USA 1994, 476–493
• L. Chung, B. A. Nixon, E. Yu, J. Mylopoulos: Non-functional Requirements in Software Engineering. Kluwer Academic Publishers, Boston, Dordrecht, London 2000
• S. Clarke, W. Harrison, H. Ossher, P. Tarr: Subject-Oriented Design: Towards Improved Alignment of Requirements, Design and Code. In: Proceedings of the Object-Oriented Programming Systems, Languages and Applications (OOPSLA’99). Denver, Colorado, USA 1999, 325–339
• S. Clarke, R. J. Walker: Separating Crosscutting Concerns Across the Lifecycle: From Composition Patterns to AspectJ and Hyper/J, Technical Report, TCD-CS-2001-15 and UBC-CS-TR-2001-05. Trinity College, Dublin, Ireland, and University of British Columbia, Vancouver, Canada 2001
• S. Clarke, R. J. Walker: Composition Patterns: An Approach to Designing Reusable Aspects. In: Proceedings of the 23rd International Conference on Software Engineering (ICSE 2001). IEEE Computer Society Press, Toronto, Ontario, Canada 2001, 5–14 Constantinides, C.A.,
• A. Bader, T. H. Elrad, M. E. Fayad, P. Netinant: Designing an Aspect-Oriented Framework in an Object-Oriented Environment. In: ACM Computing Surveys (CSUR). Vol. 32, Issue 1es, ACM Press 2000, Article No. 41
• J. A. Diaz Pace, M. R. Campo: Analyzing the Role of Aspects in Software Design. In: Communications of the ACM. Oktober 2001, Vol. 44, No. 10, 67–73
• E. W. Dijkstra: Go To Statement Considered Harmful. In: Communications of the ACM. März 1968, Vol. 11, No. 3, 147–148
• E. W. Dijkstra: A Discipline of Programming. Prentice-Hall, Englewood Cliffs, New Jersey 1976
• T. Elrad, R. E. Filman, A. Bader, Guest Editors: Aspect-Oriented Programming. In: Communications of the ACM. Oktober 2001, Vol. 44, No. 10, 29–32
• T. Elrad, M. Aksit, G. Kiczales, K. Lieberherr, H. Ossher, Panelists: Discussing Aspects of AOP. In: Communications of the ACM. Oktober 2001, Vol. 44, No. 10, 33–38
• E. Gamma, R. Helm, R. Johnson, J. Vlissides: Entwurfsmuster, Elemente wiederverwendbarer objektorientierter Software. Addison-Wesley 1996, ISBN 3-8273-2199-9.
• G. Georg, I. Ray, R. France: Using Aspects to Design a Secure System. In: Proceedings of the 8th International Conference on Engineering Complex Computing Systems (ICECCS 2002). ACM Press, Greenbelt, Maryland, USA 2002, 117–128
• J. Grundy: Aspect-oriented Requirements Engineering for Component-based Software Systems. In: Proceedings of the 4th IEEE International Symposium on Requirements Engineering (RE 1999). IEEE Computer Society Press, Limerick, Ireland 1999, 84–91
• G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J.-M. Loingtier, J. Irwin: Aspect-Oriented Programming. In: Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP 1997). Springer-Verlag, Jyväskylä, Finland 1997, Lecture Notes in Computer Science 1241, 220–242
• G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, W.G. Griswold: An Overview of AspectJ. In: Proceedings of the 15th European Conference on Object-Oriented Programming (ECOOP 2001). Springer-Verlag, Budapest, Ungarn 2001, Lecture Notes in Computer Science 2072, 327–353
• G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, W.G. Griswold: Getting Started with AspectJ. In: Communications of the ACM. Oktober 2001, Vol. 44, No. 10, 59–65
• R. Klösch, H. Gall: Objektorientiertes Reverse Engineering: Von klassischer zu objektorientierter Software. Springer-Verlag, Berlin, Heidelberg 1995, ISBN 3-540-58374-2.
• R. Laddad: AspectJ in Action, Practical Aspect-Oriented Programming. Manning Publications Co., 2003
• K. Lieberherr, D. Orleans, J. Ovlinger: Aspect-Oriented Programming with Adaptive Methods. In: Communications of the ACM. Oktober 2001, Vol. 44, No. 10, 39–41
• G. C. Murphy, R. J. Walker, E. L. A. Baniassad, M. P. Robillard, A. Lai, M. A. Kersten: Does Aspect-Oriented Programming Work? In: Communications of the ACM. Oktober 2001, Vol. 44, No. 10, 75–77
• P. Netinant, T. Elrad, M. E. Fayad: A Layered Approach to Building Open Aspect-Oriented Systems. In: Communications of the ACM. October 2001, Vol. 44, No. 10, 83–85
• M. Nishizawa, S. Chiba, M. Tatsubori: Remote Pointcut – A Language Construct for Distributed AOP. In: Proceedings of the 3rd International Conference on Aspect-Oriented Software Development (AOSD 2004). ACM Press, Lancaster, UK 2004, 7–15
• B. Oestereich: Objektorientierte Softwareentwicklung, Analyse und Design mit der Unified Modeling Language. Oldenbourg Verlag, München Wien 2001, ISBN 3-486-27266-7.
• D. Orleans, K. Lieberherr: DJ: Dynamic Adaptive Programming in Java. In: Proceedings of the 3rd International Conference on Meta-level Architectures and Separation of Crosscutting Concerns (Reflection 2001). Springer Verlag 2001, Kyoto, Japan, 73–80
• H. Ossher, P. Tarr: Using Multidimensional Separation of Concerns to (Re)Shape Evolving Software. In: Communications of the ACM. Oktober 2001, Vol. 44, No. 10, 43–50
• D. L. Parnas: On the Criteria To Be Used in Decomposing Systems into Modules. In: Communications of the ACM. Dezember 1972, Vol. 15, No. 12, 1053–1058
• A. Rashid, P. Sawyer, A. Moreira, J. Araujo: Early Aspects: A Model for Aspect-Oriented Requirements Engineering. In: Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE 2002). IEEE Computer Society Press 2002, Essen, Germany, 199–202
• A. Rashid, A. Moreira, J. Araujo: Modularisation and Composition of Aspectual Requirements, in: Proceedings of the 2nd International Conference on Aspect-oriented Software Development (AOSD 2003). ACM Press 2003, Boston, Massachusetts, USA, 11–20
• A. Rashid, R. Chitchyan: Persistence as an Aspect. In: Proceedings of the 2nd International Conference on Aspect-Oriented Software Development (AOSD 2003). ACM Press 2003, Boston, Massachusetts, USA, 120–129
• I. Sommerville: Software Engineering. 6. Auflage. Pearson Studium, München 2001, ISBN 3-8273-7001-9.
• G. T. Sullivan: Aspect-Oriented Programming Using Reflection and Metaobject Protocols. In: Communications of the ACM. Oktober 2001, Vol. 44, No. 10, 95–97
• J. J. Sung, K. Lieberherr: DAJ: A Case Study of Extending AspectJ, Technical Report, UCCS-02-16. Northeastern University, Boston, Massachusetts, USA 2002
• S. M. Sutton Jr., I. Rouvellou: Modeling of Software Concerns in Cosmos. In: Proceedings of the 1st International Conference on Aspect-Oriented Software Development (AOSD 2002). ACM Press, Enschede, Niederlande 2002, 127–133
• P. Tarr, H. Ossher, W. Harrison, S.M. Sutton Jr.: N Degrees of Separation: Multi-Dimensional Separation of Concerns. In: Proceedings of the 21st International Conference on Software Engineering (ICSE 1999). IEEE Computer Society Press, Los Angeles CA 1999, 107–119

• L. Bergmans, M. Aksit: Composing Multiple Concerns Using Composition Filters. 2001; abgerufen am 24. Juli 2004
• Peri Tarr u. a.: Multi-Dimensional Separation of Concerns: Software Engineering using Hyperspaces.