Cross-cutting concern

from Wikipedia, the free encyclopedia
This article or section needs to be revised. Details should be given on the talk page. Please help to improve it , and then remove this flag.

Cross-Cutting Concern ( CCC ) is a term in computer science that, in the context of the divide-and-conquer principle, describes so-called cross - sectional issues of software, which cannot simply be modularized because conventional modularizationapproaches(especially object orientation ) do not work . In most cases, it is non-functional requirements for software, such as safety aspects, which are implemented across the entire code with conventional programming - for example, recurring checks of the form “may this code be executed?”. The Aspect-Oriented Programming (AOP) provides the ability to formulate such a code centrally. At the same time, rules must be given for how this code can be automatically woven in or executed in the right places.

The cost-effective and timely development and maintenance of high-quality software is the primary goal of software technology . In order to achieve this goal, software that is modularized as well as possible and with as little complexity as possible is necessary. In a conventional system, which also includes the object-oriented approaches, core functionalities can be neatly separated into modules according to the rules of the art. However, there are requirements such as error handling, performance and security in every system, which affect all core functionalities and therefore cannot be clearly assigned to a software module. As a result, fragments of such cross-sectional functions are not assigned due to a lack of cohesion and are scattered unencapsulated throughout the code. These requirements prevent proper modularization in conventional software systems and impair maintenance, comprehensibility, reusability and (re) traceability. With conventional programming languages, the system decomposition, which only allows one dimension, is responsible for this . In this context one speaks of dominant decomposition, i.e. H. a naturally multi-dimensional problem must be solved one-dimensionally.

Identification, separation and integration

Every aspect-oriented development process consists of the three basic phases identification, separation and integration:

ID

In the identification phase, the relevant core concerns and overarching requirements (cross-cutting concerns) are identified with the help of various processes.

Separation

The separation phase involves defining all concerns independently of one another, operationalizing them if necessary, designing them and implementing them in a modular manner. The key word here is Separation of Concerns and is traced back to Edsger W. Dijkstra (1976). Such modularly implemented core concerns ('core functionalities') are called components; modularly implemented cross-cutting concerns are referred to as aspects. Even in conventional approaches, there are certainly options for separating concerns (for example in the area of ​​non-functional requirements), but there they are limited to identification, specification and operationalization. In addition, the integration rules must be defined in the separation phase, according to which the concerns are later to be combined to form the overall system.

Although David Parnas does not explicitly mention the term in his essay On the Criteria To Be Used in Decomposing Systems into Modules (1972), the invention of the term Separation of Concerns is often ascribed to him in the literature.

integration

In the integration phase, the fully implemented components and aspects are combined to form the overall system using the integration rules. Especially in programming with aspect orientation, integration is referred to as weaving . In some approaches, the integration and composition is (English composition ) called what not with the same association in the Language Unified Modeling -Klassendiagramm must not be identified.

target

The aim of the aspect orientation is to delay the integration in the development process as long as possible. This also significantly differentiates the conventional approaches from the aspect-oriented approaches. With the conventional approaches, the integration takes place already in the design phase, because the corresponding programming languages have no possibilities to implement overlapping concerns in several dimensions. With the aspect-oriented approaches, the concerns remain separate even during the design and implementation phases and - depending on the approach - are combined at the time of translation or runtime. This offers the advantage that the individual aspects in the source code are still neatly modularized, which improves reuse, comprehensibility and (traceability).

Requirement

A cross-cutting concern is a requirement for a software product that must be complied with 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 rather represent additional or meta requirements.

This also poses a particular problem: in many software projects with a large number of employees, the developers concentrate primarily on the core functionality, while the implementation of cross-cutting concerns requires a great deal of adaptation and coordination.

Options for solving this problem are the selection of suitable software development processes , such as generative programming , the use of specific frameworks and languages ​​and the use of patterns such as mix-in classes or aspects .

Concerns

Definition of terms

Although the term Concern is more or less understandable, it is difficult to find a definition in the literature . The term is often not defined, but only introduced on the basis of enumerations, for example in Mehmet Aksits , Lodewijk Bergmans (2001): “ […] concerns, such as access control, synchronization […] ”.

  • Subject of consideration. High regard , usually due to a personal bond or relationship ( Merriam-Webster , 2004).
  • Any thing of interest in a software system ( Stan Sutton , Isabelle Rouvellou, 2002).
  • Any thing of interest in a system i.e. H. a goal or a set of properties that the system must fulfill ( Isabel Sofia Brito , Ana Moreira, 2004).
  • Relevant (English interest ) which the development or operation relates to a system, or any other aspect that (English for one or more of the parties stakeholder ) critical or otherwise is important (IEEE, 2000).
  • Specific requirement or point of view that must be dealt with in a software system in order to achieve the overarching system goals ( Ramnivas Laddad , 2003).
  • Relevant system goal at the highest level, which is usually derived from the client's critical business goals ( Ian Sommerville , Peter Sawyer , 1997).

The definitions do not contradict each other, but simply set different priorities. The most suitable definition is based on the following two characteristics:

  • origin
    • The meaning of the word concern 'requirements' indicates that concerns are something in which those involved in the creation of a system in general and the client in particular show interest, which concern them personally and therefore do not ignore them. The definition of the term concern is therefore intended to make a statement about where concerns come from, namely that concerns result from concerns or requirements of those involved.
  • Reference point
    • Concerns are not defined as an end in themselves, but are binding specifications for the design of a system. So the definition of the concern term should also make a statement as to what concerns refer to, in our case software systems. In the sense of Ramnivas Laddad (2003), a software system is nothing more than the realization of a set of concerns. Specifications that do not refer to the system but to the development process (e.g. time and cost specifications) are not concerns in this sense.

