MENTAL
 Main Menu
 Applications
 Computer Science
 Aspect-Oriented Programming

Aspect-Oriented Programming
 ASPECT-ORIENTED
PROGRAMMING

"An aspect is a modular unit which is disseminated by the structure of other functional units" (Gregor Kickzales)

"Aspect-Oriented Programming deals with cross-cutting themes and descriptions, design and implementation of these themes" (Karl Lieberherr).

"Meta-objects seem to be a natural place to implement aspects" (Charlotte Pii Lunau).


Aspect-Oriented Programming (AOP)

When designing a software system, we are forced to choose a main paradigm (or dominant conceptual dimension) of modular type (object, functional, procedural, etc.). This is the so-called "tyranny of the dominant decomposition". But there are code fragments that are scattered in the system modules and that constitute cross-cutting functional units (cross-cutting concerns). These are called "aspects". An aspect of a program or code is a modular unit of the program that is scattered in other modular units of the program.

The −AOP− is a new programming paradigm that aims to collect these cross-cutting functionalities into centralized add-on modules. An aspect is a cross-cutting functionality that is implemented modularly and separately from the rest of the system.

AOP does not affect the core functionality of a system, but facets of its behavior: collateral or cross-cutting issues, properties or areas, which affect all components of that system, regardless of their structure or functional dependency on each other. The AOSD (Aspect Oriented Software Development) website defines AOP as "A programming paradigm in which the cross-cutting issues that permeate a system are isolated and extracted into separate modules called aspects." The implementation of the AOP paradigm consists of:
Types of aspects

There are different types or categories of aspects. They can be low-level or high-level. They can be functional or non-functional. They can be design or implementation. Some examples are: Persistence −the storage and retrieval of an application's data in secondary storage− is a typical example of a cross-cutting theme or aspect. An application can be developed without considering the persistence issue and address it at a later stage. This approach has the advantage that, if the storage type is changed, it is sufficient to change only the persistence module, without the need to change the functionality of the system. The same advantage applies to the other aspects.


Advantages of AOP

The application of paradima AOP has many advantages:
Implementation of the AOP

The traditional solution is to repeat the corresponding code in the different modules that need it, because there was no way to encapsulate in a single module something that cut across multiple modules in the system. The result was tangled code.

Today, AOP is implemented by the following components:
  1. A base (general purpose) language to define the basic functionality.

  2. One or more aspect-oriented languages, which can be:

    1. Specific.
      These are special languages to deal with different concrete aspects in concrete domains. These languages usually impose restrictions on the use of the base language to ensure its correct use. Examples: COOL (Concurrent Object Oriented Language), RIDL (Reliable Interface Design Language), etc.

    2. General.
      They are valid languages for all kinds of aspects. They are more open and it is the responsibility of the programmer to use them correctly. Examples: AspectJ (a Java extension), AspectC++ (a C++ extension), etc.

  3. Join Points.
    They are defined in the base application and indicate the locations where the aspects are to be applied.

  4. PointCuts.
    The set of conditions necessary for an aspect module to be executed at a junction point.

  5. Execution Points (Execution Points).
    These are the modules that are executed when a cut point is activated at a junction point.

  6. Advices.
    These are the actions that are executed at each junction point and triggered by the corresponding cut points.

  7. Weaver of aspects.
    It is responsible for interlinking the base language with the aspect languages through junction points, generating a complete program. The interlinking can be static (at compile time) or dynamic (at run time).

Decomposition of a system by aspects

A software system admits several possible decompositions, according to the different aspects to be considered. But, according to the main functionality that you want to assign to it, there is a dominant decomposition.

If the main functionality and those corresponding to the aspects were integrated into a single decomposition, the result would be somewhat chaotic, since the processing code for each aspect would be scattered throughout the code, with the resulting complexity.

The solution to this problem consists of:
  1. Replacing the classical decomposition of a system into conceptual blocks (functions, procedures, objects, etc.) by the aspectual decomposition, where the classical decomposition is really another aspect, although it is the main one.

  2. Program the aspectual process independently, in the form of components or modules, in order to achieve more clarity.

  3. Link the main process with the processes of the different aspects.

History of the AOP

The AOP paradigm has been the result of the convergence of several independent lines of research that began with the fundamental principle of modular software decomposition, pioneered by Edsger Dijkstra and David Parnas.
Aspects Implementation in MENTAL

With MENTAL everything is simplified and clarified:
Examples
  1. We want to know how many successive values the variable x takes along the execution of a program.

    ⟨( (nvals := 0) // initial number of values

    (x=v → ( (nvals=0 ∨ (nvals > 0 ∧ (xvals(nvals) ≠ v)))))) →
    ((nvals = nvals+1)
    ((xvals(nvals) = v)) ) ) )⟩

  2. We want to restrict all sequences to be of a certain length n at most.

    ⟨( ((x = ( x↓ )) ∧ (x# > n)) → // if x is a y-sequence of length > n

    ((m = x#) [x{[n+1...m] = θ] )⟩ // remove overflows

  3. Concurrent process structure.
    The processes p1 and p2 must be started simultaneously when the condition k=1 is met, and when both are finished, the process p3 must be executed.

    ⟨( (k = 1) → ((k = 0) ({p1 p2} p3)) )⟩

    The restoration of the variable k is important so that the condition is not fulfilled again.

Addenda

Related techniques

Many programming techniques include concepts similar to those of aspect-oriented programming such as:
Reflective Systems

A reflective module is a module that sits at a higher level (target level) from which it observes what happens at the base level and makes decisions. It can even modify the base code. It is also called "computational reflection" [Maes, 1987]. In traditional computational reflection, a base level object has at most one meta-object.


Adaptive programming

An object-oriented software design and development methodology that is evolutionary, i.e., incremental, progressive, and incremental.

The design is made from a brief initial specification, of informal type, in which the objects and the operations are separated. The objective is to maintain as loose a coupling as possible between objects and operations, so that modifications to one part have minimal impact on the others.

The software is not developed directly at the object level, but at such a level that it can be easily adapted to a wide variety of contexts. The result is more flexible, more compact and more intelligible software.

An adaptive program consists of n parts a1, ..., an, where each part ai expresses an aspect as independent as possible from the rest. The executable program is specified by a function c of combinatorial type between those n parts: c(a1,…,an).

The Demeter group has been the pioneer of Adaptive Programming. The so-called "Demeter law" was announced in 1987. This law was later improved by Karl Lieberherr in the context of Aspect-Oriented Programming.

Adaptive Programming is now considered to be a special case of Aspect-Oriented Programming.


Subject-Oriented Programming.

It is a programming technique that complements OOP to solve the problems of interoperability, cooperation and integration of applications.

Systems are modularized by initially considering topics or aspects, both static and dynamic (error detection and management, persistence, etc.). Objects and applications are built from these modules. Aspect modules come into action with events of the type "before" or "after" an operation. The "Join Points" are thus realized at the operation level, as opposed to the classical approach, which are at the statement level.

Topic Oriented Programming was pioneered at IBM by Harold Ossher and Hill Harrison.

Topic-Oriented Programming is now considered to be a form of implementation of Aspect-Oriented Programming.


Bibliography