Abstract-Prior to performing a software change task, developers must discover and understand the subset of the system relevant to the task. Since the behavior exhibited by individual developers when investigating a software system is influenced by intuition, experience, and skill, there is often significant variability in developer effectiveness. To understand the factors that contribute to effective program investigation behavior, we conducted a study of five developers performing a change task on a medium-size open source system. We isolated the factors related to effective program investigation behavior by performing a detailed qualitative analysis of the program investigation behavior of successful and unsuccessful developers. We report on these factors as a set of detailed observations, such as evidence of the phenomenon of inattention blindness by developers skimming source code. In general, our results support the intuitive notion that a methodical and structured approach to program investigation is the most effective.

Without rigorous software development and maintenance, software tends to lose its original architectural structure and become difficult to understand and modify. ArchJava, a recently proposed programming language which embeds a componentand-connector architectural specification within Java implementation code, offers the promise of preventing the loss of architectural structure. AliasJava, which can be used in conjunction with ArchJava, is an annotation system that extends Java to express how data is confined within, passed among, or shared between components and objects in a software system.We describe a case study in which we incrementally re-engineer an existing Java implementation to obtain an implementation which enforces the architectural control flow and data sharing. Building on results from similar case studies, we chose an application consisting of over 16,000 source lines of Java code and over 90 classes. We describe our process, the detailed steps involved (some of which can be automated), as well as some lessons learned and perceived limitations with the languages, techniques and tools we used.

When modifying or debugging a software system, among other tasks, developers must often understand and manipulate source code that crosscuts the system's structure. These tasks are made more difficult by limitations of the two approaches currently used to present details of crosscutting structure: tree views and structural diagrams. Tree views force the developer to manually synthesize information from multiple views; structure diagrams quickly suffer from graphical complexity. We introduce an active model as a means of presenting the right information about crosscutting structure to a developer at the right time. An active model is produced as a result of three automated operations-projection, expansion, and abstraction. Combined with particular user interaction features during display, these operations enable a view of the model to be presented to the developer without suffering from the complexity of existing approaches. We have implemented an active model tool, called ActiveAspect, for presenting crosscutting structure described by AspectJ aspects. We report on the results of a case study in which the tool was used effectively by two subjects to implement a modification task to a non-trivial AspectJ system.

Abstract

Developers must often deal with concerns that crosscut a program's structure. Understanding the crosscutting structure may help a developer understand and work with the concern. Current tools for presenting crosscutting structure suffer either from graphical complexity or a mismatch between the presentation and the underlying program structure. We introduce a concern presentation approach that overcomes these problems through a combination of automatic abstraction and interactive features that enable a developer to investigate relevant details. We sketch how the ActiveAspect tool we are developing implements this approach for presenting the crosscutting structure described by aspects in AspectJ.