Aspect-Oriented Software Development

1. Aspect-Oriented Software Development Joel Phinney March 31, 2011

2. Table of Contents • Concerns • Separation of Concerns, Tangled and Scattered Concerns, Cross-Cutting Concerns, Aspects • Aspect-Oriented Software Development • Creation of AOSD, Since AOP • Aspect-Oriented Programming • Aspect, Advice, Inter-Type Declarations, Join-Point, JPM, Point-Cut, Aspect-Weaver • Aspect-Oriented Software Engineering • Requirements, Design, Testing, Maintenance

3. Concerns • What are “concerns”? • Interests of the stakeholders • In other words, the reasons for the requirements • Example: • Requirement: • “The system shall require user authentication before allowing a user to transfer funds.” • Concern: • Security

4. Modularity • Decomposing part of a system into smaller modules – each with a well-defined purpose. • Central to modern software • Especially object-oriented software • One goal is functional cohesion • Each module has only one purpose – does only that

5. Separation of Concerns • Each module should implement only one concern. • This enforces high cohesion • Good in theory, but difficult in practice

6. Separation of Concerns public void TransferTo(Account otherAcct, int amount) { if ( balance < amount ) { Notifier.DisplayError(“Insufficient Funds”); return; } balance -= amount; otherAcct.Deposit(amount); }

