1. Technion Israel 1 Aspect-Oriented Software Development (AOSD) An Introduction Shmuel Katz Part of this lecture: Johan Brichau & Theo D’Hondt johan.brichau@vub.ac.bejohan.brichau@vub.ac.be, tjdhondt@vub.ac.betjdhondt@vub.ac.be

2. 2 Topics Introduction---a little philosophy Programming with aspects: AspectJ More details on AspectJ Requirements for aspects Aspect specifications and proof obligations Categories of Aspects Design for Aspects—extending UML More Aspect languages –Composition Filters –CeasarJ

3. 3 More topics Verification for aspects using static analysis and model checking Applications for aspects –Middleware –Security –Product lines Interference and other interactions among aspects

4. 4 Course requirements Final Exam 70% Write some aspects in AspectJ (an extension of Java), in pairs 20% Attend lectures and provide feedback 10% BUT if final exam grade is <50, the final grade is 100% of the final exam grade

5. 5 Goals of the course Enjoy a (2 point) course where a new modularity concept is presented Become acquainted with how aspects can be incorporated into system development at various stages Learn AspectJ to allow writing aspects Survey the variety of aspect languages and verification techniques See how aspects could help in ongoing research or in defining new topics

6. 6 Need for adequate software engineering techniques Software Engineering Complexity Functional Requirements Software Development Requirements Non-functional Requirements + + Complexity: =>

7. 7 Evolution of Software Engineering Machine-level Programming Complex code Difficult to read & write Poor evolvability Poor maintainability Poor reusability Program Main program data

8. 8 Evolution of Software Engineering Structured Programming + Language features for common program patterns Easier to read & write Poor evolvability Poor maintainability Poor reusability Program Main program data

9. 9 Evolution of Software Engineering Procedural Programming + Procedural abstractions + Parameter passing + Recursion Easier to read & write Improved evolvability Improved maintainability Improved reusability Program Main program data Procedure 1 Procedure 2 Procedure n

10. 10 Evolution of Software Engineering Modular Programming + Module abstractions Easier to read & write Better evolvability Better maintainability Better reusability Program Main program data module 1 data 1 module 1 data 1 Procedure 1 module 2 data 2 module 2 data 2 Procedure 2 Procedure n

11. 11 Evolution of Software Engineering Object-oriented Programming + Encapsulation + Polymorphism + Inheritance Easier to read & write Better evolvability Better maintainability Better reusability Program Object 1 data Object 2 data Object 3 data Object 4 data

12. 12 Evolution of Software Engineering Aspect-orientation Component orientation Generative Programming....

13. 13 Separation of Concerns [E.W. Dijkstra] Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day […] But nothing is gained – on the contrary – by tackling these various aspects simultaneously. It is what I sometimes have called “the separation of concerns” […]

14. 14 Modular programming –Organize code by grouping functionality Need for language mechanisms –Drives evolution of languages & paradigms Separation of Concerns 14 Concern: “Something the developer needs to care about” (e.g. functionality, requirement,..) Separation of concerns: handle each concern separately

15. 15 Separation of Concerns concern

16. 16 Crosscutting Concerns Program Object 1 data Object 2 data Object 3 data Object 4 data ConcernImplementation AObject 1 BObject 2 CObject 3 DObject 4 EObject 1,2,3 Typical examples: synchronisation, error handling, timing constraints, user-interface,... Also concerns of a specific application, e.g.: login functionality in webshop, business rules,...

17. 17 Crosscutting Concern Example Implementation of Apache Tomcat webserver Analyzed implementation of 3 concerns: –XML parsing concern –URL pattern matching concern –Logging concern

18. 18 XML parsing concern Good modularization XML parsing is implemented in its own module

19. 19 URL pattern matching concern Good modularization URL pattern matching is implemented in 2 modules

20. 20 Logging concern Bad modularization logging is implemented in a lot of different places, spread throughout other modules

21. 21 Crosscutting concerns Program Object 1 data Object 2 data Object 3 data Object 4 data Evolution ? Reuse ? Maintenance ? Cumbersome! It requires breaking all modularisations that are crosscut! Need for better language / better paradigm

22. 22 Tyranny of the Dominant Decomposition Given one out of many possible decompositions of the problem... (mostly core functionality concerns)...then some subproblems cannot be modularized! (non-functional, functional, added after the facts,...) Not only for a given decomposition –But for all possible decompositions Not only in object-orientation! –Also in other paradigms Not only in implementation! –Also in analysis & design stages

