1 / 15

Enhancing Aspect-Oriented Programming with Data-Flow Analysis and Design by Contract

This paper addresses the challenges of obliviousness in aspect-oriented programming (AOP), where classes may unknowingly interact with aspects. We propose a methodology combining data-flow analysis (DFA) and design by contract (DbC) to detect undesired behaviors that arise from these interactions. Our approach automatically identifies data dependencies influenced by aspects, helping developers recognize potential violations of contracts. By collaborating these techniques, we aim to promote safer and more predictable interactions in software systems using AOP while maintaining modularity and separation of concerns.

lala
Download Presentation

Enhancing Aspect-Oriented Programming with Data-Flow Analysis and Design by Contract

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. Taming Obliviousness in Aspects with Data-flow Analysis and Design by Contract Tim Molderez and Dirk Janssens Ansymo Antwerp Systems and Software Modelling

  2. Aspect-oriented programming (AOP) • Typically extension of object-oriented language • Aims to separate crosscutting concerns into their own modules, i.e. aspects • Crosscutting concerns: • Scattered in several places • Tangled with other concerns • Examples: logging, authentication, caching, profiling, …

  3. aspect Logging { after: call(* Bank.do*(..)) { log.write(stuff); }} Pointcut (when) Advice (what)

  4. AOP’s inherent problem • Pointcuts are an implicit mechanism • Classes (and aspects!) are not aware that their behaviour can be modified by aspects • May lead to unexpected/undesired behaviour as the system evolves

  5. Cornering the problem • Goal: Detect undesired behaviour caused by aspects • Data-flow analysis: • Automatically detect interactions caused by aspects • Present them to the developer • Design by contract: • Distinguish harmless from (potentially) harmful aspects

  6. Data-flow analysis • Expose interactions caused by aspects, both to aspect and class developers • Focus on data dependencies: • What data is being modified by advice? • Who uses this modified data?

  7. Someone unaware of the aspect might still use the stream later on. aspect CloseStreamAfterUse { after: execution(Export.write*(stream)) { stream.close(); } }

  8. Advice impact analysis • Based on definition-use analysis • Find all definitions (assignments) during the execution of advice which may affect the base system (or other aspects) • .. as well as their corresponding uses. • Implemented on top of the AspectBench Compiler • Uses AST + call graph generated from (woven) Soot representation

  9. Incremental updates • Analysis aimed to run in the background of an IDE • Determine what to invalidate and reanalyseper type of source code change • Evaluated by performing a large set of random (though realistic) changes on existing systems

  10. Design by Contract (DbC) • DbC, an intuitive and modular means to specify desired behaviour of an application • In OOP, the Liskov substitution principle: • Preconditions: must be eq. or weaker in subtype • Postconditions: must be eq. or stronger • Invariants: must be preserved • What if you add aspects?

  11. Advice substitutability • Considering all advice are around advice:Whenever a pointcut matches, the corresponding advice effectively substitutes the original join point. • Liskov substitution can be easily adjusted to aspects. • The contracts of an advice have to comply withthe contracts of the join point where it is applied.

  12. Relation to obliviousness • If the advice substitution principle is strictly applied,the base system can remain unaware of aspects. • However, some aspects have to break the principle: • e.g. authentication: Postcondition is weakened if the user is not logged in The base system must become aware of the aspect. • Principle not meant to be strictly enforced; it simply defines the border between safe/unsafe obliviousness

  13. Where DFA and DbC meet • Data flow analysis + Design by contract: Detect which interactions are desired or undesired

  14. Detecing (un)desired interactions • Given an interaction (definition+use), will the altered value cause a contract violation where the new value is used? • If the original code implements its contracts, does this still hold with the altered value? • Look into ESC/Java2, Spec#, …

  15. Summary • Aim: Detect undesired behaviour caused by aspects • Data-flow analysis: • Detect interactions caused by aspects • Design by contract: • Advice subst. principle rejects aspectswith undesired behaviour • DFA+DbC: • Detect (un)desired interactions by aspects Contact: tim.molderez@ua.ac.be | http://ansymo.ua.ac.be

More Related