Differentiating Roles of Program Elements in Action-Oriented Concerns

Many techniques have been developed to help programmers locate source code that corresponds to specific functionality, i.e., concern or feature location, as it is a frequent software maintenance activity. This paper proposes operational definitions for differentiating the roles that each program element of a concern plays with respect to the concern's implementation. By identifying the respective roles, we enable evaluations that provide more insight into comparative performance of concern location techniques. To provide definitions that are specific enough to be useful in practice, we focus on the subset of concerns that are action-oriented. We also conducted a case study that compares concern mappings derived from our role definitions with three developers' mappings across three concerns. The results suggest that our definitions capture the majority of developer-identified elements and that control-flow islands (i.e., groups of elements with little to no control flow connections) can cause developers to omit relevant elements.

[1]  Lori Pollock,et al.  An Empirical Study of the Concept Assignment Problem , 2007 .

[2]  David Coppit,et al.  Understanding concerns in software: insights gained from two case studies , 2005, 13th International Workshop on Program Comprehension (IWPC'05).

[3]  Scott P. Robertson,et al.  Expert problem solving strategies for program comprehension , 1991, CHI.

[4]  Emily Hill,et al.  Using natural language program analysis to locate and understand action-oriented concerns , 2007, AOSD.

[5]  Françoise Détienne,et al.  Object-Oriented Program Comprehension: Effect of Expertise, Task and Phase , 2002, Empirical Software Engineering.

[6]  Norman Wilde,et al.  The role of concepts in program comprehension , 2002, Proceedings 10th International Workshop on Program Comprehension.

[7]  Martin P. Robillard,et al.  Representing concerns in source code , 2007, TSEM.

[8]  William G. Griswold,et al.  Design Recommendations for Concern Elaboration Tools , 2005 .

[9]  Jonathan I. Maletic,et al.  Reverse Engineering Method Stereotypes , 2006, 2006 22nd IEEE International Conference on Software Maintenance.