Aspect Dependence Graphs (ADG)

• Aspect Dependence Graphs (ADG) are intermediate representations that capture control-flow and data-flow dependencies within aspect code in AspectJ.
• They represent dependencies in advices, pointcut definitions, inter-type declarations, and methods using control, data, call, parameter, and membership edges.
• ADGs are woven with System Dependence Graphs (SDG) at join points to form a CASDG, enabling accurate dynamic slicing and comprehensive program analysis.

An Aspect Dependence Graph (ADG) is an intermediate, dependence-based program representation specifically devised to capture the control-flow and data-flow dependencies internal to aspect code in AspectJ programs. Analogous to the System Dependence Graph (SDG) used for base (non-aspect) Java code, the ADG models intra-aspect relations among advices, pointcut definitions, inter-type declarations (introductions), and methods declared within an aspect. ADGs enable the unification of aspect code and base code dependences within a single program representation, which, when integrated with SDGs through weaving edges at join-points, forms the Concurrent Aspect-oriented System Dependence Graph (CASDG). The CASDG underpins dynamic slicing algorithms for concurrent aspect-oriented programs (Ray et al., 2014).

1. Scope, Purpose, and Role of ADG

The ADG is constructed to represent all control and data dependences present within:

• Advice bodies (including before, after, around, after-returning, and after-throwing)
• Pointcut definitions (which select join-points but have no executable body)
• Inter-type declarations (introductions) that augment classes with new fields, methods, or interfaces
• Ordinary methods declared within aspects

The principal role of the ADG is to function as the core dependence abstraction for aspect code, mirroring the function of SDG for base code. Post-construction, each ADG is woven into the SDG at the locations (join-points) designated by its pointcuts, thereby enabling unified, program-wide dependence analysis and facilitating precise dynamic slicing across the entire aspect-oriented program (Ray et al., 2014).

2. Formal Structure and Mathematical Definition

An ADG is defined as a directed graph

$\text{ADG} = (N, E)$

where:

• $N$ is a finite set of vertices, each representing one of:
  • Aspect-entry vertex (unique root)
  • Advice-entry vertex (one per advice), with further nodes for statements and predicates within each advice
  • Pointcut-entry vertex (one per pointcut)
  • Introduction-entry vertex (for each inter-type declaration), with corresponding body nodes
  • Method-entry vertex and body nodes for helper methods
• $E \subseteq N \times N$ is the edge set, partitioned as:
  1. Control-dependence edges ($E_C$): $(u \to v) \in E_C$ iff $v$ is control-dependent on $u$ (e.g., governed by an if-condition) within the same advice, introduction, or method.
  2. Data-dependence edges ($E_D$): Classical def-use edges linking a definition vertex of $x$ to a subsequent use of $x$, provided no intervening redefinition occurs.
  3. Call and parameter-passing edges ($E_\text{CALL}$, $E_\text{PARAM}$): Connect, for instance, advice entries to pointcut entries, as well as actual-in to formal-in and formal-out to actual-out parameter nodes.
  4. Aspect-membership edges ($E_M$): Link the aspect-entry root to each advice, pointcut, introduction, and method entry in the aspect, ensuring hierarchical organization.

Formally, for an aspect $A$,

• $N = \{\text{entry}_A\}$ $$\,\cup\, \bigcup_{\text{advice} \in \text{Advs}(A)} (\{\text{entry}_\text{adv}\} \cup \text{Stmts}(\text{adv}) \cup \text{Preds}(\text{adv})) \, \cup\, \bigcup_{\text{pc} \in \text{PCs}(A)} \{\text{entry}_\text{pc}\} \, \cup\, \bigcup_{\text{int} \in \text{Ints}(A)} (\{\text{entry}_\text{int}\} \cup \text{Stmts}(\text{int}) \cup \text{Preds}(\text{int})) \, \cup\, \bigcup_{m \in \text{Meths}(A)} (\{\text{entry}_m\} \cup \text{Stmts}(m) \cup \text{Preds}(m))$$

• $$E = E_C \cup E_D \cup E_\text{CALL} \cup E_\text{PARAM} \cup E_M$$

This structure provides a detailed graph model of aspect internals, supporting subsequent weaving into the CASDG (Ray et al., 2014).

3. Integration with System Dependence Graphs and CASDG Construction

The SDG models dependence relations in base (non-aspect) code. For a full aspect-oriented system, integration requires:

• Construction of an SDG for the base code.

• For each aspect $A$, independent construction of its ADG.

• Augmentation of the combined node and edge sets by adding weaving edges ($E_W$) denoting advice application.

At every join-point $j$ in the SDG that matches pointcut $pc$ from aspect $A$, the construction adds:

1. A weaving edge $(j \rightarrow \text{entry}_\text{adv})$ for each advice bound to $pc$, linking control to the advice.

2. Parameter edges between join-point actual parameters and the advice's formals, if applicable.

