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 2Lancaster 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 3Lancaster 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 4Lancaster 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 5Lancaster 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 6Lancaster 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() >> execution of B.m() >> Aspects depend on dynamic binding Effects of dynamic binding not statically computable

K. Mehner 7Lancaster 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 8Lancaster University Outline Requirements Proposed solution State-of-the-art runtime inspection Runtime inspection for AOP Example revisited

K. Mehner 9Lancaster 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 10Lancaster 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 11Lancaster 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 12Lancaster 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 13Lancaster 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 14Lancaster 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 15Lancaster 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 16Lancaster 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 17Lancaster University Example Revisited:Tracing Method Calls TimeEvent typeCallerCalleeMethod/ Advice Matched Event Advice List Point cut Condi tions …………….………… 1M_Entrymaina1: Avoid m() 2M_Exitmaina1: Avoid 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 18Lancaster University Trace format for AspectJ advice TEvent typeCallerCalleeMethod/A dvice Matched Event Advice List Pointc ut Cond itions … 3JP_MatchRef [1,2]TraceA. after(): call(void m()) After() :call (void m()) - 4Advice_ Activ TraceA. after(): call(void m()) 5Advice_ Exec TraceAafter(): call (void m()) 6M_EntryTraceAOutprintln()

K. Mehner 19Lancaster University UML trace

K. Mehner 20Lancaster University Useful trace information Compare traces with static analysis Add partial information to editor Classification of runtime information

K. Mehner 21Lancaster 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 22Lancaster University The end