Taming obliviousness in aspects with data flow analysis and design by contract
Download
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, …


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?


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 later on.

  • 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 later on.

  • 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) later on.

  • 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 later on.

  • 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 later on.

  • 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 later on.

  • Data flow analysis + Design by contract: Detect which interactions are desired or undesired


Detecing un desired interactions
Detecing (un)desired interactions later on.

  • 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 later on.

  • 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