Aspect-Oriented Software Development

Joel PhinneyMarch 31, 2011

◦ 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

Table of Contents

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

Concerns

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

Modularity

Each module should implement only one concern.◦ This enforces high cohesion

Good in theory, but difficult in practice

Separation of Concerns

public void TransferTo(Account otherAcct, int amount) {

if ( balance < amount ){

Notifier.DisplayError(“Insufficient Funds”);return;

}

balance -= amount;otherAcct.Deposit(amount);

}

Separation of Concerns

public void TransferTo(Account otherAcct, int amount) throws Exception{

Logger.BeginLog(“Attempting transfer…”);Security.VerifyAuthentication(); // throws exception if

unauthorizedLogger.Log(“…authenticated…”);if ( balance < amount ){

Logger.EndLog(“…insufficient funds.”);Notifier.DisplayError(“Insufficient Funds”);return;

}otherAcct.Deposit(amount);balance -= amount;Logger.EndLog(“…transfer successful.”);

}

Separation of 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.

Tangled and Scattered Concerns

public void TransferTo(Account otherAcct, int amount) throws Exception{

Logger.BeginLog(“Attempting transfer…”);Security.VerifyAuthentication(); // throws exception if

unauthorizedLogger.Log(“…authenticated…”);if ( balance < amount ){

Logger.EndLog(“…insufficient funds.”);Notifier.DisplayError(“Insufficient Funds”);return;

}otherAcct.Deposit(amount);balance -= amount;Logger.EndLog(“…transfer successful.”);

}

Two Tangled Concerns

In class User:◦ Method PrepareActivityReport()

In class Account:◦ Method PrepareFundChangesReport()

In class Security:◦ Method PrepareAllLoginsReport()◦ Method PrepareFailedLoginsReport()

A Scattered Concern

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

Cross-Cutting Concerns

Traditional approaches of decomposition don’t achieve separation of concerns well enough

Aspect-Oriented Software Development provides a solution

Complete Separation of Concerns

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

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

Aspects

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

Aspect-Oriented Software Development

Developments made in seeking better modularization:◦ Reflection and Metaobject Protocols◦ Composition Filters◦ Subject-Oriented Programming◦ Feature-Oriented Programming◦ Adaptive Programming◦ Aspect-Oriented Programming

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”

Creation of AOSD

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

Since AOP

C#.NET/VB.NET C/C++ COBOL Objective-C Lisp Delphi Haskell Java JavaScript

PHP Scheme Perl Prolog Python Ruby UML 2.0 XML

Aspect-Supporting Languages

An aspect-oriented extension to Java Also developed by Gregor Kiczales and his

team Now has a large userbase

AspectJ

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!

Aspect-Oriented Programming

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

AOP Terms

public aspect ReportingAspect{

// Creates PrepareActivityReport() as a method in Userpublic Report User.PrepareActivityReport(){

// Implementation of PrepareActivityReport()}// Creates PrepareFundChangesReport() as a method in Accountpublic Report Account.PrepareFundChangesReport(){

// Implementation of PrepareFundChangesReport()}

// advice or other inter-type declarations}

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

AOP Terms

public void TransferTo(Account otherAcct, int amount) {

// method entry join pointif ( balance < amount ) // accessing “balance” join point{

Notifier.DisplayError(“Insufficient Funds”);return; // method exit join point

}

balance -= amount; // modifying “balance” join pointotherAcct.Deposit(amount); // method call/return join points

// method exit join point}

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

AOP Terms

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

}

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.

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

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

AOP Terms

Cross-cutting concerns affect the entire software lifecycle – not just implementation

How to find them? How to isolate them?

Aspect-Oriented Software Engineering

Concerns initially addressed by stakeholders Different groups of stakeholders have

different concerns Some shared concerns, many different Shared concerns => core system

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

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

Requirements

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

Design

(Sommerville 2011)

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

Design

Aspect UML

Design

(Sommerville 2011)

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

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?

Testing

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

Maintenance

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

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

Conclusion

[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

References