taming obliviousness in aspects with data flow analysis and design by contract
Download
Skip this Video
Download Presentation
Taming Obliviousness in Aspects with Data-flow Analysis and Design by Contract

Loading in 2 Seconds...

play fullscreen
1 / 15

Taming Obliviousness in Aspects with Data-flow Analysis and Design by Contract - PowerPoint PPT Presentation


  • 93 Views
  • Uploaded on

Taming Obliviousness in Aspects with Data-flow Analysis and Design by Contract. Tim Molderez and Dirk Janssens. Ansymo. Antwerp Systems and Software Modelling. Aspect-oriented programming (AOP). Typically extension of object-oriented language

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Taming Obliviousness in Aspects with Data-flow Analysis and Design by Contract' - lala


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
taming obliviousness in aspects with data flow analysis and design by contract

Taming Obliviousness in Aspects with Data-flow Analysis and Design by Contract

Tim Molderez and Dirk Janssens

Ansymo

Antwerp Systems and Software Modelling

aspect oriented programming aop
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, …
slide3

aspect Logging {

after: call(* Bank.do*(..)) {

log.write(stuff);

}}

Pointcut (when)

Advice (what)

aop s inherent problem
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
cornering the problem
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
data flow analysis
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?
slide7

Someone unaware of the aspect might still use the stream later on.

aspect CloseStreamAfterUse {

after: execution(Export.write*(stream)) {

stream.close();

}

}

advice impact analysis
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
incremental updates
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
design by contract dbc
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?
advice substitutability
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.
relation to obliviousness
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
where dfa and dbc meet
Where DFA and DbC meet
  • Data flow analysis + Design by contract: Detect which interactions are desired or undesired
detecing un desired interactions
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#, …
summary
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: [email protected] | http://ansymo.ua.ac.be

ad