23. 23 Introduction to AOSD Why AOSD ? Evolution of Software Engineering techniques Advanced Separation of Concerns What is AOSD ? Aspect-orientation, Aspectual decomposition Aspect-orientation in the software development lifecycle Asymmetrical vs symmetrical approaches

24. 24 Modularize crosscutting concerns – Code scattering (one concern in many modules) – Code Tangling (one module, many concerns) Aspectual Decomposition 24

25. 25 Aspectual Decomposition [Gregor Kiczales] Many existing programming languages, including object- oriented languages, procedural languages and functional languages, can be seen as having a common root in that their key abstraction and composition mechanisms are all rooted in some form of generalized procedure.

26. 26 Program Main program data Procedure 1 Procedure 2 Procedure n Program Main program data module 1 data 1 module 1 data 1 Procedure 1 module 2 data 2 module 2 data 2 Procedure 2 Procedure n Program Object 1 data Object 2 data Object 3 data Object 4 data Explicit invocation

27. 27 Aspects Program Object 1 data Object 2 data Object 3 data Object 4 data Program Object 1 data Object 2 data Object 3 data Object 4 data Aspect Implicit invocation

28. 28 Implicit Invocation Aspect captures its own invocation that crosscuts other modules Objects are invoked by other objects through message sends

29. 29 Aspects Aspect Aspect applicability code Aspect functionality code Control over implicit invocation Aspect’s functional implementation Where / when What Pointcut Advice

30. 30 Joinpoints Program Object 1 data Object 2 data Object 3 data Object 4 data Aspect joinpoint: ● A join point is a point of interest in some artefact in the software lifecycle through which two or more concerns may be composed. Examples in implementation artefact: - message sends - method executions - error throwing - variable assignments -...

31. 31 Join point Model Specific to each aspect-oriented programming language E.g. AspectJ join point model: key points in dynamic call graph A join point model defines the kinds of join points available and how they are accessed and used.

32. 32 Pointcuts A pointcut is a predicate that matches join points. A pointcut is a relationship ‘join point -> boolean’, where the domain of the relationship is all possible join points. Aspect Aspect applicability code Aspect functionality code Pointcut Advice

33. 33 Advice Aspect Aspect applicability code Aspect functionality code Pointcut Advice

