Representing concerns in source code

Abstract

Many program evolution tasks involve source code that is not modularized as a single unit. Furthermore, the source code relevant to a change task often implements different concerns, or high-level concepts that a developer must consider. Finding and understanding concerns scattered in source code is a difficult task that accounts for a large proportion of the effort of performing program evolution. One possibility to mitigate this problem is to produce textual documentation that describes scattered concerns. However, this approach is impractical because it is costly, and because, as a program evolves, the documentation becomes inconsistent with the source code. The thesis of this dissertation is that a description of concerns, representing program structures and linked to source code, that can be produced cost-effectively during program investigation activities, can help developers perform software evolution tasks more systematically, and on different versions of a system. To validate the claims of this thesis, we have developed a model for a structure, called concern graph, that describes concerns in source code in terms of relations between program elements. The model also defines precisely the notion of inconsistency between a concern graph and the corresponding source code, so that it is possible to automatically detect and repair inconsistencies between a description of source code and an actual code base. To experiment with concern graphs, we have developed a tool, called FEAT, that allows developers to iteratively build concern graphs when investigating source code, to view the code related to a concern, and to perform analyses on a concern representation. Using FEAT, we have evaluated the cost and usefulness of concern graphs in a series of case studies involving the evolution of five systems of different size and style. The results show that concern graphs are inexpensive to create during program investigation, can help developers perform program evolution tasks more systematically, and are robust enough to represent concerns in different versions of a system.

Reusing Program Investigation Knowledge for Code Understanding

“…Ideally, concern mappings should be produced with as little effort as possible. Potential strategies to achieve this aim include: a) Creating the mappings opportunistically during program investigation [13], b) recording each transaction to a revision control system, c) using automatic techniques based on static and dynamic analysis (e.g., [5,20]), and d) recording and analyzing traces of a developer's navigation through the source code (see Section 6).…”

“…At the end of the task, this developer is likely to have located the corresponding code and to have acquired some understanding of it. Knowledge about a change task can be expressed in terms of the different concerns associated with the task [13]. Simply put, concerns are high-level concepts relevant to developers, such as individual features, requirements, or design decisions.…”

“…Prior studies have provided evidence that documenting concerns by identifying the source elements involved in their implementation can provide immediate benefits to developers involved in a non-trivial change task [9,13]. We henceforth refer to this activity as concern mapping.…”

Documenting after the fact: Recovering architectural design decisions

“…With automated tool support, like the FEAT tool (Robillard and Murphy, 2007), these kind of abstractions can easily be made without losing traceability to the source code where these abstractions originate from.…”

An Approach for Modeling and Analyzing Crosscutting Concerns

“…A concern in software defined as is anything a developer may consider as a conceptual unit such as features, security requirements, and design idioms [13]. The concern that is scattered and tangled throughout multiple modules is called a crosscutting concern [13].…”