combination of aspect-oriented design patternsvranic/pub/lu/lect2.pdf · combination of...

Combination of Aspect-Oriented Design Patterns


Erasmus Mobility at Lancaster University

Lecture 2

Valentino Vranić

Institute of Informatics and Software EngineeringFaculty of Informatics and Information Technologies

Slovak University of TechnologyBratislava, Slovakia

[email protected]://fiit.stuba.sk/~vranic/

September 16–19, 2008

1 / 31

[email protected]

http://fiit.stuba.sk/~vranic/


Overview

1 Introduction

2 Generally Applicable Aspect-Oriented Change Types

3 Structural Categorization of Aspect-Oriented Design Patterns

4 Combining Aspect-Oriented Design Patterns

5 Regularity in Aspect-Oriented Design Pattern Combination

6 Related Work

7 Summary

2 / 31

Combination of Aspect-Oriented Design PatternsIntroduction

IntroductionThe notion of pattern in its original sense proposed byAlexander was indivisible of the notion of pattern language1

Software patterns are often perceived as more or lessindependently applied sublimated pieces of developmentexperience2

We tend first to discover new patterns and then think of theopportunities of their combinationThis also applies to aspect-oriented design patterns beingdiscovered both on individual basis3 4 5 and as patternlanguages 6

1C. Alexander. The Timeless Way of Building. Oxford University Press, 1979.2J. O. Coplien. The culture of patterns. Computer Science and Information Systems (ComSIS),

1(2), November 2004.3R. Laddad. AspectJ in Action: Practical Aspect-Oriented Programming. Manning, 2003.4R. Miles. AspectJ Cookbook. O’Reilly, 2004.5A. Schmidmeier. Patterns and an antiidiom for aspect oriented programming. In Proc. of 9th

European Conf. on Pattern Languages of Programs, EuroPLoP 2004, Irsee, Germany, July 2004.6S. Hanenberg, A. Schmidmeier, and R. Unland. Aspectj idioms for aspect-oriented software

construction. In Proc. of 8th European Conf. on Pattern Languages of Programs, EuroPLoP 2003,Irsee, Germany, June 2003. 3 / 31

Combination of Aspect-Oriented Design PatternsGenerally Applicable Aspect-Oriented Change Types

The Catalog of Changes in Web Application Domain (1)

Integration ChangesOne Way Integration: Performing Action After EventTwo Way Integration: Performing Action After Event

Grid Display ChangesAdding Column to Grid: Performing Action After EventRemoving Column from Grid: Method SubstitutionAltering Column Presentation in Grid: Method Substitution

4 / 31


The Catalog of Changes in Web Application Domain (2)

Input Form ChangesAdding Fields to Form: Enumeration Modification withAdditional Return Value Checking/ModificationRemoving Fields from Form: Additional Return ValueChecking/ModificationIntroducing Additional Constraint on Fields: AdditionalParameter Checking or Performing Action After Event

Introducing User Rights Management: Border Control withMethod SubstitutionUser Interface Restriction: Additional Return ValueChecking/ModificationsIntroducing Resource Backup: Class Exchange

5 / 31


Generally Applicable Aspect-Oriented Change Types

Performing Action After EventMethod SubstitutionEnumeration ModificationAdditional Return Value Checking/ModificationAdditional Parameter CheckingPerforming Action After EventBorder ControlClass Exchange = Cuckoo’s Egg

6 / 31


Code Schemes or Patterns?

What is a pattern?Some proclaimed aspect-oriented design patterns are quitesimple (consider Border Control)Couldn’t the generally applicable change types be consideredas patterns?Patterns or idioms?

7 / 31

Combination of Aspect-Oriented Design PatternsStructural Categorization of Aspect-Oriented Design Patterns

Aspect-Oriented Programming and AspectJ

Crosscutting concerns are implemented as aspectsVariety of aspect-oriented approaches and languagesAspectJ is the most widely used and influential aspect-orientedlanguageThe key issue is to identify and specify places where thecrosscutting code affects the rest of the codeSuch places are called join points and they are specified bypointcutsAdditional behavior to be performed before, after, or instead ofjoin points is specified in advicesInter-type declarations enable introduction of new membersinto existing types, as well as introduction of compile warningsand errors

