The Object Orientation is consolidated. However, not all the promises that this paradigm is proposed to meet were, in fact, met. Some solutions have been proposed in an attempt to meet these outstanding promises, including the Orientation aspects.
Aspect Orientation (AO) is a paradigm that extends the Object Oriented (and others, like the structured paradigm) introducing new abstractions. These new elements are intended to cover deficiencies in the representation capacity of some situations.
Interests and Aspects
One of the central elements of AO is the concept of interest, which are the relevant characteristics of an application. An interest can be divided into a number of aspects that represent the requirements. Aspects can be grouped in the application, composing the functional interests, which form the business logic. Alternatively, they can be grouped into elements providing support to functional interests appointed by systemic interests, and also called orthogonal or cross interests.
When two properties must be made up differently and still coordinate, it is said that they are orthogonal to each other. The attemp to implement a systemic interest in the application of Object Orientation, results in a code that spread throughout the program. For this wse give the name of Scattering Code.
The scattering code can be classified into:
- Duplicated block;
- Additional block.
The implementation of various systemic and functional interests in the same module with the object orientation results in the code called entanglement (Tangled Code). The scattered and tangled codes difficult to maintain and reuse code at all.
Christina von Flach G. Chavez, an important brazilian researcher in AOP (Aspect Oriented Programming), said that the development of a new software engineering paradigm often progresses programming the methodology toward the design methodologies and analysis, providing a full path for the software development life cycle, and thus reaching maturity. The aspect-oriented programming (AOP) after a decade of research lies at this point, resulting in efficient tools, a community of skilled users and applications starting their path to market.
Current paradigms (such as OOP) do not meet the needs for the implementation of the requirements of a complete system without that part of the concepts of these paradigms that are broken. In an attempt to solve these problems, the aspects oriented -development emerges, promoting advanced separation of perspectives, from the level of implementation to the other stages of the development process, including requirements specification, analysis and design.
In this context, one of the creators of the AOP, Gregor Kiczales suggests that to a programming paradigm achieve broad acceptance, it needs to be expressive, efficient, intuitive, consistent and have a good tool that supports it. AOP already has these features, as we will see from now.
What is aspect-oriented programming?
The aspect-oriented programming was created in the late 1990s, more precisely in 1997 in Palo Alto at the Xerox laboratories, by Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Videira Lopes, Jean-Marc Loingtier and John Irwin. The goal was to build an approach that was set not necessarily homogeneous, which would allow the programming language, consisting of core language and various domain specific languages, to express optimally the systemic features (also called orthogonal or transverse) of the program behavior. This approach is called meta-programming.
One way to characterize a meta-programming language is by its compiler. At first, the compilers for the guidance aspects do not generate a final product (a compiled and executable - or interpretable - program), but a new code. In this first compilation, we add some elements to the code, to support new abstractions. The resulting code needs to be recompiled to be then generated the final product. Another feature of this meta-programming in the AOP is the computational reflection, in which part of the generated code is designed to change features of the program itself.
The AOP extends other techniques such as OOP or structured programming, suggesting not only a functional, but also a systemic decomposition of the problem. This allows the implementation of a system to be separated into functional and non-functional aspects providing the abstraction for the decomposition of the systemic interest in addition to features already offered by the components languages such as Java, for example.
Solving old problems
The main objective of the AOP is to separate the business code of the system from the crosscutting concerns, in a well-defined and centralized way. As seen previously, interests are the relevant characteristics of an application. An interest can be divided into a number of aspects that represent the application requirements. The aspects which can be grouped in the application make up the functional interests, also referred to as business logic.
The separation and centralization favored by AOP are indicated in Figure 1. Gregor Kiczales, in the article that launched the AOP in the academic world, makes that goal very clear. He noted that the languages of the time could do a great job of representing one of the many facets of a system. However, by the other hand, the result was always only satisfactory or even tolerable. We can cite as an example the C language family (including C++). Their work in dealing with hardware features is commendable, so that many drivers for hardware present in the market today were developed in that language. When dealing with persistence in the database, for example, it requires a dull job. As a result, the results are difficult codes to be reused, code intelligibility difficulty, etc.
Figure 1. Separation of concerns with AOP.
The aspects orientation works in parallel with another paradigm thus the concepts taught, for example, in object-orientation, are widely replicable. AOP allows a higher level of abstraction in software development. This higher level of abstraction and, consequently, the separation clearly defined for each of the components consist of the fundamental principle of software engineering, as they will be in a well defined place in the system. In Figure 1, each cloud is a systemic interest implemented in the system, such as auditing (log), exception handling, persistence, distribution, among others. Because they are well separated and in well-defined locations, components can be reused better and their maintenance and readability become more enjoyable.
By providing mechanisms for decomposition not only of elements and relationships relevant to the problems, but also to separate systemic interests, AOP promises to simplify software engineering. For example, a class for implementation of products control, as shown in Figure 2, serves only one interest, not breaking any concept of object orientation.
Figure 2. Product class
Later, we have the need for implementation of audit control (log). Without using AOP, the interest would be implemented in its own Product class, as shown in Figure 3. If it were necessary to implement the exception controling, this would also be done together in the class, as shown in Figure 4. The consequence is a gradual increase in the complexity of the code.
Figure 3 - Audit control implementation with OO
Figure 4. Exception control of Product class
In the aspect-oriented programming, interests are programmed in separate modules (classes and aspects, for example). After programming, we have the combination of classes and aspects, as shown in Figure 5. This leads to the simplification of the problem, because the developer can focus on each interest independently.
Figure 5. Combination of the Product class and other interests
Composition of an Aspect-oriented system
- Eduardo Piveta (2001) states that a system that uses aspect-oriented programming consists of the following components:
- Language Component: The language components must allow the programmer to write programs that implement the basic functionality of the system, while they do not provide anything about what must be implemented in the aspects language.
- Language aspects: The language aspects should support the implementation of the desired properties in a clear and concise manner, providing necessary buildings for the programmer to create structures that describe the behavior of the aspects and define situations in which they occur;
- Combiner aspects: The task of the combiner aspects (aspect weaver) is to combine the programs written in language components with the writings on aspects language. It is common to approach the Java language as a language of components and AspectJ aspects as a language;
- Programs written in the language components: The components may be considered the functional units of the system. A system for banking control can be defined as components customers, accounts, employees, among others. In the context of aspect-oriented programming, the components are abstractions provided by the language, which allows implementation of system functionality;
- Programs written aspects language may address systemic interests.
The composition of a aspect-oriented program is exemplified in Figure 6, showing the component programs written in the language, the language aspects, programs written in aspects language and the Aspectual Combiner.
Figure 6. Composition of a system-oriented aspect.
The aspectual combination is the process responsible for combining the elements written in language components with the elements written on the aspects language. It is a process that precedes the compilation, generating an intermediate code in the language components capable of producing the desired operation or allow its achievement during program execution.
The classes for the business code in systems do not change to support aspect-oriented programming. This is done at the time of the combination of the components and aspects. This process can also be defined as aspectual recompilation.
The aspectual combination can be:
- Static: An aspect-oriented system using static combination can bring agility to it, since there is no need for aspects existing at compile and execution time. The use of a static combination prevents an additional abstraction level to cause a negative impact on the system performance.
- Dynamic: In order to have the combination dynamic is essential that aspects exist both at compile time and at run time. Using a reflective interface, the combiner aspects have the ability to add, remove and adapt aspects at runtime.
The combiner uses aspects and components to create a new code. One development environment hypotheticaly oriented by aspects can combine the aspects of similar classes to one, the codes generated at the end of development of a system process prior to being compiled would be similar both in object-oriented as in aspects.
Fundamental orientation concepts to aspects
The orientation aspects has four basic concepts that will be covered in the following sub-topics.
Junction Points (join points)
Junction points are well-defined locations of the execution of a program, for example, a call to a method, or the occurrence of an exception, among many others.
From the junction points, the rules will lead to the points of action are created. All junction points have an associated context. For example, the call to a method has a calling object, the target object and method arguments available as context.
Performance points (pointcuts)
Action points are program elements used to define a junction point, as a kind of rule created by the programmer to specify events that will be assigned to the junction points.
The points of action aim to create generic rules to define which events are considered junction points without defining them individually (which would make the AOP almost meaningless). Another function of the action points is to present data from the execution context of each junction point, which will be used for routine triggered by the occurrence of the junction point mapped to the point of action.
After identifying the junction points to a particular interest, you need to group them into a set point. The combination of the junction point of action becomes apparent and the occurrence of systemic interest since this interest will most likely propagated in different classes in the system, and these classes are thus implementing more than one interest.
Advices are pieces of implementation of one aspect performed in well-defined points of the main program (junction points). The Advices are composed of two parts: the first is the set point, which defines the harvest rules of the junction points; the second is the code that will run when there is the junction point defined by the first part. The addendum is a very similar mechanism to a method (when compared to the object-oriented programming), whose function is to declare the code that must run every junction point in a set point.
The properties of a system involving several functional components can not be expressed using the notation and the current language and a localized manner. Properties such as synchronization, interaction between components, distribution and persistence are expressed in code fragments scattered by various components of the system.
One aspect is the mechanism available for aspect-oriented programming to group code fragments related to non-functional components in one unit in the system. To develop a calendar system could be related the following interests to be implemented:
- Contact Manager
- Commitments Manager
- Data persistence
- Access control
- Audit (log), among others
The example cited, the interests for access control, audit operations and data persistence are needed, but not related to the business. If one of these interests was implemented using only the techniques of object orientation, there would tangle and scattering code, as shown in Figure 7, where the vertical bars represent the system of classes and traits, the occurrence of code for implementation of interest .
In programming aspect-oriented, those not related to business interests, called systemic interests are grouped in areas, preventing the spread and tangled code. Thus, the aspect can not exist in isolation for implementing the system of interests (both functional and systemic). The objects continue to exist and in them the functional interests are implemented. Already in the aspects are systemic interests treated. We can define then that the couple aspect object is the main unit in a program oriented aspects, and the object would be the principal in a program oriented to objects.
Figure 7. Occurrence of tangled code
Where and why to apply the guidance aspects
The AOP contributes to the implementation of systemic interests, which, although not inherent to the business, are, in most cases, indispensable for the success of the application. Through the use of orientation aspects, these interests can be grouped into modular units, making maintenance simpler and easier reuse to reduce the interdependence of interests. A review of the list of systemic interests, from the perspective of the AOP, would be as follows:
- Synchronization of concurrent objects: the AOP provides an effective mechanism to modularize the synchronization policy.
- Distribution: with programming aspect-oriented, you can make the transparent distribution through the creation of an aspect intended to represent that interest, making it unnecessary to refactoring. The aspect distribution maps all interest, through Aspectual combiner is generated code distribuívelâ? similar to what would be re-factored code, as shown in Figure 8.
- Exception Handling: Through the use of AOP is possible to centralize the policy exception handler for basic units, which facilitates both maintenance and readability of classes as to approach to exception handling.
- Coordination of multiple objects: The AOP allows modularizing logic designed to synchronize the integration of active objects in search of a global goal.
- Persistence: By using aspects can centralize and abstracting the implementation of this interest business layer, thereby facilitating maintenance and to obtain improvements in the applied approaches.
- Audit: With the AOP, the audit interest may be implemented regardless of the business rule. Thus, the code would be in a single centralized location, well-defined in the system, being pulled out of classes.
AspectJ - Orientation aspects with Java
The AspectJ is an extension to the Java programming language. Therefore, there was and there is still a concern for compatibility four extremely important and essential items:
- Full compatibility - all valid Java program is also a valid AspectJ program;
- Platform Compatibility - all AspectJ program can run in a Java virtual machine (JVM);
- Tools compatibility - should be possible to extend existing tools to support the AspectJ in a natural way; this includes IDE's (Integrated Development Environments), documentation tools and design tools;
- Compatibility for the programmer - When programming with AspectJ, the programmer should feel like you are using an extension of the Java language.
There is a division of AspectJ into two parts: a specification language and the implementation language. The part of the specification language defines the language in which the code is written; with AspectJ, functional interests are implemented in Java, and implementation of the combination of systemic interests are used the extensions provided by AspectJ itself. Part of the implementation language provides tools for compiling, debugging and integration with integrated development environments.
The AspectJ implements two types of systemic interests, static and dynamic. These are interests that occur aspectual combination. The aspectual combination can cross several modules of a system so that the interest in question can be properly implemented.
Certainly Orientation aspects (AO) is not the ideal paradigm, and we believe that soon there will be other paradigms able to better abstracting / express solutions, and as such, allowing the creation of better solutions. But what is clear to us is that AO is a major step towards the ideal paradigm. In this article, only work part of the Orientation aspects related to programming, however the advantages of AO when applied to analysis and, especially, the project can be impressive, but this is a topic for another article.