Recovering architectural documentation from code is crucial to maintaining and reengineering software systems. Reverse engineering and program understanding approaches are often limited by the fact that (1) they propose a fixed set of predefined views and (2) they consider either purely static or purely dynamic views of the application. In this paper we present an environment supporting the generation of tailorable views of object-oriented systems from both static and dynamic information. Our approach is based on the combination of user-defined queries which allow an engineer to create high-level abstractions and to produce views using these abstractions.

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...

The increased popularity of the object-oriented paradigm has also increased the interest in object-oriented reengineering. First of all, object-oriented software systems suffer from similar maintainability problems as traditional procedural systems, displaying the need for reengineering techniques tailored to deal with ob- ject-oriented code. Secondly, the increased importance of iterative development processes make reengi- neering techniques valuable in forward engineering, and thus for all paradigms that software is developed in. Reengineering requires tool support to deal with the large amounts of information and the wide variety of tasks to be performed. An important consideration in building tool environments for reengineering is what information must be provided and how this information is modelled. Design choices have a consider- able impact not only on the ability to support reengineering tasks, but also on issues such as scalability and tool interoperability. Several metamodels exist that model software for the purposes of reengineering. How- ever, they generally lack a discussion of the relevance of information for reengineering and the trade-offs of modeling alternatives. This thesis presents FAMIX, a language-independent metamodel for modelling object-oriented soft- ware for reengineering purposes. We discuss the exact contents of the metamodel, including its relevance for reengineering and how the metamodel supports the different object-oriented languages through its lan- guage-independent core. We also discuss the infrastructural design decisions of FAMIX by placing it into a design space for infrastructural aspects of reengineering repositories and metamodels. The design space presents multiple interdependent aspects, their design alternatives and how these impact issues such as scal- ability, extensibility and information exchange. We validate the ability of FAMIX to support reengineering on a language-independent level in two ways. First, we present Moose, a reengineering tool environment with a repository based on FAMIX. Moose serves as a foundation for multiple reengineering tools and has been applied to reverse engineer several large industrial case studies. Secondly, we define a set of fifteen low-level refactorings in terms of the infor- mation available in FAMIX. Refactoring requires sufficient, complete and 100% correct information as well as a clear interpretation of the supported languages in the language-independent core of the metamod- el, in order to correctly perform transformations on the language-specific code level. As such the refactor- ings provide an in-depth validation of the language independence of FAMIX.

Legacy software systems present a high level of entropy combined with imprecise documentation. This makes their maintenance more difficult, more time consuming, and costlier. In order to address these issues, many organizations have been migrating their legacy systems to new technologies. In this paper, we describe a computer-supported approach aimed at supporting the migration of procedural software systems to the objectoriented (OO) technology, which supposedly, fosters reusability, expandability, flexibility, encapsulation, information hiding, modularity, and maintainability. Our approach relies heavily on the automatic formation of concepts based on information extracted directly from code to identify objects. The approach tends, thus, to minimize the need for domain application experts. We also propose rules for the identification of OO methods from routines. A well-known and self-contained example is used to illustrate the approach. We have applied the approach on medium/large procedural software systems, and the results show that the approach is able to find objects and to identify their methods from procedures and functions.

When programmers perform maintenance tasks, program understanding is required. One of the first activities in understanding a software system is identifying its subsystems and their relations, i.e. its software architecture. Since a large part of the effort is spent in creating a mental model of the system under study, tools can help maintainers in managing the evolution of legacy systems, by showing them architectural information. In this paper, an environment for the architectural analysis of software systems is described. The environment is based on a hierarchical architectural model that drives the application of a set of recognizers, each producing a different architectural view of the system or of some of its parts. Recognizers embody knowledge about architectural clich'es and use flow analysis techniques to make their output more accurate. 1

This paper presents a technique for recovering the high level design of legacy software systems according to user defined architectural plans. Architectural plans are represented using a description language and specify system components and their interfaces. Such descriptions are viewed as queries that are applied on a large data base which stores information extracted from the source code of the subject legacy system. Data mining techniques and a modified branch and bound search algorithm are used to control the matching process, by which the query is satisfied and query variables are instantiated. The matching process allows the alternative results to be ranked according to data mining associations and clustering techniques and, finally, be presented to the user. 1 Introduction Software maintenance constitutes a major part of the software life-cycle. Most maintenance tasks require a decomposition of the legacy system into modules and functional units. One approach to architectura...

Program understanding is an essential part of all software maintenance and enhancement activities. As currently practiced, program understanding consists mainly of code reading. The few automated understanding tools that are actually used in industry provide helpful but relatively shallow information, such as the line numbers on which variable names occur or the calling structure possible among system components. These tools rely on analyses driven by the nature of the programming language used. As such, they are adequate to answer questions concerning implementation details, so called what questions. They are severely limited, however, when trying to relate a system to its purpose or requirements, the why questions. Application programs solve real-world problems. The part of the world with which a particular application is concerned is that application's domain. A model of an application's domain can serve as a supplement to programming-language-based analysis methods and tools....

Ideally, a software project commences with requirements gathering and specification, reaches its major milestone with system implementation and delivery, and then continues, possibly indefinitely, into an operation and maintenance phase. The software system’s architecture is in many ways the linchpin of this process: it is supposed to be an effective reification of the system’s technical requirements and to be faithfully reflected in the system’s implementation. Furthermore, the architecture is meant to guide system evolution, while also being updated in the process. However, in reality developers frequently deviate from the architecture, causing architectural erosion, a phenomenon in which the initial, “as documented ” architecture of an application is (arbitrarily) modified to the point where its key properties no longer hold. Architectural recovery is a process frequently used to cope with architectural erosion whereby the current, “as implemented ” architecture of a software system is extracted from the system’s implementation. In this paper we propose a light-weight approach to architectural recovery, called Focus, which has three unique facets. First, Focus uses a system’s evolution requirements to isolate and incrementally recover only the fragment of the system’s architecture affected by the evolution. In this manner, Focus allows engineers to direct their primary attention to the part of the system that is immediately impacted by the desired change; subsequent

The first activity performed by maintenance programmers when approaching the task of understanding a system is often trying to discover its high level structure, that is identifying its subsystems and their relations: in few words, the software architecture of the system. In this paper, an approach for the architectural analysis of software systems, together with an environment implementing the approach, are described. The approach is based on a hierarchical architectural model that drives the application of a set of architectural recognizers. Each recognizer builds an abstract view describing some architectural aspects of the system, or of some of its parts. The implementation of the environment supporting the architectural analysis process described is currently in progress.

Program understanding relates a computer program to the goals and requirements it is designed to accomplish. Application-domain analysis is a source of information that can aid program understanding by guiding the source-code analysis and providing structure to its results. We use the term "dowsing" to describe the process of exploring software and the related documentation from an application-domain point of view. We have designed a tool framework to support dowsing and have populated it with a variety of commercial and research tools. Keywords: reverse engineering, domain analysis, program understanding, software tools 1. Introduction: Dowsing Software maintenance and enhancement activities are the largest part of total lifecycle costs. Moreover, understanding source code and change requirements dominate maintenance and enhancement effort. Consequently, methods and techniques for creating and browsing software artifacts that improve their understandability can significantly aid t...