Aspects are used in software engineering in the context of aspect-oriented programming( AOP), and the following definitions fit into this context. Aspects provide a solution to crosscutting concerns - that is, functionality that is needed repeatedly across module boundaries in different components. Therefore, aspects generally do not result from a decomposition - also called decomposition - of core functionalities (core concerns) into classes, data, processes, or functions. Essential characteristics of aspects are that they are free of side effects and reusable.
For the better distinction and in reference to the aspect-oriented programming languageAspectJ is differentiated into static and dynamic aspects. Static aspects are processed by the compiler while dynamic aspects are controlled by the runtime environment. Aspects can be categorized depending on their use, for example business aspects or security aspects. In connection with the integration of aspects into a software one speaks also of the fact that aspects are "woven in".
Crosscutting Concerns are those functionalities of a software system which "crosscut" its core functionalities across modules. These can be, for example, functions for security, performance or error handling. Typical applications are also procedures for authorization and logging. These modularly implementable Crosscutting Concerns are called aspects. In addition components result then from implemented core Concerns. The principle of the separation of the Concerns goes back to Edgar Dijkstra, who called it Separation of Concerns. This principle of separation must be used thus, in order to work out the system characteristics, which can be woven then as a separate module in the form of aspects by the remaining system.
In the research concerning aspects, their backgrounds, structure and use, quite different definitions of aspects have emerged. There aspects are
- are restrictively called functional units, which are then woven by the system behavior,
- software products for the treatment of Concerns called, and which are linked in the ideal case automated with basis modules to a then complete application and
- referred to as properties that "tend" to cross-cut functional components.
These definitions are more or less precise, so that here further of aspects in the sense of modules and implemented Crosscutting Concerns one speaks. Therefore also at this point some general characteristics of aspects are to be summarized in the following:
- Aspects have a modular structure.
- Aspects crosscut other aspects and components.
- Aspects must be free from side effects and thus should not change the state of a system.
- Aspects are to be in such a way conceived that they are reusable.
- Aspects always execute the same actions i.e. they must be homogeneous.
- Aspects may have no dependence on other aspects.
- Aspects are to be transparent from view of the components, which they cross.
- Aspects and components are to be to be combined flexibly with one another, one speaks here also of symmetry.
For a better modularization of the underlying criteria aspects can be categorized as in the following exemplarily pointed out.
Error handling aspects Can be used, for example, to avoid errors during translation.
Business aspects For compliance with company-specific rules.
Logging aspects Store the history of activities and have different ways of application: Error logging, profiling, tracing, or auditing.
Concurrency aspects Support the control of concurrent processes, such as synchronizing processes.
Optimization aspectsCaching and pooling aspects can be classified under this, which then enable the multiple use of resources (e.g. threads, connections, memory). The resources are managed in a central pool( cache), from where they can then be requested by processes
Security aspects Here, establishing the identity of a user( authentication) and ensuring access authorization (authorization) can be classified. Many considerations have been made as to when a requirement for software should be designed as an aspect and when as a component. Essential is in view of it that the implementation of an aspect is independent first of all of whether this requirement is functional or non-functional. The decisive factor is rather that such a requirement can be traced back to a core functionality and whether it is also "crosscutting".
Aspects are thus crosscutting concerns implemented in modules.