While a number of research systems have demonstrated the potential value of program transformations, very few of these systems have made it into practice. The core technology for such systems is well understood; what remains is integration and more importantly, the problem of handling the scale of the applications to be processed. This paper describes DMS, a practical, commercial program analysis and transformation system, and sketches a variety of tasks to which it has been applied, from redocumenting to large-scale system migration. Its success derives partly from a vision of design maintenance and the construction of infrastructure that appears necessary to support that vision. DMS handles program scale by careful space management, computational scale via parallelism

Software engineering research has focused mainly on software construction and has neglected software maintenance and evolution. Proposed is a shift in research from synthesis to analysis. Reverse engineering is introduced as a possible solution to program understanding and software analysis. Presented is reverse engineering technology developed as part of the Rigi project. The Rigi approach involves the identification of software artifacts in the subject system and the aggregation of these artifacts to form more abstract architectural models. Reported are some analyses on the source code of SQL/DS, performed by the authors while visiting the Program Understanding project at the IBM Centre for Advanced Studies in Toronto.

Lacking support for generic traversal, functional programming languages suffer from a scalability problem when applied to largescale program transformation problems. As a solution, we introduce functional strategies: typeful generic functions that not only can be applied to terms of any type, but which also allow generic traversal into subterms.

Conventional software engineering tends to focus on a small part of the software life cycle: the design and implementation of a product. The bulk of the lifetime cost is in the maintenance phase, where one must live with the product previously developed. Presently, we have little theory and fewer tools to help us manage the maintenance activity. We contend that a fundamental cause of the difficulty is the failure to preserve design information. This results from an over preoccupation with the synthesis and maintenance of code. We offer an alternative paradigm: . make the design the central focus of the construction process---get code as a byproduct; . make the design the central focus of the maintenance process---preserve revised designs and get code as a byproduct. A transformational scheme for accomplishing this is presented. We call it the Design Maintenance System. The programming roles change radically from coding instances for ill-defined specifications to specifiers of func...

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

Building models to understand software systems is an important part of reverse engineering. Formal and explicit model building is important because it focuses attention on modeling as an aid to understanding and results in artifacts that may be useful to others. The representation used to build models has great influence over the success and value of the result. Choosing the proper representation during reverse engineering is the representation problem. This paper examines the representation problem by presenting a taxonomy of solutions. It also illustrates the issues involved in choosing a representation through an example reverse engineering task. 1 Introduction Chikofsky and Cross define reverse engineering to be "the process of analyzing a subject system to identify the system's components and their interrelationships and create representations of the system in another form or at a higher level of abstraction [CC90]." They go on to describe six key objectives of reverse engineer...

In order to design and develop object-oriented programs, one must experience what is known as a "paradigm shift". This shift requires that one do not think in terms of the procedures that a software system must perform, but rather in terms of the entities or objects that participate in the system. As programmers experience a paradigm shift, so must existing software systems somehow be transformed into object-orientation if they are to benefit from object-oriented features.

This report gives an overview of the work performed by the Programming Research Group as part of the European collaborative ESPRIT II "REDO" project (no. 2487). This work covered the areas of reverse-engineering: redocumentation and re-engineering; validation: post-hoc verification and generation of correct code from specifications; maintenance: new languages and methods to support maintenance. Research in areas of concurrent programming and decompilation were also performed.

This paper presents a number of techniques that have been developed as components of the software maintenance process as part of the ESPRIT REDO project. These techniques are all based on formal methods, and the work described has provided the mathematical underpinning to a large collaborative project that has been investigating various aspects of software maintenance. The focus of the project has been on reverse engineering, and methods for this part of the maintenance process are reported on here, along with techniques for subsequent re-engineering. A proposal for specification-oriented software maintenance is presented, in which specifications in an object-oriented extension of the formal notation Z are maintained in step with the

ing Graph-Based Specifications of Object-Oriented Programs Ignacio Silva-Lepe Northeastern University, College of Computer Science Abstract This paper presents two contributions towards the automatic maintenance of object-oriented programs. First, a graph-based notation for specifying object-oriented programs is described, referred to as propagation patterns. Second, an algorithm is informally introduced that abstracts this notation from object-oriented programs expressed as call graphs. Keywords Software maintenance, reverse engineering, object -oriented design and programming, class dictionaries, Law of Demeter. Introduction Maintenance of object-oriented programs can be greatly improved if only their essential elements can be expressed using some formal and programming-language independent notation. Using such notation as a vehicle, existing objectoriented programs can be reverse engineered, raising their upkeep to a level where their behavior is easier to comprehend and the ne...