1 / 23

Aspect Oriented Programming

Thomas Dohaney COT 4810 Apr. 3. Aspect Oriented Programming. Overview. What is AOP? Limitations of OOP Why we should use AOP Basics of AspectJ language The Aspect Module Join Points, Pointcuts, Advice. What is AspectOrientedProgramming?.

rocio
Download Presentation

Aspect Oriented Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Thomas Dohaney COT 4810 Apr. 3 Aspect Oriented Programming

  2. Overview • What is AOP? • Limitations of OOP • Why we should use AOP • Basics of AspectJ language • The Aspect Module • Join Points, Pointcuts, Advice

  3. What is AspectOrientedProgramming? • Software Development paradigm that enables modularization of crosscutting concerns. • Concerns are functional and nonfunctional requirements, from the clients, end users, and developers, as well as system constraints. • If a concern is crosscutting then the requirements cut across many classes and components. • Solution: Transform crosscutting into an object called Aspects. (More later)

  4. Why use AOP? • Benefits OOP, in construction • Most useful in very large software that contains lots of business logic. • Bank systems, insurance systems, hotel management systems, library systems. • Involves customers, accounts, transactions, checking for authorization, tracking an update, notify customers of updated or changed policy, or changed data fields.

  5. Why use AOP? • In general large systems that contain lots of concerns. • In normal OOP design, M requirements map to N components, with M > N. • 1000 requirements might map to 50 components. • These are limitations of OOP

  6. Limitations of OOP • Cannot keep crosscutting concerns separate • M-to-N mapping results in tangling and scattering • Tangling is how concerns are interwoven with each other in a module • Scattering is how concerns are dispersed over many modules

  7. Inability to keep concerns separate • Concerns are different shades. • Demonstrates scattering and tangling.

  8. More about OOP and AOP • Ideally we want 1-to-1 mapping from design-level concepts to code implementation • Sometimes components contain logic that has to do with multiple concerns and requirements • Typically happens in OOP, this is N-to-1 mapping • Multiple fragments across many components to meet 1 requirement. (Scattering)

  9. More OOP and AOP • Other possibility is 1-to-N mapping. • To implement 1 design-level requirement, there are multiple fragments throughout a class. • For example, try to implement a requirement for a Customer class that every time the state of a customer it is displaying changes, a list of listeners using that view are notified. (Tangling)

  10. To implement this requirement, code has become tangled. public class Customer { private Address address; private String lastName; private String firstName; private CustomerID id; private List listeners; public Customer() {...} public void addListener(CustomerListener listener){ listeners.add(listener); } public void removeListener(CustomerListener listener) { listeners.remove(listener); } public Address getAddress() { return this.address; } public getLastName() { return this.lastName; } public void setLastName(String name) { this.lastName = name; notifyListeners(this); } } concern fragment notifyListeners(this);

  11. AOP takes care of both effects • Gives new module called an Aspect • Turns 1-to-N implementations of concepts and requirements into 1-to-1 implementations. • This technique involves concern separation technique, and concern composition technique.

  12. Technique to separate concerns • Decompose based on requirements, separate the crosscutting concerns • Almost all concerns can be identified as a use case, in use case modeling.

  13. Aspects, unit of modularity to implement crosscutting concerns • Separates the concern in its own structure • Invoking an Aspect is implicit. • When a program executes a stream of Join Points occur (stream of events). • Join Points are visible to an Aspect during program execution. • Aspects specify which events they are interested in through a pointcut.

  14. Join Points • Are events that happen when a program is running. • Well-defined places in the execution flow of a program where additional behavior can be attached • Join points consist of any method or constructor call, execution of a method or constructor, access or update of a field, initialization of classes and objects, execution of an exception handler.

  15. Pointcuts • The way to specify join points in a program is to write pointcuts. • Eliminates the need to refer to each join point explicitly. • Examples of pointcuts for method calls, method executions, object instantiations, constructor executions, field references and handler executions.

  16. Examples of Pointcuts • A method body executes execution(void Point.setX(int)) • A method is called call(void Point.setX(int)) • An exception handler executes handler(ArrayOutOfBoundsException) • Object executing of SomeType this(SomeType) • A target object of SomeType target(SomeType) • Executing code belongs to a certain class within(MyClass)

  17. Composition of Pointcuts • Can refer to a composition of point cuts. • Pointcuts compose through the operations or ("||"), and ("&&") and not ("!"). • target(Point) && call(int *()) • call(* *(..)) && (within(Line) || within(Point)) • within(*) && execution(*.new(int)) • !this(Point) && call(int *(..))

  18. Pointcut wildcards • execution(* *(..)) • The execution of any method regardless of return or parameter types • call(* set(..)) • The call to any method named set regardless of return or parameter types

  19. Pointcuts for method modifiers • You can select methods and constructors based on their modifiers and on negations of modifiers. For example, you can say: • call(public * *(..)) • execution(!static * *(..)) • execution(public !static * *(..))

  20. Advice • Additional code to be executed at a pointcut, when the condition is matched. • Advice can run before the join points matched, after the join points matched, or around the join points (instead of). • Around is the most powerful, has control whether the method runs at all.

  21. A single Aspect can implement the view notification requirement from earlier public aspect PolicyChangeNotification { pointcut notifyListeners() : call(* PolicyImpl.notifyListeners(..)); declare warning : notifyListerners() && !within(PolicyChangeNotification) : "Only the PolicyChangeNotification aspect should be notifying listeners." pointcut policyStateUpdate(PolicyImpl aPolicy) : (execution(* set*(..)) || (execution(* addClaim(..)) || (execution(* removeClaim(..))) && this(aPolicy); after(PolicyImpl policy) returning : policyStateUpdate(policy) { policy.notifyListeners(); } }

  22. Questions • 1) What are the two limitations of OOP when we try to implement crosscutting concerns? • 2) How is an Aspect called when a pointcut is matched?

  23. References • A. Colyer, A. Clement, G. Harley. Aspect-Oriented Programming with AspectJ. Addison-Wesley. 2005. • I. Jacobson., P. NG. Aspect-Oriented Software Development with Use Cases. Addison-Wesley. 2005. • Elicpse AspectJ. “AspectJ.” http://www.eclipse.org/aspectj/

More Related