1. Joel Phinney March 31, 2011

2. ◦ 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.  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.  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.  Each module should implement only one concern. ◦ This enforces high cohesion  Good in theory, but difficult in practice

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

7. 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 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. 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.  In class User: ◦ Method PrepareActivityReport()  In class Account: ◦ Method PrepareFundChangesReport()  In class Security: ◦ Method PrepareAllLoginsReport() ◦ Method PrepareFailedLoginsReport()

11.  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.  Traditional approaches of decomposition don’t achieve separation of concerns well enough  Aspect-Oriented Software Development provides a solution

13.  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.  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.  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.  Developments made in seeking better modularization: ◦ Reflection and Metaobject Protocols ◦ Composition Filters ◦ Subject-Oriented Programming ◦ Feature-Oriented Programming ◦ Adaptive Programming ◦ Aspect-Oriented Programming

17.  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.  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.  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.  An aspect-oriented extension to Java  Also developed by Gregor Kiczales and his team  Now has a large userbase

21.  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.  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. 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.  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. 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.  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 Excellent point-cut guide

27. public aspect LoggingAspect { pointcut PublicMethods() : 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.  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.  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.  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.  Cross-cutting concerns affect the entire software lifecycle – not just implementation  How to find them?  How to isolate them?

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

33.  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.  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.  Modeling Aspects ◦ Use Cases  Represent an aspect with a use case  Use > from an aspect to a use case in the core system it will affect (Sommerville 2011)

36.  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.  Aspect UML (Sommerville 2011)

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

39.  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.  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.  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.  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. [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