This thesis defines a set of program restructuring operations (refactorings) that support the design, evolution and reuse of object-oriented application frameworks. The focus of the thesis is on automating the refactorings in a way that preserves the behavior of a program. The refactorings are defined to be behavior preserving, provided that their preconditions are met. Most of the refactorings are simple to implement and it is almost trivial to show that they are behavior preserving. However, for a few refactorings, one or more of their preconditions are in general undecidable. Fortunately, for some cases it can be determined whether these refactorings can be applied safely. Three of the most complex refactorings are defined in detail: generalizing the inheritance hierarchy, specializing the inheritance hierarchy and using aggregations to model the relationships among classes. These operations are decomposed into more primitive parts, and the power of these operations is discussed from the perspectives of automatability and usefulness in supporting design. Two design constraints needed in refactoring are class invariants and exclusive components. These constraints are needed to ensure that behavior is preserved across some refactorings. This thesis gives some conservative algorithms for determining whether a program satisfies these constraints, and describes how to use this design information to refactor a program.

©2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Programmers frequently have to retrieve and link information from various software documents to accomplish a maintenance task. Ciao is a graph-based navigator that helps programmers query and browse structural connections embedded in different software and document repositories. A repository consists of a collection of source documents with an associated database that describes their structure. Ciao supports repositories organized in an architecture style called Aero, which exploits the duality between a class of entity-relationship (ER) databases and directed attributed graphs (DAG). Database queries and graph analysis operators in Aero are plug-compatible because they all take an ER database and produce yet another ER database by default. Various presentation filters generate graph views, source views, and relational views from any compatible ER database. The architecture promotes the construction of successively more complex operators using a notion of virtual database pipelines. Ci...

Abstract | A software repository provides a central information source for understanding and reengineering code in a software project. Complex reverse engineering tools can be built by analyzing information stored in the repository without reparsing the original source code. The most critical design aspect of a repository is its data model, which directly a ects how e ectively the repository supports various analysis tasks. This paper focuses on the design rationales behind a data model for a C++ software repository that supports reachability analysis and dead code detection at the declaration level. These two tasks are frequently needed in large software projects to help remove excess software baggage, select regression tests, and support software reuse studies. The language complexity introduced by class inheritance, friendship, and template instantiation in C++ requires a carefully designed model to catch all necessary dependencies for correct reachability analysis. We examine the major design decisions and their consequences in our model and illustrate how future software repositories can be evaluated for completeness at a selected abstraction level. Examples are given to illustrate how our model also supports variants of reachability analysis: impact analysis, class visibility analysis, and dead code detection. Finally, wediscuss the implementation and experience of our analysis tools on a few C++ software projects.

Types of code changes in an object oriented library are described. A formal model for capturing and inferencing on the changes to identify affected classes is described. The model consists of three types of diagrams: the object relation diagram (ORD), the block branch diagram (BBD), and the object state diagram (OSD). An ORD describes the inheritance, aggregation, and association relationships between the classes of a C++ library. A BBD describes the control structure and interfaces of a member function. And an OSD describes the state behavior of a class. Unlike in modeling, these diagrams are automatically generated from code and facilitate understanding and changing a C++ library. An OO software maintenance environment that implements the research result is described. Our experience with the environment prototype shows promising results.

C++ is an expressive language, but it does not allow software developers to say all the things about their systems that they need to be able to say. In particular, C++ offers no way to express many important constraints on a system's design, implementation, and presentation. In this paper, we describe CCEL, a metalanguage for C++ that allows software developers to express constraints on C++ designs and implementations, and we describe Clean++, a system that checks C++ code for violations of CCEL constraints. CCEL is designed for practical, real-world use, and the examples in this paper demonstrate its power and flexibility.

Many program evolution tasks involve source code that is not modularized as a single unit. Furthermore, the source code relevant to a change task often implements different concerns, or high-level concepts that a developer must consider. Finding and understanding concerns scattered in source code is a difficult task that accounts for a large proportion of the effort of performing program evolution. One possibility to mitigate this problem is to produce textual documentation that describes scattered concerns. However, this approach is impractical because it is costly, and because, as a program evolves, the documentation becomes inconsistent with the source code. The thesis of this dissertation is that a description of concerns, representing program structures and linked to source code, that can be produced cost-effectively during program investigation activities, can help developers perform software evolution tasks more systematically, and on different versions of a system. To validate the claims of this thesis, we have developed a model for a structure, called concern graph, that describes concerns in source code in terms of relations between program elements. The model also defines precisely the notion of inconsistency between a concern graph and the

Software development and maintenance tasks rely on and can benefit from an increased level of program understanding. Object-oriented programming languages provide features which facilitate software maintenance, yet the same features often make object-oriented programs more difficult to understand. We support the use of program visualization techniques to foster object-oriented program comprehension. This paper identifies ways that visualization can increase program understanding, and presents a means for characterizing both static and dynamic aspects of an object-oriented program. We then describe the implementation of a prototypical tool for visualizing the execution of C++ programs. Based on this work, we define a framework for the visualization of object-oriented software which requires little or no programmer intervention and provides a mechanism which allows users to focus quickly on particular aspects of the program. Keywords: program visualization, program comprehension. 1 In...

Object-oriented languages fail to provide software developers with a way to say many of the things about their systems that they need to be able to say. To address this need, we have designed and implemented a language for use with C++ that allows software developers to express a wide variety of constraints on the designs and implementations of the systems they build. Our language is specifically designed for use with C++, but the issues it addresses are applicable to other object-oriented languages, and the fundamental software architecture used to implement our system could be applied without modification to similar constraint languages for other object-oriented programming languages.

This paper describes the design and motivations behind the Desert environment. The Desert environment has been created to demonstrate that the facilities typically associated with expensive data integration can be provided inexpensively in an open framework. It uses three integration mechanisms: control integration, simple data integration based on fragments, and a common editor. It offers a variety of capabilities including hyperlinks and the ability to create virtual files containing only the portions of the software that are relevant to the task on hand. It does this in an open environment that is compatible with existing tools and programs. The environment currently consists of a set of support facilities including a context database, a fragment database, scanners, and a ToolTalk interface, as well as a preliminary set of programming tools including a context manager and extensions to FrameMaker to support program editing and insets for non-textual software artifacts. 1.0 Motivati...