This paper presents a method to view a system as a hierarchy of modules according to information hiding concepts and to identify architectural component candidates in this hierarchy. The result of the method eases the understanding of a system's underlying software architecture. A prototype tool implementing this method was applied to three systems written in C (each over 30 Kloc). For one of these systems, an author of the system created an architectural description. The components generated by our method correspond to those of this architectural description in almost all cases. For the other two systems, most of the components resulting from the method correspond to meaningful system abstractions. 1. Introduction It is well known that programmer efforts are mostly devoted to maintaining systems [Corb89, Somm92]. A large portion of that maintenance effort is spent in understanding the program and data [Yau80]. Within this context, helping maintainers to understand the legacy systems...

To facilitate software maintenance and evolution, a helpful step is to locate features concerned in a particular maintenance task. In the literature, both dynamic and interactive approaches have been proposed for feature location. In this paper, we present a static and non-interactive method for achieving this objective. The main idea of our approach is to use the information retrieval (IR) technology to reveal the basic connections between features and computational units in source code. Due to the characteristics of the retrieved connections, we use a static representation of the source code named BRCG to further recover both the relevant and the specific computational units for each feature. Furthermore, we recover the relationships among the relevant units for each feature. A premise of our approach is that programmers should use meaningful names as identifiers. We perform an experimental study based on a GNU system to evaluate our approach. In the experimental study, we present the detailed quantitative experimental data and give the qualitative analytical results. 1.

Approximately 70 % of the source code of a software system consists of identifiers. Hence, the names chosen as identifiers are of paramount importance for the readability of computer programs and therewith their comprehensibility. However, virtually every programming language allows programmers to use almost arbitrary sequences of characters as identifiers which far too often results in more or less meaningless or even misleading naming. Coding style guides address this problem but are usually limited to general and hard to enforce rules like “identifiers should be self-describing”. This paper renders adequate identifier naming far more precisely. A formal model, based on bijective mappings between concepts and names, provides a solid foundation for the definition of precise rules for concise and consistent naming. The enforcement of these rules is supported by a tool that incrementally builds and maintains a complete identifier dictionary while the system is being developed. The identifier dictionary explains the language used in the software system, aids in consistent naming, and improves productivity of programmers by proposing suitable names depending on the current context.

Corporations face mounting maintenance and re-engineering costs for large legacy systems. Evolving over several years, these systems embody substantial corporate knowledge, including requirements, design decisions, and business rules. Such knowledge is difficult to recover after many years of operation, evolution, and personnel change. To address this problem, software engineers are spending an ever-growing amount of effort on program understanding and reverse engineering technologies. This article describes the scope and results of an on-going research project on program understanding undertaken by the IBM Software Solutions Toronto Laboratory Centre for Advanced Studies (CAS). The project involves, in addition to a team from CAS, five research groups working cooperatively on complementary reverse engineering approaches. All groups are using the source code of SQL/DS (a multi-million line relational database system) as the reference legacy system. The article also discusses the approa...

Program comprehension is an important activity in software maintenance, as software must be sufficiently understood before it can be properly modified. The study of a program’s execution, known as dynamic analysis, has become a common technique in this respect and has received substantial attention from the research community, particularly over the last decade. These efforts have resulted in

Despite significant existing empirical work, little is known about the specific kinds of questions programmers ask when evolving a code base. Understanding precisely what information a programmer needs about the code base as they work is key to determining how to better support the activity of programming. The goal of this research is to provide an empirical foundation for tool design based on an exploration of what programmers need to understand about a code base and of how they use tools to discover that information. To this end, we undertook two qualitative studies of programmers performing change tasks to medium to large sized programs. One study involved newcomers working on assigned change tasks to a mediumsized code base. The other study involved industrial programmers working on their own change tasks to code with which they had experience. The focus of our analysis has been on what information a programmer needs to know about a code base while performing a change task and also on how they go about discovering that information. Based on a systematic analysis of the data from these user studies as well as an analysis of the support that current programming tools provide for these activities, this research makes four key contributions: (1) a catalog of 44 types of questions programmers ask, (2) a categorization of those questions into four categories based on the kind and scope of information needed to answer a question, (3) a description of important context for the process of answering questions, and (4) a description of support that is missing from current programming tools.

Concept location in source code is the process that identifies where a software system implements a specific concept. While it is well accepted that concept location is essential for the maintenance of complex procedural code like code written in C, it is much less obvious whether it is also needed for the maintenance of the Object-Oriented code. After all, the Object-Oriented code is structured into classes and well-designed classes already implement concepts, so the issue seems to be reduced to the selection of the appropriate class. The objective of our work is to see if the techniques for concept location are still needed (they are) and whether Object-Oriented structuring facilitates concept location (it does not). This paper focuses on static concept location techniques that share common prerequisites and are search the source code using regular expression matching, or static program dependencies, or information retrieval. The paper analyses these techniques to see how they compare to each other in terms of their respective strengths and weaknesses. 1.

Software system documentation is almost always expressed informally, in natural language and free text. Examples include requirement specifications, design documents, manual pages, system development journals, error logs and related maintenance reports. We propose an approach to establish and maintain traceability links between the source code and free text documents. A premise of our work is that programmers use meaningful names for program's items, such as functions, variables, types, classes, and methods. We believe that the application-domain knowledge that programmers process when writing the code is often captured by the mnemonics for identifiers; therefore, the analysis of these mnemonics can help to associate high level concepts with program concepts, and vice-versa. In this paper, the approach is applied to software written in an object-oriented language, namely C++, to trace classes to manual sections. Keywords: traceability, versions compliance check, object orientation 1.

Program comprehension research can be characterized by both the theories that provide rich explanations about how programmers comprehend software, as well as the tools that are used to assist in comprehension tasks. During this talk I will review some of the key cognitive theories of program comprehension that have emerged over the past thirty years. Using these theories as a canvas, I will then explore how tools that are popular today have evolved to support program comprehension. Specifically, I will discuss how the theories and tools are related and reflect on the research methods that were used to construct the theories and evaluate the tools. The reviewed theories and tools will be further differentiated according to human characteristics, program characteristics, and the context for the various comprehension tasks. Finally, I will predict how these characteristics will change in the future and speculate on how a number of important research directions could lead to improvements in program comprehension tools and methods. 1.

. Many organizations face the problem of improving the value of their legacy systems. Modernizing the architecture of old software helps to gain control over maintenance cost, to improve system performance, and it supports moving to a distributed or more efficient environment. We propose a re-architecturing of old procedural software to an object-oriented architecture. To overcome limits of classical reverse engineering approaches building exclusively on information extractable from source code we integrate domain knowledge in the process. The resulting object-oriented software helps reduce future maintenance cost, since modern (and more calculable) maintenance technology can then be applied. In this paper, we point out the basic concepts of the re-architecturing process, the generation of design documents at different levels of abstraction, and the necessary syntactic adaptations of the source code. 1 Introduction Legacy systems are an increasing problem for IT groups in large organi...