8 / 31


Aspect-Oriented Design Patterns

A closer look at the structure of four particular aspect-orienteddesign patternsStructural categorization of aspect-oriented design patternsApplying the combination of aspect-oriented design patterns tothe problem of class deprecation in team developmentGeneralize the dependencies between aspect-oriented designpatterns in their subsequent application

9 / 31


Border Control

Used to define regions in the applicationThe regions are intended for use by other aspects to ensurethey are applied only to appropriate placesThis is convenient also when the system changes are expected

Only declarations of regions in the Border Control aspectshould be changedOther aspects which are using these declarations will beautomatically redirected

public aspect MyRegionSeparator {public pointcut myTypes1(): within(mypackage1.+);public pointcut myTypes2(): within(mypackage2.+);public pointcut myTypes(): myTypes1() || myTypes2();public pointcut myMainMethod():

withincode(public void mypackage2.MyClass.main(..));. . .

}

10 / 31


Cuckoo’s Egg

Enables to put another object instead of the one that thecreator expected to receive (similar to what a cuckoo doeswith its eggs)public aspect MyClassSwapper {

public pointcut myConstructors():call(MyClass1.new()) || call(MyClass2.new());

Object around(): myConstructors() {return new AnotherClass();

}}

Several types can be covered by swappingSwapping can be restricted with respect to the place ofconstructionNote: the swapping object must be a subtype of the originalobject class

11 / 31


Policy

Defines a policy or rules within the applicationBreaking of such a rule or policy should result in issuing acompiler warning or errorUseful in projects that involve many developers

public abstract aspect GeneralPolicy {protected abstract pointcut warnAbout();

declare warning: warnAbout(): "Warning...";}

public aspect MyAppPolicy extends ProjectPolicy {protected pointcut warnAbout():

call(∗ ∗.myMethod(..)) || call(∗ ∗.myMethod2());}

12 / 31


Exception Introduction (1)

If an advice calls a method that throws a checked exception, itis forced to cope with itSometimes, it is not possible to handle the exception in theadvice, so it has to be thrown to a higher contextBut in AspectJ an advice cannot declare throwing a checkedexception unless the advised joint point declared thisexception, which is unlikely since base concerns are mostly notexpected to be adapted to their aspects

13 / 31


Exception Introduction (2)

Exception Introduction7 catches a checked exception andwrappes it into a new concern-specific runtime exceptionspublic abstract aspect ConcernAspect {

abstract pointcut operations();

before(): operations() {try {

concernLogic();} catch (ConcernCheckedException ex) {

throw new ConcernRuntimeException(ex);}

}void concernLogic() throws ConcernCheckedException {

. . .}

}

7R. Laddad. AspectJ in Action: Practical Aspect-Oriented Programming14 / 31


Aspect-Oriented Design Pattern Categories

Each aspect-oriented design pattern comprises at least oneaspectIn the aspects of each pattern one of the three main parts ofan aspect, i.e. a pointcut, advice, or inter-type declarations,prevails in achieving the purpose of the patternAccording to the element that dominates, aspect-orienteddesign patterns can be divided into:

Pointcut patternsAdvice patternsInter-type declaration patterns

15 / 31


Pointcut Patterns

Border Control is a pointcut patternIt actually contains no other elements than pointcutsOther examples:8

Wormhole employs pointcuts to connect a method callee witha caller so they can share their context informationParticipant enables a class decide whether it will allow anaspect to affect it by declaring an appropriate pointcut



Advice Patterns

Cuckoo’s Egg is an advice patternOther examples:9

Worker Object Creation—aka Proceed Object10—captures theoriginal method execution into a runnable object to bemanipulated furtherException Introduction resolves inability of advices in AspectJto throw checked exceptions

9R. Laddad. AspectJ in Action: Practical Aspect-Oriented Programming10A. Schmidmeier. Patterns and an antiidiom for aspect oriented programming. In Proc. of 9th

