Understanding program understanding

Abstract

It is well known that many software activities involve Program Understanding tasks. In fact, anyone working in Software Engineering is confronted with the task of understanding programs, at one level or another, in one form or another, and normally s/he succeeds rather well. However, we don't have any clear understanding of what ?to understand programs? means: is it to extract the program's structure or control/data flows? Is it to understand the relations between data and its transformations with respect to meanings in the application domain? Etc. We do neither have explicit guidelines to help us to perform a given program understanding task, nor do we have good criteria to decide how to represent knowledge derived by and used for program understanding. We conclude from the latter a strong need for further (fundamental) research in the Program Understanding area itself.Below is a provisional list of questions about program understanding: How could we define ?Program Understanding?? When do we decide we understand (enough) a program? What kind of program understanding do we achieve depending on the task at hand? How do we represent, in our minds, on paper or in files, our understanding of a program? What kind of help can we get from existing Program Understanding tools? What would we like to get actually (be it feasible or not)? What can we expect to have, as automatic help to understand programs, in the near future, in the long term? How could we describe our experiments, our own knowledge, so that they can be shared, re-used? What about Program Understanding Patterns?The goal of this Working Session is to exchange views on the former questions and others, to discuss possible research strategies, and to create an international interest group on Program Understanding, enhancing the sharing of tools, ideas and repositories.