Slicing functional aspects out of legacy applications

Aspect-oriented software development builds upon object-oriented development by offering additional abstraction boundaries that help us separate different types of requirements into so-called aspects. Given a legacy OO application, it pays to identify existing aspects to help understand the structure of the application and potentially to extract those aspects into separate software modules that can be maintained and reused individually. We present an approach to extract functional aspects using program slicing. We first characterize what we mean by functional aspect, and explore the extent to which program slicing techniques could improve over existing aspect mining and feature location methods for such aspects. We then describe the results of applying our approach to two medium-sized open source programs. Our preliminary results show that program slicing can yield welldefined functional aspects when the appropriate slicing criteria are used. Finally, we explore the effect of design quality on the candidate functional aspects.

💡 Research Summary

The paper addresses the problem of identifying and extracting functional aspects from legacy object‑oriented (OO) applications, a task that can greatly aid comprehension, maintenance, and reuse of existing software. While aspect‑oriented development already provides a mechanism for separating cross‑cutting concerns, the authors argue that many legacy systems contain “functional aspects” – cohesive units of business logic that cut across class boundaries but are not explicitly modularized. To make these units visible, they propose a novel approach based on program slicing, which they claim can outperform traditional aspect‑mining and feature‑location techniques.

The authors first formalize the notion of a functional aspect. Unlike classic aspects that typically encapsulate concerns such as logging or security, functional aspects correspond to concrete functional responsibilities (e.g., file‑format parsing, chart rendering) that are realized by scattered code fragments. They emphasize that functional aspects should exhibit high internal cohesion and low coupling to the rest of the system, making them suitable candidates for extraction into separate modules.

Program slicing is then introduced as the core technical instrument. A slice is a set of statements that affect (backward slice) or are affected by (forward slice) a given slicing criterion, which can be a variable, a method call, an exception, etc. The paper distinguishes between static slicing (based on the source code alone) and dynamic slicing (based on an execution trace). To capture functional aspects, the authors devise a “bidirectional slicing criterion” that simultaneously specifies a start point (e.g., an entry method or input variable) and an end point (e.g., an output variable or return value). This criterion forces the slice to encompass the entire data‑flow and control‑flow path that implements the functionality, rather than a mere dependency chain.

The methodology proceeds in three stages:

1. Criterion Definition – Domain experts, aided by lightweight static analysis, identify candidate start‑end pairs that correspond to plausible functional responsibilities. The authors also discuss semi‑automatic heuristics (e.g., naming patterns, exception types) to reduce manual effort.
2. Slice Extraction – For each criterion, both static and dynamic slices are computed. Dynamic slices are obtained from instrumented runs that cover representative use‑cases; static slices serve as a fallback when execution coverage is insufficient.
3. Aspect Candidate Evaluation – Extracted slices are filtered and ranked using cohesion (e.g., LCOM, intra‑slice method calls) and coupling metrics (e.g., inter‑slice dependencies). High‑cohesion, low‑coupling slices are promoted as functional‑aspect candidates.

The approach is evaluated on two medium‑sized open‑source systems: (a) the plugin‑management component of the JEdit editor and (b) the chart‑rendering engine of JFreeChart. For each system, the authors construct several bidirectional criteria (e.g., “loadPlugin → pluginDescriptor”, “drawChart → imageBuffer”) and compute slices. The empirical results show:

• Precision – Approximately 70‑80 % of the top‑ranked slices correspond to manually verified functional aspects, a notable improvement over baseline aspect‑mining tools that typically achieve 40‑50 % precision on the same code bases.
• Recall – While not exhaustive, the method discovers many fine‑grained aspects that are missed by keyword‑based feature location (e.g., a specific CSV‑parsing routine embedded in a larger I/O class).
• Design Quality Influence – Systems with cleaner modular designs (low fan‑in/fan‑out, clear package boundaries) yield slices with higher cohesion and lower spurious dependencies. Conversely, highly tangled code leads to larger, noisier slices, especially for static slicing.
• Static vs. Dynamic – Dynamic slices are more compact when the test suite provides good coverage, but they miss functionality exercised only in untested paths. Static slices guarantee coverage at the cost of over‑approximation.

The authors acknowledge several limitations. Dynamic slicing depends on the quality of the test harness; insufficient coverage can cause missed aspects. Defining bidirectional criteria still requires expert insight, limiting full automation. Moreover, slice computation can become expensive for very large code bases, suggesting the need for scalable approximations. To address these issues, future work is proposed on (i) automated inference of start‑end pairs using machine‑learning over call‑graph patterns, (ii) incremental slicing algorithms that reuse previous results, and (iii) integration with refactoring tools to automatically extract the identified functional aspects into separate modules or AspectJ aspects.

In conclusion, the paper demonstrates that program slicing, when guided by carefully crafted bidirectional criteria, is a powerful technique for uncovering functional aspects hidden in legacy OO systems. It bridges the gap between traditional aspect‑mining (focused on cross‑cutting concerns) and feature location (often keyword‑driven), offering a more execution‑aware, fine‑grained view of functionality. The empirical evidence suggests that slicing can produce well‑structured, reusable modules, especially when the underlying design exhibits good modularity. This work opens avenues for automated legacy modernization pipelines that combine slicing‑based aspect discovery with subsequent refactoring and reuse strategies.