1. OPUS Group LES | DI |PUC-Rio - Brazil http://www.les.inf.puc-rio.br/opus Alessandro Cavalcante Gurgel Composing Design Patterns in CaesarJ: An Exploratory Study

2. Agenda  Introduction  Previous Studies  Background  CaesarJ  AspectJ  Case study  Design of compositions  Related Works  Conclusions  Future Works October 15Francisco Dantas et. al @ OPUS Group2

3. Introduction  GoF Design Patterns are scattered and tangled in the base code.  Design Patterns Compositions.  Sharing: methods, attributes and classes.  Modularity Problems  Special scenario for analysing both strengths and limitations of the languages. October 15Alessandro Gurgel et. al @ OPUS Group3

4. Introduction – Previous Studies  Aspectising Design Patterns  Hannemann,J., Kiczales,G. “Design Pattern Implementation in Java and AspectJ”. Proc. OOPSLA’02, Nov 2002.  Garcia, Sant’Anna, Figueiredo, Kulesza, Lucena. “Modularizing Design Patterns with Aspects: A Quantitative Study.” 4th Intl. Conf. on Aspect- Oriented Software Development (AOSD'05). 2005  Cacho, Sant’Anna, Figueiredo, Garcia, Batista, Lucena “Composing Design Patterns: A Scalability Study of Aspect-Oriented Programming.” 5th Intl. Conf. on Aspect-Oriented Software Development (AOSD'06). 2006 October 15Alessandro Gurgel et. al @ OPUS Group4

5. Introduction – Previous Studies  Aspectising Design Patterns  Hannemann,J., Kiczales,G. Design Pattern Implementation in Java and AspectJ. Proc. OOPSLA’02, Nov 2002.  Garcia, Sant’Anna, Figueiredo, Kulesza, Lucena. “Modularizing Design Patterns with Aspects: A Quantitative Study.” 4th Intl. Conf. on Aspect- Oriented Software Development (AOSD'05). 2005  Cacho, Sant’Anna, Figueiredo, Garcia, Batista, Lucena “Composing Design Patterns: A Scalability Study of Aspect-Oriented Programming.” 5th Intl. Conf. on Aspect-Oriented Software Development (AOSD'06). 2006 October 15Alessandro Gurgel et. al @ OPUS Group5 The use of AspectJ in some compositions were problematic.

6. General Goals  Propose CaesarJ solutions that resolve or minimize emerging problems from compositions of Design Patterns.  Compare qualitatively AO, OO and CaesarJ solutions  Strengths and limitations of the languages 18 JuneAlessandro Gurgel et. al @ OPUS Group6

7.  What kind of problems ?  Coupling, application restrictions, type-safe operations  Quality solution improvements  Preserving the original solution of each design pattern. October 15Alessandro Gurgel et. al @ OPUS Group7

8. Why CaesarJ ?  Support to AOP and FOP (collaborations and refinements)  Stable compiler  Applications of different domains  Extension of Java  Tutorials, examples and support of developers October 15Alessandro Gurgel et. al @ OPUS Group8

9. Background - CaesarJ  Collaboration Interfaces  Abstractions beetween components  Virtual Classes  Inner classes,  Overriden and late bound (virtual methods) October 15Alessandro Gurgel et. al @ OPUS Group9

10. Running Example - Observer October 15Alessandro Gurgel et. al @ OPUS Group10

11. Running Example - Observer October 15Alessandro Gurgel et. al @ OPUS Group11 abstract public cclass Subject Implicit Scoping! Family

12. Aspects and Wrappers - CaesarJ  Aspects  Classes that have pointcuts and advices  References to aspects can be polymorphic  Static, dynamic and instance level deployment  Wrappers  Bindings map between types from two domains by means of wrapper classes.  Wrapper-wrappee relationship.  Created on demand  Reused for the same object  Garbage collector October 15Alessandro Gurgel et. al @ OPUS Group12

13. Running Example - Observer October 15Alessandro Gurgel et. al @ OPUS Group13

14. Running Example - Observer October 15Alessandro Gurgel et. al @ OPUS Group14

15. Mixin Composition October 15Alessandro Gurgel et. al @ OPUS Group15 public cclass CO extends ObserverProtocolImpl & ColorObserver { }

16. Background - AspectJ  Per-object aspects  aspect Id perthis(Pointcut) {... }  aspect Id pertarget(Pointcut) {... }  one object of type A is created for every this/tatget object at any of the join points picked out by Pointcut  The advice defined in A will run only at a join point where the this/target object has been associated with an instance of A  A.aspectOf(Object)  aspect Id pertypewithin(org.xyz..*)  percflow and percflowbelow October 15Alessandro Gurgel et. al @ OPUS Group16

17. Case Study - OpenOrb October 15Alessandro Gurgel et. al @ OPUS Group17  Reflective middleware  GoF patterns are used and combined to satisfy the middleware modularity-related requirements  OO and AO solutions are available.