34. 34 Example: Synchronised buffer Tangling! Crosscutting concerns! class Buffer { char[] data; int nrOfElements; Semaphore sema; bool isEmpty() { bool returnVal; sema.writeLock(); returnVal := nrOfElements == 0; sema.unlock(); return returnVal; } Synchronisation concern Buffer functionality concern

35. 35 Synchronisation Concern When a Buffer object receives the message isEmpty, first make sure the object is not being accessed by another thread through the get or put methods

36. 36 Synchronisation as an Aspect When a Buffer object receives the message isEmpty, first make sure the object is not being accessed by another thread through the get or put methods When to execute the aspect (pointcut) Composition of when and what (kind of advice) What to do at the join point (advice)

37. 37 Synchronisation as an Aspect class Buffer { char[] data; int nrOfElements; bool isEmpty() { bool returnVal; returnVal := nrOfElements == 0; return returnVal; } before: reception(Buffer.isEmpty) { sema.writeLock();} after: reception(Buffer.isEmpty) { sema.unlock(); } Aspect Pointcut Advice

38. 38 Example Domain-specific Aspect Language class Stack { push(...) {... } pop() {... }... } coordinator BoundedStackCoord { selfExclusive {pop,push}; mutExclusive {pop,push}; } Synchronisation concern is separated from other concerns using an aspect language for synchronisation

39. 39 Advice code Domain-specific Aspect Languages – Language targeted towards one kind of aspect COOL & RIDL (Synchronisation) RG (Loop fusion optimization) – Describe a concern – But Limited in expressiveness New Language for each kind of aspect?? General-purpose Aspect Languages – More-general aspects possible – describe crosscutting 39

40. 40 Other Examples Logging “write something on the screen/file every time the program does X” Error Handling “if the program does X at join point L then do Y at join point K” Persistence “every time the program modifies the variable v in class C, then dump a copy to the DB” User Interfaces “every time the program changes its state, make sure the change is reflected on the screen” 40

41. 41 Advantages of aspects A system concern is treated in one place, and can be easily changed Evolving requirements can be added easily with minimal changes to previous version Configurable components become practical (“On demand computing”) Reuse of code that cuts across usual class hierarchy to augment system in many places

42. 42  42 operations that move elements factory methods Display * 2 Point getX() getY() setX(int) setY(int) moveBy(int, int) Line getP1() getP2() setP1(Point) setP2(Point) moveBy(int, int) Figure makePoint(..) makeLine(..) FigureElement moveBy(int, int) AspectJ Figure Editor

43. 43  43 aspect modularity cuts across class modularity DisplayUpdating Display * 2 Point getX() getY() setX(int) setY(int) moveBy(int, int) Line getP1() getP2() setP1(Point) setP2(Point) moveBy(int, int) Figure makePoint(..) makeLine(..) FigureElement moveBy(int, int) AspectJ Figure Editor

44. 44  44 aspect DisplayUpdating { pointcut move(FigureElement figElt): target(figElt) && (call(void FigureElement.moveBy(int, int)) || call(void Line.setP1(Point)) || call(void Line.setP2(Point)) || call(void Point.setX(int)) || call(void Point.setY(int))); after(FigureElement fe): move(fe) { Display.update(fe); } AspectJ Figure Editor

45. 45 Modularity for Cross-cutting For distributed: –Deadlock detection: is the system stuck? –Monitoring: gathering information on messages –Fault-tolerance: resending messages on new paths For Object Oriented –Monitoring and debugging –Adding security: Encode/decode messages –Preventing overflow: Catch and correct when needed –Enforcing a scheduling policy Analyzing QOS and Performance

46. 46 Oblivious Base Systems The base system is unaware of the aspect, and can operate without it Linked to implicit invocation Often seen as a characteristic of AOSD “Take it or leave it” view of aspects May not always be reasonable: when the base depends on the existence of an aspect treating a concern

47. 47 Weavers Compilers (or interpreters) of an Aspect Language ‘Weaves’ the aspect’s crosscutting code into the other modules Source-to-source transformations Bytecode transformations Reflection Aspect-aware virtual machines

48. 48 Asymmetric vs. Symmetric Decompositions AsymmetricSymmetric Crosscutting concerns modularized in special module (aspect). All concerns modularized in same kind of module Described until now

49. 49 Symmetric Approaches Multidimensional Separation of Concerns

50. 50 Symmetric Approaches composition specification ~ in terms of join points

51. 51 The Synchronised buffer, revisited class Buffer { char[] data; int nrOfElements; bool isEmpty() { bool returnVal; returnVal := nrOfElements == 0; return returnVal; } class Synchronizer { Semaphore sema; bool lock() { return sema.writeLock; } bool unlock() { return sema.unlock(); }

52. 52 AOSD Aspect-oriented...... Requirements Engineering... Design... Architecture... Programming... Middleware... Verification techniques

53. 53 AO Requirements Engineering Arcade, ARGM, Aspectual Use Cases, Cosmos, AOREC,... Need to identify aspects early in development process Representation of crosscutting concerns in requirements analysis

54. 54 A Security Requirement Aspect Constrain all requirements specified in all user viewpoints by the top-level security requirement. Constrain all requirements in administrator viewpoint by the security policy for administrators. Constrain all requirements in manager viewpoint by the security policy for managers. … pointcut advice kind advice behavior

55. 55 AO Design AODM, Theme/UML, SUP, UFA, AML, CoCompose.... Specification of aspects at the design level –Notation –Composition specification –Precise semantics of aspect integration

56. 56 Theme/UML Example [Adapted from S. Clarke 2005]

57. 57 Theme/UML Example [Adapted from S. Clarke 2005]

58. 58 AO Programming JAsCo, CaesarJ, AspectS, Object Teams, HyperJ, JBOSS AOP, Compose*, DemeterJ, AspectC++,... Aspect languages: aspectual language features –Advice models –Join point models –Pointcut languages Development support –IDE’s

59. 59

60. 60 AO Middleware Increasing complexity in distributed middleware Aspect technology to the rescue –Hiding distribution details –Common domain-specific services –... 60

61. 61 AO Verification Techniques Adaptation of software verification techniques to accomodate AO Verification of aspect weaving –Aspect interactions / interferences 61

62. 62 AOSD Timeline 1997 Introduction of AOP 200120022004 { 2000 Advanced Separation of Concerns First AOSD Conference AOP Workshops Advanced Separation of Concerns Workshops AOSD EU Aspect-Oriented Software Development

63. 63 EU Network on AOSD

64. 64 Conclusions Separation of Concerns –Crosscutting concerns phenomenon Aspect-orientation –Modularisation of crosscutting concerns –Aspects: implicit invocation –Join points, pointcuts, advices Aspect-oriented Software Development –AO in the entire software development lifecycle

65. 65 Moreover The fun has just begun ! [Kiczales 2003] Aspect-orientation is a young and dynamic research area