The definition of Ramniva's Laddad is favored here, as it includes the most concise origin (“Requirement [...] to achieve the [...] system goals”) and the reference point (“software system”).

Categorization of concerns

It is difficult to classify the concept of concern in a meaningful way, as it is not exactly defined and it depends on the client what he regards as a requirement (concern) and what not. As a result, unstable categories can arise that change in the respective situation. For this reason, there is no categorization with the exception of the division into core concerns and crosscutting concerns.

The following categorization shows why it is problematic to categorize concerns: According to Joāo Araújo et al. (2002) there are crosscutting core functionalities / crosscutting concerns on the requirement level (e.g. security, response time) and crosscutting concerns on the design / implementation level due to technological restrictions (e.g. synchronization, error handling). The line between requirements and design decisions is fluid and depends on the client. Depending on how this limit is drawn in each individual case, the concerns belong to the respective category.

Core concerns and crosscutting concerns

Ramnivas Laddad (2003) differentiates between core functionalities / core concerns and cross-cutting core functionalities / crosscutting concerns.

Definition of core concerns

Realize the core functionality of a system.

Definition of crosscutting concerns

  • Realize those functions of a system that cut across the core concerns or other crosscutting concerns, for example logging or authentication .
  • Two concerns are “crosscutting” if the methods of these concerns intersect ( Tzilla Elrad et al., 2001).

According to Tzilla Elrad et al. (2001) one should always take into account that requirements (concerns) are always only "crosscutting" relative to a certain decomposition.

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

Separation of Concerns

Different elements of the task should be represented in different elements of the solution, if possible.

Scattering and Tangling

Definition of scattering

A single concern affects multiple design and code modules.

Scattering leads, on the one hand, to redundant or at least similar code blocks in all affected modules and thus unfortunately to poor maintainability and a high susceptibility to errors in modifications. On the other hand, it is hardly possible to track in which modules a certain requirement has been implemented.

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

Definition of tangling

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

Tangling firstly leads to badly readable code, which has negative effects on the maintainability and thus indirectly on the service life and cost-effectiveness of the software. Second, modules affected by Tangling are difficult to reuse because they contain several fragments of the concerns. Third, it is difficult if not impossible to trace which concerns a particular module implements.

literature

  • 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. October 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, GC Murphy: Explicit Programming, in: Proceedings of the 1st International Conference on Aspect-Oriented Software Development (AOSD 2002). ACM Press, Enschede, The Netherlands 2002, 10-18
  • SR Chidamber, CF 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, BA 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, RJ 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, RJ 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, CA,
  • A. Bader, TH Elrad, ME 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
  • JA Diaz Pace, MR Campo: Analyzing the Role of Aspects in Software Design. In: Communications of the ACM. October 2001, Vol. 44, No. 10, 67-73
  • EW Dijkstra: Go To Statement Considered Harmful. In: Communications of the ACM. March 1968, Vol. 11, No. 3, 147-148
  • EW Dijkstra: A Discipline of Programming. Prentice Hall, Englewood Cliffs, New Jersey 1976
  • T. Elrad, RE Filman, A. Bader, Guest Editors: Aspect-Oriented Programming. In: Communications of the ACM. October 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. October 2001, Vol. 44, No. 10, 33-38
  • E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design patterns, elements of reusable object-oriented 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, WG Griswold: An Overview of AspectJ. In: Proceedings of the 15th European Conference on Object-Oriented Programming (ECOOP 2001). Springer-Verlag, Budapest, Hungary 2001, Lecture Notes in Computer Science 2072, 327–353
  • G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, WG Griswold: Getting Started with AspectJ. In: Communications of the ACM. October 2001, Vol. 44, No. 10, 59-65
  • R. Klösch, H. Gall: Object-oriented reverse engineering: from classic to object-oriented 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. October 2001, Vol. 44, No. 10, 39-41
  • GC Murphy, RJ Walker, ELA Baniassad, MP Robillard, A. Lai, MA Kersten: Does Aspect-Oriented Programming Work? In: Communications of the ACM. October 2001, Vol. 44, No. 10, 75-77
  • P. Netinant, T. Elrad, ME 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: Object-oriented software development, analysis and design with the Unified Modeling Language. Oldenbourg Verlag, Munich Vienna 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. October 2001, Vol. 44, No. 10, 43-50
  • DL Parnas: On the Criteria To Be Used in Decomposing Systems into Modules. In: Communications of the ACM. December 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: Modularization 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. 6th edition, Pearson Studium, Munich 2001, ISBN 3-8273-7001-9
  • GT Sullivan: Aspect-Oriented Programming Using Reflection and Metaobject Protocols. In: Communications of the ACM. October 2001, Vol. 44, No. 10, 95-97
  • JJ Sung, K. Lieberherr: DAJ: A Case Study of Extending AspectJ, Technical Report, UCCS-02-16. Northeastern University, Boston, Massachusetts, USA 2002
  • SM 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, The Netherlands 2002, 127-133
  • P. Tarr, H. Ossher, W. Harrison, SM 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

Web links