18. Open-Orb October 15Francisco Dantas et. al @ OPUS Group18

19. Chosen Compositions – Representative Compositions  Strategy and Proxy  Memento and Observer  Decorator and State  Decorator and Template Method.  Mediator and Proxy  Composite and Visitor  Prototype and State. 18 de MaioAlessandro Gurgel et. al @ OPUS Group19

20. Chosen Compositions – Problematic AspectJ solutions  Strategy and Proxy  Memento and Observer  Decorator and State  Decorator and Template Method.  Mediator and Proxy  Composite and Visitor  Prototype and State. 18 de MaioAlessandro Gurgel et. al @ OPUS Group20

21. Design of the compositions Composite and Visitor 18 de MaioAlessandro Gurgel et. al @ OPUS Group21

22. Intent of each design pattern  Visitor  Represents an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates  Composite  Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. October 15Alessandro Gurgel et. al @ OPUS Group22

23. OO: Composite and Visitor October 15Alessandro Gurgel. al @ OPUS Group23 Composite Visitor

24. AO Solution  CompositeProtocol  Componente, Leaf and Composite  Interface for visiting operations  VisitorProtocol  Leaf and Node  Problems  Attribute Overlapping ( aspectOf )  Composite code in visit operations  Non type safe visit methods  Intertype declaration  Type-cast October 15Alessandro Gurgel et. al @ OPUS Group24 HK

25. CaesarJ Solution I October 15Alessandro Gurgel et. al @ OPUS Group25 Dynamic Wrapper Selection

26. Discussions about the solution I Visitor relates with the Composite pattern by the use of wrapper relations instead of AspectOf(). The visit methods do not need to typecast its argument. It uses the respective wrapper class as argument. Dynamic Wrapper Selection - different cclasses that have the same name but wraps different classes from a common hierarchy to provide polymorphic behaviour according the wrappee object. October 15Alessandro Gurgel et. al @ OPUS Group26 This mechanism is not implemented yet.

27. Discussions about the solution I  Despite of being in the same family, the composite objects can be instatianted independently from the visitor structure.  Another option is to create a Family containing only the composite structure and then create a visitor family that extends the composite family October 15Alessandro Gurgel t. al @ OPUS Group27

28. CaesarJ Solution II October 15Alessandro Gurgel et. al @ OPUS Group28 Extensibility with new operations Extensibility with new data types. The use of virtual classes promotes:

29. Creating new data types and operations October 15Alessandro Gurgel et. al @ OPUS Group29

30. Discussions  Both solutions are in the same level of extensibility in terms of data type and operations since wrappers are also virtual classes.  In second solution, there is explicit code of composite in visit methods. In the third one, it is made by wrappee object.  Glue code – inheritance x binding October 15Alessandoro Gurgel et. al @ OPUS Group30

31. Prototype and State 18 JuneAlessandro Gurgel et. al @ OPUS Group31

32. Intent of each design pattern  Prototype  Specifies the kinds of objects to create using a prototypical instance, and creates new objects by copying this prototype.  State  Allows an object to alter its behavior when its internal state changes. The object will appear to change its class.  The pattern is also responsible for the state transitions (Context). October 15Alessandro Gurgel et. al @ OPUS Group32

33. OO: Prototype and State 18 JuneAlessandro Gurgel et. al @ OPUS Group33 Prototype State

34. AO Solution October 15Alessandro Gurgel et. al @ OPUS Group34

35. Problems of AO Solution  PrototypeAspect.aspectOf().createCloneFor()  Inter-aspect coupling.  The natural dependencies between the business classes  Declare-precedence related to other aspect that is not involved in this composition (DecoratorAspect and StateAspect) October 15Alessandro Gurgel et. al @ OPUS Group35

36. CaesarJ solution October 15Alessandro Gurgel et. al @ OPUS Group36

37. Discussions  Concrete prototypes and concrete states are defined in a modular way.  The class ConcreteBind acts like the context role in state design pattern and the client in prototype.  Instead of having coupling between aspects, the ConcreteBind has variables that are states and also prototypes. The transition of bdState uses these variables in makeRequest method. October 15Alessandro Gurgel et. al @ OPUS Group37

38. Decorator and State 18 JuneAlessandro Gurgel et. al @ OPUS Group38

39. Intent of each design pattern  State  Allows an object to alter its behavior when its internal state changes. The object will appear to change its class.  The pattern is also responsible for the state transitions (Context).  Decorator  Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. October 15Alessandro Gurgel et. al @ OPUS Group39

40. OO: Decorator and State October 15Alessandro Gurgel et. al @ OPUS Group40 State Decorator

41. AO Solution October 15Alessandro Gurgel et. al @ OPUS Group41

42. Problens of AO Solution  Since BindStateAspect and DecoratorAspect intercept the same joint point, an order of execution is established using declare precedence.  Using the DecoratorAspect there is no bound about which ConcreteBind objects will be decorated. One possible solution is to create a decorator class extending the ConcreteBind and only intercept the objects from that classes using target in the joint point designator.  perthis, pertarget do not address the problem since is not related to instances of aspects October 15Alessandro Gurgel et. al @ OPUS Group42

