Affected Slice Graph (ASG)

• Affected Slice Graph (ASG) is a static graph that captures the slice of program elements affected by a change, integrating both classical and object-oriented dependences.
• It employs hierarchical decomposition slicing to structure affected packages, classes, methods, and statements for detailed change impact analysis.
• ACC quantifies coupling-based fault-proneness to prioritize regression tests by assigning weights to affected nodes in object-oriented programs.

Affected Slice Graph (ASG) is a static, change-centric graph representation of the slice of program elements affected by a specific modification in an object-oriented program. In "A Slice-Based Change Impact Analysis for Regression Test Case Prioritization of Object-Oriented Programs" (Panda et al., 26 Aug 2025), ASG is introduced as the central structure in a regression test case prioritization method that detects application-specific affected elements by hierarchical decomposition slicing, models those elements and their object-oriented dependences in a graph, computes a coupling-based fault-proneness measure called Affected Component Coupling (ACC), and prioritizes tests according to the weights of the affected nodes they cover. The approach is explicitly designed for Java and emphasizes object-oriented dependences beyond classical control- and data-dependence models.

1. Conceptual definition and graph model

ASG is defined as the graph representation of the slice of program elements affected by a specific change (Panda et al., 26 Aug 2025). The slice is computed with respect to a slicing criterion that coincides with the modification point. ASG is built on top of an extended, object-oriented system dependence graph (EOOSDG), which encodes both classical dependences and object-oriented dependences. ASG retains only those EOOSDG nodes and edges reachable via forward and backward traversals from the change, subject to traversal constraints intended to avoid double counting or redundant propagation.

The graph is hierarchical. Its nodes correspond to affected program elements at multiple levels of granularity: package nodes, class nodes, method nodes including method parameters, and statement nodes including read/write events and type uses. The underlying slicing process uses hierarchical decomposition (HD) with the progression package $\rightarrow$ class $\rightarrow$ method $\rightarrow$ statement. This hierarchy is not only representational; it also supports the selection of regression test cases at progressively finer granularity.

ASG edges encode a broad range of structural and semantic dependences characteristic of object-oriented code. The paper enumerates inheritance/implementation edges, control dependency edges, membership edges, instantiation edges, parameter passing edges, data dependency edges, package membership edges, type dependency edges, inherited membership edges, method overridden edges, read/write dependency, polymorphic call edges, summary edges, generic edges, and has edges. In this formulation, a change in a statement $s$ is used as the slicing criterion $(s,V)$ in the general sense. Forward traversal discovers program parts affected by the change, and backward traversal discovers parts influencing those affected parts.

A central point of the model is that ASG is not equivalent to a classical PDG, SDG, or call graph. PDGs and SDGs emphasize control and data dependences, while call graphs focus on invocation relations. ASG, by contrast, incorporates inheritance, overridden methods, polymorphic calls, membership, instantiation, and type relations in addition to control and data dependences. This suggests a more faithful representation of ripple effects in Java programs whose fault propagation is mediated by object-oriented structure rather than by control flow alone.

2. Construction from source code and hierarchical decomposition slicing

The construction pipeline begins with source fact extraction and formation of the EOOSDG (Panda et al., 26 Aug 2025). Java source is converted to srcML via src2srcml. XPath is then used to instrument and extract statement-level data and control dependences from the srcML representation. Higher-level object-oriented dependences such as inheritance, membership, type dependency, instantiation, and polymorphic calls are obtained from Imagix4D. The implementation maintains a program dictionary with sets of packages, classes, methods, statements, and per-edge-type dependence sets.

HD slicing computes the affected slice and the ASG with the modification point as the slicing criterion. The procedure uses a constrained two-direction traversal over the EOOSDG. In the forward traversal, the algorithm traverses forward from the modification point along EOOSDG edges except method overridden edges and marks every reached node into worklist $Q_1$. In the backward traversal, the algorithm uses two passes. In Pass-1, for each $q \in Q_1$, it traverses backward while avoiding polymorphic call edges, inherited membership edges, parameter-out edges, and generic-out edges; reached nodes are marked in $Q_2$. In Pass-2, from each $q \in Q_2$, it traverses backward while avoiding parameter-in edges, generic-in edges, and any edge traversed in Pass-1; reached nodes are marked in $Q_3$.

The ASG node set is then assembled as

$\rightarrow$0

Hierarchical decomposition partitions this set by granularity:

$\rightarrow$1

$\rightarrow$2

$\rightarrow$3

and

$\rightarrow$4

Accordingly, the final hierarchical ASG consists of affected packages, affected classes, affected methods, and affected statements.