European Conf. on Pattern Languages of Programs, EuroPLoP 2004, Irsee, Germany, July 2004.17 / 31


Inter-Type Declaration Patterns

Policy is an inter-type declaration patternAnother example is Default Interface Implementation11 whichemploys inter-type declarations to introduce fully implementedmethods into interfaces.Denoted as idiom by Laddad


Combination of Aspect-Oriented Design PatternsCombining Aspect-Oriented Design Patterns

Invoking an Example: Class Deprecation

Team development requires developers to obey some commonrules and policiesFrequently, a new version of a class is introduced into theframeworkThe old version of the class cannot be simply replaced with thenew one at onceA new class has to be tested for some time during which it iscommon to have and use both versionsAll developers should be kept informed of the new class versionand warned—or sometimes even forced—to use itThe best way is to incorporate this information into the buildprocess (compilation warnings and errors)Sometimes a new version should swap the old one

19 / 31


Class Deprecation Warning

Suppose the instantiation of OldClass is deprecatedAssume it is sufficient to issue a warning in case of deprecatedclass instantiationPolicy can be applied to achieve thispublic aspect OldClassDeprecation {

declare warning: call(∗.OldClass.new()): "Class OldClass deprecated.";}

AspectJ 5 supports declaring annotations, so a standard@deprecated annotation can be introduced instead of a generalwarning with a custom messagepublic aspect OldClassDeprecation {

declare @constructor: OldClass.new(): @deprecated;}

This approach was not used because annotations declarationsare made on type patterns, not pointcuts, which posessignificant limitations 20 / 31


Partial Class Deprecation (1)

Assume OldClass can be used within the testing package andthird party codeBorder Control can be applied to partion the code into regionspublic aspect Regions {

public pointcut Testing(): within(com.myapplication.testing.+);public pointcut MyApplication(): within(com.myapplication.+);public pointcut ThirdParty(): within(com.myapplication.thirdpartylibrary.+);public pointcut ClassSwitcher(): within(com.myapplication.ClassSwitcher);

}

Afterwards, OldClassDeprecation aspect has to be adapted:public aspect OldClassDeprecation {

protected pointcut allowedUse():Regions.ThirdParty() || Regions.Testing();

declare warning:call(Display.new()) && !allowedUse(): "Class OldClass deprecated.";

}21 / 31


Partial Class Deprecation (2)

By this, we actually combined a Policy with an existing BorderControlThus, combining a pointcut pattern with an existing inter-typedeclaration pattern requires changes in the existing inter-typedeclaration patternIf we knew there will be exemptions from banning the use ofOldClass, it would be possible to apply Border Control firstwith Policy pattern added without having to change theexisting codeThus, combining an inter-type declaration pattern with anexisting pointcut pattern can be performed without having tochange the existing pattern

22 / 31


Class Swapping

Now we want to make a change from OldClass to NewClassautomatic while keeping developers informed of attempts toinstantiate OldClass in prohibited regionsThis may be achieved with Cuckoo’s Eggpublic aspect OldClassDeprecation {

public pointcut oldClassConstructor():call(∗.OldClass.new()) &&!Regions.ThirdParty() && !Regions.Testing();

Object around(): oldClassConstructor() {return new MyApplication.NewClass();

}}

Cuckoo’s Egg uses the pointcuts defined in Border ControlThus, combining an advice pattern with an existing pointcutpattern can be made without changes in the existing pointcutpattern 23 / 31


Adding Logging (1)

Assume there is a need to log the swapping of the deprecatedclass with the new oneIt looks simple: the logging code could be simply added to theCuckoo’s Egg adviceBut we have to deal with IOException in the advice, and an itcan’t declare throwing of an exception that was not declaredby the advised join point

24 / 31


Adding Logging (2)

Exception Introduction can resolve thispublic class SwitchLoggingException extends RuntimeException {

public SwitchLoggingException(Throwable cause) { super(cause); }}

