The reengineering and reverse engineering of software systems is gaining importance in software industry, because the accelerated turnover in software companies creates legacy systems in a shorter period of time. Especially understanding classes is a key activity in object-oriented programming, since classes represent the primary abstractions from which applications are built. The main problem of this task is to quickly grasp the purpose of a class and its inner structure. To help the reverse engineers in their first contact with a foreign system, we propose a categorization of classes based on the visualization of their internal structure. The contributions of this paper are a novel categorization of classes and a visualization of the classes which we call the class blueprint. We have validated the categorization on several case studies, two of which we present here. Keywords Reverse Engineering, Program Understanding, Software Visualization, Visual Patterns, Smalltalk 1.

Merging and splitting source code entities is a common activity during the lifespan of a software system; as developers rethink the essential structure of a system or plan for a new evolutionary direction, so must they be able to reorganize the design artifacts at various abstraction levels as seems appropriate. However, while the raw effects of such changes may be plainly evident in the new artifacts, the original context of the design changes is often lost. That is, it may be obvious which characters of which files have changed, but it may not be obvious where or why moving, renaming, merging, and/or splitting of design elements has occurred. In this paper, we discuss how we have extended origin analysis [1], [2] to aid in the detection of merging and splitting of files and functions in procedural code; in particular, we show how reasoning about how call relationships have changed can aid a developer in locating where merges and splits have occurred, thereby helping to recover some information about the context of the design change. We also describe a case study of these techniques (as implemented in the Beagle tool) using the PostgreSQL database system as the subject.

Many agent-based modeling and simulation researchers and practitioners have called for varying levels of simulation interoperability ranging from shared software architectures to common agent communications languages. These calls have been at least partially answered by several specifications and technologies. In fact, Tanenbaum [1988] has remarked that the “nice thing about standards is that there are so many to choose from. ” Tanenbaum goes on to say that “if you do not like any of them, you can just wait for next year’s model. ” This article does not seek to introduce next year’s model. Rather, the goal is to contribute to the larger simulation community the authors’ accumulated experiences from developing several implementations of an agent-based simulation toolkit. As such, this article focuses on the implementation of simulation architectures rather than agent communications languages. It is hoped that ongoing architecture standards efforts will benefit from this new knowledge and use it to produce architecture standards with increased robustness.

Abstract not found

One of the major problems in software evolution is coping with the complexity which stems from the huge amount of data that must be considered. The current approaches to deal with that problem all aim at a reduction of complexity and a filtering of the relevant information. In this paper we propose an approach based on a combination of software visualization and software metrics which we have already successfully applied in the field of software reverse engineering. Using this approach we discuss a simple and effective way to visualize the evolution of software systems which helps to recover the evolution of object oriented software systems.

Surprising as it may seem, many of the early adopters of the object-oriented paradigm already face a number of problems typically encountered in large-scale legacy systems. The reengineering of those systems often poses problems because of the considerable size and complexity of such systems. In the context of the FAMOOS project we have developed a language independent environment called Moose which can deal with that complexity. This paper describes the architecture of Moose, the tools which have been developed around it and the industrial experiences we have obtained.

Reverse engineering software systems has become a major concern in software industry because of their sheer size and complexity. This problem needs to be tackled, since the systems in question are of considerable worth to their owners and maintainers. In this article we present the concept of a polymetric view, a lightweight software visualization technique enriched with software metrics information. Polymetric views help to understand the structure and detect problems of a software system in the initial phases of a reverse engineering process. We discuss the benefits and limits of several predefined polymetric views we have implemented in our tool CodeCrawler. Moreover, based on clusters of different polymetric views we have developed a methodology which supports and guides a software engineer in the first phases of a reverse engineering of a large software system. We have refined this methodology by repeatedly applying it on industrial systems, and illustrate it by applying a selection of polymetric views to a case study.

CORE ...........................................................................................................................204 Deep Models .......................................................................................................................................205 Refactoring and Distillation ................................................................................................................205 17. Large-Scale Structure.................................................................................................................206 EVOLVING ORDER .........................................................................................................................208 SYSTEM METAPHOR [BECK 2000] .................................................................................................209 PLUGGABLE COMPONENTS.............................................................................................................210 ABSTRACT DOMAIN FRAMEWORK .................................................................................................212 RESPONSIBILITY LAYERS...............................................................................................................212 Large-Scale Structure, Unification Contexts, and Distillation ............................................................223 Refactoring Toward a Fitting Structure...............................................................................................225 Architecture, Architecture Teams, and Large-Scale Structure ............................................................227 18. Game Plans ..................................................................................................................................230 Looking Forward.....

Test factoring creates fast, focused unit tests from slow system-wide tests; each new unit test exercises only a subset of the functionality exercised by the system test. Augmenting a test suite with factored unit tests should catch errors earlier in a test run. One way to factor a test is to introduce mock objects. If a test exercises a component T, which interacts with another component E (the “environment”), the implementation of E can be replaced by a mock. The mock checks that T’s calls to E are as expected, and it simulates E’s behavior in response. We introduce an automatic technique for test factoring. Given a system test for T and E, and a record of T’s and E’s behavior when the system test is run, test factoring generates unit tests for T in which E is mocked. The factored tests can isolate bugs in T from bugs in E and, if E is slow or expensive, improve test performance or cost. We have built an implementation of automatic dynamic test factoring for the Java language. Our experimental data indicates that it can reduce the running time of a system test suite by up to an order of magnitude. 1.

Adequate testing of polymorphism in object-oriented software requires coverage of all possible bindings of receiver classes and target methods at call sites. Tools that measure this coverage need to use class analysis to compute the coverage requirements. However, traditional whole-program class analysis cannot be used when testing partial programs. To solve this problem, we present a general approach for adapting whole-program class analyses to operate on program fragments. Furthermore, since analysis precision is critical for coverage tools, we provide precision measurements for several analyses by determining which of the computed coverage requirements are actually feasible. Our work enables the use of whole-program class analyses for testing of polymorphism in partial programs, and identifies analyses that compute precise coverage requirements and therefore are good candidates for use in coverage tools.