43. CaesarJ Solution October 15Alessandro Gurgel et. al @ OPUS Group43 The state design pattern remains the same Deploy on object instance

44. Discussion  Using CaesarJ we can obtain the same benefits of AO solution and we also can limit the objects that are decorated by the entity DecoratorCJ using the deploy on object mechanism.  Another scenarios  Mixin Composition  Wrappers October 15Alessandro Gurgel et. al @ OPUS Group44

45. Mediator and Proxy 18 JuneAlessandro Gurgel et. al @ OPUS Group45

46. Intent of each design pattern  Mediator  Defines an object that encapsulates how a set of objects interact.  Proxy  Provides a surrogate or placeholder for another object to control access to it. October 15Alessandro Gurgel et. al @ OPUS Group46

47. OO Mediator e Proxy October 15Alessandro Gurgel et. al @ OPUS Group47 Mediator Proxy Each method invoke makeRequest from ConcreteBind

48. Problems and Solutions  Described by Cacho (2006):  Central element in OpenOrb.  Unique instance of Mediator Aspect  Bottleneck in the invocation of the middleware platform – Performance  Extension of AspectJ - pertarget, perthis  CaesarJ dynamic aspect deployment  Multiple instances of ConcreteBind attached to different proxy instances October 15Alessandro Gurgel et. al @ OPUS Group48

49. Memento and Observer 18 JuneAlessandro Gurgel et. al @ OPUS Group49

50. Intent of each design pattern  Memento  Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.  Observer  Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. October 15Alessandro Gurgel et. al @ OPUS Group50

51. OO: Memento and Observer October 15Alessandro Gurgel et. al @ OPUS Group51 Memento Observer

52. AO Solution  ObserverProtocol – abstract pointcut and infrastructure for registration and notification of observers.  ObserverAspect – defines the abstract pointcut that intercepts changes in the subject.  MementoProtocol – defines interface for originator and its abstract methods.  MementoAspect – uses ID to assignment application classes to the originator role and implements its methods.  Problems  The implementation of the originator methods in the MementoAspect is not type safe. October 15Alessandro Gurgel et. al @ OPUS Group52

53. CaesarJ Solution October 15Alessandro Gurgel et. al @ OPUS Group53 Memento Observer

54. Discussion  The use of CaesarJ bindings wrappers instead of intertype declaration we ensure secure type in originator methods.  Alternative Solution:  Define Memento in each originator family  Dependent typing can ensure that the object is restored to its own memento objects only October 15Alessandro Gurgel et. al @ OPUS Group54

55. Decorator and Template Method 18 JuneAlessandro Gurgel et. al @ OPUS Group55

56. Intent of each design pattern  Decorator  Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.  Template Method  Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure. October 15Alessandro Gurgel et. al @ OPUS Group56

57. OO Solution October 15Alessandro Gurgel et. al @ OPUS Group57 Template Method Decorator Template Method

58. Discussion  Both classes DecoratorBind and MetaBind are part of Template Method and Decorator.  The implementation of Template Method is entirely contained by the Decorator.  In this composition, we preserved the solution of Decorator that was described in its composition with State. October 15Alessandro Gurgel et. al @ OPUS Group58

59. Related Works  Edgar Sousa, Miguel P. Monteiro, Implementing design patterns in CaesarJ: an exploratory study, Proceedings of the 2008 AOSD workshop.  Martin Kuhlemann, Marko Rosenmüller, Sven Apel, Thomas Leich, On the duality of aspect-oriented and feature-oriented design patterns, Proceedings of the 6th workshop on Aspects, components, and patterns for infrastructure software, 2007, Vancouver, Canada  Marot, A. and Wuyts, R. 2010. Composing aspects with aspects. In Proceedings of the 9th international Conference on Aspect-Oriented Software Development (Rennes and Saint- Malo, France, March 15 - 19, 2010). AOSD '10. ACM, New York, NY, 157-168. October 15Alessandro Gurgel et. al @ OPUS Group59

60. Conclusions  Inter-type Declarations x CaesarJ Bindings  Reuse and Polymorphism x Glue Code  Type-safe -> Dynamic Wrapper  Refactoring Process – Glue Code  This paper presented strenghts and limitations on both AspectJ and CaesarJ.  CaesarJ – equals or better solutions.  Joint point model  Dynamic, instance level deployment October 15Alessandro Gurrgel et. al @ OPUS Group60

61. Future Works  Replicate the study in other systens from different domains.  Trying reuse the same solutions  Comparing with new AOP languages like Compose*  Quantitative study  Metrics October 15Alessandro Gurrgel et. al @ OPUS Group61

62. Questions? Alessandro Gurgel agurgel@inf.puc-rio.br October 15Alessandro Gurgel et. al @ OPUS Group62