PRESENTE IDEOLÓGICO Y ACONTECIMENTALIDAD

AOP is above all a modularity technology, whose focus is to enable the clean modularisation of crosscutting concerns. AOP was created under the assumption that no programming model or language based on a single criterion of decomposition – be it function, assertion, class or any other – is able to separate and encapsulate all concerns found in the more complex examples of modern software [86]. When a system has two or more decompositions such that neither can fit neatly into the other, one of the decompositions tends to be dominant [150]. Only the elements relating to the dominant decomposition are cleanly modularised: the code relative to others concerns tends to be crosscutting, i.e. they are scattered throughout the modules of the existing structure. Those elements usually appear as code fragments enclosed within the existing modules, i.e. they are tangled with code related to other concerns. In the light of AOP, it is very desirable that models and tools for software development be able to present each concern in the form that most facilitate its understanding, reasoning and maintenance, thus providing greater intentionality. Code scattering and code tangling are an impediment to achieve it.

Kiczales et al. propose a new programming technique they dubbed aspect-oriented [86] as a solution to the crosscutting effect and associated problems. Kiczales et al. use the term

aspect to refer to concerns or design decisions difficult or impossible to capture cleanly, no

matter which programming model is used. AOP enables the representation in its own unit of modularity of code relative to concerns that would otherwise cut cross several units. This new type of module – the aspect – is a representation of a (otherwise crosscutting) concern cleanly captured in its own unit of modularity. The various aspects are then composed through a process dubbed weaving [86][64], which produces the application through composition of all the intended aspects.

Aspects are composed by weaving aspect code with a base code. This process works by inlining the instructions from the aspect code into the base code, producing a tangled version. The fact that it is tangled does not impact negatively the development process, since it can be regenerated every time a new version is required. The inlining analogy used to describe weaving may suggest the processing and generating of source code, but the earliest aspect-oriented compilers started to perform this inlining at the binary level, very soon in the technology’s developing process. This made it clear that weaving could be regarded as one more phase in the execution of a compiler (see Figure 5), and that is how it is presently regarded [6]. There is nothing in the aspect-oriented model stating that the target of the weaving process must be source or binary code, or that the weaving process must be static (compile-time), dynamic (runtime), something in between (e.g. load-time), or supported at the virtual machine level [134].

_______ ______ ______ _______ _______ _______ _______ ________ _______ ________ _______ _______ COMPILER 10011100111 010101011111 0000111100011 0101011101011 0101010001111 BINARY FILE a) _ ___ __ ________ _______ ___ ____ Aspect _____ __ ___ ___ _______ ________ _______ _______ _ ______ ASPECT WEAVER 10011100 01010101 00001111 010101110 101010111 BINARY FILE ____ _______ _________ ___ ____________ _______ ___ _ _______ ___ COMPILER Full compilation process b)

Figure 5: (a) Traditional Compilation (b) Compilation with Weaving

AOP is meant to complement other models, not to replace them. What distinguishes aspects from traditional modules is the crosscutting nature of the concerns they modularise. It is important to realise the relative nature of this concept: a given concern may be crosscutting using one model but may be a cleanly encapsulated one using another. For instance, the procedural model decomposes systems according to algorithms, and therefore data is scattered across multiple units of modularity (procedures). In OOP, data and functionalities comprise the primary decomposition of the system and therefore data is cleanly modularised. Other, non-functional, concerns stand out as crosscutting. That is why the aspects that complement OO applications tend to be non-functional.

Often, the various aspects relate to different abstraction domains. Recognising this fact, the earliest proposals presented by Kiczales et al. include aspects coded in different, sometimes concern-specific, languages. This is consistent with the idea of maximising intentionality. It is the task of the aspect weaver to compose the various aspects into a single application. For instance, Lopes developed two concern-specific languages – COOL and RIDL [100][102] – designed to express policies of synchronisation in multithreaded environments and the management of access to remote objects throughout networks. Although DSLs alone yields maximum intentionality to model specific domains, use of DSLs is also very limiting, since it would require a new DSL as well as its own specific aspect weaver for each new domain, and possibly for each target application language or platform. These problems are not present in the AspectJ language, which is general-purpose.

In its earliest years, there were debates on the nature of AOP and what differentiated it from other models. Filman and Friedman [45] proposed quantification and obliviousness as the defining properties of aspect-orientation. Quantification of a piece of code over a program is the ability to specify a set of separate points in the execution of the program and then execute the piece of code in every point of the set. In other words, quantification is to say, “whenever condition C arises, perform action A”. The kinds of quantifications that an aspect-oriented language supports determine the language’s expressive power. A usual quantification can be “whenever method M is called”, but can be something more fine- grained like “whenever variable v is accessed for reading”.

Obliviousness is the ability to quantify a piece of code over programs that were written oblivious to this code. The programs are said to be oblivious because they were not specifically prepared to receive those quantifications (the programmers who wrote the program were oblivious to them). Thus, it becomes possible to add, or change, or even

delete behaviour from a program without changing its code. Therefore, AOP opens the possibility to reuse code not originally intended to be reused, or in ways other than those initially intended.