The reported complexity of building the ASG is linear in the number of ASG nodes for traversal-based inflow and outflow computation and quadratic in the worst case for ACC computation. Specifically, the traversal to compute inflow and outflow per node is $\rightarrow$5 for $\rightarrow$6 ASG nodes, computing ACC for all nodes is $\rightarrow$7 in the worst case, space usage for nodes is $\rightarrow$8, and space for edges is $\rightarrow$9, yielding $\rightarrow$0 memory. A plausible implication is that the graph model is structurally expressive but may become resource-intensive when the affected region expands substantially.

3. Affected Component Coupling (ACC) and node fault association

ACC is the normalized coupling measure used as a proxy for fault-proneness (Panda et al., 26 Aug 2025). It quantifies how much information a node distributes to and receives from other nodes in the ASG, and the formulation treats inflow and outflow symmetrically. This symmetry reflects the hypothesis that ripple changes propagate along any dependence dimension rather than preferentially in one direction.

Let the ASG be

$\rightarrow$1

For any node $\rightarrow$2, the inflow set is

$\rightarrow$3

and the outflow set is

$\rightarrow$4

The dependence set is

$\rightarrow$5

and node coupling is

$\rightarrow$6

The paper states that $\rightarrow$7 and that larger values imply higher fault-proneness.

ACC is updated for composite nodes by averaging the coupling of the composite node with the couplings of its members. For a method node $\rightarrow$8 with $\rightarrow$9 member elements $s$0,

$s$1

For a class node $s$2 with $s$3 members,

$s$4

For a package node $s$5 with $s$6 members,

$s$7

The paper also defines slice cohesion,

$s$8

but explicitly notes that it is used to assign an overall weight to the slice and not directly for prioritization.

After ACC values are computed, the approach clusters them using k-means with $s$9 into three fault association categories. Critical fault association corresponds to $(s,V)$0 with weight 3, moderate fault association corresponds to $(s,V)$1 with weight 2, and weak fault association corresponds to all remaining cases with weight 1. The paper reports centroids around $(s,V)$2, $(s,V)$3, and $(s,V)$4 for the sample program. A common misunderstanding is to treat ACC as a generic software coupling metric; in this formulation it is specific to affected nodes in the ASG and is therefore explicitly change-localized.

4. Regression test case prioritization over ASG coverage

The prioritization method maps regression tests to ASG coverage and then ranks them by aggregate node weight (Panda et al., 26 Aug 2025). Coverage analysis is performed with JaBUTi to determine which ASG nodes are executed by each selected regression test case. The selected tests themselves are obtained through hierarchical selection with respect to the affected nodes.

For a test case $(s,V)$5, the algorithm distinguishes the critical, moderate, and weak nodes covered by that test. If $(s,V)$6 denotes the $(s,V)$7-th critical node covered by $(s,V)$8, then

$(s,V)$9

If $Q_1$0 denotes covered moderate nodes, then

$Q_1$1

If $Q_1$2 denotes covered weak nodes, then

$Q_1$3

The total test-case weight is

$Q_1$4

Tests are prioritized by sorting in decreasing order of $Q_1$5. Ties are broken lexicographically by $Q_1$6, then $Q_1$7, then $Q_1$8. Any remaining ties are left as equal priority.

The running example uses classes Shape, Rectangle, Triangle, and TestShape, with a change in the area computation of Triangle or Rectangle serving as the slicing criterion. For the Triangle-related region, the paper gives sample ACC values:

$Q_1$9

$q \in Q_1$0

$q \in Q_1$1

$q \in Q_1$2

$q \in Q_1$3

$q \in Q_1$4

$q \in Q_1$5

The updated composite-node couplings are then

$q \in Q_1$6

$q \in Q_1$7

and

$q \in Q_1$8

The paper also presents a concrete coverage example for five selected tests $q \in Q_1$9 through $Q_2$0. Test $Q_2$1 covers the nodes $Q_2$2. Its critical nodes are $Q_2$3, yielding $Q_2$4; its moderate nodes are $Q_2$5, yielding $Q_2$6; and its weak nodes are $Q_2$7, yielding $Q_2$8. Therefore,

$Q_2$9

The final prioritized order for the example is $q \in Q_2$0.

5. Empirical results and evaluation methodology

The evaluation uses 15 Java programs, including 10 SIR benchmarks—Stack, Sorting, BST, CrC, DLL, Elevator spl, Email spl, GPL spl, Jtopas, and Nanoxml—and 5 academic programs (Panda et al., 26 Aug 2025). The benchmark corpus totals 19,369 LOC, 185 classes, and 2,048 methods. Across the experiments, 150 ASGs were constructed; the smallest ASG has 33 nodes, the largest 5,233, and the total affected nodes across changes are 28,452, with average approximately 152 per change. Coverage is measured using JaBUTi. Mutation analysis is performed with MuClipse, the MuJava Eclipse plugin, using both traditional and object-oriented mutation operators and randomly sampling mutants per program for practicality; the reported average is 34 mutants per program. A mutant is considered killed if JUnit test outputs differ from the original.

