Existing empirical results from program comprehension research show that programmers use various stratergies to construct mental (cognitive) models of the program. Early research tended to focus on single strategies such as top-down (moving from concepts and expectations to code) and bottom-up (the opposite). However, subsequent studies indicated that programmers use a combination of strategies such as systematic, as-needed, and just-in-time. As they worked with the code, programmers built mental models, that is, representations in their minds of how the program worked. These models could also represent different levels of abstraction. For example, the situation model would describe the code on a small scale, such as a loop or data structure. The program model would describe the file or module. Finally, the domain model would represent the problem that the code is intended to solve. Von Mayrhauser and Vans found that programmers jumped between the models depending on what information was available in front of them and in their personal knowledge base. Wiedenbeck, Fix, and Scholtz found that in order to successfully make a modification to a program, a developer had to have accurate models at all three levels of abstraction and reliable mappings between them. In our recent work on software engineering expertise, we obtained results that were consistent with Wiedenbeck et al.'s findings, that experts who were able to successfully modify a web application had correct mental models at the situation, program, and domain levels, as well as mappings between them.

While previous work in program comprehension tools has focused on extracting and analyzing information from source code, we propose to recruit additional artifacts and resources to support this activity. A major consequence of this approach is the idea that program comprehension can involve more than just source code. While source code may have been the only information source in the past, there are many more artifacts involved in the implementation of a modern software application. For an example, in a typical web application, multiple frameworks are used for user interfaces, web services, and data persistence, and multiple source languages for presentation, client-side scripting, server-side processing, and application logic. Consequently, source code is only part of the picture. In addition, previous studies showed that fellow team members can provide valuable assistance in comprehension. Due to this need to bring in additional resources, it is necessary to consider program comprehension more broadly. Once additional artifacts are incorporated, the next step is to view comprehension as an activity that occurs not only while writing source code and involving more than one person.