Software engineers often use high-level models (for instance, box and arrow sketches) to reason and communicate about an existing software system. One problem with high-level models is that they are almost always inaccurate with respect to the system's source code. We have developed an approach that helps an engineer use a high-level model of the structure of an existing software system as a lens through which to see a model of that system's source code. In particular, an engineer defines a high-level model and specifies how the model maps to the source. A tool then computes a software reflexion model that shows where the engineer's high-level model agrees with and where it differs from a model of the source. The paper provides a formal characterization of reflexion models, discusses practical aspects of the approach, and relates experiences of applying the approach and tools to a number of different systems. The illustrative example used in the paper describes the application of refle...

Maintenance tends to degrade the structure of software, ultimately making maintenance more costly. At times, then, it is worthwhile to manipulate the structure of a system to make changes easier. However, it is shown that manual restructuring is an error-prone and expensive activity. By separating structural manipulations from other maintenance activities, the semantics of a system can be held constant by a tool, assuring that no errors are introduced by restructuring. To allow the maintenance team to focus on the aspects of restructuring and maintenance requiring human judgment, a transformation-based tool can be provided---based on a model that exploits preserving data flow-dependence and control flow-dependence---to automate the repetitive, errorprone, and computationally demanding aspects of re...

Documentation has traditionally played a key role as an aid in program understanding. However, most documentation is "in-the-small," describing the program at the algorithm and data structure level. For large, legacy software systems, one needs "in-the-large" documentation describing the high-level structural aspects of the software system's architecture from multiple perspectives. One way of producing such structural documentation for existing software systems is to use reverse engineering technologies. This paper describes a case study in structural redocumentation: an analysis of SQL/DS (a multi-million line relational database system) using a flexible reverse engineering approach developed as part of the Rigi project.

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.

To effectively perform a change to an existing software system, a software engineer needs to have some understanding of the structure of the system. All too often, though, an engineer must proceed to change a system without sufficient structural information because existing software understanding techniques are unable to help the engineer acquire the desired knowledge within the time and cost constraints specified for the task. The thesis of this research is that an approach based on summarization can overcome the limitations associated with existing approaches, enabling an engineer to assess, plan, and execute changes to a software system more effectively. Summarization involves the production of overviews of vast amounts of user-selected information in a timely manner. I describe two tech...

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

Software engineers often use high-level models (for instance, box and arrow sketches) to reason and communicate about an existing software system. One problem with high-level models is that they are almost always inaccurate with respect to the system's source code. We have developed an approach that helps an engineer use a high-level model of the structure of an existing software system as a lens through which to see a model of that system's source code. In particular, an engineer de nes a high-level model and speci es how the model maps to the source. A tool then computes a software re exion model that shows where the engineer's high-level model agrees with and where it di ers from a model of the source. The paper provides a formal characterization of reexion models, discusses practical aspects of the approach, and relates experiences of applying the approach and tools to a number of di erent systems. The illustrative example used in the paper describes the application of re exion models to NetBSD, an implementation of Unix comprised of 250,000 lines of C code. In only a few hours, an engineer computed several re exion models that provided him with a useful, global overview of the structure of the NetBSD virtual memory subsystem. The approach has also been applied to aid in the understanding and experimental reengineering of the Microsoft Excel spreadsheet product.

There is a significant difference between documenting large programs and documenting small ones. By large programs we mean on the order of 1,000,000 lines, usually written by many different people over a long period of time. Most software documentation may be termed documenting-in-the-small, since it typically describes the program at the algorithm and data structure level. To understand large legacy systems, one needs documenting-in-the-large: documentation describing the high-level structural aspects of the software system's architecture from multiple perspectives. This paper outlines an approach to supporting software evolution through documenting-in-the-large. The approach is based on a flexible reverse engineering process which uses virtual subsystem stratifications to represent multiple abstract views of a software system. Keywords: documenting-in-the-large, reverse engineering, software evolution y This work was supported in part by the British Columbia Advanced Systems Inst...

In today's rapidly changing world, software systems will inevitably evolve in response to evolving requirements, but software maintenance activities-such as enhancing function, repairing defects, and retargeting to other platforms-are very expensive, often consuming over 70% of project resources. Exacerbating this situation is the fact that most software programs will ultimately exist in multiple similar-but different-versions to accommodate varying requirements. To address these issues, Parnas proposed a method for developing and maintaining families of related programs. However, Parnas' method presumes that the software is planned to anticipate the design decisions that differentiate the variants and that the family members are developed incrementally rather than sequentially. Motivated by the need to make unanticipated modifications to a software tool, we used Griswold's "just-in-time architecture" concept and retroactively applied Parnas' program family principles to an existing system in order to create an unanticipated member of a program family.

Regularities, or the conformity to unifying principles, are essential to the comprehensibility, manageability and reliability of large software systems, and should, therefore, be considered an important element of their architecture. But, as is argued in this paper, the inherent globality of regularities makes them very hard to implement in traditional methods. This paper explores an approach to regularities which greatly simplifies their implementation, making them more easily employable for taming of the complexities of large systems. This approach, which is based on the concept of law-governed architecture (LGA), provides system designers and builders with the means for establishing regularities simply by declaring them formally and explicitly as the law of the system. Once such a law-governed regularity is declared, it is enforced by the environment in which the system is developed. We introduce here the formalism for specifying laws under the Darwin/2 environment, and give a sampl...