Towards a Standard Interface for Runtime Inspection in AOP Environments OOPSLA Workshop on Tool for...
-
Upload
jovan-elliston -
Category
Documents
-
view
214 -
download
0
Transcript of Towards a Standard Interface for Runtime Inspection in AOP Environments OOPSLA Workshop on Tool for...
Towards a Standard Interface for Runtime Inspection in
AOP Environments
OOPSLA Workshop on Tool for AOSD, Seattle, November 2002
Katharina Mehner and Awais Rashid
K. Mehner 2 Lancaster University
Motivation
• During development and maintenance programmers need to develop an understanding of structure and behaviour
• Programmers cannot easily determine the effects of aspects– Quantification: Aspects apply to many places– Obliviousness: Components unaware of aspects– Aspect interference
K. Mehner 3 Lancaster University
Example – Dynamic binding
class B extends A { public void m(){ //override A.m() }}
class Application{ static void main(String args[]){ A a1 = new A; A a2 = new B; a1.m(); a2.m(); }}
class A{ public void m(){ //do something }}
aspect TraceA{ after(): call (void A.m()){ System.out.println(“ }}
aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) }}
• Which code do aspects affect?• Code is affected by which aspects?
??
K. Mehner 4 Lancaster University
Editor support (1)
class B extends A { public void m(){ //override A.m() }}
class Application{ static void main(String args[]){ A a1 = new A; A a2 = new B; a1.m(); a2.m(); }}
class A{ public void m(){ //do something }}
aspect TraceA{ after(): call (void A.m()){ System.out.println(“ }}
aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) }}
• Automated tool support can identify affected method declarations
K. Mehner 5 Lancaster University
Editor support (2)
class B extends A { public void m(){ //override A.m() }}
class Application{ static void main(String args[]){ A a1 = new A; A a2 = new B; a1.m(); a2.m(); }}
class A{ public void m(){ //do something }}
aspect TraceA{ after(): call (void A.m()){ System.out.println(“ }}
aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) }}
• Automated tool support can identify affected method call sites
K. Mehner 6 Lancaster University
Running the example
class B extends A { public void m(){ //override A.m() }}
class Application{ static void main(String args[]){ A a1 = new A; A a2 = new B; a1.m(); a2.m(); }}
class A{ public void m(){ //do something }}
aspect TraceA{ after(): call (void A.m()){ System.out.println(“ }}
aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) }}
>> call to A.m()>> call to A.m()>> execution of B.m()>>
• Aspects depend on dynamic binding
• Effects of dynamic binding not statically computable
K. Mehner 7 Lancaster University
Many more problems…• Aspect behaviour is highly dynamic
– Depending on dynamic binding– Conditions on joinpoints evaluated at runtime– Dynamic aspects– Aspects introducing new join points – Aspects changing inheritance structure
• Inter-Aspect relations– Interference– Dependencies
• Limitations for formal analysis – Static analysis of dynamic binding NP-hard– Similar results for all dynamic issues
K. Mehner 8 Lancaster University
Outline
• Requirements
• Proposed solution
• State-of-the-art runtime inspection
• Runtime inspection for AOP
• Example revisited
K. Mehner 9 Lancaster University
Requirements
• Problems are highly dynamic• Get missing information from execution!• Cumbersome and error prone without tool support
– Macros and printlines– Forgetting statement and branches (“sampling errors“)
• Debuggers – Only show one state at a time– No history recording nor a complete picture– Stepwise only is timeconsuming
• Automated Tracing– Recording history
• Test case generation (not addressed here)– Coverage by user chosen input error prone
K. Mehner 10 Lancaster University
Proposed solution: Tool support
• Runtime information is essential• Used by many different tools
– Debugging, Tracing, Monitoring,…• General instead of adhoc solution• Standardization for
– Implementation/Architecture– Control model– Data format– Debug information– Visualizations
K. Mehner 11 Lancaster University
Events
Inspection
Control
Reflection
State-of-the-art runtime inspection
• Events– Predefined list of observable events (program continues)– Event records (limited information)– Filters
• Inspection– Entire state (only available if program stopped)– No history recording
K. Mehner 12 Lancaster University
Events
Inspection
Control
Reflection
State-of-the-art runtime inspection
• Control– Stop/continue on events, break-, watchpoints– Step– Stop/continue individual threads – Record & replay
• Reflection– Separate API
K. Mehner 13 Lancaster University
Events
Inspection
Control
Reflection
What extensions are needed?
Cover aspect states
Extend granularity of execution steps
Runtime changes to aspect order
• Extensions for every layer of runtime inspection• How to we determine
– New event types?– State information needed?– Execution granularity and break-/watchpoints?
• Base it on a general approach
Aspect events
K. Mehner 14 Lancaster University
A Generic AOP model
• Open issues– Granularity of aspect event model – Granularity of aspect state model
• Runtime perception influenced by implementation approaches
• Uniform Approach
• Based on Generic AOP model
K. Mehner 15 Lancaster University
Example: Advice weaves
• Statics: predefined event types, matches, predicates, …
• Dynamics: Chain of related actions– Match
• Matched Event, Parameters • Quantifying predicate (Pointcut)• Condition evaluation• List of triggered activities• Order/Conflict Resolution
– Execution of activities• Recursion: Triggers new chains…
K. Mehner 16 Lancaster University
Event model for advices
• Advices triggered by OO events– Extend existing event record with chain
• Chain accessible indepently from OO events– Create new events for actions in chain
• Trade-Off• Conflict resolution
– results in order– be more explicit
• Configurable events
K. Mehner 17 Lancaster University
Example Revisited:Tracing Method Calls
Time Event type Caller Callee Method/Advice
Matched Event
Advice List
Pointcut
Conditions
… … … … …. … … … …
1 M_Entry main a1: A void m()
2 M_Exit main a1: A void m()
class Application{ static void main(String args[]){ A a1 = new A; A a2 = new B; a1.m(); a2.m(); }}
When does the match take place?OO event model insufficient! Detach message sent from method call!
aspect TraceA{ after(): call (void A.m()){ System.out.println(“ }}
K. Mehner 18 Lancaster University
Trace format for AspectJ adviceT Event type Caller Callee Method/
AdviceMatched Event
Advice List
Pointcut
Conditions
…
3 JP_Match Ref [1,2] TraceA. after():
call(void m())
After():call (void m())
-
4 Advice_Activ
TraceA. after():
call(void m())
5 Advice_Exec
TraceA after():call (void m())
6 M_Entry TraceA Out println()
K. Mehner 19 Lancaster University
UML tracea2B
a1A
System.outaspect TraceA aspect TraceBAppl
4.1: println("call to A.m()")
2.1: println("call to A.m()")
5: after a2.m()
4: after a2.m()
3: m():void
1: m():void
2: after: a1.m
5.1: println("execution of B.m()")
<join point> a1.m <matches> {TraceA.after():call(void A.m())}<join point> a1.m <activates> TraceA.after():call(void A.m())
<join point> a2.m <matches> {TraceA.after():call(void A.m()),TraceB.after():execution(void B.m()}}<join point> a2.m <activates> TraceA.after():call(void A.m())<join point> a2.m <activates> TraceB.after():execution(void B.m())
K. Mehner 20 Lancaster University
Useful trace information
• Compare traces with static analysis
• Add partial information to editor
• Classification of runtime information
K. Mehner 21 Lancaster University
Conclusion
• Runtime information can improve understanding of aspects
• Adapt runtime inspection models from other areas of software development
• Make the right choices for extensions based on generic AOP model
K. Mehner 22 Lancaster University
The end