Understanding the implementation of a certain feature of a system requires to identify the computational units of the system that contribute to this feature. In many cases, the mapping of features to the source code is poorly documented. In this paper, we present a semi-automatic technique that reconstructs the mapping for features that are triggered by the user and exhibit an observable behavior. The mapping is in general not injective; that is, a computational unit may contribute to several features. Our technique allows to distinguish between general and specific computational units with respect to a given set of features. For a set of features, it also identifies jointly and distinctly required computational units.

Understanding a system’s implementation without prior knowledge is a hard task for reengineers in general. However, some degree of automatic aid is possible. In this paper, we present a technique building a mapping between the system’s externally visible behavior and the relevant parts of the source code. Our technique combines dynamic and static analyses to rapidly focus on the system’s parts urgently required for a goal-directed process of program understanding. 1.

The reflexion model originally proposed by Murphy and Notkin allows one to structurally validate a descriptive or prescriptive architecture model against a source model. First, the entities in the source model are mapped onto the architectural model, then discrepancies between the architecture model and source model are computed automatically. The original

The first task of a programmer who wants to understand how a certain feature is implemented is to localize the implementation of the feature in the code. If the implementations of a set of related features are to be understood, a programmer is interested in their commonalities and variabilities. For large and badly documented programs, localizing features in code and identifying commonalities and variabilities of components and features can be difficult and time-consuming. It is useful to derive this information automatically. The feature-

The majority of the algorithms in the software clustering literature utilize structural information in order to decompose large software systems. Other approaches, such as using £le names or ownership information, have also demonstrated merit. However, there is no intuitive way to combine information obtained from these two different types of techniques. In this paper, we present an approach that combines structural and non-structural information in an integrated fashion. LIMBO is a scalable hierarchical clustering algorithm based on the minimization of information loss when clustering a software system. We apply LIMBO to two large software systems in a number of experiments. The results indicate that this approach produces valid and useful clusterings of large software systems. LIMBO can also be used to evaluate the usefulness of various types of non-structural information to the software clustering process. 1

A significant aspect in applying the Reflexion Method is the mapping of components found in the source code onto the conceptual components defined in the hypothesized architecture. To date, this mapping is established manually, which requires a lot of work for large software systems. In this paper, we present a new approach, in which clustering techniques are applied to support the user in the mapping activity. The result is a semi-automated mapping technique that accommodates the automatic clustering of the source model with the user’s hypothesized knowledge about the system’s architecture. This paper describes also a case study in which our semi-automated mapping technique has been applied successfully to extend a partial map of a real-world software application. 1

In this paper we present a new instrumentation approach to reverse engineer a given software application. Our approach is based on aspect-oriented programming and provides support for dynamic feature analysis. The advantage of our approach compared to other existing approaches is that we allow the engineer to obtain deeper insights into the program executions and to combine these insights with existing analysis techniques. As we show in this paper, this significantly reduces the time necessary to obtain viable traces of a program's execution.

UML diagrams are widely employed for modeling of object-oriented software systems. In addition to their application in forward engineering, it is also possible to use them for the redocumentation of existing programs. However, the inherent structure of UML diagrams, which consists of graphical as well as textual information, makes it difficult to read and oversee large diagrams generated from complex systems. The view on such diagrams can be compared with taking a look at a detailed map: the reader has to decide whether to read the fine details or to view the whole structure.

Abstract not found

To maintain and understand large applications, it is important to know their architecture. The first problem is that unlike classes and packages, architecture is not explicitly represented in the code. The second problem is that successful applications evolve over time, so their architecture inevitably drifts. Reconstructing the architecture and checking whether it is still valid is therefore an important aid. While there is a plethora of approaches and techniques supporting architecture reconstruction, there is no comprehensive software architecture reconstruction state of the art and it is often difficult to compare the approaches. This article presents a state of the art in software architecture reconstruction approaches.