Many maintenance tasks address concerns, or features, that are not well modularized in the source code comprising a system. Existing approaches available to help software developers locate and manage scattered concerns use a representation based on lines of source code, complicating the analysis of the concerns. In this paper, we introduce the Concern Graph representation that abstracts the implementation details of a concern and makes explicit the relationships between different parts of the concern. The abstraction used in a Concern Graph has been designed to allow an obvious and inexpensive mapping back to the corresponding source code. To investigate the practical tradeoffs related to this approach, we have built the Feature Exploration and Analysis tool (FEAT) that allows a developer to manipulate a concern representation extracted from a Java system, and to analyze the relationships of that concern to the code base. We have used this tool to find and describe concerns related to software change tasks. We have performed case studies to evaluate the feasibility, usability, and scalability of the approach. Our results indicate that Concern Graphs can be used to document a concern for change, that developers unfamiliar with Concern Graphs can use them effectively, and that the underlying technology scales to industrial-sized programs.

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

The object-oriented paradigm has gained popularity in various guises not only in programming languages, but in user interfaces, operating systems, databases, and other areas. We argue that the fundamental object-oriented concept is encapsulation, and that all object-oriented mechanisms and approaches exploit this idea to various ends. We introduce the most important of these mechanisms as they are manifested in existing object-oriented systems, and we discuss their relevance in the context of modern application development.

In this paper, we explain how inheritance and dynamic binding make object-oriented programs difficult to maintain, and we give a concrete example of the problems that arise. We show that the difficulty lies in the fact that conventional tools are poorly suited for work with object-oriented languages, and we argue that semantics-based tools are essential for effective maintenance of object-oriented programs. We then describe a system we have developed for working with C++ programs. This system comprises a relational database system for information about programs, and an interactive database interface integrated with a text editor. We describe our system architecture, detail the database relations, provide informal evidence on the system's effectiveness, and compare it to other research with similar goals. Keywords: software maintenance, object-oriented languages and environments, programming environments, semantic analysis of code, software representation in relational databases, C++. ...

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.

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

Object-oriented programming is considered in the context of software communities -- groups of designers and developers sharing knowledge and experience. One way of fostering reuse of this experience is by establishing large collections of reusable object classes. Resulting problems include: ClasspacsOX6/ andcAO7 organization -- how can classes and their methods be represented to simplify reuse. Classselec7X' and exploration -- what query and browsing facilities are needed by developers in order to facilitate software reuse. Class evolution -- how may the class hierarchy be reorganized as a result of changes introduced by developers. These issues are illustrated by examining prototype tools and systems intended to aid object-oriented programming.

Despite significant existing empirical work, little is known about the specific kinds of questions programmers ask when evolving a code base. Understanding precisely what information a programmer needs about the code base as they work is key to determining how to better support the activity of programming. The goal of this research is to provide an empirical foundation for tool design based on an exploration of what programmers need to understand about a code base and of how they use tools to discover that information. To this end, we undertook two qualitative studies of programmers performing change tasks to medium to large sized programs. One study involved newcomers working on assigned change tasks to a mediumsized code base. The other study involved industrial programmers working on their own change tasks to code with which they had experience. The focus of our analysis has been on what information a programmer needs to know about a code base while performing a change task and also on how they go about discovering that information. Based on a systematic analysis of the data from these user studies as well as an analysis of the support that current programming tools provide for these activities, this research makes four key contributions: (1) a catalog of 44 types of questions programmers ask, (2) a categorization of those questions into four categories based on the kind and scope of information needed to answer a question, (3) a description of important context for the process of answering questions, and (4) a description of support that is missing from current programming tools.

Much of the elegance and power of Smalltalk comes from its programming environment and tools, but despite the passage of more than 20 years, the Smalltalk browser is much the same today as when it was first introduced. We have extended this browser with features that dramatically improve its support for incremental programming by employing real-time analysis of the code being modified. We illustrate these improvements by example, and summarize the algorithms used to implement them efficiently.

Reusability is widely believed to be a key to improving software development productivity. However, in practice, effective reuse is more an achievement of good development environments than a strategy for software development. It seems natural that a reduction of the effort needed for reuse should have a positive impact on reuse. Among the various lines of attack that may lead to a reduction of the reuse effort, we address the problem of finding and understanding reusable functionality in an object-oriented software environment. This paper presents the Affinity Browser, a selection and exploration tool based on the notion of affinity between objects. The user is presented with a two dimensional display where the objects are displayed in such a way that their relative positions convey their affinity i.e., objects lying closer together are more strongly related than objects lying farther apart. The browser provides for different views of the relationships among objects. Each view is base...