public aspect SwitchLogging {before(): adviceexecution() && Regions.ClassSwitcher() {

try {logSwapEvent()

} catch(IOException e) {throw new SwitchLoggingException(e);

}}

Exception Introduction was added to the existing Cockoo’sEgg without having to modify itIt also uses pointcuts from the already applied Border Control

25 / 31

Combination of Aspect-Oriented Design PatternsRegularity in Aspect-Oriented Design Pattern Combination

What Combinations Require Changes? (1)

Combination of aspect-oriented design patterns is substantiallyaffected by their structural categoryUnder a combination of two patterns we understand asubsequent interrelated application of two patterns to aproblem at handThanks to the crosscutting nature of aspects, mostaspect-oriented design patterns can be combined with otherpatterns without the need to modify the already appliedpatternsException Introduction can simply be added to the programwithout having to make any change to already applied patterns

26 / 31



Policy can be used with other, already applied patternswithout having to make any changes to themIt is also possible to combine a pointcut pattern with anotherpattern of the same type without having to change thatpattern (Wormhole and Border Control)However, combining a pointcut pattern with an already appliedadvice or inter-type declaration pattern usually requires achange of this pattern (Policy and Border Control)If we go the other way around, i.e. if we combine an inter-typedeclaration pattern (e.g., Policy) or advice pattern (e.g.,Cuckoo’s Egg) with an already applied pointcut pattern (e.g.,Border Control), this can be done without having to changethemAlso, if we combine a non-pointcut pattern with Participant, ithas to be altered

27 / 31



28 / 31

Combination of Aspect-Oriented Design PatternsRelated Work

Related Work (1)

Hanenberg et al. present a set of AspectJ idioms and ascheme for their interrelated application12 (similarly to thewell-known scheme of GoF patterns)However, no attempt is made to categorize the idiomsAnalogy between categories proposed here and those proposedby Gamma et al. (behavioral, structural, and creational)13

Advice patterns recall behavioral patterns since they affectbehaviorPointcut patterns deal with how aspects are composed withclasses, objects, and other aspects, which is a paraphrase ofthe description of structural patternsInter-type declarations correspond to creational patterns to alesser extent, but we may see them as patterns of creating newelements and relationships

12S. Hanenberg, A. Schmidmeier, and R. Unland. Aspectj idioms for aspect-oriented softwareconstruction. In Proc. of 8th European Conf. on Pattern Languages of Programs, EuroPLoP 2003,Irsee, Germany, June 2003.

13E. Gamma et al. Design Patterns: Elements of Reusable Object-Oriented Software.Addison-Wesley, 1995. 29 / 31

Combination of Aspect-Oriented Design PatternsRelated Work

Related Work (2)

Class deprecation in team development can be seen as achange and as such it is related to a broader area of changecontrolAspects can be used to capture change14 15

Captured in an aspect, a change becomes pluggable andreapplicable

14V. Vranić, M. Bebjak, R. Menkyna, and P. Dolog. Developing Applications with Aspect-OrientedChange Realization. Accepted to 3rd IFIP TC2 Central and East European Conference on SoftwareEngineering Techniques CEE-SET 2008, October 2008, Brno, Czech Republic.

15M. Bebjak, V. Vranić, and P. Dolog. Evolution of web applications with aspect-oriented designpatterns. In M. Brambilla and E. Mendes, editors, Proc. of ICWE 2007 Workshops, 2nd InternationalWorkshop on Adaptation and Evolution in Web Systems Engineering, AEWSE 2007, in conjunction with7th International Conference on Web Engineering, ICWE 2007, Como, Italy, July 2007.

30 / 31

Combination of Aspect-Oriented Design PatternsSummary

Summary

A categorization of aspect-oriented design patterns has beenpresentedThree categories: pointcut, advice, and inter-type declarationpatternsThis categorization can be used in determining whether acombination of an aspect-oriented design pattern with another,already applied pattern requires a change in this patternCombination of aspect-oriented design patterns of differentcategories presented on the class deprecation problem in teamdevelopmentCombination of Policy, Border Control, Cuckoo’s Egg, andParticipantFurther work involves exploring the possibilities of employingaspect-oriented design patterns and their combinations incapturing changes in a pluggable and reapplicable way

31 / 31

combination of aspect-oriented design patternsvranic/pub/lu/lect2.pdf · combination of...

Documents