Software MaintenanceSource CodeEngineeringData ScienceCode RefactoringProgram AnalysisConcern GraphsSoftware TestingSoftware EngineeringSource Code AnalysisConcern GraphSoftware AspectComputer ScienceSoftware VisualizationStatic Program AnalysisSoftware AnalysisSystem SoftwareSoftware Design
Many maintenance tasks target concerns that are poorly modularized, and existing line‑based representations make it difficult to locate and manage scattered concerns. This paper introduces the Concern Graph representation, which abstracts concern implementation details and explicitly models inter‑part relationships, and presents the FEAT tool to explore tradeoffs in manipulating such graphs. Concern Graphs provide an abstraction that maps cleanly back to source code, and the FEAT tool, supported by case studies, evaluates the feasibility, usability, and scalability of this approach. Using FEAT, the authors identified and described concerns related to software change tasks, demonstrating that Concern Graphs document change concerns, are usable by developers unfamiliar with them, and scale to industrial‑sized programs.
Many maintenance tasks address concerns, or features, that are not well modularized in the source code comprising a system. Existing approaches available to help software developers locate and manage scattered concerns use a representation based on lines of source code, complicating the analysis of the concerns. In this paper, we introduce the Concern Graph representation that abstracts the implementation details of a concern and makes explicit the relationships between different parts of the concern. The abstraction used in a Concern Graph has been designed to allow an obvious and inexpensive mapping back to the corresponding source code. To investigate the practical tradeoffs related to this approach, we have built the Feature Exploration and Analysis tool (FEAT) that allows a developer to manipulate a concern representation extracted from a Java system, and to analyze the relationships of that concern to the code base. We have used this tool to find and describe concerns related to software change tasks. We have performed case studies to evaluate the feasibility, usability, and scalability of the approach. Our results indicate that Concern Graphs can be used to document a concern for change, that developers unfamiliar with Concern Graphs can use them effectively, and that the underlying technology scales to industrial-sized programs.
20