The resulting global graph is the CASDG:

$$\text{CASDG} = (N_{SD} \cup \bigcup_A N_{AG}, E_{SD} \cup \bigcup_A E_{AG} \cup E_W)$$

This unified representation enables sound and complete dynamic slicing, accurately reflecting the semantics of woven aspect-oriented programs (Ray et al., 2014).

4. Construction Algorithm

The construction process is divided into four principal algorithmic phases:

1. SDG Construction:

   • Build the SDG for the base code via conventional program analysis.
2. Aspect-wise ADG Construction:
   • For each aspect:
     • Create an aspect-entry node.
     • Build entry nodes and subgraphs for each pointcut, advice, introduction, and method.
     • Use the method-dependence-graph constructor for advice, introduction, and method bodies.
     • Attach membership edges from the aspect entry to all member entries.
3. Weaving:
   • For each matching join-point and pointcut:
     • Insert weaving edges from the SDG to the advice-entries per aspect semantics.
     • Add necessary parameter-passing arcs.
4. CASDG Formation:
   • Merge all nodes and edges from SDG, ADGs, and weaving edges to produce the final CASDG suitable for dynamic analysis and slicing algorithms.

procedure BUILD_CASDG(BaseCode, Aspects) SDG ← BUILD_SDG(BaseCode) for each Aspect A in Aspects do N_AG(A) ← {eA}; E_AG(A) ← ∅ for each pointcut pc in A do N_AG(A) ← N_AG(A) ∪ {e_pc}; E_AG(A) ← E_AG(A) ∪ { (eA→e_pc) } for each advice adv in A do (N_adv, E_adv) ← BUILD_MDG(adv.body) let e_adv be the MDG's entry node N_AG(A) ← N_AG(A) ∪ N_adv E_AG(A) ← E_AG(A) ∪ E_adv ∪ { (eA→e_adv) } for each inter-type declaration int in A do (N_int, E_int) ← BUILD_MDG(int.body) let e_int be the MDG's entry node N_AG(A) ← N_AG(A) ∪ N_int E_AG(A) ← E_AG(A) ∪ E_int ∪ { (eA→e_int) } for each method m in A do (N_m, E_m) ← BUILD_MDG(m.body) e_m ← entry(MDG) N_AG(A) ← N_AG(A) ∪ N_m E_AG(A) ← E_AG(A) ∪ E_m ∪ { (eA→e_m) } EW ← ∅ for each Aspect A in Aspects do for each pointcut pc in A do for each join-point j in SDG matching pc do for each advice adv bound by pc do e_adv ← entry-vertex of advice adv in N_AG(A) EW ← EW ∪ { (j → e_adv) } EW ← EW ∪ PARAM_ARCS(j, adv) CASDG ← (SDG.nodes ∪ all N_AG(A), SDG.edges ∪ all E_AG(A) ∪ EW) return CASDG end BUILD_CASDG

(Ray et al., 2014)

5. Theoretical Properties and Correctness

• Soundness: Every control-flow construct in advice, introduction, or method bodies yields precisely the control-dependence edges ($E_C$). All def/use pairs result in corresponding data-dependence edges ($E_D$). Membership edges ensure all members are hierarchically reachable. The correctness is underpinned by reusing known-sound SDG/MDG constructions for every aspect subcomponent.
• Completeness: No dependencies are omitted as the standard analysis algorithms are applied exhaustively to aspect internals. Aspects and base code remain separated until weaving, preventing cross-contamination of dependencies.
• Weaving Correctness: Weaving edges are inserted strictly where required by AspectJ join-point matching semantics. This guarantees that the resulting CASDG accurately models actual program execution semantics for slicing and other analyses.

No step-by-step proof appears, but the construction is formally justified based on the established soundness of component representations (Ray et al., 2014).

6. Illustrative Example

Consider the following simple AspectJ fragment:

public aspect ThreadAspect { public pointcut classic(): execution(void run()); before(): classic() { System.out.println("Starting aspect code for run"); } after(): classic() { System.out.println("Ending aspect code for run"); } }

The corresponding ADG contains:

• A root aspect-entry node ($eA$)
• A pointcut-entry node ($e_{pc=classic}$) with no body (hence no further control or data dependence edges)
• Advice-entry nodes for the “before” and “after” advices ($e_{adv\_before}$, $e_{adv\_after}$), each with local body nodes for their respective println calls, including their internal control and data dependences

Aspect-membership edges connect $eA$ to $e_{pc=classic}$, $e_{adv\_before}$, and $e_{adv\_after}$. In the full CASDG, the SDG node representing each run() method execution is connected to these advice entries with weaving edges, ensuring precise modeling of the dynamic semantics: each execution of run() invokes the before and after advice in conjunction with the base code. This exemplifies the effective unification of aspect-oriented constructs within program slicing infrastructure (Ray et al., 2014).