Code reuse for improving software productivity and quality in AOP

Transcription

1 Code reuse for improving software productivity and quality in AOP Youssef Hassoun and Constantinos A. Constantinides School of Computer Science and Information Systems Birkbeck College, University of London, Malet Street, London WC1E 7HX, UK {yhassoun, Abstract: Aspect oriented programming languages support the principle of modularity and abstraction by allowing explicit separation between aspects and system core concerns. However, using these tools does not necessarily imply loose coupling as aspect definitions may maintain explicit visibility over application components. In this paper we look at the problem of the binding of aspect definitions to application code and propose a framework that deploys reflection in order to decrease the level of coupling between them, thereby increasing the level of reusability of aspect definitions. 1. Introduction The principle of Separation of Concerns refers to the realization of system concepts as separate software units. This principle is crucial for software development as the associated benefits include better analysis and understanding of systems, as well as readability, reusability, easy adaptability and maintainability. With Object-Oriented Programming (OOP), programmers are able to improve the modularity of software by grouping together state and behavior. In fact, object orientation has been a great success in providing good modularity in software. However, in complex object-oriented systems, certain concerns cannot be localized in single modular units, but they are scattered throughout the program structure, cutting across methods of one or more classes. These crosscutting concerns have been coined as aspects. With the existence of crosscutting, the advantages of OOP no longer hold, and problems with reuse and adaptability are well illustrated in the literature. Aspect-Oriented Programming (AOP) provides technologies that support the explicit capture of crosscutting concerns during implementation while providing mechanisms to combine them with components. Aspect-Oriented Software Development (AOSD) extends AOP to include analysis and design activities. As software products need to satisfy both technical and non-technical criteria, developers find it essential to combine theory and experience in order to reuse proven designs. The importance of reuse lies on the fact that it can speed up the development process, cut down costs, increase productivity and improve the quality of software. Design-level reuse is viewed as the attempt to share certain aspects of an approach across various projects. Object and component-based systems offer a wide spectrum of techniques to reuse designs on different levels, ranging from frameworks and patterns that constitute approaches on how to best program in-the-large to libraries and programming languages that constitute approaches on how to best program in-the-small [25]. On the higher level of the reuse spectrum in the context of AOSD, aspect-oriented frameworks have been discussed in the literature [8], and object-oriented design patterns have been migrated to aspect systems [15]. Furthermore, new design patterns and idioms 1 have been demonstrated [15, 12]. On the lower level of the reuse spectrum, the importance of the mechanism of inheritance and the contribution of OOP towards reusability has been extensively discussed in the literature. Inheritance allows non-invasive (incremental) modification of class definitions. Subclasses may introduce new attributes and methods whose definitions may be based on those of the super-classes. Furthermore, methods may be overloaded (providing different semantics for the same method names) or overridden (providing new semantics for the same method signatures). Issues of reuse also arise in aspect-oriented languages. Aspect-Oriented Programming has resulted in the provision of a higher level of functional code reuse than the one supported by OOP, as classes are not tangled and they tend to maintain a high degree of cohesion. Even though the adoption of AOP results in a good separation of concerns, restricting aspect definitions to match class and method names of system core concerns leads to strong binding between aspects and system core concerns. In such cases aspect definitions are not reusable, but they are restricted to be only applicable in one specific application context. We believe that reuse is as important as separation of concerns, and we want to investigate the level to which AOP can support reusability of aspect code. AspectJ [1] [19] and Hyper/J [26] seem to be two of the most notable technologies that provide mechanisms to support a disciplined way to applying the principle of separation of concerns. However, each technology follows a dif- 1 In [12] Hanenberg and Costanza debate whether or not the strategies they discuss can be classified as design patterns. Regardless of any formal classification, we believe that these strategies constitute an approach to support design-level reuse.

2 ferent approach. On one hand, AspectJ 2 is a general-purpose aspect-oriented language and it constitutes an extension to the Java 3 language by providing new language constructs to explicitly capture crosscutting concerns (aspects). In the AspectJ language one models aspects as separate modules that are combined with components (regular Java classes) at compile-time using a weaver tool. There are three general constructs supported by AspectJ: 1. Joinpoint specifications refer to well-defined points in the execution of the program. Joinpoints may be grouped into pointcuts. 2. An advice forms an action to be performed once a corresponding set of joinpoints is reached. 3. Introductions may enhance components with state and behavior. On the other hand, Hyper/J does not offer new language constructs, but it follows a different approach to support multi-dimensional separation and composition of concerns. Developers build regular Java classes by choosing the most appropriate decomposition for a program. Java classes are then combined at compile-time by specifying a series of composition rules. The rest of the paper is organized as follows. In section 2 we discuss the notion of we discuss the notion of visibility in OOP and in AOP where we take AspectJ and Hyper/J as representatives for the latter. Section 3 describes our approach to aspect reuse where we also discuss the design of a language framework to support reusabiliy. In section 4 we discuss the question implementing the framework in AspectJ and in Hyper/J from general perspective. In section 5 several examples are introduced in AspectJ and in Hyper/J showing the applicability of the framework as a model to minimize coupling between aspects and application components to enhance aspect reuse. In section 6 we discuss related work and in section 7 we draw some conclusions and discuss future work. 2. Visibility in OOP and AOP In this section we will discuss the notion of visibility in the context of object-oriented languages as well as in AOP languages like AspectJ and Hyper/J. Of particular interest to this study are general-purpose aspect-oriented languages that are based on (are extensions of) current object-oriented languages. One of the issues we investigate in this study is the notion of visibility of aspect definitions to classes. Visibility implies dependency and consequently coupling between components, aspects and system core concerns. In general, coupling can be viewed as restricting the scope of application of the components to their direct environment. In particular, strong coupling decreases component reusability. Larman [22] defines visibility as the ability of one object to see or have a reference to another object. In OOP where classes are the basic programming units, there are four ways that visibility can be achieved from class A to class B: (1) attribute visibility (B is an attribute of A), (2) parameter visibility (B is a parameter of a method of A), (3) locally declared visibility (B is declared as a local variable in a method of A), and (4) global visibility (B is somehow globally visible to A, e.g. as a global variable) Visibility in AspectJ With the set of linguistic constructs as well as the weaving tool and IDE support that it provides, AspectJ is a powerful technology that can explicitly capture crosscutting concerns and can combine them with system core concerns at compile-time. Consider the definition of aspect BoundPoint (Listing 1) from the bean aspect example of AspectJ on-line programming manual [1] that adds bean properties to instances of class Point. The code illustrates a number of different cases where visibility exists from the definition of aspect BoundPoint to class Point. Visibility is imposed over the Point class with the introductions of attribute support (line 2), method addpropertychangelistener (line 3), and interface Serializable (line 7), as well as with pointcut 4 setter (line 8), and advice setter(p) (line 9). Furthermore, parameter visibility is also posed to Point class by method firepropertychange( ) (line 10). Essentially, aspect definitions in AspectJ may pose various visibility types based on the constructs the language has introduced in conjunction to all types of visibility relationships already known in OOP. AspectJ may also pose additional visibility types related to visibility between two aspects which falls out of the scope of this paper. 2 AspectJ is a trademark of PARC 3 Java is a registered trademark of Sun Microsystems 4 For a pointcut declaration we may distinguish the visibility that might be introduced by the formal parameters of the pointcut from the visibility that might be introduced by the designators of the pointcut. Programmers can use pattern expressions to provide generic designators when applicable. In this example, there is visibility by both parts of the pointcut declaration over class Point. 2

3 aspect BoundPoint { // 1 private PropertyChangeSupport Point.support = new PropertyChangeSupport(this); // 2 public void Point.addPropertyChangeListener(PropertyChangeListener listener) { // 3 support.addpropertychangelistener(listener); // 4 // 5 // rest of method introductions for registering and managing listeners // 6 declare parents: Point implements Serializable; // 7 pointcut setter(point p): call(void Point.set*(*)) && target(p); // 8 void around (Point p): setter(p) {... // 9 void firepropertychange (Point p, String property, double oldval, double newval) // 10 {... // 11 // 12 Listing 1. Visibility of aspect BoundPoint over class Point It should be noted that even though we use AspectJ as an example language in our discussion about visibility and coupling issues between aspects and system core concerns, it is important to stress that these issues are not exclusive to the AspectJ language, but they can be found in other general-purpose aspect-oriented languages, at least the ones whose design dimensions tend to be along the lines of AspectJ. One such example is AspectC++ [24], which provides pointcuts, introduction and advice constructs, all of which may pose visibility to classes in a similar fashion to the AspectJ example of Listing Visibility in Hyper/J Apart from the visibility issues that are common to most OOP languages, with a similar object model like that of Java, which we already referred to in this section, the question of visibility and consequently coupling in Hyper/J is related to hyperslice definitions. A hyperslice is a set of concerns that is declaratively complete, that is, a hyperslice must be self-contained and declare everything, which it refers to. Consider the case where the Point class, being part of the application hierarchy, is defined as a unit in an application concern and belongs to a hyperslice different from a hyperslice, which includes units that (generically) implement catching and firing an event of change of state of Point objects. To make the class that implements the generic behavior visible to the Point class so that a Point object can be adapted to reuse the generic methods, the Point class or, better, its descendent may provide dummy implementations of the methods implemented in the generic class by using Hyper/J s mechanism of abstract declarations. All concrete types and methods that are defined in one hyperslice and are needed by units in another hyperslice can be, respectively, declared as abstract types and as dummy implementations in that hyperslice thus making hyperslices self-contained. Merging relationships and strategies establish the link between the corresponding units in the different hyperslices. We conclude that according to the multidimensional separation of concerns paradigm implemented in Hyper/J visibility between units in different hyperslices is achieved only through abstract declarations, because hyperslices must be declaratively complete. We shall see in the following sections that the case just described is an example of a more general approach we shall follow to construct reusable components. Reusable concerns implementing a general behavior are separated from application by assigning them different hyperslices. A system in Hyper/J consists of a set of self-contained hyperslices, where each hyperslice consists of several concerns, is independent from the rest and defines every thing it refers to. The only way that hyperslices can be made visible, i.e., coupled, to each other is through abstract declarations supplemented by merging rules. 3. An approach to reusable aspects The aspect-oriented approach provides necessary mechanisms and programming constructs to implement the concepts of separation of concerns, of modularity and of abstraction, thus supporting the construction of systems of cohesive and loosely coupled components. In general, without reference to a particular programming language, joinpoints refer to those places in the base code where aspects crosscut the application core concerns and advices are method implementations, which can be executed at, before or after these points. We may classify the ways in which aspects are implemented according to the characteristics of joinpoints and advices. On the one hand, aspects can be used to add code to an application in an orthogonal way, in which case the crosscutting nature of the added code is completely described by the joinpoints, without any reference to the base code. In such a case, the aspect and the application are independent of each other and the later remains executable without the former in the sense that the aspect can be decoupled without affecting the default behavior of the application. On the other hand, in cases where application state, structure or logic influences aspect joinpoints and/or advices, the aspect is dependent on the application and is applicable only in the application s specific context. Typical examples of such aspects are those whose pointcuts are defined in terms of application components object types. For example, in AspectJ, 3

4 public aspect AppDependentAspect { poincut setbasecomponenobj (BaseComponentType obj): target(obj) && after(basecomponenttype obj): setbasecomponenobj (obj) { < Advice logic depends on obj of Type BaseComponentType or on its state> Listing 2. Pseudo code of an application dependent aspect in AspectJ The corresponding code in Hyper/J is a Java class, which implements the after-advice of Listing 2 as a normal method setbasecomponenobj()and which belongs to a hyperslice separated from application code. As described above, this method can be made visible to its clients in other hyperslices using the mechanism of abstract declarations, in which case each client class defines a dummy implementation of it with the same name. Merging relationships and strategy must be defined to establish the necessary link between the dummy and the concrete implementation of the method. AppDependentAspect, implemented as an AspectJ aspect or as a Java class belonging to a Hyepr/J hyperslice being a unit of one of its concerns, is applicable only in the context of the application, where BaseComponentType is part of the class hierarchy of its components. This implies strong coupling between aspect and the application components using it. Moreover, in addition to type dependency, according to how the advice/method logic depends on the state of the object of BaseComponentType, the application might fail to stay executable without the aspect/class. Orthogonal aspects together with base components form a cohesive and loosely coupled system of components. Moreover, such aspects are reusable, because they are general and independent of any application, and support obliviousness as a distinguishing characteristic of aspect-oriented programming systems [9]. A base component object which, for example, needs to add the generic behavior of catching and firing of state change events needs only to be adapted and is completely oblivious of the mechanism itself. All orthogonal aspects share common properties, namely, the joinpoints and advices are independent of any specific application type, state and logic and the advices are realized at an abstract level. Our approach to reuse falls within the scope of the compositional reuse method [23], which is the most common form of software reuse and which is based on reusing components from earlier software development as building blocks for new software development. In doing so we first identify the reusable components, second adapt or specialize them to fit the application and third integrate them into the application. In AOP, the system is viewed as a set of concerns and we identify as reusable components those crosscutting concerns (aspects), which cut the core concerns in an orthogonal way as described above. These aspects implement general behavior independent of any application and must be adapted to the application before being integrated into it. AspectJ and Hyper/J support composition of concerns and provide the required tools to weave or merge aspects into or to the base code A framework to address aspect reusability The approach described above takes different forms depending on the implementation language. In the case of AspectJ, orthogonal reusable aspects, which represent the invariant part of the aspectual behavior that is independent of any application specifics, may be implemented as abstract aspects and the variable part is left to the sub-aspects to implement. The sub-aspects play the role of the merging agent, where at least joinpoints can be specified according to the needs, types and methods of the client application and/or where necessary structural extensions can be introduced (using AspectJ s introduction mechanism). In effect, abstract aspects represent a common behavior shared among their clients. The extension provided by sub-aspects is controlled by the mechanisms of extends and dominates constructs of AspectJ. In the first case, the advices to be executed at the corresponding pointcuts may be extended (not overridden). In the second case, however, the advices must be overridden 5. In the case of Hyper/J, orthogonal aspects are realized as abstract Java classes that implement a general behavior, which deals with and encapsulates a particular area of interest. These classes, together with helper classes, constitute Hyper/J s concerns and are confined to declaratively complete hyperslices. A concern consists of several units (classes, methods, attributes, etc) and a set of concerns defines a hyperslice. Like their counterparts in AspectJ, the abstract aspects, these classes are implemented in such a way that they are independent of any application specifics. 5 For a complete discussion on the semantics of extends and dominates constructs see the AspectJ documentation available electronically at 4

5 Composition with the client application is realized by using the mechanism of abstract declarations and the merging strategies of Hyper/J. The relationships between aspects and system core concerns are illustrated by UML class diagram 6 in Figure 1, which may constitute a general language framework. We may divide the framework in two levels: the abstract level and the concrete level. The generic aspects with their helper classes reside in the higher level and the application concerns populate the lower level. BaseObjectType is part of the application class hierarchy and AspectObjectType represents optional classes and/or interfaces that may be needed at the abstract level to implement the generic functionality. Note that these types are needed to support the implementation of general behavior and are independent of any application. The relationship between AbstractAspect and ConcreteAspect is, in general, an association relationship and takes different forms depending on the implementation language. In AspectJ, AbstractAspect represents, as the name suggests, an abstract aspect, which encapsulates general behavior. ConcreteAspect is a concrete aspect, which extends it and specifies, at least, the joinpoints at which the generic methods of the abstract aspect are hooked in the application code after weaving. In this way, it makes the functionality of the abstract aspect available to the application or, in other words, it adapts the generic aspect to the application. The relationship between these aspects is an inheritance relationship and determined by AspectJ s mechanisms of extends and dominates. At the abstract level AbstractAspect may need certain class types, referred to as AspectObjectType to implement its generic behavior. The ConcreteAspect, at the lower level, may use these types to adapt or specialize the generic behavior to application needs. The application s hierarchy, represented by BaseObjectType, is related (and visible) to ConcreteAspect through an association relationship. << aspect/class >> AbstractAspect uses 1 0..n <<class>> AspectObjectType 0..n The relationship depends on the implementation language ABSTRACT LEVEL CONCRETE LEVEL uses 1 ASPECT DOMAIN APPLICATION DOMAIN << aspect/class >> ConcreteAspect 1 uses 1..n <<class>> BaseObjectType Figure 1. UML class diagram of a language framework to support reusability of aspect definitions In Hyper/J the two levels are separated by confining the set of concerns at the two levels to different hyperslice. As a hyperslice is, by definition, a set of concerns that is declaratively complete, the units at the lower level are not supposed to see the reusable units at the higher level directly. The visibility and consequently the coupling between the abstract level and the application level is established, first, by identifying the methods and types that are to be 6 Despite a number of different proposals, there is currently no accepted official support for aspects in the UML. As a result, in this paper we have taken the liberty to denote AspectJ and Hyper/J aspects as classes, using stereotypes to differentiate them from regular classes. 5

6 reused and providing corresponding dummy implementations and abstract types at the concrete level and, second, by specifying the merging rules to build the required links. AbstractAspect denotes an abstract Java class that implements general behavior, independent of any application and constitutes with AspectObjectType(s) a selfcontained hyperslice. ConcreteAspect, on the other hand, is a concrete Java class, which belongs to a different hyperslice on the application side. It builds the connection to the reusable abstract class and makes its generic functionality available to the application by defining dummy implementations of its methods. It adapts the generic aspect to the application before merging. The relationship between AbstractAspect and ConcreteAspect is a general association relationship and is determined by the mechanisms of abstract declaration and of merging in Hyper/J. The relationship between ConcreteAspect and AspectObjectType cannot be materialized in Hyper/J and is effectively 1 to 0. At the concrete level, there is an association relationship between ConcreteAspect and the application class hierarchy represented by BaseObjectType. The visibility relationship and consequently the coupling between these classes depend on whether they belong to the same hyperslice or to different hyperslices. 4. Framework implementation Viewed as a model to minimize coupling between crosscutting concerns and application core concerns with the aim to enhance aspects reuse, the implementation of the framework using different AOP languages shows, as one would expect, a number of differences. In this section, we discuss implementation procedures of the framework in AspectJ and in Hyper/J being the most prominent representatives of AOP languages. According to the AOP paradigm, whether in the aspect model of AspectJ or in the Multi-Dimensional Separation of Concerns approach realized by Hyper/J, the system is considered as a multiple of concerns. These concerns are first to be identified as separate entities before they can be composed to produce the system with the required functionality. Not only AspectJ and Hyper/J differ in realizing concerns as programming entities, but they, as a consequence, also differ in composing them. AspectJ offers new language constructs, like aspect, pointcut and advice with a powerful joinpoints model, where concerns can be mapped into aspects and the crosscutting behavior is expressed in terms of specifying the joinpoints using the pointcut construct and implementing advices that can be invoked before, after or instead of application core concerns methods. Composing concerns amounts essentially to inserting the advices code into the application base code, better known as the weaving process and is realized at compile-time. In Hyper/J, on the other hand, a concern is represented as a dimension in a multi-dimensional hyperspace and contains programming units needed to encapsulate the particular area of interest addressed by that concern. The separation of concerns is supported by the concept of hyperslice, which constitutes a set of concerns and must be declaratively complete. The mechanism of Abstract Declaration allows the implementation of the concept of hyperslice. Composing the hyperslices is realized by specifying compositions rules, i.e., setting merging relationships and strategy, and amounts to building correspondence or link between dummy implementations and abstract types in one hyperslice to concrete implementations and classes/interfaces in another Implementation in AspectJ In AspectJ generic behavior can be implemented as abstract aspects using the aspect construct of the language. The adaptation to a particular application is carried out by extending this aspect using the inheritance mechanism, which applies to aspects as it does to classes in OOP. The concrete aspect is important, first, for specializing the generic aspect to the application and, second, for weaving its code into the application. Without concretizing the aspect no code weaving will take place. The concrete aspect may restrict adapting the generic aspect to the application to only specifying the joinpoints at which the advice code should be weaved in, but it may also extend or modify the default behavior offered by the super abstract aspect. As mentioned above, the AspectAbstractType are, in general, class types that may be necessary to implement the general behavior at the abstract level. Whether they are necessary to weave the generic aspect code into the application code depends on the application at hand. In case they are needed the concrete aspect may establish their link with the application using the introduction mechanism of AspectJ Implementation in Hyper/J In Hyper/J general behavior is to be implemented as abstract Java classes with no reference to any application specifics. It represents a Hyper/J concern, which is generally applicable and, as such, must be separated and encapsulated in a hyperslice. As a result the hyperspace involving such one concern is, in its most general form, a twodimensional space, where the generic concern, henceforth a generic aspect, is represented by one dimension and the base code, as the sum of all units of the application components, is considered as one concern and is represented by the other dimension. The separation between reusable aspect, expressing general behavior, and the base code or core concerns is not only logical but also physical, i.e., aspect and base code are located in different Java packages. List- 6

7 ing 3 illustrates the general structure of the hyperspace and Listing 4 depicts the general concern-mapping file, which reflects a clear separation between aspect and base code. Hyperspace genericaspectbasehyperspace composable class base.*; composable class genericaspect.*; Listing 3. Two-dimensional hyperspace including base and generic aspect code package base : Feature.base package genericaspect : Feature.genericAspect Listing 4. Base and generic aspect concern file Having separated reusable aspect, including class types it needs to implement the general behavior, from base code, we need to adapt the aspect to the application before merging them together. This is the role assigned to the ConcreteAspect class at the concrete level of Figure 1 (See subsection 3.1 Framework to address aspect reusability ). To play this role, ConcreteAspect class provides dummy implementations for the generic methods implemented by the AbstractAspect. Moreover, abstract declarations are required for all class types at the abstract level (AspectObjectType in Figure 1) that are referred to at the concrete level. Both, dummy implementations of methods and abstract declarations of types (classes or interfaces), are essential to secure separation of concerns and guarantee declarative completeness of hyperslices. Listing 5 shows the general structure of the composition script (a hypermodule file in Hyper/J terminology) needed to merge generic aspects with base concerns. Two hyperslices are defined, one for the generic reusable aspect and the other for the base code, considered as one entity. To merge the base concerns with the generic aspect, we need to build a correspondence between the units ConcreteAspectClass and AGenericAspect belonging to different self-contained hyperslices. The merging relationship equate is used to build such correspondence and the merging strategy mergebyname establishes the merging link between the two classes as well as between the types, defined at the abstract level as part of the generic implementation of the reusable aspect and corresponding types declared as abstract at the concrete level. hypermodule GenericHyperModule hyperslices: Feature.genericAspect, Feature.base; relationships: mergebyname; equate class Feature.base.ConcreteAspectClass, Feature.genericAspect.AGenericAspect; end hypermodule; Listing 5. Composition script to merge base and generic aspect code The general approach just described, in which concerns are confined to a Java package and at the same time they defines a hyperslice is a general design approach and is referred to as developing with hyperslice packages" [26]. To summarize, the approach to merge generic aspect code with application code in Hyper/J consists of two steps: 1. Deploy the Java s reflective API in order to encapsulate generic behavior within an aspect class. 2. Follow the design principle of developing with hyperslice packages." With the reflective capabilities of the Java language like introspection and method invocation, it is reasonable to assume that the first step is applicable in general. The second step involves the definition of a two-dimensional concern hyperspace and a concern mapping that matches the package structure a one-to-one mapping. Moreover, each concern is associated with one hyperslice and thus self-contained. Furthermore, to satisfy the requirement of declarative completeness of hyperslices, the base concern must, if necessary, be supplemented with abstract classes and it must provide dummy implementations of the generic methods of the aspect class. 5. Examples In this section examples in AspectJ and in Hyper/J shall serve as a means to illustrate the design of the language framework presented in the previous section to support code reusability in AOP by focusing on advice or correspondingly on hyperslice reuse Observer pattern The Observer pattern, well known from the work on Deign Patterns by GoF [10], is first implemented in Smalltalk environment as the user interface framework Model/View/Controller (MVC) [21]. 7

8 The Observer Pattern deals with the question of dependency between objects, where a change of one object (the subject) requires changing other objects (the observers). To express this relationship, we need, to start with, two abstractions, a Subject and an Observer (See Listing 6 and Listing 7). package observer; public interface Subject { void addobserver(observer obs); void removeobserver(observer obs); java.util.vector getobservers(); Object getdata(); Listing 6. The Subject interface package observer; public interface Observer { void setsubject(subject s); Subject getsubject(); void update(); Listing 7. The Observer interface A subject holds a list of its observers, can add and remove observers from the list whereas an observer can set and get its subject and update its state upon receiving a notification from the subject Observer pattern in AspectJ The implementation of the subject-observer protocol, as realized in AspectJ on-line programming manual [1], is a good example on the framework presented in the previous section. The implementation uses the abstractions Subject and Observer to implement the protocol as an advice, whereby the subject notifies all registered observers that its state has changed. In doing so, no reference is made to any particular application. Figure 2 depicts the class diagram of this example. << aspect >> SubjectObserverProtocol extends 1 uses 1 uses 1 1 uses n <<class>> Vector <<interface>> Subject <<interface>> Observer 1..n uses uses << aspect >> SubjectObserverProtocolImpl 1 1 uses 1 <<class>> Button 1 uses 1 Appl class hierachy <<class>> ColorLabel Figure 2. UML class diagram of an example on the observer pattern The observer pattern implementation class diagram matches the general framework presented above. Vector, Subject and Observer are helper classes needed to implement the abstract aspect s functionality of registering and re- 8

9 moving observers, getting all observers as well as setter and getter methods for the subject (See Listings 6 and 7). Button and ColorLabel are application classes, whose roles as Subjects or as Observers and consequently the reaction of the observer to notification message of a change of state are defined in the concrete aspect, SubjectObserver- ProtocolImpl, which establishes the connection with the application by further specifying the joinpoints by concretizing the abstract point cut defined in the abstract aspect. Listing 8 shows the AspectJ implementation of the generic part of the subject-observer protocol and Listing 9 the concrete part as implemented in [1] 7. package observer; Import java.util.vector; public abstract aspect SubjectObserverProtocol { private Vector Subject.observers = new Vector(); // observer list private Subject Observer.subject = null; // the subject public void Subject.addObserver(Observer obs) { observers.addelement(obs); obs.setsubject(this); public void Subject.removeObserver(Observer obs) { observers.removeelement(obs); obs.setsubject(null); public Vector Subject.getObservers() { return observers; public void Observer.setSubject(Subject s) { subject = s; public Subject Observer.getSubject() { return subject; public abstract pointcut statechanges(observer.subject s); after(observer.subject s): statechanges(s) { for (int i = 0; i < s.getobservers().size(); i++) { ((observer.observer)s.getobservers().elementat(i)).update(); Listing 8. The generic part of subject-observer protocol implemented as an abstract aspect in AspectJ package observer; import java.util.vector; aspect SubjectObserverProtocolImpl extends SubjectObserverProtocol { declare parents: Button implements Subject; public Object Button.getData() { return this; declare parents: ColorLabel implements Observer; public void ColorLabel.update() { colorcycle(); pointcut statechanges(subject s): target(s) && call(void Button.click()); Listing 9. The concrete aspect adapts the generic behavior to the application objects Button and ColorLabel Observer pattern in Hyper/J In Hyper/J the general behavior of the SubjectObserverProtocol is realized as an abstract Java class with the after-advice being implemented as a method statechanges() (See Listing 10). Following the implementation steps of subsection 4.2, the class SubjectObserverProtocolImpl, whose role is to adapt the general behavior defined by the abstract class to the client application must provide a dummy implementations of statechanges(), addobserver(), removeobserver(), and setsubject() to allow the application objects to notify their observers of their change of state, to add or remove an observer and to set the subject they want to listen to (Listing 11). The application objects, on the other hand, must define the events marking a change of state (subject role) and the observers must provide an implementation of the update() method as their reaction to receiving the event. In addition, abstract declarations for the Observer and Subject interfaces must be provided at the concrete level (application side) (Listing 12). package observer; public abstract class SubjectObserverProtocol { private java.util.vector observers = new java.util.vector(); private Subject subject = null; 7 For a complete description of the code please refer to [1] 9

10 public void addobserver(observer obs) { observers.addelement(obs); public void removeobserver(observer obs) { observers.removeelement(obs); obs.setsubject(null); public java.util.vector getobservers() { return observers; public void setsubject(subject s) { subject = s; public Subject getsubject() { return subject; public void statechanges(subject s) { for (int i = 0; i < getobservers().size(); i++) { ((Observer)getObservers().elementAt(i)).update(); Listing 10. The generic part of subject-observer protocol implemented as an abstract class package base; public class SubjectObserverProtocolImpl { public void statechanges(subject s) { throw new com.ibm.hyperj.unimplementederror(); void addobserver(observer obs) { throw new com.ibm.hyperj.unimplementederror(); void removeobserver(observer obs) { throw new com.ibm.hyperj.unimplementederror(); public void setsubject(subject s) { throw new com.ibm.hyperj.unimplementederror(); Listing 11. The dummy implementations of subject-observer protocol at the application level package base; abstract interface Observer { abstract interface Subject { Listing 12. Abstract declarations of Observer and Subject interfaces at the application side The application object ColorLabel takes the role of an observer in which it implements the abstract (empty) interface Observer. It provides an implementation of the update method, which defines its observer response of its instances (Listing 13). The subject, SButton, which implements the abstract (empty) integface Subject, delegates the notification of its change of state (click event) to a SubjectObserverProtocolImpl object (Listing 14). package base; import java.awt.color; import java.awt.label; class ColorLabel extends Label implements Observer { ColorLabel(Display display) { super(); display.addtoframe(this); final static Color[] colors={color.red, Color.blue, Color.green, Color.magenta; private int colorindex = 0; private int cyclecount = 0; void colorcycle() { cyclecount++; colorindex = (colorindex + 1) % colors.length; setbackground(colors[colorindex]); settext("" + cyclecount); public void update() { colorcycle(); 10

11 Listing 13. As Observer ColorLabel defines the response behavior of its instances through update() package base; class SButton extends java.awt.button implements Subject { static final java.awt.color defaultbackgroundcolor = java.awt.color.gray; static final java.awt.color defaultforegroundcolor = java.awt.color.black; static final String defaulttext = "cycle color"; private SubjectObserverProtocolImpl sopi=null; public SButton(Display display) { super(); setlabel(defaulttext); setbackground(defaultbackgroundcolor); setforeground(defaultforegroundcolor); addactionlistener(new java.awt.event.actionlistener() { public void actionperformed(java.awt.event.actionevent e) { SButton.this.click(); ); display.addtoframe(this); public void click() {sopi.statechanges(this); public void setsopi(subjectobserverprotocolimpl sopi) {this.sopi=sopi; public Object getdata() { return this; Listing 14. SButton delegates notification of its observers on click() events to SubjectObserverProtocolImpl Note that SubjectObserverProtocolImpl not only allows subjects to notify their observers but it also allows observers to set their subjects and subjects to add observers and to remove them. Listing 15 shows an example of an application in which SButton objects and ColorLabels are defined as subjects and observers, respectively. The dummy implementations of SubjectObserverProtocolImpl allow its instances to set subjects and associate observers to them. package base; public class Demo { public static void main(string[] args) { Display display = new Display(); // helper class ColorLabel c1 = new ColorLabel(display); // 1 st observer ColorLabel c2 = new ColorLabel(display); // 2 nd observer ColorLabel c3 = new ColorLabel(display); // 3 rd observer SButton b1 = new SButton(display); SButton b2 = new SButton(display); // a subject // a second subject SubjectObserverProtocolImpl sopi1=new SubjectObserverProtocolImpl(); // a broker SubjectObserverProtocolImpl sopi2=new SubjectObserverProtocolImpl(); // a second broker b1.setsopi(sopi1); sopi1.setsubject(b1); sopi1.addobserver(c1); sopi1.addobserver(c2); // define first broker as the delegate // set the subject // add an observer // add a second observer b2.setsopi(sopi2); // define second broker as the delegate sopi2.setsubject(b2); // set the subject sopi2.addobserver(c3); // attach an observer Listing 15. SubjectObserverProtocolImpl acts as a broker between abstract level and application objects Note that the hyperspace, the concern mapping and the hyperslice structures are those defined in section 4.2 and follow the design principle of developing with hyperslice packages. According to this design principle, the hyperslice structure follows the package distribution and, as such, all the units in package observer, i.e., the abstract class SubjectObserverProtocol and the interfaces Observer and Subject belong to one hyperslice, self-contained, implement a general behavior and is independent of any application. All the rest including SubjectObserverProtocolImpl together with abstract interface declaration and the application objects belong to another hyperslices. 11

12 The composition script is similar to that in Listing 5, where the merging relationship is shown in Listing 16 and the merging strategy remains mergebyname. Equate class Feature.base.SubjectObserverProtocol,Feature.observer.SubjectObserverProtocolImpl Listing 16. Merging relationship as part of composition script for generic implementation of the observer pattern 5.2. JavaBeans active properties Changing an active JavaBeans property results in firing an event. We can make a simple property active by binding its changes to anonymous event listeners. JavaBeans supports active (precisely bound) properties through a new event type called the PropertyChangeEvent, the listener interface PropertyChangeListener and through a support class called PropertyChangeSupport. To make object s properties active, the object implements IPropertyChangeSupport (Listing 16) and is thus capable of registering (or removing) listener objects that get notified once the object s state (defined in terms of its properties) is modified. Listener objects (Listing 17) are those that implement the PropertyChangeListener interface. The responsibility of notifying state changes is delegated to an instance of PropertyChangeSupport. This protocol is similar to the subject observer protocol presented above and is an instance of the MVC framework that is often deployed to construct graphical user interfaces in Java. One possible solution to this problem would be to provide an aspect that introduces bean behavior to a specific an application component. However, in order to decrease the level of coupling between aspects and application and to support reuse, we implement the mechanism of catching and firing the event independent from any application as a general behavior. package bean; public interface IPropertyChangeSupport extends Serializable { public void addpropertychangelistener(propertychangelistener listener); public void removepropertychangelistener(propertychangelistener listener); public void firepropertychange( String property, Object oval, Object nval); Listing 16. IPropertyChangeSupport is to be implemented by any objects that require bean behavior public class ListenerObject implements PropertyChangeListener { private <BaseObjectType> abaseobject; public void propertychange(propertychangeevent e) { // do something, as the state of abaseobject has changed Listing 17. Pseudocode for ListenerObject which is-a PropertyChangeListener Active properties in AspectJ Listing 18 shows a generic implementation of active properties that can be applied to any object of arbitrary type as an abstract aspect in AspectJ. It uses Java s reflective API to define a polymorphic behavior independent of object type. BeanAspect includes an abstract pointcut and provides an advice where a change of state is fired based on calls to setter methods of any object provided it implements the IPropertyChangeSupport interface. package bean ; import java.lang.reflect.*; public abstract aspect BeanAspect { abstract pointcut setter(ipropertychangesupport obj); void around(ipropertychangesupport p): setter(p) { String property = thisjoinpoint.getsignature().getname().substring("set".length()); Method[] meths=p.getclass().getdeclaredmethods(); for (int i=0; i<meths.length; i++) { if (meths[i].getname().tolowercase().indexof("set")!=-1) { //use reflection to get corresponding get<property>-method Method getmeth=getgetmethod(p, property); Object oldval=null; Object newval=null; try { oldval = getmeth.invoke(p, null); // getmethods have no parameters proceed(p); newval=getmeth.invoke(p, null); catch (java.lang.illegalaccessexception iae) { iae.printstacktrace(); catch (java.lang.reflect.invocationtargetexception ite) { ite.printstacktrace(); 12

13 p.firepropertychange(property, oldval, newval); // if // for Listing 18. Aspect BeanAspect as a generic realization of catching and firing an event of a change of state Abstract aspects in AspectJ serve the same purpose as abstract classes in Java. However, abstract aspects and the mechanism of inheritance do not necessarily imply loose coupling between aspects and application core concerns. BaseBeanAspect (Listing 19) inherits from BeanAspect and its responsibility is twofold: (1) to provide a concrete pointcut that refers to the execution of any setter method on any arbitrary type BaseObjectType (part of the system core concerns), and (2) to extend the behavior of objects of this type by introducing bean active properties semantics 8. package base; import java.beans.propertychangesupport; import java.beans.propertychangelistener; public aspect BaseBeanAspect extends BeanAspect { pointcut setter(ipropertychangesupport obj): execution(* set*(*)) && target(obj); declare parents: <BaseObjectType> implements IPropertyChangeSupport; PropertyChangeSupport <BaseObjectType>.support = new PropertyChangeSupport(this); public void <BaseObjectType>.addPropertyChangeListener(PropertyChangeListener listr){ support.addpropertychangelistener(listr); public void <BaseObjectType>.removePropertyChangeListener(PropertyChangeListener listr) { support.removepropertychangelistener(listr); public void <BaseObjectType>.firePropertyChange(String p, Object oldval, Object newval){ support.firepropertychange(p, oldval, newval); Listing 19. Pseudocode for a concrete aspect needed to weave in the advice code of its super abstract aspect Active properties in Hyper/J The implementation of making a simple object property active in Hyper/J follows the same procedure used above to implement the subject-observer protocol. The generic behavior of catching and firing an event of change in the property is implemented as an abstract class in Listing 20, which in order to allow its clients to transform their simple properties into active ones, implements IPropertyChangeSupport. package bean; import java.lang.reflect.*; import java.beans.*; public abstract class BoundProperty implements IPropertyChangeSupport { public void fireevent(ipropertychangesupport p, Method setmeth, Object[] params) { String propertyname =setmeth.getname().substring("set".length()); // use Java introspection to find the corresponding get-method; Method getmeth=getgetmethod(p, propertyname); Object oldval=null; Object newval=null; try { oldval = getmeth.invoke(p, null); setmeth.invoke(p, params); newval=getmeth.invoke(p, null); catch (java.lang.illegalaccessexception iae) { iae.printstacktrace(); catch (java.lang.reflect.invocationtargetexception ite) {ite.printstacktrace(); p.firepropertychange(propertyname, oldval, newval); protected Method getgetmethod(ipropertychangesupport p, String propertyname) { Method[] meths=p.getclass().getsuperclass().getdeclaredmethods(); // Method[] meths=p.getclass().getdeclaredmethods(); // case delegation for (int i=0; i<meths.length; i++) { if ((meths[i].getname().tolowercase().indexof("get")!=-1) && 8 For more implementation details please refer to [16] 13