Aspect Orientation was spawn out of the need to express
in a more modular way crosscutting concerns, originally
identified by Matsuoka, Yonezawa as inheritance anomalies
in [4]. The term inheritance anomalies
was coined by the authors to denote the problems that one has to work
around in an OOP program in order to introduce a concern that
affects your class hierarchy (and even methods within a class) by
introducing duplicate code at distinct points within your programs code.
This systematic addition of code at different points within the programs code
could not be captured and extracted with current OOP mechanisms (abstrac classes
interfaces etc). As such the concern is said to crosscut the base
program. The encapsulation of such a concern in a modular and well localized manner
is your Aspect. Logically then, having the ability to capture aspects in a language
the next step is to be able to introduce this aspectual behavior at the points within a
programs execution. This introduction will provide the execution of aspectual code
at the correct point in the programs execution time, so that your concern
(refered to now as an Aspect) will perform its intented job correctly. That is,
as if the code was manually inserted in the original program as we did before.
The above description can be refered to as the "birth" of Aspect Oriented Programming.
Recently it has been identified that AOP is not a simple little hack to code some
exaples that exhibit crosscuting concerns, but rather a programming discipline
that can be followed not only by OO Programmers. Clear separation of concerns not
only at design level but also at the implementation stage, allows for a higher level
of modularity, eases extensibility/alteration and manageability of program code.
ABB's AIP system however, provides a different definition for the notion of
an "Aspect". In particular, "an aspect defines a piece of information, and a
set of functions to create, access, manipulate the information". Then, using
"Aspect Objects" one can define the "Aspects" which an "Aspect Object" has. In this
way within ABB' AIP system one can create modular units "Aspects" for concerns (or
parts of the concern) that when grouped together under the definition of an
"Aspect Object" will provide a representation of a real life artifact with its operations
and functionality.
With the mouse example, I attempted to cast the initial problem as described in
Matsuoka & Yonezawa form the bounded buffer example, to something simpler and not
concurrent. In the place of "gget()" and other such functionality that the original
paper introduces, in the mouse example we added double-click operations (similar other
such operations can be implemented at will).
The given implementation uses AspectJ, but attempts to follow the design principles that
ABB's AIP system has. In a little more detail, representing ABB aspects as AspectJ aspects
Classes as Aspect Objects. The design constraints set forth by ABB's AIP should provide
a solution to the Mouse problem that will not suffer from code taggling (crosscuting).
This is more of a test to see whether the design decision in AIP can accomodate a modular
and easily extensible solution without suffering from any inheritance anomaly issues.
|
