An Aspect-Oriented Approach - Autonomics Development: A Domain-Specific Aspect Language Approach - page 40

3 An Aspect-Oriented Approach

3.1 Introduction
Object-orientation has been presented as the technology that will finally make soft-
ware reuse a reality as the object model provides a better fit with domain models
than procedural programming [63]. Object-orientation, currently the dominant
programming paradigm, allows a programmer to build a system by decomposing
a problem domain into objects that contain both data and the methods used to
manipulate the data, thereby providing both abstraction and encapsulation. In ad-
dition, object-oriented languages typically provide an inheritance mechanism that
allows an object to reuse the data and methods of its parent, thereby enabling
polymorphism.
There are, however, many programming problems where the object-oriented
programming (OOP) technique, or the procedural programming technique it re-
places, are not sucient to capture the important design decisions a program
needs to implement. Kiczales et al. [59] refer to these design decisions as aspects
and claim the reason they are so dicult to capture is because they crosscut the
systems basic functionality. Kiczales et al. claim that AOP makes it possible to
clearly express programs involving such aspects, including appropriate isolation,
composition and reuse of the aspect code.

3.2 Crosscutting Concerns and Aspects
Separation of concerns has long been a guiding principle of software engineering as
it allows one to identify, encapsulate and manipulate only those parts of software
that are relevant to a particular goal or purpose [79]. Unfortunately, there can be
many concerns that crosscut one another leading to tangled code that is dicult
to understand, reuse and evolve. Concerns are said to crosscut if the methods
related to those concerns intersect [31] as illustrated in the UML for a simple
picture editor 1 in Figure 3.1.
Figure 3.1 illustrates two implementations of the FigureElement interface,
Point and Line . Although these classes exhibit good modularity, consider the
concern that the screen manager must be notified whenever a FigureElement
moves. In this case every time a FigureElement changes, the screen manager must

1 This example is reproduced from Kiczales et al. [60].