Prioritization effectiveness is evaluated with Rothermel’s APFD:

$q \in Q_2$1

where $q \in Q_2$2 is the number of tests, $q \in Q_2$3 is the number of faults, and $q \in Q_2$4 is the position of the first test that reveals fault $q \in Q_2$5. The paper notes that the standard form is

$q \in Q_2$6

while the paper’s equation uses $q \in Q_2$7 in the summation index.

The reported mutation results indicate that mutant presence in affected parts ranges from 12% for DLL to 94% for Sorting, with average approximately 47%. Mutants killed by prioritized tests range from 70% to 95%, with average approximately 85%. For coverage, the average percentage of affected nodes covered (APNC) by Panigrahi and Mall’s ANC approach is 77.2%, whereas the fault-prone affected node coverage (FPANC) in the ASG-based method is 80.6%. The APFD comparison reports that FPANC improves APFD by approximately 8% over ANC across the fifteen programs. With precomputed coverage and ASG, end-to-end prioritization time ranges from 1.3 to 3.87 seconds per program, with average approximately 2.4 seconds.

These results support the paper’s central claim that test cases executing fault-prone affected parts have a higher chance to reveal faults earlier than other test cases in the test suite. At the same time, the evaluation is framed specifically around mutation faults and static analysis of Java programs, so the evidence is strongest for that setting.

6. Relation to adjacent approaches, implementation requirements, and limitations

The paper positions ASG against several families of regression test prioritization methods (Panda et al., 26 Aug 2025). Relative to PDG/SDG and call-graph approaches, ASG derives from an EOOSDG and represents a richer set of dependences than models restricted to control/data edges or method invocations. Relative to slice-based relevant slices as in Jeffrey and Gupta, the distinction is that this method does not merely count modified slice statements; it weights slice elements by coupling-based fault-proneness. Relative to static JUnit call-graph prioritization as in Mei et al., the paper characterizes ASG as finer-grained and more object-oriented, while also noting reduced scalability. Relative to similarity-based or mutation-only prioritization such as Fang et al. and Lou et al., the approach integrates change-based slicing with coupling-derived fault-proneness rather than relying only on statement-count similarity or mutants. Relative to EFSM model-based prioritization as in Korel et al., it operates directly on source-level object-oriented dependences and explicitly targets affected code.

Implementing the method requires source-to-XML conversion with src2srcml, fact extraction with XPath, object-oriented dependence extraction with Imagix4D or a similar static analysis tool, EOOSDG construction over all edge types, HD slicing with the specified forward and two-pass backward traversal rules, coverage acquisition through JaBUTi or equivalent instrumentation, ACC computation for each ASG node, k-means clustering with $q \in Q_2$8, and test ranking by $q \in Q_2$9 with the prescribed tie-breakers. The computational profile reported in the paper gives worst-case $Q_3$0 ACC computation, prioritization cost $Q_3$1 to compute test weights, and $Q_3$2 sorting if $Q_3$3, with space complexity $Q_3$4. The parameter recommendations given are to start with thresholds 0.7 and 0.6 for critical, moderate, and weak categories and to use weights 3, 2, and 1; the paper also notes that learned centroids can refine these thresholds per project.

The method is most effective, according to the paper, for object-oriented programs with significant use of inheritance, polymorphism, and inter-class relations; regression scenarios where changes are localized but ripple through object-oriented dependences; and test suites where coverage is known and mapping to fine-grained slices is feasible. Several assumptions and threats to validity are also identified. Coverage information must be available and must accurately map test cases to ASG nodes. ACC is assumed to be a reasonable surrogate for fault-proneness. The weights $Q_3$5 and thresholds $Q_3$6 are assumed to separate fault association levels appropriately. Limitations include the absence of separate treatment for coupling in inheritance hierarchies versus across hierarchies, limited analysis of interface-induced coupling, the use of coupling without cohesion for fault-proneness estimation, scalability concerns for very large codebases, and reliance on primary mutants rather than secondary mutants or industrial fault distributions. The paper further notes that the practical value of the APFD difference depends on cost models such as prioritization time and testing budgets, which are not analyzed there.

In this formulation, ASG can be understood as a source-level, object-oriented change-impact representation that supports regression test prioritization by explicitly coupling slice construction with a normalized dependence-based fault association score. ACC supplies the ranking signal, while the ASG supplies the affected structural context in which that signal is computed.