MACS '05 Proceedings of the 2005 workshop on Modeling and analysis of concerns in software
JASPER: an Eclipse plug-in to facilitate software maintenance tasks
eclipse '06 Proceedings of the 2006 OOPSLA workshop on eclipse technology eXchange
Representing concerns in source code
ACM Transactions on Software Engineering and Methodology (TOSEM)
IEEE Transactions on Software Engineering
Mismar: A New Approach to Developer Documentation
ICSE COMPANION '07 Companion to the proceedings of the 29th International Conference on Software Engineering
Aiding evolution with concern-oriented guides
Proceedings of the 3rd workshop on Linking aspect technology and evolution
The emergent structure of development tasks
ECOOP'05 Proceedings of the 19th European conference on Object-Oriented Programming
Hi-index | 0.00 |
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.