7. Separation of Concerns public void TransferTo(Account otherAcct, int amount) throws Exception { Logger.BeginLog(“Attempting transfer…”); Security.VerifyAuthentication(); // throws exception if unauthorized Logger.Log(“…authenticated…”); if ( balance < amount ) { Logger.EndLog(“…insufficient funds.”); Notifier.DisplayError(“Insufficient Funds”); return; } otherAcct.Deposit(amount); balance -= amount; Logger.EndLog(“…transfer successful.”); }

8. Tangled and Scattered Concerns • Tangled Concern: • When one concern’s implementation is mixed (tangled) in the implementation of another concern. • Scattered Concern: • When parts of one concern’s implementation are scattered in the modules of other concerns.

9. Two Tangled Concerns public void TransferTo(Account otherAcct, int amount) throws Exception { Logger.BeginLog(“Attempting transfer…”); Security.VerifyAuthentication(); // throws exception if unauthorized Logger.Log(“…authenticated…”); if ( balance < amount ) { Logger.EndLog(“…insufficient funds.”); Notifier.DisplayError(“Insufficient Funds”); return; } otherAcct.Deposit(amount); balance -= amount; Logger.EndLog(“…transfer successful.”); }

10. A Scattered Concern • In class User: • Method PrepareActivityReport() • In class Account: • Method PrepareFundChangesReport() • In class Security: • Method PrepareAllLoginsReport() • Method PrepareFailedLoginsReport()

11. Cross-Cutting Concerns • Those with implementations that “cut across” other concerns’ implementations • Tangled and scattered concerns • Prevent complete separation of concerns • Lead to low reusability • Make software harder to maintain

12. Complete Separation of Concerns • Traditional approaches of decomposition don’t achieve separation of concerns well enough • Aspect-Oriented Software Development provides a solution

13. Aspects • The complete implementation of a cross-cutting concern • Only one concern – no part of any other • Example: • Concern: • Reporting • Aspect: • All of the Prepare*Report methods • All other reporting-related code

14. Aspects • Aspect-Orientation • Defined by Filman and Friedman as: • Quantification + Obliviousness • Quantification: • Aspects should be a part of multiple places in a program (a.k.a. cross-cutting) • Obliviousness: • The system code should be oblivious to (unaware of) any aspects • Separation of concerns

15. Aspect-Oriented Software Development • AOSD • Attempts to achieve complete separation of concerns by modularizing a system in a non-traditional manner • A software development approach • Affects each phase of the software lifecycle

16. Creation of AOSD • Developments made in seeking better modularization: • Reflection and Metaobject Protocols • Composition Filters • Subject-Oriented Programming • Feature-Oriented Programming • Adaptive Programming • Aspect-Oriented Programming

17. Creation of AOSD • Aspect-Oriented Programming (AOP) • A better approach of modularizing code • Developed by Gregor Kiczales and his team from Palo Alto Research Center • Introduced at the European Conference for Object Oriented Programming in 1997 • Their paper described two experimental languages to better modularize code • Also introduced the term “aspect”

18. Since AOP • International Conference on Aspect-Oriented Software Development (2002) • Various methods of aspect-oriented software engineering • All phases of the software lifecycle • Extensions to a growing number of languages

19. Aspect-Supporting Languages • C#.NET/VB.NET • C/C++ • COBOL • Objective-C • Lisp • Delphi • Haskell • Java • JavaScript • PHP • Scheme • Perl • Prolog • Python • Ruby • UML 2.0 • XML

20. AspectJ • An aspect-oriented extension to Java • Also developed by Gregor Kiczales and his team • Now has a large userbase

21. Aspect-Oriented Programming • Aspect (concrete definition) • A standalone module containing the “implementation of a cross-cutting concern” and “specifying” “where” the implementation should be “placed” in the system • Why all the “ ”? • Terms!

22. AOP Terms • Advice • “implementation of a cross-cutting concern” • Actual code implementing the concern • Inter-Type Declarations • “implementation of a cross-cutting concern” • Class methods, attributes, parents • If it’s related to the aspect and not the cross-cut concern, put it in the aspect module

23. AOP Terms public aspect ReportingAspect { // Creates PrepareActivityReport() as a method in User public Report User.PrepareActivityReport() { // Implementation of PrepareActivityReport() } // Creates PrepareFundChangesReport() as a method in Account public Report Account.PrepareFundChangesReport() { // Implementation of PrepareFundChangesReport() } // advice or other inter-type declarations }

24. AOP Terms • Join-Point • Events in a system “where” advice can be inserted • Join-Point Model (JPM) • Events supported by a particular aspect-oriented language. • Typically: • Accessing/changing an attribute • Calling a method (constructor too) • Executing a method (or constructor) • Handling an exception • Initializing an object

25. AOP Terms public void TransferTo(Account otherAcct, int amount) { // method entry join point if ( balance < amount ) // accessing “balance” join point { Notifier.DisplayError(“Insufficient Funds”); return; // method exit join point } balance -= amount; // modifying “balance” join point otherAcct.Deposit(amount); // method call/return join points // method exit join point }

26. AOP Terms • Point-Cut • A statement, associated with advice, “specifying” where advice should be placed in the system relative to a specified join point(s) • Excellent point-cut guide

27. AOP Terms public aspect LoggingAspect { pointcutPublicMethods() : call( public * *(..) ); before() : PublicMethods() // point-cut { Logger.BeginLog(“Entering: ” + thisjopinpoint); // advice } after() : PublicMethods() // point-cut { Logger.EndLog(“Exited: ” + thisjopinpoint); // advice } // Other logging-related code }

28. AOP Terms • Aspect-Weaver • processes aspects and system code • locates join points matching the point-cuts • weaves (“places”) the corresponding advice into the system code at those join points.

29. AOP Terms • Aspect-Weaver techniques • Produce system code with advice weaved in • Weave at compile-time • Fast; static; impedes debugging • Weave at runtime • Slow; dynamic; impedes debugging • Subclass existing classes to include advice • Originals are untouched • Debuggers see advice

30. AOP Terms • Aspect (complete definition) • Standalone module • Contains advice and/or inter-type declarations • Contains point-cuts to specify join points where advice/inter-type declarations should be weaved

31. Aspect-Oriented Software Engineering • Cross-cutting concerns affect the entire software lifecycle – not just implementation • How to find them? • How to isolate them?

32. Requirements • Concerns initially addressed by stakeholders • Different groups of stakeholders have different concerns • Some shared concerns, many different • Shared concerns => core system

33. Requirements • To find cross-cutting: • Group requirements by concern • Concerns shared by stakeholders => core system • Other concerns => extensions to core system • Cross-cutting is caused by some extensions • Logging, monitoring, synchronization, security, etc. • Should be easy to locate

34. Requirements • Stakeholders: • Emergency service users, emergency planners, security advisors • Concerns: • Emergency Service Users: • Check out/in equipment, submit damage report • Emergency Planners: • Check out/in equipment, order new equipment • Security Advisors: • Check out/in equipment if a user’s authorized to, record failed authorizations

35. Design • Modeling Aspects • Use Cases • Represent an aspect with a use case • Use <<extend>> from an aspect to a use case in the core system it will affect (Sommerville 2011)

36. Design • Design Process: • Core system design • Design the core system in the usual manner • Aspect identification and design • Identify aspects in the extensions and design them • Composition design • Locate join points in the core system at which aspects should be weaved • Conflict Analysis and Resolution • Point-cut clashes, changes to system structure • Name Design • Devise naming standards to avoid accidental weaving

37. Design • Aspect UML (Sommerville 2011)

38. Testing • Code walkthroughs and inspections • White-box testing • Aspects are not accounted for • Special tools are needed

39. Testing • Test coverage: • What defines test coverage? • Each advice tested once? • Each advice tested once for each matching join point? • Dynamic join points? • Aspect interference testing?

40. Maintenance • If requirements change: • Requirements part of a concern • Find the module (core system or extension) implementing that concern • Code to change is localized • Saves time => saves money • If methods in the core system change: • Check for affected point-cuts • Make appropriate changes

41. Conclusion • Aspects • Implementations of concerns tangled with or scattered among other concerns’ implementations. • Aspect-Oriented Software Development • Attempts to achieve complete separation of concerns by modularizing cross-cutting concerns

42. Conclusion • Aspect-Oriented Programming • Programming constructs, rules, and techniques to allow the modularization of aspects • Aspect-Oriented Software Engineering • Altering each phase of the software lifecycle to assist in separating aspects from the core system

43. References [1] Cohen, T. & Gil, J. (2004). AspectJ2EE = AOP + J2EE. Towards an Aspect Based, Programmable and Extensible Middleware Framework. Retrieved from http://tal.forum2.org/static/cv/AspectJ2EE.pdf [2] Filman, R. & Friedman, D. (2001). Aspect-Oriented Programming is Quantification and Obliviousness. Workshop on Advanced Separation of Concerns, OOPSLA 2000. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.417&rep=rep1&type=pdf [3] Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Videira Lopes, C., Loingtier, J.-M., Irwin, J. (1997). Aspect-Oriented Programming. Proceedings of the European Conference on Object-Oriented Programming, 1241, 220-242. [4] Sommerville, I. (2011). Aspect-Oriented Software Engineering. Retrieved from http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/SampleChapters/PDF/Chap21-AOSD.pdf [5] Tekinerdogan, B. Separating Software Engineering Concerns: Introduction to AOSD. Retrieved from http://trese.cs.utwente.nl/taosad/e-tutorial.htm [6] Whitney, R. (2003). AspectJ Syntax. Retrieved from http://www.eli.sdsu.edu/courses/spring03/cs683/notes/aspectJSyntax/aspectJSyntax.html