Applications based on an object-oriented framework can be built by programming against the framework's reuse interface. Mastering a framework is typically a time-consuming and difficult task. This paper presents a pattern language for developing higher level reuse interfaces for an existing framework. When applying the patterns that constitute the language it is implied that the framework becomes enhanced with an additional layer of reusable modules that rely on aspect-oriented programming. These modules are referred to as Modular Hot Spots. They modularize existing hot spots, enabling a framework-based application to be built in a stepwise way and at a higher abstraction level than if using the conventional reuse interface. By raising the abstraction level, it is intended that the development of framework-based applications becomes facilitated.
An object-oriented framework [
A hot spot is a fragment of the reuse interface that enables the adaptation of a certain variation point in framework-based applications. A hot spot typically involves more than one framework class, while on the other hand, a same framework class may be involved in more than one hot spot. Therefore, there is a many-to-many mapping between variation points and framework classes that support them (illustrated in Figure 1). variation points hot spot framework
class
The described many-to-many mapping implies that there are classes of a framework-based application that will be tangled with respect to the adaptation different variation points, while the adaptation of certain variation points is going to be scattered among more than one class of the framework-based application. Tangling implies that modifying the adaptation of a variation point in a framework-based application requires to cope with code statements that pertain to other variation points, whereas scattering implies that the modification may involve more than one class.
The work in [
This paper presents design patterns for enhancing a conventional reuse interface with specialization aspects, in the form of a pattern language that we refer to as Modular Hot Spots. The patterns can be used together for solving the problem of developing the several modules which form the higher level reuse interface. By having Modular Hot Spots it is intended that the new reuse interface has: – Modular reuse interface. Framework-based applications can be developed in a stepwise way. Each application module is the adaptation of a Modular Hot Spot and implements an increment that does not require modifications or knowledge about the internals of existing modules. The capability of developing application increments without having to modify or understand existing code is beneficial with respect to evolution. – Less hook methods. Through the adaptation of Modular Hot Spots, framework-based applications can be developed without dealing with as many hook methods as in conventional solutions. This contributes to have a narrow inheritance interface, a principle that states that only a few hook methods should be required to be given per each apframework development
Object-Oriented Framework SA AA
SA
SA
SA
AA application development SA AA
plication class [
Given the above points, the abstraction level is raised with respect to
the development of framework-based applications. Frameworks tend to
evolve from white-box to black-box [
The knowledge embodied in the language results from developing
Modular Hot Spots using AspectJ [
The target audience of this pattern language are framework developers that seek for solutions to provide higher level reuse interfaces, enabling framework-based applications to be built more easily.
Section 2 introduces a simple framework that is used as a running example in the description of the patterns, and several scenarios where specialization aspects can be beneficial. Section 3 presents an overview of the pattern language. Section 4 presents an AspectJ idiom that is used on the implementation of the patterns. Sections 5-10 present the patterns that constitute the pattern language. Section 11 revisits the example framework taking into account the new reuse interface that resulted from all the examples given throughout the patterns. Finally, Section 12 concludes the paper. 2
This section introduces a simple example of a framework, which can be used to build GUI applications. An GUI application has actions that can be triggered by the UI elements. The action can be either applicationspecific or provided by the framework. An application may have menus, which may contain submenus. The menus may contain either items that trigger application actions or other menus (i.e. the submenus). Implementation-wise there is no distinction between a menu and a submenu (i.e. they are represented by the same class). Figure 3 contains an UML class diagram depicting the classes of the framework’s reuse interface (in gray), and an example application (in white) based on the given reuse interface. Below we present Java code that implements the example frameworkbased application.
MenuBar add(IMenu) <<abstract>>
AbstractApplication createActions(ActionBar) createMenus(MenuBar) ...
ExampleApplication createActions(ActionBar) createMenus(MenuBar) <<interface>>
IMenu addAction(IAction) addSubMenu(IMenu)
MenuImpl addAction(IAction) addSubMenu(IMenu)
ActionBar register(IAction) <<interface>>
IAction run() ExitAction run()
...
ExampleAction run() : void p u b l i c c l a s s ExampleAction implements I A c t i o n { v o i d run ( ) {
// do something
The main class is a subclass of AbstractApplication. Application developers must be aware that createActions() is executed before createMenus(). The sample framework-based application has two actions, an application-specific one, ExampleAction, and the framework-provided ExitAction. It has a “Menu1”, which has the exit action and a submenu “Menu2” that has the application-specific action.
The following list presents a set of scenarios where application developers (i.e. the ones who use the framework) may be faced with difficulties. Each of these scenarios is associated with a goal of application developers. – Scenario 1, plugging menus. The application concept menu is represented directly by the interface IMenu, which MenuImpl implements. Therefore, it should be easy for an application developer to locate it. However, once the interface/class is known, it is necessary to find out how to plug the menu in the application. Given that the application concept is represented abstractly by the AbstractApplication class, one would go to inspect that class, and then, to realize that there is a hook method for the intended purpose (i.e. createMenus(...)). Plugging the menu involves modifying the method body, which may have existing statements. Therefore, in order to implement the goal of plugging a menu, one has to “interfere” with statements pertaining to other goals (i.e. other menus and their contents). – Scenario 2, menu context. The application concept menu can be used in two different contexts, either as an application menu or as submenu of another menu. As explained in Scenario 1, by knowing IMenu and MenuImpl one does not know where and how the menus can be plugged. If one has an existing application menu m1 and wants that menu to become a submenu of another menu m2, besides understanding the subclass of AbstractApplication (Scenario 1) to remove the statement that plugs the menu, there is need to locate where m2 is instantiated and to know its interface to add m1 to it. Therefore, changing the context of an existing menu requires changes both in statements pertaining to the original context and in statements pertaining to the new context. – Scenario 3, associating actions. The application concept action is represented by the interface IAction. Actions may be associated to menus. Suppose that there is an existing application with an action a and a menu m, and that one wants to associate a to m. In order to do so, one has to inspect the hook method createActions() of the subclass of AbstractApplication to find out the instance of a, and then, to modify the hook method createMenus() by finding the instance of m and adding a statement that associates a to it. Therefore, an association between two application elements involves two parts of a module (the subclass of AbstractApplication) which is not directly related to those elements.
Each of the given scenarios can be improved by applying the Modular Hot Spots pattern language. When addressing a scenario by applying a pattern, it might happen that a scenario with a new problem arises. In these cases, there are other patterns for overcoming the new problems. 3
Figure 4 gives an overview of Modular Hot Spots. The diagram contains related patterns and idioms represented in white, while the actual patterns/idioms of the language are represented in gray. Design patterns are represented in ellipses, whereas AspectJ idioms are represented in circles.
Hot spots based on Template Method [
A Self-Pluggable Object is a hot spot that enables its
adaptations to localize both the creation of an object representing an application
element and its composition with another application element. It may be
plugged in another Self-Pluggable Object and it may have
Composition Hook Methods itself. It can be implemented using a Template
Pointcut (Section 4). A Template Pointcut is an AspectJ idiom that
combines the idioms Abstract Pointcut and Composite Pointcut
[
A Multi-Context Self-Pluggable Object (Section 7) is a special kind of Self-Pluggable Object that is suitable in cases when the object can be plugged in different application contexts (elements). The Multi-Context Self-Pluggable Object pattern is suitable for improving the menu context scenario. An Abstract Self-Pluggable Template Advice
Idiom implemented applies
Factory
Method
Abstract Self-Pluggable
Object
may be alternative
Composite Pointcut Idiom may have
Abstract Pointcut
Idiom applies Association
Object implemented
applies implemented organized in
Template Pointcut
Idiom Self-Pluggable
Type
Hierarchy Template Method may have is a may plug in
is a Multi-Context Self-Pluggable
Object may have
Composition Hook Method completed by
participant in Self-Pluggable
Object
Object (Section 8) is a module suitable for structuring a set of related
Self-Pluggable Objects, so that the behavior that plugs those
objects can be reused. It applies Factory Method [
Finally, an Association Object (Section 10) enables to establish associations between Self-Pluggable Objects. This pattern is suitable for improving the associating actions scenario.
The examples of applying the patterns are given in Java, using
AspectJ as the AOP language. Although the patterns were only experienced
in AspectJ, they are not necessarily specific to it. An AOP language for a
base object-oriented language, that features method execution pointcuts,
abstract aspects, and abstract pointcuts, should be suitable for
implementing the patterns. For instance, the patterns should be applicable to
AspectC++ [
In the figures that illustrate the solutions, the framework modules are always represented in gray, whereas the white classes represent application modules. Aspects are depicted with a class with stereotype aspect . Pointcuts and advices are represented in the method’s placeholder using the stereotypes pointcut and advice , accordingly. Stereotyped dependencies represent pointcut definitions, where the stereotype name represents the pointcut name. 4
This section presents an AspectJ idiom referred to as Template Pointcut. Its name results from an analogy with the Template Method pattern. In a Template Method we have a partially implemented method which uses abstract methods that are given by subclasses. In the case of a Template Pointcut, we have a partially defined pointcut within an aspect module that uses abstract pointcuts that are given by the subaspects. An aspect module transforms (by weaving) other modules, which can be either classes or other aspect modules. A reusable abstract aspect is a module from which other aspects inherit (the subaspects), reusing its implementation. The scope of applicability of a reusable aspect may be restricted to a certain kind of base modules. The advantage of doing so is that the reusable aspect may assume certain characteristics of the modules which are going to be transformed. For instance, the reusable aspect may be applicable to all subclasses of a certain class, an therefore the common inherited methods may be safely used by the aspect.
How to implement a reusable abstract aspect so that its advice can only take effect in a partially defined set of join points, while being able to generalize the commonalities between those join points? – The information factored out to the reusable aspect should be maximized. – The more “black-box” the reusable aspect is, the better. – The simpler the pointcut definitions in the subaspects are, the better. – The less one needs to know about the modules that an aspect transforms, the better.
Implement an abstract aspect containing a Composite Pointcut (the template) that is defined as the intersection of certain join points with another Abstract Pointcut (the hook). The advice takes effect on the Template Pointcut (Figure 5). Subaspects of the abstract aspect have to define the hook pointcut.
Consider a reusable aspect that can be used to transform classes that inherit from the following abstract class. p u b l i c a b s t r a c t c l a s s A b s t r a c t C l a s s { /∗ . . . ∗/ p u b l i c S t r i n g method ( ) ; } <<aspect, abstract>>
AbstractAspect <<pointcut>> template() : ... && hook() <<pointcut>> hook() : ... <<advice>> template()
ConcreteAspect <<hook>>
...
The following is a reusable aspect with a Template Pointcut defined as the intersection between the execution of method() within subclasses of AbstractAspect and a hook class, which is to be given by the abstract pointcut hook(). The definition of hook() is intended to match a particular subclass of AbstractAspect, which the aspect will transform. Although the pointcut template() is declared separately, it could be incorporated directly in the advice. Assuming the existence of a subclass of AbstractClass named SomeClass, the code below shows how the aspect could be used for activating the transformation of SomeClass. p u b l i c a s p e c t C o n c r e t e A s p e c t e x t e n d s A b s t r a c t A s p e c t { p r o t e c t e d p o i n t c u t hook ( ) : t a r g e t ( SomeClass ) ;
A Template Pointcut is particularly useful to relieve the one who reuses the aspect from understanding details of the modules where the aspect takes effect. 5
Template Method is an elementary and common pattern for enabling framework specialization, where adaptation is achieved by subclassing. The role of the hook methods that have to be overridden is often to plug objects on the application.
How to define hook methods for the purpose of enabling object plugging, so that they are intuitive to use? – Reuse interfaces should be as simple as possible. By reading a hook method signature, it should be intuitive what the method has to do and how. – The less framework methods that one has to know for building an application, the better.
Define hook methods that expose in their parameters objects that are instantiated by the framework. These exposed objects are accessed by applications for composing other objects. The intent of a Composition Hook Method (Figure 6) is intuitively given by the method signature, while the way how to plug objects on the exposed object is given by its interface.
<<abstract>>
AbstractClass -object : Obj compositionHookMethod(Obj) templateMethod()
ConcreteClass compositionHookMethod(Obj) // ... object = new Obj(); compositionHookMethod(object); // ...
compositionHookMethod(Obj o) { o.add(new OtherObj()); // ...
}
Considering the example framework, the abstract class AbstractApplication could be something like shown below. The class constructor is the template method, and there are two Composition Hook Methods for plugging actions and menus. – There is no need for additional methods whose purpose is to do the object compositions, which are done through the interface of the exposed objects. – The way how to use hook methods is intuitive by reading their signature.
The main class of a JHotDraw-based application has to override Composition Hook Methods for plugging menus and the tools that create the figures. A viewpart of an application based on Eclipse RCP has a Composition Hook Method for plugging GUI elements.
The reader may indeed find a Template Method and this pattern very alike. However, the purpose of a Template Method is more generic, and the hook methods may have purposes other than enabling object composition.
By overriding a Composition Hook Method the variation is achieved through the exposed object. The type of objects that can be composed in the exposed objects is known, and there are methods in the objects’ interface specifically for that purpose. Therefore, the body of an overridden Composition Hook Method is predictable in what respects to the method invocations on the exposed object. For instance, the only purpose of the exposed object of type ActionBar in the given example is to perform register() calls with objects of type Action as arguments. All the implementations of this Composition Hook Method will be similar across framework-based applications.
A Composition Hook Method may become hidden from application developers, so that they will not need to deal with it when building an application. In order to do so, a Self-Pluggable Object is capable of dismissing the need of overriding the Composition Hook Method. 6
Framework classes have Composition Hook Methods.
How to hide a Composition Hook Method from the reuse interface, so that there is one less framework element that application developers have to know about? Forces – Usually the type of the objects we want to plug is easy to find. Finding the way how to plug the objects is the most difficult part, since the framework user has to understand the interface of the object where plugging takes place. – The less hook methods that have to be known and dealt by application developers, the better. – The lack of documentation may cause application developers to plug objects in wrong locations, resulting in incorrect uses of the framework.
Develop an abstract aspect that encapsulates the behavior that creates and plugs the object in a Composition Hook Method. Use a Template Pointcut where the fixed part defines the Composition Hook Method and the variable part (hook) is intended to match a subclass of the template class that owns that method. Application developers use a Self-Pluggable Object (Figure 7) by extending the aspect and defining the hook pointcut on the desired context. <<aspect, abstract>>
SelfPluggableObject <<pointcut>> context() : AbstractContext <<advice>> AbstractContext.hookMethod() && context() <<aspect>>
Object
This pattern is illustrated by presenting a solution for improving the plugging menus scenario given in Section 2. The Composition Hook Method is AbstractApplication.createMenus(). Since this method will not need to be overridden by applications, it may have reduced visibility and be locked for overriding, as shown below. p u b l i c a b s t r a c t c l a s s A b s t r a c t A p p l i c a t i o n { /∗ . . . ∗/ f i n a l v o i d c re ate Me nus ( MenuBar m bar ) { } } The following is a reusable aspect for plugging menus. The menu name is given in the constructor, while the menu is created by createMenu() using that name. The hook pointcut is application(). The advice creates the menu and plugs it on the MenuBar object parameter of createMenus(..). Using an independent method for creating the menu facilitates the collaboration with other aspects. p u b l i c a b s t r a c t a s p e c t Menu { p r i v a t e S t r i n g name ; p u b l i c Menu ( S t r i n g name ) {
t h i s . name = name ; } } }
} p r o t e c t e d a b s t r a c t p o i n t c u t a p p l i c a t i o n ( ) ; a f t e r ( MenuBar mb) : w i t h i n ( A b s t r a c t A p p l i c a t i o n +) && a p p l i c a t i o n ( ) && e x e c u t i o n ( v o i d c re ate Me nus ( MenuBar ) ) && a r g s (mb) {
mb . add ( createMenu ( ) ) ; IMenu createMenu ( ) { r e t u r n new MenuImpl ( name ) ; The main class of an application (subclass of AbstractApplication) does not need to override createMenus(..). ExampleApplication would be given like shown below. p u b l i c c l a s s E x a m p l e A p p l i c a t i o n e x t e n d s A b s t r a c t A p p l i c a t i o n { } }
} In order to plug a menu, a subaspect of Menu has to be defined. The following is an example of how to plug a menu (“Menu1”) in ExampleApplication. p r o t e c t e d p o i n t c u t a p p l i c a t i o n ( ) : t a r g e t ( E x a m p l e A p p l i c a t i o n ) ; In case the order of multiple Self-Pluggable Objects of the same type is relevant, precedences have to be used to explicitly declare the order in which the several objects are plugged. The following example shows how it could be declared that Menu1 is to be plugged before MenuX. p u b l i c a s p e c t MenuOrder {
d e c l a r e p r e c e d e n c e : MenuX , Menu1 ; } The precedence declaration may be given in an independent module as shown, but it can also be given together with the other modules. Resulting Context – Application developers no longer have to deal with the Composition Hook Method. Instead, they implement an independent aspect, which defines the hook pointcut. – Objects can be plugged in other objects incrementally, without the need of modify, inspect, or understand, code related to the object where composition takes place. – Changing the context where the object is composed can be done only by changing the hook pointcut definition. – Framework-based applications are adaptable without the need of understanding or modifying source code. Removing a Self-Pluggable Object can simply be done by recompiling the application without its module (e.g. deactivating Menu1 as a compilation unit). Self-Pluggable Objects in JHotDraw can plug menus, tools, and undo on tools. Self-Pluggable Objects in Eclipse RCP can plug the toolbar, perspectives, and viewparts (an application can have several viewparts, which are organized in different perspectives).
The Decorator pattern [
A Self-Pluggable Object can be plugged in another Self-Pluggable Object. This can be done by intercepting the creation of objects in order to plug other objects in them, or by completing Composition Hook Methods, which Self-Pluggable Objects may have. A Self-Pluggable Object may be a Multi-Context SelfPluggable Object if the object can be plugged in different application contexts. A Self-Pluggable Object may be based on an Abstract Self-Pluggable Object if there are multiple subtypes of the pluggable object. A Self-Pluggable Type Hierarchy merges the type implementations with their abstract composition (i.e. plugging). An Association Object enables the establishment of associations between Self-Pluggable Objects. 7
A Self-Pluggable Object is an object that plugs itself in a certain application context. However, there are objects which can be plugged in different application contexts.
How to develop a Self-Pluggable Object that can be plugged in more than one application context? Forces – It is appealing to have everything what is possible to do with an object represented in a single module. By knowing about that module, an application developer knows all that can be done with the object. – If we would have a Self-Pluggable Object for each application context, there would be multiple modules for addressing a single concept.
Develop an aspect similar to a Self-Pluggable Object, which has one advice for each Composition Hook Method related with an application context. The hook pointcut is used in the different advices. When using the Multi-Context Self-Pluggable Object (Figure 8), the context is given by the module that is matched by the hook pointcut, implying that only the advice related to that application context will take effect.
<<aspect, abstract>>
MultiContextSelfPluggableObject <<pointcut>> context() : AbstractContext1 || AbstractContext2 <<advice>> AbstractContext1.hookMethod1() && context() <<advice>> AbstractContext2.hookMethod2() && context() <<class/aspect, abstract>>
AbstractContext1 ~ <<final>> hookMethod1()
<<aspect>> ObjectOnContext2 <<class/aspect, abstract>>
AbstractContext2 ~ <<final>> hookMethod2() <<class/aspect>>
Context1
This pattern is illustrated by evolving the previous example, while addressing the improvement of the menu context scenario given in Section 2. Besides the application, a (sub-)menu can also be composed in another menu. Therefore, a menu can be used in more than one application context. The following is a new version of Menu, containing two advices. The first is like in the previous example, while the second is for addressing the composition of menus and sub-menus. /∗ t o match an e x t e n s i o n o f e i t h e r A b s t r a c t A p p l i c a t i o n or Menu ∗/ p r o t e c t e d p o i n t c u t c o n t e x t ( ) ; The following module would plug the menu “Menu1” in ExampleApplication (very similar to the example given previously). p r o t e c t e d p o i n t c u t c o n t e x t ( ) : t a r g e t ( E x a m p l e A p p l i c a t i o n ) ; The following module would plug the menu “Menu2” in the “Menu1”. p u b l i c a s p e c t Menu2 e x t e n d s Menu { p u b l i c Menu2 ( ) {
s u p e r ( ”Menu2” ) ; p r o t e c t e d p o i n t c u t c o n t e x t ( ) : t a r g e t ( Menu1 ) ;
} } – Everything that can be done in an application with an object is achieved through the same module. – Changing the context where the object is composed, including different context types, can be done just by changing the hook pointcut definition in the object’s module.
A Multi-Context Self-Pluggable Object in Eclipse RCP can plug menus, whose context may be (a) the application menu bar (conventional
menu), (b) a certain viewpart (only shown in there), and (c) a certain viewer (appears as a pop-up menu).
A Multi-Context Self-Pluggable Object is a special kind of SelfPluggable Object. 8
Objects are plugged using Self-Pluggable Objects. A common case in frameworks is that objects of a certain type (e.g. represented by an interface) may be plugged in an application, and therefore, several subtypes of that type can be plugged in the same way.
When having a hierarchy of types whose objects can be plugged in an application, if we would have a Self-Pluggable Object for each one, there would exist duplicated code, given that all the objects are plugged in the same way. How to generalize the common behavior that is necessary to plug objects of a certain type? – Code reuse should be maximized. – A Self-Pluggable Type Hierarchy is also suitable to structure
Self-Pluggable Objects, but this option is not always viable. Develop an aspect similar to a Self-Pluggable Object, but with a Template Advice where the creation of the object to be plugged is done by a Factory Method (abstract method). This Abstract Self-Pluggable Object (Figure 9) should not be visible to applications. Develop one abstract aspect inheriting from it for each type to be plugged, where the implementation of the Factory Method returns the proper object. If application-specific objects of that type are allowed to be plugged, develop also an abstract aspect that implements the type but which does not implement the methods of the type, so that they can be given in application modules. An application developer may use one of the visible aspects by extending it and defining the hook pointcut. In case the application-specific type is intended to be implemented, the application developer extends the aspect for that purpose, and in addition to the hook pointcut definition, the type’s methods have to be implemented. factoryMethod() { return this; } <<interface>>
Type method() : ...
SubType1 method() : ...
SubType2 method() : ...
Type object = factoryMethod(); /* plug object */
<<aspect, abstract>>
AbstractSelfPluggableObject <<pointcut>> context() : AbstractContext <<advice>> : ... && context() factoryMethod() : Type <<aspect, abstract>> SelfPluggableType factoryMethod() : Type method() : ...
<<aspect>>
ObjectOfType method() : ...
<<aspect, abstract>> SelfPluggagleSubType1 factoryMethod() : SubType1
<<aspect, abstract>> SelfPluggableSubType2 factoryMethod() : SubType2 This pattern is illustrated with the plugging of actions in the example framework. The case of actions is very similar to the plugging menus scenario described in Section 2. Applications may include actions by plugging objects of type IAction. The following is an Abstract Self-Pluggable Object for this purpose. Except for the Template Advice, the solution is analogous to a Self-Pluggable Object. a b s t r a c t a s p e c t A b s t r a c t A c t i o n { p r o t e c t e d a b s t r a c t p o i n t c u t a p p l i c a t i o n ( ) ; a f t e r ( A c t i o n B a r ab ) : w i t h i n ( A b s t r a c t A p p l i c a t i o n +) && a p p l i c a t i o n ( ) && e x e c u t i o n ( v o i d c r e a t e A c t i o n s ( A c t i o n B a r ) ) && a r g s ( ab ) { p r o t e c t e d a b s t r a c t I A c t i o n c r e a t e A c t i o n ( ) ; p u b l i c a b s t r a c t run ( ) ; p r o t e c t e d I A c t i o n c r e a t e A c t i o n ( ) {
r e t u r n t h i s ;
The following module illustrates how Exit could be used, by plugging the exit action in ExampleApplication. p u b l i c a s p e c t ExitOnExample e x t e n d s E x i t {
p r o t e c t e d p o i n t c u t a p p l i c a t i o n ( ) : t a r g e t ( E x a m p l e A p p l i c a t i o n ) ; The aspect that allows the plugging of application-specific actions could be implemented like shown below. The aspect implements IAction, but it is up to applications to implement the interface methods (run() in this case). p u b l i c a b s t r a c t a s p e c t A c t i o n e x t e n d s A b s t r a c t A c t i o n
implements I A c t i o n { The above aspect can be extended by Self-Pluggable Objects, which can be used by application developers. The following is an example SelfPluggable Object, based on the Abstract Self-Pluggable Object, for addressing the exit action. The aspect overrides createAction() for returning an instance of the framework class ExitAction. p u b l i c a b s t r a c t a s p e c t E x i t e x t e n d s A b s t r a c t A c t i o n { p r o t e c t e d I A c t i o n c r e a t e A c t i o n ( ) {
r e t u r n new E x i t A c t i o n ( ) ; The following module illustrates how Action could be used. In addition to the hook pointcut definition, the method implementation is given. p u b l i c a s p e c t ExampleAction e x t e n d s A c t i o n { p u b l i c v o i d run ( ) {
/∗ a p p l i c a t i o n −s p e c i f i c a c t i o n implementation ∗/ – The plugging of objects of a certain type is generalized. Support for new types can be added simply by developing an aspect module that overrides the Factory Method (e.g. as in Exit). – The code of the modules that extend the Abstract Self-Pluggable Object still has some redundancy given that the implementation of the Factory Methods across the several modules is very similar (only the name of the class changes). – The number of subaspects grows along with the number of frameworkprovided type implementations, implying one more framework module for each one (i.e. the aspect).
In Eclipse RCP, an Abstract Self-Pluggable Object can generalize the plugging of actions, which may be either chosen from a set of framework-provided actions or implemented by applications. In JHotDraw there is an analogous case for plugging commands.
An Abstract Self-Pluggable Object serves the purpose of structuring a set of related Self-Pluggable Objects, and consists of an alternative to a Self-Pluggable Type Hierarchy. 9
An Abstract Self-Pluggable Object is capable of generalizing the plugging of objects of a certain type, implying that there will exist an aspect for each type. All these subaspects are similar and only differ in the object instance returned by the Factory Method.
How to avoid the existence of all the similar subaspects, and therefore, to reduce the number of framework modules?
– In solutions based on an Abstract Self-Pluggable Object, the number of subaspects grows along with the number of frameworkprovided type implementations. The disadvantage is that the solution implies one Self-Pluggable Object for each pluggable type. Merge the implementation of a type hierarchy of default components with the Self-Pluggable Objects that implement the composition of objects of that type. In order to do so, develop an aspect similar to a SelfPluggable Object that is of the top-most type of the hierarchy (i.e. it declares that it implements that type), while it does not implement the type’s methods. Develop a subaspect for each subtype, where the type methods are implemented. These aspects may represent partial type implementations by implementing a subset of the type methods, while leaving the remaining methods to applications. Application developers can use the appropriate member of the Self-Pluggable Type Hierarchy (Figure 10) that implements the type they wish to use. If an application has to include its own implementation of the type, it extends the top-most aspect.
This pattern is illustrated with the same case of the actions in the example framework, as it consists of an alternative solution to the one given in Section 8.
The following is a new version of Action that can be used in the same way by application developers (exemplified in Section 8). The aspect is of type IAction, and registers itself as an action. p u b l i c a b s t r a c t aspect A c t i o n implements I A c t i o n { p r o t e c t e d a b s t r a c t p o i n t c u t a p p l i c a t i o n ( ) ; a f t e r ( ActionBar ab ) : w i t h i n ( A b s t r a c t A p p l i c a t i o n +) && a p p l i c a t i o n ( ) && e x e c u t i o n ( v o i d c r e a t e A c t i o n s ( ActionBar ) ) && a r g s ( ab ) {
ab . r e g i s t e r ( t h i s ) ; }
} p u b l i c a b s t r a c t v o i d run ( ) ; The following is a new version of Exit that can be used in the same way by application developers (as given in Section 8).
<<aspect>> ObjectOfSubType1 <<context>> <<interface>>
Type method1() : ... method2() : ...
<<aspect, abstract>>
SelfPluggableAbstractType <<pointcut>> context() : AbstractContext <<advice>> ... && context()
<<aspect>> ObjectOfType method1() : ... method2() : ... ... – Less framework modules when comparing with a solution based on an Abstract Self-Pluggable Object, and more elegant given the nonexistence of all the similar subaspects for each pluggable type. – The types addressed by the Self-Pluggable Type Hierarchy cannot be instantiated independently.
In JHotDraw, a Self-Pluggable Type Hierarchy is capable of organizing the framework-provided figures and connection figures. In order to use an application-specific figure, application developers may extend a member of the hierarchy, which may be the top element for implementing a completely new figure, or a lower one in case if the figure is intended to be based on an existing one.
If merging the implementation of the types with Self-Pluggable Objects is not possible due to some constraint, a solution based on an Abstract Self-Pluggable Object can be used instead. 10
Objects are plugged in an application using Self-Pluggable Objects or Multi-Context Self-Pluggable Objects. The objects plugged in an application may need to have other associations between them. The plugged objects are not visible to application developers, so that they can define the associations. How to establish an association between two Self-Pluggable Objects? – Having the possibility of managing object associations independently is advantageous because application features relying on associations may be plugged and unplugged without modifying other modules. – Given that the objects are handled by Self-Pluggable Objects, it makes sense to define associations in terms of these modules.
Develop an abstract aspect, which when made concrete encapsulates an association between two objects — an Association Object (Figure 11). Use two Template Pointcuts to capture the creation of the objects, each one with its own advice. One advice captures and stores a reference to one of the objects, while the other advice uses that reference to establish the association with its captured object. Application developers can establish an association by defining the hook pointcuts on the modules representing the two objects to be associated. An Association Object can be defined in terms of an Abstract Self-Pluggable Object or the top-level aspect of a Self-Pluggable Type Hierarchy. This enables that the association can be established between any object whose type is a subtype of the type addressed by either the Abstract Self-Pluggable Object or the Self-Pluggable Type Hierarchy. <<aspect, abstract>>
AssociationObject -obj1 : Type1 <<pointcut>> object1() : SelfPluggableObject1 <<advice>> SelfPluggableObject1.constructor() && object1() <<aspect, abstract>> SelfPluggableObject1 ... constructor() : Type1 <<aspect>>
Object1 ...
<<aspect>>
Association <<object1>> <<object2>>
<<aspect, abstract>> SelfPluggableObject2 ... constructor() : Type2 <<aspect>>
Object2 ...
Fig. 11. Association Object pattern.
/* store returned object */ obj1 = ... /* get returned object */ Type2 obj2 = ... obj2.compose(obj1); <<interface>>
Type2 compose(Type1) : void ...
This pattern is illustrated by presenting a solution for improving the associating actions scenario given in Section 2. Below we present the aspect that enables the encapsulation of such associations, assuming the specialization aspect Action from Section 9 and the specialization aspect Menu from Section 7. The first advice captures the instantiation of a subaspect of Action, which is itself an object of type IAction, while the second advice includes the captured action in a menu captured from the execution of createMenu() within a subaspect of Menu. p u b l i c a b s t r a c t a s p e c t MenuAction { p r o t e c t e d a b s t r a c t p o i n t c u t a c t i o n ( ) ; p r o t e c t e d a b s t r a c t p o i n t c u t menu ( ) ; p r i v a t e I A c t i o n a ; a f t e r ( I A c t i o n a ) : w i t h i n ( A c t i o n +) && a c t i o n ( ) && e x e c u t i o n ( A c t i o n . new ( . . ) ) && t h i s ( a ) { t h i s . a = a ; Assuming the Self-Pluggable Objects Menu1 and ExitOnExample given previously, the following aspect implements the association that places the exit action on “Menu1”. p u b l i c aspect ExitOnMenu1 extends MenuAction { p r o t e c t e d p o i n t c u t a c t i o n ( ) : t a r g e t ( ExitOnExample ) ; p r o t e c t e d p o i n t c u t menu ( ) : t a r g e t ( Menu1 ) ; In JHotDraw an Association Object can define the valid source and target figures which a connection figure may connect. However, the solution is a bit different than the one in the example, since the valid connections are given by overriding a hook method of the connection figure. In Eclipse RCP, Association Objects may link the actions and the toolbar, the actions and the menus, or the viewparts and the perspectives. An Association Object may be adaptable by having Composition Hook Methods, which in turn can be completed by Self-Pluggable Objects. 11 This section revisits the example framework, taking into account the Modular Hot Spots pattern language given throughout sections 6-10. Figure 12 depicts the new reuse interface after applying the patterns. We can see the several abstract modules (gray) and their abstract pointcuts. Regarding the menus, the example of Section 7 is considered (MultiContext Self-Pluggable Object), instead of the one given in Section 6. Regarding the actions, the examples of Section 9 are considered (Self-Pluggable Type Hierarchy), instead of the ones of Section 8.
<<abstract>> AbstractApplication <<aspect, abstract>>
Menu <<poincut>> context() : AbstractApplication || Menu <<aspect, abstract>>
MenuAction <<poincut>> menu() : Menu <<poincut>> action() : Action <<application>>
<<aspect>> ExampleAction run() : void <<aspect, abstract>>
Exit <<application>> <<aspect>>
Menu1 <<aspect>> ExitOnExample <<action>> Fig. 12. Modular Hot Spots for the example framework (in gray) and example application (in white). 1. Each of the application concepts (i.e. application, menu, action, exit, and menu action) can be used incrementally, where each concept instance is implemented in an independent module. Throughout the pattern examples a framework-based application was given in the modules ExampleApplication (Section 6), Menu1 and Menu2 (Section 7), ExitOnExample and ExampleAction (Section 8), and ExitOnMenu1 (Section 10). 2. Without source code modification, the application may be compiled with subsets of the modules enumerated in (1), obtaining variants of the application. This issue is particularly important in the context of software product-lines. For instance, one could have a variant of the application without the “Menu2”, just by not including that module in the compilation. 3. Application features can be removed without understanding source code, as far as one knows which application elements the modules are representing (a fairly basic information that is easy to maintain). This issue facilitates the maintenance and reengineering of frameworkbased applications. For instance, suppose that the application implemented by the modules enumerated in (1) needs to be changed for a new version without the ExampleAction. If the task is given to a programmer that was not the one who developed the application in first place, his or her task becomes facilitated, given that only that module has to be identified and removed, while no understanding of the existing code is necessary. 4. The associations between menus and actions can be independently and non-invasively defined. 5. The two hook methods of AbstractApplication, plus the two methods of Menu, of the conventional reuse interface, no longer have to be dealt with by applications. Instead, there are pointcuts that assume their role. The advantages of the latter is that compositions can take place without modifications and inspection of the target modules. 6. The two classes MenuBar and ActionBar are no longer relevant for the application developer.
The items (1), (2), and (3) are related with the improvement of the plugging menus and menu context scenarios given in Section 2. Item (4) is related with the improvement of the associating actions scenario also given in Section 2. 12
This paper presented Modular Hot Spots, a pattern language for helping on the task of developing framework reuse interfaces with a higher abstraction level concerning the development of framework-based applications. The application of the given patterns relies on aspect-oriented programming primitives. However, the required knowledge of this programming paradigm is small, if we consider the whole set of primitives that these languages offer.
Modular Hot Spots can form a black-box reuse interface with a higher level of abstraction than conventional black-box reuse interfaces.
We would like to thank our EuroPLOP’08 shepherd Uir´a Kulesza, and the Writer’s Workshop participants Paul G. Austrem, Dietmar Schu¨tz, Diethelm Bienhaus, and Ju¨rgen Salecker, for the valuable suggestions for improving this paper.