Talk at the 5th Asian Workshop on Aspect-Oriented and Modular Software Development (AOAsia \'09) at the 24th International Conference on Automated Software Engineering (ASE \'09), Auckland, New Zealand, November 17, 2009.

1. Specifying Reusable Aspects
Neelam Soundarajan and Raffi Khatchadourian
Department of Computer Science & Engineering
Ohio State University
Columbus, OH USA

2. Reuse in Object-Oriented Programming

3. Reuse in Object-Oriented Programming
• Object-Oriented Programming promotes reuse
through mechanisms such as inheritance and
polymorphism.

4. Reuse in Object-Oriented Programming
• Object-Oriented Programming promotes reuse
through mechanisms such as inheritance and
polymorphism.
• Well-known, proven techniques exist to effectively
reason about OOP.

5. Reuse in Object-Oriented Programming
• Object-Oriented Programming promotes reuse
through mechanisms such as inheritance and
polymorphism.
• Well-known, proven techniques exist to effectively
reason about OOP.
Behavioral
subtyping, separation
logic, etc.

6. Common Crosscutting Concerns

7. Common Crosscutting Concerns
• Many systems must deal with crosscutting concerns.

8. Common Crosscutting Concerns
• Many systems must deal with crosscutting concerns.
• Many crosscutting concerns appear in multiple
systems.

9. Common Crosscutting Concerns
Synchronization,
authentication, etc.
• Many systems must deal with crosscutting concerns.
• Many crosscutting concerns appear in multiple
systems.

10. Common Crosscutting Concerns
• Many systems must deal with crosscutting concerns.
• Many crosscutting concerns appear in multiple
systems.
• Application of these concerns vary in individual
systems.

11. Common Crosscutting Concerns
• Many systems must deal with crosscutting concerns.
• Many crosscutting concerns appear in multiple
systems.
• Application of these concerns vary in individual
systems.
Many
portions are
similar.

12. Reuse in Aspect-Oriented Programming

13. Reuse in Aspect-Oriented Programming
• AOP also promotes reuse through abstract aspects.

14. Reuse in Aspect-Oriented Programming
Limited form of
inheritance
• AOP also promotes reuse through abstract aspects.

15. Reuse in Aspect-Oriented Programming
• AOP also promotes reuse through abstract aspects.
• Common portions of crosscutting concern
implementations are localized in aspects that are
declared as abstract.

16. Reuse in Aspect-Oriented Programming
• AOP also promotes reuse through abstract aspects.
• Common portions of crosscutting concern
implementations are localized in aspects that are
declared as abstract.
Can be used in
many systems

17. Reuse in Aspect-Oriented Programming
• AOP also promotes reuse through abstract aspects.
• Common portions of crosscutting concern
implementations are localized in aspects that are
declared as abstract.
• Portions specific to individual systems are localized
in concrete aspects that extend the abstract aspects.

18. Reasoning about Reusable Aspects

19. Reasoning about Reusable Aspects
• Large body of work on reasoning about how base-
code is affected by aspects and vice-versa.

20. Reasoning about Reusable Aspects
• Large body of work on reasoning about how base-
code is affected by aspects and vice-versa.
• What if an aspect extends an abstract aspect?

21. Reasoning about Reusable Aspects
• Large body of work on reasoning about how base-
code is affected by aspects and vice-versa.
• What if an aspect extends an abstract aspect?
• What should behavioral specifications of abstract
aspects look like?

22. Reasoning about Reusable Aspects
• Large body of work on reasoning about how base-
code is affected by aspects and vice-versa.
• What if an aspect extends an abstract aspect?
• What should behavioral specifications of abstract
aspects look like?
• What is the relationship between specifications of
abstract aspects and that of concrete aspects?

23. Motivating Example: Observer Protocol

24. Motivating Example: Observer Protocol
• Many objects are interested
in changes to the state of a
subject object.

25. Motivating Example: Observer Protocol
• Many objects are interested
in changes to the state of a
subject object.
• Each object registers itself
with a subject as an
observer.

26. Motivating Example: Observer Protocol
• Many objects are interested
in changes to the state of a
subject object.
• Each object registers itself
with a subject as an
observer.
• Following significant state
modifications, the subject
notifies registered
observers.

27. Motivating Example: Observer Protocol
• Many objects are interested
in changes to the state of a
subject object.
• Each object registers itself
with a subject as an
observer. Scattered
• Following significant state
modifications, the subject
notifies registered
observers.

28. Motivating Example: Observer Protocol
• Many objects are interested
in changes to the state of a
subject object.
• Each object registers itself
with a subject as an
observer. Scattered
• Following significant state
modifications, the subject
notifies registered
observers.
Tangled

29. Motivating Example: Observer Protocol
• Many objects are interested
in changes to the state of a
subject object.
• Each object registers itself
with a subject as an
observer.
• Following significant state
modifications, the subject
notifies registered
observers.
• Observers are then updated
to be consistent with the
state of the subject.

30. Motivating Example: Observer Protocol
public abstract aspect Observing

31. Motivating Example: Observer Protocol
public abstract aspect Observing

32. Motivating Example: Observer Protocol
public abstract aspect Observing {
}

33. Motivating Example: Observer Protocol
public abstract aspect Observing {
interface Subject {} Type
declarations
}

34. Motivating Example: Observer Protocol
public abstract aspect Observing {
interface Subject {} Type
interface Observer { declarations
}
}

35. Motivating Example: Observer Protocol
public abstract aspect Observing {
interface Subject {} Type
interface Observer { declarations
public void update();
}
}

36. Motivating Example: Observer Protocol
public abstract aspect Observing {
interface Subject {}
interface Observer {
public void update(); Introductions
}
List<Observer> Subject.observers;
}

37. Motivating Example: Observer Protocol
public abstract aspect Observing {
interface Subject {}
interface Observer {
public void update(); Introductions
}
List<Observer> Subject.observers;
List<Subject> Observer.subjects;
}

38. Motivating Example: Observer Protocol
public abstract aspect Observing {
interface Subject {}
interface Observer {
public void update();
}
List<Observer> Subject.observers;
List<Subject> Observer.subjects;
private void Subject.notify() {
}
}

39. Motivating Example: Observer Protocol
public abstract aspect Observing {
interface Subject {}
interface Observer {
public void update();
}
List<Observer> Subject.observers;
List<Subject> Observer.subjects;
private void Subject.notify() {
for (Observer obs : observers)
obs.update();
}
}

40. Motivating Example: Observer Protocol
public abstract aspect Observing {
}

41. Motivating Example: Observer Protocol
public abstract aspect Observing {
Pointcuts
abstract pointcut subjMod(Subject s);
}

42. Motivating Example: Observer Protocol
public abstract aspect Observing {
Pointcuts
abstract pointcut subjMod(Subject s);
abstract pointcut attach(Observer o,
Subject s);
}

43. Motivating Example: Observer Protocol
public abstract aspect Observing {
Pointcuts
abstract pointcut subjMod(Subject s);
abstract pointcut attach(Observer o,
Subject s);
detach is
similar
}

44. Motivating Example: Observer Protocol
public abstract aspect Observing {
}

45. Motivating Example: Observer Protocol
public abstract aspect Observing {
Advice
after(Subject s): subjMod(s){
}
}

46. Motivating Example: Observer Protocol
public abstract aspect Observing {
Advice
after(Subject s): subjMod(s){
s.notify();
}
}

47. Motivating Example: Observer Protocol
public abstract aspect Observing {
Advice
after(Subject s): subjMod(s){
s.notify();
}
after(Observer o, Subject s) :
attach(o, s){
}
}

48. Motivating Example: Observer Protocol
public abstract aspect Observing {
Advice
after(Subject s): subjMod(s){
s.notify();
}
after(Observer o, Subject s) :
attach(o, s){
s.observers.add(o);
}
}

49. Specifying Reusable Aspects

50. Specifying Reusable Aspects
• Many reusable aspects correspond to design
patterns.

51. Specifying Reusable Aspects
• Many reusable aspects correspond to design
patterns.
• Design patterns are general descriptions of widely
accepted software practices for common problems.

52. Specifying Reusable Aspects
• Many reusable aspects correspond to design
patterns.
• Design patterns are general descriptions of widely
accepted software practices for common problems.
• Patterns are customized for specific systems.

53. Specifying Reusable Aspects
• Many reusable aspects correspond to design
patterns.
• Design patterns are general descriptions of widely
accepted software practices for common problems.
• Patterns are customized for specific systems.
• Adopt techniques for reasoning about design patterns
to reasoning about reusable aspects.

54. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?

55. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?

56. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?
• Following significant state modifications, the subject
notifies registered observers.

57. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?
• Following significant state modifications, the subject
notifies registered observers.
/∗@ abstract boolean
Modified(Subject s1, Subject s2); @∗/

58. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?

59. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?

60. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?
• Observers are then updated to be consistent with the
state of the subject.

61. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?
• Observers are then updated to be consistent with the
state of the subject.
/∗@abstract boolean
Consistent(Subject s, Observer o); @∗/

62. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?
• Observers are then updated to be consistent with the
state of the subject.
/∗@abstract boolean
Consistent(Subject s, Observer o); @∗/
after(Subject s) : subjMod(s);

63. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?
• Observers are then updated to be consistent with the
state of the subject.
/∗@abstract boolean
Consistent(Subject s, Observer o); @∗/
/*@pre: true *@/
after(Subject s) : subjMod(s);

64. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?
• Observers are then updated to be consistent with the
state of the subject.
/∗@abstract boolean
Consistent(Subject s, Observer o); @∗/
/*@pre: true *@/
after(Subject s) : subjMod(s);
/∗@post: ∀ob ∈ s.observers :

65. What are the behavioral requirements for a
concrete aspect to correctly extend the
Observing aspect?
• Observers are then updated to be consistent with the
state of the subject.
/∗@abstract boolean
Consistent(Subject s, Observer o); @∗/
/*@pre: true *@/
after(Subject s) : subjMod(s);
/∗@post: ∀ob ∈ s.observers :
Consistent(s, ob)@∗/

66. A Concrete Aspect: Library Observing
public aspect LibraryObserving

67. A Concrete Aspect: Library Observing
public aspect LibraryObserving

68. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing {
}

69. A Concrete Aspect: Library Observing
public aspect LibraryObserving
Inter-type
extends Observing { declarations
declare parents:
BookCopy implements Subject;
}

70. A Concrete Aspect: Library Observing
public aspect LibraryObserving
Inter-type
extends Observing { declarations
declare parents:
BookCopy implements Subject;
declare parents:
BookMan implements Observer;
}

71. A Concrete Aspect: Library Observing
public aspect LibraryObserving
Inter-type
extends Observing { declarations
declare parents:
BookCopy implements Subject;
declare parents:
BookMan implements Observer;
public void BookMan.update()
{...}
}

72. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing {
declare parents:
BookCopy implements Subject;
declare parents:
BookMan implements Observer;
public void BookMan.update()
{...}
}

73. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing {
}

74. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing { Pointcuts
pointcut subjMod(Subject copy):
}

75. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing { Pointcuts
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
}

76. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing { Pointcuts
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
}

77. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing { Pointcuts
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
target(copy) && args(..);
}

78. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing { Pointcuts
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
target(copy) && args(..);
pointcut attach(): //...
}

79. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing { Pointcuts
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
target(copy) && args(..);
pointcut attach(): //...
pointcut detach(): //...
}

80. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing { Pointcuts
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
target(copy) && args(..);
pointcut attach(): //... Predicate
pointcut detach(): //... definitions
/∗@ Modified(s1,s2): ... @∗/
}

81. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing { Pointcuts
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
target(copy) && args(..);
pointcut attach(): //... Predicate
pointcut detach(): //... definitions
/∗@ Modified(s1,s2): ... @∗/
/∗@ Consistent(s,o): ... @∗/
}

82. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing {
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
target(copy) && args(..);
pointcut attach(): //...
pointcut detach(): //...
/∗@ Modified(s1,s2): ... @∗/
/∗@ Consistent(s,o): ... @∗/
}

83. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing {
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
target(copy) && args(..);
}

84. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing {
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
target(copy) && args(..);
What if
we forgot
this?
}

85. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing {
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
target(copy) && args(..);
What if
/*@pre: true we forgot
after(Subject s) : subjMod(s); this?
/∗@post: ∀ob ∈ s.observers :
Consistent(s, ob)@∗/
}

86. A Concrete Aspect: Library Observing
public aspect LibraryObserving
extends Observing {
pointcut subjMod(Subject copy):
(execution(* BookCopy.bkBorrow(..))||
execution(* BookCopy.bkReturn(..)))&&
target(copy) && args(..);
What if
/*@pre: true we forgot
after(Subject s) : subjMod(s); this?
/∗@post: ∀ob ∈ s.observers :
Consistent(s, ob)@∗/
Would fail!
}

87. Conclusion

88. Conclusion
• AOP promotes reuse through abstract aspects.

89. Conclusion
• AOP promotes reuse through abstract aspects.
• Abstract aspects localize common functionality, while
concrete aspects localize specific functionality.

90. Conclusion
• AOP promotes reuse through abstract aspects.
• Abstract aspects localize common functionality, while
concrete aspects localize specific functionality.
• Likewise, specifications of abstract aspects can be
written abstractly.

91. Conclusion
• AOP promotes reuse through abstract aspects.
• Abstract aspects localize common functionality, while
concrete aspects localize specific functionality.
• Likewise, specifications of abstract aspects can be
written abstractly.
• Concrete aspects provide predicate definitions
specific to the needs of individual systems.

92. Conclusion
• AOP promotes reuse through abstract aspects.
• Abstract aspects localize common functionality, while
concrete aspects localize specific functionality.
• Likewise, specifications of abstract aspects can be
written abstractly.
• Concrete aspects provide predicate definitions
specific to the needs of individual systems.
• Abstract aspects can specify acceptable behavior of
subaspects.

93. Conclusion
• AOP promotes reuse through abstract aspects.
• Abstract aspects localize common functionality, while
concrete aspects localize specific functionality.
• Likewise, specifications of abstract aspects can be
written abstractly.
• Behavioral
Concrete aspects provide predicate definitions
subaspects?
specific to the needs of individual systems.
• Abstract aspects can specify acceptable behavior of
subaspects.

94. Future Work and Obstacles

95. Future Work and Obstacles
• Formal reasoning framework (possible automation).

96. Future Work and Obstacles
• Formal reasoning framework (possible automation).
• How to deal with singleton aspects?

97. Future Work and Obstacles
• Formal reasoning framework (possible automation).
• How to deal with singleton aspects?
• Traces?

98. Future Work and Obstacles
• Formal reasoning framework (possible automation).
• How to deal with singleton aspects?
• Traces?
• Aspect invariants?

99. Future Work and Obstacles
• Formal reasoning framework (possible automation).
• How to deal with singleton aspects?
• Traces?
• Aspect invariants?
• JUnit integration.

100. Future Work and Obstacles
• Formal reasoning framework (possible automation).
• How to deal with singleton aspects?
• Traces?
• Aspect invariants?
• JUnit integration.
• Transform specifications to unit tests.

101. Questions?